Anthropic、Claude Platform のコスト削減と性能向上手法を公開

パフォーマンスとコストは、しばしばトレードオフの関係にあると考えられています。つまり、コストを削減すれば結果の質が下がるという考え方です。しかし実際には、Claude Platform を利用する多くのアプリケーションで、以下の 3 つの対策を講じることで、性能を損なうことなくコストを大幅に削減できることが分かっています。

1. プロンプトキャッシュのヒット率を最大化する
2. フロンティアモデル（最新モデル）へのアップグレード時に、プロンプトからアンチパターンを取り除く
3. タスクに応じて適切な処理量を調整する

これらの知見は、`claude-api `skill に実装されています。本記事では、このスキルを活用した Claude Code が、性能を維持または向上させながらコスト削減を実現できる具体的な方法について解説します。

プロンプトキャッシュ（Prompt cache）

Claude が応答を生成する前には、まず入力されたプロンプトを内部の作業状態に変換する必要があります。このプロセスは「プリフィル（prefill）」と呼ばれ、入力を処理する中で最もコストがかかる部分です。

プロンプトキャッシュはこの状態（キー・バリューペア、すなわち KV キャッシュ）を保存します。リクエストが同じプレフィックスから始まる場合、Claude は再計算せず、保存された状態を読み取って応答を生成します。キャッシュからの読み取りは、通常の入力価格のわずかな fraction で課金されます。

プロンプトキャッシュを効果的に活用するためには、いくつかの実践的な留意点があります。まず、キャッシュは特定のモデルに紐付けられることです。次に、プロンプトのプレフィックス部分において、キャッシュ読み取りはバイト単位で完全に一致している必要があります。最後に、プロンプトキャッシュには有効期限（TTL: Time To Live）が設定されており、一定期間 しか保持されません。

これらのポイントを踏まえて、いくつかの実践的なヒントをご紹介します。

• 会話中に努力設定を変更する際は注意が必要です。 これらの設定はコンテンツよりも前にプロンプトに組み込まれるため、キャッシュされるプレフィックスの一部となります。Opus 5 や Fable 5.1 など一部の Claude モデルを除き、キャッシュを破綻させることなく会話中に effort を更新 することはできません。

• 動的な値はプレフィックスから除外してください。 システムプロンプトに動的なタイムスタンプや ID が含まれていると、モデル呼び出しごとに値が変化し、キャッシュが破綻する原因となります。

• 順序が変わるツール定義を避けてください。 Claude Messages API を使用する場合、プロンプトは固定された順序で組み立てられ、ツール定義が先頭にレンダリングされます。ツール定義に任何変更を加えるとキャッシュが破綻します。

• 会話のフォーク（分岐）を行う際は注意が必要です。 サブエージェントや分岐は、フォーク側のプレフィックスがバイト単位で同一であり、同じモデル・同じ努力設定を使用している場合にのみ、親のキャッシュを共有できます。

解決策について

プロンプトキャッシュ管理については、いくつかの教訓 を蓄積しています。

プロンプトキャッシュのヒット率を注意深く監視してください。

Claude Console や キャッシュ診断 API を利用すれば、プロンプトキャッシュの診断が可能です。これらには、プロンプトキャッシュがヒットしなかった理由（図 1）や、2 つのリクエストがどこで分岐したかを特定する機能が含まれています。

図 1. Claude Console は、連続するリクエストを比較し、プロンプトプレフィックスがどこで分岐したかを特定することで、予期せぬプロンプトキャッシュのミスを診断できます。

「あまり使わないツールは遅延ロードする」すべてのツールを事前に宣言し、使用頻度の低いツールには defer_loading を設定します。これにより、キャッシュされるプレフィックスから除外され、Claude がツール検索で呼び出すまで会話に追加されないため、キャッシュを維持できます。

「システムプロンプトの更新はメッセージとして行う」Claude Platform を使えば、会話中にシステム指示をメッセージとして追加でき、プロンプトそのものを編集する必要がなくなるためキャッシュを維持できます。

「リクエストの構成は、安定した部分を固定する」静的なコンテキスト（ツールの定義やシステムプロンプト）を先に配置し、その後に増え続ける会話を続けます（図 2）。

図 2. ダイナミックなコンテンツは、安定したプレフィックスの末尾に追加されるようにプロンプトを整理する。

「モデルやコスト設定の変更は、キャッシュがすでに無効になるタイミングで行う」compaction などの特定の操作では、会話部分を含むキャッシュの大部分が書き換えられます。この時点でモデルやコスト設定を変更すれば、キャッシュミスが発生しているため追加コストは発生しません。つまり、キャッシュがすでに破綻しているタイミングこそが変更を加える好機です。

