Amazon Bedrockは、処理した入力トークンと出力トークンに応じて課金され、コストはモデル、料金モード、workloadsのパターンによって変動します。オンデマンドは予測しづらい用途や少量利用に適しており、プロビジョンドスループットは安定した大規模本番workloadsに保証されたキャパシティを提供します。バッチ推論はリアルタイム性が不要なジョブで最大50%の割引が受けられます。モデルのカスタマイズやファインチューニングでは、トレーニング、ストレージ、推論にそれぞれ別建ての料金が発生します。AIのコストは従来のコンピュートとは挙動が異なるため、CloudOpsチームはBedrockの支出を予測可能に保つために、トークンレベルの可視性と自動化された予算管理を必要とします。
従来のクラウド予算管理は、インスタンス時間、ストレージ容量、ネットワーク下り通信といった予測しやすい単位を前提に組み立てられてきました。しかしAmazon Bedrockはその枠組みに収まりません。請求額は、ユーザーが入力する文字量、プロンプトの冗長さ、選んだ基盤モデル、そして失敗したコールをアプリケーションが何度リトライしたかによって変わります。Claude 3 HaikuではなくClaude 3 Opusを選ぶといった一つのアーキテクチャ判断だけで、スケール時のコストが一桁変わることもあります。
これはBedrockへの批判ではありません。多くのCloudOpsチームやFinOpsチームがこれまで向き合ってこなかった、推論ベース料金ならではの構造的な現実です。AI機能を作ったエンジニアはトークンを理解しています。一方で、クラウド予算を承認する立場の人は、おそらく理解していません。このギャップを埋めることは急務です。FinOps Foundationの「2026 State of FinOps」レポートによれば、AI支出を積極的に管理している組織は98%にのぼり、2年前のわずか31%から急増しています。コストの可視性は「あれば便利」なものではなく、AIの成長を議論するための前提条件なのです。
本ガイドでは、Bedrockの料金体系の仕組み、請求が届く前にコストを試算する方法、そしてAI支出を説明可能な状態に保つためのモニタリングとコントロールの設計について解説します。
Amazon Bedrockの料金体系の仕組み
Amazon Bedrockは推論、つまり基盤モデルにプロンプトを送信して応答を受け取るプロセスに対して課金されます。料金の基本単位はトークンで、おおよそ4文字または単語の4分の3に相当するテキストの塊です。すべてのリクエストには入力トークン(プロンプト、システムメッセージ、会話履歴など)と出力トークン(モデルの応答)が含まれ、それぞれ異なる単価で課金されます。
Bedrockのコストがコンピュートよりも予測しづらいのは、トークン量が一定でないためです。2文の質問しか書かないユーザーは、3,000語の文書を貼り付けるユーザーよりも入力トークンを大幅に少なく消費します。「簡潔に要約して」と依頼するアプリケーションは、詳細な分析を求めるアプリケーションよりも出力トークンが少なくなります。こうしたばらつきが日々何千ものリクエストに及ぶと、適切な計測なしに予算を予測するのは極めて困難になります。
状況をさらに複雑にする要因が二つあります。第一に、多くのモデルでは出力トークンの方が入力トークンよりも高額です。これは、テキストの生成が処理よりも計算負荷が高いためです。プロバイダーによって扱いは異なり、入力と出力を同単価にしているモデルもあれば、出力に大幅に高い単価を設定しているモデルもあります。第二に、モデル選択がトークン単価に劇的な影響を与えます。同じファミリー内でも、軽量モデルは100万トークンあたりの料金がフロンティアモデルのほんの一部で済みます。分類タスクに最適なモデルが複雑な推論タスクには不向きであることはよくあり、その逆も然りです。コストを考慮せず性能だけでモデルを選ぶことは、Bedrockで無駄な支出が発生する最も一般的な原因の一つです。
Amazon Bedrockの料金モデルとレート構造
Bedrockには主に3つの料金モードがあります。オンデマンド、プロビジョンドスループット、バッチ推論です。それぞれ異なるworkloadsプロファイルに適しており、これらのトレードオフを理解することはコスト管理と運用の信頼性の両面で土台となります。
料金モード
支払い方法
コミットメント
レイテンシ
適した用途
オンデマンド
処理トークン単位
なし
変動あり、ピーク時にスロットリングのリスク
バースト型、実験用、または少量のworkloads
プロビジョンドスループット
モデルユニットあたりの固定時間料金
1か月または6か月
保証あり、スロットリングなし
大規模で安定したworkloads、カスタムモデルでは必須
バッチ推論
トークン単位(オンデマンド比で最大50%割引)
なし
非同期、リアルタイム不可
文書処理、夜間ジョブ、非同期エンリッチメントパイプライン
基盤モデル向けオンデマンド料金
オンデマンドはデフォルトの料金モードです。処理した1,000トークン単位で支払い、前払いコミットメントも最低利用額もありません。探索的、バースト的、あるいはまだキャパシティ予約を正当化できるほど予測可能でないworkloadsに最適です。
オンデマンドの運用上のリスクはスロットリングです。AWSは基盤モデルへのアクセスに同時実行数の制限を設けており、需要のピーク時にはリクエストがキューに入ったり失敗したりすることがあります。社内ツールや影響度の低いアプリケーションであれば許容できるトレードオフですが、レイテンシ要件のある顧客向け機能では受け入れられません。
トークン単価はモデルファミリーや世代によって大きく異なります。たとえばBedrock上のAnthropic Claudeシリーズでは、軽量モデルは同ファミリーのフロンティアモデルと比べて100万トークンあたりの料金が一桁安いこともあります。多くのモデルでは入力トークンと出力トークンで単価が異なりますが、同一料金にしているプロバイダーもあります。利用可能な最高性能モデルではなく、タスクに見合ったモデルを選ぶことは、チームが下せるコスト判断の中で最もレバレッジの効くものです。レートや利用可能なモデルバージョンは頻繁に更新されるため、モデル選定戦略を確定する前に必ずAWS Bedrock料金ページで最新のレートを確認してください。*
プロビジョンドスループットの料金オプション
プロビジョンドスループットは、推論版のリザーブドインスタンスのような仕組みです。モデルユニットを購入すると、それぞれが毎分の特定トークンスループットを保証し、そのキャパシティを使うかどうかに関係なく固定の時間料金が発生します。コミットメント期間は1か月または6か月で、長期契約ほど有利なレートが適用されます。
プロビジョンドスループットの財務的な妥当性は、利用率次第です。営業時間中に一定のボリュームでworkloadsが稼働する場合、同じスループットレベルで比較すれば固定時間料金がオンデマンドよりも有意に安くなります。とはいえコミットメントは現実です。未使用のプロビジョンドキャパシティでも、フル稼働時と同じ料金がかかります。ピーク負荷を見越してプロビジョニングし、平均稼働率30%で運用しているチームでは、節約にはなりません。
また、プロビジョンドスループットはカスタムモデルやファインチューニングモデルにとって唯一の推論オプションでもあります。ドメイン適応した基盤モデルをデプロイする予定なら、ボリュームの多寡に関係なくプロビジョンドスループットが必須となります。
モデルカスタマイズとファインチューニングのコスト
Bedrock上で基盤モデルをファインチューニングすると、トレーニング、ストレージ、推論という3つのコストイベントが発生します。トレーニングコストは、データセット全体で処理されたトークン数とエポック数に基づきます。トレーニング後、カスタムモデルはストレージに保管され、月額料金がかかります。ファインチューニング済みモデルを稼働させるにはプロビジョンドスループットが必要で、長期コミットメントなしでも最低1モデルユニットが求められます。
カスタマイズに踏み切る前に、まずは縮小データセットでProof of Conceptを実施し、性能向上が追加コストに見合うかを検証すべきです。大規模モデルの能力をより小さく高速なモデルに圧縮するモデル蒸留は、長期的な推論コストを下げる手段になり得ます。ただし蒸留モデルにも独自のトレーニングコストがかかり、デプロイにはやはりプロビジョンドスループットが必要です。
Amazon Bedrockのコストを計算・試算する方法
正確なコスト試算には、漠然とした想定から実測トークン量への移行が欠かせません。「APIコール数」を起点にBedrockの支出を予測しているチームは、見込みを外します。コール数よりも、コールあたりのトークン数と入出力比のほうがはるかに重要です。
入力・出力トークン料金の計算
基本式はシンプルです。月額コスト = 入力トークン数 × 入力トークン単価 + 出力トークン数 × 出力トークン単価(いずれも100万トークン単位)。難しいのは、本番データが存在しない段階でこれらのトークン量を正確に見積もることです。
まずアプリケーションのプロンプト構成を確認しましょう。500トークンのシステムプロンプトは、リクエストのたびに毎回課金されます。クエリごとに2,000トークンのコンテキストを差し込むRAG(検索拡張生成)構成では、その分のコストが呼び出しごとに乗ってきます。リリース前にプロンプトテンプレートを棚卸しし、Bedrockのトークナイザーかモデル固有のカウンターでトークン数を計測してください。
出力の見積もりでは、アプリケーションがモデルに何を生成させているかを分析します。単一回答の分類タスクは、対話的な応答や長文コンテンツに比べて出力トークン数がはるかに少なくなります。代表的なリクエストのサンプルを用意し、実際の入力・出力トークン数を計測してベースラインとし、想定リクエスト量を掛け合わせて試算します。
具体例を挙げましょう。中位帯の基盤モデルに1日10万件のリクエストを送り、入力トークンの平均が800、出力トークンの平均が400のアプリケーションでは、1日あたり入力8,000万トークン、出力4,000万トークンが発生します。モデルや出力トークン単価によって、1日の総支出は数十ドルから数百ドル、月額では5桁に達することもあります。同一モデルでは入力より高くなりがちな出力トークンのコストが、その大半を占めます。* 利用可能な全基盤モデルの最新レートは、AWS Bedrock料金ページでご確認ください。
コスト試算のツールと手法
AWSはコンソール上でBedrockの料金計算ツールとトークン推定ツールを提供しており、初期モデリングに役立ちます。継続的な可視化にはAWS Cost ExplorerでBedrock支出を確認できますが、リソースタグなしではモデル別、アプリケーション別、チーム別の内訳までは分かりません。タグ付けは必須です。本番にworkloadsを移行する前に、すべてのBedrock呼び出しに対して、コスト配分構造に対応するアプリケーション、チーム、環境の識別子をタグ付けしておきましょう。
DoiT Cloud Intelligenceは、タグ付けやダッシュボードの一歩先を行きます。Bedrock利用全体にわたるAIコストをリアルタイムで可視化し、モデル選択、プロンプトのパターン、利用スパイクが支出をどう動かしているかを細かい粒度で分析します。これにより、静的なレポートでは難しい形で、コストデータをエンジニアリングの意思決定に直結させられます。
異なるアプリケーションが異なる基盤モデルを使うマルチモデル環境では、モデル別にコスト予算とアラート閾値を分けて設定しましょう。フロンティアモデルのコストスパイクと軽量モデルのスパイクは性質がまったく異なり、これを単一の予算枠にまとめてしまうと根本原因の分析が難しくなります。
CloudOpsチームのためのAmazon Bedrockコスト最適化戦略
Bedrockにおける最適化は、一度きりの監査ではなく運用の規律です。AIのworkloadsは急速に進化します。リリース時には効率的だったプロンプトも、ユースケースが広がり、コンテキストウィンドウが拡大し、会話履歴が積み上がるにつれて高コスト化します。Bedrockコストをコントロールできているチームは、コンピュートのライトサイジングと同じ姿勢で取り組んでいます。すなわち、自動化されたシグナルがアクションを駆動する形で、継続的に行うのです。
workloadsに合わせたモデル選定のライトサイジング
モデルのライトサイジングは最もレバレッジの効く最適化手段ですが、多くのチームで取り組みが不足しています。ありがちなのは、ファミリー内で最高性能のモデルを選び、すべてのユースケースに同じものを使い回すパターンです。より良いアプローチは、モデルの能力をタスクの複雑さに合わせることです。
各ユースケースで本当に必要なものは何かを分類しましょう。シンプルな抽出、分類、要約タスクにフロンティアモデルは要りません。より小さく安価なモデルでも、コストのほんの一部で十分正確に処理できます。大規模モデルは、複雑な推論、複数ステップの問題解決、出力品質がビジネス成果に大きく影響するタスクに温存しましょう。
これは厳密にテストしてください。実際のworkloadsを階層化したモデル群で動かし、出力品質を受け入れ基準と照らし合わせて測定し、コスト差を計算します。多くの場合、最上位モデルの10〜20分の1のコストのモデルでも90%の品質基準を達成できます。これは小さな効率化ではなく、スケール時には予算そのものを変えるインパクトを持ちます。
リアルタイム応答が不要なworkloadsには、バッチ推論も検討しましょう。Bedrockのバッチモードは、対応モデルでトークンコストを最大50%削減します。文書処理、夜間分析ジョブ、非同期エンリッチメントパイプラインは有力候補です。トレードオフはレイテンシで、バッチジョブは非同期で実行されるため、即時応答が求められるユーザー向け機能には不向きです。
利用状況のモニタリングと予算管理の実装
トークンレベルのテレメトリなしにBedrockをモニタリングするのは、CPUメトリクスなしにEC2をモニタリングするようなものです。AWS CloudWatchはBedrockの呼び出し回数とエラーを表示してくれます。これに加えて、モデル別、アプリケーション別、環境別のトークン消費量についてカスタムメトリクスを追加しましょう。請求書が届いてからではなく、コストが問題になる前に発火するトークン閾値のアラームを設定してください。
プロンプトキャッシングは、繰り返し利用される静的コンテンツの入力トークン料金を削減します。リクエストごとに変化しないシステムプロンプト、参照ドキュメント、共有コンテキストはキャッシュ可能です。キャッシュされた部分は割引料金で課金されるため、毎回同じシステムプロンプトを送るアプリケーションでは大きな節約になります。このパターンに該当するコンテンツでは、プロンプトキャッシングを有効にしましょう。
クロスリージョン推論は、プライマリリージョンでスロットリングが発生したりキャパシティに達したりした際に、AWSリージョン間で利用可能なモデルキャパシティへリクエストをルーティングします。これにより、別途プロビジョンドスループットのcommitmentsを契約せずとも、負荷時の信頼性を高められます。スロットリング許容度が低い本番workloadsでは検討に値します。
AWS Budgetsの予算管理機能はBedrock支出に対してアラートを出せますが、これは発生済みの支出に対する事後対応です。より強力な手段は、アプリケーション層でのレート制限です。請求に至る前に暴走的な利用を未然に防ぎます。アプリケーション層でユーザー別、セッション別、アプリケーション別のトークン上限を設け、リクエストがBedrock APIに届く前に強制的に適用しましょう。これがモニタリングの「気付き」と本物のガードレールの違いです。
DoiT Cloud Intelligenceは、AI支出に対する自動異常検知を提供し、想定されるコストパターンからの逸脱をリアルタイムで可視化します。これにより、CloudOpsチームは月末締めではなく、数時間以内にコスト問題を把握できます。
Amazon Bedrockのコストを予測可能で説明可能なものに
予測不能なAI支出は、単なる財務問題ではありません。信頼性の問題です。エンジニアリングリーダーが、Bedrockコストが前月比40%増加した要因を説明できないと、財務部門との摩擦が生まれ、AI投資の意思決定が遅れ、AI施策拡大の根拠も揺らぎます。コストの可視性はオーバーヘッドではなく、AIの成長を議論するための前提条件です。
これを正しく実践しているチームは、Bedrockのコスト管理を財務機能ではなくエンジニアリングの実務として扱っています。最初の想定外の請求が届いてからではなく、ビルド時からトークン使用量を計測します。リリース前にコストと品質のトレードオフに照らしてモデル選択を検証します。手動介入なしで支出制限を強制する自動化されたガードレールを構築します。そして、コール単位のコストではなく成果単位のコストを追跡し、エンジニアと経営層の双方が理解できる言葉でROIを示します。
これこそが、Bedrockをコストリスクから持続可能なケイパビリティへと変える運用の成熟度です。
DoiTは、CloudOpsチームとFinOpsチームがAIコストデータと具体的なアクションの間にあるギャップを埋めるお手伝いをします。DoiT Cloud Intelligenceは、モデル別、アプリケーション別、チーム別のBedrock支出をリアルタイムで可視化し、FinOpsの専門家による解釈を必要としない自動アラートと推奨事項を提供します。DoiTはAWS Generative AI Competencyを取得しており、AWS Marketplaceから直接利用可能です。新しいベンダー関係を追加することなく、既存のAWS Procurementワークフローの中でCloud Intelligenceを導入できます。
AIコスト管理のためのDoiT Cloud Intelligenceを見る。Bedrock料金の可視化が、リアクティブからプレディクティブへどのように進化するかをぜひご確認ください。
Amazon Bedrock料金に関するよくある質問
Amazon Bedrockを最も安く使う方法は?
最も安価なアプローチは、可能な限りモデルのライトサイジングとバッチ推論を組み合わせることです。フロンティアモデルではなくタスクに見合った小型モデルを使うだけで、トークン単価を10〜20分の1にまで下げられます。リアルタイム性が不要なworkloadsでバッチ推論を有効にすれば、さらに最大50%の割引が上乗せされます。繰り返し使うシステムプロンプトやコンテキストにプロンプトキャッシングを適用すれば、入力トークン料金もさらに減らせます。まずは、本当に大規模モデルが必要なユースケースを棚卸しし、それ以外は品質基準を満たす最小のモデルへ移行することから始めましょう。
Amazon Bedrockのプロビジョンドスループットとオンデマンド料金はどう違いますか?
オンデマンドは処理したトークン単位で課金され、コミットメントはありません。プロビジョンドスループットは固定時間料金で専用キャパシティを予約し、使用の有無にかかわらず課金されます。プロビジョンドが費用対効果を発揮するのは、利用率が高く安定している場合、つまりオンデマンドのコストが時間コミットメント料金を上回る水準のときです。カスタムモデルやファインチューニングモデルでは、ボリュームに関係なくプロビジョンドスループットが必須となります。可変的なworkloads、初期段階のアプリケーション、利用パターンがまだ予測できないユースケースでは、オンデマンドが適切なデフォルトです。
入力トークンと出力トークンはAmazon Bedrockのコストにどう影響しますか?
入力トークンと出力トークンは別々に料金が設定されており、出力トークンは100万トークンあたりで通常、入力トークンの3〜5倍のコストがかかります。つまり、リクエストごとにモデルにどれだけ生成させるかという出力の冗長さが、請求額に不釣り合いに大きな影響を与えます。詳細な説明、長文コンテンツ、冗長な構造化出力を求めるアプリケーションは、出力トークンコストに大きく寄ります。品質を犠牲にせずに出力長を抑えるプロンプト設計は、それ自体が直接的なコストコントロール手段になります。
Amazon Bedrockは失敗したAPIコールに対しても課金しますか?
Bedrockは正常に処理されたトークンに対して課金します。認証エラーやスロットリングされたリクエストなど、推論が始まる前に失敗するリクエストではトークン料金は発生しません。ただし、推論まで到達してから失敗するコール(例えばコンテキスト長違反による失敗)のリトライでは、部分的に料金が発生する可能性があります。リトライ率と障害モードを監視することは、責任あるコスト管理の一部です。
Amazon Bedrockの支出を追跡・コントロールするのに役立つツールは?
AWS Cost ExplorerはサービスレベルでBedrock支出を表示し、AWS Budgetsはコスト閾値に対してアラートを出せます。CloudWatchは呼び出しメトリクスを取得します。トークンレベルの可視性を得るには、リクエストごとの入力・出力トークン数をアプリケーション側でロギングすることが欠かせません。アプリケーション、チーム、環境ごとのリソースタグ付けにより、コスト配分が可能になります。DoiT Cloud Intelligenceのようなプラットフォームは、Bedrock利用全体にわたるリアルタイムのAIコスト分析と自動異常検知を提供します。