コラム / コスト最適化 /
Claude API のコストを 1/5 にする ─ プロンプトキャッシュ・モデルカスケード・バッチAPI の実務
📖 約11分 / 公開日: 2026/05/18
## Claude API の請求書が想定の3倍になった、という相談が4月から急増している
ここ数ヶ月、Anthropic Claude API のコストが想定を大きく超えた、という相談が立て続けに入っています。共通するのは「Claude 3.5 Sonnet で組んだ社内チャットを Claude Opus 4 に切り替えたら月額が 8万円から 38万円になった」「RAG のプロンプトが長くなり1リクエスト 0.04 ドルに膨らんだ」というパターン。料金体系を理解せずにモデル選定とプロンプト設計を進めると、簡単に当初予算の3倍に達します。
当センターでは過去半年で12件、Claude API のコスト最適化を直接担当しました。プロンプトキャッシュ、モデルのカスケード、バッチ API、コンテキスト圧縮 ─ 効くものと効かないものがあります。順に書きます。
## プロンプトキャッシュは「効く現場」と「効かない現場」で180度違う
Anthropic のプロンプトキャッシュは、5分以上同じプレフィックスが使い回されることが見込めるなら、ほぼ無条件で導入すべき機能です。キャッシュ書き込みのコストは通常入力の 1.25倍、読み出しは 0.1倍。つまり1回書いて9回以上読まれれば、トータルで安くなる計算です。実測では、同一システムプロンプト 1.2万トークン + RAG コンテキスト 4万トークンの構成で、キャッシュ未使用時の月額 22万円が 6.8万円まで下がった事例があります。
ところが、ユーザーごとに動的にコンテキストを入れ替えるアーキテクチャだと、キャッシュヒット率は10%を切ります。Anthropic のキャッシュは「完全一致のプレフィックス」を求めるため、ユーザー名や日付がプレフィックスに混じった瞬間に効かなくなる。よくある失敗が「リクエストごとに `現在時刻: 2026-05-18 21:07` をシステムプロンプトの先頭に入れる」設計です。これだけでキャッシュは完全に無効化されます。可変要素は必ず末尾に寄せる ─ この原則を理解しないまま実装したシステムを、いままで何度も書き直しました。
cache_control の入れ方にも注意がいります。最大4箇所までしかブレークポイントを置けないため、システムプロンプト → ツール定義 → RAG コンテキスト → 会話履歴、と区切りを意識した設計が必要です。何も考えず全部の塊にキャッシュ指定を入れると、最後の塊しか効かないケースに陥ります。
## Opus 4 を全リクエストで使っているなら、その時点でコスト最適化の余地は7割以上
最も効くのはモデルのカスケード設計です。Claude Opus 4 の入力は 15 ドル / 100万トークン、出力 75 ドル。Sonnet 4 の5倍。Haiku 4.5 はその10分の1。全リクエストを Opus に流す設計は、ほぼ間違いなくコスト過剰です。
実務では「分類は Haiku → 簡易応答は Sonnet → 複雑な推論のみ Opus」の3段カスケードを組みます。社内 FAQ チャットの実例で、Opus 単独で月額 47万円だったシステムを、Haiku で意図分類してから Sonnet に渡す2段構成に変更したところ、月額 11万円まで下がりました。正答率は人間評価で 92% → 91% と、有意差なし。
意外と効くのが「初回応答は Haiku で出して、ユーザーが詳細を求めたら Opus を呼ぶ」段階的応答です。チャット UI の体感速度も上がり、Opus 呼び出し回数が 65% 減ったケースがあります。コストと UX を同時に改善する珍しいパターンで、優先度の高い改善策。
ただしカスケードには罠もあります。Haiku の分類精度が落ちると上位モデルへのエスカレーションが過剰発生し、結果的に Opus 単独より高くなることがある。閾値設計とログ監視を怠ると逆効果になる、という現場の苦い経験を共有しておきます。
## バッチ API は「即時性が不要な処理」では使わない理由がない
Anthropic のバッチ API は、24時間以内に処理されればよい用途で 50% 引きになります。月次レポート生成、大量ドキュメントのタグ付け、過去ログの要約 ─ これらをリアルタイム API で回している組織は、いまだに多い。
900万トークンの社内文書を Claude Sonnet 4 でタグ付けする処理が、リアルタイム API で月額 13.5万円かかっていたものを、バッチ API に切り替えて 6.7万円に圧縮した実例があります。コードの変更は数十行。投資対効果が極めて高い領域です。
注意点として、バッチ API はストリーミングに対応せず、エラー時のリトライ制御も独自仕様。失敗バッチの再投入ロジックを真面目に組まないと、運用で破綻します。あと、24時間きっかりで返ってくるわけではなく、混雑時は 18〜23時間に分散する。深夜帯に投げて朝に結果を見る運用が現実的です。
## コンテキスト圧縮は「やりすぎ」が事故の元
長文 RAG で安易にやってしまうのが、過去会話を要約して詰め直す rolling summary 方式。コストは確実に下がりますが、固有名詞や数値が要約で抜け落ち、回答精度が著しく劣化するケースを何度も見ました。
代替案は「直近 5 ターン + 過去のキーフレーズ抽出（人名、金額、日付）のみ保持」というハイブリッド方式。トークン数は要約方式と同等まで圧縮できる一方、業務上重要な情報の脱落が大幅に減ります。Anthropic の公式ドキュメントには載っていない、現場で編み出した方式です。
もうひとつ、RAG のチャンク粒度を見直すだけでコンテキストが3割減ることがあります。多くの実装が 1000 トークン固定でチャンクしていますが、社内文書のセクション境界に沿った可変長チャンク（300〜1200 トークン）に切り替えると、ヒットしたチャンクの情報密度が上がり、上位 5件ではなく上位 3件で同じ回答精度に達する。プロンプトキャッシュとの相性もよく、組み合わせると月額が半分以下になることもあります。
## やらないほうがいいこと
最後に、コスト削減で「やってはいけない」典型を3つ。
1つ目、出力トークン上限を絞りすぎる。max_tokens を 512 に固定してコストを下げようとすると、回答が途中で切れて再生成リクエストが2倍3倍に膨れ、結果として高くつきます。出力を制限したいなら、システムプロンプトで「簡潔に答えよ」と指示するほうが効きます。
2つ目、安いモデルに無理やり全部寄せる。Haiku で複雑な推論を強引にやらせると、リトライとプロンプトの肥大化で、結局 Sonnet を素直に使ったほうが安く済むパターンが頻発します。タスクの難易度を測ってからモデルを選ぶ。順序が逆になっている組織は多い。
3つ目、コスト監視を入れずに走らせる。Anthropic Console の Usage 画面は日次更新で、リアルタイム性がない。Datadog や CloudWatch にカスタムメトリクスを流す仕組みを、本番投入前に必ず入れること。月末に請求書を見て驚く、という運用は職務怠慢です。
Claude API は使い方次第で月額が3倍にも 1/5 にもなります。プロンプトキャッシュ・モデルカスケード・バッチ API ─ この3点を抑えるだけで、ほとんどの現場で 40〜70% のコスト削減が実現可能。困っている現場は、まず現状の月額内訳をモデル別・エンドポイント別に出すところから始めてください。それで自然と着手すべき場所が見えます。
ここ数ヶ月、Anthropic Claude API のコストが想定を大きく超えた、という相談が立て続けに入っています。共通するのは「Claude 3.5 Sonnet で組んだ社内チャットを Claude Opus 4 に切り替えたら月額が 8万円から 38万円になった」「RAG のプロンプトが長くなり1リクエスト 0.04 ドルに膨らんだ」というパターン。料金体系を理解せずにモデル選定とプロンプト設計を進めると、簡単に当初予算の3倍に達します。
当センターでは過去半年で12件、Claude API のコスト最適化を直接担当しました。プロンプトキャッシュ、モデルのカスケード、バッチ API、コンテキスト圧縮 ─ 効くものと効かないものがあります。順に書きます。
## プロンプトキャッシュは「効く現場」と「効かない現場」で180度違う
Anthropic のプロンプトキャッシュは、5分以上同じプレフィックスが使い回されることが見込めるなら、ほぼ無条件で導入すべき機能です。キャッシュ書き込みのコストは通常入力の 1.25倍、読み出しは 0.1倍。つまり1回書いて9回以上読まれれば、トータルで安くなる計算です。実測では、同一システムプロンプト 1.2万トークン + RAG コンテキスト 4万トークンの構成で、キャッシュ未使用時の月額 22万円が 6.8万円まで下がった事例があります。
ところが、ユーザーごとに動的にコンテキストを入れ替えるアーキテクチャだと、キャッシュヒット率は10%を切ります。Anthropic のキャッシュは「完全一致のプレフィックス」を求めるため、ユーザー名や日付がプレフィックスに混じった瞬間に効かなくなる。よくある失敗が「リクエストごとに `現在時刻: 2026-05-18 21:07` をシステムプロンプトの先頭に入れる」設計です。これだけでキャッシュは完全に無効化されます。可変要素は必ず末尾に寄せる ─ この原則を理解しないまま実装したシステムを、いままで何度も書き直しました。
cache_control の入れ方にも注意がいります。最大4箇所までしかブレークポイントを置けないため、システムプロンプト → ツール定義 → RAG コンテキスト → 会話履歴、と区切りを意識した設計が必要です。何も考えず全部の塊にキャッシュ指定を入れると、最後の塊しか効かないケースに陥ります。
## Opus 4 を全リクエストで使っているなら、その時点でコスト最適化の余地は7割以上
最も効くのはモデルのカスケード設計です。Claude Opus 4 の入力は 15 ドル / 100万トークン、出力 75 ドル。Sonnet 4 の5倍。Haiku 4.5 はその10分の1。全リクエストを Opus に流す設計は、ほぼ間違いなくコスト過剰です。
実務では「分類は Haiku → 簡易応答は Sonnet → 複雑な推論のみ Opus」の3段カスケードを組みます。社内 FAQ チャットの実例で、Opus 単独で月額 47万円だったシステムを、Haiku で意図分類してから Sonnet に渡す2段構成に変更したところ、月額 11万円まで下がりました。正答率は人間評価で 92% → 91% と、有意差なし。
意外と効くのが「初回応答は Haiku で出して、ユーザーが詳細を求めたら Opus を呼ぶ」段階的応答です。チャット UI の体感速度も上がり、Opus 呼び出し回数が 65% 減ったケースがあります。コストと UX を同時に改善する珍しいパターンで、優先度の高い改善策。
ただしカスケードには罠もあります。Haiku の分類精度が落ちると上位モデルへのエスカレーションが過剰発生し、結果的に Opus 単独より高くなることがある。閾値設計とログ監視を怠ると逆効果になる、という現場の苦い経験を共有しておきます。
## バッチ API は「即時性が不要な処理」では使わない理由がない
Anthropic のバッチ API は、24時間以内に処理されればよい用途で 50% 引きになります。月次レポート生成、大量ドキュメントのタグ付け、過去ログの要約 ─ これらをリアルタイム API で回している組織は、いまだに多い。
900万トークンの社内文書を Claude Sonnet 4 でタグ付けする処理が、リアルタイム API で月額 13.5万円かかっていたものを、バッチ API に切り替えて 6.7万円に圧縮した実例があります。コードの変更は数十行。投資対効果が極めて高い領域です。
注意点として、バッチ API はストリーミングに対応せず、エラー時のリトライ制御も独自仕様。失敗バッチの再投入ロジックを真面目に組まないと、運用で破綻します。あと、24時間きっかりで返ってくるわけではなく、混雑時は 18〜23時間に分散する。深夜帯に投げて朝に結果を見る運用が現実的です。
## コンテキスト圧縮は「やりすぎ」が事故の元
長文 RAG で安易にやってしまうのが、過去会話を要約して詰め直す rolling summary 方式。コストは確実に下がりますが、固有名詞や数値が要約で抜け落ち、回答精度が著しく劣化するケースを何度も見ました。
代替案は「直近 5 ターン + 過去のキーフレーズ抽出（人名、金額、日付）のみ保持」というハイブリッド方式。トークン数は要約方式と同等まで圧縮できる一方、業務上重要な情報の脱落が大幅に減ります。Anthropic の公式ドキュメントには載っていない、現場で編み出した方式です。
もうひとつ、RAG のチャンク粒度を見直すだけでコンテキストが3割減ることがあります。多くの実装が 1000 トークン固定でチャンクしていますが、社内文書のセクション境界に沿った可変長チャンク（300〜1200 トークン）に切り替えると、ヒットしたチャンクの情報密度が上がり、上位 5件ではなく上位 3件で同じ回答精度に達する。プロンプトキャッシュとの相性もよく、組み合わせると月額が半分以下になることもあります。
## やらないほうがいいこと
最後に、コスト削減で「やってはいけない」典型を3つ。
1つ目、出力トークン上限を絞りすぎる。max_tokens を 512 に固定してコストを下げようとすると、回答が途中で切れて再生成リクエストが2倍3倍に膨れ、結果として高くつきます。出力を制限したいなら、システムプロンプトで「簡潔に答えよ」と指示するほうが効きます。
2つ目、安いモデルに無理やり全部寄せる。Haiku で複雑な推論を強引にやらせると、リトライとプロンプトの肥大化で、結局 Sonnet を素直に使ったほうが安く済むパターンが頻発します。タスクの難易度を測ってからモデルを選ぶ。順序が逆になっている組織は多い。
3つ目、コスト監視を入れずに走らせる。Anthropic Console の Usage 画面は日次更新で、リアルタイム性がない。Datadog や CloudWatch にカスタムメトリクスを流す仕組みを、本番投入前に必ず入れること。月末に請求書を見て驚く、という運用は職務怠慢です。
Claude API は使い方次第で月額が3倍にも 1/5 にもなります。プロンプトキャッシュ・モデルカスケード・バッチ API ─ この3点を抑えるだけで、ほとんどの現場で 40〜70% のコスト削減が実現可能。困っている現場は、まず現状の月額内訳をモデル別・エンドポイント別に出すところから始めてください。それで自然と着手すべき場所が見えます。