トークンとクラウド支出の間に欠けている指標

問題はAIチームにコストデータが不足していることではありません。トークンダッシュボードとクラウド請求書が異なるシステムを示し、所有チームも異なるため、両者を確実に結びつける方法がありません。

サポートエージェントは、5回のモデル呼び出し、1回の検索ステップ、2回のツール呼び出し、そしてリトライを経て1件のチケットを解決することがあります。ビジネス側は1件の完了したケースとして記録しますが、インフラ側は多数のリクエスト、ポッド、メモリ、アクセラレータ時間、共有サービスとして散在した記録を残します。これらの記録が一致するまで、コスト最適化はある程度の推測に過ぎません。

トークン指標とクラウド請求書が異なるストーリーを語る理由は何ですか？

トークン数は有用です。モデルが受け取り返したテキスト量を示し、プロンプトやモデル、ルーティング選択を比較する際に役立ちます。しかし、モデル呼び出しの前後で何が起きたか、検索やツール使用にどれだけの計算資源が使われたか、失敗した試行がいくつあったか、最終結果が実際に有用だったかは示してくれません。

The State of FinOps 2026 は、AI が従来の FinOps 業務に急速に浸透した様子を示しています。回答者の 98% が現在 AI 支出を管理しており、2025 年の 63% と比べて大幅に増加しています。しかし、予算項目が増えても、どのワークフローが費用を消費したのか、なぜかは依然として不明です。

トークン数はほぼ同じでも、実行フローは大きく異なることがあります。たとえば、ある文書処理ジョブは単一のモデルリクエストで完了するかもしれませんが、別のジョブは複数のストアからコンテキストを取得し、外部サービスを呼び出し、別モデルにフォールバックし、ユーザーが目にしない失敗した検証チェックの後に再度文書を処理することがあります。トークン総数は似ていても、実行経路は全く違います。

Unite.ai はすでに トークン数が自動的にビジネス価値を表さない理由 を検証しています。次のステップは、これらのトークン数をそれらを生成したワークロードに結びつけることです。そうしなければ、チームはトークンあたりのコストは改善できても、完了したタスクあたりのコストは悪化させてしまう可能性があります。

完全なコストチェーンはどのような形ですか？

有用なコストチェーンは、ビジネスが重視する成果から始まります。たとえば、解決されたサポートケース、処理された文書、受け入れられたコード変更、完了したエージェントワークフローなどです。その下にあるすべての要素は、システム全体で追跡可能な ID を持つ必要があります。

アプリケーション層が最初の接続点となります。リクエスト ID、トレース ID、ワークフロー名、または会話 ID が、複数のモデルやツール操作をひとつの作業に結びつけます。このスレッドがなければ、10 件の関連イベントは 10 件の無関係な課金として見えてしまいます。

The OpenTelemetry conventions for GenAI agents は、この層のための新興語彙を提供します。操作、プロバイダー、要求されたモデル、エージェント、会話、トークン使用、ツール実行、エラー、ワークフローをカバーしています。これらの規約はまだ開発中と位置付けられているため、チームは完成した普遍的標準として扱うべきではありません。ただし、相関問題を具体化する上で有用です。

次にインフラ層です。AWS の split cost allocation data for EKS は、Kubernetes ポッドに対して共有コンピュートとメモリコストを割り当て、クラスター、ネームスペース、デプロイメント、ノード、ワークロード名、ワークロードタイプなどの詳細を公開します。加速インスタンスが対象の場合、GPU、Trainium、Inferentia の予約情報も含まれます。

これがチェーンのもう片方です。トレースはアプリケーションが何をしようとしたかを説明し、Kubernetes の割り当てはどのリソースが作業を担ったかを示します。Unite.ai の deploying and monitoring LLMs on Kubernetes ガイドは、リソース割り当て、スケーリング、可観測性を含む広範な本番コンテキストを提供します。

結合は偶然に起こりません。チームは、アプリケーションテレメトリとワークロードラベル、割り当て記録、あるいは別のマッピング層を結びつけるのに十分長く存続する安定した識別子が必要です。顧客データを Kubernetes タグに入れるべきではありません。ワークフローカテゴリ、サービス、機能とそれが消費したリソースを安全に結びつけられる低カーディナリティの識別子をどれにするか、チームで決める必要があります。

