ブログに戻る
公開日
更新日
REF 33 NODES

LLMでトークンを節約する方法：Claude Code実践ガイド

Claude Codeでトークンを節約する実践的なアプローチ：サブエージェント、スキル、フック、中国製モデル、ナレッジグラフ、RAG、pxpipe、そしてサーバー側の節約（Tool Search、コンテキスト編集、プロンプトキャッシュ、Batches API）。コストを10分の1に削減するチェックリスト。

LLMでトークンを節約する方法：Claude Code実践ガイド
VISUAL INPUT saving-tokens-llm

LLMでトークンを節約する方法：Claude Code実践ガイド

月額$200のサブスクを10個使い切るのは難しくない。問題は、それを意味のある使い方ができているかどうかだ。以下に、私がClaude Codeでの日常的な作業で実践しているトークン節約のアプローチをまとめた。

1. 課金の仕組み

Claude Codeは入力トークンと出力トークンそれぞれに課金される。入力とはコンテキストに含まれるすべて：システムプロンプト、チャット履歴、ファイル、スクリーンショット。出力とはモデルが生成する内容。

チャットでの各メッセージは、蓄積されたコンテキスト全体を入力に追加する。1MコンテキストのOpusを使っている場合、各メッセージは毎回その100万トークン全体を送信しているのと同じ料金がかかる。出力もコンテキストを圧迫する — 回答のたびに蓄積されていく。

結論： 会話が短いほど安い。コンテキストが小さいほど安い。モデルの「思考」が少ないほど安い。

2. サブエージェントは必須

メインプロセス（リーダー）自体は何も作業すべきではない。その役割は調整と委任。すべての作業は小さなコンテキストを持つサブエージェントが実行する。

なぜ：

  • リーダープロセスのコンテキストは100〜200Kの範囲に収まり、増加しない
  • サブエージェントが作業を終えると、コンテキストはクリアされる
  • 数十のエージェントを並列実行できる

設定方法：

メインプロセス (Opus, 200K コンテキスト)
├── エージェント1 (Haiku, 短いコンテキスト) — スクリプト処理
├── エージェント2 (Sonnet, 短いコンテキスト) — テスト作成
└── エージェント3 (Haiku, 短いコンテキスト) — リファクタリング

大量タスク（例：8000のスクリプトを処理）の場合 — スクリプト1つにつきサブエージェント1つ、Haikuモデル。1つのチャットですべてを処理するより圧倒的に安い。

3. コンテキストとハルシネーション — 非線形の関係

100KコンテキストのOpusは、1MコンテキストのOpusより正確に動作する。1Mコンテキストではハルシネーションが非線形に増加する。つまり、大きなコンテキストは高コストで品質も低下する。

教訓：コンテキストはコンパクトに保つべし。500Kのチャット1つより、100Kのチャット5つの方が良い。

4. スキルが解決策

スキル（skills）は、必要に応じて読み込まれる事前設定済みプロンプトで、常にコンテキストに常駐しない。多くのフレームワークは、作業の最初のステップとしてスキルを準備・ダウンロードする。

MCPサーバー（常にコンテキストに説明をロードする）とは異なり、スキルは必要な時だけアクティブになる。Opus 4.5以前はMCPで多くのトークンが消費されていた — 現在は問題が解決されたが、「MCPをスキルとコマンドに置き換える」アプローチは、節約の観点から依然として有効。

Caveman

Caveman は Claude Code（および他エージェント）向けのオープンソーススキル／プラグインで、技術的正確性は保ちつつ「caveman speak」で超短い返答を促す — §1の「会話が短いほど安い」を実装した例だ。リポジトリのベンチマークでは平均で 出力 トークンが約 65% 削減という結果。別途 caveman-compress でメモリファイルの散文を圧縮し 入力 も削れる。

5. 中国製モデルと安価なサブスク

Alibaba Cloudや中国のサブスクリプションは、価格/トークン比で圧倒的に有利。約$30のサブスクで、Anthropicの$200プランと同等のトークン量が得られる。

実践：

  • モデルプロバイダーを切り替えられるClaudeラッパーを使用
  • グローバル環境変数は変更せず、ラッパー起動時に必要なものだけ渡す
  • Geminiも同様に安価なサブスクがあり、同じように活用できる

「異なるプロバイダーのモデルをClaudeに直接統合する」完成品はないが、ラッパーでニーズの80%はカバーできる。その一つがClother — グローバル設定を変更せずに、異なるモデルプロバイダーでClaude Codeを実行できる。

