AIへの「念のためプロンプト」はもう逆効果 Claudeのトークンを浪費する6つのアンチパターン：コストを最大73％削減する手法とは

Anthropicは、Claude Platformでコスト削減と精度向上を両立する3つの手法を公開した。

[＠IT]

　Anthropicは2026年9月8日（米国時間）、「Claude Platform」でコストを削減しながら、アプリケーションのパフォーマンスを維持、向上させる方法を紹介するブログ記事を公開した。

　コストとパフォーマンスはトレードオフと考えられがちだが、Anthropicは、多くのアプリケーションでは次の3つの対策によって、コスト削減とパフォーマンスの維持、向上を両立できるとしている。

1. Claudeのフロンティア（最先端）モデルへの移行時にプロンプトからアンチパターンを排除する
2. プロンプトキャッシュのヒット率を最大化する
3. タスクに応じてエフォート（effort）（※）を調整する

※Claudeがリクエストに応答する際に費やすトークン数を制御し、応答の徹底度とトークン効率のバランスを調整するパラメーター。

　Anthropicはこれらのガイダンスをブログ記事で解説している他、「Claude Code」の「claude-api」スキルにまとめて公開している。

【1】プロンプトにおけるアンチパターンを排除する

　プロンプトには、古いモデルの弱点を補う指示が蓄積しがちだ。だが、フロンティアモデルに対しては、こうした指示は余計な干渉になり、トークンの浪費などによってコストを押し上げる可能性がある。Anthropicはこの種の一般的なアンチパターンとして、以下の6つを挙げている。

1. 重複的な検証の強制（「作業を再確認せよ」「応答する前に2回検証せよ」など）
2. 強調表現（「最大限に徹底せよ」「重要：常に〜しなければならない」など）
3. 固定された手順や思考テンプレートの指定（「スクラッチパッドを用いて段階的に思考せよ」）など）
4. 古いモデルの失敗モードに合わせて調整されたFew-Shot例（指示に追加する少量の具体例）
5. 矛盾したルール
6. 従来世代のClaude向けに記述された設定（手動の思考予算など）

　Claude Codeの新しい監査コマンド「/claude-api prompt-audit」を使えば、作業ディレクトリ内のプロンプト、スキル、ツール説明をスキャンし、これらのアンチパターンを除去できる。Claude APIを呼び出すアプリケーションコードや、Claude Code自体の設定（CLAUDE.md、スキルなど）も、このコマンドの対象となる。

　Anthropicは、Opus 4.8からOpus 5への移行を想定したカスタマーサポートのベンチマークでこの監査コマンドをテストした。アンチパターンを1つずつ仕込んだ6種類の旧式プロンプトを用意し、それぞれをOpus 4.8、モデルIDのみを変更したOpus 5、「/claude-api prompt-audit」を実行した後のOpus 5で実行した。その結果、監査によってコストは平均14.6％減少し、精度は平均5.3％向上した。

Opus 4.8からOpus 5への移行時におけるプロンプトのアンチパターンの影響（提供：Anthropic）

【2】プロンプトキャッシュを有効活用する

　Claudeは応答を生成する前に、プロンプトを内部の作業状態に変換する。「プレフィル」（prefill）処理が、入力にかかるコストの大部分を占める。プロンプトキャッシングはこの状態（Key-Valueキャッシュ）を保存し、同じプレフィックスで始まるリクエストでは、再計算する代わりにそれを読み出す。キャッシュの読み取りにかかるコストは、入力コストのごく一部だ。

　ただし、プロンプトキャッシュはモデルごとに固定されており、プレフィックス全体がバイト単位で完全に一致する必要があり、有効期間（TTL：Time To Live）も限られている。キャッシュが無効になる主な原因には、以下のようなものがある。

• 会話の途中でのエフォートや思考設定の変更（これらの設定は、キャッシュされるプレフィックスに含まれるが、「Claude Opus 5」「Claude Fable 5.1」では、キャッシュを壊さずにエフォートを変更できる）
• システムプロンプトへの変動する値（タイムスタンプなど）の記載
• ツール定義の変更や順序の入れ替わり
• プレフィックス、モデル、エフォートのいずれかが親と異なるサブエージェントへの分岐
• TTLを超えて実行される同期的なツール呼び出しやサブエージェント（通常の1.25倍の入力コストでキャッシュの書き直しが必要になる）

　Anthropicは、「『Claude Console』でキャッシュの診断情報を監視すること」「めったに使わないツールに『defer_loading』を指定してキャッシュ対象のプレフィックスから外すこと」「会話の途中で追加するシステム指示は、システムプロンプトを編集するのではなく、メッセージとして追加すること」を推奨している。

　また、「リクエストを構成する際に静的なコンテンツを先頭に置き、増えていく会話をその後ろに配置すること」も勧めている。「モデルやエフォートの変更は、コンパクション（compaction）（※）の実行時のように、キャッシュが書き直されるタイミングで行うのが望ましい」とも述べている。

※コンテキストウィンドウの上限に近づいたときに古いコンテキストを自動的に要約すること

