ログ関連調査：Azure・Microsoft 365・Microsoft Power Platform

Microsoft Azure（以下、Azure）、Microsoft 365（以下、M365）、Microsoft Power Platform（以下、Power Platform）にあるログと関連情報を、管理・運用と監査の目的に分けて整理した調査資料です。ログの種類、有効化・取得・転送、保存先、標準の閲覧・アラート、他サービスとの組み合わせを扱います。

共通のIDサービスであるMicrosoft Entra ID、関連するMicrosoft Purview、Microsoft Defender、Microsoft Sentinel、Microsoft Fabricも対象に含めます。

調査日：2026年10月29日（日本時間）。Microsoftの公式資料82件を参照し、ログと関連情報を65区分に整理しました。文献調査のみで、テナントへの接続、設定変更、取得・遅延・完全性の実測、費用試算は実施していません。検索結果で確認した資料は参考資料に注記しています。

Azureの全リソースプロバイダーの全イベントや、全SKU・全地域の差を列挙した資料ではありません。主要な系列と取得方式を整理し、公式のカテゴリ一覧を追加調査の入口にしています。

目次

  1. 調査結果の要点
  2. 分類と用語
  3. Azureのログ
  4. 共通IDのログ
  5. Microsoft 365のログ
  6. Power Platformのログ
  7. 取得・転送方式
  8. 標準の閲覧・アラート
  9. 保持・権限・費用
  10. 他サービスとの組み合わせ
  11. 管理・運用と監査の設計
  12. 追加検証と資料の説明差
  13. 参考資料

1. 調査結果の要点

ログは製品名で分類するだけでは、取得と利用の違いを説明できません。この調査では、各ログを「記録する出来事 → 有効化する設定 → 収集・転送 → 保存 → 検索・可視化 → 検知・対応」の流れに沿って整理します。

確認できた主な違いは次のとおりです。

論点 調査で分かったこと 利用時に区別すること
Azureの管理操作とデータ操作 Activity logは主に管理操作を記録します。データ操作はサービス別のリソースログや監査機能が担当します。Activity logは通常、読み取り操作を記録しません。[1][6] 「リソースが作成された」と「保存されたデータが読まれた」を分けます。
自動生成と利用者側への保存 Activity logの標準保存、診断設定による転送、OS内のエージェント、アプリの計装は別の経路です。[1][2][3][5] ポータルにリソースがあることから、必要なログが保存済みだとは判断できません。
M365の監査と運用 統合監査ログのほかに、メール配送、通話品質、サービス正常性、利用集計、セキュリティ製品のテレメトリがあります。[22][29][30][33][34][36] Purviewの検索だけで障害調査を完結させようとしない構成にします。
Entra IDとPurviewの保持 Entra IDの監査・サインインログとM365の統合監査ログは別の保持体系です。[20][23] 同じ利用者の操作でも、画面や保存先で参照可能期間が異なります。
Dataverseの変更監査と操作監査 行・列の変更履歴はDataverse監査、読み取り・エクスポートなどの活動はPurviewへ送る活動ログで扱います。Purviewの活動ログへ列の変更前後値は送られません。[39][40] 「誰が値を変えたか」と「誰がデータを参照したか」を別々に調べます。
Power Automateの監査と実行 PurviewのPower Automate監査はフローのライフサイクル・権限操作です。実行・失敗・アクションの詳細は別の履歴やApplication Insightsを使います。[42][51][52] フローの編集履歴を、実行証跡の代わりにしません。
標準機能と費用 製品標準の画面・連携機能にもライセンスや従量費用の条件があります。[21][23][47][52][59][67] 「追加開発不要」と「追加費用なし」を分けて説明します。

2. 分類と用語

2.1 管理・運用と監査

この資料では、管理・運用を「サービスを安定して提供し、障害・性能・容量・処理失敗を調べる目的」、監査を「誰が、いつ、何に、どの操作を行ったかを追い、後から説明する目的」と定義します。セキュリティ監視は、これらの記録に検知ルールや相関分析を適用する用途として扱います。

管理者の操作を記録したログは、監査にも障害調査にも使えます。ログの名称に「管理」「監査」が含まれるかだけで用途を固定しません。以下の表では「運用」「監査」「両方」で主な用途を示します。

記録の種類 主な問い 例
管理操作の記録 誰が設定・権限・リソースを変更したか Activity log、Entra監査、Power Platform管理活動
データアクセス・変更の記録 誰がデータを読み、変更し、持ち出したか Storageの要求、SQL監査、SharePoint活動、Dataverse監査
実行・診断の記録 どの処理が、どこで、なぜ失敗・遅延したか OSイベント、アプリログ、分散トレース、フロー実行履歴
性能・利用の集計 どの程度利用され、性能・容量がどう変化したか メトリック、利用レポート、容量分析
検知・評価の結果 どの規則に該当し、どの程度のリスクがあるか セキュリティアラート、インシデント、リスク検出、推奨事項

この表は編集上の分類です。メトリック、集計レポート、アラートは関連情報として調査対象に含めますが、個々の操作を残す生ログと同一視しません。

2.2 役割の異なる名称

Azure Monitorは監視サービス群、Azure Monitor Logsはログの収集・分析機能、Log Analytics workspaceはログテーブルの保存先、Log Analyticsはその照会に使う操作環境です。Application Insightsはアプリケーション監視の機能です。[62]

Kusto Query Language（以下、KQL）は、Azure Monitor Logs、Azure Data Explorer、FabricのKQL Database、Defenderの高度な追及などで使われます。ただし、テーブル名、保持、権限、対応するクエリは接続先に依存します。KQLを使えることだけで、すべてのログを同じ場所から検索できるわけではありません。[36][62][74][75]

3. Azureのログ

3.1 管理・OS・アプリ・ネットワーク

「標準の入口」は、最初に使える製品機能を示します。事前設定が必要なものや、保存先の費用がかかるものも含みます。表の保持欄を省略したログは一律の標準日数を確認した意味ではなく、第9節の条件確認が必要です。

ID ログ・関連情報／主用途 記録する内容 取得条件・経路 標準の入口・主な拡張 根拠
A01 Activity log／両方 リソースの作成・更新・削除、デプロイ失敗などの管理操作 自動収集。90日保持。診断設定で外部保存先へ転送 Azure portalのActivity log、CLI、PowerShell、REST。活動ログアラート、Log Analytics、Storage、Event Hubsへ拡張 [1][2]
A02 リソースログ／両方 データ要求、認証・認可結果、処理、サービス内部の診断イベント リソースごとにカテゴリと保存先を選ぶ診断設定。対応範囲限定でDCR方式もプレビュー Logs、サービス別Insights。サービス固有テーブルまたはAzureDiagnosticsなどを確認 [2][6][76]
A03 VMのWindowsイベント・Linux Syslog／両方 OS、サービス、アプリ、セキュリティイベント Azure Monitor Agentとデータ収集ルール（DCR）を設定。非AzureサーバーはAzure Arcなどの前提を確認 Log Analytics、VM insights、Sentinel。Securityイベントは収集方式と保存テーブルを区別 [3][4]
A04 VM内のテキスト・独自ログ／運用 業務アプリの任意メッセージ、独自形式のイベント エージェントの対応収集、または送信プログラム＋Logs Ingestion API。スキーマ・送信権限が必要 カスタムテーブル、KQL、ログ検索アラート [3][5]
A05 アプリの要求・依存関係・例外・トレース／運用 リクエストの成否、時間、サービス間の呼び出し Application Insightsの計装・対応する自動計装、OpenTelemetryなど。収集量・サンプリングを設定 Failures、Performance、トランザクション調査、Smart detection、KQL [8][13][62]
A06 AKSの制御プレーン・監査／両方 APIサーバー、コントローラー、kube-auditなど 制御プレーンのカテゴリを選択。クラスター・プランの監視既定値と診断設定を確認 AKSの監視、Log Analytics。制御操作とコンテナ内ログを別に収集 [7]
A07 AKSのコンテナ・ノードログ／運用 コンテナ標準出力・標準エラー、イベント、状態 Container insights等の収集構成。フィルターとDCRを確認 コンテナ調査、ContainerLogV2など。Prometheusのメトリックは別経路 [7][4]
A08 仮想ネットワークフローログ／両方 IPフロー、通信方向、ポートなど Network Watcherで有効化しAzure Storageへ保存。通常のリソース診断設定とは別の設定 保存JSON、Traffic analytics、外部分析 [17]
A09 Firewall・WAF・ゲートウェイ等のリソースログ／両方 許可・拒否、ルール該当、接続・要求情報 製品ごとのカテゴリと診断設定。ログ内容・本文の有無はサービス別 Log Analytics、Insights、Sentinel、外部SIEM。対象カテゴリは公式一覧から調査 [6]
A10 Azure Resource Graphの変更情報／両方 Resource Managerプロパティの変更、変更主体など Resource Graphのresourcechangesを照会 変更差分の調査。Activity logと合わせて変更内容を追う [77]
A11 Defender for Cloudのアラート・推奨事項／セキュリティ監視 脅威検出、セキュリティ構成の評価結果 Defenderの機能・対象プランを有効化。継続エクスポートを別途設定 Defender画面、Log Analytics、Event Hubs。生の要求ログとは別 [78]

