Codexのコンテキストとは？上限や圧縮・確認方法も解説

Codexを使い始めてから「コンテキスト」という言葉を目にする機会が増え、何なのか気になっている人は多いですよね。

プロンプトやコンテキストウィンドウなど、似たような言葉との違いや理解する必要性があいまいな人もいるはず。

そこでこの記事では上限サイズも交え、Codexにおけるコンテキストが何なのかを解説します。圧縮やリセットのやり方も紹介するので、ぜひ参考にしてください。

Codexの特徴を詳しく知りたい人は、次の記事を参考にしてください。

Codexのコンテキストとは？

Codexにおけるコンテキストとは、AIがコードを生成・編集する際に参照する情報全体を指します。ユーザーが入力した指示文だけでなく、過去の会話履歴や読み込んだファイルの内容もすべて含まれる点が特徴です。

ここからはコンテキストの基本知識を、3つにまとめて解説します。

プロンプトとの違い

プロンプトは「ユーザーがAIに送る指示文そのもの」を指します。一方、コンテキストはプロンプトを含む、AIが処理する入力情報全体の総称です。

たとえば「この関数にテストを追加して」と入力した場合、入力した文がプロンプトにあたります。Codexはプロンプトに加え、対象ファイルの中身や過去のやり取りもあわせて読み取ります。読み取った情報すべてがコンテキストです。

つまりプロンプトはコンテキストの一部であり、コンテキストのほうが範囲が広いといえます。

Codexのおすすめプロンプトを詳しく知りたい人は、次の記事を参考にしてください。

コンテキストウィンドウとの違い

コンテキストウィンドウとは、AIが一度に読み込める情報量の上限枠を指します。コンテキストが「中身」なら、コンテキストウィンドウは「器の大きさ」にあたります。

器の容量を超えると、古い情報から順に切り捨てられる仕組みです。OpenAIの公式ドキュメントでも、モデルごとにトークン数の上限が明記されています。

コンテキストウィンドウの大きさはモデルによって異なり、後述する「モデル別のトークン上限」で詳しく触れます。

コンテキストを消費する要素

コンテキストを消費する要素は、大きく分けて4つあります。

とくに見落としがちなのがAIの応答テキストです。ユーザーの入力だけでなく、Codexが返したコードや説明文もトークンとして蓄積されます。

長い会話を続けるほど消費量は増え、コンテキストウィンドウの上限に近づきます。「急にCodexの回答がおかしくなった」と感じたら、消費量の増大が原因である可能性が高いです。

Codex・コンテキストの上限サイズ

Codexで扱えるコンテキストには、モデルごとに決まったトークン上限があります。上限を把握しておかないと、作業途中で情報が切り捨てられ、意図しない出力につながります。

ここからはトークン上限と自動圧縮の仕組みを、2つにまとめて解説します。

モデル別のトークン上限

Codexで利用できる主なモデルのトークン上限は、次のとおりです。

モデル名	コンテキストウィンドウ	最大出力トークン
codex-1	19万2,000トークン	1万6,384トークン
o3	20万トークン	10万トークン
o4-mini	20万トークン	10万トークン

codex-1はCodex専用に最適化されたモデルで、コード生成やファイル編集に強みがあります。o3やo4-miniはコンテキストウィンドウが20万トークンとやや大きく、長い会話にも対応しやすい設計です。

1トークンは英語で約4文字、日本語では1〜2文字程度に相当します。19万2,000トークンは日本語のコードコメント込みで約10万〜15万文字に相当するため、大規模なプロジェクトでも一定の余裕があります。

Codexで使えるモデルの種類を詳しく知りたい人は、次の記事を参考にしてください。

上限に近づくと自動圧縮が入る

コンテキストの使用量が上限に近づくと、Codexは古い会話履歴を自動で要約・圧縮します。ユーザーが何も操作しなくても発動する仕組みです。

自動圧縮では、直近のやり取りを優先して残し、古いやり取りを要約文に置き換えます。要約によってトークン数を削減し、新しい指示を受け付ける余地を確保する仕組みです。

