Azure Policy入門｜リソースガバナンスとコンプライアンス自動チェックの設計と運用ガイド

「Azure環境が増えるにつれて、禁止リージョンへのリソース作成や必須タグの付け忘れをどう防ぐか」——オンプレ時代はExcelや社内Wiki、承認フローで縛っていた構成基準が、クラウドでは権限さえあれば誰でもGUIから一瞬でリソースを作れてしまうため、野放しになりがちです。

Azure Policyは、その問題を根本から解決するサービスです。「日本以外のリージョンにリソースを作らせない」「特定のVMサイズだけを許可する」「タグがなければデプロイを拒否する」といったルールをコードで定義し、Azure全体に一括適用できます。

この記事では、Azure Policyの基本構造から、ポリシー定義・イニシアチブ・スコープの関係、Azureポータルを使った設定手順、コンプライアンス評価の読み方まで、オンプレ経験のあるインフラエンジニアに向けてわかりやすく解説します。

なぜAzure Policyが必要なのか？（オンプレとの違い）

オンプレ環境では、新しいサーバーを立てるには調達申請・ネットワーク設計・ラッキング・OS設定と、自然に複数の人が関わる「ゲート」がありました。誰かが勝手にルールを破ることは物理的に難しかったわけです。

クラウドは違います。権限さえあれば、エンジニア一人が10分で東南アジアリージョンにVMを100台立てられます。これは生産性の革命である反面、ガバナンス不在だと「気づいたら禁止タグのないリソースが数百個ある」「コンプライアンス違反のストレージ設定が散在している」という状況を招きます。

Azure Policyは、このクラウド特有のガバナンスギャップを埋めるために設計されています。

Azure Policyの基本構造を理解する

Azure Policyを使いこなすには、3つの概念を整理するのが先決です。

・ポリシー定義（Policy Definition）: 「何を評価し、どう処置するか」を記述したJSON定義。Azureが提供するビルトイン定義が数百種類あり、要件に合わせてカスタム定義も作成できます。
・イニシアチブ（Initiative / Policy Set Definition）: 複数のポリシー定義をまとめたグループ。例えば「CIS Microsoft Azure Foundations Benchmark」はセキュリティ関連ポリシーを100本以上まとめたイニシアチブです。
・スコープ（Scope）: ポリシーを適用する範囲。管理グループ・サブスクリプション・リソースグループの3階層から選べます。広いスコープに割り当てるほど、配下のリソース全体に効きます。

【重要】エフェクト（Effect）の種類と選び方

ポリシー定義の核心は「エフェクト」です。条件を満たさないリソースに対して何をするかを指定します。

・Deny: リソースのデプロイ・変更を拒否します。最も強力で、禁止リージョンや許可外VMサイズの封鎖に使います。
・Audit: 違反を検知してコンプライアンスダッシュボードにフラグを立てますが、デプロイは通します。まず「現状把握」したいときに向いています。
・Append: リソースに追加のフィールドを付加します。タグの強制付与に使われます。
・DeployIfNotExists: リソースが条件を満たさない場合、自動的に関連リソースをデプロイして修復します。「診断設定のないストレージアカウントには自動でLog Analyticsへの転送設定を追加する」といった用途です。
・Modify: リソースのプロパティを変更・追加・削除します。既存リソースのタグを自動修正する際に向いています。

Azure Policyを設定する基本手順

1. ビルトインポリシーをサブスクリプションに割り当てる

まずはAzureポータルから操作します。「Policy」サービスを開き、「定義」から目的のビルトインポリシーを検索します。例として「許可されている場所（Allowed locations）」を割り当ててみます。

Azureポータル操作手順:
・手順1: 「Policy」→「割り当て」→「ポリシーの割り当て」をクリック
・手順2: スコープをサブスクリプションまたはリソースグループに設定
・手順3: ポリシー定義で「許可されている場所」を検索して選択
・手順4: パラメーターで「japaneast」「japanwest」を選択
・手順5: 「確認と作成」で割り当て完了

Azure CLIでも同様の操作が可能です。

# Azure CLI — ビルトインポリシー定義のIDを確認する
az policy definition list \
  --query "[?policyType=='BuiltIn'] | [?contains(displayName, '許可されている場所')]" \
  --output table

# ポリシーをサブスクリプションに割り当てる（Japan East と Japan West のみ許可）
az policy assignment create \
  --name "allow-japan-only" \
  --display-name "日本リージョンのみ許可" \
  --policy "e56962a6-4747-49cd-b67b-bf8b01975c4f" \
  --scope "/subscriptions/<サブスクリプションID>" \
  --params '{"listOfAllowedLocations": {"value": ["japaneast", "japanwest"]}}'

2. カスタムポリシー定義を作成する

ビルトインにない要件には、JSON形式でカスタムポリシーを作ります。例として「Environmentタグがないバーチャルマシンのデプロイを拒否する」ポリシーを定義します。

# policy-require-environment-tag.json
{
  "mode": "Indexed",
  "displayName": "VMにEnvironmentタグを必須化",
  "description": "VMリソースにEnvironmentタグがない場合、デプロイを拒否する",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Compute/virtualMachines"
        },
        {
          "field": "tags['Environment']",
          "exists": "false"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}

