Kiro に仕様駆動開発を強制してもらう理由 – ChatGPT や Claude Code にはできない新しいウォーターフォール

D.M.です。

結論ファースト

・Kiroの凄さは、仕様駆動開発をUI・UX（体験）として強制するところ。
人間が判断する部分を減らすワークフローになっていて、これが楽しい。

アジェンダ

1. Kiroとは
2. 優れた点
3. 課題と将来性

1. Kiro とは

AWS が7月に公開したIDEです。
https://kiro.dev/
コンセプトとして、「仕様駆動開発」スペックドリブンデベロップメント Spec Driven Development を強く打ち出しているツールになります。
※他にもプランニングファーストエンジニアリング Planning First Engineering といった単語で説明している人も見かけました。

発表直後から注目が非常に高まっていまして、2025年7月22日ごろの公式発表によると
・新規ユーザーは全て Waitlist 送り
・既存ユーザーも Rate Limit 付きであんまり自由に使えません
・有料プラン開始までもうちょっとしばらく調整
みたいになってしまいました。

なぜKiroが注目されるのか?

仕様の要件定義を含めた開発の流れ全体をAIエージェント化するコンセプトはLLM登場とともに提案されています。

これまで数えきれないほどのAIエージェントが発表されました。
（この記事とかすごい大量に紹介してる https://tech.algomatic.jp/entry/2024/04/04/180922 ）
Devin
ChatDev
AutoDev
AutoGen（Microsoft）
…

AIエージェントのタイプ別分類
IDE型、CLI型、クラウド型（自立型）

この乱立状況下で Kiro の差別化要素は以下にあると考えています。
・「仕様駆動」で、仕様ドキュメントの書式にこだわる。EARS形式！
・要件定義→基本設計→実装タスク一覧といった開発フローの強制。ウォーターフォール的！

AIエージェントといえば Vibe Coding が主流だと思います。
要件としてのプロンプト情報が少ない場合でも、それらしいものを雰囲気で実装できてしまうあれです。
仕様駆動開発はバイブコーディングに対する一つのアンチテーゼとして提案されました。
以下では仕様駆動開発の核である Spec について掘り下げていきます。

2. Kiro の優れた点

[Kiro クイックスタート]

① Kiro立ち上げ。
② 適当な空Folderを選ぶ。
③ UI上で Spec を選ぶ。
④ 「○○がほしい」的な1行プロンプトを送る。
⑤ 要件定義、基本設計、タスク一覧が生成される。

まず①。IDEを立ち上げてフォルダを選びます。

②、③ で、チャットインタフェースが現れます。

この「Spec」が要件定義ドキュメントを自動的に生成してから開発に入るエージェントになってます。
プロンプトを書くと感じに要件定義書を作ってくれて、もちろん1行でもいいんですが、なんか画像をマルチモーダルで送ってそれに補足説明してもやってくれたりします。

実際ドキュメントは3つできます。
要件定義 requirements.md
基本設計 design.md
タスク一覧 tasks.md

要件定義の方をしっかり作って、基本設計をして、タスクリストを作って、、っていうWeb開発の一般的な開発フローに近い流れでドキュメントを整理してからコードを書き始めます。（これらをすっ飛ばしていきなり Vibe Coding もできる）

例）「天秤.AI」の要件定義書を起こしてもらう

今回やってみたのは、弊社グループの「天秤.AI」っぽいシステム開発です。（ LLM を複数同時実行するツールになっています）
https://tenbin.ai/

私はIDE上のチャットに本番で動いているシステムの画像をポコっと貼り付けて「こんな感じの画面を作りたいです」っていう雑なプロンプトを書いて送りました。（下の画像の右側がチャットインタフェースです）（画像だけでは指示が出せなかったので一言書いています）

そうするとKiroが画像からモデルを複数実行してますねみたいな点を読み取ってくれて、要件定義書 requirements.md を書いてくれました。（下の画像の左側）
要件定義書の中身はEARSという形式に沿って書かれています。

