Claude Platformのコストを削減する3つの実装レバー

Claude Platformのコスト削減で押さえる3つのレバー

Claude Platformを使うアプリケーションのコストは、性能を落とさなくても下げられる余地が残っていることが多いです。効くレバーは3つに絞れます。プロンプトキャッシュのヒット率を上げること、フロンティアモデルの足を引っ張る指示のアンチパターンを取り除くこと、タスクの難度に合わせてeffortを調整することです。

3つはClaude Codeに組み込まれたclaude-apiスキルのコマンド(/claude-api prompt-audit /claude-api cost-optimize /claude-api hillclimb)から実行できます。個別コマンドの詳しい使い方は各記事で扱うため、ここではどの症状にどのレバーが効くかの全体像を先に示します。

前提

claude-apiスキルはClaude Code上で動きます。会話に明示的に呼び出さなくても、コスト削減やプロンプト設計に関する質問をすると自動で読み込まれる仕組みです(詳細はclaude-apiスキルの自動読み込み)。3つのコマンドのうち/claude-api hillclimbだけは、正解ラベル付きの評価データセットが無いと実行できません。prompt-auditとcost-optimizeはデータセット無しでも動きます。

症状から着手するコマンドを選ぶ早見表です。

プロンプトキャッシュのヒット率を上げる

Claudeはリクエストを処理する前に、プロンプトを内部状態へ変換するprefillという処理を行います。これは入力処理の中で最もコストがかかる部分です。プロンプトキャッシュはこの内部状態(KVキャッシュ)を保存し、同じプレフィックスで始まるリクエストが来たときに再計算を省きます。キャッシュ読み込みの価格は通常入力の1/10が基本で、Claude Opus 5.5では5%、Claude Fable 5.1とMythos 5.1では2.5%まで下がります。

キャッシュを機能させる条件は3つあります。キャッシュは特定のモデルに紐づくこと、プレフィックス全体がバイト単位で一致する必要があること、そしてキャッシュには有効期限(TTL)があることです。既定のTTLは5分で、書き込みは5分キャッシュで通常入力の1.25倍、1時間キャッシュでは2倍の価格になります。キャッシュできるプロンプトの長さにも下限があり、モデルによって512〜4,096トークンの範囲で決まっています(下限に満たないプロンプトはエラーにならず、単にキャッシュされません)。ヒット率を崩しやすい典型的な原因は次のとおりです。

• 会話の途中でeffortやthinkingの設定を変える(プロンプト先頭にレンダリングされるため)。Claude Opus 5とFable 5.1に限っては、途中で変えてもキャッシュが壊れません
• システムプロンプトに動的な値を混ぜる。タイムスタンプやIDのような変わる値がプレフィックスに入っていると、呼び出しのたびにキャッシュが崩れます
• ツール定義の順序を変える。Messages APIはツール定義をプロンプトの先頭に固定順で並べるため、定義を少しでも変えるとキャッシュが崩れます
• 会話を分岐する。サブエージェントや分岐先が親のキャッシュを共有できるのは、プレフィックスがバイト単位で一致し、同じモデル・同じeffortの場合だけです
• キャッシュのTTLより長く動くサブエージェントや同期的なツール呼び出し。5分TTLはリクエスト開始時点から数えるため、結果が返る前に5分を超えると、通常より高い書き込み価格で再構築することになります

対処の方向性は4つです。頻度の低いツールはdefer_loadingで宣言しておき、Claudeがツール検索で参照するまでキャッシュ済みプレフィックスの外に置きます。システムプロンプトの追記はプロンプト自体を書き換えるのでなくメッセージとして追加します。安定した部分(ツール定義・システムプロンプト)を先頭に、変化する会話履歴をその後ろに置きます。モデルやeffortを変えるタイミングは、compactionのようにどのみちキャッシュが崩れる操作に合わせます。5分を超えて動くエージェントやサブエージェントには、1時間TTLを検討します。

