最近、Claudeのプランに大きな変化があるという声が多く、プランのコスパが悪くなったか、プランに影響する大きなバグがあるかのどちらかを指摘する人が増えている。
読み始める前に、このページをブックマークしておくといい。Claude使用コスト効率化戦略を完全に実装していく中で、何度か戻って読みたくなるはずだ。
トークンを無駄にせず、より多く作り、より多く生み出せるようになる。
なぜClaudeが突然プランユーザーに与えるトークンが少なくなったように感じるのか、その主な理由を特定するために多くの調査をした。
一部はプロンプトキャッシングのバグに関係しているかもしれないが、実際にトークンの無駄を防げる場所は多い。さらに、これらのシステムが実際にどのように機能するかについての基礎知識を持っている人はほとんどいない。
たとえば、この記事を調査中に、プロンプトに画像を追加するとキャッシュが壊れることがわかった。
多くの人がUIやUXにClaudeを使い、常に画像を提供しているが、それがプロンプトキャッシュを壊している。キャッシュされたプロンプトは通常、通常のプロンプトコストの10%しかかからない。
しかしキャッシュするには元のベース入力価格の25%かかる。
だから100万トークンが5ドルなら、キャッシュするために文字通り6.25ドル払い、0.5ドルで使えるようにする。しかしプロンプトキャッシングが壊れると、毎回また6.25ドルかかる。
プランを使っていても、プロンプトキャッシングは影響する。だから、プロンプトキャッシングを壊さない方法を知ることが本当に重要だ。
また、100万コンテキストウィンドウはメモリに関して助けよりも問題を増やした。この記事の残りでその点と、そちら側からの漏れも実際に解決できる方法について説明する。
このガイドは5つのレベルで構成されている。
---
TL;DR — 最も影響力の高い5つのヒント
これだけ読むなら、この5つをやれ。最小限の努力で請求額を50%以上削減できる。
1. シンプルなタスクにはHaiku 4.5を使う（入力/出力 / per MTok。Sonnetの/と比べて）。ほとんどの分類、抽出、ルーティングタスクに大きなモデルは不要。
2. プロンプトキャッシングを有効にする。リクエストに "cache_control": {"type": "ephemeral"} を追加する。キャッシュ済み読み取りは標準入力価格の0.1倍。つまり90%オフ。
3. 急がない作業にはBatch APIを使う。全トークンに50%割引。キャッシングと組み合わせると最大95%の節約。
4. シンプルなタスクにはeffortパラメータをlowに設定する。Claudeは深い推論をスキップして少ないトークンで応答する。速くて安い。
5. タスク間でコンテキストをクリアする。フォローアップメッセージのたびに会話全体が再処理される。10回のやり取りで、気づかないうちにトークン消費が10倍になる可能性がある。
では、完全な解説へ。
---
レベル1：無料で得られる改善
実装に2分。ゼロ努力。一度やれば永久に節約できる。
ヒント1. まずHaikuを使え。本気で。
Haiku 4.5：/ per MTok。Sonnet 4.6：/。Opus 4.6：/。
分類、抽出、ルーティング、要約、シンプルなQ&Aには、Haikuで十分。3〜5倍節約できる。ほとんどの開発者は品質の違いに気づかずに、日常タスクの60〜70%でHaikuを使える。
ヒント2. effortパラメータを使う。
Claude Opus 4.6とSonnet 4.6はeffortレベル（low、medium、high、max）をサポートしている。effortが低いほど推論のトークンが少なくなる。シンプルなタスクにはlowでレイテンシとコストの両方が劇的に削減される。
json:
{
"thinking": {"type": "adaptive"},
"effort": "low"
}
ヒント3. 不要なときはextended thinkingを無効にする。
Extended thinkingのトークンは出力トークンとして課金される。デフォルトのバジェットはリクエストごとに数万トークンになる可能性がある。シンプルな検索、フォーマット、分類タスクなら、thinkingを完全にオフにする。
ヒント4. 複雑なタスクのthinkingバジェットに上限を設ける。
thinkingが必要なときは、budget_tokensを合理的な上限に設定する。多くのタスクには8,000〜16,000のthinkingトークンで十分。日付をフォーマットするために10万トークンの推論は必要ない。
ヒント5. thinkingブロックにdisplay: "omitted"を使う。
アプリがClaudeの推論をユーザーに表示しない場合、thinkingのdisplayをomittedに設定する。これにより出力品質に影響せずにfirst-tokenまでの時間が短縮される。thinkingトークンの費用は払うが、ストリーミングのオーバーヘッドをスキップできる。
ヒント6. プロンプトに単語数または行数の制限を設ける。
「50文字以内で答えて」や「最大3つの箇条書きで」は出力トークンを直接削減する。Claudeはこれらの制約を遵守する。長さについての短い指示＝短い（安い）応答。
ヒント7. 出力形式を明示的に制限する。
「name、status、scoreをキーとするJSONオブジェクトを返して。説明不要。」は常に「これを分析してあなたの考えを聞かせて」より安い。オープンエンドなプロンプトはオープンエンドな（高い）応答を生む。
---
レベル2：プロンプトアーキテクチャ
構造化に5分。プロンプトの書き直しが必要だが、即座に効果がある。
ヒント8. 直接的に書く。丁寧な挨拶を省く。
「こんにちは、Claude！お元気ですか。ちょっとお聞きしたいことがあるんですが...」はゼロ価値の言葉にトークンを燃やしている。1単語いくらで書いていると思って書け。実際そうなんだから。
代わりに：このJSONをパースして、nameフィールドだけを返して。
ヒント9. 指示を先頭に置く。
最も重要な指示を最初に置く。実際のリクエストを3段落のコンテキストの下に埋めない。Claudeはプロンプトの冒頭部分にアテンションを重く置く。
ヒント10. XMLタグを使った構造化プロンプトを使う。
<instructions>、<context>、<output_format>などのタグがClaudeの意図の把握を速め、より焦点を絞った応答を生む。曖昧さが減ると、Claudeが何を望んでいるか「推測」するための無駄なトークンが減る。
ヒント11. 一度だけ言う。
指示を繰り返してもClaudeがより確実に従うようにはならない。トークンが余分にかかるだけだ。各指示を明確に、一度だけ述べる。
ヒント12. 関連するコンテキストだけを含める。
1つの関数を変更するだけなのに500行のファイルを貼り付けない。関連するセクションだけを貼る。ファイル構造が必要なら、全体をダンプする代わりに1文で説明する。
ヒント13. assistantのプリフィルテクニックを使う。
assistantターンをプリフィルしてClaudeの応答を始める。JSON出力が欲しいなら、{でプリフィルすればClaudeは前文や説明なしでそこから続ける。
json:
{
"role": "assistant",
"content": "{"
}
ヒント14. JSONキーをプリフィルして前文を完全にスキップする。
これはヒント13の強化版だ。{だけでなく、{"result":でプリフィルするとClaudeは値に直接ジャンプする。毎回トークンを消費する「わかりました！JSONを作成します：」のような前文がなくなる。
ヒント15. 会話履歴からthinkingブロックを除去する。
APIは以前のターンのthinkingブロックを自動的に無視する。ただし、履歴を手動で管理している場合は、これらを戻さないようにする。ゼロ利益で入力トークン数が膨らむ。
ヒント16. 送信前にtoken counting APIを使う。
Anthropicには推論を実行せずにリクエストの正確なトークン数を返すエンドポイントがある。予想外に大きいプロンプトが高くつく前に発見するために使う。リクエストが突然高くなった理由のデバッグに最適。
---
レベル3：キャッシングのマスタリー
適切に設定するのに10分。これが本当に節約できる場所だ。
プロンプトキャッシングはClaude APIで最も強力なコスト削減機能の一つだ。キャッシュされた入力トークンは標準入力価格のわずか10%。正しく使う方法と、壊さない方法を説明する。
ヒント17. 自動キャッシングを有効にする。
最も簡単な出発点。リクエストレベルでcache_controlを追加するとシステムがブレークポイントを自動的に処理する。
json:
{
"model": "claude-sonnet-4-6",
"max_tokens": 1024,
"cache_control": {"type": "ephemeral"},
"system": "ここにシステムプロンプト...",
"messages": [...]
}
ヒント18. キャッシュ可能なようにプロンプトを構造化する。
Claudeはコンテンツをこの順序で処理する：tools → system prompt → messages。最も安定した再利用可能なコンテンツを先に置く。システムプロンプトとtool定義はリクエスト間でほとんど変わらないため、完璧なキャッシュ候補だ。
ヒント19. 料金の計算を理解する。
キャッシュ書き込み：ベース入力価格の1.25倍（最初のリクエストのみ）
キャッシュ読み取り：ベース入力価格の0.1倍（以降すべてのヒット）
1時間キャッシュ：書き込みコスト2倍、読み取りは同じ0.1倍
Sonnet 4.6（入力/MTok）では、キャッシュ読み取りの実質コストは/bin/zsh.30/MTok。同じ1万トークンのシステムプロンプトをすべてのリクエストで送っているなら、キャッシングは2回目の呼び出しで元が取れる。
ヒント20. 粒度の細かい制御のための明示的なキャッシュブレークポイントを使う。
異なる頻度で変わるセクションを持つ複雑なプロンプトには、個々のコンテンツブロックにcache_controlを配置する。最大4つのブレークポイントを使える。
ヒント21. 最小トークン閾値を満たす。
キャッシングはチェックポイントごとに最小トークン数が必要で、モデルによって異なる。
Opus 4.6/4.5：4,096トークン。Sonnet 4.6：2,048トークン。Sonnet 4.5/4：1,024トークン。Haiku 4.5：4,096トークン。
閾値以下だとリクエストは成功するがキャッシュされず、エラーも返らない。レスポンスのcache_creation_input_tokensフィールドを確認してキャッシングが実際に機能したか検証する。
ヒント22. キャッシュを温かく保つ。
デフォルトのTTLは5分で、ヒットのたびにリフレッシュされる。リクエスト間隔が5分を超えるとキャッシュが切れて再び書き込みコストを払う。間隔が長いワークロードには1時間オプションを使う（書き込み2倍、読み取りは引き続き0.1倍）。
定期的に5分を超えるextended thinkingタスクには、1時間キャッシュはほぼ常に元が取れる。
キャッシュを壊す方法（やってはいけないこと）
このセクションだけで何時間ものデバッグを節約できる。
ヒント23. リクエストごとに変わるコンテンツにcache_controlを置かない。
これが最も一般的なキャッシングの間違いだ。タイムスタンプ、セッションID、またはユーザーのメッセージを含むブロックにキャッシュブレークポイントを置くと、毎回プレフィックスハッシュが変わり、読み取りゼロですべてのリクエストでキャッシュ書き込みが発生する。1.25倍の書き込みプレミアムを繰り返し払い、節約がない。
ヒント24. 画像を追加したり削除したりしない。
プロンプトのどこかに（キャッシュされたセクションだけでなく）画像を追加したり削除したりするとキャッシュが壊れる。ワークフローで画像がある場合とない場合があるなら、それらを別々のキャッシュライフサイクルを持つ別々のリクエストパターンとして扱う。
ヒント25. キャッシュブレークポイントより前のものを変更しない。
キャッシュは完全なプレフィックスでマッチする。システムプロンプト、tool定義、またはキャッシュされたブロックより前のメッセージの1文字でも変わると、完全なキャッシュミスと再書き込みが強制される。システムプロンプトは慎重にバージョン管理する。
ヒント26. thinkingパラメータを切り替えない。
リクエスト間でextended thinkingのオン/オフを切り替えたり、バジェット割り当てを変更したりすると、メッセージキャッシュブレークポイントが無効になる。キャッシュされたシステムプロンプトとtool定義はthinkingの変更に生き残るが、メッセージレベルのキャッシュは生き残らない。
クイックリファレンス：キャッシュ無効化
キャッシュを壊す：ブレークポイントより前のコンテンツ変更、tool_choiceの変更、画像の追加/削除、thinkingパラメータの変更、TTLの期限切れ
キャッシュが生き残る：ブレークポイントより後のメッセージ変更、max_tokensの変更、最後への新規ユーザーメッセージ追加
ヒント27. 並行リクエストに注意する。
キャッシュエントリは最初のレスポンスがストリーミングを始めた後にのみ利用可能になる。同時に10個の並行リクエストを送ると、最初の1つだけがキャッシュに書き込む。他の9つはエントリがまだ存在しないのでキャッシュヒットしない。ファンアウトパターンには、最初のリクエストを送り、ストリーミングが始まるのを待ち、それから残りを送る。
---
レベル4：システム設計
設計に15分。これが趣味と本番チームを分ける決断だ。
ヒント28. モデルルーターを構築する。
すべてのリクエストを同じモデルに送らない。シンプルなタスクはHaikuに、中程度の複雑さはSonnetに、深い推論だけをOpusにエスカレートする。この単一のアーキテクチャ決定が、スケールでは通常最大のコストレバーだ。
ヒント29. 急がない作業にはBatch APIを使う。
全トークン価格に50%割引。24時間以内に結果が出る。バルクコード分析、コンテンツ生成、データ処理、リアルタイム応答が不要なワークロードに最適。プロンプトキャッシングと組み合わせると最大95%の節約。
ヒント30. トークン効率の高いtool useを使う。
Claude 4モデルはすべてデフォルトでトークン効率の高いtool useをサポートしており、出力トークンを平均14%節約できる（最大70%）。Claude 3.7 Sonnetにはベータヘッダーtoken-efficient-tools-2025-02-19を追加する。文字通り無料の節約だ。
ヒント31. 必要なtoolだけを含める。
すべてのtool定義はすべてのリクエストで送られる。15個のtoolが定義されているが特定のタスクに2個しか必要ない場合、毎回のAPIコールで13個の無用なtool定義を払っている。タスクに基づいて動的にtoolをロードする。
ヒント32. 関係ないタスク間でコンテキストをクリアする。
Claude Codeでは、トピックを切り替えるときに/clearを使う。API統合では新しい会話を始める。以前のタスクの古いコンテキストは以降のすべてのメッセージで再処理され、コストが指数関数的に複利で増大する。
ヒント33. 長い会話を要約する。
すべてのリクエストで完全な会話履歴を送る代わりに、定期的に以前のターンを要約に圧縮する。20往復のやり取りを200文字の要約に置き換える。トークン使用量が指数関数的から線形になる。
ヒント34. 関係ないターンを削除する。
マルチターンの会話のすべてのメッセージがコンテキストに残る必要はない。現在のタスクに関係なくなったターンは削除する。一貫性を維持するためにClaudeが必要なものだけを保持する。
ヒント35. 詳細な操作をサブエージェントに委任する。
テストの実行、ドキュメントの取得、ログファイルの処理はコンテキストをトークンで溢れさせる可能性がある。これらをサブエージェントに委任することで、冗長な出力はサブエージェントのコンテキストに留まり、簡潔な要約だけがメイン会話に返る。
Claude Codeでは、エージェントチームは標準セッションより約7倍多くのトークンを使うが、トークンの分離によりプライマリコンテキストがスリムで安いまま保たれる。
正直に言うと、100万コンテキストウィンドウはほとんどのユーザーが気づかないうちにコスト効率の問題を本当に生み出している。このパラドックスについてのClaudeの答えはこうだ：
---
レベル5：監視と測定
継続的な規律。測定しないものは最適化できない。
ヒント36. Usage and Cost APIで監視する。
AnthropicのAPIはモデル別、キャッシュヒット/ミス別、トークンタイプ別の使用量を提供する。ダッシュボードを設定する。最もトークンを消費するエンドポイントを見つける。それを先に修正する。
Claude Codeでは、/costを使って現在のセッション使用量を確認するか、ステータスバーを設定して継続的に表示させる。チームにはConsoleでワークスペースの支出制限を設定する。
このオープンソースツールも使える：
https://github.com/Maciek-roboblog/Claude-Code-Usage-Monitor
---
最後に：
トークン最適化はケチになることではない。賢くなることだ。
最高の製品や自動化を出荷しているチームは、トークンを効率的に使うことを気にしている。本当に重要なことにトークンを使う。
まずレベル1から実装して、上に向かって進んでいこう。多少の作業が必要だが、やり終えれば自分を褒めることができ、創造性と夢の追求のためのトークンが残る。
P.S. この投稿を保存して、ステップバイステップで使い始めよう。