Azure Resource Graph

解決する課題

数百のサブスクリプションに散らばるリソースを、ポータルで1つずつ開いて確認するのは現実的ではありません。Azure Resource Graph は、テナント全体のリソースを横断して高速に照会できる読み取り専用の基盤を提供します。

• 全サブスクリプション・全リージョンにまたがるリソースを一括で棚卸ししたい
• 「パブリック IP を持つ VM」「特定タグが欠けたリソース」など条件付きの構成調査をしたい
• 監査やコスト最適化のために特定 SKU や種別のリソースを横断集計したい
• ポリシーの非準拠リソースを一覧で抽出してレポート化したい
• 大量リソースに対してポータルの一覧よりも速くフィルタ・集計したい

主要概念と用語

Azure Resource Graph は「リソースのメタデータを集約したインデックス」を「KQL で照会する」サービスとして理解すると整理しやすいです。

• Resource Graph: Azure Resource Manager（ARM）が管理するリソースのプロパティを集約し、横断クエリ向けに最適化したインデックス。リソースそのものではなく、その構成情報のコピーを照会する
• KQL（Kusto Query Language）: クエリに用いる言語。Azure Monitor / Log Analytics と同系統で、where・project・summarize・join などの演算子を使う
• テーブル: 照会対象の論理的なまとまり。代表的なものに resources（リソース全般）、resourcecontainers（サブスクリプションや管理グループ）、policyresources（ポリシー準拠状態）、securityresources（セキュリティ関連）などがある
• スコープ: クエリを実行する範囲。管理グループ・サブスクリプション単位に絞り込める。指定しない場合はアクセス可能な範囲が対象になる
• type / kind / properties: 各リソースの種別やプロバイダー固有の構成は properties フィールドに JSON として格納され、ドット記法で参照できる
• RBAC 連動: クエリ結果は呼び出し元が読み取り権限を持つリソースだけに限定される。権限のないリソースは結果に現れない

仕様・制限・クォータ

• 読み取り専用である。リソースの作成・変更はできず、あくまで構成情報の照会に特化する
• 結果はインデックス由来のため、リソースの作成・変更が反映されるまでわずかな遅延が生じることがある。リアルタイムの厳密な整合性が必要な操作には向かない
• 1回のクエリで返せる件数には上限があり、大量結果はページング（スキップトークン）で分割取得する。具体的な上限値は公式ドキュメントを確認する
• 対応する KQL 演算子は Log Analytics のサブセットであり、すべての演算子が使えるわけではない。利用可能な演算子は公式の一覧で確認する
• 集約・結合にも制約がある。join の種類や summarize の規模には実用上の限界があるため、巨大な結合は分割して設計する
• 照会できるのは ARM 管理下のリソースのメタデータであり、リソース内部のデータ（BLOB の中身や DB のレコードなど）は対象外

内部の仕組み

Azure Resource Graph は、ARM が受け取るリソースの状態変化を継続的に取り込み、横断クエリ向けに最適化したインデックスへ反映する仕組みで動作します。

• インデックス更新: リソースが作成・更新・削除されると、その変化が Resource Graph のインデックスに伝播し、照会可能な状態に保たれる
• クエリエンジン: ユーザーが投げた KQL を、集約済みインデックス上で評価して結果を返す。リソース本体へ都度問い合わせないため、横断検索でも高速に応答する
• 権限フィルタ: クエリ実行時に呼び出し元の RBAC を評価し、読み取り権限のあるリソースだけを結果に含める。スコープ指定と RBAC の積集合が実効範囲になる
• ポータルとの関係: Azure ポータルの「すべてのリソース」一覧や検索の裏側でも Resource Graph が使われており、大量リソースの一覧表示を支えている

ポータル操作・ポリシー準拠ダッシュボード・各種ガバナンスツールが共通の照会基盤として Resource Graph を利用するため、同じ視点でリソースを横断的に扱えます。

設計パターン / ベストプラクティス

• 絞り込みを先に書く。where で type やスコープを早めに限定してから project で必要列だけ取り出すと、結果が見やすく転送量も減る
• 必要な列だけ project する。properties 全体を返すと結果が巨大になりやすいので、使うフィールドだけ取り出す
• 集計は summarize で行う。type 別・リージョン別・サブスクリプション別の件数集計は summarize count() by ... で一気に把握する
• 大量結果はページングを前提に設計する。CLI やスクリプトで全件取得するときはスキップトークンでループする
• タグやガバナンス調査の定番クエリを共有資産化する。よく使う棚卸しクエリは保存し、チームで再利用する
• 管理グループ スコープで全社横断。テナント全体を見るときは最上位の管理グループをスコープに指定して継承配下をまとめて照会する

運用・監視

• 定期的な構成棚卸しに組み込む。タグ欠落・許可外リージョン・想定外 SKU などを定型クエリで定点観測する
• ポリシー非準拠の抽出に使う。policyresources 系の照会で非準拠リソースを一覧化し、修復の優先順位付けに使う
• コスト最適化の調査材料にする。停止済み VM・未アタッチのディスク・古い SKU などを洗い出し、棚卸し結果を削減検討に回す
• 遅延を前提に運用する。変更直後の即時反映を期待せず、横断調査の用途に絞る
• アクセス権限の差を理解する。実行者の RBAC によって見える範囲が変わるため、棚卸しは十分な読み取り権限を持つ主体で行う

コスト

Azure Resource Graph の照会機能は、基本的に追加料金のかからないプラットフォーム機能として提供されます。ポータルやガバナンスツールの裏側で使われる横断検索基盤であり、クエリ自体に対する従量課金を意識する場面は通常ありません。ただし、過度に頻繁・大量のクエリにはスロットリング（要求のレート制限）がかかり得るため、自動化ではページングと適切な間隔を前提に設計します。コストは Resource Graph 単体よりも、ここで見つけた無駄なリソースをどれだけ削減できるか、という最適化の入口として捉えると価値を出しやすいです。

セキュリティ

• 読み取り専用で攻撃面が小さい。リソースを変更する経路を持たないため、構成情報の閲覧に用途が限定される
• RBAC で結果が自動的に絞られる。呼び出し元が読み取れないリソースは結果に現れず、最小権限がそのまま可視範囲になる
• 棚卸しでセキュリティ逸脱を発見する。パブリック公開・暗号化なし・古い構成などを横断クエリで洗い出し、是正の起点にする
• メタデータのみを扱う。リソース内部のデータには触れないため、機微データそのものが照会対象になることはない

関連サービス・比較

Azure Resource Graph は「リソース構成の横断照会」を担い、リソース操作の制御プレーンである ARM や、ルールを強制する Azure Policy と組み合わせて使います。Policy の準拠ダッシュボードの裏側でも Resource Graph が照会に使われています。

ハンズオン / CLI例

# 拡張機能を有効化（初回のみ）
az extension add --name resource-graph

# 種別ごとのリソース数を集計する
az graph query -q "resources | summarize count() by type | order by count_ desc"

# パブリック IP を持つ VM を抽出する（プロパティをドット記法でたどる）
az graph query -q "resources \
  | where type =~ 'microsoft.compute/virtualmachines' \
  | project name, location, resourceGroup, vmSize = properties.hardwareProfile.vmSize"

# 特定タグ（owner）が付いていないリソースを洗い出す
az graph query -q "resources \
  | where isnull(tags.owner) \
  | project name, type, resourceGroup, subscriptionId"

# 管理グループ スコープで全社横断クエリを実行する
az graph query \
  -q "resources | summarize count() by subscriptionId" \
  --management-groups "<MANAGEMENT_GROUP_ID>"