Amazon Bedrock 上で、基盤モデル (FM) の一種である大規模言語モデル (LLM) の利用が拡大するにつれ、コストは増加していきます。しかし、従来のクラウドコスト管理ツールは、いくら使ったかは教えてくれても、なぜそのコストが発生したのかまでは教えてくれません。請求データと運用インサイトとの間に生じるこのギャップの中で、コストの非効率は見過ごされてしまいます。LLM コストの最適化には、どの開発者、どのモデル、どのオペレーションが支出を生み出しているのかを可視化する必要があります。

本記事では、AWS ネイティブツール (Kiro、Amazon Q Developer)、開発者向けツール (Claude Code、Cursor)、そしてカスタムアプリケーションのいずれにも対応する、Amazon Bedrock 向けの 3 層のオブザーバビリティフレームワークについて学びます。AWS Identity and Access Management (IAM) と AWS Cost and Usage Report (CUR) を用いたネイティブな請求の帰属を出発点として、各層の実装方法を解説します。また、コスト最適化において最も重要となるメトリクスと、ワークロードに応じて支出を 30〜50% 削減できる 5 つの具体的なレバー (施策) についても説明します。

課題：LLM 支出における可視性のギャップ

多くの場合、まずは Amazon Bedrock の組み込みオブザーバビリティから始めることになります。呼び出し回数とトークン消費量を示す Amazon CloudWatch メトリクス、支出の集計と可視化のための CUR および AWS Cost Explorer、しきい値アラートのための AWS Budgets です。これらのツールは不可欠ですが、答えられるのはインフラストラクチャレベルの問いに限られます。

Amazon Bedrock の利用がチームやユースケースを跨いで拡大するにつれ、インフラストラクチャレベルのデータだけでは不十分になります。重要となる問いは、より運用レベルへシフトしていきます。

1. どの開発者・チームが最も多くのトークンを消費しているか？
2. 各タスクに適切なモデルが割り当てられているか？定型的な作業をプレミアムモデルが処理していないか？
3. プロンプトキャッシュは、どの程度効果を発揮しているか？
4. 失敗したリクエストによって、どれだけの支出が無駄になっているか？
5. セッション、コミット、プルリクエストあたりのコストはいくらか？

拡張テレメトリは、インフラストラクチャ向けツールでは本来捕捉できない、組織的なコンテキストを提供します。

フレームワーク：LLM オブザーバビリティの 3 つの層

LLM コストのオブザーバビリティは 3 つの層で構成され、各層は前の層の上に積み上がっていきます。

レイヤー 1：Amazon Bedrock のネイティブメトリクス (まずはここから)

Amazon Bedrock がネイティブに提供する、基盤となるオブザーバビリティを有効化します。Amazon Bedrock の CloudWatch メトリクスは、モデルごとの呼び出し回数、レイテンシー、トークン使用量を追跡します。また、Amazon Bedrock は最近、IAM ベースのコスト配分機能を発表しました。これは CUR 2.0 の機能で、各呼び出しを実行した IAM アイデンティティに支出を帰属させることができます。アプリケーション推論プロファイルに付与したコスト配分タグ (呼び出し元のアイデンティティに関係なく、チームやプロジェクトに支出を帰属させる) と、しきい値ベースのアラートを備えた AWS Budgets を組み合わせることで、カスタムパイプラインを構築することなく請求レベルの可視性が得られます。

このレイヤーを有効化するには：

• ユーザー単位のコスト帰属：IAM コンソールで IAM ユーザーとロールに、組織構造に合わせた属性 (チーム、プロジェクト、コストセンター) のタグを付与し (図 1 参照)、それらのタグを AWS Billing and Cost Management コンソールでコスト配分タグとして有効化します (図 2 参照)。CUR 2.0 のデータエクスポートを作成し、「Include caller identity (IAM principal) allocation data」を選択すると、ユーザー単位・ロール単位の Amazon Bedrock 支出を CUR と Cost Explorer 上で確認できるようになります。実装の詳細については、コスト配分に IAM プリンシパルを使用するを参照してください。
• チーム / プロジェクト単位のコスト帰属：アプリケーション推論プロファイルを作成し、組織構造 (チーム、プロジェクト、環境) に合わせたコスト配分タグを割り当てます。それらのタグを AWS Billing and Cost Management コンソールで有効化します。Amazon Bedrock の支出に対して、しきい値ベースのアラートを備えた AWS Budgets を設定します。

図 1： IAM コンソールで IAM ロールにタグを適用する (team、cost-center、project、environment)

