Claude Codeのトークンを節約する：/clearと/compactの使い分けでコンテキストを軽くする

ある日の夕方、Claude Codeに頼んだバグ修正がやけに遅かった。返ってきた答えは見当違いで、しかも2時間前に「もう消した」はずのファイルの話を蒸し返してくる。

「急にバカになった？」と思いました。でも違ったんです。

/context を打って血の気が引きました。会話の窓が、もう半分以上埋まっていた。古いログ、関係ないファイル、解決済みの議論。机の上に三日分の書類を積んだまま、新しい仕事をしようとしていたわけです。賢いAIに重い荷物を背負わせていたのは、僕自身でした。

トークンの節約は、ケチる話に聞こえます。でも実際は逆で、軽くするほど返答は速く、正確になり、結果としてコストも下がる。今日はその具体的なやり方を、僕がやらかした失敗込みで書きます。

この記事の要点

• Claude Codeが遅く・雑になる最大の原因は、会話の窓（コンテキスト）の圧迫。まず /context で中身を見る。
• 別の作業に移るなら /clear（捨てる）、同じ作業を続けるなら /compact（要約して残す）。この使い分けが効く。
• CLAUDE.md は毎回読まれる固定費。200行以内に絞り、たまにしか使わない手順はスキルへ逃がす。
• ログや差分は丸ごと貼らない。失敗行の前後だけを渡すと、トークンが減って原因究明も速くなる。
• 公式の請求は Claude Console で確認する。/usage のセッション金額はローカル推定なので、それだけで判断しない。

何がトークンを食っているのか

最初に誤解を解きます。トークンは「いま打った文章」だけで増えるわけではありません。

Claude Codeは、毎回のやり取りで会話全体を読み直しています。だから増えるのはこれ全部です。

• これまでの会話履歴（質問も、AIの長い返答も、ツールの実行結果も全部）
• 起動時に読み込まれる CLAUDE.md
• あなたが貼り付けたログや差分
• MCPサーバーやツールの定義
• テストの出力、前の調査メモ

会話が進むほど、この「背負っている荷物」が重くなる。公式のコスト管理ドキュメントでも、コストはコンテキストのサイズに比例すると明言されています。処理する文脈が多いほどトークンを使う。シンプルな話です。

だから節約の本質は「打つ文字を減らす」ことではなく、会話の窓に余計なものを溜めないことにあります。机を片付ける、と言い換えてもいい。荷物が軽ければ、AIは目の前の仕事に集中できます。

まず現状を見る：/context と /usage

片付けの前に、何が散らかっているか見ます。道具は2つです。

/context は、いま会話の窓を何が占めているかを見せてくれます。CLAUDE.mdが重いのか、MCPサーバーの定義が膨らんでいるのか、履歴が伸びすぎなのか。原因が分かれば打ち手が決まります。

/usage は、現在のセッションの使用状況を見せます。ここで大事な注意をひとつ。公式ドキュメントによると、/usage のSessionブロックに出る金額はローカルで計算された推定値で、API利用者向けの数字です。MaxやProのサブスク利用者は、その金額がそのまま請求されるわけではありません。実際の請求は Claude Console のUsage画面で確認します。

打つタイミングはこんな時です。

• 作業を始める時
• 大きなツール実行（全文検索、長いテスト）の直後
• 「あれ、遅くなったな」と感じた時
• 別の人やサブエージェントに引き継ぐ前

毎回打つ必要はありません。遅くなった、と感じた瞬間に /context を打つ癖をつけるだけで、原因の切り分けが一気に楽になります。

/clear と /compact を使い分ける

ここが今日いちばん伝えたいところです。会話を軽くするコマンドは2つあって、役割がまったく違う。

ざっくり言うと、/clear は「机を全部片付けて白紙に戻す」、/compact は「散らかった書類を1枚の要約にまとめて手元に残す」です。

やりたいこと	使うコマンド	何が起きるか
無関係な別の作業に移る	/clear	前の文脈を捨てて新規スタート。窓が一気に空く
同じ作業を続けたいが履歴が重い	/compact	作業履歴を要約して、要点だけ残す
何が窓を占めているか確認	/context	内訳を表示（消さない）

判断の分かれ目はシンプルで、「さっきまでの決定を引き継ぐ必要があるか」だけです。

引き継ぐ必要がないなら /clear。たとえば「認証バグの修正」が終わって、次は「READMEの英訳」に移るとき。前の文脈は一切いりません。捨てた方が速いし安い。公式も、無関係な作業に移るときは /clear で新しく始めろと書いています。

引き継ぐ必要があるなら /compact。長い調査の末にようやく原因が見えてきた、でも履歴が重い。そんな時は要約して核だけ残します。このとき何を残すか指示できるのがポイントです。空の /compact ではなく、残したいものを言葉で渡します。

# Claude Code の会話欄で実行する

# まず何が窓を占めているか見る
/context

# 同じ作業を続けるが、判断だけ残して軽くしたい
/compact 変更したファイル、失敗中のテスト、決定事項、未解決の疑問を残して。それ以外の探索ログは捨ててOK。