6. ナレッジグラフとRAG：トークンを10分の1に

LightRAG

LightRAGは、ナレッジグラフとLLMを組み合わせるアプローチ。コンテキスト全体を読み込む代わりに、構造化された関連情報の抽出により、トークン消費を最大10分の1に削減できる。

a8e

ivansglazunovの開発 — 作者は隠者モードで作業しており、ほとんど公開していないため、プロジェクトを実際に見るのは難しい。司書RAGとして機能：入力されるデータをすべてデータベースに投げ込む。ナレッジグラフとLLMを組み合わせ、より正確で安価なコンテキスト抽出を目指す。この動画で説明されている技術に似たアプローチ。

cmdop-claude

cmdop-claude — markolofsenのアプローチ。グラフとしてマークルツリーを使用。基本アイデア：ほぼ無料の中国製LLMをバックグラウンドで動かし、.claudeフォルダを整理 — メインモデル用のコンテキストを準備する。

ナレッジグラフのグローバル設定 — graphify（OpenRouterをバックエンドにして意味論処理でClaudeのトークンを消費しない）— は§11でrtkと合わせて解説する。

7. エージェント管理フレームワーク

Superpowers

Claude Code用の人気フレームワークで、完成されたスキル、パターン、パイプラインを提供。

AI Factory

ai-factory — AIエージェント管理の興味深いフレームワーク。aif-handoffと組み合わせると、カンバンボードとフィルター付きのフロントエンドが得られる。

重要なアイデア：人間が最初のタスクを設定し、AIがそれを分解するが、完成したプランの人間による承認なしには作業は開始されない。これがトークンを節約し（やり直しが不要）、コントロールも提供する。

8. 実践的なティップス

High effortとreasoningは無効化してコストを削減できる。すべてのタスクがモデルの「深い思考」を必要とするわけではない。

スキルをMCPの代わりに。 Opus 4.5以前は、MCPをスキルに置き換えることで大きな節約になった。現在は差が縮まったが、大量タスクでは依然として有効。

サブエージェントのモデル管理。 サブエージェントが使用するモデルを指定できる。ルーティンタスクにはHaiku、複雑なタスクにはSonnetまたはOpus。

--bareモード — クリーンな起動。 フラグ--bareは、フック、LSP、プラグイン同期、自動メモリ、バックグラウンドプリロードなしでClaude Codeを起動する。そして重要なのは、CLAUDE.mdの自動検出なし。これらはすべて通常、システムプロンプトにロードされ、最初のメッセージの前にトークンを消費する。bareモードではコンテキストが最小限でスタートし、必要なデータは--system-prompt、--append-system-prompt、--add-dir、または--mcp-configで的確に渡せる。余分な事前プロンプトが純粋な無駄になる大量サブエージェント実行に最適。

9. フック — 自動的な節約

フック（hooks）は、Claude Code内のイベントで発火するスクリプト。.claude/settings.jsonで設定し、トークン節約のルーチンを自動化できる。

フックの種類

  • PreToolUse — ツール呼び出しの前に発火。入力データのフィルタリングや変更に使用。
  • PostToolUse — 呼び出し後に発火。自動フォーマットや後処理に便利。
  • PreCompact — コンテキスト圧縮の前に発火。重要な情報の保存に使用。
  • Stop — エージェントが作業を終了した時に発火。完了の確認に使用。
  • SessionStart — セッション開始時に発火。コンテキストのプリロードに便利。

役立つフックの例

テスト出力のフィルタリング。 Anthropicの公式例 — Bashに対するPreToolUseフックで、長いテスト出力を切り詰め、失敗したテストとサマリーだけを残す。500行のログの代わりに10行がコンテキストに入る — トークンの直接的な節約。

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "command": "あなたのフィルタリングスクリプト.sh"
    }]
  }
}

保存後の自動フォーマット。 Write/Editに対するPostToolUseフック — ファイル保存のたびにprettierやblackを実行。モデルがコードのフォーマットにトークンを使う必要がない — ロジックを書き、フォーマットはフックが処理。

破壊的コマンドの防止。 Bashに対するPreToolUseフックで、rm -rfやDROP TABLEなどのコマンドをブロック。直接的なトークン節約にはならないが、高コストなエラーとやり直しを防ぐ。

