レッスン6：クラウドのコストとガバナンス——FinOps の発想

このレッスンで学ぶこと

クラウドの従量課金が引き起こす「コストの落とし穴」を理解する
予約インスタンス・Savings Plans・コミットメントの違いを把握する
タグ付けとコスト可視化の発想を持つ
予算アラートとオートスケーリングの設計判断を理解する
FinOps Foundation の発想を整理する
2026 年 6 月時点の生成 AI 推論コスト構造を概観する

前のレッスンでは、コンテナ・サーバーレス・マネージドサービスといったモダンな実行環境を扱いました。今回のレッスンでは、視点を変えて「お金」の話に焦点を当てます。「クラウドは安い」という言葉は、業界で長く流通してきた神話です。現場で見てきたのは、移行後にコストが想定の 3 倍に膨らんだ案件、放置された仮想マシンに月数十万円を払い続けた組織、生成 AI の推論で月額が読めなくなったスタートアップでした。本レッスンでは、コストの落とし穴とそれに立ち向かう発想（FinOps）を整理します。

「クラウドは安い」神話への批判

「クラウドにすればコストが下がる」というのは、文脈に依存する命題です。条件次第で安くもなれば、高くもなります。

安くなりやすい条件

需要が大きく変動する（ピークの数十倍）：オンプレでは最大需要に合わせて設備を持つ必要があるが、クラウドなら使った分だけ
立ち上げが速い新規事業：オンプレの 5 年減価償却を待たずに開始・撤退が判断できる
災害対策・地理分散：複数の場所に設備を持つコストが、自社建設より大幅に安い
短期間の実験・PoC：数か月だけ使ってやめる、が現実的な選択肢になる

高くなりやすい条件

需要が安定していて、常時フル稼働している：オンプレの償却が終われば原価が下がるが、クラウドは使うかぎり料金が続く
移行のための再設計・スキル獲得を軽視した：クラウドの利点を活かさず「単にオンプレと同じ構成を乗せた」場合
ガバナンスが甘い：誰がいつ何を起動したか追えず、放置されたリソースが積み上がる
データ転送料金の計算を見落とした：クラウドからインターネットへの「出向け（egress）」転送には料金がかかる
マネージドサービスを乱用：マネージド DB を 10 個立ててテスト後に消し忘れる、など

💡 ポイント 「クラウドが安いかどうか」は組織の使い方で決まります。「安い」という前提で予算を立てると、想定との乖離で説明責任が発生します。

従量課金の落とし穴

クラウドの料金は基本的に「使った分だけ」の従量課金です。便利な反面、予測しにくく、油断すると膨らみます。

典型的な落とし穴

起動しっぱなしの仮想マシン：1 か月の検証のつもりが、6 か月経っても起動したまま。1 台月数万円が積み上がる
不要なディスクの放置：仮想マシンを削除しても、付属していたディスクは残ることがある。月数千円が継続発生
オブジェクトストレージへのログ垂れ流し：1 日 1 GB のログでも、3 年で 1 TB を超えて保管料金が無視できなくなる
データ転送料金：クラウド内の通信は安いか無料、外部に出る通信は GB あたり数円〜十数円。動画配信や大容量ダウンロードで予想外に膨らむ
マネージド DB の最低料金：「動かさなければ料金が出ない」と誤解しがちだが、確保した時点で時間課金が始まることが多い
オートスケーリングの誤設定：負荷に応じて自動拡張するが、上限を設定し忘れると暴走する

「最初の請求書ショック」

組織がクラウドを使い始めて 3〜6 か月目あたりに、想定の 2〜3 倍の請求書が届くことがあります。業界では「ビルショック（bill shock）」と呼ばれる現象です。原因は、たいてい上のいくつかの落とし穴の組み合わせです。

⚠️ 注意 「クラウドは安い」と社内で説明していた人ほど、ビルショックが起きたときの説明責任を負います。事前に「変動する」「監視と統制が必要」と伝えておくのが現代的な責任の取り方です。

予約インスタンスと Savings Plans

需要が安定している部分には、長期コミットによる割引が用意されています。

予約インスタンス（Reserved Instance：RI）

「1 年または 3 年、この仮想マシンを使い続けます」と事業者にコミットする代わりに、通常料金より大幅な割引（30〜70% 程度）を受けられる仕組みです。

AWS：Reserved Instances（旧来の方式）、Savings Plans（後述の柔軟な方式）
Azure：Reserved VM Instances
Google Cloud：Committed Use Discounts（CUD）

「使わなくても料金は発生する」点に注意が必要です。3 年契約で 2 年後にビジネスがピボットすると、残期間の料金を負担し続けることになります。

Savings Plans（AWS）

AWS では、特定の仮想マシンに縛らず「1 時間あたり◯ドル使い続けます」とコミットすることで割引を得る Savings Plans が広く使われています。仮想マシンの種類変更に強いのが利点です。

