AI Tools 2026年6月11日 (更新: 2026年8月28日)

10-2 Claude Code のトークン節約術｜同じ成果をより安く出す

Claude Code のトークン消費を減らす実践テクニックを解説。セッションの区切り方、/clear と /compact の使い分けと圧縮率の実測手順、ファイル指定の工夫、長文の渡し方、単価差5倍のモデル使い分けまでを扱います。

#Claude Code #カリキュラム #トークン節約 #コンテキスト管理 #コスト最適化

難易度前提知識ゼロでも読めます所要時間約 30 分種別学習コース

先に読む10-1 Claude Code の料金の仕組み｜トークン課金を理解する

このレッスンでわかること

前のレッスン 10-1 で、コストの正体は「トークン」であり、長い会話ほどコンテキストが膨らんで高く・遅くなる、という仕組みを学びました。このレッスンでは、その仕組みを踏まえた実践的な節約術を扱います。

このレッスンを読み終えると、次の5つができるようになります。

タスクごとにセッションを区切る判断
/clear と /compact を場面に応じて使い分け、効果を自分で測る
必要なファイルだけを読ませる指示の出し方
長文資料を渡すときの事前の工夫
単価が5倍違うモデルを、タスクの重さで使い分ける

大事なのは、節約のために成果の質を落とすことではありません。目指すのは「同じ成果を、より少ないトークンで出す」こと。料理でいえば、味を落とさずに食材の無駄をなくすイメージです。むしろコンテキストが整理されるぶん、AIの応答の質が上がることも珍しくありません。

このレッスンでは、それぞれの節約術に「何を見れば効果がわかるか」を添えています。数値は 2026年8月28日時点の公式情報にもとづきます。

節約術1：タスクごとにセッションを区切る

最も効果が大きく、しかも簡単なのがこれです。10-1 で見たとおり、会話の履歴は毎回まるごと送り直されます。つまり、**関係ない過去の話題は「運び続けるだけの荷物」**です。

判断基準はシンプルです。

前の会話の文脈が必要 → 同じセッションを続ける
前の会話と関係ない新しいタスク → 新しいセッションを始める

【Bad】
1つのセッションで「売上データの集計」→「プレゼン資料の構成案」→「英文メールの添削」
→ メール添削の時点で、売上データやプレゼンの履歴を毎回送り続けている

【Good】
「売上データの集計」が終わったら区切り、「プレゼン資料の構成案」は新セッションで開始
→ 各タスクのコンテキストが最小限に保たれる

「セッションを切ると、せっかくのやりとりが消えてもったいない」と感じるかもしれません。しかし残しておきたい結論があるなら、ファイルに書き出させてから区切るのが正解です。「ここまでの決定事項を notes.md にまとめて」と頼めば、次のセッションではそのファイルだけ読ませれば済みます。会話履歴を引きずるより、はるかに軽くて確実です。

なお /clear で会話を消しても、以前の会話が削除されるわけではありません。/resume で復元できますし、CLAUDE.md と auto memory は保持されて自動で読み直されます。「切ると失う」という心配は、実際には当たりません。

効果の測り方：新セッションの最初のやりとりの直後に /usage を実行し、入力トークン数を控えます。長く続いたセッションでの1回あたりの入力量と比べると、区切ったことで何トークン浮いたかが数字で出ます。

節約術2：/clear と /compact の使い分け

ここがこのレッスンの中心です。セッション途中でコンテキストを整理する手段は2つあります。

/clear（別名 /reset / /new）：空のコンテキストで新しい会話を始める
/compact：それまでの会話を要約してコンテキストを解放する。要約時にどこへ焦点を当てるかをオプションで指示できる

公式が明言している、意外な事実

多くの人が「/compact のほうが賢くて得」と思っていますが、公式ドキュメントは次の点を注記しています。

/compact は、それ自体がコンテキストを読み込んで要約するため「大きなリクエスト」になる。コスト面では /clear のほうが安い。

要約を作るには、要約対象の会話を全部読ませる必要があります。つまり /compact は「膨らみきったコンテキストを丸ごと入力するリクエストを1回追加で発生させる」操作です。10-1 の単価表を思い出すと、これは入力トークンと出力トークンの両方を消費する処理です。

したがって判断はこうなります。

