FinOps FoundationがTokenomics Foundationを立ち上げたのは、AIコスト管理という「すでに解決済みの課題」に新しい名前を付けたかったからではありません。JR Stormentが指摘しているように、トークン経済とは、AIの消費を計測し、配賦し、ビジネス成果に結び付けるための領域であり、これを確実に実行できている企業はいまだにほとんどありません。すでに片付いた問題のまわりに、新たな領域が築かれることはないのです。
こうした課題に直面すると、これまでクラウドコストの問題を解いてきた方法、すなわちリソースにタグを付け、呼び出しをSDKでラップし、命名規則を徹底するというやり方に頼りたくなります。この定石は従来型のインフラでは機能しました。しかし、AIインフラでは通用しません。理由は運用手順ではなく、アーキテクチャそのものにあります。
より新しいアプローチとして登場したeBPFによるカーネルレベル計測は、タグもSDKもコード変更も使わず、OSレベルで消費を直接観測することで、計装という問題そのものを回避します。これが「タグ・SDK・コード変更なしのトークン経済」が意味するところです。以下では、計装アプローチが行き詰まる理由と、カーネルレベル配賦がどう異なるのかを見ていきます。
AIコスト配賦とは何か（そしてなぜ今、機能していないのか）
AIコスト配賦とは、AI支出、GPUサイクル、モデルAPI呼び出し、トークン消費を、その発生源である特定の顧客・機能・チーム・エージェントまで遡って紐付ける取り組みです。クラウドコスト配賦のAI時代版と言えますが、決定的な違いが一つあります。計測対象となるインフラが、従来の手法で捕捉できるほど長くじっとしていてくれないのです。
従来のコスト配賦は計装に依存します。リソースにタグを付ければ所有者がわかり、API呼び出しをSDKでラップすればどのチームが呼び出したかがわかる。このアプローチは従来のクラウド環境でも完璧ではなく、タグ付けカバレッジは永遠に道半ばですが、それでも「実用に足る」レベルで機能してきました。下層のインフラが比較的静的で、所有権も比較的明確だったからです。
AIインフラは、こうした前提をことごとく崩します。
1つのマネージドモデルAPIアカウントが、同時に何十ものチームに使われます。共有GPUクラスタは複数プロダクトのworkloadsを同時に走らせ、リソースレベルの境界はありません。LLMゲートウェイは、エージェント・パイプライン・人間ユーザーからのリクエストを1本の外向きストリームに束ね、その過程で呼び出し元のアイデンティティを削ぎ落とします。エージェント型workloadsはサブエージェントを生成し、それがコンピュート・メモリ・ネットワークといった下流コストを引き起こしますが、元の請求項目まで辿れる経路は残りません。
LLMプロキシを一度でも経由すれば、生き残るタグはありません。共有GPUをラップできるSDKもありません。理論上は計装できる箇所であっても、AI workloadsは計装を配備できるより速く動きます。エージェントは一晩で1,000のサブエージェントを産み、追跡コードを誰かが更新するはるか前に請求書が届くのです。
AI支出における配賦のギャップは、プロセス上の課題ではありません。AIインフラの動き方そのものから生まれる、構造的な帰結なのです。
従来型アプローチが頭打ちになる理由
この問題に取り組むツールは、大きく3つに分けられます。
請求層のツールは事後的に働き、プロバイダーの請求書をレポートに突き合わせます。集計ベースで「いくら使ったか」は教えてくれますが、コストを生んだworkloadsが走り終わってからずいぶん経った後の話です。
Kubernetesエージェント型のツールは、オーケストレーション層に計装を仕込み、ポッドやコンテナ単位のリソース使用状況を追跡します。workloadsがKubernetes内、しかも単一クラスタの境界内に収まっている限りは機能しますが、リクエストがマネージドAPI・共有GPU・LLMゲートウェイを跨いだ瞬間に可視性を失います。
メタデータ推論型のツールは、手動タグ付けそのものを飛ばそうと試み、利用可能なメタデータから所有権を推論し、仮想タグを自動的に提案します。手動タグ付けからは確かに一歩前進ですが、同じ天井を引き継いでいます。記述するメタデータが存在するものしか配賦できず、AI消費が実際に発生する層には、そのメタデータが存在しないのです。
3つのアプローチはいずれも、実際の消費が起きている層よりも上に位置するシグナルから、配賦を事後的に再構築しています。共有GPUの内側を覗くことはできません。ゲートウェイを通過したトークンを、発生源のエージェントまで追いかけることもできません。
それができるプラットフォームは、これら3つの層の「横」ではなく「下」から、つまりカーネルから計測しているものです。カーネルでは、消費は推論ではなく直接観測されます。
カーネルレベル配賦の仕組み
カーネルレベルのアプローチでは、eBPFセンサーをOS内部に直接デプロイします。デプロイは通常数分で完了し、コード変更もKubernetesマニフェストの編集もSDK統合も一切不要です。
稼働を開始したセンサーは、実際の消費をリアルタイムで観測します。あらゆるトークン、モデルリクエスト、GPUサイクルを捉え、各単位を担当したプロセス・コンテナ・ポッド・リクエストへとマッピングします。このランタイムデータは、Anthropic、OpenAI、Google Gemini、AWS Bedrockといったソースからのプロバイダー請求と突き合わされ、キャッシュトークン、推論トークン、入力トークン、出力トークンを自動的に分けて集計します。
こうして、顧客別・機能別・エージェント別のトークン経済が、計装なし・タグ付けなし・コード変更なしで継続的に得られます。センサーがカーネルで動くからこそ、消費を直接観測できるのです。推論すべきものは何もなく、エージェントもゲートウェイも共有GPUも、その背後に隠れる余地はありません。
カーネルレベル配賦が各チームにもたらすもの
VP of Engineeringのチームにとって、カーネルレベル配賦は「根拠のあるチャージバック」を意味します。GPUコストは発生源のworkloadsまで辿れるため、インフラを共有するチーム間で請求を巡って揉める場面はなくなります。
FinOpsプラクティショナーにとっては、迷子のスプレッドシートからの解放を意味します。タグは劣化します。タグ付けの規則は、新しいサービスがリリースされた瞬間に時代遅れになります。カーネルレベル計測は、誰かがタグ付けを覚えていることに依存しません。
CFOや財務リーダーにとっては、アカウント単位の概算ではなく、特定の機能や顧客セグメントに結び付いたROIの可視化が手に入ることを意味します。ある機能が更新率を押し上げているとわかることは、先月アカウント全体でいくら使ったかを知ることとは、まったく質の異なる洞察です。
なぜ今なのか
同じパターンは、これまでのあらゆるクラウドコスト領域、すなわちコンピュート最適化、commitments管理、Kubernetesコスト配賦においても繰り返されてきました。適切な計測基盤を早期に築いた組織は、その後の意思決定すべての精度が上がります。請求額が膨らむまで配賦を先送りにした組織は、初日から手にできたはずのコンテキストを、何年もかけて後追いで組み直すことになります。
AI支出はこれまでのどの領域よりも速く動いており、データもそれを裏付けています。Sapio Researchが財務リーダー500名を対象に実施した調査では、企業の79%がすでにAIコストの超過を経験しており、大きなボトルネックなくAIのROIを算出できているのはわずか15%にとどまります。適切な基盤を築くべきタイミングは、次の想定外の請求書が届いた後ではなく、今なのです。
DoiTのアプローチ
DoiTは27カ国4,500社にわたる80億ドル超のクラウド支出を管理しており、この計測パターンが主要なクラウドコスト領域のたびに繰り返されるのを見てきました。Attribute™ by DoiTは、ここまで述べてきたカーネルレベルのアプローチを実装したものです。約15分でデプロイできるeBPFセンサーが、タグなし・SDKなし・コード変更なしで、導入当日中に顧客別・機能別・エージェント別のトークン経済を生み出します。
DoiTはTokenomics Foundationのマーケティングパートナーでもあり、JR StormentおよびFinOps Foundationと連携し、AIトークン経済のオープンな業界標準を、この領域の成熟に合わせて策定しています。
デモを予約して、Attribute™をご自身の環境でお試しください。