仕様駆動開発とは

Microsoft社のGitHub Copilot、Anthropic社のClaude Code、あるいはIBMのBobのような、AIツールやコーディング・アシスタントが利用しやすくなったことで、コード生成への参入障壁が低くなりました。高度なAIモデルを使用する、LLMを活用したAIエージェントは、ユーザーからの単一の自然言語プロンプトだけで、いつでもリアルタイムに一連の反復的なタスクを実行できます。

ソフトウェア開発において、これは、プロトタイプ、新機能、単体テストなどの構築に向けた開発ワークフローを最適化し、自動化できることを意味します。コードを生成することがこれまでになく容易になりました。しかし、バイブ・コーダーが注意すべき落とし穴があります。それは、AIは受け取る指示の質に見合った成果しか出せないということです。

おそらく気付かないうちに、現実世界で技術負債を目にしたことがあるでしょう。技術負債はバイブ・コーディングよりも前から存在しており、何十年もの間ソフトウェア開発の一部となっています。これは、スピードの名の下に近道が選ばれるときに蓄積されます。しかし、バイブ・コーディングは、完全に理解したり検証したりすることなく大量のコードを容易に生成できるようにすることで、技術負債を加速させます。おそらく迅速にリリースしなければならないプレッシャーがあるか、あるいはバイブ・コーダーに、技術負債が始まる前にそれを阻止するための技術的な背景が単に不足しているのでしょう。

AI支援開発における技術負債には、いくつかの形態があります：

• コンテキストの変動は、ある領域でのバグ修正プログラムが別の領域の機能を意図せず損なうときに発生するもので、より広範なシステムを完全に理解せずに生成されたコードに見られる現象です。
• 断片化もよく見られる兆候であり、新しく生成された機能が既存のアーキテクチャーの慣習に準拠せず、コードベースの一貫性と保守性を徐々に損なっていきます。
• 考慮すべき運用コストもあります。生成プロセスを方向付ける明確な仕様がないと、開発者は長期にわたるプロンプトのサイクルに陥る可能性があります。このアプローチでは、適切に定義された仕様があれば完全に防げたはずのエラーを解決するために、何千ものトークンを消費する可能性があります。

業界の多くの開発者がよく知っているシナリオを想像してみてください。数日または数週間にわたり新機能に取り組んでおり、リリースの準備がほぼ整っているとします。その後、迫りくる締め切りのプレッシャーの下で、AIプロンプトによる一連の変更を通じて、最後の微調整を急いで行います。

生成されたコードの機能は、Pythonで書かれているか別の言語であるかにかかわらず、ユーザーの視点からは問題がないように見えるかもしれません。しかしその過程で、いくつかの脆弱性が露呈し、依存関係の競合が持ち込まれ、エッジケースの処理やテストが完全に忘れ去られています。

事前に確立された正式な仕様は、誰がコードを書いているかにかかわらず、ソフトウェア開発ライフサイクル（SDLC）のあらゆる段階を管理するための、チームで共有された「真実の情報源」となります。

仕様駆動開発にはいくつかの手法やテンプレートがあり、仕様の保守レベルやトレードオフがそれぞれ異なります。厳密にどちらが「より優れている」という進展ではなく、適切な選択はお客様のコードベース、チーム、そして問題領域によって決まります。いずれかを選択する前に、チームのニーズと制約を考慮してください。

仕様ファースト開発では、いかなるコードが生成される前にも、ユーザー・ストーリー、受け入れ基準、または正式な要件定義書の形式で仕様が記述されます。初期の明確さが提供されてコードが生成された後、仕様は必ずしも保守されるとは限りません。ソフトウェアの進化に伴い、仕様が古くなる可能性があります。その主な目的は、継続的な仕様の保守を行うことなく、初期の明確さを提供することでした。この側面は、「SDDへのエントリー・ポイント」とみなされています。¹

仕様アンカー開発では、仕様はソフトウェアとともに進化します。要件が変更され、機能が追加されると、システムの現在の状態を反映するように仕様が更新されます。これは、より大規模なイニシアチブに対応するプロジェクトにおいて特に有用です。

自動テストはドキュメンテーションと実装の間の架け橋として機能し、多くの場合、開発ライフサイクル全体を通じて両者が同期され実行可能な状態を維持できるようにするために、CI/CDパイプラインに統合されます。構造と柔軟性のこのバランスにより、仕様アンカー開発は、ほとんどのエンジニアリング・チームにとって実用的で拡張可能なアプローチとなっています。¹

スペクトルの最も極端な端にあるのが、最もAIファーストな形態である仕様・アズ・ソース開発です。仕様をソースとする開発では、仕様の変更によってコードの変更が自動的にトリガーされます。人間が直接コードをリファクタリングすることはありません。

このレベルの仕様権限には、AIコード生成パイプラインの品質と一貫性に対する高度な信頼が必要ですが、現在のところ、それは本質的に非決定的なままです。実際には、人間の強力な監視がなければ、厳密さに欠ける可能性があることを意味します。このアプローチを採用する前に、チームは自社のテック・スタックと仕様キットの成熟度、関与するシステムの重要性、およびAIが生成した出力を検証する能力を慎重に評価する必要があります。¹

実際には、多くのチームがハイブリッド・アプローチを採用しています：