状況	使うコマンド	理由
前のタスクが完了し、次は別件	`/clear`	過去の文脈が不要。要約する価値がないので、最も安い
同じタスクの続きだが、会話が長くなってきた	`/compact`	要約1回分のコストを払ってでも、文脈を引き継ぐ価値がある
会話が脱線して収拾がつかなくなった	`/clear` ＋指示の出し直し	混乱した履歴を要約しても混乱を引き継ぐだけ
残したい結論がある	ファイルに書き出してから `/clear`	要約より確実で、以降のコンテキストも軽い

**「迷ったら /compact」ではなく「迷ったら、結論をファイルに書き出して /clear」**が、コスト面では正解です。

自動コンパクションは約 967K トークンで発動する

自分で打たなくても、コンテキストが一定量を超えると自動でコンパクションが走ります。1M コンテキストのモデルの場合、既定の閾値は約 967K トークンです。1M の枠に対して、残り約 33K を残した地点ということになります。

この閾値は変更できます。

# 現在のセッションで閾値を 300K トークンに変更する
/autocompact 300000

環境変数 CLAUDE_CODE_AUTO_COMPACT_WINDOW でも設定でき、指定できる範囲は 100K〜1M トークンです。閾値を下げれば早めに畳まれてコンテキストが軽く保たれますが、そのぶんコンパクションの回数（＝要約リクエストの回数）は増えます。どちらが得かは作業内容によります。

`/compact` の圧縮率は「自分で測る」しかない

ここで正直に書いておきます。/compact で何パーセント圧縮できるかについて、公式の数値は存在しません。

当然といえば当然で、圧縮率は会話の中身に完全に依存します。同じ内容を何度も往復した会話は大きく縮みますし、密度の高い議論が続いた会話はあまり縮みません。「◯%減る」という一般解はないのです。

しかし、自分がよくやる作業での目安なら測れます。手順は4ステップです。

【/compact 効果測定ワークシート】

手順1. /compact を実行する直前に /context を実行し、使用量を控える
   → 実行前: ________ トークン（全体の ____ %）

手順2. /compact を実行する
   → 焦点を指定した場合はその内容: ______________________

手順3. すぐにもう一度 /context を実行し、使用量を控える
   → 実行後: ________ トークン（全体の ____ %）

手順4. 減った割合を計算する
   → 削減率 =（実行前 − 実行後）÷ 実行前 × 100 = ______ %

補足. その日の作業内容をメモしておく
   → 作業の種類: ______________________
     （例: 長い調査 / コード実装 / 資料作成 / 質疑応答の往復）

これを種類の違う作業で3〜5回繰り返すと、「自分が普段やる作業なら、だいたいこれくらい減る」という目安が見えてきます。そうなれば「今 /context が何%だから、あと何回やりとりできるか」「ここで畳むべきか」が判断できるようになります。他人のブログの数字を覚えるより、この5回のほうが確実に役に立ちます。

最初につまずくポイント

新しいセッションでいきなり /compact を試すと、次のメッセージが出て実行されません。

Not enough messages to compact.

これは不具合ではありません。要約するだけの会話履歴がまだ溜まっていない、という意味です。ワークシートを試すときは、ある程度作業を進めたセッションで実行してください。

【Bad】
何時間も同じセッションを続け、応答が遅くなっても何もしない
→ 967K 付近まで膨らみ、そこで自動コンパクションが走る。
  最も大きくなった状態で要約リクエストが発生するので、最も高い

【Good】
作業の節目で /context を確認し、続きが必要なら /compact、別件なら /clear
→ 小さいうちに畳むので要約リクエストも軽く済む

効果の測り方：上記のワークシート。加えて /usage の「キャッシュ書込」が急に増えていたら、それはコンパクションで文脈を作り直した分です。

節約術3：必要なファイルだけを読ませる

Claude Code はファイルやフォルダを読み込めますが、読んだ分はすべて入力トークンになります。しかも 10-1 で見たとおり、ツールの実行結果（読んだファイルの中身）はコンテキストに積まれ、以降のやりとりで毎回送り直されます。「とりあえず全部読んで」は、一度きりの出費ではなく、そのセッションの間ずっと払い続ける固定費になるということです。

【Bad】
「このフォルダ全部読んで、何か改善点ある？」
→ 無関係なファイルまで大量に読み込み、以降のやりとりで毎回それを再送する。焦点もぼやける

【Good】
「sales-report.xlsx の『4月』シートだけを読んで、前月比が下がっている項目を挙げて」
→ 対象を絞った指示。消費は最小限で、回答も的確になる

