AIコスト按分:CFOの問いにタグ付けでは答えられない

AI支出でタグ付けが行き詰まるのは、トークン呼び出しにはタグを付ける相手そのものが存在しないからです。従来のクラウド按分はこうでした。EC2インスタンスにteam=platformとタグを付ければ、稼働時間の分だけコストがplatformチームに流れます。タグはリソースに宿り、リソースがコストを生む。この鎖は途切れません。

AI APIコールはそうはいきません。アプリケーションがopenai.chat.completions.create()を呼んでも、タグを付けるリソースがそもそもありません。あるのはリクエストとレスポンス、そしてOpenAI側で記録されたトークン数だけ。クラウドプロバイダーはこの呼び出しを目にすることもなく、タグ付けシステムが触れる余地もありません。月末、OpenAIは組織単位で1通の請求書を送ってきます。モデル別に内訳が付くことはあっても、手に入る情報はそれで全部です。

FinOps FoundationはAllocationをコアケイパビリティと定義していますが、このフレームワークはタグ付けできる単位が存在することを暗黙の前提にしています。SaaS型のAIプロバイダーには、その前提が成り立ちません。AnthropicもBedrockも構造は同じです。プロバイダーのダッシュボードは支出をAPIキーやモデル単位でしか分解せず、リクエストを発生させた顧客や機能では区切ってくれません。仮にチームごとにAPIキーを分けても、顧客単位で分けるとなれば、ディレクトリサービス並みに数千本のキーを立てて運用することになります。

EC2向けのタグ付けの定石をそのままOpenAIに持ち込んだFinOps担当者が、結局CFOと同じ「合計値」に戻ってきてしまうのは、これが理由です。按分は成立していないのです。

同じAI請求書が社内で呼び起こす問いは3種類あり、そのいずれもプロバイダーの課金データだけでは答えが出ません。

財務が知りたいのはユニットエコノミクスです。顧客1社あたりの提供コストはいくらか。上位顧客が月40ドル分のClaude呼び出しを発生させ、99ドルのサブスクリプションを払っているなら、月2ドルしか呼び出さない顧客とはマージン構造が根本的に違います。顧客別の按分がなければ、粗利計算は当て推量の域を出ません。

プロダクトが知りたいのは機能単位のROIです。トークンコストに見合う機能はどれか。要約機能は月8,000ドルでリテンションを支えているかもしれません。実験的なエージェントは月22,000ドルかかっている割に、利用者は40人ということもあり得ます。どの機能が請求書のどの部分を占めているのかが見えなければ、プロダクトは優先順位を決められません。

CFOが知りたいのは、数字が動いた理由です。Anthropicの請求額が前月比で倍になったとき、誰かが説明できなければなりません。新規顧客の流入なのか、プロンプトの変更か、自己ループに陥った暴走エージェントか。請求書はそのどれも語りません。示されるのは合計値だけです。

生の課金データをFinOpsダッシュボードに取り込んでも、これらの問いにはひとつも答えられません。それは請求書の再表示にすぎず、レポーティングレイヤーであって按分レイヤーではないからです。FinOps Frameworkは「Automation, Tools, & Services」を、新興の支出カテゴリにおけるAllocationも含むケイパビリティを支えるソフトウェアと位置付けています。AIについては、その自動化がリクエストそのものに踏み込む必要があります。ビジネスコンテキストが宿っているのは、そこだけだからです。

トラフィックレベル按分は、AIリクエストが発生するたびにその中身を読み取り、トークン数を発生源の顧客・機能・エージェントに紐付けます。集約後の請求書から按分を逆算するのではなく、リクエストが投げられたその瞬間、コンテキストが消える前に捕まえるのです。

実運用はこう流れます。アプリケーションがプロンプトを添えてClaudeを呼び出す。リクエストはゲートウェイあるいはプロキシを経由し、ペイロードが検査され、認証トークンから顧客ID、リクエストパスから機能名、呼び出し元サービスからエージェント識別子が付与される。リクエストはそのままAnthropicへ渡り、レスポンスが戻る。ゲートウェイは、付与した各ディメンションに対してトークン数をログに残します。月末に手元に残るのは、Anthropicからの一つの数字ではなく、任意のビジネス軸でグルーピングできる数千件の按分済みイベントです。

この仕組みはOpenAI、Anthropic、Bedrockのいずれでも成立します。トラフィックのパターンが共通しているからです。どのプロバイダーもレスポンスにトークン数を返し、どのリクエストもアプリケーションレベルのコンテキストを運びます。按分ロジックはコードとプロバイダーの間に置かれるため、タグを持たせるためにアプリケーションコードを書き換える必要はありません。顧客別のコストが欲しければ顧客別に、エージェント別のコストが欲しければエージェント別に出せます。

これはタグ付けというより、オブザーバビリティに近い設計思想です。だからこそツールの姿も変わります。タグベースのFinOpsツールはCURファイルを取り込みたがりますが、トラフィックレベル按分ツールはリクエストパスの中に居場所を求めます。アーキテクチャが違えば、ケイパビリティも別物です。この転換の重要性については、Why traditional FinOps breaks down with AI workloadsで以前掘り下げていますので併せてご覧ください。

AIコスト按分は新しいダッシュボードの話ではありません。既存のエンタープライズアーキテクチャの前提に収まらない支出カテゴリのための、新しいAllocationケイパビリティです。FinOps Frameworkはタグ付け可能なリソースを前提に設計されました。コンピュート、ストレージ、ネットワーク、データベースはいずれも、ツールがまとめてグルーピングできる識別子を備えています。AI APIの支出はそうではありません。消費の単位はトークンであり、トークンはリソースではなくリクエストの中にしか存在しないのです。

つまりAI按分は、フレームワークの「Automation, Tools, & Services」レイヤーに位置付けられるものの、その実装はタグベースの按分とは異なるパターンを取ります。課金エクスポートを取り込んでタグでグルーピングするのではなく、ライブトラフィックを読み取って按分レコードを生成し、それをAllocationケイパビリティへ戻します。財務担当者から見えるアウトプットは同じ、チーム別・顧客別・機能別のコストです。ただし裏側の仕組みはまったく違います。

これはFinOps担当者がツールチェーンを設計するうえで重要な論点です。タグベースのツールの上にAI FinOpsの実践を積み上げようとすれば、あのCFOの財務責任者と同じ壁にぶつかります。AI按分ツールを評価するときに問うべきは「OpenAIの請求書を取り込めるか」ではありません。どのツールもそれはできます。問うべきは「OpenAIの請求書を按分できるか」です。そのためには課金取り込みではなく、トラフィックレベルの計装が要ります。

FinOps FrameworkのCapabilitiesページは、AIワークロードを念頭に置いて読み直す価値があります。Anomaly Management、Allocation、Forecastingはいずれも、按分の存在を暗黙の前提にしています。AI支出において、その按分こそが欠落している入力なのです。