会話の進展に合わせてキャッシュのブレイクポイントも移動させる。Claude Platform では、自動キャッシング を設定することで、キャッシュ可能な最後のブロックに自動的にブレイクポイントを適用できます。

キャッシュを事前に温めておく（プリウォーム）ことも有効です。遅延を減らすため、max_tokens: 0 と明示的なキャッシュブレイクポイントを含むリクエストを送信します。これによりプロンプトが処理されキャッシュに書き込まれますが、実際の生成は行われません。セッション開始時（例えばユーザーが入力している最中）にこの処理を実行しておけば、最初の実際のリクエストで温められたキャッシュを即座に利用できます。

プロンプトキャッシュの TTL（有効期限）を超えないように注意してください。5 分の TTL はリクエスト開始時点からカウントされます。もしエージェントがツール呼び出しやサブエージェントのリクエストによって 5 分以上ブロックされている場合、親プロセスのキャッシュは結果が返ってくる前に期限切れになります。このようなケースでは、プレフィックスに対して 1 時間の TTL を設定する ことを検討してください。

指示

プロンプトにはモデルの弱点を補うための指示が蓄積されがちです。これらの指示は、最新の Claude モデル の能力との間にズレが生じることがあります。以下に、最先端の Claude モデルのパフォーマンスを阻害し、結果として意図せずコストを増加させる一般的なプロンプティングの「アンチパターン」を紹介します。

• 検証儀式。"作業を二重確認する" や "回答する前に二度確認する" といった指示は、最先端モデルが文字通りに解釈して実行してしまうことが多く、トークンの無駄遣いにつながります。

「徹底性」や「強調」を過度に求めるプロンプトは、例えば「最大限の詳しさを心がける」「重要：必ず…してください」といった指示ですが、最先端モデルでは冗長な出力や過剰なツール呼び出しを招く原因となります。

必須手順やスクラッチパッド（思考メモ）の構造化も注意が必要です。「スクラッチパッドで段階的に思考する」などの固定されたステッププロセスや推論テンプレートは、最先端モデルには不要な儀式です。これらは既存の推論機能に重ねられ、無駄なトークンを消費します。

時代遅れの例示（Few-shot examples）も問題です。古いモデルの弱点に合わせて調整された例を提示すると、最先端モデルが不要な長い推論連鎖を模倣してしまう恐れがあります。

矛盾するルールも避けるべきです。最先端モデルは指示に従う能力に優れていますが、「ポリシー内で常に返金する」対「エスカレーションなしでは絶対に返金しない」といった矛盾した指示を与えると、モデルが文字通り解釈して性能が低下します。

設定の陳腐化にも注意が必要です。古い Claude 世代向けに書かれた設定（例：手動での思考予算の設定）は、最先端モデルへのアップグレード時に Claude Platform から拒否される可能性があります。

解決策

これらのアンチパターンを検出する新しいコマンドを claude-api スキルに追加しました。Claude Code では、/claude-api prompt-audit コマンドを実行して、プロンプトやスキル、ツール記述を確認できます。この監査は作業ディレクトリ内のすべての対象（Claude API を呼び出すアプリケーションコードや、Claude Code 自身の設定ファイルである CLAUDE.md やスキルなど）を網羅します。

例えば、カスタマーサポートのベンチマークにおいて、Opus 4.8 から Opus 5 へのモデル移行をテストしました。クリーンなプロンプトから始め、一度に一つのアンチパターン（廃止された思考設定、矛盾する返金ルール、手動のスクラッチパッド、「2 回検証」「最大限徹底する」、必須の 6 ステップ手順）を組み込み、計 6 つのレガシープロンプトを作成しました。

これらをそれぞれ Opus 4.8 で実行し、次にモデル ID のみを変更した Opus 5 で実行。さらに各プロンプトに対して /claude-api prompt-audit を一度実行した後の Opus 5 でもテストしました（Figure 3 はこれら 6 つの平均値を示しています）。

Figure 3 | The effect of prompting anti-patterns during model migration from Opus 4.8 to Opus 5.

Opus 5 では、検証の儀式（"*verify twice*"）が返金ごとに注文照会を二重に行うことでトークンを無駄に消費します。また、「*be maximally thorough*」のような強調指示は、不要な知識ベース検索を数十回も引き起こすようになりました。

「/claude-api」プロンプト監査を実行してアンチパターンを排除した結果、コストは平均で14.6%削減され、精度は5.3%向上しました。コストが下がったのは、不要なツール呼び出しや推論の重複が解消されたためです。一方、精度が向上した背景には三つの要因があります。