ポイントは、依頼する前に自分が一瞬だけ考えることです。「この作業に本当に必要な材料はどれか？」を3秒考えてファイル名を指定するだけで、消費トークンが大きく変わります。どのファイルが関係するかわからない場合も、「まずファイル名の一覧だけ見て、関係しそうなものを教えて。中身はまだ読まないで」と段階を踏めば、無駄読みを防げます。

効果の測り方：ファイルを読ませた直後に /context を実行します。読み込み前後の差が、そのファイルのコンテキスト上のサイズです。/context は「コンテキストを圧迫しているツール」の最適化提案も出すので、そこに名前が挙がったものは読ませすぎのサインです。

節約術4：長文を渡すときは「要約してから」

議事録、調査レポート、長いメールスレッド——長文を扱う場面では、渡し方の工夫が効きます。

目的に関係する部分だけ抜粋して渡す：50ページの資料でも、必要なのは3ページかもしれません
先に要約を作らせ、要約をもとに本作業をする：いったん「この資料を500字で要約して」と頼み、以降の議論は要約をベースに進める。元の長文を会話で引きずらずに済みます
繰り返し使う長文はファイルにする：毎回貼り付けるのではなく、ファイルとして保存して必要なときだけ参照させる

要約を挟むかどうかの損得は、単純な掛け算で見積もれます。3万字の資料はおおまかに数万トークン規模です。これを10回の質問で毎回送り直せば、その数万トークンを10回払います。対して、最初に1回だけ読ませて500字の要約（1000トークン未満）を作れば、以降の10回はその要約だけで済みます。要約を作るコスト1回分と、長文を送り直すコスト10回分を比べれば、答えは明らかです。

【Bad】
3万字の議事録を毎回チャットに貼り付けて、質問のたびに送り直す

【Good】
議事録をファイルとして保存 → 「要点を箇条書きで抽出して summary.md に保存して」
→ 以降の質問は summary.md を参照して回答させる

「素材は外部のファイルに置き、会話には要点だけを乗せる」。これが長文との付き合い方の基本形です。

効果の測り方：/usage の入力トークン数を、質問1回ごとに比べます。要約に切り替えたあと、1回あたりの入力量が下がっていれば効いています。

節約術5：タスクの重さに合わせてモデルを使い分ける

Claude には性能と単価の異なる複数のモデルがあり、Claude Code では /model コマンドで切り替えられます。単価差は「なんとなく高い / 安い」ではなく、はっきりした倍率です（100万トークンあたり、2026年8月28日時点）。

モデル	入力	出力	コンテキスト長
Claude Opus 5	$5	$25	1M
Claude Sonnet 5	$2	$10	1M
Claude Haiku 4.5	$1	$5	200K

Haiku 4.5 と Opus 5 では、入力単価も出力単価もちょうど5倍違います。 同じ作業を Haiku で済ませられるなら、費用は5分の1です。中間の Sonnet 5 でも、Opus 5 に対して入力・出力とも2.5分の1になります。

考え方は「仕事の重さに合った道具を選ぶ」です。

軽いタスク（誤字チェック、簡単な変換、定型文の生成、ファイルの形式変更など）→ 軽量・低単価のモデルで十分
重いタスク（複雑な分析、設計の検討、長い文書の作成、難しいコードの実装など）→ 高性能モデルの出番

ただし1点、単価表だけを見ていると見落とす制約があります。Haiku 4.5 のコンテキスト長は 200K で、Opus 5 や Sonnet 5 の 1M の5分の1しかありません。 長い文書をまとめて読ませる作業や、長時間続くセッションでは、安さより先にコンテキストの上限に当たります。「安いから何でも Haiku」ではなく、「短くて軽い作業を Haiku」が正確な指針です。

【Bad】
「CSVの列名を英語に直すだけ」の作業を、常に最高性能のモデルで実行
→ 5倍の単価を払っている。軽トラで済む配達に大型トレーラーを使うようなもの

【Good】
単純作業は Haiku、通常の作業は Sonnet、ここぞという設計・分析は Opus と切り替える
→ 成果はほぼ同じで、消費は最大5分の1になる

迷ったら「この作業、新人さんに頼んでも問題なくできるか？」と考えてみてください。できそうなら軽量モデルで十分なことが多い、というのが実務的な目安です。

効果の測り方：/usage はモデル別の内訳を表示します。「重いモデルの行が大きく、軽いモデルの行がほとんどない」なら、切り替えが習慣になっていない証拠です。