1時間TTLの損益分岐は単純です。書き込みは5分キャッシュの1.25倍に対して1時間キャッシュは2倍なので、追加コストは通常入力の0.75倍分。5分キャッシュが1回切れて再書き込みが発生するだけで、この差は相殺されます。つまり5分以内に1回でもキャッシュが切れる呼び出しパターンなら、1時間TTLに切り替えたほうが安くなります。

自動化する手段として、リクエストの最上位にcache_controlを1つ置くだけの自動キャッシュがあります。ブレークポイントを最後にキャッシュ可能なブロックへ自動的に移動させるため、会話が伸びてもcache_controlを手で更新する必要がありません。多ターン会話での挙動やmax_tokens: 0を使った事前ウォームアップは既存記事で詳しく扱っています。プロンプトキャッシュの基本的な仕組みはPrompt Cachingの解説記事を参照してください。

キャッシュのヒット率はClaude Consoleのキャッシュ診断で確認できます。ヒット率が想定外に落ちたときは、診断APIが直前のリクエストとどこで分岐したかを教えてくれます。

指示のアンチパターンを取り除く — /claude-api prompt-audit

プロンプトには、過去のモデルの弱点を埋めるための指示が蓄積しがちです。こうした指示はフロンティアモデルの能力に対して古くなり、コストを押し上げる原因になります。アンチパターンは次の6種類です。/claude-api prompt-auditコマンド自体の詳しい使い方はClaude Codeのprompt-auditで古いモデル向けの記述を検出するで扱っています。ここでは3レバーの中での位置付けと効果の規模を示します。

/claude-api prompt-auditはこれらのアンチパターンを、作業ディレクトリ内のプロンプト・スキル・ツール説明(CLAUDE.mdやClaude Code自体の設定を含む)から機械的に検出します。カスタマーサポート用のベンチマークでOpus 4.8からOpus 5.5への移行を計測すると、モデルIDを変えただけで約18%のコスト削減、そこにprompt-auditを適用するとさらに約9%のコスト削減が積み上がりました。正解率もおよそ2ポイント向上しています。原因は3つです。廃止済みのthinking設定がAPIのリクエストを一律拒否していたこと、矛盾する返金ルールのせいでOpus 5.5が本来払うべき返金4件を顧客への確認待ちのまま保留していたこと、そして手動のスクラッチパッドがOpus 5.5の内蔵thinkingと衝突し、3件のチケットでツール呼び出しを実行せず思考内に書いて終わらせていたことです。

/claude-api prompt-audit

Opus 5.5への移行にあわせてプロンプトを見直す作業は、thinking無効プロンプトの移行手順とあわせて進めると重複が少なくなります。

effortを作業量に合わせて調整する

effortはClaudeに「どれだけ粘るか」を指示するパラメータです。低いeffortでは早く結論に達し、高いeffortでは検証や別解の検討を重ねます。同じモデルでも、effortを上げたときのコストと性能の伸び方は一様ではありません。

Claude Fable 5はFrontierCode Diamond(最難関50問)で低effort時に11.5%・1タスクあたり5.35ドル、最大effort時に30.9%・19.00ドルでした。effortを上げると正解率は約2.7倍(19ポイント増)になりますが、コストは約3.5倍です。一方、Claude Fable 5.1のHumanity's Last Exam(ツールなし)では、低effortで約53%・1問あたり約0.30ドル、最大effortで約61%・約2.23ドルという結果になり、最後の一段はコストが46%増えるのに正解率はベンチマークのノイズの範囲内(0.5ポイント程度)しか上がりませんでした。

effortの誤設定は両方向で起こります。「高いほど良い」という思い込みは過剰な検討を招き、コストと遅延を増やしたうえで回答の質を下げることがあります。逆にeffortを下げすぎると、Claudeは十分な根拠が集まる前に止まり、ツール呼び出しの回数が減って最初の検索結果だけで答えてしまうことがあります。