コンパクト前のコンテキスト保存。 PreCompactフック — コンテキスト圧縮前に重要な決定と状態をファイルに保存し、コンパクト後も失われないようにする。

フックにできないこと

Nメッセージごとの自動コンパクトはフックで設定できない — これはClaude Codeの組み込み機能。ただしPreCompactフックを使って、圧縮時に何を保存するかを制御できる。

10. スクリーンショット — 隠れたトークン消費者

ドキュメントによるとClaudeは画像を解像度で圧縮する。実際には、圧縮はほとんど見られない。4Kモニターでは1枚のスクリーンショットが高額。

解決策：送信前にスクリーンショットを幅約400pxに縮小する。テキストは読みやすく、トークン消費は大幅に減少。

macOS向けに私が作った Open Screenshot がある — 解像度が圧縮された形式でスクリーンショットを直接撮影でき、手動でリサイズする必要がない。ぜひ使ってみてください！

11. すぐ使える設定：rtk + graphify

グローバルで常時有効にしている2つのツール — それぞれ§1の別々の項目に効く。rtk はコマンド出力の入力トークンを削り、graphify は「リポジトリ全体を読め」というコンテキストを排除する。どちらも独自のAPIキー不要（graphifyはセマンティクス処理を高コストなClaudeトークンではなく安価なOpenRouter経由で実行する）。caveman（§4）と組み合わせると完結したスタックになる：コマンド入力 + リポジトリコンテキスト + モデル出力の3層を網羅。

すぐ使える設定は専用リポジトリにまとめてある — suenot/claude-code-token-savers（スクリプト、パッチ、フック、setup.sh）。

rtk — コマンド出力の圧縮

rtk（Rust Token Killer）はCLIプロキシ：git、docker、pytest、cargoなど100以上のコマンドの出力をコンテキストに入る前にフィルタリング・重複除去・切り詰めし、60〜90% 削減する。単一バイナリ、依存なし、オーバーヘッド10ms未満、LLM不使用。

brew install rtk
rtk init -g --auto-patch   # Claude Code向けグローバルPreToolUse-フックをインストール
# Claude Codeを再起動して確認：git status

フックが透過的に git status → rtk git status へ書き換える。§9（フックによるテスト出力フィルタリング）と同じ手法を、一度に100以上のコマンドに適用したものだ。

graphify — リポジトリ全読み込みの代わりにナレッジグラフ

graphify はコードとドキュメントをナレッジグラフ（ノード、コミュニティ、god-nodes）に変換し、ファイルをコンテキストに流し込む代わりに クエリ (/graphify query "…") で必要な情報だけを取り出せる — §6のアイデアを実践した形だ。重要なポイント：セマンティック抽出はOpenRouter（deepseek/deepseek-v4-flash）経由で実行され、Claudeのトークンを消費しない — 中規模プロジェクトのグラフ構築コストはOpenRouterで~$0.10、セッショントークンはゼロ。

上記リポジトリ（graphify/フォルダ、./setup.sh）に含まれる設定内容：

  • OpenRouterバックエンド（~/.graphify/providers.json、モデルはGRAPHIFY_OPENROUTER_MODELで変更可）
  • SessionStart-フックによる自動watch：グラフが存在すれば変更を監視して更新し、未初期化のプロジェクトでは「/graphify . を実行してください」と表示するだけ（うっかり開いたルートや巨大フォルダがトークンを食い尽くさないよう配慮）
  • シンプルな no-media トグル（touch ~/.graphify/no-media）— ignoreファイルを手動編集せずに画像・PDF・動画をグラフから除外
  • セキュリティ修正：.graphifyignore が .gitignore を「上書き」しなくなった（置換ではなくマージ、PR #1364 としてアップストリームに提出済み）、さらに .gitignore 対象ファイルがグラフに含まれた状態でコミットされないよう pre-commit-guard を追加。

Caveman（§4）が3層目を担う — モデル自身の出力。rtk + graphify + caveman = コマンド入力、リポジトリコンテキスト、モデル出力をそれぞれカバー。ただし文章編集作業では caveman はオフにした方がいい（「normal mode」）— 簡潔すぎる出力スタイルが校正の邪魔になる。

pxpipe — リクエストを画像としてレンダリングする（§10を裏返した発想）

