KiroはAmazonが提供する仕様駆動型開発をAIで支援するIDEです。
生成AIに適切なコンテキストを渡す仕組みを作りたいけど、あまり手を出せていない人は多いのではないでしょうか。私もその一人で、そんな私にとってKiroはかなり衝撃的なプロダクトでした。
色々学ばせてもらった感謝の気持ちを込めて、Kiroの良いところをお伝えしたいと思います。
Kiroが提供するコアソリューション
仕様駆動開発（spec-driven development）はKiroの重要なコンセプトです。
要件（requirements）、構造化された設計（design）、実装タスク（tasks）を生成AIを活用して作成、管理し、熟練の開発者が行っているプラクティスを多くの人が効率的に行えるようにします。
個人的には、Kiroの最大の価値は、仕様駆動開発のワークフローをフレームワークとして提供していることだと考えています。また、各工程をシームレスにサポートする機能はとても強力だと感じています。
構造化されたドキュメント管理
Kiroでは、以下の3つのファイルが中核となります：
- 要件（requirements.md） - 構造化された EARS 記法でユーザーストーリーと受入基準を記述
- 設計（design.md） - テクニカルアーキテクチャ、シーケンス図、実装に関する考慮事項を記述
- タスク（tasks.md） - 個別の追跡可能なタスクによる詳細な実装計画を記述
これらは単なる独立したドキュメントではなく、相互に依存関係を持つ構造化された情報として管理され続けます。
例えば、以下はtasks.mdの例ですが、最後に要件（requirements.md）の何番に対応するかが記載されており、構造的なドキュメントの依存関係が管理されていることがわかります。
- [x] 1. Update GitHub summary module to remove arbitrary label feature
- Remove `label` parameter from `SummaryOptions` interface in
`src/github/summary.ts`
- ...
- _Requirements: 2.1, 3.1, 3.3_
作成もふんわりした機能の説明から要件ファイルが作成され、それをベースに詳細を詰めていきます。それをインプットに設計、またそれをインプットにタスクのファイルを作成します。
今回Kiroの検証で実際に作成したドキュメントのリンクを、参考までに以下に記載します。どんなものができるか興味があれば見てみてください。
高速な試行サイクルの実現
初期の要件や設計が完璧であることは稀です。むしろ、試行錯誤を通じて最適解を見つけていくプロセスが重要です。
Kiroにより要件、設計、タスクを頻繁に修正することができ、試行を高速に回すことができるのがメリットだと感じています。
個人的には、その体験をしっかり考え抜いた機能が多く実装されていると感じました。当社でも「体験を想像する」ことを重要視しているのですが、そのマインドを感じてプロダクトとしてはとても好印象です。
次に、そのマインドを感じた細かい体験、機能をいくつかご紹介します。
良かった体験
実装時の設計変更提案
実装の修正指示の内容から要件の変更に結びつきそうな場合はそれを提案してくれる機能がありました。それにより、要件や設計からまた練り直してタスクを再作成するというフローがシームレスにできます。
これにより実装レベルの気づきをドキュメントに反映でき、実装との乖離を防止できます。
専用タブによる効率的なドキュメント参照
仕様駆動開発では、要件、設計、タスクのファイルを頻繁に参照、編集します。Kiroでは、これらのファイル用の専用タブが用意されており、ワンクリックでアクセスできます。
このタブがあることで素早く確認できるのは、意外と大きなメリットだと思いました。こういう細かい機能の積み重ねが大きく効率を上げるように感じています。
タスク管理と変更履歴の追跡
完了したタスク実行における変更差分と、タスク実行時のセッションに飛べる機能があります。
これによりタスクがどのような経緯で変更されたかを追跡でき、実装時の判断根拠を後から確認できます。デバッグ時の原因調査が効率化されるなど、多くの利点があると感じました。
タスクは同時に1個しか実行できない仕様ですが、実行待ちが設定できるのも良いです。一気にここは作っちゃおうというタスクを一気に設定できます。
開発の中で考えていることがドキュメントとして残るのは、やはりいいなぁと思いました。これにより、後から「なぜこの設計にしたのか」を振り返ることができ、チームメンバーとの知識共有が容易になり、類似プロジェクトでの参考資料として活用できるなど、多くのメリットがあると思います。
また、それをベースとして要件を変更したら設計が、設計を変更したらタスクが変わるという依存関係で常に管理し続けることに、とてもメリットを感じます。それがあることによって、各変更を記録しながら、今までの変更内容を加味した修正等が行えると感じました。
またリファクタリングなどの経緯も残せます。下記は実際に機能ができた後にリファクタリングした時のタスクです。
コンテキスト管理の最適化
Kiroは、大きなコンテキストを含まないように、毎回必要な情報だけを読み取ってセッションを実行する設計になっているようです。
細かいセッションが区切られる設計になっていて、例えば、タスクを実行するごとに新しいセッションが開かれ、今まで作成した要件、設計、タスクのファイルが読み込まれます。
生成AIはコンテキストが膨らむとバカになるというのは有名な話ですが、仕様駆動開発で実装に必要な情報を構造的に管理することで最低限のインプットにすることが可能となるため、実装の精度も上がるのではないかと感じました。
現時点での制約
現時点では足りていない機能も多いと感じました。例えば、Devcontainerが利用できないのと、Web検索機能をしてくれないのは開発中にかなり不便を感じました。
ただ、まだ新しいプロダクトなので、今後の機能追加ですぐ利用できるようになるでしょう。
雑感
料金モデル
Kiroのコアバリューは仕様駆動開発の効率化にあると感じています。この価値は確実に存在し、実際に体験してみると大きなメリットを感じます。
しかし、料金面はプロダクトとして心配です。以下が現在公開されている料金プランです。
vibeリクエストは作業時のプロンプト実行、specリクエストは要件、設計、タスクの更新時のプロンプト実行時に消費されます。
今回ボーナスで 150 vibe、100 specリクエストをもらいましたが、GitHub ActionsのTrace IDをサマリに表示するちょっとした機能を実装しただけで、vibeリクエストを使い切ってしまうくらいでした。
現状毎月$20払って225 vibe、125 specリクエストしか使えないので、全然開発するのに足りない印象です。他のプロダクトが安すぎるという面もありますが、ユーザーとしては抵抗を感じる価格帯です。
Kiroは内部で外部ベンダーのAI APIを利用するモデルです。このモデルで利益を出そうとするとAPI利用コストに加えてマージンが必要で、結果として他の直接利用サービスより高額になり、採算を取るのがかなり難しいのだろうなと推測しています。
素晴らしいプロダクトですが、このままの料金体系で大丈夫なのかという不安を感じました。
コアソリューションを他のサービスに実現される可能性
細かな体験はKiroが間違いなく優れています。プロダクトとしては大好きです。一方で、一番のコアソリューションがフレームワークであると感じる状況では、他のサービスに模倣されてしまうと差別性があまりなくなってしまうのではないかと感じます。
例えばClaude CodeでKiro互換の要件、設計、タスクを作成するclaude-code-specも出てきています。もちろん、システムプロンプトの品質や細かな管理機能ではKiroの方がプロダクトとして強化されやすい可能性はあります。一方でコアソリューション部分が模倣しやすいことも事実に感じています。
現時点ではプロダクトとして先行きが心配というのが初心者目線の所感です。
まとめ
Kiroの最大の価値は、多くの開発者が自分では構築できない仕様駆動開発のフレームワークを提供していることだと思います。
Kiroの良いところとして、やはりそれらのドキュメントを管理するのを効率的にするという思想が垣間見えるところです。
ドキュメントを管理しつつ開発をするということに関して、体験をよく考えて機能が追加されていることがとてもわかります。
現時点では制約もありますが、仕様駆動開発のワークフローを学び、体験するという観点で、多くの開発者にとって価値のあるプロダクトだと確信しています。
特に、自分で仕様駆動開発の体系を構築できていない開発者には、ぜひ一度試してみることをお勧めします。そこで得られる学びは、Kiroを使い続けるかどうかに関わらず、今後の開発プロセス改善に大きく役立つはずです。
