コンテンツにスキップ

CodexでGPT-5.6 Solの1Mコンテキストを有効にする前に：公式設定と観測上限の差

8月23日時点の導入判断

対象: Codexで巨大リポジトリや長時間セッションを扱う開発者

作業現時点の選択
日常の修正、レビュー、調査デフォルトを維持する
compaction後に必要情報が欠ける巨大リポジトリ作業1セッションだけ設定を試す
文字どおりの1Mが保証条件実効上限を確認できるまで待つ
使用量を厳しく管理するデフォルトを維持する

1M設定は、compactionで失いたくないコードや履歴が明確な作業に限って試す。 設定は簡単だが、GPT-5.6 Solのモデル仕様とCodexクライアントの実効上限は同じではない。 公式案内どおり設定しても、配布中のモデルカタログやアカウント条件で小さい値へ制限される場合がある。15

Codexのデフォルト設定と1M設定を、用途、設定値、実効上限、確認方法で比較した判断図

1M設定は限定利用から始める

日常作業ではデフォルトを維持し、compaction後に必要情報が欠ける作業だけ1回限りの設定で比較する。 実効上限とusageの両方を確認できてから、常用設定へ移す。

1M設定は新規セッションでだけ試す

OpenAIのCodex責任者Tibo Sottiaux氏が共有した設定は、~/.codex/config.tomlのトップレベルへ次の3行を置く。1

model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000

model_context_windowはCodexへ要求するコンテキスト予算、model_auto_compact_token_limitは古い履歴を要約するしきい値の要求値である。 Codexは後者を解決後のコンテキスト上限の90%以下へ制限するため、編集環境で観測した872,000上限では784,800以下になる。46 保存後はCodexを再起動し、新しいセッションを開始する。 既存セッションの上限が途中で置き換わるとは案内されていない。

常用設定を変えずに試すなら、CLIの1回限りの指定を使う。

codex -m gpt-5.6-sol \
  -c model_context_window=1000000 \
  -c model_auto_compact_token_limit=900000

この構文は公式案内の1セッション用指定である。1

設定キーはCodexの公開ソースにも定義されている。3 ただし、キーが受理されることは、要求した値がそのまま実効値になることを保証しない。

モデルの1.05MとCodexの実効上限は別である

GPT-5.6 SolのAPIモデルページは、コンテキストウィンドウを1,050,000トークン、最大出力を128,000トークンと記載する。2 これはモデル側の仕様であり、Codexが各プランとクライアントへ配布するコンテキスト設定とは別の層にある。

Codexはmodel_context_windowを、モデルカタログのmax_context_window以下へ制限する。 さらに入力、ツール、出力の余白を確保するため、カタログのeffective_context_window_percentを適用する。4設定値と実効上限は別の数字として確認する。

8月23日にWSLのCodex CLI 0.149.0と、Windows・WSLのサーバー配布キャッシュを確認したところ、Solのデフォルトは272,000、設定可能な最大値は872,000、実効率は95%だった。 この組み合わせでは、1,000,000を要求しても計算上の実効上限は約828,400になる。 実際のセッションでの表示は、別途/statusで確認する必要がある。 OpenAIの公式リポジトリにも、クライアントやアカウントで上限が異なるという未解決報告がある。56

確認は新規セッションの開始直後だけでは足りない。 最初の応答後にも/statusを開き、合計コンテキストが維持されているかを見る。5 編集時のバンドル内メタデータは最大1,000,000だった一方、Windows・WSLのサーバー配布値は872,000だったため、最初の応答後の再確認が必要になる。6

デフォルトは日常作業の性能と利用枠を守る

Tibo氏の案内は、Codexのデフォルト上限が性能とコストの均衡を取るよう調整されていると明記する。1 1Mは標準値の訂正ではなく、長い履歴をcompaction前に保持したい利用者向けの上書きである。

