Anthropic がコスト削減の実務ガイドを公開、claude-api スキルに prompt-audit コマンドを追加

要約

Anthropic は 2026-09-08、公式ブログで Claude Platform 上のアプリケーションのコストを、性能を落とさずに下げる方法をまとめた記事を公開しました。

主張は冒頭で明確に示されています。性能とコストはトレードオフだと思われがちだが、実際には多くのアプリで両立できる。その根拠として3つの具体策が提示されます。プロンプトキャッシュのヒット率を最大化する、フロンティアモデルへ移る際にプロンプトのアンチパターンを取り除く、タスクに応じて effort を較正するの3つです。

キャッシュについては、成立条件が整理されています。モデルに固定されること、プレフィックスがバイト単位で完全一致すること、TTL（有効期限）があることの3つです。そのうえで、キャッシュを壊す典型パターンが挙げられます。会話途中での effort / thinking 設定の変更、システムプロンプト内の可変タイムスタンプや ID、順序が変わるツール定義、フォーク時のプレフィックス不一致、そしてキャッシュ TTL より長く動くツール呼び出しやサブエージェントです。

対策も具体的です。Claude Console のキャッシュ診断でミス箇所を特定する、稀にしか使わないツールを defer_loading でキャッシュ済みプレフィックスから外す、システム指示を会話途中のメッセージとして追加してシステムプロンプトを書き換えずに済ませる、max_tokens: 0 でキャッシュを事前ウォームする、といった手法が並びます。

指示文については、旧世代モデルの弱点を補うために書かれた指示が、フロンティアモデルではむしろ害になるという指摘が中心です。そして claude-api スキルに /claude-api prompt-audit コマンドが追加され、作業ディレクトリ内のプロンプト・スキル・ツール説明を対象に、これらのアンチパターンを監査できるようになりました。

何が変わったか

• /claude-api prompt-audit が claude-api スキルに追加された（Claude Code から実行）
• Claude Console にプロンプトキャッシュ診断があり、直前リクエストとの分岐点を特定できる
• defer_loading で稀用ツールをキャッシュ済みプレフィックスから外せる
• Opus 5 と Fable 5.1 は、会話途中で effort を変更してもキャッシュが壊れない（他モデルは壊れる）
• 自動キャッシュブレークポイントで、会話の伸長にあわせて位置を追従させられる
• キャッシュミス時の再書き込みは通常入力価格の 1.25倍（1時間キャッシュでは2倍）

業務インパクト（一般企業向け）

この記事が刺さるのは、すでにプロンプト資産を持っている組織です。

指摘されているアンチパターンを並べると、その理由が分かります。「二重チェックせよ」といった検証儀式、「CRITICAL: YOU MUST ALWAYS」のような強調、scratchpad や「ステップごとに考えよ」といった固定手順、旧モデルの失敗パターンに合わせた few-shot、矛盾する規則、旧世代向けの手動 thinking budget 設定。これらはいずれも、数年前には有効だった、あるいは有効だと信じられていた手法です。当時のプロンプトをそのまま運用し続けている組織ほど、該当箇所が多くなります。

厄介なのは、これらが壊れていないことです。動作はします。出力も返ってきます。ただ、フロンティアモデルはこうした指示を字義通りに受け取るため、不要な検証を実際に行い、不要な推論を実際に回し、その分のトークンを消費します。つまり**「動いているから触らない」という判断が、そのまま毎月の課金として積み上がる**構造です。prompt-audit は、この棚卸しを手作業から機械的な検査へ移す手段になります。

**キャッシュ側の指摘には、設計を見直す価値のあるものが混ざっています。**特に、キャッシュ TTL（既定5分）より長く走るツール呼び出しやサブエージェントの話は重要です。エージェント構成で外部 API を叩き、その応答を待っている間にキャッシュが切れると、次のターンはキャッシュ再書き込みの 1.25 倍価格になります。エージェントの並列化やタイムアウト設計が、そのままコストの問題になるという指摘は、機能設計とコスト設計を分けて考えている組織には見落とされがちです。

**defer_loading と「システム指示をメッセージとして追加」の2つは、すぐ効く実装テクニックです。**前者はツールを大量に定義しているエージェントで効き、後者は「会話の途中でルールを足したい」という要求をキャッシュを壊さずに満たします。どちらも大がかりな改修を伴わないため、優先度の高い順に着手するなら、この2つが最初でしょう。

**なお、同日に OpenAI 側も Prompt Cache Diagnostics を GA にしています。**2社が同じ日に、同じ論点（キャッシュミスの可視化）へ動いた形です。キャッシュ効率が LLM アプリの運用コストの主要因になったという認識が、ベンダー側で共有されつつあると読めます。

副業・個人活用視点

個人開発では、まず /claude-api prompt-audit を一度流すのが費用対効果として最短です。

Claude Code から実行でき、対象は作業ディレクトリ内のプロンプト、スキル、ツール説明です。自分で書いたプロンプトほど、アンチパターンが入りやすいという事情もあります。ネット上のプロンプト集や少し前の記事を参考にすると、「必ず段階的に考えて」「絶対に確認してから答えて」といった記述が自然に混ざります。当時は有効だった手法が、今は課金だけ増やすという構図に、個人開発者は最も引っかかりやすい位置にいます。

**キャッシュの話は、個人開発でも金額として体感できます。**特にシステムプロンプトに現在時刻を入れているケース。ログのために入れた1行が、毎リクエストでキャッシュを完全に無効化します。動作は何も変わらないため、請求書を見るまで気づきません。この記事が挙げている「可変値をプレフィックスから外す」という指摘は、個人開発でこそ効きます。

Opus 5 と Fable 5.1 は会話途中で effort を変えてもキャッシュが壊れないという記述も、実用的です。「難しいところだけ effort を上げる」という運用は品質とコストの両面で合理的ですが、キャッシュが壊れるならその節約が相殺されるという問題がありました。この2モデルではその制約がありません。モデル選定の判断材料として、単なる性能比較とは別の軸になります。

受託で AI 機能を組み込んでいる場合、この記事は提案書の裏付けになります。「コスト最適化」を工数として計上する際、公式ベンダーが手順を明文化していることは、見積もりの根拠として説明しやすい材料です。prompt-audit の実行結果と、キャッシュ診断の前後比較を成果物にすれば、削減額の説明も数字で成立します。

一点だけ。この記事の手法はすべてを一度に適用するものではありません。キャッシュヒット率の改善と、指示文の削減と、effort の較正は、それぞれ独立して測れます。1つずつ入れて効果を測る方が、何が効いたかが分かり、次の案件へ知見として持ち出せます。