仕様駆動開発とは？仕様を真実の源（Source of Truth）として

仕様を唯一の信頼できる情報源とし、付属文書としない。

目次

仕様駆動開発（Spec-Driven Development）は、ソフトウェアエンジニアが以前から模索してきたものの、その労力に見合う成果が得られなくなった際に棚上げされてきたアイデアの一つです。

2025年に状況が変わったのは、AIコーディングエージェントが登場し、明示的な意図の欠如がコストを伴うようになったことです。プロンプトは一時的なものです。エージェントのセッションはリセットされます。コードは変更されますが、その背後にある推論は消えてしまいます。仕様（スペック）は、それを防ぐための成果物です。

仕様駆動開発とは – AIコーディングにおける真実の源としての仕様

仕様が真実の源（Source of Truth）になりつつある

ソフトウェア開発の歴史の大部分において、仕様は一時的な計画資料、あるいは後付けの産物でした。要件はチケットに、設計上の決定はチャットスレッドに存在し、コードが真実の源でした。ドキュメントは、事実として存在するものを後から説明するものでした。

仕様駆動開発は、その関係を反転させます。仕様が一次の成果物になります。コードは、仕様に従って生成されるか、仕様に対して検証されるものであり、逆ではありません。

これは新しいアイデアではありません。形式手法、契約による設計（Design-by-Contract）、BDD（行動駆動開発）は、これの一種を含んでいます。新しいのは、実用的な動機です。AIコーディングエージェントは、正確で一貫した出力を生み出すために、明示的で持続的なコンテキストを必要とします。プロンプトは一時的すぎます。仕様は、エージェントセッション間、チームメンバー間、時間を超えて意図を運ぶことができる唯一の成果物です。

仕様駆動開発が実際に意味すること

仕様駆動開発（通常はSDDと略されます）は、バージョン管理された仕様が実装を主導または生成するワークフローです。仕様は、エージェントがコードを書く前に作成され、レビューされます。それは以下を捕捉します：

  • 何を構築するか – ユーザーの問題、目標、非目標
  • 正しい動作とは何か – 受け入れ基準、エッジケース、エラー状態
  • どのように構築するか – アーキテクチャの決定、データモデル、API契約、セキュリティ制約
  • どのように検証するか – テスト戦略、検証ルール、要件へのトレーサビリティ

最後の項目は、書くのは簡単ですが、実践では簡単にスキップされがちです。AI開発における仕様、テスト、コードの同期を維持する では、要件へのトレーサビリティがデータとして実際にどのようなものか（要件ID、設計決定ID、それらを实装したプルリクエストにリンクされたテスト）を扱っています。

仕様は一度きりの文書ではありません。現実が設計と異なる場合に更新されます。エージェントが実装中に仕様が誤っていたことを発見した場合、継続する前に仕様は修正されます。仕様はコードのように扱われるため、誠実さを保ち続けます。

最近の学術研究は、このフレームワークを形式化しています。研究者たちは、仕様駆動開発を、仕様を真実の源として扱い、コードをそれに対して生成または検証するものとして説明しています。実用的な解釈としては、仕様が、人間やAIツールが読み取り信頼できる、レビューされた意図の持続的な記録であるということです。

3つの用語が、仕様利用のスペクトラム上の異なる点を表します：

Spec-first（仕様最優先） は、いかなる実装が始まる前に完全な仕様を書くことを意味します。これは最も厳密な解釈であり、慎重に行わない限りウォーターフォールモデルに最も近いものです。

Spec-anchored（仕様アンカリング） は、機能のライフサイクル全体を通じて、仕様が実装と同期を保たれることを意味します。決定が変更されると、仕様も更新されます。これはほとんどのチームにとって最も実用的なバージョンです。

Spec-as-source（仕様がソース） は、AIエージェントを通じて、またはコードを仕様の制約に対してチェックするツールを通じて、仕年から実装を生成または検証することを意味します。これは、GitHub Spec KitとKiro のようなツールが進もうとしている方向です。それぞれは、ポータビリティと統合されたIDEガイダンスの間の異なるトレードオフを持っています。Superpowers のようなスキルパッケージは、spec-anchoredの側により近く位置しています – 彼らはコードを仕様から直接生成するのではなく、レビューの規律を自動的に強制します。

なぜ今SDDが重要なのか

正直な答えは、1日だけのスクリプトを構築する個人開発者にとって、SDDは魅力的ではないということです。オーバーヘッドはそれに値しません。

SDDが価値を持つのは、3つの条件が揃っているときです：機能が複数のセッションにまたがるほど十分に大きいこと、エージェントがアーキテクチャに影響を与える決定を行う必要があること、そして作業が他の誰かによってレビューされたり継続されたりすることです。

AI支援開発では、これら3つの条件はますます一般的になっています。

LLMにはプロンプトだけでなくコンテキストが必要です。 曖昧なプロンプトを受け取ったモデルは、曖昧な決定をします。明示的な制約、非目標、受け入れ基準を持つレビューされた仕様を受け取ったモデルは、より良い決定を行い、逸脱したときに軌道修正しやすくなります。これは、知識管理における検索と表現 がどのように機能するかに関連しています：エージェントにバージョン管理された仕様を与えることは、プロジェクトの意図の構造化された検索の一種です。

