Claude Code のコストを 30% 削る試算 — モデル選択とプロンプトキャッシュの設計

コストを可視化したあとは「どこを削るか」を決める

Claude Code を本気で運用すると、cost.log に積み上がる金額は1日数ドル単位まで膨らむ。
可視化までは前作「Claude Code のトークン消費を可視化する」で扱った。
残るのは「数字を見たあと何を削るか」だ。

結論を先に置く。
3つの軸 — モデル選択・プロンプトキャッシュ・命令単価チューニング — の組み合わせで、月額の30%は試算可能な範囲で削れる。
本記事は実施前の設計と試算に絞る。削減ポテンシャルの見積もり手順と根拠だけを扱い、施策の選定と効果検証は読み手のチームに残す。
まず、削減が進まない3つの構造を確認する。

なぜコストが膨らんだまま放置されるのか

可視化があってもコスト削減に進めない理由は3つある。

第一に、コマンドごとに最適なモデルを決め切れていない。
Sonnet 4.6 は強力だが、単純な分類・抽出・テンプレ生成に Sonnet を使う必然はない。
Haiku 4.5 の入力単価は $1/MTok、Sonnet 4.6 は $3/MTok と3倍差がある（Anthropic API Pricing）。

第二に、プロンプトキャッシュを意識せず命令を組んでいる。
キャッシュヒットの入力単価は通常の1/10。
コマンドファイル・MEMORY.md・コード断片など同じ文脈を反復する箇所は、キャッシュ対象に揃えるだけでヒット部分のコストが90%下がる。

第三に、出力トークンが入力の5倍単価で効いている。
JSON ops 形式の冗長な前置き・コードフェンス・説明文を吐かせると、安いはずの命令がじわじわ高くつく。
出力単価（output tokens）は Haiku 4.5 で $5/MTok、Sonnet 4.6 で $15/MTok。
出力100KTokは入力1MTokより高い。この単価構造を前提に設計する。

3軸を組み合わせれば、可視化の段階で見えていた「重い命令」の単価を大きく下げられる（後述の試算では合計で約30%）。
施策ごとに試算していく。

施策1: コマンド単位でモデルを選び直す

cost.log の集計から「重いコマンド上位」を出す。
コンテンツ自動化パイプラインの例で言うと、

research

draft

review

• 判断が複雑か（複数文脈を統合するか）: 必要 → Sonnet 4.6
• テンプレ生成・抽出・分類か: 不要 → Haiku 4.5
• コード生成や設計判断を含むか: 必要 → Sonnet 4.6

たとえば

dispatch_ops

draft

editorial-review

切り替え方法は、各コマンドの frontmatter に

model

---
description: "JSON ops を整形して標準出力に返す"
model: claude-haiku-4-5
allowed-tools: Read
---

<プロンプト本文>

run_cmd

model

claude --print --model

ここで効果を見積もる際の試算例を置く（コマンド構成・実行回数は典型例ベース）。

この構成単体で約22%。
モデル選び直しだけでも、命令量を変えずに2割は削れる試算になる。

施策2: プロンプトキャッシュをコマンドファイルに当てる

プロンプトキャッシュ は、システムプロンプト・長いコンテキスト・反復するコマンドファイルをサーバ側に保存する仕組み。
書き込みコストは通常入力の1.25倍だが、ヒット時は0.1倍 — つまりヒット部分は90%引き。
2回目以降の呼び出しで効く。

効果が出やすい使い方はこの3パターン。

• 同じコマンドを連続実行: バッチ処理で

  review

  を5回連続で叩く、など
• 共通のコンテキスト: 全コマンドで同じ MEMORY.md / CLAUDE.md を読み込む
• 長いプロンプト本体: 1コマンドのキャッシュ対象が最小単位を超える場合。最小単位は Sonnet 4.6 / Opus 4.7 で 2,048 トークン、Haiku 4.5 で 1,024 トークン（Anthropic 公式 docs）

キャッシュ対象にするには、API リクエスト側で

cache_control

claude --print

単価の関係は次のとおり（入力単価ベース）。

