Skip to content
Published on

FinOps / クラウドコスト管理 2026 — Vantage / Infracost / OpenCost / Kubecost / CloudZero 徹底比較

Authors

「コストは非機能要件ではない。2026年においては最重要の機能要件である」— あるFinOpsリード

本稿は 2026年5月時点のFinOps市場マップ である。2023年からGenAIワークロードが爆発し、クラウドの請求が突然2倍3倍になる事態が一般化した結果、FinOpsは「あれば良いもの」から「なければ会社が潰れるもの」に変わった。FinOps Foundationが策定した FOCUS (FinOps Open Cost and Usage Specification) 1.0は2024年にGA、2025年にはAWS / GCP / Azureがいずれも正式にFOCUSフォーマットの請求出力をサポートした。マルチクラウドのコスト比較が、初めて同じ語彙で可能になった。

この記事ではコスト可視化SaaS (Vantage, CloudZero, Cloudability)、OSS可視化 (OpenCost, Infracost, Komiser, Cloud Custodian)、Kubernetes専用 (Kubecost, Densify)、自動最適化 (Spot.io, ProsperOps, Granulate)、異常検知 (Anodot, Yotascale)、ミッドマーケット (FinOut) を網羅的に比較する。最後にToss / Kakao / メルカリ / サイボウズ の実例を整理し、「自社はどのFinOpsツールを選ぶべきか」の意思決定ガイドで締める。

1. 2026年のFinOpsマップ — なぜ再びコスト管理か

FinOpsという言葉が本格的に使われ始めたのは、2019年にLinux Foundation傘下でFinOps Foundationが設立されてからだ。核となる考えはシンプルである。クラウドコストはエンジニアリング、財務、ビジネスの3つの責任 であり、共通の言語、共通のデータ、共通のプロセスを作ろう、という運動だ。

2023年までのFinOpsは概ね「コストを見せて減らそう」だった。ところが2024年からGenAIワークロードが爆発した。OpenAIへの月額が数十万ドルを超えるスタートアップが珍しくなくなり、自前モデルを動かす会社はH100 GPU 1枚を時間4ドルで8枚、24時間使うことで月2万ドル単位のGPU費用を負担するようになった。CFOが「AWSの請求が四半期ごとに30%伸びるのに、売上はそれほど伸びていない」と毎度問うのが日常になった。

2026年のFinOps市場は大きく5つに分かれる。

  • マルチクラウド可視化SaaS: Vantage, CloudZero, Cloudability (Apptio→IBM), FinOut
  • OSS可視化: OpenCost (CNCF), Infracost, Komiser
  • Kubernetes専用: Kubecost (IBM), Densify
  • 自動最適化: Spot.io (NetApp), ProsperOps, Granulate (Intel)
  • 異常検知 / 予測: Anodot, Yotascale
  • ポリシーエンジン: Cloud Custodian (Capital One OSS)

Gartnerは2026年までに世界100大企業の80%が専任FinOpsチームを持つと予測しており、FinOps Foundation自身も会員組織が1万を突破した。

2. FinOps Foundation + FOCUS仕様

FinOps Foundationは2019年にLinux Foundation傘下で発足した。当初はベストプラクティス共有のコミュニティ程度だったが、2023年に FOCUS (FinOps Open Cost and Usage Specification) の仕様策定を開始したことで、事実上の業界標準化機構になった。

FOCUSの核はシンプルだ。AWSはCUR (Cost and Usage Report)、GCPはBilling Export、AzureはCost Management Export、OracleはOCI Usageと、それぞれ請求データを出力するが、列の名前と意味がすべて違う。同じ「リソースID」もAWSは resource_id、GCPは resource.name、Azureは ResourceId と呼ぶ。マルチクラウド企業はこれを毎度正規化しなければならなかった。

FOCUSはこれら列の語彙を合意した仕様である。1.0は2024年にGAし、2025年から主要クラウドがFOCUSフォーマットを正式に出力するようになった。主な列:

