FinOpsは、クラウドコスト管理の実践的な指針をチームにもたらしました。リソースにタグを付け、ユニットエコノミクスを追跡し、エンジニアリングと財務が同じ数字で説明責任を負えるチャージバックモデルを構築する——この手法は確かに機能し、成熟したクラウド組織の多くが今日、何らかの形で運用しています。
しかし、AIインフラはこの指針を破綻させつつあります。そして多くのチームは、その破綻がどれほど根本的なものかを、まだ十分に受け止めきれていません。
今日における「FinOps for AI」とは
FinOps for AIは、クラウド財務管理の規律を機械学習および生成AIのワークロードへ自然に拡張したものです。狙いは従来のFinOpsと変わりません。支出を、それを生み出したチーム・プロダクト・顧客に紐づけ、財務とエンジニアリングが同じ数字をもとに意思決定できるようにする、というものです。変わったのは、その足元にあるインフラです。この領域のインフラに馴染みがなければ、まずLLMが実際にリクエストを処理する仕組みを押さえておくと理解が進みます。
実務上、FinOps for AIはいくつかの中核機能でカバーされており、いずれも従来のFinOpsの手法を新たなワークロードに向け直したものです。
コスト配賦。 VMにタグを付けるのと同じ要領で、GPUインスタンスにタグを付ける。APIキー、モデル、プロジェクトをチーム・プロダクト・顧客にマッピングする。Kubernetesのネームスペースに対して行うのと同じオーナーシップマップを、トレーニングクラスタにも構築する。
ショーバックとチャージバック。 モデル学習の実行にいくらかかったのか、ある機能の推論コストが先月どうだったのかをチームに示すレポートを作成する——コンピュートやストレージについて長年行われてきたショーバックと同じ発想です。
ユニットエコノミクス。 生の支出額を、ビジネスが動ける数値に翻訳する。推論あたりコスト、アクティブユーザーあたりコスト、機能あたりコスト——トランザクションあたりコストやリクエストあたりコストに長年適用されてきた考え方と同じです。
予算、アラート、異常検知。 チーム別・モデル別にしきい値を設定し、トークン消費やプロンプト長が想定外に急増した際に通知を受け取る。クラウドコスト管理で標準となっている予算・異常検知ツールと同じ発想です。
ガバナンスとポリシー適用。 誰が、どのモデルで、いくらまでの範囲でリソースを立ち上げられるかを定義する——リソースクォータやタグ付けポリシーのAI版です。
一定範囲のAIワークロードでは、このアプローチは今でも十分に機能します。オーナーが明確な専用トレーニングクラスタ。単一プロダクトのためのシングルテナント推論エンドポイント。呼び出しパターンが予測可能で追跡可能なモデル。タグを付け、追跡すれば、それで完了です。
通用する領域と、通用しない領域
問題は、そうした整った形をしていないワークロードから始まります。そして今、そちらの方が多数派になりつつあります。
共有インフラがオーナーシップモデルを崩す
マネージド型のモデルAPIアカウントは、日常的に数十のチームからのリクエストを、一つの請求行で処理しています。請求書そのものにチーム単位の境界は存在せず、事後にメタデータから再構築するしかありませんが、そのメタデータの信頼性はまちまちです。共有GPUクラスタは複数プロダクトの推論を同時に実行しており、コンピュートサイクルはどんなタグでも見通せないレベルで交錯しています。
ゲートウェイがタグ付けの前提となるシグナルを剥ぎ取る
LLMゲートウェイは、エージェント、自動化パイプライン、人間のユーザーからのリクエストを一本の外向き通信に集約します。その過程で、呼び出し元のアイデンティティは、プロバイダーに届く前に取り除かれてしまいます。リクエストがモデルに到達する頃には、チームや機能に紐づけるためのコンテキストはすでに失われていることがほとんどです。上流で付けたタグは、この経路を越えて生き残れません。
エージェント型ワークロードは、SDKで包まれていないコストを生み出す
エージェント型ワークロードはサブエージェントを次々に生成し、コンピュート、メモリ、ネットワーク、データベース負荷といった実インフラコストを引き起こしますが、それらは元のAI請求項目とは何の関係も持ちません。連鎖を開始したリクエストへと遡って結びつけるタグも命名規則も存在しません。計装を組んだ時点で、その連鎖は想定されていなかったからです。
計装はAIインフラの速度についていけない
カバレッジの問題は、話の半分に過ぎません。AIワークロードは、計装が追いつけないペースで動きます。エージェントは一晩で1,000のサブエージェントを生み出しかねません。エンジニアリングが新しい呼び出しパターンを特定し、SDKで包み、アップデートをリリースした頃には、請求書はすでに届いています。これは、より優れたガバナンスや厳格な命名規則で解決できるタグ付け規律の問題ではありません。AIインフラが実際にどう動くかというアーキテクチャ上の現実であり、FinOpsの実践がどれほど規律正しくても関係なく発生します。
「オーナー不明の支出」問題
AIコストプログラムに取り組んで半年経ったFinOps実務者に話を聞けば、誰もが同じような話をします。前月比で40%成長している請求行があるが、オーナーが誰にもわからない。タグは3チームで共有されているサービスアカウントを指しており、VM向けに機能していた命名規則は推論エンドポイントには適用されなかった。誰かが手作業でオーナーシップを再構築するスプレッドシートを作ったが、完成した時点ですでに古くなっている——。
その支出はオーナー不在なのではありません。「未帰属」なのです。なぜなら、それを見つけ出すために使われた手法が、動かず、共有されず、ランタイムで子プロセスを生成することのないインフラのために作られたものだからです。AIインフラは、そのすべてを行います。
FinOps for AI と 従来型クラウドFinOpsの違い
| 従来型クラウドFinOps | FinOps for AI | |
|---|---|---|
| 主要な帰属手法 | タグ、命名規則、アカウント構造 | 共有インフラやゲートウェイが介在するまではタグが機能する |
| インフラの安定性 | 比較的静的で、オーナーシップは通常明確 | 極めて動的で、リクエストの途中でオーナーシップが移り変わることもある |
| カバレッジのギャップ | 主にタグ付け規律の問題 | アーキテクチャ的問題:そもそもタグを付けられないワークロードが存在する |
| 変化のスピード | 予測可能で管理された変更サイクル | 一晩で変わり得る。計装の更新が追いつかない |
| 破綻するポイント | エッジケース、レガシーリソース | 共有GPUクラスタ、LLMゲートウェイ、エージェント型・マルチエージェント型ワークロード |
次に来るもの:タグの下の層で計測する
AIワークロードのアーキテクチャが設計上、計装を無効化してしまうのであれば、計測すべき層は計装ではありません。代わりに、スキップも剥ぎ取りも追い越しもできない場所——カーネルから計測するのです。
これがAttribute™ by DoiTを支えるアーキテクチャです。OS内部にeBPFセンサーを配置し、実際の消費量——トークン一つひとつ、モデルリクエスト一つひとつ、GPUサイクル一つひとつ——を発生と同時に観測し、各単位を担当するプロセス、コンテナ、リクエストにマッピングします。タグも、SDKも、コード変更も不要です。さらに、そのデータをAnthropic、OpenAI、Google Gemini、AWS Bedrockのプロバイダー請求データと突合し、キャッシュ、推論、入力、出力の各トークンを自動で分割します。
この層こそ、Tokenomicsが実運用に載る場所です。トークンレベルの経済性を自動で帰属させる——タグ付けでは決して届かなかったワークロードに対して。タグも、SDKも、コード変更も要らないTokenomicsです。
なぜ今、これが重要なのか
Sapio Researchが実施した500名の財務リーダーへの調査によると、企業の79%がすでにAIコスト超過を経験しており、**AIのROIを大きなボトルネックなく算出できるのはわずか15%**にとどまることが分かりました。このギャップは、まだ着手できていないプロセス上の課題ではありません。解決には別の層が必要な、計測の問題なのです。
DoiTはこれまで、27か国4,500社の顧客について、80億ドルを超えるクラウド支出を管理してきました。私たちは、コンピュート最適化、コミットメント管理、Kubernetesのコスト配賦といったあらゆる主要コストカテゴリで、同じパターンを繰り返し見てきました。計測の基盤を早期に整えたチームは、その後のあらゆる意思決定の質を高められます。先送りにしたチームは、初日から手にできたはずのコンテキストを、何年もかけて再構築することになります。
私たちは、Tokenomics Foundation、そしてJR StormentとFinOps Foundationとともに、業界にとってのこの基盤のあるべき姿を定義する取り組みを進めています。
FAQ
FinOps for AIとは何ですか?
FinOps for AIとは、コスト配賦、ショーバックとチャージバック、ユニットエコノミクス、予算、異常検知といったクラウド財務管理の実践を、機械学習および生成AIのワークロードに適用することを指します。従来のクラウドインフラで機能してきた規律を、新しいカテゴリの支出へと拡張したものです。
なぜAIのコスト帰属にタグ付けが通用しないのですか?
タグ付けは、リソースとそのオーナーの間に安定した追跡可能な関係が存在することを前提としています。共有GPUクラスタ、LLMゲートウェイ、エージェント型ワークロードは、その関係を設計上壊してしまいます。ゲートウェイは呼び出し元のアイデンティティを剥ぎ取り、共有インフラには明確なオーナーシップの境界がなく、エージェントの連鎖はそもそもタグを付けようがないコストを次々に生み出します。
FinOps for AIとTokenomicsの違いは何ですか?
FinOps for AIは、AIワークロードにコスト管理の規律を適用する実践そのものを指します。Tokenomicsはその基盤となる計測の規律であり、各トークンにどれだけの価値があり、誰が消費し、その支出は成果に見合っていたのかを——ワークロードにタグ付けができるかどうかに関わらず——理解するためのものです。
計装なしでFinOps for AIは実現できますか?
はい。eBPFのような技術を用いたカーネルレベルの計測は、タグやSDKに依存せず、OSレベルで消費量を観測します。これにより、共有GPUクラスタやゲートウェイ経由のトラフィックなど、従来の計装では到達できないワークロードに対しても帰属が可能になります。
組織内でFinOps for AIは誰が担うのですか?
企業によって異なりますが、FinOps for AIは通常、既存のFinOpsチームまたはクラウドコストチーム、プラットフォーム/インフラエンジニアリング、そして近年ではAIプロダクトを直接構築しているチームの交点に位置します。AI支出は従来のクラウド支出よりも速く動き、より多くのチームに関わるため、この実践では従来のFinOps以上に、財務とエンジニアリングの緊密な連携が求められます。どちらか一方だけでは全体像が見えないからです。
AIのコスト配賦は、クラウドのコスト配賦とどう違うのですか?
クラウドのコスト配賦は一般に、比較的安定したオーナーを持つリソース——インスタンス、バケット、ネームスペース——に支出をマッピングします。AIのコスト配賦では、単一リクエストの内部でオーナーシップの境界を越えて発生する消費まで扱う必要があります。複数プロダクトに提供されている共有GPU、複数チームのトラフィックを取り回すゲートウェイ、直接触れていないサービスにコストを発生させるエージェントなどです。目的は同じでも、そこにたどり着くために必要な仕組みはまったく違います。
FinOps for AIのプログラムでは、どのような指標を追跡すべきですか?
多くのプログラムでは、トークンあたりコスト、推論あたりコスト、機能あたりコスト、顧客またはアカウントあたりコストといった指標に加え、プロバイダーごとに異なる入力・出力・キャッシュ・推論トークンの内訳を組み合わせて追跡します。適切な組み合わせは、対象がエンジニアリング(通常はワークロード単位の詳細を求める)か、財務(通常は売上や更新データと紐づけたアカウント・機能単位のロールアップを求める)かによって変わります。
本当のAIコスト・トゥ・サーブを可視化しませんか?
インストールは15分。計装は不要。トークン経済性は当日中に。