8月19日、OpenAIは開発者ブログに「Codex as a platform」と題する記事を公開し、Codexの位置付けを「ターミナルで動くコーディングアシスタント」から「誰もがその上に直接構築できるオープンソースの実行層」へと転換した。
記事は冒頭で、見落とされがちな事実を明かしている。大半のユーザーはデスクトップアプリ、コマンドライン、あるいはIDEプラグインを通じてCodexを知っているが、この3つの入口は同一の基盤システムを共有しており、そのシステムはすでにGitHub上に公開されている（リポジトリはopenai/codex、Apache 2.0ライセンス、現時点でスター数10万9000）。今回OpenAIが行ったのは位置付けの再定義であり、「自社製品の実装の一部」から「あなたたちの土台」へと書き換えたことになる。
モデルを取り巻く層
OpenAIはこの仕組みを「harness」という言葉で呼んでおり、その定義は極めて簡潔だ。
"That surrounding execution system is the harness."
分解すると、その役割はコンテキストの収集、タスクを実行可能なステップへの分解、ターン間でのセッション状態の維持、ツール呼び出し、設定済みのサンドボックスと権限境界内での実行、人間の判断が必要な場面での承認待ちの一時停止、そして最終的な結果のビジネスシステムへの引き渡しまで多岐にわたる。これらはいずれもモデルの重み自体とは無関係だが、その出来栄えがベンチマークのスコアを直接左右する。OpenAIは記事内で7月末の自社ARC-AGI-3データを引用している。harness層で「推論の保持」と「コンテキスト圧縮」という2つのスイッチをオンにするだけで、GPT-5.6 Solの公開評価スコアは13.3%から38.3%に上昇し、出力トークンは約6分の1に減少したという。モデルは変えていない、変えたのはその周りの層だ。
侵襲度別の3段階の統合方式
OpenAIは統合方式を明確に3段階に分け、開発者が用途に応じて選べるようにした。すべてをチャット画面に押し込む必要はない。
codex execはスクリプト、CIタスク、一回限りのバックグラウンドジョブ向けで、境界の定まったエージェントフローを実行し、構造化された結果を返して終了する。Codex SDKは、コード内からCodexタスクを開始・再開・ストリーミング読み取りする必要があるアプリケーション向けだ。Codex app-serverは最も侵襲度の高い方式で、アプリケーションがローカルのCodexプロセスに接続し、セッションを常時開いたまま維持し、イベントストリームを受信し、いつでも割り込み、エージェントに自前のツールを公開し、承認リクエストの処理を引き受ける。
app-serverの使い方を説明するため、OpenAIはRelayという架空の貨物異常処理コンソールのデモアプリを用意した。ユーザーはプロンプトを書かず、まず対象の貨物を選択し、「Compare recovery」といったボタンをクリックする。アプリが関連コンテキストを渡すと、Codexはアプリ自身が接続したMCPツール経由で最新データを取得し、選択肢を説明する。実際に予約を変更する際は必ず人間の承認を経る必要があり、書き込み処理がデータベースに反映された後、アプリが自身の業務ビューを更新する。
この設計思想について記事は率直に述べている。汎用のチャット画面でディスパッチボード、タイムライン、地図、チケット画面を置き換えるべきではない。それらのUIは、人間が現場を理解し、判断を下し、コントロール感を保つためにこそ存在するからだ。
すでに製品に組み込んだ企業
OpenAIは3つの公開事例を挙げている。GitHubとJetBrainsはそれぞれのIDEワークフローにCodexを組み込んだ。Ciscoは自社のCloud Control内のApp BuilderでCodex SDKを利用している。Thrive HoldingsとCreteは税務申告プロセスにCodexを導入し、試験導入段階で7000件の申告を処理、申告準備時間を約3分の1削減した。
最後のこの数字は具体性がある。税務申告は反復性が高く、許容できるミスが少なく、規制も厳しい典型的な領域であり、試験導入の規模と比較可能な効率指標を示せることは、「生産性が大幅に向上した」といった曖昧な表現よりもはるかに有用だ。OpenAIはまた、このパターンがエンジニアリングチームだけのものではないと強調する。カスタマーサポートのトリアージ、オペレーション調整、セキュリティインシデントの重大度判定、営業の与信調査もすべて同じ形をしている。アプリケーションがコンテキスト、ツール、承認プロセスを提供し、Codexがそのループを担う。
オープンソース化の範囲
記事中には下線付きで強調された一文がある。オープンソース化されるのはharnessと統合面であり、モデルへのアクセスとホスティングサービスは別料金のままだという。
この一文を3段階の統合方式と合わせて見ると、OpenAIの取捨選択がはっきりする。実行層は無料で提供され、監査可能で改造も自由、誰でも自社製品に組み込める。しかし、エージェントのループが1回動くたびに、トークンは依然としてOpenAIのAPIを通過する。オープンソース部分が使いやすくなり、組み込まれる製品が増えるほど、モデル側の呼び出し量は増えていく。これはAnthropicがMCPによってツール統合を事実上の標準にしたのと同じ種類の戦略だが、今回OpenAIが手放すものはより重い。ランタイム全体を差し出したのだ。
中国国内でエージェント製品を開発するチームにとって、すぐに得られる恩恵は重複作業を省けることだ。セッション状態、イベントストリーム、ツール呼び出し、承認による中断といった仕組みは、多くのチームがすでに自前で書いた経験を持ち、書いた後も調整を重ねてきたはずだ。今回、大規模に検証済みで一行ずつ読める実装が参照先として加わったことになる。ざっと試算すると、harness層の変更だけで出力トークンを6分の1に圧縮できるなら、同じ予算でさらに5回多く実行できる。この計算だけでも、多くのチームがソースコードを真剣に読む価値がある。
代償も明らかだ。統合が深くなるほど、OpenAIの課金モデルへの依存も強まる。特にapp-serverの段階でそれが顕著で、これはもはや単なるAPI呼び出しの関係を超えており、相手のプロセスを自社製品の中に招き入れるに等しい。
参考資料：OpenAI開発者ブログ「Codex as a platform」、CocoLoop、GitHubリポジトリopenai/codex（ライセンス、スター数、3段階の統合方式はリポジトリと公式ドキュメントで確認。ARC-AGI-3のスコアおよびトークン削減幅はOpenAIの自己申告値）。