コミットメント割引の使い分け

安定的・継続的な土台部分（インフラの 60〜70%）：長期コミットで割引を取る
変動・実験部分（残り 30〜40%）：従量課金のままで柔軟性を確保する

「コミットメントは怖いから取らない」のも、「全部コミット」も、いずれもバランスを欠きます。

📝 補足 Savings Plans やコミットメントの「最適配分」を分析する専門ツール・サービス（AWS Cost Explorer、Azure Cost Management、Google Cloud Recommender、第三者の SaaS ツール）が複数あります。中堅以上の組織では、こうしたツールで配分を継続的に見直すのが普通です。

タグ付けとコスト可視化

クラウドの請求書を見ても「何にいくらかかったか」がわからない、という声をよく聞きます。事業者の請求書は、サービス別・リージョン別の細分化が中心で、業務との対応が直感的ではありません。

タグ（tag）の発想

各リソース（仮想マシン、ストレージ、データベースなど）に「タグ」というメタデータを付ける機能が、3 社すべてに用意されています。

環境：production、staging、development
事業部：sales、engineering、marketing
プロジェクト：projectA、projectB
責任者：tanaka@example.com

タグを付けると、コスト分析ツールで「事業部別の月額」「プロジェクト別の月額」を集計できます。

タグ運用のルール作り

タグの名前と値を統一する（誰でも自由に付けると集計できなくなる）
必須タグを定める（「環境」「事業部」は必須にする、など）
新規リソース作成時にタグ付けを強制する仕組みを使う
定期的に「タグなしリソース」を棚卸しする

タグ運用は退屈な仕事ですが、ガバナンスの中核です。

ショーバック・チャージバック

タグ集計によって部署別のコストが見えるようになると、社内の財務処理と組み合わせる発想が生まれます。

ショーバック（showback）：実際に料金を移動させず、部署別の見える化だけを行う
チャージバック（chargeback）：部署別に実際に料金を付け替える（社内振替）

組織の成熟度に応じて、ショーバックから始めてチャージバックに進むことが多いです。

予算アラートとガードレール

「気づいたら予算超過」を防ぐために、予算アラート（budget alert）を設定します。

予算アラートの設計

月次予算（または四半期予算）をクラウド事業者の管理コンソールに登録する
50%、75%、90%、100% といった節目で、責任者にメール・Slack 通知を飛ばす
一定額を超えた場合に、リソースの新規作成を自動で停止する（事業者によって機能差あり）

ガードレール（guardrail）の発想

「やってよいこと」と「やってはいけないこと」を、ポリシー（policy）として事業者の管理機能で強制する発想を「ガードレール」と呼びます。

大型インスタンス（高額な仮想マシン）の起動を特定権限者のみに制限
特定リージョン以外でのリソース作成を禁止
データ暗号化なしのストレージ作成を禁止
全リソースに必須タグを強制

ガードレールがあれば、開発者の生産性を保ちつつ、予期しない高額利用を防げます。「禁止」より「自然と安全な道に誘導」する発想です。

オートスケーリングの設計判断

オートスケーリング（auto scaling）は、負荷に応じて仮想マシンやコンテナの数を自動で増減する仕組みです。クラウドのコスト最適化の代表的な手段ですが、設計次第で逆効果にもなります。

オートスケーリングが効く条件

負荷が時間帯・日付で変動する
起動時間（数十秒〜数分）に耐えられるアプリ設計
上限と下限が明確に設計されている

落とし穴

上限を設定し忘れ、暴走する：障害時に「異常な負荷」と誤判定して大量起動、月額が数十倍になる
下限が高すぎる：夜間や週末に使われない時間帯も多数のサーバーが動き続ける
スケールアウトが間に合わない：急峻な負荷増加に追従できない
メトリクス（測定指標）の選び方を間違える：CPU 使用率だけで判断するとメモリ不足を見逃す

「自動だから安心」ではなく、上限・下限・メトリクスを継続的にチューニングする運用が必要です。

FinOps Foundation の発想

クラウドコストの運用を体系化したのが、FinOps（Financial Operations の略）という考え方です。

FinOps Foundation

2020 年に Linux Foundation 配下で設立された業界団体です。クラウドコスト管理のフレームワーク、ベストプラクティス、ジョブディスクリプション、認定資格などを整理しています。

FinOps の 3 つのフェーズ

FinOps Foundation は、組織のクラウドコスト運用を 3 つのフェーズで段階的に進める発想を提示しています。

Inform（情報を得る）：タグ付け、可視化、ショーバックで現状を把握する
Optimize（最適化する）：予約インスタンス、コミットメント、不要リソース整理、オートスケーリング設計
Operate（運用する）：月次の振り返り、組織全体の文化、責任の明確化

順番が重要で、可視化なしの最適化は推測になり、最適化なしの運用は形骸化します。

