AIコスト配賦を「信頼できる数字」にする検証プロセス

「正しい」の定義から始める

配賦の仕組みを構築する前に、まずその結果がどのような問いに答えるためのものなのかを決める必要があります。

例えば:

• サービス提供にかかるコストは顧客単位でいくらか
• モデルのコストを最も押し上げているプロダクト機能はどれか
• 各AIエージェントの運用コストはいくらか
• インフラコストの原因となっている共有ワークロードはどれか
• 対象範囲内の支出のうち、現時点で配賦できない割合はどれくらいか

これらの問いは、配賦のそれぞれ異なる側面に関わるものです。ショーバックが目的であればチーム単位の粒度で十分かもしれませんが、顧客単位の可視化を実現するには、テナント識別子、機能に関する詳細、そしてランタイム識別子とビジネス上の名称とのマッピングが必要になります。

アウトプットを確認する前に、検証基準を文書化しておく必要があります。有効な検証計画には以下を明記すべきです:

• 対象となるワークロードとプロバイダー
• 可視化すべきディメンション
• 比較の拠り所となる信頼できる情報源
• 比較対象の時間枠
• 許容される差異
• 未配賦の支出の扱い

Attribute™は、ランタイムの消費量をチーム、ネームスペース、ワークロード、モデル、機能、環境、テナント、顧客といったさまざまなディメンションに割り当てます。重要なのは、考えられるすべてのラベルを収集することではなく、ビジネス上の問いに対応するディメンションを選ぶことです。

1. 範囲を限定したワークロードから始める

クラウド環境全体を一度に検証しようとしてはいけません。まずは小規模で代表的な一部分から始めましょう:

• 本番サービス1つ
• モデルまたはゲートウェイ1つ
• 顧客向け機能1つ
• Kubernetesネームスペース1つ
• 請求アカウントまたはプロジェクト1つ

範囲を限定することで不一致を特定しやすくなり、プラットフォームチームにとっては、今後拡張していくための基準となる結果も得られます。

最初のテストでは、想定されるアクティビティを独立して記録しておきます。比較に有用なデータには次のようなものがあります:

• プロバイダーの使用量データまたは請求データ
• LLMゲートウェイのリクエスト数・トークン数カウンター
• アプリケーションログ
• テナントまたは顧客の識別子
• Kubernetesワークロードのメタデータ
• GPUまたはコンピュートの使用率

すべてのシステムが同じ用語を使っている必要はありません。各システムが互いにどう対応しているのかを理解できれば十分です。

2. 配賦キーをランタイムで観測できることを確認する

配賦の失敗は、たいていコストの計算より前の段階で始まります。テレメトリーを収集する時点で、配賦キー、つまり、ある使用量を別の使用量と区別するために必要な識別子が欠落している場合があるのです。

対象とする各ディメンションについて、次の3つの問いに答えてください:

• 顧客、機能、テナントを示す識別子はどれか
• その識別子はリクエストパスのどこに現れるか
• ランタイムコレクターはそれを継続的に観測できるか

例えば、顧客識別子は認証済みリクエスト、ゲートウェイヘッダー、データベース接続属性、あるいはアプリケーション固有のフィールドに含まれているかもしれません。しかし、識別子がアプリケーションのメモリ内にしか存在せず、観測可能な境界を一度も通過しない場合は、別のインテグレーション手法やインストルメンテーション手法が必要になります。

だからこそ検証は、ダッシュボードに表示される合計値ではなく、ランタイムでキーを観測できるかどうかから始めるべきです。キーを確実に観測できなければ、レポーティングレイヤーをどれだけ丁寧に設定しても、下流の配賦は不完全なままです。

タグでは、共有GPUやゲートウェイを通過するAI支出を追跡できません。 ランタイムの可観測性がインストルメンテーションに勝る理由は、AI Features Have a Visibility Problemをご覧ください。 eBookをダウンロード →

3. 収集の境界を定める

Attribute™は、eBPF(extended Berkeley Packet Filter — 低オーバーヘッドの可観測性を実現するために設計されたLinuxカーネル技術)を用いてカーネルレベルでランタイムの消費量に関する情報を収集するため、アプリケーションコードやアプリケーションSDKの変更は不要です。ただし、収集の境界は依然として重要です。

