Azureをチームで使いはじめると、必ずぶつかるのが「勝手に変なリソースを作られない仕組み」です。誰かが東日本リージョン以外にうっかりVMを立てたり、タグを付け忘れたまま本番リソースを量産したり——人が増えるほど、こういう「ルールからのはみ出し」は避けられなくなります。それを一人ひとりの注意力ではなく、仕組みで自動的に取り締まるのがAzure Policyです。
ただ、いざMicrosoft Learnの公式ドキュメントを開くと、「ポリシー定義」「イニシアチブ」「効果（effect）」といった用語が一気に押し寄せてきて、私自身、学びはじめの頃はここで完全に手が止まりました。用語は正確なんですが、初心者にはとにかく関係性が見えづらいんですよね。
「Azure Policyって、RBAC（アクセス権）と何が違うの？定義とかイニシアチブとか、結局どういう関係で動いてるの？」
この記事は、そんな「全体像がつかめない」を解消するためのハブ記事です。Azure Policyとは何かから始めて、初心者が最も混同するRBACとの役割の違い、そしてポリシー定義・イニシアチブ・割り当てという3人の登場人物の関係、スコープと継承、効果（Deny／Audit／Modifyなど）の全体像、最後に実務でいちばん大事な「監査から強制へ段階的に移る考え方」までを、公式Learnを日本語で噛み砕きながら通しで整理します。読み終わるころには、Azure Policyの世界地図が頭の中にできあがっているはずです。
具体的な割り当ての操作手順やカスタムポリシーの書き方は、記事末尾で紹介する子記事に譲ります。まずはここで「概念の土台」を固めましょう。
Azure Policyとは：リソースを「組織のルール」に従わせる仕組み
Azure Policyを一言でいうと、「Azure上のリソースが、組織の決めたルールに従っているかを評価し、従っていなければ止めたり直したりする仕組み」です。公式の言葉では「組織標準への準拠（コンプライアンス）を強制・評価する」と表現されますが、要するにクラウド版の校則だと思えば分かりやすいです。
校則の例をそのままAzureに当てはめると、こんなイメージになります。
- 「リソースはJapan East（東日本）以外のリージョンに作ってはいけない」→ データの越境を防ぐ
- 「すべてのリソースにowner（管理者）タグを必ず付けること」→ 誰の持ち物か分からないリソースをなくす
- 「指定したサイズより大きいVMは作れない」→ コストの暴走を防ぐ
ポイントは、これらを人間が目視でチェックするのではなく、Azureが自動で評価してくれるところです。誰かがルール違反のリソースを作ろうとした瞬間にブロックしたり、あるいは「違反しているリソースの一覧」をダッシュボードに出したりしてくれる。人の善意や注意力に頼らず、ガードレールを敷けるのがAzure Policyの本質です。
RBACとの違い：「誰が」ではなく「何を」を制御する
ここが、初心者がAzure Policyでいちばん混乱する山場です。「アクセス制御ならRBAC（ロールベースアクセス制御）があるじゃないか、Policyと何が違うの？」という疑問。私も最初、この2つの守備範囲がぐちゃぐちゃになっていました。結論から言うと、両者はまったく別の質問に答える仕組みです。
いちばんスッキリするたとえはマンションの管理です。
RBACは「誰がその部屋に入れるか（＝誰が操作していいか）」を決める鍵の配布です。田中さんには303号室の鍵を渡す、佐藤さんには管理人室の鍵も渡す——つまり「人」に対して「この操作をしていいよ」という権限を与える仕組みですね。「仮想マシンを作成できる」「ストレージを読み取れる」といった操作の可否を担当します。
一方のAzure Policyは「その部屋に何を置いていいか（＝どんなリソースを許すか）」を決める管理規約です。「ベランダに物置を設置してはいけない」「ペットは小型犬まで」——つまり相手は「人」ではなく「リソースそのものの性質」。誰が操作するかにかかわらず、「東日本以外にVMを作る」という行為の結果を許すか許さないかを判定します。
両者は競合するものではなく、重ねて効く二重のガードです。実務ではこの順番で考えると腹落ちします。
- まずRBACが「あなたはVMを作る権限を持っていますか？」をチェックする（権限がなければここで終わり）
- 権限があっても、次にAzure Policyが「そのVMは組織のルールに合っていますか？」をチェックする（東日本以外ならブロック）
「RBAC＝人への権限」「Policy＝リソースへのルール」。この一行だけ覚えて帰ってもらえれば、この記事の半分は成功です。
だから「Contributor（共同作成者）ロールを持っている＝何でも作り放題」ではありません。強い権限を持った人でも、Policyのガードレールの外には出られない。ここが、大規模な組織でガバナンスを効かせるうえでAzure Policyが欠かせない理由です。
登場人物は3つ：定義・イニシアチブ・割り当て
Azure Policyがつかみにくい最大の理由は、「ルールを1つ作る」だけでは何も起きないところにあります。実際に効かせるには、3つの登場人物を順番に通す必要があるんです。ここを図解的に整理しておくと、あとの理解が一気にラクになります。
この3つは、料理でたとえると分かりやすいです。
① ポリシー定義（Policy Definition）＝ 1枚のレシピ
ポリシー定義は、「どんな条件のときに、どうする」というルール1つ分の設計図です。「リージョンが東日本でなければ、作成を拒否する」——このワンセットが1つの定義。料理でいうレシピ1枚ですね。ここではまだ「書いてあるだけ」で、実際の鍋には何も起きていません。
Azureには最初から数百種類の組み込みポリシー定義（Built-in）が用意されています。「許可されたリージョン」「タグの継承」「監査ログの有効化」など、よくある要件のレシピはたいてい最初から揃っているので、まずはここから選ぶのが基本です。足りなければカスタム定義を自分で書きます（これは子記事のテーマです）。
② イニシアチブ（Initiative）＝ レシピをまとめた献立集
ルールが1つや2つならレシピ単位でも回りますが、実務では「セキュリティ基準を満たすために30個のルールをまとめて適用したい」といったことが普通に起きます。それを1枚ずつ扱うのは大変です。
そこで登場するのがイニシアチブ（ポリシーセットとも呼ばれます）。これは複数のポリシー定義を1つの束にまとめたもので、料理でいう「今日の献立集（前菜＋メイン＋デザート）」にあたります。たとえばAzureにはCIS（セキュリティのベンチマーク）に対応した組み込みイニシアチブがあり、これ1つを扱うだけで、その基準を構成する何十ものルールをまとめて管理できます。「関連するルールをパッケージにして扱う」のがイニシアチブの役割です。
③ 割り当て（Assignment）＝ 実際に調理する
ここが最重要ポイントです。定義やイニシアチブを用意しただけでは、まだ1つのリソースも評価されていません。レシピや献立集を棚に置いてあるだけで、まだ誰も料理していない状態です。
実際にルールを効かせるには、その定義（またはイニシアチブ）を「どの範囲に適用するか」を指定して割り当て（Assign）します。この「どの範囲に」が次章で説明するスコープです。割り当てて、スコープを指定して、はじめてAzure Policyはそのスコープ内のリソースを評価しはじめます。料理でいえば、献立を選んで実際にキッチンで作る工程ですね。
この3段構えを一本の流れにすると、こうなります。
- 定義（ルール1つ）を作る／組み込みから選ぶ
- 必要なら複数の定義をイニシアチブに束ねる
- それをスコープに割り当てて、はじめて評価が動きだす
「定義したのに効かない」と悩む初心者の9割は、この「割り当てを忘れている」のが原因です。定義＝作った、割り当て＝効かせた、と役割をハッキリ分けて覚えておきましょう。
スコープと継承：どの範囲に効かせるか
割り当てのときに指定するスコープ（適用範囲）は、Azureの階層構造に沿って決めます。Azureのリソースは、大きい入れ物から順にこう入れ子になっています。
- 管理グループ（Management Group）… 複数のサブスクリプションをまとめる、いちばん大きな入れ物
- サブスクリプション（Subscription）… 課金と管理の単位。その中に…
- リソースグループ（Resource Group）… 関連リソースをまとめる、いちばん小さな入れ物
ここで大事なのが継承です。ポリシーの割り当ては、指定したスコープと、その「下」にあるものすべてに自動的に効きます。会社の組織図で、社長が出した通達が全部署に降りていくのと同じイメージです。
たとえば管理グループに「リージョンは東日本のみ」を割り当てると、その配下のすべてのサブスクリプション・すべてのリソースグループに、この1つの割り当てがまとめて効きます。逆に、あるリソースグループにだけ試したいなら、そのリソースグループをスコープに指定すればいい。広く効かせたいほど上の階層に、狭く限定したいほど下の階層に割り当てる——この使い分けがスコープ設計の基本です。
実務では「全社共通の必須ルールは管理グループに」「特定プロジェクト固有のルールはそのサブスクやリソースグループに」と、階層ごとに役割分担させます。また、割り当てには除外（exclusion）を設定して「基本は全体に効かせるが、この1つのリソースグループだけは対象外」といった例外も作れます。この設計論の深掘りは運用編の子記事で扱います。
効果（effect）：ルールに引っかかったとき「何をするか」
ポリシー定義には必ず効果（effect）が1つ設定されています。これは「ルールの条件に一致したときに、Azureが実際に何をするか」を決める部分で、Azure Policyの挙動を理解するうえでいちばんの肝です。効果にはいくつか種類がありますが、初心者はまず次の4系統を押さえれば十分です。
Deny：ルール違反の作成をブロックする
Denyは、いちばん強い効果です。ルールに違反するリソースの作成・更新をその場で拒否します。「東日本以外にVMを作ろうとするとエラーで弾かれる」——これがDenyです。ガードレールとしていちばん効きますが、それだけにいきなり本番でこれを付けると、正当な作業まで止まって現場が混乱します。ここが後述する「段階的移行」の話につながります。
Audit：ブロックせず「違反を記録」だけする
Auditは、Denyと対になる穏やかな効果です。ルールに違反していても作成は止めず、「これは違反していますよ」とコンプライアンス状況に記録するだけ。いわば見張りはするけど手は出さないモードです。「今の環境にどれだけルール違反があるか」をまず可視化したいときに使います。学習でも実務でも、最初に触るべきはこのAuditです。
Append / Modify：足りないプロパティを補ってくれる
AppendとModifyは、拒否ではなく「足りない部分を自動で埋める」効果です。たとえば「作成されるリソースにownerタグが無ければ、自動で付け足す」といった動きをします。Appendはプロパティの追加、Modifyはタグの追加・変更・削除など、より柔軟な書き換えができる上位版、というイメージです。ユーザーの作業を止めずに、こっそり組織標準に整えてくれる、実務でとても便利な効果です。
DeployIfNotExists：不足しているリソースを自動で作る
DeployIfNotExists（DINE）は、いちばん賢い効果です。「あるべきリソースが存在しなければ、自動でデプロイして揃える」という動きをします。たとえば「新しく作られたストレージアカウントに診断ログ設定が無ければ、自動でログ設定をデプロイする」といった具合。違反を見つけたら直すところまでやってくれるので、大規模環境の自動修復（Remediation）でよく使われます。強力な分、この効果はデプロイのためのマネージドID（権限）が必要になるなど設定が一段複雑なので、まずは「そういう自動化系の効果もある」と知っておけば十分です。
このほかにも、子リソースの有無を監査するAuditIfNotExists、評価を一時的に止めるDisabledなどがありますが、まずは「止める(Deny)・記録する(Audit)・補う(Append/Modify)・作る(DeployIfNotExists)」の4系統を軸に覚えておけば、公式ドキュメントもぐっと読めるようになります。
監査（Audit）から強制（Deny）へ：段階的に移行するのが鉄則
効果を理解したうえで、実務でいちばん大事な「勘所」をお伝えします。それはいきなり本番環境にDeny（強制ブロック）を付けてはいけないということです。これは私が現場で何度も実感してきた、Azure Policy運用の鉄則です。
理由は単純で、既存の環境にはすでにルール違反のリソースが山ほどあるのが普通だからです。そこへ何の準備もなくDenyを効かせると、既存リソースの更新が突然できなくなったり、正当な運用作業まで軒並みブロックされたりして、現場が大混乱します。「ガバナンスを強めようとしたら業務が止まった」——これは避けなければいけません。
そこで定石になるのが、Auditから始めてDenyへ段階的に引き上げるという進め方です。
- まずAuditで割り当てる。ブロックはせず、「今どれだけ違反があるか」をコンプライアンス画面で可視化する。この時点では誰の作業も止まらない。
- 可視化された違反を洗い出して直す。違反しているリソースを一つずつ組織標準に合わせていく（あるいは正当な例外は除外設定する）。
- 違反がほぼ無くなったら、効果をDenyに切り替える。ここではじめて「今後の新規作成はブロックする」という強制モードにする。すでにクリーンなので、切り替えても現場は止まらない。
ちょうど、いきなり全校で校則を厳罰化するのではなく、まず「調査期間」を設けて現状を把握し、周知して直させてから、正式にルールを施行するのと同じ流れです。多くの組み込みポリシーが、割り当て時に効果をAudit／Deny／Disabledから選べるようになっているのは、まさにこの段階的移行を想定しているからなんですね。
「まずAuditで見える化 → 直す → Denyで締める」。この順番さえ守れば、Azure Policyで現場を止めてしまう事故はほぼ防げます。
まとめ
この記事では、Azure Policyの全体像を「概念の地図」として一気に整理しました。要点を振り返っておきます。
- Azure Policyとは：リソースが組織のルールに従っているかを自動評価し、止めたり直したりする「クラウド版の校則」。
- RBACとの違い：RBACは「誰が操作できるか（人への権限）」、Policyは「どんなリソースを許すか（リソースへのルール）」。二重のガードとして重ねて効く。
- 3つの登場人物：ルール1つの定義 → 束ねるイニシアチブ → スコープに割り当てて、はじめて評価が動く。「割り当て忘れ」が効かない原因の定番。
- スコープと継承：管理グループ／サブスク／リソースグループの階層に割り当て、下位に継承される。広く効かせたいほど上の階層へ。
- 効果：止める(Deny)・記録する(Audit)・補う(Append/Modify)・作る(DeployIfNotExists)の4系統を軸に押さえる。
- 段階的移行：本番はいきなりDenyにせず、Auditで可視化 → 直す → Denyへの順で締めるのが鉄則。
ここまでで、Azure Policyの用語と関係性の地図はできあがりました。次は実際に手を動かすフェーズです。「組み込みポリシーを割り当ててみる」ところから始めて、カスタムポリシー、本格運用へと進んでいきましょう。
さらに深く学ぶ：Azure Policy 実務シリーズ
本記事はAzure Policyシリーズの概要ハブ（親記事）です。ここで固めた全体像をもとに、実際に手を動かす実務編を用意しています（順次公開予定）。
- 組み込みポリシーを割り当ててみる（Audit→Denyの実践ハンズオン）… まずはAzure用意済みの組み込み定義を割り当て、コンプライアンス画面で違反を確認するところまで。
- カスタムポリシーとイニシアチブを自作する… 組み込みで足りない要件を、ポリシー定義（JSON）とイニシアチブで自分で作る方法。
- Azure Policyの運用と設計（コンプライアンス・例外・Landing Zone）… 例外（除外）の扱い、自動修復、Landing Zoneでの全社設計まで、本番運用の勘所。
Azure Policyはガバナンスの中心にある機能なので、Azureをチームで使うすべての人にとって避けて通れないテーマです。まずはこのハブで地図を頭に入れ、実務シリーズで一歩ずつ手を動かしていってください。
Azureのスキルを「年収」に変えるなら
ここまで手を動かせるようになったなら、そのスキルは市場価値のある武器です。私自身、クラウドの実務経験を軸に単価を上げてきました。クラウドエンジニアとして転職・フリーランスで年収を上げたいなら、まずは自分の市場価値を知るところからです。
未経験・学生・ハイクラスなど、状況別におすすめのエージェントを比較した記事を用意しています。あわせてどうぞ。
