仕様を書いてからコードを書け。AWS Kiroが「バイブコーディングの弱点」を正面から潰しにきた

バイブコーディングに足りなかったのは「書く前の5分」だった

先週まで4本の記事を書いた。テーマはバイブコーディングのセキュリティだ。

Moltbookの150万APIキー流出を掘り下げた。Cursor CEOの「脆い基盤」発言を追った。Forrester（フォレスター）の3原則で答え合わせをした。「ノリから統制へ」の転換点も整理した。

書きながらずっと感じていた。問題はセキュリティだけじゃない。品質そのものが不安定なのだ。

Cursorを開く。「こういう機能を作りたい」と打ち込む。動くものが出てくる。楽しい。

ただ翌週に見返すと、設計の意図がわからない。テストが通らない。仕様変更にも対応できない。

「動いた」と「使える」の間に大きな溝がある。

この溝の正体を、あるデータが教えてくれた。Stack Overflowの2024年調査が示した数字だ。AIコーディングツール利用者の63%が、デバッグに「想定以上の時間」を費やしていると回答している。速く書けても、直すのに時間がかかる。ここがバイブコーディングのアキレス腱だ。

AWSが作ったKiro（キロ）というIDEがある。この溝を正面から埋めにきたツールだ。

発想はシンプルだった。コードを書く前に仕様を書け。たったこれだけで品質問題が構造的に変わる。

元・挫折エンジニアの私が、Kiroの仕様駆動開発を整理する。

AWS Kiroとは何か。「構造が先、コードは後」のIDE

KiroはAWSが開発したAI搭載のコードエディタだ。VS Code（Visual Studio Code）をベースに作られている。

見た目はCursorに似ている。ただし設計思想がまるで違う。

Cursorは速度が武器だ。書きながらAIが逐次補完する。

Claude Codeは自律性が武器になる。リポジトリ全体を理解して変更を提案する。

Kiroの武器は構造にある。コードを1行も書く前に、3つのドキュメントを自動生成する仕組みだ。

1つ目が**requirements.md（要件）**だ。何を作るのかを定義する。ユーザーストーリーと受け入れ基準を記述する。

2つ目がdesign.md（設計）。どう作るのかを決める。技術設計やDBスキーマ、シーケンス図が含まれる。

3つ目がtasks.md（タスク）。実装の手順書だ。チェックリスト形式で1つずつ消化していく。

「こういうアプリを作りたい」と自然言語で伝える。Kiroが3ファイルを生成する。中身を確認してOKを出す。その後で実装に進む。

この手法を**Spec-Driven Development（仕様駆動開発）**と呼ぶ。

2025年7月にプレビューが公開された。同年11月にGA（一般提供）が始まっている。

公式サイトによると、プレビューだけで25万人以上が利用した。

料金は無料プラン（月50クレジット）からスタートできる。Proは月$20で1,000クレジット。Pro+は月$40で2,000クレジットだ。

無料枠で十分に試せる。試すハードルは低い。

ここで大事なポイントがある。Kiroは「AIがコードを書くツール」ではない。**「AIが設計を書くツール」**と理解したほうが正確だ。コードは設計の結果として出てくる。この順序の違いが品質に直結する。

Kiroには「ステアリングフック（Steering Hook）」と呼ばれる仕組みもある。実装フェーズでコードが仕様から逸脱しそうになると、requirements.mdを参照して軌道修正を促す。仕様が「生きたドキュメント」として実装全体を監視し続ける構造だ。

EARS記法。ジェットエンジンの安全基準がバイブコーディングに降りてきた

Kiroの要件定義にはEARS記法が使われている。正式名称はEasy Approach to Requirements Syntax（イージー・アプローチ・トゥ・リクワイアメンツ・シンタックス）。読み方は「イアーズ」。

この記法が生まれた場所が面白い。Rolls-Royce（ロールスロイス）のジェットエンジン部門だ。

2009年にAlistair Mavin（アリスター・マービン）らが開発した。ジェットエンジンの耐空性規則を記述する手法だ。「この条件でエンジンはこう動く」を曖昧さなく書く。そのために生まれた構文である。

基本形はこうなる。

# EARS記法の基本形
# While（前提条件）+ When（トリガー）+ shall（システム応答）

WHEN a user submits a contact form with valid data
THE SYSTEM SHALL send confirmation email within 5 minutes
AND display success message

5つのパターンがある。

• Ubiquitous（普遍）: 常に適用される要件。「全リクエストをログ記録」
• Event-driven（イベント駆動）: 特定イベント発生時。「ログインでセッション生成」
• State-driven（状態駆動）: 特定の状態にある間。「メンテナンス中は書き込み拒否」
• Unwanted behavior（非期待動作）: エラー時の対処。「認証3回失敗でロック」
• Optional feature（オプション）: 条件付き機能。「プレミアムならCSVエクスポート」

