Spec-Driven Development (SDD) による AI Drift の解決方法

現代の AI 支援開発ワークフローは、しばしば、優秀だがバラバラな設計者たちの委員会を管理しているかのような感覚に陥ります。Claude Code を使用して機能を構築しても、修正を依頼した際に Cursor が実装を異なる解釈をし、さらに GitHub Copilot がクリーンアップ中に第三の解釈を持ち出すことがあります。この「AI drift」と呼ばれる現象は、各エージェントがプロジェクトの要件の欠落を独自の想定で埋めてしまうために発生します。

これに対抗するため、Spec-Driven Development (SDD) のための新しい Claude skill が導入されました。コードに直接飛び込むのではなく、SDD は、ロジックを一行も書く前に、すべての AI ツールが参照しなければならない「共有された真実のソース（shared source of truth）」の作成を義務付けています。これにより、どのツールを使用しているかにかかわらず、エージェントがプロジェクトの「何（what）」「どのように（how）」「いつ（when）」について一致していることが保証されます。

コア・フレームワーク：真実の3つの柱

SDD アプローチの中核は、3つの特定の Markdown ファイルの生成にあります。これらのファイルはプロジェクトの憲法として機能し、エージェントが要件を幻覚（hallucination）させたり、意図した設計から逸脱したりすることを防ぎます。

ファイル	目的	内容の焦点
`requirements.md`	何をするか (The What)	「shall」を用いた表現と、追跡可能性のためのユニークな ID（例：REQ-001）を使用した機能要件。
`design.md`	どのようにするか (The How)	アーキテクチャの決定、データモデル、および構造的な制約。
`tasks.md`	いつするか (The When)	特定の要件に紐付けられた、アトミックで順序付けられた実装ステップのリスト。

これらのファイルを最初に確立することで、開発者は AI の役割を「推測者」から「実装者」へと変えることができます。既存のコードベースに対しては、現在のコードの状態をリバースエンジニアリングして、推論されたフィールドを [TO VERIFY] とマークすることで、開発者が AI の理解を検証できるようにする「レトロフィット（後付け）」機能も備えています。

Universal Instruction Block (UIB)

マルチ AI ワークフローにおける最も大きな課題の一つは、異なる設定ファイル（.cursorrules や .github/copilot-instructions.md など）の間で一貫性を維持することです。SDD skill は、Universal Instruction Block を生成することでこれを解決します。

このブロックは、すべてのツールの設定ファイルに挿入される標準化された一連の命令セットです。AI に対して以下のような強力な制約を課します：

必須の読み込み: エージェントは、いかなるアクションの前に、要件、設計、およびタスクのファイルを完全に読み込まなければならない。
厳格な遵守: エージェントは、requirements.md に記載されていない要件を実装したり、design.md を先に更新せずにデータモデルを変更したりすることは禁止されている。
逸脱プロトコル: もしエージェントが、実装が設計から逸脱しなければならないと判断した場合、直ちに停止し、その衝突を説明して、ユーザーの承認を待つよう指示されている。

AI エコシステム全体への統合

SDD skill はツールに依存しないように設計されており、、最も人気のある AI コーディング環境向けに特定の構成ファイルを提供します：

Claude Code: CLAUDE.md を使用して自動ブートストラップを行う。
Cursor: .cursorrules を生成する。
Windsurf: .windsurfrules を生成する。
GitHub Copilot: .github/copilot-instructions.md を生成する。
Aider: .aider.conf.yml を生成する。

厳格な検証とテスト

逸話的な成功に頼る多くの AI プロンプトや「skill」とは異なり、SDD フレームワークには、skill 自体が確実に動作することを保証するための包括的なテストスイートが含まれています。プロジェクトは、3 つの評価フェーズを使用しています：

Phase 2A (Static Assertions): 64 個の Python ベースのチェックにより、生成されたファイルが構造的要件を満たしていることを確認する。
Phase 2B (Behavioral Tests): 13 個のライブセッションテストにより、エージェントの対話中の挙動を検証する。
Phase 2C (Generation Quality): 53 個のコミット済みフィクスチャに対するチェックにより、異なるフローにおける高品質な出力を保証する。

批判的な視点と検討事項

SDD アプローチは一貫性への構造化された道筋を提供しますが、コミュニティからはスケーラビリティに関する重要な検討事項が提起されています。一部の開発者は、requirements.md や tasks.md が過度に大きくなると、AI のコンテキストウィンドウを消費しすぎ、システムが防ごうとしているまさにその幻覚や drift を引き起こす可能性があると指摘しています。

さらに、spec-driven AI 開発のエコシステムは成長しています。他のツールやプラグイン（superpowers、get-shit-done、spec kit など）も、厳学な計画を通じて AI の出力を構造化するという同様の目標を試みています。

結論

Spec-Driven Development は、AI コーディングのパラダイムを「プロンプトを投げて祈る（prompt and pray）」から、規律あるエンジニアリング・プロセスへとシフトさせます。機能の概念化と実装の間に一時停止を強制し、複数の AI エージェントを単一の Markdown ドキュメントのセットに固定することで、SDD は、ますます断片化が進む AI ツールチェーンにおいて、アーキテクチャの整合性を維持するためのスケーラブルな方法を提供します。