# 別の作業に移る（前の文脈は不要）
/clear

僕が最初にやった失敗は、この使い分けを知らずに何でも /clear していたことです。気持ちよく軽くなるんですが、苦労して突き止めた原因まで毎回消える。同じ調査を翌日もう一度やる羽目になって、トータルではむしろトークンを浪費していました。逆に、無関係な作業なのに /clear せず引きずって、窓を圧迫したこともあります。コマンドは、目的に合わせて選ぶものです。

CLAUDE.md は「毎回払う固定費」と考える

CLAUDE.md は、起動するたびにコンテキストへ読み込まれます。つまり全セッションで払い続ける固定費です。

ここを太らせると、関係ない作業のときまでその分のトークンを払い続けることになる。公式ドキュメントもはっきり書いていて、CLAUDE.mdは200行以内を目安にし、入れるのは本当に必須のものだけにしろ、と。PRレビューの細かい観点やDB移行の手順みたいに「たまにしか使わない長い手順」は、スキルへ移すよう勧めています。スキルは呼び出したときだけ読み込まれるので、固定費になりません。

僕が今使っている CLAUDE.md は、この粒度です。

# CLAUDE.md

## よく使うコマンド
- ビルド: npm run build
- テスト: npm run test
- 型チェック: npm run typecheck

## 場所のメモ
- API: src/api/
- 画面: src/components/
- テスト: tests/

## デフォルトで避けること
- node_modules/ dist/ coverage/ 生成物は読まない
- ログ全文を貼らない。失敗コマンドと関連する末尾数行だけ渡す

## /compact 時の指示
要約のときは、変更ファイル・失敗テスト・決定事項・次の一手を残す

これくらいなら毎回読み込む価値があります。判断の基準は「毎回必要か」のひと言。@別ファイル.md で分割しても、起動時に読み込むなら節約にはなりません。構造化には役立ちますが、トークンを減らしたいなら「常時いるか」を先に考えます。粒度と更新の考え方はCLAUDE.mdは「何を書かないか」で決まるにまとめたので、合わせてどうぞ。

読ませる量を絞る：ログと差分は丸ごと貼らない

初心者がいちばんトークンを増やすのが、ログや差分を全部コピペすることです。

Claude Codeは大量のテキストも読めます。でも、読む必要がない行まで渡すと、返答が遅くなり、肝心のエラー行が埋もれる。減らすべきは証拠ではなくノイズです。公式も「improve this codebase（このコードベースを良くして）」のような曖昧な依頼は広範囲のスキャンを誘発する、と注意しています。具体的に頼むほど、AIは少ないファイル読み込みで動けます。

下のコマンドはそのままBashで動きます。要点は、全文は手元のファイルに残しつつ、Claudeには失敗の周辺だけ見せること。

# テストの全出力は test.log に保存し、失敗の前後だけ抜き出す
npm test 2>&1 | tee test.log
grep -nE -C 6 "FAIL|ERROR|Error|failed|Assertion" test.log | head -160

# PR全体を読ませる前に、まず規模と変更ファイルだけ見る
git diff --stat
git diff -- src/auth.ts tests/auth.test.ts

# 巨大ログから対象IDとエラー周辺だけ渡す
tail -n 800 logs/app.log | grep -nE -C 4 "request_id=abc123|ERROR|WARN"

WindowsのPowerShellなら、grep の代わりに Select-String を使えば同じ発想で絞れます。tee test.log で全文を残しておくのがコツで、足りなければ後から範囲を広げればいい。最初から全部渡さない。これだけで日々のトークンが目に見えて減ります。

依頼の文も同じです。「ログを見て直して」ではなく「auth.ts の login 関数に入力チェックを足して」と書く。範囲が狭いほど、AISの読み込みも返答も軽くなります。

長い出力を避ける依頼の仕方

入力だけでなく、AIに長く喋らせないのも効きます。出力トークンも当然コストだからです。

僕がよくやるのは、成果物の形を先に指定すること。「調べて」だけだと、AIは丁寧に全部を説明し始めて、その長文がまた次の会話の荷物になります。だから最初から枠を渡します。

• 「結論・変更したファイル・根拠リンク・未解決点、の4項目だけで返して」
• 「コードだけ出して。説明は3行以内で」
• 「該当する変更点だけ。前置きはいらない」

長い調査そのものをサブエージェントに隔離するのも手です。公式が勧めているやり方で、テスト実行・ドキュメント確認・ログ処理といった出力の多い作業をサブエージェントに任せると、その膨大な出力はサブエージェント側の窓に留まり、メインの会話には要約だけが返ってきます。メインの机を汚さずに済む。

ただし注意も。サブエージェントは別の窓を持つので、増やしすぎれば合計トークンは増えます。目的は「全部を並列化すること」ではなく「メインの判断文脈を汚さないこと」。ここを取り違えると、軽くするつもりが逆に高くつきます。会話が長くなって精度が落ちる仕組みはClaude Codeが急にバカになる原因はコンテキスト管理で詳しく書きました。

