OpenAIへのトラフィックが LiteLLM、Portkey、Kong AI Gateway、または社内ゲートウェイを経由しているなら、コスト按分モデルはすでに破綻しています。
上流の呼び出し元は、まさに課金が発生するその地点で、すべて単一のワークロードIDへとまとめられてしまいます。プロバイダーの請求書も、タグベースのFinOpsツールも、クラウドコスト管理プラットフォームも、そのコストをサービス・チーム・機能・顧客単位に分解し直すことはできません。
これがLLMゲートウェイの死角です。DevOpsおよび FinOps for AI における中核的な課題として急速に顕在化しており、トークンベースの支出と共有インフラが、従来のコスト按分モデルを機能不全に陥らせています。
これはクラウドコスト按分の領域で最も急速に広がりつつあるギャップであり、KafkaやSnowflakeをはじめとする共有システムでチームが直面してきたのと同じ構図です。違いは、支出がトークンベースであり、急拡大しており、プロダクトの利用状況と直結している点にあります。
なぜゲートウェイでチェーンが途切れるのか
ゲートウェイを介した呼び出しには、2つのホップがあります。
upstream-svc ──► llm-gateway ──► api.openai.com
本当に把握したいアイデンティティ(サービス、テナント、機能、顧客)は、最初のホップに存在します。
一方、課金対象のイベントが発生するのは2番目のホップ、すなわち トークン使用量 です。
プロバイダーの請求書に見えるのはゲートウェイのIDだけです。いったん集約されてしまうと、下流のシステムでは元に戻せません。
標準的なデータソースはすべて、この集約より後ろに位置しています。
- プロバイダーの請求エクスポート:APIキーまたはプロジェクト単位のコストしか見えず、サービス単位では把握できません
- クラウド請求( CUR、GCP、Azure):OpenAIの支出を捉えられないか、ゲートウェイに帰属させてしまいます
- タグベースのFinOpsツール:支出が発生したリソース、つまりllm-gatewayにコストを割り当ててしまいます
その結果、使えるユニットエコノミクスは得られず、共有インフラのコストバケットだけが残ります。
実際にはどう見えるのか
| ビュー | デフォルト(集約された状態) | ビジネスに必要な視点 |
| ワークロード別コスト | llm-gateway = $X | トークン使用量に基づき実サービス単位に分解 |
| 顧客別コスト | 共有インフラ扱い | 顧客ごとのAIコスト |
| 機能別コスト | AIが無料に見える | 機能ごとの実際のAI COGS |
| プライシングの示唆 | コスト全体に対する比率 | 顧客レベルの収益性 |
これは単なる可視化の問題ではありません。次の領域に直接影響します。
- 顧客収益性の分析
- プライシングの意思決定
- 機能単位のROI
- クラウドコスト最適化
タグ付けとログでは解決できない理由
多くのチームはヘッダーの伝播とログでこの問題に対処しようとします。ステージングでは動きます。しかし本番では破綻します。
1. 伝播はいずれ崩れる 新規サービス、リトライ、代替経路が追加されるたびに按分の抜けが生まれます。時間が経つほど、支出のうち「不明」に分類される割合が増えていきます。
2. ログはコスト管理システムではない サンプリング、保持期間の制約、取り込みの偏りによってデータセットは歪みます。ログと請求データを突き合わせるパイプラインは脆くなりがちです。
3. 共有された呼び出しはタグでは分割できない リトライ、バッチ処理、キャッシング、ファンアウト型のワークフローでは、複数の呼び出し元が1つのプロバイダーリクエストを共有します。タグでは公平にコストを配分できません。それができるのはトークンレベルの会計だけです。
4. ログは「見えない部分」を捕捉できない 失敗した呼び出し、リトライ、フォールバックはインフラコストを押し上げますが、ログでは十分に捉えきれません。
タグ付けに頼らずマイクロサービス間で共有クラウドコストを配分する方法を探しているチームが行き詰まる理由は、まさにここにあります。タグ付けはギャップを狭めるだけで、埋め切ることはできません。
ランタイム按分:再構築ではなく、リクエストそのものを観測する
唯一信頼できるアプローチは、請求データから逆算するのではなく、ランタイムでコストを直接観測することです。
Attribute™は、ゲートウェイと並走するeBPFセンサーによってリクエストの両側を観測します。
- 最初のホップ: 上流サービス → ゲートウェイ(アイデンティティが保持されている)
- 2番目のホップ: ゲートウェイ → プロバイダー(トークン使用量とコスト)
両者を突き合わせることで、実際のトークン消費量に基づき、プロバイダーコストを発生元のワークロードへとマッピングし直します。
これによって実現できること:
- 発生元ワークロード別のKubernetesコスト可視化
- 顧客レベルのAIコスト按分
- 機能レベルのAI COGS
- リアルタイムのコストシグナル
- タグ付け不要の正確なクラウドコスト配分
押さえておきたい実装上のポイント
- 読み取り専用センサー
- データが環境外に出る前にPIIとシークレットを除去
- TLSとJWT認証による最小限のOpenTelemetryイベント
- 既存のOTelコレクターと連携可能
- サイドカー不要・コード変更不要・ゲートウェイ設定変更不要
結果として、llm-gatewayというコストバケットは消え去ります。OpenAIに支払う1ドル1ドルが、ワークロード、チーム、機能、顧客へと紐づきます。
評価チェックリスト
AIや共有インフラ向けのFinOpsツールを評価する際は、以下の点を確認してください。
- タグの伝播に頼らずに、ゲートウェイコストを発生元のワークロード別に分解できるか?
- AIコストを顧客単位・機能単位で按分できるか?
- ライブトラフィックを見るのか、それとも請求エクスポートを読むだけなのか?
- 共有された呼び出しをトークン使用量に応じて比例配分できるか?
- テレメトリを自社環境内に留められるか?
多くのツールは、請求イベントの後からデータを扱い始めるため、複数の項目でつまずきます。
LLMゲートウェイは、支出が始まるまさにその地点でコスト按分を断ち切ってしまいます。FinOpsモデルが請求データを起点にしている限り、最も重要なシグナルはすでに失われているのです。それを取り戻す唯一の方法は、システムが稼働している最中に観測することです。ここに、コストを推定するにとどまるか、真に理解できるかの差が生まれます。