💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 「なんでまた請求書が増えた?」は2026年も終わらない

2026年になっても、毎月第一火曜日には同じ会話が繰り返される。財務が「先月のAWS請求が18%増えたが理由は?」と聞き、エンジニアリングは「トラフィックが増えました」と答え、CFOが「うちはトラフィック1%増えるとコスト18%増える会社なのか?」と聞き返す。誰かがKubecostのダッシュボードを開くが、どのnamespaceが高いかは見えても、**なぜ**高いかは見えない。

これが2026年のクラウドコストの本質である。**データは溢れているが意思決定が進まない。** AWS Cost Explorer、GCP Recommender、Azure Cost Management、Kubecost、OpenCost、Vantage、Cloudability(Apptio)、Spot.io(NetApp)、CAST AI、PerfectScale、Densify — ツールが多すぎて、それぞれ別の単位で請求書を切る。だから2024年にFinOps Foundationが発表した **FOCUS 1.0** 仕様が2026年には業界標準になった。AWS·GCP·Azure·Oracle·Snowflakeが同じスキーマで請求書を出すようになり、FinOps FoundationがLinux Foundation傘下に入ってガバナンスも安定した。

さらにもう一つ爆発した。**LLM GPUコスト**である。2025年を通してOpenAI·Anthropic·Cohereの請求書を監査した企業は「これEC2より大きいぞ」と気づいた。だから2026年のFinOpsは単純にEC2 RIを買って未使用EBSを消すだけではなく、**トークン単価経済学**と**GPU使用率**が中核KPIになった。

本記事はその地図を描く。FinOps Foundationのフレームワークから、Kubecost·OpenCost·Vantageのようなツールの位置づけ、Karpenter vs Cluster Autoscaler、Spot.io·CAST AIの自動化、そしてLLM推論コストまで。

1. FinOpsライフサイクル — Inform · Optimize · Operate

FinOps Foundationの公式フレームワークは3段階のライフサイクルである。2026年版(FinOps Framework v2)でドメインとcapabilityが整理された。

- **Inform(情報化)**: 誰が、何を、なぜ使っているかを可視化する。タギング、割当、請求分解、ユニットエコノミクス。

- **Optimize(最適化)**: 見えるものを実際に削る。RI/SP購入、未使用リソース削除、ライトサイジング、スポット活用。

- **Operate(運用化)**: 最適化を一過性のイベントではなく日常運用に組み込む。ポリシー、ガードレール、コストSLO、部門チャージバック。

ありがちな失敗: **Optimizeから始める。** Reserved Instanceを先に買うが、どのワークロードがどこで動いているか把握していない。するとRI利用率が60%台に落ち、節約額より未使用RI損失が大きくなる。順序は常に **Inform → Optimize → Operate**。

ドメインは6つ: Understand Usage and Cost、Quantify Business Value、Manage the FinOps Practice、Optimize Usage and Cost、Manage Anomalies、Forecast。2026年に追加されたcapabilityは **Sustainability**(炭素計測とコストを同時に見る)と **Onboarding Workloads**(新規ワークロードがFinOps体系に入る手順)。

2. FOCUS 1.0 — クラウド請求書の共通言語

FOCUS(FinOps Open Cost and Usage Specification)1.0は2024年6月にGAされ、2026年現在1.2がロードマップで議論されている。要点は **すべてのクラウド請求を同じカラムスキーマに揃える** ことだ。

| カラム | 意味 |

| --- | --- |

| `BilledCost` | 実際の請求額(RI/SP割引反映後) |

| `EffectiveCost` | 約定·前払いを按分した実効単価 |

| `ListCost` | 割引前の定価 |

| `ContractedCost` | 契約単価 |

| `ServiceCategory` | Compute / Storage / Networking / AI and Machine Learning ... |

| `ChargeCategory` | Usage / Purchase / Tax / Credit / Adjustment |

| `BillingPeriodStart/End` | 請求期間 |

| `ResourceId`, `ResourceType` | リソース識別子 |

| `Tags` | k=v ペア(正規化済み) |

| `SkuId`, `SkuPriceId` | SKU識別子 |

2026年の意味: AWS CUR(Cost and Usage Report)、GCP BigQuery Billing Export、Azure Cost Management Exportがすべて FOCUS 1.0 で出力できる。つまり **一つのSQLクエリで三大クラウドを横断的に見られる**。Vantage·Cloudability·Anodot·FinoutのようなSaaSはもはやプロバイダー別パーサーを維持する必要がなくなった。

-- FOCUS 1.0 統合クエリ — マルチクラウドコストTop-10サービス

SELECT

ServiceCategory,