# FOCUS 1.0 主要列の一部
BilledCost: 実際に請求された額(割引・クレジット適用後)
EffectiveCost: 約定割引を分配した後の単位コスト
ListCost: 定価コスト
ServiceName: 正規化されたサービス名(例: Amazon EC2)
ServiceCategory: カテゴリ(Compute, Storage, AI/ML など)
ChargeCategory: Usage / Purchase / Tax / Adjustment / Credit
ChargeFrequency: One-time / Recurring / Usage-based
ResourceId: リソース識別子
ResourceType: リソース種別
SkuId: SKU識別子
PricingUnit: 価格単位(GB-Mo, vCPU-Hour など)

FOCUSの意味は単に「フォーマット統一」ではない。ベンダーロックインが緩むということだ。VantageからCloudZeroへ乗り換える際、これまではデータパイプラインを最初から組み直す必要があったが、これからはFOCUSデータセットを丸ごと移すだけで良い。また自社データウェアハウス (Snowflake / BigQuery) にFOCUS形式でコストを取り込む企業も急速に増えた。「コスト分析はSQLでやる」が再び流行している理由だ。

3. Vantage — マルチクラウド可視化のリーダー

Vantageは2020年に米国で始まった。創業者がDigitalOcean出身という背景から、最初から「開発者が作るFinOps」を掲げてきた。2024年にSeries Bをクローズし、マルチクラウド可視化SaaSの事実上のリーダーに位置している。

強み:

  • 30以上の統合: AWS, GCP, Azure, Oracle, Alibaba, Snowflake, Databricks, Datadog, MongoDB Atlas, Confluent, Fastly, Linode, DigitalOcean ほか。「クラウドだけでなくSaaSも1か所で見える」が差別化点。
  • Cost Reports が直感的。SQLを書かずに「過去90日のEC2コストをリージョン別 / チームタグ別に分解」のようなクエリをGUIで作れる
  • Active Discounts: 未使用のRI/SP、誤割り当ての約定を自動検出
  • Cost Anomaly Detection: 閾値ベースとMLベースの両方
  • 価格が透明 (利用額の一定割合 + 最低料金)

弱み:

  • 自動修正アクションは限定的。「見つけてくれるが、削減するには別ツールか手作業が必要」
  • エンタープライズRBAC / SSOは上位プランのみ
  • Kubernetesコストは別途統合が必要 (VantageはOpenCostを内部利用)

誰が使うべきか: 50〜500名規模、マルチクラウド利用中、SaaSコストも1か所で見たい組織。Toss, Figma, Snap, PagerDuty などがユーザーとして知られる。

4. Infracost — IaCのPRでコスト差分を見る

Infracostは2021年に英国発のOSSとして始まった。他のFinOpsツールが「すでに使ったコストを見せる」のに対し、Infracostは 「これから使うコスト」をPR時点で見せる ほぼ唯一のツールだ。

動作:

  1. 開発者がTerraform / Pulumi / CloudFormationのPRを上げる
  2. GitHub ActionでInfracostが走る
  3. PRコメントに「この変更は月$1,840増えます」のような差分を貼る
# Infracost の基本利用
infracost breakdown --path=terraform/
# 出力例:
# Project: my-infra/terraform
#
# Name                     Monthly Qty  Unit       Monthly Cost
#
# aws_instance.web_app
# ├─ Instance usage (m5.large)  730  hours       $70.08
# ├─ EBS volume (gp3)            30  GB-month     $2.40
# └─ EBS snapshots                5  GB-month     $0.25
#
# Project total                                  $72.73

CI統合例 (GitHub Actions):

# .github/workflows/infracost.yml
name: Infracost
on: [pull_request]
jobs:
  infracost:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: infracost/actions/setup@v3
        with:
          api-key: $INFRACOST_API_KEY
      - run: infracost breakdown --path=. --format=json --out-file=/tmp/base.json
      - uses: actions/checkout@v4
        with: { ref: $GITHUB_HEAD_REF }
      - run: |
          infracost diff --path=. \
            --compare-to=/tmp/base.json \
            --format=github-comment \
            --out-file=/tmp/comment.md
      - uses: infracost/actions/comment@v3
        with: { path: /tmp/comment.md }

