Continuous Optimizationツールとは？CNCF掲載28製品の現状とOpenCost・Karpenterの使い分け

Continuous Optimizationは、CNCF Landscapeでクラウドとコンテナのリソースを継続的に見直すツールを集めた区分です。2026年10月2日時点で28製品が載っていますが、リポジトリURLが登録されているのは7項目、CNCFのプロジェクトはOpenCostの1件だけです。残りは商用サービスなので、「CNCFに載っている＝OSSで無料」とは読めません。

この記事では、掲載製品を「何を最適化するか」で4つの層に分け、リポジトリURL付きの7項目の開発状況を確認したうえで、OpenCost・Kubecost・VPA・Karpenter・Infracostをどの順で入れるかを示します。

まとめ：Continuous Optimizationツールの選び方の要点

• CNCF Landscapeの区分は「Observability and Analysis」配下の「Continuous Optimization」。28製品のうちCNCFプロジェクトはOpenCost（Incubating）だけ
• ツールは最適化する層で選ぶ。コストの見える化（OpenCost・Kubecost）、Podのrequests適正化（VPA・Kruize・KRR）、ノードの統合（Karpenter）、IaC変更の事前見積もり（Infracost）の4層
• Craneは最終リリースが2023年7月で止まり、nOpsの掲載リポジトリはGitHub APIで404（2026年10月2日）。どちらも保守の継続を前提にできないため、新規採用では優先度を下げる
• 依存関係があるのは「見える化→requests適正化→ノード統合」の3段階。requestsが過大なままKarpenterを入れても、過大な予約に合わせてノードが並ぶだけになる
• IBM Kubecost 3.0はPrometheus依存をなくした一方、無料枠に直近30日10万ドルの支出上限が付いた。EKS向けバンドルは上限の対象外

以下、区分の定義、層ごとの代表ツール、導入順と避けるべき使い方の順に説明します。

Continuous Optimizationの定義とCNCF Landscape上の位置

CNCF LandscapeはGitHubのcncf/landscapeリポジトリにあるlandscape.ymlが元データです。このファイルでは「Continuous Optimization」は「Observability and Analysis」カテゴリの下位区分として定義されています。監視・ログ・トレースと同じ大分類に入っているのは、最適化の前提が「使用量を測ること」だからです。

掲載28製品の内訳とCNCFプロジェクト

2026年10月1日更新のlandscape.ymlを数えると、掲載は28製品です。repo_url（ソースの所在）を持つのはgocrane（Crane）・Infracost・Kruize・Kubecost・nOps・OpenCost・Karpenterの7件で、ほかの21件（cast.ai、IBM Turbonomic、Spot.io、StormForge、ScaleOps、CloudZero、PerfectScale by DoiTなど）は商用サービスとして載っています。

CNCFのプロジェクトとして成熟度が付いているのはOpenCostだけです。OpenCostは2022年6月17日にSandboxとして受理され、2024年10月25日にIncubatingへ昇格しました。KarpenterはKubernetesのSIG Autoscaling配下（kubernetes-sigs/karpenter）で開発されており、CNCFの独立プロジェクトではありません。

FinOpsとの関係

FinOps Foundationの定義では、FinOpsはクラウドとテクノロジーの事業価値を最大化するための運用の枠組みと文化で、エンジニアリング・財務・事業部門の協働で費用の説明責任を持たせます。Continuous Optimizationのツールは、そのうちクラウド費用の「最適化」の実務を自動化する道具にあたります。組織づくりやフェーズの考え方はFinOpsのクラウドコスト管理の仕組みと3フェーズで扱っているので、本記事はツールの選定と設定に絞ります。

最適化する層で分ける4つのツール群

同じ区分に並んでいても、ツールが触る対象はまったく違います。クラスターを書き換えるかどうかで導入時のリスクも変わるため、まず層を分けて考えます。

見える化と事前見積もりは既存ワークロードの設定を変えません。ただしOpenCost自身もクラスター内で動き、Prometheusへの問い合わせを増やすので、導入時はPodのリソース設定と監視側の負荷を確認します。requests適正化とノード統合はPodの再作成やノードの入れ替えを伴うので、PodDisruptionBudgetと合わせて段階的に有効にします。

リポジトリURL付き7項目の開発状況（2026年10月時点）

Landscapeへの掲載は、開発が続いていることを保証しません。landscape.ymlのrepo_urlを起点に、各リポジトリのリリースと既定ブランチの最終コミットをGitHub APIで確認した結果が次の表です（2026年10月2日取得）。版番号は各リポジトリのReleasesページで追えます。

Kubecostの欄に載っているkubecost/cost-modelは、開くとopencost/opencostへ転送されます。KubecostのOSS部分がOpenCostとして寄贈された経緯の名残で、商用のKubecost本体のソースではありません。

