OpenAIがCodexを「分解して販売」

今回は、OpenAI がコーデックスを「分解して販売」したためです。

もともとコーデックスの背後に隠されており、エージェントの動作継続、ツールの呼び出し、コンテキストの管理、複数のエージェントの調整を行う機能セットが抽出され、すべての開発者が呼び出せるクラウド API にパッケージ化されました。

サービスとしてのコーデックス?

実際、OpenAI は長い間コーデックスを解体してきました。

OpenAI が最初に o3 と o4-mini をリリースした 2025 年 4 月には、Codex CLI をオープンソース化しました。これは、ローカル ターミナルに直接インストールされる、Claude Code の OpenAI バージョンに似ています。エージェントの実行方法とツールの呼び出し方法はすべて GitHub に明確に掲載されています。努力する意欲があれば、それを持ち帰って変更し、自分で実行することができます。

しかし当時は、物はただ配られるだけでした。それらを使用できるかどうか、およびそれらをどのように使用したいかは、依然としてあなた自身の問題です。

1 か月後、今日私たちがよく知っている製品である Codex クラウド バージョンが正式にリリースされました。ユーザーはコード ウェアハウスを引き渡すことができ、各タスクは独立したクラウド サンドボックスに対応します。 Codex は、コードを変更し、テストを実行し、バグを修正し、複数のタスクを同時に処理できます。

数か月後の 2025 年 10 月に、OpenAI は Codex SDK をリリースしました。

簡単に言うと、SDK は開発者向けのツールキットであり、Codex をスタンドアロン製品として使用できるだけでなく、他の人のアプリケーションに統合することもできます。 SDK を使用すると、開発者は数行の TypeScript コードを使用して、Codex CLI を駆動する同じエージェントを起動し、構造化された出力を取得し、タスクのステータスを保持し、一時停止後に実行を継続することができます。

ただし、SDK は主にプログラム内で Codex を呼び出すのに適しており、完全な Codex 対話機能はまだ公開されていません。バックグラウンド ワークフロー、自動スクリプト、サーバー側プログラムに非常に適しています。ただし、Codex IDE のような完全なクライアントを作成したい場合は、まだ少し難しいです。

そこで、2026 年 2 月に、OpenAI は Codex App Server を正式にリリースし、Codex のハーネスを初めて体系的に明確に説明しました。

OpenAI は、Codex Web、CLI、IDE 拡張機能、および Mac App は別の製品のように見えますが、実際にはその下で同じ Codex Harness を実行しており、エージェント ループ、スレッド、ツールの実行、認証、および管理ステータスを担当するレイヤーであると明確に説明しました。

App Server は、この完全なハーネス セットに双方向 JSON-RPC インターフェイスを追加します。 JetBrains、Xcode、またはその他のクライアントは、エージェント ループを再作成する必要はありません。 App Server を直接起動して、完全な Codex を実行できます。

App Server を使用すると、他の製品を完全な Codex ハーネスに直接接続できます。

しかし、この時点で、解決すべき最後の問題が 1 つ残っています。

SDK はローカルの Codex エージェントを制御します。また、App Server 自体も開発者によって起動および保守される必要がある常駐プロセスです。 Codex を製品に組み込むという問題は解決しましたが、オンライン サービスとして安定して実行するのはまだ少し難しいです。

より具体的な例を挙げると、App Server を使用して独自のコーディング エージェント Web サイトを構築する場合、フロントエンドは Codex に接続されていますが、ユーザーが [このウェアハウスを修復する] をクリックすると、その後に発生する多数の操作およびインフラストラクチャの問題を解決する方法を見つける必要があります。

そして8月19日がやって来ました。この日、OpenAIは過去1年間にオープンしてきたCLI、SDK、App Serverを「Open Codex Harness」というプラットフォームの物語に統合し、Codexを製品からプラットフォームに明確にアップグレードした。

そして昨日の 9 月 10 日 (米国時間) に、エージェント API が公開テストのために正式にオープンされました。

今回、開発者は、タスク、モデル、ツール、実行環境という 4 つのことを API に伝えるだけで、エージェントを直接作成できます。 Codex Harness は、長時間セッションのコンテキスト圧縮、ツールのスケジューリング、サブエージェントのコラボレーションを担当し、OpenAI 自体によってホストおよび維持されます。

エージェントが実際に動作するマシンを選択することもできます。 OpenAI のサンドボックス、独自のインフラストラクチャ、または Cloudflare、E2B、Modal などのサードパーティ環境のいずれを使用するかを選択できます。ハーネスはOpenAIによって提供され、実行環境は開発者が決定します。