Infracostの意義は「コストをコードレビューのループに組み込んだ」点にある。開発者がRDSのインスタンスタイプを db.r5.4xlarge にしてPRを上げると、レビュワーが「月$1,400増えるが、ここまで必要か?」と聞き始める。コスト判断の位置を、本番で気付く時点からPR時点に移した のだ。

Infracost Cloud (SaaS) はポリシー自動化、組織ダッシュボード、ガードレールを追加で提供する。OSS CLIは無料、Cloudはシート単位の月額。

誰が使うべきか: Terraform / Pulumi を本格的に使う全てのチーム。特にIaCのPRが日に何十件も上がるプラットフォームチーム。

5. OpenCost (CNCF) — Kubernetesコストの標準

OpenCostは2022年にKubecostがCNCFへ寄贈したOSSだ。2024年にCNCF Incubatingに入り、Kubernetesコスト可視化の事実上の標準となった。

動作:

  • クラスタにOpenCost Podを1つ起動
  • Prometheusと連動してノード / Pod / Namespace単位のCPU / メモリ / GPU / ストレージ / ネットワーク利用量を収集
  • クラウドの価格表 (AWS / GCP / Azure) を掛けてコストを算出
  • 結果をPrometheusメトリクスとして公開
# OpenCost を Helm でインストール
helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm install opencost opencost/opencost \
  --namespace opencost \
  --create-namespace \
  --set opencost.prometheus.internal.serviceName=prometheus-server

主要メトリクス (Prometheus公開):

opencost_node_total_hourly_cost           # ノード別の時間あたりコスト
opencost_load_balancer_cost               # LoadBalancer コスト
opencost_pv_cost                          # PV (永続ボリューム) コスト
opencost_namespace_total_cost             # Namespace 合計コスト
opencost_workload_cost_running            # ワークロード単位コスト

OpenCostは「コストを見る」までで終わる。減らしてはくれない。そのためOpenCost + Grafanaダッシュボード + Slackアラートで可視化し、削減は別ツール (Karpenter, KEDA, Spot.io) に任せるパターンが多い。

ベンダーの採用状況:

  • Vantage, CloudZero, Datadog Cloud Cost Management, Grafana Cloud がいずれもOpenCostをバックエンドに使う
  • つまりOpenCostを直接入れなくても、上記製品を使えばOpenCost上で動いていることになる

誰が使うべきか: Kubernetesを運用する全チーム。無料・ロックインなしなので、入れておくのが合理的だ。

6. Kubecost — IBM買収 (2024)

Kubecostは2019年に米国で始まったKubernetesコストSaaSだ。上で見たOpenCostを作りCNCFへ寄贈した本家でもある。2024年にIBMが買収し、現在はIBM Cloud Paksポートフォリオの一部として展開されている。

OpenCostとKubecostの関係:

  • OpenCost = 無料コア、CNCF Incubating
  • Kubecost = OpenCost上にUI / ダッシュボード / マルチクラスタ / 異常検知 / 推奨エンジンを載せた商用品

Kubecostの差別化機能:

  • Multi-cluster aggregation: 数十のクラスタを1画面に集約
  • Allocation views: Namespace / ラベル / Deployment / チーム / 製品 単位の費用分解
  • Savings recommendations: 適正サイジング、未使用ノード検出、Spot転換候補の識別
  • Budget alerts: チーム / Namespace 単位での予算超過アラート
  • Cluster Right-Sizing: ノードプール構成の推奨

IBM買収の影響:

  • IBM Cloud / OpenShift との統合が加速
  • 一部エンタープライズ価格の変更 (Kubecost Free Tierは継続)
  • ロードマップが「Kubernetes only」から「OpenShift + IBM Cloud 優先」へ多少寄ったとの評がある

誰が使うべきか: 100ノード超のマルチクラスタ、Namespaceをチーム / 製品の境界として使う組織、chargebackしたい組織。

7. CloudZero — unit cost economics