ただし自動圧縮が入ると、過去の細かいニュアンスが失われる場合があります。「さっき伝えた条件を忘れている」と感じたら、自動圧縮が働いた可能性を疑ってください。重要な前提条件はAGENTS.mdに書いておくと、圧縮後も参照されやすいです。

Codex・コンテキストの使い方

コンテキストは「消費量の把握」と「適切なタイミングでの圧縮・リセット」が重要です。

ここからはコンテキスト管理の具体的な操作手順を、3つにまとめて解説します。

使用率の確認方法

Codex CLIでは、現在のコンテキスト使用率をコマンドで確認できます。

手順は、次のとおりです。

1. Codex CLIを起動した状態でセッション内コマンドを実行する
2. `/stats` と入力してEnterキーを押す
3. 画面に現在のトークン使用量と上限が表示される

表示例として「Used: 45,000 / 192,000 tokens（23%）」のような数値が出ます。使用率が70%を超えたら、圧縮やリセットを検討するタイミングです。

Web版のCodexダッシュボードを使っている場合は、タスク詳細画面の右側パネルにトークン使用量が表示されます。CLI・Web版のどちらでも、こまめに確認する習慣をつけるのがおすすめです。

圧縮方法

コンテキストの手動圧縮は、CLI上でコマンドを入力するだけで実行できます。

1. Codex CLIのセッション中に `/compact` と入力してEnterキーを押す
2. Codexが過去の会話履歴を要約し、トークン数を削減する
3. 圧縮完了後、新たなトークン使用量が表示される

`/compact` の後ろに圧縮時の指示を追記することも可能です。

“`
/compact フロントエンドの修正履歴だけ残して
“`

上記のように書くと、指定した内容を優先して残しつつ、ほかの履歴を圧縮します。プロジェクトの文脈を維持したまま空き容量を確保できるため、単純なリセットより実用的です。

リセット方法

コンテキストを完全にリセットしたい場合は、セッションを終了して新しいセッションを開始します。

1. Codex CLIで `Ctrl + C` または `/exit` を入力しセッションを終了する
2. ターミナルで再度 `codex` コマンドを実行し新しいセッションを開始する
3. 新セッションではコンテキストが0トークンの状態から始まる

リセットすると、過去の会話履歴はすべて失われます。必要な前提条件やルールは、リセット前にAGENTS.mdへ転記すると安心です。

「圧縮で対応できるレベルか、リセットが必要か」の判断基準として、使用率が70%を超えたらリセットを検討するのが目安になります。

Codex・コンテキストを効率よく使うコツ4つ

コンテキストを節約すると、1回のセッションで扱える作業量が増えます。

ここからはコンテキストを効率よく使うコツを、4つにまとめて解説します。

指示文を短く的確に書く

指示文が長いほどトークン消費は増えるため、指示文はできるだけ短く書きましょう。

 「〜してほしいのですが、もし可能であれば〜も考慮しつつ」のような回りくどい書き方は避けてください。

悪い例と良い例を比較します。

良い例では、約30文字で同じ要件を伝えています。箇条書きで要件を分けるのも効果的です。1回のプロンプトで複数の作業を詰め込まず、作業ごとに分けて送ると精度も上がります。

自分でプロンプトを作成するのが苦手な人は、ChatGPTなどの生成AIを活用して要約してもらうのもおすすめです。

必要なファイルだけを参照させる

コンテキストを節約するために、必要なファイルだけ参照させましょう。

Codexはプロジェクト内のファイルを読み込む際、ファイルの中身がそのままトークンとして消費されます。不要なファイルまで読み込むと、コンテキストが一気に圧迫されます。

対策として、`.codexignore` ファイルを活用してください。`.gitignore` と同じ書式で、Codexに読み込ませたくないファイルやディレクトリを指定できます。

```
node_modules/
dist/
*.log
*.csv
```