Azure Monitor AgentはOS内の記録を取得します。VMの作成やサイズ変更はActivity log、OSへのログオンなどはOS内のイベント、アプリの例外はアプリ側の計装が担当します。VMを一台監視する場合でも、これらの設定は別々に確認します。[1][3][8]

3.2 データ・Web・処理サービス

ID 対象／主用途 調べるログ 有効化・保存の特徴 標準利用と拡張 根拠
A12 Azure Key Vault／監査・運用 キー・シークレット等への操作、結果、アクセス主体 Key Vaultの監査カテゴリを診断設定で転送。管理操作ログと分ける 誰が取得を要求したかの調査、拒否・失敗の監視 [9][2]
A13 Azure Storage／両方 Blob等への読み取り・書き込み・削除、要求結果 Blobなど対象サービスの診断設定を確認。ストレージアカウントの管理操作とは別 Storage insights、Log Analytics。Blob、Files、Queue、Tableの対象を別々に確認 [11][6]
A14 Azure SQL Database／監査 接続・SQL操作など、選択したDBイベント SQL監査ポリシーを有効化。Storage、Log Analytics、Event Hubsへ保存 監査検索・分析。DB性能調査用ログと監査対象を混同しない [10]
A15 Azure Cosmos DB／両方 データプレーン要求、クエリや性能に関連する診断 診断設定でAPI・カテゴリを選択。サービス固有テーブル方式の推奨を確認 要求・スロットリング・処理の分析。API別の差を残す [16]
A16 Azure App Service／運用 アプリログ、Webサーバーログ、詳細エラー、失敗要求トレース等 OS・プランごとに対応が違う。ファイルやBlobへの保存とAzure Monitor送信を区別 Log stream、診断機能、ダウンロード、Log Analytics、Application Insights [12]
A17 Azure Functions／運用 関数実行、要求、依存関係、例外 Application Insightsとの組み込み連携、送信方式・ログレベル・収集設定を確認 実行調査、失敗・遅延の分析。アプリ全体のリソース監視とも分ける [13]
A18 Azure Logic Apps／運用 トリガー・実行・アクションの結果と診断 実行履歴と診断設定による転送。Consumption／Standardの差を確認 実行履歴、Log Analytics、Storage、Event Hubs等。入力・出力の秘匿設定も検証対象 [14]
A19 Azure API Management／両方 API要求、ゲートウェイ処理、成否・性能 診断設定、Application Insights連携などを用途別に設定 組み込み分析、メトリック、アラート、Logs。本文・ヘッダーの収集範囲を確認 [15]
A20 その他のPaaS／両方 Service Bus、Event Hubs、Data Factory、Backup、Container Apps、AI関連サービス等のカテゴリ 公式カテゴリ一覧でリソース型→カテゴリ→保存テーブル→対応プランをたどる 個別の調査の対象に採用した時点で詳細調査。全カテゴリの意味は今回未精査 [6]

Azure SQL Databaseの監査を、診断設定の追加だけで有効になる機能として説明しないようにします。サービス側の監査対象設定と、ログの転送・保存設定の関係を個別に示す必要があります。[10]

NSGフローログは新規作成が停止しており、2027年9月30日の廃止が案内されています。新規構成では仮想ネットワークフローログを中心にし、NSGフローログは移行の説明として扱います。[18]

4. 共通IDのログ

Microsoft Entra IDはAzure、M365、Power Platformにまたがるため、製品別の説明と分けて整理します。サインイン成功は、個々のデータへのアクセス成功や、後続処理の完了を意味しません。

ID ログ／主用途 記録する内容 取得・閲覧 主な条件・拡張 根拠
I01 監査ログ／両方 利用者、グループ、アプリ、ライセンス等の変更 Entra管理センター、Microsoft Graph。診断設定で転送 Freeは7日、P1/P2は30日が基本。M365統合監査とは別 [19][20]
I02 利用者のサインイン／両方 対話・非対話の認証、結果、認証関連情報 Entra管理センター、対応API、診断設定 対話・非対話を区別。ライセンスで閲覧・取得条件が変わる [19][20][72]
I03 サービスプリンシパル・マネージドIDのサインイン／両方 アプリや自動処理の認証 各サインインログのカテゴリを指定 人のサインインと分離。アプリIDと実行主体を照合 [19]
I04 プロビジョニングログ／運用・監査 アカウント同期・作成・更新の処理結果 Entra管理センター、対応API、診断設定 サインインとは別工程。対象アプリへの反映失敗を追う [19]
I05 ID Protectionのリスク情報／セキュリティ監視 危険なサインイン、利用者・ワークロードIDのリスク リスク画面・対象ログ・対応API P2やWorkload ID Premiumなど、対象機能ごとの条件を確認 [19][20][72]
I06 Microsoft Graph activity logs／両方 Microsoft Graphが処理したHTTP要求の監査証跡 明示的に診断設定を有効化し、Log Analytics等へ送る P1/P2とAzureの保存先が必要。既定のEntra保持に依存して検索するログではない [20][21]
I07 Global Secure Access関連／両方 ネットワークアクセス、正常性、M365の拡充ログ等 対応製品の利用・設定後に診断カテゴリを指定 該当サービスを利用していなければ、カテゴリ選択だけでデータは増えない [19]

Microsoft Graph activity logsはGraphへの要求を記録するもので、すべてのM365データアクセス経路を一括して保証するものとしては扱いません。Purview側の操作イベント、Entraのトークン取得、サービス側の処理結果を照合するための別の記録です。[21]

PIM、条件付きアクセス、認証方法の変更などは、まずEntra監査とサインインのどのイベント・プロパティに残るかを調べます。専用画面の履歴と外部転送できるカテゴリの差は、実機検証で追加確認する事項です。

5. Microsoft 365のログ

5.1 監査系