　「『max_tokens: 0』を指定したリクエストを送れば、キャッシュを事前にウォームアップできる。長時間のツール呼び出しでブロックされるエージェントには、1時間のTTLが適している」（Anthropic）

【3】タスクに合わせてエフォートを調整する

　エフォートは、Claudeに「どれだけの労力で取り組むか」を指示する設定だ。「低」エフォートではより迅速に結論に到達し、「高」エフォートでは回答の前に熟考、検証し、代替案を検討する。コストとパフォーマンスの関係はタスクによって異なる。

　「FrontierCode Diamond」（最も難易度の高い50のタスク）では、Claude Fable 5のスコアは「最大」エフォートで、低エフォートの約2.7倍の（19.4ポイント高い）30.9％となったが、コストは約3.5倍のタスク当たり19.00ドルかかった。

　一方、「Humanity's Last Exam」（ツール不使用）では、Fable 5.1の最大エフォートでのコストは、「超高」エフォートと比べて46％跳ね上がるが、スコアの伸びは0.5ポイントに過ぎない。この伸びは、ベンチマークの実行ごとのばらつきの範囲内にある。

　エフォートの調整は、レベルの高低どちらの方向にも誤り得る。エフォートレベルが高過ぎると、考え過ぎが生じてコストと遅延が増え、低過ぎると、十分な証拠や根拠を集める前にClaudeが処理を停止してしまう。

　Anthropicは、エフォートの有効な調整方法の一つとして、より強力なモデルを低いエフォートで試すことを提案している。例えば、「CursorBench 3.2」では、低エフォートのFable 5.1が高エフォートのFable 5と同等のパフォーマンスを3分の1のコストで達成している。これは低エフォートでのタスク当たり処理量が少ないことに加え、プロンプトキャッシュ読み取り単価が高エフォートのFable 5（1.00ドル/100万トークン）に対し、低エフォートのFable 5.1では0.25ドルにとどまるからだ。

CursorBench 3.2におけるエフォートレベル別のFable 5とFable 5.1の比較（提供：Anthropic）

　Anthropicは、エフォートレベルを段階的に変えて、アプリケーションのパフォーマンスを測定することも、特定のタスクにおけるコストとパフォーマンスのトレードオフを理解する上で役立つと述べている。

　エフォートレベルを上げても、パフォーマンスが横ばいなら、そのタスクは思考計算によって制限されていないことを示唆しており、エフォートレベルを高めるメリットはないことになる。

　こうしてエフォートを調整するには、多くの場合、モデルとエフォートレベルをまたいだ評価が必要になる。Anthropicは、Claude Codeで「/claude-api hillclimb」コマンドを使って、この探索を自動的に行えるようにした。このコマンドは、評価をトレーニングセットとテストセットに分割し、設定変更を提案し、失敗したトレーニング例を読み込んで問題点を修正する。

　Anthropicはカスタマーサポートのベンチマークでこのコマンドをテストした。デフォルト（既定）の高エフォートで動作するOpus 4.8から出発し、監査コマンドの/claude-api prompt-auditを適用した低エフォートのOpus 5に移行することで、トレーニングデータで98.9%の正答率を1チケット当たり2.6セントで達成した。

　続いて、低エフォートの「Sonnet 5」を試したところ、コストは1チケット当たり1セントに下がったが、正答率は88.9％に低下した。ルーティングルールの追加などによってプロンプトを改善すると、同じコストで正答率は98.9％に回復した。

　この最終的な構成では、探索の過程で一度も遭遇しなかった14件のテスト用チケットにおいて、正答率は90.5％に達し、元の構成での78.6％を上回り、コストは約5分の1だった。

「/claude-api hillclimb」を使った反復的探索を通じて、モデルの選択、エフォートレベル、プロンプトの更新によってコストとパフォーマンスが改善（提供：Anthropic）

コスト削減を自動化する

　Anthropicは、包括的なコスト監査のために「/claude-api cost-optimize」コマンドを導入した。

　このコマンドはまず、利用状況とコストのレポートや、各APIレスポンスの「usage」オブジェクト、リクエストを組み立てるコードから、トークンの消費傾向をプロファイリングする。

　その上で、プロンプトキャッシング、各リクエストの内容の削減、出力の制限、無人で実行できる処理のバッチ化の順に、コスト削減策をランク付けする。評価条件を指定すれば、エフォートレベルやモデル選択に応じてコストとパフォーマンスを算出する。

　Sonnet 5をベースラインとして4つの公開ベンチマークでこのコマンドをテストした結果は、以下の通り。

1. tau2-bench retail：明示的なブレークポイントを置いたプロンプトキャッシングにより、合格率を維持したままコストが約73％減少
2. LegalBench：共通プレフィックスのキャッシュ、低エフォート、Batch APIの利用により、合格率は誤差の範囲内のまま、コストが約58％減少
3. OfficeQA Pro：バッチ処理とドキュメントのキャッシュにより、コストが約52％減少
4. SWE-bench Verified：「中」エフォートと簡潔な出力により、コストが約55％減少

「/claude-api cost-optimize」による各ベンチマークでのコストとパフォーマンスの変化（Anthropic）