大きい窓は、常に高い性能を意味しない。 モデルへ渡す履歴が増えれば、関連情報を探す範囲、キャッシュが外れたときの入力、利用枠の消費要因も増える。 一方、compactionが十分に働く小中規模タスクでは、保持量を増やしても回答に必要な情報は増えない。

APIではGPT-5.6 Solのプロモ価格が入力4、出力20 per 1Mトークンで、少なくとも2026年11月21日まで提供される。 API料金では、272Kを超える入力はリクエスト全体の入力が2倍、出力が1.5倍になる。2 この272KはAPIの長文料金しきい値であり、前述したCodexのデフォルト272,000とは別の条件である。 ChatGPTプランのCodexはAPI請求と同じではなく、公開資料は「1M設定で週間枠が何倍速く減るか」という固定率を示していない。 導入判断は、API単価を週間枠の減少率へ換算せず、対象アカウントのusage前後差で行う。

得をするのは保持すべき情報が多い作業である

1M設定の価値は、リポジトリのファイル数ではなく、同時に保持しなければ判断が崩れる情報量で決まる。

ワークロード1Mを試す理由デフォルトを選ぶ条件
大規模マイグレーション多数の依存関係と変更履歴を同時に追う作業を境界ごとに分割できる
考古学的デバッグ長いログ、過去実装、複数仮説を保持する再現条件と差分が小さい
巨大リポジトリの横断調査離れたモジュールの関係を比較する検索と要約で必要箇所を絞れる
日常の修正とレビュー原則なしcompaction後も判断に必要な情報が残る

「大きい方が安心」という理由だけでは切り替えない。 失われた情報を具体的に説明できないなら、まずデフォルトでタスクを分割し、必要なファイルを再読込する方が利用量を管理しやすい。

実測の不足は設定前後の記録で補う

公開情報からは、1M時の性能低下率、ChatGPTプランの使用量増加率、すべてのCodexビルドとアカウントでの実効上限を確定できない。 今回の確認もモデルカタログと設定経路の検査であり、巨大リポジトリに対する性能比較ではない。

導入テストは条件を一つずつ固定する。

  1. 利用者がCodexのバージョン、モデル、推論設定、usage残量を記録する
  2. 利用者がCLIの1回限りの指定で新規セッションを開始する
  3. Codexが最初の応答を返した後、利用者が/statusで実効上限を確認する
  4. 利用者が同じ規模のタスクをデフォルト設定と比較し、compaction後の不足とusage差を記録する
  5. 利用者が実効上限の縮小や設定消失を確認した場合、常用設定へ入れず公式更新を待つ

1Mが必要な作業は存在する。 ただし、導入条件は「設定を保存できた」ではなく、実効上限が維持され、compactionによる不足が減り、追加のusageを受け入れられたことである。

この記事をポスト リンクをコピー

関連記事

出典

  1. Tibo Sottiaux, Codexで1Mコンテキストを有効にする設定（2026年8月23日確認）。設定値、1セッション用CLI指定、新規セッション、デフォルトが性能とコストの均衡を取るという注意を確認した。 ↩↩↩↩

  2. OpenAI, GPT-5.6 Sol Model（2026年8月23日確認）。1,050,000トークンのモデル仕様、最大出力、プロモ価格、長文入力の料金条件を確認した。 ↩↩

  3. OpenAI, Codex ConfigToml（2026年8月23日確認）。model_context_windowとmodel_auto_compact_token_limitの定義を確認した。 ↩

  4. OpenAI, Codex model metadata（2026年8月23日確認）。設定上限と実効率の役割を確認した。 ↩↩

  5. OpenAI Codex Issue #38917および#39144（2026年8月23日確認）。設定値と配布カタログの不一致に関する利用者報告であり、全利用者の状態を証明するものではない。 ↩↩↩

  6. SmartScope編集環境のサニタイズ済み確認（2026年8月23日）。Codex CLI 0.149.0とWindows/WSLの配布キャッシュで、Solのcontext_window=272000、max_context_window=872000、effective_context_window_percent=95を確認した。性能または使用量の比較試験ではない。 ↩↩↩