11月7日、startuphub.aiが「Your old Claude prompts are costing you twice」と題した記事を公開した。AnthropicのLance Martinが解説する、古いClaudeプロンプトがコストと品質の両面で損失を生んでいる問題とその対策について詳しく紹介されている。
コスト72%削減——プロンプトの「棚卸し」が生む最大の果実
Martinが内部ベンチマークで示した数字は明快だ。プロンプトキャッシュを最適化するだけで、パフォーマンスの有意な変化なしに最大72%のコスト削減を達成できるという。
プロンプトキャッシュとは、繰り返し使われるコンテキストをキャッシュとして保持し、APIコールのたびに同じ内容を再送しなくて済む仕組みを指す。Martinによれば、キャッシュヒット時のトークン読み取りコストは通常トークンの約10分の1。Claude Codeはキャッシュヒット率を重点的に追跡しており、それがコスト構造を大きく左右するからだという。
この数字を聞いて「うちのプロンプトは大丈夫か」と思ったチームこそ、以下に紹介する監査とeval（評価）の手順を試す価値がある。
「良いプロンプト」が負債になる
AnthropicのMember of Technical Staff（MTS）であるLance Martinが、AI Engineerのインタビューで語った内容が、プロンプトエンジニアリングの現場に刺さる内容だ。MTSはAnthropicにおける個人貢献者（Individual Contributor）として最上位に近い技術職位であり、モデル・インフラ・ツールチェーンにまたがる深い知見を持つロールとされている。
「プロンプトはコードと同じように技術的負債を積み上げる」
Martinが問題視するのは、以下のような定番フレーズだ。
think step-by-step（ステップごとに考えろ）double-check your work（作業を二重確認しろ）be maximally thorough（最大限に徹底しろ）
これらはかつてのモデルには有効だったが、現在のフロンティアモデル（最先端の大規模言語モデル）には不要どころか逆効果になる。強力なモデルは矛盾するルールを無視するのではなく、どれにも従おうとするため、トークン消費量が増加し、むしろ出力品質が下がるとMartinは説明する。
つまり、昨年書いた「良いプロンプト」が、今年は余計なトークンを消費させながら品質を落とすという二重の損失を引き起こしている。モデルの進化サイクルが短くなるほど、この「プロンプト負債」の蓄積スピードも上がる。自社プロダクトのプロンプトを最後に見直したのがいつか思い出せないチームには、特に切実な問題といえる。
3つの対策：監査・キャッシュ・eval
1. プロンプト監査
Martinがデモしたのは、Claude Code上で動作するプロンプト監査コマンドだ。
実際の運用では /doctor prompt-audit（/checkup prompt-audit のエイリアス）として呼び出せる。このコマンドは CLAUDE.md、AGENTS.md、rules、skills、subagentsといったファイルをスキャンし、問題のある記述（アンチパターン）を洗い出す。なお、settings や .mcp.json は読み取り対象外だという。
監査の目的は「何を削れるか」を見つけることにある。現行モデルがデフォルトで行う処理をプロンプトで二重に指示しているケースを機械的に検出し、不要な命令を整理することで、次のキャッシュ最適化の効果も高まる。
2. プロンプトキャッシュ（最大72%コスト削減）
前述のとおり、キャッシュヒット時のトークン読み取りコストは通常の約10分の1だ。キャッシュ効率を高めるには、変化しない長いコンテキスト（システムプロンプト・ドキュメント・ルール定義など）をプロンプトの前半にまとめ、変化する部分（ユーザー入力など）を後半に配置するという構成上の工夫が有効とされている。Claude Codeがキャッシュヒット率を専用指標として追跡しているのも、この最適化が実運用で無視できないインパクトを持つからだとMartinは強調する。
3. eval（評価）とヒルクライミング
変更が本当に改善をもたらしたかを検証するのがeval（評価用タスクセット）だ。Martinは claude api build eval コマンドを使い、テストケースをトレースから選択し、実行ごとのばらつきを抑えたバイナリ評価基準（合否二択）でスコアリングする仕組みをデモした。
その上でヒルクライミング（hill climbing）と呼ばれる自動最適化ループを走らせる。これはプロンプトや設定の変更案をevalスコアと照らし合わせながら試し、スコアが上がったものだけを残していく手法だ。過学習（overfitting）を防ぐため、訓練セットとテストセットを分けて運用する。
evalを持たずに「感覚」でプロンプトを改善しているチームは、変更が効いているのか副作用を生んでいるのかを判断する手段がない。監査→キャッシュ最適化→evalという一連のサイクルを回すことで、プロンプト改善を再現性のある工学的プロセスに引き上げることがMartinの主眼だ。
なぜ今これが重要か
モデルの能力が急速に向上している現在、プロンプトの書き方の「正解」も変わり続けている。1年前に最適化したプロンプトがそのまま本番環境で動き続けているチームは少なくないはずで、Martinの指摘は「プロンプトにも定期的なメンテナンスが必要」という当然だが見落とされがちな事実を改めて浮き彫りにしている。コードに技術的負債の概念を持ち込んだように、プロンプトにも同じ視点を持ち込む時期に来ているといえる。
詳細はYour old Claude prompts are costing you twiceを参照していただきたい。