CloudZeroは2018年に米国で始まった。他のFinOpsツールが「総コストを減らそう」に集中する一方、CloudZeroは 「単位コスト (unit cost)」 を前面に押し出した。

単位コストとは何か。例:

  • 「顧客1名あたり月インフラコスト」= $0.42
  • 「APIコール1,000件あたりのコスト」= $0.018
  • 「分析クエリ1件あたりのコスト」= $0.07
  • 「AI推論1,000トークンあたりのコスト」= $0.0012

総コストは減らなくとも、単位コストが減れば事業は健全になる。CloudZeroのメッセージは「CFOが見たいのは総額ではなく単位コストで、単位コストは売上と連動して動くべきだ」である。

技術的にCloudZeroは:

  • AWS / GCP / Azure / Snowflake / Databricks / Kubernetes (OpenCost経由) を統合
  • 独自DSLの CostFormation で任意のコスト分配ルールを定義 (どのコストをどの製品 / 顧客 / チームへどう流すか)
  • AI / ML コストカテゴリを別建てで分離 (GenAIワークロード分析が強い)
  • 単位コストの推移を売上 / 利用メトリクスと並べて表示

価格は非公開で、概ね年間クラウド支出規模に応じた契約となる。ミッドマーケット〜エンタープライズ向け、シート課金ではない。

誰が使うべきか: SaaS企業で「ARRに対するクラウドコスト比率」がボード資料に載る組織。AI企業で「トークン単位の推論コストが四半期ごとに下がっている」ことを示したい組織。

8. Cloudability (Apptio/IBM) — エンタープライズ

Cloudabilityは2011年に始まった第一世代のFinOps SaaSだ。2019年にApptioが買収し、2023年にIBMがApptioを買収 したことで、Cloudability も IBM 傘下に入った。

ポジション:

  • 最も古いFinOpsツールの一つ、エンタープライズでの占有率が圧倒的
  • IBM Apptio ポートフォリオと束ねられ、ITFM (IT Financial Management) 統合ソリューションとして販売される
  • 価格はエンタープライズ交渉ベース、一般に高め

機能:

  • AWS / Azure / GCP / Oracle / OpenShift を全面カバー
  • True Cost (定価 vs 実コスト) 分析が精緻
  • Rightsizing推奨が機械学習ベース
  • 約定管理 (RI / Savings Plans) の最適化が強い
  • True Up: 約定期限切れの自動アラート

新興SaaS (Vantage, CloudZero) と比較した弱み:

  • UI / UX が重く、学習コストが高い
  • セットアップと設定にコンサルが必要なケースが多い
  • 変化のスピードが遅い (エンタープライズ要件が優先)

誰が使うべきか: クラウド年間支出1,000万ドル超、既にApptio ITFMを使っている組織、IBMとのエンタープライズ契約がある組織。

9. Spot.io (NetApp) — スポットインスタンス自動化

Spot.io の前身は Spotinst だ。2015年にイスラエルで始まり、2020年にNetAppが買収 した。中心となる価値提案は「スポットインスタンスのリスクは我々が管理する、君らは60〜90%のコスト削減だけ受け取れ」だ。

動作原理:

  • Spot ElastigroupがAWS Spot, Azure Spot VM, GCP Preemptible VM をオーケストレーション
  • 価格変動 / 回収 (reclamation) 予測をMLで実行
  • 回収シグナルが来たら新しいインスタンスを先回りで起動し、ワークロードを移す
  • 平均で「オンデマンドの30%価格」を謳う

製品ファミリ:

  • Elastigroup: 一般ワークロード (EC2 / VMSS) のスポット自動化
  • Ocean: Kubernetesノードプールのスポット自動化。事実上Karpenterの商用競合
  • Eco: 約定 (RI / SP) 管理。ProsperOpsの競合
  • CloudCheckr: 2021年買収、FinOps可視化を追加

2024-2025年の流れ:

  • AWS KarpenterがOSSとして急成長し、Oceanの存在意義が一部弱まった
  • それでも「Karpenter運用人材がいない組織」にはOceanがまだ有効
  • 社内ではNetApp BlueXPブランド下で再編中