ServiceName,

ProviderName,

SUM(EffectiveCost) AS cost_usd

FROM focus_billing

WHERE BillingPeriodStart >= '2026-05-01'

AND BillingPeriodEnd < '2026-06-01'

GROUP BY 1, 2, 3

ORDER BY cost_usd DESC

LIMIT 10;

3. Kubecost — Kubernetesコストをnamespace/podまで分割

Kubecostは2024年にIBMが買収した後もOSS版が維持されている。中核機能は **Kubernetesコストをcluster → namespace → deployment → pod単位で割り当てる** こと。

デプロイは簡単だ。

helm repo add kubecost https://kubecost.github.io/cost-analyzer/

helm install kubecost kubecost/cost-analyzer \

--namespace kubecost --create-namespace \

--set kubecostToken="$(echo helm-install@kubecost.com | base64)"

インストールされるもの:

- `cost-analyzer` (UI + API)

- `kube-state-metrics`, `prometheus`, `node-exporter` (メトリクス収集)

- Network Costs Daemonset (オプション — クラスタ内外のトラフィック費用)

Allocation API 呼び出し例:

過去7日間のnamespace別コスト

curl -G "http://kubecost.local/model/allocation" \

--data-urlencode "window=7d" \

--data-urlencode "aggregate=namespace" \

--data-urlencode "accumulate=true" \

| jq '.data | to_entries | map({name:.key, cost:.value.totalCost}) | sort_by(.cost) | reverse'

中核概念:

- **Allocation**: どのワークロードがいくら使ったか(cpuCost、ramCost、gpuCost、pvCost、networkCost)。

- **Asset**: クラスタに実際に課金されたリソース(ノード、ディスク、LB)。

- **Cloud Integration**: クラウド請求書を取り込み、ノードの実単価で補正する。未設定の場合はオンデマンドのlist priceが使われ実請求との差が出る。

見落とされがちなのは、**idle cost**(ノードは立ち上がっているがpodが動いていない時間)と **shared cost**(kube-system、monitoringのような共通コスト)の配分ポリシーだ。Kubecostは4種類提供する — `evenly`、`proportional`、`weighted`、`none`。

4. OpenCost — KubecostのOSSコア、CNCF Sandbox

OpenCostはKubecostのコスト割当エンジンがCNCFに寄贈されたプロジェクトだ。2022年に発足、2024年にIncubatingへ昇格。2026年現在は `kubectl cost` プラグインまで安定化している。

Kubecostとの関係:

- OpenCost = アルゴリズム + メトリクス + API。

- Kubecost = OpenCost + UI + マルチクラスタ + レポート + アラート + SaaS。

Prometheus exporterとして動作するので、Grafanaダッシュボードを直接構築できる。

namespace別の時間あたりコスト (USD)

sum by (namespace) (

node_namespace_pod_container:container_cpu_usage_seconds_total:sum_irate

* on(node) group_left

node_cpu_hourly_cost

)

+ sum by (namespace) (

container_memory_working_set_bytes / 1024 / 1024 / 1024

* on(node) group_left

node_ram_hourly_cost

)

OpenCostの意義は **ベンダーロックインのないコスト標準** だ。AWS·GCP·Azureの料金表はOpenCostが保有し、Kubecost·Vantage·CAST AIといった商用ツールも内部的にOpenCostメトリクスに従う。

5. Vantage — マルチクラウドコストの統合UI

Vantageは2020年創業のSaaS。強みは **UI/UX** と **統合の速さ** だ。AWS·GCP·Azure·Snowflake·Datadog·MongoDB Atlas·Databricks·Fastlyまでの請求書を一画面に集約する。

主要機能:

- **Cost Reports**: スライス/ダイスが直感的。dimension(account, service, region, tag)を追加して時系列で見る。

- **Active Resources**: 実際に課金されているリソースだけを表示。空のEBSのような無駄資源の整理に有用。

- **Anomalies**: 異常コストスパイクの検出。Slack/PagerDuty通知。

- **Autopilot**: AWS Compute Savings Plansの自動購入·管理(オプション、手数料モデル)。

- **Network Flow Reports**: データ転送コスト分析。どこからどこへ送られているかが見える。

2026年に追加された大きな機能は **FOCUS 1.0ネイティブビュー** と **AI Cost** ダッシュボード(OpenAI/Anthropic/Bedrock統合)。

価格は使用量比例の%モデル(管理コストの0.5-2%程度)。

6. Cloudability(Apptio·IBM) — エンタープライズFinOpsの老舗

Cloudabilityは2011年創業、クラウドコストSaaS最古参である。2019年にApptioが買収、2024年にIBMがApptioを買収。現在はIBM傘下の製品。

