Claude Code のトークン最適化 2026：API 料金を 60〜90% 削減する 5 つの戦略

TL;DR：Claude Code は、生のファイル内容をそのまま流し込み、毎ターン同じ system prompt を再読み込みさせていると、週末だけで 4 桁の API 料金を焼き尽くせます。本番環境で実際にコストカーブを動かすテクニックは 5 つです。適切な TTL での積極的な prompt caching、/compact と /clear の規律ある運用、Sonnet をデフォルトにして Opus には選択的にだけ上げるルーティング、高コンテキストな作業を隔離する subagent、そして MCP ツールの肥大化を削ることです。5 つすべてを回しているチームは、実ワークロードで 60〜90% の削減を報告しています。

この料金は Anthropic の問題ではありません。ワークフローの問題です。Claude Code は、やめろと言わない限り、毎ターン喜んでリポジトリ全体を読み直します。

なぜあなたの Claude Code の料金は Cursor の料金より高いのか

Cursor は一律 $20 です。Claude Code は token 単位の課金で、MCP server を 3 つ読み込み、prompt caching なし、デフォルトルーティングが Opus というアツいセッションは、昼食前に $100 分のクレジットを焼き払います。直し方は別の agent に乗り換えることではありません。Claude Code が実際に通信で何を送っているかを理解することです。

毎ターン送られるもの：

1. system prompt（Claude Code の内部指示。大きく安定しており、絶好の cache 候補）
2. これまでの会話履歴すべて
3. すべての MCP ツールの schema（このターンで使うかどうかに関係なく）
4. Read ツールで読んだファイル内容（以降のターンで毎回再送される）
5. あなたの実際のメッセージ

血を流させているのは 1、3、4 です。以下の 5 つの戦略が、それぞれの漏れを順に止めます。

戦略 1：prompt caching で、再読み込みするものは 10% だけ払う

cache hit は Anthropic の公表料金で 標準 input の 0.1× のコストで、キャッシュされた token に対して一律 90% の割引です。落とし穴は、cache の 書き込み が高くつくことです。5 分 TTL では標準 input の 1.25×、1 時間 TTL では 2× かかります。この計算から強い帰結が出ます。5 分の caching は 1 回 hit すれば元が取れますが、1 時間の caching は最低 2 回 hit しないと損益分岐に届きません。

Claude Sonnet 4.6（input $3/M）なら、cache read は $3/M ではなく $0.30/M です。Claude Opus 4.7（ofox.ai で input $5/M）なら、cache read は $5/M ではなく $0.50/M です。1 セッション中に 40 回 hit する 50,000-token の system prompt なら、Sonnet でおよそ $5.94 節約できます。しかもこれはキャッシュされたブロック 1 つ分にすぎません。

何をキャッシュすべきか：

• system prompt と CLAUDE.md の内容：大きく安定しており、毎ターン hit する
• tool definition：ターンが変わっても同じペイロード
• 再度クエリする参照ドキュメント：schema、設計ドキュメント、コードベースのツリー
• few-shot examples：完璧に静的なペイロード

生の SDK 呼び出しで有効化する方法：

client.messages.create(
    model="anthropic/claude-sonnet-4.6",
    system=[
        {
            "type": "text",
            "text": large_system_prompt,
            "cache_control": {"type": "ephemeral"}  # default 5m TTL
        }
    ],
    messages=conversation
)

1 時間版は、テレメトリで正当化できるときだけ切り替えてください：

"cache_control": {"type": "ephemeral", "ttl": "1h"}

2026 年 3 月の cache 退行：請求を確認しよう

ワークフローを何も変えていないのに 3 月初めに Claude Code の料金が 20〜30% 跳ね上がったなら、気のせいではありません。Anthropic は 2 月から Claude Code が使っていたデフォルトの 1 時間 TTL をこっそり巻き戻し、5 分に戻しました。以前は 1 回の cache 書き込みを再利用していた長い非同期セッションが、代わりに 5 分ごとに cache を書き込むようになり、cache 作成コストが実測で 20〜32% 膨らみました。

ユーザー側の対処：ワークロードパターンが正当化するなら設定で明示的に 1h TTL を要求し、API レスポンスの cache_creation_input_tokens と cache_read_input_tokens フィールドで cache hit 率を監視します。read が write を 2:1 以上で上回っていれば勝ちです。そうでなければ、あなたの cache 戦略は上下逆さまになっています。

戦略 2：/compact は早めに、/clear はこまめに