「クラウド時代の経理」が必要

FinOps の発想は、エンジニアと経理（CFO 配下）の橋渡しが要点です。エンジニアが「予算は気にせず使う」だけでも、経理が「予算超過を止める」だけでも、組織は機能しません。両者が共通言語で議論する場が、クラウド時代のコストガバナンスです。

💡 ポイント FinOps は「節約のテクニック集」ではありません。組織全体で「使った分が見える」「ビジネスの判断と整合する」「予算超過の説明責任が果たせる」状態を作る、運用設計の話です。

2026 年 6 月時点：生成 AI 推論コストの不確実性

2024〜2025 年にかけて、業務システムに生成 AI を組み込む案件が急増しました。クラウドのコスト構造にも大きな影響が出ています。

生成 AI 推論コストの特徴

1 回の API 呼び出し（推論）あたりの料金が、入力と出力の文字数（厳密にはトークン数）で決まる
1 件あたり数円〜数十円でも、業務で 1 日数万件の呼び出しがあると、月額が数百万円に達することがある
モデル提供事業者の料金改定が頻繁（半年で半額になることも、引き上げになることもある）
GPU 需給の影響を受け、価格と利用枠の予測が難しい
マネージド推論サービス（AWS Bedrock、Azure OpenAI Service、Google Vertex AI）の選択次第で、コスト構造も大きく変わる

業務システムへの組み込み判断

「とりあえず全社員に生成 AI 機能を開放」はコストが読めない危険な選択になりやすい
ユースケースを絞って、コスト上限を設定し、効果を測る発想が現実的
同じ業務処理を、生成 AI とそれ以外（既存ルール・人間の作業）でコスト比較する
モデルのバージョンアップに伴う料金変動に備えて、月次でレビューする

📝 補足 生成 AI の料金は 2026 年現在も四半期単位で変動し続けています。「半年後の料金は今と同じ」とは仮定せず、運用設計の段階で「料金が 2 倍になっても破綻しない」設計を意識します。

講師の現場メモ：「月額が想定の 4 倍だった救済案件」

私（山下）が独立する直前、勤めていたクラウド事業者で大手金融機関のお客様の救済案件に呼ばれました。クラウド移行から 8 か月、月額の請求が当初試算の 4 倍になり、社内で大問題になっていました。

CTO が私に「いくつ問題があるか整理してほしい」と頼んできました。私と現場の 2 名で 2 週間かけて全リソースを棚卸ししました。

検証で作った仮想マシンが 80 台、全部起動中で月額 400 万円
マネージド DB を 20 個、テスト後に消し忘れて月額 60 万円
データ転送料金が月額 200 万円（CDN 設計のミス）
バックアップを 3 か月のはずが 3 年保管設定で、ストレージが 50 TB
オートスケーリング上限なしで、ある日 1 件の異常で月額 50 万円突発

合計で当初試算の 4 倍。原因は単一ではなく、複合的な「ガバナンスの不在」でした。

私たちは 4 週間かけて、

不要リソースの整理（即時 30% 削減）
タグ付けとショーバックの導入（部署別の見える化）
予算アラートと上限ガードレールの設定
月次の FinOps レビュー会議の発足（CTO・CFO・事業責任者が同席）

を実施しました。3 か月後、月額は当初試算の 1.1 倍まで戻り、CFO が「これでようやくクラウドが見える化できた」と納得してくれました。

このときに痛感したのは、「クラウドは安い」と説明した側にも責任がある、ということです。コストの不確実性は最初から伝えるべきで、ガバナンス設計をセットで提案しなければ、必ずビルショックが起きます。本コースで FinOps を 1 レッスン丸ごと割いているのは、この苦い経験があるからです。

まとめ

このレッスンでは、以下のことを学びました。

「クラウドは安い」は条件付きの命題。安くなる条件と高くなる条件の両方がある
従量課金の落とし穴：起動しっぱなし、ディスク放置、ログ垂れ流し、転送料金、最低料金、オートスケーリング暴走など
安定部分には予約インスタンス・Savings Plans・コミットメントで割引（30〜70%）を取る
タグ付けで「事業部別・プロジェクト別」のコスト可視化を進める
ショーバック（見える化のみ）→チャージバック（実際の付け替え）と段階的に進める
予算アラートとガードレール（事業者の管理機能でポリシー強制）でビルショックを防ぐ
オートスケーリングは上限・下限・メトリクスを継続的にチューニングする運用が必要
FinOps Foundation の 3 フェーズ（Inform → Optimize → Operate）でクラウドコスト運用を体系化
2026 年 6 月時点：生成 AI 推論コストは入出力トークン数で決まり、料金変動の不確実性が大きい

次のレッスンでは、クラウドのセキュリティを扱います。責任共有モデル、IAM、KMS、ログと監査といった発想を整理します。

確認クイズ

このレッスンの理解度をチェックしましょう。