AIトークン費用をFinOpsだけで管理しない──BCGのRoAIをワークフロー運用へ落とす

生成AIを本番業務に入れると、最初の請求額よりも厄介なのは「なぜ増えたか」が分からない請求額だ。利用者数が変わらなくても、長いコンテキスト、強い推論設定、エージェントの再試行、ツール呼び出しでトークン利用は変わる。SaaSの1ユーザーあたり単価や、クラウドの月次予算だけでは、成果と費用を結び付けにくい。

BCGの「Return on AI: How CFOs and CIOs Can Manage the Token Meter」は、AIのコスト管理を「利用量を抑える」問題ではなく、成功した成果あたりの総コストを管理する問題として整理する。本稿では同記事の主張を確認しつつ、IT部門が実装できる可視化・最適化・停止判断へ翻訳する。

FinOpsが無力なのではない。管理単位が足りない

BCGは、従来のFinOpsを否定しているわけではない。インフラ費用の可視化、責任の割り当て、利用最適化には強みがある、と評価したうえで、AIでは管理単位が変わると述べる。

同じ「1リクエスト」でも、次の条件でコストも品質も大きく違う。

• プロンプトと出力の長さ
• 検索で取得した文書、会話履歴、ツール出力などのコンテキスト量
• モデル、推論強度、コンテキストウィンドウの選択
• キャッシュの効き方、バッチ処理の可否
• エージェントが停止までに回す計画・実行・再試行の回数

「エージェントだから費用が指数関数的に増える」と断言するのも正確ではない。BCGの原文も、トークン費用は自動的に指数関数的ではなく、プラットフォームやモデルによって幅があると注意している。ただし、長いコンテキストを各ループで再送し、再試行が重なる未管理のワークフローでは、成功1件あたりの消費量が見えないまま急増し得る。

重要なのは、リクエスト数ではなく、この1本のワークフローを完了させるための「トークン」「ツール実行」「人間の確認時間」「成果」を同じ実行IDで追うことだ。

RoAIは「AIが安いか」ではなく「成功1件の総コスト」を問う

BCGが提案するRoAI（Return on AI）は、次の考え方である。

RoAI = 経済的リターン ÷（人間の知的労働コスト + トークンコスト）

分母に人間の費用を入れる点が肝心だ。AIが回答を作っても、仕様の作成、根拠確認、修正、テスト、承認、障害対応に多くの時間が必要なら、そのワークフローの投資対効果は高くない。

たとえばコーディングエージェントなら、生成コードの行数は活動量にすぎない。価値として見るべきは、レビューを通ってリリースされ、品質を保ち、総リードタイムを縮めた変更である。問い合わせエージェントも、解決チケット数だけでなく、再問い合わせ、誤案内、有人エスカレーション、顧客満足を含めて評価する。

ワークフロー	経済的リターンの例	総コストに必ず入れるもの
開発支援	リリースまでの時間短縮、障害削減	トークン、仕様・レビュー・テスト・修正時間
顧客対応	解決率、継続率、対応容量	トークン、監督、エスカレーション、再対応
社内調査	意思決定の迅速化、調査の再利用	トークン、根拠確認、更新・承認の時間

RoAIは会計基準ではなく、BCGの投資判断用フレームワークである。「経済的リターン」の定義、観測期間、品質条件を先に合意しなければ、もっともらしい分子を置くだけの比率になる。品質・遅延・リスク・人間の追加負担を満たした成功成果あたりのコストを、運用上の主要指標にするのが安全である。

トークン費用を一つのIT予算に閉じ込めない

BCGは、トークン費用を用途に応じて三つに分けて把握することを提案する。これは会計処理を一律に決めるものではないため、実際の資産計上や原価計算は自社の会計方針と監査担当者に確認する必要がある。ここでは、誰が価値と予算に責任を持つかを決める管理分類として使う。

BCGの整理	典型例	管理で問うべきこと
Capex（投資）	再利用可能なエージェント基盤、全社横断の業務再設計、自前推論基盤	再利用性、利用部門、回収見込み、維持責任
Opex（運営費）	社内の開発・営業・調査・バックオフィスでのAI利用	部門・業務別の予算、成果KPI、上限、継続条件
COGS（売上原価）	顧客向けAI機能、AIを含む問い合わせ対応	1顧客・1成功成果あたりの原価、価格、粗利、利用制限

特に顧客向け機能では、SaaSのように「顧客が一人増えても推論費用はほぼ増えない」とは限らない。利用量、モデル構成、キャッシュ、ルーティング、料金体系を見なければ、利用が伸びるほど粗利が下がることがある。プロダクトチーム、財務、プラットフォームチームが同じ原価データを見る必要がある。

