生成AI基盤としてAmazon Bedrock（マネージド生成AI基盤、複数の基盤モデルをAPI経由で呼び出せるサービス）を使う企業が増えている。複数モデルを切り替えながら使える利便性の裏で、月次の請求書に並ぶのは合計金額だけ、という状態が長く続いていた。どのチームがどのモデルをどれだけ呼び出したか、コスト明細だけでは追いにくい。
2026年7月、AWSがData Exports（コストと使用状況データの出力機能）でBedrockのコスト内訳を標準化した。モデル提供者・モデル名・トークン種別・提供形態を属性として揃え、請求データから直接読み取れるようにした。この変更は、生成AI利用コストのブラックボックス化に悩むFinOps担当者・AI基盤運用チームにとって、タグ付け設計とチーム別コスト帰属を組み立て直す転機になる。本稿では新しい可視化の中身と、読者が着手すべき論点を整理する。
予備知識
- FinOps: クラウド費用を財務・開発・運用の三者で協調管理する実務規律。
- Bedrock: AWSのマネージド生成AI基盤。複数の基盤モデルをAPI経由で呼び出せる。
- トークン: LLMが処理するテキストの最小単位。入力トークンと出力トークンで課金単価が異なる。
- CUR（Cost and Usage Report）: AWSの利用量・請求明細データ。Data Exportsで出力形式を柔軟に選べる。
FinOpsの原典を書いた著者陣による体系書。クラウド費用を財務・開発・運用で協調管理する枠組みを、生成AIコストにも応用できる形で学べる。
Bedrockのコストに何が新しく表示されるようになったか
AWS Data Exportsは2026年7月、Amazon Bedrockの利用コストに標準化された商品メタデータを付与する機能を追加した[1]。従来はCUR 2.0の商品メタデータを自前で解析し、Bedrock分の費用を切り出す処理が必要だった。今回の変更で、モデル提供者・モデル名・料金単位・推論タイプ（入力トークンか出力トークンか）・提供形態（オンデマンドかバッチか）が標準属性として揃い、加えて「Amazon Bedrock」という統一の製品ファミリー名でコストを集計できるようになった[1]。
| 属性 | 内容 | 活用例 |
|---|---|---|
| モデル提供者 | Anthropicなど提供元 | 提供者別コスト比較 |
| モデル名 | 呼び出したモデル | モデル選定の費用対効果検証 |
| 料金単位 | 課金の計算単位 | 単価ベースの予算試算 |
| 推論タイプ | 入力・出力トークンの別 | 入出力比率の把握 |
| 提供形態 | オンデマンド・バッチの別 | 用途別コスト配分 |
| 製品ファミリー名 | 「Amazon Bedrock」で統一 | 全体コスト集計の単純化 |
AWSの請求データを読み解き最適化につなげる実務書。CUR・Cost Explorerの使い方を体系的に押さえたい担当者に向く。
演算タイプ単位の可視化は今年1月から始まっていた
今回の7月更新は独立した変更ではなく、2026年1月に始まった演算タイプ単位の可視化強化の延長線上にある[2]。1月の更新では、汎用的な「Usage」表記に代わり、InvokeModelInferenceやInvokeModelStreamingInferenceといった具体的な演算タイプがコストレポートに表示されるようになった[2]。この演算タイプは、Legacy CURとCUR 2.0では「line_item_operation」列、FOCUS形式のレポートでは「x_Operation」列、Cost Explorer APIでは「Operation」ディメンションの値として確認できる[2]。
CUR 2.0では、Bedrockへの推論リクエスト1件ごとに、トークン種別ごとの明細行が分かれて記録される。価格はトークン種別・サービス階層・リージョン間推論の経由有無によって決まる[3]。1月の演算タイプ開示と7月の商品メタデータ標準化が組み合わさり、Bedrockコストはどの演算を、どのモデルで、どちらの方向のトークンで使ったかまで追える状態になった。
AWSがEC2 Capacity Blocks for ML（GPUインスタンスを一定期間だけ確保予約できるAWSの購入方式）の料金を、2026年7月1日付で再び引き上げた。対象はP6-B300・P6-B200・P5・P5e・P5en・P[…]
なぜLLMコストの帰属はここまで難しかったのか
LLMコストの帰属とは、消費されたトークン量を利用チームや用途に結びつけて配分する作業を指す。FinOps実務では、この作業がここ数年で急速に主要課題化している。FinOps Foundationの「State of FinOps 2026」（年間クラウド支出計830億ドル超、1192人の実務者が回答）によれば、AI費用を能動的に管理していると答えた割合は2024年の31%から2025年に63%、2026年には98%まで上昇した[4]。
費用の管理対象が急拡大したぶん、粒度の細かい可視化への要求も強まっている。トークン利用をチーム・機能・環境・用途ごとに区別してタグ付けする「TokenOps」的な運用が、AI費用を配分可能な単位にする実務として位置づけられている[5]。BedrockのコストがCUR上で合計額だった段階では、こうしたタグ設計を組んでもモデルやトークン種別まで遡れず、突き合わせ作業が重い負担になっていた。
AI推論を24時間止めずに動かすコストと、クラウドの外へデータを出すたびに課される通信費（エグレス費用）が、企業のインフラ判断を揺さぶっている。銀行大手Barclaysが四半期ごとに実施するCIO調査（2024年第4四半期）では、8[…]
タグ付け・チーム別帰属をどう実務に落とすか
実務論点は、Bedrock呼び出し単位でタグを設計し、その情報を予算管理の仕組みに連携することに集約される。まず、プロジェクト・チーム・環境を識別するタグをリクエスト側で付与する設計を固める。次に、今回開示されたモデル提供者・トークン種別・提供形態とタグを組み合わせ、CUR上でチーム別・用途別のコストを集計する。
集計結果はチーム別チャージバックの根拠にできる。オンデマンドとバッチで単価が異なる点を踏まえ、バッチ処理に回せる非緊急ワークロードを見極めることも、予算圧縮の具体策になる。さらに、モデルやチーム単位で予算アラートの閾値を設定すれば、想定外の消費増を早期に検知できる。今回の標準化は、こうした運用を組むうえで必要だったカスタム解析ロジックの大半を不要にした[1]。
※本記事は2026年7月時点の情報です。料金・提供条件は変動が速いため、最新は各公式でご確認ください。一部アフィリエイトリンクを含みます。 ✅ 先に結論（Seedance 2.0の要点） 何がすごい[…]
まとめ
Bedrockのコスト可視化は、演算タイプ・モデル提供者・トークン種別まで踏み込んで初めて実務に使える情報になる。1月の演算タイプ開示と7月の商品メタデータ標準化が重なり、Bedrock利用はどのモデルをどちらの方向のトークンで使ったかまで請求データ上で追跡できる状態になった。
読者への具体的な行動として、まずリクエスト単位のタグ設計を見直すことを勧める。新しく開示されたモデル提供者・トークン種別・提供形態の3属性を使い、チーム別チャージバックの試算を一度組んでみるとよい。生成AI利用コストの可視化は、今回の変更で技術的な壁が下がった段階にある。
よくある質問（FAQ）
Q1. AWS Data ExportsとCURは何が違うか。
A1. CURは請求明細データそのものを指し、Data Exportsはそのデータを目的に応じた形式・頻度でS3に出力する機能を指す。
Q2. BedrockのオンデマンドとバッチはFinOps上どう扱い分けるとよいか。
A2. 即時応答が必要な処理はオンデマンドに残し、非緊急の処理はバッチに移すことで、提供形態別のコスト配分を予算圧縮に生かせる。
Q3. 今回の変更で既存のコストダッシュボードは作り直す必要があるか。
A3. 完全な作り直しは不要な場合が多い。標準属性が追加されたため、既存のCUR取り込み処理に列を足す形で拡張できる。
出典
[1] AWS Data Exports now provides standardized Amazon Bedrock product metadata[2] AWS Data Exports adds granular operation visibility for Amazon Bedrock model usage
[3] Understanding your Amazon Bedrock Cost and Usage Report data
[4] State of FinOps 2026 Report
[5] TokenOps: The Definitive Guide to FinOps for Tokens (2026)
