AWSが「Calculating the Return on Investment (ROI) of AI」と題した記事を公開した。AI関連コストが増加する一方で「それが本当に価値を生んでいるのか」を定量的に示せていない組織は多い。AWSはこの問いに対し、「Cost per Outcome（アウトカム当たりコスト）」という指標を軸に据えた算出フレームワークを提示している。さらに記事の核心には、指標選定における古典的な落とし穴であるGoodhart's Lawへの警告が据えられており、測定設計の質がROI算出全体の信頼性を左右すると強調している。
ROI算出の核心：Cost per Outcome
記事が提示する基本式はシンプルだ。
Cost per Outcome = AI Cost / Business Value Metric
具体例として、開発者の生産性向上を取り上げている。AIツール導入前のバグ修正件数が週5件（ベースライン）だったとする。AI導入後に週15件に増加し、AIコストが週5,000ドルだった場合、AIによる純増分は10件（15－5）なので：
$500 per bug remediated = $5,000 / 10 bugs
バグ1件の修正にAIコストが500ドルかかっている、というのが出発点の数字だ。
この数字は単独で良し悪しを判断するものではなく、週ごとに追跡することで傾向を読む。コストが固定でバグ修正件数が増えれば効率向上、件数が減れば効率低下を意味する。ただし件数が減った場合でも、より複雑なバグを解決しているなら「バグの複雑度」といった追加指標で補正する余地がある。
ユースケースの分類から始める
ROI算出の前提として、AIの用途をExternal（外部向け）とInternal（内部向け）に分類する。
- External：収益に直結する活動を支援するAI。コストは売上原価（COGS）の一部として扱える。
- Internal：開発者の生産性向上（コーディングアシスタント等）や業務効率化が目的。収益への直接紐付けが難しく、ROI算出には定量的なアウトカム設定が必要になる。
さらに、各ユースケースをStructured（構造化）とUnstructured（非構造化）に区別することも求められる。注文履歴に答えるチャットボットのように目的とKPIが明確なものがStructured、コーディングアシスタントのようにオープンエンドな利用がUnstructuredだ。後者はコスト配分が難しく、より細かい計測が必要になる。
TCOの正確な把握
ROI算出の前に、Total Cost of Ownership（TCO）を正確に算出することが前提となる。見落とされがちな間接コストとして、記事は以下を挙げている：
- ストレージ：RAG（Retrieval-Augmented Generation）で使うVector Databaseのコストが予想以上に大きくなるケースがある
- データ転送：サービス間・外部システムとのデータ移動に伴うコスト
- 監視・レポーティング：ログ収集、ダッシュボードのライセンス費用
- Agentic AI：AWS LambdaやAmazon API Gatewayを経由した外部システム連携コスト。ツールコール数やオーケストレーションの複雑さによって変動幅が大きく、他の項目に比べて事前見積もりが難しい点に注意が必要だ
TCOの把握が甘いままCost per Outcomeを算出しても、分母の「AIコスト」自体が実態を反映していないことになる。まずコスト計測の網羅性を確認することが、フレームワーク全体の精度を左右する。
コスト配分の仕組み（Amazon Bedrock）
Amazon Bedrockでは、用途に応じた複数のコスト配分メカニズムが提供されている。
| メカニズム | データの見え方 | 主な用途 |
|---|---|---|
| IAM Principal-Based Cost Allocation | AWS Cost Explorer / CUR | 財務チームへのチャージバック |
| Application Inference Profiles | AWS Cost Explorer / CUR | アプリ・チーム単位の集計 |
| Projects / Workspaces | AWS Cost Explorer / CUR | OpenAI互換API / Anthropic互換API |
| Request-Level Metadata | モデル呼び出しログ | リクエスト単位の詳細分析 |
記事は「これらは競合するものではなく、補完し合うもの」と説明している。IAM Principalで常時自動追跡を行いつつ、Projects/WorkspacesやApplication Inference Profilesで集計し、必要に応じてRequest-Level Metadataでリクエスト単位に掘り下げる、という重ね合わせが推奨パターンだ。
各メカニズムは目的に応じて使い分けるというより、粒度の異なる視点を同時に持つために組み合わせて運用するものと理解すると導入しやすい。財務報告向けの粗い集計と、改善施策の判断に使う詳細ログを別々に整備しておくことが、実運用上は重要になる。
ビジネス価値指標の選び方とGoodhart's Law
指標選定において記事が強調するのがGoodhart's Lawだ。
「ある指標がターゲットになった瞬間、それは良い指標ではなくなる。」
例として「開発者のコード行数」を指標にすると、AIにコメント行を大量生成させてインフレさせられる。代わりに「リリースされた機能数」や「修正されたバグ数」など、操作しにくい指標を選ぶことが重要だとしている。
ビジネス価値指標は3カテゴリに分類される：
- Business and Product Revenue（製品売上、サブスクリプション収益など）：直接的だが、マーケティングや競合など外部変数の影響を受けやすい
- Development Metrics（デプロイ頻度、機能デリバリー数など）：技術速度を追うが、複雑度の正規化が難しい
- Revenue Support Metrics（クリック率、リテンション率など）：間接的な収益寄与を測るが、AIとの因果関係が薄れやすい
Goodhart's Lawへの対処は、指標を複数組み合わせて一点集中を避けることと、定期的に指標自体を見直す運用サイクルを持つことに尽きる。記事はこの問題を「ROI算出の技術的な問題」ではなく「組織設計の問題」として位置づけており、計測体制と評価文化の両面から取り組む必要があることを示唆している。
実践的な出発点
記事の結論として提示されているアクションは明快だ。まず上位3つのAIワークロードにコスト配分タグを付け、それぞれに1つのビジネス価値指標を定義し、今四半期中にCost per Outcomeを初回算出する、というものだ。
ROI単体がAI戦略の唯一の判断軸である必要はない。短期ROIが低くても長期的な競争優位を生む可能性がある施策は存在する。記事はROIを「継続・停止の判断基準」として使いつつ、高ポテンシャルのプロジェクトには柔軟性を残すことを推奨している。
詳細はCalculating the Return on Investment (ROI) of AIを参照していただきたい。
