コストとパフォーマンスはトレードオフなのか？Claude 公式ブログから、ポイントを整理してみた
こんにちは
5分置きににcompact
運用イノベーション部のかわいです。
先週 AWS 上で性能の良いマシンを起動させたところ、少し予算がオーバーしてしまったためすぐ止めた、ということがありました。
一般的にコストを削るとパフォーマンスが落ちる、という考え方は通念としてあると思いますが、先日 Claude Code 公式ブログで「パフォーマンスを犠牲にせずコストを削減する」tips的な記事を見つけました。
記事の冒頭ではこう言い切っています。
Performance and cost are often viewed as a trade-off: to spend less, you accept worse results. In practice, we've found that many applications using Claude Platform can cut costs without giving up performance with three fixes: maximize the prompt cache hit rate, remove anti-patterns from your prompts when upgrading to frontier Claude models, and calibrate effort to the task.
（コストと性能はトレードオフと見られがちだが、実際には多くのアプリで、プロンプトキャッシュのヒット率を最大化する・フロンティアモデルへの移行時にプロンプト内のアンチパターンを除去する・タスクに応じてeffortを調整する、という3つの対処で性能を犠牲にせずコストを削減できる）
これらの手法は claude-api という新しいスキルに実装されていて、Claude Code で使用できます。今回はこのスキルのうち、手元で試せる prompt-audit を実際に自分の CLAUDE.md に対して動かしつつ、記事全体で紹介されている方法を整理して紹介します。
1.プロンプトキャッシュ
プロンプトキャッシュは、リクエストの処理コストの高い部分を保存しておき、次回以降使い回す仕組みです。ブログ記事内では、効果的にプロンプトキャッシュを使用する際の考慮事項が挙げられています。
※補足として、記事内で言及されている prefill は Opus 4.6以上のモデルで廃止されています。
- キャッシュはモデルに紐づく（Avoid changing effort or thinking settings mid-conversation）
- キャッシュの読み取りにはプロンプト全体のバイト完全一致が必要（only share the parent’s cache when the fork’s prefix is byte-identical）
- TTL は有限（If an agent blocks on a long-running tool call or sub-agent, the cache can expire before the results come back）
※ただし Opus 5 と Fable 5.1 では、キャッシュ破損なしに effort レベルの変更が可能とのこと
With Claude Opus 5 and Fable 5.1 specifically, you can update effort mid-conversation without breaking the cache.
上記を守らない場合、キャッシュが壊れる（break the cache）可能性があるようです。
これらの対策としては、記事内では以下が紹介されています。
- キャッシュ診断昨日を使用して、キャッシュヒット率を監視する
- 使用頻度の低いツールに
defer_loadingフラグを付与する。これを付けたツールはキャッシュ対象のプレフィックスから除外され、Claudeがtool searchで実際に参照したときだけ会話に追加される - システムプロンプト自体を編集せず、メッセージとしてシステムプロンプトの更新を送る
- ツール定義やシステムプロンプト等の安定した部分を先頭に配置し、（変化の大きい）会話部分を後ろに配置する
（画像は How to fix it 項より引用）
- キャッシュTTLはデフォルト5分のため、5分以上のツール呼び出しやサブエージェント処理が必要な場合は TTL を1時間に設定する
2.プロンプト（の中身）
記事では、モデルの性能が上がるにつれて、旧来のプロンプトの書き方がそのままアンチパターンになっていく、と指摘されています。
列挙されていたのは以下の6種類です。
| アンチパターン | 問題点 |
|---|---|
| ダブルチェック文化 | 「作業をダブルチェックして」や「返答前に再度確認して」等の指示だと、今のモデルは指示に忠実なため、文字通り余計な確認処理を実行してしまう |
| 強調表現 | 「可能な限り徹底して～」や「重要：必ず～しないといけない」等は、冗長な出力や過剰なツール呼び出しを誘発する |
| 必須手順や思考過程の強制 | モデルのネイティブな思考と重複し、無駄なトークンを消費する |
| 陳腐化したfew-shot例 | 旧モデルの失敗パターンに合わせた例が、無駄に長い推論の連鎖を模倣させる |
| 矛盾するルール | 忠実に従おうとするほど、矛盾した指示の板挟みで動けなくなる |
| 古い設定 | 新しいモデルへの移行時に、API側から拒否される場合がある |
特に上記は「the latest Claude models（最新モデル）」になるにつれて、乖離が大きくなるようです（常にアップデートしていく必要があり、私も今回を機に CLAUDE.md を改修しました）。
CLAUDE.md へ prompt-audit をかけてみる
Claude Code から、以下のように自然言語でチェックをかけられます。
claude -p "自分のCLAUDE.mdを対象に、claude-apiスキルのprompt-auditの考え方で古い指示などがないかチェックしてほしい"
↓結果の一部
監査結果
**確定した問題（1件）**
- **7行目「利用スキル」リストが古い**
- `xxxxxxx` は `~/.claude/skills/` に実在しない（削除済みか、当初から未作成のまま記載された可能性）
- 逆に実在する `xxxxxxxxx`がリストに未記載
- 影響: このリストはあくまで参考情報で強制力は薄いですが、放置すると「今何が使えるか」の把握がずれ続けます
**問題なし（古い痕跡なし）**
- パス参照（ファイル保存先・メモリディレクトリ）は全て実在を確認済み
- 「Claude Code最新ベストプラクティス適用」方針そのものは矛盾なし
- セッション記憶ルール（39-49行目）は auto memory システムの説明と役割分担ができていて重複ではない
- 応答スタイル・検証ルール等は日付依存の技術仕様ではなく運用ポリシーなので「dated pattern」に該当する箇所なし
具体的にスキルに関する点や、反対に問題が見つからなかった点についても結果が表示されました。
指示は「最新のベストプラクティスを適用し～」等を付与してもいいかもしれない。
この結果をベースに、CLAUDE.md のメンテナンスも可能かと思います。
3.effort
effort は、簡単に言うと「どれだけ Claude にがんあって考えてもらうか」を決めるパラメータです。詳しくは以下参照されたし。
記事内では一部モデルにおけるベンチマークの値が掲載されています。
- Fable 5
低effort → 正答率11.5%、$5.35/タスク
max effort → 正答率30.9%、$19.00/タスク
→ effortを上げるとスコアは約2.7倍、コストは約3.5倍
- Fable 5.1
低effort → 正答率約53%、約$0.30/問
max effort → 正答率約61%、約$2.23/問
低effort → max effortは、正答率0.5ポイント程度の向上に対してコストが46%増
effortがモデル合っていないと、高すぎれば過剰思考でコストとレイテンシが増え、低すぎれば証拠不足のまま停止したり、ツール呼び出しの回数が減ったりしてしまいます。
「回答は完成して見えるが、部分的な情報の上に成り立っている」との表現が印象的でした。
The answer looks finished, but it's built on partial information.
改善案としては、以下のような方法が示されています。
Test stronger models at lower effort. A stronger model at low effort can be cheaper than a weaker model working hard (high effort).
→ 「より強い」モデル with 低いeffort は、「弱い」モデル with 高effortよりコストが安くつく
- Understand your task shape.
→ アプリケーションのパフォーマンスを測定し、対象タスクにおけるコストと性能のトレードオフを理解することで、適切なモデル/effortを指定できる
簡易まとめ的な
ここまで記事を簡単にかいつまんでまとめました。
プロンプトキャッシュや指示、モデルやeffortパラメータを適切に設定することで、コストとパフォーマンスの両立が可能、との内容でした。
私自身も普段あまり意識せず effortレベルを middle に設定していたり、CLAUDE.md が賞味期限切れになったりしていたので、この記事を参考に、あらためてメンテナンスの大事さと、タスクの性質理解が大事だと感じました。
ではまた！
完
参考