Crane（Tencent発のFinOps向けOSS）は、2023年7月25日のv0.11.0を最後にリリースがなく、コミットも2024年12月20日で止まっています。nOpsの掲載先nops-io/nops-k8s-agentはGitHub APIで照会すると404を返し、同社の公開リポジトリ一覧にも、2022年のEKS Blueprints用アドオン以外にKubernetesエージェントは見当たりません。nOps自体はAWSとKubernetesの商用最適化サービスとして続いていますが、OSSとして使う前提は成り立ちません。旧来の解説記事で「代表的なOSS」として紹介されていても、この2つを2026年に新しく採るなら、自社でフォークを保守できるかが条件になります。

OpenCostによるKubernetesコストの配賦

OpenCostは、ノードやディスクの料金をPodのrequestsと実使用量に応じてNamespace・ラベル・Deploymentへ割り振るツールです。導入時に自身のDeploymentなどは作りますが、既存ワークロードのrequestsやノードを自動で変えることはないので、最初に入れる層に向いています。

OpenCostのHelm導入手順

公式手順は、既存のPrometheusがある前提でHelmチャートを入れる形です。Prometheusの構成はPrometheusの仕組みとCNCF卒業までの経緯を参照してください。

helm repo add opencost-charts https://opencost.github.io/opencost-helm-chart
helm repo update
helm install opencost opencost-charts/opencost \
  --namespace opencost --create-namespace -f values.yaml

# UI(9090)とAPI(9003)をローカルへ転送（このまま実行し続ける）
kubectl port-forward --namespace opencost service/opencost 9003 9090

# 別のターミナルで：直近7日のコストをNamespace別に集計
curl -G http://localhost:9003/allocation \
  -d window=7d \
  -d aggregate=namespace

values.yamlはhelm installの前に作ります。既存のPrometheusを指す最小構成は次のとおりで、Service名・Namespace・ポートは自分の環境の値に置き換えます。

opencost:
  prometheus:
    internal:
      enabled: true
      serviceName: prometheus-kube-prometheus-prometheus
      namespaceName: prometheus-system
      port: 9090

AWSの場合、ノード単価は既定で公開のオンデマンド価格APIから取得します。割引やSavings Plans込みの実額と突き合わせるには、v1.108.0で安定版に入った「Cloud Costs」を設定し、AWS・Azure・GCPなどの請求データを別に読み込みます。

Prometheusなしの構成とMCPサーバー

公式ドキュメントの要件欄は2026年10月時点でも「Prometheusが必要」と書いていますが、2025年のリリースでPrometheusなしで動く「Collector Datasource」がベータとして入りました。監視基盤を別製品にしているクラスターで試す価値はありますが、ベータなので本番の配賦の根拠にはまだ使わないほうが安全です。

同じく2025年に、AIエージェントから配賦データ・資産データ・クラウド費用を問い合わせるMCPサーバーが追加されました。ポートは8081です。注意したいのは既定値の食い違いで、本体のREADMEとコード（環境変数MCP_SERVER_ENABLEDの既定はfalse）では無効なのに、公式Helmチャート2.5.32のvalues.yamlはopencost.mcp.enabled: trueです。Helmで入れると有効になるので、使わないならfalseを明示します。

IBM Kubecost 3.0とOpenCostの違い

KubecostはOpenCostを生んだ商用製品で、IBMが2024年9月17日に買収を発表し、IBMのFinOps Suiteに組み込まれました。2025年9月30日に発表されたKubecost 3.0で構成が大きく変わり、2026年9月22日にはv3.3.0が出ています。

3.0はPrometheusへの依存をやめ、Cloudabilityと統合したエージェントがKubernetes APIから直接メトリクスを集めます。複数クラスターのデータはS3互換のオブジェクトストレージに置きます。v2からの移行はストレージ構成ごと変わるので、AWSのドキュメントも「アップグレード前にKubecostのドキュメントを確認する」よう注意しています。

選び分けは単純です。配賦の数字だけが欲しく、Prometheusを運用できるならOpenCost。予算アラートや異常検知、requestsの自動調整まで欲しく、クラスター費用が月10万ドルを超えないか、EKSだけで運用するならKubecost 3.0の無料枠かEKS向けバンドルが候補になります。

Podのrequestsを適正化するVPA・Kruize・KRR

Kubernetesはノードの空きをrequestsで判断するので、実使用量より大きいrequestsはそのまま空き容量の無駄になります。この層のツールは、過去の使用量から妥当なrequestsを計算します。

VPAのOffモードによる推奨値の取得

Vertical Pod Autoscaler（VPA）はkubernetes/autoscalerリポジトリのコンポーネントで、2026年9月23日にv1.8.0が出ています。更新モードは6種類あり、Autoは非推奨（現状はRecreateと同じ動作）です。Podを止めずに値を変えるInPlaceと、失敗したら作り直すInPlaceOrRecreateも選べます。

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
      - containerName: "*"
        controlledResources: ["memory"]

