はじめに：トークン節約はケチる話ではない
Claude Code（クロード・コード）を使っていると、いつの間にかトークンを大量に消費していることがあります。トークンとは、AIが文章やコードを処理するときの単位で、利用料金はこのトークン量に比例します。会話が長引いたり、AIが多くのファイルを読んだりするほど積み上がっていきます。
ここで多くの人が「では指示を短くすればよい」と考えます。しかし、これは正しくありません。むしろ、指示が短すぎるせいでAIが目的を取り違え、関係のないファイルを次々に読み、動かして、直して、また直して──と作業が膨らみ、結果的に高くついてしまうことがよくあります。
トークン節約の本質は、情報を削ることではありません。AIに見せる情報を設計することです。何を見せ、何を見せないかを決める。それだけで、AIが迷う範囲が狭まり、読み込み・確認・やり直しが減ります。最適なのは「最小のプロンプト」ではなく、誤解なく完了できる最小の文脈です。
いい感じに直して。
auth.ts のログイン関数に、空文字と不正なメール形式のバリデーションを追加してください。
既存のエラーハンドリング方式に合わせてください。
完了条件は、既存テストの通過と、新規テスト2件の追加です。
良い例のほうが文字数は多く、一見すると「無駄」に見えます。しかし、AIが迷う範囲は圧倒的に狭い。対象ファイル、やること、合わせるべき方式、完了条件がすべて指定されているため、AIは余計な探索をしません。読み込むファイルも、確認作業も、手戻りも減ります。短い指示が安いのではなく、迷わせない指示が安いのです。
まず全体像：どの節約術がどのツールに効くか
細かい話に入る前に、代表的な節約術が各ツールに使えるかを一覧にします。○＝そのまま使える、△＝一部・工夫次第、×＝仕組み上使えない、の目安です。仕様は変わりやすいため、重要なものは後半で公式情報の確認先とあわせて解説します。
| 節約術 | Claude Code | GPT / ChatGPT | OpenAI API | Codex | 重要度 |
|---|---|---|---|---|---|
| 目的・対象・完了条件を明確にする | ○ | ○ | ○ | ○ | 高 |
| 長い会話をタスク単位で区切る | ○ | ○ | ○ | ○ | 高 |
| 不要な過去文脈を消す・要約する | ○ | ○ | ○ | ○ | 高 |
| ログやエラーを全文で渡さない | ○ | ○ | ○ | ○ | 高 |
| まず計画だけ出させる | ○ | ○ | ○ | ○ | 高 |
| 出力形式・出力量を指定する | ○ | ○ | ○ | ○ | 中 |
| モデルを使い分ける | ○ | ○ | ○ | ○ | 高 |
| 推論（reasoning / effort）を調整する | ○ | 一部○ | ○ | ○ | 高 |
| コンテキストをクリアする（/clear） | ○ | × | × | × | 高 |
| 会話を圧縮する（/compact） | ○ | × | △ | ○ | 高 |
| CLAUDE.md を整理する | ○ | × | × | × | 高 |
| AGENTS.md を整理する | × | × | × | ○ | 高 |
| Prompt Caching を意識する | △ | △ | ○ | △ | 高 |
| Batch API を使う | × | × | ○ | × | 中 |
| Flex processing を使う | × | × | ○ | × | 中 |
| MCP・ツールを絞る | ○ | △ | △ | △ | 高 |
| Skills を使う | ○ | △ | △ | ○ | 中 |
ChatGPTのような対話サービスは、利用者がAPIの内部設計を触れないため、Prompt CachingやBatch APIは主にOpenAI API利用者向けの話になります。以下、共通する原則から順に見ていきます。
1. なぜAIエージェントはトークンを大量消費するのか
Claude CodeやCodexのような「AIエージェント」は、単に会話文だけをやり取りしているわけではありません。裏側では、次のようなものがすべてコンテキスト（AIが一度に見ている情報のかたまり）に含まれます。
- これまでの会話の履歴
- AIが読んだファイルの中身
- 実行したコマンドの出力やエラーログ
- 使えるツールの定義（どんな道具が使えるかの説明）
- 常時読み込まれる設定ファイル（CLAUDE.md など）
つまり、コードベースを広く探索させるほど、テストログを全文で貼るほど、ツールをたくさん繋ぐほど、コンテキストは膨らみます。さらに、思考する能力を持つモデル（推論モデル）では、答えを出す前に内部で考える「推論トークン」も消費されます。これは画面に表示されないことが多いのに、料金には反映されます。
2. まず押さえる共通原則（すべてのツールに効く）
ここからの5つは、Claude Code・GPT・ChatGPT・Codexのどれでも効く、土台となる考え方です。最新機能を使う前に、まずここを押さえるだけで消費は大きく変わります。
2-1. 目的・対象・完了条件を明確にする
AIに渡すべき最小限は、「何のために（目的）」「どこを（対象）」「どうなれば終わりか（完了条件）」の3点です。これが欠けると、AIは推測で範囲を広げます。
このコードを改善して。
対象は src/payment 配下です。
目的は決済失敗時のエラーメッセージの改善です。
画面の見た目は変えず、文言とログ出力だけ修正してください。
完了条件は、既存テストの通過と、失敗時メッセージの確認です。
2-2. 「全部見て」ではなく、見る範囲を指定する
AIは広く見せるほど安心、ではありません。最初から全リポジトリを読ませるより、対象を絞り、不明点はAIのほうから聞かせるのが効率的です。
まず、変更に必要そうなファイルの候補だけを挙げてください。
まだ実装はしないでください。
足りない情報があれば、ファイル名かコマンドで指定してください。
2-3. 長い会話を続けすぎない
1つの会話で何でも続けると、無関係な情報が最後まで残り、毎回のやり取りに乗り続けます。作業の区切りで会話を分けるのが基本です。ただし、区切る前に「今後も必要な前提」だけを要約させておくのがコツです。
この作業を次のセッションに引き継ぐため、今後も必要な前提だけを10行以内でまとめてください。
実装の履歴ではなく、設計判断・制約・未完了タスクだけを残してください。
2-4. ログ・エラー・テスト結果を全文で渡さない
大量ログの貼り付けは、コスト増の最も典型的なパターンです。必要なのは、失敗したテスト名、エラーメッセージ、関連するスタックトレースの要所だけです。
テストログを全部貼ります。（数千行）
失敗したテスト名、エラーメッセージ、関連スタックトレースの上位30行だけを共有します。
原因の候補を3つに絞ってください。
2-5. まず計画だけ出させる
いきなり実装させると、方向違いだったときの修正が大きくなります。先に方針と変更対象だけ出させ、確認してから実装に進むほうが、結局は安くなります。
まだコードは変更しないでください。
まず、変更方針・対象ファイル・リスク・確認方法を箇条書きで出してください。
Claude Codeには、この「まず計画」を仕組みにしたPlanモードがあります。計画に合意してから実装に移れるため、手戻りを構造的に減らせます。
3. Claude Codeで今日から使える節約術
ここからはClaude Code固有の機能です（コマンド名・挙動は執筆時点＝2026年7月の公式ドキュメントで確認しています。仕様は更新されることがあるため、最新は公式でご確認ください）。
3-1. まず /usage で現状を見る
節約は、現状を見ることから始まります。/usage は、今のセッションで発生している費用や、プランの利用状況を表示します（/cost でも同様の情報が見られます）。有料プランでは、スキル・サブエージェント・MCPサーバーなど、何が使用量を押し上げているかの内訳も確認できます。まず「何が重いのか」を把握しましょう。
3-2. /clear で文脈を切る
別のタスクに移るときは /clear でコンテキストを空にします。「タスクが変わったら /clear」を基本ルールにするだけで、無関係な履歴の持ち越しがなくなります。ただし、重要な設計判断まで消すと困るので、先に要約させてから実行します。なお、CLAUDE.md や自動メモリは /clear 後も読み込まれるため、プロジェクトの前提が消える心配はありません。
3-3. /compact で残す情報を指定する
会話が長くなってきたら /compact で圧縮します。何に焦点を当てて要約するかを指示でき、古いツール出力は落として要点だけを残せます（コンテキストが一杯に近づくと自動でも実行されます）。
/compact 今後も必要な設計判断・制約・未完了タスクに絞って要約してください。
細かい試行錯誤や古いエラーは残さなくて構いません。
3-4. CLAUDE.md を太らせすぎない
CLAUDE.md は、プロジェクトの前提をAIに毎回伝えるための便利な設定ファイルです。ただし毎セッション読み込まれるため、何でも書き込む場所ではありません。常時必要なものだけに絞り、たまにしか使わない手順はSkillsや別ファイルに逃がします。
| 入れるとよいもの | 入れない方がよいもの |
|---|---|
| プロジェクトの目的 | 長大な過去の議事録 |
| 主要コマンド・テスト実行方法 | 一度しか使わない作業メモ |
| コーディング規約・禁止事項 | 詳細すぎる手順書 |
| よく使うディレクトリ構成 | 古いエラー対応の履歴 |
3-5. Skills に分ける
PRレビュー手順、DB移行手順、記事執筆手順のような「たまに使う長い手順」は、Skills（スキル）に切り出します。スキルは、名前と概要だけが常時読み込まれ、実際に使うと判断したときに初めて全文が読み込まれる仕組みです。そのため、スキルが何十個あっても、使わない限りコンテキストはほとんど圧迫しません。「常時は軽く、必要なときだけ重く」を実現する道具です。
3-6. MCPサーバー・ツールを絞る
MCP（外部ツールをAIに繋ぐ仕組み）は便利ですが、繋いだツールの定義そのものがコンテキストを使います。使っていないMCPは無効化しましょう。なお、執筆時点のClaude Codeでは、ツール定義を必要になるまで読み込まない「Tool Search」が既定で働き、多数のツールを繋いでも名前だけを保持して負荷を抑える仕組みが導入されています。とはいえ、そもそも使わないツールは外しておくに越したことはありません。GitHub操作のようにコマンド（gh CLIなど）で足りるものは、MCPを増やさずCLIで済ませたほうが軽い場合もあります。
3-7. Hooks でログを前処理する
Hooks（フック）を使うと、ツール実行の前後に自分の処理を挟めます。テストログやビルドログをそのままAIに渡すのではなく、フックでエラー行や失敗テストだけに絞ってから渡す、といった前処理が可能です。ログの多い大規模プロジェクトほど効果が大きくなります。
3-8. /effort やモデルを使い分ける
すべての作業に最大の推論力は要りません。Claude Codeでは /effort で推論レベル（low〜max など。選べる範囲はモデルにより異なります）を、/model でモデル自体を切り替えられます。軽い文言変更や単純な修正は低めに、設計判断・障害調査・大規模リファクタは高めに、と使い分けます。
3-9. サブエージェントは「節約にも浪費にもなる」道具
サブエージェントは、調査や大量ログの精査といった重い作業を別の作業空間に任せ、メインの会話には要約だけを戻す使い方ができます。メインのコンテキストに探索の残骸が入らないので、長い作業でも会話が重くなりにくいのが利点です。
ただし注意が必要です。サブエージェントは独立したコンテキストで動くため、複数を並列で走らせれば、その分だけ全体のトークン消費は増えます。「文脈を隔離して軽くする道具」であると同時に、「並列でどんどん燃やす装置」でもあるということです。メインの文脈を守る目的で使うのか、単に手を増やしたいのかを意識して使い分けてください。
4. GPT / ChatGPT / OpenAI API / Codex で使える節約術
次に、Claude Code以外での節約術です。考え方は共通しつつ、仕組みが違います。
4-1. ChatGPTでも「新しいチャットに分ける」
Claude Codeの /clear に近い発想です。話題が変わったら新しいチャットに移る。ただしここでも、必要な前提だけを要約してから移すのがコツです。長い1本のチャットを使い続けると、無関係な履歴が毎回の応答に乗り続けます。
4-2. APIでは過去メッセージを毎回投げ続けない
OpenAI APIでは、会話履歴をどこまで送るかは開発者の設計次第です。全履歴を毎回送れば、当然そのぶん高くつきます。必要な履歴だけを要約して送り、重要な状態は構造化して保持するのが定石です。
{
"project_goal": "ログイン画面のバリデーション改善",
"constraints": ["UIは変更しない", "既存のエラーハンドリングに合わせる"],
"current_task": "メール形式チェックの追加"
}
4-3. Prompt Caching を意識する（OpenAI API）
Prompt Caching（プロンプトキャッシュ）は、同じ内容の先頭部分（プレフィックス）を再利用するとき、その部分を割安で処理できる仕組みです。OpenAI APIでは自動で働き、追加のコードは不要ですが、効かせるにはプロンプトの並べ方が重要です。固定の内容を前に、毎回変わる内容を後ろに置きます。
ユーザー入力 → 今日の日付 → 可変データ → 固定ルール → 出力例
固定ルール → 出力例 → 評価基準 → ツール定義
――― ここまで毎回同じ ―――
ユーザー入力 → 今回だけの条件
キャッシュは先頭からの一致でのみ効くため、毎回変わるものを先頭に置くと台無しになります。割引率は執筆時点の公式ガイドで「入力トークン最大90%減」と案内されています（初出時のアナウンスは50%減でした。現行モデルの料金表ではキャッシュ入力が標準入力の約10分の1に設定されています）。数値は時点とモデルで変わるため、検討時は必ず公式の料金ページをご確認ください。
4-4. reasoning effort を調整する
OpenAIの推論モデルでも、内部で考える推論トークンが課金対象になります（表示されなくても料金には乗ります）。reasoning.effort（Chat Completions では reasoning_effort）で推論の深さを調整できます。軽い作業は低め、難しい設計や分析は高め。常に最大にするのは避けます。
4-5. 出力トークンの上限を設定する
「短く答えて」と頼むだけでなく、上限そのものを設定します。max_output_tokens（Chat Completions では max_completion_tokens）で、生成トークンの上限を決められます。これは推論トークンと出力トークンの合計に効くため、推論モデルでは「推論だけで上限に達して、肝心の回答が出ない」ことも起こり得ます。実験開始時は余裕をもった上限にするのが安全です。
4-6. Batch API / Flex processing（即時性が不要な大量処理向け）
分類・要約・評価・大量の下書き生成のように、すぐの応答が要らない処理は、通常APIで1件ずつ処理するのではなく、まとめて安く回せる仕組みを検討します。
- Batch API：非同期でまとめて処理し、同期API比で入出力とも50%割引。完了は最大24時間のウィンドウ内です。
- Flex processing：低優先度で処理する代わりに割安（Batch相当のレート）になるティアです。執筆時点ではベータかつ対応モデルが限られ、混雑時は待たされたり一時的に利用不可（この場合は課金されません）になることがあります。本番のリアルタイム対話には向きません。
4-7. Codex の AGENTS.md を整理する
Codex（OpenAIのコーディングエージェント）では、AGENTS.md がClaude CodeのCLAUDE.mdに近い役割を持ちます。常時の指示は短く保ち、ディレクトリごとに近いAGENTS.mdを使い分けます（現在のディレクトリに近いものが優先されます）。読み込みサイズには上限があるため、長い運用手順を全部詰め込まないのが原則です。Codexにも、コンテキストが上限に近づくと会話を自動要約する圧縮機能や、必要になって初めて全文を読むスキルの仕組みがあります。
5. やってはいけない節約
ここが最も大切です。間違った節約は、節約どころか割高を招きます。
5-1. 必要な前提まで削る
安くしたい一心で説明を省いた結果、AIが前提を誤解して実装を間違える。これは一見の節約が、再修正で高くつく典型です。最低限、目的・対象・制約・完了条件は必ず渡します。
5-2. 何でも小さいモデル・低い推論で済ませる
単純作業なら小さいモデルで十分です。しかし、設計判断や障害調査のような難所で安いモデルや低い推論に落とすと、誤判断が増えて手戻りが発生し、かえって高くつきます。モデルと推論レベルは「安さ」ではなく「タスクの難易度」で選びます。
5-3. ログを削りすぎて原因が見えなくなる
全文を貼るのは論外ですが、逆に削りすぎるのも問題です。エラー行だけでなく、直前に何をしたか、どんな環境か、どうすれば再現するかがないと、AIは原因を推測できず、往復が増えます。
5-4. CLAUDE.md / AGENTS.md を空に近づける
常時指示を減らすのは正しい方向ですが、毎回必要なルールまで消すと、都度説明する羽目になり逆に非効率です。残すべき前提と、切り出すべき手順を分けるのが正解です。
5-5. MCP・ツールを全部切る
MCPを減らすのは有効ですが、必要なツールまで切ると、AIが遠回りをして目的を達成しようとし、結局トークンを使います。よく使うものは残します。
6. 実務でのおすすめ運用
行動に落とせるよう、立場別の運用ルールにまとめます。
個人利用向け
- タスクが変わったら新しいチャット、または /clear
- 会話が長くなったら /compact（残す内容を指定）
- 最初に「目的・対象・完了条件」を書く
- ログは必要な部分だけ渡す
- まず計画だけ出させてから実装させる
- 軽い作業では推論レベルを上げすぎない
開発チーム向け
- CLAUDE.md / AGENTS.md の管理責任者を決める
- 常時読み込む指示は短く保つ
- 詳細な手順はSkillsに切り出す
- MCPサーバーを定期的に棚卸しする
- Hooksでログを整形してから渡す
- 高コストな使い方の事例をチームで共有する
企業導入向け
- まず利用量の可視化から始める（/usage や利用ダッシュボード）
- 部署・用途別にモデル選択のルールを作る
- API利用では Prompt Caching を前提にプロンプトを設計する
- 即時性が不要な大量処理は Batch / Flex を検討する
- 「AIに何を見せるか」を業務設計そのものに組み込む
7. そのまま使えるプロンプト集
最後に、各場面でコピーして使える指示文をまとめます。
まだ実装しないでください。
まず、目的を達成するために必要なファイルの候補、確認すべき点、リスクを箇条書きで出してください。
変更対象は次のファイルに限定してください。
対象外のファイルを変更する必要がある場合は、先に理由を説明してください。
以下は、失敗したテスト名・エラー行・関連スタックトレースのみです。
原因の候補を3つに絞り、追加で必要な情報があればファイル名かコマンドで指定してください。
次のセッションに引き継ぐため、今後も必要な前提だけを10行以内でまとめてください。
残すのは設計判断・制約・未完了タスク・注意点だけです。古いエラーや試行錯誤は不要です。
今回の変更内容・確認できたこと・未確認のこと・次に見るべきことを簡潔にまとめてください。
次回以降も必要な情報だけに絞ってください。
まとめ：トークン節約はAI時代の業務設計である
Claude CodeやGPTのトークン節約は、単なる小技ではありません。AIに何を見せ、何を見せないかを決める設計力です。
曖昧な指示、長すぎる会話、不要なログ、膨らみすぎた設定ファイルは、すべてAIの判断を重くします。一方で、必要な前提まで削れば、誤解や手戻りが増えて逆に高くつきます。大切なのは、最小のプロンプトではなく、誤解なく完了できる最小の文脈です。
トークンを節約できる人は、AIをケチに使っているのではありません。AIに仕事を渡す設計がうまい人です。そしてこの設計力は、コスト削減にとどまらず、AIを前提とした業務そのものの質を左右します。まずは自分の使い方を /usage で一度眺めてみることから始めてみてください。