この記事で分かること
- Codex App Server の役割と誕生の背景
- Item / Turn / Thread — 3つの会話プリミティブの設計思想
- CLI・VS Code・Web・macOS アプリ・Xcode・JetBrains を1つのプロトコルで繋ぐ仕組み
- MCP との違いと使い分け
- 個人開発者が活用できるポイント
Codex App Server とは
OpenAI は2026年2月、Codex のコアアーキテクチャである App Server の詳細を公式ブログで公開した。執筆者は OpenAI エンジニアの Celia Chen 氏。
App Server は一言で言えば、Codex エージェントのロジック（ハーネス）をあらゆるクライアントに提供する双方向 JSON-RPC API だ。
現在 Codex は以下のすべての「表面（surface）」で利用できる：
| Surface | 提供形態 |
|---|---|
| Codex CLI | ターミナル（TUI） |
| VS Code 拡張 | IDE 統合 |
| Codex Web | ブラウザアプリ |
| Codex macOS アプリ | デスクトップ |
| JetBrains | パートナー IDE |
| Xcode | パートナー IDE |
これらすべてが同一の App Server プロトコルで動いている。UIごとにエージェントロジックを再実装する必要がなく、1つの「ハーネス」を共有する設計だ。
なぜ App Server が生まれたのか
TUI から IDE へ — 再実装の壁
Codex はもともと CLI（ターミナル UI）として始まった。VS Code 拡張を作る際、同じエージェントループを IDE の UI から駆動する必要が出たが、以下のようなリッチなインタラクションが求められた：
- ワークスペースの探索
- エージェントの推論過程のストリーミング
- diff の段階的な表示
- コマンド実行前の承認フロー
単純な request/response では表現できない。
MCP を試して断念
OpenAI チームは最初に MCP（Model Context Protocol）をベースに Codex を MCP サーバーとして公開する実験を行った（GitHub PR #2264）。しかし、IDE に必要なセッション管理・ストリーミング diff・承認フローなどのリッチなセマンティクスが MCP のツール指向モデルに綺麗にマッピングできず、断念した。
代わりに、TUI のループを模した独自の JSON-RPC プロトコルを導入。これが App Server の非公式な初版になった。
パートナー需要で「プラットフォーム」へ
Codex の普及に伴い、JetBrains・Xcode・macOS デスクトップアプリなど複数のパートナーが「同じハーネスを自社製品に組み込みたい」と要望。これが App Server を安定したプラットフォーム API へと進化させるきっかけになった。
アーキテクチャの全体像
App Server プロセスは4つの主要コンポーネントで構成される：
| コンポーネント | 役割 |
|---|---|
| stdio Reader | クライアントからの JSON-RPC メッセージを読み取る |
| Codex Message Processor | JSON-RPC ↔ Codex Core の変換レイヤー |
| Thread Manager | スレッド（会話）ごとに Core セッションを起動・管理 |
| Core Threads | 実際のエージェントループを実行する Codex Core のインスタンス |
通信は JSON-RPC over stdio（JSONL） で行われる。HTTP や WebSocket ではなく標準入出力を使うのがポイントで、子プロセスとして起動するだけで統合できる。
Codex Core（ソースコード）には以下の機能が含まれる：
- スレッドのライフサイクル管理 — 作成・再開・フォーク・アーカイブ、イベント履歴の永続化
- 設定と認証 — Sign in with ChatGPT、認証情報の管理
- ツール実行と拡張 — サンドボックス内でのシェル/ファイル操作、MCP サーバーやスキルの統合
3つの会話プリミティブ
App Server のプロトコル設計で最も重要なのが、Item・Turn・Thread の3層構造だ。
Item（アイテム）— 入出力の最小単位
ユーザーメッセージ、エージェントメッセージ、ツール実行、承認リクエスト、diff など、型付きの入出力単位。明確なライフサイクルを持つ：
item/started → 開始（クライアントは即座にレンダリング開始）
item/*/delta → ストリーミング更新（オプション）
item/completed → 確定
Turn（ターン）— エージェント作業の1単位
ユーザーの入力で開始し、エージェントが出力を完了するまでの一連の Item を包含する。例えば「テストを実行して失敗をまとめて」という1回の指示が1ターン。
Thread（スレッド）— 永続的なセッション
複数のターンを含む耐久コンテナ。作成・再開・フォーク・アーカイブが可能で、イベント履歴が永続化されるため、クライアントが切断されても再接続で状態を復元できる。
承認フロー — 安全なツール実行
App Server のプロトコルは完全に双方向だ。通常はクライアントがリクエストしてサーバーが通知を返すが、サーバーからクライアントへのリクエストもサポートしている。
代表例が承認フロー：エージェントがコマンドを実行する前に、サーバーがクライアントに承認を求め、ターンを一時停止する。クライアントが「allow」か「deny」を返すまで処理は進まない。
これにより、AIエージェントが意図しない操作を実行するリスクを制御できる。
クライアント統合の3パターン
1. ローカルアプリ / IDE
VS Code 拡張やデスクトップアプリは、プラットフォーム固有の App Server バイナリをバンドルし、子プロセスとして起動。双方向 stdio チャネルを維持する。
Xcode のようなパートナーは、クライアントのリリースサイクルを分離。クライアントは安定させたまま、サーバー側だけを更新できる。後方互換性が設計されているため、古いクライアントが新しいサーバーと通信しても安全。
2. Codex Web
ブラウザはエフェメラル（タブが閉じればセッションが消える）なので、アーキテクチャが異なる：
- ワーカーがコンテナ内で App Server バイナリを起動
- ブラウザは HTTP + SSE（Server-Sent Events）でバックエンドと通信
- バックエンドがワーカーにプロキシ
タブを閉じてもサーバー側で作業が継続し、再接続時にキャッチアップできる。
3. TUI（CLI）
歴史的に TUI は Codex Core と同一プロセスで動いていた特殊なクライアントだったが、現在は App Server クライアントとしてリファクタリングが進行中（PR #10192）。これにより、リモートマシンで動く Codex サーバーにローカルの TUI から接続するワークフローも可能になる。
MCP / ACP との関係
MCP（Model Context Protocol）との違い
Codex は codex mcp-server コマンドで MCP サーバーとしても動作する。ただし MCP はツール呼び出しに特化しており、以下の機能は MCP 経由では利用できない：
- ストリーミング diff
- 承認フロー
- スレッドの永続化と再接続
- Sign in with ChatGPT
使い分け：
- すでに MCP ベースのワークフローがあり、Codex を「呼び出せるツール」として使いたい → MCP
- フルのハーネス機能と UI 対応イベントストリームが必要 → App Server
ACP（Agent Client Protocol）との並立
Agent Client Protocol は Zed Industries が主導し、JetBrains もサポートする、エディタとエージェントを繋ぐ汎用プロトコル。LSP（Language Server Protocol）がエディタと言語サーバーを標準化したように、ACP はエージェント統合を標準化しようとしている。
App Server は Codex 固有のプロトコル、ACP は汎用プロトコルという位置づけで、Codex CLI は ACP 互換エージェントとしてもリストされている。OpenAI はこの領域が「急速に進化している」と認めており、今後の標準の収斂が期待される。
個人開発者が知っておくべきポイント
1. 「どこからでも同じ Codex」が使える
CLI で始めた作業を Web で確認し、VS Code で仕上げる — スレッドの永続化により、こうしたクロスサーフェスのワークフローが自然に実現する。
2. カスタムツールの組み込みが容易
App Server は MCP サーバーやスキルを統合できるため、自作のツールやワークフローを Codex エージェントに組み込める。コードレビュアー、SRE エージェント、テスト実行エージェントなど、用途に応じた特化型エージェントを構築可能。
3. オープンソースで全ソースが公開
App Server のソースコードは GitHub で公開されている。TypeScript や JSON Schema の型定義も自動生成でき、Go・Python・Swift・Kotlin など任意の言語でクライアントバインディングを作れる。
4. エージェントプロトコルの標準化は始まったばかり
App Server・MCP・ACP と、複数のプロトコルが並立している状態。LSP のように1つに収斂するかはまだ分からないが、この分野の動向を追っておくことは、AIツール統合を考える開発者にとって重要。
まとめ
Codex App Server は、AI コーディングエージェントの「フロントエンドとバックエンドの分離」を実現したアーキテクチャだ。
| ポイント | 内容 |
|---|---|
| 核心 | エージェントロジックを1つのハーネスに集約し、JSON-RPC で公開 |
| プリミティブ | Item（入出力）・Turn（作業単位）・Thread（永続セッション） |
| 対応クライアント | CLI・VS Code・Web・macOS・Xcode・JetBrains |
| 通信 | JSON-RPC over stdio（JSONL） |
| 承認 | サーバー主導の双方向承認フロー |
| MCP | 簡易統合用に併存。フル機能は App Server |
LSP がエディタの言語対応を標準化したように、App Server はエージェント統合の基盤を築こうとしている。まだ標準化途上の段階だが、OpenAI がこのアーキテクチャをオープンソースで公開したことは、エコシステム全体にとって大きな一歩だ。
参考リンク:
📝 編集部コメント