変更要約: AZ-500 第4章を深掘り（図ja化・比較表/シナリオ/FAQ/ひっかけ/深掘り段落を全節に追加）
4.3ガバナンスとコンプライアンス
組織のルールを技術的に強制する Azure Policy、設定の雛形をまとめて適用する Azure Blueprints（※非推奨で 2026 年 7 月に廃止予定。後継は Azure Deployment Stacks＋Azure Policy）、規制基準への適合を可視化する Defender for Cloud の 規制コンプライアンス を理解します。大規模環境を一貫して安全に保ちます。
大規模な環境では「人手のチェック」では一貫性を保てません。Azure Policy でルールを技術的に強制し、コンプライアンス状態を継続的に評価します。
4.3.1ガバナンスの仕組み
- Azure Policy：ルールを定義しスコープに割り当て、準拠/非準拠を継続評価する。
- effect：deny（非準拠の作成を拒否）・audit（記録のみ）・deployIfNotExists（自動修復）など。
- イニシアチブ：複数ポリシーを束ねた集合。基準（例: ISO/PCI）への対応をまとめて割り当てる。
- Blueprints / 規制コンプライアンス：設定の雛形をまとめて展開し、Defender for Cloud で基準への適合を可視化する。
「ルールを技術的に強制＝Azure Policy」「非準拠の作成を拒否＝deny effect」「記録のみ＝audit」「自動修復＝deployIfNotExists」「複数ポリシーの束＝イニシアチブ」「基準への適合を可視化＝Defender for Cloud の規制コンプライアンス」 は AZ-500 で頻出です。RBAC が「誰が何を」なら、Policy は「リソースがどうあるべきか」を強制します。
RBAC（認可）と Azure Policy（リソースの状態の強制）は役割が異なります。両方を組み合わせて最小権限かつ準拠した環境を保ちます。
effect は挙動が大きく異なるため整理が要ります。deny は非準拠リソースの作成/更新を拒否、audit/auditIfNotExists は記録のみ、append は不足プロパティを付与、modify はタグ等を変更、deployIfNotExists は不足する関連リソース（例：診断設定）を自動展開します。後者 2 つは実際に変更を加えるため マネージド ID と修復タスク（リメディエーション）が必要です。スコープは 管理グループ→サブスクリプション→リソースグループ の階層で継承され、例外は 除外（exclusion） や 適用しない（exemption） で表現します。deny を後から割り当てても既存の非準拠リソースは消えず「非準拠」と評価されるだけなので、是正は修復タスクで行います。なお Azure Blueprints は現在 Template Specs＋デプロイスタック への移行が案内されている点も新しめの観点です。組織全体の土台設計は Azure Landing Zone（管理グループ階層・ポリシー・ネットワークの既定）として体系化されています。
| 観点 | Azure RBAC | Azure Policy |
|---|---|---|
| 問い | 誰が何をできるか | リソースはどうあるべきか |
| 対象 | プリンシパルの操作権限 | リソースの構成/状態 |
| 代表例 | Reader/Contributor/Owner | 暗号化必須・許可リージョン限定 |
シナリオ： 「すべてのストレージは診断設定が有効でなければならない」を組織全体に強制し、既存分も自動で是正したい。→ deployIfNotExists のポリシー（イニシアチブに含めてもよい）を管理グループに割り当て、マネージド ID を付与、修復タスクを実行して既存リソースにも診断設定を展開します。新規作成分は以後自動で準拠します。
FAQ： Q. Policy で既存の非準拠リソースは自動で消えますか？ → A. いいえ。deny は新規の作成/更新を止めるだけで、既存分は「非準拠」と評価されます。是正は修復タスク（modify/deployIfNotExists）で行います。Q. RBAC で代用できますか？ → A. できません。RBAC は権限、Policy はリソースの状態を強制するもので役割が異なり、併用します。
ひっかけ： 「deny ポリシーを割り当てると既存の非準拠リソースが削除/修正される」は誤りです。deny は新規の作成/更新を拒否するだけで、既存分は非準拠評価のまま。自動修正は modify や deployIfNotExists ＋修復タスクの役割です。また「Azure Policy はアクセス権を制御する」も誤り（それは RBAC）。
4.3.2この節のまとめ
- Azure Policy＝ルールの技術的強制（deny/audit/deployIfNotExists・イニシアチブ）
- 規制コンプライアンス＝基準への適合を可視化（Defender for Cloud）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 「すべてのリソースは特定リージョンのみ」「暗号化必須」などの組織ルールを技術的に強制したい。何を使いますか？
Q2. 非準拠なリソースの作成自体をブロックする Azure Policy の effect はどれですか？
Q3. 複数の Azure Policy を束ね、ISO や PCI などの基準対応をまとめて割り当てたい。何を使いますか？