Bedrockの推論コストをどう下げるか — ワークロード特性から効くレバーを引くFinOps判断木
Bedrockの推論コストは「安いモデルに変える」だけでは下がりません。プロンプトキャッシュ／バッチ・サービスtier・Intelligent Prompt Routing・モデル蒸留——効くレバーはワークロード特性で変わり、併用不可の罠もあります。即時性・再利用性・定型性の判断木で当たるレバーだけを選ぶFinOps設計を整理します。効き幅は公式の最大値・2026年6月時点、個別単価は公式料金へ。
- #Bedrock
- #生成AI
- #推論コスト
- #FinOps
- #プロンプトキャッシュ
- #バッチ推論
- #Intelligent Prompt Routing
- #モデル蒸留
- #コスト最適化
生成AIを本番で運用すると、トラフィックの増加にともなって推論費が線形に膨らみます。これを抑える発想は「より安いモデルに変える」だけではありません。Amazon Bedrock には推論コストを下げる独立したレバーが複数あり、それぞれ効く条件とトレードオフ、そして併用できない組み合わせがあります。本記事は、Bedrockの推論コストを下げるレバーを、ワークロード特性（即時性・再利用性・定型性）から判断木で引き、併用不可の罠やプロンプトキャッシュが逆に高くつく条件まで含めて単価を設計する、FinOps視点の手引きです。対象は生成AIを本番運用する実務者で、Bedrock 料金の基本構造は前提として簡潔に扱います。効き幅はいずれも公式が示す最大値であり、料金や対応状況は2026年6月時点のため、適用前に公式の最新情報をあわせてご確認ください。
なぜ単価設計が上級テーマなのか
推論コストの難しさは、レバーが1つではなく、しかも効く前提がレバーごとに異なる点にあります。あるワークロードで大きく効くレバーが、別のワークロードではまったく効かない、あるいは逆効果になることもあります。レバーはそれぞれ、レイテンシ・精度・実装コストのいずれかと引き換えになっており、トレードオフの形が違います。
そのため、コスト最適化は「使えるレバーを全部盛る」問題ではありません。むしろ全部盛りは、実装コストと運用の複雑さを増やすだけの過剰投資になりがちです。要点は、自分のワークロードの特性に「当たるレバーだけ」を選ぶことです。以降では、まず5つのレバーと効き幅を一覧で押さえ、ワークロード特性からレバーを引く判断木に落とし、課金モードの選び方と併用可否、そして最後にプロンプトキャッシュが逆に高くつく条件を確認します。
5つのレバーと効き幅 — 何がどれだけ効くか
Bedrockで推論コストに効く主なレバーは5つです。まず効き幅・前提・トレードオフを一覧で把握します。効き幅はいずれも公式が示す最大値（up to）で、実際の効果はワークロードに依存します。
| レバー | 効き幅（公式・最大） | 効く前提 | 主なトレードオフ |
|---|---|---|---|
| プロンプトキャッシュ | コスト最大 90% 削減・レイテンシ最大 85% 削減 | 長い共通プレフィックスを最小トークン以上・高頻度で再利用 | 再利用不足だと純損／対応モデル限定 |
| バッチ推論 | オンデマンド比 約 50% 低価格 | レイテンシ要件が緩い一括処理 | 即時応答に使えない／キャッシュと併用不可 |
| サービスtier（Flex／Priority） | Flexは標準比 -50%、Priorityは +75% プレミアム | 即時性の要否で選ぶ | Flexはレイテンシ緩和が前提 |
| Intelligent Prompt Routing | 精度を保ちつつ最大 30% 削減 | 同一ファミリの2モデルを基準でルーティング | 精度維持は事前evalが前提 |
| モデル蒸留 | 元モデル比 最大 75% 低コスト（高速化も） | タスクが定型・ドメイン固定 | 蒸留の構築・評価コスト |
プロンプトキャッシュは、システムプロンプトやRAGの固定コンテキストのような長い共通プレフィックスを繰り返し使う用途で効きます。バッチ推論は、夜間処理や大量要約のようにレイテンシ要件が緩い処理で効きます。サービスtierは即時性の要否で選ぶレバーです。Intelligent Prompt Routing は2025年4月にGA（一般提供）し、同一モデルファミリの2モデルを設定した基準でルーティングして、品質とコストを両取りします。モデル蒸留は、定型タスクで教師モデルの出力を小型モデルに学習させ、単価と速度を改善します。
ワークロード特性で効くレバーは変わる — 適性の判断木
レバーの一覧を頭に入れたら、次は自分のワークロード特性から「どのレバーが当たるか」を引きます。判断軸は即時性・再利用性・定型性の3つです。
レバーは2つのレイヤーに分けて考えると整理できます。第一のレイヤーが、ワークロード特性に合わせて引く「適性レバー」です。再利用性が高い、つまり共通プレフィックスを最小トークン以上・高頻度で再利用するなら、プロンプトキャッシュが当たります。定型性が高い、つまりタスクとドメインが固定されていて教師モデルの出力を小型モデルに移せるなら、モデル蒸留が当たります。品質を保ちながらコストを下げたい混在ワークロードなら、Intelligent Prompt Routing が当たります。これらは排他ではなく、特性が重なれば組み合わせ得ますが、当たらないレバーを無理に足しても効果は出ません。
第二のレイヤーが、後述する「課金モードの選択」です。判断木の末尾では、即時性の要否で課金モードへ分岐します。即時性が高い対話的な処理は Standard や Priority、即時性が緩い処理は Flex やバッチへ寄せる、という分岐です。
課金モードと併用可否 — サービスtierとバッチ
第二のレイヤーである課金モードは、サービスtierとバッチ推論で構成されます。ここで重要なのは、バッチ推論はサービスtierの一種ではなく、独立した推論モードだという点です。両者を別レーンとして捉えないと、選択を誤ります。
サービスtierは4種類あります。Standard を基準に、Priority は最優先・低レイテンシ向けで標準比 +75% のプレミアム、Flex はレイテンシ要件が緩い処理向けで標準比 -50% の割引です。Reserved は入出力のスループット（TPM）を一定期間予約する容量予約型で、固定費でミッションクリティカルな高ボリュームに備えます。バッチ推論はこれらとは別レーンの独立モードで、対応モデルでオンデマンド比およそ 50% 低価格になります。
| 課金モード | 価格の目安（公式・対標準） | レイテンシ | 適用ケース |
|---|---|---|---|
| Reserved（容量予約） | TPM予約の固定費 | 予約容量で安定 | 予測可能な高ボリューム・ミッションクリティカル |
| Priority | 約 +75% プレミアム | 最優先・低 | 即時性が最重要の対話 |
| Standard | 基準（係数1.0） | 標準 | 通常のオンデマンド |
| Flex | 約 -50% 割引 | 緩い | レイテンシを許容できる処理 |
| バッチ推論（別モード） | オンデマンド比 約 -50% | 非即時 | 夜間一括・大量要約・評価データ生成 |
注意点として、プロンプトキャッシュとバッチ推論は併用できません。プロンプトキャッシュはオンデマンド推論で効くレバーで、バッチ推論APIとは相互排他です。したがって、非即時の大量処理をバッチへ寄せる設計と、共通プレフィックスをキャッシュする設計は、同じ処理経路では両立しません。どちらが効くかをワークロードごとに判断します。また、各モデルがどのtier・どのリージョンに対応するかはモデル単位で異なるため、2026年6月時点の対応状況を公式ドキュメントで確認してください。個別モデルの単価も変動するため、断定した金額ではなく公式の料金ページで確認します。
「キャッシュで安く」が逆に高くつくとき
最後に、最も誤解されやすいレバーであるプロンプトキャッシュの落とし穴を確認します。「キャッシュを入れれば安くなる」という単純な期待は、条件次第で裏切られます。
第一に、純損の条件です。キャッシュ書き込みのトークンは、未キャッシュの入力より高く課金され得ます。つまり、書き込んだキャッシュが十分な回数だけヒットして再利用されなければ、書き込みの割増分を回収できず、かえって高くつきます。キャッシュは「再利用の前払い」であり、ヒット率が一定以上あって初めて得になります。導入前に、対象プレフィックスがどれだけの頻度で再利用されるかを見積もることが欠かせません。
第二に、最小トークンの制約です。キャッシュのチェックポイントにはモデル依存の最小トークンがあり、Claude 3.7 Sonnet では 1024 トークン、Opus 4.5・Haiku 4.5・Sonnet 4.5 では 4096 トークンが目安です。これに満たない短いプロンプトは、そもそもキャッシュの対象になりません。短い問い合わせが中心のワークロードでは、キャッシュの効果は限定的です。
第三に、TTL（有効期間）です。キャッシュの保持時間は多くが5分、一部のモデルで1時間とされ、ヒットのたびにリセットされます。再利用の間隔がTTLより長いと、キャッシュは保持されず書き込みからやり直しになります。アクセスが散発的なワークロードでは、この点も効果を削ります。
なお、Intelligent Prompt Routing やモデル蒸留の効き幅も用途に依存します。「精度を落とさず」「精度低下を抑えて」という公式の表現は、自分のワークロードでの事前評価（eval）があって初めて担保されるものです。安いモデルや蒸留モデルへ落とす判断は、評価で品質を確認してから行うのが安全です。
まとめ — 当たるレバーだけを選ぶ単価設計
Bedrockの推論コスト最適化は、使えるレバーを全部盛る作業ではありません。ワークロード特性に当たるレバーだけを選ぶ、FinOpsの単価設計です。要点は次の3つです。
第一に、レバーは2つのレイヤーで考えます。即時性・再利用性・定型性から引く適性レバー（プロンプトキャッシュ・モデル蒸留・Intelligent Prompt Routing）と、即時性で選ぶ課金モード（サービスtier4種とバッチ推論）です。第二に、バッチ推論はtierの一種ではなく独立モードであり、プロンプトキャッシュとは併用できません。この区別と排他を取り違えないことが設計の前提です。第三に、効き幅はいずれも公式の最大値であり、プロンプトキャッシュは再利用が不足すれば純損になり得ます。効き幅を鵜呑みにせず、ヒット率・最小トークン・TTL・事前evalで自分のワークロードに当てはめて判断します。
推論単体ではなく、RAG構成全体のインフラを含めた費用試算が必要な場合は、構成全体のTCOを扱う関連記事をあわせてご参照ください。安いモデルや蒸留モデルへ落とす判断を品質面で担保する評価の手順や、単価設計をADR（設計判断の記録）として言語化する考え方は、それぞれの専門記事に譲ります。推論コストの最適化は、効き幅の大きさで選ぶのではなく、ワークロード特性に当たるかどうかで選ぶことが、過剰投資を避ける近道です。
出典
- Amazon Bedrock コスト最適化（公式） — https://aws.amazon.com/bedrock/cost-optimization/
- Amazon Bedrock プロンプトキャッシュ（公式） — https://aws.amazon.com/bedrock/prompt-caching/
- プロンプトキャッシュ（公式ドキュメント・最小トークン／TTL／併用制約） — https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html
- サービスtier（Reserved／Priority／Standard／Flex・公式ドキュメント） — https://docs.aws.amazon.com/bedrock/latest/userguide/service-tiers-inference.html
- バッチ推論（公式ドキュメント） — https://docs.aws.amazon.com/bedrock/latest/userguide/batch-inference.html
- Intelligent Prompt Routing GA（What’s New・2025年4月） — https://aws.amazon.com/about-aws/whats-new/2025/04/amazon-bedrock-intelligent-prompt-routing-generally-available
- Intelligent Prompt Routing（公式ドキュメント） — https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-routing.html
- Amazon Bedrock 料金 — https://aws.amazon.com/bedrock/pricing/