「念のため」プロンプトがClaudeを劣化させる——Anthropicが明かした6つのアンチパターンとコスト最大73%削減の具体策
AIをちゃんと使い込んでいる現場ほど、見えにくいコストが積み上がっている。
Anthropicが2026年9月に公開したブログ記事とClaude Codeのスキルは、その「見えにくいコスト」に正面から切り込んだ内容だった。テーマは「コスト削減とパフォーマンス維持の両立」。3つの手法が提示されているが、最も実務的な示唆が大きいのは最初の一手——プロンプトに蓄積されたアンチパターンの排除だ。
「念のため指示」が積み重なると何が起きるか
プロンプトが育っていく様子を想像してほしい。最初はシンプルな指示で始まる。しかし運用が進むにつれて、「ちゃんと確認させたい」という意図から「作業を再確認せよ」という一文が加わる。出力がぶれるたびに「重要：常に〜しなければならない」という強調表現が増える。思考の深さを担保しようと「スクラッチパッドを用いて段階的に思考せよ」という手順が固定される。
これは、旧モデルの弱点を補うための調整が積み重なった結果だ。そして問題は、フロンティアモデルに対してこうした指示が「余計な干渉」になるという点にある。
Anthropicが挙げた6つのアンチパターンは以下の通りだ。
- 重複的な検証の強制（「応答する前に2回検証せよ」など）
- 強調表現（「最大限に徹底せよ」「重要：常に〜」など）
- 固定された手順や思考テンプレートの指定（「スクラッチパッドを用いて段階的に思考せよ」など）
- 古いモデルの失敗モードに合わせたFew-Shot例
- 矛盾したルール
- 従来世代のClaude向けの設定（手動の思考予算など）
どれも「そりゃそうだ」と思いながら、ついやってしまうものばかりだ。特に3番と4番は、過去の失敗対策として意図的に入れたものほど残りやすい。「前に精度が落ちたときに追加した指示」は、精度が改善された後も生き続ける。
Anthropicが提示した3つの対策の全体像
対策は構造的に整理されている。
① プロンプトのアンチパターンを排除する
Claude Codeに新しい監査コマンド「/claude-api prompt-audit」が追加された。作業ディレクトリ内のプロンプト、スキル、ツール説明をスキャンして上記のアンチパターンを検出・除去できる。Claude API呼び出しコードやCLAUDE.mdも対象になる。
② プロンプトキャッシュのヒット率を最大化する
Claudeはリクエストを受け取ると、まずプロンプトを内部の作業状態（Key-Valueキャッシュ）に変換する。この「プレフィル処理」が入力コストの大部分を占める。キャッシングはこの処理を省略できるが、いくつかの落とし穴がある。
- 会話の途中でのエフォートや思考設定の変更でキャッシュが無効化される
- システムプロンプトにタイムスタンプなどの可変値を入れるとキャッシュが崩れる
- ツール定義の変更や順序の入れ替わりも同様
Anthropicの推奨は「静的なコンテンツを先頭に、増えていく会話をその後ろに配置すること」。また、まれにしか使わないツールには「defer_loading」を指定してキャッシュ対象のプレフィックスから外すことも提案されている。
③ タスクに合わせてエフォートを調整する
エフォートとは、Claudeがリクエストに費やすトークン数を制御するパラメーターだ。「高」エフォートでは熟考・検証・代替案の検討が入り、「低」エフォートでは迅速に結論に至る。
数字で読む——どれだけコストが変わるか
抽象論ではなく、具体的な数字を見ておきたい。
プロンプト監査の効果
Opus 4.8からOpus 5への移行を想定したカスタマーサポートのベンチマークで、アンチパターンを1つずつ仕込んだ6種類の旧式プロンプトを比較した。監査コマンドを適用したOpus 5は、監査なしのOpus 5と比べてコストが平均14.6%減少し、精度は平均5.3%向上した。コストと精度が同時に改善するのは珍しい構造で、「余計な指示が邪魔をしていた」という仮説を裏付けている。
コスト最大73%削減の内訳
/claude-api cost-optimizeコマンドをSonnet 5ベースで4つの公開ベンチマークに適用した結果は以下の通り。
- tau2-bench retail：プロンプトキャッシングにより、合格率を維持したままコストが約73%減少
- LegalBench：共通プレフィックスのキャッシュ＋低エフォート＋Batch API利用で約58%減少
- OfficeQA Pro：バッチ処理とドキュメントキャッシュで約52%減少
- SWE-bench Verified：中エフォートと簡潔な出力で約55%減少
73%という数字はやや特殊ケース（キャッシングの恩恵が最大化しやすいリテール系サポート）だが、50%台が複数のベンチマークで出ているのは実務レベルの話として受け取ってよい。
エフォート調整の具体例
「難しいタスクには高エフォートを」という直感が常に正しいわけではない。
Humanity's Last Exam（ツール不使用）では、Fable 5.1の最大エフォートのコストは「超高」エフォートと比べて46%跳ね上がるが、スコアの伸びは0.5ポイントに過ぎない。この差はベンチマーク実行ごとのばらつきの範囲内だという。つまり、コストを46%積み増ししても意味のある性能向上は得られていない。
逆に、CursorBench 3.2では低エフォートのFable 5.1が、高エフォートのFable 5と同等のパフォーマンスを3分の1のコストで達成している。これはモデルの世代差とキャッシュ読み取り単価の差（高エフォートFable 5は1.00ドル/100万トークンに対し、低エフォートFable 5.1は0.25ドル）が組み合わさった結果だ。
ここからは見方の話——この発表が示す構造的な変化
事実の整理はここまでにして、少し引いた目線で見てみたい。
今回のAnthropicの発表が興味深いのは、「コスト削減のTips集」ではなく、「モデル移行時にプロンプトを見直せ」というメッセージが中心になっている点だ。
旧モデルの弱点を補うために積み上げてきたプロンプトの「補正」は、モデルが進化するたびに負債に変わる。これは「プロンプトエンジニアリング負債」とでも呼ぶべき構造だ。コードのリファクタリングに似ている。動いているから放置していたものが、バージョンアップの瞬間に足を引っ張る。
そしてここが見逃されがちなポイントだが、このアンチパターンの多くは「ちゃんと考えて入れた指示」だ。「2回検証せよ」は、過去に誤りが多かったから入れた。「重要：必ず〜」は、重要な制約を見落とされたから入れた。つまり、意図があるほど残りやすく、気づきにくい。
監査コマンドを使って機械的に検出できるようにしたのは、そのための現実的な解だ。ただし、「コマンドを叩けば最適化完了」とは思わないほうがいい。アンチパターンの除去後に何が変わったかを評価セットで確認する工程は省けない。
実務で何を考えるべきか
既存プロンプトの棚卸しをどう優先するか
全てのプロンプトを一気に見直すのは非現実的だ。まずターゲットを絞るべきで、優先度は「コストが大きいもの」×「モデルを最近更新したもの」の掛け算で決まる。コストが見えていなければ、各APIレスポンスのusageオブジェクトを集計するところから始める必要がある。
エフォート調整は「まず測定」が先
エフォートを変えるのは、変えた結果を測定できる評価セットがある場合に限る。感覚で「低エフォートにしてみた」では、何が改善して何が劣化したかが分からない。Anthropicが/claude-api hillclimbコマンドでトレーニングセットとテストセットを分割して反復探索できるようにしたのは、このためだ。
カスタマーサポートのベンチマークでの実例は参考になる。高エフォートOpus 4.8から出発し、監査済み低エフォートOpus 5に移行してコスト削減を確認。次に低エフォートSonnet 5を試すと正答率が98.9%から88.9%に落ちたが、プロンプト改善で同コストのまま98.9%に回復。最終的なテスト用チケット14件での正答率は90.5%（元の78.6%を上回り）、コストは元の約5分の1。この「試して、計測して、改善する」というプロセスそのものが再現すべきものだ。
プロンプトキャッシュは「静的なものを前に出す」という設計思想が要る
キャッシングの最大化は、プロンプトの構造設計に関わる話だ。「動的に変わる部分」と「固定される部分」を意識して分離する習慣がないと、キャッシュが頻繁に無効化されて効果が薄れる。特に、システムプロンプトにタイムスタンプやセッションIDを埋め込む実装は今すぐ見直したほうがいい。
次に来る論点
自動最適化コマンドの登場は便利だが、気になる論点がある。
最適化の自動化は「評価セットの品質」に依存する。/claude-api hillclimbが提案するのはあくまでもトレーニングデータを基にした改善だ。評価セットが実業務のエッジケースをカバーできていなければ、最適化が本番で失敗する。「テストで98.9%、本番で想定外の挙動」というパターンはAI開発あるあるであり、コマンドがあっても解決しない。
もう一つは、コスト管理がプロダクト設計の上流に入り込む時代という変化だ。エフォートの調整、モデルの選択、キャッシュ戦略は、アプリケーションの設計段階で考慮すべき要素になりつつある。「とりあえず最上位モデルで動かしてから考える」という開発フローは、スケールした途端に請求書が爆発する構造を内包している。
コストを後から削るより、設計段階でコスト効率を意識した構造を組む——これが次のフェーズで問われる開発リテラシーになっていく。
Anthropicの今回の発表は、「よいプロンプトを書く」という話ではない。モデルが進化するたびに、プロンプトもメンテナンスが必要という当たり前の事実を、具体的な数字とツールと一緒に突きつけてきた。73%のコスト削減という数字は一番いいケースだが、50%台が複数の場面で出ているなら、棚卸しをやらない理由は薄い。
