Microsoft Purview Data Security Investigations（データ セキュリティ調査）の今回の更新で、管理者がまず押さえるべき点は「調査担当者への通知」と「検索クエリ作成の改善」です。AI ジョブの完了や調査スコープへの新しいデータ追加など、調査中に見落とすと対応が遅れやすいイベントを通知で把握しやすくなります。あわせて、影響を受けた可能性のあるデータを探すためのクエリ作成も改善されます。Microsoft 365 ロードマップ ID は 560325、対象は Microsoft Purview、Web、Worldwide（Standard Multi-Tenant）、一般提供予定は 2026 年 6 月です。(Microsoft)
この更新は、単に画面が少し便利になるだけではありません。データ漏えい、内部不正、資格情報の露出、機密データの持ち出し調査では、「AI 分析が終わったことに気づかない」「検索条件が曖昧で関係ないデータまでスコープに入る」「追加データを誰が確認するか不明」といった運用上の遅れが起こりがちです。今回の変更は、そうした調査ワークフローの滞留を減らすための更新と捉えると、管理者が確認すべきポイントが明確になります。
Microsoft Purview Data Security Investigationsとは
Microsoft Purview Data Security Investigations は、組織のサイバーセキュリティチームが生成 AI を使って、データ セキュリティ インシデント、危険なインサイダー、データ侵害を分析・対応するための機能です。機密データ露出のリスクをすばやく特定し、関係チームと連携して修復するために使われます。(Microsoft Learn)
具体的には、次のような場面で使います。
- 退職予定者や高リスクユーザーによる機密ファイルの持ち出し調査
- SharePoint、OneDrive、Exchange Online などに残る影響データの特定
- 漏えいした可能性がある個人データ、資格情報、財務情報の確認
- Microsoft Defender XDR や Insider Risk Management からのインシデント深掘り
- Data Security Posture Management（DSPM）の分析情報からの追加調査
Data Security Investigations では、検索、スコープ追加、AI 分析、分類、調査、軽減策の検討を反復しながら進めます。Microsoft のドキュメントでも、調査ワークフローは線形ではなく、検索・証拠収集・分類・調査を何度も微調整するプロセスとして説明されています。(Microsoft Learn)
今回の更新で何が変わるのか
今回の「Microsoft Purview: Data Security Investigations – notification and improved search capabilities」では、大きく次の 2 点が追加・改善されます。
| 変更点 | 内容 | 管理者・調査担当者への影響 |
|---|---|---|
| 通知機能 | AI ジョブ完了、新しいデータのスコープ追加など、重要な調査イベントを調査担当者に通知 | 待ち時間や確認漏れを減らし、次の分析・レビュー・軽減対応に移りやすくなる |
| 検索機能の改善 | 影響を受けた可能性のあるデータを見つけやすくするため、クエリ作成が改善 | 調査初期の検索条件作成、範囲の絞り込み、過剰なデータ取り込みの抑制に役立つ |
| 対象環境 | Worldwide（Standard Multi-Tenant）、Web | 主に商用クラウドの標準マルチテナント環境で影響を確認すべき |
| 提供段階 | General Availability、In development | 2026 年 6 月の一般提供予定に向け、事前確認が必要 |
Microsoft 365 ロードマップでは、この機能は 2026 年 4 月 16 日に作成され、2026 年 5 月 12 日 23:00 UTC に更新されています。日本時間では 2026 年 5 月 13 日相当の更新として扱うのが自然です。なお、ロードマップ情報は変更される可能性があるため、展開直前には管理センターや公式ロードマップで再確認してください。(Microsoft)
通知機能のポイント：AIジョブ完了とスコープ追加の見落としを防ぐ
Data Security Investigations では、調査中に複数のジョブが走ります。たとえば、検索結果を調査スコープに追加すると、対象アイテムの処理、インデックス再作成、AI 分析の準備などが発生します。アクティビティ履歴には、検索、調査範囲、AI 分析、軽減アクティビティに関連する情報が記録されます。(Microsoft Learn)
これまでは、担当者がアクティビティ画面を見に行き、ジョブの完了状況を確認する運用になりがちでした。今回の通知機能により、少なくとも次のようなイベントを調査担当者が把握しやすくなります。
- AI ジョブが完了した
- 新しいデータが調査スコープに追加された
- 次のレビューや分析に移るべき状態になった
- 調査対象が更新され、再確認が必要になった
特に効果が出やすいのは、担当者が複数の調査を並行して扱う環境です。たとえば、内部不正調査と外部漏えい調査が同時に進んでいる場合、AI 分析の完了を手作業で何度も確認するのは非効率です。通知によって「次に見るべき調査」を判断しやすくなります。
通知機能で変わる実務フロー
通知が追加されると、調査担当者の動きは次のように変わります。
| 従来起こりやすい運用 | 更新後に期待できる運用 |
|---|---|
| AI 分析の完了を手動で確認する | 完了通知を受けてレビューに移る |
| スコープ追加後、誰が確認するか曖昧になる | 新規データ追加を通知で把握し、担当者が確認する |
| 調査が長時間止まっていても気づきにくい | 重要イベントをきっかけに次のアクションを取りやすい |
| 複数案件で優先順位が見えにくい | 通知内容をもとに対応順を決めやすい |
ただし、通知が増えるほど「通知疲れ」も起こります。すべての担当者にすべての通知を受け取らせるのではなく、調査責任者、一次分析担当、レビュー担当、軽減策担当の役割を分け、どのイベントを誰が確認するかを決めておくことが重要です。
検索改善のポイント：調査スコープを広げすぎない
今回の検索改善では、影響を受けた可能性のあるデータを識別しやすくするため、クエリ作成が強化されます。Data Security Investigations では、調査を作成した後、検索ツールを使ってメール、ドキュメント、メッセージなどの関連コンテンツを特定します。Microsoft は、調査範囲にデータ項目を追加する前に、できるだけ結果を絞り込むことを推奨しています。(Microsoft Learn)
これは実務上とても重要です。検索条件が広すぎると、次の問題が起こります。
- 関係ないファイルまで調査スコープに入る
- AI 分析やレビューの対象が増え、調査が遅くなる
- 関係者への共有や軽減策の判断が難しくなる
- コストや容量の見積もりが読みづらくなる
反対に、検索条件が狭すぎると、漏えいした可能性のあるファイルを見逃します。今回のクエリ作成改善は、この「広すぎる」と「狭すぎる」の間を調整しやすくする更新と考えるとよいでしょう。
検索条件を作るときの判断基準
調査担当者は、検索クエリを作る前に次の観点を整理しておくと、改善された検索機能を活かしやすくなります。
| 観点 | 確認すること | 例 |
|---|---|---|
| 対象ユーザー | 誰の操作・所有データを調査するか | 退職予定者、特定部門、外部共有を行ったユーザー |
| 対象期間 | いつからいつまでの操作を見るか | 退職通知後の 30 日間、インシデント検知前後 7 日間 |
| データ種別 | 何を探すか | 顧客リスト、契約書、設計資料、資格情報、個人データ |
| 保存場所 | どこを探すか | SharePoint サイト、OneDrive、Exchange Online、Teams 関連コンテンツ |
| 操作内容 | どのアクティビティに注目するか | ダウンロード、コピー、外部共有、ラベル変更、削除 |
たとえば「営業部の退職予定者が顧客情報を持ち出した可能性がある」という調査では、最初から全社の顧客関連ファイルを検索するのは広すぎます。対象ユーザー、対象期間、OneDrive と関連 SharePoint サイト、ファイル名やキーワード、ダウンロードやコピーなどの操作に分解して検索条件を組み立てるべきです。
監査検索・クエリビルダー・ベクター検索の使い分け
Data Security Investigations では、検索といっても目的が異なる機能があります。今回の検索改善を理解するには、監査検索、クエリビルダー、ベクター検索の違いを押さえておくと実務で迷いにくくなります。
| 機能 | 向いている場面 | 使い方の例 |
|---|---|---|
| クエリビルダー | Microsoft 365 コンテンツを条件で検索したい | 特定キーワード、場所、ファイル種別、ユーザー条件で候補データを探す |
| 監査検索 | ユーザー操作を起点に関連コンテンツを集めたい | ファイルアクセス、コピー、ダウンロード、アップロード、秘密度ラベル変更を調べる |
| ベクター検索 | キーワード一致だけでは見つけにくい関連データを探したい | 「認証情報が含まれる資料」「顧客の個人情報を含む文書」など意味ベースで探す |
監査検索では、統合監査ログに記録されたユーザーアクティビティをもとにコンテンツを特定・収集できます。対象アクティビティには、ファイルアクセス、コピー、削除、ダウンロード、移動、アップロード、秘密度ラベル変更、送信済みメールなどが含まれます。(Microsoft Learn)
一方、ベクター検索は、調査スコープに追加したデータをコンテキストで検索する機能です。単なるキーワード一致ではなく、クエリに含まれる単語やフレーズの意味、意図、文脈を理解する検索として説明されています。(Microsoft Learn)
実務では、まず監査検索やクエリビルダーで「対象になりそうなデータ」を集め、調査スコープに追加した後、ベクター検索や分類で深掘りする流れが使いやすいです。
影響範囲：誰が確認すべきか
今回の更新は、Microsoft Purview を利用するすべてのユーザーに同じ影響があるわけではありません。主に影響を受けるのは、Data Security Investigations を使っている、または今後使う予定のセキュリティ・コンプライアンス担当者です。
| 対象者 | 確認すべきこと |
|---|---|
| Microsoft Purview 管理者 | 対象テナント、ロール、通知を受け取る担当者、利用手順 |
| セキュリティ運用担当 | AI ジョブ完了後のレビュー手順、インシデント対応フロー |
| コンプライアンス担当 | 調査スコープ追加時の承認、証跡、監査ログ確認 |
| Insider Risk Management 担当 | 内部不正調査から Data Security Investigations へ連携する流れ |
| SOC・CSIRT | 通知を起点にしたエスカレーション基準 |
| 開発者・自動化担当 | 監査ログ、Graph beta API、通知後の運用連携。ただし本更新自体は Web 機能であり、API 仕様変更とは限らない |
開発者が注意すべき点は、今回のロードマップ項目が「通知機能と検索改善」を示しているだけで、外部 API の安定版追加や既存 API の変更を明示しているわけではない点です。Microsoft Graph beta には Data Security Investigations の監査レコードを表すリソースが掲載されていますが、beta API は変更される可能性があり、本番環境での利用はサポートされないとされています。(Microsoft Learn)
管理者が事前に確認すべき設定
今回の更新に備えるなら、まず確認すべきは「通知の前に、そもそも誰が調査にアクセスできるのか」です。
Data Security Investigations にアクセスするには、適切なアクセス許可が必要です。Microsoft のドキュメントでは、コンプライアンス管理者ロール グループと組織管理ロール グループのメンバーは管理および共同作成者アクセスを持ち、Data Security Management ロール グループと Insider Risk Management ロール グループのメンバーは共同作成者アクセスを持つと説明されています。また、AI 容量を構成するには Data Security Investigations Admins ロール グループのメンバーである必要があります。(Microsoft Learn)
確認チェックリスト
| 確認項目 | 実施内容 | 失敗しやすいポイント |
|---|---|---|
| ロール グループ | 調査担当者、管理者、レビュー担当者の権限を確認 | 退職者や異動者がロールに残っている |
| 通知の受信者 | 誰が重要イベントを受け取るべきか整理 | 全員に通知して誰も見なくなる |
| 調査フロー | 通知後に誰がレビュー・判断・軽減策へ進むか決める | 通知を受けても次の担当が不明 |
| AI 容量と課金 | AI 分析の利用量、容量、課金設定を確認 | 検索範囲が広すぎて分析対象が膨らむ |
| 監査ログ | 調査アクティビティが監査できるか確認 | 証跡確認の担当が決まっていない |
| 検索テンプレート | よくあるインシデント別に検索条件の型を作る | 毎回ゼロから検索条件を作る |
通知機能は便利ですが、権限設計が曖昧なまま導入すると、不要な人に調査イベントが届いたり、逆に必要な担当者が通知を受け取れなかったりします。特に、個人データや内部不正に関わる調査では、最小権限の原則を守り、調査に関与する人を絞ることが重要です。
移行や展開で注意すべきこと
今回の更新は、既存機能の廃止や強制的な移行を伴うものとしては案内されていません。したがって、大規模な移行プロジェクトというより、既存の Data Security Investigations 運用を見直すタイミングと考えるのが現実的です。
ただし、展開時には次の点に注意してください。
通知を運用ルールに組み込む
通知が来るようになっても、対応ルールがなければ効果は限定的です。たとえば次のように、通知ごとの対応を決めておきます。
| 通知イベント | 推奨アクション |
|---|---|
| AI ジョブ完了 | 調査担当者が結果を確認し、重大度を仮判定する |
| 新しいデータがスコープに追加 | 追加理由、対象データ、検索条件を確認する |
| 分析対象が増えた | AI 分析やレビューの優先順位を見直す |
| 調査の次工程に進める状態 | レビュー担当または軽減策担当へ引き継ぐ |
通知を Microsoft Teams やチケット管理とどう連携するかは、公式ロードマップ項目だけでは明示されていません。現時点では、Purview 側で提供される通知を確認し、自社のインシデント管理フローに手作業または既存の運用ルールで組み込む前提で設計すると安全です。
検索クエリの標準化を先に進める
検索機能が改善されても、組織内で検索条件の作り方が属人化していると効果が出にくくなります。よくある調査パターンごとに、検索条件の「型」を作っておきましょう。
退職予定者の持ち出し調査
- 対象ユーザー：退職予定者、関連する代理アカウント
- 対象期間：退職通知日から最終出社日まで
- 対象操作：ダウンロード、コピー、外部共有、ファイル移動
- 対象場所：本人の OneDrive、所属部門の SharePoint サイト
- キーワード：顧客名、案件名、契約、見積、価格表、設計、個人情報
資格情報露出の調査
- 対象データ：パスワード、シークレット、API キー、接続文字列らしき文字列
- 対象場所：開発部門の SharePoint、Teams、メール添付
- 検索方法：キーワード検索とベクター検索を併用
- 確認ポイント：本物の資格情報か、サンプル文字列か、期限切れか
個人データ漏えいの調査
- 対象データ：氏名、メールアドレス、住所、電話番号、顧客 ID
- 対象期間：インシデント検知前後
- 対象操作：外部送信、ダウンロード、共有リンク作成
- 確認ポイント：対象人数、データ種別、保存場所、外部共有の有無
検索条件を標準化しておくと、改善されたクエリ作成機能を使う際に、調査担当者が判断に迷いにくくなります。
調査スコープ追加時の注意点
Data Security Investigations では、検索結果を調査スコープに追加した後、そのデータを AI 分析やレビューに使います。アクティビティ履歴の説明では、スコープに追加する処理により、アイテムが Azure ストレージの場所にコピーされ、再インデックスされ、その新しいインデックスでクエリと分析が可能になると説明されています。(Microsoft Learn)
そのため、スコープに追加する前の絞り込みが重要です。特に次の失敗は避けたいところです。
- 「念のため」で大量のデータを追加する
- 検索条件を保存せず、後から再現できない
- 追加したデータの根拠を記録していない
- 関係ない部署やユーザーのデータまで含める
- AI 分析結果だけで判断し、人手の確認を省く
Microsoft のベストプラクティスでも、AI の提案は隠れた問題の発見に役立つ一方で、重要な結果は常に人間の判断で検証すべきとされています。(Microsoft Learn)
開発者・自動化担当が見るべきポイント
今回のロードマップ項目は Web プラットフォーム向けの機能として記載されています。そのため、開発者が最初に見るべきポイントは「コードの修正」ではなく、「既存の自動化や監査連携に影響が出るか」です。
確認すべき項目は次の通りです。
| 確認対象 | 見るべきポイント |
|---|---|
| 監査ログ収集 | Data Security Investigations 関連のアクティビティを既存 SIEM やログ基盤で拾っているか |
| チケット運用 | 通知を受けた後、手動でチケット化するのか、既存フローで扱うのか |
| Graph beta API | beta API を本番運用に使っていないか |
| レポート | AI ジョブ完了、スコープ追加、検索実行などを管理レポートに含めるか |
| 権限管理 | 自動化用アカウントに過剰な Purview 権限を付けていないか |
特に beta API は注意が必要です。Microsoft Graph beta の Data Security Investigations 関連リソースは変更される可能性があり、本番アプリケーションでの使用はサポートされません。監査データの取り込みや可視化を自動化する場合は、正式版 API の有無、利用条件、監査ログ経由で代替できるかを確認してください。(Microsoft Learn)
導入前にやるべき実務チェック
2026 年 6 月の一般提供に向けて、管理者は次の順番で準備すると無駄が少なくなります。
| 優先度 | 作業 | 目的 |
|---|---|---|
| 高 | Data Security Investigations を使う担当者を洗い出す | 通知対象と権限を整理する |
| 高 | ロール グループを確認する | 最小権限で調査できる状態にする |
| 高 | 代表的な調査シナリオを 3〜5 個定義する | 検索条件の標準化に使う |
| 中 | 通知後の対応フローを作る | 通知を受けても放置されないようにする |
| 中 | 調査スコープ追加の承認ルールを決める | 過剰なデータ取り込みを防ぐ |
| 中 | 監査ログとアクティビティ履歴の確認方法を共有する | 調査証跡を残す |
| 低 | チケット管理や SOC 運用との連携を検討する | 継続的な運用に組み込む |
まずは、実際に Data Security Investigations を使う人を明確にしてください。機能更新に合わせて全員に権限を付けるのではなく、調査責任者、分析担当者、レビュー担当者、承認者に分けるのが安全です。
よくある疑問
今回の更新で既存の調査データは移行が必要か
公式ロードマップ項目では、既存データの移行や廃止機能は示されていません。現時点では、通知機能と検索改善が追加される更新として捉えるのが妥当です。ただし、一般提供前後に仕様や画面が変わる可能性はあるため、展開時には管理センターのメッセージや公式ロードマップを確認してください。
すべてのテナントで同時に使えるようになるのか
対象クラウドは Worldwide（Standard Multi-Tenant）です。Microsoft 365 ロードマップでは一般提供予定が 2026 年 6 月とされていますが、ロードマップのリリース予定は変更されることがあります。また、ロールアウトは段階的に進む場合があります。(Microsoft)
通知だけでインシデント対応は十分か
不十分です。通知は「次の行動に移るためのきっかけ」です。重要なのは、通知を受けた後に誰が結果を確認し、誰がリスクを判断し、誰が軽減策を実行するかです。通知機能を導入する際は、インシデント対応手順書やチケット運用とセットで見直してください。
検索改善があればベクター検索だけでよいのか
いいえ。ベクター検索は意味や文脈に基づく検索に強みがありますが、監査検索やクエリビルダーには別の役割があります。ユーザー操作を起点に調べるなら監査検索、保存場所や条件を明確に指定するならクエリビルダー、キーワードだけでは拾いにくい関連情報を探すならベクター検索、という使い分けが現実的です。
まとめ：通知と検索改善は、調査スピードより「判断の遅れ」を減らす更新
Microsoft Purview Data Security Investigations の今回の更新は、通知機能と検索クエリ作成の改善により、調査担当者が重要なタイミングを見逃しにくくし、影響データをより適切に探せるようにするものです。AI ジョブ完了やスコープ追加を通知で把握できれば、レビュー、分類、軽減策の判断に移るまでの空白時間を減らせます。
管理者が今やるべきことは、機能の一般提供を待つだけではありません。調査担当者のロール確認、通知後の対応ルール、検索条件の標準化、調査スコープ追加の判断基準を先に整えておくことです。特に、検索範囲を広げすぎないこと、AI 分析結果を人間が検証すること、監査ログとアクティビティ履歴で証跡を残すことは、実運用で失敗しないための重要なポイントです。
まずは自社の代表的なデータ漏えい・内部不正・資格情報露出シナリオを 3 つ選び、誰が通知を受け、どの検索条件で調査を始め、どの基準でスコープに追加するかを文書化してください。今回の更新は、その運用設計ができている組織ほど効果を発揮します。
コメント