2026/7/15

ChatGPTとCodexのコンテキストはどう違うか

ChatGPTで観測できた履歴の残り方と、Codexの公開実装を、保存・コンテキスト構築・モデル入力の3層に分けて整理する。

aichatgptcodexcontext

ChatGPTとCodexで、過去の会話やTool callが次のターンにどう残るかを整理したメモ。結論は、単純な「ChatGPTはTool callを忘れ、Codexは覚える」ではない。

ChatGPTとCodexの履歴・コンテキスト・モデル入力の違い

まず3つを分ける

「覚えている」という表現には、異なる3層が混ざっている。

保存された履歴: サービスやクライアントが保持している会話・Tool call・Tool result
次ターン用コンテキスト: 保存履歴から、次の推論用に選択・圧縮・追加された内容
モデル入力: 実際に有限のコンテキストウィンドウへ入るメッセージやitem

保存されていても毎回モデルへ全文が入るとは限らない。逆に、モデルから参照できたからといって、永続化方法まで分かるわけではない。

ChatGPTで今回観測できたこと

同一チャット内でMCPツールを実行し、後続ターンから確認した。

観測項目	結果
過去のユーザー・アシスタント発言	参照できた
過去ターンのMCP Tool call名	参照できた
MCPへ渡した引数	参照できた
MCP Tool resultのフィールドと値	参照できた
複数ターン経過後のMCP履歴	参照できた
組み込みWeb検索のターン間保持	未確認
組み込みPythonのターン間保持	未確認

したがって、少なくとも今回のChatGPTでは、概念的に次の履歴が参照可能だった。

システム・開発者指示

ユーザー 1
アシスタントの途中メッセージ
MCP Tool call
MCP Tool result
アシスタントの最終回答 1

ユーザー 2
アシスタントの最終回答 2

最新のユーザー
現在ターンのTool call / Tool result
アシスタントの最新回答

以前試したPythonについては、実際にはPythonツールが呼ばれておらず、アシスタント回答にテスト値を書いただけだった。そのため、組み込みPythonの履歴が消えたという証拠にはならない。

古い回答にWeb引用が残り、検索の生ログが見えない場合も、組み込みWeb検索だけが除外されたとは断定できない。古い部分が会話要約として渡された可能性や、引用を含む最終回答だけが残った可能性もある。

ChatGPT製品が、ツール種別ごとに何を保存し、何ターン後まで、どの粒度でモデルへ再投入するかは公開されていない。今回分かったのは、MCP履歴が過去ターンから実際に参照できたことまでである。

Codexで公開されていること

Codexは、履歴の保存構造が公式ドキュメントと公開ソースコードで確認できる。

App Serverのthread itemには、次の種類などがある。

userMessage / agentMessage
commandExecution
fileChange
mcpToolCall
dynamicToolCall
webSearch
imageView
contextCompaction

thread/readでturn履歴を読み、thread/turns/listではitemを notLoaded・summary・full から選べる。thread/items/listでは永続化されたitemをページングできる。

公開実装の RolloutRecorder は、Codexのsession rolloutをJSONLへ記録し、後から再生・検査できるようにしている。record_canonical_itemsで RolloutItem を追加し、resume時は load_rollout_itemsで読み戻し、get_rollout_historyから再開用履歴を構成する。実装上も会話だけではなく、canonical item列を保存する設計である。

概念的には次のようになる。

JSONL rollout / thread store

SessionMeta
TurnContext
User message
ResponseItem: tool call
ResponseItem: tool output
Event / completed item
Agent message
...
Compacted item
...

ただし、Codexでも「保存された全itemが、毎ターンそのままモデル入力へ入る」とは限らない。model_contextはrolloutを走査し、compactionやturn境界を考慮して、モデルに使う履歴範囲を組み立てる。App Serverにも contextCompaction itemと、明示的な thread/compact/start がある。

Codexについて確実に言えるのは、Tool callを含む実行履歴が構造化itemとして永続化され、取得・再開・圧縮の仕組みが公開されていることである。

現時点の比較

観点	ChatGPT	Codex
会話履歴	参照できる	thread / rolloutへ保存
MCP Tool callとresult	今回は過去ターンから参照できた	`mcpToolCall`などとして保存
コマンド・ファイル変更	接続ツールとChatGPT内部構成に依存	専用itemとして定義
Web検索履歴	ターン間保持の詳細は未確認	`webSearch` itemとして定義
履歴の公開取得API	ChatGPT内部仕様は非公開	turn/itemをsummary・fullで取得可能
永続化形式	非公開	JSONL rolloutとthread store
長い履歴の処理	選択・要約方法は非公開	compactionとmodel-context構築を確認可能
外部状態	接続したツール次第	worktree・Git・テストも復元手段になる

違いの中心は、Tool callを持つかどうかではない。

ChatGPTは、どの履歴が保存・再投入されるかの内部仕様が見えない。Codexは、実行履歴の永続化・取得・圧縮・再開が製品仕様とソースコードで明示されている。

実務上の扱い

どちらでも、過去のTool resultだけを現在状態の証拠にしない。

Git、ファイル、プロセス、デプロイ先を再確認する
完了条件や重要な識別子を再読込可能な場所へ残す
保存履歴とモデル入力を同一視しない
ChatGPTのツール履歴については、製品保証ではなく観測事実として扱う
Codexでもcompaction後に全ログが逐語的にモデルへ入るとは考えない

Codexが長期作業を続けやすいのは、thread履歴に加えて、リポジトリ・Git・テストという第二の復元経路を持つためでもある。

関連: ChatGPTから複数のCodex運用を調整する