誰が使うべきか: スポットを使いたいが回収処理のコードを自前で書きたくない組織。Karpenter運用人材のいないミッドマーケット。

10. Densify / ProsperOps / FinOut / Anodot / Yotascale — その他

Densify はカナダ・トロント発で2010年からのベテラン。強みは Kubernetes / VMライトサイジング 推奨。MLでワークロードパターンを分析し、「このDeploymentはCPU 1コアではなく0.3コアで十分、メモリは512Mi → 384Mi」のようなPRを自動生成する。Terraform / Helmの出力にも対応。

ProsperOps は2018年米国発。一点に集中している: AWS RI / Savings Plans の自動管理。人手による約定ポートフォリオ管理をアルゴリズムに置き換えた。毎週自動でSPを買ったり売ったりして「effective savings rate」を最大化する。手数料は削減額の一定割合 (通常15〜25%)。

FinOut は2021年テルアビブ発。ミッドマーケット向けSaaSとして定着した。強みは 「コストをビジネス単位に分解」できるダッシュボードビルダー。CloudZero比で価格が手頃と評価され、「10名未満のスタートアップには無料」というポリシーもある。

Anodot は2014年イスラエル発。元々はビジネスメトリクスの異常検知SaaSで、同じMLエンジンをクラウドコストにも適用した。異常検知が最も精緻なツールの一つ と評価される。「昨日EC2コストが急に23%上がったが原因はus-east-1のr5.large 100台追加」を自動で見つける。

Yotascale は2015年米国発。コスト分配 (allocation) ルール定義の柔軟さが強み。エンジニアリングマネージャがSQLを書かなくても「過去30日にサーチチームがML推論で使ったコスト」をGUIで作れる。

ツール選定マトリクス (要約):

ツール強み弱み価格
Densifyk8s/VM ライトサイジング推奨可視化が弱いエンタープライズ
ProsperOpsAWS RI/SP 自動売買AWS専用削減額の%
FinOutミッドマーケット向けダッシュボード自動化が弱いリーズナブル
Anodot異常検知MLUIが重いエンタープライズ
Yotascale柔軟なコスト分配知名度低シート + 利用量

11. Komiser / Cloud Custodian — OSSインベントリ + ポリシー

Komiser はTailwarden (元Mlabs) によるOSSのクラウドリソースインベントリツールだ。2024年からSaaS版 (Tailwarden) も提供している。

動作:

  • AWS / GCP / Azure / DigitalOcean / Linode / OCI に read-only でアクセス
  • 全リソースをインベントリ化
  • コスト / タグ / オーナー / 異常を1画面で可視化
  • 「タグ無しEC2 47台」「stopped状態で30日経過したEBS 12台」のようなインサイトを提供
# Komiser CLI クイックスタート
docker run -d -p 3000:3000 \
  -v $HOME/.aws:/root/.aws:ro \
  tailwarden/komiser:latest
# http://localhost:3000 を開く

Cloud Custodian はCapital Oneが2016年にOSS化したポリシーエンジンだ。CNCF Incubating。「YAMLでクラウドガバナンスのルールを書き、違反リソースに自動アクションを走らせる」ツールだ。

# Cloud Custodian ポリシー例 - タグ無しEC2を30日後に自動停止
policies:
  - name: ec2-untagged-stop-30d
    resource: aws.ec2
    filters:
      - State.Name: running
      - "tag:Owner": absent
      - type: instance-age
        days: 30
        op: gt
    actions:
      - type: notify
        to: [costops@example.com]
        template: untagged-instance.html
        subject: "Untagged EC2 - will stop in 7 days"
      - type: mark-for-op
        op: stop
        days: 7
      - type: stop

Cloud Custodianの価値は「ポリシーをコードとして管理」する点にある。「リージョン別コスト上限」「タグ無しリソース禁止」「7日以上アイドルなRDSは停止」のようなルールをGitで管理し、PRで変更する。

利用者: Capital One自身、FINRA, HBO Max, eBay など大規模エンタープライズ多数。