pxpipe（作者はteamchong）は、入力を予想外の角度から攻める。§10ではスクリーンショットは敵だった — 画像はトークンを食う。pxpipeはこれを逆手に取る：画像のトークンコストは、中にどれだけテキストを詰め込んだかではなく、そのピクセル寸法で決まる。実際のClaude Codeのトラフィックでは、密度の高いコンテンツ（コード、JSON、ツール出力）は画像トークン1つあたり約3.1文字を詰め込めるのに対し、テキストトークンでは約1文字にとどまる。そこで、あらゆるリクエストのかさばる静的な部分 — システムプロンプト、ツールのドキュメント、古い履歴 — を、リクエストがマシンを離れる前に密度の高いPNGにレンダリングする。モデルはそれを、Anthropicのcomputer useがすでに依存しているのと同じビジョンチャネルで読み取る。謳われている効果は入力の請求額が約59〜70%減少。そして持続的な指標はトークン削減そのもので、無料のcount_tokensによる反実仮想と比較してリクエストごとに測定される。

これはプロキシで、当然の疑問に先回りして答えると、統合はすでにネイティブ：プラグインもフックも不要、Claude Code組み込みのANTHROPIC_BASE_URLを使うだけ。

npm install -g pxpipe-proxy   # or on demand: npx pxpipe-proxy
pxpipe                                            # proxy on 127.0.0.1:47821
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude  # point Claude Code at it

127.0.0.1:47821のダッシュボードでは、節約されたトークン、text→image変換のすべてを並べて表示、ライブのkill switch、そして各イベントを~/.pxpipe/events.jsonlに記録する様子が見られる。圧縮されるのはリクエストだけ — レスポンスは通常どおりストリーミングされる。

⚠️ 可逆ではなく、しかもその取りこぼしは静かに起きる。 画像から読み取った正確なバイトレベルの値（16進文字列、ID、ハッシュ、シークレット）は、エラーになるのではなく**でっち上げられる（confabulate）**可能性がある。そのため直近のやり取りは自動的にテキストのまま保たれ、バイト単位で正確さが要る作業は、allowlistに載っていないモデル（CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6）のサブエージェントに回すべきで、これはテキストとして素通りする。読み手への依存も大きい：Fable 5リーダーではテキストのneedleで約100/100を叩き出すが、Opusは画像化されたコンテンツを誤読する — pxpipeがOpusをopt-in方式にしているのはこのためだ。

スタックとの衝突ポイント。 pxpipeはANTHROPIC_BASE_URLを占有する — Clotherをはじめとするどのラッパーも使う、まさにあのスロットだ — ため、チェーンしない限り2つのプロキシを同じbase URL上にぶら下げることはできない。前段に立てるプロキシは1つだけ選び、その上にフックベースのツール（rtk、graphify、caveman）を積む。これは中でも最も過激な入力圧縮ツールであり、リクエスト側の請求（システムプロンプト + ツールのドキュメント + 長い履歴）こそが本当に効いているときに試す価値がある。

12. サーバー側・APIレベルの節約（Claude Codeがすでにやっていること、そしてやっていないこと）

これまで挙げてきたのはすべてあなたが後付けするものだ。だが、節約の丸ごと1層はAnthropic側のワイヤーの向こうに存在する — その一部はすでにClaude Codeであなたのために有効になっており、一部は生のAPI/SDKの上に自分で組んだときにしか手が届かない。どちらがどちらかを知っておけば、プラットフォームがすでに解決した問題を直すためにツールを入れる愚を避けられ、そして本当はオフの機能をオンだと思い込む愚も避けられる。

高度なツール活用：Tool Search、Programmatic Tool Calling — デフォルトですでに有効

Anthropicのadvanced tool useスイート（2025年11月）は、このリストの中で単独最大の効果で、良い知らせは設定不要だということだ：

  • Tool Search Tool（defer_loading）。すべてのツールの完全なスキーマを毎リクエストでシステムプロンプトに流し込む代わりに、モデルにはツールの名前だけが見せられ、実際に必要なツールについてのみ完全な定義を取り寄せる。Anthropicの数字：大きなツールセットで77K → 8.7Kトークン（約85%）。Claude Codeではこれがすでにデフォルトで有効 — 多数のMCPサーバーやプラグインが接続されていても、余分なツールは呼ばれるまで名前だけの状態で座っており、モデルは必要に応じてスキーマを取得する。切り替えるスイッチはない：規模に応じて効いてくる — 接続しているツールが多いほど節約は大きくなる。唯一考える必要があるのはカスタムハーネス／Agent SDKアプリだ — そこでは自分で実装する（ツールにdefer_loading: trueを付ける）か、少なくともハーネスがdeferをしているか確認する必要がある。さもないと毎ターン、すべてのスキーマ分をまた払うことになる。
  • Programmatic Tool Calling。モデルが実行コンテナ内でコードを書き、ツールを呼び出してその結果をコンテキストに入る前にフィルタリングする — 生のツール結果がいちいちウィンドウを往復する代わりに。ツールを多用するエージェント実行で典型的には20〜40%（加えて精度も向上）。これはまだAPIネイティブ（ベータ）で、Claude Codeではまだ自動ではない。