Claude Sonnet 4.6 と Opus 4.7 は今や標準料金で 1M token のコンテキストウィンドウを備えています（2026 年 3 月 13 日に一般提供開始 — beta ヘッダーもプレミアムティアも不要）。余裕ができたように聞こえますが、素朴な失敗パターンは以前と同じです。セッションを auto-compact のトリガーまで漂流させ、コンテキストがすでにノイズだらけのせいで質の悪い要約をもらう、というものです。

/compact は会話を要約し、生の履歴をその要約で置き換えます。早めにトリガーするほど要約は良くなります。Claude が、残すべきものを保持し、そうでないものを捨てる余地を多く持てるからです。妥当なトリガーのしきい値は 90% ではなく コンテキスト利用率 ~60% です。多くのエンジニアはカスタムヒントも渡します：/compact Focus on code samples and API usage。

/clear はすべてを消します。要約も引き継ぎもありません。本当に無関係な作業に切り替えるときに使ってください。フロントエンドのバグを片付けてマイグレーションスクリプトに着手するのは /compact の場面ではなく /clear の場面です。無関係な作業に古いコンテキストを持ち込むと、それ以降ずっと無関係な履歴に input token を払い続けることになります。

実用的な規律：

• 同じ機能、継続中のスレッド → そのまま続ける
• 新しいチケット、コードベースの同じ領域 → まず /compact、1 行の前置きで状況を語る
• まったく新しいドメイン → /clear

KDnuggets の 7 practical ways to reduce Claude Code token usage は、先回りの compaction を上位 3 つのレバーに挙げています。定性的なポイントは、会話がまだきれいなうちに 早めに compact すれば使える要約になり、90% 以上で compact するとノイズになる、ということです。Anthropic 自身の cost guide も同じパターンを推奨しています。

戦略 3：デフォルトは Sonnet 4.6、行き詰まったときだけ Opus 4.7 に上げる

Claude Code で最も効果の高い設定変更ひとつは /model claude-sonnet-4.6 です。Sonnet 4.6 はコーディングタスクで本当に強く、Anthropic 自身のベンチマークでも SWE-bench で Opus に肉薄しながら、input 料金の 60%、output 料金の 60% で動きます。

ofox.ai の料金では：

実際に Opus 4.7 に手を伸ばすべきとき：

• 多数の編集にまたがる一貫性が必要な、ファイル横断のアーキテクチャ判断
• 同じ問題で Sonnet がすでに一度失敗している難しいデバッグ
• ミスが下流の利用者に波及する schema や API 契約の設計
• エッジケースが重要で、Sonnet がカラム名を幻覚し続けているマイグレーションのロジック

Sonnet が正しいデフォルトであるとき：

• 既知のファイルへの編集
• テスト作成
• スコープが明確なリファクタリング
• コードレビューと説明
• ほとんどの agentic ループ（ファイル読み込み、grep、単純な編集）

実用的なパターンは「Sonnet が下働きをし、Opus が考える」分担です。Sonnet が実際のファイル操作をこなし、設計の議論や行き詰まった瞬間だけ /model opus にします。設定の詳細はClaude Code ハイブリッドルーティングパターンをご覧ください。Claude Opus 4.7 API レビューでは、4.6 に対する 4.7 の改善にお金を払う価値があるときとないときを扱っています。

戦略 4：冗長な作業は subagent に隔離する

subagent は、自分のコンテキストウィンドウで動く Claude のインスタンスです。親がタスクを渡して呼び出し、subagent は自分のコンテキストを使い切りながら作業をこなし、要約だけが親に返ります。結果として、50K token の grep 出力がメインスレッドを汚染することはありません。

subagent が効くところ：

• コードベースの探索：「processPayment のすべての呼び出し元を見つけてパターンを要約して」
• 大きなファイルの読み込み：10K 行の vendored ライブラリを読んで 1 つの API サーフェスを抜き出す
• リサーチタスク：web 検索結果、ドキュメントの大量ダンプ、長いログ解析
• テスト失敗の調査：50KB の pytest 出力をパースする

subagent がトークンを無駄にするところ：

• ささいなシェルコマンド（spawn のオーバーヘッドのほうがタスクより大きい）
• 親が直接できる単一ファイルの編集
• どうせ親が出力全体を必要とするもの

コストの罠：subagent を多用するワークフローは、各 subagent が system prompt と tool definition を再読み込みするため、シングルスレッドのセッションのおよそ 7× のトークンコストに達することがあります。subagent は、冗長な中間出力が本当に使い捨て であるタスクに限って使ってください。親が生の出力を必要とするなら、インラインで作業したほうが安上がりです。

