Codexへ短い依頼をしたのに、思ったよりTokenを使っていることがあります。
例えば、次の依頼だけを見ると処理はかなり小さく見えます。
この文章を3カテゴリのどれかに分類してCodexが実際に扱うのは、この1文だけではありません。プロジェクトのルール、利用できる外部機能、必要になって読んだファイル、コマンドの実行結果、これまでの会話なども、モデルが判断するための材料になります。
モデル自身が答えを考える処理にもTokenを使います。Codexがコードを調べる場合は、ファイルを読む、コマンドを実行する、その結果を見て次の行動を決める、という流れを何度か繰り返します。
Tokenの消費先は、大きく4つに分けると分かりやすくなります。
Token消費
├─ 入力Token
│ └─ モデルへ渡す情報
│
├─ 推論Token
│ └─ モデルが考えるために使うToken
│
├─ 出力Token
│ └─ 外部機能の呼び出しや最終回答
│
└─ 繰り返し処理
└─ 調査・実行・確認のたびに上の3つが増えるこの記事では、Codexを使う側で実際に減らせる場所を中心に見ていきます。
Responses APIまで使うと、出力Tokenの上限や推論量なども細かく指定できます。実際のAPIコードと使用Tokenの確認方法は次の記事で扱います。
Tokenは何に使われているのか
OpenAIの現在のCodex rate cardでは、Codexの使用量をInput、Cached Input、Output Tokenに分けて扱っています。
https://help.openai.com/en/articles/11481834
ここでいうInputはモデルへ渡した情報、Outputはモデルが生成した情報です。推論を行うモデルでは、画面に表示されない推論TokenもOutput側に含まれます。
Codexでコード修正をすると、1回の依頼の中でもモデルとのやり取りが複数回発生します。
最初に依頼を読む
↓
ファイルを調べる
↓
結果を見て考える
↓
コマンドを実行する
↓
結果を見て考える
↓
コードを修正する
↓
テスト結果を確認する
↓
回答するこの途中でモデルが呼ばれるたびに、入力Token、推論Token、出力Tokenが使われます。
「コンテキスト」という言葉もよく出てきます。この記事では、モデルへ渡す仕事の材料くらいの意味で考えます。ユーザーの依頼だけでなく、プロジェクトのルールやファイルの内容、コマンド結果などもコンテキストです。
入力Tokenには、例えば次のような情報が入ります。
入力Token
├─ ユーザーの依頼
├─ Codex側の基本ルール
├─ AGENTS.md
├─ Skillsから読み込んだ説明
├─ MCPやその他の外部機能の定義
├─ 読み込んだファイル
├─ コマンドやテストの結果
├─ これまでの会話
└─ 作業中に追加で集めた情報コンテキストを小さくすると、主に入力Tokenを減らせます。総Tokenを減らすには、モデルが考える量、返す量、作業を何回繰り返すかも関係します。
利用者が減らせるところ、APIまで使わないと触れないところ
Codex CLIだけでも、入力Tokenを中心にかなり見直せます。Responses APIまで使うと、推論や出力の上限も直接指定できます。
| 対象 | Codex CLIでできること | Responses APIまで使うとできること | 主に影響するToken |
|---|---|---|---|
| IDEが追加する情報 | IDE連携が不要ならCLIを使う | 送る情報をアプリ側で決める | 入力 |
| AGENTS.md | 小さくする、用途ごとに分ける | 必要な指示だけ送る | 入力 |
| Skills | 重複や巨大化を避ける | 必要な指示だけ構成する | 入力 |
| MCP・外部機能 | 不要なものを有効にしない | リクエストごとに使う機能を指定する | 入力・出力 |
| 読み込むファイル | 対象ファイルやディレクトリを指定する | 送信内容そのものを決める | 入力 |
| コマンド・テスト結果 | 必要な箇所だけ取得する | 外部機能から返す情報を加工する | 入力 |
| 会話履歴 | 無関係な作業は別スレッドにする | 履歴の持ち方をアプリ側で管理する | 入力 |
| モデルが考える量 | Codexの推論設定を仕事に合わせる | reasoning.effortをリクエストごとに指定する | 推論 |
| 回答の詳しさ | 必要な回答形式を指示する | text.verbosityを指定する | 出力 |
| 最大出力Token | Codex側に任せる部分が大きい | max_output_tokensで上限を指定する | 推論・出力 |
| 出力形式 | Promptで形式を指定する | Structured Outputsで形式を固定する | 出力 |
| 調査や実行の繰り返し | 対象範囲やゴールを具体的にする | 繰り返し処理そのものをアプリ側で設計する | 全体 |
利用者から直接触れない部分もあります。Codex内部の基本指示や、長い作業で履歴を圧縮する処理などはCodex側が管理しています。
| Token消費に関係するもの | 利用者からの制御 |
|---|---|
| Codex内部の基本指示 | 基本的に直接は触れない |
| Codexが内部で必要とする情報 | 直接の制御は難しい |
| 長い履歴を圧縮する内部処理 | 設定できる範囲は限られる |
| 実際に使われる推論Token数 | 推論の強さは選べるがToken数そのものは指定できない |
| 作業中に何回やり直すか | 指示で減らせるが、作業内容にも左右される |
入力Tokenは「必要なものだけ渡す」
Codex利用者が最も手を入れやすいのは入力です。
OpenAIのGPT-5.6向けガイドでも、重複した指示や例を減らし、作業に関係する外部機能だけを使える状態にすることでToken効率を改善できると案内されています。OpenAI内部のCoding Agent評価では、指示と利用できる機能を小さくした構成で、総Tokenが41〜66%減った例も紹介されています。
これはCodexの使い方を見直すときの参考になります。
Model guidance | OpenAI API
Compare model features, migration guidance, and prompting best practices across OpenAI models.
https://developers.openai.com/api/docs/guides/latest-model
IDE連携がいらない作業ではCodex CLIを使う
CodexのIDE拡張は、いま開いているファイルや選択中のコードなど、エディタ上の情報を使えることが強みです。
Codex IDE extension | ChatGPT Learn
Use Codex beside your code and editor context.
https://developers.openai.com/codex/ide
「いま開いているこのコードを直して」と頼むときには便利ですが、Token節約だけを見ると、ユーザーが自分で指定した情報に加えてエディタ側の情報も扱うことになります。
対象ファイルが最初から分かっている作業なら、CLIから直接指定できます。
src/auth/session.ts のrefresh処理を確認してCodexはそのファイルを読み、必要になれば関連するファイルを追加で探します。最初からエディタ上の情報一式を持たせず、必要になったものを順番に読ませる形です。
Tokenを節約しやすい順で考えると、必要な情報を自分で絞りやすいCLIが基準になります。IDE連携が必要な作業では拡張機能を使い、長時間の処理や並列実行を任せたいときはCloudを使う、と役割を分けられます。
Codex Cloudは、OpenAI側の隔離された環境でrepositoryを扱い、作業を進める仕組みです。
Codex cloud | ChatGPT Learn
Delegate work to Codex in isolated cloud environments.
https://developers.openai.com/codex/cloud
ローカルで終わる作業はCLI、エディタの情報が役立つ作業はIDE拡張、Cloudへ任せる意味がある作業だけCloudへ送る。この使い分けだけでも、不要な情報や処理が増える場面を減らせます。
AGENTS.mdは毎回必要な内容に絞る
CodexはAGENTS.mdをプロジェクトの指示として読み込みます。
公式ドキュメントでは、プロジェクトのrootから現在作業しているディレクトリまでAGENTS.mdを探し、該当する内容を組み合わせて使います。読み込む量にはproject_doc_max_bytesという上限があり、デフォルトは32 KiBです。
Custom instructions with AGENTS.md | ChatGPT Learn
Give Codex extra instructions and context for your project
https://developers.openai.com/codex/guides/agents-md
例えばrootのAGENTS.mdに、記事の書き方、API設計、デプロイ手順、Git運用、過去のトラブルまで全部入れていると、記事を書くだけの作業でもAPIやデプロイの説明まで読むことになります。
rootにはプロジェクト全体で常に必要なルールを置き、詳しい説明は用途ごとに分けます。
AGENTS.md
├─ 常に守るルール
└─ 詳細ドキュメントの場所
docs/writing.md
└─ 記事を書くときに読む
docs/api.md
└─ APIを変更するときに読むmonorepoなら、特定のディレクトリだけに適用したいルールを、そのディレクトリ側のAGENTS.mdへ置く方法もあります。
資料を減らすというより、毎回読む資料と、必要になったときに読む資料を分けるのがポイントです。
Skillsも必要になった情報だけ読む形にする
Skillsは、Codexに特定の作業手順や知識を追加する仕組みです。
すべてのSkill本文を最初から読むのではなく、まずSkillの名前と説明を見て、必要だと判断したSkillのSKILL.mdを読みます。さらに詳しい資料が必要なら、Skillから参照されているファイルを読みます。
Skillの名前と説明
↓
必要ならSKILL.md
↓
さらに必要なら詳しい資料OpenAIのSkill Creatorでも、モデルが使えるコンテキストには限りがあるため、Skillには必要な情報を簡潔に置くよう案内されています。
codex/codex-rs/skills/src/assets/samples/skill-creator/SKILL.md at main · openai/codex
Lightweight coding agent that runs in your terminal - openai/codex
https://github.com/openai/codex/blob/main/codex-rs/skills/src/assets/samples/skill-creator/SKILL.md
似たSkillが複数ある場合はまとめ、SKILL.mdが長くなってきたら詳細資料を別ファイルへ移します。Skillを使ったときに必要な情報だけ読める状態にしておくと、入力を増やしにくくなります。
MCPや外部機能は使うものに絞る
Codexに外部機能を追加すると、モデルは「何ができる機能なのか」「どんな引数を渡すのか」を理解する必要があります。
MCPでGitHub、Slack、データベース、ブラウザなどを大量に接続している場合、それらの説明もモデルが扱う情報になります。
普段使わないMCP serverは常時有効にせず、作業に必要なものを残します。選択肢が少ない方が、モデルがどの機能を使うか判断する負担も小さくなります。
外部機能そのものの制御については、別の記事でResponses APIのallowed_toolsなどを扱っています。
OpenAI APIでAIが使えるツールを制限する。「使うな」とプロンプトに書くだけで安全なのか？ | kuromica
OpenAI APIでAIに複数のツールを使わせるとき、プロンプトで「使うな」と書くだけで十分なのか。tool_choiceやallowed_tools、Function Callingを使い、AIが使えるツールと実際に実行してよい操作を分けて考えます。
https://kuromica.com/blog/openai-api-tool-control/
読むファイルと検索範囲を最初に伝える
Codexは必要なコードを探すためにrepositoryを検索します。対象が分かっている作業では、その場所を最初に伝えると探索を減らせます。
例えば、
認証処理を調べてより、
src/auth/session.ts と src/auth/token.ts を確認して、
refresh tokenの更新処理を調べての方が開始地点が明確です。
原因が別の場所にあればCodexは追加で調べます。それでも、分かっている情報を最初から渡しておけば、最初の広い検索を省けることがあります。
コマンドやテストの結果は必要な範囲だけ読む
コマンドの出力もモデルへ渡す情報です。
例えばbuild logが数千行あると、そのまま読むだけで入力Tokenが増えます。エラーを探したいなら、ログ全体よりエラー周辺を取り出す方が効率的です。
rg -n "error|failed" build.logテストも同じです。失敗しているテストが分かっているなら、そのテストだけを実行できます。git diffも対象ファイルを指定できますし、大きなJSONなら必要なfieldだけ取り出せます。
必要な情報まで削ると再調査が増えるので、エラーの前後を含めるなど、原因を追える範囲は残します。
前の作業を使わないなら新しいスレッドにする
長いスレッドでは、それまでの会話や作業内容も次の判断材料になります。
build errorの修正が終わった後に、まったく関係のない記事レビューやCSS修正を続けるなら、新しいスレッドへ分けた方が履歴を小さくできます。
前の作業を引き継ぐ必要があるときは同じスレッド、関係がなければ新しいスレッド、と考えるだけで十分です。
推論Tokenは仕事の難しさに合わせる
モデルが答えを出すまでに考える処理にもTokenが使われます。OpenAI APIではこの量をreasoning.effortという設定で調整できます。
GPT-5.6では、none、low、medium、high、xhigh、maxが用意されています。Codexでもモデルや推論の強さを選べます。
Model guidance | OpenAI API
Compare model features, migration guidance, and prompting best practices across OpenAI models.
https://developers.openai.com/api/docs/guides/latest-model
カテゴリ分類や単純な変換、場所が分かっている小さな修正なら、低めの推論設定から使えます。原因不明の不具合や複数ファイルにまたがる設計変更では、推論を強くする意味があります。
推論を強くすると、モデルが考えるために使える量も増えます。作業の難しさに合わせて設定することが、そのままToken節約につながります。
出力Tokenは「何を返してほしいか」を決める
最終回答もTokenを使います。
文章を3カテゴリに分類する処理なら、
security / backend / frontend のどれか1つを返すと指定すれば十分です。
コード修正でも、最終回答として欲しいものが「変更内容、テスト結果、未解決事項」なら、その3点を指定できます。必要な形式が決まっている処理では、回答の形を先に決めておくと出力を小さくできます。
Responses APIでは、さらに出力を直接制御する設定があります。text.verbosityは回答の詳しさ、max_output_tokensは生成できるTokenの上限を指定します。Structured Outputsを使えば、決めたJSON形式だけを返すようにもできます。
Create a model response
https://developers.openai.com/api/reference/resources/responses/methods/create
「100文字以内で返して」と指示する方法もありますが、文字数とToken数は同じではありません。APIでToken数そのものを管理したい場合はmax_output_tokensを使います。
これらの設定をTypeScriptから指定する方法は、次の記事で実際に試します。
調査や実行を繰り返すほどTokenは増える
CodexのようなAgentは、一度モデルへ質問して終わるとは限りません。
コードを直すときは、次のような流れになります。
依頼を読む
↓
検索する
↓
検索結果を見て考える
↓
ファイルを読む
↓
内容を見て考える
↓
コードを修正する
↓
テストする
↓
結果を見て考える
↓
回答する検索やファイル読み込みを指示する情報はモデルから出力され、その結果は次にモデルへ渡す入力になります。この往復が増えるほど、合計Tokenも増えます。
探索を減らすには、分かっている情報を最初に渡します。対象ファイル、問題が起きている場所、再現手順、期待する結果、実行してよいテスト、変更してよい範囲などです。
例えば、
build errorを直してより、
pnpm buildで出る型エラーを修正して。
エラーはsite/src/foo.tsのBar型周辺。
関連する型定義はsite/src/types/bar.tsにある。
修正後はpnpm typecheckを実行して。と伝えた方が、Codexは必要な場所から作業を始められます。
repository全体から原因を探す作業では、検索やテストの繰り返しそのものが必要です。文章分類のように入力を見て結果を返すだけの処理なら、この仕組みはかなり大きくなります。
アプリケーションへ組み込む単純処理ではResponses APIを直接使うと、入力、推論、出力を小さく設計できます。CodexとResponses APIの使い分けについては、以前の記事で詳しく扱っています。
Codex CLIでできるならOpenAI APIはいらない？ codex exec・SDK・App ServerとResponses APIを使い分ける | kuromica
Codexをプログラムから呼び出せる現在、Responses APIを直接使うのはどんなときか。codex exec、Codex SDK、App Server、Responses APIを、実装・運用・配布の違いから比較します。
https://kuromica.com/blog/codex-cli-sdk-app-server-responses-api/
同じ入力を再利用できると料金も下げられる
Prompt Cachingは、同じ入力の先頭部分を繰り返し使うときに、その処理結果を再利用する仕組みです。
キャッシュされた入力もTokenとして数えられますが、通常の入力より低い料金が設定されています。2026年9月時点のCodex rate cardでも、InputとCached Inputは別のrateです。
Prompt caching | OpenAI API
Learn how prompt caching reduces latency and cost for long prompts in OpenAI's API.
https://developers.openai.com/api/docs/guides/prompt-caching
そのため、Tokenそのものを減らす方法と、同じTokenを安く処理する方法は分けて考えられます。
モデルへ渡す情報を減らす
→ Token数を減らす
同じ入力をキャッシュから再利用する
→ 料金を下げる大量の処理を急がずまとめて実行できる場合は、Batch APIも料金を下げる選択肢です。Batch APIは1回あたりのToken数を減らす機能ではなく、大量処理の実行方法と料金に関係します。
1万件をAIで処理したい。forループでAPIを呼び続ける設計でいいのか | kuromica
数千・数万件の独立したAI処理をどう実行するか。単純な逐次処理、Queue + Responses API、OpenAI Batch APIを比較し、rate limit、retry、途中失敗、サーバー再起動、料金まで含めて選び方を考えます。
https://kuromica.com/blog/openai-batch-api-large-scale-processing/
Codexで確認したいToken節約ポイント
ここまでの内容を、Codexを使うときの確認項目にすると次のようになります。
□ ローカルで済む処理はローカルで実行する
□ エディタの情報が不要ならCLIを使う
□ 対象ファイルやディレクトリを最初に伝える
□ AGENTS.mdには毎回必要な情報を置く
□ 詳細ドキュメントは必要なときに読む
□ Skillsの重複や巨大化を見直す
□ 不要なMCPや外部機能を有効にしない
□ コマンドやテストの出力を必要な範囲に絞る
□ 前の作業を使わないなら新しいスレッドにする
□ 推論の強さを仕事の難しさに合わせる
□ 最終回答で必要な内容を指定する
□ 単純な処理ならCodexのAgent機能が必要か考える入力を絞るときは、作業に必要な情報を残します。例えばテストの失敗箇所だけを切り出すなら、エラーの前後も含めて原因を追える量を渡します。Codexが同じ情報を取り直さずに済む状態を作る方が、結果としてTokenも抑えやすくなります。
APIまで使うと推論や出力も直接決められる
Codex CLIでは、CodexがAgentとして動くための仕組みを残しながら、プロジェクト側の情報や使い方を調整します。
Responses APIでは、アプリケーション側でさらに細かく決められます。
モデルへ渡す情報
→ アプリ側で決める
考える量
→ reasoning.effort
回答の詳しさ
→ text.verbosity
出力Tokenの上限
→ max_output_tokens
返すデータの形
→ Structured Outputs
使える外部機能
→ リクエストごとに指定
会話履歴
→ アプリ側で管理ここまで制御したくなったら、Codexを節約して使う話から、AI処理そのものを設計する段階に入ります。
次の記事ではTypeScriptからResponses APIを1回呼ぶ最小構成を作り、返ってきた結果と実際に使ったTokenを確認します。
参考資料
OpenAI GPT-5.6 model guidance
推論の強さ、回答の詳しさ、指示や外部機能を小さくするToken効率について。
Model guidance | OpenAI API
Compare model features, migration guidance, and prompting best practices across OpenAI models.
https://developers.openai.com/api/docs/guides/latest-model
Codex IDE extension
開いているファイルや選択中のコードなど、エディタの情報をCodexで利用する仕組みについて。
Codex IDE extension | ChatGPT Learn
Use Codex beside your code and editor context.
https://developers.openai.com/codex/ide
Codex CLI
Codexをターミナルから利用する公式ドキュメント。
Codex CLI | ChatGPT Learn
Use Codex from your terminal and scripts.
https://developers.openai.com/codex/cli
AGENTS.md
Codexがプロジェクトの指示をどのように読み込むかについて。
Custom instructions with AGENTS.md | ChatGPT Learn
Give Codex extra instructions and context for your project
https://developers.openai.com/codex/guides/agents-md
Codex Skill Creator
Skillの情報を段階的に読み込む設計、SKILL.md、参照資料について。
codex/codex-rs/skills/src/assets/samples/skill-creator/SKILL.md at main · openai/codex
Lightweight coding agent that runs in your terminal - openai/codex
https://github.com/openai/codex/blob/main/codex-rs/skills/src/assets/samples/skill-creator/SKILL.md
Responses API
max_output_tokensなど、回答生成時に指定できる設定について。
Create a model response
https://developers.openai.com/api/reference/resources/responses/methods/create
Prompt Caching
同じ入力の先頭部分を再利用する仕組みについて。
Prompt caching | OpenAI API
Learn how prompt caching reduces latency and cost for long prompts in OpenAI's API.
https://developers.openai.com/api/docs/guides/prompt-caching
Codex rate card
CodexのInput、Cached Input、Output Tokenとcredit rateについて。
https://help.openai.com/en/articles/11481834