要点： 約85%のツールスキーマ節約はClaude Codeですでにあなたのもの — 追加設定なし。自分でハーネスを書いている場合だけ気にすればいい。

コンテキスト編集（clear_tool_uses）— APIの機能；Claude Codeは独自版を提供

Anthropicのcontext editing（beta header context-management-2025-06-27、strategy clear_tool_uses_20250919）は、コンテキストがしきい値を越えると最古のツール結果を自動的にクリアし、それぞれを短いプレースホルダーに置き換える。Anthropicの100ターンの評価では、そのまま行けばコンテキスト枯渇で死んでいた実行で84%のトークン削減になった。

だが：その生のノブはClaude Codeには公開されていない（表に出すよう求めるオープンなリクエストはある）。代わりにClaude Codeが提供するのはmicrocompactだ — 大きなツール出力を自動的にディスクへ退避し、直近の結果のホットな末尾とパス参照だけを保持する — これが/compactやautocompactと並んで静かに動いている。つまり振る舞い（古いツール出力の刈り込み）はあなたのために自動でカバーされている；特定のAPIパラメータはAnthropicのAPI/SDKの上に直接組んだときにしか手が届かない。Claude Codeでclear_tool_uses設定を探すな — すでにハウス版が手に入っている。

先回りのプロンプトキャッシュ — キャッシュ読み取りが90%オフ、しかもほぼ自動

Prompt cachingはGAで基盤的：キャッシュ読み取りは0.10×入力（−90%）。TTLは2つ — 5分（デフォルト）と1時間（拡張）。Claude Codeはすでにあなたのために積極的にキャッシュしている；あなたが制御するのはキャッシュがヒットするかだ：

  • コンテキストの前方をバイト単位で安定に保つ — システムプロンプト、ツール定義、CLAUDE.mdはターン間でころころ変わってはならない。さもないとプレフィックスキャッシュが外れ、モデルは最初から読み直す。
  • セッション途中でツールを並べ替えたり初期コンテキストを書き換えたりしない（これはまさにあのキャッシュを焼くトラップだ）。
  • Opus 4.8はここで助けになる：role:"system"メッセージをユーザーターンの後に置けるようになり、キャッシュされたプレフィックスを壊さずに指示を追加でき、さらにキャッシュ可能な最小プロンプトを1,024トークンに下げた。

Message Batches API — オフラインの一括処理に一律50%オフ

非対話的な一括作業 — §2の「8000のスクリプト、それぞれにサブエージェント1つ」シナリオ、あるいは一括の要約／分類／評価 — には、Message Batches APIがそれらを非同期で実行し（結果は24時間以内、たいていはもっと早い）、入力・出力ともに一律50%割引、しかもプロンプトキャッシュと重ねられる（キャッシュ読み取りにさらに90%）。

落とし穴：Claude Code自体にはバッチモードがない。 これは対話的なREPLだ — どのターンもライブで全額のリクエストであり、「8000ジョブを半額でキューに入れる」ボタンはない。50%割引は1層下、生のAPIにあり、CLIを離れてはじめて手が届く：

  • Anthropic API / SDKを直接 — client.messages.batches.create(...)（Python/TS）。ここで一括パスを自分でスクリプト化するか、対話的なCLIではなくClaude Agent SDKの上に組む。
  • AWS Bedrock — 「Batch Inference」。
  • Google Vertex AI — 「Batch Prediction」。
  • （他所も同じパターン：OpenAIにも−50%の同等のBatch APIがある。）

つまり経験則：対話的なコーディング → Claude Code（キャッシュが重労働を担う）；オフラインの一括処理 → API/SDKやBedrock/Vertexに降りてバッチ化する。 一括ラベリングを対話的なCLIに無理やり通そうとすると、その50%をテーブルに置き去りにすることになる。

