AWS エリック・ハンチェット氏、生産ワークフローに仕様駆動開発を適用

AWS エリック・ハンチェット氏が提唱する「仕様駆動開発」：LLM を使いこなすための新・標準ワークフロー

大規模言語モデル（LLM）を単なるコード補完ツールとして扱う限り、その真価は発揮されません。AWS のシニア開発者アドボケートであるエリック・ハンチェット氏は、複雑なプロジェクトにおいて LLM を効果的に活用するための鍵として「仕様駆動開発」の導入を提唱しています。

これは、コードを書く前に Markdown 形式で詳細な仕様書や設計ドキュメントを作成し、AI に厳密なガイドラインを与える手法です。ハンチェット氏はこれを「指示待ちの AI インターン」への教育と捉え、人間の監督下で文脈（コンテキスト）を制御することで、予測可能性の高い高品質なコード生成を実現できると説きます。

LLM は「AI インターン」だ：逸走を防ぐための厳密なガイドライン

ハンチェット氏が最も強調するのが、LLM を「指示待ちの新人インターン」として捉える視点です。彼によれば、大規模言語モデルは優秀ですが、曖昧な指示を与えるとすぐに思考が逸走してしまいます。

「もし彼らに少しの融通を利かせると、彼らは軌道から外れます」

ハンチェット氏は自身のキャリア初期のエピソードを思い出します。役員からの思いつきでランダムなアイデアを即座に実行しようとした結果、後で上司から「なぜ全てを捨てたのか」と問われた経験です。あの時彼は学びました。与えられた情報は書き留め、スケジュールに組み込み、管理者と相談する必要があると。

これは現在の LLM にも当てはまります。彼らに与える情報が曖昧であれば、彼らは勝手に解釈して作業を進めてしまいます。仕様駆動開発では、コード作成前に構造化された仕様書を作成することで、「何をするべきか」を明確に定義し、AI の思考を正しい方向へ誘導します。

最新モデルでも「文脈」は必要：なぜ計画が必要なのか

「最新の最先端モデルなら、すでにすべてをしてくれるのではないか？」という疑問に対し、ハンチェット氏は「文脈（コンテキスト）の制御」が不可欠だと答えます。モデルは年々進化していますが、まだ完璧ではありません。

特にソフトウェア開発では要件やパラダイムが常に変化します。AI に「どこへ行くべきか」を明確に示すドキュメントを作成し、その中で思考や計画モードを持たせることが重要です。いくつかのツールはこの点を意識し始めていますが、人間が主導してドキュメントを作成し、それを AI に読み込ませるプロセスこそが最強の組み合わせとなります。

ここで重要なのが情報の「黄金律ゾーン（ゴールデン・ロックス・ゾーン）」です。情報が多すぎても少なすぎてもいけません。必要なルールとガイドラインを適度に与えれば、AI は何をすべきかを理解します。AWS ではこれを「ステアリング・ドキュメント」と呼び、agents.md などのファイルに適切な情報を記載して AI に読み込ませます。

AWS「Kiro」が実装する Spec モードと EARS 形式のワークフロー

この考え方を具体化したのが、AWS が提供する新しい AI コーディングアシスタント「Kiro」です。IDE 版と CLI 版があり、特に「Spec モード（仕様モード）」に注力しています。

1. EARS 形式での要件定義

Kiro の Spec モードでは、要件定義をEARS（Extended Abstract Requirements Specification）という形式で自動生成します。これにより、単なる箇条書きではなく、以下の要素が構造化されたドキュメントとして出力されます。

• 導入部分: プロジェクトの概要
• 要件: 具体的な機能要件
• ユーザーストーリー: ユーザー視点での利用シーナリオ

また、プロンプト入力直後に AI が明確化質問（Q&A）を行い、要件をすり合わせるプロセスも用意されています。これにより、曖昧なまま開発が開始されるリスクを排除します。

2. 設計ドキュメントと Mermaid ダイアグラム

要件定義の後、AI は高レベルの設計ドキュメントを作成します。ここではMermaid ダイアグラムや ASCII アートを用いて、アーキテクチャやシーケンス図を視覚的に提示します。

「自宅で試している場合は、一旦停止して、あなたの知識や専門性を反映させて更新することをお勧めします」

AI が生成した設計図はあくまで出発点です。開発者が自分の知識で修正・補完し、最終的な設計を確定させることが重要です。

3. プロパティテストの自動生成と MVP の優先

最も画期的なのが、プロパティベーステスト（Property-based Testing）の自動生成機能です。Kiro は要件ドキュメントや設計ドキュメントに反するケースをシミュレーションし、数十回から数百回の異なる値で実行されるテストコードを自動生成します。

「タスクリストを作成したら、『上位 4 つのタスクを最上部に配置し、まず MVP を作成してください』と指示します」

これにより、開発者はすぐに動作確認可能な最小機能（MVP）を立ち上げ、要件が正しく満たされているかを検証できます。例えば「映画サイト作成」の事例では、検索・フィルタリング・ソート機能を備えた MVP が数ステップで生成され、その後プロパティテストによって堅牢性が保証されました。

人間のループと責任：AI はあくまでパートナー

ハンチェット氏は最後に、「人間がループ内にあること」の重要性を強調します。ツールを使わないという意味ではなく、最終的なコードレビューや設計文書の確認は必ず人間が行うべきだという原則です。

「生成されたすべてのコードのコードレビューをあなたが行う必要があります。最終的に何か問題が起きた場合、責任を問われるのはエージェントではなく、あなた自身だからです」

AI は強力なパートナーですが、開発者がその出力に対して責任を持ち、必要な修正を加える姿勢が不可欠です。また、MCP（Model Context Protocol）を活用することで、Jira や Asana などのプロジェクト管理ツールから要件情報を自動的に取り込み、仕様の作成をさらに効率化することも可能です。

まとめ：生成 AI を「設計・実装パートナー」へ進化させる標準プラクティス

仕様駆動開発は、生成 AI を単なる補完ツールから、複雑なプロジェクトの設計と実装を担う信頼できるパートナーへと進化させるための重要なステップです。AWS の Kiro などのツールが提供する Spec モードを活用し、人間が主導して文脈を制御することで、セキュリティや予測可能性を保ちつつ開発速度を劇的に向上させることが可能になります。

このアプローチは、エンタープライズ環境において AI の活用標準として広まる可能性を秘めています。AI に任せるのではなく、「AI へどう指示し、どう監督するか」という人間の役割が、これからの開発者には求められているのです。