AIエージェントの組み込み、OpenAIはループを渡し承認を残す

OpenAI Developers, “Codex as a platform: build on the open agent harness”（developers.openai.com/blog、2026年9月15日時点の頁の内容。頁に公開日は示されていない）。作った側が公開されたハーネスを組み込みの土台として位置づける文章である。ハーネスのリポジトリはgithub.com/openai/codexで、GitHub APIの記録では2025年4月13日に作られ、2026年9月15日の時点で124,061のスターと19,132のフォークを持つ（api.github.com/repos/openai/codex の created_at・stargazers_count・forks_count）。頁はそれまでの作法と自分の答えを「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」と書き、公開の理由を「Because the harness is open source, you can inspect the layer between your application and the model, understand how it behaves, and adapt the integration to fit your product.」と書く。分担については、アプリが「product context, business rules, and tools」を持ち、「Codex app-server provides the agent loop and sandboxed execution」と述べ、アプリが手元に残すものとして「dashboards, editors, queues, maps, records, and approval flows」を挙げる。公開されている部品として頁が名指すのはCodex CLI、Codex app-server、公式のCodex SDKの三つで、続けて「open-source components guide」を指す。頁の図（Figure 1）は、alt文で「Codex app-server agent loop and sandboxed execution」と「application-owned interface, business context, and consent」を書き分け、目視ではapp-serverの箱に「Sandboxed execution: Filesystem · network · runtime approvals」、アプリの箱に「Business rules & consent: Allowed actions · human decisions」を置く。ループについて頁は「The reusable part is the agent loop」と見出しを立て、「you can start with Codex instead of inventing a new runtime, then decide what the surrounding application should own」と書くが、作る難しさの序列は書いていない。頁は公開の範囲を「The open-source layer is the harness and integration surface; model access and managed services remain separate.」と自分で区切っており、本稿はこの一文に重みを置く。頁が挙げる公開実装は三つ（GitHubとJetBrains、Cisco、Thrive HoldingsとCrete）で、数値を伴うのは Thrive HoldingsとCrete の税務申告の試行が「processed 7,000 returns and reduced preparation time by about a third」と書かれる一件だけである。三つのうち app-server を使うと頁が書くものは無く、app-server の例は頁自身が架空データで作ったサンプル Relay である。これらは頁自身の例であり、本稿は主張の根拠には使わない。頁は位置づけと分担を述べる文章で、ハーネスの挙動を自分で測ってはいない。ただし「Harness design can materially change results」と書き、ARC-AGI-3 で retained reasoning と context compaction が GPT-5.6 Sol の得点を 13.3% から 38.3% へ上げたとする OpenAI 自身の別記事を数値ごと引いている。https://developers.openai.com/blog/codex-as-a-platform ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹

Codex App Server protocol documentation（learn.chatgpt.com/docs/app-server、2026年9月15日時点の頁の内容）。目的を「Embed Codex into your product with the app-server protocol」と書き、同じプロトコルが「the interface Codex uses to power rich clients (for example, the Codex VS Code extension)」と述べる。やり取りは「bidirectional communication using JSON-RPC 2.0 messages」で、経路は標準入出力（改行区切りのJSON）、WebSocket、Unixソケットである。要求はmethod、params、idを持ち、応答は同じidにresultまたはerrorを載せ、通知はidを持たない。三つの型は、ターンを含む会話であるスレッド、ユーザーの一つの依頼とそれに続くエージェントの作業でアイテムを含むターン、メッセージ・コマンド・ファイル変更・道具の呼び出しといった入出力の単位であるアイテムである。流れは、接続ごとに一度の初期化、スレッドの開始または再開、ユーザー入力によるターンの開始、ターン完了までのthread/*、turn/*、item/*の通知の読み取りである。文書は分担を一覧にはせず、要求の向きで示す。承認は「The app-server sends a server-initiated JSON-RPC request to the client, and the client responds with a decision payload.」であり、動的な道具の呼び出しは「item/tool/call as a server request to the client」、追加の権限は「item/permissions/requestApproval (server request)」で、いずれもサーバからクライアントへ向く。「agent loop」の語は文書に無い。承認は「Depending on a user’s Codex settings, command execution and file changes may require approval.」と条件つきで、隔離は「Use sandboxPolicy.type = "externalSandbox" if you already sandbox the server process and want Codex to skip its own sandbox enforcement.」と、ホストの側で行う道がある。動的な道具は「dynamicTools on thread/start and the corresponding item/tool/call request or response flow are experimental APIs.」で、実験的なAPIは「Omit capabilities (or set experimentalApi to false) to stay on the stable API surface, and the server rejects experimental methods/fields.」と既定では拒否される。文書は自分の限界も書く。「The app-server command and WebSocket transport are experimental and aren’t supported for production workloads.」文書はプロトコルの形と分担を述べるもので、クライアントが承認の判断をどう実装するか、サンドボックスがどの範囲を隔離するかの測定は含まない。https://learn.chatgpt.com/docs/app-server ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹

Yilun Yao, Xinyu Tan, Chao-Hsuan Liu, Yaoming Li, Zhengyang Wang, Wenhan Yu, Zhewen Tan, Yuxuan Tian, Guangxiang Zhao, Lin Sun, Xiangzheng Zhang, Tong Yang, “Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows”（arXiv:2605.27922、2026年5月27日投稿）。ハーネスが結果に何をするかを説明するために引く論文である。ハーネスを「the system layer that manages context, tools, state, constraints, permissions, tracing, and recovery」と定義する。本稿が引く数字は要旨と、Table 2 の Codex の行（総合 80.4）と、Figure 3 右の値ラベル（GPT-5.4 を載せた構成型ハーネス六本の 0.5432〜0.8132）によるもので、Table 2 の Score 列は 8 バックエンド平均（52.4〜76.2）なので別の数である。Codex 80.4 は著者らが「制御されたハーネスの切り分けではなく実用上の参照点」と断る値——逐語 Codex is included as a practical reference point rather than a controlled harness ablation——で、論文は Codex を既定のモデル構成の下で、独自の実行インタフェースを持つ専用スタックとして測ったと書き、呼び出しの経路は書いていない（app-server の語は無い）。論文は、106のサンドボックス化されたオフライン課題における5,194の実行軌跡を対象に、「substantial variation in completion, process quality, efficiency, and failure behavior across model-harness pairings」を観察したと述べ、エージェントの能力は基盤モデル単独に帰すのではなく、モデルとハーネスの構成の単位で報告すべきだと結論する。論文は自分の限界として、制御されたサンドボックス化されたオフラインの作業に焦点を絞り、そのぶん稼働中のサービス、ユーザーからのフィードバック、変化する外部状態、長期の本番メモリを扱っていないと述べる。本稿の主張に当てると、ループとサンドボックスを第三者のハーネスへ渡すということは、製品の完了と失敗の振る舞いがそのハーネスに依存するということであり、読者は自分のアプリだけをハーネスから切り離して測れない。https://arxiv.org/abs/2605.27922 ↩ ↩² ↩³ ↩⁴

Yunbei Zhang, Janet Wang, Yingqiang Ge, Weijie Xu, Jihun Hamm, Chandan K. Reddy, “Stop Comparing LLM Agents Without Disclosing the Harness”（arXiv:2605.23950、2026年5月7日投稿）。著者ら自身が立場論文と名乗るが、SWE-bench Verified から層化抽出した100課題で3モデル×3ハーネスを各2回走らせる制御実験を含む。Table 2 はハーネス由来の分散がモデル由来の分散の 7.80 倍、順位の逆転が9組中6組と報告する。主張は「for long-horizon tasks evaluated across models with comparable frontier capability, the agent execution harness … is often a stronger determinant of agent performance than the model it wraps」で、「harness-induced variance can substantially exceed model-induced variance, including cases of model ranking reversal」と述べ、開示の基準を伴うハーネスを意識した評価の枠組みを提案する。本稿の主張に当てると、自分で書いていないハーネスを組み込んだチームは、結果をアプリとハーネスの組として報告することになり、自分の側に変更がなくてもハーネスの更新が結果を動かすと見込んでおくことになる。本稿はこれを、報告の作法についての提案と、その提案を支える小規模な実測として引く。https://arxiv.org/abs/2605.23950 ↩ ↩² ↩³ ↩⁴

OpenAI, “Open Source”（learn.chatgpt.com/docs/open-source、2026年9月15日時点の頁の内容。developers.openai.com/codex/open-source から転送される）。「Codex as a platform」の頁が「open-source components guide」として指す案内である。表「Open-source components」はCodex CLI、Codex SDK、Codex Security CLI、Codex Security TypeScript SDK、Codex App Server、Skills、Plugins、Universal cloud environmentの八つにGitHubの所在を示し、IDE extensionとCodex cloudの行は「Not open source」と書く。本稿の主張に当てると、app-serverが動かしていると文書が書くVS Code拡張の側は公開されておらず、読者が読める線はサーバ側で止まる。https://learn.chatgpt.com/docs/open-source ↩

Agent Client Protocol, “Introduction” / “Protocol Overview” / “Agents” / “Clients”（agentclientprotocol.com、2026年9月20日時点の頁の内容）。「The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents」と書き、「The protocol follows the JSON-RPC 2.0 specification」で、プロンプトのターンでは「Agent → Client: File operations or permission requests as needed」、権限の要求は session/request_permission（「Request user authorization」）である。Agents の頁は Codex CLI（ACP のアダプタ経由）、Claude Agent（Zed の SDK アダプタ経由）、Gemini CLI、GitHub Copilot（public preview）、Junie by JetBrains を含む一覧を置き、Clients の頁は JetBrains を Editors and IDEs に置く。射程は「ACP assumes that the user is primarily in their editor」と自分で区切る。本稿はこれを、第三の型の約束事が OpenAI の外にも在ることの地図として引き、採用の多寡の根拠には使わない。https://agentclientprotocol.com/overview/introduction https://agentclientprotocol.com/protocol/overview https://agentclientprotocol.com/overview/agents https://agentclientprotocol.com/overview/clients ↩ ↩² ↩³