OpenAIのCodexとBedrock経由のCodexは別物だと考えた方がいいかもしれないよって話

モデルが同じでもハーネスが違えばエージェントの性能が大きく異なることはすでによく知られている（例えば Cursor などがハーネスによるエージェント性能の違いについて報告している）。

で、このハーネスには Responses API に代表されるモデル周りの機能群も含まれていて、OpenAI-hosted の Responses API と LM Studio などが提供する「Responses API 互換」は別物なので、それによって構成されるハーネスも別物だと考えた方が良さそうだ、というのが今回の主論である。

どういうこと？って思う人が多いかもしれないので、以下で詳細を説明する。

2026年1月に OpenAI は、Responses API をベースとしたオープンソース仕様「Open Responses」を公開した。LM Studio などは、この仕様や OpenAI 互換の /v1/responses を実装している。これにより、OpenAI にも LM Studio にも同様の JSON Schema で LLM モデルにアクセスすることができる。

ただし、API の構造が同じだからといって、その裏側の実装まで同じというわけではない。具体的には、モデルが使用する一部ツールの実装などは、各プロバイダ側に委ねられている。

プロバイダ側の実装に依存する要素はツールだけではなく、それら Responses API 周りの機能群は、AI エージェントにおいてモデルと外側のハーネス（例: Codex の OSS 部分）とを繋ぐ、目に見えない「内側のハーネス」と便宜上位置付けることができる。

この内側のハーネスにどのようなものがあるか、Codex に調べてもらった（一部を抜粋）↓

内部推論状態の維持・再利用やコンパクションは OpenAI-hosted Codex の性能に少なからず寄与していると考えられており、この中でも特に重要な機能だと考える。

<内部推論状態の維持・再利用>

少なくとも OpenAI-hosted の Responses API では、内部の推論状態を永続化することができる（生の推論内容を外に取り出すことはできないらしい）。モデルは以前のターンで生成された互換性のある推論内容をコンテキストに反映させることができる。これはモデルが以前考えていた内容を必要に応じて再利用できることに繋がり、エージェントの能力向上に寄与することが予想できる。

<コンパクション>

OpenAI-hosted の Responses API が提供するコンパクションはただの文章要約ではなく、過去のメッセージ、推論、ツールコールなどを圧縮した、より少ないトークンで構成された特殊なアイテムを返す。このコンパクション機能が優秀だからこそ、OpenAI-hosted の Codex はコンパクションを経由しても重要なコンテキストの消失が少なく、ロングタスクに秀でたエージェントとなっている。

で、ここからが本題だが、Bedrock の Codex はたとえ OpenAI の GPT モデルを使っている場合でも、OpenAI-hosted の Responses API を経由しない。

Amazon Bedrock 版 ChatGPT Work / Codex に関する OpenAI の公式ドキュメントに以下の記述がある。

When you configure a local ChatGPT Work or Codex surface with Amazon Bedrock as the model provider, the OpenAI-hosted Responses API isn’t in the request path. The local client sends model requests to Amazon Bedrock, and Bedrock provides an OpenAI-compatible Responses API implementation for supported OpenAI models.

Bedrock で使う場合は OpenAI の Responses API はリクエストパスに含まれず、Bedrock の Responses API 互換に送信される、と書いてある。つまり、Bedrock 版 Codex の内側ハーネスは、Bedrock 側の実装に依存している。ユーザーが送信した情報が指定のリージョンのAWSのサーバー内で留まる代わりに、というわけではないが、Responses API の中身が微妙に違っていることは意識しておいた方が良さそうだ。

なお、Bedrock 側にもちゃんとコンパクション用のエンドポイント POST /v1/responses/compact は存在するので、「Bedrock の Codex はコンパクションが貧相である」と断言できるわけではない。が、Codex リポジトリに Bedrock のコンパクションに関する issue が挙がっていたりするので、少なくとも OpenAI のコンパクションと同等の実装である可能性は低いと思われる。

ちなみに Azure についても同様のことが言えるが、こちらは OpenAI との付き合いが長い分、機能が充実しているっぽい。とはいえ OpenAI の実装と異なる可能性は高いので、微妙に本家とは異なる挙動が観測されることも十分に考えられる。

というわけで、特に企業での利用においては Bedrock 経由で Codex を使うシーンは結構ありそうなので、「あれ？私の Codex、性能低すぎ！？」となったら Bedrock 由来の内側ハーネスが原因かもしれないよ、という話でした（もちろん、Bedrock の Codex 性能高すぎ！？ってなる可能性もある）。