ID 対象／主用途 主な記録 取得・保存 標準利用と拡張 根拠
M01 Purviewの統合監査ログ／監査 複数サービスの利用者・管理者・システムの操作 サービスから監査基盤へ集約。テナントの監査状態、対象操作、ライセンスを確認 Purview Audit検索、CSV、PowerShell、Graphの監査検索API、Management Activity API [22][24][27][28]
M02 Exchange Onlineの管理操作／監査 設定、権限、管理コマンドなど 対応するExchange管理イベントが統合監査へ Purviewで主体・操作・時間を検索。メール配送とは別 [25]
M03 Exchange Onlineのメールボックス操作／監査 所有者・代理人・管理者による対象操作 メールボックス監査は組織で既定有効。対象アクション、例外、ライセンスを確認 メールボックスの監査イベントを検索。全メール閲覧が同じ粒度で残ると断定しない [26]
M04 SharePoint Online・OneDrive／監査 ファイル参照・ダウンロード・共有・削除、設定変更等 対応操作が統合監査へ。操作名・生成条件は個別仕様 持ち出し・外部共有調査、アラートポリシー、SIEM連携 [25][37]
M05 Microsoft Teams／監査 チーム・チャネル・メンバー・会議等の対象操作 Teamsの監査イベント。関連ファイルの操作はSharePoint等にも分かれる Purview検索。通話品質の記録と分けて照合 [25][31]
M06 Purview・情報保護・その他のM365サービス／監査 ラベル、DLP、調査・管理機能、Forms、Planner等の対象操作 Auditの対応サービス・RecordTypeから選定 製品ごとの記録とポリシー該当を検索。対象イベントを公式一覧から追加 [25][80]
M07 Microsoft 365 Copilot／監査 利用者のCopilot操作、参照リソース等のメタデータ CopilotInteractionなど、製品の監査スキーマに従う 誰がどのアプリで使い、何を参照したかを調査。会話本文の保全・検索要件は別に確認 [79]

統合監査は「全サービスのすべての処理の完全な複製」ではありません。対象サービス、RecordType、Operation、生成条件、既定監査設定を調べて、必要な操作が含まれるかを確認します。管理画面の選択肢と、APIやPowerShellで指定できる操作にも差があります。[25][80]

5.2 管理・運用系と関連テレメトリ

ID 対象／主用途 主な記録・情報 標準の入口 取得・拡張の特徴 根拠
M08 Exchange Onlineのメッセージ追跡／運用 受信、配送、拒否、保留等のメール配送経路 Exchange管理センターのMessage trace、対応PowerShell 過去90日までが対象。要求期間・結果形式・生成待ちの条件がある。Purview保持とは別 [29]
M09 Teamsの会議・通話診断／運用 利用者ごとの接続・端末・ネットワーク・品質 Teams管理センターの現行トラブルシューティング画面 詳細閲覧のロール、機能・ライセンスを確認。会議中と終了後の機能を分ける [31]
M10 TeamsのCall Quality Dashboard／運用 組織全体の通話・会議品質の傾向 Call Quality Dashboard（CQD） 拠点・端末情報を加えて品質傾向を分析。個別監査イベントの代わりにはしない [30]
M11 TeamsのcallRecords API／運用 通話・会議終了後の使用・診断情報 Microsoft Graph 記録は30日保持。変更通知・一覧・ID照会等で取り出す。録音・会話内容とは別 [32]
M12 M365利用レポート／管理 利用者数、操作数、サービス利用の集計 M365管理センター、Microsoft Graph reports 利用傾向の分析向け。集計値から個々の操作順序は復元できない。匿名化設定も確認 [33]
M13 サービス正常性・Message center／運用 Microsoft側の障害・復旧情報と変更告知 M365管理センター、Graph service communications API テナントに関係する情報を定期取得し、社内通知・障害時系列と照合 [34]
M14 Microsoft Intune／両方 管理操作監査、登録・準拠関連の運用情報、端末情報 Intune管理センター Intuneの診断設定からLog Analytics、Storage、Event Hubsへ送信可能。M365全体の一般則にはしない [35]
M15 Microsoft Defender XDR／セキュリティ監視 端末・メール・ID・クラウドアプリ等のテレメトリ、アラート・インシデント Defender portal、高度な追及、カスタム検出 元製品の導入・ライセンス・オンボードが必要。生のDefenderデータは高度な追及で基本30日 [36]

SaaSの障害調査では、利用者に見える処理とMicrosoft側の内部ログの境界も説明対象です。利用者が取得できるサービスログ、管理API、クライアント側の診断と、サポート調査が必要な範囲を個別の調査で区切ります。

6. Power Platformのログ

6.1 監査・ガバナンス系

ID 対象／主用途 主な記録 有効化・保存の特徴 標準利用と拡張 根拠
P01 Power Platform管理活動／監査 環境の作成・削除・バックアップ・復元、設定、データポリシー、管理操作 管理活動の収集はテナントで既定有効。閲覧にはPurview側の権限等が必要 Purview、Management Activity API。製品別の利用者活動設定と分ける [41]
P02 Power Apps活動／監査 アプリの作成・変更・起動・公開・権限変更・削除等の対応操作 PurviewのPower Apps活動。対象操作と環境・ライセンス条件を確認 Purview検索、監査API。画面内の全操作を記録する診断とは別 [81]
P03 Power Automate活動／監査 フロー作成・編集・削除、権限変更、試用ライセンス等 PurviewのPower Automate活動 実行・アクション・実行時コネクタ呼び出しはこの監査に含まれない [42]
P04 コネクタ・接続・ゲートウェイ活動／監査 カスタムAPI、接続、権限、ゲートウェイ等の作成・更新・削除 Purviewの対応操作 「API」という呼称を、全実行要求の本文を収集する意味に広げない [43]
P05 Power Pages管理活動／監査 所有権、公開・認証関連設定、診断・WAF等の設定変更 PurviewのPower Pages活動 WebサイトのすべてのHTTPアクセスやページ閲覧履歴とは別 [44]
P06 Dataverse変更監査／監査 行の作成・変更・削除、共有、関連付け等。対象列の変更前後 環境→テーブル→列の監査を有効化。Dataverseのログ容量を消費 レコードのAudit History、Audit Summary、Web API／SDK [39]
P07 Dataverse・モデル駆動型アプリの活動／監査 読み取り、複数行参照、エクスポート、SDK操作、サポート操作等 環境の監査・活動ログとPurviewを設定。本番環境・ライセンス条件を確認 Purview、Management Activity API。変更前後値は送られない。複数行参照で個別行IDがそろう保証もない [40]
P08 Copilot Studio監査／監査 エージェントの作成・設定・公開等と、対応する作成者・利用者の対話 Copilot Studioの対応監査イベントをPurviewで検索。管理活動は既定収集 監査で取得できる対話情報と、Dataverse等の会話トランスクリプトを分ける。提供形態・権限・保持を確認 [56][57]
P09 Power BI・Fabric活動／監査 レポート等の参照・共有・エクスポートなどの対応活動 Purviewに加えPower BI Activity Events APIを選べる APIは過去28日、同一UTC日内の範囲で取得。長期利用には定期退避が必要 [58][80]

Power Platformの概要資料には本番環境、監査有効化、SAS logging設定などの前提が示されています。ただし、Power Platform管理活動は既定収集であり、ログ系列ごとの例外があります。概要の前提を、そのまますべてのログへ一括適用しない方針です。[38][41]

Dataverse変更監査は、読み取り・エクスポートや認証の監査を一括して満たしません。取得する列、履歴を読む権限、削除できる権限、容量、保持を設定し、アクセス活動は別途確認します。[39][40]

6.2 診断・実行・利用分析系