• 仕様を常に完全に最新の状態に保つのではなく、アーキテクチャー決定記録（ADR）のように、積み重ね可能なバージョン管理された成果物として扱うこと。
• 意図的な分離を導入するために、外部システム（例えば、問題トラッカー）を真実の情報源として使用すること。
• 変更に対する厳格な管理が不可欠である、高複雑度のプロジェクトやコミュニティー主導のプロジェクトにおいて、過度な自動化を避けること。

それぞれの手法に強みと限界があります。いずれか1つのモデルを厳格に遵守することよりも、コンテキストが重要になります。

好ましいとする仕様権限のレベルに応じて、効果的な仕様のあり方は異なる場合があります。しかし、お客様がスペクトルの真ん中あたりに位置し、仕様アンカー開発を選択すると仮定した場合、仕様では、システムが明確でテスト可能な言葉で何を行う必要があるかを記述する必要があります。この仕様により、それがどのように実装されるかということに、時期尚早に縛られることを避けることができます。

仕様は、入力と出力の定義、データ・スキーマ、エッジ・ケース、および成功基準を含めるのに十分なほど詳細である必要があります。しかし、問題への理解が深まるにつれて進化できるよう、十分に軽量である必要があります。何よりも、優れた仕様は開発を加速させるべきです。より優れたコードをより迅速に書くことや、誤解を減らすことに役立っていないのであれば、それはおそらく必要以上に詳細すぎるのでしょう。

効果的な仕様が実際にはどのようなものであるかを示すために、ユーザー認証機能に関するこちらの例を考慮してください。

あなたはWebアプリケーション用のユーザー・ログイン機能を実装しているとします。
以下の仕様を「信頼できる唯一の情報源」として使用します。
ここに記載されていない要件については、いかなる想定も行わないでください。

機能：ユーザー・ログイン

概要：
登録済みのユーザーが、Eメール・
アドレスとパスワードを使用して安全に認証できるようにすること。

受け入れ基準：
1.ログイン・フォームは、Eメール・アドレスとパスワードを受け付ける必要がある 
2. 認証情報が有効な場合、ユーザーをダッシュボードにリダイレクトする 
3. 認証情報が無効な場合、どのフィールドが誤っているかを特定することなく、一般的なエラー・メッセージを表示する 
4. ログイン試行が5回連続して失敗した後、
アカウントを15分間ロックする 
5. パスワードはHTTPS経由でのみ送信し、プレーン・テキストでは決して保管しないこと 
 
スコープ外： 
- ソーシャル・ログイン（OAuth） 
- 二要素認証 
- パスワード・リセット・フロー 
 
エッジ・ケース： 
- 送信前にクライアント・サイドで空のフィールドを検出すること 
- 期限切れのセッションを案内メッセージとともにログイン・ページにリダイレクトすること 
- JavaScriptが無効な場合でもフォームが機能し続けること 
 
受け入れ基準を理解したことを確認するまでは、  
実装を開始しないでください。

これらはプロダクト・マネージャーが作成する機能仕様書に似ていますが、実装に含めるべき内容、つまり受け入れ基準や、エッジ・ケースに適切に対処する方法へと厳密に範囲が絞られています。

最も一般的には、この仕様はGitHub上のプロジェクト・リポジトリー（「レポ」）に、SPEC.md または/docs/auth-login.md のようなMarkdownファイルとして保存され、コードベースとともにGitを通じてバージョン管理されます。コーディング用エージェント型AIは、ユーザーがそれをプロンプトに貼り付けるか、あるいはより好ましい方法として、CLIを介してファイルを参照し、エージェントがプロジェクト・ディレクトリーからそれを読み取ることで、その仕様にアクセスできます。例えば、「/docs/auth-login.mdに記述されている機能を実装してください。」のようになります。

より自動化されたパイプラインでは、タスクの開始時に仕様ファイルがシステム・プロンプトまたはコンテキスト・ウィンドウの一部として渡され、開始前にエージェントに指示を与えます。

仕様駆動開発によって多くの時間や技術負債を削減できるとしても、「オーバー・エンジニアリング」に時間を費やしすぎてしまう可能性があることを忘れないことも重要です。1カ月後に削除される可能性のある機能のために、単一のJSONキーの名前や特定のAPIエンドポイントについて3週間も議論を重ねるようでは、仕様駆動開発の目的が失われてしまいます。

起こり得るすべての未来をモデリングすることに集中しすぎないようにしてください。網羅的な「最終」仕様よりも、軽量で進化し続ける仕様を優先します。前進するために必要なものを記述し、コード内で迅速に検証し、状況の変化に応じて反復適用します。一般的な原則として、仕様を洗練させるためのコストは、実装における誤解を修正するためのコストよりも常に低く抑えられるべきです。そのバランスが逆転したときが、ブラッシュアップをやめて構築を開始すべきサインです。

AIコーディング支援の登場に伴い、テスト駆動開発（TDD）や振る舞い駆動開発（BDD）が新たな潮流、すなわち仕様駆動開発をインスパイアしました。TDDが開発者にテストを通じて期待される成果を定義することを求め、BDDがコラボレーションを通じて振る舞いを定義することを求めるのに対し、仕様駆動開発はまず、より根本的な問いを投げかけます。それは、私たちは構築しようとしているもの、そしてそれが誰のためのものであるかを明確に定義できているか、ということです。^2,3

AIエージェントが実装作業のより大きな割合を担うようになるにつれて、その作業の品質は、受け取る指示の品質に正比例するようになります。適切に作成された仕様は、開発プロセスを制約するものではなく、むしろモダンなソフトウェア・システムにおいて開発プロセスを加速させるものです。