アプリケーションコンテキストが整ったら、チームは tracking Kubernetes costs by workload を開始し、ネームスペース、CPU、メモリ、GPU 使用量を実行された作業に紐付けられます。これだけではワークフローがビジネス価値を創出したかは分かりませんが、インフラ側の計算に具体的な根拠が得られます。

ビジネスが信頼すべき単位指標はどれですか？

すべてのチームが使用すべき単一の AI コスト指標は存在しません。トークンあたりのコストはモデル消費の質問に答え、ポッドあたりのコストはインフラ割り当ての質問に答えます。どちらもプロダクトオーナーに機能が費用対効果を持つかは示しません。

最適な分母は、ビジネスが明確に定義でき、プロダクトチームが影響を与えられる最小の成果です。サポート業務では解決済みケースあたりのコストを追跡し、文書システムでは正常に処理されたファイルあたりのコストを、コーディングアシスタントでは提案ではなく受け入れられた変更あたりのコストを測ります。

成功は計算式を変えます。

試行あたりのコストが低くても、失敗が頻発し、検証が繰り返され、人手レビューに多くのケースが送られると高コストになります。そこでチームは「試行コスト」と「完了コスト」を分離し、可能であれば「受け入れ成果あたりのコスト」を測るべきです。後者は、システムが生成したがビジネスで活用できなかった作業を含むため、最も有用になることが多いです。

エージェントシステムは、実行ごとにパスが変わるため、さらに複雑になります。Unite.ai の the economics of scaling agentic AI workloads の分析は、ルーティング、ツール呼び出し、リトライ、ワークフロー単位の帰属を扱っています。これらの動作はリソースを消費する限り、最終ユーザーが 1 つの回答だけを見る場合でも単位指標に含める必要があります。

指標は完璧にはなりません。共有サービス、キャッシュ結果、バッチジョブ、遅延処理などが帰属を曖昧にします。エンジニアがどの層を調査すべきかを示す、誤った精度よりも意思決定に役立つ概算の方が価値があります。

数値の所有者は誰ですか？

最も難しいのは組織的な側面かもしれません。ML チームはモデル呼び出しと評価を理解し、プラットフォームチームはワークロードとクラスターの挙動を把握し、FinOps は請求データと割り当てルールを管理し、プロダクトチームはどの成果が重要かを知っています。

全体のチェーンを所有するチームは存在しません。

このため、どのダッシュボードが正しいかについて予測可能な議論が生まれます。ML チームはトークン使用量の減少を指摘し、プラットフォームチームは GPU 時間の増加を見て、プロダクトチームは完了タスクが減少したことを指摘します。これら三つの観測は同時に正しい可能性があります。共有指標はそれらの関係性を説明しなければなりません。

実行可能な出発点は、明確な完了イベントを持つ 1 つの本番ワークフローです。安定した識別子を付与し、そのコンテキストをモデルとツールのトレースに持ち込み、Kubernetes 上で実行されているサービスやワークロードにマッピングし、ビジネス側の分母を一つ選択します。その上で、数値が予期せず変動したときにチームを集めます。

このレビューは洗練されたダッシュボード以上に重要です。急激な増加は、プロンプトが長くなったり、新しいフォールバックパスが導入されたり、GPU 容量が過小利用されたり、オートスケーリングポリシーが変更されたり、AI 機能により多くの作業が送られた結果として起こります。原因はそれぞれ異なるオーナーに属します。

自動化は後回しにすべきです。レコメンデーションエンジンは受け取ったラベルと閾値に基づいてしか行動できず、誤った分母は効率的なシステムを無駄に見せたり、ユーザーが拒否する安価なワークフローを報酬したりします。チームは、モデルの挙動とアプリケーション設計、インフラ割り当てを区別できるだけの共有可視性を確保してから、システムに自動的に結果を適用させるべきです。さもなければ、自動的なコスト修正が容量を削減し、レイテンシを上げ、費用を目に見えにくい場所へ移す恐れがあります。

コストチェーンは共有されなければならない

AI コスト管理は、すべてのチームが自分の見える層だけを最適化し続ける限り、断片的なままです。トークン、トレース、ポッド、アクセラレータ、請求書は競合する測定基準ではなく、同じコストチェーンの構成要素です。

それらを結びつける企業は、初日から完璧な数値を得られるわけではありません。重要なのは、チームが高額な請求を引き起こしたワークフローをたどり、何が変わったかを把握し、結果がコストに見合うかどうかを判断できるかどうかです。