皆さんこんにちは、EC 本部の手嶋です。現在ラスベガスで開催されている re:Invent に参加しています。
充電器のブログ、ごはんのブログと書いてきましたが、そろそろ技術についてのブログを書きたいと思います。
さて、昨今の AI コーディングツールの進化はめざましく、気づけば開発プロセス全体を Agent が行えるようになってきました。
みなさんも Copilot や Cline、RooCode などは使っていますか？ 便利ですよね。小さい関数などを作成させるのには重宝しますが、規模が大きくなると推測で勝手に埋められてしまう箇所が多くなり、「車を依頼したのに、翼の生えた自転車が出てくる」ような場合があります。
そこで注目されているのが 「スペック駆動開発（Spec-Driven Development）」 です。 これは AI を単なるコード生成マシンから「パートナー」へと昇華させる試みであり、AI との対話の仕方を根本から変え、腰を据えて計画を立てるアプローチです。
恥ずかしながらあまり情報をキャッチアップできていなかったので、re:Invent で開催されていたセッション 「From concept to production: Build with spec-driven development and Kiro」 に参加してきました。
セッションで聞いた話と私の意見を混ぜつつお届けできればと思います。
AI 開発の現状と「スケールの壁」
AI コーディングは、単なる補完から Agent 開発へと進化してきました。
開発者が夢見ていた理想は以下のようなものです。
- 自律性
- 協調性
- 高品質なコード
開発者がバカンスしている間に AI が勝手にコードを書き、テストしてデプロイまでやってくれる。あるいは、シニアエンジニアとペアプロをするようにスムーズに開発が進められる。そんな未来を期待していました。
現在の AI 利用方法でも、一人のエンジニアが個人開発をする分には大きな問題はありません。 しかし、歪みが発生するのは 「チームでの開発」 を行うときです。
セッションでは「AI は非決定論的である」と言及されていました。つまり、出力の際にわずかな揺らぎが必ず発生するということです。 このわずかな揺らぎが、数百人で数万行もあるようなコードベースを利用する際に大きな問題になります。
例えば、チームメンバーがそれぞれ AI に生成させたコードには、微細ながらも無数の「勝手な判断」が混入します。コーディングスタイルや構造がずれていたりして、いざ結合しようとした時に正常に動かない、ということが頻繁に発生します。 このように、チーム全体で一貫性を持たせることが非常に難しくなる現象を 「スケールの壁」 と呼ぶそうです。
AI の「レビュー」にかかるコスト
また、AI の助けを借りたつもりが、AI の生成したコードを読み解くのに時間を要してしまうのも問題です。
生成されたコードには無数の「勝手な判断」が含まれるため、それらが本当に正しかったか、コンテキストに合っているかを人間が検証する必要が出てきます。 これでは相互に協力できている関係とは言えず、人間は「AI が生成したコードのレビュー者」に成り下がってしまいます。
「5 分で書いたプロンプトで生成させたコードの検証に 2 時間かかる」といった話は、昨今の開発現場における"あるある"になってきているのではないでしょうか。（私の個人開発ではそうです…）
「こいつ、AI で生成しただけのコードを投げてるだろ！」という怒りを覚えた経験は、コードレビューを担当されるエンジニアの方々であれば一度はあるのではないでしょうか。
これらのコントロールの問題が、最終的なプロダクトの品質低下にもつながります。また、 たとえコードを作るのが早くなったとしても、その後のメンテナンス工数の増大で相殺されてしまいます。
スペック駆動開発（Kiro）のアプローチ
これらの問題を解決するのが、 Kiro の採用する「スペック駆動開発」 です。
「仕様」と言われると、レガシーなウォーターフォール開発を想像してしまいますが、これは「作る前に何を作るのかをしっかり決める」という基本的で堅実なアプローチへの回帰です。曖昧な指示で完璧な結果を期待するのではなく、構造化されたプロセスを重視し、まずはドキュメントを作るのです。
これがスペック駆動開発、ひいては Kiro というプロダクトのオリジンなのだと思います。
生成される 3 つのドキュメント
具体的に、まず以下のドキュメントを作成します。
- 要求仕様書 (Requirements Spec)
- ユーザーの視点からどういった機能が必要で、それらがどう振る舞うべきかを定義
- 「何を作るか」を決定する
- 設計書 (Design Spec)
- 技術的な視点から要求仕様書をどう実現するかを定義
- エラーハンドリング、言語、アーキテクチャなど「どう作るか」を決定する
- タスクリスト (Task List)
- 要求仕様と設計書を基に、現実的な作業フェーズに分割したもの
- 「まずは DB を作成し、次に API エンドポイントを作り……」といった作業の流れを作成する
AI がコードを書き始める前にこれらのドキュメントを生成し、人間がレビュー・編集を行います。
実践的なワークフロー
セッションのライブデモでは、「フィットネス活動を追跡し、消費カロリーを計算する WEB アプリ」というごく短いプロンプトからスタートしていました。
この一文から、Kiro は要求仕様書のドラフトを生成します。 ここで人間が仕様書を修正し、「位置情報を追跡する機能」を追加したりしていました。出力された大量のコードを読み解く必要はなく、事前に機能の追加を自然言語で行えるのが大きなメリットです。
次に、人間が手を加えた要求仕様書を基に、設計書を生成させます。
当初、Kiro は React と TypeScript での実装を提案していました。 ここで、先に挙げた「コントロールの問題」への解決策が出てきます。もしあなたのチームが Vue.js に精通したチームだった場合、どうするべきでしょうか。
今までの AI 開発であれば、AI が勝手に 1000 行のコードを書き始めてから、再度「Vue で書き直して」とプロンプトを修正し、実行し直す必要がありました。 しかしスペック駆動開発であれば、この段階で設計書のテキストファイルを開いて、React / TypeScript と書かれている部分を Vue.js と書き換えるだけで済みます。
こうすることで、AI が Vue を前提にすべての設計を再構築します。このプロセスを踏むことで、人間がアーキテクトとしての主導権を完全に握ることが可能になります。
最後に生成されるのがタスクリストです。 印象的だったのが、MVP 作成のためのタスクと、本番向けのタスクを分けて定義してくれる点です。MVP に必要なタスク以外はグレーアウトされ、オプションとして選択できるようになっています。 「まずは動くものを作る」ことに集中できるよう、PM としてのタスク整理の役割も果たしているわけです。
これらのドキュメントを人間がレビュー・承認して初めて、Kiro はコードを書き始めます。
既存プロジェクトへの対応：ステアリングドキュメント
上記は新規プロジェクトの話ですが、既存の「秘伝のタレ」がふんだんに使われているような巨大コードベース（100 万行規模）に機能を追加する場合はどうでしょうか？ これこそがツールの真価が問われる部分です。
ここで役立つのが、Kiro の 「ステアリングドキュメント（Steering Document）」 機能です。
Kiro に既存のコードベースを読み込ませると、それらをリバースエンジニアリングのように分析し、現在のアーキテクチャ、使われている技術スタック、コーディング規約などを要約したドキュメントを生成してくれます。
さらに、変更を加えた際の影響範囲（ブラスト・ラディウス）まで算出してくれます。「ここの機能をいじると、あそことそこに影響が出ると思うよ」と事前に警告してくれるのです。これ、すごくないですか？
100 万行クラスのコードを人間がすべて把握することは不可能ですが、AI なら可能です。 AI によって変更作業の基となるコンテキストが生成され、安全な変更を加えられるようになります。
ツール間の連携と MCP
開発者は Kiro だけを使っているわけではありません。PM は Jira でチケットを書き、デザイナーは Figma を使っている。こういったバラバラのツールによって情報が分断され、「Jira の情報が古かった」なんてことが頻繁に起こります。
そういった問題を解決するために、MCP (Model Context Protocol) サーバーと Agent フックを利用し、外部サービスとの連携が可能です。
例えば、要求仕様が変更になった際に、変更内容を自動で Jira チケットにも投稿するといったことができます。 Kiro がハブとなることで、ツール間の情報のサイロ化を防ぎ、情報の連携コストを大幅に削減することが見込めそうです。
出力の揺らぎについて
スペック駆動開発を採用しても、AI による「揺らぎ」は発生します。セッション内でも「出力は 100％確実ではない」と強調されていました。
ここの考え方として重要なのは、スペック駆動開発の目標は「毎回同じコードを生成すること」ではないという点です。
二人の優秀な開発者に同じ課題を与えても、全く同じコードが書かれるわけではありません。「毎回同じコード」は現実的ではないし、必ずしも必要ではないのです。
目標は 「仕様を満たす成果物を一貫して作ること」 です。 実装のアプローチが多少異なっていても、要求される仕様を成果物が満たしているのであれば、それは正しい成果物と言えます。
これによって、人間側が AI コードをレビューする際のスタンスにも変化が必要です。 「AI が勝手な推測で書いたコードを直す後片付け」ではなく、「生成されたロジックやアーキテクチャが、我々が承認した仕様通りになっているかを検証する」作業へと変化します。
思考の転換：エンジニアの新しい役割
私自身、AI 開発を行う 1 エンジニアとして今回のセッションを聞き、これまでの開発スタイルからの大きな思考の転換が必要になると強く感じました。
今までの AI 開発では、いかに AI に望み通りの結果を生成させるかという点で、職人技的なプロンプトエンジニアリングに焦点が当たっていました。 しかしスペック駆動開発では、 「AI とともにいかに優れた計画を定義するか」 が開発者の主な仕事になってきます。
人間がより上流の設計者、システムアーキテクトとしての役割を担い、AI が正確に定義された仕様を実装する。そして人間は、コードの一字一句ではなく、仕様との整合性をレビューする。 そういった明確で健全な役割分担になっていきそうです。
今後、開発者の仕事は「書く（Writing）」から「設計し、レビューする（Architecting & Reviewing）」へシフトしていくのかもしれません。
まとめ
スペック駆動開発というアプローチが、AI 開発の現場にいかにして構造、コントロール、そしてスケーラビリティを持ち込もうとしているのか、非常によく理解できるセッションでした。
これからは「とりあえず AI に作らせてみよう」といったギャンブルから、「AI と共同で計画を策定し、常に人間が主導権を握る」プロセスへの移行が進むでしょう。AI をただコードを吐き出すツールから、思考の整理と計画策定のためのパートナーへと昇華させる試み。
今後のスペック駆動開発と Kiro の動向に期待大です。
充電器とごはんのブログはこちら
