LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Amazon Bedrockのトークン課金と3つの推論モード

Amazon Bedrock（アマゾン ベッドロック）とは、AWSが提供するフルマネージドの生成AI基盤モデル（Foundation Model）APIサービスであり、Claude・Nova・Llama・Mistralなど複数のモデルをAPIで利用できるプラットフォームです。サーバーの管理やモデルのホスティングを自前で行う必要がなく、APIを呼び出すだけでLLM（大規模言語モデル）の推論機能を使えます。

コストの観点で重要な特徴は、料金が「入力トークン数」と「出力トークン数」に応じて従量課金される点です。送るプロンプトの文字数が多いほど、返ってくる回答が長いほど、費用が積み上がります。この課金構造を理解したうえで、3つの推論モードを使い分けることが費用管理の起点となります。

推論モードを適切に選ぶことが、すべての最適化施策の前提です。用途ごとのモード選択を次のセクションで整理します。

オンデマンド・プロビジョンドスループット・バッチ — 用途別の料金モード選択

Amazon Bedrockには、利用規模や用途に応じて3つの推論モードが用意されています。モード選択を誤ると、利用量に見合わないコストが発生します。

オンデマンド推論：従量課金で小〜中規模に適する

オンデマンド推論は、APIを呼び出した回数とトークン量に応じてその都度課金されるモードです。事前のコミットメントが不要で、利用開始のハードルが低い点が特徴です。

利用量が安定していない初期フェーズや、想定外のスパイクが発生しやすいケースでは、このモードが選ばれます。一方で、大量の推論を継続的に処理する用途では、後述のプロビジョンドスループットより割高になる場合があります。

プロビジョンドスループット：コミット割引で大量利用向き

プロビジョンドスループット（Provisioned Throughput）は、一定のスループット容量をあらかじめ確保し、時間単位で課金されるモードです。AWSドキュメントによると、コミット期間として1か月または6か月を選択でき、期間が長いほど時間単価が割安になります^*1。

スループットの単位はModel Unit（MU）と呼ばれ、1MUが処理できる入力・出力トークン量が定義されています。カスタムモデル（モデル蒸留後のモデル）を本番利用する際にも、このプロビジョンドスループットの購入が必要です^*1。

バッチ推論：大量リクエストを非同期で割安処理

バッチ推論（Batch Inference）は、複数のプロンプトをまとめて非同期に処理するモードです。入力ファイルをAmazon S3に配置してジョブを投入し、処理完了後にS3から結果を取得します。AWSドキュメントには、大規模なデータセットに対するモデル推論のパフォーマンスを向上させる用途に適すると記載されています^*2。

リアルタイム性を必要としないバッチ処理（レポート生成・一括翻訳・データ分類など）に向いており、オンデマンド推論と比べて料金が割安です。なお、バッチ推論ではプロビジョンドモデルや、ツール呼び出し（関数呼び出し）はサポートされません^*2。

プロンプトキャッシング — 同一コンテキストの再利用でキャッシュ読込料金を削減

プロンプトキャッシング（Prompt Caching）は、長くて繰り返し使われるプロンプトの一部をキャッシュに保存し、次回以降のリクエストでキャッシュから読み込むことで、入力トークンの再処理コストを削減する機能です。AWSドキュメントには、キャッシュから読み込まれたトークンは通常の入力トークン料金より低い料金で課金されると記載されています^*3。

典型的な活用例として、ユーザーがドキュメントをアップロードして質問するチャットボットが挙げられます。毎回のリクエストでそのドキュメントをモデルに再読み込みさせると、入力トークンが増大します。プロンプトキャッシングを使うと、同じドキュメントを2回目以降に読み込む際はキャッシュヒットとなり、割引レートが適用されます^*3。

キャッシュの仕組みとTTL

キャッシュは「キャッシュチェックポイント」と呼ばれるマーカーを設定することで機能します。チェックポイントより前の静的なプロンプト部分がキャッシュ対象となります。モデルによってキャッシュに必要な最小トークン数が異なり、Claude 3.7 Sonnetでは1,024トークン以上、Claude Opus 4.5・Haiku 4.5・Sonnet 4.5では4,096トークン以上が必要です^*3。

キャッシュのTTL（有効期間）はデフォルト5分で、対応モデルでは1時間のTTLも選択できます。キャッシュ期間内にキャッシュヒットがなければ期限切れとなります^*3。なお、プロンプトキャッシングはオンデマンド推論エンドポイントでのみ利用可能で、バッチ推論APIはサポートされません^*3。

対応モデルと注意点

2026年6月時点でプロンプトキャッシングに対応しているモデルには、Claude Opus 4・Claude Opus 4.5・Claude Sonnet 4.5・Claude Haiku 4.5・Claude 3.7 Sonnet・Claude 3.5 Sonnet v2が含まれます^*3。また、Amazon NovaシリーズはAPIの明示的な設定なしに自動的なプロンプトキャッシングが適用され、さらにコスト削減をより安定的に実現するためのExplicit Prompt Cachingもサポートされています^*3。