コピペで動く：会話に貼る「作業要約」を作る

最後に、僕が毎回使っている小さなNode.jsスクリプトを置いておきます。依存パッケージなしで動きます。

やることは単純で、変更ファイル・差分の規模・テストの失敗行だけを集めてMarkdownにする。これを会話に貼れば、Claudeは全ログや全diffを読まずに、必要な範囲から判断を始められます。

#!/usr/bin/env node
// 使い方: node scripts/claude-brief.mjs test.log > brief.md
// 変更ファイル・diff規模・テスト失敗行だけを集めて、会話に貼る用の要約を作る
import { execFileSync } from "node:child_process";
import { existsSync, readFileSync } from "node:fs";

function git(args) {
  return execFileSync("git", args, { encoding: "utf8" }).trim();
}

const testLogPath = process.argv[2];

// 変更ファイル一覧（未コミット分）
const changedFiles = git(["diff", "--name-only"]).split(/\r?\n/).filter(Boolean);

// 差分の規模だけ（中身ではなく統計）
const diffStat = git(["diff", "--stat"]);

// test.log があれば失敗行だけ最大80行
const testLog = testLogPath && existsSync(testLogPath)
  ? readFileSync(testLogPath, "utf8")
  : "";
const failures = testLog
  .split(/\r?\n/)
  .filter((line) => /(FAIL|ERROR|Error|failed|Assertion)/.test(line))
  .slice(0, 80);

console.log("# Claude への作業要約\n");
console.log("## 変更ファイル");
console.log(changedFiles.length ? changedFiles.map((f) => `- ${f}`).join("\n") : "- なし");
console.log("\n## 差分の規模");
console.log(diffStat || "差分なし");
console.log("\n## テストの失敗行");
console.log(failures.length ? failures.map((l) => `- ${l}`).join("\n") : "- 該当なし");

保存して実行するだけです。

mkdir -p scripts
# 上の内容を scripts/claude-brief.mjs に保存してから実行
node scripts/claude-brief.mjs test.log > brief.md

この brief.md を会話に貼る。原因究明に足りなければ、そこで初めてファイルやログを追加で渡します。「困ったらまず全部見せる」から「まず要約、足りなければ足す」へ。発想を逆にするだけで、無駄なトークンがごっそり消えます。

よくある質問

Q. /cost はもう使えないんですか？ A. 消えたわけではありません。2026年6月時点では、入口を /usage にそろえると混乱が少ないです。/usage はセッションのトークン使用量や、プラン利用者なら利用制限の内訳まで見せてくれます。請求の確定額は Claude Console 側で確認してください。

Q. /compact と /clear、迷ったらどっち？ A. 「さっきまでの決定を引き継ぐ必要があるか」で決めます。引き継ぐなら /compact（要約して残す）、要らないなら /clear（捨てて新規）。判断に困るほど混ざっているなら、たいてい別作業なので /clear が正解のことが多いです。

Q. CLAUDE.md は何行までが目安ですか？ A. 公式ドキュメントは200行以内を目安にしています。毎回必要な数行（ビルド・テスト・禁止事項）だけ残し、たまにしか使わない長い手順はスキルへ。@別ファイル 分割は構造化には役立ちますが、起動時に読むならトークン削減にはなりません。

Q. ログを絞ると、原因を見逃しませんか？ A. 全文を tee でファイルに残しておけば見逃しません。Claudeにはまず失敗の前後だけ渡し、足りなければ範囲を広げる。最初から全部渡すより、この方が原因の特定も速いです。削るのはノイズで、証拠は手元に残します。

Q. サブエージェントを増やせばコストは下がりますか？ A. 一概には言えません。長い出力をメイン会話から隔離するには有効ですが、サブエージェントは別の窓を持つので、増やしすぎれば合計トークンは増えます。「並列化」ではなく「メインを汚さない」目的で使うのが正解です。

実際に試した結果

冒頭の「急にバカになった」事件のあと、僕のやり方は変わりました。

返答が遅いと感じたら、まず /context を打つ。原因が履歴の重さなら、引き継ぐ必要があるかで /clear と /compact を選ぶ。これを習慣にしただけで、夕方になってもAIの答えがダレなくなりました。

いちばん効いたのは、CLAUDE.md を「毎回必要な短いルール」に戻したことです。あれもこれもと詰め込んでいた頃は、関係ない作業のたびに重い荷物を背負わせていた。固定情報・今回の判断・一時ログを分けるだけで、手戻りがはっきり減りました。トークンが減ったのは、その結果としておまけでついてきた感じです。

トークン最適化は、最小トークンを競うゲームではありません。同じ品質を、より軽い文脈で出す運用設計です。会話の窓を意識し始めた人は、コストも返答の質も自然とよくなります。

個人で使えるチェックリストやプロンプト集はClaudeCodeLabの教材一覧に、チームで権限・レビュー・研修をまとめて整えたい場合はClaude Code研修・導入相談にまとめてあります。まずは次に遅いと感じた瞬間、/context を打つところから始めてみてください。