ID 対象／主用途 主な記録 取得・保存の特徴 標準利用・拡張 根拠
P10 Power AppsのLive monitor／運用 セッション中のネットワーク、データ操作、数式・画面・エラー関連イベント 開発中または公開アプリのセッションを監視。常時蓄積する中央監査とは別 問題の再現・詳細調査。利用権限はアプリ種別で異なる [45]
P11 キャンバスアプリのApplication Insights／運用 利用、画面、エラー、Trace関数の独自イベント等 テナント設定とアプリの接続文字列を設定し、公開アプリから送信。Studioのプレビューでは送信されない 継続的な分析、KQL、アラート。送信先が別テナントになり得る点も管理 [46]
P12 モデル駆動型アプリ・DataverseのApplication Insights／運用 ブラウザー・サーバー操作の性能・例外等 Power Platform管理センターでデータエクスポート連携。paid／premium Dataverseライセンス条件 標準スキーマで相関調査。環境・モデル駆動型アプリの処理を追う [47]
P13 DataverseのPlug-in Trace Log／運用 プラグイン・カスタム処理のトレース・例外 ITracingServiceと追跡設定。PluginTraceLogへ記録 開発・障害診断向け。24時間より古い記録を削除する日次ジョブがある [48]
P14 DataverseのILogger／運用 拡張コードが出すApplication Insights向けテレメトリ Application Insights連携が必要。ITracingServiceとは別の出力経路 長期の傾向・相関分析。ログ量・機密情報・計装位置を設計 [49]
P15 クラウドフローの実行履歴／運用 トリガー・アクション、入出力、成否、実行時間 フロー詳細の実行履歴。現行の制限文書ではストレージ保持30日 開発者・運用者の障害調査。入出力の保護と閲覧権限を確認 [50]
P16 DataverseのFlowRun／運用 フロー実行の開始・終了・状態・エラー等のメタデータ ソリューションのクラウドフローが対象。既定TTLは28日。Dataverseのデータベース容量を消費 Automation center、Dataverse API等。全アクションの入出力保存とは別 [51]
P17 Power AutomateのApplication Insights／運用 Requestsに実行、Dependenciesにトリガー・アクション Managed Environmentsのみ対応。データエクスポート設定とAzure側リソースが必要 実行・依存関係の分析とアラート。通常の実行履歴とは別の保存先 [52]
P18 Power Automate管理分析／管理・運用 実行数、利用、エラー、コネクタ等の集計 Power Platform管理センター。クラウドフロー分析とデスクトップを区別 環境の傾向・ガバナンス。個々の詳細ログの代わりにはしない [53]
P19 デスクトップフローの実行・アクションログ／運用 RPA実行と各アクションの結果 V1はFlowSessionのファイル属性、V2はFlowLogsのElastic Table。収集有無・詳細度・TTLを確認 V1はファイル容量、V2はログ容量。V2の起動条件等に制限がある [54]
P20 Power Pagesのエラーログ／運用 Webサイトのアプリケーションエラー 管理センターで診断ログを有効化し、自分のAzure Blob Storageへ保存 既定保持30日。サイトの接続先Dataverseを変えると再有効化が必要 [55]
P21 Copilot Studioの会話・セッション／運用・利用分析 会話、セッション情報、評価用データ等 Copilot Studioのダウンロード、DataverseのConversationTranscript等。保存設定・環境・提供形態の条件あり 応答・利用・失敗の分析。監査ログと保存先・内容・保持が異なる [57]
P22 Power BIのセマンティックモデル診断／運用 クエリ、更新、実行時間、CPU、スロットリング等 対応するPremiumワークスペース等とLog Analytics接続を設定 PowerBIDatasetsWorkspaceのKQL分析。テナントの活動監査とは別 [59]
P23 Fabricワークスペース監視／運用 対応するFabricアイテムの診断テレメトリ Monitoring ItemのEventhouse／KQL Databaseへ送信 KQL、ダッシュボード、通知。既定保持30日。対応ワークロード・提供段階を確認 [60]

Power Platformの「ログ容量」は、ログと名付けられたすべてのデータを格納する一律の区分ではありません。Dataverse監査はログ容量、FlowRunはデータベース容量、デスクトップフローはバージョンで容量区分が異なります。費用を説明するときは実際のテーブル・保存方式へ戻って確認します。[39][51][54]

Power AutomateからApplication Insightsへ送るテレメトリは、公式資料でも100%の無損失データとはされていません。転送側で一時的な欠落が疑われる場合は、Power Automateのフロー詳細にある実行履歴と照合します。監査や処理完了の証明に使う場合は、分析用テレメトリの件数だけで完了を判断しない設計が必要です。[52]

CoE Starter Kitなどによる独自の管理データ収集は、標準監査ログの保存・完全性とは別の仕組みとして扱う候補です。今回、導入・構成・収集範囲は検証していません。

7. 取得・転送方式

7.1 方式ごとの役割

方式 代表例 利用者が設定するもの 保存・利用上の違い 根拠
サービスの標準記録 Azure Activity log、Entraの基本ログ 閲覧権限、必要に応じて外部転送 標準の保持が切れる前に退避。取得開始前に存在する履歴はサービス仕様次第 [1][20]
サービス側の監査有効化 SQL監査、Dataverse監査 監査対象・粒度・保持・権限 転送先を作るだけでは対象操作の監査にならない [10][39]
診断設定による転送 Azureリソース、Entra、Intune カテゴリ、送信先、送信先権限、ネットワーク条件 Log Analytics、Storage、Event Hubs、パートナー等。通常は有効化後のデータが対象 [2][19][35]
Agent＋DCR Windowsイベント、Syslog、OS内のログ エージェント、ルール、関連付け、収集対象 OS側の監査・出力設定と収集設定の両方が必要 [3][4]
SDK・OpenTelemetry・製品計装 Webアプリ、Functions、Power AppsのTrace 計装、接続先、ログレベル、サンプリング 出力していない内容は送信されない。トレースの採取率にも依存 [8][13][46]
SaaSの製品連携エクスポート Dataverse・Power Automate→Application Insights 対象環境、データエクスポート、Azureの受信先 サービスが保有する所定のテレメトリを送る。ライセンスと対応範囲がある [47][52]
APIの検索・ダウンロード Purview検索、Graph監査検索、Power BI活動 権限・アプリ登録、期間、ページング 保存期間、APIで指定できる期間、1回の取得件数を分ける [28][58]
購読・通知＋定期取得 Management Activity API、Teams callRecords コンテンツ種別の購読、通知先、取得・再試行処理 通知を受けた後の本体取得、再取得可能期間、重複処理を管理 [27][32]
独自収集→取り込みAPI API取得したSaaSログや独自監査 収集プログラム、DCR、テーブル、送信権限 標準接続のないデータを集約できるが、収集処理自体の監視が必要 [5]
サービス固有の保存 Network Watcherフローログ、Power Pagesのエラー 対象機能とStorage接続 同じAzure Storageが宛先でも設定箇所と形式が異なる [17][55]

7.2 DCRと診断設定

DCRは収集・変換・配送先を宣言する設定リソースで、ログの保存先そのものではありません。エージェント、取り込みAPI、ワークスペース変換などで参照方法が異なります。[4][5]

プラットフォームログをDCRで収集する方式も公式資料にありますが、調査時点ではプレビューです。対応するリソース型・地域・宛先の制限があり、非対応のリソースでは診断設定が必要です。従来方式は現行の一般的な経路であり、DCR方式は条件付きの追加選択肢です。[76]

診断設定は一つのリソースに最大5個で、一設定に各宛先種別を一つずつ指定します。リージョン付きリソースからStorageやEvent Hubsへ送る場合の地域制約、ファイアウォールの信頼されたMicrosoftサービスの例外など、宛先側の条件もあります。設定を作成できたことと、実際に受信したことを分けて確認します。[2]

7.3 API収集の取りこぼし

Management Activity APIでは、まずコンテンツ種別を購読し、取得可能なコンテンツを列挙して本体をダウンロードします。コンテンツは出来事の順序どおりに到着するとは限りません。コンテンツ取得の7日という制約と、Purviewの180日などの監査保持は別の値です。[27][22]

API収集の設計では、次の項目をログごとに記録する案です。これは製品共通の実装保証ではなく、ログ収集を設計する際の確認項目です。

  1. イベント発生時刻、サービスへの到着時刻、取得時刻を区別します。
  2. 時間範囲、継続トークン、コンテンツIDなど、再開位置を保存します。
  3. 遅れて届く記録を取得するため、必要な重複期間を設けます。
  4. 記録IDと取得元を使い、同一記録の重複取り込みを抑えます。
  5. スロットリング、取得失敗、権限失効、購読停止、最終成功時刻を監視します。
  6. 取得元の保持・再取得期間内に再実行できるようにします。

8. 標準の閲覧・アラート

8.1 製品ごとの標準機能

ここでの「標準」は製品が提供する機能であるという意味です。すべての契約で利用できることや、無償であることを意味しません。

