🎬 はじめに
Azure の利用が広がるにつれて、多くの企業様が同じような壁にぶつかります。「リソースが増えて全体像を把握できない」「誰がどのリソースを管理しているのか分からない」「設定不備が発見されず、後になってコストやセキュリティの問題が表面化する」。こうした課題は、リソースを作り始めた段階でガバナンスを組み込んでいれば、大部分を防げます。
本記事では、Azure リソースの 設計と構築の段階 にフォーカスし、ガバナンスの効いた運用を実現するための 5 つの手法をご紹介します。すべて今日から着手できる実践的な内容です。
目次
- 手法1：管理グループとサブスクリプションの構造を設計する
- 手法2：命名規則とタグを標準化する
- 手法3：Azure Policy でルールを自動適用する
- 手法4：RBAC で最小権限の権限設計を行う
- 手法5：IaC で構築を再現可能にする
❓なぜ「設計・構築」の段階でガバナンスが必要なのか
ガバナンスを後から整備しようとすると、すでに作られた数百のリソースを対象に、修正や再設定が必要になります。Azure Policy の割り当てやタグの追加は可能ですが、リソースが増えるほど作業は増え、対応コストは大きくなります。
一方、設計・構築の段階で仕組みを組み込んでおくと、新しいリソースは最初からルールに従った形で作られます。Microsoft のクラウド採用フレームワーク（Cloud Adoption Framework）でも、ガバナンスは「後付け」ではなく「最初の設計」に含めることが推奨されています。5 つの手法の全体像は以下の通りです。
| 手法 | 主な目的 | 主な成果物 |
|---|---|---|
| 1. 構造設計 | 環境の整理・境界の明確化 | 管理グループ階層、サブスクリプション分割 |
| 2. 命名規則・タグ | 一覧性・検索性・コスト配分の基盤 | 命名規則表、タグ標準 |
| 3. Azure Policy | ルールの自動適用・違反検知 | ポリシー/イニシアティブの割り当て |
| 4. RBAC | 最小権限の権限設計 | ロール定義、スコープ設計 |
| 5. IaC | 構築の再現性・レビュー性 | テンプレート、CI/CD パイプライン |
📌 手法1：管理グループとサブスクリプションの構造を設計する
Azure ガバナンスの土台となるのが、 管理グループ（Management Group） による階層構造です。管理グループを使うと、複数のサブスクリプションを束ねて、ポリシーやロール、コスト管理の設定を一括で適用できます。
構造設計の考え方
Microsoft が推奨するのは、環境（本番・検証・開発）と部門（事業部・プロジェクト）を軸にした階層設計です。たとえば、次のような構造が一般的です。
- ルート管理グループ
- 本番環境
- 事業部A
- 事業部B
- 検証環境
- 開発環境
- 本番環境
サブスクリプションの分割基準
サブスクリプションは「環境」「部門」「システム」のいずれかを単位に分割します。すべてを 1 つのサブスクリプションに集約すると、ポリシーや予算、権限の境界が曖昧になり、後々の管理が難しくなります。分割の目安は以下の通りです。
- 環境単位：本番、検証、開発で分ける（最も多いパターン）
- 部門・予算単位：部門別にコストを把握したい場合
- システム単位：重要システムやコンプライアンス要件が異なる場合
⭐️ 実装のポイント：管理グループとサブスクリプションの構造は、Azure Portal や Bicep、Terraform で宣言的に定義できます。最初は最小構成（環境単位の分割）から始め、運用しながら育てていくことをお勧めします。
設計・設定後の活用例
構造を一度作ってしまえば、あとは「集約された場所」に設定を置くだけで、環境全体に効きます。たとえば次のような運用が日常的に行えます。
- 一括ポリシー適用：本番環境の管理グループに Azure Policy を割り当てれば、配下の全サブスクリプションに一斉にルールが効きます。環境ごとに共通ルールを 1 回の設定で維持できます。
- 環境別のコスト把握：管理グループ単位で予算（Budget）とアラートを設定し、本番・検証・開発それぞれのコスト超過を早期に検知します。
- 利用状況の見える化：管理グループ配下のリソース全体を一覧し、使われていない開発環境の棚卸しや不要リソースの削除判断に使います。
📌 手法2：命名規則とタグを標準化する
構造が決まったら、次に命名規則とタグを標準化します。これはリソースの一覧性と検索性を高め、コスト管理や運用の土台になります。
命名規則の例
Azure にはリソースごとに名前の制約（長さや使える文字）があり、それに従ったうえで統一ルールを決めます。たとえば、リソースグループは次のような形式が分かりやすいです。
rg-{システム}-{環境}-{用途}
例）rg-sales-prod-webapp
各リソースにも接頭辞を決めます。例えば、仮想ネットワークは vnet-、ストレージは st、Web アプリは app- などです。Microsoft の公式ドキュメントでは、Azure リソースの推奨略称（Abbreviation examples）が公開されているため、それを基準にするのがお勧めです。
タグ標準の設計
タグは「キー＝値」のラベルで、リソースの分類やコストの配分、運用担当の特定に使います。多くの企業様で有効なタグの例は以下の通りです。
| タグキー | 値の例 | 用途 |
|---|---|---|
| Environment | prod / staging / dev | 環境の識別、開発環境の自動停止 |
| Owner | 担当チーム名 | 問い合わせ先の特定 |
| CostCenter | 部門コード | コスト配分、部門別レポート |
| AppName | システム名 | システム単位の把握 |
⭐️ 実装のポイント：命名規則とタグの標準は、ドキュメント化して共有するだけでなく、次の手法で紹介する Azure Policy によって「必須タグ」として強制すると定着します。
設計・設定後の活用例
命名規則とタグは、作って終わりではなく「リソースを探す・分ける・自動化する」ための道具として日常的に使います。
- 検索と特定：命名規則に沿った名前やタグでリソースを絞り込み、「このシステムのリソースは全部でいくつあるか」をすぐに把握します。
- コスト配分レポート：
CostCenterタグを基に部門別のコストレポートを出力し、予算管理や請求書の按分に使います。 - 環境別の自動運用：
Environmentタグを見て、開発環境だけを夜間に自動停止するなど、タグを起点にしたコスト削減の自動化を組みます。 - 未設定リソースの検知：タグが付いていないリソースを一覧化し、運用ルールの定着状況を定期的に確認します。
📌 手法3：Azure Policy でルールを自動適用する
設計ルールを「人間の意識」に頼らず運用するのが Azure Policy です。ポリシーを割り当てておくと、リソースの作成時に自動的にルールがチェックされ、違反を防いだり検知したりできます。
よく使われるポリシーの例
- 必須タグの強制：
Environment、Ownerなどのタグがないリソースを拒否、または自動でタグを付与 - 許可リージョンの制限：利用できる Azure リージョンを指定し、海外リージョンへのリソース作成を防止
- SKU の制限：高額な SKU や許可外の SKU の使用を防止
- パブリックアクセスの禁止：ストレージや仮想マシンの公開設定を規制
ポリシーは複数まとめた イニシアティブ（ポリシーセット） として定義すると、テーマごとに管理しやすくなります。
導入の進め方
- まず対象とするルールを 3〜5 個に絞って定義する
- 監査モード（違反の検知のみ）で割り当て、現状を把握する
- 影響を確認しながら、拒否モードへ切り替える
- 既存リソースの違反は「修復タスク」で自動修正する
⭐️ 実装のポイント：Azure Policy は管理グループ単位で割り当てると、複数のサブスクリプションに一括適用できます。手法1 の構造設計と組み合わせることで効果を発揮します。
設計・設定後の活用例
ポリシーを割り当てた後は、「守られているか」を継続的に確認するのが活用の中心になります。
- コンプライアンスの可視化：Policy のコンプライアンス画面でルールごとの合格率を確認し、チームや経営層への報告資料に使います。
- 違反の早期検知：違反を検知したらメール通知やアラートで担当者に知らせ、設定不備の放置を防ぎます。
- 修復タスクの実行：既存リソースの違反を「修復タスク」で一括修正し、基準への適合を回復します。
- 新規作成時の即時チェック：新しいリソースを作るたびに自動でルールがチェックされるため、設定不備のまま残るリソースが増えません。
📌 手法4：RBAC で最小権限の権限設計を行う
Azure の権限は RBAC（ロールベースのアクセス制御） で管理します。メンバーを直接権限付与するのではなく、ロールを定義し、そのロールを「誰に」割り当てるかを管理します。
スコープの考え方
RBAC の割り当ては「管理グループ」「サブスクリプション」「リソースグループ」「リソース」の単位で行えます。上位で割り当てた権限は下位に継承されるため、次のような設計が基本です。
- 管理グループ：全環境に共通の閲覧ロール
- サブスクリプション：環境ごとの管理者ロール
- リソースグループ：開発チームの所有者・投稿者ロール
最小権限の実践
- 組み込みロール（
Contributor、Reader、Ownerなど）を基本に選ぶ - 特殊な要件がある場合のみカスタムロールを作成する
- リソースグループ単位の割り当てを優先し、サブスクリプション全体への
Owner付与は最小限にする - 特権操作は PIM（Privileged Identity Management）による一時的な昇格を検討する
⭐️ 実装のポイント：権限は「誰が何をできるか」を定期的に見直します。特に退職者や担当変更時の失効した権限の削除は、監査の観点でも重要です。
設計・設定後の活用例
権限設計は、作成した時点で完了するのではなく「見直し続ける」ことが重要です。
- 定期アクセスレビュー：四半期ごとにアクセスレビューを実行し、不要になった権限や不正な割り当てを棚卸しします。
- 特権操作の記録と監査：PIM による一時昇格の履歴から「誰が・いつ・なぜ高い権限を使ったか」を監査資料として確認します。
- 入退社・異動時の権限変更：担当変更時にロール割り当てを更新する手順を標準化し、失効した権限の放置を防ぎます。
📌 手法5：IaC で構築を再現可能にする
最後は、Azure リソースの構築を手作業ではなく IaC（Infrastructure as Code） で行う手法です。Bicep や Terraform を使ってリソースをコードで定義すると、構築手順が属人化せず、レビューや監査の対象にもできます。
Bicep の例（タグ付きリソースグループ）
resource rg 'Microsoft.Resources/resourceGroups@2024-03-01' = {
name: 'rg-sales-prod-webapp'
location: 'japaneast'
tags: {
Environment: 'prod'
Owner: 'sales-platform'
CostCenter: 'CC-1002'
}
}
このようなテンプレートを Git で管理し、Pull Request によるレビューと承認を経てデプロイすることで、「誰が、いつ、何を変更したか」の履歴が残ります。
ドリフトの検知
コードで構築した後、ポータルからの手動変更が入ると「コードと実環境の乖離（ドリフト）」が発生します。Bicep や Terraform にはドリフトを検出する機能があり、定期的にチェックして実環境をコードの状態に戻す運用が有効です。
⭐️ 実装のポイント：最初から完璧なパイプラインを作る必要はありません。まずは 1 つのシステムの標準テンプレートを作り、CI/CD に組み込むところから始めることをお勧めします。
設計・設定後の活用例
テンプレートと CI/CD ができあがると、構築と変更が「レビュー可能な手続き」として毎日使われます。
- PR による変更レビュー：環境の変更はすべて Pull Request を経由するため、誰でも変更内容を確認してからマージできます。
- CI/CD での自動デプロイ：マージされたコードは自動で Azure にデプロイされ、構築手順の属人化がなくなります。
- ドリフトの定期監視：実環境とコードの差分を定期的に検出し、ポータルからの手動変更が入っていないかを確認します。
- 変更履歴の監査：Git の履歴から「いつ・誰が・何を変えたか」を遡れるため、インシデント調査や監査に対応できます。
play infra でできること
本記事の 5 つの手法は、Azure の標準機能だけでも進められますが、運用しながら継続していくには、リソースの「見える化」と「管理の仕組み化」が欠かせません。play infra は、Azure リソース管理 SaaS として、この 5 つの手法を日常の運用に落とし込むための機能を提供しています。
| 本記事の手法 | play infra でできること |
|---|---|
| 手法1：構造設計 | サブスクリプション・リソースグループ単位のリソース台帳と一覧 |
| 手法2：命名規則・タグ | タグ・命名規則の適用状況を一覧で確認、未設定リソースを検知 |
| 手法3：Azure Policy | ポリシー違反の一覧化とリスクの優先表示、是正状況の管理 |
| 手法4：RBAC | 権限・テナントの一元管理、監査に使える操作履歴 |
| 手法5：IaC | Bicep / Terraform の変更を Pull Request でレビュー、ドリフトの監視 |
たとえば、「タグが未設定のリソースを可視化して運用ルールを定着させたい」といった課題には、play infra のタグ確認やポリシー違反の表示機能を活用できます。リソースの所有者やコストセンターを台帳で確認できるため、手法2 や手法3 の定着を支えます。
各機能の詳細は機能一覧ページでご確認いただけます。まずは自社の Azure 環境で「どこから手をつければよいか」を把握するために、無料デモでリソースの可視化をご体験ください。
🥅 まとめ
Azure リソースのガバナンスは、後から整備するよりも、設計・構築の段階で仕組みとして組み込むことが効果的です。本記事でご紹介した 5 つの手法の要点は、以下の通りです。
- 構造設計で管理グループとサブスクリプションの境界を明確にする
- 命名規則・タグでリソースの一覧性とコスト配分の基盤を作る
- Azure Policy でルールを自動適用し、属人運用を防ぐ
- RBAC で最小権限の権限設計を行い、安全な運用を実現する
- IaC で構築を再現可能にし、レビューと監査を可能にする
これらをすべて一度に完璧に整える必要はありません。「構造設計と命名規則・タグ」から始め、Azure Policy と IaC で自動化・標準化していく段階的な進め方がお勧めです。
実際に、自社の Azure 環境でどこから着手すればよいか迷われている場合は、まず現状のリソースを可視化して、ガバナンスの課題を洗い出すことから始めるとよいでしょう。無料デモでは、Azure 環境の可視化やタグ・ポリシーの適用状況の確認をご体験いただけます。