誰が使うべきか: Komiserは全員に推奨 (無料、5分でセットアップ)。Cloud Custodianはセキュリティ / ガバナンスチームがあり、ポリシーをコードで管理する文化のある組織。

12. Granulate (Intel) — ワークロード最適化

Granulateは2018年にイスラエルで始まったワークロード自動最適化会社だ。2022年にIntelが6億5,000万ドルで買収 した。他のFinOpsツールが「リソースサイズを削ろう」に集中する中、Granulateは 「同じインフラで同じワークロードをより速く回し、結果としてコストを下げる」 という別の道を選んだ。

動作原理:

  • ホストにGranulateエージェントをインストール
  • JVM / Python / Node.js / Spark / PostgreSQL / MySQL / NGINX などランタイムを分析
  • OSスケジューラ、GCポリシー、コンテナのcgroupパラメータをワークロードごとに自動調整
  • 平均20〜40%のCPU削減を謳う (ワークロード別の差は大きい)

主な提供物:

  • gProfiler (OSSとして派生): コンテナホストでの継続プロファイリング。Pyroscope / Polar Signals と競合
  • Granulate Continuous Optimization: 商用本体
  • Optimizer for Spark: Databricks / EMR Spark ジョブの自動チューニング
  • Optimizer for K8s: ワークロード別 cgroup / スケジューリング調整

Intel買収後:

  • Intel Tiber Cloud Optimization としてブランド再編
  • gProfiler は OSS のまま継続
  • Spark / Databricks 最適化の事例が増加 (分析ワークロードで効果が大きい)

誰が使うべきか: JVM / Spark / Python のような重いランタイムを大規模に動かしている組織。ライトサイジングは終わり「他に削れる余地は」を探す段階。

13. showback vs chargeback / reserved capacity / savings plans

FinOps運用モデルには大きく2つの流派がある。

showback: 「あなたのチームが先月5万ドル使った」を見せるだけ。請求は会社全体で負担。

chargeback: 上記5万ドルを実際にチーム予算から差し引く。チームがP&L責任を負う。

ほとんどの組織は showbackから始める。コストを正確に分配できるタグ付け / カタログが整っていない状態でchargebackを始めると、「自分のコストではない」という抗議が殺到する。通常は6〜12か月のshowbackでデータ信頼度を作ってからchargebackへ移る。

タグ標準 (よくあるパターン):

# コスト分配タグ標準の例
team: payments              # 責任チーム
service: payment-api        # サービス名
env: production             # 環境
cost-center: 12345          # 会計のコストセンター
business-unit: consumer     # 事業部
project: checkout-redesign  # プロジェクト(任意)
owner: yj.kim@example.com   # 担当者

Reserved Instances (RI) と Savings Plans (SP) はAWSの約定割引制度だ。1年または3年の利用量約束で30〜72%割引を受ける。RIはインスタンスファミリ / リージョンに紐づくが、SP (特に Compute SP) は遥かに柔軟だ。2026年のベストプラクティスは「定常ワークロードの70〜80%は1年のCompute SPでカバー、残りはオンデマンド / スポット」である。

GCPの CUD (Committed Use Discounts) と Azureの Reserved VM Instances / Savings Plan も類似構造だ。マルチクラウドではクラウドごとに別管理となる。

14. 韓国 / 日本 — Toss, Kakao, メルカリ, サイボウズ

Toss は2022年頃から本格的なFinOpsチームを運営している。社内向けにコストダッシュボードを自前構築し、一部の領域でVantageを併用する。Tossが公開した資料によれば「Sparkクラスタのライトサイジングと RI最適化だけで四半期あたり数億ウォン単位の削減」を達成した。韓国フィンテックの性質上データ分析 / AIワークロードの比重が大きく、BigQuery / Snowflakeのコスト管理に多くのリソースを投じている。

Kakao グループはKakao Enterprise / Kakao Bank / Kakao Pay でそれぞれ別のFinOpsアプローチを取る。Kakao Bankは自社データウェアハウスにコストデータを取り込み社内SQL / BIで分析する。Kakao Enterpriseは自社クラウド (KC) の利用を直接管理する。共通して「OSS + 自前構築」の比重が大きく、商用SaaS依存は海外企業に比べて低い。

