クラウド・AIコスト配賦の完全ガイド

状況	請求データで十分か?
シンプルなシングルテナントインフラ	はい
小規模チーム、単一のクラウドアカウント	はい
Kubernetesマイクロサービス	通常は不十分
マルチテナントのSaaSプロダクト	いいえ
共有RDS、Kafka、Elasticsearch	いいえ
顧客別・機能別のAI推論コスト配賦	いいえ
顧客マージン分析	いいえ
セルフマネージドインフラ(EC2上のデータシステム)	いいえ
NATゲートウェイ・データ転送の配賦	いいえ

ご自身の環境が上表の下半分に当てはまるなら、請求データはあくまで出発点にすぎません。それ自体はコスト最適化ツールではないのです。特にAI機能を運用しているチームにとって、このギャップは深刻です。トークン支出はAIコストの一部にすぎず、ベクターデータベース、オーケストレーション層、下り通信料、そしてモデル呼び出しを取り巻くセルフマネージドインフラが、機能全体の支出の40〜60%を占めることも珍しくありません。トークンの請求書しか見ないツールは、その大半を取りこぼしてしまいます。

クラウド請求は、もともと静的なモデル、つまり「リソースをプロビジョニングし、タグを付け、月末にタグを読む」という前提で設計されていました。

Kubernetesはその前提をことごとく崩しました。Podは短命で、サービスはチームやテナントの境界を越えてインフラを共有します。1つの顧客リクエストが、応答が返るまでに複数のサービスをまたぐこともあります。結果として、「誰が何を消費したか」を捉えるタグは存在せず、あるのは「誰がリソースを所有しているか」だけ。しかし、所有と消費はイコールではありません。

多くのKubernetesコスト監視ツールは、これに対してクラスターレベル、CPU割り当て、メモリリクエスト、Pod稼働時間といった単位で測定することで対応しています。それらは有用なコンテキストではあっても、コスト配賦にはなりません。RDS、Kafka、Snowflake、データ転送はクラスターと並ぶ大きなコストドライバーでありながら、十分に配賦されていないことがよくあります。ノードやPodのレベルで止まってしまうツールでは、請求書の大半が未配賦のまま残るのです。

そこから4つの失敗が、判で押したように続きます:

• タグ付けそのものがプロジェクト化する。 タグは所有者を捉えるだけで、共有リソースの消費を配賦することはできません。プロジェクトは何カ月もかかり、最後までやり切れないのが常です。
• 共有コストは当て推量で割り振られる。 静的な割合や均等分割。スプレッドシート上では説明可能でも、正確ではありません。
• 顧客別配賦が欠落している。 総支出は見えても、テナントごとのコストは見えません。儲かっている顧客も、そうでない顧客も、区別がつかないのです。
• データが届くのが遅すぎる。 請求データは月末に締められます。ムダはすでに発生した後です。

ランタイム配賦は、まったく別のデータソースから出発します。すなわち、システム内で「今この瞬間、実際に起きていること」です。

Attribute™はEKSノード、ECSタスク、EC2インスタンス、Auto Scalingグループといったコンピュートインフラ上にeBPFセンサーをデプロイします。eBPF(extended Berkeley Packet Filter)は、Linuxカーネルの技術であり、カーネルレベルでのシステム動作をサンドボックス化された安全な形で観測できるものです。センサーはネットワークパケットを読み取り専用で検査するため、パフォーマンスへのオーバーヘッドはなく、アプリケーションコードの変更も不要です。

センサーが観測するもの:

• サービス間のすべてのネットワーク呼び出し
• どのマイクロサービスが、どのデータベースを、どの頻度で呼び出しているか
• 共有インフラが実際にどのように消費されているか
• どのAI APIエンドポイントが、どのworkloadから、どのトークン量で呼び出され、どの顧客・機能・エージェントに紐付くか
• 顧客識別子を含むHTTPヘッダー
• データ転送の宛先と転送量

これらの観測データから、Attribute™はライブなサービス依存グラフを構築します。どのサービスが、どのリソースに、どの程度の強度で、どの比率で依存しているのかを把握するのです。このグラフこそが配賦モデルの本体になります。

共有RDSインスタンスにコストが発生した場合、モデルは静的なルールを当てはめるのではなく、その期間中に各サービスから発行されたデータベースクエリの実際の分布を見て、実消費に比例した形でコストを割り当てます。

新しいサービスは出現した時点で自動的に検出され、デプロイの変更に応じて依存関係も更新されます。静的なサービスカタログも、手動の再設定も必要ありません。

導入事例:Island

状況: Islandは、エンタープライズブラウザーという新カテゴリーを50億ドル評価額で切り拓き、数百社のエンタープライズ顧客へと拡大中です。同社のAWS環境では、共有EKS、RDS、DynamoDBを利用し、AZ間のデータ転送量も大きなものになっています。マルチテナントアーキテクチャでは顧客にタグを付けられないため、タグ付けはそもそも選択肢になりませんでした。

導入前: 顧客ごと、機能ごとの真のコストが見えず、価格設定、成長モデリング、GTM意思決定を実際のコストデータで裏付けることができませんでした。クラウドネイティブのツールもサードパーティのプラットフォームも、請求書やチャートは表示できても、各顧客が実際にいくらかかっているのかには答えられなかったのです。

導入後: Attribute™は数日以内に、顧客別・機能別の正確なコストを算出しました。タグ付けもインストルメンテーションも、Engineersへの依頼も、一切不要でした。