コード生成は安価ですが、何を構築するかを決めるのは依然として難しい。 AI支援開発のボトルネックはもはやタイピングではありません – 何を構築し、エージェントをどのように制約するかを知ることです。SDDは、労力を重要である場所に移します：生成が始まる前に意図を明確に仕様化するということです。

プロンプトは一時的です。 エージェントは、前回のセッションで何をしたか覚えていません。リポジトリに保存されたバージョン管理された仕様は覚えています。各新しいセッションは、同じ仕様を読み取り、同じ意図に対して実装を行うことができ、コンテキストを最初から再構築する必要はありません。

**Vibe coding は使い捨ての作業には速いが、SDD vs Vibe Coding は、いつ仕様を追加し、いつ自由にプロンプトを続けるべきかを扱っています。

コア成果物

SDDは4種類の成果物を生成します。各々は、エージェントがコードに触れる前に、異なる種類の曖昧さを減らします：

  • 要件仕様 – 問題、ユーザー、目標、非目標、受け入れ基準
  • 設計仕様 – この機能のためのアーキテクチャ、データモデル、API契約、セキュリティ制約
  • タスク計画 – 依存関係と検証基準を持つ小さな実装スライス
  • トレーサビリティ記録 – 受け入れ基準からテストへ、設計決定からファイルへ、タスクからコミットへのマッピング

それらを段階的に作成し、レビューする方法（仕様化、計画、タスク、実装、検証）は、要件からコードへ：仕様駆動開発ワークフロー で扱われています。単純な機能であれば、短いMarkdownファイルで4つの領域すべてをカバーできます。習慣の方がフォーマットよりも重要です。

SDDはドキュメントとどう異なるか

最も一般的な誤解は、SDDの成果物をドキュメントとして扱うことです。それらは、従来の意味でのドキュメントではありません。

ドキュメントは記述します。 システムが何をし、どのように使用し、何を含んでいるかを伝えます。それは事後に書かれ、システムが変更されたときに更新されます。

仕様は制約します。 仕様は、エージェントが構築してよいもの、そしてしてはならないものを伝えます。それは実装が始まる前に権威を持ちます。実装が完了した後に検証されます。実際に構築されたものを記述する（構築されるべきものを制約するのではなく）仕様は、すでにその目的を失敗しています。

実行可能な仕様は生成と検証を導きます。 最高のSDD仕様は、エージェントがそれに対して実装し、テストスイートがそれらを検証できるほど、機械可読性に近いです。「エンドポイントは認証されていないリクエストを401レスポンスで拒否しなければならない」という受け入れ基準として書かれたものは実行可能な仕様であり、「エンドポイントは安全である」というのはドキュメントです。

決定記録 – ADR、PDR、DDR – はSDDの成果物と補完的ですが、異なる目的をサービスします。決定記録は、なぜその選択が行われ、何が拒否されたかを捕捉します。SDD仕様は、何を構築し、どのように検証するかを捕捉します。両方ともリポジトリに属します。一緒に、AIエージェントに完全な図面を与えます：現在の意図と、その背後にある推論です。

SDDはTDDとどう異なるか

テスト駆動開発（TDD）と仕様駆動開発（SDD）は、両方がコードが存在する前に明示的な成果物を生成するため、しばしば混同されます。違いは、出発点です。

TDDはテストから始まります。 望ましい動作を記述する失敗するテストを書き、それをパスするために必要な最小限のコードを書きます。TDDはユニットレベルのフィードバックループです。良いテストを生成しますが、正しいものを作っているかどうかという質問には答えません。

SDDは意図から始まります。 テストが存在する前に、アーキテクチャが決定される前に、仕様は誰がこの問題を持っており、正しい動作とはどのようなもので、何が明示的にスコープ外かを答えます。仕様は、次にどのようなテストを書くかを情報提供するため、良いSDDと良いTDDは競合ではなく補完的です。

実用的な思考法は：SDDがTDDを駆動します。仕様の受け入れ基準がテストシナリオになります。設計仕様は、契約テストが必要な統合境界を特定します。タスク計画は、エージェントがそれらを実装する前にテストカバレッジが必要な単位の動作を特定します。

SDDはBDDとどう異なるか

行動駆動開発（BDD）は、自然言語のシナリオ（通常はGherkin形式）を使用して、ユーザーの視点からの期待される動作を記述します。これらのシナリオは、ビジネス意図と技術実装の間のギャップを埋めます。

SDDはより広範です。動作の記述（BDDスタイルの言語や平文を使用できます）を含みますが、アーキテクチャの決定、データモデル、セキュリティ制約、タスク計画、トレーサビリティもカバーします。BDDは、SDD要件仕様の内で受け入れ基準を書くための有用なフォーマットになることができます。仕様はコンテナであり、BDDシナリオは、その中に何を書くか的一种方式です。

