「クラウドはオートスケーリングで無限にスケールするのだから、キャパシティ管理は前世代の概念だ」
クラウド移行初期に何度も聞いたフレーズですが、月次請求書を開いた瞬間にその幻想は崩れます。オンプレでサーバー台数とラック電力を握ってきた感覚で見れば、「リソースは有限」という前提を捨てた設計はコストとSLOの両方を蝕みます。
この記事では、TechTargetジャパン2026年5月22日掲載の「『クラウドの無限スケール』幻想に終止符」（Microsoftプリンシパルエンジニアの講演「Infinity Is Not a Strategy」が起点）を踏まえ、航空・電力業界のキャパシティ管理が示す示唆とFinOps実装手順をオンプレ経験者向けに整理します。FinOps Foundation公式フレームワーク、AWS Cost Explorer／Microsoft Cost Management／Google Cloud Billingの公式機能を一次情報ベースで比較し、明日から手を動かせる順序まで具体化します。
「クラウドは無限にスケールする」幻想がコストとSLOを同時に壊す
まず一次情報を整理します。TechTargetジャパン（ITmedia）2026年5月22日掲載記事は、Microsoft傘下のプリンシパルエンジニアが行った講演「Infinity Is Not a Strategy（無限はストラテジーではない）」を起点に、「クラウド環境でも“リソースは有限である”という前提に立ち戻り、Right-Sizing（適正規模化）を本質に据えるべき」という主張を紹介しています。
オンプレ運用の立場から見れば違和感のない指摘です。データセンターでは1ラックあたりの電力・冷却・物理スペースが上限として常に意識され、コアスイッチのポート数も上位回線の帯域も無限ではありません。クラウドに移行した瞬間にその上限が消えるわけではなく、サービスクォータ、ゾーン障害時のリソース枯渇、リージョン別のGPU・大容量インスタンスの在庫制約など、形を変えて存在し続けます。
それでも「無限スケール前提」で設計すると、典型的に3つの問題が同時発生します。
・コストが青天井になる：オートスケーリング上限を緩く設定するとトラフィック異常やバグループでインスタンスが連鎖増殖し、月末請求書で初めて気づきます。
・SLOが揺らぐ：リージョン障害時の代替リソースが必ず取れる保証はなく、大容量GPUインスタンスは枯渇することがあります。無限前提ではフェイルオーバー計画が成立しません。
・意思決定が属人化する：コストとキャパシティの責任が曖昧なまま、エンジニアが個別判断でサイズを選び、財務とビジネスの会話から切り離されます。
この3つを同時に解く枠組みが、後述するFinOpsです。その前に、「リソースは有限」を前提に運用してきた航空・電力業界の示唆を整理します。
航空業界・電力業界のキャパシティ管理がクラウドに示唆すること
ここでの航空・電力の事例は、前述のTechTargetジャパン記事および講演者（Microsoftプリンシパルエンジニア）の見解として紹介されているものです。独自の業界統計や数字は出しません。記事内で挙げられている要点をクラウド実務の文脈に翻訳します。
1. 航空業界：需要予測とオーバーブッキングの組み合わせ
航空業界は、季節・曜日・突発イベントによる需要変動に対応するため、過去予約データから「Booking Curves（予約曲線）」を抽出し需要予測モデルを運用しています。講演ではARIMA等の時系列モデルや指数平滑法（exponential smoothing）の組み合わせ、キャンセル率を踏まえたオーバーブッキングが戦術として言及されています。
クラウドに置き換えると、過去トラフィックから将来需要を予測し、予約購入（Reserved Instances／Savings Plans／コミットメント割引）の量を最適化する発想に直結します。重要なのは、需要予測を過去データの延長だけで作らず、外部イベント（キャンペーン・新機能リリース・季節要因）を変数化して織り込むことです。
2. 電力業界：N-1冗長性と負荷制限（Load Shedding）
電力業界は、単一設備の故障で系統全体が落ちないよう「N-1冗長性」を原則設計します。記事内では、2003年8月にオハイオ州起点で米国北東部からカナダにかけて広域停電（約5,000万人に影響）を引き起こした事例を踏まえ、予備容量確保が業界標準として定着している文脈で紹介されています。需要が供給を超えそうな局面では、計画的に一部負荷を切り離す「Load Shedding（負荷制限）」で系統を守ります。
クラウドに置き換えると、N-1はマルチAZ／マルチリージョン設計と予備キャパシティの確保、Load Sheddingはピーク時に重要度の低いワークロード（バッチ処理や非クリティカルなレコメンド計算など）を意図的に縮退させる設計に対応します。
3. 共通する原則：リソースは有限と認める設計の規律
航空も電力も「無限に運べる／発電できる」前提では設計せず、だからこそ需要予測・予備容量・縮退運用・路線別／需要家別の費用配賦といった運用規律が積み上がっています。FinOpsはこの思想をデジタルワークロードに適用したものと理解すると納得感が上がります。
FinOps Foundationの公式フレームワークを5分で押さえる
FinOps Foundation（Linux Foundation配下）の公式フレームワーク（finops.org/framework/）から、定義・原則・フェーズを一次情報のまま整理します。
公式定義は次の通りです。
“FinOps is an operational framework and cultural practice which maximizes the business value of technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams.”
意訳すると「エンジニアリング・財務・ビジネス各チームの協働により技術のビジネス価値を最大化し、データに基づくタイムリーな意思決定と財務的説明責任を生む運用フレームワーク兼カルチャー実践」。単なるコスト削減手法ではなく「協働」と「カルチャー」を含む枠組みです。
FinOps 6つの原則（Principles）
公式が掲げる6原則（カッコ内は意訳）。
・Teams need to collaborate（チームは協働する／財務・技術・プロダクト・経営で各技術カテゴリーを管理）
・Business value drives technology decisions（ビジネス価値が技術意思決定を駆動／単位経済とバリューベース指標）
・Everyone takes ownership for their technology usage（説明責任をエンジニアの手元に分散）
・FinOps data should be accessible, timely, and accurate（データはアクセスしやすく適時で正確）
・FinOps should be enabled centrally（中央集約的に有効化／集中機能がベストプラクティスを推進）
・Take advantage of the variable cost model of the cloud（クラウドの変動費モデルを活用）
FinOpsの3フェーズ：Crawl→Walk→Run、Inform→Optimize→Operate
公式フレームワークは成熟度モデルとして「Crawl, Walk, Run」（這う→歩く→走る）の段階的アプローチを採用し、組織は小さく始めて規模・範囲・複雑さを段階的に拡大します。実装サイクルは次の3フェーズで回ります。
・Inform（情報の可視化）：誰が・どこで・いくら使っているかを把握。タグ戦略、コスト配分、ダッシュボード整備。
・Optimize（最適化）：Right-Sizing、リザーブド／コミットメント割引、ストレージ階層最適化、不要リソース削除を実行。
・Operate（運用）：予算・アラート・異常検知・定期レビューで継続運用。
ここにFinOpsの4ドメイン（Understand Usage & Cost／Quantify Business Value／Optimize Usage & Cost／Manage the FinOps Practice）が対応します。4ドメインに散らばる活動を3フェーズのサイクルで回す、と整理すると実装に落としやすくなります。
AWS／Azure／GCPコスト管理ツール公式機能比較
FinOpsの「Inform」を担う中核ツールが、各クラウドのネイティブなコスト管理サービスです。3大クラウドの公式機能を一次情報ベースで比較します。詳細仕様や料金は各公式ドキュメント・料金ページで最新情報を再確認してください。
| 項目 | AWS Cost Explorer | Microsoft Cost Management（Azure） | Google Cloud Billing Reports |
|---|---|---|---|
| 位置づけ | AWSコストと使用量の可視化・分析 | Microsoft CloudのFinOpsツールスイート | Google Cloudの請求情報レポート |
| データ更新 | 最低24時間ごと／当月は約24時間後に閲覧可 | Commerceパイプライン経由、請求は期末から72時間後に確定 | 利用可能になり次第反映 |
| 履歴・予測 | 過去12か月／将来12か月予測 | 異常検出と予測機能 | 2017年1月以降／予測あり |
| 予算・アラート | AWS Budgetsと連携 | 予算／異常／スケジュール／EAコミット残高アラート | 予算アラート（50%/90%/100%、Pub/Sub通知可） |
| 外部出力 | CSV／API | Exports API／Cost Details API／ストレージ出力 | BigQueryエクスポート／CSV |
| 最適化推奨 | Cost Anomaly Detection／Trusted Advisor／Compute Optimizer連携 | Azure Advisorのコスト推奨を取り込み | 節約プログラム・割引・ネゴ価格を分離表示 |
3つに共通するのは、Inform（可視化）／Optimize（推奨と割引購入）／Operate（アラートとエクスポートによる自動化）の3層が公式機能でカバーされている点です。マルチクラウド構成では、各社ネイティブで Inform を完結させた後、エクスポート経由でデータレイクに集約し、横断ダッシュボードを別途構築する設計が現実解になります。
PR
クラウドFinOps 第2版 ―協調的でリアルタイムなクラウド価値の意思決定（オライリー・ジャパン）
FinOps Foundation公認の日本語書籍。原著は J.R. Storment／Mike Fuller。本記事のCrawl→Walk→RunとInform→Optimize→Operateを自社の現状に当てはめて読むと、最初の90日のアクションが具体化します。
AWS側の深掘りは「AWS Cost ExplorerとAWS Budgets入門」、機械学習による異常コスト検知は「AWS Cost Anomaly Detection入門」を参照してください。
FinOps実装手順：90日でCrawlからWalkに移行する具体ステップ
FinOps Foundationの「Crawl→Walk→Run」を、オンプレ経験のあるインフラエンジニアが実務に落とす場合の具体手順を、最初の90日でCrawlからWalkに移行する3フェーズで組み立てます。
1. Day 1～30：Inform（可視化）フェーズ
最初の30日は「誰がどこでいくら使っているかを再現可能に説明できる」状態を作ります。
・タグ戦略の設計：Environment／CostCenter／Owner／Service の最低4軸を必須化。タグ未設定リソースを毎日抽出。
・コスト管理ツールの有効化：AWSなら Cost Explorer＋CUR、Azureなら Cost Management＋Exports、GCPなら Billing Reports＋BigQueryエクスポートを有効化。
・初期ダッシュボード：サービス別・環境別・部門別の月次コスト推移を1枚に集約し、経営・財務・技術が同じ画面を見られる状態にする。
・無駄リソース棚卸し：未アタッチのEBS／管理ディスク、停止インスタンスに残るストレージ、未使用Elastic IP、古いスナップショットなど即削除可能な対象をリスト化。
2. Day 31～60：Optimize（最適化）フェーズ
次の30日で可視化したコストに対し具体的な打ち手を実行します。
・Right-Sizing：AWS Compute Optimizer／Azure Advisor／GCP Recommender のサイズ変更提案を確認し、使用率の低いインスタンスを縮小。
・割引購入：1年以上継続が見込めるベースロード分について Savings Plans／Reserved Instances／Azure Reservations／GCP Committed Use Discounts（CUDs）を検討。
・ストレージ階層最適化：S3 Intelligent-Tiering、Azure Blob ライフサイクル管理、Cloud Storage Autoclassでアクセス頻度に応じた階層へ自動移行。
・不要リソース削除の定例化：棚卸しリストを月次ミーティングで継続削減。
3. Day 61～90：Operate（運用）フェーズ
最後の30日で最適化を一度きりで終わらせない仕組みを実装します。
・予算とアラート：部門別・サービス別に月次予算を設定し50%／80%／100%でアラート。AWS Budgets／Azure Budgets／GCP Budgets（しきい値ルール、Pub/Sub通知）を活用。
・異常検知：AWS Cost Anomaly Detection、Azure Cost Management の異常検出、GCP Recommender の異常通知で想定外の急増を24時間以内に検知。
・定例レビュー：月次でエンジニア・財務・ビジネスの3者が同じダッシュボードを見て、前月差分・未達のRight-Sizing・予算超過の原因を共有。
・チャージバック／ショウバック：部門別コストを請求書相当形式で配賦し、技術投資のビジネス価値を経営層と議論する材料にする。
ここまででCrawlからWalkに到達できます。Runに進むにはユニットエコノミクスの定常計測と、IaCのコストプレビュー等の開発プロセス組み込みが必要ですが、次サイクルの領域です。
キャパシティ管理＝FinOpsの落とし穴と回避策
実装時に必ず引っかかる落とし穴を、オンプレ経験者の視点で3つ言語化します。
1. タグ運用の崩壊
最初の30日で設計したタグ戦略は3か月で崩れます。新規プロジェクトでのタグ漏れ、命名揺れ（CostCenterとcost-center、prodとproduction）、退職者がOwnerに残るなどの劣化が起きます。対策はIaC（Terraform／CloudFormation／Bicep）でタグを強制し、AWS Organizations SCP／Azure Policy／GCP Organization Policy でタグなしリソース作成をブロックすることです。
2. Right-Sizingで障害が起きる問題
CPU使用率が低いという理由で縮小したら、月末バッチでメモリ枯渇、ピークでスループット低下というインシデントが起きやすい領域です。対策はRight-Sizing前に過去90日のピーク値をCloudWatch／Azure Monitor／Cloud Monitoringで確認し、平均値だけで判断しないこと。電力業界のN-1原則を借りるなら、ピーク時でも余裕を残す前提が必須です。
3. 割引購入の塩漬けとダッシュボードの賞味期限切れ
Savings PlansやReserved Instancesを購入したのに、アーキテクチャ変更（EC2→Fargate、VM→AKS、Compute Engine→Cloud Run）で購入分が空転するケースです。購入前に今後12か月のアーキテクチャ変更予定を確認し、変更が見える領域は柔軟性の高いCompute Savings Plansを優先します。あわせて、初期ダッシュボードも3か月後には見られなくなりがち。「数字は出ているが次に何をすべきかが書いていない」が原因なので、異常時の初動アクション・相談先・直近の意思決定ログを併記して運用ドキュメントと一体化させます。
よくある質問（FAQ）
Q1. FinOpsは何人くらいの組織から必要ですか？
FinOps Foundationの原則「FinOps should be enabled centrally」は専任チーム規模ではなく「中央で支援機能を持つ」ことを求めています。1人兼任から始められ、月次コストレビューの定例化だけでも効果があります。月額クラウド利用が数十万円規模を超えた時点で兼任でも明示的な役割割当を検討するのが現実的です。
Q2. 「クラウドは無限にスケールする」は完全な誤りですか？
アーキテクチャ上スケールアウト可能という意味では正しい一方、コスト・在庫・運用負荷も無限なら誤りです。サービスクォータ、ゾーン別在庫制約、リージョン別GPU供給は現実の有限性として常に存在します。
Q3. Right-SizingとオートスケーリングはFinOps上どちらが優先ですか？
両方必要です。Right-Sizingは常時稼働分の最適化、オートスケーリングは変動分の吸収を担当し、オートスケーリングだけでは常時稼働分が肥大化、Right-Sizingだけではピーク時にSLOが揺らぎます。Optimize フェーズで組み合わせるのが定石です。
Q4. マルチクラウドFinOpsにサードパーティツールは必須ですか？
必須ではありません。3大クラウドはCSV／API／BigQuery／ストレージへのエクスポート機能を持つため、自社データレイクに集約して横断ダッシュボードを構築できます。複数事業部での横断分析や複雑な配賦が必要になった段階でサードパーティFinOpsプラットフォームを検討する順序で無理ありません。
Q5. FinOpsとSRE・セキュリティ運用の関係は？
FinOpsはコストとビジネス価値、SREは信頼性、セキュリティはリスクを運用する独立領域ですが、タグ・IaCガードレール・ダッシュボード・定例レビューなど共通基盤を共有します。90日で整備する仕組みはSRE・セキュリティとも連携できる形で設計すると後の手戻りが減ります。
本記事のまとめ
「クラウドは無限にスケールする」前提はコストとSLOの両方を蝕みます。航空業界の需要予測とオーバーブッキング、電力業界のN-1冗長性と負荷制限が示すのは、「リソースは有限」と認めて規律を積み上げてきた運用思想です。FinOpsはその思想をデジタルワークロードに適用したものと理解すると腹落ちします。
実装の道筋はシンプルです。FinOps Foundationの6原則・3フェーズ（Inform→Optimize→Operate）を縦軸に、最初の90日でタグ整備・可視化・Right-Sizing・割引購入・予算アラート・異常検知・定例レビューを順に揃える。AWS Cost Explorer／Microsoft Cost Management／Google Cloud Billing Reports の公式機能だけでCrawl／Walkのほとんどは賄えます。
オンプレで物理キャパシティと闘ってきた感覚はそのまま活きます。「リソースは有限」「予備容量を持つ」「ピーク時に縮退を許容する」「コストは部門に配賦する」という当たり前を、クラウドという別レイヤで再実装するだけです。自社の現状をCrawl／Walk／Runのどこに置き、次の30日で何を整えるかを言語化してみてください。
PR
門畑顕博・仁戸潤一郎ら著。本記事Optimizeフェーズの Right-Sizing／割引購入／ストレージ階層／不要リソース削除をAWSサービス別に実装レベルで深掘りしたい方向け。Cost Explorer／Budgets／Compute Optimizer／Trusted Advisor の使い分けと、持続的最適化の体制づくりまで整理されます。
FinOpsを「自社の言葉」で動かしたい方へ
クラウドコストの可視化からCrawl→Walk→Run の段階運用までを、現場のインフラエンジニアの視点で体系的に学びたい方へ。
オンプレの経験を活かしながら、現場で使えるクラウドスキルを体系的に身につけたい方へ、メルマガで実践的なクラウド活用ノウハウをお届けしています。
参考一次情報
・TechTargetジャパン「『クラウドの無限スケール』幻想に終止符」（2026年5月22日掲載）
・FinOps Foundation 公式フレームワーク（finops.org/framework/）
・AWS Cost Explorer 公式ページ／Microsoft Cost Management 概要／Google Cloud Billing Reports 公式ドキュメント
