「安くする」は「性能を落とす」と同義だと思っていた。だがAnthropic公式ブログは、モデルのランクを下げずにコストだけ削る3つのレバー——プロンプトキャッシュ・指示文の棚卸し・effortの較正——を、実測のコスト削減率とセットで示していた。
プロンプトキャッシュを静かに壊す5つのNG行動と直し方、frontierモデルへ移行するときに消すべき6つの"アンチパターン"、effortを較正する具体的な判断基準——それぞれ公式が公開した実測値つきで持ち帰れる。
Anthropicが2026年9月8日付で公開した記事の主張は明快だった。Claude Platformを使う多くのアプリケーションは、性能を落とさずにコストを削減できる、という。
効くレバーは3つ。①プロンプトキャッシュのヒット率を最大化する②frontierモデルへ移行する際に、古い指示文に積もった"アンチパターン"を取り除く③タスクの形に合わせてeffort（思考の強さ）を較正する。3つとも「モデルのランクを下げる」以外の手段である点が肝で、以前このブログで書いた「読む仕事」に高いモデルを使わないという判断（タスクの性質でモデルの単価を変える）とは別の軸の話になる。あちらが「どのモデルを使うか」なら、今回は「同じモデルの中で、どう無駄を削るか」だ。
プロンプトキャッシュは、プロンプトの処理結果（KVキャッシュ）を保存し、同じプレフィックスで始まるリクエストは再計算せず読み込むだけで済ませる仕組み。読み込みは通常価格の一部で課金される。ただし条件は厳しい——モデルに固定され、バイト単位で完全一致し、有効期限（TTL）がある。
これらの設定は本文より前にプロンプトへ描画されるため、キャッシュされたプレフィックスの一部になっている。途中で変えるとそこから先のキャッシュが崩れる（Opus 5とFable 5.1だけは、会話の途中でeffortを変えてもキャッシュを壊さない例外）。
システムプロンプトに埋め込んだタイムスタンプやIDのような、呼び出しごとに変わる値はキャッシュを直接壊す。Claude Messages APIはツール定義を先頭に固定順で組み立てるため、定義の変更もキャッシュミスに直結する。
親のキャッシュを引き継げるのは、分岐後のプレフィックスがバイト単位で同一・同じモデル・同じeffortのときだけ。同期的なツール呼び出しやサブエージェントがTTLより長くブロックすると、結果が返ってくる頃にはキャッシュが切れている。次のターンはキャッシュを書き直すことになり、安い読み込み価格ではなく通常入力価格の1.25倍（1時間キャッシュなら2倍）を払う羽目になる。
ここが核心。ヒット率はClaude Consoleのキャッシュ診断で監視でき、ミスが起きた場合は2つの連続リクエストのどこでプレフィックスが分岐したかまで特定できる。「なんとなく速い／遅い」で終わらせず、原因を機械的に追える設計になっている。
直し方の実務Tipsも具体的だった：使用頻度の低いツールは defer_loading でプレフィックスの外に逃がす／システムプロンプトを直接編集せず会話途中のメッセージとして指示を追加する／安定した部分（ツール定義・システムプロンプト）を先頭、変化する会話を末尾に置く／モデルやeffortを変えるならcompactionなどどうせキャッシュが壊れるタイミングに合わせる／セッション開始時に max_tokens: 0 で明示的なブレークポイントを送りキャッシュを温めておく。
プロンプトやCLAUDE.md、スキルの指示文は、モデルの弱点を補うための注記を積み重ねながら育っていく。だが新しいモデルの能力に対して、その注記自体が古くなっていることには気づきにくい。公式が名指しした6つの"アンチパターン"は次の通り。
これを検出するために、公式はclaude-apiスキルに/claude-api prompt-auditというコマンドを追加した。作業ディレクトリ内のプロンプト・スキル・ツール定義（CLAUDE.mdも含む）をまとめて監査する。
実証実験も具体的だ。Opus 4.8からOpus 5への移行を想定し、カスタマーサポートのベンチマークで、クリーンなプロンプトに上記6種のアンチパターンを1つずつ仕込んだ「旧式プロンプト」を6本用意。①Opus 4.8のまま②モデルIDだけOpus 5に変更③さらにprompt-auditを1回かけたOpus 5——の3パターンで比較した。
ここが核心。prompt-auditでアンチパターンを取り除いた結果、平均でコスト-14.6%・精度+5.3%。理由は3つ具体的に判明している——①廃止済みの思考設定がルーティングのリクエストをAPIごと拒否させていた②矛盾した返金ルールのせいで、Opus 5が本来払うべき返金4件を"確認"のため保留していた③手動スクラッチパッドがOpus 5組み込みの思考と衝突し、3件のチケットでツール呼び出しを推論の中に書いたまま実行しなかった。
effortはClaudeに「どれだけ粘るか」を伝えるパラメータ。低effortは早く結論を出し、高effortは検証や別解の検討に時間をかける。だがコストと性能の関係はタスクごとに曲線の形がまったく違う、と公式は数値で示す。
Fable 5・FrontierCode Diamond（最難関50タスク）：低effortで11.5%・$5.35/タスク、最大effortで30.9%・$19.00/タスク。effortを最大まで上げるとスコアは約2.7倍（+19pt）伸びるが、コストは約3.5倍になる。
Fable 5.1・Humanity's Last Exam（ツールなし）：低effortで約53%・$0.30/問、最大effortで約61%・$2.23/問。最後の一段はスコア+0.5ptに対してコスト+46%——ベンチマークのノイズの範囲内で、実質「伸びしろゼロにお金を払う」形になる。
effortの較正は両方向に外れうる。高ければ良いと思い込むと、必要以上に長く迷い、コスト・レイテンシが増えるうえ回答の質が落ちることさえある（deliberationは"まだ探す余地がある"間だけ効く）。逆に低effortに偏らせすぎると、十分な証拠が揃う前に止まってしまう。ツール呼び出しが減り、3番目でなく最初の検索結果で答えてしまい、本来なら自分でやるはずのチェックまで飛ばす。
CursorBench 3.2で、Fable 5.1の低effortはFable 5の最大effortと同等の性能を1/3のコストで達成した。安さの理由は2つ——低effortでは1タスクあたりの処理量が減ること、Fable 5.1のキャッシュ読み取り単価が$0.25/百万トークン（Fable 5は$1.00/百万トークン）であること。Fable 5と同じ価格だとしても、Fable 5.1の低effortは約40%安い計算になる。
effortを何段階かに振って評価を回し、コスト-性能の曲線が平坦なら、そのタスクは思考量に律速されていない——つまりeffortを上げても意味がない、と判定できる。
/claude-api hillclimbは、評価セットをtrain/testに分け、失敗したtrainの例を読んで設定変更を提案する自動探索。カスタマーサポートのベンチマークで、Opus 4.8の既定(高)effortから開始し、まずOpus 5の低effort＋prompt-auditを試したところ、train精度98.9%でOpus 4.8の基準を上回りつつコストは1チケット2.6セントまで下がった。さらにSonnet 5の低effortに下げると1セントまで安くなるが精度は88.9%に低下——そこでルーティングルールと返金上限の相互参照をプロンプトへ追加し、コストを据え置いたまま98.9%まで回復させた。探索が一度も見ていない保留14チケットでの最終評価は精度90.5%（元の設定は78.6%）、コストは約1/5だった。
①のプロンプトキャッシュ制御は、Claude APIを直接叩くアプリケーション向けの話で、対話型のClaude Codeをそのまま使っている今の運用には直接は乗らない——ブレークポイントやTTLを自分で操作する場面がそもそも無いからだ。
一方、②の「指示文のアンチパターンを消す」は、CLAUDE.md/AGENTS.mdの運用そのものに当てはまる。実際にこの記事を書くにあたり、6つのアンチパターンの物差しでAGENTS.mdを読み返してみたが、公式が問題視するような「検証儀式」「矛盾したルール」「強制スクラッチパッド」は見当たらなかった——見つかったのは「必ず承認を得る」「必ずjournalに追記する」といった運用上の安全策で、公式が指す"冗長なトークン消費の温床"とは性質が違う。とはいえ、"念のため"の一文を積み重ねがちなCLAUDE.md運用者ほど、一度この物差しで棚卸しする価値はありそうだ。
③のeffort較正は、「読む仕事」に高いモデルを使わないで決めた「探す・数える・集める＝安いモデル／書く・直す・判断する＝既定モデル」という静的な振り分けの、より細かい版として読める。公式が示す「モデルを下げるより先に低effortを試す」という優先順位は、こちらの「モデルのランクを落とすより先に生産量を絞る」というルールと同じ発想だ——コスト削減の第一手はモデルのグレードダウンではなく、同じモデルの中でパラメータを絞ることにある。