8月16日、Runtime Wireが「OpenAI benchmarks a 16x load-time gain for giant ChatGPT and Codex threads」と題した記事を公開した。OpenAIがChatGPTおよびCodexデスクトップアプリにおける大規模会話スレッドのロード時間を約16.6倍高速化したベンチマーク結果を報告している。
741ターン・231MBの会話が1.66秒でロード
OpenAIのCodexデスクトップアプリを率いるAndrew Ambrosino(@ajambrosino)が、X上でベンチマーク結果を公開した。
テストに使用したのは741ターン、231MBの会話スレッド。改善前のロード時間は27.62秒だったが、新実装では1.66秒まで短縮された。削減率にして約94%、速度倍率では約16.6倍に相当する。
メモリ面での改善も大きい。JavaScriptヒープ(ブラウザやElectronアプリのメモリ空間)の増加量は87.8%削減、アプリケーション全体のメモリ増加も41.2%削減された。
何が変わったのか:「全件ロード」から「遅延ロード」へ
数字の内訳を見ると、改善の源泉がわかる。
| 指標 | 改善前 | 改善後 | 削減率 |
|---|---|---|---|
| ネットワークリクエスト数 | 894 | 16 | 98.2%減 |
| 初期ロードするトランスクリプト件数 | 15,529 | 64 | 99.6%減 |
リクエスト数が894から16へ、初期ロードするトランスクリプト件数が15,529から64へと激減している。旧実装はスレッド全体を一括で取得していたと考えられる。新実装は表示に必要な最小限のアイテムだけを先にロードする方式に切り替えたとみられる。
ただし、ユーザーが過去メッセージをスクロールして遡った際の挙動(ページネーションの滑らかさ、スクロール位置の安定性)については、今回のベンチマークでは示されていない。※編集部の考察:この部分はUX品質に直結するため、実際のリリースを見るまで判断は保留が妥当だ。
なお、今回の改善はあくまでクライアントサイドの会話ロードおよびレンダリングの話であり、モデルの推論速度や回答品質、Codexがタスクを完了するまでの時間とは無関係である。
なぜ今、長大スレッドが問題になっているのか
OpenAIのCodexリポジトリには、ユーザーから長セッション時の不具合報告が蓄積されていた。7月には「アップデート後に古いターンが参照できなくなる」という報告が上がり、ページネーションされた履歴を仮想スクロールのトランスクリプトにマージする部分に問題があることが指摘されていた。また別のIssueでは、会話状態が積み重なるにつれてフリーズ、メモリ増加、アクティブターンの制御喪失が発生するケースも報告されていた。
背景にあるのはOpenAI自身が公表した利用実態だ。2026年6月のリサーチ投稿によれば、5月時点でCodexユーザーの70%以上が「人間なら1時間以上かかる作業」をエージェントに依頼していた。長時間タスクはツール呼び出し結果、中間推論ログ、ファイル変更履歴、追加ターンを次々と生成し、スレッドは通常のチャットとは比較にならない規模に膨れ上がる。
エージェント型製品において、モデルのコンテキストウィンドウに十分な余裕があっても、インターフェース側がトランスクリプトのレンダリング負荷で詰まるという構造的な問題がある。今回の改善はモデルや会話データには手を加えず、クライアントのボトルネックだけを削りに行ったアプローチだ。
現時点での注意点
Ambrosinoがベンチマークを公開した時点では、この改善がどのパブリックビルドに含まれるかは明示されていない。現在のChatGPTおよびCodexユーザーへのパフォーマンス保証ではなく、あくまでベンチマーク上の結果である。ハードウェアやOS、実際の本番スレッドで同様の結果が得られるかは、正式リリース後に確認が必要だ。
詳細はOpenAI benchmarks a 16x load-time gain for giant ChatGPT and Codex threadsを参照していただきたい。