🕛

実践VC-AD:AIを「過保護な執事」から「爆速のハッカー」に変えるYAML【VC-AD 第5話】

に公開

はじめに:言葉による説得の限界

「シンプルに書いて」「余計なことはしないで」。 これまで、私たちはAIに対して自然言語で必死に「お願い」をしてきました。しかし、彼らの「良かれと思ってやる」バイアスは強力で、気がつけばまた重厚なクラス設計や丁寧なコメントが生成されています。

言葉でダメなら、契約(コード)で縛るしかありません。

最終回となる今回は、VC-AD(Value-Continuous AI Development) の核心である、YAML形式のプロトコルを用いたAI制御の実践手法を公開します。 AIを「空気を読む執事」から、あなたの指示通りに動く「爆速のハッカー」へと変貌させるための技術です。

なぜYAMLなのか?

VC-ADでは、AIへの境界条件をYAMLファイルとして定義し、開発コンテキストに含めます。プロンプトに長々と条件を書くのではなく、外部ファイルとして参照させるのです。

理由は3つあります。

  • トークン効率: 自然言語よりも構造化データの方が、AIは少ないトークンで正確に意図を理解します。
  • 再利用性: プロジェクトごとに「MVP用」「本番用」などのプロトコルを切り替えられます。
  • 権威性: AIは、チャットでの会話(Instruction)よりも、ファイルとして渡された定義(Context)を「守るべき仕様」として強く認識する傾向があります。

実践:MVPのための「拘束衣」を作る

では、実際にAIの「丁寧な常識」を無効化し、爆速MVP開発モードに強制移行させるための protocol.yaml を書いてみましょう。

1. 憲法(Constitution)の定義

まず、プロジェクトの最上位ルールを定義します。

# mvp-constitution.yaml
constitution:
  version: "1.0"
  core_principles:
    - id: "speed_over_quality"
      statement: "機能的価値の検証速度を、コードの品質よりも優先する。"
      implication: "リファクタリングの可能性を考慮してはならない。"
    
    - id: "disposable_code"
      statement: "このコードは24時間以内に破棄される前提である。"
      implication: "保守性、拡張性、可読性のための記述を禁止する。"

これを読み込ませるだけで、AIの思考の優先順位がガラリと変わります。「綺麗に書かないと」というブレーキを破壊するのです。

2. 境界(Boundaries)の定義

次に、具体的なコーディングルールを「やってはいけないこと(境界)」として定義します。boundaries.yaml の構造を参考に、MVP特化の制約を作ります。

# mvp-boundaries.yaml
boundaries:
  - id: "b-structure-01"
    name: "single-file-constraint"
    description: "ファイル分割の禁止"
    rule: |
      全てのロジックは単一のファイル(例: main.py, app.ts)に記述すること。
      クラスによる分割よりも、トップレベル関数とグローバル変数を優先せよ。

  - id: "b-readability-01"
    name: "obfuscation-preference"
    description: "可読性への配慮禁止"
    rule: |
      変数名は最短(x, y, data等)であること。
      コメントアウトは禁止する。型定義も最小限とせよ。

  - id: "b-persistence-01"
    name: "on-memory-only"
    description: "外部依存の排除"
    rule: |
      DBへの接続は禁止する。全てのデータはオンメモリの配列またはMapで管理せよ。

見ての通り、 「人間のエンジニアが見たら卒倒しそうなルール」 です。しかし、これこそがAIにとっては「考慮事項が減り、最も高速に出力できる最適解」なのです。

ワークフロー:AIにプロトコルを遵守させる

これら2つのYAMLファイルを作成したら、実際の開発フローは以下のようになります。

  • Context Loading: CursorやWindsurfなどのエディタで、@mvp-constitution.yaml と @mvp-boundaries.yaml をコンテキストに追加します。

  • Prompting: プロンプトの冒頭で、このプロトコルへの準拠を宣言します。
    「コンテキストにある mvp-constitution.yaml および mvp-boundaries.yaml の定義を厳守せよ。 これらに違反する『良いコード(可読性への配慮など)』はバグとみなす。この条件下で、タスク管理アプリのバックエンドを実装せよ」

  • Result: AIは迷うことなく、数百行のスパゲッティコードを数秒で吐き出します。クラス図も、ディレクトリ構成も、エラーハンドリングもありません。 しかし、python main.py と叩けば、その瞬間からアプリは動きます。

おわりに:トロッコのレバーを握るのはあなただ

全5回にわたり、AIコーディングにおける「責任境界」について語ってきました。

  • AIの「良かれと思って」は、時に私たちの邪魔をする。
  • デフォルト設定(人間中心主義)は、MVP開発においては足枷となる。
  • VC-AD(境界のデザイン)によって、私たちはAIのポテンシャルを真に解放できる。

VCDesign、そしてVC-ADが目指すのは、「AIにコードを書かせる」ことではなく、「AIを使って価値(Value)を継続(Continuous)させる」こと です。

もちろん、すべてのプロジェクトでこのような極端なプロトコルが必要なわけではありません。
重要なのは、「どの価値を捨て、どの価値を守るか」を人間が決めている、という事実です。

AI時代において、コードはもはや絶対的な「資産」ではなくなりつつあります。 境界内で容易に捨て、容易に作り直せること。この「軽さ」こそが、逆説的にシステム全体を長生きさせることになるのです。

それこそが、本当にVCDesignが目指すことです。

そのための「境界」をデザインし、トロッコのレバーを握り続ける責任は、AIではなく、あなた自身の手の中にあります。

そしてもし私の構成が参考になるのであれば下記をどうぞ。
VCDesign
VC-AD

VC-ADとは、新しい開発手法ではありません。
「判断をどこで止め、どこから委ねるか」を設計するための、責任の設計論です。
AIがコードを書く時代において、レバーを引く責任は、依然として人間の側にあります。

(続く)

Discussion