特徴:

- **TBM(Technology Business Management)** 統合。IT資産をビジネス価値単位にマッピングするIBM·Apptio方法論。

- **Containers(Cloudability Containers)**: Kubecost同様のコンテナコスト割当。EKS/AKS/GKE対応。

- **Rightsizing推奨**: ML駆動のEC2/RDSダウンサイズ。

- **Reserved Instance Planner**: RI/SPシミュレーション。1年·3年、部分/全額前払いを比較。

- **True Cost**: 直接コスト + 間接コスト(エンジニア人件費、ライセンス)。

Cloudabilityを使うべき場面: **年間 `$1M` 以上のクラウド支出** と **複数のBU/コストセンター** を運用するエンタープライズ。チャージバック·ショウバック·予算ワークフローが強い。スタートアップ·中堅企業はVantageの方がコスパが良い。

7. Spot.io(NetApp) — スポット自動化の元祖Ocean

Spot.ioは2020年にNetAppが買収した。主力製品は二つ。

- **Elastigroup**: EC2/GCE/Azure VMのスポット·オンデマンド混在を自動管理。割り込み予測MLでワークロードを自動移行。

- **Ocean**: Kubernetesノードの自動管理。Cluster Autoscalerを置き換える。

Oceanの動作:

1. podの要求(CPU/メモリ/GPU)を分析する。

2. 最もコスト効率の良いインスタンスタイプを選んでノードを立ち上げる。

3. スポット利用率を最大化(目標%を設定可能)。

4. 割り込み発生が近づいたらワークロードを別ノードへ事前移行(Spot Interruption Predictor)。

差別化ポイント: **headroomの自動管理**、**rightsizing推奨を直接適用**(Ocean Rebalance)、**VNG(Virtual Node Group)** によるワークロード分離管理。

2026年現在Karpenterが台頭しOceanのシェアは横ばいだが、**マルチクラウド + 非Kubernetes** まで自動化したいチームには依然として強力な選択肢だ。

8. CAST AI — 自動リバランスとCommitments

CAST AIは2019年創業の後発だが急成長中。強みは **自動化の積極性** と **クラウド抽象化** だ。

主要機能:

- **Autoscaler**: Karpenter同様、podの要求を直接見てノードを立ち上げる。Cluster Autoscaler代替。

- **Rebalancer**: 定期的にクラスタを分析し、より安いインスタンスへワークロードをダウンタイムなく移動。

- **Spot Automation**: スポット·オンデマンド自動混在。割り込み処理が組み込み。

- **Commitments Engine**: RI/SP購入推奨 + 自動マネジメント。

- **Multi-cloud**: AWS/GCP/Azureで同じUI。

設定例(CAST AIクラスタ接続後のHelm):

castai-cluster-controller values.yaml

apiKey:

key: $CAST_AI_API_KEY

clusterID: $CAST_AI_CLUSTER_ID

autoscaling:

enabled: true

unschedulablePods:

enabled: true

nodeDownscaler:

enabled: true

emptyNodes:

delaySeconds: 60

spotInstances:

enabled: true

spotDiversityEnabled: true

spotInterruptionPredictionsEnabled: true

2026年の差別化ポイントは **AI Workload Optimizer** — GPUワークロードの使用率測定とrightsizing推奨を自動化。NVIDIA DCGMメトリクスを活用する。

9. Karpenter vs Cluster Autoscaler — 2026年の標準はどちらか

Cluster Autoscaler(CA)はKubernetes標準のノードオートスケーラだ。**Auto Scaling Groupを通じて** ノードを増減する。難点はASGのインスタンスタイプが固定であること。ワークロードが多様な場合は複数のASGを作り、各ASGに優先順位を付ける必要がある。

KarpenterはAWSが2021年に発足、2024年にv1.0 GA。2026年現在 **EKSのデフォルトオートスケーラとして定着し、Azure(AKS Karpenter Provider)とGCPにも移植されている。**

違いは本質的だ。

| 軸 | Cluster Autoscaler | Karpenter |

| --- | --- | --- |

| 動作 | 事前構築のASGをスケール | podの要求に合わせて直接ノードをプロビジョン |

| インスタンス選択 | 単一/限定的 | 広範(多様性 = 可用性 + コスト) |

| スポット対応 | ASG mixed instances policy | ネイティブ |

| 抽象化 | ClusterAutoscaler CR | NodePool + EC2NodeClass |

| ノード起動時間 | 3-4分程度 | 40秒程度 |

| 断片化整理 | 困難(drift) | consolidationが自動 |

NodePool例:

