VS CodeとJetBrainsとCLIで、同じAIエージェントが動いている。これは偶然ではない。
2026年2月2日、OpenAIがCodex macOSアプリをリリースした。その3日後、エンジニアのCelia ChenがOpenAIブログに技術解説を公開した。タイトルは「Unlocking the Codex harness」。内容は「なぜ同じCodexエージェントがCLI、VS Code、macOSアプリ、JetBrains、Xcodeと複数の環境で動くのか」への回答だった。
Codex macOSアプリの機能や設計思想については別記事で詳しく書いた。この記事では「なぜ動くのか」という問い、つまりApp Serverというアーキテクチャを解説する。「プロトコル」とはプログラム同士の取り決め・共通言語のことだ。プログラミングの知識がなくても読める内容にした。
プラグイン地獄——N×M問題
AIエージェントを複数のIDEで動かすには、普通ならどうするか。IDE別にプラグインを作る。VS Code用のプラグイン、JetBrains用のプラグイン、Xcode用のプラグイン……。エージェントが増えるたびに、IDEの数だけ実装が増える。エージェントを1つ改善したら、全プラグインに変更を反映しなければならない。
これが「N（エージェント数）×M（IDE数）問題」だ。MCPというプロトコルがAIツールの世界で解決しようとしているのも、実は同じ構造の問題だ。App Serverはこの問題に、別の角度から答えを出している。Codexが今後新しいIDEに対応するとき、エージェントのロジックを書き直す必要はない。接続する「窓口」を増やすだけでいい。
App Serverとは何か——「共有バックエンド」という考え方
「バックエンド」という言葉は難しく聞こえるかもしれない。Twitterを例に考えよう。Twitterの中身（ツイートのデータ、タイムラインの計算、フォロー関係の管理）は1か所のサーバーにある。iOSアプリを使っても、Androidアプリを使っても、ブラウザから使っても、同じツイートが見えるのはそのためだ。クライアント（アプリ）が変わっても、中身（サーバー）は共通だ。
Codex App Serverはこれと同じ発想だ。エージェントの「頭脳」にあたるロジックを1か所のプロセス（App Server）に集め、VS CodeでもJetBrainsでもCLIでも、共通のプロトコル（JSON-RPC）で話しかける構造にした。
App ServerはオープンソースとしてGitHubで公開されている。実装言語はRustだ。
内部構造——4つのコンポーネント
OpenAIのエンジニアリングブログによると、App Serverは常駐プロセスとして動き続け、4つのコンポーネントで構成されている。
ひとつめは「stdioリーダー」。ターミナルの入出力ストリーム（stdio）を通じてクライアントとのメッセージのやり取りを担う、玄関の窓口にあたる部分だ。
ふたつめは「Codexメッセージプロセッサ」。クライアントから受け取ったメッセージを解釈し、適切なスレッドに振り分ける処理を担う。郵便局の仕分け係のようなものだ。
みっつめは「スレッドマネージャ」。複数の会話（スレッド）を並列で管理する調整役だ。Codexが同時に複数のタスクを実行できるのはこのコンポーネントのおかげだ。
よっつめは「コアスレッド」。実際にAIエージェントのループ（考える→コードを書く→ツールを実行する→結果を返す）を実行する本体だ。ここが「頭脳」にあたる部分で、IDEが何であっても同じロジックが動く。
3つの会話プリミティブ——Item・Turn・Thread
App Serverには、会話を構成する3つの単位がある。これを理解すると、後述するプロトコルの構造が見えてくる。
もっとも小さい単位が「Item」だ。テキスト1行、コマンド1回、ファイルの差分1件——それぞれが1つのItemだ。原子のような最小単位として考えるとわかりやすい。
その上が「Turn」。1回のやり取り——ユーザーの指示とエージェントの応答のセット——がTurnだ。「認証バグを修正して」と伝え、エージェントが作業して結果を返すまでの一連の流れが1つのTurnだ。
最大の単位が「Thread」。ThreadはItemとTurnが積み重なった会話セッション全体だ。一度始めたスレッドを維持したまま複数のタスクを順番に処理できる。
この3層構造は、WebのDOM（ドキュメント・オブジェクト・モデル）の構造に似ている。一番小さいテキストノードが積み重なって段落になり、段落が積み重なってドキュメントになる。App Serverの会話も同じ階層で管理されている。
なぜMCPを使わなかったのか
OpenAIはまずMCP（Model Context Protocol）でCodexを公開することを試みた。MCPはAnthropicが2024年11月に策定したプロトコルで、AIツールをさまざまなクライアントから使うための共通インターフェースだ。
しかし公式ブログによると、VS Code統合でMCPを採用することを断念した。その理由を端的に言えば、MCPは「単方向の荷物の受け渡し」にしか対応していなかったからだ。
MCPは宅配ボックスのような仕組みだ。クライアントが「このツールを実行して」と荷物を入れ、サーバーが「実行結果はこれ」と荷物を返す。受け渡しはできる。しかしエージェントが「実行前に確認してください」とサーバー側からドアベルを押す仕組みがない。宅配ボックスにドアベルはないのだ。
AIエージェントが危険なコマンド（たとえばgit push）を実行しようとするとき、人間に承認を求める必要がある。「承認要求」はサーバー（エージェント）からクライアント（人間）への能動的な問いかけだ。これを実現するには、サーバー側から自発的にメッセージを送れる「双方向プロトコル」が必要だった。
❌ MCP方式の限界（単方向ツール呼び出し）
クライアント → MCPサーバー: 「このツールを実行して」
MCPサーバー → クライアント: 「実行結果はこれ」
# → 「実行前に確認して」をサーバー側から能動的に送れない
✅ App Server（双方向JSON-RPC）
クライアント → App Server: 「turn/start: 認証バグを修正して」
App Server → クライアント: 「item/started: git diff を実行中」（サーバー起点の通知）
App Server → クライアント: 「approval/requested: git push を実行してもいいですか？」（サーバー起点の承認要求）
クライアント → App Server: 「accept（承認する）」
App Server → クライアント: 「item/completed: 完了」
実際のメッセージはJSON形式でやり取りされる。この形式を「JSON-RPC」と呼ぶ。
// ① クライアント → サーバー: ターン開始（指示を送る）
{ "method": "turn/start", "id": 2, "params": {
"threadId": "thr_abc123",
"input": [{ "type": "text", "text": "認証バグを修正して" }]
}
}
// ② サーバー → クライアント: 通知（IDなし）——エージェントが動き始めた
{ "method": "item/started", "params": { "item": { "type": "commandExecution", "command": "git diff" } } }
// ③ サーバー → クライアント: 承認要求——コマンド実行前に人間の確認が必要
{ "method": "approval/requested", "id": 99, "params": { "kind": "command", "command": "git push" } }
// ④ クライアント → サーバー: 承認応答——ここでサーバーが待っていた
{ "id": 99, "result": { "decision": "accept" } }
③のメッセージがポイントだ。これはサーバー（App Server）側から自発的に送られてくる。クライアントはこの問いかけを待ち、ユーザーに確認ダイアログを出し、応答を返す。MCPの単方向設計ではこの流れを実現できなかった。
MCPが完全に否定されたわけではない。codex mcp-server コマンドを実行するとCodexをMCPサーバーとして起動できる。OpenAI Agents SDKなど、stdioを使えるMCPクライアントからは引き続き接続可能だ。App ServerとMCPサーバーは用途が異なり、棲み分けが存在する。
LSP類比——エージェント版「Language Server Protocol」
この構造に覚えがあるプログラマは多いはずだ。LSP（Language Server Protocol）だ。
LSPが登場する2016年以前、エディタごとにJavaScriptのコード補完・エラー検出・定義ジャンプを別々に実装していた。VS Codeに実装したら、VimやEmacsには別途実装しなければならなかった。「エディタ×言語」の組み合わせ分だけ、実装コストがかかった。
MicrosoftがLSPを策定したことで構造が変わった。言語のロジック（Language Server）とエディタを分離し、共通プロトコルで話しかける設計にした。ひとつのLanguage Serverを作れば、LSPに対応したどのエディタでも動く。AIコーディングに取り組む人には、LSPがコード補完・エラー表示を提供している仕組みだ、と言えば伝わりやすいかもしれない。
App Serverは、AIエージェントにこれと同じことをしている。「エージェントのロジック」と「IDEのUI」を切り離し、共通プロトコルで接続する。ひとつのApp Serverを作れば、対応クライアントが増えてもエージェントのロジックを書き直す必要がない。
この動きはOpenAIだけではない。エディタのZedはACP（Agent Client Protocol）という独自のプロトコルを提唱している。エコシステム全体で「エージェントと接続するための共通言語」の模索が始まっている段階だ。
現状の数字
Codex macOSアプリのリリース発表によると、GPT-5.2-Codexが2025年12月中旬に公開されて以降、Codexの全体的な利用は2倍になり、過去1ヶ月で100万人以上の開発者がCodexを使用した（2026年2月時点）。
また、OpenAIの別のブログ投稿によると、週間アクティブ開発者数が2026年1月比で5倍に成長したという。Codex desktopアプリ自体のコードの約90%はCodex自身が生成したと、技術メディアThe Pragmatic Engineerが伝えている。ツールがツール自身を作る構造は、AIコーディングの現在地を象徴している。
「プラグイン時代」から「サービス時代」へ
AIエージェントの配信が、IDEのプラグインから共有バックエンドへ移行しつつある。
これはWeb開発の歴史で何度も見てきた動きだ。デスクトップソフト→クラウドサービス、ネイティブアプリ→Webアプリ。機能の「本体」が手元から遠ざかり、「窓口」だけが多様化する。AIエージェントも今、同じ道を歩んでいる。
App Serverはまだ発展途上だ。2026年2月にはv0.106.0でスレッドAPIが拡張され、v0.100.0ではWebSocketトランスポートが実験的に追加されるなど、活発に更新が続いている。しかし「1つのエージェントをどこからでも呼べる」という設計の方向性は、今後のAIコーディングツールの標準的なアーキテクチャになっていく可能性がある。
Codex macOSアプリが「何ができるか」を見せたとすれば、App Serverは「どうすれば維持できるか」を示した。AIエージェントが複数のIDEで同時に動き、人間の承認を求め、会話の文脈を保持し続ける——それを支える設計の話だ。