第一に、「思考（thinking）」機能を無効化することで、API がルーティングリクエストを即座に拒否するようになりました。第二に、矛盾する返金ルールにより、Opus 5 は顧客の確認を待つ間に本来支払うべき4件の返金を保留してしまいました。第三に、手動のスクラッチパッドが Opus 5 の内蔵思考機能と競合し、3件のチケットでツール呼び出しを推論内に記述したまま実行されなかったことが挙げられます。

Effort

Effort は Claude に対して「どれほど努力して作業するか」を指示するパラメータです。低設定では Claude は一般的に素早く結論に至ります。一方、高設定では回答前に検討、検証、および代替案の探索を行います。

単一のモデルにおいて、Effort のレベルによるコストとパフォーマンスの関係は変動します。例えば、最も困難な50件のタスクを対象とした FrontierCode Diamond において、Claude Fable 5 は低 Effort で11.5%のスコアを記録し、1件あたりのコストは5.35ドルでした。一方、最大 Effort ではスコアが30.9%に上昇し、1件あたり19.00ドルとなりました。Effort を変更することで、スコアは約2.7倍（+19ポイント）向上しますが、そのためにはコストを約3.5倍にする必要があります（図4参照）。

Claude Fable 5.1 の Humanit y's Last Exam（ツールなし）では、コストと性能の関係は明確な曲線を描きます。低コストで約 0.3 ドル/問あたりの試行では正答率が約 53% ですが、最大限のリソースを投入しても正答率は約 61% にしか達しません。最後のステップで最大リソースに切り替えることで得られるのはわずか半ポイントの向上であり、コストは 46% も増加します。この性能差はベンチマーク自体のランダムなばらつき（ノイズ）の範囲内にあるため、追加のコストに見合う明確な効果は得られません。

リソースの投入量（Effort）は、過不足なく調整する必要があります。方向を誤ると以下の問題が発生します。

• 常に「高リソース」が最善だと考える：必要以上に多くの思考時間を費やす「過剰思考」に陥ります。タスクに必要な時間を超えて検討を続けるため、コストと応答遅延が増大し、回答の質が低下する恐れがあります。証拠が見つかる限りは検討が有効ですが、それ以上は逆効果です。

• 低リソース側に偏る：投入量が不足すると、Claude は十分な証拠を集める前に判断を停止してしまいます。ツール呼び出し回数が減り、最初の検索結果だけで回答してしまう可能性があります。困難なステップでは思考が浅くなり、通常行うべき自己検証を省略します。一見完成したように見える回答も、実は不完全な情報に基づいて構築されたものになります。

改善策

リソース投入量を適切に調整するための有効な方法はいくつかあります：

低コストで強力なモデルを試す。低負荷（Low Effort）で動作する強力なモデルは、高負荷（High Effort）で動作する weaker モデルよりも安価になる可能性があります。例えば CursorBench 3.2 の結果では、Claude Fable 5.1 を低負荷で実行した方が、Fable 5 を高負荷で実行した場合と同等の性能を達成しながら、コストは約 3 分の 1 で済みます（図 5）。このコスト削減には二つの要因があります。まず、低負荷ではタスクあたりの処理量が減る点です。次に、Fable 5.1 のプロンプトキャッシュ読み取り料金がトークン百万あたり $0.25 と設定されているのに対し、Fable 5 は $1.00 です。仮に Fable 5 の料金体系のままでも、Fable 5.1 を低負荷で使う方が約 40% 安くなります。

タスクの特性を理解する。アプリケーションのパフォーマンスを さまざまな負荷レベル で測定することは、特定のタスクにおけるコストと性能のトレードオフを理解するための有効な手段です。評価対象が飽和していない場合、負荷レベルを変えてもコスト対性能の曲線が平坦であれば、そのタスクは思考計算（thinking compute）によって制約されていないことを意味します。つまり、負荷を増やしても有益な効果は得られません。

この最適化プロセスでは、通常、複数のモデルと設定レベルを跨いで評価を実行します。Claude Code の /claude-api コマンドにある hillclimb 機能は、この検索作業を自動化してくれます。具体的には、評価データを学習用セットとテスト用セットに分割し、構成の変更案を提案するとともに、失敗した学習例を読み込んで問題点を特定・修正します。

私たちは顧客サポートのベンチマークでこの手法を試しました。デフォルト（高レベル）の設定を持つ Opus 4.8 からスタートします。hillclimber はまず低設定の Opus 5 を試し、プロンプト監査機能を使って必須のツール呼び出しの手順やスクラッチパッドステップ、矛盾するルールを削除しました。その結果、学習データの精度は 98.9% に達し、チケットあたりのコストは 2.6 セントに削減できました。

*図 6. モデルの選択、設定レベル、プロンプトを更新することで、コストとパフォーマンスを同時に向上させることが可能です。

