Azure Policyでポリシーを割り当てるところまでできると、次に気になるのが「で、ちゃんと守られてるの？」という運用の話です。ルールを配っただけでは意味がなく、実際にどれだけ守られているか（コンプライアンス）を確認し、どうしても例外を認めたいリソースをうまく逃がし、最終的には組織全体に統制を効かせる——ここまでできて初めて、Azure Policyは「ガードレール」として機能します。
私自身、はじめてポリシーを割り当てたとき「非準拠が0件のまま出てこない」「一部のリソースだけどうしても例外にしたいのにやり方が分からない」と手が止まりました。公式のMicrosoft Learnを開いても、コンプライアンス・例外（exemption）・Landing Zoneといった言葉が並んで、初心者にはどれが実務のどこに効くのか掴みづらいんですよね。
「ポリシーは割り当てた。でも準拠状況ってどこで見るの？どうしても守れないリソースはどうすればいいの？」
この記事では、Azure Policyの運用と設計を、実務でつまずく順に3つに分けて解説します。コンプライアンス評価の確認、例外（exemption）の扱い方、そしてLanding Zone／ガードレールとしての設計思想です。公式の正確さは押さえつつ、初心者がつまずく所を日本語で噛み砕いていきます。読み終わるころには、Azure Policyを「組織のガードレール」として運用する全体像が自分の中で組み上がっているはずです。
なお、そもそもAzure Policyが何者なのか、RBACとどう違うのかがあやふやな方は、先に Azure Policyとは？RBACとの違い・効果・運用の全体像を図解 に目を通しておくと、この記事の位置づけがはっきりします。本記事はそのシリーズの締めにあたる、運用・設計を深掘りする子記事です。
コンプライアンス評価を確認する
ポリシーを割り当てたら、まず見に行くのがコンプライアンスの画面です。Azureポータルで「ポリシー」を開き、左メニューの「コンプライアンス」を選ぶと、割り当てたポリシーやイニシアチブごとに準拠（Compliant）か非準拠（Non-compliant）かが一覧で並びます。上部には全体の準拠率（Overall compliance）がパーセンテージで表示され、「割り当てたルールに対して、いま組織全体の何％のリソースが守れているか」がひと目で分かるようになっています。
ここは学校の「成績表」だと思うとイメージしやすいです。各ポリシーが科目で、準拠率が点数。非準拠のポリシーをクリックすると、どのリソースが違反しているのか（Resource compliance）まで掘り下げられます。「タグが付いていないストレージアカウントが3件」といった具合に、直すべき対象が具体的に見えてくるわけです。
評価が反映されるまで時間がかかる（最初のつまずき所）
ここで多くの人が最初につまずきます。ポリシーを割り当てても、コンプライアンスの結果はすぐには出ないのです。Azure Policyの評価は、リソースを作成・変更したタイミングのほか、おおむね24時間ごとの定期評価（標準のコンプライアンス評価サイクル）で走ります。つまり、割り当てた直後に画面を見ても「まだ何も出ていない」ことが普通で、私も最初は「設定を間違えたのか？」と何度も見直してしまいました。
結果が出ていないからといって焦る必要はありません。どうしても今すぐ確認したいときは、オンデマンド評価スキャンを手動で走らせられます。Azure CLIなら次の一行です。
az policy state trigger-scan --resource-group myResourceGroupaz policy state trigger-scan：コンプライアンス評価をその場で手動実行するコマンド。--resource-group：スキャン範囲をリソースグループに絞る指定。付けなければサブスクリプション全体が対象になり、規模によってはかなり時間がかかる。
スキャンを走らせても、対象が多いと完了まで数分〜数十分かかることがあります。「反映は即時ではない」という前提さえ頭に入れておけば、無駄に設定を疑わずに済みます。学習中にポリシーを試すときは、割り当て→少し待つ（またはtrigger-scan）→コンプライアンスを確認という順番を体に覚えさせておくと、以降がぐっとラクになります。
「非準拠」は必ずしも即エラーではない
もう一つ押さえておきたいのが、非準拠＝ただちに問題、ではないという点です。ポリシーにはDeny（作成をブロック）のように強制するものもあれば、Audit（違反を記録するだけで止めはしない）のように監査目的のものもあります。Auditで運用しているポリシーなら、非準拠のリソースはコンプライアンス画面に「見える化」されるだけで、実害は出ていません。まずAuditで現状を可視化し、直せるものから直していく——という段階的な進め方が実務では定番です。この「見えている非準拠をどう扱うか」という話が、次の例外につながります。
例外（exemption）を扱う
運用を続けていると、必ず「このリソースだけは、どうしてもポリシーに従えない（従わせたくない）」というケースに出会います。たとえば、検証用に一時的に立てているVMや、特別な事情で古い構成のまま動かし続けているレガシーなシステム。こうした「ルール上は非準拠だけど、事情があって直さない」リソースをキレイに逃がす仕組みが例外（exemption）です。
例外を「校則の許可証」にたとえると分かりやすいです。校則（ポリシー）はクラス全員（全リソース）に適用されるけれど、正当な理由がある生徒には先生が許可証を出す。許可証を持っている生徒は、校則違反としてカウントされない——これが例外の役割です。
例外を作ると何が変わるのか
ここが一番大事なポイントです。例外を設定したリソースは、そのポリシーの評価対象から外れ、コンプライアンス（準拠率）に影響しなくなります。非準拠としてカウントされなくなるので、準拠率が本来対応すべきリソースの状況だけをきれいに映すようになる、というわけです。逃がしたいリソースを例外にしておけば、「直せないものが混ざって準拠率がずっと100%にならない」というモヤモヤも解消されます。
設定はポータルの「ポリシー」→対象の割り当てを開き、「例外の作成」から行えます。範囲（どのリソース／リソースグループを逃がすか）を選び、次の例外のカテゴリを指定します。
- Waiver（免除）：「今は対応しない」と割り切って評価対象から外すケース。もう直す予定がない、あるいは意図的に許容する場合に使う。
- Mitigated（緩和済み）：ポリシーとは別の手段で、すでにリスクに対処できているケース。「このポリシーでは非準拠に見えるが、別の仕組みでカバー済み」という状況。
この2つは「なぜ例外にするのか」という理由づけの分類です。監査のときに「この例外はどういう判断で出したのか」を説明できるよう、正直に選んでおきましょう。
例外に「期限」を付けるクセをつける
例外でやりがちな失敗が、「一時的に」と言いながら永久に残ってしまうことです。検証用に逃がしたはずのリソースが、半年後もこっそり例外のまま統制の外にいた——というのは、あるあるの事故です。これを防ぐために、例外には有効期限（expiresOn）を設定できます。期限を切っておけば、その日を過ぎると自動的に例外が失効し、リソースは再び評価対象に戻ります。
「例外は許可証。ただし期限付きで発行する」。この一手間が、例外の穴だらけ運用を防いでくれます。
なお、例外は「評価から外す」仕組みであって、ポリシーそのものを弱めるわけではありません。他のリソースには変わらずルールが効き続けます。あくまでピンポイントで、理由と期限を添えて逃がす——この節度を守れると、統制を保ったまま現実の例外にも対応できるようになります。
Landing Zone / ガードレール設計に活用する
ここまでは「割り当てたポリシーをどう運用するか」の話でした。最後は視点を一段上げて、組織全体にどう統制を効かせるかという設計の話です。これがAzure Policyの本当の使いどころ、いわゆるガードレールです。
ガードレールは、その名のとおり道路のガードレールをイメージすると腑に落ちます。ガードレールは車の運転を細かく指示はしませんが、コースから大きく外れて崖に落ちることだけは防いでくれる。同じように、開発者にはある程度自由にリソースを作らせつつ、「許可されていないリージョンには作らせない」「タグの付いていないリソースは作らせない」といった致命的な逸脱だけを自動で止める——これがガードレールとしてのAzure Policyの発想です。一人ひとりを監視するのではなく、外枠を決めておく、というイメージですね。
管理グループに配って、サブスク全体に一気に効かせる
組織全体に統制を効かせる鍵が管理グループ（Management Group）です。Azureの階層は上から管理グループ → サブスクリプション → リソースグループ → リソースという入れ子になっていて、ポリシーは上の階層に割り当てると下の階層すべてに継承されるという性質があります。
これは会社の「全社ルール」と同じ構造です。本社（管理グループ）が決めた就業規則は、各支店（サブスクリプション）にも各部署（リソースグループ）にも自動的に適用される。ポリシーを一番上の管理グループに一度割り当てておけば、その配下に新しくサブスクリプションを追加しても、わざわざ設定し直さなくても最初から同じ統制が効いている——これがガードレール設計の肝です。サブスクリプションごとに手で割り当てていたら、抜け漏れが必ず起きますからね。
Landing Zoneという「整地された土地」
この考え方を体系化したのが、Microsoftのクラウド導入フレームワーク（CAF）で語られるLanding Zone（ランディングゾーン）です。Landing Zoneは、直訳すると「着陸地帯」。新しいワークロード（アプリやシステム）をAzureに載せるときに、あらかじめネットワーク・セキュリティ・そしてガバナンス（＝ポリシー）が整えられた”整地済みの土地”を用意しておく、という設計思想です。
更地に家を建てるのと、水道・電気・道路が通った分譲地に家を建てるのとでは、後者のほうが圧倒的に速くて安全ですよね。Landing Zoneはこの「分譲地」にあたります。そしてその土地に最初から敷かれている交通ルールが、管理グループに割り当てられたAzure Policyです。開発チームが新しいサブスクリプション（区画）を受け取った時点で、すでにガードレールが効いている状態を作っておく——ここまで来て、Azure Policyは「個別のルール」から「組織のガバナンス基盤」へと役割が変わります。
もちろん、いきなり本格的なLanding Zoneを一から組む必要はありません。学習段階では「ポリシーは管理グループに割り当てると下に継承される」「その継承の仕組みでガードレールを設計する」という考え方を理解しておくだけで十分です。イニシアチブ（複数ポリシーの束）を管理グループに割り当てる形が、実務でのガードレールの基本形になります。イニシアチブの作り方は、姉妹記事のカスタムポリシー編で扱っています。
まとめ
この記事では、Azure Policyの運用と設計を、割り当てた後の実務でつまずく順に見てきました。要点を振り返っておきます。
- コンプライアンス評価：ポータルの「コンプライアンス」画面で準拠／非準拠と全体準拠率を確認。ただし評価の反映には時間差（標準で約24時間サイクル）があるので焦らない。急ぐなら
trigger-scanで手動実行。 - 例外（exemption）：「非準拠だが直さない」リソースを評価対象から外し、準拠率に影響させない仕組み。カテゴリはWaiverとMitigated。有効期限を付けて、逃がしっぱなしを防ぐ。
- ガードレール設計：ポリシーを管理グループに割り当てて下位のサブスク全体に継承させ、致命的な逸脱だけを自動で止める。これを整地済みの土地として体系化したのがLanding Zone。
ここまで来れば、Azure Policyを単なる「割り当てるルール」ではなく、組織全体を守るガードレールとして運用・設計できるようになったはずです。ポリシーを作り、割り当て、準拠状況を見て、例外を管理し、管理グループで全体に効かせる——この一連の流れが頭の中でつながっていれば、Azure Policyのシリーズはひとまず卒業です。あとは実際のテナントで手を動かしながら、自分の組織に合ったガードレールを育てていってください。
あわせて読みたい：