以下を文書化してください:

• 対象となるクラスター、ホスト、アカウント
• 対象に含める/除外するワークロード
• サポートされるOSとカーネルバージョン
• 観測可能な境界に到達する前にトラフィックが暗号化されるかどうか
• 共有インフラが測定対象範囲に含まれるかどうか

配賦のモデリングを開始する前に、DoiTのオンボーディングプロセスでは、クラスタートポロジーの確認、カーネルとOSの互換性チェック、セキュリティ要件の確認、テレメトリーフローの確認を行います。エンゲージメントモデルの詳細については、Attributeの概要ドキュメントをご参照ください。

有効なカバレッジの記述は次のようなものです:

本検証の対象は、月曜0:00 UTCから火曜0:00 UTCまでの本番推論ネームスペース、セルフホスト型ゲートウェイ、および関連するGPUノードとし、開発トラフィック、バッチワークロード、既存のコネクションは除外する。

境界を明確に定めておけば、意図的に部分的にとどめた結果を不具合とみなしたり、測定していない領域のコストをゼロと考えたりすることがなくなります。

4. 識別子とビジネスのマッピングを作成する

ランタイムテレメトリーは多くの場合、技術的な識別子から始まります:

• Pod名
• コンテナID
• ネームスペース名
• モデルID
• APIキー
• テナントID
• サービス名

一方、財務チームやプロダクトチームには、理解しやすいディメンションが必要です:

• 顧客名
• プロダクト機能
• 事業部門
• 環境
• 料金プラン
• 担当チーム

マッピングを明確にし、記録として残してください。誰が責任者か、最終更新日はいつか、対応するビジネスレコードが存在しない識別子をどう扱うかを明記します。

マッピングテーブルには、例えば少なくとも次のような列を含めるべきです:

ランタイム識別子	ビジネスディメンション	責任者	適用開始日	検証ステータス
tenant-4821	Acme / Search Assistant	Product Platform	2026-09-01	確認済み
tenant-5177	ExampleCo / Document Review	AI Applications	2026-09-01	確認済み
tenant-unknown	未マッピング	Platform FinOps	2026-09-01	要調査

未マッピングの行は重要です。これを隠してしまうと、配賦が完全であるかのように見える一方で、カバレッジ改善に必要な証拠が失われてしまいます。

どの顧客に最もコストがかかっているかを知りたいですか? AWS、Google Cloud、Azureでそのまま使えるSQLを収録したCost Per Customer: A FinOps Field Guide to Multi-Tenant Cloud Attributionをご覧ください。 ガイドをダウンロード →

5. 同じアクティビティに対する3つの視点を突き合わせる

信頼できる検証では、少なくとも次の3つの視点を比較します:

• ランタイムアクティビティ — ワークロードが何を呼び出し、何を消費したか
• プロバイダーまたはゲートウェイの使用量 — トークン、リクエスト、コンピュートについてプラットフォームが報告する値
• 配賦済みコスト — その使用量がビジネスディメンションにどう割り当てられているか

比較は同じ時間枠で行い、タイミングのずれを考慮してください。請求データのエクスポートは遅延する可能性があり、ゲートウェイのカウンターはリクエストを異なる形で解釈するかもしれず、ランタイムテレメトリーはリトライやキャッシュされた呼び出しをプロバイダーの請求書とは異なる形で観測する可能性があります。

シンプルな指標が2つ役立ちます:

Coverage = attributed in-scope spend / total in-scope spend

Variance = absolute (source total - attributed total) / source total

全体の合計パーセンテージでは特定の顧客や機能に関わる深刻な問題が隠れてしまう可能性があるため、これらの指標はワークロード単位で日次で監視する必要があります。

不一致が見つかった場合は、すぐに配賦ルールを変更するのではなく、まず分類してください:

• 対象範囲の不一致
• 時間枠の不一致
• プロバイダー請求の遅延
• ランタイム識別子の欠落
• 未マッピングの識別子
• リトライまたは重複リクエスト
• キャッシュ処理または非同期処理
• 非対応のトラフィックパス

この分類のプロセスによって、照合作業が一連のエンジニアリングタスクへと変わります。次の例では、エッジケースのテストに進む前に、この照合を最後まで行う方法を示します。