DoiTでField CTOを務める前、私はFinOpsの実務家でした。タグ付けポリシーを整備し、予算レビュー直前になってタグ未設定のリソースを追い回し、技術的には筋の通ったチャージバックモデルを組み上げてきました。それでも会議のたびに議論は紛糾しました。誰かの共有クラスターの使われ方が、P&Lの区分けと噛み合わなかったからです。
ですから今週 Attribute™ をローンチしたとき、議論がまずトークン——入力、出力、キャッシュ、推論——から始まる理由はよく分かりました。リクエスト単位、顧客単位、機能単位、エージェント単位のコスト。切り口としては正しい。ただ、それだけでは足りないと私は考えています。
トークンを数えるのは簡単です。難しいのは、そもそもなぜそのトークンが発生したのか、という問いです。顧客が新しいAI機能を使い始めたのか。社内ワークフローがいつの間にか高価なモデルに切り替わっていたのか。あるプロンプトが本来の10倍ものトークンを浪費しているのか。エージェントが誰も頼んでいない下流タスクを何百と生み出しているのか。コストレポート上では、この4つのシナリオはほぼ見分けがつきません。しかしビジネスから見れば、まったくの別物です。
タグ付けは目的ではなかった
実務家なら誰もが知っているのに、あまり口にされない事実があります。誰もタグそのものが欲しかったわけではないのです。本当に欲しかったのはアカウンタビリティ——適切な人が、行動できるタイミングで、適切なコスト情報を目にする、という状態です。タグ付けは、当時のアーキテクチャにおいてアカウンタビリティを実現する最善の手段にすぎませんでした。1つのVMが1つのアプリケーションを担い、1つのアカウントが1つのチームに紐づいていた頃は、所有・消費・アカウンタビリティがきれいに揃っていた。アーキテクチャがそれを許していたから、タグは機能していたのです。
そのアーキテクチャが変わりました。Kubernetesはインフラを共有化し、サーバーレスはそれを抽象化しました。マネージドサービスは、支出をリクエストやクエリ、呼び出しの中に埋め込みました。Vadimは なぜ計装が破綻するのか について、Joshは タグ付けがどこで失敗するのか について書いていますので、ここでは繰り返しません。要約すれば、課金される対象と需要を生み出す対象がずれていき、AIがその両者を完全に引き剥がした、ということです。1つのモデルアカウントやゲートウェイが、あらゆる製品・チーム・エージェント・従業員からのリクエストを一括して集約してしまう。請求書が届く頃には、それを説明する文脈はすでに消えています。
同じ数字、4つの異なる判断
ここが私が最もこだわる部分です。なぜなら、これは「報告する」ことと「意思決定する」ことの違いだからです。
仮に、先月のAI支出が40%増えたとします。長年の実務経験から言わせてもらえば、その数字だけで導ける結論は何もありません。次に何をすべきかは、なぜそうなったかに完全に左右されます。
顧客向け機能の利用と定着が進んだ結果なら、投資を増やすべきです。これはコストの問題ではありません。コストの顔をした成長シグナルです。
小さなモデルで十分こなせるタスクに、社内ワークフローがプレミアムモデルを使っている結果なら、最適化の出番です。投資対効果の測れるエンジニアリング仕事になります。
エージェントが不要な下流呼び出しを大量にばら撒いている結果なら、ガバナンスの出番です。レート制限、予算、コントロールを敷きます。
そして、ある一社のエンタープライズ顧客が推論コストの大半を占めている結果なら、もはやFinOpsの話ですらありません。プライシング、パッケージング、マージンの話——CFOとプロダクトチームが議論すべきテーマです。
原因は4つ。担い手も4通り。取るべきアクションもまったく異なる4種類。コストの数字だけでは、どの会議を設定すべきかは分かりません。それを教えてくれるのは文脈です。
これこそが Attribute™ が実際に変えるものです。カーネルレベルで実際の消費を計測し、プロバイダーの請求データと突き合わせるため、「なぜ」が数字とセットで届きます。この顧客、この機能、このエージェント、このワークフロー——と。トークン集計そのものが目的なのではありません。アトリビューションこそが、数字を意思決定へと変えるからです。

実務はどう変わるのか
私たちが実施した 500人の財務リーダーへの調査 では、79%がすでにAIコスト超過を経験しており、大きなボトルネックなくAIのROIを算出できているのはわずか15%でした。私はこれを規律の問題だとは思いません。彼らはFinOpsに失敗しているのではなく、旧来のプレイブックを、それを打ち負かすアーキテクチャに向かって走らせているだけなのです。
次に来るもの、そして私が現場で顧客に伝えていることはこうです。FinOpsは、事後に文脈を再構築する報告機能であることをやめ、意思決定が下されるその場に組み込まれていく——。Engineersは30日後ではなく、設計しているその瞬間にコストへの影響を目にします。プロダクトチームは、プライシング議論の後ではなく前に、機能のユニットエコノミクスを把握します。ファイナンスは、切り分け不能な1行の項目を眺める代わりに、AI支出を顧客あたりのマージンに結び付けます。AIプラットフォームチームは、どのモデルが動いたかだけでなく、どのユースケースが価値を生み、どれが無駄を生んだかまで見通せるようになります。
そのどれも、アトリビューションなしには成り立ちません。それはFinOpsのあらゆる要素が乗る土台であり、AI workloadsにおいては、これまで私たちに欠けていた土台なのです。
私はキャリアの長い時間を、請求書が届いた後に文脈を再構築することに費やしてきました。FinOpsの次の時代は、お金が使われる前にその文脈を手にしていることです。今回のローンチが私にとって意味するのは、まさにそれです。
インストールは15分。計装は不要。当日中にトークンエコノミクスが見えます。デモを予約して、Attribute™をご自身の環境でお試しください。