製品・用途 閲覧・調査 通知・検知 条件・限界 根拠
Azure管理操作 Activity logの絞り込み、変更・相関情報 Activity log alerts、Service Health／Resource Health関連アラート 管理イベント中心。単発イベントのアラートは継続条件と解除の扱いが異なる [1][63]
Azureの性能・可用性 Metrics explorer、Insights メトリックアラート、対応する動的しきい値 メトリックをLogsへ送らなくても評価できる場合がある [61][63]
Azureの複数ログ Log Analytics、KQL、Workbooks ログ検索アラート、対象に応じた検出機能 テーブルプラン、クエリ、評価間隔、対象範囲、費用を確認 [62][63][65]
アプリ性能 Application InsightsのFailures・Performance等 Smart detection、メトリック・ログ条件 計装・収集範囲・サンプリングに依存 [8][62][63]
M365の監査 Purview Audit、検索・CSV・API Defender portalの対応アラートポリシー Auditの検索権限とアラート管理の条件は別。任意の監査検索がそのまま通知ルールになるとは限らない [22][28][37]
M365のセキュリティ Defenderのインシデント・高度な追及 製品の検知、カスタム検出 対象製品のライセンス・オンボード・データが必要 [36]
Entraの認証・ID変更 監査・サインイン・リスク画面 Identity Protection等の機能、転送後のAzure Monitor／Sentinel すべての任意条件をEntra画面だけで通知できる前提にしない [19][20][72]
Power Apps・Dataverse Live monitor、Audit History、Audit Summary 製品診断の確認、必要に応じApplication Insights側で通知 監査履歴とリアルタイム診断の権限・保持を分ける [39][45][47]
Power Automate 実行履歴、Automation center、管理分析 製品のエラー通知と、Application Insightsでの条件評価 標準エラー通知の宛先・頻度・対象を実機で追加確認 [51][52][53]
Power BI・Fabric 活動監査、セマンティックモデル診断、ワークスペース監視 対応する監視クエリ・通知機能 レポートのデータアラートと運用・監査検知を区別 [58][59][60]

Azure Monitorでは、アラートの評価と通知・自動処理を分けて設計できます。Action groupはメール、SMS、Webhook、Azure Functions、Logic Appsなどの通知・処理を定義します。Teamsへの通知も、対応するLogic Apps等の経路を選んで構成します。[64]

8.2 アラート設計の比較軸

比較軸 管理・運用の例 監査・セキュリティの例
検知する事象 エラー増加、応答時間、処理停止、容量逼迫 権限付与、監査停止、外部共有、異常な持ち出し
即時性 数分以内の検知など、復旧要件から決める 操作の重大さと取得遅延から決める
判定 単発、連続、割合、平常時との差、未到着 主体・対象・件数・時刻・前後関係・例外
通知と担当 対象サービスの運用担当、当番 ID管理者、セキュリティ担当、監査担当
解除と再通知 自動復旧、再発、通知抑制 調査・承認・インシデントの状態で管理
必要な記録 実行ID、エラー、依存先、直前の変更 操作者、対象ID、変更内容、原記録、調査履歴

この表は設計上の提案です。製品ごとの既定しきい値や通知時間を確認した結果ではありません。

9. 保持・権限・費用

9.1 保持期間と取得窓

対象 公式資料で確認した条件 設計上の注意 根拠
Azure Activity log 標準90日 長期保存は診断設定で別宛先へ。保持期限後に設定しても失われた履歴は戻らない [1]
Azureのプラットフォームメトリック 基本93日。Prometheus等は別体系 ログの保持と別。チャート一回の表示可能期間も別 [61]
Entraの監査・サインイン Free 7日、P1/P2 30日が基本 昇格前の期限切れデータは復元されない。リスク・Graph activityは別条件 [20]
Purview Audit Standard 基本180日 監査が有効で対象操作が収集されていることが前提 [22][24]
Purview Audit Premium 対象ユーザーのExchange、SharePoint、OneDrive、Entra監査は既定1年。他の活動は基本180日 適用するライセンスとポリシーで変わる。非ユーザー主体にも固有条件がある [22][23]
Purviewの長期保持 対応する追加ライセンスで最大10年の保持ポリシー テナントで一人が上位ライセンスを持つだけで全員の記録が延長されるわけではない [23]
Management Activity API コンテンツ取得は7日の制約。列挙の指定範囲は基本24時間以内 Purview検索の180日と混同しない。購読・再取得・失敗監視を設計 [27]
Exchangeメッセージ追跡 過去90日まで。1回の検索範囲や出力形式に条件 監査保持やメール本文の保持とは別 [29]
Teams callRecords 通話・会議終了後に作成し30日保持 その後の分析が必要ならAPIで保存 [32]
Defender高度な追及 生のDefender XDRデータは基本30日 接続したSentinelデータはワークスペースの保持による [36]
Power BI Activity Events API 過去28日、同一UTC日内で開始・終了を指定 Purview保持と別。JSTの一日をそのままUTC一日として扱わない [58]
クラウドフローの標準実行保持 現行の制限ページは30日と記載 Dataverse FlowRunの28日や、過去の解説の28日と分ける [50]
Dataverse FlowRun 既定28日。TTL変更・収集停止が可能 ソリューションクラウドフロー限定。実行詳細全体の保持ではない [51]
Dataverse変更監査 保持設定を選択。既定Foreverの記述あり 設定経路により既存記録への適用説明に差があり、実機で確認が必要 [39]
Plug-in Trace Log 24時間を超えた記録を削除する日次ジョブ 「24時間で必ず消える」「長期監査として保存される」としない [48]
Power Pagesエラーログ 既定30日、選択可能な保持期間あり Blob側の管理・接続先変更時の再設定も確認 [55]
Fabricワークスペース監視 既定30日。Eventhouseの保持・キャッシュポリシーを設定 利用可能なデータと高速検索できる期間を分ける [60]

Log Analyticsの保持はワークスペース・テーブル・プランで管理します。現在の資料では、Analyticsの分析保持は最大2年、総保持は最大12年が案内されています。Basic、Auxiliaryの照会条件や長期保持データのアクセス方法は異なり、検索ジョブを使う場合があります。古い資料の「すべて30日」「Basicは8日」といった値を一律に引用しない方針です。[65][66]

テーブルプランの選択は費用だけで決められません。Auxiliaryへの変更でアラートが機能しなくなるなど、利用機能が変わります。必要なアラート、クエリ、検索範囲、外部エクスポートを確認してから、テーブルごとに選びます。[65]

9.2 有効化・権限・ライセンス

M365の監査は一般説明では既定有効とされていますが、監査有効化の個別資料にはBusiness Basic、Business Standard、Business PremiumなどのSMBライセンスや一部試用テナントの例外が記載されています。この資料では「M365は必ず最初から監査済み」と書かず、監査状態の確認を入口にします。[22][24]

層 確認する権限・契約 混同しやすい点 根拠
Azureの設定 リソースの診断設定、保存先の構成、DCRへの操作権限 ログの送信設定を変えられることと、全ログを読めることは別 [2][5][68]
Log Analyticsの閲覧 ワークスペース・リソース・テーブル等のアクセス方式 一覧画面のフィルターだけではアクセス制御にならない。対象プラン・_ResourceIdも確認 [68]
Entraの閲覧・転送 Entraロール、カテゴリ別ライセンス、Azure側権限 EntraとAzureの権限は別。Graph activityはP1/P2が必要 [19][21][72]
Purviewの閲覧 Audit Logs／View-Only Audit Logs等 監査を読む権限と、保持・有効化・アラートを変える権限は別 [24][38]
Purviewの長期保持 記録を生成する利用者に適用されるライセンスと保持ポリシー 検索する管理者の上位ライセンスだけで対象者全員をカバーしない [23]
Dataverse監査 環境・テーブル・列の設定権限、履歴・概要の閲覧、削除権限 Power Platform管理者という名称だけで全操作の権利を推定しない [39]
Power Platform→Application Insights モデル駆動型／Dataverseの有償条件、フローのManaged Environments条件 Power Appsのキャンバス、Dataverse、フローで設定・条件が違う [46][47][52]
Power BI診断・Fabric分析 Premium等の対応条件、Fabric容量、ワークスペースの権限 Power BI活動監査APIの条件と、診断・分析容量の条件は別 [58][59][75]