Offは推奨値を計算してVPAオブジェクトに書くだけで、Podには手を触れません。kubectl describe vpa api-vpaで推奨値を確認し、問題がなければマニフェストに反映します。このYAMLはVPA v1.8.0のCRDスキーマで検証済みです。

対象をメモリに絞っているのは、HPAとの併用のためです。VPAの既知の制約として、HPAと同じリソース指標（CPUかメモリ）で併用してはいけないと明記されています。HPAがCPUで台数を決めているなら、VPAはメモリだけを見るように分けます。

Kruize・KRR・Goldilocksの違い

VPAは対象ごとにオブジェクトを作る必要があり、推奨値が出るまで使用量の蓄積を待ちます。この手間を減らす道具が3つあります。

• KRR（Robusta）：手元のPCから実行するCLIで、既存のPrometheusの履歴（既定14日）からCPU・メモリのrequestsとlimitsを推奨する。クラスターに何も入れない。krr simpleで全ワークロードを一覧できる
• Goldilocks（Fairwinds）：Namespace内の各ワークロードに推奨専用のVPAを自動で作り、推奨値をダッシュボードに並べる。中身はVPAなのでVPA本体の導入が前提
• Kruize：Red Hat InsightsのResource Optimization Serviceの裏側で動くOSS。PrometheusかThanosの履歴から、コンテナのrequests・limitsに加え、NamespaceのResourceQuotaと、NVIDIA A100・H100などのMIGスライス構成まで推奨する

Prometheusがすでにあり、まず全体の過大requestsを洗い出したいならKRRが最も手早く、継続的に推奨値を見張るならGoldilocks、GPUノードやOpenShiftを抱えるならKruizeを当たります。

Karpenterによるノード統合

requestsが適正になったら、空いたノードを畳む段階です。Karpenterは、スケジュールできないPodに合わせてノードを起動し、空いたノードを統合して減らします。仕組みとCluster Autoscalerとの違いはKarpenterのノード自動プロビジョニングの仕組みとCluster Autoscalerとの違いで扱っています。

consolidationPolicyとdisruption budgetsの設定例

統合の挙動はNodePoolのspec.disruptionで決まります。次の例は、平日の日本時間9時から19時には過少利用ノードの統合を止め、それ以外の時間はこのNodePoolのノードの10%（端数切り上げ）を同時に中断できる上限にする設定です。

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
      expireAfter: 720h
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 5m
    budgets:
      - nodes: "10%"
      - nodes: "0"
        schedule: "0 0 * * 1-5"
        duration: 10h
        reasons:
          - Underutilized

このYAMLはKarpenter v1.14.1のNodePool CRDスキーマで検証済みです。scheduleは常にUTCで解釈されるため、例の「0時から10時間」は日本時間の9時から19時にあたります。budgetsを書かなければ既定はnodes: 10%の1本だけです。許容数は「NodePoolのノード数×割合の切り上げ」から削除中とNotReadyのノード数を引いて計算され、複数書いた場合は最も厳しい値が使われます。統合そのものを止めたいNodePoolはconsolidateAfter: Neverにします。

v1.14.0（2026年7月11日）では、consolidationPolicyにBalancedが加わりました。統合による節約額がその入れ替えで生じる中断の半分以上（NodePool全体に対する割合で比較）のときだけ実行する方式で、わずかな節約のためにPodを何度も動かす事態を避けられます。公式のDisruptionページにも比較表と「Balanced consolidation」の節が追加されています。

EKSでは、Karpenterの運用をAWSに任せるEKS Auto Modeも選べます。NodePoolの設定項目には制約があるので、EKS Auto Modeで自動化される範囲とNodePoolの制約と比べてから決めます。

InfracostによるIaC変更費用のPR時点見積もり

Infracostは、Terraform・Terragrunt・CloudFormation・AWS CDKのコードを読み、変更でいくら増減するかをプルリクエストに書き込むツールです。AWS・Azure・Google Cloudの1,100以上のリソースに対応しています。クラスターの外側、つまりインフラを作る前の段階で止めるのが他の3層との違いです。

2026年に入ってCLIの系統が分かれました。従来のinfracost/infracost（v0.10系）は2026年9月25日にv0.10.46を出していますが、READMEはすでに新しいinfracost/cli（2026年9月30日にv2.17.0）を「すべての中核」と案内しています。

# 新CLI（v2系）の基本操作
infracost auth login
infracost scan ./infra
infracost inspect --summary

新CLIはブラウザ経由のログインが前提で、CIではINFRACOST_CLI_AUTHENTICATION_TOKENにトークンを渡します。v0.10系の設定を持ち込むときは、旧コマンドの扱いを確認してください。v2.17.0のソース（internal/cmds/deprecated.go）では次のとおりです。

