Claude Codeを使っていると、月末の請求書を見て「え、こんなに使った？」となることがあります。特にextended thinkingを有効にしたまま日常的なコーディングに使い続けている場合、コストが想定の数倍になっていることも珍しくありません。
ただ、問題はextended thinkingそのものではありません。使い方の設定が間違っているケースがほとんどです。
コスト増の原因を構造的に整理し、extended thinkingを中心に「どこを・どう調整するか」を並べます。
そもそも何にトークンが消えているか把握する
対策を打つ前に、現状把握から。
/cost
このコマンドを打つと、セッション中のトークン使用量と費用が表示されます。
Total cost: $2.30
Total duration (API): 18m 42.1s
Total duration (wall): 2h 15m 33.0s
Total code changes: 148 lines added, 32 lines removed
/cost はAPIユーザー向けのコマンドです。Claude MaxやProのサブスクリプション契約者は /stats でセッションの利用パターンを確認できます。
コストが高くなりやすい原因は大きく3つに分かれます。
| 原因 | 典型的なケース |
|---|---|
| extended thinkingのデフォルト設定 | 全タスクにOpus+フル思考予算が適用されている |
| コンテキストの肥大化 | CLAUDE.mdに詳細なワークフロー手順を全部書いている |
| エージェントチームの放置 | サブエージェントが完了後も生きている |
それぞれ見ていきます。
extended thinkingの設定を見直す
最もインパクトが大きいのがここです。
extended thinkingはデフォルトで有効になっており、思考トークンは通常の出力トークンと同じ料金で課金されます。デフォルトの思考予算はモデルによっては1リクエストあたり数万トークンになることがあります。
やるべき調整はシンプルです。
タスクの複雑さに応じてeffortレベルを変える
/effort low
/effort medium
/effort high
ログ確認、簡単なリファクタ、コメント追記といった作業に /effort high のまま投げ続けるのは、タクシーで隣のコンビニに行くようなものです。
思考トークン予算を直接制限したい場合は環境変数で設定できます。
MAX_THINKING_TOKENS=8000 claude
デフォルトが数万トークンのところを8000に絞るだけで、シンプルな作業のコストは大幅に下がります。
タスク別のeffort運用例
| タスク種別 | 推奨effort | 理由 |
|---|---|---|
| 変数名変更・コメント追記 | low | 思考不要 |
| バグ修正・関数追加 | medium | 適度な推論で十分 |
| アーキテクチャ設計・複雑なリファクタ | high | ここでは惜しまない |
| 大規模な依存関係の整理 | high | 方向性を間違えると後が高くつく |
特に「ここでは low でいい」という判断ができるようになると、コストは自然と落ち着いてきます。
モデル選択とコンテキスト管理の組み合わせ技
extended thinkingの調整と並行してやると効果が高い施策です。
モデルを使い分ける
Opusをデフォルトにしている場合、セッション途中でもモデルを切り替えられます。
/model
設計フェーズが終わったらSonnetに切り替える、サブエージェントにはHaikuを使う、という運用が現実的です。公式のデータでもSonnet 4.6でデベロッパー1人あたり月100〜200ドルが平均ラインとされており、Opusをフルに使い続けると当然これを大きく超えます。
サブエージェントのモデルは設定ファイルで指定できます。
# subagent設定例
model: haiku
description: "ログ解析・ドキュメント取得専用エージェント"
コンテキストを小さく保つ3つの習慣
1. タスクの切れ目で /clear
関係のないタスクに移るとき、前のコンテキストは邪魔なだけです。セッション名を保存しておけば後で戻れます。
/rename feature/auth-refactor
/clear
2. コンパクション指示をカスタマイズする
/compact Focus on code changes and test results only
デフォルトのコンパクションは何でも要約しようとしますが、不要な情報まで要約文として残ることがあります。何を残すか明示的に指定する方が効率的です。
3. CLAUDE.mdはエッセンスだけにする
CLAUDE.mdはセッション開始時に必ずコンテキストに入ります。PRレビュー手順、マイグレーション手順など、特定の作業にしか使わない詳細なガイドラインが書いてある場合、毎回それが余計なトークンを消費しています。
CLAUDE.mdは200行以内を目安にしてください。それ以上はほぼ間違いなく削れます。
特定ワークフローの詳細はスキルに切り出す方が合理的です。スキルは呼び出されたときだけコンテキストに入るので、使わない日には一切コストがかかりません。
hookでClaudeに渡す情報量を減らす
地味に効くのがhookによる前処理です。
たとえばテスト出力をそのままClaudeに渡すと、成功ログも全部コンテキストに入ります。失敗行だけ渡せば十分なケースがほとんどです。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "~/.claude/hooks/filter-test-output.sh"
}
]
}
]
}
}
#!/bin/bash
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command')
if [[ "$cmd" =~ ^(npm test|pytest|go test) ]]; then
filtered_cmd="$cmd 2>&1 | grep -A 5 -E '(FAIL|ERROR|error:)' | head -100"
echo "{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"permissionDecision\":\"allow\",\"updatedInput\":{\"command\":\"$filtered_cmd\"}}}"
else
echo "{}"
fi
10,000行のログファイルをそのまま処理させるのと、エラー行だけ100行渡すのでは、コンテキストの消費量がまるで違います。ログ処理・ドキュメント取得・外部APIレスポンスの整形など、hookで前処理できる場面は意外と多いです。
エージェントチームのコストは別格
エージェントチーム（CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1）を使っている場合、コスト構造が根本的に変わります。
プランモードで動作するチームは通常セッションの約7倍のトークンを消費します。各エージェントが独立したコンテキストウィンドウを持って動くためです。
エージェントが完了後も生き続けているとアイドル状態でもトークンを消費します。作業が終わったら必ずチームを終了させてください。
エージェントチームを使う際のコスト管理ポイントをまとめます。
| ポイント | 内容 |
|---|---|
| チームメンバーはSonnetで | Opusをエージェントに使うと掛け算で高くなる |
| スポーンプロンプトは短く | 起動時から全員のコンテキストに入る |
| チームは小さく | メンバー数に比例してトークンが増える |
| 完了後は即終了 | アイドル状態でも消費が続く |
プロンプトの書き方でもコストは変わる
設定の話ばかりしましたが、プロンプト自体の書き方もコストに直結します。
# 悪い例（広範囲のスキャンが走る）
「このコードベースを改善して」
# 良い例（対象が明確）
「auth.tsのlogin関数にメールアドレスの形式バリデーションを追加して」
曖昧なリクエストはClaudeが関係ありそうなファイルを広く探索するため、ファイル読み込みのコストが積み上がります。具体的なファイルパスや関数名を含めるだけで、不要な探索が減ります。
複雑なタスクにはプランモードを使うのも重要です。
Shift + Tab でプランモードに切り替え
実装前にアプローチを確認することで、方向性が間違っていたときの手戻りコストを防げます。途中で間違いに気づいたときは Escape で即停止、/rewind で巻き戻せます。間違った方向に走り続けるよりはるかに安上がりです。
設定変更のチェックリスト
今すぐ試せる改善策をまとめます。
-
/costでセッションコストを確認する習慣をつける -
日常的なタスクは
/effort lowまたは/effort mediumに変更する -
MAX_THINKING_TOKENS=8000を環境変数に設定する - CLAUDE.mdを200行以内に削り、残りをスキルに移す
-
サブエージェントに
model: haikuを指定する - テスト出力フィルタリングhookを導入する
- エージェントチームを使っているなら完了後に必ず終了させる
extended thinkingは「全タスクに使うもの」ではなく「複雑な推論が必要な場面だけオンにするもの」です。この認識のズレがコスト爆増の本質的な原因です。設定のデフォルトを疑うことから始めると、使い方が変わってきます。