・概要（上の画像の左側）
簡単な2、3行が入ります。

・ユーザストーリー（上の画像の左側）
スクラムのユーザーストーリーが生成されます。
この下の「受け入れ基準」がEARSの核心です。
この機能が何をできますよっていうのを、 While, When, Where, If の条件に応じて Then 何をするかという形式で記載します。

While (状態) にある場合、
When (契機) が発生した場合、
Where (条件) があるした場合、
If (不測の事態) が発生した場合、
Then (応答) する。

受け入れの基準としてユーザーがこうしたらこういう挙動をします、みたいのを、条件とともに詳細に書いてくれるのがEARSの特徴です。
BDD （Behavior Driven Development）にも通じるところがあり、テストの観点からも理解しやすい形式ではないでしょうか。
今回は6個の要件を自動的に生成して、それに関するユーザーストーリーと受け入れ基準を生成してくれました。
同じようにして、この要件を実現するためのシステムの「基本設計」 design.md と、実際の実装の「タスク一覧」 tasks.md も生成してくれます。

Kiro の Spec 機能は本当に凄いのか？

そもそも要件定義ぐらいLLMで元々できたんじゃないでしょうか。
この疑問があると思うんですね。
要件定義プロンプトで検索するとそれなりにひっかかります。
そんなプロンプトを使わなくても、ChatGPT o3 にとりあえずやらせてみたら、むしろ Kiro よりたくさんの仕様定義を書いてくれました。

ChatGPT o3 へのプロンプト

「このあなたは要件定義の専門家です。2つのLLMを同時に実行するチャットツールを考えてください。仕様が不明な箇所は一般的な要件で埋めてください。」
そのあと先ほどのEARSのフォーマットを教えてあげるんですね。この形式で書いて受け入れ基準を書いてくださいみたいにしてやる。

レスポンス

概要として、2つのLLM同時に実行できます。対象のユーザーは一般ユーザーとか、スコープとしてこんなところを考えてます。想定しない項目（アウトオブスコープ）、非機能要件なんかも書いてくれました。
さっきの Kiro の Spec よりもむしろ詳細に答えてくれるぐらいの内容ではある。
これ全部画像を載せると非常に長いので割愛しますが、なんとストーリーを20個ぐらい出してくれました。

こうしてみると、別に Kiro の Spec にオリジナリティってあんまりないんじゃないの、っていうことも言えると思うんですね。

改めて Kiro は何が凄いのか？（まとめ）

ではこの Spec の独自性はどこにあるのか。

それは、全体のUXです。

・開発フローの強制
UI・UX的に、要件定義 → 基本設計 → タスク一覧 → 実装という開発の流れを強制されます。すると人間が考えなくちゃいけないところが減るので、気楽に流れに乗っていくだけである程度かたちになるという開発体験になります。この流れがシームレスなのが気持ちがいい。仕様駆動開発がこのIDE環境1つで完全に固まって綺麗に流れていくっていうのが非常に洗練されていると感じています。

・属人性の排除
流れがツール1つで完結できるということは、属人性の排除にもつながります。例えば、他のツール Claude Code と ChatGPT o3 を使ったらこうできるよねというアイデアを組み合わせなくても、 Kiro さえ利用しておけば全部が整っているよねという状況になり、個別の開発者のアウトプットの安定化につながるといえると思います。

これこそが Kiro に仕様駆動開発を強制してもらう理由になるのではないでしょうか。私たちは余計なことを考えずに確実なフローを着実に進捗させたい。そんな観点から私はこのツールにハマりつつあります。

Spec以外の機能もいいぞ

Kiro の Hook は自然言語で Hook できる

一般的に Hook と言うと、「AをしたらBをする」を自動化する機能に当たると思います。
例） Formatter / Linter
git で commit / push した時に Formatter, Linter とかをかけて、書式の整形などをするような処理
これは通常はスクリプトを書いたり、ライブラリを入れたり、動作環境を整理したり色々準備をしてやっていくものです。

