プロンプトキャッシュ、指示、および努力のチューニングにより、アプリケーションのパフォーマンスを犠牲にすることなく、Claude のコストを削減できます。
パフォーマンスとコストは、しばしばトレードオフの関係と見なされます。つまり、支出を抑えれば、結果が悪くなることを受け入れることになります。実際には、Claude Platform を使用する多くのアプリケーションが、3 つの修正によってパフォーマンスを犠牲にせずにコストを削減できることがわかっています。それは、プロンプトキャッシュのヒット率を最大化すること、最先端の Claude モデルにアップグレードする際にプロンプトからアンチパターンを削除すること、そしてタスクに応じて努力を調整することです。このガイダンスを claude-api スキル にまとめました。この記事では、Claude Code と claude-api スキルを使用して、パフォーマンスを維持または向上させながらコストを削減する方法を紹介します。
プロンプトキャッシュ
Claude が応答を生成する前に、まずプロンプトを内部の作業状態に処理します。このステップは プリフィル と呼ばれ、入力処理の中で最もコストがかかる部分です。プロンプトキャッシュは、その状態（キー・バリュー、つまり KV キャッシュ）を保存します。リクエストが同じプレフィックスで始まる場合、Claude はそれを再計算する代わりに読み戻します。キャッシュ読み取りは、完全な入力価格の一部 で課金されます。
プロンプトキャッシュを効果的に使用するための実用的な考慮事項がいくつかあります。まず、プロンプトキャッシュは特定のモデルに固定されます。次に、プロンプトキャッシュの読み取りは、プレフィックス全体で バイト単位で正確 である必要があります。最後に、プロンプトキャッシュには 限られた有効期間 (TTL) があります。
これらの点を念頭に置くと、いくつかの実用的なヒントがあります。
- 会話の途中で努力設定を変更する際は注意してください。これらの設定は、コンテンツの前にプロンプトにレンダリングされるため、キャッシュされたプレフィックスの一部になります。Opus 5 や Fable 5.1 などの一部の Claude モデルでのみ、キャッシュを壊さずに会話の途中で努力を更新 できます。
- 変動する値をプレフィックスに含めないでください。システムプロンプト内の動的なタイムスタンプや ID は、モデル呼び出し間で変化し、キャッシュを壊す可能性があります。
- ツール定義が自己再配置しないようにしてください。Claude messages API を使用する場合、プロンプトは固定順序で組み立てられ、ツール定義が先頭にレンダリングされます。ツール定義に変更があると、キャッシュが壊れます。
- 会話をフォークする際は注意してください。サブエージェントとブランチは、フォークのプレフィックスがバイト単位で同一であり、同じモデルで、同じ努力を使用している場合にのみ、親のキャッシュを共有します。
修正方法
プロンプトキャッシュ管理に関して、いくつかの教訓を 蓄積 してきました。
- プロンプトキャッシュのヒット率を注意深く監視してください。Claude Console と キャッシュ診断 API は、プロンプトキャッシュの診断情報を提供します。これには、キャッシュミスの理由 (図 1) や、2 つのリクエストが正確にどこで分岐したかが含まれます。
- 使用頻度の低いツールは遅延読み込みにしてください。すべてのツールを事前に宣言しますが、使用頻度の低いツールには defer_loading をマークします。これらはキャッシュされたプレフィックスの外側に留まり、Claude がツール検索でそれらを検索した場合にのみ会話に追加されるため、キャッシュが保持されます。
- システムプロンプトの更新はメッセージとして適用してください。特定の Claude モデル では、システムプロンプトを編集する代わりに、会話の途中でシステム指示をメッセージとして追加でき、キャッシュが保持されます。
- 安定した部分が安定したままになるようにリクエストを構成してください。まず静的なコンテキスト（ツール定義とシステムプロンプト）を追加し、その後に成長する会話を追加します (図 2)。
- プロンプトキャッシュが既に壊れるタイミングで、モデルや努力の変更を行ってください。コンパクション などの特定の操作は、キャッシュの大部分（会話）を既に書き換えます。これは モデルや努力を切り替える良いタイミング です。なぜなら、ミスに対して支払いが発生するからです。
- 会話が進むにつれて、キャッシュブレークポイントを移動してください。Claude Platform では、自動キャッシング を設定して、キャッシュブレークポイントを最後のキャッシュ可能なブロックに適用できます。
- キャッシュを事前にウォームアップしてください。レイテンシを削減するために、実際のトラフィックと同じ努力設定を使用して、max_tokens: 0 と明示的なキャッシュブレークポイントを指定したリクエストを送信します。これにより、何も生成せずにプロンプトが処理され、キャッシュに書き込まれます。セッション開始時（ユーザーが入力している間など）に実行すると、最初の実際のリクエストはウォームキャッシュにヒットします。
- プロンプトキャッシュの TTL を超えないようにしてください。5 分間のキャッシュ TTL は、リクエストの開始時からカウントされます。エージェントが 5 分以上実行されるツール呼び出しやサブエージェントリクエストでブロックされている場合、結果が返ってくる前に親のキャッシュが期限切れになります。このような場合は、プレフィックスに 1 時間の TTL を設定する ことを検討してください。
指示
プロンプトには、モデルの弱点を補うための指示が蓄積される可能性があります。これらの指示は、最新の Claude モデル の機能と比較してずれる可能性があります。以下は、最先端の Claude モデルを妨げ、結果的にコストを増加させる可能性のある、一般的なプロンプトの「アンチパターン」です。
- 検証儀式。「作業を再確認してください」や「応答する前に 2 回確認してください」などの指示は、最先端のモデルによって文字通りに受け取られることが多く、トークンを浪費する可能性があります。
- 徹底性と強調のブースター。「最大限に徹底してください」、「重要: 必ず…」などは、最先端のモデルで作業する場合、冗長性や余分なツール呼び出しにつながる可能性があります。
- 必須手順とスクラッチパッドの枠組み。固定ステップのプロセス（例：「スクラッチパッドで段階的に考えてください」）や推論テンプレートは、最先端のモデルには不要な儀式です。このような枠組みは、ネイティブの推論の上に積み重なり、不要なトークンを使用する可能性があります。
- 古い例。古いモデルの失敗モードに合わせた少数ショットの例は、最先端のモデルに、必要のないリクエストに対して長い推論チェーンを模倣するように教える可能性があります。
- 矛盾するルール。最先端のモデルは指示に従うのがより得意です。矛盾する指示（「ポリシーに従って常に返金する」と「エスカレーションなしに返金を発行しない」）は、最先端のモデルによってより文字通りに従われ、パフォーマンスの低下につながる可能性があります。
- 古い設定。古い Claude 世代向けに書かれた設定（手動思考予算など）は、新しいモデルでは Claude Platform によって拒否される可能性があります。
修正方法
claude-api スキルを、これらのアンチパターンを監視する新しいコマンドで更新しました。Claude Code で、プロンプト、スキル、またはツールの説明に対して /claude-api prompt-audit を実行します。監査は、Claude API を呼び出すアプリケーションコードや Claude Code 自身の設定（例：CLAUDE.md やスキル）など、作業ディレクトリ内のすべてを対象とします。
例えば、カスタマーサポートベンチマークで、Opus 4.8 から Opus 5 へのモデル移行をテストしました。クリーンなプロンプトから始め、一度に 1 つのアンチパターン（廃止された思考設定、矛盾する返金ルールのペア、手動スクラッチパッド、「2 回確認」、「最大限に徹底」、必須の 6 ステップ手順）を仕込み、6 つのレガシープロンプトを作成しました。
各プロンプトを Opus 4.8、モデル ID のみを変更した Opus 5、そしてプロンプトごとに /claude-api prompt-audit を 1 回実行した後の Opus 5 で実行しました（図 3 は 6 つの平均を示しています）。
Opus 5 では、検証儀式（「2 回確認」）は、返金のたびに注文検索を複製することで不要なトークンを使用しました。強調ブースター（「最大限に徹底」）は、数十もの不要なナレッジベース検索になりました。
/claude-api prompt-audit を実行すると、アンチパターンが削除され、コストが平均 14.6% 削減され、精度が平均 5.3% 向上しました。コストが削減されたのは、余分なツール呼び出しと重複した推論が排除されたためです。精度が向上した理由は 3 つあります。廃止された思考設定により、API はすべてのルーティングリクエストを即座に拒否していました。矛盾する返金ルールにより、Opus 5 は顧客に確認を求める間、支払うべき 4 件の返金を保留しました。そして、手動スクラッチパッドが Opus 5 の組み込み思考と衝突し、3 つのチケットでは、ツール呼び出しを推論内に記述し、実行しませんでした。
努力
努力 は、Claude に「どの程度努力するか」を指示します。低い努力では、Claude は一般的に迅速に結論に達します。高い努力では、Claude は回答する前に熟考、検証、代替案の探索を行います。
単一モデル内の努力レベル間でのコスト対パフォーマンスは変動する可能性があります。例えば、Claude Fable 5 は、FrontierCode Diamond（最も難しい 50 タスク）において、低い努力でタスクあたり $5.35 で 11.5% のスコアを獲得します。最大努力では、Fable 5 はタスクあたり $19.00 で 30.9% を獲得します。努力を変更すると、スコアは約 2.7 倍（+19 ポイント）向上しますが、コストは約 3.5 倍になります（図 4）。
Claude Fable 5.1 では、Humanity's Last Exam（ツールなし）は、最後のステップで収穫が逓減する急峻な曲線を示しています。低い努力では質問あたり約 $0.30 で約 53%、最大努力では質問あたり約 $2.23 で約 61% のスコアです。最大への最後のステップでは、46% のコスト増加に対して約 0.5 ポイントの向上です。この利得はベンチマークの実行間ノイズの範囲内であるため、測定可能な利得なしにコストが増加します。
努力は、どちらの方向にも誤調整される可能性があります。
- 高い方が常に良いと想定する。高い努力は 考えすぎ を引き起こす可能性があります。Claude はタスクに必要な時間よりも長く熟考し、コストとレイテンシが増加し、回答品質が低下する可能性があります。熟考は、まだ発見すべき証拠がある場合にのみ役立ちます。
- 低い努力に偏る。低く設定しすぎると、Claude は十分な証拠が得られる前に停止します。ツール呼び出しが少なくなるため、3 番目の検索結果ではなく、最初の検索結果から回答する可能性があります。難しいステップでは考える量が減り、通常実行するチェックをスキップします。回答は完成しているように見えますが、部分的な情報に基づいています。
修正方法
努力を調整するための便利な方法がいくつかあります。
- より強力なモデルを低い努力でテストする。低い努力のより強力なモデルは、懸命に努力する（高い努力の）弱いモデルよりも安価になる可能性があります。例えば、CursorBench 3.2 では、低い努力の Claude Fable 5.1 は、高い努力の Fable 5 のパフォーマンスに 3 分の 1 のコストで匹敵します（図 5）。新しいモデルがより安価である理由は 2 つあります。低い努力ではタスクあたりの作業量が少なく、Fable 5.1 のプロンプトキャッシュ読み取り価格は 100 万トークンあたり $0.25 であるのに対し、Fable 5 は $1.00 です。Fable 5 の価格でも、低い努力の Fable 5.1 は約 40% 安くなります。
- タスクの形状を理解する。さまざまな努力レベルにわたって アプリケーションのパフォーマンスを測定することは、特定のタスクにおけるコストとパフォーマンスのトレードオフを理解するための有用な方法です。飽和していない評価では、努力レベル間でコストパフォーマンス曲線が平坦である場合、タスクが思考計算に制約されていないことを示唆しており、努力を増やしてもメリットはありません。
この調整には、多くの場合、モデルと努力レベルにわたる評価の実行が含まれます。Claude Code では、/claude-api hillclimb がこの検索を代行します。評価をトレーニングセットとテストセットに分割し、設定変更を提案し、失敗したトレーニング例を読み取って、見つけた問題を修正します。
カスタマーサポートベンチマークで、デフォルト（高）努力の Opus 4.8 から開始して実行しました。hillclimber は最初に、低い努力の Opus 5 を試し、prompt-audit を適用して、必須のツール呼び出し儀式、スクラッチパッドステップ、矛盾するルールを削除しました。これにより、98.9% のトレーニング精度で Opus 4.8 のベースラインをクリアし、コストをチケットあたり 2.6 セントに削減しました（図 6）。
次に、低い努力の Sonnet 5 にステップダウンしました。これはチケットあたり 1 セントとさらに安価でしたが、精度は 88.9% に低下しました。失敗したトレーニングチケットを読み取り、Claude はルーティングルールと返金上限の相互参照をプロンプトに追加し、Sonnet 5 を同じコストで 98.9% に戻しました。
検索が一度も見たことのない 14 の保留チケットでは、最終的な設定は元の設定の 78.6% に対して 90.5% のスコアを記録し、コストは約 5 分の 1 でした。
コスト削減の自動化
プロンプトキャッシュ、指示、努力は、コスト削減のための一般的なレバーです。当社のドキュメントでは、さらに多くの方法を紹介しています。Claude API を使用するアプリケーションコードの全体的なコスト監査を実行するために、/claude-api cost-optimize を追加しました。これは、支出の内訳をプロファイリングし、コスト削減を適用し、評価を提供する場合は、節約とパフォーマンスのトレードオフを示します。
cost-optimize は、トークンの使途を特定することから始まります。Claude Admin API キーを持っている場合は組織の使用量とコストレポートから、アプリケーションがログに記録している場合は各 API 応答の usage オブジェクトから、またはその両方が不可能な場合はリクエスト構築コードを読み取って推定します。
次に、利用可能な節約方法をランク付けします。プロンプトキャッシュの最適化から始め、各リクエストが運ぶもののトリミング（prompt-audit を含む）、出力の制限、および無人作業のバッチ処理を行います。評価を提供する場合は、さらに進んで、努力レベルとモデル選択全体のコストとパフォーマンスを計算します。これを Sonnet 5 をベースラインとして 4 つの公開ベンチマークで実行しました（図 7）。
- LegalBench（コスト約 58% 削減）: cost-optimize は、タスク間で共有プレフィックスをキャッシュし、低い努力を設定し、Batch API を介してタスクを処理することを提案しました。思考トークンは 102,779 から 8,284 に減少し、合格率はノイズの範囲内に留まり、コストは約 58% 削減されました。
- tau2-bench retail（コスト約 73% 削減）: 明示的なブレークポイント配置によるプロンプトキャッシュを実装することで、cost-optimize は合格率を横ばいに保ちながら支出を 72% 削減しました。
- OfficeQA Pro（コスト約 52% 削減）: cost-optimize はバッチ処理とドキュメントキャッシュを追加し、コストを $136.20 から $64.87 に削減しました。
- SWE-bench Verified（コスト約 55% 削減）: cost-optimize は、デフォルト設定が既に正しくキャッシュしていることを発見しました。節約は、努力を中程度に設定し、エージェントの出力を簡潔な数文に制限することから得られました。タスクあたりの中央ステップ数は 29 から 17 に減少し、プロンプトトークンは 75.2M から 33.7M に減少しました。
はじめに
最先端の Claude モデルに移行し、既存のプロンプトを確認したい場合は、/claude-api prompt-audit から始めてください。これは、作業ディレクトリ内のプロンプト、スキル、ツールの説明をスキャンします。これは、Claude API を呼び出すアプリケーションコードや Claude Code の設定（CLAUDE.md、スキル）である可能性があります。最先端のモデルを妨げる一般的なアンチパターンを削除します。
アプリケーションが Claude API を使用しており、コスト監査が必要な場合は、/claude-api cost-optimize を使用してください。これは、トークン支出をプロファイリングし、次にさまざまなレバーをテストします。prompt-audit を適用するだけでなく、プロンプトキャッシュ、無人作業のバッチ処理、または出力の制限によるコスト削減方法もチェックします。評価を提供する場合は、努力とモデル選択のトレードオフを測定します。
最後に、コストとパフォーマンスの検索には /claude-api hillclimb を使用してください。評価が与えられると、Claude はそれをトレーニングセットとテストセットに分割し、ベースラインパフォーマンスを維持しながらコスト削減を目指すアプリケーションの更新を提案します。Claude は失敗したトレーニングケースを読み取って検索をガイドし、最終的な設定は保留されたテストセットでスコアリングされます。
詳細については、以下を参照してください。
執筆者: Lance Martin (@RLanceMartin)、Brad Abrams (@brada)、Isabella He (@IsabellaKHe)、Ben Lehrburger (@benlehrburger)。