Claude Code の hooks、subagent、skills ガイドでは、繰り返すタスク向けのカスタム subagent 定義を含め、設定を詳しく扱っています。

戦略 5：MCP server を監査する。ほとんどはトークン税に見合わない

これは最も語られていないレバーです。最新の Claude Code はデフォルトで MCP tool definition を遅延読み込みします。Claude が特定のツールを実際に呼ぶまで、コンテキストに入るのはツール名だけです。ただし、その節約はサーバーリストを実際にスリムに保ったときにしか実現しません。Anthropic 自身の advanced tool use の記事からの実数値：

• 58 ツールの 5 サーバー構成：従来の preload モデルで ~55K token のオーバーヘッド
• Jira MCP だけ：~17K token
• Anthropic 自身の最適化前の社内テスト：134K token の tool definition
• Tool Search 有効時：58 ツールが ~8.7K の合計コンテキスト消費に圧縮、~84% の削減

遅延読み込みのない古いクライアントを使っているなら、何もする前にコンテキストウィンドウの 3 分の 1 を税として払っていることになります。遅延 definition があっても、接続された MCP server ごとに system prompt にツール 名 が追加され、Claude が推論しなければならない表面積が増えます。

すべきこと、影響の大きい順：

1. /context を実行して、実際の tool-definition の支出を見る。驚いたなら、お金を失っている。
2. 今のセッションで不要な MCP server を無効化する。 ほとんどのワークフローは一度に 1〜2 個のサーバーしか触らない。/mcp を実行して設定済みのサーバーを確認し、残りを無効化する。
3. Tool Search が有効か確認する。 現在の Claude Code では MCP tool definition がデフォルトで遅延読み込みされる。古いクライアントや直接の SDK 呼び出しでは、Anthropic の Tool Search を明示的に有効にする。
4. 存在するなら MCP server より CLI ツールを優先する。 gh、aws、gcloud、sentry-cli は、Claude が tool schema 経由ではなく Bash 経由で呼ぶため、ツールごとのリスト掲載オーバーヘッドがゼロ。
5. 残った tool definition をキャッシュする。 ターンをまたいで安定しているので、キャッシュされた system prefix に入れるべき。これは戦略 1 と相乗効果になる。
6. 1 つのリポジトリでしか必要ないなら MCP server をグローバルに接続しない。 プロジェクトスコープの設定を使う。

妥当な経験則：あるツールの definition が、そのツールが実際に役立つ分よりも大きいなら、読み込むべきではありません。あらゆる MCP server を「念のため」使える状態にしておく便利さは、そのセッションが終わるまで毎ターンのすべての input token で支払うことになります。

まとめ：60〜90% という目標は現実的だ

節約は乗算的に積み上がります。5 つすべて（caching、compaction の規律、Sonnet デフォルトルーティング、慎重な subagent 利用、スリム化した MCP 構成）をやっているチームは、$1,600 の週末料金を、同じ作業に対しておよそ $200〜400 と比べることになります。個別のレバーで最大なのは、長いセッションでは通常 #1（caching）、短いセッションでは #3（Sonnet デフォルト）です。最大の隠れたレバーは #5（MCP 監査）です。関わるトークンが会話に一度も現れないからです。

直接 Anthropic ではなく ofox.ai 経由でルーティングしているなら、cache 対応の料金が自動的に適用され、さらに Opus と Sonnet が直接の定価より割引で使えます。AI API コスト削減の完全ガイドではプロバイダー横断のパターンを扱い、Claude Code ofox 設定ガイドでは実際のセットアップを順を追って説明します。コストを意識したエンドツーエンドのスタックについては、月 $30 の AI コーディングスタックガイドが全体のパターンを示します。

subagent は Claude Code を安くするわけではありません。subagent は、ある特定の種類の高コストな作業を安くします。MCP 監査はすべてを安くします。最短時間で最大の成果がほしいなら、そこから始めてください。

出典

• Anthropic Prompt Caching Documentation：cache の料金、TTL オプション、cache_control の構文
• Anthropic Claude API Pricing：Sonnet、Opus、Haiku の基本料金
• Claude Code GitHub Issue #46829：2026 年 3 月の TTL 退行
• Anthropic Engineering: Advanced Tool Use：Tool Search とオンデマンドのツール読み込み
• ofox.ai Models Catalog：ofox ゲートウェイ上の現在の Claude 料金
• Claude Code Cost Management Docs：公式の最適化ガイダンス