Contents
Azureコスト削減の基本構造と主要要因
Azureの課金はサービスごとのメーターと利用量で決まります。固定的な割引（予約／Savings Plans／ライセンス）と変動的な使用料に分かれます。ここでは主要なコスト要因を短く整理します。
主要コスト要因の概観
主要な費用項目ごとに、何が課金を左右するかを示します。
- Compute（仮想マシン、VMSS、App Service、Functions）
- VMはインスタンスサイズと稼働時間で課金されます。VMSSはVirtual Machine Scale Setsの略です。
-
Functionsは実行回数とメモリ×時間（GB-秒）で課金されます。
-
Storage（Managed Disk、Blob）
-
容量（月額GB）とIO/トランザクションで課金されます。BlobはHot/Cool/Archiveの階層で単価が変わります。
-
Network（egress、VPN、ExpressRoute）
-
リージョン間やインターネットのegressが変動要因です。CDNや負荷分散の利用もコストに影響します。
-
Database（Azure SQL、Managed Instance、Cosmos DB）
-
Azure SQLはvCore/DTU、Cosmos DBはRU/s（Request Units per second）で課金されます。スケール設定でコストが大きく変わります。
-
Monitoring（Log Analytics）
-
取り込み（ingest）GBと保持期間が直接コストになります。診断ログの送信先設定も重要です。
-
ライセンス（Azure Hybrid Benefitなど）
- Azure Hybrid Benefit（AHB）は既存のオンプレライセンスを活用する割引です。適用条件を必ず確認してください。
上記を踏まえて、固定費（予約等）と変動費（使用量）を分けて分析します。
現状把握とKPI設計（実務ステップ）
短期施策の前に、まずは「何にいくら使っているか」を短時間で可視化します。スコープを定義し、責任者とKPIを決めて継続的に監視できる形にします。
KPI例とAzure Cost Managementの活用
直近30/90/365日のスコープを決め、Cost Analysisで上位要因を抽出します。以下は実務での優先手順です。
- 集計スコープと期間を決める（例：直近30／90／365日）
- Azure Portal → Cost Management + Billing → Cost analysis で Group by して上位コストを特定する
- タグ戦略で配賦可能にする（CostCenter、Owner、Environment、Workload、Project）
- データ出力と自動化：Cost ManagementのExportsで定期出力し、Power BI等で可視化する
タグ未設定リソースの抽出はResource Graphが便利です。以下はコピーして使えるクエリ例です。
|
1 2 3 4 |
Resources | where isempty(tags['CostCenter']) | project subscriptionId, resourceGroup, name, type, tags |
Cost Managementはデータ遅延があるため、複数期間で傾向を確認してください。各KPIにはオーナーを割り当て、週次または月次でアクションに落とします。
短期（30日以内）で実行する即効施策とチェックリスト
リスクが低く効果が出やすい施策を優先します。各施策には事前チェックとロールバック手順を必ず付けてください。
不要／アイドルVMの検出と停止（deallocate）
まずは候補を抽出し、オーナー承認を得たうえで停止（割当解除＝deallocate）します。停止すると計算リソースは課金されませんが、ディスクとパブリックIPは残り課金されます。
- 判定の方針（例）
- 過去30日間の平均CPUが5%未満、かつネットワークI/Oが低いVMを候補とする
-
本番可用性・バックアップ・DR要件は除外する
-
実行前チェック（必須）
- バックアップ/スナップショットがあるか確認する
- オーナーの承認を文書で取得する（後述の承認テンプレート参照）
-
ステージング環境で停止→起動の検証を行う
-
操作（例: Azure CLI / PowerShell）
-
CLI: deallocate（可搬性が高い）
bash
az vm deallocate --resource-group <RG> --name <VM_NAME> -
PowerShell: 停止（deallocate）
powershell
Stop-AzVM -ResourceGroupName <RG> -Name <VM_NAME> -Force -
起動（ロールバック）:
bash
az vm start --resource-group <RG> --name <VM_NAME> -
メトリクス取得のサンプル（PowerShellで過去30日の平均CPUを算出）
powershell
$end = Get-Date
$start = $end.AddDays(-30)
Get-AzVM | ForEach-Object {
$vm = $_
$m = Get-AzMetric -ResourceId $vm.Id -MetricName "Percentage CPU" -StartTime $start -EndTime $end -Interval "PT1H" -Aggregation "Average"
$avg = ($m.Data | Where-Object { $_.Average -ne $null } | Measure-Object -Property Average -Average).Average
if ($avg -ne $null -and $avg -lt 5) {
[PSCustomObject]@{ResourceGroup=$vm.ResourceGroupName;VM=$vm.Name;AvgCPU=[math]::Round($avg,2)}
}
} -
推奨権限（RBAC）
- 最小限: Virtual Machine Contributor（VMの停止/起動が可能）
- 追加: ContributorまたはOwnerは全般的な操作が可能だが最小権限を推奨
予算（Budgets）設定とアラート運用
予算と通知をまずは観測運用で開始し、段階的に自動化を検討します。自動停止は破壊的リスクがあるため最初は「通知のみ」を推奨します。
- 導入手順の例
- Cost Management → Budgets でスコープ（Subscription/Resource Group）を設定
- 閾値（50%/75%/90%など）を設定し、通知先にAction Groupを指定
-
Action Groupは最初はメール/Webhookで運用、必要に応じ自動化を追加する
-
CLIでのAction Group作成（例）
bash
az monitor action-group create \
--resource-group <RG> \
--name <AG_NAME> \
--short-name <SHORT> \
--action webhook StopWebhook <WEBHOOK_URL>
※Webhookや自動停止を使う際は検証を必須にしてください。 -
必要な権限
- Cost Management Contributor（予算作成）
- Monitoring Contributor（Action Group作成）
Azure Hybrid Benefit（AHB）の適用確認
所有中のオンプレライセンスをAzureで活用できるか確認します。対象はWindows ServerやSQL Serverのライセンスです。
- 手順（概略）
- 所有ライセンスのリストアップと要件確認
-
該当VMに対しライセンスタイプを指定して適用（リスク評価を実施）
-
既存VMへの設定例（CLI）
bash
az vm update --resource-group <RG> --name <VM_NAME> --set licenseType=Windows_Server
※適用条件を満たしているか必ず確認してください。
その他の短期施策
簡単に実行できる追加施策を並べます。各操作にはバックアップと承認を必須としてください。
- 未使用のPublic IP、未接続ディスク、古いスナップショットの洗い出しと削除
- Log Analyticsの保持期間短縮と重要データのアーカイブ
- BlobのHot→Cool移行ルールの設定（ライフサイクル管理）
- Azure Advisorの「低リスクのコスト推奨」の優先実行
未接続ディスクや未使用Public IPの抽出（Resource Graph）
|
1 2 3 4 5 6 7 8 9 10 11 12 |
// 未接続マネージドディスク Resources | where type =~ 'microsoft.compute/disks' | where isnull(properties.managedBy) or properties.managedBy == '' | project subscriptionId, resourceGroup, name, properties.diskSizeGb // 未割当のPublic IP Resources | where type =~ 'microsoft.network/publicipaddresses' | where isnull(properties.ipConfiguration) | project subscriptionId, resourceGroup, name, properties.ipAddress |
中長期（3〜12か月）で進める施策とガバナンス
短期施策で負債を減らしたら、再発防止と継続最適化の仕組みを整えます。サブスクリプション設計、ポリシー、予約・割引戦略、アーキテクチャ見直しが中心です。
サブスクリプション設計・タグ・Azure Policy
管理をスケールさせるために、管理グループや命名規則を定め、Azure Policyで自動的にチェック・補正します。段階的にAudit→Append→Denyを適用します。
- 推奨設計例
- 管理グループ → サブスクリプション（prod/nonprod/shared） → リソースグループ（ライフサイクル単位）
- タグ運用
- 必須タグ: CostCenter、Owner、Environment、Workload、Project
- Azure Policyで欠如リソースを検出し、段階的に強制適用する
予約・Savings Plans・割引戦略
予約（Reservations）とSavings Plansは長期的に大きな削減効果がありますが、コミットに伴うリスクがあります。過去12か月の利用実績を分析して段階導入を行います。
- 選定の流れ
- 利用実績の分析 → 候補リソース抽出 → シミュレーション（Cost Managementの推奨）→ スコープ・期間決定→ 承認
- 重要点
- Reservationsはリソース種別・リージョン依存がある
- Savings Plansはより柔軟だが計画が必要
- 交換・払い戻しルールを事前に確認する
アーキテクチャ改善（PaaS／Serverless／コンテナ等）
長期的にはPaaSやServerlessへの移行で運用コストと稼働率を改善できます。移行工数とTCOを比較して意思決定してください。
- 例
- Web系：App Service／Functionsで運用負荷とスケール効率を改善
- バッチ：Spot VMやコンテナでコストを最適化（中断対策必須）
- DB：Elastic PoolやServerless（断続負荷向け）を検討
ガバナンスは「ポリシー適用 → 四半期レビュー → 予約の見直し → KPI監視」のサイクルで回します。
実行テンプレートと自動化スクリプト集（Resource Graph / CLI / Runbook）
ここでは実務でコピペして使えるテンプレートを示します。実行前に必ずステージング検証とオーナー承認を行ってください。
承認テンプレート（例）とRBACの目安
以下は承認用の最低限テンプレート例です。運用に合わせて項目を追加してください。
| 項目 | 内容（記入例） |
|---|---|
| 申請者 | 担当者名／部署 |
| リソースID | /subscriptions/…/resourceGroups/…/providers/…/… |
| 現状コスト | 月額 〇〇円 |
| 提案アクション | VM停止（deallocate） / ディスク削除 / ライフサイクル適用 など |
| 影響範囲 | サービス名、稼働時間帯、依存関係 |
| バックアップ確認 | スナップショット/バックアップの有無 |
| ステージング検証 | 実施日／結果 |
| ロールバック手順 | 起動手順、復旧担当 |
| 承認（オーナー） | 名前、承認日時 |
RBACの目安：
| 操作 | 推奨ビルトインロール |
|---|---|
| VMの停止/起動 | Virtual Machine Contributor |
| ディスク削除 | Managed Disk Contributor または Contributor |
| タグ変更 | Contributor（またはカスタムロールで Microsoft.Resources/tags/*） |
| 予算作成 | Cost Management Contributor |
| Action Group作成 | Monitoring Contributor |
| Automation Runbook 実行（Managed Identity） | Runbookに必要な対象リソースへ限定的にContributor権限を付与 |
必要に応じて、最小権限のみ付与するカスタムロールを作成してください。
タグのバックフィル（PowerShellの例）
既存タグを保持しつつCostCenterを追加する例です。スクリプトは小規模で検証してから実環境へ適用してください。
|
1 2 3 4 5 6 7 |
$rg = "<ResourceGroup>" $resource = Get-AzResource -ResourceGroupName $rg -Name "<ResourceName>" $tags = @{} if ($resource.Tags) { $tags = $resource.Tags } $tags['CostCenter'] = 'CC123' Set-AzResource -ResourceId $resource.ResourceId -Tag $tags -Force |
大規模なバックフィルはステージングで動作確認をしてから、ロールアウト用Runbookを作成してください。
Automation Runbook（アイドルVMを自動停止する例）
以下はManaged Identityで実行するPowerShell Runbookの簡易例です。稼働前に必ずステージングで検証してください。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
param( [int]$IdleDays = 7, [string]$TagName = "AutoStop" ) Connect-AzAccount -Identity $end = Get-Date $start = $end.AddDays(-$IdleDays) $vms = Get-AzVM -Status | Where-Object { $_.Tags.ContainsKey($TagName) -and $_.Tags[$TagName] -eq "true" } foreach ($vm in $vms) { $metrics = Get-AzMetric -ResourceId $vm.Id -MetricName "Percentage CPU" -StartTime $start -EndTime $end -Interval "PT1H" -Aggregation "Average" $avg = ($metrics.Data | Where-Object { $_.Average -ne $null } | Measure-Object -Property Average -Average).Average if ($avg -ne $null -and $avg -lt 5) { # 事前承認フラグ確認やスケジュール制御を追加すること Stop-AzVM -ResourceGroupName $vm.ResourceGroupName -Name $vm.Name -Force } } |
RunbookのManaged Identityには、実行対象のVMに対するVirtual Machine Contributor権限を最小スコープで与えてください。
BudgetsとAction Groupの自動化サンプル（注意あり）
Action Group作成（Webhook例）
|
1 2 3 4 5 6 |
az monitor action-group create \ --resource-group <RG> \ --name <AG_NAME> \ --short-name <SHORT> \ --action webhook StopWebhook <WEBHOOK_URL> |
Budgetと通知の紐付けはPortalでの検証を推奨します。自動停止などの破壊的アクションはまずステージングで確実にテストしてください。
コスト試算・事例とよくある落とし穴（FAQ）
施策ごとの投資対効果は、前提を明確にした上で算出してください。ここでは簡易ROIの計算方法と事例の目安を示します。
簡易ROI算出手順と注意点
必要データと計算式は以下の通りです。数字は必ず自社データで再計算してください。
- 必要データ：現状月額コスト、最適化後月額、導入費用（工数×単価）、評価期間
- 月間削減額 = 現状月額 − 最適化後月額
- 回収期間（月） = 導入費用 ÷ 月間削減額
- 年間ROI = (月間削減額×12 − 導入費用) ÷ 導入費用
数値例は参考であり、前提次第で大きく変わります。期待削減率はケースにより幅が出るため、保守的な前提で算出してください。
事例（前提明示と保守的目安）
- 事例A：中小ECサイト（非稼働時間が長い）
- 対応：開発環境の自動停止、WebをPaaSへ一部移行、DBをElastic Poolへ変更
- 保守的な期待効果（前提に依存）：概ね5〜25%のコスト低減の可能性
-
前提：移行工数や動作テストを含めた総コストを計上すること
-
事例B：ログ蓄積型サービス（参照頻度が低い古いログ多数）
- 対応：古いログのArchive移行、Log Analyticsの保持最適化、Cosmos DBのTTL設定
- 保守的な期待効果：10〜30%程度（データ量と取り出しパターン次第）
注意：上記は事例ベースの目安です。移行コストや業務影響を必ず含めて評価してください。
よくある落とし穴と対策（短文）
- 予約を変動ワークロードにそのまま適用するリスク
- 対策：段階的購入と定期的な見直し
- Spot VMを重要処理に使って中断被害が発生
- 対策：中断許容のみ適用、チェックポイントとフォールバック実装
- ログやバックアップの過剰保持による肥大化
- 対策：保持ポリシーとアーカイブ戦略を定義、定期削除を自動化
- タグ未整備で配賦できない
- 対策：タグ戦略を優先し、Azure Policyでバックフィルを段階導入
- 権限の過剰付与
- 対策：RBAC最小権限、承認フローの徹底
参考（公式ドキュメント、確認日付き）
- Azure 価格ページ（確認日: 2026-05-17）: https://azure.microsoft.com/pricing/
- Azure Cost Management ドキュメント（確認日: 2026-05-17）: https://learn.microsoft.com/azure/cost-management/
- Reservations（確認日: 2026-05-17）: https://learn.microsoft.com/azure/cost-management-billing/reservations/
- Savings Plans（確認日: 2026-05-17）: https://learn.microsoft.com/azure/savings-plans-for-compute/
- Azure Hybrid Benefit（確認日: 2026-05-17）: https://learn.microsoft.com/azure/virtual-machines/windows/hybrid-use-benefit
- Azure Resource Graph（確認日: 2026-05-17）: https://learn.microsoft.com/azure/governance/resource-graph/
- Azure Monitor メトリクス（確認日: 2026-05-17）: https://learn.microsoft.com/azure/azure-monitor/essentials/metrics
まとめ（要点、箇条書きで約200〜300文字）
- まずTop10コストを可視化し、タグ整備で配賦できる状態にすることが最優先です。
- 30日以内は「不要VMのdeallocate」「Budgetsで通知運用」「AHB適用確認」を実行し、事前チェックとオーナー承認を必須にしてください。
- 中長期はサブスクリプション設計、Azure Policy、予約／Savings Plansの段階的導入で再発防止を図ります。
- すべての破壊的操作にはステージング検証とロールバック手順を用意し、RBACで最小権限を適用してください。