図 2：AWS Billing and Cost Management コンソールでコスト配分タグを有効化する

レイヤー 2：モデル呼び出しのログ記録 (深さを加える)

モデル呼び出しのログ記録は、すべての Amazon Bedrock API 呼び出しについて、リクエストデータ、レスポンスデータ、メタデータという全体像を記録します。これにより、「何トークン使ったか」から「そのトークンには何が含まれ、なぜ使われたのか」へと踏み込めるようになります。

Amazon Bedrock は、すべての API 呼び出しを Amazon Simple Storage Service (Amazon S3) または Amazon CloudWatch Logs に記録できます。Bedrock の設定で有効化すると、各ログエントリにはモデル ID、リクエスト所要時間、トークン内訳などのメタデータが含まれます。この生のシグナルを活用することで、Amazon Athena と Amazon Quick Sight を用いた分析パイプラインを構築でき、モデル・チーム・期間を横断した使用パターンを可視化できます。

モデル呼び出しのログ記録を設定するには：

1. Amazon Bedrock コンソールまたは API でモデル呼び出しのログ記録を有効化します (図 3 参照)。
2. ログの送信先を選択します：長期的な分析には Amazon S3、リアルタイムのクエリには CloudWatch Logs を使用します。
3. Amazon Quick Sight または CloudWatch でダッシュボードを構築し、モデル・チーム・期間ごとのトークン使用量を可視化します。

図 3：Amazon Bedrock の設定でモデル呼び出しのログ記録を有効化する

実践的な実装方法については、Monitor and optimize your Amazon Bedrock usage with Amazon Athena and Amazon QuickSight を参照してください。

レイヤー 3：アプリケーションレベルのテレメトリ (最適化を引き出す)

実行可能なコスト最適化のインサイトが得られるのは、この層です。OpenTelemetry (OTEL) は、Amazon Bedrock のネイティブメトリクスでは提供できない組織的コンテキスト、つまり「誰が、何を、どのように、どれだけ効率的に使っているか」といった情報を付加します。レイヤー 1 と 2 は Amazon Bedrock が「何をしているか」を示し、レイヤー 3 は「なぜ」を明らかにします。

OpenTelemetry の計装は、Amazon Bedrock 自体ではなく、クライアントアプリケーション側に実装します。レイヤー 3 の可視性を実現する方法は、チームが使用するクライアントによって異なります。

OpenTelemetry は、LLM クライアントとモデルプロバイダーを横断して機能するオープン標準です。開発者単位・チーム単位のコスト帰属、セッションレベル・オペレーションレベルの粒度、そして多次元分析のための豊富な属性を提供します。Claude Code は、実践的なリファレンス実装として役立ちます。組み込みの OpenTelemetry サポートを備えており、拡張 LLM テレメトリが実際にどのようなものかを示す優れた例です。カスタムアプリケーションの場合は、OpenTelemetry SDK と ADOT を用いて、同等のメトリクスを計装します。

コスト最適化における主要メトリクス (Claude Code 組み込み)：

• claude_code.token.usage：セッションごとの消費トークン (直接的なコストドライバー)
• claude_code.cost.usage：セッションごとのドルコスト (即時の支出可視化)
• claude_code.active_time.total：アクティブなセッション時間。アイドルセッションの特定に使用
• claude_code.commit.count / claude_code.pull_request.count：ROI メトリクス (アウトプット単位あたりのコスト)

より深いインサイトを得るための主要イベント (Claude Code 組み込み)：

• claude_code.api_request：コスト、モデル、レイテンシー、トークンの内訳 (入力/出力/キャッシュ)。高コストな操作の特定とキャッシュ効率の測定
• claude_code.api_error：エラーメッセージ、ステータスコード、リトライ回数。失敗による無駄な支出の定量化
• claude_code.tool_result：実行時間、成功/失敗。どの操作が最もコストを生んでいるかを特定

データを切り分けるための標準属性：

• model：モデル別のコスト比較とモデル切り替えの判断
• type (input/output/cacheRead/cacheCreation)：キャッシュ効率の分析
• tool (Edit/Write/Bash/Read)：操作タイプ別のコスト
• language：プログラミング言語のコンテキスト別のコスト

Claude Code の実装については、Guidance for Claude Code with Amazon Bedrock を参照してください。

AWS ネイティブクライアント (Kiro、Amazon Q Developer) の場合は、CloudTrail データイベントと Athena クエリを使用することで、同等のユーザー単位・機能単位の可視性を実現できます。 Exploring Telemetry Events in Amazon Q Developer を参照してください。

