OpenAIが変更した内容
この発表は短いものですが、そこに含まれるすべての詳細が有用です。
CodexおよびWorkにおけるGPT-6.1 Solの新しいデフォルトは、従来の272kから500kに引き上げられました。これは上限ではありません。投稿には「将来的にはさらに引き上げる予定です」とあり、モデルの最大値として「GPT-6.1 Solの最大コンテキスト長は1M」と示されています。また、500kは限界というよりも、選択されたバランスとして位置づけられています。「慎重にテストされた結果、ほとんどのユーザーにとって新しいスイートスポットとなっています。」
デフォルトは変更可能です。投稿には「引き続き上書き可能です」とあり、増減どちらの方向にも調整できます。
サブスクリプション会員向けの価格設定もこれに伴い変更されました。2つ目の投稿によると、サブスクリプションから利用する場合、GPT-6.1 Solのロングコンテキスト料金は請求されません。
執筆時点では、この変更はこれらの投稿で説明されています。Codexの変更履歴の最新エントリは、10月8日のGPT-6.1 Sol向けUltrafastモードのリリースであり、Codexのモデルページにはコンテキスト長が記載されていません。チームの意思決定のために書面での数値が必要な場合は、1週間後に両方のページを再度確認してください。
Codexにおけるコンパクションとは
すべてのCodexチャットには、モデルが一度に考慮できる会話、ツールの出力、および指示の量である「コンテキストウィンドウ」があります。Codexの設定リファレンスでは、この設定を明確に定義しています。model_context_windowは「アクティブなモデルが利用可能なコンテキストウィンドウのトークン数」です。
チャットがその制限に近づくと、Codexはそれを圧縮（コンパクション）します。過去の変更履歴のエントリでは、この動作を次のように説明しています。「コンテキストコンパクションは、セッションがコンテキストウィンドウの制限に近づくと、自動的にセッションを要約します。」これが発生するポイントには、独自の設定があります。model_auto_compact_token_limitは「自動履歴コンパクションをトリガーするトークンのしきい値（未設定の場合はモデルのデフォルトを使用）」です。
手動でトリガーすることもできます。スラッシュコマンドのリファレンスには、/compactが「表示されているチャットを要約してトークンを解放する」という説明とともに記載されており、確認後に「Codexは以前のターンを簡潔な要約に置き換え、重要な詳細を保持しながらコンテキストを解放します」とあります。
この最後のフレーズがトレードオフです。要約は、コンパクションステップが重要と判断したものを保持します。以前のターンのそれ以外の内容はすべて、チャットのワーキングコンテキストから失われます。
コンパクションが依然として機能するタイミング
500kのウィンドウは十分な広さですが、Codexでの長時間の作業はそのスペースをすぐに埋めてしまいます。
長期にわたる目標。 Codexの長期作業ガイドラインでは、モデルが同じコンテキストを使用して次のステップを選択できるように、関連する作業を1つのチャットにまとめることを推奨しています。このアドバイスは合理的ですが、チャットがしきい値を超えて肥大化する原因でもあります。
大量のツール出力。 テストの実行、ログ、ファイルの読み込みはすべてコンテキストに送られます。長時間のデバッグセッションでは、自分自身のメッセージよりもツールの出力によって多くのコンテキストが追加されることがあります。
手動コンパクション。 /compactは以前と同様に機能します。あなたやチームメンバーがセッションを軽量に保つために日常的にこれを使用している場合、要約ステップはあなたのスケジュールに従って実行されます。
独自のしきい値。 設定のいずれかの場所でmodel_auto_compact_token_limitが設定されている場合、コンパクションは新しいデフォルトから導出されたポイントではなく、その数値で開始されます。
コンパクションには、フックできる観測可能なエッジもあります。Codexのフックに関するドキュメントでは、2つのイベントが説明されています。PreCompactは「Codexがチャットをコンパクションする前に実行されます。」 PostCompactは「Codexがチャットをコンパクションした後に実行されます。」 どちらも、トリガーが手動か自動かを報告します。そのため、長いセッションがコンパクションされたかどうかを推測する必要はありません。確実に把握できます。
どの古い設定がそれを上書きするか
これは、発表を読んで明日からセッションが長くなると期待している人を最も驚かせる可能性が高い部分です。
Codexは複数のレイヤーから設定を読み込み、その設定ガイドには「優先度の高い順」に以下の順序が記載されています。
- CLIフラグおよび
--configによる上書き - プロジェクトのルートから作業ディレクトリまでのプロジェクト設定ファイル
--profileで選択されたプロファイルファイル~/.codex/config.tomlにあるユーザー設定- ワークスペース向けに配信されるクラウド管理のデフォルト値
- システム設定
- ビルトインのデフォルト値
新しい500kはデフォルト値です。デフォルト値はこのリストの最下位に位置します。上位のレイヤーで同じ設定に値が指定されている場合、そちらが優先されます。
これが重要になるのは、272kがデフォルトだった頃に広まった推奨事項があるためです。GPT-5.6やGPT-6 Solのガイドでは、古いデフォルトを超えるため、あるいはより早く安価にコンパクションを行うために、model_context_windowとmodel_auto_compact_token_limitを手動で設定する方法が紹介されていました。もしそれに従っていた場合、それらの行がまだ設定ファイルに残っている可能性があります。サンプル設定ではデフォルト値について次のように説明されています。model_context_windowについては「デフォルト：モデルの自動設定（auto for model）」、model_auto_compact_token_limitについては「未設定の場合はモデルのデフォルトを使用」となっています。これらを設定すると、モデルのデフォルトは適用されなくなります。
確認すべきいくつかの具体的なケース：
- 固定されたウィンドウ。 ユーザー設定で
model_context_windowが272k時代の値に設定されている場合、そのウィンドウが適用されます。 - 固定されたコンパクションしきい値。
model_auto_compact_token_limitが設定されている場合、ウィンドウが大きくても、設定した数値でコンパクションがトリガーされます。 - チームで共有しているプロジェクトファイル。 リポジトリ内の
.codex/config.tomlはユーザー設定よりも優先されるため、誰かが数ヶ月前に追加した値が、そのプロジェクトを信頼する全員に適用されます。 - プロファイル。 プロファイルを使用して起動する場合、その値はユーザー設定よりも優先されます。
- 管理されたデフォルト値。 ワークスペースがクラウド管理の設定を配信している場合、管理者がこれらの値を設定している可能性があります。
また、知っておくべきスコープ設定もあります。model_auto_compact_token_limit_scopeは「自動コンパクションのしきい値が、アクティブなコンテキスト全体（デフォルトのtotal）をカウントするか、引き継がれたコンパクションウィンドウのプレフィックス以降の増加分のみ（body_after_prefix）をカウントするかを制御します。」 これを変更した場合、コンパクションのタイミングはあなたの選択に従います。
これらはどれも間違いではありません。デフォルト値が小さかった頃の合理的な選択でした。ただ、それらが自動的に更新されることはありません。
ウィンドウが大きくなっても変わらない部分
コンテキストウィンドウが大きくなると、コンパクションが発生するまでに1つのチャットを実行できる時間が変わります。しかし、チャット間でコンテキストがどのように移動するかは変わりません。Codexのドキュメントでは、いくつかの場所でその境界線が引かれています。
指示は開始時に読み込まれる。 「Codexは起動時に指示チェーンを構築します（実行ごとに1回。TUIでは通常、起動されたセッションごとに1回を意味します）。」そのチェーンはあなたのAGENTS.mdファイルであり、上限があります。Codexは「合計サイズがproject_doc_max_bytes（デフォルトは32 KiB）で定義された制限に達すると」ファイルの追加を停止します。ウィンドウが大きくなっても、この上限は引き上げられません。ルールが消えてしまったように見える場合は、CodexがAGENTS.mdのルールをスキップする問題に関するガイドで一般的な原因を確認してください。
新しいチャットは古い書き起こしからではなく、指示から開始される。 指示チェーンはCodexの起動時に構築されます。ローカルメモリ（有効にしている場合）は、対象となる過去のチャットからバックグラウンドで生成されます。これは、チャットの完全なコンテキストをそのまま引き継ぐこととは異なります。
メモリは独立している。 OpenAIのメモリに関するページには、「ChatGPTのウェブ版はChatGPTメモリを使用しますが、ローカルのCodexクライアントは独立したローカルメモリの保存領域とコントロールを使用します」と記載されています。また、明確な経験則も示されています。「メモリは役立つ想起レイヤーとして扱い、常に適用されるべきルールの唯一の情報源とはみなさないでください。」また、Codexは「アクティブなセッションや短命なセッションをスキップする」ため、タスクの途中でローカルメモリが形成されることもありません。Codexのローカルメモリを有効にする方法に関するウォークスルーで、そのコントロール方法を説明しています。
Workは独自の設定に従う。 メモリについて、OpenAIはChatGPT Workが「アカウントとワークスペースで利用可能なメモリ設定を使用し、ローカルのCodexメモリ保存領域やローカルメモリコントロールは使用しない」と述べています。ローカルのconfig.tomlは、それを読み込むCodexクライアントを制御します。
代わりに試されがちなこと
ウィンドウを1Mに設定してコンパクションを忘れる。 モデルの最大値の範囲内であれば設定可能ですが、十分に長いタスクは適用されているしきい値に依然として到達します。
古いしきい値をそのまま残す。 272k向けに選択されたコンパクション制限は、そのポイントでコンパクションを実行し続けます。
次のチャットが覚えていると期待する。 大きなウィンドウは、1つのチャット内でのみ有効であり、チャットが終了すれば消え去ります。
正確なルールを要約に委ねる。 コンパクションは、重要と判断した内容のみを保持します。維持しなければならないルールはAGENTS.mdに記述すべきであり、そこから開始時に読み込まれます。
チーム全員が同じセットアップであると仮定する。 プロファイル、プロジェクトファイル、および管理されたデフォルト値により、同じリポジトリであっても2人のユーザーで異なるウィンドウが適用されることがあります。
解決策：デフォルトを上書きしているものを確認し、コンパクションで保持すべきものを決定し、実行後に元に戻す
ステップ 1：固定されたコンテキスト設定がないか設定を監査する
~/.codex/config.tomlを開き、model_context_window、model_auto_compact_token_limit、およびmodel_auto_compact_token_limit_scopeを探します。リポジトリ内の.codex/config.tomlや、使用しているプロファイルファイルでも同様に確認します。
見つかった各値について、引き続き必要かどうかを判断します。古い272kのデフォルトを回避するためだけに設定していた場合は、それを削除してモデルのデフォルトを適用させます。コストや速度のために意図的に設定した場合は、その理由を書き残して、次の人が誤って削除しないようにします。管理されたワークスペースにいる場合は、Codexの設定を管理している担当者に何が設定されているか確認してください。
ステップ 2：コンパクションで保持すべき内容を指定する
Codexでは、コンパクションプロンプトを置き換えることができます。設定リファレンスでは、compact_promptを「履歴コンパクションプロンプトのインライン上書き」と説明しています。また、実験的としてマークされているファイルベースのオプションもあります。
これは控えめに使用してください。優れたコンパクションプロンプトは、存続させるべきカテゴリ（現在の目標、このチャットで行われた決定、変更されたファイル、未解決の問題など）を指定します。短く、自分の作業方法に特化した内容にしてください。別のツールでの同様のアプローチについては、Claude Codeの自動コンパクション設定に関するガイドを参照してください。
ステップ 3：コンパクション後に重要な情報を元に戻す
一部のコンテキストは、要約するのではなく再提示する必要があります。Codexのフックに関するドキュメントでは、コンパクションによって発生したセッション開始を検知し、次のモデルリクエストの前に実行されるSessionStartフックについて説明されています。これにより、モデルが追加の開発者コンテキストとして認識するコンテキストを追加できます。これは、長いタスクで失うわけにはいかないいくつかの事実を再提示するための、ドキュメント化された方法です。
その後、永続的な知識をチャットの外に移動します。ルールはAGENTS.mdに記述します。チャット間で再利用する価値のある決定事項は、単一のセッションよりも長生きする場所に保存します。
MemoryLakeでの設定方法
コンテキストウィンドウが大きくなると、1つのチャットのより多くの部分が視野に残り続けます。しかし、来週必要になる決定事項には、チャットではない別の「家」が必要です。MemoryLakeは、それらの決定事項をあなたが維持する1つのリストに保存し、Codexや他のアシスタントから利用できるようにするためのメモリレイヤーです。
エントリーはあなた自身の言葉で自分で作成します。Codexの設定、ローカルのCodexメモリ、ChatGPTアカウント、またはベンダーの保存領域から何かが読み取られたり、書き込まれたり、削除されたりすることはありません。管理されたワークスペースで作業している場合は、プロジェクトの詳細を他の場所にコピーすることに関する組織のポリシーを確認してください。
ステップ 1：APIキーを作成する
サインインし、ダッシュボードからキーを生成します。このキーはMemoryLakeのワークスペースに属しており、OpenAIのアカウントとは独立しています。
ステップ 2：最初のメモリをアップロードする
コンパクションの要約で最も曖昧になりやすいものから始めましょう。アーキテクチャの決定とその理由、まだAGENTS.mdに記載されていない規約、既知の落とし穴などです。1つのエントリーにつき1つの決定事項を、日付付きで登録します。
ステップ 3：AIとエージェントを接続する
Codexや、使用している他のアシスタントを接続します。これにより、前回のチャットのウィンドウがどれほど大きかったか、あるいはいつコンパクションされたかに関係なく、新しいチャットごとに同じ決定事項を利用できるようになります。
実務における変化
第1の違いは、実際にどのウィンドウが適用されているかを把握できることです。監査を行うことで、新しいデフォルトが適用されているか、あるいは適用しないことを選択したかが明確になります。
第2に、長いセッションでの予期せぬ事態が減少します。フックを設定しておくことで、コンパクションは目に見えるイベントとなり、実行後に重要な情報が復元されます。
第3に、役割分担が明確になります。コンテキストウィンドウは現在のタスクを保持します。AGENTS.mdはルールを保持します。独立したメモリは決定事項を保持します。この同じ分割は、モデルを変更する場合にも適用されます。詳細はGPT-6 Astraへの切り替えに関するガイドで説明されています。
第4に、モデルが頭の中に保持している内容への依存度が下がります。OpenAI自体も、モデルの推論の内部を見ることの限界について言及しています。これについては、そのウィンドウが狭まるにつれて書き留めるべき内容に関する考察で解説しています。決定事項を書き留めておくことは、信頼性の高いアプローチです。Kiroのユーザーも同様の問題に直面しており、Kiroのコンパクションで何を存続させるかの決定で説明されています。
500kデフォルトにおけるベストプラクティス
思い込む前に監査する。 いずれの設定レイヤーであっても、固定された値は新しいデフォルトを上書きします。
意図的な設定はドキュメント化しておく。 固定された値の横にコメントを残しておくことで、次の人が推測する手間を省けます。
プロジェクトファイルを確認する。 共有されている.codex/config.tomlは、そのプロジェクトを信頼する全員に適用されます。
コンパクションを監視する。 フックを使用することで、いつコンパクションが発生し、何がトリガーになったかを知ることができます。
コンパクション後に重要な情報を再提示する。 ルールを要約に依存しないでください。
ルールはAGENTS.mdに保持する。 すべてのセッションの開始時に読み込まれます。
決定事項はチャットの外に書き留める。 ウィンドウサイズがどれほど大きくても、それらを次のチャットに引き継ぐことはできません。
結論
OpenAIは、コンパクションを削減するため、2026年10月11日にCodexおよびWorkにおけるGPT-6.1 Sol'sのデフォルトコンテキスト長を従来の272kから500kに引き上げ、サブスクリプション利用におけるロングコンテキスト料金の請求を停止しました。モデルの最大値は1Mであり、デフォルトは上書き可能です。
長いタスクがあなたに適用されているしきい値に達すると、コンパクションは依然として発生します。そして、そのしきい値は新しいデフォルトとは全く異なる可能性があります。CLIフラグ、プロジェクトファイル、プロファイル、ユーザー設定、または管理されたデフォルト値はすべて、デフォルト値よりも優先されます。
設定を確認し、コンパクションで保持すべき内容を決定し、実行後に重要な情報を再提示してください。そして、単一のチャットを超えて重要となる決定事項は、どれほどウィンドウが大きくなっても届かない場所に保管しておきましょう。