Claude Codeのトークンを節約する9つの方法：研修と実務で使える整理
山崎講師こんにちは。ゆうせいです。
Claude Codeを使い始めると、多くの方が同じ壁にぶつかります。使用量の上限に、思ったより早く到達してしまうという問題です。上位プランへの変更や追加購入という選択肢はありますが、その前にできることがあります。実は、消費量の大半は、使い方の工夫で削減できる部分です。本記事では、トークン消費を抑える方法を九つ、六つの原則に整理して解説します。個別のテクニックとして覚えるより、なぜ消費が増えるのかという原因から理解したほうが、応用が利きます。研修で新人に教える際の順序についても、最後に触れます。
結論：消費が増える四つの原因を潰す
先に全体像を示します。
トークン消費が増える原因は、大きく四つです。
第一に、毎回読み込まれるものが重いこと。
第二に、一度に渡す仕事が大きすぎること。
第三に、指示が曖昧で、やり直しが発生すること。
第四に、AIに任せる必要のないことまで任せていること。
これから紹介する九つの方法は、いずれかの原因に対応しています。原因と対策の対応を意識しながら読み進めてください。
原則1：毎回読まれるものを軽くする
方法1：設定ファイルをコンパクトに保つ
Claude Codeには、プロジェクトの前提を伝えるための設定ファイルがあります。CLAUDE.mdという名前のファイルです。
ビルドコマンド、コーディング規約、ディレクトリ構成といった、毎回説明したくない情報をここに書いておくと、セッションの開始時に自動的に読み込まれます。
便利な仕組みですが、ここに落とし穴があります。
このファイルは、毎回のセッション開始時に読み込まれます。つまり、まだ何のタスクも与えていない段階で、すでにトークンを消費しているのです。
大量の情報を詰め込めば、その分だけ、毎回のセッションが重くなります。
どれくらいに抑えるべきか
公式のドキュメントでは、簡潔に保つことが推奨されています。目安として200行未満という数字が示されています。
なお、この数値や推奨の表現は更新される可能性がありますので、実際の運用にあたっては公式ドキュメントで最新の記述を確認してください。
詳細な仕様はどこに置くか
では、書き切れない情報はどうすればよいのでしょうか。
答えは、別ファイルに分けて、必要なときだけ読ませることです。
プロジェクトの直下に、ドキュメント用のディレクトリを作ります。docsという名前が一般的です。
その配下に、仕様ごとにファイルを分けて置きます。
project-root/
├── CLAUDE.md
└── docs/
├── overview.md
├── domain-rules.md
├── data-source.md
└── tasks.md
そして、CLAUDE.mdからは、必要に応じてこれらを参照する形にします。
Claude Codeには、他のファイルを取り込む記法があります。アットマークに続けてパスを書くと、そのファイルを参照できます。
詳細な仕様は @docs/overview.md を参照してください。
ドメインのルールは @docs/domain-rules.md にあります。
この書き方の利点は、Claudeがタスクに必要だと判断したときだけ読みに行く点です。毎回すべてを読み込む必要がなくなります。
分割の効果を具体的に考える
たとえば、Eコマースサイトを開発しているとします。
販売ページの仕様、顧客管理の仕様、在庫管理の仕様。これらが一つのファイルに書かれていれば、販売ページだけを実装する場面でも、すべてが読み込まれます。
ファイルを分けておけば、今回は販売ページだけだから他は不要、という状況を作れます。
必要なときに、必要な情報だけを読む。この設計にするだけで、無駄な消費を大きく減らせます。
研修で伝えるべき点
新人には、次の判断基準を伝えてください。
毎回のセッションで必要な情報は、CLAUDE.mdに書く。
特定の作業のときだけ必要な情報は、別ファイルに分ける。
この切り分けができるかどうかが、運用の質を決めます。
原則2：一度に渡す仕事を小さくする
方法2：実装を小分けにする
大きなタスクをまとめて渡すのは、避けてください。
アプリを全部作って、この機能を全部お願い、といった指示です。
問題は二つあります。
一つ目は、読み込むファイルが増えることです。タスクが大きいほど、参照すべき情報も増えます。
二つ目は、精度が下がることです。複雑なタスクをまとめて実行させると、途中で判断がずれることがあります。
そして、ずれた分を修正するやり取りが、さらにトークンを消費します。結局、小分けにするより高くつくのです。
タスクを管理するファイルを作る
小分けにするには、何が済んでいて何が残っているかを、把握しておく必要があります。
そこで、タスク管理用のファイルを用意します。
# 実装済みの機能
- ユーザー登録
- ログイン、ログアウト
- 商品一覧の表示
# 今後追加する機能
- カート機能
- 決済処理
- 注文履歴の表示
一つ実装し終えたら、実装済みの側に移します。
このサイクルで管理すると、次のセッションを始めるときに、余計な文脈を持ち込まずに済みます。
なぜ文脈が持ち込まれると困るのか
Claude Codeが一度に扱える情報量には、上限があります。これをコンテキストウィンドウと呼びます。
人間で言えば、短期記憶のようなものです。
会話が長くなるほど、この領域が埋まっていきます。埋まるほど、重要な指示が埋もれ、判断の精度が落ちます。
タスクを細かく区切り、セッションも区切る。これにより、一回あたりの消費を抑えられます。
原則3：溜まったものを捨てる
方法3：会話履歴を圧縮する
セッションを区切るといっても、作業の途中で完全にリセットしたくない場合もあります。
そのときに使うのが、圧縮のコマンドです。
/compact
これを実行すると、それまでの会話履歴が要約され、コンテキストが大幅に削減されます。
公式の説明では、相当な削減効果が見込めるとされています。
いつ打つのか
使いどころは、二つあります。
一つ目は、同じセッションで長時間作業を続け、応答の精度が落ちてきたと感じたときです。
二つ目は、古い方針での会話を整理して、新しい方針に切り替えたいときです。
なお、詰まってから打つより、予防的に打つほうが効果的です。集中して作業しているときは、20分から30分ごとに実行する、という運用をしている方もいます。
何を残すかを指示できる
引数を付けると、圧縮の際に何を優先して残すかを指定できます。
/compact 認証機能の変更点と残タスクに絞って要約して
このように書けば、必要な部分を保持したまま、他を圧縮してくれます。
漫然と圧縮するより、精度の高い要約が得られます。
原則4：手戻りを減らす
ここからは、やり直しによる無駄な消費を防ぐ方法です。
方法4：計画を先に立てさせる
Claude Codeには、実行はせず計画だけを立てるモードがあります。プランモードと呼ばれるものです。
このモードでは、ファイルの変更やコマンドの実行を行いません。こういう手順で進めます、という計画を提示するだけです。
なぜこれが節約になるのか
いきなり実装させると、方針がずれていた場合、書かれたコードがすべて無駄になります。
計画の段階でずれに気づけば、修正のコストは文章のやり取りだけで済みます。
実装をやり直すより、はるかに安いのです。
使うべき場面
すべてのタスクで使う必要はありません。目安を示します。
三つ以上のファイルにまたがる変更であれば、使ってください。
設計の判断が必要な機能実装であれば、使ってください。
アーキテクチャに影響する変更であれば、使ってください。
一方、軽微な修正であれば、計画を立てるほうが手間です。そのまま実装させて構いません。
方法5：指示を具体的に書く
曖昧な指示と具体的な指示では、消費量に大きな差が出ます。
理由は明快です。曖昧な指示を受けると、Claudeはすぐに行動に移れません。どのファイルのことか、何をすればよいのかを探すため、関連しそうなファイルを次々と読みに行きます。
この探索が、消費を押し上げます。
悪い例と良い例
ログイン処理の修正を依頼する場面で考えます。
避けるべき書き方は、次のようなものです。
login.tsのバリデーション周りの処理を改善して
問題は二つあります。login.tsがどこにあるか分かりません。そして、改善という言葉が何を指すのか分かりません。
推奨する書き方は、次のようなものです。
@src/features/auth/login.ts のバリデーション処理について、
メールアドレスの形式チェックが正規表現で行われていますが、
全角文字が通ってしまう問題があります。
全角を含む場合は弾くように修正してください。
ファイルのパスを明示しているため、探す必要がありません。
そして、何をどう直すのかが具体的です。
具体的に書くための三つのコツ
第一に、インポート記法でファイルを指定してください。アットマークとパスを書くだけで、探索の手間がなくなります。
第二に、可能であれば関数名や行数も指定してください。
第三に、これが最も重要ですが、なぜそうしてほしいのかを添えてください。
どう変えるかだけでなく、なぜ変えるのかを伝えると、Claudeが文脈を理解しやすくなります。結果として、一回で意図どおりの実装が返ってくる確率が上がります。
複数の問題があるファイルの場合
一つのファイルに複数のエラーがある場合、まとめて直してと指示するのは避けてください。
このファイルのエラーを全部直して
この書き方だと、Claudeはすべてのエラーを調査する必要があります。
代わりに、一つに絞ってください。
@src/components/UserForm.tsx で、フォーム送信後に
入力値がリセットされない問題を修正してください。
一つずつ片付けるほうが、結果的に速く、安くなります。
原則5：仕事の割り当てを変える
ここからは、そもそもAIに任せるべきかを見直す方法です。
方法6：モデルを使い分ける
Claude Codeでは、複数のモデルを選べます。性能の高いモデルほど、消費するトークンも多くなります。
したがって、タスクの難易度に応じて使い分けることで、消費を抑えられます。
使い分けの考え方
設計や複雑な実装が必要なタスクには、性能の高いモデルを使ってください。
通常の実装やドキュメント作成には、中位のモデルで足ります。
単純な定型作業や、繰り返し実行するサブタスクには、軽量なモデルで十分です。
モデルの切り替え方
コマンドラインで使っている場合は、次のコマンドで選択できます。
/model
デスクトップアプリの場合は、画面上のモデル選択欄から変更できます。
注意点
モデルの名称、性能、消費量の比率は、更新されることがあります。
特に、消費量の倍率については、具体的な数値を覚えるより、公式のドキュメントで都度確認することを推奨します。
利用可能なモデルの一覧についても、同様です。
方法7：軽微な修正は自分でやる
当たり前のようですが、見落とされがちな点です。
自分でコードを書く分には、トークンを消費しません。
タイポの修正、コメントの追加、変数名の変更。こうした軽微な作業は、自分でやったほうが速く、しかも無料です。
開発環境の選び方
コーディングができる方であれば、エディタのターミナル上でコマンドライン版を使うことを推奨します。
理由は二つあります。
一つ目は、機能面です。デスクトップ版やウェブ版では、一部の機能が制限されていたり、新機能の反映が遅れたりすることがあります。コマンドライン版であれば、すべての機能を使えます。
二つ目は、修正のしやすさです。エディタのターミナルで動かしていれば、Claudeが変更したファイルの差分が、エディタ上でリアルタイムに確認できます。
直すべき箇所をすぐに見つけて、自分で直せます。
補完系のツールと組み合わせる
コード補完を行うAIツールと併用するのも有効です。
補完や軽微な修正は補完ツールに任せ、Claude Codeは複雑な実装や設計判断に絞って使う。この役割分担ができます。
方法8：繰り返す処理はスクリプト化する
これも、見落とされやすい観点です。
毎回Claudeに頼んでいるその処理は、プログラムで書けるものではないでしょうか。
ファイルのフォーマット、データの変換、ファイルの結合。こうした処理は、一度スクリプトにしてしまえば、その後は何度実行してもトークンを消費しません。
具体例
分割して作成したマークダウンファイルを、最後に一つに結合するという作業を考えます。
毎回Claudeに頼めば、毎回消費します。
シェルスクリプトにしておけば、実行するだけです。
#!/bin/bash
# 分割されたマークダウンファイルを1つに結合する
OUTPUT="merged.md"
> "$OUTPUT"
for file in chapters/*.md; do
cat "$file" >> "$OUTPUT"
echo "" >> "$OUTPUT"
done
echo "結合が完了しました: $OUTPUT"
このスクリプト自体を、最初にClaudeに書いてもらっても構いません。
一度書いてしまえば、あとは何度でも無料で実行できます。
判断の基準
毎回同じことを頼んでいると気づいたら、それはスクリプト化の候補です。
処理の内容が固定されていて、判断を伴わないもの。これが対象になります。
原則6：出力を絞る
最後は、やや技術的な方法です。
方法9：コマンドの出力を圧縮する
見落とされがちな消費源として、コマンドの実行結果があります。
Claude Codeは、コードを書くだけでなく、テストを実行したり、ビルドしたり、バージョン管理のコマンドを走らせたりします。
このとき、コマンドの出力結果が、そのままコンテキストに追加されていきます。
何が無駄なのか
たとえば、100件のテストがあるプロジェクトで、テストを実行させたとします。
通ったテスト100件分の実行ログ、各テストの実行時間、カバレッジのレポート。これらがすべて積み上がります。
しかし、判断に必要な情報は、何が失敗したかだけです。
通ったテストの詳細なログを、覚えさせる必要はありません。
圧縮ツールという解決策
この問題に対応するため、コマンドの出力を圧縮するツールが公開されています。
Claude Codeとコマンドの間に入り、出力をフィルタリングしてから渡す、という仕組みのものです。
コメント行、空白、重複行、冗長なログを取り除き、判断に必要な情報だけを残します。
導入にあたっての注意点
こうしたツールは、有志によって開発されているものが多く、仕様や導入方法が変わる可能性があります。
導入を検討する際は、次の点を確認してください。
第一に、公式のリポジトリで、最新の導入手順を確認すること。
第二に、同名の別パッケージが存在する場合があるため、正しいものをインストールしていること。
第三に、業務で使う場合は、社内のセキュリティ方針に照らして問題がないかを確認すること。
第四に、導入後、実際に削減効果が出ているかを測定すること。
ツールに頼らない代替手段
外部ツールの導入がためらわれる場合、指示の工夫でもある程度は対処できます。
たとえば、テストの実行を依頼する際に、失敗したものだけを報告するよう指示する方法があります。
テストを実行してください。
出力が長くなるため、失敗したテストの内容だけを報告し、
成功したテストの詳細ログは不要です。
また、コマンド自体にオプションを付けて、出力を絞る方法もあります。多くのテストツールには、静かに実行するためのオプションが用意されています。
九つの方法を、原因別に整理する
ここまでの内容を、一覧にまとめます。
| 原因 | 方法 | 効果の大きさ |
|---|---|---|
| 毎回読まれるものが重い | 設定ファイルを軽く保つ | 大 |
| 毎回読まれるものが重い | 仕様を別ファイルに分ける | 大 |
| 仕事が大きすぎる | 実装を小分けにする | 大 |
| 仕事が大きすぎる | タスク管理ファイルで進捗を追う | 中 |
| 履歴が溜まっている | 会話履歴を圧縮する | 大 |
| 手戻りが発生する | 計画を先に立てさせる | 中 |
| 手戻りが発生する | 指示を具体的に書く | 大 |
| 割り当てが不適切 | モデルを使い分ける | 中 |
| 割り当てが不適切 | 軽微な修正は自分でやる | 中 |
| 割り当てが不適切 | 繰り返す処理をスクリプト化する | 中 |
| 出力が冗長 | コマンド出力を圧縮する | 中から大 |
効果の大きさは、あくまで目安です。プロジェクトの性質によって変わります。
研修で教える順序
新人エンジニアに教える場合、九つを一度に伝えるのは無理があります。段階を分けてください。
第一段階：まず教える三つ
初日に伝えるべきは、次の三つです。
指示を具体的に書くこと。
タスクを小分けにすること。
会話履歴を圧縮するコマンドがあること。
この三つだけで、消費量はかなり改善します。しかも、特別な設定が不要で、すぐに実践できます。
第二段階：プロジェクトに入ってから
実際のプロジェクトに配属されたら、次を教えます。
設定ファイルの整備と、仕様の分割。
計画を先に立てさせるモードの使い方。
モデルの使い分け。
これらは、プロジェクトの文脈があって初めて意味を持つ内容です。
第三段階：慣れてきたら
ある程度使いこなせるようになったら、次を伝えます。
軽微な修正は自分でやるという判断。
繰り返す処理のスクリプト化。
コマンド出力の圧縮。
特に二つ目は、そもそもAIに任せるべきかを見極める力を育てます。新人が最も伸びる観点です。
教えるときの注意点
節約の話ばかりすると、萎縮させてしまいます。
使うことをためらわせるのではなく、賢く使えばもっと使える、という伝え方をしてください。
節約は目的ではなく、より多くの仕事をこなすための手段です。
実務での注意点
注意点1：仕様は更新される
Claude Codeは、更新が非常に速いツールです。
コマンドの名前、利用できるモデル、推奨される設定。いずれも変わる可能性があります。
本記事の内容も、数か月後には一部が古くなっているかもしれません。
最新の情報は、公式のドキュメントで確認してください。
注意点2：測定してから判断する
どの方法が効いているかは、プロジェクトによって異なります。
削減できたつもりで、実は変わっていないということもあり得ます。
コマンドの使用量を確認する手段が用意されていますので、実施の前後で比較してください。
注意点3：生成されたコードは必ず確認する
これは、節約の話を超えた、根本的な注意点です。
指示を具体的にしても、計画を立てさせても、生成されたコードの確認は必要です。
トークンを節約した結果、レビューを省略して不具合を出しては、本末転倒です。
理解度を確認する問い
研修で使える問いを、いくつか挙げます。
設定ファイルに大量の情報を書くと、なぜトークン消費が増えるのでしょうか。
大きなタスクをまとめて渡すと、消費が増える理由を二つ挙げてください。
曖昧な指示が消費を増やす仕組みを、Claudeの動きに即して説明してください。
繰り返し頼んでいる処理をスクリプト化すべきか、どのように判断すればよいでしょうか。
まとめ
Claude Codeのトークン消費が増える原因は、四つに整理できます。毎回読まれるものが重いこと、一度に渡す仕事が大きすぎること、指示が曖昧で手戻りが発生すること、そしてAIに任せる必要のないことまで任せていることです。
毎回読まれるものを軽くするには、設定ファイルを簡潔に保ち、詳細な仕様は別ファイルに分けて、必要なときだけ参照させる設計にします。
一度に渡す仕事を小さくするには、実装を機能単位で区切り、タスク管理ファイルで進捗を追います。会話が長くなったら、圧縮のコマンドで履歴を要約します。
手戻りを減らすには、大きな変更の前に計画を立てさせ、指示にはファイルのパスと、何をどう変えるか、そしてなぜ変えるかを具体的に書きます。
割り当てを見直すには、タスクの難易度に応じてモデルを使い分け、軽微な修正は自分で行い、繰り返す処理はスクリプトにします。
出力を絞るには、コマンドの実行結果を圧縮する方法があります。外部ツールを使う方法と、指示やオプションで対処する方法があります。
研修で教える際は、三段階に分けてください。まず具体的な指示、小分けの実装、履歴の圧縮という、すぐ実践できる三つを教えます。プロジェクトに入ってから設定ファイルの整備とモデルの使い分けを、慣れてきたら自分でやるべきかの判断とスクリプト化を教えます。
次のステップとして、まずは自分のプロジェクトで、設定ファイルの行数を数えてみてください。200行を大きく超えていれば、分割の余地があります。あわせて、直近の指示を見返し、ファイルのパスを明示していたか、なぜを添えていたかを確認してみてください。この二点を改善するだけでも、体感できる差が出るはずです。
なお、Claude Codeの仕様や利用できるモデルは更新が続いています。具体的な数値や機能名については、公式ドキュメントで最新の情報を確認してください。
セイ・コンサルティング・グループでは新人エンジニア研修のアシスタント講師を募集しています。
投稿者プロフィール