テレメトリを原動力とする 5 つのコストレバー

これら 3 つの層が整うと、5 つの具体的なコスト最適化レバーを実行できます。

1. モデルの切り替え：大きな効果を持つレバー (モデル間の価格差に基づき 30〜50% の削減可能性) 

model 属性をみれば、どのモデルがどのタスクを処理しているかがわかります。コードの整形や単純な編集といった定型作業によって、プレミアムモデルのトークン消費が多くなっていないか確認しましょう。プレミアムモデルは複雑な推論のために温存し、定型タスクにはより小型で安価なモデルを使用するように、ルーティングルールを設定します。model 属性を継続的にモニタリングして、定着度を測定し、削減効果を検証します。例えば、Claude Sonnet 4.5 は 100 万トークンあたり $3/$15 (入力/出力) であるのに対し、Claude Haiku 4.5 は $1/$5 で、定型タスクでは約 67% の削減になります。30〜50% という試算は、すべてのタスクを小型モデルにルーティングできるわけではないことを前提とした、控えめなブレンド値です。

2. キャッシュ効率：冗長な処理を削減 (対応モデルの場合、キャッシュされたトークンで最大 90% のコスト削減と最大 85% のレイテンシー削減) 

type 属性はトークンを input、output、cacheRead、cacheCreation に分解します。cacheRead の比率が高いということは、コンテキストを再処理するのではなく再利用できていることを意味し、コストと推論レイテンシーの両方を削減します。cacheRead 比率が低い場合は、プロンプトやワークフローを再構成する機会があるというシグナルです。チーム横断でキャッシュヒット率を分析し、効率の高いチームのベストプラクティスを共有しましょう。この削減効果は Amazon Bedrock の料金に基づきます。対応モデルでは、キャッシュされた入力トークンは標準の入力トークンと比べて最大 90% 安く課金されます (例えば、Amazon Bedrock 料金ページによると、Claude Sonnet 4.6 では 100 万トークンあたり $0.30 対 $3.00)。レイテンシーの削減は、キャッシュ済みのプロンプトプレフィックスの再計算を省略することで得られます。

3. エラーによる無駄：失敗に対する支払いをやめる

api_error イベントで捕捉されるすべての失敗リクエストは、生産的なアウトプットをまったく生まずにトークンを消費します。高いエラー率や繰り返しのリトライは、対処可能な改善機会を示すシグナルです。エラー率のしきい値に対して CloudWatch アラームを設定し、根本原因を調査しましょう。一般的な対策には、プロンプトエンジニアリングの改善、入力検証、レート制限の管理があります。

4. ツールと操作の最適化：何がコストを生んでいるかを知る

tool_result と tool_decision イベントは、どの操作が最も時間とトークンを消費しているかを明らかにします。より効率的に処理できる高コストな操作や、無駄な計算を示す高い拒否率を特定します。コストの上位を占める操作を特定し、最適化・バッチ化・より安価なモデルへの移行が可能かどうかを評価しましょう。

5. 開発者単位・チーム単位の可視性：アカウンタビリティを実現

まずは、IAM ベースのコスト配分から始めます。これにより、Amazon Bedrock の支出を IAM ユーザーおよびロール別に、CUR や Cost Explorer にて請求レベルで直接帰属させることができるようになります。カスタムパイプラインは不要です。その上に OTEL 属性を重ね、運用コンテキスト、すなわちセッション・コミット・プルリクエストあたりのコスト情報を付加します。目的は、プロンプトエンジニアリングの指針やモデル切り替えの恩恵を受けられるワークフローを特定するなど、チームおよび個人レベルで最適化の機会を可視化することです。

アラートの設定

拡張テレメトリが CloudWatch に流れ込む状態になったら、段階的なアラートを設定します。

• Info：日次支出がベースラインを 20% 超過 → ダッシュボード通知
• Warning：時間あたりのトークン消費が 95 パーセンタイル (P95) を超えてスパイク → Amazon SNS 経由でチームリードに通知
• Critical：エラー率が 15 分間継続して 10% を超過 → オンコール担当を呼び出し、無駄な支出を調査
• Budget：月次の予測支出がしきい値を超過 → AWS Budgets アクションをトリガーし、モデル選択を見直し

開始方法：段階的アプローチ

3 つの層を一度に実装する必要はありません。

フェーズ 1 (第 1 週)：レイヤー 1 を有効化：ユーザー単位の請求帰属のための IAM コスト配分、Amazon Bedrock のネイティブメトリクス、コスト配分タグ、予算アラートを設定し、直ちにベースラインの可視性を確保します。

