Microsoft Purviewの監査でまず確認すべきことは、「統合監査ログが有効か」「誰が検索・エクスポートできるか」「必要な保持期間をライセンスとポリシーで満たせるか」の3点です。2026年5月19日前後の公式情報では、Microsoft Purview Audit（Standard）とAudit（Premium）の機能差、監査ログ保持、Graph APIやOffice 365 Management Activity APIからの取得、検索時の制限を前提に、運用設計を見直すことが重要です。統合監査ログは、Microsoft 365内の多数のユーザー操作・管理者操作を記録し、セキュリティ調査、内部調査、法務・コンプライアンス対応に使えます。(Microsoft Learn)
Microsoft Purviewの監査ソリューションで確認できること
Microsoft Purviewの監査ソリューションは、組織内のMicrosoftサービスで発生したユーザー操作や管理者操作を、統合監査ログとして検索・確認するための仕組みです。対象はExchange Online、SharePoint Online、OneDrive、Microsoft Entra ID、Microsoft Teams、Power BI、Microsoft Purview関連機能、DLP、eDiscovery、Microsoft 365 Copilotなど幅広く、サービスごとにRecord typeが定義されています。(Microsoft Learn)
実務での主な用途は次のとおりです。
| 利用シーン | 具体例 | 確認したいログ |
|---|---|---|
| アカウント侵害調査 | 退職者アカウントや不審なサインイン後の操作確認 | Entra ID、Exchange、SharePoint、OneDrive |
| 情報漏えい調査 | ファイル共有、ダウンロード、外部共有の追跡 | SharePoint、OneDrive、DLP |
| 管理者操作の監査 | 権限変更、設定変更、アプリ登録の確認 | Entra ID、Exchange管理、Purview管理 |
| 法務・内部調査 | eDiscoveryケースや保持、エクスポート操作の確認 | eDiscovery、Purview Search |
| SIEM連携 | 監査ログを継続的に収集し検知ルールに利用 | Office 365 Management Activity API、Graph API |
ポイントは、Microsoft Purviewの監査ログを「後から検索するための履歴」だけでなく、「日常的な検知・調査・証跡保全の基盤」として設計することです。特にセキュリティ部門、Microsoft 365管理者、法務・監査部門、SIEMを扱う開発者は、同じログを別々の目的で使うため、保持期間とアクセス権を先に整理しておく必要があります。
公式情報から見る主な変更点と確認ポイント
今回の公式情報で管理者が押さえるべき中心は、Audit（Standard）とAudit（Premium）の役割分担です。Audit（Standard）は既定で有効化され、監査ログ検索、CSVエクスポート、Search-UnifiedAuditLog、Audit Search Graph API、Office 365 Management Activity APIへのアクセスに対応します。一方、Audit（Premium）はStandardの機能に加えて、監査ログ保持ポリシー、より長い保持期間、インテリジェントな分析情報、Office 365 Management Activity APIの高い帯域を提供します。(Microsoft Learn)
| 項目 | Audit（Standard） | Audit（Premium） | 管理上の判断基準 |
|---|---|---|---|
| 既定の有効化 | 対応 | 対応 | まずStandardで検索できる状態を確認する |
| 監査ログ検索 | 対応 | 対応 | Purviewポータル、PowerShell、Graph APIを使い分ける |
| 既定の保持期間 | 180日 | 一部ワークロードは1年、その他は条件により延長 | 調査要件が半年を超えるならPremiumを検討 |
| 保持ポリシー | 非対応 | 対応 | 部門・ユーザー・操作単位で保持を分けたい場合に必要 |
| 10年保持 | 非対応 | 追加ライセンスとポリシーで対応 | 規制・訴訟・長期監査要件がある場合に検討 |
| API帯域 | 標準 | より高い帯域 | SIEMや自社システムへ大量連携する場合に重要 |
| インテリジェントな分析情報 | 非対応 | 対応 | メールアクセスや検索操作など高度な調査に有効 |
Audit（Standard）の既定保持期間は、以前の90日から180日に変更されています。ただし、2023年10月17日より前に生成されたStandardログは90日保持、同日以降に生成されたログは180日保持という扱いです。古いログまで自動的に180日へ延びるわけではないため、過去調査の前提を誤らないよう注意が必要です。(Microsoft Learn)
また、Classic Searchは2023年11月30日に廃止されており、現在はNew Searchを前提に運用します。New Searchでは検索の高速化、検索条件の拡充、検索の保存などが含まれるため、旧UIや旧手順を社内手順書に残している場合は更新が必要です。(Microsoft Learn)
影響範囲は管理者だけでなく開発者・監査部門にも広がる
Microsoft Purviewの監査ソリューションは、単に管理画面の表示項目が変わる話ではありません。保持期間、権限、API、エクスポート上限、タイムゾーン、検索条件の作り方が、調査結果の完全性に影響します。
| 対象者 | 影響するポイント | すぐ確認すべきこと |
|---|---|---|
| Microsoft 365管理者 | 監査ログの有効化、ロール、ライセンス | Audit Reader / Audit Managerの割り当て |
| セキュリティ運用担当 | 不審操作の検知、SIEM連携、調査手順 | どのログを何日保持するか |
| 法務・内部監査担当 | 証跡保全、eDiscovery、長期保持 | 10年保持や1年保持の対象ユーザー |
| 開発者・SRE | Graph API、Management Activity API、スロットリング | API権限、取得間隔、再試行設計 |
| ヘルプデスク | 共有、削除、メール転送などの一次調査 | 代表的なOperation名と検索テンプレート |
特に注意したいのは、監査ログは「存在しているはず」と思い込むだけでは不十分な点です。ライセンス、サービスプラン、保持ポリシー、ユーザー単位の設定、API権限のいずれかが欠けると、必要な証跡が検索できない、または保持されていない可能性があります。
管理者が最初に確認すべき設定
監査ログ検索が有効か確認する
Microsoft 365およびOffice 365のエンタープライズ組織では、監査ログ検索は既定で有効です。ただし、実運用では設定変更やテナント移行の影響を受ける可能性があるため、Exchange Online PowerShellで確認しておくのが安全です。Microsoft Learnでは、UnifiedAuditLogIngestionEnabledがTrueであれば監査ログ検索が有効と説明されています。(Microsoft Learn)
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabledこの確認はExchange Online PowerShellで実行します。Security & Compliance PowerShellでも同名のコマンドレットは利用できますが、公式情報では、その場合UnifiedAuditLogIngestionEnabledが常にFalseと表示される点が注意事項として示されています。(Microsoft Learn)
監査ログを検索できるロールを割り当てる
監査ログを検索・エクスポートするには、Microsoft PurviewポータルでView-Only Audit LogsまたはAudit Logsロールが必要です。既定では、Audit ReaderロールグループとAudit Managerロールグループにこれらのロールが割り当てられます。Audit Readerは検索・エクスポート向け、Audit Managerは検索・エクスポートに加えて監査設定の管理も行う権限として使い分けます。(Microsoft Learn)
管理の原則としては、日常調査担当にはAudit Reader、設定変更まで担う少数の管理者にはAudit Managerを割り当てます。全員に強い権限を付けると、監査ログ自体の管理操作が増え、内部監査時に説明しづらくなります。
SearchQueryInitiatedイベントを明示的に有効化する
Exchange OnlineとSharePointでユーザーの検索操作を監査したい場合、SearchQueryInitiatedExchangeとSearchQueryInitiatedSharePointに関する設定を明示的に有効化する必要があります。公式手順では、対象ユーザーごとにExchange Online PowerShellで次のように設定します。(Microsoft Learn)
Set-Mailbox <user> -AuditOwner @{Add="SearchQueryInitiated"}マルチGeo環境では、ユーザーのメールボックスが存在するフォレストでコマンドを実行する必要があります。別フォレストで設定していた場合は、いったん値を削除し、正しいフォレストで追加し直す流れになります。検索操作の監査は、内部調査や情報探索行動の確認で重要になるため、対象部門だけでも事前に設定を確認しておくとよいでしょう。(Microsoft Learn)
Audit（Premium）のサービスプランを確認する
Audit（Premium）の高度な機能を使うには、対象ユーザーに適切なE5系ライセンスまたはアドオンが割り当てられているだけでなく、Microsoft 365 Advanced Auditingサービスプランが有効である必要があります。公式情報では、サービスプラン有効化後、Audit（Premium）の分析情報のログ記録は24時間以内に開始されると説明されています。(Microsoft Learn)
ライセンスを購入したのにPremiumのログが期待どおり出ない場合は、次の順で確認します。
| 確認項目 | 見落としやすい点 |
|---|---|
| 対象ユーザーにE5または該当アドオンがあるか | 一部の役員・管理者だけ別ライセンスになっている |
| Advanced Auditingサービスプランが有効か | ライセンスはあるがアプリ単位で無効化されている |
| 監査対象の操作がPremiumイベントか | Standardでは出ない詳細イベントを期待している |
| 反映までの時間を待ったか | 有効化直後に検索して「出ない」と判断している |
保持期間と監査ログ保持ポリシーの設計
Microsoft Purviewの監査で最も失敗しやすいのは、ログの検索方法ではなく保持期間の設計です。Audit（Standard）は180日保持が基本です。Audit（Premium）では、Microsoft Entra ID、Exchange、OneDrive、SharePointの監査レコードが既定で1年保持され、その他のアクティビティは既定で180日保持、またはカスタム監査ログ保持ポリシーで延長できます。(Microsoft Learn)
| 要件 | 推奨する設計 |
|---|---|
| 半年以内の通常調査で足りる | Audit（Standard）の180日保持を前提に検索手順を整備 |
| 退職者や役員など一部ユーザーを長く追跡したい | Audit（Premium）でユーザー単位の保持ポリシーを検討 |
| Exchange、SharePoint、OneDrive、Entra IDを1年調査したい | Audit（Premium）の既定1年保持を確認 |
| 規制対応で数年単位の証跡が必要 | 10-Year Audit Log Retentionアドオンと保持ポリシーを検討 |
| SIEMで長期分析したい | APIで外部保管し、Purview側の保持期間と二重管理する |
監査ログ保持ポリシーを作成・変更するには、Microsoft PurviewポータルでOrganization Configurationロールが必要です。組織で作成できる監査ログ保持ポリシーは最大50個で、カスタムポリシーは既定ポリシーより優先されます。保持期間を短くするカスタムポリシーを作ると、意図せずログ保持が短くなる可能性があるため、優先度と対象条件は必ずレビューしてください。(Microsoft Learn)
10年保持にも注意が必要です。10年保持には追加のユーザー単位アドオンライセンスと、適切な10年保持ポリシーが必要です。また、このポリシーは遡及適用されず、ポリシー作成前に生成された監査ログを10年保持に変更することはできません。(Microsoft Learn)
さらに、サービスプリンシパル操作、システムイベント、アプリケーション活動などの非ユーザーエンティティが生成する監査レコードは、固定で1年保持され、カスタム監査ログ保持ポリシーの対象にはならないと説明されています。開発者がアプリ操作ログを長期保管したい場合は、外部ログ基盤への取り込みも併せて設計する必要があります。(Microsoft Learn)
検索・エクスポート・API連携の使い分け
Microsoft Purviewの監査ログは、Purviewポータルだけでなく、PowerShell、Microsoft Graph、Office 365 Management Activity APIからも扱えます。どれを選ぶかは、目的で決めるのが実務的です。
| 方法 | 向いている用途 | 注意点 |
|---|---|---|
| PurviewポータルのAudit検索 | 管理者の手動調査、一次確認 | 日付はUTC。検索条件の理解が必要 |
| Search-UnifiedAuditLog | 定型調査、PowerShellによる抽出 | Exchange Online PowerShellで実行する |
| CSVエクスポート | ExcelやPower Queryでの分析 | Standardは最大50,000件、Premiumは最大1,000,000件 |
| Audit Search Graph API | 自社ツールからの検索ジョブ作成・取得 | Graph権限と対応クラウドを確認 |
| Office 365 Management Activity API | SIEM連携、継続収集、外部保管 | サブスクリプション、Webhook、スロットリング設計が必要 |
CSVエクスポートでは、AuditData列にJSON形式の詳細情報が含まれます。ExcelのPower QueryでAuditDataを複数列に展開すると、RecordType、Operation、対象ファイル、IPアドレスなどを絞り込みやすくなります。ただし、Audit（Standard）の単一検索エクスポート上限は50,000件、Audit（Premium）は1,000,000件です。上限を超える場合は、日付範囲やユーザー、Operationで検索を分割する必要があります。(Microsoft Learn)
Graph APIを使う場合は、POST /security/auditLog/queriesで監査ログ検索クエリを作成し、GET /security/auditLog/queries/{auditLogQueryId}/recordsでレコードを取得します。権限はサービス別に分類されており、最小権限としてAuditLogsQuery-Entra.Read.Allなどを選び、必要に応じてExchange、SharePoint、OneDrive、Endpoint、CRM、または包括的なAuditLogsQuery.Read.Allを検討します。(Microsoft Learn)
Office 365 Management Activity APIは、SIEMや監視基盤へ監査ログを継続的に取り込む用途に向いています。Audit.AzureActiveDirectory、Audit.Exchange、Audit.SharePoint、Audit.General、DLP.Allなどのコンテンツタイプがあり、サブスクリプションを作成してからポーリングまたはWebhookで新しいコンテンツを取得します。サブスクリプション作成後、最初のコンテンツBlobが利用可能になるまで最大12時間かかる場合があり、イベントの並び順も必ずしも発生順とは限りません。(Microsoft Learn)
API連携ではスロットリングも重要です。Office 365 Management Activity APIでは、各組織に初期値として毎分2,000リクエストのベースラインが割り当てられますが、応答率はクライアント性能やネットワーク状況などにも依存し、Microsoftは一定の応答率を保証していません。Audit（Premium）では、E5系組織において非E5系より約2倍の帯域が提供されると説明されています。(Microsoft Learn)
検索時に失敗しやすいポイント
キーワード検索はAuditData全体を検索するわけではない
PurviewポータルのKeyword Searchは、Audit common schemaのインデックス化された内容を検索します。AuditData内のすべての詳細プロパティを全文検索するものではありません。ファイル名、サイト、ユーザー、Operation、Record typeなど、検索条件を分けて指定するほうが精度は上がります。(Microsoft Learn)
Operation名は完全一致で入力する
Operations namesで検索する場合、Operation名は正確に入力する必要があります。誤字があると結果は返りません。公式情報では、該当するOperation名をドキュメントからコピーして貼り付けることが推奨されています。Operation名にピリオドが含まれる場合は、PowerShellやポリシー作成時にそのピリオドも含める必要があります。(Microsoft Learn)
監査ログは即時に出るとは限らない
監査対象の操作が発生しても、すぐ検索結果に現れるとは限りません。Exchange、SharePoint、OneDrive、Teamsなどのコアサービスでは、監査レコードの可用性は通常60〜90分後と説明されていますが、Microsoftは特定の時間を保証していません。インシデント対応では、初回検索で出ない場合に時間を置いて再検索する手順を決めておくべきです。(Microsoft Learn)
検索範囲とエクスポート範囲を広げすぎない
広すぎる日付範囲や全アクティビティ検索は、時間がかかるだけでなく、エクスポート上限に達して一部ログが含まれないリスクがあります。実務では、最初に「対象ユーザー」「対象期間」「対象ワークロード」「対象Operation」を仮説として絞り、その後に範囲を広げる方法が有効です。
例として、SharePointの外部共有を調べる場合は、最初から全ログを検索するのではなく、SharePointSharingOperationのRecord typeや関連Operation、対象ユーザー、問題が発生した日の前後数日で絞り込みます。結果が少なすぎる場合に期間や対象者を拡張するほうが、調査の再現性が高くなります。
Power BIなど一部サービスは追加設定が必要な場合がある
Microsoft Purviewの統合監査ログが有効でも、サービス側の監査設定が別途必要なケースがあります。たとえばPower BIアクティビティを監査ログで検索するには、Power BI管理ポータルで監査を有効にする必要があると説明されています。(Microsoft Learn)
また、Microsoft 365外のAIデータや外部接続されたAIアプリケーションとのユーザー操作を監査する場合、組織で従量課金を有効化する必要があるケースがあります。Copilot in Microsoft Fabric、Microsoft Security Copilot、Microsoft Copilot Studio、接続済みクラウドAIアプリケーションなどを扱う組織は、通常のMicrosoft 365監査ログだけで足りるかを確認してください。(Microsoft Learn)
移行・展開時の実務チェックリスト
Microsoft Purviewの監査を既存運用に組み込む場合は、機能を有効にするだけでなく、調査フローとして成立するかを確認します。
| チェック項目 | 確認内容 | 完了の目安 |
|---|---|---|
| 監査ログの有効化 | UnifiedAuditLogIngestionEnabledがTrueか | Exchange Online PowerShellで確認済み |
| ロール設計 | Audit ReaderとAudit Managerを分けているか | 最小権限で割り当て済み |
| ライセンス | Standardで足りるか、Premiumが必要か | 調査要件と保持期間で判断済み |
| 保持ポリシー | 180日、1年、10年の対象が明確か | ユーザー・ワークロード単位で設計済み |
| 検索手順 | 代表的な調査パターンをテンプレート化したか | 侵害、外部共有、削除、権限変更で手順化 |
| API連携 | Graph APIまたはManagement Activity APIの選択理由が明確か | 権限、スロットリング、再試行を設計済み |
| エクスポート | CSV上限とPower Query整形手順を理解しているか | 分割検索ルールを用意済み |
| AI/Copilot関連 | 対象ログと追加課金・設定を確認したか | 対象サービスごとに確認済み |
移行時に特に避けたいのは、旧手順のまま「90日保持」「Classic Search」「全件エクスポート前提」で運用し続けることです。現在の運用では、180日保持、New Search、Premium保持ポリシー、API連携、エクスポート上限を前提に、調査シナリオごとの検索条件を作る必要があります。
管理者と開発者が次に取るべき行動
まずは、Microsoft PurviewポータルでAuditソリューションにアクセスし、監査ログ検索ができるロールを持つ管理者を確認してください。次に、Exchange Online PowerShellで監査ログ検索の有効化状態を確認し、代表的な操作ログを実際に検索します。ここまでで「ログが取れているか」「誰が見られるか」「何日前まで見られるか」が分かります。
そのうえで、半年を超える調査要件がある部門、役員・特権管理者、法務対応が必要なユーザーを洗い出し、Audit（Premium）や10年保持アドオンの必要性を判断します。SIEMや自社アプリに取り込む場合は、Graph APIで検索ジョブを扱うのか、Office 365 Management Activity APIで継続収集するのかを分けて設計します。
Microsoft Purviewの監査は、インシデントが起きてから整備しても間に合いません。公開・更新された公式情報を踏まえ、今のうちに「検索できる状態」「保持できる状態」「必要な人だけがアクセスできる状態」を作っておくことが、セキュリティ運用と監査対応の両方で最も効果的です。
コメント