次に、さらに安価な低設定の Sonnet 5 に切り替えました。チケットあたりのコストは 1 セントまで下がりましたが、精度は 88.9% に低下しました。そこで失敗した学習データ（チケット）を読み込み、プロンプトにルーティングルールと返金上限の照合機能を追加。その結果、Sonnet 5 の精度も再び 98.9% に回復し、コストは同じ水準を維持できました。

検索プロセスで一度も見たことのない 14 枚のテスト用チケットでは、最終的な構成が 90.5% のスコアを記録しました。これは元の設定の 78.6% を上回る結果であり、コストは約 5 分の 1に抑えられています。

コスト削減の自動化

コスト削減には、プロンプトキャッシングや指示の最適化、そして作業負荷の調整といった一般的な手法があります。当社のドキュメントではさらに多くの詳細を解説しています。

Claude API を利用するアプリケーションコードの包括的なコスト監査を行うため、私たちは /claude-api cost-optimize という機能を追加しました。このツールは支出の内訳をプロファイリングし、具体的な削減施策を適用します。また、評価指標を提供いただければ、パフォーマンスとのトレードオフを含めた節約効果を可視化することも可能です。

cost-optimize はまず、トークンがどこで消費されているかを特定することから始めます。Claude Admin API キーをお持ちの場合は組織の利用状況とコストレポートを参照し、アプリケーション側で各 API 応答に含まれる使用量オブジェクトをログに記録している場合はそこから取得します。これら両方が該当しない場合でも、リクエスト構築コードを読み込んで推計を行うことで対応可能です。

次に、利用可能な削減施策を優先順位付けします。まずはプロンプトキャッシングから始め、各リクエストが運ぶデータ（プロンプト監査を含む）の削減、出力サイズの制限、そして無人処理におけるバッチ処理の実施などを行います。評価指標を提供いただければ、さらに踏み込んで、作業負荷やモデル選択に応じたコストとパフォーマンスを計算します。

私たちはこのツールを実際に 4 つの公開ベンチマークで検証しました。まずは Sonnet 5 をベースラインとして使用し（図 7）、その結果を確認しています。

• LegalBench（コスト約58%削減）: タスク間で共有プレフィックスをキャッシュし、努力レベルを低く設定、Batch APIで処理することでコスト最適化を行いました。思考トークンは102,779から8,284に激減しましたが、正答率はノイズの範囲内で維持され、コストは約58%削減されました。

• tau2-bench retail（コスト約73%削減）: 明示的なブレイクポイント配置によるプロンプトキャッシュを実装した結果、正答率を横ばいに保ちながら支出を73%削減できました。

• OfficeQA Pro（コスト約52%削減）: バッチ処理とドキュメントキャッシュを追加したことで、コストは136.20ドルから64.87ドルに引き下げられました。

• SWE-bench Verified（コスト約55%削減）: デフォルト設定ですでに正しくキャッシュされていることが確認されました。節約の要因は、努力レベルを「medium」に設定し、エージェントの出力を数文の簡潔な文章に制限した点にあります。タスクあたりの中央値ステップ数は29から17へ、プロンプトトークンは75.2Mから33.7Mへと減少しました。

図7. /claude-api cost-optimize適用後のベンチマーク全体におけるコストとパフォーマンスの変化

はじめに

最先端の Claude モデルへ移行し、既存のプロンプトを確認したい場合は、/claude-api prompt-audit コマンドから始めましょう。このコマンドは作業ディレクトリ内のプロンプト、スキル、ツール説明をスキャンします。対象となるのは Claude API を呼び出すアプリケーションコードや、Claude Code の設定（CLAUDE.md やスキル定義）です。これにより、最先端モデルの性能を阻害する一般的なアンチパターンを排除できます。

Claude API を利用しているアプリケーションでコストの見直しをしたい場合は、/claude-api cost-optimize コマンドを使用してください。このコマンドはトークンの使用状況をプロファイルした上で、コスト削減のためのさまざまな手段を検証します。具体的には prompt-audit の実行に加え、プロンプトキャッシングの活用や、無人作業のバッチ処理、出力サイズの制限などによるコスト削減の可能性をチェックします。評価指標（evaluation）を提供すれば、その取り組みとモデル選択におけるトレードオフを測定することも可能です。

最後に、コストとパフォーマンスのバランスを反復的に最適化したい場合は /claude-api hillclimb を使いましょう。評価指標が与えられると、Claude はそれを学習用セットとテスト用セットに分割し、ベースラインのパフォーマンスを維持しつつコストを削減できるようなアプリケーションへの更新案を提案します。Claude は失敗した学習ケースを読み込んで検索を誘導し、最終的な設定は保持されたテストセット上でスコアリングされます。

詳細については以下をご参照ください：

• 公式ドキュメント：こちら
• クックブック：こちら