注意点はTTL。
デフォルトTTLは 5分（ephemeral）で、追加コストなしでキャッシュヒット時に自動更新される。
5分を超える間隔でキャッシュを保持したい場合に限り、

ttl: "1h"

試算の例：

• バッチ実行で共通文脈 8KTok のキャッシュヒット率を 80% 想定
• Sonnet 4.6 の場合、通常 $3 / 1MTok → ヒット部 $0.30 / 1MTok（90%引き）
• 月間の該当部分が 200KTok なら、$0.60 → $0.06 で $0.54 の削減
• 施策1で出した月額合計 $11.10 に対して約5%相当

施策1と合わせて約27%。
30%まであと一押し。

施策3: 出力トークンを削って単価を絞る

入力削減の次は出力削減。
出力単価は入力の5倍に固定されているので、無駄な前置き・コードフェンス・「以下に〜を示します」のような定型句が積み上がると、見落とした方の単価が効く。

dispatch_ops

**出力制約（厳守）**:
- 1文字目は `[`、最終文字は `]`
- JSON の前後に空行・説明文・選択理由を絶対に置かない
- 思考プロセスは内部に留め、出力はJSONのみ

効果というより、入れないと前置きで出力が膨らむのを防ぐ予防策に近い。
モデルの「丁寧に説明したがる傾向」を制約で抑える。

加えて、失敗時の早期exit設計でコストを削る。
リトライを無条件にすると、同じ失敗にトークンを2回・3回払うことになる。
「明らかに失敗するパターン（spending limit到達など）」は早期exitして再試行を止める。
一方、一時障害（503・タイムアウト）はリトライで救うべき。
ここを混同すると、削るべきコストと払うべきコストが入れ替わる。

設計ルールはこの3つに整理できる。

• 出力形式を冒頭で固定: JSONなら「1文字目は

  [

  、最終文字は

  ]

  」と明示
• 思考プロセスを出力しない: 「考え方を示せ」を求めると出力長が2倍以上に
• 早期exit条件を分ける: 一時障害（リトライで救済可）と確定的な失敗（再試行しても無駄）

出力トークン削減効果の見積もりは、

dispatch_ops

施策1〜3の合計：22% + 5% + 5% = 32%。
試算ベースで30%超の削減ポテンシャルが見える。

削減施策の検証方法

試算は試算であって、実測ではない。
施策投入の前後で同じ条件の比較が要る。

検証は3ステップで進める。

• 施策投入前の基準値を取る: 1週間 cost.log を蓄積、コマンド別に単価を出す
• 施策ごとに段階投入する: モデル切替 → キャッシュ → 出力削減の順で1施策ずつ
• 各段階の差分を測る: 1週間ごとに

  cost-report.py --date-range

  で前週比を出す

複数施策を一気に投入すると、どれが効いたか分からなくなる。
1つずつ入れて差分を測ると、効果のない施策が見える。

予算が厳しいときは、最も削減幅が大きいモデル切替から始める。
キャッシュは「同じ命令を高頻度で叩く」前提があるので、cron 頻度が低い処理では効果が出にくい。
コマンド頻度の分布を見てから順番を決めると、無駄な投資を避けられる。

まとめ — 試算は出発点、段階投入で実測に落とす

Claude Code のコストは、可視化のあと「削る設計」に進める段階で初めて運用対象になる。
モデル選択・プロンプトキャッシュ・出力トークン削減の3軸を組み合わせれば、試算ベースで30%削減のポテンシャルが見える。

ただし試算は実測ではない。
30%という数字は、上の前提（コマンド構成・実行頻度・ヒット率・出力短縮率）のもとでの見積もりに過ぎない。
試算で出た削減幅を実測に落とすには、施策を1つずつ段階投入して前週比を測る運用が要る。

設計と試算は Claude Code 自身に書かせて構わない。
そのうえで、人間が握る判断は3つに絞れる。

• どこまで削るか: 30%か、50%か、品質との交換比率
• どの精度を妥協できないか: Haiku に振り替えてはいけない命令はどれか
• 検証期間をどう取るか: 1週間で打ち切るか、月単位で測るか

仕組みを作るのは Claude Code、検証して採否を決めるのはSRE。
コスト削減もこの分業で前に進められる。