Azure Monitor activity logは、Azureリソースに対する作成・更新・削除などの管理操作を確認するための基本ログです。今回の公式情報でまず押さえるべき結論は、Activity log自体の収集を有効化するための新しい設定作業は不要という点です。一方で、90日を超える監査保存、Log Analyticsへの転送、管理グループ単位のエクスポート、REST APIやCLIでの取得方法を運用している管理者は、設定やクエリの見直しが必要です。Microsoft Learnの公式ページはActivity logを「Azureリソースの管理操作を記録する機能」と説明し、仮想マシン作成、Key Vaultアクセスポリシー変更、Resource Managerデプロイエラーなどを例示しています。(Microsoft Learn)
Azure Monitor activity logとは何か
Azure Monitor activity logは、Azureサブスクリプション、リソースグループ、個別リソースなどに対するコントロールプレーン操作を記録するログです。たとえば、次のような操作を後から確認できます。
- 仮想マシンの作成、サイズ変更、削除
- リソースグループやサブスクリプション配下の構成変更
- Azure Resource Managerデプロイの失敗
- Key Vaultアクセスポリシーなど、管理設定の変更
- ポリシー割り当てや管理グループ配下の変更
重要なのは、Activity logは「アプリケーションの実行ログ」や「データアクセスログ」ではないことです。Azure Monitorでは、Activity logが管理操作を扱うのに対し、Azure resource logsはKey Vaultからシークレットを取得する、データベースへリクエストするなど、リソース内部で発生するデータプレーン操作を扱います。Resource logsは既定では収集されず、診断設定が必要です。(Microsoft Learn)
| ログの種類 | 主な対象 | 既定の収集 | 代表例 |
|---|---|---|---|
| Activity log | 管理操作、構成変更、デプロイ操作 | 収集される | VM作成、ポリシー変更、デプロイ失敗 |
| Resource logs | リソース内部の操作、データプレーン操作 | 設定が必要 | Key Vaultのシークレット取得、DBリクエスト |
| Metrics | 数値ベースの状態監視 | サービスにより異なる | CPU使用率、リクエスト数、可用性 |
実務では、Activity logを「誰が、いつ、どのAzureリソースに、どの管理操作を行ったか」を追うための監査ログとして扱うと分かりやすいです。
今回の公式情報で何が変わったのか
今回の更新は、Azure Monitor activity logの収集仕様が大きく変わったというより、Activity logの取得・確認・エクスポート方法をより実務向けに整理した更新と見るのが妥当です。GitHub上の更新履歴では、2026年5月4日から5日にかけて、REST APIの説明、取得シナリオ、クエリ制限、ポータル画面の補足、CLI・PowerShell例、リンク修正などが反映されています。(GitHub)
特に管理者や開発者が確認すべきポイントは次の4つです。
| 確認ポイント | 何が整理されたか | 実務上の影響 |
|---|---|---|
| Activity logの既定収集 | Activity log entriesは設定なしで収集されることが明確化 | 収集開始のための追加設定は不要。ただし長期保存には別設定が必要 |
| 取得スコープ | サブスクリプション、リソースグループ、個別リソース、テナント、管理グループ単位の取得方法を整理 | 監査や障害調査で、どの範囲を検索すべきか判断しやすくなる |
| REST APIの取得条件 | $filter、eventTimestamp、Preferヘッダーなどの説明を強化 | 自動収集スクリプトや監査ツールの見直しが必要 |
| エクスポート先 | Log Analytics、Event Hubs、Storageへの送信用途を整理 | 長期保存、SIEM連携、バックアップ用途ごとの設計を見直しやすくなる |
つまり、今回の更新を「Azure Monitor activity logの使い方を改めて標準化するタイミング」と捉えるとよいでしょう。既存環境でActivity logを見ているだけなら即時対応は少ない一方、監査・セキュリティ・自動化に使っている環境では確認すべき項目があります。
Activity logは設定なしで収集されるが、90日を超える保存には対策が必要
Azure Monitor activity logの大きな特徴は、Activity log entriesが既定で収集され、ユーザー側で収集設定を追加しなくても記録される点です。公式情報では、Activity log entriesはシステムによって生成され、変更や削除はできず、通常は作成・更新・削除などの変更操作やアクション開始によって発生すると説明されています。(Microsoft Learn)
ただし、ここで失敗しやすいのが「収集される」と「長期保存される」を混同することです。Activity logイベントは既定で90日保持され、その後削除されます。90日を超えて監査証跡を残したい場合は、診断設定を作成し、Log Analyticsワークスペース、Azure Event Hubs、Azure Storageなどへエクスポートする必要があります。(Microsoft Learn)
90日保持で足りるケース
90日以内の障害調査や、直近の構成変更確認だけであれば、AzureポータルのActivity logやCLIでの確認で足りる場合があります。たとえば、先週のデプロイ失敗、昨日のVM削除、直近のアクセス権変更を調べる用途です。
90日保持では足りないケース
次のような環境では、90日保持だけでは不十分です。
| 用途 | 推奨される保存先 | 理由 |
|---|---|---|
| 監査証跡を半年から数年残したい | Log AnalyticsまたはStorage | 90日を超える保持が必要 |
| SIEMや外部監視基盤に連携したい | Event Hubs | 外部システムへストリーミングしやすい |
| 年次監査や証跡保全を重視したい | Storage | 静的な保管、バックアップ用途に向く |
| KQLで他ログと相関分析したい | Log Analytics | AzureActivityテーブルでクエリできる |
特に「リソースを誰が作成したか」を後から調べたい場合は注意が必要です。公式情報では、リソース作成者情報はActivity logで確認できるものの、既定では90日しか保持されないため、長期的に保持したい場合はLog Analyticsなどへエクスポートする必要があると説明されています。(Microsoft Learn)
管理者が確認すべき設定
Azure管理者は、まずActivity logの「表示」ではなく「保存・転送・重複」を確認してください。ポータルで見えることと、監査に耐えられることは別問題です。
診断設定でActivity logをエクスポートしているか
Azureポータルでは、Azure MonitorメニューのActivity logからExport Activity Logsを選び、診断設定を作成できます。公式情報では、Activity log entriesを長期保存や追加機能のために他の宛先へ送るには診断設定を作成すると説明されています。(Microsoft Learn)
確認すべき観点は次の通りです。
| 確認項目 | 見るべき内容 | 判断基準 |
|---|---|---|
| エクスポート先 | Log Analytics、Event Hubs、Storageのどれか | 監査・分析・外部連携の目的に合っているか |
| 対象スコープ | サブスクリプション、管理グループ | 必要な範囲を漏れなく含んでいるか |
| 保持期間 | Log Analyticsの保持、Storageのライフサイクル | 社内規定や監査要件を満たすか |
| 既存設定 | 旧方式のlog profilesが残っていないか | 重複や運用混乱を避ける |
公式情報では、Activity logのレガシーなエクスポート方法としてlog profilesに触れ、Export Activity Logsから診断設定を使う場合はレガシー構成を無効化するよう案内しています。(Microsoft Learn)
Log Analyticsへ送っている場合はAzureActivityテーブルを確認する
Activity logをLog Analyticsワークスペースへ送信すると、データはAzureActivityテーブルに格納されます。Activity log insightsもこのAzureActivityテーブルを利用します。(Microsoft Learn)
基本的な確認には、次のKQLが使えます。
AzureActivity
| summarize Count = count() by CategoryValue
| order by Count desc管理操作だけを確認したい場合は、Administrativeカテゴリを絞り込みます。
AzureActivity
| where CategoryValue == "Administrative"
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, ResourceId, ActivityStatusValue
| order by TimeGenerated descここで注意したいのは、大文字・小文字の違いです。公式情報では、AzureActivityのフィールド値は同等の値でも大文字・小文字が異なる場合があるため、文字列比較では大文字小文字を区別しない演算子やtolower()の使用が推奨されています。(Microsoft Learn)
たとえば、運用スクリプトでは次のように書くと安全です。
AzureActivity
| where tolower(ActivityStatusValue) == "succeeded"または、大文字小文字を区別しない比較演算子を使います。
AzureActivity
| where ActivityStatusValue =~ "Succeeded"開発者が確認すべきAPI・CLI・PowerShellのポイント
開発者やSREがActivity logを自動取得している場合は、取得範囲、フィルター、タイムアウト、取得件数を見直してください。
REST APIでは$filterとeventTimestampが重要
Activity logをREST APIで取得する場合、$filterパラメーターに少なくともeventTimestampの開始値を含める必要があります。公式情報では、取得する期間の開始・終了が既定保持期間である90日以内に収まるようにする必要があると説明されています。(Microsoft Learn)
代表的なフィルターは次の通りです。
| 取得したい範囲 | $filterの考え方 |
|---|---|
| サブスクリプション全体 | eventTimestampで期間指定 |
| リソースグループ | resourceGroupNameを追加 |
| 個別リソース | resourceUriを追加 |
| 特定のリソースプロバイダー | resourceProviderを追加 |
| デプロイや操作単位の追跡 | correlationIdを追加 |
障害調査で特に便利なのはcorrelationIdです。デプロイ失敗や一連のAzure Resource Manager操作を追うとき、関連するイベントをまとめて確認できます。
CLIではサブスクリプションの指定漏れに注意する
Azure CLIでは、az monitor activity-log listでActivity logを取得できます。公式情報では、このコマンドは既定で現在のAzure CLIコンテキストに設定されているサブスクリプションからイベントを取得し、明示的に指定する場合は--subscriptionを使うと説明されています。(Microsoft Learn)
複数サブスクリプションを運用している組織では、ここが事故につながりやすいです。調査対象ではないサブスクリプションを見て「ログがない」と判断してしまうケースがあります。
az monitor activity-log list \
--subscription "00000000-0000-0000-0000-000000000000" \
--resource-group "myResourceGroup" \
--offset 30d \
--select "eventName operationName status eventTimestamp correlationId"実務では、調査用のスクリプトに--subscriptionを必ず含めることをおすすめします。特に本番・検証・開発サブスクリプションを切り替えて使うチームでは、CLIコンテキスト依存を避けるべきです。
PowerShellではSelect-ObjectだけでAPI応答量は減らない
PowerShellではGet-AzActivityLogを使ってActivity logを取得できます。ただし、公式情報ではSelect-ObjectはPowerShellの表示出力を絞るだけで、API応答サイズ自体を減らすものではないと説明されています。大量データを扱う場合は、-MaxRecordなどで取得件数を制限することが重要です。(Microsoft Learn)
$subscriptionId = '00000000-0000-0000-0000-000000000000'
Set-AzContext -Subscription $subscriptionId
$activityLogParams = @{
StartTime = (Get-Date).AddDays(-30)
EndTime = Get-Date
DetailedOutput = $true
MaxRecordCount = 100
}
Get-AzActivityLog @activityLogParams |
Select-Object EventName, OperationName, Status, EventTimestamp, CorrelationId, SubmissionTimestamp, Level調査では見やすい出力も大切ですが、定期実行ジョブではAPI負荷やタイムアウトも考慮してください。
スコープ別に見るActivity logの確認方法
Azure Monitor activity logは、どの階層で見るかによって取得できるイベントの範囲が変わります。今回の公式情報では、サブスクリプション、リソースグループ、テナント、管理グループといったアクセスシナリオが整理されています。(Microsoft Learn)
サブスクリプション単位
通常の運用調査では、まずサブスクリプション単位で確認します。仮想マシン、ストレージ、ネットワーク、Key Vaultなど、サブスクリプション配下の多くのリソース管理操作を横断的に確認できます。
向いている用途は次の通りです。
- 直近のデプロイ失敗を追う
- 誰がリソースを削除したか調べる
- 本番サブスクリプションで発生した構成変更を洗い出す
- 監査対象期間内の管理操作を抽出する
リソースグループ単位
特定システムやアプリケーション単位でAzureリソースを管理している場合は、リソースグループ単位の確認が便利です。
たとえば、rg-prod-webで発生した変更だけを確認すれば、他システムのログを除外できます。障害対応時には、時間範囲を障害発生前後に絞り、OperationやEvent initiated byでさらに絞り込むと原因に近づきやすくなります。
個別リソース単位
VM、App Service、Storage accountなど、問題のリソースが分かっている場合は、個別リソースのActivity logから確認するのが最短です。
たとえば、VMのサイズが意図せず変わった場合は、そのVMのActivity logを開き、変更時刻、操作名、実行者、ステータスを確認します。公式情報では、一部イベントについて、操作時刻の前後30分にリソースへ発生した変更をChange historyとして確認できると説明されています。(Microsoft Learn)
テナント・管理グループ単位
大規模環境では、管理グループやテナント単位のActivity logも重要です。公式情報では、テナントレベルのActivity logには管理グループやサブスクリプション作成などの重要イベントが含まれる場合があり、サブスクリプションレベルとは別のREST APIを使うと説明されています。また、管理グループレベルではポリシー割り当てや管理グループメンバーシップ変更など、その管理グループにスコープされたイベントを取得できます。(GitHub)
エンタープライズ環境では、次のような用途で活用できます。
- 管理グループ階層の変更監査
- Azure Policy割り当ての変更確認
- 新しいサブスクリプション作成の検知
- 全社横断のガバナンス監査
管理グループの診断設定は重複イベントに注意
管理グループ単位でActivity logをエクスポートする場合は、重複イベントに注意が必要です。公式情報では、管理グループに診断設定を作成すると、その管理グループと配下の管理グループのActivity logイベントがエクスポートされ、階層内の複数管理グループに診断設定がある場合は重複イベントを受け取ると説明されています。(Microsoft Learn)
さらに、サブスクリプション側と管理グループ側の両方に診断設定がある場合も、同じようなイベントが重複する可能性があります。公式情報では、欠落より重複の方が望ましい場合があるとしつつ、重複がある場合は全フィールドのハッシュを使って一意化するKQL例を示しています。(Microsoft Learn)
AzureActivity
| extend Hash = hash(dynamic_to_json(pack_all()))
| summarize arg_max(TimeGenerated, *) by Hash設計上は、次の判断基準で整理すると運用しやすくなります。
| 環境 | おすすめの考え方 |
|---|---|
| 小規模でサブスクリプション数が少ない | サブスクリプション単位で診断設定を管理 |
| 管理グループ階層で全社統制している | 最上位に近い管理グループで集約を検討 |
| SIEM連携を全社統一したい | Event Hubsへの出力を標準化 |
| 重複が許容できないレポート用途 | KQLやETLで重複排除ロジックを実装 |
ここでの失敗例は、管理グループとサブスクリプションの両方からLog Analyticsへ送信し、ダッシュボード上の件数が実際より多く見えることです。監査レポートを作る場合は、重複排除の有無を明記してください。
Activity log insightsを使うべき場面
Activity log insightsは、Azure Monitor workbookとしてActivity logを可視化する機能です。公式情報では、サブスクリプション内のリソースやリソースグループの変更、誰またはどのサービスが操作を実行したか、操作のステータスなどをダッシュボードで確認できると説明されています。利用するには、Activity logをLog Analyticsワークスペースへエクスポートし、AzureActivityテーブルへ送る必要があります。(Microsoft Learn)
Activity log insightsが向いているのは、次のような場面です。
- 管理操作の傾向を可視化したい
- どのユーザーやサービスプリンシパルが変更を多く行っているか見たい
- 失敗した操作や警告レベルのイベントを定期的に確認したい
- KQLに慣れていない運用担当者にも状況を共有したい
一方で、Activity log insightsだけに頼るのは避けましょう。監査証跡の抽出、外部SIEM連携、独自アラート、証跡保全には、Log Analytics、Event Hubs、Storageなどの設計が必要です。
アラート設計で見るべきActivity logイベント
Activity logは「見に行くログ」だけでなく、「検知するログ」として使うと価値が高まります。特に本番環境では、重大な管理操作をActivity log alertやLog Analyticsのログアラートで検知できるようにしておくべきです。
代表的な監視対象は次の通りです。
| 監視対象 | 検知したい理由 | 対応例 |
|---|---|---|
| リソース削除 | 誤削除や不正操作の早期発見 | 即時通知、変更承認との照合 |
| ロール割り当て変更 | 権限昇格や過剰権限の検知 | IAMレビュー、Privileged Identity Management確認 |
| Network Security Group変更 | 通信許可範囲の意図しない拡大防止 | 変更内容のレビュー |
| Key Vaultアクセスポリシー変更 | 機密情報アクセス経路の監査 | セキュリティ担当へ通知 |
| Azure Policy割り当て変更 | ガバナンス設定の無効化検知 | 管理グループ単位で監視 |
| デプロイ失敗 | リリース失敗や構成不整合の検知 | DevOpsチームへ通知 |
ポイントは、すべてのActivity logを通知しないことです。通知対象を広げすぎると、重要な通知が埋もれます。まずは削除、権限変更、ネットワーク変更、Key Vault関連、ポリシー変更のように、影響が大きい操作から始めるとよいでしょう。
移行・展開時に失敗しやすいポイント
Azure Monitor activity logの運用でよくある失敗は、技術的な設定ミスよりも「何を証跡として残すべきか」が決まっていないことです。展開前に次の点を確認してください。
監査要件より保持期間が短い
Activity logは既定で90日保持されますが、監査要件が半年、1年、数年であれば不足します。90日を超える保存が必要な場合は、診断設定でLog AnalyticsやStorageへ送る設計にしてください。
Resource logsと混同している
Activity logだけでは、リソース内部のデータアクセスまでは追えません。たとえば「Key Vaultのアクセスポリシーを誰が変更したか」はActivity logの対象ですが、「誰がシークレットを読み取ったか」はResource logs側の設計が必要です。
管理グループとサブスクリプションで重複している
管理グループ単位で集約しつつ、各サブスクリプションでも同じ宛先に送ると、Log AnalyticsやSIEM側で重複します。重複を許容するのか、KQLや取り込み側で排除するのかを先に決めてください。
スクリプトがCLIコンテキストに依存している
CLIで--subscriptionを指定していないスクリプトは、実行者や実行環境によって対象サブスクリプションが変わる可能性があります。定期実行や監査用スクリプトでは、サブスクリプションIDを明示してください。
大量CSVエクスポートで時間がかかる
公式情報では、大量のログエントリをCSVにエクスポートする場合は時間がかかる可能性があり、パフォーマンス改善のために時間範囲を短くすることが推奨されています。(Microsoft Learn)
一括で長期間を出力するより、1時間単位や1日単位に分割した方が、失敗時の再実行もしやすくなります。
実務で使える確認チェックリスト
Azure Monitor activity logの更新内容を受けて、管理者と開発者は次の順で確認すると効率的です。
| 優先度 | 確認内容 | 対象者 |
|---|---|---|
| 高 | Activity logの保持要件が90日以内か、超えるかを確認する | 管理者、監査担当 |
| 高 | 診断設定でLog Analytics、Event Hubs、Storageへ送っているか確認する | 管理者 |
| 高 | 旧方式のlog profilesや重複する診断設定が残っていないか確認する | 管理者 |
| 高 | 重要操作のActivity log alertを設定しているか確認する | 管理者、セキュリティ担当 |
| 中 | CLI、PowerShell、REST APIスクリプトでサブスクリプションや期間指定が明示されているか確認する | 開発者、SRE |
| 中 | AzureActivityのKQLで大文字小文字を考慮しているか確認する | 開発者、運用担当 |
| 中 | 管理グループ単位のエクスポートで重複イベントをどう扱うか決める | 管理者、アーキテクト |
| 低 | CSVエクスポートを長期間一括で実行していないか確認する | 運用担当 |
まず取るべき次のアクション
Azure Monitor activity logの今回の更新では、収集機能そのものを有効化するための新しい移行作業よりも、監査・保存・取得・可視化の設計を見直すことが重要です。
まずは、Azureポータルで対象サブスクリプションのActivity logを開き、直近の管理操作が確認できるかを見てください。次に、90日を超える保存が必要かを判断し、必要であれば診断設定でLog Analytics、Event Hubs、Storageのいずれかへエクスポートします。すでにエクスポートしている環境では、管理グループとサブスクリプションの重複、旧方式のlog profiles、KQLの大文字小文字比較、CLIやREST APIのスコープ指定を確認しましょう。
Activity logは、障害発生後に慌てて見るものではなく、平常時から「どの操作を、どこに、どれだけ残すか」を決めておくべき監査基盤です。今回の公式情報をきっかけに、Azure Monitor activity logを単なる履歴確認ではなく、セキュリティ監査と運用改善の中核として整備しておくことをおすすめします。
コメント