Microsoft Purview Data Security Investigationsは、データ侵害や内部不正の疑いがあるときに、関連するメール、ファイル、Teamsメッセージ、SharePoint/OneDrive上のデータなどを集め、生成AIでリスクを分析するための調査機能です。特に今回押さえるべきポイントは、AI分析の準備自動化、標準カテゴリ分け、OCR対応、DSPMや監査ログとの連携強化により、調査開始からリスク把握までの手作業が減る一方で、権限・課金・AI結果の検証体制を事前に整える必要がある点です。
Microsoft Purviewをすでに使っている管理者は、「機能を有効にするか」だけでなく、誰が調査を作成できるのか、AI分析にどこまで課金上限を設けるのか、調査対象に画像やスキャンPDFが含まれる場合にどのような確認プロセスを追加するのかを見直すべきです。開発者やセキュリティ担当者は、ソースコード、APIキー、接続文字列、設計資料などが漏えい調査の対象になり得ることを前提に、保管場所と分類ルールを整理しておくと実務で役立ちます。
Microsoft Purview Data Security Investigationsとは
Microsoft Purview Data Security Investigationsは、組織内のサイバーセキュリティチームが、データセキュリティインシデント、危険な内部関係者、データ侵害に対応するための調査機能です。Microsoftの公式説明では、生成AIを使って影響を受けたデータを分析し、機密データの露出リスクを素早く特定し、関係チームと連携して是正につなげることが目的とされています。(Microsoft Learn)
従来のデータ侵害調査では、監査ログ、DLPアラート、メール、ファイル共有、チャット履歴を別々の画面で確認し、怪しいファイルを手作業で分類するケースが少なくありませんでした。Data Security Investigationsは、この分断を減らし、調査対象データの検索、AIによる内容分析、リスク評価、軽減策の検討をMicrosoft Purview内で進めやすくします。
主な用途は次のとおりです。
| 利用シーン | 具体例 | 確認すべき観点 |
|---|---|---|
| データ侵害調査 | 攻撃者にアクセスされた可能性があるSharePointファイルを確認する | どの機密情報が含まれるか、誰がアクセスしたか |
| 内部不正・持ち出し調査 | 退職予定者が大量のファイルを外部共有した疑いを調査する | 顧客情報、知的財産、認証情報の有無 |
| DLP・監査ログ起点の調査 | ファイルダウンロードやラベル変更の監査ログから関連ファイルを集める | 行動とコンテンツの関係 |
| 予防的なリスク評価 | DSPMで検出されたデータ露出リスクを深掘りする | 継続的に危険なデータが露出していないか |
ポイントは、Data Security Investigationsが単なる検索ツールではないことです。検索したファイルやメッセージをAI分析の対象に追加し、カテゴリ分け、ベクトル検索、詳細な検査を組み合わせて「どのデータを優先的に対処すべきか」まで判断しやすくします。
2026年5月下旬時点で押さえるべき主な変更点
今回の更新で特に重要なのは、Data Security InvestigationsのAI分析がより実務寄りになっている点です。すべての組織で同じ影響が出るとは限りませんが、Microsoft 365の標準マルチテナント環境でPurviewを利用している管理者は確認しておきたい内容です。
| 変更点 | 内容 | 管理者への影響 |
|---|---|---|
| OCRサポートの追加 | 画像内の文字を抽出し、調査データに取り込む | 画像やスキャン資料に含まれる機密情報も調査対象になり得る |
| AI分析準備の自動化 | 調査に追加されたデータをAI分析向けに準備しやすくする | 調査時間は短縮されるが、スコープ管理と課金管理が重要になる |
| 標準カテゴリ分けの追加 | 標準カテゴリと高度なカテゴリ分けを使い分け可能 | コストと精度のバランスを判断する必要がある |
| カスタム検査の追加 | 調査目的に応じて独自の検査観点を設定できる | 自社固有の機密情報、開発資産、業務コード名を調査しやすくなる |
| DSPM連携の強化 | DSPMで検出したデータ流出リスクをDSIで深掘り可能 | 事後対応だけでなく、予防的なデータリスク管理に使いやすくなる |
| 監査ログ・DLP起点の調査強化 | Unified Audit LogやEndpoint DLPアラートから関連ファイルを調査に取り込む | SOC、DLP、情報保護チームの連携が重要になる |
Microsoft 365 Roadmapでは、OCRサポートについて、Data Security Investigationsが画像からテキストを抽出して調査データに組み込み、視覚コンテンツ内に隠れたデータセキュリティリスクをAI分析で見つけやすくすると説明されています。プレビューは2026年5月、一般提供は2026年7月予定で、2026年5月27日に更新されています。(Microsoft)
また、AI分析強化では、標準カテゴリ分けと高度なカテゴリ分けを選べるようになり、調査にデータを追加する際にAI分析の準備を自動化する方向が示されています。(Microsoft)
AIは何を分析するのか
Data Security InvestigationsのAI分析は、大きく分けて「ベクトル検索」「カテゴリ分け」「検査」の3つで理解すると分かりやすくなります。Microsoft Learnでは、Data Security Investigationsが生成AI、LLM、オーケストレーションを使って組織内データを分析する一方、AIの結果は常に正確または完全とは限らないため、検証して慎重に扱う必要があると明記されています。(Microsoft Learn)
ベクトル検索
ベクトル検索は、単純なキーワード一致ではなく、検索意図や文脈をもとに関連データを探す仕組みです。たとえば「Contoso Securityプロジェクトに関する機密データ」と検索した場合、ファイル本文にその言葉が完全一致していなくても、関連する文書、メール、記録を見つけやすくなります。Microsoft Learnでは、ベクトル検索は調査範囲内のデータに対してAI埋め込みを使い、意味的に関連する項目を返すと説明されています。(Microsoft Learn)
実務では、次のような使い方が向いています。
| 調査したい内容 | 検索例 |
|---|---|
| 認証情報の漏えい | 「パスワード、APIキー、接続文字列、秘密鍵を含む資料」 |
| 開発情報の持ち出し | 「未公開機能、設計仕様、ソースコード、脆弱性修正に関する文書」 |
| 顧客情報の露出 | 「顧客リスト、契約情報、請求情報、本人確認情報」 |
| 役員・法務関連資料 | 「買収、訴訟、未発表の財務情報に関する文書」 |
キーワード検索だけに頼ると、「secret」「password」のような英語表記は拾えても、日本語の「認証情報」「接続情報」「本番環境キー」などを見落とすことがあります。ベクトル検索はその穴を埋める手段として有効です。
カテゴリ分け
カテゴリ分けは、大量の調査対象データをリスクや内容ごとに整理し、優先順位を付けるための機能です。Microsoft Learnでは、標準または高度なAIカテゴリ分けを使い、既定カテゴリ、カスタムカテゴリ、AIが提案するカテゴリでデータを整理できると説明されています。標準カテゴリ分けは関連度スコアに基づいて選択カテゴリへ分類し、高度なカテゴリ分けではカテゴリ内の具体的なトピックまで追加処理します。(Microsoft Learn)
使い分けの目安は次のとおりです。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| 標準カテゴリ分け | まず全体像を把握したい、費用や時間を抑えたい | 詳細なトピック分析までは期待しすぎない |
| 高度なカテゴリ分け | 侵害規模が大きく、内容の内訳まで深掘りしたい | 処理時間とコンピュート使用量が増える可能性がある |
| カスタムカテゴリ | 自社固有のプロジェクト名、製品コード、機密用語を追いたい | カテゴリ名が曖昧だと結果も曖昧になりやすい |
カテゴリ分けは、すべてのデータを完全に網羅的に判定するというより、各カテゴリに対して関連性の高いデータを優先的に浮かび上がらせる機能です。Microsoft Learnでも、カテゴリ分けは各カテゴリの最も関連性の高いコンテンツを優先表示するもので、調査範囲内の全アイテムを網羅分析するものではないと説明されています。(Microsoft Learn)
検査
検査は、確認対象として絞り込んだアイテムに対し、より具体的なリスクを調べる機能です。公式情報では、Credentials、Risk、Mitigation、Personal data、Customといった検査観点が示されています。たとえばCredentialsでは認証情報、Personal dataでは氏名、メールアドレス、社員ID、IPアドレスなどの個人データを確認できます。(Microsoft Learn)
2026年の更新では、個人データ検査やカスタム検査の追加も重要です。Microsoft 365 Roadmapでは、個人データ検査が選択アイテムから氏名、住所、銀行口座番号などの個人データを識別・抽出すると説明されています。(Microsoft) また、カスタム検査では調査の種類や重視する情報に応じて独自の検査観点を作成できるとされています。(Microsoft)
開発部門が関わる場合は、カスタム検査に次のような観点を用意すると実用的です。
| 部門 | カスタム検査の例 |
|---|---|
| 開発 | APIキー、JWTシークレット、SSH秘密鍵、DB接続文字列、CI/CDトークン |
| 情報システム | 管理者手順書、VPN設定、MFAバックアップコード、ネットワーク構成図 |
| 法務 | NDA対象資料、訴訟関連資料、未公開契約書 |
| 研究開発 | 試験データ、特許出願前資料、製品ロードマップ |
OCR対応で影響が大きいデータ
OCR対応は、見落とされやすい変更です。テキストファイルやOffice文書だけでなく、画像やスキャンPDFに含まれる文字も調査対象になりやすくなるためです。
Microsoft Learnでは、JPEG、PNG、スキャンPDFなどについて、OCRで画像からテキストを抽出したうえでベクトル化すると説明されています。(Microsoft Learn) また、対応ファイル種別のページでは、BMP、GIF、JPEG、PNG、SVG、TIFF、DWG/DXF、WMFなどの画像形式でOCRテキスト抽出に対応し、OCR処理はデータ準備時に自動で行われると説明されています。(Microsoft Learn)
実務上の影響は大きく、次のようなデータも調査で浮かび上がる可能性があります。
| データ例 | これまでの見落としリスク | OCR対応後の確認ポイント |
|---|---|---|
| 画面キャプチャ | パスワード、顧客情報、エラー画面が画像として残る | Teamsやメール添付のスクリーンショットを調査対象に含める |
| スキャンPDF | 紙の申込書や契約書が画像PDFとして保存される | 個人情報や署名済み契約書の露出を確認する |
| 設計図・構成図 | ネットワーク名やIPアドレスが図中に記載される | インフラ情報や接続情報の漏えいを確認する |
| ホワイトボード写真 | 未公開仕様やプロジェクト名が写る | 研究開発・企画部門の共有ルールを見直す |
注意したいのは、OCRは万能ではないことです。低解像度、手書き、斜めに撮影された画像、多言語が混在する資料では抽出精度に限界があります。重要な判断では、AIやOCRの結果だけでなく、原本確認と人によるレビューを組み合わせるべきです。
影響範囲：誰が何を確認すべきか
Data Security Investigationsの変更は、Purview管理者だけの話ではありません。SOC、DLP担当、内部不正調査担当、法務、開発部門まで影響します。
| 対象者 | 確認すべきこと | 放置した場合のリスク |
|---|---|---|
| Microsoft Purview管理者 | ロールグループ、課金設定、AI処理場所、利用状況ダッシュボード | 過剰権限、想定外の課金、調査不能 |
| SOC担当 | Defender XDR、監査ログ、DLPアラートからの調査導線 | インシデントとデータ影響の切り分けが遅れる |
| DLP・情報保護担当 | ラベル、DLPポリシー、外部共有、Endpoint DLPとの連携 | 検出後の深掘りや是正が属人的になる |
| 内部不正調査担当 | Insider Risk Managementからのエスカレーション手順 | 危険ユーザーのコンテンツ影響を見誤る |
| 開発者・DevSecOps | ソースコード、シークレット、設計資料の保管場所 | 漏えい時に影響範囲を特定できない |
| 法務・コンプライアンス | 個人データ、規制対象データ、証跡保存 | 通知義務や証跡保全の判断が遅れる |
特に管理者は、Data Security Investigationsを「便利なAI機能」としてだけ捉えないことが重要です。調査対象データには機密性の高い情報が含まれるため、誰に調査作成・AI実行・パージ権限を与えるかを最小権限で設計する必要があります。
管理者が確認すべき設定
ロールと権限を確認する
Data Security Investigationsを使うには、Microsoft Purviewポータルで適切な権限を割り当てる必要があります。公式ドキュメントでは、権限適用に最大30分かかる場合があること、Global Administratorの利用は最小限にすべきこと、Data Security Investigations Admins、Investigators、Reviewersなどのロールグループを用途に応じて使い分けることが示されています。(Microsoft Learn)
最低限、次の点を確認してください。
| 確認項目 | 推奨対応 |
|---|---|
| 管理者が1人だけになっていないか | Data Security Investigations Adminsに複数の適任者を配置する |
| Global Administratorで日常運用していないか | 専用ロールグループに権限を委任する |
| 調査担当者に過剰権限がないか | Admin、Investigator、Reviewerを分ける |
| パージ権限を誰が持つか | 削除操作は承認フローとセットで管理する |
| 退職・異動者が残っていないか | 定期棚卸しを行う |
Microsoft Learnでは、Compliance AdministratorやOrganization Managementなど一部のロールグループにもData Security Investigationsのアクセス権が含まれると説明されています。つまり、専用ロールだけを見ていても実際のアクセス権を把握しきれない場合があります。(Microsoft Learn)
課金とAI容量を設定する
Data Security Investigationsの課金は、専用のエンタープライズライセンスではなく、保存データ量とAI分析に必要なコンピュート容量の組み合わせで決まります。ストレージは調査に関連する保存データ量、AI容量はData Security Investigations Compute Unitsで測定されます。(Microsoft Learn)
管理者が特に注意すべきなのは、調査対象を広げすぎるとストレージとAI分析の両方でコストが増える点です。公式ドキュメントでも、調査スコープを絞ること、完了した調査を速やかに削除すること、利用状況ダッシュボードでストレージとコンピュート使用量を確認することが推奨されています。(Microsoft Learn)
初期導入では、次の順序で設定すると失敗しにくくなります。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 1 | Azureサブスクリプションとリソースグループを決める | Purview用の課金を追跡しやすい構成にする |
| 2 | ストレージメーターを有効化する | 調査データの保存コストを管理できる状態にする |
| 3 | AI容量を設定する | 最初は上限ありで開始し、利用実績を見て調整する |
| 4 | AI処理場所を選ぶ | 組織のデータ所在地、社内規程、応答性を考慮する |
| 5 | Azure Cost Managementで予算とアラートを設定する | 50%、75%、90%など段階的な通知を設ける |
| 6 | 月次で利用状況を確認する | 高コストな調査パターンを見直す |
AI容量の設定にはData Security Investigations Adminsロールグループのメンバーである必要があります。公式ドキュメントでは、AI処理場所としてANZ、EU、UK、USなどを選択でき、必要に応じて世界中の利用可能なGPU容量で処理する選択肢も説明されています。(Microsoft Learn)
DSPMのプロアクティブAIインサイトは課金に注意する
Data Security Posture Management、いわゆるDSPMとの連携も重要です。Microsoft Learnでは、DSPMのプロアクティブAIインサイトを有効にすると、最近流出した機密データを5つのリスクカテゴリで自動分析し、手動で調査を作らなくても継続的な可視性を提供すると説明されています。(Microsoft Learn)
一方で、DSPMによる自動作成調査は24時間ごとに更新されるため、ストレージとAI容量のコストが継続的に発生します。公式ドキュメントでも、トグルを有効にしている間は継続的な課金が発生すると説明されています。(Microsoft Learn)
導入時は、いきなり全社で有効化するのではなく、次のような段階的な展開が現実的です。
- 高リスク部門や重要データ領域を決める
- 1〜2か月分の利用量を測定する
- 調査で有用だったリスクカテゴリを確認する
- 不要なスコープや重複調査を削減する
- 月額予算とアラートしきい値を見直す
開発者・DevSecOpsが見直すべきポイント
開発者にとってData Security Investigationsは、直接コードを書くための機能ではありません。ただし、漏えい時に「どの開発資産が影響を受けたか」を調べるうえで大きく関係します。
特に確認すべきなのは、開発関連情報がMicrosoft 365上にどのように保存されているかです。
| 対象データ | よくある保管場所 | 見直すべきこと |
|---|---|---|
| APIキー・トークン | Teams、SharePoint、OneDrive、メール添付 | 本番シークレットを貼り付けない運用にする |
| 設計資料 | SharePointサイト、Teamsチャネル | 機密ラベルとアクセス権を付与する |
| 障害対応ログ | メール、Teams、OneNote | 個人情報や接続情報の混入を避ける |
| 画面キャプチャ | Teamsチャット、Wiki、SharePoint | OCRで検出される前提でマスキングする |
| ソースコード断片 | チャット、ドキュメント、レビュー資料 | リポジトリ外への貼り付けルールを決める |
実務で効果があるのは、Data Security Investigationsのカスタムカテゴリやカスタム検査で使う語彙を、開発部門と一緒に決めておくことです。たとえば「prod」「production」「connection string」「client secret」「秘密鍵」「本番DB」「障害調査ログ」など、現場で実際に使われる表現を登録候補にします。
セキュリティ部門だけでカテゴリを作ると、現場用語を拾えずに重要な情報を見落とすことがあります。逆に、開発部門だけで判断すると、法務・個人情報・知的財産の観点が抜けることがあります。両者で「漏えいしたら困るデータ辞書」を作るのが理想です。
調査開始までの実務手順
Data Security Investigationsを初めて使う場合は、機能を触る前に、権限・課金・調査テンプレート・レビュー体制を整えるとスムーズです。Microsoft Learnでは、初回アクセス時に条件を確認して同意し、権限を設定し、課金と使用状況を構成したうえで調査を作成する流れが示されています。(Microsoft Learn)
実務向けには、次の手順で進めるとよいでしょう。
| フェーズ | やること | 成果物 |
|---|---|---|
| 準備 | 管理者、調査担当、レビュアーを決める | ロール設計表 |
| 課金 | PAYG設定、AI容量上限、予算アラートを設定する | 課金設定メモ |
| 調査設計 | 典型シナリオを3つ決める | データ侵害、内部不正、DLPアラート対応の手順書 |
| テスト | 小規模データで検索、カテゴリ分け、検査を試す | 検証結果とコスト実績 |
| 展開 | SOC、DLP、開発、法務に手順を共有する | インシデント対応フロー |
| 運用 | 月次で権限、課金、調査件数、削除状況を確認する | 運用レビュー記録 |
Data Security Investigationsのワークフローは直線的なものではありません。Microsoft Learnでも、検索、証拠収集、分類、AIを使った調査は何度も反復しながら調整する必要があると説明されています。(Microsoft Learn)
失敗しやすいポイント
調査スコープを広げすぎる
最初から全社のSharePoint、OneDrive、Teamsを広く対象にすると、ノイズが増え、AI分析のコストも増えます。公式ドキュメントでも、調査範囲を最小限に絞ることが速度向上とコスト削減につながると説明されています。(Microsoft Learn)
初回調査では、次の順に広げるのが現実的です。
- 対象ユーザー
- 対象期間
- 関連サイト・メールボックス
- ファイル種別
- 検索条件
- 必要に応じて追加データソース
AIの結果をそのまま断定する
AI分析は調査を速くしますが、最終判断を代替するものではありません。Microsoftも、AI結果が常に正確または完全とは限らないため、検証が必要だと説明しています。(Microsoft Learn)
特に、懲戒、法的対応、顧客通知、規制当局への報告に関わる判断では、AI結果、原本、監査ログ、アクセス履歴、関係者ヒアリングを組み合わせて確認してください。
パージ操作を軽く扱う
Data Security Investigationsでは、リスクのあるアイテムを軽減計画に追加し、必要に応じてパージ操作を行えます。公式ワークフローでは、ソフトパージで回復可能なアイテムフォルダーへ移動し、ハードパージで完全削除できると説明されています。(Microsoft Learn)
パージは調査の最終段階で使うべき操作です。誤って証拠を消すと、法務・監査上の問題になる可能性があります。運用では、次のルールを決めておきましょう。
| ルール | 目的 |
|---|---|
| パージ前に法務またはコンプライアンス確認を入れる | 証跡保全の失敗を防ぐ |
| ソフトパージとハードパージの基準を分ける | 誤削除時の復旧余地を残す |
| パージクエリをレビューする | 対象外データの削除を防ぐ |
| 操作ログを保全する | 事後説明と監査に備える |
移行・展開時の注意点
既存のDLP、eDiscovery、Defender XDR、Insider Risk Managementを使っている組織では、Data Security Investigationsを追加することで調査導線が変わります。移行というより、「既存の検出機能からDSIへどうエスカレーションするか」を整理する作業が中心です。
Microsoft Learnでは、Defender XDRインシデント、Insider Risk Managementケース、DSPMインサイト、手動作成のフルドラフトモードから調査を作成できると説明されています。(Microsoft Learn) また、調査対象のデータソースとして、Exchange Online、Microsoft Copilot、Teams、OneDrive、SharePointが示されています。(Microsoft Learn)
展開時は、次のように役割を分けると運用が安定します。
| 領域 | 主担当 | DSIでの使い方 |
|---|---|---|
| Defender XDR | SOC | インシデントに関連するデータの影響範囲を確認 |
| Insider Risk Management | 内部不正調査担当 | 危険ユーザーが扱ったデータの内容を確認 |
| Endpoint DLP | DLP担当 | 持ち出し疑いのあるファイルを深掘り |
| Unified Audit Log | 監査担当 | ダウンロード、アクセス、ラベル変更から関連ファイルを収集 |
| DSPM | データセキュリティ担当 | 流出リスクを予防的に確認 |
Microsoft 365 Roadmapでは、Unified Audit LogのアクティビティからData Security Investigationsを起動し、時間範囲、アクティビティ、ユーザー、キーワードなどを指定して関連ファイルを調査に取り込める機能が示されています。(Microsoft) Endpoint DLPアラートから関連ファイルを自動収集する機能も、2026年6月のプレビューおよび一般提供予定として示されています。(Microsoft)
まず実施すべきチェックリスト
Data Security Investigationsを利用する、または今後の展開に備えるなら、最初に次のチェックリストを確認してください。
| チェック項目 | 完了の目安 |
|---|---|
| Data Security Investigations Admins、Investigators、Reviewersの割り当てを確認した | 過剰権限やゼロ管理者状態がない |
| Compliance AdministratorやOrganization Management経由のアクセス権も確認した | 想定外のアクセス者がいない |
| PAYGのストレージメーターとAI容量を設定した | Azure予算とアラートがある |
| AI処理場所を社内規程に照らして確認した | データ所在地や規制要件と矛盾しない |
| 標準カテゴリ分けと高度なカテゴリ分けの使い分けを決めた | 調査規模ごとの判断基準がある |
| OCR対象データの運用ルールを見直した | 画像・スキャンPDFの機密情報を想定している |
| カスタムカテゴリ・カスタム検査の候補を作った | 自社固有の機密語彙を反映している |
| パージ操作の承認フローを決めた | 証跡保全と削除手順が明確 |
| SOC、DLP、法務、開発部門の連携フローを作った | 調査結果を誰が判断するか決まっている |
Microsoft Purview Data Security Investigationsは、AIで調査を自動化する機能というより、調査対象を素早く絞り込み、人間が正しい判断を下すための支援基盤です。導入時は、まず小規模な調査シナリオで権限、課金、AI分析、OCR、パージ手順を検証し、結果をもとに全社運用へ広げるのが安全です。
次に取るべき行動は明確です。Purview管理者はロールとPAYG設定を確認し、セキュリティ担当は代表的なインシデントシナリオを1つ選んで検証環境で調査フローを試してください。開発部門は、ソースコード、シークレット、設計資料、画面キャプチャがMicrosoft 365上に散在していないかを棚卸しし、カスタム検査に使うべき社内用語をセキュリティチームへ共有しましょう。
コメント