apiVersion: karpenter.sh/v1

kind: NodePool

metadata:

spec:

template:

metadata:

labels:

intent: apps

spec:

requirements:

- key: kubernetes.io/arch

operator: In

values: ["amd64", "arm64"]

- key: kubernetes.io/os

operator: In

values: ["linux"]

- key: karpenter.sh/capacity-type

operator: In

values: ["spot", "on-demand"]

- key: karpenter.k8s.aws/instance-category

operator: In

values: ["c", "m", "r"]

- key: karpenter.k8s.aws/instance-generation

operator: Gt

values: ["5"]

nodeClassRef:

group: karpenter.k8s.aws

kind: EC2NodeClass

limits:

cpu: 1000

memory: 1000Gi

disruption:

consolidationPolicy: WhenEmptyOrUnderutilized

consolidateAfter: 30s

決定的なのは `consolidationPolicy: WhenEmptyOrUnderutilized` — 未使用ノードを自動的に整理する。CAでは直接実現しにくい機能だ。

2026年の選択: **AWS EKSならKarpenter**、**GCP GKEならGKE Autopilotまたは Karpenter GCP**、**AKSならKarpenter Provider**、**もっと自動化したいならCAST AI/Ocean**。

10. スポットインスタンス — 割り込みを設計に織り込む

スポットインスタンスは平均で70-90%割引される。難点は2分(AWS)·30秒(GCP preemption)·30秒(Azure)で回収される可能性があること。

スポット設計原則:

1. **インスタンスを多様化する**。一種類に偏らないこと。AWSの標準は今では「spot allocation strategy: price-capacity-optimized」。

2. **graceful shutdown**。PreStop hook、terminationGracePeriodSeconds、in-flightリクエストのdrain。

3. **チェックポイント**。長時間ジョブの進行状況をS3に定期保存。

4. **AZの多様化**。あるAZでスポットが枯れたら別のAZへ。

5. **ステートフルワークロードは慎重に**。RDS·OpenSearchはRI。Kafka·Cassandraは可能だが割り込み処理必須。

6. **Interruption Handler**。AWS Node Termination Handler(NTH)、GKEのspot preemption handler。

NTHデプロイ:

helm repo add eks https://aws.github.io/eks-charts

helm install aws-node-termination-handler eks/aws-node-termination-handler \

--namespace kube-system \

--set enableSpotInterruptionDraining=true \

--set enableRebalanceMonitoring=true \

--set enableRebalanceDraining=true \

--set queueURL=$NTH_SQS_QUEUE_URL

2026年の経験則: 良く設計されたスポットクラスタはコストを60-80%削減する。逆に設計が悪いと割り込みがSLAを破壊する。だから一般的な分割は **batch·CI·dev·stateless APIはスポット、データベース·セッションストア·決済はオンデマンド** となる。

11. Reserved Instance vs Savings Plans vs Spot — 約定の三者比較

AWSの割引オプションは3種類。2026年現在のまとめ。

| オプション | 割引 | 約定単位 | 柔軟性 | 譲渡 |

| --- | --- | --- | --- | --- |

| Convertible RI | 最大54% | インスタンスファミリー交換可能 | 中 | 不可 |

| EC2 Instance Savings Plan | 最大72% | インスタンスファミリー + リージョン | 低 | 不可 |

2026年の実務推奨:

- **ベースラインはCompute Savings Plan**。柔軟性が最も高い。

- **長期固定ワークロード(DB·コントロールプレーン)はStandard RI 1年または3年**。

- **バーストとdev/CI/batchはSpot**。

- **GPUワークロードはSP ComputeまたはCapacity Block**。

GCPはCommitted Use Discounts(CUD)とSustained Use Discounts、AzureはReservationとSavings Planで類似モデル。FOCUS 1.0の `CommitmentDiscountType` カラムがこの3つを統合する。

12. Kubernetesリソースのrightsizing — request·limitの神話

ありがちな誤解: 「limitを高くしておけば安全」。実際はその逆 — **limitが高いとノードパッキングが非効率** になりコストが膨らむ。CPU limitはthrottlingを引き起こしlatencyを破壊する。

2026年のrightsizing指針:

1. **CPU limitは設定するな**(Tim Hockinの長年の立場)。throttlingがlatencyキラー。ノードパッキングはrequestで行う。

2. **Memory limitは設定する**。メモリリーク防御。request = limitが最も安全。

3. **requestはP95-P99実使用量基準**。Prometheusの90日データから算出。

4. **VPAは `Off` モードでrecommendation取得**、**`Auto` モードは危険**。再起動が発生する。

