Codexコンテキストウィンドウとは｜容量と利用上限の違い

Codexのコンテキストウィンドウとは

コンテキストウィンドウは、モデルがその時点の回答や作業を考えるために扱える文脈の範囲です。大きなプロジェクトを開いていることと、プロジェクト内のすべてのファイルが一度にモデルへ渡されていることは同じではありません。Codexが必要な情報を読み、その情報と依頼の条件をもとに判断する際には、扱える文脈に限りがあります。長い会話を続けるほど、何を参照したか、どの条件を維持すべきかを整理する意味が大きくなります。この容量は、保存できるファイルの大きさや端末の空き容量とも区別して考える必要があります。

容量は文字数と同じ単位ではない

文脈容量は一般にトークンという単位で扱います。トークンは文章やコードを処理するための区切りで、日本語の一文字、英語の一語、コードの一行と一定の割合で対応するものではありません。同じ見た目の長さでも、使う言語や記号、文字列の内容によって必要量は変わります。そのため、容量の数字を見て「日本語なら必ず何万字入る」と換算する説明は目安にとどめるべきです。実際の作業では、文字数から推測するより、利用中の画面や公式資料で確認できる情報を優先してください。

会話に見える情報と、判断に使う情報を分ける

画面に過去のメッセージが残っているからといって、その内容が常に同じ詳しさでモデルの判断に使われるとは限りません。長い会話では過去の内容が要約され、詳細な記述と要約が違う形で扱われることがあります。また、フォルダーに資料を置いただけで必要な箇所まで読んだと判断するのも早計です。仕様の中で必ず守ってほしい条件があるなら、ファイル名だけを渡すのではなく、確認してほしい箇所と作業上の優先順位を明示すると、結果を評価しやすくなります。

モデル変更の前に容量を確認したい理由

2026年10月12日時点で、OpenAIのモデルの公式案内は、GPT-5.5が10月14日にChatGPT、ChatGPT Work、Codexで提供終了する予定を示しています。この案内はOpenAI APIの終了を意味しません。CodexをChatGPTへのサインインで使う場合には、自分のプランと利用画面で選べる代替モデルを確認する必要があります。モデルを変更したときは、以前の数字や設定をそのまま前提にせず、新しいモデルで扱える文脈と、長い作業を続けた際の結果を確認しましょう。これは移行時に見直すべき項目としての提案であり、すべての移行で容量が減るという意味ではありません。

共通の固定値として覚えない

「Codexの容量は何トークンか」という問いに、製品全体で一つの数字を当てはめると誤解が生じます。Codexという利用環境の名前と、実際に選んでいるモデルの名前は別です。さらに、モデルの公表仕様と、その利用画面で扱える条件が同じとは限りません。本記事では、確認できていないモデルの容量を推測で並べません。数字が必要な場合は、対象モデル、利用する画面、公式資料の確認日をそろえて記録してください。別の画面や古い記事の値を混ぜると、更新後の違いを見つけにくくなります。

変更前後で同じ小さな作業を比べる

移行時の比較には、すでに結果が分かっている小さな修正を使う方法が向いています。たとえば、特定の入力だけで表示が崩れる問題について、同じ資料と同じ受け入れ条件を渡し、修正範囲や説明の正確さを比べます。会話の長さ、読み込ませるファイル、出力に求める内容が違えば、モデルの差と依頼の差が混ざります。容量の数字だけで判断せず、必要な条件を保ったまま作業を終えられるかを確かめることが、実務上の選択につながります。

文脈容量と利用上限、クレジットの違い

文脈容量は一度の判断で扱う情報量に関係し、利用上限は一定の条件でどれだけサービスを使えるかに関係します。クレジットは利用の計算に関わる別の要素です。会話の文脈に余裕があっても利用枠に達する場合はありますし、利用枠に余裕があっても長い会話の整理が必要になる場合があります。両方にトークンという言葉が出てきても、同じ残高を表しているとは限りません。原因を切り分けるときは、表示された文言が何の上限を指しているかを先に確認してください。容量の数字だけでは、契約で使える量や追加の費用を判断できません。

残量表示の対象を読み取る

残量らしい数字を見たら、まず表示の見出しと単位を読みます。文脈の使用状況なのか、一定期間の利用枠なのか、クレジットなのかによって、次に取る行動が変わるためです。文脈が大きくなっているなら資料の絞り込みを検討し、利用枠の案内なら利用状況や再び利用できる条件を確認します。数字だけを記録するより、見出し、モデル名、確認時刻を一緒に記録した方が、後から同じ表示を比較できます。画面によって案内が異なる場合は、その画面の説明を優先してください。

推論の強さを容量の設定だと思わない

モデルに深く考えさせる設定と、文脈容量は同じものではありません。公式のモデル案内は、推論の強さを高めると複雑な課題で結果が改善する可能性がある一方、時間やトークンの使用量が増えると説明しています。これは、文脈容量がその分だけ拡張されるという説明ではありません。依頼に必要な深さと、渡す資料の量をそれぞれ考えてください。短い修正に大量の資料を添え、推論も強くすれば必ず良くなる、という単純な関係を想定しない方が比較しやすくなります。

容量の設定と履歴の圧縮をどう読むか

公式の設定リファレンスでは、model_context_windowを使用中のモデルが扱える文脈容量のトークン数として説明しています。一方、model_auto_compact_token_limitは履歴の圧縮が始まるトークン数のしきい値で、未設定の場合はモデルの既定値を使うとされています。この二つは、容量を示す情報と、履歴を整理するタイミングの違いを理解する手掛かりです。設定名が見つかったという理由だけで、現在の環境に数値を追加する必要はありません。自分のモデルとクライアントの説明を確かめ、変更する理由がある場合に限って検討してください。