EARS公式サイトによると、Airbus（エアバス）、NASA、Bosch（ボッシュ）、Intel（インテル）が採用している。航空宇宙・自動車・半導体の現場で検証済みだ。

なぜこれがバイブコーディングに効くのか。具体例で示す。

EARS記法なしのプロンプト: 「ログイン画面を作って」

EARS記法ありの要件:

WHEN a user attempts to log in
THE SYSTEM SHALL validate email and password format
IF the credentials are incorrect 3 consecutive times
THE SYSTEM SHALL lock the account for 30 minutes
AND send a security notification to the registered email

上の「ログイン画面を作って」というプロンプトで何が未定義かわかるか。ロックアウトの条件、通知の有無、ロック時間、回復方法。全部が未定義だ。AIはプロンプトに書かれていないことは書いてくれない。

EARS記法の「非期待動作」パターンを使うだけで、エラーケースが自然に洗い出される。「3回失敗したらどうなるか」は意識しないと書き忘れる。でも「IF the credentials are incorrect…」という型があれば、そこに填める形で考えられる。

ジェットエンジンの安全基準がAIコーディングの品質管理に降りてきた。この「降りてきた」感覚が、個人的に一番興奮するポイントだった。

「数ヶ月→3週間」。製薬AI事例が示したKiroの実力

理論だけでは説得力が足りない。Kiroで実際に何が起きたか。2つの事例を紹介する。

1つ目は製薬AI事例だ。AWS Industries Blogに掲載されている。

3人の開発者が3週間で、本番対応の創薬エージェントを構築した。

扱うデータが膨大だ。PubMed（パブメド）やChEMBL（ケムビーエル）など30以上のバイオメディカルDBがある。PubMedだけで年間約150万件の論文が追加される。

この膨大なデータを横断統合する。治療ターゲットを特定し、エビデンスに基づく推奨を出すシステムだ。従来なら数ヶ月かかる規模のプロジェクトである。

3週間で完成した鍵はrequirements.mdにある。「どのDBから何を取得するか」を先に定義した。「エビデンスの信頼度評価方法」も明記した。「推奨の出力形式」も決めた。すべて実装前の段階でだ。

コードを書く前に仕様が固まっている。だから3人でも迷わず手を動かせた。

2つ目はRackspace Technology（ラックスペーステクノロジー）の事例だ。こちらはさらに劇的だ。見積もり52週間の作業を3週間で完了した。90%の効率向上と報告されている。

私が注目したいのは速度だけではない。仕様が先に存在するから、完成品を仕様と照合できる。「動いたけど正しいかわからない」。この不安が構造的になくなる。

前職でCSをやっていた経験から言わせてほしい。「要件が曖昧なまま開発が走る」のは炎上の典型パターンだ。AIが書く時代でも、この原則は変わらない。

Kiro × Cursor × Claude Code。3つの思想を整理する

「Kiroが最強」と言いたいわけではない。3つのツールは、解いている問題が違うのだ。

Cursorの設計思想は「速さ」にある。Sub-200ミリ秒のタブ補完で手が止まらない。バグ修正やリファクタリング、小規模プロトタイプが得意だ。速度が命のシーンで替えが利かない。

Claude Codeの強みは「自律性」だ。ターミナルから動き、Gitワークフローに乗る。大規模リポジトリの修正に強い。複数ファイルにまたがる変更が得意だ。

Kiroの信条は「構造が先」だ。新規プロジェクトの立ち上げに合う。要件→タスクのトレーサビリティがある。チーム開発や監査が必要な場面で力を発揮する。

使い分けの目安はこうなる。

• プロトタイプを速く → Cursor
• 既存コードを大きく変えたい → Claude Code
• 新規を品質込みで立ち上げたい → Kiro

私は3つとも併用している。初期設計はKiro。日々の修正はCursor。大規模リファクタリングはClaude Codeだ。

たとえば業務ツールを新しく作る場合。まずKiroでrequirements.mdを生成する。設計が固まったら、日常的な機能追加はCursorで回す。3ヶ月後に大規模な構造変更が必要になったらClaude Codeに任せる。

「どれが上か」ではない。「何を解決したいか」で選ぶ。ツールの選択肢が増えること自体が進歩だ。

試してわかった「仕様を先に書く」の実感

理論と事例の次は、私自身の体験を話す。Kiroの無料プランで業務ツールの設計を試した。

作りたかったのはSlackフィードバック自動分類ツールだ。特定チャンネルの投稿をカテゴリ別にスプレッドシートへ転記する。以前Cursorで作りかけて放置していた。

