TL;DR:「バイブ・コーディング」--AIにさりげなくソフトウェアを構築させる実践--が流行している。しかし、構造がなければ、必然的に「コンテキスト・ドリフト」やスパゲッティ・コードにつながります。AIでエンタープライズグレードのソフトウェアを構築するには、厳格なコンテキストアーキテクチャが必要です。マーキュリーではこれを「コーデックス プロトコル」と呼んでいます。これは、ドキュメントを提案としてではなく、AIがコードを1行書く前に参照しなければならない不変の法則として扱います。
マーキュリー・テクノロジー・ソリューションズのCEO、ジェームスである。
インターネットは "バイブ・コーディング "で賑わっている。AIに何気なく話しかけると（「バイブ」）、AIがアプリを構築してくれるというものだ。
私は、開発サークルで流布している一般的なワークフローをレビューしてきた。それらはプロトタイプとしては素晴らしいが、本格的なエンジニアリングには致命的な欠陥がある：AIが "全体像 "を覚えていると仮定していることです。そうではありません。
LLMはエントロピーに苦しんでいる。会話が長くなると、AIは40メッセージ前に合意したデータベーススキーマを忘れてしまう。新しいパターンを発明し始める。バイブ」はカオスに変わる。
マーキュリーでは、これを厳格なワークフローに洗練させました。私たちはこれをバイブ・コーディングとは呼びません。私たちはそれをコンテキスト・エンジニアリングと呼んでいます。
私たちがコーデックスと呼ぶ「単一の真実の情報源」を使って、AIでソフトウェアを構築するための「マーキュリー・プロトコル」を紹介しよう。
核となる哲学"写本"
秘密はモデル（クロード対GPT-5）ではない。秘密は外部化されたメモリーにある。
プロジェクト・フォルダーは、単にコードを入れる場所としてではなく、AIの「頭脳」として扱わなければなりません。私たちは/codexと呼ばれる厳密なフォルダ構造を強制しています。
なぜ「写本」なのか？それは権威を意味するからだ。これはメモではなく、法則なのだ。AIはコードを一行でも書く前に、コーデックスを参照しなければなりません。
構造
ルート・ディレクトリに/codexという名前のフォルダを作成する。その中には5つの不変ファイルが含まれている：
- product-vision.md（Why）：ハイレベルなゴール。(例: "ThreeJSを使用した3Dマルチプレイヤードッグファイトゲーム").
- tech-stack.md（どのように）: 具体的なツール。(例: "ネットワークはWebSocket、物理はRapier。Reactは使わず、バニラJSのみ」）。
- architecture.md（マップ）: ファイル構造とデータベーススキーマ。これは最も重要なファイルです。
- implementation-plan.md（パス）: タスクのステップ・バイ・ステップのリスト。各ステップは検証テストを持たなければならない。
- progress.md（ログ）：何が完了し、何が保留されているか。
ワークフローアーキテクチャ --実行 --検証
ただチャットを開いてコーディングを始めないこと。このループに従ってください。
フェーズ1：建築家（モデル：クロード・オーパス4.5）
私たちは、最も賢く、最も遅いモデルを使って法律を書きます。
アクションあなたはプロダクトマネージャーとして行動する。チャットに脳みそをぶちまける。
プロンプト「システムアーキテクトとして行動してください。私のアイデアに基づいてproduct-vision.mdとtech-stack.mdのエントリを作成してください。それからarchitecture.mdを提案してください。まだコードは書かないでください。これらのファイルはコーデックスに入れる。"
結果：デザインを固定する。AIが後でアーキテクチャを決定することを明示的に禁止しているのです。
第2段階：書記（モデル：クロード・ソネット4.5／写本）
私たちは法律を実行するために、高速の『エージェント』モデルを使用しています。
黄金律新しいチャット・セッションは、必ずAIがコーデックスを参照するところから始めなければならない。
プロンプト"/codex/@architecture.md、/codex/@implementation-plan.md。現在ステップ3に進んでいます。コーデックスで定義されたアーキテクチャーを厳守し、ステップ3を実施してください。ステップ4に進んではいけません。"
AIに毎回/codexを読ませることで、"コンテキスト・ドリフト "をなくすことができる。プロンプト#1であろうとプロンプト#100であろうと関係なく、AIは同じ真理に立脚している。
フェーズ3：検証者（モデル：人間＋BrowserTools）
<これが君の仕事だ。
一般的なガイドでは自動化を勧めているが、私は人間による検証にこだわっている。
アクションAIは "ステップ3は終了しました "と言う。
あなた：コードを実行する。ログをチェックする。3D飛行機は実際に飛んでいますか？
重要なステップ：うまくいったら、AIにこう命令する。「ステップ3が完了したことを示すために、/codex/@progress.md を更新してください。新しいファイルを追加した場合は、/codex/@architecture.md を更新してください。"
そのときだけGitにコミットする。Gitがあなたのセーブポイントです。もしステップ4でAIが幻覚を見てしまったら、git reset --hardでもう一度やり直してください。
反重力」の優位性：モデル裁定取引
オリジナルのガイドでは、1つのツールを選択することを提案している。私はそうは思わない。
モデル裁定取引を利用する：
- 計画 (アーキテクト): Opus 4.5を使いましょう。エッジケースについて深く考え、堅牢なコーデックスを書きます。
- コーディング (The Scribe): Sonnet 4.5 を使う。これは指示に従うし、より安い。
- リファクタリング (ライブラリアン): Gemini 3 Pro を使う。巨大なコンテキストウィンドウがあり、物事が面倒になったときにコードベース全体を一度に読むことができます。
結論雰囲気」から「ビジョン」へ
"バイブ・コーディング "とは、AIが働いている間、ただ冷静でいられるという意味だ。それは間違いだ。
このワークフローは、あなたの労力をタイピングからガバメントへとシフトさせる。
- あなたはもうレンガ職人ではない。
- あなたは写本の管理人です。
あなたの仕事は、Codexがきれいなままであることを保証することです。architecture.mdが乱雑になれば、コードも乱雑になります。implementation-plan.mdが曖昧だと、AIは動けなくなる。
コーデックスを使いこなせば、エンタープライズグレードのソフトウェアを一人で構築できる。コーデックスを無視すれば、フォルダいっぱいに壊れたスクリプトが並ぶだけだ。
マーキュリー・テクノロジー・ソリューションズ：
