OpenAIがCodexのコンテキストサイズを372kから272kへ縮小：エンジニアへの影響は？

OpenAIがCodexモデルのコンテキストウィンドウを、従来の372kトークンから272kトークンへと縮小しました。この変更により、長大なコードベースの処理や大規模なプロンプト運用を行っているエンジニアにとっては、設計の見直しが必要になる可能性があります。

これに関しては発生した当時ツイートされてたよ。Tiboによる解説がここにある： https://x.com/thsottiaux/status/2076543065045795309

自分のワークロードにはちょっと小さすぎるな。普段は200k以下に抑えてるけど、DeepSeekやMiMoのセッションだと、最後の一回を圧縮で絞り出そうとして350kトークンまで膨らむことがあるんだ。OpenAIは論文で公開されてるDeepSeekのK/Vキャッシュ技術をコピーして、もっと格安にできないものかな？

Codexを使っててコンテキストサイズが問題になったことは一度もないな。圧縮の仕組みはよく知らないけど、コンテキスト制限なんて存在しないかのようにずっと動き続けてくれるんだよね。少なくとも自分の経験上はそう。

圧縮がいかに優秀でも、大規模なプロジェクトだと結局大量のファイルを読み込む必要があるんだよ。自分の経験では、最初の200,000トークンは爆速だけど、それを過ぎると遅くなる。Fableのセッションなら大抵500,000トークンには収まるから圧縮しなくてもいいけど、Codexだと1つのセッションで何度も圧縮しなきゃいけなくなるんだ。

コンテキストの圧縮機能はあんまり好きじゃないな。今の時代、最低でも1Mトークンのコンテキストは必要だと思う。GPT 5.5や5.6を見てると、圧縮のたびにフルスピードに戻るまで少し苦戦してるし、圧縮後のコンテキストに残った古い指示内容に執着しすぎることもあってイライラする。

コンテキスト圧縮があれば無問題って言う人は多いけど、自分の作業において圧縮で失われる情報の細かさは、残念ながら許容範囲を大幅に超えてるんだよね。作業内容がそこまで詳細じゃないとか、細かい議論をする必要がないならいいのかもしれないけど。結局Anthropicを使い続けてる一番の理由は長大なコンテキストが使えるから。最悪なのは、複数の論文や巨大で複雑な資料を読み込ませて、完全に理解させた状態で作業したいのに、コンテキストウィンドウがずっと16％程度で埋まってる時。5分くらい会話して圧縮が走ると、また読み込み待ちが発生して……っていうのを繰り返す羽目になる。372は完璧じゃなかったけど、あれは神がかり的な改善だった。12〜20％だったのが40％くらいまで改善されたからね。

普段使いには主にOpusを使ってて、こまめに /clear してる。1Mコンテキストは魅力だけど、50％を超えるとすぐ劣化するし。個人的には、コンテキストが30〜40％になった時点で /clear する方がずっと良い結果が出るんだ。経験上、圧縮するより新しくやり直して、最初から必要な情報をモデルに学習させる（フロントロード）方が遥かにうまくいく。機能ごとに整理したMarkdownドキュメントをいくつか用意して、タスクに必要な情報をどこで見ればいいか最初に教え込むようにしてるよ。これがかなり調子いい。

これが理由かは分からないけど、このコンテキストサイズを超えるのはそもそも間違いだと思うよ。コンテキストを大きくするほどモデルの頭が悪くなるし、トークンコストも激増するってことを皆あまり意識してないんじゃないかな。自分はClaudeを300k以上にさせたことはないし、基本的には圧縮もしない。300kに収まるように作業を分割して、ドキュメントは極力シンプルに、コードベースはモジュール化を心がけてる。面倒といえば面倒だけど、たまのタスクに巨大なコンテキストが必要になることはあっても、もし日常的に300kを超えてるなら、それは設計の悪いコードベースを扱ってる証拠だと思う。

これは残念だし、すぐに元に戻ってほしいな。Fableが出る直前にClaudeからCodexに乗り換えたんだ。Claudeは指示を守らないし、すぐ脱線するからね。本質的に劣っていると自分が感じているモデルに戻りたくなんてないよ。

しばらく長いコーディングセッションはやってないな。どのモデルを使っても100-150kを超えると目に見えてパフォーマンスが落ちるから、常にその数値を下回るようにしてる。