• breakdown：警告を出してscanを実行する。引き継がれるのは--pathだけで、ほかのフラグは黙って捨てられる
• diff：エラーで止まり、scanを使うよう案内される
• comment：エラーで止まり、infracost ci setupでの公式CI連携へ誘導される
• generate・configure・output・upload：削除済み

breakdown --format jsonと書いたCIでも--formatは無視され、scanの既定の出力が返ります。コマンド自体は成功するため、JSONを読む後段の処理で初めて失敗する点が移行時に最も気づきにくい箇所です。JSONが要るならinfracost scan --jsonに書き換えます。料金はCI/CDのFreeが月1,000回まで無料、Starterが月額250ドル（月10,000回）、タグポリシーやガードレールを含むCloudが月額1,000ドルです。CLIの見積もりは公開価格が既定で、企業割引を反映するにはCloudの価格表機能が要ります。

導入順序と採用を見送るべき場面

依存関係があるのは「見える化→requests適正化→ノード統合」の3段階で、この順は崩さないほうがよいと考えます。最初にOpenCostで部署やサービスごとの費用を出し、削る対象を決めます。次にKRRかVPAのOffモードでrequestsを実使用量に寄せ、そのあとでKarpenterの統合を有効にします。Infracostによる事前見積もりはこの3段階と依存しないので、IaCの変更頻度が高いチームなら並行して始めて構いません。

逆に、次の場面では採用を見送るか、範囲を絞ります。

• requestsを見直していない状態でのKarpenter：過大なrequestsを満たすノードが選ばれるだけで、統合しても台数はほとんど減らない
• HPAがCPUで動いているワークロードへのVPA（CPU対象）：VPAの既知の制約に反し、両者が互いの値を打ち消し合う
• Crane・nOpsの掲載リポジトリ：リリースが止まっているか公開先が見つからず、上流の修正を当てにできない。自社でフォークを保守する体制がなければ採らない
• 月のクラウド費用が10万ドルを超えるEKS以外の環境でのKubecost無料枠：3.0の支出上限に掛かるため、OpenCostか有償版を前提に比べる

どの層も、効果は配賦の数字で確かめます。統合後のノード費用、requests変更後の空き容量をOpenCostで前後比較し、監視側のアラート閾値も合わせて見直します。監視設計はKubernetes監視・モニタリングの設計にまとめています。

よくある質問

Continuous OptimizationとFinOpsツールは同じものですか？

重なりますが同じではありません。FinOpsはクラウドとテクノロジーの事業価値を高めるための運用の枠組みと文化で、特定のツール群を指しません。Continuous OptimizationはCNCF Landscapeがリソースの継続的な最適化を行う製品を分類した区分で、FinOps専用の枠ではありません。請求データの分析だけを行うFinOpsツールは、この区分に載っていないこともあります。

Kubecostは無料で使えますか？

使えます。Kubecost 3.0の無料枠はクラスター数の制限がない代わりに、直近30日のクラウド支出が10万ドルまでです。EKSで提供されるAWS向けバンドルは追加費用なしで、この上限の対象外です。

OpenCostにPrometheusは必須ですか？

公式の要件ではPrometheusが必要です。2025年にPrometheusなしで動くCollector Datasourceがベータとして追加されましたが、本番の配賦に使うなら、Prometheusを前提とした構成で始めるのが確実です。

自動でリソースを最適化するOSSはどれですか？

クラスターを自動で書き換えるのは、PodのrequestsならVPA（RecreateやInPlaceOrRecreateモード）、ノードならKarpenterです。OpenCost・KRR・Infracostは数字を出すだけで、反映は人かCIが行います。

KarpenterとCluster Autoscalerはどちらを選ぶべきですか？

EKSやAKSで、インスタンスの種類を柔軟に選ばせたいならKarpenterです。AWSとAzureのプロバイダーは2026年9月時点でどちらもv1.14系が出ています。READMEにはOracle Cloud・IBM Cloud・Cluster APIなど計15の基盤向け実装が並びますが、GCP向けは第三者（cloudpilot-ai）の開発で、一部はAlpha段階です。成熟したプロバイダーがない環境では、従来どおりCluster Autoscalerを使います。

関連記事

• FinOpsとは？クラウドコスト管理の仕組み・3フェーズと導入判断を解説
• Karpenterとは？Kubernetesのノード自動プロビジョニングの仕組みとCluster Autoscalerとの違い・採用判断
• EKS Auto Modeとは？自動化される範囲・料金・NodePoolの制約【2026年版】
• Kubernetes監視・モニタリングの設計｜メトリクス・ログ・アラート閾値の実装判断
• Prometheusとは？SoundCloud発の監視OSSの仕組みとCNCF卒業までの経緯・Zabbixとの違い