VDD（Vision-Driven Development）は、AI 自律開発における「型」のフレームワークである。ルールを文書に書くだけでなく技術的に強制し、その境界の中で AI に最大限の自律性を与える。戦略（VDD）と実行（RDD）を明確に分離することで、人間はビジョンに集中し、AI は実装に集中できる。
ドキュメントに「こうしてください」と書くだけでは不十分である。AI は文脈に応じてルールを破ることがある。VDD では重要なルールを git hook や Claude Code hook で技術的にブロックし、違反を物理的に不可能にする。
L5: deny（技術的ブロック） ← 最重要ルール
L4: ask/block（確認要求） ← 重要だが例外あり
L3: コンテキスト注入 ← サブエージェントへの自動通知
L2: プロンプト内ルール ← 最低限の強制
この階層設計により、「絶対に守るべきルール」と「判断に委ねるガイドライン」が明確に区別される。詳細は enforcement-levels.md を参照。
VDD のパラドックスは「制約が自律性を生む」ことにある。
- 境界がないと: AI は「これをやっていいか？」と常に確認を求め、人間が逐一判断する必要がある
- 境界があると: AI は「この範囲内なら自由にやっていい」と理解し、確認なしに高速で実装を進められる
リリース仕様書がスコープを定義し、ブランチ戦略が影響範囲を隔離し、TDD がテストで品質を担保する。この三重の境界の中で、AI は自律的に設計・実装・テスト・レビューを完結できる。
VDD は2つの明確なレイヤーで構成される:
| レイヤー | 担当 | 問い | 成果物 |
|---|---|---|---|
| VDD（戦略） | 人間主導 | 何を目指すか？なぜそれをやるか？ | ビジョン、意思決定、リリース仕様書 |
| RDD（実行） | AI 主導 | どう届けるか？ | コード、テスト、PR、レビュー |
この分離の意義は:
- 人間は「判断」に集中できる: 実装の詳細に引きずられず、ビジョンとの整合性を判断する
- AI は「実行」に集中できる: 「なぜ作るか」が明確なので、「どう作るか」に全力を注げる
- 手戻りが減る: 方向性の合意が先にあるため、実装後に「そもそもこれ違う」が起きにくい
VDD では、全てのコード変更を git worktree 上で行い、メインワークツリーを読み取り専用として扱う。これは単なる好みではなく、AI 自律開発における安全性の根幹である。
問題: AI がメインワークツリーでブランチを切り替えると、未コミットの作業が消失するリスクがある。人間が途中まで作業していたファイル、別のリリースの修正中のコードなど、git の staging area に載っていない変更は git checkout で失われる。
解決: worktree は物理的に独立したディレクトリであり、メインワークツリーに一切影響を与えない。複数のリリースを並列で進めても、互いに干渉しない。
repository/ # メインワークツリー（読み取り専用）
├── .worktrees/
│ ├── release-feature-a/ # リリース A の作業（独立）
│ └── release-feature-b/ # リリース B の作業（独立）
この隔離は hook（L5: deny）で技術的に強制される。メインワークツリーでのファイル編集は物理的にブロックされる。
武道の「型」のように、VDD は一見すると制約に見えるが、実際には熟達への道筋を提供する。
- 初心者（L1）: worktree-guard と commit-guard だけで「AI が壊さない」安全性を確保
- 中級者（L3）: TDD + レビュー + サブエージェントルールで「AI が自律的に品質を担保する」
- 上級者（L5）: VDD アーティファクト + ディベートパートナー + クラウド実行で「AI が完全自律パイプラインを回す」
各段階で必要な「型」を身につけることで、AI の自律性を段階的に拡大できる。一気に全てを導入する必要はない。詳細は adoption-levels.md を参照。
サブエージェントに手順書（HOW）を渡す代わりに、ゴール（WHAT）を宣言し、完了条件を出口ゲート（Stop フック）で機械的に検証する。
| 要素 | 役割 |
|---|---|
| ゴール宣言 | 「develop にマージまでやり切れ」 |
| 出口ゲート (Stop フック L4) | 完了条件の機械的検証（仕様書の存在、レビュー実行、PR マージ） |
| ガードレール (既存フック群 L5) | してはいけないことのブロック |
| 道具 (スキル) | 使うかどうかは AI の判断に委ねる |
Before: L3 注入で 10 ステップの手順書 → コンテキスト消費、メンテナンスコスト
After: L3 注入でゴール宣言 + L4 Stop フックで検証 → AI が手段を自分で選ぶ
この設計は「境界が自律性を生む」（原則 2）の延長にある。ガードレールが「してはいけないこと」を、出口ゲートが「完了条件」を定義し、その間の HOW は AI の自律判断に委ねる。
フレームワークの全てを一度に導入する必要はない。最小限の安全装置（L1）から始めて、プロジェクトの成熟に応じて段階的にレベルを上げる。各段階で十分な価値が得られる設計になっている。
VDD は自然言語中心で運用する。過度なスキーマ化やフォーマット強制は避ける。必要最小限の「置き場所」を固定することで、解釈ブレを防ぎつつ柔軟性を保つ。
全てのリリースはロールバック可能であることを要求する。不可逆な変更には人間の明示的な承認を必要とする。これにより、AI が自律的に実装を進めても、問題があれば即座に巻き戻せる。
全ての意思決定は理由（context）とともに記録される。「何を決めたか」だけでなく「なぜそう判断したか」が追跡可能であること。これが将来の判断の基盤となる。
| 特徴 | 従来の開発プロセス | VDD |
|---|---|---|
| ルールの強制 | ドキュメント + コードレビュー | hook による技術的強制 |
| AI の役割 | コード補助（Copilot 的） | 自律的な実装・テスト・レビュー |
| 品質保証 | 人間によるコードレビュー | 多角的 AI レビュー + 人間 QA |
| ブランチ戦略 | 開発者の判断 | worktree による物理的隔離 |
| 意思決定 | 暗黙的 / Slack で流れる | 台帳で永続化、理由を必須記録 |
- VDD.md — VDD の詳細仕様
- RDD.md — RDD の詳細仕様
- getting-started.md — 導入手順
- adoption-levels.md — 段階的採用パス