BCGの「See / Shape / Prove, Stop, or Minimize」を実装する

See：最適化より前に帰属をつくる

ダッシュボードを豪華にする前に、すべての重要なワークフローへ次の属性を付ける。

workflow_id / 実行ID / 事業オーナー / 部門 / 内部利用または製品利用
P&L区分 / モデル・プロバイダー / 入出力トークン / キャッシュヒット率
ツール実行回数 / 推論・再試行回数 / 人間レビュー時間 / 成果・品質結果

APIキーやプロジェクトを用途ごとに分け、タグを必須化する。こうすると「高額なワークフローは何か」「所有者のない支出はどれか」「フロンティアモデルへのデフォルト利用はどこか」「内部Opexと製品COGSがいくらか」を答えられる。BCGの言うとおり、所有者のない支出は統制されず、成果定義のない支出は価値を証明できない。

ログにはプロンプト本文を無制限に保存しない。個人情報・機密情報を含む可能性を前提に、本文の保管可否、マスキング、保持期間、閲覧権限をデータ区分ごとに決める。費用可視化のために新しい情報漏えい経路を作らないことが重要だ。

Shape：4つのレバーを品質条件付きで使う

BCGはコストを形づくるレバーを四つ示す。順番を誤ると品質だけを落とすので、各施策を評価セットと成功率と一緒に適用する。

1. 不要なモデル利用をなくす：計算、固定的な規則判定、構造化検索、決定的なルーティングは、通常のプログラム、API、ルールエンジンで処理する。費用だけでなく再現性も改善しやすい。
2. タスクの複雑さでモデルをルーティングする：簡単な抽出・分類には軽量モデルやオープンウェイトモデルを使い、難しい推論にだけ高性能モデルを予約する。弱いモデルの再試行が多ければ、かえって成功1件あたりの原価が上がるため、単価だけで選ばない。
3. コンテキストと部品を再利用する：安定したシステム指示、規程、ブランドルールをキャッシュしやすい先頭部分へ寄せる。非同期処理はバッチ化し、共通の手順はテンプレートやスキルとして管理する。
4. トークン規律をプロダクトに埋め込む：利用者に短い回答を求める教育をするだけでは弱い。UIの既定値を簡潔な出力にし、検索件数、最大出力、ループ回数、停止条件を設計する。
   

Prove, Stop, or Minimize：活動量ではなく、継続判断をする

高コストのワークフローには定例レビューを置き、分子の成果と、トークン＋人間の総コストを比較する。その結果は「拡大」だけではない。

• Prove / Scale：品質しきい値とRoAIを満たす。利用対象を広げる。
• Optimize / Rescope：価値はあるが、モデル・コンテキスト・手順・対象範囲を見直す。
• Stop / Minimize：成果が乏しい、あるいは人間の修正負担やリスクが大きい。停止するか、人が主導する限定用途へ戻す。

停止条件を開始前に決めることが大切だ。例として「30日間の成功率が90%未満」「1成功成果あたりの総原価が手作業より高い」「重大な根拠不備が1件でも起きた」を置く。具体的な閾値は業務のリスクと既存ベースラインに合わせて決める。

1〜12か月の実行順序

BCGは、1〜3か月のクイックウィン、3〜6か月の大きな施策、6〜12か月の継続改善という順序を示す。実装では次のように進めると、削減だけで終わりにくい。

期間	実施すること	成果物
1〜3か月	主要ワークフローへ所有者・予算・タグを付与。不要な利用を止め、上限と停止条件を設定	費用台帳、初期ダッシュボード、評価セット
3〜6か月	モデルルーティング、キャッシュ、バッチ処理、利用者向け既定値を導入	成功成果あたりの原価と品質を示す比較結果
6〜12か月	COGSと価格・粗利を接続し、再利用部品と評価を標準化	継続・縮小・停止を決めるポートフォリオレビュー

結論：AI FinOpsの目的は請求額の最小化ではない

AIの請求額を一律に削れば、品質、速度、顧客体験、将来の収益機会も同時に削ることがある。BCGのRoAIが促しているのは、安いモデルを選ぶことそのものではなく、人間とAIが生む成果を、必要な品質と安全性の下で最も良い単価にすることだ。

まずは、最も費用が大きい一つのワークフローで、誰が使い、何を成功とし、どのコストを負担し、いつ止めるかを追跡できるようにする。そこから初めて、トークン費用は「予測不能なIT請求」ではなく、改善可能な事業の単位になる。

作成日: 2026年8月13日