LabHub

ブログ

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

2026-05-16 · 30 分で読めます · #finops#cloud-cost#vantage#infracost#opencost#kubecost#cloudzero#cloudability#spot-io#densify#prosperops#finops-foundation#focus#cloud-custodian#deep-dive#japanese

한국어English日本語

「コストは非機能要件ではない。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つに分かれる。

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の事実上のリーダーに位置している。

強み:

弱み:

誰が使うべきか: 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 を 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) に任せるパターンが多い。

ベンダーの採用状況:

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

6. Kubecost — IBM買収 (2024)

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

OpenCostとKubecostの関係:

Kubecostの差別化機能:

IBM買収の影響:

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

7. CloudZero — unit cost economics

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

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

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

技術的にCloudZeroは:

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

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

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

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

ポジション:

機能:

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

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

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

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

動作原理:

製品ファミリ:

2024-2025年の流れ:

誰が使うべきか: スポットを使いたいが回収処理のコードを自前で書きたくない組織。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) も提供している。

動作:

# 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は 「同じインフラで同じワークロードをより速く回し、結果としてコストを下げる」 という別の道を選んだ。

動作原理:

主な提供物:

Intel買収後:

誰が使うべきか: 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) も同様のアプローチで社内コスト可視化プラットフォームを自前運用している。

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

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

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

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

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

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

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

Kubernetes 専業

AI / ML 企業

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

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

参考 / References

コメント

まだコメントはありません。

ログインするとコメントできます