仕様駆動開発とは：AIに実装を任せる前の準備
最終更新: 2026-07-23・読了目安 約4分
仕様駆動開発とは、AIに実装させる前に「何を作るか」を文書として整理してから着手する進め方です。結論として、要件定義書・仕様書・受け入れ基準の3つを役割分担して書くと、AIへの指示のブレが大きく減ります。
なぜ仕様を先に書くのか
AIコーディングエージェントは指示された内容を素早く実装しますが、指示があいまいだと「作ってほしかったもの」と「実際に作られたもの」がずれやすくなります。実装に着手する前に仕様を言語化しておくことで、AIへの指示が具体的になり、手戻りを減らせます。近年はGitHubも「Spec-Driven Development」というオープンソースの取り組みを公開しており、GitHub公式ブログの解説記事（外部サイト、新しいタブで開きます）でも同様の考え方が紹介されています。
3つの文書の役割分担
仕様を整理する際は、次の3つの文書に役割を分けると書きやすくなります。
- 要件定義書：目的・想定ユーザー・スコープ（やること／やらないこと）を整理します。書き方は要件定義書の書き方で解説しています。
- 仕様書（DESIGN.md）：画面構成・データ構造・振る舞いなど、具体的にどう動くかを記述します。実例はDESIGN.mdテンプレート実例で紹介しています。
- 受け入れ基準：「何をもって完了とするか」という完了条件を、確認可能な形で書き出します。
進め方の流れ
基本の流れは、要件定義 → 仕様書作成 → 受け入れ基準の設定 → AIへの実装依頼 → 受け入れ基準に沿った検証、という順番です。GitHubが公開しているspec-kit（外部サイト、新しいタブで開きます）のように、この流れをツール化する動きも出てきています。実装後の検証はAIとテスト駆動開発とあわせて進めると、より安全に完了条件を確認できます。
やりすぎ注意点
仕様は詳しいほど良いとは限りません。最初から全項目を完璧に書こうとすると、仕様書を書くこと自体が目的化してしまいます。個人開発や小規模なタスクでは、目的・概要・完了条件の3点を先に固め、実装を進めながら足りない部分を追記していく進め方が現実的です。
よくある質問
仕様駆動開発は個人開発でも必要ですか？
大規模なチーム開発でなくても有効です。特にAIに実装を任せる場合、口頭的な指示だけでは意図がずれやすいため、簡単な仕様書があるだけで手戻りを大きく減らせます。
仕様書はどのくらい詳しく書けばいいですか？
最初から完璧を目指す必要はありません。目的・画面や機能の概要・完了条件が伝われば十分で、実装を進めながら足りない部分を追記していく進め方でも問題ありません。
要件定義書と仕様書はどう違いますか？
要件定義書は「何を・なぜ作るか」という目的とスコープを扱い、仕様書は「具体的にどう動くか」という画面やデータ、振る舞いを扱います。役割を分けて書くと、AIへの指示も整理しやすくなります。