Kiro の場合のこの Hook を LLM にやってもらうことができる。LLMとMCPと自然言語で定義してやれば同じことが実現できます。

例）機密情報チェック
push した時に本番の API Key とか含んでないですよねみたいなことをLLMに命令するだけでチェックしてくれます。
これを自然言語でやれるので非常に柔軟性があって、少ない設定で実現できるっていうのが強みになるかと思いました。
※Claude Code の Hook + Sub Agent も似たようなことができそうなものがあったりするので、これからトレンド的にこういうのが出てくるかもと思っています。

Kiro Steering は自然言語で設定が書ける

Steering はプロジェクトルールを自然言語で書いておけばLLMがやり取りの前提として読み込みんでくれるのでその通り動作してくれる機能です。
例）日本語化
チャットのレスポンスは基本的にデフォルト英語になっちゃうので、そこを日本語で答えてねっていうのを初期プロンプトとして定義してます。（下の画像）

普通に日本語でこうして欲しいっていうプロンプトを書いてあるだけなんですけど、書くだけで日本語で回答してくれるようになりました。

Hook, Steering 凄いところ（まとめ）

・自然言語でやれちゃうっていうところがすごい楽です。
・属人的・環境依存の問題の排除。AWS や Github Actions みたいな縛りがなくて、Kiro とLLMさえ繋がってれば全然誰でもできちゃうのがすごいところだなと思っています。

FAQ

個人的に気になった箇所をFAQ形式で。

Spec は既存プロジェクトに適用できますか?

可能です。これはベストプラクティスのページにやり方が書いてあります。

翻訳 https://kiro.dev/docs/specs/best-practices/

いくつかのタスクがすでに実装されている場合はどうなりますか?

既存のコードベースで作業していると、同僚や自分が別のセッションで作業したために、仕様書内の一部のタスクが既に完了していることに気づくことがあります。このような場合に対処するには、以下の2つの方法があります。

オプション1:tasks.mdの「タスクの更新」をクリックする

tasks.mdファイルを開く
タスクの更新をクリック
Kiro は完了したタスクを自動的にマークします。

オプション2: スペックチャットセッションでKiroにスキャンを依頼する

仕様セッションで、Kiro に「どのタスクがすでに完了しているかを確認してください」と尋ねます。
Kiroはコードベースを分析し、実装された機能を特定します
Kiroは完了したタスクを自動的にマークします
これにより、タスクの仕様が正確になります。

情報は学習されますか?

YES。
オプトアウト設定をしっかりする必要があります。
公式ページに方法があります。
https://kiro.dev/docs/reference/privacy-and-security/#opt-out-of-data-sharing-in-the-ide

Kiroにコーディング力はあるのでしょうか？

Claude 4 Sonnet をベースにしたコード生成ができます。
このモデルは2025年7月現在で SWE-Bench Verified 最高レベルなので、そこに依存した高いクオリティが出せます。同様に設計書のクオリティも高いと考えられます。
GitHub Copilot 的なコード補完機能もあるんですけど、なぜか分からないんですが、デフォルトではオフになってます。マニュアルにも記載がなかったので掘っていかないと気がつかないっていうよくわからない設定でした。
また、 Kiro は Claude Code に比べて実装が遅いぞ！と社内の人が言っていました。（ Kiro がタスク一覧を完了するのに3時間かかったが、Claude Code だと同じタスクが20分ぐらいで終わる）原因が Rate Limit なのかエージェントの性能差なのかわかりませんが、そういう意見もある状況でした。

Cursor と比べてどうですか?

現段階では IDE として明らかに Cursor のほうが安定しています。（が、将来的に Kiro は強い競合になる可能性があります）

[細かいマイナス点]

・Kiroは出たばかりで、現状バグや要望が山積み
GitHub Issues が700個以上ありました。
こちら OSS としての GitHub ではなくて、あくまで Issues を公開しているという状況みたいです。
https://github.com/kirodotdev/Kiro
※これとは別のGitHubでソースコード分析記事があります。下のほうで紹介します。