大きな数字を書いても能力の追加にはならない

設定欄に大きな数字を入れることと、提供側のモデルが対応する情報量を増やすことは別です。設定資料の説明からも、文脈容量は使用中のモデルに結び付いた値として読むのが適切です。インターネット上の設定例を写す前に、対象モデル、設定を使う目的、公式に示されている条件を確認してください。うまく動かない場合にも、値を大きくすることを最初の対処にせず、何を読み込ませたか、どこで問題が起きたか、どの設定を変更したかを切り分ける方が原因を追えます。

圧縮は重要な条件を再確認するきっかけにする

公式の開発者向けコマンド資料では、/compactは会話を要約して文脈のトークンを空ける操作として案内されています。要約は長い作業を続ける助けになりますが、元の会話のすべての文言をそのまま残すものではありません。特に、変更してはいけない場所、受け入れ条件、調査で除外した原因などは、作業の判断に影響します。圧縮後は重要な条件を短く確認し、回答や修正内容が条件を満たしているかを見てください。要約があることだけを、細部まで理解した根拠にしないことが大切です。

長いコード作業で文脈を整理する手順

文脈を節約する目的は、情報を少なくすること自体ではありません。判断に必要な根拠を残し、無関係な情報に埋もれさせないことです。最初からすべてのファイルや長い記録を貼るより、症状、発生条件、関係するファイルを示し、必要な範囲を確認してもらう方が、何を根拠に修正したかを追いやすくなります。途中で目的が変わったら、合意した条件も更新します。以下は本記事で提案する進め方であり、特定のモデルにだけ備わる機能の説明ではありません。容量の数字にかかわらず、修正の理由と結果を人が確認できる形にするための手順です。

Step 1: 目的と受け入れ条件を短く書く

依頼の冒頭に、直したい症状と、成功したと判断する条件を書きます。たとえば「空の入力でエラーになる。空の場合は既定の表示にし、通常の入力結果は変えない」と説明します。単に「直して」と伝えるより、対象と判断基準が明確になります。変更してはいけない公開仕様があるなら、それも最初に添えます。複数の目的を一度に詰め込むと確認範囲が広がるため、まず一つの目的で結果を評価できる依頼にすると、必要な情報を選びやすくなります。

Step 2: 関係する資料を指定して読む範囲を絞る

ファイルの場所、問題が起きる入力、短いエラーメッセージなど、原因を調べる入口を示します。長い記録を渡す場合は、関係する時刻や症状も添えてください。必要な周辺情報まで削ってしまうと誤った推測につながるので、読み込む量は少なければよいというものではありません。最初の調査で不足が分かったら、理由を確認して関連資料を追加します。資料を段階的に確認することで、どの情報が判断を変えたかを追いやすくなります。

Step 3: 合意した内容を短い作業メモに残す

作業が長くなったら、目的、確定した条件、触った箇所、未解決の点、次に確認することを短い文章にまとめます。Codexにメモを作ってもらった場合も、元の資料と照合してから使ってください。推測した原因が確定事項として混ざっていないか、途中で取り消した方針が残っていないかが確認のポイントです。新しい会話へ移る際には、このメモと必要な資料を渡します。元の長い会話をそのまま追加するより、引き継ぐべき条件を説明しやすくなります。

Step 4: 修正結果を条件と照らして検証する

コードが出力されたら、最初に決めた受け入れ条件を満たすかを確認します。直した入力だけでなく、通常の入力や境界になる値で結果が変わっていないかを見ることも必要です。Codexが「検証した」と説明した場合は、何を確認し、何が未確認かを読みます。容量に余裕があることも、長い会話を続けたことも、正しい修正の証明にはなりません。変更箇所と検証結果を短いメモに残せば、後で別のモデルや会話へ移っても、判断の根拠を引き継ぎやすくなります。

文脈が足りないと感じたときの確認ポイント

Codexが以前の条件を見落としたり、似た説明を繰り返したりしても、それだけで文脈容量が原因だと断定することはできません。資料の不足、依頼の曖昧さ、矛盾する条件、モデルの誤った判断なども考えられます。まず、見落とした条件を具体的に示し、どの資料に書いてあるかを確認してください。そのうえで、不要な情報を整理する、短いメモから新しい会話を始める、利用できる別のモデルで同じ課題を比べる、といった方法を検討します。原因を一つずつ切り分ければ、容量の大きなモデルへの変更が本当に必要かも判断しやすくなります。

大容量でも条件の照合を省かない

文脈容量の大きさは、長い資料を扱う際の選択材料になります。ただし、大量の情報を渡せることと、その中の重要な条件を常に正確に適用できることは同じではありません。たとえば、例外条件が資料の離れた場所にある場合や、古い仕様と新しい仕様が並んでいる場合には、どれを優先するかを示す必要があります。容量が十分に見えるときも、守る条件を短く明示し、修正後に照合してください。モデル選択と資料整理を組み合わせることで、結果を評価できる作業に近づけられます。

数字が確認できない部分は未確認として扱う

利用画面や公式資料で特定の容量が確認できない場合は、別のモデルの値を当てはめず、未確認として記録します。困っている症状があるなら、モデル名、利用画面、資料の量、問題が起きた時点をそろえるだけでも、調査の条件を整理できます。容量の設定、履歴の圧縮、契約の利用枠を分けて読むことが、適切な対処を選ぶ入口です。長い作業を続けるときは、重要な条件を短いメモに残し、実際の出力と検証結果で判断する習慣を持ってください。