PerfectScale·Densify·CAST AIのrightsizing推奨はこのデータを自動的に見ている。

VPA recommendation抽出:

kubectl get vpa my-app -o jsonpath='{.status.recommendation}'

{"containerRecommendations":[{"containerName":"app",

"lowerBound":{"cpu":"50m","memory":"100Mi"},

"target":{"cpu":"100m","memory":"200Mi"},

"upperBound":{"cpu":"200m","memory":"400Mi"}}]}

13. LLM·GPUコスト — トークン単位経済学

2026年に最も急成長しているコストカテゴリーはLLM推論だ。自前GPU(EKS H100、GCP a3-highgpu、Azure ND H100 v5)か、API(OpenAI、Anthropic、Bedrock、Vertex AI)か。

API価格(2026年5月時点の代表値):

| モデル | input $/1M tok | output $/1M tok |

| --- | --- | --- |

| GPT-5 (OpenAI) | $5.00 | $15.00 |

| Claude Opus 4.7 | $15.00 | $75.00 |

| Claude Sonnet 4.6 | $3.00 | $15.00 |

| Gemini 2.5 Pro | $2.50 | $10.00 |

| GPT-4o-mini | $0.15 | $0.60 |

自前ホスティングコスト(H100 SXM):

| --- | --- | --- | --- |

| AWS p5.48xlarge | 8xH100 | $98.32 | ~$70 |

| GCP a3-highgpu-8g | 8xH100 | $88.50 | ~$60 |

| Azure ND H100 v5 | 8xH100 | $91.00 | ~$65 |

トークン単位経済学の式:

$/1M tok (セルフホスト) = (時間あたりコスト / 時間あたり処理トークン数) * 1M

時間あたり処理トークン数 = throughput tok/s * 3600

vLLM·SGLang·TensorRT-LLMのスループットを計測してbreak-even点を求める。一般則は **1日`<10M`tok = API**、**`10M-1B`tok = ハイブリッド**、**`>1B`tok = セルフホスト検討**。

コスト可視化:

- **Helicone**、**Langfuse**、**LangSmith** がAPI呼び出しごとのコストを追跡する。

- **OpenAI Usage Dashboard** がプロジェクト·APIキー別にトークン消費を分離。

- **Kubecost GPU Allocation** がセルフホストGPUの使用率をnamespaceに割り当てる。

14. S3ストレージクラス — ポリシー一行で60%削減

S3コストは二要素: ストレージ + リクエスト·転送。ストレージクラスポリシーを組まないと積み上がる。

2026年のS3ストレージクラス(USD/GB-month、代表値):

| クラス | 価格 | アクセスパターン |

| --- | --- | --- |

| Standard | $0.023 | 頻繁 |

| Standard-IA | $0.0125 | 月1回以下 |

| One Zone-IA | $0.01 | 非重要·復旧可能 |

| Intelligent-Tiering | $0.023 + 監視費 | パターン不明 |

| Glacier Instant Retrieval | $0.004 | 四半期1回 |

| Glacier Flexible Retrieval | $0.0036 | 年1回、分-時間単位で復元 |

| Glacier Deep Archive | $0.00099 | 7-10年保管 |

ライフサイクルポリシー例:

