Spec-Driven Development:From Code to Contract in the Age of AI Coding Assistants
本論文は、仕様を主要なアーティファクトとして扱うことが、多様なソフトウェアドメインにおいてAIコーディングアシスタントをいかに効果的に活用できるかを実証するために、その原則、3つのレベルの仕様の厳密性、および支援ツールを概説する、スペック駆動開発（SDD）への包括的なガイドを提示するものである。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
あなたは、非常に有能で、驚くほど速いが、少し融通の利かない「直訳的な」ロボットシェフに、複雑な料理を作らせることを想像してください。
旧来の方法（コード・ファースト）:
あなたはロボットに近づき、「美味しい夕食を作って」と言います。
意欲的なロボットは、すぐに野菜を刻み始め、フライパンを熱し始めます。彼は、あなたがパスタを望んでいるのだと推測します。パスタは辛いものだと推測します。あなたが言及もしなかった高価なトリュフオイルを使うことさえ、彼は推測します。
10分後、あなたの前にはスパイシーなトリュフパスタが置かれています。あなたが欲しかったのはサラダでした。
これで、あなたはロボットに止まるよう命じ、パスタを捨てさせ、最初からやり直させなければなりません。これが、論文が「バイブ・コーディング（Vibe Coding）」と呼ぶものです。曖昧なプロンプトに頼り、AIにあなたの意図を推測させる手法です。その結果は、絶えず修正を必要とする混乱した状態であることがよくあります。
新しい方法（スペック駆動開発）:
命令を叫ぶ代わりに、まず最初に「レシピカード（仕様書）」を書きます。
あなたは次のように正確に書き込みます。「サラダが欲しい。ほうれん草、トマト、フェタチーズを使用すること。ナッツ類は入れないこと。ドレッシングは横に添えること。室温で提供すること。」
あなたはこれをロボットに渡します。ロボットはそれを読み、理解度を確認し、それから調理を開始します。
もしロボットがナッツを加えようとしたら、「ナッツ禁止」という記述があるため、彼は停止します。もし彼が熱い状態で出そうとしたら、彼は停止します。
このシナリオでは、レシピカードがボスです。料理（コード）は、単にレシピに従った結果に過ぎません。もし料理の味が間違っていたら、シェフを責めるのではなく、レシピが明確であったかどうかを確認します。
3つの厳格さのレベル
この論文では、常に50ページの契約書が必要なわけではないと説明しています。この「レシピカード」のアプローチには、どれほど真剣に取り組むかに応じて、3つの方法があります。
スペック・ファースト（「スケッチ」）:
- 内容: 全員が何を作るのかについて合意するために、調理を始める前にレシピを書きます。
- 使い時: 新しいアイデアを試している時や、使い捨てのプロジェクトに適しています。
- 注意点: 食事が完成したら、レシピカードを捨ててしまうかもしれません。後でレシピを変更した場合、カードが更新されない可能性があります。これは開始段階には適していますが、長期的なメンテナンスには向きません。
スペック・アンカー（「生きたメニュー」）:
- 内容: レシピカードは、コンロの横にある冷蔵庫に保管されています。料理を変更するたびに（チーズを増やしたり、ドレッシングを変えたりする場合）、必ず直ちにカードを更新しなければなりません。
- 使い時: ほとんどのプロフェッショナルな厨房（プロダクション・ソフトウェア）にとってのスイートスポットです。
- 魔法: 厨房にはロボットの検査官がいます。もしシェフが料理を変更したのに、カードの更新を忘れた場合、検査官はアラームを鳴らします。これにより、メニュー（ドキュメント）が常に料理（ソフトウェア）と一致することを保証します。
スペック・アズ・ソース（「3Dプリンター」）:
- 内容: これは最も極端なバージョンです。あなたは決して直接食べ物に触れません。レシピカードだけを編集します。すると、機械がそのカードのみに基づいて、自動的に料理をプリントアウトします。
- 使い時: 自動車のエンジンや医療機器の製造など、ミスが危険を招く可能性のある、極めて高い精度が求められる分野で使用されます。
- ルール: 車のブレーキを変更したい場合、レンチを持ってボンネットの下に手を突っ込むことはしません。設計図を変更し、機械が完璧にブレーキを再構築します。あなたは、生成された部品を手動で編集することは決して許されません。
なぜAIがこれらを必要とするのか
論文は、AIコーディング・アシスタントは、その有能だが直訳的なロボットシェフのようなものであると主張しています。彼らは指示に従うことには長けていますが、「心の読み取り」は苦手です。
- スペックがない場合: あなたがAIに「ログイン機能を追加して」と頼みます。AIはパスワードのルール、データベースの型、そしてセキュリティレベルを推測します。そして、しばしば間違えます。
- スペックがある場合: あなたは明確な契約を与えます。「ログインには12文字のパスワードが必要。メールアドレスを使用。3回の失敗でアカウントをロックする。」AIはルールを完璧に遵守します。
ワークフロー：4ステップのダンス
論文は、このプロセスにおけるシンプルなリズムを提案しています。
- 指定（Specify）: 「何（What）」を書く。（レシピ）
- 計画（Plan）: 「どのように（How）」を書く。（買い物リストとキッチンのレイアウト）
- 実装（Implement）: 構築する。（調理）
- 検証（Validate）: チェックする。（味見）もし味がレシピと一致しない場合は、調理を修正するか、あるいはレシピを更新します。決して、不一致を無視してはいけません。
使い時（および使わない時）
論文は簡単な判断ガイドを提供しています。
- 使うべき時: 大きなものを作っている時、チームで作業している時、AIを使用している時、あるいはミスがコストに直結する分野（銀行業務や自動車など）を作っている時。
- 使わないべき時: 使い捨てのプロトタイプを作っている時、あるいは要件が明白な単純なToDoリストアプリを個人で開発している時。そのような場合、詳細なレシピを書くことは時間の無駄です。
重要な教訓
数十年の間、ソフトウェア開発者はコードを先に書き、その後で「レシピ」（ドキュメント）を書くか、あるいは全く書かないことが一般的でした。この論文はこう言っています：その構図を逆転させなさい。
**仕様（Specification）**を、最初に作成すべき主要なものとしなさい。コードは、その仕様から自動的に出力される結果に過ぎないと捉えなさい。
こうすることで、推測することをやめ、AIツールとの戦いを終わらせ、構築したものがまさに意図した通りのものであることを確実にできるのです。コードは仕様の影となるべきであり、その逆であってはなりません。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。