Azure Cost Managementでコストを「見える化」できるようになると、次に必ずぶつかるのが「で、どうやって安くするの？」という壁です。何にいくら使っているかが分かっただけでは、請求額は1円も減りません。そこから先、実際にコストを削って、しかもそれを組織として回し続ける——ここからが本当の腕の見せどころです。
私自身、会社を経営しながらAzureを触っている身なので、コストの話は他人事ではありません。毎月の請求書を見て「この従量課金、まとめ買いすれば半額近くになるのに放置してた」と反省したことも一度や二度ではないです。この記事では、そういう実務での節約の勘所を、公式のMicrosoft Learnを日本語で通訳しながら解説していきます。
「コストを見える化まではやった。でも、予約とかSavings Planって結局どっちを買えばいいの？組織全体でコストを管理するって何から始めるの？」
家計にたとえるなら、親記事の「Cost Managementとは」で扱った可視化・予算アラートが「家計簿をつける」段階だとすれば、この記事は「節約術と資産運用」にあたります。まとめ買いで単価を下げ、無駄な出費に気づき、家族全員でお金の使い方を共有する——そういう一段上の話です。読み終わるころには、クラウドコストを組織で継続的に最適化していくための地図が頭に入っているはずです。
なお、そもそもCost Managementで「何にいくら使ったか」を見る・予算を張る、といった基本がまだあやふやな方は、先に Azure Cost Managementとは？コスト分析・予算・予約・FinOpsで無駄をなくす実務ガイド（親記事）に目を通しておくと、この記事の位置づけがはっきりします。本記事はその「最適化」パートを深掘りする子記事です。
予約とSavings Planでコンピューティングの単価を下げる
まず節約の本命から入ります。Azureのコストで大きな割合を占めるのが、仮想マシン（VM）などのコンピューティングリソースです。そしてここは、買い方を変えるだけで最大で6〜7割ほど単価が下がる、いちばん効くレバーでもあります。
買い方には大きく3つあります。従量課金（Pay-As-You-Go）、予約（Reserved Instances、RI）、Savings Plan（節約プラン）です。この3つの違いを、携帯電話の料金プランにたとえて整理すると腹落ちしやすいと思います。
従量課金・予約・Savings Planの違い
従量課金は、使った分だけ後払いする「縛りなしプラン」です。いつ止めても自由な代わりに、単価はいちばん高い。試しに使ってみる段階や、いつ止めるか読めない一時的なリソースにはこれが向きます。
予約（RI）は、「この構成のVMを1年（または3年）ずっと使い続けます」と先に宣言する代わりに大きく割引してもらう、いわばまとめ買いです。スーパーで同じ商品を箱買いすると1個あたりが安くなるのと同じ発想ですね。1年より3年、支払いも月払いより一括前払いのほうが割引率は高くなります。その代わり、「どのサイズのVMを何台」といった対象をある程度固定することになります。
Savings Planは、対象を固定する代わりに「1時間あたり◯ドル分は必ず使います」と金額でコミットする、より柔軟な割引プランです。「毎月これくらいはコンピューティングに使うのは確実だけど、VMのサイズやリージョンは今後変わるかもしれない」というときに効きます。金額の約束さえ守れば、その枠内でVMの種類を変えても割引が効き続けるのが強みです。定額の「使い放題プラン」に近いイメージですね。
ざっくり整理すると、こういう性格の違いになります。
| 買い方 | 割引 | 縛り（コミット対象） | 向いている場面 |
|---|---|---|---|
| 従量課金 | なし（標準料金） | なし | 一時利用・止める時期が読めない |
| 予約（RI） | 大きい | 特定の構成を1〜3年 | 構成が固まった長期稼働のVM |
| Savings Plan | 大きい | 時間あたりの金額を1〜3年 | 金額は読めるが構成は変わりうる |
公式ドキュメントの 予約でコンピューティングコストを削減する でも、この予約とSavings Planの2本立てが節約の中心として説明されています。ざっくりした選び分けの目安は、「構成が完全に固まっていてしばらく変えないなら予約、金額は読めるけど構成を柔軟に変えたいならSavings Plan」と覚えておけば大きく外しません。
いきなり買わない。まず「推奨」を見る
ここが実務でいちばん大事なところなのですが、予約もSavings Planも、勘で買ってはいけません。買ったはいいものの実際には使い切れず、割引どころか「使わない枠にお金を払う」状態になっては本末転倒です。私も最初、なんとなく「安くなるらしいから」と手を出しそうになって、踏みとどまった経験があります。
Azureには、過去の実際の使用状況を分析して「この予約を買えば、あなたの環境ではこれくらい節約できます」と提案してくれる推奨（Recommendation）機能があります。予約やSavings Planの購入画面には、この推奨がもとから表示されます。手順としては、こう進めるのが安全です。
- まず数週間〜1か月ほど、対象のリソースを従量課金で普通に動かして「実績」を作る。
- 予約／Savings Planの購入画面で、Azureが出す推奨を確認する。「どのサイズを・いくつ・どの期間」買うと得か、節約見込み額まで提示される。
- 推奨のうち、今後も確実に使い続けると言い切れる分だけを購入する。
ポイントは、推奨を鵜呑みにせず「本当にこの先も使うか」を人間が判断してから買うことです。推奨はあくまで過去データからの提案なので、「来月このプロジェクトは終わる」といった未来の事情は織り込めません。そこを補うのが、コストに関心の高い担当者の役目です。
「安くなるから」で飛びつかず、「推奨を見る→この先も使うか判断→使う分だけ買う」。この順番を守るだけで、予約で損をする事故はほぼ防げます。
なお、予約は買ったあとも塩漬けにする必要はありません。使わなくなった予約は交換（別の予約に組み替え）や、一定条件での払い戻しにある程度対応しています。とはいえ制限もあるので、「あとで直せるから適当に」ではなく、最初から使う分だけを推奨ベースで買うのが結局いちばんラクです。
コスト異常検出と推奨で「想定外の急増」に気づく
単価を下げる話の次は、「気づかないうちに膨らむ出費」への対策です。クラウドの怖いところは、設定ミスや消し忘れが、静かに毎日課金され続ける点にあります。テスト用に立てた大きなVMを消し忘れた、ログ出力を絞り忘れてストレージがどんどん膨らんでいた——この手の「じわじわ課金」は、月末の請求書を見て初めて気づくことが少なくありません。
これに対してAzureが用意しているのがコスト異常検出（Anomaly detection）です。これは、日々のコストの動きを学習して、「普段の傾向から見て、明らかにおかしな増え方をした」タイミングを検知して知らせてくれる機能です。家計でいえば、いつもの月と比べて急に光熱費が跳ね上がったら教えてくれる見張り役ですね。
公式の 想定外の請求を分析する では、急増に気づいたときの「犯人探し」の進め方が示されています。実務での動き方をかみ砕くと、こんな流れです。
- 異常や急増に気づいたら、まずコスト分析を開く。
- グラフを「サービス別」「リソースグループ別」などで分解して、どこが跳ねているかを絞り込む。
- 怪しいリソースにあたりがついたら、その設定・稼働状況を確認して原因（消し忘れ・スケールしすぎ・想定外のデータ転送など）を特定する。
「全体の合計だけ見て慌てる」のではなく、切り口を変えて分解し、跳ねている一点まで下りていくのがコツです。ここで、前半でも触れた推奨がもう一つの武器になります。Azure Advisorが出すコスト系の推奨——たとえば「このVMは使用率が低いのでサイズを下げては？」「このリソースは長期間アイドルなので削除・停止しては？」といった提案は、想定外の出費を生む原因そのものをつぶしてくれます。
異常検出が「起きてしまった急増を捕まえる守り」なら、Advisorのコスト推奨は「無駄を生む前に手を打つ攻め」です。この2つをセットで回すことで、「気づいたら請求が倍になっていた」という事故をかなり減らせます。Advisorの使い方そのものは奥が深いので、末尾の関連記事で別途詳しく扱っています。
スコープ別の配賦設計：組織の階層でコストを整理する
ここまでは「どう安くするか」でしたが、組織で運用するとなると、もう一つ避けて通れないテーマがあります。「このコスト、誰の・どのプロジェクトの費用なの？」を分けて集計する——いわゆる配賦（はいふ）です。会社全体で1枚の請求書が届いても、それを部門やプロジェクトごとに切り分けられないと、「どこにコストがかかりすぎているか」を誰も責任を持って追えません。
Azureで配賦を考えるとき、土台になるのがスコープ（Scope）という考え方です。公式の スコープの使い方を理解する でも、コスト管理はこのスコープ単位で行うと説明されています。スコープとは、ざっくり言えば「どの範囲のコストを見るか」を指す階層のレベルのことです。
管理グループ・サブスクリプション・リソースグループの階層
Azureのコストは、上から順にこう入れ子になっています。組織図にたとえると分かりやすいです。
- 管理グループ（Management Group）＝会社・事業部レベル。複数のサブスクリプションをまとめて束ねる、いちばん大きな箱。
- サブスクリプション（Subscription）＝部門・プロジェクトレベル。課金の基本単位で、請求はここに紐づく。
- リソースグループ（Resource Group）＝チーム・システム単位。ひとまとまりのリソースを入れておく箱。
コスト分析は、このどの階層でも開けるのがポイントです。管理グループのスコープで開けば会社全体の合計が見え、サブスクリプションのスコープで開けばその部門だけの内訳が見え、リソースグループなら特定システムのコストだけを追える。上から下へ、見たい粒度でズームイン・ズームアウトできるイメージです。
だからこそ、コストをきれいに配賦したいなら「どういう階層でリソースを配置するか」を最初に設計しておくことが効いてきます。たとえば「部門ごとにサブスクリプションを分ける」「プロジェクトごとにリソースグループを分ける」といった線引きをしておけば、あとはスコープを切り替えるだけで部門別・プロジェクト別のコストが自然に出せます。逆に、全部を1つのリソースグループに突っ込んでしまうと、あとから「これは誰の費用？」を分けるのに苦労します。
さらに細かい配賦、たとえば「同じリソースグループの中でも案件Aと案件Bを分けたい」というレベルになると、親記事でも触れたタグ（リソースに付ける「案件名」などのラベル）と組み合わせます。スコープで大きく区切り、タグで細かく分ける——この二段構えが、組織のコスト配賦の基本形です。
エクスポートとPower BI連携でレポートを自動化する
スコープで配賦できるようになると、次に欲しくなるのが「毎月、決まった形のコストレポートを関係者に配りたい」という要望です。ポータルのコスト分析画面は自分で見る分には便利ですが、毎月スクショを撮って資料に貼る、というのは続きません。ここで登場するのがエクスポートとPower BI連携です。
まずは定期エクスポートで「データを外に出す」
エクスポートは、コストデータをAzure Storage（ストレージアカウント）へ定期的に自動で書き出す機能です。公式の コストデータをエクスポートする にチュートリアルがありますが、やることはシンプルで、コスト管理の「エクスポート」から次を指定するだけです。
- 何を：日次・月次などの実際のコスト（利用明細）。
- どこへ：出力先のストレージアカウントとコンテナー。
- いつ：毎日・毎月といったスケジュール。
これを設定しておくと、指定したストレージにCSV形式のコストデータが自動でたまっていきます。手作業でダウンロードする必要はありません。まずはこの「データが定期的に外に出てくる状態」を作ることが、レポート自動化の第一歩です。
Power BIで「見せられるレポート」に仕上げる
ストレージにたまったCSVを、そのまま経営会議に出すわけにはいきません。ここでPower BI（Microsoftのデータ可視化ツール）を使います。Power BIから、エクスポート先のストレージ上のコストデータを読み込めば、部門別・月別の推移グラフや、予算に対する消化率のダッシュボードを自分好みに組み立てられます。
ポータルの標準画面ではやりにくい「複数サブスクリプションを横断した集計」「独自の見た目でのレポート」も、Power BIなら自由自在です。しかも一度データソースとレポートを作ってしまえば、エクスポートで毎日データが更新される→Power BIを開けば最新のレポートが出ている、という自動更新の仕組みが手に入ります。毎月の報告作業がボタン一つになるわけです。
まとめると、「エクスポートでデータを定期的に外に出す」→「Power BIで見せられる形に整える」の2ステップ。これで、コストレポートを人手をかけずに継続的に配れる体制ができあがります。ここまで来ると、コスト管理は「個人がたまに見るもの」から「組織の仕組み」へと変わっていきます。
FinOps：コストを組織の文化にする
最後に、ここまでの機能をすべて束ねる考え方を紹介します。FinOpsです。名前だけ聞くと大げさに感じますが、要はクラウドコストを、エンジニア・財務・経営が一緒になって、継続的に見える化・最適化していくための「文化と仕組み」のことです。ツールの名前ではなく、組織の運用スタイルの話だと捉えてください。
従来、クラウドの費用は「気づいたら財務が請求書を見て青ざめる」ものになりがちでした。使うのはエンジニア、払うのは会社、でも誰も日々の金額に責任を持っていない——この断絶をなくし、「コストはみんなの責任」にしていこう、というのがFinOpsの根っこにある思想です。私のように経営とエンジニアリングを両方見ている立場だと、この「使う人がコスト意識を持つ」ことの効き目は本当に大きいと感じます。
Inform・Optimize・Operateの3サイクル
公式の FinOpsの概要 では、FinOpsを3つのフェーズを回し続けるサイクルとして説明しています。そして面白いのは、この3つが、まさにこの記事と親記事で扱ってきた機能そのものに対応していることです。
- Inform（見える化）：何にいくら使っているかを把握する。＝親記事のコスト分析・スコープ配賦・タグ・Power BIレポートがここ。
- Optimize（最適化）：把握したうえで無駄を削り、単価を下げる。＝この記事の予約・Savings Plan・異常検出・Advisor推奨がここ。
- Operate（運用）：一度きりで終わらせず、予算・アラート・レポートを回して継続する。＝予算アラートや定期エクスポートで仕組み化した部分がここ。
つまり、これまで学んできた個々の機能はバラバラの道具ではなく、「見える化する→最適化する→運用として回す→また見える化する」という一つの輪の中の部品だった、というわけです。FinOpsという言葉は、その輪全体に名前を付けたものだと思えば、身構える必要はありません。
大きな仕組みをいきなり作らなくて大丈夫。「見える化→最適化→運用」の輪を、小さくても回し始めることがFinOpsの第一歩です。
まとめ
この記事では、Cost Managementで「見える化」した先のコスト最適化を、実務でつまずく順に見てきました。要点を振り返ります。
- 予約とSavings Plan：単価を下げる本命。予約＝構成を固定してまとめ買い、Savings Plan＝金額でコミットする柔軟版、従量課金＝縛りなしで割高。推奨を見て、この先も使う分だけ買うのが鉄則。
- コスト異常検出とAdvisor推奨：想定外の急増は分解して犯人を特定。推奨で無駄を生む前に手を打つ。守りと攻めのセット。
- スコープ別の配賦：管理グループ→サブスク→リソースグループの階層で見たい粒度に切り替え。スコープで大きく区切り、タグで細かく分ける。
- エクスポートとPower BI：データを定期的に外へ出し、見せられるレポートに整える。報告作業を自動化。
- FinOps：Inform（見える化）→Optimize（最適化）→Operate（運用）の輪。学んできた全機能がこの3サイクルに対応する。
ここまで押さえれば、単に「コストを見る」だけでなく、実際に安くして、組織として継続的に最適化を回していくための地図はそろいました。あとは自分の環境で、小さくてもこの輪を回し始めるだけです。クラウドコストは、放っておけば膨らむ一方ですが、仕組みで向き合えば確実にコントロールできます。
あわせて読みたい：