メルカリ は日本でFinOps事例を最も活発に公開する企業の一つだ。Mercari Engineering Blogに OpenCost 活用記、GCP BigQuery のコスト削減事例、Kubernetes マルチテナンシでのコスト分配事例などを定期的に投稿している。社内ではメルカリコストダッシュボードを運用している。

サイボウズ はKintone / Garoonを運営する日本のSaaS企業だ。コスト運用を「本番SRE チームの役割の一部」と位置付け、OpenCost + Datadog Cloud Cost Management の組み合わせを公開事例として発表した。CyberAgent CIU (Cyber Infrastructure Unit) も同様のアプローチで社内コスト可視化プラットフォームを自前運用している。

韓国 / 日本に共通するパターン:

  • 商用SaaSは高めで自前構築が好まれる
  • OpenCost + Infracost + 自前のBigQuery / Snowflake への取り込みが定番
  • 約定 (RI / SP) は財務とインフラの共同判断領域
  • chargebackまで到達する事例は稀で、ほとんどはshowbackで止まる

15. 誰が何を選ぶか — 意思決定ガイド

組織規模とワークロードによって推奨組み合わせが変わる。

シード / Series A (1-20名、月クラウド支出 $5K未満)

  • AWS Cost Explorer + GCP Billing Console + Azure Cost Management で十分
  • Infracost OSS は無料なのでとりあえず入れる
  • コストが急に増えたら Vantage 無料枠から始める

Series B-C (20-100名、月クラウド支出 5K5K-100K)

  • Vantage または FinOut。SaaSコストも見たいなら Vantage
  • Infracost を CI に組み込む
  • Kubernetesがあれば OpenCost を追加
  • スポットを使いたければまず Karpenter (OSS)、難しければ Spot.io Ocean

ミッドマーケット (100-500名、月クラウド支出 100K100K-1M)

  • Vantage または CloudZero (unit cost が重要なら CloudZero)
  • Infracost Cloud でガバナンス
  • OpenCost + Kubecost コンボ
  • ProsperOps で RI / SP 自動化
  • 異常検知で Anodot を検討

エンタープライズ (500名以上、月クラウド支出 $1M以上)

  • Cloudability (Apptio) が事実上の標準、または CloudZero / Vantage Enterprise
  • Cloud Custodian でポリシー自動化
  • Densify でライトサイジング自動化
  • Granulate でワークロード最適化 (分析系が多ければ ROI が大きい)
  • 自社 Snowflake / BigQuery に FOCUS 形式で取り込み

Kubernetes 専業

  • OpenCost をデフォルト
  • ダッシュボード / マルチクラスタが必要になったら Kubecost を追加
  • ライトサイジングは Densify または自前 VPA
  • スポット自動化は Karpenter (OSS) または Spot.io Ocean

AI / ML 企業

  • GenAIコスト分離が最も強いのは CloudZero
  • GPUクラスタは OpenCost + 自前分析
  • 推論コストは単位コスト (トークン単位、リクエスト単位) で追跡
  • Granulate で学習ジョブ最適化を検討

ツール選定で最も重要な意思決定はツールそのものではなく、「自社がどのコスト判断を誰に任せるか」 の政治的合意だ。合意が無ければどのツールを買ってもダッシュボードが増えるだけになる。


FinOpsはツールの問題ではなく 組織の問題 だ。2026年の違いはGenAIによってコストが「エンジニアリングの付随事項」ではなくなったこと、そしてFOCUS仕様がマルチクラウドのコスト分析語彙を統一したことだ。市場はその結果として5つのカテゴリに整理された。どのツールを選ぶにせよ、始まりはシンプルだ。OpenCostを入れ、InfracostをCIに組み込み、タグ標準を決め、一四半期分のshowbackデータを集める。それからSaaSを買うか、chargebackへ進むかを決めれば良い。

参考 / References