有効な調整方法として、まず強いモデルを低effortで試すことが挙げられます。CursorBench 3.2では、Claude Fable 5.1を低effortで動かすと、Fable 5を高effortで動かした場合と同等の性能を約3分の1のコストで達成しました。Fable 5.1のプロンプトキャッシュ読み込み単価がFable 5の1/4($0.25/MTok対$1.00/MTok)であることも寄与しています。会話の途中でeffortを切り替える実装は既存記事に手順があります。

タスクの性質を理解することも重要です。effortを段階的に上げてもコストとスコアの曲線が平坦なら、そのタスクは思考量に律速されていないという判断材料になります。この探索を自動化するのが/claude-api hillclimbで、評価データセットを訓練用とテスト用に分割し、設定変更を提案し、失敗した訓練事例を読んで修正案を出します。前提は評価データセットがあることで、無ければこのコマンドは使えません。カスタマーサポートのベンチマークで実行した例では、Opus 4.8の既定(高effort)から出発し、まずOpus 5を低effortにしてprompt-auditの指摘(必須ツール呼び出しの儀式化・スクラッチパッド・矛盾ルール)を取り除くことで、訓練正解率98.9%・1件あたり2.6セントを達成しました。そこからSonnet 5・低effortへ切り替えるとコストは1件1セントまで下がりましたが正解率は88.9%に落ち、ルーティングルールと返金上限の参照を追加して98.9%まで戻しています。ホールドアウトの14件では、最終設定が90.5%(元の設定は78.6%)を約5分の1のコストで達成しました。

3レバーをまとめて回す — /claude-api cost-optimize

個別のレバーを組み合わせて棚卸しするコマンドが/claude-api cost-optimizeです。まず支出の内訳を、Claude Admin APIキーがあれば組織の利用状況・コストレポートから、なければ各APIレスポンスのusageオブジェクトのログから、それも無ければリクエスト構築コードを読んで見積もります。そのうえで、プロンプトキャッシュの適用余地、prompt-auditによる指示の削減、出力量の制限、まとめて実行できる作業のBatch API化の順に節約策をランク付けします。評価データセットを渡せば、effortとモデル選択の性能・コストのトレードオフも計算します。

/claude-api cost-optimize

4つの公開ベンチマークでOpus 5.5を基準に実行した結果は次のとおりです。

cost-optimizeの実行手順は/claude-api cost-optimizeの解説記事にまとめています。

導入手順とよくあるつまずき

3つのコマンドは役割が異なるため、順番に使い分けます。フロンティアモデルへ移行した直後は/claude-api prompt-auditでアンチパターンを洗い出し、次に/claude-api cost-optimizeでキャッシュ・出力量・バッチ化まで含めた棚卸しを行い、評価データセットが用意できるタスクでは/claude-api hillclimbでモデルとeffortの組み合わせを反復探索します。

つまずきやすい点は次のとおりです。

• Opus 5とFable 5.1以外の組み合わせでは、effortの途中変更でキャッシュが壊れます。それ以外のモデルで会話の途中でeffortを変えると、変更以降のリクエストはキャッシュ書き込みからやり直しになります
• defer_loadingしたツールは、Claudeがツール検索で参照するまで会話に追加されず、その間は呼び出せません。よく使うツールをdefer_loadingの対象に含めていないか確認します
• 1時間キャッシュは書き込みコストが2倍になります。TTLを延ばす判断は、5分キャッシュが切れる頻度と書き込みコストの増分を比べた材料で決まります
• 廃止済みの設定(手動thinking budgetなど)はエラーで弾かれるため、prompt-auditを走らせる前にモデル移行そのものが失敗していないかを先に確認する必要があります

まとめ

Claude Platformのコスト削減は、性能を犠牲にする値下げではなく、キャッシュ・指示・effortという3つのレバーの調整で実現できる余地です。まずプレフィックスの構造を安定させてキャッシュヒット率を上げ、次に/claude-api prompt-auditで古い指示のアンチパターンを取り除き、最後に/claude-api hillclimbでモデルとeffortの組み合わせを評価データセットに基づいて探索する。この順番を守れば、コスト削減は正解率とのトレードオフではなく、無駄を削る作業になります。