先に結論｜Codexのトークン消費を抑える7つの打ち手
Codexのトークン消費は、渡す情報の量・返させる情報の量・やり取りの回数の3か所で決まります。効果の大きい順に並べると、打ち手は次の7つです。
- 対象のディレクトリとファイルを指定し、リポジトリ全体を読ませない
- 1つの依頼に1つの目的だけを入れる
- 長くなった対話は要点をまとめ、新しいセッションへ引き継ぐ
- テストやビルドの出力は、失敗した箇所だけを渡す
- 返してほしい形式と分量を先に指定する
- 日常的な作業は軽いモデルへ切り替える
- AGENTS.mdは毎回の依頼に同梱される前提で短く保つ
いずれも設定と渡し方の変更だけで実行でき、コードを書き直す必要はありません。ただし上から順に全部を適用すると、説明不足による作り直しが増えます。自分の使い方に当てはまるものから1つずつ試すほうが、結果的に早く効きます。
関連記事：Codexでできることを一覧で整理｜非エンジニアでも使える活用法まで
打ち手ごとの効きどころと注意点
どの打ち手にも、削りすぎたときに逆効果になる境目があります。手を付ける前に、自分の作業がどの行に当てはまるかを確認してください。
| 打ち手 | 効くのはどんなときか | 削りすぎたときに起きること |
|---|---|---|
| 対象ファイルを指定する | 大きなリポジトリで作業している | 関連ファイルを外すと調査の往復が増える |
| 1依頼1目的にする | 「ついでに」を足しがち | 依頼の数自体は増える |
| 対話を区切って引き継ぐ | 同じ課題で10往復以上している | 要約が雑だと前提が落ちる |
| 失敗箇所だけ渡す | ログやテスト出力が長い | 原因が別の行にあると特定できない |
| 形式と分量を指定する | 説明が長く返ってくる | 指定が細かすぎると指示文が膨らむ |
| 軽いモデルへ切り替える | 抽出・変換・定型作業が多い | 難しい判断では手戻りが増える |
| AGENTS.mdを短く保つ | 長期運用でルールが増えている | 毎回の説明が必要になる |
このうち軽いモデルへの切り替えと対話の引き継ぎは、線の引き方を誤ると節約した分を上回って消費します。
Codexのトークン消費が決まる3か所｜入力・出力・往復
打ち手を選ぶ前に、消費がどこで積み上がっているかを押さえておくと、自分に効く順番がわかります。Codexのようなエージェント型のツールでは、消費は次の3か所に分かれます。
関連記事：Codexの利用制限とは？5時間枠・週次枠の仕組みとリセット・残量確認・対処法
入力｜毎回のやり取りで会話全体が送り直される
最も見落とされやすいのが入力側です。Codexは1回の依頼に対して、その時点までの会話と読み込んだファイルをまとめて渡し直しながら処理を進めます。つまり10往復目の依頼は、10往復ぶんの履歴を抱えた状態で処理されます。
ここで効いてくるのが、最初に何を読ませたかです。リポジトリ全体を読ませたまま対話を続けると、その中身は以降の全ターンに乗り続けます。1つのファイルを直すだけの作業でも、無関係なディレクトリを抱えたまま10回やり取りすれば、その情報を10回払うことになります。
逆に言えば、対話が短いうちは多少雑に渡しても大きな差は出ません。渡す範囲の設計が効いてくるのは、同じセッションを長く続けるときです。
出力｜返ってくる量も消費に乗る
次に出力側です。Codexが返す説明・コード・差分も消費の対象で、出力の単価は入力より高く設定されています。長い解説を毎回添えて返させると、その差は積み上がります。
公式の節約に関する案内でも、対象読者・形式・分量をあらかじめ定義し、必須の作業と任意の改善を分けることが挙げられています（出典: openai.com）。「変更点だけを箇条書きで」「説明は不要」と先に書いておくだけで、返ってくる量は変わります。
往復｜やり直しは同じ入力を何度も払う
3つ目が往復の回数です。1回で意図どおりに動かず、指示を足しては試すことを繰り返すと、そのたびに積み上がった履歴を抱えたまま処理が走ります。やり直しが高くつくのは、この二重構造があるためです。
入力を1割削るより、10往復を5往復にするほうが効果が大きい場面は珍しくありません。節約の打ち手を選ぶときは、往復を減らす施策を優先して検討する価値があります。
入力を絞る｜Codexに渡すファイルとコンテキストの範囲を決める
入力側で効くのは、範囲の指定と、対話をどこで切るかの2点です。
対象のディレクトリとファイルを明示する
依頼文の冒頭で、触ってよい範囲を書いておきます。「src/components/Button.tsxとそのテストだけを見てください」のように、パスまで書いてしまうのが確実です。範囲を書かないと、Codexは関連しそうな場所を自分で探しに行き、その探索ぶんが消費に乗ります。
逆に、関連ファイルを外しすぎると「この関数の定義が見つかりません」と聞き返され、往復が増えます。修正対象と、その対象が参照している定義まではまとめて渡すのが現実的な線です。
「ついでに」を足さずに依頼する
「このバグを直して、ついでにテストも足して、型定義も整理して」とまとめて頼むと、どこかで方針がずれたときに全体をやり直すことになります。目的を1つに絞ると、ずれた時点で気づけるため、巻き戻しの範囲が小さくなります。
依頼の数自体は増えますが、1件あたりの履歴が短く保たれるぶん、合計の消費は下がります。工程を分けて渡す進め方は、大きな改修ほど差が出ます。
AIエージェントを「どう作り、どう育てるか」を、GiftX記事制作エージェントの実物で解説。
長くなった対話は要点をまとめて引き継ぐ
うまく動かず何度も往復しているとき、その履歴のすべてが以降のターンに乗り続けます。ある程度の段階で、わかったことと残っている課題を短くまとめ、新しいセッションで続きから始めると、抱えている履歴をいったん切れます。
引き継ぎのときは、試して駄目だった方法も1行で残しておきます。ここを省くと、新しいセッションで同じ方法をもう一度試され、切った意味がなくなります。
出力を絞る｜CLIログとテスト結果でトークンを使わない
入力と往復に比べると地味ですが、出力側は手間をかけずに効かせやすい領域です。
テストやビルドの出力は失敗した箇所だけを渡す
テストを流した結果をそのまま貼ると、通ったケースの行まで全部が入力に乗ります。失敗したテスト名とエラーメッセージ、該当するスタックトレースの数行に絞って渡せば、判断に必要な情報は変わりません。
ビルドログも同様です。警告が数百行出るプロジェクトでは、エラー行だけを抜き出して渡す運用にしておくと、1回あたりの消費が安定します。実行結果をCodex自身に取らせる場合も、出力の多いコマンドは結果を絞ってから渡すよう依頼文に書いておきます。
ただし、原因が失敗した行以外にあるケースでは、絞りすぎると特定できません。1回で当たらなかったときに範囲を広げる、という順番にしておくと無駄が出ません。
返してほしい形式と分量を先に指定する
何も指定しないと、変更の意図・代替案・今後の改善提案まで添えて返ってくることがあります。読まない説明を毎回受け取っているなら、それはそのまま消費です。
「変更したファイルと差分だけ」「説明は3行以内」のように、形式と分量を依頼文に固定しておきます。必須の作業と、やってもやらなくてもよい改善を分けて書いておくと、任意の部分に手を広げられることも減ります。
毎回同じ指定を書くのが手間であれば、次のセクションのAGENTS.mdに寄せる方法があります。
往復を減らす｜AGENTS.mdとCodexへの指示の書き方
往復の削減は効果が最も大きい一方で、設計に手間がかかる領域です。ここは一度整えると効き続けます。
関連記事：AGENTS.mdとは？Codexにプロジェクト規約を守らせる設定と書き方
AGENTS.mdは毎回の依頼に同梱される前提で短く保つ
AGENTS.mdには、ビルドとテストの実行方法、触ってほしくないディレクトリのように、毎回必要になる前提を書きます。ここに書いた内容は依頼のたびに参照されるため、説明を繰り返す往復が減ります。
一方で、ここに書いたものは毎回の入力に乗り続けます。運用しているうちに例外規定や過去の経緯が積み上がり、数百行になっているケースは珍しくありません。四半期に一度は読み直し、いま効いていない項目を落とす時間を取ってください。
判断の基準は「この行が無いと毎回説明することになるか」です。説明せずに済むなら残し、そうでなければ落とします。設定ファイル側も同じ考え方で、config.tomlにはmodelと権限まわりのapproval_policy・sandbox_modeを置き、細かい調整は必要になってから足す順番にすると肥大化を防げます。
1回で通る指示に何を書くか
往復が増える原因の多くは、完了条件が書かれていないことです。「動くようにして」だけでは、どこまでやれば終わりかがCodex側にも判断できず、確認のやり取りが発生します。
完了条件は、テストが通ること、特定のコマンドが成功すること、のように機械が判定できる形で書きます。あわせて、迷ったときにどちらを選んでほしいか（既存の書き方に合わせる、新しいライブラリは足さない、など）を書いておくと、確認の往復がそのぶん減ります。
確認の往復は設定でも減らせる
実行のたびに承認を求められる設定にしていると、その確認自体がやり取りとして積み上がります。approval_policyとsandbox_modeは安全性に直結する項目なので、範囲を広げる方向の変更は慎重に判断する必要がありますが、作業内容と扱うリポジトリに応じて見直す余地はあります。
モデルとreasoning effortを使い分けてトークンを抑える
設定側で効かせられるのが、モデルと推論の深さです。ここは切り替えるだけなので、手間に対する効果が最も読みやすい領域です。
日常の作業は軽いモデルに切り替える
Codexでは、最難関の複数工程に向くGPT-6 Astra、品質の基準点となる5.6 Sol、能力と速度の均衡を取る5.6 Terra、高速で使用量を抑えやすい5.6 Lunaなどを選べます。公式の節約に関する案内でも、日常的な作業では小さいモデルに切り替えることが推奨されています（出典: openai.com）。
判断は作業の性質で切ります。抽出・分類・変換・定型的な要約のように、正解の形が決まっている作業は軽いモデルで十分です。逆に、曖昧な要件から設計を決める作業や、複数のツールをまたぐ工程では、軽いモデルに任せると手戻りが増え、節約した分を往復で失います。
| 作業の性質 | 向いているモデル | 判断の目安 |
|---|---|---|
| 抽出・分類・変換・定型要約 | 5.6 Luna | 正解の形が最初から決まっている |
| 日々の実装・レビュー | 5.6 Terra | 手順は見えていて、書く量が多い |
| 曖昧な改修・設計判断 | 5.6 Sol | 何を作るかから決める必要がある |
| 複数工程をまたぐ最難関の作業 | GPT-6 Astra | ほかのモデルで完了条件を満たせない |
すべてを軽いモデルに寄せる必要はありません。まずは定型作業だけを切り替え、品質が落ちないことを確認してから範囲を広げる順番が安全です。
reasoning effortは作業の難しさに合わせる
Codexにはモデルとは別に、1回の作業にどれだけ推論を使うかを決めるreasoning effortがあります。モデルが能力や速度の性質を選ぶ軸だとすれば、effortは選んだモデルにどこまで考えさせるかを調整する軸です。
同じモデルでも、範囲が狭く手順が見えている作業はlow、複数の手順をまたぐ作業はmediumやhighというように動かせます。範囲の狭い修正に高いeffortを当て続けると、判断に必要のない検討にまで消費が乗ります。
結果が足りないときは、モデルの能力が不足しているのか、検討に使う手数が足りていないのかを切り分けてください。後者であればeffortを上げるほうが、モデルを上げるより消費を抑えられます。
全国8,000人調査で、AIの活用方法によって生産性向上に約3.8倍の差が生まれることが判明。
チームで使うときにトークン消費を抑える｜手順を共有して同じ失敗を繰り返さない
ここまでの打ち手は、個人が自分の使い方を変えるものでした。複数人で使っている場合、同じ工夫を各自が別々に発見し直している状態になりやすく、全体の消費は思ったほど下がりません。
個人の工夫はチームには伝わらない
うまくいった依頼文や、対象ファイルの渡し方は、多くの場合その人の手元にしか残りません。隣の席の人が同じ作業で10往復している状況は、本人からは見えないためです。
効くのは、成功した依頼文を手順として書き出し、誰が実行しても同じ流れになる形に落とすことです。AGENTS.mdに書ける前提はそちらへ寄せ、作業ごとの進め方は共有の手順として残します。
手順を共有して手戻りを減らした自社事例
GiftXでは、業務で使うプロンプトや定型フローを「スキル」として整備し、誰が実行しても同じ品質になる形で共有しています。改善のたびに手順へ書き戻すことで、個人メモに散らばっていたノウハウをチームの資産に移す運用です。
例えば新しく参加したメンバーが同じ作業に入るとき、整備前は手探りで試行錯誤する時間が必要でしたが、整備後は既存の手順から始められるようになりました。立ち上がりにかかる期間が半分程度に収まったケースもあり、試行錯誤の往復がそのまま消費に乗るCodexのようなツールでは、この差は枠の減り方にも表れます。
どの業務から手順化するかの選び方は「職種別AI活用事例集」にまとめています。
AIエージェントを業務に組み込むときに陥りがちな3つの落とし穴
トークンの使い方を整えることは、AIエージェントを業務に組み込む工程の一部です。ここでつまずく形はおおむね決まっています。
落とし穴1｜いきなり全ての工程を任せようとする
設計から実装、テスト、デプロイまでを一度に任せようとすると、1回の依頼が肥大化し、どこでずれたのかも追えなくなります。ずれるたびに全体をやり直すことになり、消費と時間の両方を失います。
落とし穴2｜壮大な自動化の構想から考えて手が止まる
「開発全体をどう自動化するか」から入ると、決めることが多すぎて着手できません。検討している間は成果が出ないため、費用だけが積み上がっていきます。
落とし穴3｜既製のチャット型AIでは自社の手順を渡しきれない
汎用のチャット型AIは手軽に試せますが、自社の設計方針や禁止事項を毎回説明し直す必要があります。業務フローに組み込める水準まで持っていくには、前提を持たせたうえで動かす仕組みが要ります。
スモールスタートで1業務をAIエージェントに任せる
避け方は共通しています。まず1つの業務を選び、そこだけを任せられる状態にしてから範囲を広げることです。対象が1つなら完了条件も決めやすく、うまくいかなかったときの巻き戻しも小さく済みます。
トークンの節約も同じで、全ての打ち手を一度に適用するのではなく、自分の使い方にいちばん効く1つから始めるほうが、効果を確かめながら進められます。GiftXでは、こうしたスモールスタート前提の取り組みを1業務単位から伴走支援しています。詳細は AIエージェント構築支援サービス をご覧ください。
Codexのトークン消費を抑える方法に関するよくある質問
Codexのトークン使用量はどこで確認できますか？
Codex CLIのセッション中に/statusと入力すると、動いているモデルと現在のトークン使用量、残りのコンテキスト容量が表示されます。アカウント全体の使用量は/usageで、週単位の消費は/usage weeklyで確認できます。毎回入力するのが手間であれば、/statuslineでフッターに常時表示させる方法もあります。
reasoning effortを下げると品質は落ちますか？
作業の性質によります。範囲が狭く手順が見えている作業では、下げても結果は変わらないことがほとんどです。一方で、複数の手順をまたぐ作業や判断を伴う改修では、下げると必要な検討が省かれ、やり直しで結果的に消費が増えます。まず定型作業だけで試し、品質を確認してから範囲を広げてください。
ChatGPTで下調べしてからCodexに渡すと節約になりますか？
方針の検討や要件の整理を別の場所で済ませ、確定した指示だけをCodexに渡す進め方は、往復を減らす方向に働きます。ただし前提の説明が二重になると手間が増えるため、コードを読まないと決められない判断まで切り離すのは向きません。
節約してもすぐ枠に当たる場合はどうすればいいですか？
まず、どの枠に当たっているのかを/usageで確認してください。短い枠に当たっているだけなら時間の経過で回復しますが、週単位の枠に達している場合は当日中に戻らないこともあります。渡し方の見直しで往復が半分近くに減る余地がまだ残っているかを確認し、それでも足りなければプランの見直しを検討する順番になります。
まとめ
Codexのトークン消費は、渡す情報の量・返させる情報の量・やり取りの回数の3か所で決まります。効果が大きいのは往復の削減で、完了条件と迷ったときの判断基準を依頼文に書いておくだけでも、確認のやり取りは減ります。入力側では対象ファイルの指定と対話の区切り方、出力側では形式と分量の指定が効きます。
設定面では、定型作業を軽いモデルへ切り替え、reasoning effortを作業の難しさに合わせるだけで消費の減り方は変わります。AGENTS.mdは毎回の入力に乗り続けるため、短く保つ運用にしてください。
打ち手は7つ挙げましたが、全部を一度に適用する必要はありません。自分の使い方にいちばん効く1つを選び、前後の消費を比べながら範囲を広げていくほうが、品質を落とさずに枠を持たせられます。
AI活用の伴走支援をご検討の方へ
本記事で紹介したAIエージェントの活用に向けて、自社の業務でも具体的に進めたい・相談したいとお考えの方は、ぜひGiftX AIエージェント構築支援までお問い合わせください。
GiftX AIエージェント構築支援では、貴社の業務に合わせて1業務単位のスモールスタートから本番運用まで、AIエージェント構築をワンストップで支援します。ユースケースの洗い出しから、PoC、本番運用、社内ナレッジ化まで伴走します。
AI活用にご関心のある方は、ぜひ一度ご相談ください。
▶ GiftX AIエージェント構築支援の詳細・お問い合わせはこちら