安上がりな衛生管理：/context、痩せたCLAUDE.md、遊んでいるMCPサーバーの切り離し

  • /context は、ウィンドウを埋めているもののトークンごとの内訳を表示する — システムプロンプト、システムツール、MCPツール、メモリファイル（CLAUDE.md）、カスタムエージェント、メッセージ。誰が大食いかを見るために実行しよう。
  • 肥大したCLAUDE.mdは毎メッセージへの税金だ — 10Kトークンのメモリファイルは毎ターン再送される。痩せさせておき、タスク固有の指示は代わりにスキル（オンデマンドで読み込まれる）へ押し込む。
  • 遊んでいるMCPサーバーはすべて、毎リクエストでツール定義を課金する。 /mcp（またはcctoggleのようなトグル）で使っていないものを切断する。Tool Searchはこれを和らげるが、サーバーをそもそも使わない方が、それをdeferするより安い。

Structured Outputs — リトライと前置きを消す

Structured Outputs（ベータ）は制約付きデコードでスキーマ準拠のJSONを保証する（output_format、またはツールでのstrict: true）。節約は間接的だが実在する：無効なJSONのリトライ往復がなくなり（1回のパース失敗は、この機能の約2〜3%のスキーマオーバーヘッドより高くつく）、モデルが答えの周りに巻きつけがちな冗長なナレーション付き推論をそぎ落とす。

わざわざやる必要のない2つ

  • token-efficient-tools-2025-02-19ヘッダーは過去のもの。 これはClaude 3.7 Sonnetだけでツール呼び出しの出力トークンを削っていた；Claude 4+の全モデル（Opus 4.7/4.8を含む）はデフォルトでトークン効率的なツール使用を行うので、このヘッダーは今日では何もしない。追加するな。
  • LLMLingua-2（Microsoftのプロンプト圧縮器、2〜5倍）は本物で優秀だが、これは同じ入力圧縮の枠にはまるエンジンにすぎない — pxpipeのような入力圧縮ツール（§11）が埋めるのと同じ役割であって、それらと並べて別途インストールする独立した手法ではない。

節約チェックリスト

アプローチ節約効果
短いコンテキストのサブエージェント長いセッションで2〜5倍
ルーティンに中国製モデル価格で5〜10倍（$30 vs $200）
常駐MCPの代わりにスキル1.5〜2倍
出力フィルタリングのフックテスト/ログタスクで1.5〜3倍
コンパクトなスクリーンショットビジュアルタスクで1.5〜2倍
全コンテキストの代わりにグラフ/RAG3〜5倍
単純タスクでreasoningを無効化1.5〜2倍
サブエージェントに--bareモード毎回の起動で1.5〜2倍
プラン承認付きフレームワーク間接的 — やり直しの削減
rtk — コマンド出力の圧縮（PreToolUse-フック）git/docker/pytest/ログで1.5〜3倍
graphify — 全コンテキストの代わりにグラフ（セマンティクスはOpenRouter）大規模リポジトリのナビゲーションで最大10倍；構築~$0.10、Claudeトークン不使用
pxpipe — リクエスト（システムプロンプト／ツールのドキュメント／履歴）を密度の高いPNGとしてレンダリングビジョンチャネル経由で入力を約59〜70%削減；バイト単位で正確な値には非可逆、Opusはopt-in
Tool Search / defer_loading（Claude Codeで自動）ツールスキーマのトークンを最大約85%；設定ゼロ — 規模に応じて効く
コンテキスト編集 / microcompact（Claude Codeで自動）長いエージェント実行で最大84%；APIのノブclear_tool_usesは生のSDK経由でのみ
先回りのプロンプトキャッシュ（安定プレフィックス、1h TTL）キャッシュ読み取りが0.10×（−90%）；ほぼ自動、プレフィックスをバイト単位で安定に
Message Batches API（オフライン一括、Claude Codeではない）入力＋出力に一律−50%；API/SDK、Bedrock、Vertex経由 — キャッシュと重ねられる
/context ＋ 痩せたCLAUDE.md ＋ 遊んでいるMCPサーバーの切り離しメモリファイルと遊休ツール定義の削減でメッセージあたり数千トークン
Structured Outputs（strict JSON）パースのリトライ往復と冗長な前置きを排除

いくらでも使い込める — 月額$200のアカウント10個でも限界ではない。でも、それは効率性の指標ではない。目標は、品質を犠牲にせずにコストを少なくとも10分の1に減らすこと。