本番でAIエージェントを動かし始めると、LLM APIの月次請求が想定を超えて膨らむケースが頻発します。大半の原因は「すべてのリクエストをフロンティアモデルに投げ、システムプロンプトを毎回ゼロから送る」という非効率な実装にあります。Anthropicの公式APIが提供する3つの最適化手法——バッチAPI・プロンプトキャッシュ・モデルルーティング——を正しく組み合わせると、品質を落とさずにコストを最大95%削減できます。
本記事はAIエージェントガバナンスの基盤設計に連動しています。コストの計測・配賦についてはAI FinOps設計を参照してください。
LLM推論コストの構造——なぜ最適化が必要か
LLMコストは「入力トークン数×単価＋出力トークン数×単価」で決まり、同じ機能を3手法で最適化するとコスト構造が根本的に変わります。
LLMのAPIコストは単純な式で表せます。
``
コスト = (入力トークン数 × 入力単価) + (出力トークン数 × 出力単価)
Claude Sonnet 4.6を例に取ると、通常の入力単価は1Mトークンあたり$3です。ここで問題になるのは「同じシステムプロンプトを何万リクエストにもわたって繰り返し送信している」という実装パターンです。1,000トークンのシステムプロンプトを10万リクエスト/日で送ると、それだけで月に約90万トークン分の無駄なコストが生まれます。
最適化の対象となるコスト構造は3層です。
| コスト層 | 最適化手法 | 削減率 |
|---|---|---|
| 繰り返し入力トークン（システムプロンプト・ツール定義） | プロンプトキャッシュ | 最大90% |
| 非同期・バッチ処理可能なリクエスト | バッチAPI | 50% |
| フロンティアモデルで不要なタスク | モデルルーティング | 60〜75% |
バッチAPIで非同期タスクのコストを50%削減する
Anthropicのバッチ処理APIは一律50%割引で、レイテンシに余裕がある非同期タスクに適用するだけで請求額が半減します。
Anthropicのメッセージバッチング（Message Batches API）は、レスポンスが数秒以内に必要でない場合にすべての非同期タスクに適用できます。価格は通常の50%で、対象モデルは全Claude系列です。
向いているタスク:
- ドキュメントの一括要約・分類
- レポートの定期自動生成
- 大量の問い合わせログ分析
- 深夜バッチでのデータ加工
向かないタスク:
- チャットUIでの対話（レイテンシが直接UXに影響）
- ユーザーの操作をブロックする処理
バッチAPIの実装は通常APIと構造がほぼ同じですが、custom_idを付与してリクエストを束ね、ポーリングで結果を取得する非同期モデルになります。バッチ実行時間の上限は24時間（通常は1時間以内に完了）のため、SLA設計でバッファを持たせる必要があります。
プロンプトキャッシュで入力トークンを最大90%削減する
キャッシュ読み取りトークンの単価は通常入力の0.1倍。長いシステムプロンプトやツール定義を1回書いて繰り返し読む設計が、コストとレイテンシの両方を改善します。
プロンプトキャッシュ（Prompt Caching）はClaudeのAPIが提供するプレフィックスキャッシュ機能です。プロンプトの先頭から指定した位置（ブレークポイント）までをキャッシュし、以降のリクエストでキャッシュが命中すると、そのトークンを0.1倍の単価で読み込めます。
価格構造（Claude Sonnet 4.6の場合）:
| 操作 | 単価（1Mトークンあたり） |
|---|---|
| 通常入力 | $3.00 |
| キャッシュ書き込み（5分TTL） | $3.75（1.25倍） |
| キャッシュ書き込み（1時間TTL） | $6.00（2倍） |
| キャッシュ読み取り | $0.30（0.1倍） |
実装の要点:
- 静的コンテンツをプロンプト先頭に配置する: ツール定義・システム指示・背景知識など、リクエストをまたいで変化しないコンテンツを先頭に固め、そこにブレークポイントを置く
- 変動コンテンツはブレークポイントより後ろに置く: ユーザーメッセージ・タイムスタンプ・リクエスト固有のコンテキストはキャッシュされない部分に置く
- 最小キャッシュ長に注意する: Claude Sonnet 4.6では1,024トークン未満のブロックはキャッシュ対象外。短すぎるシステムプロンプトはキャッシュが機能しない
``python``
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
system=[
{
"type": "text",
"text": "（1,024トークン以上の静的システムプロンプト・ツール定義）",
"cache_control": {"type": "ephemeral"} # ブレークポイント
}
],
messages=[{"role": "user", "content": user_query}] # 変動部分
)
# usage.cache_read_input_tokens でキャッシュヒット数を確認
キャッシュは組織・ワークスペース単位で分離されており（2026年2月以降はワークスペースレベルで分離）、複数チームが同じワークスペースのキャッシュを共有することはありません。
モデルルーティング——タスク複雑度に応じて使い分ける
全リクエストの70〜85%はフロンティアモデルを必要としない。タスク分類で小型モデルに振り分けると、同品質で60〜75%のコスト削減が実現できます。
本番AIエージェントのログを分析すると、大半のリクエストは以下の4種類に集約されます。
- 分類・ラベリング
- 要約・構造化抽出
- テンプレートへの穴埋め
- FAQ形式の定型回答
これらはフロンティアモデル（Opus系）でなくとも、軽量モデル（Haiku系）で同等品質を出せます。Haiku 4.5の単価はSonnet 4.6の約1/3で、Opus 4.8と比べると1/5以下です。
ルーティング設計の実装方針:
- 信頼スコアによる分岐: 軽量モデルで回答を生成し、信頼スコアが閾値以下なら高性能モデルに再投入する（カスケードルーティング）
- タスク種別による事前分類: プロンプトから「分類・要約・推論・創作」のカテゴリを検出し、カテゴリに応じてモデルを選択する（ポリシーベースルーティング）
- LLMゲートウェイで一元管理: LLMゲートウェイにルーティングポリシーを集約し、個々のサービスに判断ロジックを持たせない
3手法の組み合わせ設計
バッチ50%割引とキャッシュ読み取り0.1倍と小型モデルルーティングを重ねると、フロンティアモデル全量実行比で最大95%のコスト削減が理論上実現できます。
3手法は互いに排他的でなく、重ねて適用できます。
| シナリオ | 適用手法 | 削減率 |
|---|---|---|
| 夜間バッチ・ドキュメント分析 | バッチAPI＋プロンプトキャッシュ | 〜95% |
| 対話型チャット（長い共通プロンプト） | プロンプトキャッシュ＋モデルルーティング | 70〜80% |
| リアルタイム分類・ラベリング | モデルルーティング | 60〜75% |
| 全ての非対話タスク | バッチAPI単体 | 50% |
実装時の優先順位は「プロンプトキャッシュ → モデルルーティング → バッチAPI」の順です。プロンプトキャッシュはコードの変更が最小限で済み、即効性があります。
規模別の留意点（SMB / エンタープライズ）
SMBの場合: まずプロンプトキャッシュの自動キャッシュ機能を有効化するだけで始められます。APIのレスポンスに含まれるcache_read_input_tokensを確認し、キャッシュヒット率が50%を超えるまでシステムプロンプトの構造を調整してください。次のステップとしてHaiku系モデルへのルーティングを試し、品質を評価した上で適用範囲を広げます。Kuuの運用管理サービスでは、コスト最適化の実装支援を提供しています。
エンタープライズの場合: LLMゲートウェイにルーティングポリシーとキャッシュ制御を集約し、複数チームの実装を統一します。モデル別・タスク種別のコスト配賦はAI FinOpsの計装と組み合わせて可視化してください。大規模な最適化基盤の設計はKuuのRDEサービスにご相談ください。
参考
- Prompt caching — Claude API Docs（Anthropic公式）
- Claude API pricing（Anthropic公式）
- Building Effective Agents（Anthropic Research）
まとめ
LLM推論コストの削減は、バッチAPI（50%割引）・プロンプトキャッシュ（読み取り0.1倍）・モデルルーティング（60〜75%削減）の3手法を組み合わせることで、品質を維持したまま最大95%のコスト削減が実現できます。
実装の優先順位は明確です。まずプロンプトキャッシュを有効化してシステムプロンプト・ツール定義のキャッシュヒット率を上げ、次に分類・要約系タスクをHaiku相当の小型モデルに振り分け、バッチ処理可能な非同期タスクはバッチAPIに移行します。
コスト最適化の実装支援についてはKuuのエージェント運用管理サービスにお問い合わせください。