AIの請求書は確認できます。ある程度の説明もできます。しかし、その支出を顧客・チーム・ユーザーに紐づけることはできません。結果として、自社製品を健全なマージンで価格設定できているのかを言い切れなくなります。支出額と説明可能な範囲の間に生じるこのギャップ - それこそが、私たちが Attribute™ で解決しようとしている課題です。
クラウドコストの配賦は、特に共有リソースにおいて、これまで決して簡単ではありませんでした。DoiT はこの15年間、4,000社を超えるお客様とともに、共有インフラの解きほぐし、タグ付けポリシーの徹底、精査に耐えるチャージバックモデルの構築に取り組んできました。もともと難しい問題でしたが、AIによってさらに困難さが増しています。
AIが稼働するインフラは、配賦ではなく速度とスケールを目的に設計されています。業界がクラウドで落としどころとしてきた配賦手法(タグ)は、そのままでは通用しません。これはアーキテクチャ上の現実であり - まったく異なる種類の答えが求められました。
計装(instrumentation)の罠
コスト配賦の定石は、常に「計装」でした。リソースにタグを付ける。API呼び出しをSDKでラップする。命名規則を徹底する。それらのシグナルを集約するパイプラインを構築し、ダッシュボードに反映する。
従来のクラウドインフラであれば、完璧ではないにせよ、このアプローチで十分機能します。基盤となる共有インフラは比較的静的で、所有権モデルも比較的明確です。いくつかの妥協を受け入れれば、「まずまず」のレベルまでは到達できます。
ところが、AIインフラはそのアプローチの前提をことごとく崩します。
1つのマネージドモデルが同時に複数の顧客にサービスを提供します。共有GPUクラスタは複数プロダクトのモデルを並行して実行します。LLMゲートウェイは、エージェント、ハーネス、人間からのリクエストを1本のアウトバウンドストリームに束ねます。さらに、エージェント型 workloads はサブエージェントを次々に生成し、元となったAI請求項目とのつながりが見えないままインフラコストを発生させることもあります。
共有GPUをラップできるSDKは存在しません。LLMプロキシを経由しても生き残るタグもありません。そもそもAI workloads は、計装が追随できるようなペースでは動かないのです。1体のエージェントは一晩で1,000のサブエージェントを生み出し得ます。新しい呼び出しパターンをSDKでラップしてアップデートを配信し終える頃には、請求書はすでに届いています。
AI支出における配賦のギャップは、計装で乗り越えられるプロセスの問題ではありません。AIインフラの仕組みそのものに根ざした、アーキテクチャ上の現実なのです。
「AI支出における配賦のギャップは、計装で乗り越えられるプロセスの問題ではない。AIインフラの仕組みそのものに根ざした、アーキテクチャ上の現実だ。」
これこそ、私たちを Attribute™ に導いた気づきです。AI workloads のアーキテクチャが設計上、計装を無力化してしまうのであれば、計装はそもそも間違った答えということになります。抽象化、プロキシ、所有権境界のいずれよりも手前にあり - すべてを見通せるレイヤーから計測しなければなりません。すなわち、OSカーネルで計測するのです。
まったく異なるアプローチ
Attribute™ は、オペレーティングシステム内部で動作するeBPFセンサーを展開します。実際の消費 - すべてのトークン、すべてのモデルリクエスト、すべてのGPUサイクル - を発生と同時に観測し、それぞれの単位を、原因となったプロセス、コンテナ、Pod、リクエストへとマッピングし直します。さらに、Anthropic、OpenAI、Google Gemini、AWS Bedrock からのプロバイダー請求データと突き合わせ、キャッシュトークン、推論トークン、入力トークン、出力トークンを自動で分解します。
その結果得られるのは、顧客ごと・機能ごと・エージェントごとのトークンエコノミクスです。計装なし、タグ付けなし、コード変更なしで、継続的に生成されます。
現在利用できるツール(優れたものもあります)は、大きく2つに分かれます。1. Engineers にコードでアロケーションロジックを定義させるもの、2. メタデータ推論によって仮想タグを自動提案するもの。
いずれも手動タグ付けから見れば大きな前進です。しかし、どちらも共有GPUの内側までは覗けません。LLMゲートウェイを通ったトークンを、それを発生させた顧客やユーザーまで辿ることもできません。ボトルネックはツールではなく、方法論そのものにあります。
メタデータを頼りに配賦を再構築しようとするアプローチは、すべて同じ壁にぶつかります。実際に消費が起きているレイヤーには、そのメタデータが存在しないからです。
カーネルレベルでの計測は、単なる技術的な細部の話ではありません。現代のAIインフラの全領域にわたって完全な配賦を実現できる、唯一のアーキテクチャなのです。
Tokenomics こそが正しいフレームである理由
この新しいアプローチを通じて、私たちは Tokenomics というカテゴリーの立ち上げを積極的に後押ししています。これは非常に明確な概念です。いわゆる「AIコスト管理」ではありません - 業界にはその話題があふれていますが、その多くはクラウドFinOpsの語彙を新しい請求項目に当てはめ直しただけのものです。
Tokenomics とは、各トークンが自社ビジネスにとって実際にどれほどの価値を持つのかを見極める規律です。誰が消費し、何を生み出し、その支出が成果に見合っていたのか - それを問うものです。
そのためには、トークン単位の配賦が欠かせません。アカウント単位でも、チーム単位でもなく、トークン単位です。ある顧客セッションが3つのモデルにまたがって47,000トークンを消費し、そのうち31,000トークンが更新率の80%を左右する機能で使われ、残る16,000トークンがまだ本番投入前の実験機能で使われていた - ここまで解像度を持って把握する必要があります。どこに投資し、どこから手を引くかを賢く判断できるのは、こうしたデータがあってこそです。
そのデータには、タグ付けでは辿り着けません。SDKでも辿り着けません。実際に消費が発生するレイヤーで計測して、はじめて手が届くのです。
Linux Foundation は先日、FinOps Foundation と連携し、AIトークンエコノミクスに関するオープンな業界標準を策定するために Tokenomics Foundation を立ち上げる意向を発表しました。FinOps Foundation エグゼクティブディレクターであり、DoiT の緊密なパートナーでもある JR Storment は、率直にこう語っています。問題に名前を付けることと、それを解決することは違う、と。
その通りです。このカテゴリーは、名称と制度上の拠り所を得ました。Attribute™ は、それを実運用に落とし込む計測レイヤーです。
なぜ DoiT なのか、そしてなぜ今なのか?
DoiT はこれまで、27カ国4,500社のお客様について、200億ドルを超えるクラウド支出を管理してきました。コンピュート最適化、commitments 管理、Kubernetes のコスト配賦 - 主要なクラウドコストのカテゴリーが登場する場面を、私たちはそのつど目の当たりにしてきました。適切な計測基盤を早期に据えたチームは、その後のあらゆる意思決定の質を高められます。逆に、請求額が膨らむまで配賦を先送りしたチームは、初日から手にできたはずの文脈を再構築するのに何年も費やす羽目になります。
AI支出はこれまでのどのカテゴリーよりも急速に伸びています。当社が500名の財務リーダーを対象に行った調査では、企業の79%がすでにAIコストの超過を経験しており、**AIのROIを大きなボトルネックなしに正確に算出できると答えたのはわずか15%**にとどまることが分かりました。適切なツールセットを整えるタイミングは「今」であって、次の想定外の請求書が届いてからでは遅いのです。
もう一つ挙げておくべき兆しがあります。AIが実験段階から本番インフラへと移行するなかで、問いの中身も変わってきました。「いくら使っているのか」ではなく - 「顧客1社あたりの提供コストはいくらか」「マージンを圧迫しているAI機能はどれか」「成果を出せていないのに支出しているエージェントはどれか」といった問いです。取締役会もCFOも、こうした問いを投げかけています。アカウント単位の支出データからは、アカウント単位の答えしか出てきません。カーネルレベルの配賦 - 顧客ごと、エージェントごと、機能ごと - こそが、意思決定を実際に動かす答えを生み出します。
だからこそ、私たちはこれを構築しました。そして今、DoiT から皆さまへお届けします。
Attribute™ について
インストールは15分。計装は不要。その日のうちにトークンエコノミクスが手に入ります。ご自身の環境で Attribute™ の動きを確かめてみたい方は、こちらからデモをご予約ください。