Cloud Intelligence™
財務が信頼するレポートをつくる
このページはEnglish、Deutsch、Español、Français、Italiano、Portuguêsでもご覧いただけます。
About Devorah Klartag
Marketing director. 15+ years turning marketing vision into infrastructure that actually scales - GTM, demand gen, ops, and the AI-powered systems that keep the whole thing moving. At Attribute, I built the marketing function from the ground up and hit top-3 AI search rankings on competitive FinOps queries in ChatGPT, Perplexity, and Claude.
Previously: senior growth and marketing ops at D-ID (led the self-service studio launch that hit #1 Product of the Day on Product Hunt and landed coverage in TechCrunch, Fast Company, and Forbes), digital marketing at CyberProof, and $7M campaigns at McCann Tech for NICE and Amdocs. Earlier, hospitality marketing across NYC restaurants and cruise lines.
Ex-New Yorker in Tel Aviv. Still misses the bagels most.
My personal page何か月もかけてレポートやダッシュボードを構築してきました。チーム別のコスト、ワークロード別のコスト、事業部門別のチャージバック。エンジニアの目にはすべて正しく見えます。ところがレビューに参加した財務チームはこう尋ねます。「この数字、根拠を示せますか?」
答えは簡単ではありません。ツールの拠り所は、請求エクスポート、ルールエンジン、そしてカバレッジ70%のタグ。これでは、ビジネス上の意思決定や予測・見通しの根拠としては具体性が足りません。
PerfectScale™ for Kubernetes
Ready to optimize?
Get your free Kubernetes savings analysis
数字が通用しない理由
FinOpsツールは、クラウドプロバイダーが生成する請求ファイルを読み込み、ルールとタグで切り分け、その結果をダッシュボードに表示するために作られました。
一方、財務や経営層は別の角度から質問します。顧客Xへのサービス提供にいくらかかっているのか。自社のどの製品が利益を出しているのか。ほとんどのFinOpsツールは答えを出してくれます。しかし、監査に耐える答えを出せるツールはごくわずかです。
「ゴミ」と言われる本当の意味
ステークホルダーがコストレポートを「ゴミ」と呼ぶとき、それは自分が事実と知っていることと数字が合わないか、数字の導出過程が理解できないかのどちらかです。
実際には、原因はたいてい次の3つに集約されます。
かつては妥当だったが、古くなったルール。
配賦ルールが設定されたのは18か月前。3回の移行と2回の製品リブランドを経て、ルールが指すサービスやラベルは、もはや当時の意味を持っていません。ルールは一貫して実行されるため、ダッシュボード上の数字は一貫して見えます。しかし、ルールが今も正しいかどうかは誰も確認していません。誰もが「クリーンアップは他の誰かの仕事」だと思い込んでいたのです。
完全なカバレッジに達しなかったタグ。
タグベースのコスト帰属は、タグ付けされたリソースしかカバーできません。エンジニアリングチームがタグ付けしなかった30%は、集計から漏れるか、便宜的な按分で振り分けられます。財務から「未配賦のバケットには何が入っているのか」と聞かれたとき、正直な答えは「実支出のかなりの部分」です。AI推論はこの問題をさらに悪化させます。多くのチームは、モデル呼び出しをタグ付けする方法自体を確立できておらず、機能別や顧客別のタグ付けなど言うまでもありません。
モデル内の古いデータ。 古いアカウント、廃止されたサービス、終了した契約。それらの過去データがモデルに残ったままになっています。
製品P&Lの問題
FinOpsチームが財務の本当の質問——「このワークロードのコストはいくらか」ではなく「この製品のコストは、リージョン別、顧客ティア別でいくらか」——に答えようとすると、信頼の問題はさらに深刻になります。
この質問に答えるには、コストデータだけでは足りません。5つのリージョンで3つの製品を運用している顧客にとって、支出がどのKubernetesネームスペースに属するかはどうでもよいことです。重要なのは、その顧客が利益を生んでいるかどうか。それには、どのワークロードがどの製品を支え、どの顧客がどのワークロードを消費し、共有インフラがそれら全体にどう按分されるかを把握する必要があります。標準的なFinOpsツールでも、十分なタグ付けとルール作成で近似値は出せます。しかし近似値は、VPに「算出方法を説明してほしい」と言われた瞬間に崩れます。
財務が本当に求めているのは、顧客単位・製品単位のサービス提供コスト(cost-to-serve)です。固定費と変動費、SnowflakeやTwilioといったサードパーティSaaSの支出まで含め、取締役会に対して説明できる形式で。プライシングチームはマージン設定のために、財務はCOGS報告のために、プロダクトリーダーはどの機能がマージンを圧迫しているかを知るために、この数字を必要としています。
ほとんどのクラウドコストツールは「なぜAWSの請求額が増えたのか」に答えるのは得意です。しかし「この製品は儲かっているのか」に答えるようには設計されていません。
いま、同じ問題がAI支出からより速いペースで押し寄せています。LLM推論コストはEC2のようには振る舞いません。リクエスト駆動で、顧客ごとに発生し、急速に積み上がります。請求エクスポートは、先月BedrockやOpenAIにいくら請求されたかは教えてくれます。しかし、どの製品機能がそれを生んだのか、どの顧客ティアが消費したのか、スケール時にユニットエコノミクスが成り立つのかは教えてくれません。トークン量、モデル選択、プロンプト長——どれも請求明細の行には対応していません。財務は、クラウドのCOGSと同じようにAIのCOGSを問い始めています。データのギャップはまったく同じです。ただし、コストの動きが速いぶん、リスクはより大きくなっています。
Your cloud bill shouldn't be a mystery
Optimization, automation, expertise. In one platform.
現実を再構成することの限界
請求エクスポートに依存するツールには、すべて同じ構造的な限界があります。請求ファイルが教えてくれるのは「いくら請求されたか」だけ。なぜ発生したのか、どの顧客が引き起こしたのか、共有リソースが利用者間で実際にどう按分されるのかは分かりません。
Attributeは、請求ファイルではなく稼働中のシステムを読み取ります。コンピュートインフラに導入された超軽量のeBPFセンサーが、ランタイムデータを使い、ネットワークレイヤーで、どのワークロードがどのデータベースやサービスと通信しているかを観測します。コストの帰属は、「こう動くはず」というルールではなく、実際の挙動に基づいて行われます。
この違いが最も重要になるのは、ステークホルダーに「その数字はどうやって出したのか」と聞かれたときです。請求ベースのコスト帰属では、ルールと仮定の連鎖をたどることになります。ランタイムアトリビューションなら、観測されたネットワークアクティビティにまでさかのぼれます。
実際の現場ではどうなるか
FinOpsで最もよくある要望のひとつ、チーム別のコスト可視化を例に取りましょう。タグベースのツールでは、チームコストの精度はタグカバレッジとラベル管理の質に左右されます。共有ネームスペースは厄介です。先週デプロイされたばかりでまだタグ付けされていないサービスは、見えないままです。
Attributeのセンサーは、誰かがラベルを付けるのを待つのではなく、インフラ内で通信しているワークロードを観測するため、新しいワークロードを自動的に検出します。チームが「 チームごとのチャージバック対象コスト」を示す必要があるとき、ランタイムアプローチなら、実際に稼働しているものを反映した、根拠を持って説明できる数字が得られます。
同じ原則は顧客レベルにも当てはまります。固定インフラ、変動コンピュート、SaaSツールまで含めて、特定の顧客へのサービス提供に実際いくらかかっているかを知りたい場合、請求エクスポートからでは大量の手作業によるマッピングなしにはたどり着けません。Attributeは、そのマッピングを観測結果から構築します。どの顧客のワークロードが、どのサービスに、どの程度の量で、いくらのコストでアクセスしているのか。顧客からリージョン別の製品コストやサービスタイプごとの製品収益性を求められたとき、その質問には推定値ではなく、実データに基づく答えを返せます。
AIコストも同様です。Attributeのセンサーはネットワークレイヤーで呼び出しを読み取ります。どのサービスが呼び出したのか、どの顧客のワークロードがトリガーしたのか、いくらかかったのか。これこそ、推論コストを自社で吸収するか顧客に転嫁するかを判断するために、プライシングチームが使える数字です。
Attributeは、手作業のタグや請求エクスポートではなくランタイムアトリビューションを用いて、クラウドとSaaSの支出が実際に何に使われているかをFinOpsチームと財務チームが把握できるよう支援します。
クラウドコストレポートが財務レビューを通らないのはなぜですか?
ほとんどのFinOpsツールは、請求エクスポート、配賦ルール、タグからレポートを作成します。ルールは古くなり、タグカバレッジが完全であることはまれです。財務から数字の導出方法を聞かれたとき、正直な答えは観測データではなく仮定の連鎖に行き着きます。それがギャップです。
ランタイムコストアトリビューションとは何ですか?
ランタイムアトリビューションとは、コストが「こう動くはず」というルールではなく、システムの実際の挙動に基づいて帰属されることを意味します。Attributeは、どのワークロードがどのサービスとランタイムレベルで通信しているかを観測するeBPFセンサーを導入します。すべてのコストは、18か月前のタグ付けの判断ではなく、観測されたネットワークアクティビティにさかのぼれます。
タグ付けされていない支出はどう扱われますか?
タグベースのツールでは、タグのないリソースは集計から漏れるか、便宜的な按分で振り分けられます。Attributeのセンサーは、インフラ内で通信しているワークロードを観測するため、ラベルの有無にかかわらずワークロードを検出します。先週デプロイされた新しいサービスも、すぐに可視化されます。
Attributeで顧客ごとのサービス提供コストを確認できますか?
できます。Attributeは、どの顧客のワークロードがどのサービスに、どの程度の量で、いくらのコストでアクセスしているかを観測することで、クラウドとSaaSの支出を個々のエンド顧客にマッピングします。これにより、固定インフラ、変動コンピュート、SnowflakeやTwilioといったサードパーティツールまで含めた、真のサービス提供コストが得られます。
AIやLLMの推論コストについてはどうですか?
推論コストは、有用と言えるほどの詳細度では請求エクスポートに表れません。Attributeのセンサーはネットワークレイヤーでモデル呼び出しを読み取り、各リクエストを、それをトリガーしたサービス、顧客、機能に帰属させます。これは、AI機能のマージン設定にプライシングチームが必要とする数字です。
CloudZeroやApptioとはどう違いますか?
これらのツールは請求エクスポートを基に動作し、意味のあるデータを表示するにはタグ付けが前提となります。Attributeは代わりに稼働中のシステムを読み取ります。タグ付けもルールのメンテナンスも不要で、ステークホルダーに「その数字はどうやって出したのか」と聞かれても揺るがない方法論です。
