Why VC-AD?

The Context Gap: AIはなぜ文脈を読めないのか

AIは「地図」を持たずに走っている

現在のAIは、コードを書く能力において人間を凌駕しつつあります。
しかし、AI開発の現場では「動くけれど、何かが違う」「修正するたびに別の場所が壊れる」という問題が多発しています。

原因は能力不足ではありません。「コンテキスト（文脈）の欠如」です。
人間は「このディレクトリは認証系だから慎重に」「ここは将来マイクロサービスになる」といった 暗黙の地図 を頭の中に持っています。
しかしAIにはその地図が見えていません。AIにとって、すべてのコードは等しく修正可能です。

この 「人間だけに見えている地図」 を可視化しない限り、AIは永遠に「無邪気な破壊者」であり続けます。

見えない地図の正体：「11の境界」

VCDesignでは、AIが見落としがちな「コードの外側にある制約」を11のレイヤに分類しています。
これらは、プログラム言語（As Code）として表現しにくく、プロジェクトの歴史や組織構造、物理的制約に依存する領域です。

Group 1: 変えられない前提 (Context)

1. 物理・現場制約 / 10. 組織・境界 / 11. ガバナンス
「物理的に離れている」「組織が違う」「法律で決まっている」。これらは設計で解決するものではなく、受け入れるべき前提条件です。

Group 2: 選ぶだけのリソース (Resource)

2. 実行基盤 / 3. ネットワーク / 9. プラットフォーム
クラウドやコンテナ技術によって隠蔽されていますが、性能特性やコスト構造は「選択」の結果です。

Group 3: 守るべき品質標準 (Standard)

6. 信頼性(SRE) / 7. セキュリティ / 8. 可観測性
「アクセス権限」「ログのフォーマット」。これらには明確なベストプラクティスがあり、AIが勝手に崩してはいけない領域です。

Group 4: VC-ADの主戦場 (Core Domain)

4. 分散の本質 / 5. データ意味論
「整合性を犠牲にしてでも可用性を取るか？」「二重課金を許すか？」。
ここには正解がなく、ビジネスの「意思決定（Decision）」だけが存在します。AIが最も苦手とする領域です。

解決策：AIに「設計方法」を渡す

これらの境界を、毎回プロンプトでAIに説明するのは不可能です。
そこで VC-AD は、最もシンプルで強力な解決策を提案します。

「境界定義ファイル（Boundaries YAML）を、「設計方法」としてリポジトリに置くこと」です。

The "Static Badge" Strategy

Gitにおける .gitignore や、エディタにおける .editorconfig のように、 「そこに置いてあるだけでAIが振る舞いを変えるファイル」 を標準化します。

「見えない地図」を「見える宣言」に変える。
これが、AI開発におけるコンテキスト・ギャップを埋めるための、VC-ADの基本戦略です。