Cursorで挫折した理由は「分類の基準」で迷ったことだ。バグ報告と機能要望をどう分けるか。信頼度が低い分類はどう扱うか。考え始めると手が止まった。

KiroにSlackフィードバック分類ツールの要件を入力した。

生成されたrequirements.mdに驚いた。

# requirements.md（Kiroが自動生成した要件の一部）
# EARS記法でアクセプタンスクライテリアが定義されている

## ユーザーストーリー1: フィードバック自動分類
WHEN a message is posted in the designated Slack channel
THE SYSTEM SHALL classify the message into one of:
  - bug_report
  - feature_request
  - praise
  - question
AND store the classification with confidence score

## 非期待動作
IF the classification confidence is below 0.7
THE SYSTEM SHALL flag the message for manual review
AND notify the admin channel

「信頼度0.7未満なら手動レビューに回す」。この要件はCursorで作った時に思いつかなかった。EARS記法の「非期待動作」パターンが、エラーケースを洗い出してくれたのだ。

さらにdesign.mdも生成された。Slack API→分類エンジン→Google Sheets APIの接続設計が書かれている。tasks.mdには12個の実装タスクがチェックリスト形式で並んだ。

コードを書く前に全体像が見える。Cursorの「とりあえず動かす」とは質が違う安心感だ。

実際に実装を進めると、その安心感の正体がわかった。「次に何をすべきか」に迷う時間がゼロだった。tasks.mdの1番から順番に消化するだけでいい。Cursorでコードを書いている時も、「いまrequirements.mdの何を実装しているか」が常に明確だった。

正直に書くと、仕様生成には1回10〜15秒かかる。即座の補完に慣れていると少しもどかしい。

ただ15秒で得られる設計精度を考えてほしい。私がCursorで「分類の基準どうしよう」と30分迷っていた問題が、requirements.md生成の15秒で解決した。

「とりあえず動くもん作ろう」が私の哲学だ。これは変わっていない。変わったのは「動かす前に5分だけ仕様を確認する」手順が加わったこと。たった5分で、後の修正3時間を節約できる。

バイブコーディングの品質問題は「ツール」ではなく「順序」だった

ここまでの話を整理する。

品質が安定しない原因はツールの性能不足ではなかった。仕様を定義するステップが抜けていた。それだけの話だ。

Kiroが証明したのは「順序の逆転」の効果である。

• 製薬AI: 数ヶ月→3週間。requirements.mdで先に要件を固めた
• Rackspace: 52週→3週間。仕様駆動で90%効率向上
• EARS記法: ジェットエンジン安全基準由来の手法がAIコーディングの品質管理に使える
• 25万人以上が利用: 無料プランから始められる

三部作でセキュリティの問題を追いかけた。第4弾で「ノリから統制へ」の転換を書いた。今回の結論はさらにその先だ。

統制の正体は「仕様を先に書く」だった。

まず1回だけやってみてほしいこと

Kiroを試す時は、大きなプロジェクトから始めなくていい。次の手順で体験できる。

1. kiro.dev の無料プランに登録する
2. 普段Cursorで「作りたいけど後回しにしている」ツールを1つ思い浮かべる
3. Kiroに「〇〇を作りたい。まずrequirements.mdを生成して」と入力する
4. 生成された要件を読む。「これ考えてなかった」という項目を探す

4番でひとつでも「これ考えてなかった」が出てくれば、Kiroの価値は証明される。仕様書を読んで「そうか、ここまで決める必要があったのか」と気づく体験こそが、バイブコーディングの次のステージへの入口だ。

セキュリティを意識した。統制の重要性を理解した。そして仕様を先に書く習慣をつける。この3ステップで、バイブコーディングは「遊び」から「武器」に変わる。

かつてプロのエンジニアと仕事をした時を思い出す。彼らが最初にやっていたのは要件定義だった。コードを書くのは最後だった。

あの頃、自分にはその「最初の設計」ができなかった。技術力が足りないと思っていた。

Kiroはその設計をAIがやってくれるツールだ。

凄腕エンジニアが自分に宿る体験をCursorで感じた。Claude Codeで確信が深まった。Kiroで加わったのは「設計する力」だ。

書ける。直せる。そして設計できる。バイブコーディングが次のステージに入った。

もし今バイブコーディングに不安を感じている人がいるなら、「ツールを変える」のではなく「順序を変える」ことを試してほしい。仕様を先に書く。たったそれだけで体験が変わる。

kiro.devの無料プランで、まずrequirements.mdを1回だけ生成してみてほしい。同じような壁を感じている人に、この体験を届けたい。