はじめに：「コード」がもはや「意図」とイコールではなくなった時代
過去数十年のソフトウェアエンジニアリングにおいて、「私たちのコード」は「私たちの意図」の直接的な具現化でした。アーキテクチャを設計し、インターフェースを定義し、ロジックを書き、境界をデバッグする――コードの1行1行が思考の具象化でした。コミュニケーションのズレがあったとしても、それは主に人と人の間で発生していました。いったんコーディングフェーズに入れば、意図はコードの中にしっかりと定着していました。
従来の意味での「インテントアライメント」は、通常、要件理解の一致にとどまっていました。しかし、Vibe CodingやHarness Engineeringといった新興パラダイムが開発プロセスを席巻している今日、この等式は完全に崩れました。
コードはもはや意図の媒体ではありません。AIがあなたの意図を「翻訳した結果」です。
これは、「意図の一致」という課題が「人と人」から「人とAI」へと移行したことを意味します。しかも、より高いレベルの要件が求められ、許容範囲はより狭まります。「書きながら考える」や「コードがドキュメント」といった曖昧な暗黙の了解に依存することはもうできません。AIに対して以下の情報を、ほぼ100%正確に伝える必要があります：
- 実行順序：何を先にやるか？何を後にやるか？どのステップは並行実行不可か？
- 技術選定：どのフレームワークを使うか？どの依存バージョンか？新しいライブラリの導入は許可するか？
- アーキテクチャ規約：モジュールの境界はどこか？どこが禁止区域か？データフローをどのように制約するか？
- 開発方式：通常開発か、テスト駆動開発か？（TDD）
- コンテキスト資産：ナレッジベースはどこにあるか？既存のインターフェース契約は何か？
- 環境制限：実行時のリソース上限は？ネットワークポリシー？セキュリティコンプライアンスのレッドラインは？
- 検証基準：何が「完了」と言えるか？テストはどのパスをカバーするか？失敗のセマンティクスはどのように定義するか？E2Eテストは必要か？
いずれかが欠けると、AIは訓練データからの「一般的なパターン」に基づいて、合理的だが誤った推論を行う可能性があります。これは初期のVibe Codingで最も批判された点です――思い込みで判断し、勝手に決定を下すこと。そして、これらの欠落した情報こそが「意図と結果のギャップ」の根源です。
意図と結果のギャップ：多くの要因が良くない成果につながる
Vibe Codingの実践において、私たちはしばしば一種の錯覚に陥ります。アイデアを「言う」だけで、AIが「理解」して「正しくやってくれる」と。しかし現実は異なります：意図 ≠ 指示、指示 ≠ 実装、実装 ≠ 正解。
曖昧な自然言語
自然言語は感情と方向を伝えるのには優れていますが、エンジニアリングに必要な精密さは極めて欠けています。そもそも自然言語は「人との効率的なコミュニケーション」のために使われているもので、朝食の材料、火加減、食感、そして身体への長期的影響まで事細かに描写したい人はいません。
「パフォーマンスを最適化して」「コードをきれいにして」「もっとロバストに処理して」……こうした表現は人間同士の協業ではよく見られますが、人机インタラクションでは災難の起点となります。AIはあなたの裏の意図を感じ取ることはできず、確率に基づいて「最も可能性が高い」解釈（訓練データに基づく）を選択するしかありません。そして、その解釈は多くの場合、あなたの真の意図とは大きく乖離しています。
不十分なコンテキスト
AIはあなたのシステムについて何も知りません。明示的に伝えない限り：
- どのサービスがクリティカルパスで、どれが周辺機能か？
- フィールドの意味は何か？どれが変更不可で、禁止区域はどこか？
- このインターフェースのRPC呼び出しパスは何か？
- キャッシュ失効後、グレースフルデグラデーションにするか、エラーを返すか？
- キャッシュTTLに20%のランダムジッターを追加して、キャッシュスタンプビートを防ぐべきか？
これらの「組織内の常識」をコンテキストに明示的に注入しないと、AIは過去の訓練からの一般的なパターンで空白を埋めてしまいます。結果として誤ったデグラデーション戦略、権限を超えたデータアクセス、既存の契約と衝突するインターフェース変更につながり、アーキテクチャを汚染し、隠れたバグを埋め込むことになります。
フィードバックなし、明確化なし、調査なし、検証なし
「曖昧な自然言語」と「不十分なコンテキスト」は最も深刻な問題ではありません。本当に危険なのは人間-AI協同の検証ループの欠如です。現在のAIは不確実性を積極的にフィードバックすることはなく、ナレッジベースを自ら参照することもありません。これらはすべて開発者が積極的にインタラクションフローを設計することに依存しています：
- 強制明確化：曖昧な部分や判断がつかない部分がある場合、A案かB案かを選択し、独断で決めず、必ず私たちに問い合わせること。
- コンテキスト補完：私たちがAIに伝える情報は必ず不十分です。AIは自分で指定された場所を調査できる必要があります。
- 自己検証：情報が十分に多い場合、それらを繋ぎ合わせて合理的な方案を形成できるか？AIに自己検証能力が必要です。
過長なコンテキストによる「腐敗」と幻覚の発生
前述の通り、コンテキスト情報の不足は意図理解のズレにつながります。しかし、過度に冗長な情報も同様に意図理解の誤りを招く可能性があります。大規模モデルのコンテキスト容量は限られており、情報処理能力にも限りがあります。情報量が増えるにつれて、AIのAttentionメカニズムが「ピンぼけ」を始めます。会話の早い段階の重要な制約が希釈され、後半の追加内容が過剰に強調されます。明らかな問題に気づくでしょう――最初に伝えた規則が、最後には「忘れ去られている」ことに。同時に、過度なコンテキストは大モデルに圧縮を強制し、さらなる情報の歪みを引き起こします。
シグナル対ノイズ比をコントロールする。私たちがやるべきことは：
- コンテキスト情報：精度 > 量
- 構造化された記述
- フォーカスすべきポイントは何か？
最後に：実践
まずコンテキスト内にベースライン規範を定義する必要があります。スキル設定に追加することもできます：
- 要件に曖昧さがある場合は先に聞くこと。「一般的なやり方」に基づいて、ユーザーが要求していないタスクを勝手に追加しないこと。
- ユーザーの説明に複数の解釈方法がある場合は、先に明確化を問い合わせること。ユーザーの代わりに勝手に推測しないこと。
- 50行で解決できる問題は、200行に書かないこと。コードの過剰なカプセル化、過剰な抽象化を避けること。
- 可能な限りローカルな変更にとどめること。最初から大規模なリファクタリングを始めないこと。小さなタスクを大規模な手術に変えないこと。
- タスクが非常に複雑な場合は、段階的に実施すること。コンテキスト総量をコントロールし、「腐敗」を避けること。
プロンプトからエンジニアリング制約へのパラダイムシフトについては、Vibe Coding：Harness Engineeringを参照してください。コンテキスト腐敗がAIコーディングセッションにどのように影響するかについては、私のGSD体験をチェックしてください。Vibe Codingの実用的なワークフローについては、Vibe Coding時代のGit Worktreeを参照してください。仕様駆動開発の実践については、私のOpenSpec体験をお読みください。