AIエージェント

Codex app-serverとは：承認をアプリに残す組み込みの仕組み

2026/9/21 （更新: 2026/10/14）

🤖 AIを使用して執筆

承認はサーバからクライアントへの要求として置かれ、ループとサンドボックスは向こう側にある

OpenAIは企業で、Codexはその製品であり、OpenAIが公開しているハーネスはopenai/codexリポジトリにあって¹、2025年4月13日に作られた⁵。本稿は組み込みの作法を三つに分ける。エージェントのループを自分で書く型、仕事のほうを汎用のアシスタントへ移す型、そして公開ハーネスのループをプロトコル経由で組み込み、自分の画面を保つ型である。Codex app-serverは第三の型に属する。本稿がCodex app-serverを選んだのは、作った側が分担とその理由を自社の開発者向けサイトに書き、プロトコルを文書にし、ハーネスのリポジトリを公開していて、読者が自分で読めるからである¹²。第一の型では線引きはチームの内部にあり、第二の型ではアシスタントの内部にあって、どちらも外から読めない。第三の型は、線引きを二つのプログラムの間の約束事として書き出すので、読者は線がどこにあるかを文書から確かめられる。

OpenAIの開発者向けサイトにある「Codex as a platform」の頁は、2026年9月15日の時点で、公開されたハーネスを組み込みの土台として位置づけている。頁に公開日は示されていない¹。分担は作った側の言葉でこう置かれる。アプリが持つのは「product context, business rules, and tools」、つまり製品のコンテキストと業務規則とツールである。「Codex app-server provides the agent loop and sandboxed execution」、つまりapp-serverがエージェントのループとサンドボックス化された実行を提供する。アプリが手元に残すものとして頁は「dashboards, editors, queues, maps, records, and approval flows」を挙げる。ダッシュボード、エディタ、キュー、地図、記録、そして承認の流れである¹。頁がこの文で挙げる公開部品はCodex CLI、Codex app-server、公式のCodex SDKの三つで、頁が併せて指す公開部品の案内は十の部品を表にし、八つに所在を示して、IDE拡張とCodex cloudは公開していないと書く¹⁶。

同じ線は、プロトコルの文書では要求の向きとして現れる。文書は目的を「Embed Codex into your product with the app-server protocol」と書き、同じプロトコルがVS Code拡張のようなクライアントを動かしていると述べる²。やり取りの形は「bidirectional communication using JSON-RPC 2.0 messages」、JSON-RPC 2.0のメッセージによる双方向通信である。JSON-RPCとは、呼び出したいメソッドの名前と引数をJSONで送り、結果を同じ形式で受け取る、遠隔呼び出しの約束事を指す。プロトコルは、会話をスレッド、一つの依頼とそれに続く作業をターン、入出力の単位をアイテムと呼ぶ三つの型で会話の形を固定する。クライアントは接続ごとに一度初期化し、スレッドを開始または再開し、ユーザーの入力でターンを始め、ターンが完了するまで通知を読み続ける²。

分担はここで線になる。プロトコル文書は分担を一覧にはしないが、コマンド実行とファイル変更の承認、動的なツールの実行、追加の権限は、いずれもサーバがクライアントへ送る要求であり、クライアントが決定や結果を返す²。ループとサンドボックス化された実行をapp-serverが提供する、というのは作った側の頁の図の言葉である¹。したがって承認の判断はクライアント側にあり、ループとサンドボックスはサーバ側にあって、線はその間を通る。ただし線の位置は固定ではない。承認は利用者の設定次第で要求され、隔離もホストが自前で行うならapp-serverの強制を省く設定（externalSandbox）がある²。どちらも、クライアントがスレッドやターンを始めるときに渡す設定で変えられる。ただし、管理者が置く要件（requirements.toml や MDM から読まれる）には、許す承認の方式とサンドボックスの種類を並べる欄もある²。

作った側の頁の図は承認を二つに分けて描き、app-serverの箱には「runtime approvals」が、アプリの箱には「human decisions」がある¹。承認を求める仕掛けはサーバ側にあり、決める判断はアプリ側にある。頁はまた、どのファイルやツールに触れさせ、どの操作に承認を求めるかを、組み込む側のアプリが決められると書く¹。

仕事ではなくエージェントを動かす、という作った側の一文

作った側は、それまでの作法と自分の答えを一文で書く。「Instead of asking every team to move its work into a general-purpose coding assistant, you can bring the agent into software designed around the actual job」¹。すべてのチームに仕事を汎用のコーディングアシスタントへ移すよう求めるかわりに、実際の仕事に合わせて設計されたソフトウェアの中へエージェントを持ち込める、という意味である。向きは、仕事を動かすことではなく、エージェントを動かすことにある。

自作の型に対しては、頁は「再利用できる部分」という見出しでループを挙げ、新しい実行系を発明するかわりにCodexから始めて、周りのアプリが何を持つべきかをそのあとで決めればよいと書く¹。作る難しさの序列は頁に無く、ループがもっとも難しく製品固有の中身をもっとも含まないという判断は本稿のものである。公開する理由も同じ頁が書く。ハーネスが公開されているので、アプリとモデルの間にある層を検査し、その振る舞いを理解し、統合を製品に合わせて調整できる、という¹。