公式声明は非常に明確で、エージェント API 自体には追加料金はかかりません。言い換えれば、ハーネス ホスティング、長時間セッション管理、その他の機能には、エージェント プラットフォーム料金の別のレイヤーが請求されません。

開発者は、実際に使用されたモデル トークンとツールに基づいて支払います。 OpenAI 独自のホスティング サンドボックスを使用する場合、コンピューティング リソースは別途計算されます。

OpenAI は 1 年以上にわたって同じことを行ってきました。つまり、特定の製品の Codex を層ごとに再利用可能な機能に分割することで、開発者が自分自身について心配することが少なくなるようにします。

この製品ラインに名前を付ける必要がある場合、実際には当時の SaaS に非常によく似ていますが、今回サービスされるのはソフトウェアではなく Codex である点が異なります。

サービスとしてのコーデックス。

ハーネスも分岐し始めました

もちろん、Harness に注目しているのは OpenAI だけではありません。

DeepSeek Harness (以下、DSH と呼びます) がリリースされたとき、

エージェント = モデル + ハーネスという非常に大きな方程式が与えられました。

DeepSeek の見解では、モデルはエージェントの半分にすぎず、残りの半分は環境を理解し、ツールを呼び出し、ステータスを管理し、タスクの実行を継続する役割を担うハーネスです。この 2 つが相互に連携する場合にのみ、エージェントは実際にタスクを実行できます。

DSH は、Harness 自体を高度にモジュール化されたオープン フレームワークにしました。モデル、ツール、スキル、セッション、サンドボックス、ストレージ、エージェント ループ、スケジューリング、さらには UI さえもすべて置き換えることができます。

「すべてはプラグインである」というスローガンは単なる冗談ではありません。誰もがプラグインを作成して DSH に適応することが最善です。最終的に、DeepSeek または他のモデルが上部で実行されているかどうかに関係なく、同じセットのハーネスを下部で使用できます。

これは、OpenAI が現在とっている方向性とは興味深い対照的です。

OpenAI は Codex ハーネスもオープンソース化していますが、Agents API は明らかに別の方向に進んでいます。独自のハーネスを使用することも、オープンソースのハーネスを使用することもできますが、面倒だと思う場合は、無視して私に手配させてください。

したがって、私たちはこれを「サービス」として考えています。 OpenAI は Harness のホストと継続的な保守を担当します。開発者は、エージェントに何をさせたいか、どのツールを使用するか、どこで実行するかを決定するだけで済みます。将来的にモデルがバージョンアップした場合でも、それに合わせてHarnessが変更される場合には、OpenAIも一緒にパッケージ化する準備をしています。

ハーネス レベルには、ある意味、あいまいなルートが 2 つあります。

DeepSeek が代表するルートは、オープン エコシステムを構築することに似ており、すべてのパーツを開発者が自分で組み立てられるプラグインにします。一方、OpenAI が代表する政党はクラウド サービスに賭けて資金と需要を確保するようなものです。残りの解決は私がお手伝いします。

一方は Harness をますます Linux らしくしたいと考えており、もう一方は Harness をますます AWS らしくしたいと考えているとさえ考えられます。

Of course, this is just a metaphor. OpenAI は Codex Harness もオープンソース化しており、DeepSeek が将来的にさらに多くのホスティング サービスを提供することも不可能ではありません。しかし、少なくとも現段階では、2 つの製品の焦点は明らかに異なります。

興味深いことに、Anthropic は Harness をサービスに変える点で OpenAI よりも一歩先を行っています。

2025 年 9 月には、Anthropic は Claude Agent SDK をリリースし、Claude Code の背後にあるツール、コンテキスト管理、権限システム、サブエージェント機能を開発者に公開し、他のユーザーがこのセットをエージェントとして使用できるようにしました。

今年 4 月、OpenAI よりも早く、Claude Managed Agents を開始しました。セッション、ハーネス、サンドボックスは 3 つの独立したレイヤーに分割されています。Anthropic はハーネスと長時間のタスクのホストを担当します。サンドボックスは Anthropic によって提供されるか、他の実行環境に接続できます。このアイデアは、実際には今日のエージェント API に非常に近いものです。 Anthropic 自体は、これを「長期的なエージェント タスクのためのホスティング サービス」と定義しています。

つまり、ある意味では、OpenAI は Anthropic が今回たどった道に沿って前進し続けているということになります。違いは、OpenAI にはより「製品化された」Codex があることです。

しかし、Codex と Claude Code は長い間異なる製品印象を与えてきたため、同じストーリーであっても、まったく異なる印象をもたらします。 Claude Codeは開発者がターミナルに座ってエージェントと一緒にコードを書かせているような感じですが、Codex Appは最初から「複数の長期エージェントを同時に監視する」インターフェースを重視しています。

