開発ツールのワークフローが立体的につながる抽象ビジュアル
NAW / PRODUCTS 03

IMAGE: AI生成ビジュアル

PRODUCTS / PRODUCTS

OpenAI、Codexのエージェント実行基盤「Codex harness」をオープン化 — アプリに組み込むプラットフォームとして公開

Webアプリ/CLI/IDE拡張を支える同一のエージェントループをオープンソースとして公開。会話状態・ツール呼び出し・サンドボックスと承認ポリシー・ターン間の継続実行を担い、Codex app-server経由でアプリ側のUIやMCPツールと結合できる。

OpenAIは2026年8月21日、開発者向けブログ「Codex as a platform: build on the open agent harness」を公開し、コーディングエージェントCodexを支える実行基盤Codex harnessをオープンソースとして提供すると発表した。多くの利用者が知るCodexのApp/CLI/IDE拡張は、いずれも同一のハーネス上で動いており、同社はこの「エージェントループ」をアプリケーションに組み込めるプラットフォームとして開放する方針を示した。

アプリケーションがUIとビジネス文脈を所有し、Codex app-serverがエージェントループとサンドボックス実行を提供するアーキテクチャ図 出典: Codex as a platform: build on the open agent harness — OpenAI Developers (2026-08-21) Figure 1 画像クレジット: OpenAI

再利用されるのは“エージェントループ” — ハーネスが変える成果

OpenAIによれば、有能なエージェントはプロンプトとモデル応答だけでは成立しない。タスク理解、文脈の保持、関連情報の調査、ツール呼び出し、進捗の可視化、失敗時の処理、必要に応じた人間の承認要求、そして有用な結果の返却までを含む「周辺の実行システム」が不可欠で、これが**ハーネス(harness)**だ。

  • ハーネス設計が成果を左右する: 例としてARC-AGI-3では、推論の保持と文脈圧縮の改善によりGPT-5.6 Solのスコアが13.3%から38.3%へ向上しつつ出力トークンは約6分の1に削減されたとしている(同社ブログの記述による)
  • Codex harnessの責務: 会話状態の管理、実行のストリーミング、ツール利用、設定されたサンドボックスと承認ポリシーの強制、ターン間の作業継続を担う
  • Codex app-serverで公開: アプリはスレッド生成・ターン開始・イベント受信・承認要求の処理を文書化されたクライアントプロトコル経由で行える
  • オープンソースの範囲: ハーネスと統合面がオープンソースであり、モデルアクセスやマネージドサービスは別に提供される

同社は、エージェントを汎用チャット窓に閉じ込めるのではなく、既存のダッシュボードやエディタ、キュー、地図、レコード、承認フローといったプロダクト固有の界面にエージェントを連れてくる発想を強調している。

3つの統合レイヤーとサンプル「Relay」 — アプリ側が文脈とツールを所有

Codexで構築する際、用途ごとに適切な統合レイヤーを選べるとしている。あわせて、輸送オペレーションを想定したサンプルアプリRelayで統合パターンを示した。

  • codex exec: スクリプト、CIジョブ、単発のバックグラウンドタスクなど、区切られたエージェントワークフローを実行して構造化出力を返す用途
  • Codex SDK: アプリケーションコードからCodexタスクを開始・再開・ストリーミングしたい場合のプログラム的インターフェース
  • Codex app-server: エージェントをプロダクトの一部として組み込む場合。ローカルCodexプロセスに接続し、会話を維持、イベントをストリーミング、作業を中断、ツールを公開、承認要求を処理できる。SDKが定型ワークフローを簡素化するのに対し、app-serverはライフサイクルとUXを直接制御できる

Relay — 輸送オペレーションのダッシュボードにCodexを埋め込み、アプリ所有のMCPツールと人間承認で例外対応を支援する例 出典: Codex as a platform: build on the open agent harness — OpenAI Developers (2026-08-21) Figure 2 画像クレジット: OpenAI

Relayでは、ユーザーは一からプロンプトを書くのではなく、配送を選択して「Compare recovery」などのアクションを押す。アプリが関連文脈を供給し、Codexが最新のサンプル業務データを取得、選択肢を説明し、影響の大きい書き込みは承認を経て実行する。基盤レコードが変更されればアプリ側の業務ビューが更新される。ハーネスがエージェントループと会話状態、ストリーミング、ツール連携を担い、プロダクト側がダッシュボードや記録、統制を所有し続けるという分担が核だ。

既存の採用例と始め方 — オープン化の位置づけ

ブログでは、このパターンがすでに公開実装で現れているとして、以下の事例を挙げた。

  • GitHubとJetBrains: 既存IDEワークフローにCodexを取り込む
  • Cisco: Cisco Cloud Control内のApp BuilderでCodex SDKを利用
  • Thrive HoldingsとCrete: 実務者のフィードバックを取り込む税務ワークフローでCodexを利用。パイロットで7,000件の申告を処理し、準備時間を約3分の1削減したとしている(いずれも一次情報の記述による)

同社は、支援やオペレーション、セキュリティ、営業、マーケティングなど、ダッシュボードやタイムライン、地図、文書、システムレコードといった「実際の仕事の文脈」が宿る界面にエージェントを与えることで、汎用チャットへの置換ではなく界面自体を強化する機会があると位置づける。開発者が始める際は**open-source Codex repository**を起点に、用途に応じて codex exec/Codex SDK/Codex app-serverを選ぶ構成を推奨している。

一次情報にベンチマーク比較画像(他モデルとの性能チャート)は掲載されておらず、本記事では図表の代わりに一次情報の説明図2点を掲載した。モデル性能の数値的優劣を断定するものではなく、実行基盤としてのハーネスの役割と統合方法を整理した内容として扱いたい。

出典