節約チェックリスト

依頼の前後で、次の6点を確認する習慣をつけましょう。それぞれ「何で確認するか」まで決めておくのがポイントです。

このタスクは前の会話の続きか？別件なら結論をファイルに書き出して /clear（/compact より安い）
読ませるファイルは必要最小限に絞ったか？ → 読み込み前後で /context を比べる
長文は要約・抜粋してから渡しているか？ → /usage の1回あたり入力トークンを比べる
タスクの重さに合ったモデルを選んだか？ → /usage のモデル別内訳を見る（Haiku と Opus では単価5倍）
コンテキストが 967K の自動コンパクション閾値に近づく前に、自分で節目を作れたか？ → /context
/compact の削減率を、自分の作業で一度は測ったか？ → 本文のワークシート

10-1 で見たとおり、キャッシュ読取の単価は通常入力の0.1倍です。同じ文脈を続けて使うほど実効単価は下がりますが、そもそも余計なものをコンテキストに乗せないことが節約の本筋である点は変わりません。10分の1になっても、元が大きければ結局大きいからです。

発展：日常運用のコマンドを一通り押さえる

セッションの再開（-c / -r）、チェックポイントによる巻き戻し（/rewind）など、日々の操作を網羅的に知りたい場合は日常運用ガイドにまとめてあります。

やってみよう

/compact の削減率を測る：本文のワークシートに沿って、実行前後の /context の数値を控え、削減率を計算してみましょう。作業の種類を変えて3回試すと、自分の目安が見えてきます。新規セッションでは Not enough messages to compact. と出るので、ある程度進めたセッションで行ってください。
/clear と /compact のコストを比べる：別件のタスクに移るとき、いつもどおり /compact する代わりに「決定事項を notes.md に書いて」と頼んでから /clear してみましょう。次のやりとりの /usage を比べます。
モデルの5倍差を体感する：「誤字チェック」のような軽い作業を Haiku 4.5 で実行し、品質が用途に対して十分かを確認します。十分なら、その作業は今後ずっと5分の1の単価で回せます。

まとめ

節約の目的は「同じ成果をより少ないトークンで出す」こと。質を落とす我慢ではない
最も効くのは「タスクごとにセッションを区切る」こと。残したい結論はファイルに書き出してから区切る
公式注記のとおり、/compact はそれ自体が大きなリクエストになる。コスト面では /clear のほうが安い
自動コンパクションの既定の閾値は約 967K トークン。/autocompact や環境変数で 100K〜1M に変更できる
/compact の圧縮率に公式値はない。/context → /compact → /context の3ステップで自分の目安を測る
ファイルは名指しで最小限に読ませる。読んだ中身は以降ずっと毎回送り直される
長文は要約・抜粋してから渡し、素材はファイルに置いて会話には要点だけを乗せる
Haiku 4.5 と Opus 5 の単価差は入力・出力とも5倍。ただし Haiku 4.5 のコンテキスト長は 200K しかない

理解度チェック

問1. 午前中に「経費データの集計」を終え、午後から全く別の「新サービスの企画メモ作成」を始めます。トークン節約の観点で最も適切な行動はどれでしょう？

A. 同じセッションでそのまま続ける（履歴が多いほどAIは賢くなるため）
B. /compact を実行してから企画メモの作業を始める
C. 残したい結論をファイルに書き出したうえで /clear し、新しい文脈で企画メモの作業を始める
D. 高性能モデルに切り替えてから同じセッションで続ける

解答を見る

正解：C

経費データの履歴は企画メモ作成には不要で、残しておくと毎回送り直される「荷物」になります。/compact（B）は公式注記のとおりそれ自体が大きなリクエストになるため、無関係な履歴を要約するのは二重の無駄です。コスト面では /clear のほうが安く、残したい内容はファイルに出すほうが要約より確実です。履歴が多いほど賢くなる（A）はむしろ逆で、無関係な文脈は精度低下の原因になります。

問2. 「/compact を使うとコンテキストが何パーセント減るか」を知りたいとき、正しい調べ方はどれでしょう？

A. 公式ドキュメントに圧縮率が明記されているので、それを参照する
B. /context で数値を控え、/compact を実行し、もう一度 /context を実行して差を計算する
C. 一般に70%減ると決まっているので、計算する必要はない
D. /usage のドル換算額を見れば、圧縮率がそのまま表示される