9.3 費用の内訳

今回は単価や月額を試算していません。費用を比較する際は、次の費目を分けて確認します。

費目 確認する数量・条件
発生元の権利 Entra、Purview、Defender、Power Platform、Power BI等のライセンス。記録を生成する主体と利用者数
収集・取り込み 取り込みGB、カテゴリ、重複転送、サンプリング、変換、対象プラン
検索・保持 分析保持・長期保持、検索ジョブ、Basic／Auxiliaryのクエリ等
Azureの保存・中継 Blobの容量・操作・アクセス層、Event Hubsの容量・保持、転送
分析・検知 Sentinel、Azure Data Explorer、Fabric容量、アラート評価・通知
Dataverse容量 データベース・ファイル・ログ容量。実際のテーブルと保存方式
独自実装の運用 API収集、再試行、スキーマ変更、秘密・証明書の更新、監視、保守

Azure Monitor Logsは主に取り込みと保持が費用を左右し、課金量の計算はログファイルのディスクサイズと単純には一致しません。Sentinelを有効にしたワークスペースでは課金経路も確認します。費用試算では対象地域・契約・メーター・取得日を明記する必要があります。[67]

10. 他サービスとの組み合わせ

以下は、公式に確認できた接続を用いた構成候補です。接続全体を実装・検証した結果ではありません。「標準接続」「独自収集が必要」「分析用の構成提案」を区別します。

構成候補 接続方法 用途・得られること 成立条件・限界 根拠
Azure／Entra／Intune→Log Analytics→Workbooks・Alerts 診断設定などの標準経路 障害と変更の関連調査、傾向分析、通知 それぞれのカテゴリを設定。保持・閲覧権限・取り込み費用を確認 [2][19][35][62]
Power Platform→Application Insights→Logs・Alerts 対応する製品エクスポート・計装 アプリとフローの性能、依存先、失敗の調査 キャンバス・Dataverse・フローで条件が違う。相関IDが自動で全経路をつなぐとは限らない [46][47][52]
M365→Sentinel Microsoft 365コネクタなど OfficeActivity等で利用者活動を検索・検知 接続対象はコネクタの対応範囲。Purviewの全イベントを自動複製する保証として扱わない [71]
Entra→Sentinel Entra IDコネクタ ID認証・変更と他サービスの活動を相関 サインインやリスクログのライセンス・権限を確認 [72]
Power Platform→Sentinel Microsoft Business Appsソリューションと対応コネクタ 業務アプリの監査・不審活動の検知 ソリューション、カテゴリ、アラートテンプレート等の対応範囲を確認 [73]
Purview→独自収集→保存・分析 Management Activity API、Graph監査検索API等 独自要件の長期保存、横断集計、レポート APIの取得窓、検索ジョブ、権限、再開・重複・遅延の処理が必要 [27][28]
診断設定→Event Hubs→Azure Data Explorer 標準の転送＋Event Hubsデータ接続 大量ログのKQL分析、独自の集計・保持 テーブル・形式・マッピング、取り込み・中継費用、保持を設計 [2][74]
診断設定等→Event Hubs→Fabric Eventstream 標準の転送＋Event Hubsソース Eventhouse等での分析、ダッシュボード、業務データとの組み合わせ Fabric容量、接続権限、形式、ネットワーク条件が必要。M365から直接つながる一般経路ではない [2][75]
Log Analytics→Storage／Event Hubs Data export rule 受信データを継続的に別の保存先・分析先へ送る 設定後の対象テーブルへの受信データが基本。過去データの一括バックアップとは別 [69]
発生元→Blob Storageの不変ストレージ 対応する転送とWORMポリシー 指定期間の上書き・削除防止を含む保存 ログ発生・配送の欠落は埋めない。ポリシーと書き込み方式の適合を検証 [2][70]
Event Hubs→外部SIEM・監視製品 発生元の標準転送＋製品の取り込み 既存監視・セキュリティ運用への統合 パーサー、スキーマ、遅延、再送、重複、受信側課金を確認 [2][35]
Azure Monitor／Sentinel→業務通知・対応 Action group、Logic Apps等 担当者への通知、チケット起票、対応処理 検知と処理権限を分ける。自動修復は対象・再試行・誤判定を設計 [64]

Power BIは分析結果を共有する候補ですが、監査の原記録を保存する場所、収集の再開位置を管理する場所としては別の保存先を設ける設計案です。表示用集計と原記録の対応を残し、更新遅延と閲覧権限を確認します。

Log Analyticsの継続エクスポートは対象テーブルの到着データを送る機能です。過去データの抽出は検索・クエリ・別のエクスポート方式を確認します。現行資料には履歴データ向けexport jobのプレビューもありますが、継続エクスポートと同じ機能として説明しません。[69]

11. 管理・運用と監査の設計

11.1 共通する原則と分ける要件

観点 管理・運用で中心になる要件 監査で中心になる要件
収集の粒度 エラー、遅延、実行、依存関係を原因調査できる粒度 主体、対象、操作、時刻、結果と必要な変更内容
収集量の調整 ログレベル、サンプリング、集計で最適化 必須操作の記録を落とさない対象選定。診断用の採取率を安易に適用しない
保持 日常調査の頻度・遡及期間から決定 社内の説明・調査・保全要件から決定
アクセス アプリ・サービス担当へ必要な範囲を開示 監査閲覧、収集設定変更、削除・保全の権限を分ける
保存 検索速度、コスト、再処理しやすさ 原記録、変更・削除防止、検索可能性、出力の由来
対応 復旧、再実行、性能・容量調整 事実確認、承認確認、影響調査、記録の保全

これは構成提案です。管理系と監査系を分けることを、必ず異なるワークスペースへ保存することと同一視しません。権限・保持・課金・地域・運用主体が異なるなら物理的な分離を検討し、同じログを両方で使うなら重複取り込みとアクセス範囲を確認します。[68][67]

Log Analyticsは取り込み後のデータを書き換える用途ではありませんが、purgeなどによる削除が可能なため、それだけで不変保存の要件を満たすと判断しません。必要な場合は不変ストレージへのエクスポートを検討します。[69][70]

11.2 ログごとに残す設計項目

分類 記録する項目
目的 読者の問い、管理・運用／監査／検知、担当者、必要な証跡
発生元 サービス、テナント、サブスクリプション、環境、リソース型、カテゴリ、Operation
発生条件 既定有効か、事前有効化か、対象外操作、環境種別、ライセンス、プレビューか
内容 主体ID、代理実行、対象ID、操作、成功・失敗、変更前後、本文・個人情報の範囲
取得 診断設定、DCR、Agent、計装、API、コネクタ、権限、取得窓、ページング
配送 宛先、リージョン、ネットワーク、遅延、再送、重複、欠落、収集停止の検知
保存 テーブル、プラン、保持、検索可能期間、削除権限、不変保存、容量区分
利用 標準画面、クエリ、ダッシュボード、アラート条件、通知先、対応手順
費用 発生元ライセンス、取り込み・保持・検索・転送・分析・通知・運用
検証 再現操作、期待する記録、実際の到着、閲覧権限、通知、保存・再取得の結果

11.3 横断調査の題材