上記のように設定すると、依存パッケージやビルド成果物、ログファイルなどを除外できます。大量のテストデータやCSVファイルを除外するだけで、数万トークンの節約につながります。

調査はサブエージェントに任せる

調査やリサーチをサブエージェントに任せると、メインのコンテキストを消費せずに済みます。

たとえば「このライブラリの最新バージョンを調べて」という調査タスクをメインセッションで行うと、検索結果や参考情報がすべてコンテキストに蓄積されます。サブエージェントに任せれば、調査結果の要約だけがメインセッションに返されるため、消費トークンを大幅に削減可能です。

Codex CLIでは、プロンプト内で「サブエージェントを使って調べて」と指示すると、Codexが自動的にサブプロセスを生成して調査を実行します。

Codexのサブエージェントについて詳しく知りたい人は、次の記事を参考にしてください。

AGENTS.mdに前提を書いておく

AGENTS.mdに前提条件やコーディング規約を記載することで、毎回プロンプトで説明し直す手間とトークン消費を両方削減できます。

AGENTS.mdは、Codexがセッション開始時に自動で読み込む設定ファイルです。プロジェクトの前提条件やコーディング規約をここに書いておくと、トークン消費を削減できます。

記載内容の例は、次のとおりです。

“`
言語: TypeScript（strictモード）
フレームワーク: Next.js 14（App Router）
テスト: Vitest
コードスタイル: ESLint + Prettier準拠
コミットメッセージ: Conventional Commits形式
日本語でコメントを書くこと
“`

AGENTS.mdは、プロジェクトのルートディレクトリに配置します。サブディレクトリにも個別のAGENTS.mdを置けるため、フロントエンドとバックエンドで異なるルールを設定する運用も可能です。

圧縮やリセットを行っても、AGENTS.mdの内容は新しいセッションで再読み込みされます。「何度も同じ前提を伝えている」と感じたら、AGENTS.mdの作成を検討してください。

Codexのコンテキストによく抱く疑問

Codexのコンテキスト管理では、圧縮やモデル切り替えに関する疑問がよく挙がります。

ここからはよくある疑問を、2つにまとめて解説します。

圧縮するとCodexの精度は下がる？

結論として、圧縮によって精度が下がるリスクはあります。ただし「圧縮しないまま上限に達する」ほうが精度低下は深刻です。

圧縮時にCodexは、過去の会話を要約文に置き換えます。要約の過程で、細かい変数名や条件分岐の詳細が省略される場合があり、生成される成果物の精度が下がる可能性も。

一方、圧縮せずに上限へ到達すると、自動圧縮が強制的に実行されます。手動圧縮では `/compact` に指示を添えて残す情報を選べますが、自動圧縮では残したい情報の制御ができません。

精度を維持するためのポイントは、次の3つです。

計画的に手動圧縮を行うほうが、自動圧縮に任せるより精度を保ちやすいです。

途中でモデルを切り替えるとどうなる？

Codex CLIでセッション中にモデルを切り替えた場合、コンテキストの内容は引き継がれます。 ただし、切り替え先モデルのコンテキストウィンドウが小さいと、既存の情報が入りきらず圧縮が発生します。

たとえばo3（20万トークン）で15万トークンまで使った状態から、codex-1（19万2,000トークン）に切り替えた場合、上限の差は約8,000トークンです。すぐに上限に達する可能性は低いものの、余裕は少なくなります。

モデル切り替え時の注意点は、次のとおりです。

モデルの切り替えは「作業内容に応じて最適なモデルを選ぶ」ために有効ですが、コンテキスト管理とセットで考える必要があります。

まとめ

今回は、Codexのコンテキストの仕組みと効率的な活用方法を解説しました。

コンテキストとは、AIがコードを生成・編集する際に参照する情報全体のことです。

まずは `/stats` コマンドで現在のトークン使用量を確認し、上限に余裕があるかをチェックするところから始めてみましょう。慣れてきたら `.codexignore` での不要ファイルの除外やAGENTS.mdへの前提条件の記載にも取り組むと、コンテキストをより効率よく活用できます。