完了率は他人のハーネスに依存し続け、実験的という制約は文書の現在の状態

第一の代償は、ループとサンドボックスを外から受け取るということが、製品の完了率と失敗の振る舞いを、チームが書いていないハーネスに依存させることである。作った側の頁自身が、ハーネスの設計は結果を大きく変えうると書き、その例として自社の ARC-AGI-3 の得点が 13.3% から 38.3% へ動いた別記事を引いている¹。

Yaoらは、ハーネスを「コンテキスト、ツール、状態、制約、権限、追跡、回復を管理するシステム層」と定義し、要旨によれば、106のサンドボックス化されたオフライン課題で5,194の実行軌跡を集め、モデルとハーネスの組み合わせによって完了、過程の質、効率、失敗の振る舞いが大きく変わると観察した。同じ論文は Codex そのものも既定構成で106課題すべてに走らせ、参考値として別枠で報告している——GPT-5.4 を土台にした総合得点は 80.4 で、同じモデルを載せた構成型ハーネス六本の幅は 54.3 から 81.3 だった³。論文はまた、強い基盤モデルほど平均の得点が高く、ハーネスを替えたときの得点の分散が小さい傾向も報告しており、著者らはこの傾向も含めて、エージェントの能力は基盤モデル単独に帰すのではなく、モデルとハーネスの構成の単位で報告すべきだと結論する³。

Zhangらは立場論文で、長期のタスクを同程度の最前線能力を持つモデルの間で比べる場面では、エージェントの実行ハーネスがそれの包むモデルよりも強く性能を決めることがしばしばあると主張する⁴。同じ論文は、コーディングの順位表で得点の近い3モデルと、コンテキストの圧縮、再試行、検証と回復の仕掛けを段階的に足した3ハーネスを、SWE-bench Verified の100課題で走らせ、ハーネス由来の分散がモデル由来の 7.80 倍だったと報告している⁴。著者らは、この比が普遍だとは主張していない⁴。

どちらもあらかじめ用意された課題で測った数であり、承認の手順を持つ業務アプリを測ったものではない。この二本を本稿の主張に当てると、ハーネスを組み込んだチームは、結果をアプリとハーネスの組として報告することになり、自分の側に変更がなくても、ハーネスの更新が結果を動かすと見込んでおくことになる。この代償は、ループを外から受け取るという型そのものから出るので、文書が整っても消えない。

第二の代償は文書の現在の状態であり、型に内在するものではない。作った側自身が、app-serverコマンドとWebSocketの経路は実験的で、本番の作業には対応しないと文書に書いている²。クライアント側でツールを走らせる動的なツールの流れも、既定では拒否される実験的なAPIである²。作った側の頁は、app-serverを選ぶ理由の中にアプリがツールを渡せること（expose tools）を挙げる一方で、アプリが持つツールの例として挙げるのはアプリが所有するMCPサービスである¹。

第三は代償というより公開の範囲の限界で、線の位置とは別に決まっている。「The open-source layer is the harness and integration surface; model access and managed services remain separate.」公開されている層はハーネスと統合面であり、モデルへのアクセスと管理されたサービスは別に残る¹。検査できるという性質はモデルの境界で止まる。これは作った側の事業上の決定であり、頁はそれを一文で明示している。

承認を手元に残す線は、作った側の製品と研究の測り方に現れ、組み込む側の採用はまだ読めない

方向は、本稿の出典が届く範囲で二つの側から読める。作った側は、公開したハーネスを組み込みの土台と位置づけ、自社のVS Code拡張を同じプロトコルで動かしている¹²。研究の側は、ハーネスをモデルと別の層として定義して測り、結果をモデルとハーネスの組で報告するよう求めている³⁴。ループと隔離を製品から切り離して扱う見方は、作る側と測る側の両方に現れた。同じ形の約束事はOpenAIの外にもある。Agent Client Protocolは、エディタとコーディングエージェントの間をJSON-RPC 2.0で結び、権限の要求をエージェントからクライアントへの要求として置く公開のプロトコルである⁷。エージェント側にはCodex CLI（ACPの側のアダプタ経由）、Gemini CLI、GitHub Copilot、JetBrainsのJunieなどが、クライアント側にはJetBrainsなどが載る⁷。ただしこのプロトコルは、利用者が主にエディタの中にいることを想定すると自分で書いており、業務アプリへの組み込みをどれだけ担っているかは、その一覧からも読めない⁷。OpenAIの頁は公開実装としてGitHubとJetBrains、Cisco、Thrive HoldingsとCreteの三つを挙げるが、app-serverを使うと書かれたものは無い¹。頁がapp-serverを土台にした例として示すのは、OpenAI自身が架空の出荷データで作ったサンプル一つで、出荷を手配し直す前に人の承認を求める¹。本稿は、どちらも採用の根拠には使わない。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。