フェーズ 2 (第 2〜3 週)：レイヤー 2 を有効化：モデル呼び出しのログ記録を有効化し、Amazon Quick Sight または CloudWatch で初期ダッシュボードを構築して、使用パターンを把握します。

フェーズ 3 (第 3〜4 週)：レイヤー 3 を有効化：LLM クライアントへの OpenTelemetry を計装します。パイロットチームから始めてメトリクスを検証し、その後組織全体に展開します。

継続的な取り組み：ダッシュボードを週次でレビューして、5 つのコストレバーに基づいて行動し、使用パターンを学びながらアラートのしきい値を調整していきます。

図 4：モデル呼び出しのログ記録のアーキテクチャ

テレメトリの先へ：補完的な戦略

Amazon Bedrock のインテリジェントプロンプトルーティングは、単一のサーバーレスエンドポイントを提供し、リクエストを同一モデルファミリー内の異なる基盤モデル (FM) にルーティングして、応答品質とコストの両方を最適化します。インテリジェントプロンプトルーティングは、精度を損なうことなく最大 30% のコスト削減を実現できます。テレメトリへの投資は、ルーティングが正しい判断をしているかどうかの検証に役立ちます。ダッシュボードを活用して、ルーティング有効化の前後でリクエストあたりのコストを比較し、ルーティングによる削減効果が最も大きいプロンプトのカテゴリを特定して、ルーティングが出力品質に影響を与えているケースを検出しましょう。

Amazon Bedrock はほかにも、Model Distillation (AWS のベンチマークに基づくと、精度低下 2% 未満で最大 75% のコスト削減)、バッチ推論 (時間的制約のないワークロードで最大 50% の割引)、予測可能で持続的なワークロード向けの専用キャパシティを提供する Reserved Tier、トラフィックバーストをコスト効率よく処理するクロスリージョン推論、ベクトルストレージのコストを最大 90% 削減する S3 Vectors を用いた Knowledge Bases を提供しています。さらに詳しくは、Effective cost optimization strategies for Amazon Bedrock、Amazon Bedrock で基盤モデルを使用する際のコスト最適化、FinOps for AI Playbooks を参照してください。

まとめ

Amazon Bedrock 上で LLM のコストを最適化するには、十分な情報に基づく意思決定を可能にするテレメトリ基盤の構築が必要です。ネイティブの IAM ベースコスト配分が請求の帰属を担い、拡張テレメトリが運用インサイトをカバーすることで、フルスタックが揃います。Amazon Bedrock のネイティブメトリクス、モデル呼び出しのログ記録、OpenTelemetry 計装を積み重ねることで、本当に重要な問いに答えるための可視性が得られます。すなわち、「このタスクにはどのモデルを使うべきか？」「キャッシュは効果的に機能しているか？」「エラーによってどれだけ損失が出ているか？」といった問いです。

このフレームワークは、Amazon Bedrock 上で動作する LLM クライアントに適用できます。OpenTelemetry をネイティブにサポートする Claude Code、CloudTrail テレメトリを用いる Kiro や Amazon Q Developer、BYOK を利用する Cursor、ADOT で計装したカスタムアプリケーション、いずれにも対応します。テレメトリを実現する経路はクライアントによって異なりますが、3 層のフレームワークと 5 つのコストレバーは一貫しています。

まずは基本から始め、段階的に深さを加え、テレメトリに最適化の意思決定を導かせましょう。

Amazon Bedrock についてさらに学ぶには、Amazon Bedrock ドキュメントを参照してください。CloudWatch のメトリクスとモニタリングについては Amazon CloudWatch ドキュメントを、コスト管理ツールについては AWS Cost Explorer と AWS Budgets を参照してください。

次のステップ

フレームワークを実装してベースラインの可視性を確保したら、テレメトリから得られるインサイトに基づいて優先順位を付けましょう。

• 定型タスクへの支出が多い？ → インテリジェントプロンプトルーティングを検討
• 繰り返しのプロンプトを伴う一貫したワークロードパターン？ → プロンプトキャッシュと Model Distillation を評価
• 時間的制約のないワークロード？ → バッチ推論を実装して 50% の割引を実現

始める準備はできましたか？ 今すぐ AWS Billing and Cost Management コンソールで IAM ベースのコスト配分を有効化しましょう。テレメトリダッシュボードを週次でレビューし、5 つのコストレバーに基づいて行動し、使用パターンを学びながらアラートのしきい値を調整していきましょう。

翻訳はテクニカルアカウントマネージャーの西村が担当しました。原文はこちらです。