キャッシュ書き込み時は通常の入力トークン料金より高い料金が発生するモデルもあるため、利用頻度とコスト削減効果のバランスを設計段階で確認する必要があります。

インテリジェントプロンプトルーティング — モデル切替判断を自動化してコストと品質を両立

インテリジェントプロンプトルーティング（Intelligent Prompt Routing）は、同一モデルファミリー内の複数モデルに対して単一のエンドポイントを提供し、リクエストごとに最適なモデルへ動的にルーティングする機能です。AWSドキュメントには、各リクエストに対して各モデルの応答品質を予測し、応答品質とコストの最適なバランスのモデルを選択すると記載されています^*4。

「どのモデルを使うか」を固定的に決めるのではなく、「どの条件でモデルを切り替えるか」を設計するアプローチがコスト最適化の要点です。シンプルな問い合わせには安価な軽量モデルを割り当て、複雑な推論が必要なリクエストのみ高精度な大型モデルに回す、という設計が実現できます。

デフォルトルーターと設定済みルーターの違い

プロンプトルーターには、AWSが用意したデフォルトルーターと、ユーザーが独自設定する設定済みルーターの2種類があります。デフォルトルーターはAnthropicとMetaファミリーのモデル向けに事前設定されており、設定なしですぐに試せます^*4。

設定済みルーターでは、「フォールバックモデル」と「応答品質差」（Response Quality Difference）を定義します。例えば、フォールバックモデルをClaude Haiku（安価）に設定し、品質差が10%以上になる場合のみClaude Sonnet（高精度）に切り替える、という設定が可能です^*4。

対応モデルと制約

2026年6月時点でインテリジェントプロンプトルーティングに対応しているモデルには、Claude 3 Haiku・Claude 3.5 Haiku・Claude 3.5 Sonnet・Claude 3.5 Sonnet v2（Anthropicファミリー）、Llama 3.1 8B/70B・Llama 3.2 11B/90B・Llama 3.3 70B（Metaファミリー）、Amazon Nova Lite/Proが含まれます^*4。

なお、現在のインテリジェントプロンプトルーティングは英語プロンプトに最適化されており、独自の性能データに基づいたルーティング調整はできません^*4。日本語プロンプトを主体とする業務用途では、ルーティング効果が英語利用時と異なる可能性があります。

モデル蒸留・RAG・出力制御 — アーキテクチャ設計で下げる長期コスト

推論モードやキャッシングといった即効性の高い施策に加え、アーキテクチャ設計レベルで長期的なコストを下げる手法があります。

モデル蒸留：大型モデルの知識を小型モデルに転移

モデル蒸留（Model Distillation）は、精度の高い大型モデル（教師モデル）の知識を、小型で安価なモデル（生徒モデル）に転移させてファインチューニングするプロセスです。AWSドキュメントには、特定のユースケースに対して生徒モデルの性能を向上させながら、速度とコスト効率を改善できると記載されています^*5。

具体的な流れは、まず教師モデルに大量のプロンプトを投入して合成データを生成し、そのデータで生徒モデルをファインチューニングします。蒸留後の小型モデルを本番利用するには、プロビジョンドスループットの購入が必要です^*5。

モデル蒸留は一度設定すれば継続的にコスト削減効果が得られますが、教師モデルへの推論コストがファインチューニング時に発生します。特定のドメイン・言語スタイルに特化した業務用途（カスタマーサポート・定型レポート生成など）で効果が高い手法です。

RAGによる不要な文脈の削減

RAG（Retrieval-Augmented Generation：検索拡張生成）は、プロンプトに静的な全文書を含めるのではなく、検索エンジンで関連箇所のみを取得してプロンプトに挿入する手法です。大量のコンテキストをまるごとプロンプトに含めると入力トークンが膨大になりますが、RAGを使えば必要な断片だけを渡せるため、入力トークン量を抑えられます。

Amazon Bedrockでは、ナレッジベース機能（Amazon Bedrock Knowledge Bases）を使ってRAGアーキテクチャを構築できます。社内ドキュメントやFAQなど大量の参照資料がある業務システムでは、RAGの導入でトークンコストを大幅に改善できる可能性があります。

出力トークン制御とプロンプト圧縮

出力トークン量はAPIパラメータ（max_tokens）で上限を設定できます。必要以上に長い回答を生成させないよう、タスクに応じた上限値を明示的に設定することが基本的な対策です。また、プロンプト自体の冗長な記述を取り除く「プロンプト圧縮」も入力トークン削減の手段となります。具体的には、不要な前置き表現や重複する説明を削減し、構造化された簡潔な指示に書き直すことで、同等の精度を保ちながらトークン使用量を減らせます。

Bedrock最適化を内製で進める際の難易度と必要スキル

Amazon Bedrockのコスト最適化は、AWSコンソールで設定を変えるだけで完了するものではありません。適切な施策を選択し、本番環境で安定させるには複数の専門領域にわたるスキルが必要です。

内製に必要な知識と工数

