第1章 · ID・ガバナンス・監視の設計·v2.0.0·更新 2026/6/3·読了目安約10分

変更要約: AZ-305 第1章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）

1.2ガバナンスの設計

この節の要点

組織規模の統制——管理グループ／サブスクリプション、Azure Policy、ランディングゾーン、タグ、コスト管理、リソースロック——を理解します。一貫したガードレールとコスト統制を設計します。

大規模環境ではガードレールが不可欠です。管理グループの階層と Azure Policy で、組織全体に一貫した統制を効かせます。

1.2.1ガバナンスの階層

Azure のガバナンス階層を示した図。ルート管理グループの下に管理グループ（部門/環境別に階層化）→サブスクリプション→リソースグループ→リソースが連なり、各レベルに Azure Policy（許可/拒否/監査・準拠の強制）と RBAC（権限）が継承的に適用され、ランディングゾーン（標準化された基盤の青写真）、タグ（コスト配分/分類）、Cost Management（予算/アラート）、リソースロック（誤削除防止）を添えた図。 — ガバナンスの階層

管理グループ：複数サブスクリプションを階層的に束ね、ポリシー/RBAC を継承適用。
Azure Policy：リソースに許可/拒否/監査を課し、コンプライアンスを強制（例: 特定リージョンのみ）。
ランディングゾーン：標準化された基盤の青写真（ネットワーク/ID/ポリシーを事前構成）。
タグ/Cost Management/ロック：コスト配分・予算アラート・誤削除防止を実現。

試験ポイント

「複数サブスクリプションの階層統制＝管理グループ」「許可/拒否/監査の強制＝Azure Policy」「標準基盤の青写真＝ランディングゾーン」「コスト配分＝タグ、予算アラート＝Cost Management」「誤削除防止＝リソースロック」は AZ-305 で頻出です。Azure Policy は SCP 相当の予防的ガードレールとして使います。

AZ-305 のガバナンス設計は「組織の統制要件を、どの階層でどの手段に落とすか」を問います。管理グループはサブスクリプションを階層化し、ルート管理グループに当てたポリシー/RBAC が下位へ継承されるため、全社共通のガードレールを一元的に効かせられます。Azure Policy は effect（Deny=予防的に作成拒否、Audit=逸脱を記録、DeployIfNotExists/Modify=自動修復・タグ付与）で構成され、複数ポリシーを イニシアチブ（ポリシーセット）にまとめて配布、コンプライアンスダッシュボードで準拠率を可視化します。組織全体の基盤は Azure ランディングゾーン（Cloud Adoption Framework のエンタープライズスケール）で、ネットワーク（ハブ&スポーク）・ID・ポリシー・管理を事前構成された青写真として展開します。コスト面は、タグでコストを部門/プロジェクトに配分し、Cost Management で予算・アラート・コスト分析・推奨を行い、課金は EA/MCA のアカウント階層で管理します。リソースロック（CanNotDelete/ReadOnly）は誤削除・誤変更を防ぎ、ロールやポリシーより優先されます。設計の要は、予防（Deny ポリシー）と発見（Audit）と是正（DeployIfNotExists）を組み合わせ、最上位の管理グループに共通ガードレールを置いて継承させることです。

統制の目的	手段	要点
多サブスクリプションの一元統制	管理グループ	ポリシー/RBAC を継承
構成ルールの強制/監査/是正	Azure Policy（イニシアチブ）	Deny/Audit/DeployIfNotExists
標準化された基盤展開	ランディングゾーン	CAF・ハブ&スポーク・事前構成
コスト配分/予算/誤削除防止	タグ・Cost Management・ロック	ロックはロール/ポリシーより優先

補足

シナリオ：全社で「リソースは日本リージョンのみ・タグ未付与は禁止・診断ログは必ず有効」を強制し、新規サブスクリプションにも自動適用したい。→ ルート管理グループに、許可リージョン（Deny）・必須タグ（Deny/Modify）・診断設定（DeployIfNotExists）を束ねたイニシアチブを割り当て、配下のサブスクリプションへ継承。準拠率はコンプライアンスダッシュボードで監視し、新規サブスクは管理グループ配下に入れるだけで自動適用されます。

補足

FAQ：Azure Policy と RBAC はどう違う？ RBAC は「誰が何の操作をできるか（権限）」を制御し、Azure Policy は「リソースがどんな状態であるべきか（準拠）」を制御します。例えば「VM を作成する権限」は RBAC、「作成する VM は特定 SKU/リージョンに限る」は Azure Policy。両者は補完関係で、ガバナンスには両方が必要です。

注意

ひっかけ：「特定リージョン以外でのリソース作成を防ぎたい」のに RBAC で対応しようとするのは誤り。RBAC は操作権限の制御であり、リソースの属性（リージョン/SKU/タグ）の強制は Azure Policy（Deny）の役割です。また、リソースロックはロールや所有権より優先して削除を防ぐため、Owner でもロック中は削除できない点に注意します。

1.2.2この節のまとめ

統制＝管理グループ階層＋Azure Policy＋ランディングゾーン
コスト/保護＝タグ・Cost Management・リソースロック

進捗の記録にはログインが必要です。

理解度チェック

（軽い確認用）

Q1. 複数のサブスクリプションに対し、一貫したポリシーと RBAC を階層的に適用したい。何を使いますか？

Q2. 「リソースは特定のリージョンにしか作成できない」という強制力のあるルールを課したい。何を使いますか？

Q3. 本番リソースが誤って削除されるのを防ぎたい。何を使いますか？

理解度を確認第1章「ID・ガバナンス・監視の設計」の問題を解く