Codex エージェントループの読み解きノート¶

元記事: Codex エージェントループの展開 | OpenAI（2026年1月23日公開 / 著者: Michael Bolin）

表記メモ: 本ノートでは arXiv（大小区別あり）で統一する。

結論¶

この OpenAI 記事は、Codex の新アルゴリズム論文の解説ではなく、Codex CLI / Codex harness のエージェントループ実装を分解したエンジニアリング記事です。2026年1月23日公開、著者は Michael Bolin です。¹

特に重要なのは、OpenAI がここでいう「Codex」を、Codex CLI / Codex Cloud / VS Code 拡張を含む製品群として扱いつつ、記事ではその基盤である Codex harness、つまり「中核のエージェントループと実行ロジック」に焦点を当てている点です。¹

アルゴリズムとして見ると何をしているか¶

最小化すると、構造はこれです。

history = initial_input(
  instructions,
  tools,
  sandbox/developer message,
  user/project instructions,
  skills metadata,
  environment_context,
  user_message
)

loop:
    response = Responses API に HTTP POST
    stream = SSE で受信

    for event in stream:
        UI 用 delta は表示
        reasoning / function_call / assistant_message 等は item として保存

    if assistant_message が完了:
        history += assistant_message
        break

    for function_call in response:
        result = execute_tool(function_call)
        history += function_call
        history += function_call_output(call_id, result)

    if context_window が厳しい:
        history = compact(history)

記事内の説明では、Codex CLI は Responses API に HTTP リクエストを送り、Responses API を使ってエージェントループを駆動します。エンドポイントは設定可能で、ChatGPT ログイン、OpenAI API キー、--oss のローカル OpenResponses 互換エンドポイントなどを使い分ける設計です。¹

プロンプトは単なる巨大文字列ではなく、instructions、tools、input の構造化 JSON ペイロードとして作られます。input の各項目には system / developer / user / assistant のロール優先順位があり、Codex 側では instructions を ~/.codex/config.toml の model_instructions_file またはモデル別 base instructions から読み込みます。¹

tools には、Codex の shell ツール、組み込みの update_plan ツール、Responses API 側の web_search、MCP サーバー由来のツールなどが並びます。つまり「モデルが次に何を呼べるか」を JSON Schema 的に提示して、モデルが function_call を返す構造です。¹

初期 input には、サンドボックスと承認ルールを説明する developer メッセージ、任意の developer_instructions、AGENTS.md / AGENTS.override.md / project doc / skills metadata 由来のユーザー指示、そして cwd や shell を含む environment_context が入ります。¹

モデル応答は SSE で返り、Codex は response.output_text.delta のような UI 用イベントを表示しつつ、response.output_item.added / done 系を内部 item に変換し、後続の Responses API 呼び出しの input に再投入します。¹

例として、モデルが type=reasoning と type=function_call を返した場合、Codex は実際に shell などを実行し、その観測結果を type=function_call_output として同じ call_id に紐づけ、次の推論に入れます。¹

実装上のキモ¶

Codex は古いプロンプトを新しいプロンプトの正確な prefixにするよう設計されています。これは、プロンプトキャッシュを効かせるためです。ツール実行結果を末尾に追加していくので、前半の大部分が不変になり、次回以降の推論でキャッシュが効きやすくなります。¹

一方で、Codex は Responses API の previous_response_id を現在使っていません。理由は、リクエストを完全にステートレスに保ち、ゼロデータ保持、つまり ZDR 構成を支えるためです。そのため、通信量としては履歴 JSON が伸び続けるが、モデル計算側はプロンプトキャッシュで緩和する、という設計判断になっています。¹

キャッシュミス要因としては、途中で tools を変更する、モデルを変更する、サンドボックス構成・承認モード・cwd を変更する、などが挙げられています。Codex は可能な場合、既存メッセージを書き換えず、新しい developer / user メッセージを追加することで prefix を壊さないようにしています。¹

コンテキストが大きくなりすぎた場合は compact します。初期実装では /compact で会話を要約していたが、現在は /responses/compact エンドポイントにより、会話を継続するための小さい item リストへ置き換える方式が説明されています。¹

現在読むべき実装場所¶

現在の Codex CLI は Rust 実装がメンテ対象かつデフォルト体験になっています。TypeScript 時代の agent-loop.ts 的な理解は歴史的には参考になりますが、今の実装を読むなら openai/codex の codex-rs 側です。²

中核は codex-rs/core です。OpenAI リポジトリ側の説明でも、codex-core は Codex の business logic を実装し、複数の Rust UI から使われる層とされています。³

実装を追うなら、おおむね次の対応です。

見たいもの	入口
セッション / agent loop の中心	`codex-rs/core/src/codex.rs`
Responses API クライアント	`client.rs`, `client_common.rs`
会話スレッド API	`codex_thread.rs`
compact	`compact.rs`, `compact_remote.rs`, `compact_remote_v2.rs`
tool / shell / MCP	`exec.rs`, `function_tool.rs`, `mcp.rs`, `mcp_tool_call.rs`, `tools/`
SSE / output item 処理	`stream_events_utils.rs`, `event_mapping.rs`

実際に codex-rs/core/src には client.rs、codex_thread.rs、compact.rs、compact_remote.rs、compact_remote_v2.rs などが並んでいます。⁴

背景論文は arXiv にあるか¶

厳密に言うと、この記事そのものに対応する arXiv 論文は確認できませんでした。記事本文内にも arXiv、ReAct、SWE-agent、論文 への明示的参照は見当たりません。¹

ただし、背景概念に近い arXiv 論文は残っています。

まず、最も近い基礎概念は ReAct: Synergizing Reasoning and Acting in Language Models です。これは 2022年10月提出の arXiv:2210.03629 で、LLM が reasoning trace と task-specific action を交互に生成し、外部環境や知識源と相互作用する枠組みを扱っています。Codex の「推論 → tool call → observation → 再推論」という形とかなり近い抽象です。⁵

ソフトウェアエージェント文脈では SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering が重要です。arXiv:2405.15793 で、LM agent がコード編集、リポジトリ探索、テスト実行を行うための Agent-Computer Interface、ACI の設計が性能に影響することを扱っています。Codex harness の設計思想に近い「モデル本体だけでなく、周囲の実行環境・ツールインターフェースが性能を決める」という系譜です。⁶

また、Codex 記事が扱う「履歴が伸び続ける」「コンテキスト管理・圧縮が必要」という問題に近い論文として、Improving the Efficiency of LLM Agent Systems through Trajectory Reduction があります。multi-turn agent では trajectory が増え続け、tool call と結果が後続入力に連結され続けるためコスト問題が出る、と明示しています。⁷

なお、2026年4月提出の Agentic Harness Engineering は、coding-agent harness 自体を自動進化させる研究で、Codex-CLI を比較対象として扱っています。ただし公開日は 2026年4月28日で、OpenAI 記事の 2026年1月23日より後なので、この OpenAI 記事の「背景となった論文」とは言いにくいです。むしろ、Codex harness 的な設計が研究対象化されてきた後続文脈として見るのが正確です。⁸

要するに¶

この記事の核は、論文アルゴリズムではなく、ReAct 系の reason-act-observe loop を、Responses API・ツール定義・サンドボックス・AGENTS/skills・MCP・prompt cache・compact で実用品に落とした実装解説です。

研究背景として読むなら、

ReAct: reasoning と acting の交互実行
SWE-agent: coding agent 用の agent-computer interface
Trajectory reduction / context management: 伸び続ける agent history の効率化
Agentic Harness Engineering: harness そのものを性能要因として扱う後続研究

この順で読むのが一番つながります。