この区別は実践において重要です：BDDツールは、シナリオを実行可能にすることに焦点を当てています。SDDの実践は、意図を永続的にすることに焦点を当てています – ツールを超えて、セッションを超えて、チームメンバーを超えて。

SDDは形式手法とどう異なるか

形式手法は、数学記号と自動検証を使用して、ソフトウェアシステムの特性を証明します。それらは非常に厳密であり、ほとんどの本番開発コンテキストにおいて非常にコストがかかりません。

SDDは形式記号を必要としません。受け入れ基準とアーキテクチャの決定を持つMarkdownファイルは仕様です。それは数学的に形式的ではなく、制約を課します。厳密さのレベルは、懸念に応じてスケーリングされます：請求サービスの仕様は、ドキュメントページの仕様よりも、より正確で、より慎重にレビューされるべきです。

関係はスペクトラムです：

  • 非公式な散文仕様（最小限の実践可能なSDD）
  • 受け入れ基準と非目標を持つ構造化Markdown
  • スキーマ検証を持つ機械可読仕様
  • 仕様から直接導出された契約テスト
  • 自動証明を持つ形式的仕様

ほとんどのチームは、そのスペクトラムの中間で動作しています。目標は数学的な厳密さではなく – AIエージェントがそれに対して実装し、人間のレビュアーが結果を検証できるほど、意図を明示的にすることです。

仕様駆動開発の利点

意図のドリフトの減少。 仕様は参照です。エージェントがドリフトしたとき – それは起こります – レビュアーは実装と比較するためのものがあります。仕様なしでは、ドリフトは何か壊れるまで見えません。

より良いAI出力。 明示的な制約、非目標、受け入れ基準を与えられたエージェントは、意図したものにより近い実装を生成し、外れたときに修正しやすくなります。コンテキストの品質は直接、出力の品質を決定します。

レビューの容易さ。 仕様に関連付けられたプルリクエストは、レビュアーがコードから意図を再構築することを要求するプルリクエストよりもレビューしやすいです。仕様はレビューチェックリストです。

チームの整合性。 複数の人間やエージェントが同じ機能に作業している場合、仕様は共有契約です。それなしでは、各貢献者がローカルに最適化し、パーツが合わなくなる可能性があります。

より良いテスト計画。 仕様の受け入れ基準は、テストケースに直接マッピングされます。テストカバレッジは、仕様カバレッジの問題になります：各受け入れ基準は少なくとも1つのテストでカバーされていますか？

持続的な引き継ぎ。 機能が変わるとき – エンジニア間、エージェントセッション間、スプリント間 – 仕様は引き継ぎ成果物です。それは、何が決定され、何がスコープ外であり、何が検証待ちかを捕捉します。

仕様駆動開発のコスト

事前の労力。 いかなるコードを書く前に良い仕様を書くのは時間がかかります。小さな機能の場合、このオーバーヘッドは現実的であり、時にはそれに見合いません。

誤った自信。 実装に対して検証されないで存在する仕様は、誤った正確性の感覚を与えます。古い仕様は、ない仕様よりも悪いことがありますが：それらは、それらを読むレビュアーやエージェントを誤導します。

古い仕様。 チームが仕様を計画資料としてではなく、生きた文書として扱わない場合、仕様はドリフトします。実装が設計と異なる場合に仕様を更新することは任意ではありません – それは、蓄積し腐敗するドキュメントからSDDを区別するものです。

生成された官僚主義。 AIエージェントは、包括的なタスクリストと冗長な仕様を素早く生成できます。30秒で生成された200タスクの仕様は、有用な仕様ではなく – それは官僚主義ジェネレーターです。良いSDDは、何を仕様化し、何を暗黙の内に残すかについての判断を必要とします。

ツールロックイン。 一部のSDDツールは、フォーマット、ファイル構造、ワークフローに対して意見が強いです。プロプライエタリ形式で書かれた仕様は、明確なヘッダーと受け入れ基準を持つMarkdownファイルよりも、ツール間で持ち運ぶのが困難です。

結論

仕様駆動開発は新しい方法論ではありません。それは、暗黙の意図のコストがAI生成コードの中で目に見えるようになったため、再び実用的になる古い規律です。

その規律はシンプルです：エージェントがそれを構築する前に、レビューされバージョン管理された、何を構築するつもりかを記録してください。現実が異なる場合にそれを更新することで、その記録を誠実なものに保ちます。レビュー、テスト、引き継ぎのための参照としてそれを使用してください。

仕様は魔法ではありません。検証されない仕様は、最も高価な種類のドキュメントになります：自信を持って誤導するものです。良いSDDは、仕様を誠実なものに保つ実践です – 維持できるほど小さく、制約できるほど正確で、単一のエージェントセッションよりも長く持続できるほど永続的。

SDDは、ドキュメントの実践、テストアーキテクチャ、コード設計の交差点に位置しています – すべては、本番環境におけるアプリアーキテクチャ クラスタで、決定記録、API設計、データアクセスパターンとともに扱われています。

有用なリンク

購読する

システム、インフラ、AIエンジニアリングの新記事をお届けします。