「バイブコーディングはプロトタイプの道具だ」——この批判はずっとあった。AWSは2025年7月、その批判にIDEを丸ごとぶつけて答えを出した。それがKiroだ。
バイブコーディングの「Stage 2問題」
バイブコーディングが機能する場面がある。アイデアを試す段階、動作確認、プロトタイプ。「こういうものを作りたい」という曖昧なイメージが、数十分でUIになる体験は本物だ。
問題はその先だ。機能を20個追加したとき、3週間前に動いていたログイン機能が壊れる。AIに「直して」と言えば直るが、別の場所が壊れる。この追いかけっこが始まると、多くの人が「AIが悪い」と思う。だが根本的な原因は別にある。
仕様書がないから、AIはセッションをまたぐたびに意図を失う。
AIは前の会話で「この設計にした理由」も「この関数がこう動くべき理由」も覚えていない。文脈を持たずに指示が積み重なる。コードが矛盾し始めるのは時間の問題だ。仕様書駆動開発（SDD）という考え方がこの問題に答えを出しているが、それを「意識して実践する」かどうかは開発者次第だった。
Kiroは違う。「仕様書を先に書く」をIDEの標準ワークフローとして組み込んだ。 意識しなくても、仕組みがそこに引き込む。
Kiroとは何か
Kiroは、AWSが開発したAI IDE（統合開発環境）だ。2025年7月14日にプレビュー版をリリースし、2025年11月17日に正式版（GA）として一般提供を開始した。
ベースはVS Codeと同じオープンソース（Code OSS）で、Mac・Windows・Linuxに対応する。見た目や操作感はVS Codeに近いので、CursorやWindsurfを使ったことがあれば馴染みやすい。AIモデルはAnthropicのClaude Sonnet 4.6を中心に使用し、Autoモードでは用途に応じてモデルが自動選択される（2026年2月にSonnet 4.5からアップグレード）。MCP（Model Context Protocol）もネイティブサポートしており、GitHubやデータベースなどの外部ツールとの接続も可能だ。
CursorやClineとの技術的な違いは、搭載するAIモデルよりもワークフローの設計思想にある。Kiroの核心は「コードの前に仕様書を書く」という強制機能だ。
3段階のSpecワークフロー
Kiroの最も特徴的な機能がSpecワークフローだ。1つのプロンプトを入力すると、コードを書く前に3つの仕様書ファイルを生成する。
Stage 1：Requirements（要件定義）
ユーザーストーリーと受け入れ条件をrequirements.mdとして生成する。特徴的なのがEARS記法（Easy Approach to Requirements Syntax）の採用だ。もともとRolls-RoyceのAlistair Mavinが航空機エンジンの制御システム要件定義のために開発した書き方で、「誰が・何をしたとき・システムはどう動くか」が1文に収まる。
バイブコーディング的な指示と、KiroのEARS記法で生成される要件の違いを見てほしい。
❌ バイブコーディング的な指示
「ログイン機能を追加して」
→ AIは最低限の実装をする。3回失敗でロック？セッション期限は？何も決まっていない。
実装のたびに解釈がブレる。
✅ KiroがEARS記法で生成する要件（requirements.md）
When the user submits the login form with valid credentials,
the system shall redirect to the dashboard within 2 seconds.
When the user submits invalid credentials 3 consecutive times,
the system shall lock the account for 15 minutes and display a notification.
When the user session exceeds 30 minutes of inactivity,
the system shall require re-authentication before allowing further access.
条件（When）・動作（shall）・期待結果が明確に分かれているため、AIがコードを書くときの判断基準が揃う。「なんとなく動く」ではなく「この条件に合格する」という基準でコードが評価される。エッジケース——「3回連続で失敗したらどうなるか」「非アクティブが続いたらどうなるか」——が最初から可視化されていることが、バイブコーディングとの決定的な差だ。
Stage 2：Design（技術設計）
要件をもとにdesign.mdを生成する。TypeScriptの型定義、APIのエンドポイント設計、データベーススキーマ、データフロー図が自動で作られる。コードを書く前に設計の矛盾を発見できるのが、このフェーズの価値だ。実装後に「設計が間違っていた」と気づくのと、前に気づくのでは修正コストが大きく違う。
先に建築図面を書いてから工事を始めるようなものだ。バイブコーディングでは「とりあえず柱を立てて、次に壁を考える」。Kiroは「図面を引いてから資材を発注する」。
Stage 3：Tasks（タスク分解）
設計をもとに、依存関係を考慮した実装タスクのリストが生成される。各タスクには単体テスト・統合テスト・アクセシビリティ対応が含まれる。「機能を作る」だけでなく「品質基準を満たす」ところまでタスクに組み込まれている点がバイブコーディングとの決定的な違いだ。
Agent Hooks：「書いたら動く」自動化
Agent Hooksは、ファイルの操作をトリガーにAIが自動で追加作業を行う仕組みだ。「GitHubActionsのローカル版、AI搭載」と表現すると分かりやすい。
設定ファイルは.kiro/hooks/に置く。以下の例では、src/**/*.tsxのファイルを保存するたびに対応するテストファイルを自動更新する。
{
"name": "Test Updater",
"event": "file_saved",
"filePattern": "src/**/*.tsx",
"prompt": "このコンポーネントに対応するテストファイルを更新してください。新しいpropsや変更されたロジックに合わせてテストケースを追加・修正してください。"
}
他に使えるトリガーとしては、ファイルの作成・削除、エージェントのライフサイクルイベント、コミット前のセキュリティスキャンなどがある。
実際の使用例でよく挙げられるのは以下の3パターンだ。
- Reactコンポーネントを保存 → テストファイルを自動更新
- APIエンドポイントを変更 → READMEを自動更新
- コミット前 → セキュリティスキャンを自動実行
バイブコーディングで最も起きやすい「コードを変えたがテストは放置」という状態を、仕組みで防ぐ。
Agent Steering：AIへの「永続的なルール書き」
Agent Steeringは、プロジェクトのルールをAIに永続的に記憶させる仕組みだ。.kiro/steering/にMarkdownファイルを置くだけでいい。
Claude CodeのCLAUDE.mdと発想は同じだが、Kiroはこれをより整理された形で提供している。ワークスペース単位（プロジェクト固有）とグローバル単位（全プロジェクト共通）の2種類があり、ワークスペースの設定が優先される。
# .kiro/steering/project-rules.md
## 技術スタック
- フロントエンド: Next.js 15 + TypeScript（strict mode）
- データベース: Supabase（Row Level Securityを必ず有効化）
- 認証: Supabase Auth（独自実装禁止）
## コーディング規約
- コンポーネントは必ず関数コンポーネントで書く
- APIエンドポイントには必ずzodでバリデーション
- エラーメッセージはユーザーに内部情報を露出しない
## AIへの指示
- コードを書く前に必ず仕様書を確認すること
- 仕様書に記載のない変更を勝手に行わないこと
これを置いておくと、毎回のセッションでAIがこのルールを読み込んでから作業を始める。「毎回同じことを指示する手間」がなくなるのに加え、チームで複数人がAIを使う場合に認識を揃える効果もある。
料理で言えば、シェフが交代しても同じ料理が出てくるための「店のレシピブック」だ。バイブコーディングでは感覚で調理していたところを、レシピを先に書いておくことで再現性を持たせる。
Property-Based Testing：仕様からテストを自動生成
GAリリース（2025年11月）で追加された機能がProperty-Based Testingだ。仕様書から「このコードが持つべき性質（Property）」を自動で抽出し、数百〜数千のランダムなテストケースを生成してコードを検証する。
通常のテストは「この入力を入れたら、この出力が返る」という特定のケースを確認する。Property-Based Testingは「どんな入力を入れても、この性質を満たすはずだ」という前提から出発して、AIが考えつかないエッジケースを自動で発見する。
たとえば仕様書に「認証済みの任意のユーザーが、有効な任意のリスティングを閲覧できる」と書いてあれば、KiroのPBTは「認証済みユーザー×有効なリスティング」の組み合わせをランダムに大量生成して、すべてのケースで動作を確認する。さらに"shrinking"という技術で、テストが失敗したときに「最小限の失敗ケース」まで自動で絞り込む。「どんな条件で壊れるのか」の特定が速くなる。
バイブコーディングでは「動いた！」で次に進みがちだが、この機能によって「本当にどんな条件でも動くか」という検証のハードルを超えやすくなる。
Claude Code・Cursorとの思想的な違い
KiroはSpec-Drivenを「強制」する。Claude CodeとCursorはユーザーが自由にワークフローを選べる。どちらが優れているかではなく、思想の違いを理解した上で選ぶ必要がある。
| 比較軸 | Kiro | Claude Code | Cursor |
|---|---|---|---|
| インターフェース | フルIDE（VS Codeベース） | CLI + 拡張機能 | VS Codeフォーク |
| AIモデル | Claude Sonnet 4.6（Auto選択あり） | Claude Opus 4.6 | マルチモデル |
| ワークフロー | Spec-Driven（仕様書を強制） | フレキシブル（ユーザー次第） | 会話型（インライン） |
| 料金 | $0〜$200/月（クレジット制） | $20〜$200/月（サブスクリプション） | $0〜$200/月（固定） |
| 向いている用途 | 本番開発・チーム開発 | 複雑なタスク・自動化 | 日常的なコーディング補助 |
Kiroの「強制」は制約でもある。素早くコードを試したいプロトタイプ段階では、仕様書生成フローが邪魔になる場面もある。Kiro自身も「vibe mode」（spec生成をスキップして直接コードを書くモード）を持っているのは、その認識があるからだ。
「意識してSDDを実践できる人」にはClaude CodeやCursorで十分だ。「仕組みがないと仕様書を書かない」という自覚があるなら、Kiroが有効に機能する。
Amazonが自社のエンタープライズ基盤（IAM Identity Center）と統合し、GovCloud（米国政府系クラウド）にも2026年2月に対応した点は注目に値する。Kiroは個人開発者向けのツールというより、エンタープライズとチーム開発を主戦場と見ている。
料金と、GAリリース直後に起きたトラブル
Kiroの料金は以下の通りだ（2026年2月時点）。
| プラン | 月額 | クレジット/月 | 超過料金 |
|---|---|---|---|
| Free | $0 | 50 | なし |
| Pro | $20 | 1,000 | $0.04/クレジット |
| Pro+ | $40 | 2,000 | $0.04/クレジット |
| Power | $200 | 10,000 | $0.04/クレジット |
新規登録時に500ボーナスクレジット（ソーシャルログインまたはAWS Builder ID利用時）が付与される。未使用クレジットの翌月繰越はない。超過課金はデフォルトで無効になっている。Series B以前のスタートアップ向けにPro+の1年間無料特典もある。
ただし、GAリリース直後に課金トラブルが発生した。1リクエストで複数クレジットが消費されるバグが見つかり、「軽い使用で月550ドル、本格使用で1,950ドルに達する可能性がある」というユーザー報告が出た。AWSはバグを認め、当該月の利用分を無料にした上で修正後のクレジットをリセットする対応を取った。
このトラブル自体は解決済みだが、新しいAIツールの課金モデルに慣れていない段階で超過課金が発生しやすい点は意識しておく必要がある。初めて使う場合は超過課金が無効になっていることを確認し、Freeプランから始めることを勧める。
Freeプランは月50クレジットしかない。Specワークフローはクレジットを消費するため、本格的に試すにはProプラン（月$20）以上が現実的だ。まず30日間のボーナスクレジット500で試してから判断するのが無難な順序だ。
誰がKiroを使うべきか
Kiroが向いているのは、次のいずれかに当てはまる人だ。
プロトタイプから本番に進もうとしている人。 バイブコーディングで動くものが作れたが、機能を増やすと壊れる問題に直面している。仕様書を書いたほうがいいと分かっていても、どう書けばいいか分からない人に、Kiroのワークフローは道筋を示す。
チームでAI開発ツールを使う人。 複数人が別々のAIツールに「それぞれの言い方で指示」を出すと、コードの一貫性が崩れる。Steeringファイルに共通ルールを書いておくことで、チーム全員のAIが同じ基準で動く。
AWSエコシステムと深く連携している人。 IAM Identity Center、GovCloud、AWS Activateクレジットとの統合は、AWS環境で本番システムを運用している組織向けに設計されている。
逆に、向いていないケースもある。素早くプロトタイプを試したいだけなら、仕様書生成フローは手間だ。Claude CodeやCursorの自由度が合う場面は多い。
「仕様書を書くだけでAIが勝手にいいコードを書いてくれる」という期待は禁物だ。仕様書の品質が低ければ、AIが生成するコードも低品質になる。「良い仕様書を書く能力」こそが、Kiroの恩恵を最大化する鍵だ。
Specを書く習慣が開発の質を決める
Kiroが提示しているのは、ツールの機能よりも開発の順序の話だ。「コードより先に仕様書を書く」——この順序が守られるかどうかが、プロトタイプで終わるか本番プロダクトになるかの分岐点だ。
Kiroはその順序を強制機能として組み込んだ。IDEが誘導するから、意識しなくても仕様書を書く方向に引き込まれる。これは制約でもあるが、「仕様書を書く習慣がまだない」人にとっては有効な補助輪になる。
バイブコーディングを否定する必要はない。プロトタイプには威力を発揮する。ただ、そこから「壊れずに育つプロダクト」にするには、仕様書という下地が必要だ。Kiroはその下地を作る手順を、ツールとして提供している。
SDDの方法論そのものについては仕様書駆動開発の解説記事で詳しく扱っている。まずClaude Codeで手動SDDを試してみて、それでも仕様書を書く習慣が身につかないと感じたら、Kiroを試してみる順序がいいだろう。