# Azure CLI — カスタムポリシーをサブスクリプションに登録する
az policy definition create \
  --name "require-environment-tag-on-vm" \
  --display-name "VMにEnvironmentタグを必須化" \
  --description "VMリソースにEnvironmentタグがない場合、デプロイを拒否する" \
  --rules policy-require-environment-tag.json \
  --mode Indexed \
  --subscription "<サブスクリプションID>"

3. イニシアチブにまとめて一括割り当てする

ポリシーが増えてきたら、関連するものをイニシアチブ（ポリシーセット）にまとめると管理が楽になります。オンプレで「基本セキュリティ設定チェックリスト」を一冊にまとめていたのと同じ発想です。

# initiative-definition.json の例（2つのポリシーをまとめたイニシアチブ）
{
  "displayName": "基本ガバナンス要件",
  "description": "タグ必須化とリージョン制限のセット",
  "policyDefinitions": [
    {
      "policyDefinitionId": "/subscriptions//providers/Microsoft.Authorization/policyDefinitions/require-environment-tag-on-vm",
      "parameters": {}
    },
    {
      "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4f",
      "parameters": {
        "listOfAllowedLocations": {
          "value": ["japaneast", "japanwest"]
        }
      }
    }
  ]
}

# Azure CLI — イニシアチブを作成して割り当てる
az policy set-definition create \
  --name "basic-governance-initiative" \
  --definitions initiative-definition.json \
  --display-name "基本ガバナンス要件"

az policy assignment create \
  --name "apply-basic-governance" \
  --display-name "基本ガバナンス要件を適用" \
  --policy-set-definition "basic-governance-initiative" \
  --scope "/subscriptions/<サブスクリプションID>"

料金の仕組み（コスト感覚）

Azure Policyの基本機能（ポリシー定義・割り当て・コンプライアンス評価）は無料です。ほとんどのガバナンスユースケースは追加コストなしでカバーできます。

・Azure Policy基本機能: 無料
・ゲスト構成評価（仮想マシン内部のOS設定チェック）: 仮想マシン1台あたり$6/月（2026年6月時点）
・Azure Arc対象マシン（オンプレのサーバーをAzure管理下に置く場合）: Arc課金体系に準ずる

コスト面での導入障壁が低く、まずAuditエフェクトで現状のコンプライアンス状況を可視化するところから始めやすいサービスです。

コンプライアンスダッシュボードの読み方と運用Tips

ポリシーを割り当ててからコンプライアンス評価が完了するまで、最大で30分程度かかります（リソース数が多い環境ではそれ以上になることがあります）。Azureポータルの「Policy」→「コンプライアンス」でポリシーごとの準拠率を確認できます。

・コンプライアンス率: 準拠リソース数 ÷ 総リソース数 × 100。100%が目標ですが、最初はAuditで現状を把握してから段階的にDenyへ強化するのが正攻法です。
・非準拠リソースの詳細: 違反しているリソースをクリックすると「どのポリシーに違反しているか」「いつから違反しているか」が確認できます。
・修復タスク: DeployIfNotExistsまたはModifyエフェクトのポリシーでは「修復タスクの作成」ボタンから、既存の違反リソースに対して一括修復を実行できます。

段階的強化の推奨手順:
・フェーズ1: Auditエフェクトで割り当て → コンプライアンスダッシュボードで現状把握
・フェーズ2: 影響範囲と既存の自動化スクリプトへの干渉を確認
・フェーズ3: チームに周知後、DenyまたはDeployIfNotExistsに切り替え

最初からDenyにすると、既存のデプロイパイプラインがいきなり拒否されて障害に繋がるケースがあります。Auditで一週間様子を見るだけで、多くのトラブルを未然に防げます。

Azure環境のLinuxサーバー管理についての基礎知識は、姉妹サイトLinuxMaster.JPでも詳しく解説しています。

よくあるトラブルと対処法

・ポリシーを割り当てたのに既存リソースに反映されない: 新規デプロイ時の評価は即時ですが、既存リソースへの適用には「修復タスクの作成」を手動で実行する必要があります。「Policy」→「修復」から対象リソースを選択してください。
・DenyにしたらCI/CDパイプラインが止まった: パイプラインが使うサービスプリンシパルに除外スコープを設定するか、一時的にAuditに戻して影響範囲を再確認してください。
・カスタムポリシーのJSONが検証エラーになる: modeフィールドの指定が重要です。タグやARMプロパティを対象とする場合はIndexed、全リソースタイプを対象とする場合はAllを使います。
・コンプライアンス評価がいつまでも更新されない: 割り当て直後は最大30分待ってください。急ぐ場合は以下のコマンドで手動スキャンを実行できます。

# Azure CLI — コンプライアンス評価を手動でトリガーする
az policy state trigger-scan \
  --resource-group "<リソースグループ名>"

本記事のまとめ

Azure Policyは、クラウド環境のガバナンスをコードとして管理するためのコアサービスです。オンプレの「人とフローによる統制」をAzureでは「ポリシー定義の自動適用」に置き換えることで、リソース数が増えてもガバナンスが崩れない仕組みを作れます。

最初の一歩は「Auditエフェクトでビルトインポリシーを一つ割り当てる」だけで十分です。コンプライアンスダッシュボードに現状が可視化されれば、何を優先してDenyに格上げすべきかが自然と見えてきます。