Bedrockコスト最適化の内製化には、次の知識が求められます。AWS SDKとBedrock APIの実装経験、トークン課金の仕組みとメトリクス計測・可視化の設計、プロンプトエンジニアリング（キャッシングを考慮したプロンプト設計・プロンプト圧縮）、モデル蒸留のためのファインチューニング手順、RAGアーキテクチャの設計とナレッジベース管理、の5領域です。

これらをゼロから整備する場合、アーキテクチャ設計だけで複数名が数か月単位の工数を要します。AWS公式の各機能を正しく理解するだけでも、日々更新されるドキュメントのキャッチアップに継続的な時間が必要です。

設計ミスが招くリスク

プロンプトキャッシングの設定を誤ると、意図せずキャッシュミスが続いてキャッシュ書き込み料金だけが積み上がることがあります。プロビジョンドスループットのMU数の見積もりが過剰になれば、使いきれない固定費を支払い続けることになります。バッチ推論のS3権限設定を誤るとジョブが完了せず、再試行コストが発生します。

こうした設計ミスは、開発環境では気づきにくく、本番でトラフィックが増加してから顕在化するケースが多く見られます。発見が遅れるほど無駄なコストが積み上がり、修正工数も大きくなります。

外注パートナー選定で確認すべき3つの要件

Bedrockコスト最適化の設計を外部パートナーに委託する際は、生成AI特有の評価軸で選定することが大切です。一般的なAWS運用支援の経験だけでは、トークン課金特有の設計課題に対応できない場合があります。

要件1：Bedrock API・プロンプトエンジニアリングの実装実績

Bedrock特有のAPIパラメータ（cachePoint・推論プロファイル・バッチジョブ設定）を正しく使った実装経験があるかを確認します。具体的には、プロンプトキャッシングのチェックポイント設計、インテリジェントプロンプトルーティングの設定済みルーター構築、モデル蒸留ジョブの実行管理の経験が評価の基準になります。

LLMをAPI経由で使う開発経験と、Bedrockのコスト最適化機能を実務で使った経験は別物です。提案書やヒアリングでBedrock固有の機能について具体的な説明ができるパートナーを選ぶことが大切です。

要件2：コスト可視化と継続的なモニタリング体制

最適化施策を導入したあと、その効果を継続的に計測できる体制があるかを確認します。AWSコスト管理ツール（AWS Cost Explorer・AWS Budgets）とBedrock固有のメトリクス（キャッシュヒット率・モデル別コスト配分）を連動させたダッシュボード設計が、運用フェーズで重要になります。

初期設定だけを行って運用を引き渡すパターンでは、利用量の変化に応じた追加最適化が滞りやすくなります。月次や四半期単位でのコストレビューを提供できるかを契約前に確認してください。

要件3：元請（プライムベンダー）としての責任範囲の明確化

Bedrockを組み込んだシステム全体（アプリケーション層・API連携・インフラ）を一貫して設計・保守できるかを確認します。生成AI APIのコスト最適化は、アプリケーションのプロンプト設計と不可分であるため、フロントエンド・バックエンド・インフラのそれぞれを分散した複数ベンダーが担当すると、責任の所在が曖昧になりやすくなります。

特に障害発生時やコスト急増時の対応において、元請（プライムベンダー）として窓口を一本化できるパートナーの方が、複数の下請けベンダーに依頼するより問題の切り分けと解決が迅速になります。

まとめ：Bedrockコスト最適化の3つの設計判断

本稿ではAmazon Bedrockのトークン課金を前提に、コスト最適化の施策をAWS公式ドキュメントの情報をもとに整理しました。要点を3つに集約すると次のとおりです。

第一に、推論モードの選択が費用の起点です。小〜中規模はオンデマンド、大量かつ安定利用はプロビジョンドスループット、非同期バッチ処理はバッチ推論と使い分けることで、利用量に見合った料金体系を選べます。

第二に、プロンプトキャッシングとインテリジェントプロンプトルーティングを活用することで、同一コンテキストの再利用コストを削減し、リクエストごとに適切なモデルを選択できます。これらはAWSが提供する機能として利用可能ですが、設計上の注意点（最小トークン数・TTL・英語最適化）を正確に把握したうえで実装する必要があります。

第三に、モデル蒸留・RAG・出力制御はアーキテクチャ設計レベルの施策であり、特定のユースケースで継続的な費用削減効果が期待できます。ただし実装難度が高く、内製化には複数領域の専門スキルが必要です。外注パートナーに設計支援を依頼する場合は、Bedrock固有の実装経験・コスト可視化体制・元請としての責任範囲の3点を選定基準にしてください。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「Increase model invocation capacity with Provisioned Throughput in Amazon Bedrock」（2026年確認）
2. *2　出典：Amazon Web Services「Process multiple prompts with batch inference」（2026年確認）
3. *3　出典：Amazon Web Services「Prompt caching for faster model inference」（2026年確認）
4. *4　出典：Amazon Web Services「Understanding intelligent prompt routing in Amazon Bedrock」（2026年確認）
5. *5　出典：Amazon Web Services「Customize a model with distillation in Amazon Bedrock」（2026年確認）

Tweet