題材 管理・運用で調べるもの 監査で調べるもの 相関で確かめる点
アプリからKey Vaultへアクセスできない アプリ例外・依存要求、Key Vault拒否、必要な認証ログ Key Vault設定・RBAC等の変更、要求主体 リソースID、主体ID、要求時刻。IDがサービスごとに共通かを確認
M365のファイル共有後に持ち出しが疑われる 関連するサービス・端末の状態 SharePoint共有・ダウンロード、Entra認証、対応するDefender情報 操作イベントと人の実際の閲覧を同一視しない。アプリ主体も確認
Power Appsの処理が遅くフローも失敗する Live monitor、Dataverse／アプリのApplication Insights、フロー履歴 アプリ・フロー編集、接続・権限変更、Dataverse変更監査 環境ID、アプリID、フロー実行ID、レコードID。相関情報の伝播は要検証
Dataverseの業務値が変わり、外部へ出された疑い 関連プラグイン・フローの処理 Dataverseの変更前後値、Purviewの参照・エクスポート、ID情報 Purviewに変更前後値がないこと、複数行参照の行ID制約を踏まえる

これらは検証シナリオの提案です。現時点で実際の操作や取得結果を確認した事例ではありません。

12. 追加検証と資料の説明差

12.1 説明差を残しておく項目

論点 確認した資料の記述 利用時の扱い
Purviewの既定有効 概要は既定有効、有効化資料はSMB等の例外を明記 個別の有効化資料の条件を採用し、実際の監査状態を確認する。[22][24]
Power AutomateのPurview記録 Power Platform概要には実行・失敗も連想させる説明がある一方、個別資料はライフサイクル・権限操作のみと明記 個別資料を優先。実行・アクションは履歴、FlowRun、Application Insightsで扱う。[38][42]
Power PagesのPurview記録 概要はサイトの対話・ページイベントを広く説明する一方、個別イベント表は所有権・設定等が中心 HTTPアクセスや全ページ閲覧の取得を保証しない。イベント表で対象を指定する。[38][44]
コネクタのAPI呼び出し 概要・導入にはAPI callsの表現があるが、個別表は接続・API定義・権限・ゲートウェイの変更が中心 実行時呼び出しの完全な追跡と解釈しない。必要なOperationの生成を検証する。[43]
フロー保持30日と28日 制限ページは実行保持30日、FlowRunは既定28日 保存先を明記し別々に説明。テナント画面とAPIで確認する。[50][51]
Dataverse監査の保持変更 従来設定では既存記録の保持は変わらないと説明。Security側の設定には既存ログにも適用できる旨の注記 設定箇所・適用時刻・既存／新規記録の削除を検証し、両者を一括説明しない。[39]
Copilot Studioトランスクリプト保持 ダウンロード資料の28日等と、Dataverse上の記録・別資料の保持説明は保存場所・提供形態が異なる 一律の日数を本文へ採用しない。利用する保存先・環境・設定を特定して追加確認。[57]
デスクトップフローV2 導入説明にはローカル実行もある一方、Known limitationsにはクラウドフローから開始した実行のみの制限 V2の利用形態を実機で検証。対象外のローカル実行も一括取得できるとしない。[54]
AzureのDCR方式 リソースログのDCR収集はプレビュー、対応範囲限定 診断設定を一律に廃止扱いしない。対応リソース・地域・宛先を併記。[76]
Fabric監視の提供段階 テナント設定ページにpreviewの表記がある一方、監視概要には機能・保存方式の更新がある 対応ワークロードごとに利用時に再確認。全体のGAを今回断定しない。[60][82]

12.2 実機で検証する項目

以下は未実施の検証計画です。実際の取得結果や成功を確認した事例ではありません。

優先度 検証 確認する結果
高 Activity logとデータアクセスの比較 リソース変更、シークレット取得等を行い、主体・操作・記録先の違いを見る
高 診断設定の作成前後 作成前の履歴、作成後の到着、カテゴリ、テーブル、遅延を確認
高 Entraの対話・非対話・アプリ認証 各主体のログと転送先のカテゴリ・テーブルを対応づける
高 M365の監査状態・ライセンス 実際の有効状態、対象操作、保持、Audit権限とAPI権限を確認
高 Dataverseの変更・参照・エクスポート 変更前後値、Purviewの活動、対象外操作・行IDの制約を確認
高 フロー編集・共有・実行・失敗 Purview、実行履歴、FlowRun、Application Insightsへ何が残るかを比較
高 Power Platformの本番・Sandbox・Developer等の差 管理活動と利用者活動、SAS logging等の前提をログごとに確認
高 アラートと欠測の検知 期待する失敗、収集停止、通知先不備を区別して検知できるか確認
中 監査担当・運用担当・アプリ担当の閲覧 画面・API・Workbooks等で同じ権限範囲が保たれるか確認
中 Management Activity APIの継続取得 購読、ページング、重複、遅着、再試行、失敗からの再開を確認
中 Power BI Activity EventsのUTC日次取得 JSTとUTCの境界、継続トークン、28日の取得窓を確認
中 Agentと計装 OSで生成したイベントが収集されること、サンプリング・フィルターによる差を見る
中 データエクスポートと不変保存 設定後の到着データ、過去履歴の別取得、対象テーブル、保存時の制約を確認
中 Event Hubs経由のADX／Fabric分析 形式・マッピング、相関キー、遅延、重複、容量・課金を確認

Azure Monitorのリソースログは、公式資料でも100%の無損失配送を保証するものとして説明されていません。Application Insightsにはサンプリングもあります。監査要件を論じる場合は、保存先の保護だけでなく、発生対象・生成・配送・欠落検知を含めて確認します。[14][8]

12.3 追加で掘り下げる範囲

Azureの各カテゴリのイベント・フィールドと対応テーブル、サービス別SKU、PIM等の詳細履歴、Microsoftのサポート操作、各APIの制限、Copilot／AI関連の新しい監査イベントは、利用するサービスと要件に応じて追加調査する項目です。公式のリソースログカテゴリ一覧とPurviewの対応サービス・操作一覧を使い、既存のカタログに対象を追加します。[6][25][80]

また、日次取得だけでは満たせない検知時間、複数テナント、地域間転送、Private Link、データの秘匿・削除、証跡の提出形式は要件次第です。今回は一般的な成立条件までとし、法令に沿った保存年数や適法性の判断は行っていません。

参考資料