※Discordもあり、コミュニティでベストプラクティスなどが紹介されています。
https://discord.com/invite/kirodotdev

・Kiroは課金プランが開始されていない。（料金表が一回クローズしましたが、25年8月にようやくプランがもう1回表示されました。まだ Comming Soonではありますが、、）
https://kiro.dev/pricing/

・KiroはモデルはまだClaudeしか選べない。

・Kiroのコードベース把握力に関してはまだ不明な点がある。
Cursorと同じCodebase Indexingを持ってるんですけど、なんかネットの書き込み見るとそこまで高性能ではないんじゃないかっていうのがあるというところでした。
https://dev.to/aws-builders/kiro-vs-cursor-how-amazons-ai-ide-is-redefining-developer-productivity-3eg8

※ Kiro と Cursor は VS Code 1.94 をフォークし Open VSX マーケットプレイスを採用しているため Microsoft が専売化した公式 C++ 拡張や一部デバッガが利用できず、C++／.NET／Python で不具合がある可能性が報告されています。
https://ghuntley.com/amazon-kiro-source-code/
上の記事には Kiro のソースコードの分析がありました。以下のリンクでそのコードが読めると思います。
https://github.com/ghuntley/amazon-kiro.kiro-agent-source-code-analysis

3. Kiro の課題と将来性

課題

上述の通り Cursor がまだまだ IDE では優位です。 Kiro の強みである Spec は ChatGPT o3 で真似したりするのは簡単でしたので、 Cursor が同じ機能を提供するのもすぐやってくるのではないかと思います。加えて Devin や Claude Code も同様に Spec モードを作ってしまうことはできるので、競合にすぐに無力化される可能性があります。

将来性

（ここからは推測ですが） AWSプラットフォームの戦略として高い将来性があるのではないでしょうか。
IDE はエンジニアの作業の中心的存在ですので、ここを支配することで関連プロダクトの利用は推進できる状況を作り出せる可能性が大いにあります。
（ちょうど Google が Chrome を持ってるおかげで Google 関連のプロダクトが使いやすくなっているのと同じような状況を AWS も作り出せると思います）
例えば、AWS インフラに Kiro から AWS CDK で直接デプロイや変更を実行したり、 Amazon Q のような専用の LLM を通して AWS インフラをダイレクトに操作したりという機能のが今後提供されることが想定されます。
そうしていくと、どんどんベンダーロックインが進み、もちろん便利なんですけど、完全に支配的になっていくことで顕在化する別の課題もあるのかなと思っています。

結論

Kiro の強み
・Kiro の Spec は要件定義周りが統一的にできてその後の開発フローが強制される（それが気持ちいい）。
・Kiro の Hook, Steering は自然言語で指示を書けるのが楽。
・Kiro は属人化や環境依存の問題を最小化していく。
・Kiro には AWS エコシステムという観点で将来性がある。

逆に Cursor など他の競合ツールも同様の機能を真似できるハードルは低い。

他の仕様駆動開発

1. BMAD Method
https://github.com/bmadcode/BMAD-METHOD/
BMAD は仕様駆動開発のエージェントフレームワークです。（2025年4月に登場した模様）
PRD 形式でのドキュメントを生成します。ドキュメントが結構多めで、それらを分割（シャーディング）していくという特徴があります。

2. Claude Code Spec
https://qiita.com/nokonoko_1203/items/8bafb6033409aadccd9f
Claude Code に直接的に仕様書駆動開発をさせる方法が提案されています。（EARSフォーマットではないようなのですが、もし完全にKiro化したい人はプロンプトに一言 EARS と追記すればやってくれそうです）

これからさらに多数が提案されるのではないでしょうか。

採用に力を入れています。鋭意募集中

GMOインターネットグループ グループ研究開発本部 次世代システム研究室では、最新のテクノロジーを調査・検証しながらインターネットやロボットに関するアプリケーション開発を行うエンジニア、アーキテクトを募集しています。募集職種一覧 からご応募をお待ちしています。