Azure Monitorの公式リファレンス「Supported Resource log categories for Azure Monitor」が、2026年7月10日相当のタイミングで更新されました。結論からいうと、公開差分から確認できるのは、Azure Monitor全体の設定を一斉に変更する破壊的なアップデートではなく、リソースの種類、対応ログカテゴリ、メトリック、ログテーブルなどを整理した自動生成リファレンスの更新です。
ただし、Oracle.Database/exadbVmClustersなどの新規掲載リソースを利用している場合や、診断設定のログカテゴリをBicep、Terraform、ARMテンプレート、Azure Policyなどに固定している場合は確認が必要です。新しいカテゴリを収集できていない、反対にallLogsによって想定外のログまで収集される、といった影響が考えられます。
この記事では、2026年7月の公式差分から読み取れる変更内容、対象ユーザー、提供条件、導入前に確認すべきポイントを整理します。
Azure Monitorの「Supported Resource log categories」とは
「Supported Resource log categories for Azure Monitor」は、Azure Monitorで利用できるリソースログとメトリックを、リソースプロバイダー別に確認するための索引です。
Azureのリソースログには、リソース内部で実行された処理、処理結果、状態、エラーなどが記録されます。すべてのリソースログは共通の上位スキーマを持ちますが、具体的な項目はサービスやログカテゴリによって異なります。そのため、リソースタイプとログカテゴリの組み合わせによって、実質的なログスキーマが決まります。なお、リソースログは以前「診断ログ」と呼ばれていました。(Microsoft Learn)
公式ページでは、主に次の情報を確認できます。
- リソースプロバイダー
- 対応するリソースタイプ
- 利用可能なメトリック
- 利用可能なリソースログカテゴリ
- 出力先となるLog Analyticsテーブル
- Basic Logsプランへの対応
- 取り込み時変換への対応
- クエリ例
- ログのエクスポート費用の対象可否
重要なのは、公式ページに掲載されたことと、ログが自動収集されることは別だという点です。リソースログは既定では収集されず、対象リソースごとに診断設定を作成しなければなりません。(Microsoft Learn)
2026年7月10日相当の更新で何が変わったのか
公式ページの日付は7月9日、日本時間では7月10日
Microsoft Learnのページには、最終更新日として「2026年7月9日」と表示されています。一方、更新元となったGitHubコミットの日時は2026年7月9日11時32分44秒、タイムゾーンはUTC-4です。日本時間では2026年7月10日0時32分44秒に当たるため、日本語圏では7月10日相当の更新として整理できます。(Microsoft Learn)
ソース上の更新日は、前回の2026年6月19日から2026年7月9日に変更されました。また、コミット名には[AUTOGEN]と記載されており、公式ソースにも一覧の大部分が自動生成されていることが明記されています。(GitHub)
したがって、今回の更新は「Azure Monitorの新しい大型機能が一つ追加された」というより、複数サービスの監視リファレンスを最新状態へ同期した更新と捉えるのが適切です。
公開差分から確認できる主な変更
ログカテゴリの収集やクエリに直接関係する主な差分は、次のとおりです。
| 対象リソース | 確認できた変更 | 実務上の確認ポイント |
|---|---|---|
Oracle.Database/exadbVmClusters | メトリックとリソースログの参照が新規追加されました。ログはAddVm、Creation、Critical、Delete、Information、Maintenance、TerminateVm、Updateの8カテゴリです。生成リファレンス上では、8カテゴリともエクスポート費用の対象表示が「Yes」、Basic Logsと取り込み時変換は「No」、Log table欄は未記載です。(GitHub) | 診断設定へ追加するカテゴリ、出力先、ログ量、費用を確認します。専用テーブル名を推測してクエリを先に作らないことが重要です。 |
Microsoft.CognitiveServices/accounts | ManagedNetworkEventが追加されました。表示名は「Managed Network Events」で、出力テーブルはAzureDiagnostics、エクスポート費用の対象表示は「Yes」です。(GitHub) | Azure AIサービスやAzure OpenAI関連リソースで、管理ネットワークイベントを監視対象に含めるか判断します。 |
Microsoft.MachineLearningServices/workspaces | ManagedNetworkEventが追加されました。生成リファレンス上ではLog table欄が未記載で、Basic Logsと取り込み時変換は「No」、エクスポート費用の対象表示は「Yes」です。(GitHub) | Azure Machine Learningワークスペースのネットワーク監視要件と、既存のカテゴリ固定設定を確認します。 |
Microsoft.Quantum/providerAccounts | Operationalカテゴリが追加されました。表示名は「Operational Logs」で、Log table欄は未記載、Basic Logsと取り込み時変換は「No」、エクスポート費用の対象表示は「Yes」です。(GitHub) | 既存のAuditEventだけで十分か、運用ログも収集すべきかを判断します。 |
Microsoft.Orbital/geocatalogs | Auditカテゴリの生成リファレンスが変更されました。以前はOGOAuditLogsテーブル、Basic Logs対応「Yes」、取り込み時変換対応「Yes」でしたが、更新後はテーブル未記載、両機能とも「No」になっています。(GitHub) | 実際のサービス仕様変更か、参照メタデータの訂正かを区別するため、現物リソースとワークスペースで確認します。OGOAuditLogsを前提とするクエリやアラートは要点検です。 |
MICROSOFT.OPENENERGYPLATFORM/ENERGYSERVICES | 索引のメトリック欄がN/Aから対応ページへのリンクに変更されました。比較した範囲では、リソースログカテゴリ本体に実質的な追加はなく、メトリック参照の追加が中心です。(GitHub) | 新たに参照できるメトリックをアラートやダッシュボードに使う場合、診断設定でエクスポート可能かも個別に確認します。 |
Open Energy Platformのメトリックでは、たとえばDataVolumeは診断設定によるエクスポートが「No」、TotalHttpRequestsは「Yes」とされています。メトリックページが追加されたからといって、掲載されたすべてのメトリックをLog Analyticsへ転送できるわけではありません。(Microsoft Learn)
また、「Costs to export」が「Yes」であっても、あらゆる利用形態で必ず同額の追加料金が発生するという意味ではありません。公式ページは、Log Analytics、Storage、Event Hubsなどの取り込み・保存費用に加えて、一部カテゴリではエクスポート費用が発生する可能性があると説明しています。実際の費用は、出力先、ログ量、契約条件、最新の料金体系を基に確認する必要があります。(Microsoft Learn)
差分行数を新機能の数と解釈しない
今回のコミットでは39ファイルが変更され、数千行規模の追加・削除が記録されています。ただし、対象には索引、テーブル一覧、クエリ一覧、目次、自動生成ファイルの再出力なども含まれます。差分行数が大きいからといって、同じ数だけAzure Monitorの機能が追加されたわけではありません。(GitHub)
実務では、次の3点に絞って確認すると判断しやすくなります。
- 自社で利用中のリソースタイプが追加・変更対象か
- 利用可能なカテゴリ名やテーブル名が変わったか
- Basic Logs、取り込み時変換、エクスポート費用の表示が変わったか
対応が必要なユーザーと緊急度
| 利用状況 | 対応の緊急度 | 必要な対応 |
|---|---|---|
| 今回変更されたリソースタイプを利用している | 高 | 実リソースで利用可能なカテゴリを取得し、現在の診断設定と比較します。 |
| Bicep、Terraform、ARMテンプレートでカテゴリ名を固定している | 高 | 新規カテゴリを追加するか、意図的に除外するかを決めます。 |
| Azure Policyで診断設定を自動展開している | 高 | Policy定義やDeployIfNotExistsテンプレートのカテゴリ配列を確認します。 |
allLogsカテゴリグループを利用している | 中～高 | 新規カテゴリが自動的に収集対象へ入っていないか、ログ量と費用を確認します。 |
| Log Analyticsのクエリやアラートでテーブル名を固定している | 高 | 特にMicrosoft.Orbital/geocatalogsの監査ログ参照を確認します。 |
| 変更対象リソースを利用していない | 低 | 緊急変更は不要です。定期的な監視設定の棚卸しに組み込みます。 |
| Open Energy Platformを利用し、メトリックアラートを管理している | 中 | 新規掲載されたメトリックとエクスポート可否を確認します。 |
allLogsと個別カテゴリ指定ではリスクが逆になる
診断設定では、サービスが対応している場合、個別カテゴリの代わりにallLogsやauditといったカテゴリグループを利用できます。
カテゴリグループの構成が更新されると、ログ収集の対象も自動的に変更されます。ただし、すべてのAzureサービスがカテゴリグループに対応しているわけではありません。また、カテゴリグループと個別カテゴリを同じ診断設定内で併用することはできません。(Microsoft Learn)
実務上は、設定方法によって次のようにリスクが逆になります。
allLogsを利用している場合
新規カテゴリが自動的に追加され、監視範囲が広がる一方、ログ量や費用が増える可能性があります。- 個別カテゴリを指定している場合
既存費用は変わりにくい一方、新規カテゴリが自動追加されず、必要なイベントを収集できない可能性があります。
どちらが適切かは、コスト、セキュリティ、監査要件を基に判断します。単純にすべての環境をallLogsへ統一するのではなく、重要な本番環境では必要カテゴリを明示し、カテゴリ追加を定期検知する運用も有効です。
提供条件と導入前に押さえるべき仕組み
対応カテゴリが掲載されてもログは自動収集されない
プラットフォームメトリックとアクティビティログは、基本的にAzure側で自動収集されます。一方、リソースログは既定では収集されません。
Log Analytics、Storage、Event Hubsなどへ送るには、対象リソースごとに診断設定を作成する必要があります。1つの診断設定には、収集するカテゴリと送信先を指定します。(Microsoft Learn)
したがって、今回新しいログカテゴリが公式リファレンスへ追加されても、既存の個別カテゴリ指定へ自動的に追加されるわけではありません。
出力先ごとの用途を決める
| 出力先 | 主な用途 | 導入前の確認 |
|---|---|---|
| Log Analyticsワークスペース | KQLによる調査、Workbook、ログアラート、複数リソースの相関分析 | 格納テーブル、保持期間、取り込み量、クエリやアラートへの影響 |
| Azure Storage | 長期保管、監査証跡のアーカイブ、後日の静的分析 | リージョン、ファイアウォール、ライフサイクル管理 |
| Event Hubs | Microsoft Sentinel以外のSIEMや外部分析基盤への転送 | リージョン、認可規則、スループット、コンシューマー側の処理能力 |
| Azure Monitorパートナー連携 | 対応する監視・セキュリティ製品との統合 | 対応サービス、契約、データ転送費用 |
出力先リソースは診断設定より先に作成しておく必要があります。リージョンを持つ監視対象からStorageまたはEvent Hubsへ送信する場合は、原則として同じリージョンの出力先が必要です。
StorageやEvent Hubsで仮想ネットワークやファイアウォールを使用する場合は、信頼されたMicrosoftサービスからのアクセスを許可する必要があります。また、1リソースにつき作成できる診断設定は最大5件です。(Microsoft Learn)
Log Analyticsの格納モードを確認する
Log Analyticsに送られるリソースログには、次の2種類の格納モードがあります。
| モード | 格納方法 | 特徴 |
|---|---|---|
| Azure diagnostics | 複数サービスのログをAzureDiagnosticsへ格納 | 従来方式。ResourceTypeやCategoryによる絞り込みが必要 |
| Resource-specific | サービスやカテゴリごとの専用テーブルへ格納 | スキーマが分かりやすく、クエリ性能やテーブル単位のRBACに利点がある |
Microsoftは、選択できる新規診断設定ではResource-specificモードを指定することを推奨しています。ただし、今回追加されたカテゴリの中には、生成リファレンス上でLog table欄が空欄になっているものもあります。空欄の場合は専用テーブル名を推測せず、実際の診断設定と着信データで確認する必要があります。(Microsoft Learn)
既存の診断設定をAzure diagnosticsからResource-specificへ変更しても、過去データはAzureDiagnosticsに残ります。変更後のデータだけが専用テーブルへ送られるため、移行期間中はunionを利用するなど、両方のテーブルを検索できるようにクエリを修正します。(Microsoft Learn)
対応要否を判断する実務手順
対象リソースを棚卸しする
まず、今回の差分に含まれるリソースが、どのサブスクリプションに存在するか確認します。Azure Resource Graph Explorerでは、次のクエリを利用できます。
Resources
| where type in~ (
"oracle.database/exadbvmclusters",
"microsoft.cognitiveservices/accounts",
"microsoft.machinelearningservices/workspaces",
"microsoft.quantum/provideraccounts",
"microsoft.orbital/geocatalogs",
"microsoft.openenergyplatform/energyservices"
)
| project
subscriptionId,
resourceGroup,
type,
name,
location,
id
| order by type asc, name asc対象が0件であれば、今回の具体的なカテゴリ差分への緊急対応は基本的に不要です。ただし、今後対象サービスを導入する予定がある場合は、標準診断設定の設計へ反映します。
実リソースで利用可能なカテゴリを取得する
公式リファレンスは全体を把握するための索引です。最終的な設定前には、実在するリソースIDを指定して、現在利用できる診断設定カテゴリを取得します。
Azure CLIでは次のコマンドを使用します。
az monitor diagnostic-settings categories list \
--resource "<RESOURCE_ID>" \
--output table現在設定されている診断設定も取得します。
az monitor diagnostic-settings list \
--resource "<RESOURCE_ID>" \
--output jsoncAzure CLIのcategories listは、指定したリソースで利用可能な診断設定カテゴリを取得する正式なコマンドです。diagnostic-settings listでは、有効な診断設定の一覧を確認できます。(Microsoft Learn)
Azure PowerShellを使用する場合は、次のように確認します。
Get-AzDiagnosticSettingCategory -ResourceId "<RESOURCE_ID>"
Get-AzDiagnosticSetting -ResourceId "<RESOURCE_ID>"前者は対応カテゴリ、後者は現在有効な診断設定を取得します。(Microsoft Learn)
確認結果は、次の3つに分けて整理します。
- 利用可能だが収集していないカテゴリ
- 収集中だが現在の運用では不要なカテゴリ
- IaCテンプレートに記載されているが、実リソースでは利用できないカテゴリ
IaCと監視ルールを同時に確認する
カテゴリを追加する場合、Azureポータルだけを変更すると、次回のIaCデプロイで元に戻る可能性があります。
次の場所を検索してください。
- BicepまたはARMテンプレートの
logs配列 - Terraformの
enabled_logやカテゴリ指定 - Azure Policyの診断設定展開テンプレート
- CI/CDパイプライン内のAzure CLIまたはPowerShell
- Log Analyticsの保存済みクエリ
- Azure Monitorのログアラート
- Workbook
- Microsoft Sentinelの分析ルール
- 外部SIEM側のパーサーやフィールドマッピング
特に、OGOAuditLogsなどのテーブル名を直接指定しているクエリは、今回の生成リファレンスとの差異を確認する必要があります。ただし、ドキュメント上のテーブル記載が消えたことだけを理由に、本番クエリを直ちに削除してはいけません。実際にどのテーブルへデータが到着しているかを確認してから変更します。
まず代表リソースでログを検証する
診断設定を全リソースへ展開する前に、非本番環境または代表的な1リソースで検証します。
AzureDiagnosticsへ格納されるサービスでは、次のようなKQLで着信を確認できます。
AzureDiagnostics
| where TimeGenerated > ago(2h)
| where _ResourceId =~ "<RESOURCE_ID>"
| summarize Records = count()
by Category, bin(TimeGenerated, 15m)
| order by TimeGenerated descResource-specificモードの場合は、公式リファレンスまたは実際に作成された専用テーブルへ置き換えます。
<LOG_TABLE_NAME>
| where TimeGenerated > ago(2h)
| where _ResourceId =~ "<RESOURCE_ID>"
| summarize Records = count()
by bin(TimeGenerated, 15m)
| order by TimeGenerated desc診断設定を作成した後、データは通常90分以内に送信先へ流れ始めるとされています。24時間経過してもデータがない場合は、ログを生成する操作が行われていないか、ルーティングに問題がある可能性があります。(Microsoft Learn)
単に待つだけではなく、対象カテゴリに対応する安全なテスト操作を実行してください。たとえば、更新イベントのカテゴリを検証する場合は、影響の小さいタグや設定を変更し、イベント発生時刻を記録してログ到着を確認します。
運用前に注意したい失敗パターン
新しいカテゴリを無条件ですべて有効化する
診断設定では、必要なログカテゴリだけを収集することが推奨されています。診断設定自体には、選択したカテゴリ内のレコードを細かく絞り込む機能がありません。対応テーブルであれば取り込み時変換を利用できますが、今回追加されたカテゴリには取り込み時変換が「No」とされているものもあります。(Microsoft Learn)
新規カテゴリを有効にする前に、次の用途のどれに該当するかを決めます。
- セキュリティ監視に必要
- 障害調査に必要
- 監査やコンプライアンスに必要
- 運用分析に必要
- 保存義務はないが一時的に検証したい
- 現時点では利用目的がない
目的が説明できないカテゴリは、まず代表リソースでログ量を測定してから全体へ展開する方が安全です。
公式リファレンスの空欄を「機能なし」と断定する
自動生成リファレンスのLog table欄が空欄でも、直ちに「Log Analyticsへ送れない」「ログテーブルが存在しない」とは断定できません。
空欄には、専用テーブル情報が未登録、Azure diagnosticsモードを使用、段階的な公開途中、メタデータの同期前など、複数の可能性があります。実リソースのカテゴリAPI、診断設定画面、実際の着信テーブルを組み合わせて確認します。
メトリックとリソースログを混同する
プラットフォームメトリックは診断設定を作成しなくても、通常はAzure Monitorのメトリックエクスプローラーで利用できます。診断設定は、メトリックをLog Analyticsなどの別の出力先へ送る場合に使用します。
Open Energy Platformのようにメトリック参照が新規追加されたケースでは、次の2点を分けて判断します。
- メトリックエクスプローラーやメトリックアラートで利用するか
- 診断設定を使ってLog Analyticsなどへエクスポートするか
後者は、各メトリックのDS Exportが「Yes」かどうかを確認する必要があります。
リソースログを完全な取引記録として扱う
Azureのリソースログは、冗長化や再試行を備えたストアアンドフォワード方式ですが、トランザクション上の完全性を保証するものではありません。小規模な一時的データ欠損が発生する可能性があると公式に説明されています。(Microsoft Learn)
法令対応や厳密な監査証跡が必要な業務では、Azure Monitorのリソースログだけに依存せず、サービス固有の監査機能、業務アプリケーション側の記録、保存先の改ざん防止策などを組み合わせます。
削除したリソースの診断設定を放置する
リソースを削除、名前変更、別のリソースグループやサブスクリプションへ移動する場合は、不要になった診断設定も削除します。同じリソースIDに相当するリソースが再作成されると、古い診断設定が新しいリソースへ適用される可能性があります。(Microsoft Learn)
特に自動構築環境では、リソースの作成処理だけでなく、診断設定の削除処理もIaCへ含めることが重要です。
今回の更新に対する判断のまとめ
2026年7月10日相当の「Supported Resource log categories for Azure Monitor」更新は、公開差分を見る限り、自動生成された監視リファレンスの更新が中心です。そのため、すべてのAzure利用者が直ちに設定変更する必要はありません。
一方、次のいずれかに該当する場合は、早めの確認が必要です。
Oracle.Database/exadbVmClustersを利用している- Azure AIサービスまたはAzure Machine Learningで管理ネットワークイベントを監視したい
- Azure Quantumの運用ログが必要
Microsoft.Orbital/geocatalogsの監査ログやOGOAuditLogsを参照している- Open Energy Platformのメトリックをアラートや外部出力に利用したい
- 診断設定のカテゴリをIaCへ固定している
allLogsによるログ量や費用の増加を管理している
最初に行うべき作業は、全環境の診断設定を変更することではありません。Azure Resource Graphで対象リソースを洗い出し、az monitor diagnostic-settings categories listまたはGet-AzDiagnosticSettingCategoryで実際の対応カテゴリを取得し、現在の診断設定とIaCとの差分を確認してください。
そのうえで、監視目的、格納テーブル、エクスポート費用、ログ量、既存クエリへの影響を確認し、必要なカテゴリだけを段階的に有効化することが、安全かつ費用対効果の高い対応です。
コメント