運用面の変化: Engineering、プロダクト、GTMの各チームが、共通のコストソースをもとに動くようになりました。価格設定や成長モデリングの意思決定は、推測ではなく実消費データに基づくものへと変わりました。

「マルチテナント環境では、顧客にタグを付けることはできません。Attribute™によって、各顧客のコストと、そのコストを押し上げている要因が、ようやく見えるようになりました。」

– Omri Cohen, Director of Engineering Platform, Island

さらに読みたい方へ: 大手ワークマネジメントプラットフォームが赤字アカウント360件を発見した事例はこちら、セキュリティ企業が財務部門とエンジニアリング部門のレポート分断を解消した事例はこちらからご覧いただけます。

ユニットエコノミクスには、実際のユニットに対応したコストモデルが欠かせません。SaaS企業にとって、そのユニットは通常「顧客」です。

この問いに、請求データからは答えられません。請求書が示すのはリソースコストであって、どの顧客がそのリソースを、どの比率で消費したかは示さないからです。

Attribute™の顧客配賦レイヤーは、観測されたランタイムアクティビティを、HTTPヘッダー、workloadラベル、あるいはデータベース名やキュー名の命名規則から顧客識別子にマッピングします。いったんマッピングが確立されれば、モデル内のすべてのコストイベントは、それを引き起こした顧客に紐付けられます。

収益データと接続すれば、アウトプットは顧客レベルのP&Lになります。どのアカウントが利益を生んでいて、どのアカウントがそうでないのか、そしてその差はどの程度なのかが、明確になります。

この可視化から得られるもの:

• 損失が積み上がる前に、マージンがマイナスのアカウントを特定
• 請求サイクルが締まる前に、コストが暴走しているAI機能を検知
• プラットフォームチームに、共有インフラのチャージバックを説明できる数字を提供
• 推測ではなく実消費に基づいてエンタープライズ契約の価格を設定
• アーキテクチャ投資を、実データによる導入前後の比較で正当化
• 配賦手法をめぐる、財務とエンジニアリングの毎月の応酬に終止符を打つ

Time to value: センサーはKubernetes上にDaemonSetとしてデプロイされます。初期のworkload検出は数時間以内に完了し、意味のあるコスト配賦は数日以内に利用可能になります。タグ付けプロジェクトは不要です。

パフォーマンスへの影響: eBPFセンサーは読み取り専用で、カーネルレベルでサンドボックス化されています。トラフィックを傍受・改変することはなく、コンピュートへのオーバーヘッドは無視できるレベルです。

インテグレーション: Attribute™はコンピュートインフラ(EKS、ECS、EC2)上にインストールされ、アプリケーション層から他のクラウドリソースに向かうトラフィックを監視します。MongoDB Atlas、Snowflake、OpenAIなどのサードパーティSaaSプロバイダーも対象です。アプリケーションレベルのインストルメンテーションは必要ありません。

KubecostやCloudHealthを置き換えるのか? クラスターレベルのレポートでは足りないコスト分析を必要とするSaaS企業であれば、答えはイエスです。Attribute™は共有リソース配賦、顧客レベルのコスト・トゥ・サーブ、セルフマネージドインフラのカバレッジ、そして顧客・機能・エージェント単位のトークン配賦を含むAIコスト全体像の可視性において、既存ツールが見落としている周辺インフラ支出にまで踏み込みます。

ヒストリカルデータ: クラウド請求履歴はセットアップ時に取り込まれます。センサーのデプロイ前にチャージバック成果物が必要なチーム向けには、Attribute™はセンサーなしでも、顧客から提供された請求データをもとにレポートを生成できます。

対応環境: AWS、GCP、Azure。Kubernetes(EKS、GKE、AKS)、ECS、EC2。Snowflake、MongoDB Atlas、OpenAI、Anthropic、Amazon Bedrock、Azure OpenAI、Vertex AI。セルフマネージドのKafka(トピックレベルの粒度含む)、Elasticsearch、RabbitMQ。

セキュリティ: PII、認証情報、シークレット、APIキー、Cookieは、顧客環境からデータが出る前にすべて除去されます。送信されるのは最小限のイベントのみで、暗号化されたOpenTelemetry経由、JWT認証、TLS保護のもとで転送されます。生のパケットが送信されることは決してありません。テレメトリを自社のOpenTelemetryエンドポイント経由でルーティングすることも可能で、完全な監査体制を確保できます。

請求ベースのツールが問うのは「何が請求されたか」です。ランタイム配賦が問うのは「システム内で実際に何が起き、誰がそれを引き起こしたか」です。

プラットフォームを評価する購買チームにとって、本当に重要な問いに答えられるツールとそうでないツールを見分ける、5つの質問があります:

1. 初日から、タグなしで機能するか?
2. 共有リソースコストを、静的なルールではなく、観測された消費に基づいて配分できるか?
3. マルチテナントシステムで、顧客別にコストを配賦できるか?
4. セルフマネージドインフラや外部AI支出まで可視化できるか?
5. 請求サイクルが締まった後ではなく、サイクルの最中にコストシグナルを浮かび上がらせられるか?

AI支出が大きいチームであれば、6つ目の質問を加えてください。「トークンコストを、単なるAPIキー単位ではなく、特定の顧客・機能・エージェントに紐付けて配賦できるか」という問いです。請求ベースのツールは、これらの質問のいくつかに、特定の環境に限って、大規模なセットアップ投資と引き換えに、部分的に答えられるにとどまります。ランタイム配賦は、デプロイした時点でこれらすべてに答えます。