{

"Rules": [

{

"ID": "logs-lifecycle",

"Status": "Enabled",

"Filter": { "Prefix": "logs/" },

"Transitions": [

{ "Days": 30, "StorageClass": "STANDARD_IA" },

{ "Days": 90, "StorageClass": "GLACIER_IR" },

{ "Days": 365, "StorageClass": "DEEP_ARCHIVE" }

"Expiration": { "Days": 2555 }

{

"ID": "incomplete-mpu-cleanup",

"Status": "Enabled",

"AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }

}

]

}

よくある二大漏れ: (1) **incomplete multipart upload** — アップロード失敗の残骸がストレージコストに計上される。上のルールで7日後削除。(2) **バージョニング有効·失効ポリシー無し** — 古いバージョンが無限に蓄積する。

15. データegress — 隠れコストの第一位

データ送信(egress)は請求書を見るまで気付かない。しかし設計を誤るとコンピュートより高くなる。

代表単価(2026年):

| 経路 | $/GB |

| --- | --- |

| AWS → インターネット | $0.09(最初の10TB) |

| AWS リージョン間 | $0.02 |

| AWS AZ間 | $0.01 |

| GCP → インターネット | $0.12 |

| GCP リージョン間 | $0.01-0.08 |

| Azure → インターネット | $0.087 |

| CloudFront → インターネット | $0.085(北米·欧州) |

設計原則:

1. **同じAZにデータを置く**。RDS·EKS·キャッシュが別AZだとAZ間トラフィック費が累積。

2. **VPC Endpoint(PrivateLink)**。S3·DynamoDBはGateway Endpointで無料。SNS·SQSはInterface Endpoint(`$0.01/hr`)。

3. **CDNを最大活用**。CloudFront、Cloudflare、Fastlyのorigin egress割引。

4. **Cross-region replicationはコスト認識**。S3 CRRは同クラスへの複製でtransfer + storage二重。

5. **VPC Flow Logsでmonitoring**。AWS Cost Explorerはsourceを開示しない。Flow LogsでソースIP分析。

KubecostのNetwork Costs Daemonsetはこの領域をクラスタ内から自動計測する。

16. RDSコスト — RIの数学とread replicaの落とし穴

RDSコストはインスタンス + ストレージ + IOPS + バックアップ + データ転送。約定で50-70%削減できる。

RI数学例 — db.r6g.4xlarge(us-east-1):

- オンデマンド: $1.36/hr → 3年 = $35,750

- 1年 No Upfront RI: $0.85/hr → $7,446

- 3年 All Upfront RI: $0.43/hr → $11,300(前払い)、break-even 約17ヶ月

推奨:

- **本番DBは常に約定**。オンデマンドRDSはstage·devのみ。

- **3年 All Upfront** が最大割引だが、**ワークロード安定性を見て判断**。

- **read replicaにもRI適用可能**。writer/reader両方を約定する。

- **Aurora I/O-Optimized vs Standard**: I/O重なら I/O-Optimized に切り替えればIOPS課金が消える。

- **Reserved Capacity(Aurora Serverless v2 → Aurora Capacity Units, ACU)** — 2026年にACUにも1年約定オプションが入った。

- **Blue/GreenデプロイでDBアップグレード**。EOLインスタンスは価格が上がる。

17. コストガバナンス — OPA·Kyvernoでガードレール

コストを「見る」から「止める」に進むにはポリシーが必要だ。2026年標準はOPA(Open Policy Agent)またはKyverno。

Kubernetes Gatekeeper例 — limit無しpodをブロック。

apiVersion: constraints.gatekeeper.sh/v1beta1

kind: K8sRequiredResources

metadata:

spec:

match:

kinds:

- apiGroups: [""]

kinds: ["Pod"]

namespaces: ["prod", "stage"]

parameters:

requests: ["cpu", "memory"]

limits: ["memory"]

Terraformレベルのポリシー — 高価なインスタンスをブロック(OPA Conftest):

package terraform.cost

deny[msg] {

resource := input.resource.aws_instance[name]

blocked := {"p5.48xlarge", "p4d.24xlarge"}

resource.instance_type == blocked[_]

not has_approval_tag(resource)

msg := sprintf("Instance %s requires CostApprover tag", [name])

}

has_approval_tag(r) {

r.tags.CostApprover != ""

}

組織レベルのガード:

- **タギング強制**。CostCenter·Project·Environment·Owner。

- **予算アラート**。AWS Budgets、GCP Budgets、Azure Cost Alerts。

- **Anomaly Detection**。AWS Cost Anomaly Detection、Vantage Anomalies。

- **dev環境の自動シャットダウン**。夜間·週末。

18. ユニットエコノミクス — $/request、$/user、$/feature

FinOpsの究極指標は **ユニットエコノミクス** だ。請求書の絶対値は意味が薄い — 「ユーザー1人をサーブするのにいくら」が意味だ。

よく使う単位:

- **$/request**: API費を呼び出し回数で割る。

- **$/user**: 月間アクティブユーザー1人あたりのインフラ費。

- **$/transaction**: 決済·注文のような中核ビジネストランザクションあたり。

- **$/feature**: 一機能を運用するコスト(マルチサービス按分が必要)。

- **$/1M token**: LLMワークロード。

ダッシュボード設計:

[推移] 月別 $/MAU ── ユニットエコノミクスが改善しているか

[分解] サービス別 $/request ── どこで非効率か

[アラート] ユニットエコノミクス +20% ── 回帰検出

これが無いとトラフィック増加にコストが線形に追随する。うまく回ればトラフィック2倍でコスト1.3倍(規模の経済)のようなグラフが出る。

19. 韓国事例 — Woowa Brothers·LINE·Kakao

韓国大手テックのFinOps事例。

- **Woowa Brothers(Baemin)**: 2023年からFinOps専任チームを別途運営。Kubecost社内フォーク + 独自ユニットエコノミクスダッシュボード(注文1件あたりのインフラ費)を構築。2024年カンファレンスで「注文あたりコストを30%削減」と発表。

- **LINE Plus**: グローバルメッセージトラフィックが巨大 → 自社PoP + クラウドのハイブリッド。2025年からLLM推論コスト可視化のため独自トークントラッカーを構築、Helicone/Langfuseのパターンを参照。

- **Kakao**: マルチクラウド(AWS+GCP+Naver Cloud) → FOCUS 1.0導入で請求書統合。社内BigQueryから一本のSQLで見ている。

- **Coupang**: AWSヘビー。Reserved Instance·Savings Plan自動マネジメントSaaS導入後、RI利用率95%以上を維持。

- **Toss**: Karpenter早期採用(2022年)、スポット比率80%以上。決済はオンデマンド、それ以外はスポット。

共通点: (1) FinOpsを財務ではなく **エンジニアリングKPI** として扱う。(2) ユニットエコノミクスのダッシュボードを持つ。(3) 可視化 → 自動化の順序。

20. 日本事例 — NTTドコモ·楽天·LINE

日本のFinOpsも急速に整いつつある。

- **NTTドコモ**: 通信バックエンドの大規模AWS利用。2024年FinOps Foundation Japan Chapterで「タギング·チャージバックを強制したら未使用RIが40%減った」と発表。

- **楽天**: 長年の自前データセンターから GCP·AWS マルチクラウドへ移行中。Cloudability(Apptio) + 自社ツールの組み合わせ。

- **LINE東京**: 韓国LINE Plusとは別に、日本LINEはNHN·ソフトバンクグループのワークロードと統合。Spot.io Oceanを広く活用。

- **CyberAgent**: 広告プラットフォームが大規模BigQuery利用 → VantageでBigQueryスロットコストの可視化 + ワークロードスケジューリング。

- **メルカリ**: GKEヘビー。GKE Autopilotを積極活用、Kubecostでnamespace単位のチャージバック。

文化差: 日本企業は **チャージバック·予算ガバナンス** に重きを置く傾向。韓国企業は **自動化·rightsizing** が速いという評。両者とも2026年はFOCUS 1.0導入が標準。

21. オープンソース vs SaaS FinOpsツール — 選定基準

| 項目 | オープンソース(OpenCost+Grafana、Komiser) | SaaS(Kubecost SaaS、Vantage、Cloudability) |

| --- | --- | --- |

| 初期コスト | 0 | $1k-50k/mo |

| 運用コスト | エンジニア工数 | ライセンス |

| セットアップ時間 | 1-2週間 | 1-2日 |

| マルチクラウド | 自前で統合 | 内蔵 |

| チャージバックワークフロー | 自前で実装 | 内蔵 |

| アラート·anomaly | 自前で構築 | 内蔵ML |

| データセキュリティ | 自社インフラ | 外部SaaS(選択肢あり) |

推奨:

- **年間クラウド支出 `<$500k`**: OSSで開始 — OpenCost + Grafana + クラウドネイティブ(Cost Explorer/Recommender/Cost Mgmt)の組み合わせ。

- **年間 `$500k-3M`**: VantageのようなSaaS — 運用負担 vs ライセンスを比較。

- **年間 `>$3M`**: Cloudability/Anodot/Apptioのようなエンタープライズ + 自動化(CAST AI、Spot.io)。

ここで罠: **ツールを買えばコストは下がらない。** ツールは可視化するだけ。削るのは人の判断。だからFinOps Foundationは常に「ツール < 文化」を強調する。

22. アンチパターン — FinOpsが失敗する7つの理由

現場でよく見る失敗パターン。

1. **タギングが任意**。CostCenterタグがオプションだと50%が欠落する。強制しないとダメ。

2. **財務しか見ない**。エンジニアがコストダッシュボードを見ないと意思決定が進まない。

3. **RIを先に買う**。ワークロードパターンを知らずに買ったRIは黒字にならない。

4. **rightsizingしかしない**。60%削減はrightsizingではなくアーキテクチャ(スポット·キャッシュ·S3クラス)。

5. **anomalyアラートを無視する**。アラートが多すぎてミュートすると本物の漏れも逃す。

6. **ユニットエコノミクスを見ない**。絶対コストだけ見るとトラフィック増加がコスト増加に見えるだけ。

7. **GPU·LLMを別カテゴリ扱い**。2026年はAIコストがインフラコストの30-50%。別管理しないと爆発する。

23. 90日FinOps導入ロードマップ

初めてFinOpsを始めるチーム向けのステップ。

**Days 1-30(Inform)**

1. CUR/Billing Export → BigQuery/Snowflake/S3にパイプライン。

2. FOCUS 1.0カラムに正規化。

3. 主要dimension定義(Account、Service、Environment、Team)。

4. タギングポリシー公表、未タグ率計測。

5. Kubecost/OpenCostインストール → Kubernetesコスト可視化。

6. 週次コストレビューミーティング開始。

**Days 31-60(Optimize)**

1. Top-10コストワークロード特定。

2. rightsizing推奨をレビュー(VPA·CAST AI·PerfectScale)。

3. 未使用リソース整理(空のEBS·idle ELB·古いスナップショット)。

4. S3ライフサイクルポリシー導入。

5. 初回RI/SP購入(保守的に1年約定)。

6. dev/CI環境の夜間自動停止。

**Days 61-90(Operate)**

1. コストアラート(Anomaly Detection、ユニットエコノミクス回帰)。

2. OPA/Kyvernoでポリシー施行。

3. チャージバック/ショウバックレポートをBU別配信。

4. KPI定義(`$/MAU`、`$/request`、RI利用率目標)。

5. FinOpsチャンピオン任命(各チーム1名)。

6. 四半期コストOKRに統合。

24. 2027年展望 — AIワークロードとsustainability

向こう1-2年のトレンド。

1. **AIコストが1番カテゴリーになる**。2027年には多くの企業でAI請求書 > 一般コンピュート請求書。

2. **トークン単位SLO**。応答時間SLOのように「ユーザーあたりトークンコスト」SLOが一般化。

3. **FOCUS 1.x → 2.0**。1.1ではcommitmentモデルの標準化、2.0ではcarbonメトリクスの統合。

4. **Sustainability統合**。コスト = $ + CO2。AWS Customer Carbon Footprint、GCP Carbon Footprint、Azure Emissions ImpactのFOCUS統合。

5. **自律FinOps(autonomous FinOps)**。CAST AI·Spot.ioのような自動化がさらに深化 — 人間の承認なしにクラスタを再配置。

6. **AIエージェント基盤のFinOps分析**。「なぜ先週コストが増えたか?」をLLMがデータ分析で回答。

7. **エッジ·CDNコストの台頭**。エッジコンピュートとAI推論のエッジ移行で新カテゴリ。

締め: 2026年のFinOpsはもはや「財務がコストレポートを作る」ではない。**エンジニアリング組織のガードレールであり、ユニットエコノミクスは会社OKR** である。ツールはOpenCost·Vantage·CAST AIといった十分な選択肢がある。足りないのは常に **文化と実行** である。

References

- FinOps Foundation Framework — [https://www.finops.org/framework/](https://www.finops.org/framework/)

- FOCUS Specification — [https://focus.finops.org/](https://focus.finops.org/)

- Kubecost — [https://www.kubecost.com/](https://www.kubecost.com/)

- OpenCost CNCF Project — [https://www.opencost.io/](https://www.opencost.io/)

- Vantage — [https://www.vantage.sh/](https://www.vantage.sh/)

- Cloudability (Apptio/IBM) — [https://www.apptio.com/products/cloudability/](https://www.apptio.com/products/cloudability/)

- Spot.io by NetApp — [https://spot.io/](https://spot.io/)

- CAST AI — [https://cast.ai/](https://cast.ai/)

- Karpenter — [https://karpenter.sh/](https://karpenter.sh/)

- Kubernetes Cluster Autoscaler — [https://github.com/kubernetes/autoscaler](https://github.com/kubernetes/autoscaler)

- AWS Cost Explorer — [https://aws.amazon.com/aws-cost-management/aws-cost-explorer/](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)

- AWS Savings Plans — [https://aws.amazon.com/savingsplans/](https://aws.amazon.com/savingsplans/)

- GCP Recommender — [https://cloud.google.com/recommender](https://cloud.google.com/recommender)

- Azure Cost Management — [https://azure.microsoft.com/en-us/products/cost-management/](https://azure.microsoft.com/en-us/products/cost-management/)

- PerfectScale — [https://www.perfectscale.io/](https://www.perfectscale.io/)

- Densify — [https://www.densify.com/](https://www.densify.com/)

- AWS Node Termination Handler — [https://github.com/aws/aws-node-termination-handler](https://github.com/aws/aws-node-termination-handler)

- Open Policy Agent (Gatekeeper) — [https://open-policy-agent.github.io/gatekeeper/](https://open-policy-agent.github.io/gatekeeper/)

- Kyverno — [https://kyverno.io/](https://kyverno.io/)

- vLLM — [https://docs.vllm.ai/](https://docs.vllm.ai/)

- Helicone — [https://www.helicone.ai/](https://www.helicone.ai/)

- Langfuse — [https://langfuse.com/](https://langfuse.com/)