ちなみに、Google はすでにこの路線に参加しています。今年 5 月の I/O カンファレンスで、Gemini API はマネージド エージェントを発表しました。これにより、Antigravity Harness とサンドボックスもマネージド サービスに変わりました。しかし、Google のカードはこれで終わりではありません。これについては後で説明します。

しかし、そうは言っても、誰が先かはそれほど重要ではないようです...もちろん、最終的には、ハーネスを開発者向けのデフォルト レイヤーに変えた人が一番大きなケーキを食べることができるでしょう。

大勝者は誰ですか?

結局のところ、なぜ今、モデル会社が Harness を買収し始めているのでしょうか?

DSH によって与えられる方程式 (エージェント = モデル + ハーネス) と同様に、モデルはエージェントに次に何をすべきかを指示できますが、実際にタスクを最初から最後まで実行するには、ファイルがどこにあるのか、どのツールを呼び出す必要があるのか​​、エラー発生時の回復方法、結果が最終的にどこに書き込まれるのかを把握する必要があります。

言い換えれば、モデルがエージェントの能力の上限を決定し、ハーネスがジョブを完了できるかどうかを決定します。

競争の次元が「インテリジェンス」から「実行」に移行すると、最も優位に立つのは最良のモデルを備えた AI 企業ではなくなる可能性があります。

エージェントが実際に動作を開始した後、エージェントに必要なもの (電子メール、文書、会議、コミュニケーション、アカウント権限など) は多くの場合、従来のプラットフォーム企業の手に渡ります。

最近中国で激化している「オフィス エージェント戦争」は、実際には非常に典型的な例です。インターネット プラットフォームの時代に大企業が蓄積したものは、どちらかというとそれぞれのエコシステムの機能の一部にすぎませんでしたが、エージェントの時代では、これらのものはたまたまエージェントが実際に作業するときに呼び出す必要があるツールになります。

今では誰もがオフィスエージェントとして働いています。表面的には、彼らは他の AI 従業員よりも賢く、有能です。実は舞台裏では、過去に蓄積したプラットフォームのアドバンテージを再利用しているのです。より多くの企業データ、ドキュメント、ツール、権限を持っている人は、エージェントに作業を任せやすくなります。

モデル企業は、自社が持っていないポータルにアクセスする必要があります。オフィス ソフトウェアやインターネット プラットフォームを 10 年以上製造している企業は、すでにこれらのポータルを持っています。

言い換えれば、

AI 企業は現実世界との再接続を望んでおり、プラットフォーム企業はすでに大量の鍵を手にしています。

この道に沿って見て、最も有利な「ファミリーバケット」プレーヤーを見つけなければならないとしたら、おそらく Google が最も誇張されたプレーヤーでしょう。

TPU、クラウド インフラストラクチャ、Gemini から検索、ワークスペース、Chrome、Android に至るまで、Google は基盤となるテクノロジーからエンド ユーザーに至るまで、AI の主要な側面のほぼすべてをカバーしています。検索、Gmail、カレンダー、ドライブ、YouTube、マップ、その他の製品は、エージェントが呼び出すことができるデジタル環境を自然に形成します。これらの資産は、前世代のインターネットでは独立したポータルでしたが、エージェント時代では同じタスクに再編成できます。

実際、Google は、さまざまな製品に散在するエージェント機能を、下部の同じ実行システムに統合し始めています。 Gemini Spark、Gemini API の管理対象エージェント、さらには検索の一部のエージェント エクスペリエンスでさえ、その背後にある同じ反重力ハーネスを徐々に共有しています。

しかし、ユーザー側では、状況はまだ少し厄介です。

現在、Google の検索には、Gemini Spark、Workspace Studio、Antigravity、Gemini Enterprise、および Information エージェントも含まれています。直面するユーザーやシナリオは異なりますが、一般の人にとって、複雑な問題を Google に引き継ぎたい場合、誰に頼ればよいのかはまだわかりません。

Google の場合、これらすべてを達成するために必要な条件のほとんどがすでに揃っています。欠けているのは、十分にシンプルな製品の答えです。

そして、Google がこの問題を本当に理解すれば、統合されたエージェント ワークベンチを作成するか、同じエージェント実行システムを Google エコシステム全体に浸透させて、ユーザーが「問題が発生したときに Google を見つける」ことに慣れられるようにするかにかかわらず、世界のエージェント市場の競争環境はおそらく再び変わるでしょう。

とはいえ、Google が実際にこの「ファミリー バケット」をエージェントに追加したとしても、国内ユーザーは最初にのみ視聴できる可能性が高くなります。

まず国内エージェント戦争を見て、次にどのように戦うのかを見てみましょう。