確認日：2026年10月29日。提供元はすべてMicrosoftです。本文の仕様説明はMicrosoft Learnの製品文書・APIリファレンスを使用しています。一部は検索結果本文での確認であり、下記に注記します。Microsoft Learnの画面共通の認証案内が表示されても、製品本文が取得できた資料は本文を参照しました。取得できなかった推測URLは参考資料に含めていません。

  1. Activity log in Azure Monitor：管理操作、既定収集、90日保持、閲覧・API。
  2. Diagnostic settings in Azure Monitor：対象、宛先、最大設定数、地域・ネットワーク制約。
  3. Azure Monitor Agent overview：OS内の収集、DCR、導入方法。
  4. Data collection rules in Azure Monitor：DCRの役割、関連付け、設定とデータ経路の区別。
  5. Logs Ingestion API in Azure Monitor：独自データの取り込み、DCR、宛先テーブル、認証。
  6. Supported Resource log categories for Azure Monitor：リソース型別のカテゴリとスキーマ。個別カテゴリの詳細は追加調査。
  7. Monitor Azure Kubernetes Service (AKS)：制御プレーン、コンテナ、メトリック等の区別。
  8. Sampling in Azure Monitor Application Insights with OpenTelemetry：サンプリング、ログ・トレース・メトリック、日次上限。
  9. Azure Key Vault logging：アクセス記録、保存と利用。
  10. Auditing for Azure SQL Database：監査対象とStorage、Log Analytics、Event Hubsへの保存。
  11. Monitor Azure Blob Storage：リソースログ、メトリック、分析。
  12. Enable diagnostic logs for apps in Azure App Service：ログ種別、OSによる差、保存・アクセス。
  13. Monitor executions in Azure Functions：Application Insights、計装・送信方式。
  14. Monitor and collect diagnostic data for workflows in Azure Logic Apps：トリガー・実行・アクション、診断、配送の非無損失性。
  15. Tutorial: Monitor published APIs：標準分析、メトリック、ログ、アラート。
  16. Monitor Azure Cosmos DB data using Azure Monitor Log Analytics diagnostic settings：データプレーンログとAPIごとの設定。
  17. Virtual network flow logs：Network Watcherの取得とStorageへの出力。
  18. Flow logging for network security groups：新規作成停止と2027年9月30日の廃止。今回の確認は検索結果に取得された公式本文。
  19. What are the identity logs you can stream to an endpoint?：監査、各サインイン、プロビジョニング、リスク、Graph等のカテゴリ。
  20. Microsoft Entra data retention：ライセンス別保持、統合監査との区別、Graph activity。今回の確認は検索結果に取得された公式本文。
  21. Access Microsoft Graph activity logs：記録する要求、P1/P2、権限、宛先。
  22. Learn about auditing solutions in Microsoft Purview：Standard／Premium、検索・API、保持。
  23. Manage audit log retention policies：既定・カスタム保持、対象ユーザー、追加ライセンス。
  24. Turn auditing on or off：既定有効の例外、状態確認、必要権限。
  25. Audit log activities：製品別の操作とOperation、表示・APIの差。
  26. Manage mailbox auditing：既定監査、所有者・代理人・管理者、対象操作。
  27. Office 365 Management Activity API reference：購読、コンテンツ、通知、到着順、取得期間。
  28. auditLogQuery resource type：統合監査ログを検索するGraphリソース。
  29. Message trace in the Exchange admin center in Exchange Online：配送状態、90日の範囲、出力方式。
  30. What is Call Quality Dashboard (CQD)?：組織全体の通話・会議品質。
  31. Monitor and troubleshoot Teams meetings and calls from the Teams admin center：現行の通話・会議診断の入口。旧Call Analytics資料からの案内先。
  32. Working with the call records API in Microsoft Graph：終了後の記録、30日保持、購読・照会。
  33. reportRoot resource type：M365の利用レポートと対象メソッド。
  34. Working with service communications API in Microsoft Graph：サービス正常性とMessage center。
  35. Send Intune log data to Azure Storage, Event Hubs, or Log Analytics：監査・運用・準拠・端末情報と転送。
  36. Proactively hunt for threats with advanced hunting in Microsoft Defender：対象製品、生データ30日、Sentinel接続、カスタム検出。
  37. Alert policies in the Microsoft Defender portal：対象活動、しきい値、通知、利用条件。
  38. Power Platform activity logs and auditing in Microsoft Purview：対象製品、前提、SAS logging、管理活動の例外。個別資料との説明差は第12節参照。
  39. Manage Dataverse auditing：対象操作、環境・テーブル・列、容量、閲覧・削除、保持。今回の確認は検索結果に取得された公式本文。
  40. View Microsoft Dataverse and model-driven app activity logs in Microsoft Purview：参照・出力、変更前後値の非送信、行IDの制約。
  41. View Power Platform admin logs in Microsoft Purview：既定収集、管理活動のカテゴリ。
  42. View Power Automate activity logs in Microsoft Purview：ライフサイクル・権限操作、実行の除外、代替の監視。
  43. View Power Platform connector activity logs in Microsoft Purview：コネクタ・接続・権限・ゲートウェイのイベント。
  44. View Power Pages activity logs in Microsoft Purview：対象管理・設定イベント。
  45. Live monitor overview：セッション診断、イベント、アプリ種別ごとの権限。
  46. Analyze system-generated logs using Application Insights：キャンバスアプリ、設定、公開、Trace。
  47. Analyze model-driven apps and Microsoft Dataverse telemetry with Application Insights：対象、ライセンス、エクスポート、相関。
  48. Tracing and logging：ITracingService、PluginTraceLog、削除ジョブ。今回の確認は検索結果に取得された公式本文。
  49. Write Telemetry to your Application Insights resource using ILogger：ILoggerとITracingServiceの比較。今回の確認は検索結果に取得された公式本文。
  50. Limits of automated, scheduled, and instant flows：実行期間とストレージ保持30日。
  51. Manage cloud flow run history in Dataverse：FlowRun、対象フロー、28日TTL、データベース容量。
  52. Set up Application Insights with Power Automate：Managed Environments、Requests／Dependencies、監視。
  53. View analytics for cloud flows：管理センターのクラウドフロー分析。
  54. Desktop flow action logs configuration：V1／V2、容量、TTL、Known limitations。今回の確認は検索結果に取得された公式本文。
  55. View error logs：Blob保存、保持、Dataverse接続先変更の影響。今回の確認は検索結果に取得された公式本文。
  56. View Copilot Studio audit logs in Purview：監査の入口と対象。
  57. Understand downloaded session data from Copilot Studio：セッションの出力、28日のダウンロード対象、環境等の例外。今回の確認は検索結果に取得された公式本文。Dataverseの保持全体への一般化は保留。
  58. Admin - Get Activity Events：28日の取得窓、同一UTC日、権限。今回の確認は検索結果に取得された公式本文。
  59. Configure Azure Log Analytics in Power BI：対応条件、PowerBIDatasetsWorkspace、ExecutionMetrics。
  60. Workspace monitoring overview：Monitoring Item、Eventhouse、対応テレメトリ、保持・通知。提供段階はテナント設定資料と併せて利用時に再確認。
  61. Metrics in Azure Monitor：基本93日、Prometheusとの違い。今回の確認は検索結果に取得された公式本文。
  62. Azure Monitor Logs overview：保存・分析・利用の役割。
  63. Choose the right type of alert rule：メトリック・ログ・Activity log等のアラート。今回の確認は検索結果に取得された公式本文。
  64. Action groups：通知・自動アクションとTeamsへの連携例。
  65. Configure a table plan in a Log Analytics workspace：Analytics／Basic／Auxiliaryと変更の影響。今回の確認は検索結果に取得された公式本文。
  66. Manage data retention in a Log Analytics workspace：分析保持、総保持、検索ジョブ。今回の確認は検索結果に取得された公式本文。
  67. Azure Monitor Logs cost calculations and options：取り込み・保持、課金量、Sentinelとの関係。単価の調査・試算は未実施。
  68. Manage access to Log Analytics workspaces：アクセス方式、リソース・ワークスペース・テーブルの権限。
  69. Log Analytics data export rules in Azure Monitor：継続出力、履歴の別方式、purge、不変保存との関係。
  70. Store business-critical blob data with immutable storage in a write once, read many (WORM) state：保持ポリシー、legal hold、上書き・削除防止。
  71. Find your Microsoft Sentinel data connector：Microsoft 365：対応コネクタ、OfficeActivity。全カテゴリの複製保証とは扱わない。
  72. Send data to Microsoft Sentinel using the Microsoft Entra ID data connector：ログ種別、サインイン・ワークロードIDのライセンス、権限。
  73. What is the Microsoft Sentinel solution for Microsoft Business Apps?：Power Platform等の監査・活動と脅威検知。
  74. Azure Event Hubs data connection：Azure Data Explorerへの継続取り込み。
  75. Add an Azure Event Hubs source to an eventstream：Fabricへの接続、容量、権限、ネットワーク。
  76. Platform log collection with data collection rules (Preview)：対応範囲、地域、宛先、診断設定との関係。
  77. Get resource changes：Resource Graphの変更情報と変更主体。
  78. Set up continuous export in the Azure portal：アラート・推奨事項の継続出力。
  79. Audit logs for Copilot and AI applications：CopilotInteraction、対象アプリ、メッセージや参照情報のスキーマ。今回の確認は検索結果に取得された公式本文。
  80. Microsoft services that support auditing：対象サービスとRecordType。今回の確認は検索結果に取得された公式本文。
  81. View Power Apps activity logs in Microsoft Purview：起動・公開・権限・パッチ等の個別イベント。
  82. Audit and usage tenant settings：Power BIのLog Analytics接続とワークスペース監視のテナント設定・preview表記。