Microsoft Purviewの「Scanner data export for custom reporting」は、情報保護スキャナーの結果をSQLテーブルに蓄積し、Power BIやSQLベースのレポート基盤で独自レポートを作りやすくする更新です。結論から言うと、オンプレミスのファイル共有やSharePoint ServerなどをMicrosoft Purview Information Protectionスキャナーでスキャンしている組織は、スキャナーのバージョン、SQL Serverの容量、レポート用の読み取り負荷、PowerShellでの有効化設定を事前に確認すべきです。
従来のようにスキャンごとのCSV/TXTレポートをつなぎ合わせる運用から、スキャナークラスターデータベースをレポートの土台として使う運用へ移行しやすくなります。ただし、2026年6月5日更新相当のMicrosoft 365 Roadmapではステータスが「In development」、Previewは2026年5月、GAは2026年8月とされており、ロードマップ情報は変更される可能性があります。(Microsoft)
Microsoft PurviewのScanner data export for custom reportingとは
「Microsoft Purview compliance portal: Scanner data export for custom reporting」は、Microsoft Purview Information Protectionスキャナーで取得したスキャン結果を、カスタムレポートに使いやすい形でSQL Server上のスキャナークラスターデータベースに保存する機能です。
対象になるのは、Microsoft Purview Information Protectionスキャナーを使って、オンプレミスのファイル共有やSharePoint Server上のファイルを検出、分類、ラベル付け、保護している環境です。スキャナーは、指定したデータストアを巡回してファイルを検査し、機密情報の種類やパターン検出を使って、ラベル付けや保護の判断を行います。リアルタイム検出ではなく、構成したサイクルに従ってクロールする仕組みです。(Microsoft Learn)
今回の更新で重要なのは、単なる「エクスポートボタンの追加」ではない点です。プレビュー中のCustom Reportingでは、スキャンされたファイルのラベル、保護状態、機密情報の種類、スキャン間の差分などを、SQLテーブルに蓄積してレポート作成に利用できます。Microsoft Learnでは、Power BI、エンタープライズレポートウェアハウス、SQLベースのダッシュボードツールなどに接続できることが説明されています。(Microsoft Learn)
今回の変更点をひとことで整理
これまでの情報保護スキャナーのレポート運用は、スキャンごとのCSV/TXTファイルを確認し、必要に応じて別のレポートツールに取り込む形が中心でした。Microsoft Learnでも、スキャン完了後のレポートは%localappdata%\Microsoft\MSIP\Scanner\Reportsに保存され、管理ポータルで見られるのは最後のスキャン情報であると説明されています。(Microsoft Learn)
Custom Reportingでは、スキャン結果の状態情報がスキャナークラスターデータベース側に蓄積されます。これにより、管理者は次のような問いに答えやすくなります。
| 確認したいこと | 従来の運用で起きやすい課題 | Custom Reportingで期待できる改善 |
|---|---|---|
| ラベル未設定だが機密情報を含むファイルはどれか | 複数回分のCSVを集約する必要がある | SQLクエリやPower BIで抽出しやすい |
| 前回スキャンからラベルが変わったファイルはどれか | 差分比較の処理を自作しがち | 以前のラベルや保護状態を使った比較がしやすい |
| リポジトリごとの機密情報の分布を見たい | ファイル単位のレポートを加工する必要がある | SITの種類や件数を集計しやすい |
| 監査・改善活動の証跡を残したい | スキャンごとのファイル管理に依存しやすい | SQLベースの履歴・集計に寄せられる |
Microsoft Learnでは、カスタムレポートを有効にすると、スキャンされたすべてのファイルの現在および以前のラベル、保護状態、SITカウント、スキャン間の差分、ファイルごとの一致した機密情報の種類などを照会できるとされています。(Microsoft Learn)
ロードマップ上の公開情報
2026年6月5日更新相当のMicrosoft公式APIでは、この項目はMicrosoft 365 Roadmap ID 494839として公開されています。対象製品はMicrosoft Purview、対象クラウドはWorldwide、GCC、GCC High、プラットフォームはDesktop、リリースリングはPreviewとGeneral Availabilityです。Previewは2026年5月、GAは2026年8月、ステータスはIn developmentとされています。(Microsoft)
| 項目 | 内容 |
|---|---|
| Roadmap ID | 494839 |
| 機能名 | Microsoft Purview compliance portal: Scanner data export for custom reporting |
| 対象サービス | Microsoft Purview |
| 対象クラウド | Worldwide、GCC、GCC High |
| プラットフォーム | Desktop |
| ステータス | In development |
| Preview | 2026年5月 |
| GA | 2026年8月 |
| 主な目的 | スキャン済みリポジトリの状態把握とカスタムレポート作成 |
| データの保存先 | スキャナークラスターデータベース上のSQLテーブル |
注意したいのは、Roadmapの予定日は確定したSLAではないことです。Microsoft 365 Roadmapは商用機能の予定日と説明を示すもので、情報は変更される可能性があると明記されています。展開計画では、GA月だけを前提にせず、Message Center、Microsoft Learn、テナント上の実機表示を合わせて確認しましょう。(Microsoft)
影響範囲：誰が何を確認すべきか
この更新の影響は、Microsoft Purviewの管理者だけに閉じません。SQL Server、レポート基盤、セキュリティ運用、場合によってはデータエンジニアリングにも関係します。
| 役割 | 確認すべきポイント | 実務上の注意点 |
|---|---|---|
| Purview管理者 | スキャナークラスター、コンテンツスキャンジョブ、ラベル構成 | まず検出モードで結果を確認し、ラベル適用や保護の影響を段階的に検証する |
| セキュリティ・コンプライアンス担当 | ラベル未設定ファイル、保護状態、SITの分布 | レポート結果をそのまま監査資料にせず、検出条件やスキャン範囲を明記する |
| SQL Server管理者 | DB容量、インデックス、バックアップ、読み取り負荷 | レポートクエリがスキャン処理と競合しない設計にする |
| 開発者・データエンジニア | Power BI、SQLビュー、抽出ジョブ、DWH連携 | スキーマ変更やプレビュー制限を前提に、疎結合な取り込み設計にする |
| 運用担当 | スキャン周期、フル再スキャン、ジョブ失敗時の確認 | 「最新スキャンだけ見れば十分」と判断せず、差分と履歴の扱いを決めておく |
特に大規模なファイル共有をスキャンしている環境では、Custom Reportingを有効にするとデータベースに保存される情報が増えます。レポート用の読み取りクエリも増えるため、SQL Serverの性能と容量を事前に見積もることが重要です。
追加される主なSQLデータ
Custom Reportingでは、既存のdbo.ScannerFilesに追加列が設定され、新しいテーブルとしてdbo.MatchedClassificationActionとdbo.ScannedFilesArchiveが使われます。Microsoft Learnでは、dbo.ScannerFilesはスキャンされたファイルごとに1行を保持し、現在のラベル、以前のラベル、保護状態、SIT一致数、最新スキャンセッションID、ファイルステータスなどの列が追加されると説明されています。(Microsoft Learn)
| テーブル | 主な用途 | 見られる情報の例 |
|---|---|---|
dbo.ScannerFiles | スキャン済みファイルの最新状態 | 現在のラベル、前回ラベル、保護状態、SIT一致数、処理ステータス |
dbo.MatchedClassificationAction | ファイルごとのSIT一致情報 | ファイルパス、SIT名、SIT ID、一致数、信頼度スコア |
dbo.ScannedFilesArchive | 処理済みファイルの履歴アーカイブ | スキャン時点のフルパス、ラベル名、保護状態、変更状態、スキャンセッション |
dbo.MatchedClassificationActionは、1つのスキャンセッション内で、1つのファイルに一致した1つのSITを1行として保持します。たとえば、あるファイルで複数種類の機密情報が検出された場合、SITごとに集計しやすくなります。dbo.ScannedFilesArchiveは履歴アーカイブ用ですが、変更がないためスキャナーがスキップしたファイルは再挿入されないため、後続のスキャンセッションが常に全ファイルの完全スナップショットになるわけではありません。(Microsoft Learn)
有効化に必要な前提条件
Custom Reportingは、Microsoft Purview Information Protectionクライアントおよびスキャナーのバージョン3.2.89.0以降で利用できます。Microsoft Learnでは、カスタムレポート用のテーブルと列はクライアントバージョン3.2.57.0のスキーマで最初に追加されたものの、新規インストールまたは旧バージョンからのアップグレード時に完全なデータベーススキーマが展開されるため、最初に3.2.57.0を入れる必要はないと説明されています。(Microsoft Learn)
事前確認では、少なくとも次を見ておきましょう。
| 確認項目 | 判断基準 |
|---|---|
| スキャナーのバージョン | Microsoft Purview Information Protectionクライアントおよびスキャナーが3.2.89.0以降か |
| スキャナークラスター | 既存クラスター名、ノード数、対象リポジトリが整理されているか |
| SQL Server | スキャナークラスターデータベースの容量、バックアップ、保守計画があるか |
| 権限 | Purview管理、SQL読み取り、レポート作成の権限を分離できるか |
| ラベル構成 | スキャナーアカウントに適用される秘密度ラベルと自動分類条件が妥当か |
| レポート利用目的 | 監査、改善活動、経営報告、運用監視のどれに使うか明確か |
情報保護スキャナーの構成では、Microsoft Purviewポータルでスキャナークラスターとコンテンツスキャンジョブを作成します。必要な管理ロールとして、Compliance Administrator、Compliance Data Administrator、Security Administrator、Organization Managementなどが案内されています。(Microsoft Learn)
Custom Reportingを有効化する手順
既存のスキャナークラスターで有効化する場合は、クラスター内の任意のノードからPowerShellでSet-ScannerConfigurationを実行します。新規ノードのインストール時に有効化する場合は、Install-Scannerに-FeatureSettingsを追加します。変更は次のスキャンサイクルでクラスター内の全ノードに反映され、サービス再起動は不要です。(Microsoft Learn)
Set-ScannerConfiguration -FeatureSettings @{CustomReporting=$true}新規インストール時に有効化する例です。
Install-Scanner -SqlServerInstance SQLSERVER1 -Cluster Europe -FeatureSettings @{CustomReporting=$true}現在の状態は、次のコマンドで確認します。
Get-ScannerConfigurationPowerShellで有効化されている場合、Features行に次のような状態が表示されます。(Microsoft Learn)
Features : {CustomReporting: True (Source: PowerShell)}無効化する場合は、次のように指定します。
Set-ScannerConfiguration -FeatureSettings @{CustomReporting=$false}無効化すると新しい書き込みは停止しますが、すでにレポート列やテーブルに書き込まれたデータは削除されません。将来、再度有効化しても既存データを失わない設計です。(Microsoft Learn)
展開前に決めておきたい運用設計
Custom Reportingは便利ですが、オンにすれば自動的に完成したダッシュボードが出る機能ではありません。プレビュー中は組み込みダッシュボードが含まれず、利用者がスキャナークラスターデータベースに対して独自のレポートを作成する必要があります。(Microsoft Learn)
展開前には、次の順番で設計すると失敗しにくくなります。
| ステップ | やること | 成功基準 |
|---|---|---|
| 現状把握 | スキャン対象、ファイル数、スキャン頻度、SQL容量を確認 | 対象リポジトリと推定データ量を説明できる |
| 小規模検証 | 限定したリポジトリでCustom Reportingを有効化 | テーブルに想定どおりデータが入る |
| レポート設計 | Power BIまたはSQLビューで初期レポートを作成 | ラベル未設定・高リスクファイルを抽出できる |
| 性能確認 | スキャン中のSQL負荷とレポート更新負荷を確認 | スキャン時間やSQL待機が許容範囲に収まる |
| 本番展開 | 対象範囲を段階的に拡大 | 運用チームが結果を改善アクションにつなげられる |
特に本番環境では、スキャナーが書き込むプライマリDBに対して、重い集計クエリや頻繁なPower BI更新を直接実行しない設計が理想です。Microsoft Learnでは、ほとんどの本番展開において、SQL Server Enterpriseでスキャナークラスターデータベースをホストし、Always On可用性グループの読み取り可能なセカンダリレプリカをレポート専用にすることが推奨されています。スキャナー自体は常にプライマリDBを読み書きするため、読み取り専用レプリカはレポートワークロードのみを向ける必要があります。(Microsoft Learn)
管理者が確認すべき設定
まず確認すべきなのは、スキャナーの基本構成です。スキャナークラスターは、スキャナーインスタンスを識別する単位であり、インストールやアップグレード時にも使用されます。コンテンツスキャンジョブでは、どのリポジトリをスキャンするかを定義します。(Microsoft Learn)
管理者は、次のチェックリストを使うと確認漏れを減らせます。
| 項目 | 確認内容 |
|---|---|
| スキャナークラスター名 | 地域、部門、用途が分かる命名になっているか |
| コンテンツスキャンジョブ | 本当に必要なファイル共有、SharePoint Serverライブラリだけを対象にしているか |
| スキャンモード | まずDiscovery目的で結果を確認し、ラベル適用や保護は段階的に有効化しているか |
| DLPルール | DLPポリシーを構成していないのにDLPルールを有効にしていないか |
| レポート権限 | SQLの読み取り権限を必要最小限にしているか |
| ログ・レポート保管 | 既存のCSV/TXTレポートとSQLレポートの役割を整理しているか |
DLPポリシーに関しては注意が必要です。Microsoft Learnでは、Microsoft 365でDLPポリシーを構成していない場合、スキャンジョブの「Enable DLP policy rules」をオンにしないよう注意が示されています。有効化するとスキャナーでエラーが発生する可能性があります。(Microsoft Learn)
開発者・データ担当者向けのレポート活用例
Custom Reportingの価値は、スキャン結果を「一覧で見る」だけでなく、改善アクションにつながる形に加工できる点にあります。たとえば、次のようなレポートが実務で役立ちます。
| レポート例 | 目的 | 次のアクション |
|---|---|---|
| ラベル未設定かつSIT一致あり | 機密情報があるのに分類されていないファイルを見つける | ラベルポリシー見直し、所有部門への通知 |
| 保護状態が変化したファイル | 保護適用・解除の動きを追跡する | 不自然な解除がないか確認 |
| リポジトリ別SIT件数 | 高リスクな共有領域を特定する | アクセス権見直し、スキャン頻度調整 |
| ファイル処理失敗一覧 | スキャンできないファイルを把握する | 権限、ファイル形式、パス長、ロック状態を確認 |
| ラベル変更履歴 | ラベル運用の定着度を測る | 自動ラベル条件やユーザー教育を改善 |
SQLクエリを作る場合は、まず読み取り専用の接続ユーザーを作成し、本番スキャナー処理と競合しない時間帯に検証しましょう。以下は考え方を示すサンプルです。実際の環境では、列名、インデックス、対象リポジトリ、件数制限を確認して調整してください。
-- SIT一致数が多いファイルを確認する例
SELECT TOP 100
FilePath,
MatchedInformationTypeName,
MatchedInformationTypeCount,
ConfidenceScore
FROM dbo.MatchedClassificationAction
ORDER BY MatchedInformationTypeCount DESC;-- アーカイブ上でラベル未設定かつ機密情報が検出されたファイルを確認する例
SELECT TOP 100
FullPath,
LabelName,
ProtectionState,
ClassificationCount,
FileStatus
FROM dbo.ScannedFilesArchive
WHERE LabelName IS NULL
AND ClassificationCount > 0
ORDER BY ClassificationCount DESC;ここで重要なのは、レポートを「監視するだけ」で終わらせないことです。たとえば、ラベル未設定ファイルが多い部門が分かったら、スキャン条件、ラベル条件、アクセス権、部門への案内をセットで見直します。Power BIのダッシュボードも、単なるグラフではなく「誰が、いつ、何を直すか」まで追える形にすると効果が出ます。
移行時の注意点
既存の運用がCSV/TXTレポート中心の場合、Custom Reportingを有効にした直後から過去すべての詳細履歴が完全にSQLへそろうわけではありません。Custom Reportingは有効化後の次のスキャンサイクルから追加のレポートデータを書き込みます。(Microsoft Learn)
また、スキャナーは初回スキャンでは構成済みデータストアの全ファイルを検査しますが、以降のスキャンでは新規または変更されたファイルだけを検査します。レポートに全ファイルを含めたい場合や、ラベル設定変更を全体に反映したい場合は、手動でフル再スキャンを実行する判断が必要です。(Microsoft Learn)
移行でよくある失敗は、次の3つです。
| 失敗パターン | 起きる問題 | 回避策 |
|---|---|---|
| いきなり全社ファイル共有で有効化する | SQL容量やクエリ負荷を読み違える | 小規模な代表リポジトリで試験し、件数と増加量を測る |
| Power BI更新を高頻度にする | スキャン処理とSQLリソースを奪い合う | 更新間隔を長めにし、可能なら読み取り専用レプリカを使う |
| レポート結果を絶対視する | スキャン対象外や未処理ファイルを見落とす | スキャン範囲、ジョブ失敗、FileStatusも一緒に確認する |
セキュリティと権限管理の注意点
Custom Reportingで扱うデータには、ファイルパス、ラベル名、保護状態、機密情報の種類、一致数などが含まれます。ファイル本文そのものではなくても、ファイル名やパス、検出されたSITの種類だけで機密性の高い業務内容を推測できる場合があります。
たとえば、\\fileserver\Legal\M&A\...のようなパスや、特定の国の個人番号・金融情報の検出数は、それ自体が取り扱い注意の情報です。レポート利用者には、SQLの読み取り権限を広く付与せず、必要なビューやPower BIデータセット経由に限定するのが安全です。
実務では、次のように分けると運用しやすくなります。
| 権限レベル | 利用者 | 許可する範囲 |
|---|---|---|
| SQL管理 | DBA、限られたインフラ担当 | DB保守、バックアップ、性能確認 |
| レポート作成 | セキュリティ分析担当、データ担当 | 必要なテーブルまたはビューの読み取り |
| レポート閲覧 | 部門管理者、監査担当 | 集計済みダッシュボードのみ |
| 改善実施 | ファイル所有部門、情報管理担当 | 対象ファイルの確認とラベル・権限見直し |
レポートは便利なほど共有したくなりますが、共有範囲を広げすぎると「機密情報がどこにあるか」を広く知らせることになります。特に部門別レポートを配布する場合は、部門外のファイルパスや詳細なSIT名を見せない加工を検討しましょう。
PowerShellとMicrosoft Purviewポータルの関係
Custom Reportingは、スキャナー機能コントロールを通じて提供される機能です。現時点のプレビューではPowerShellによる構成が中心で、機能設定はクラスターごとに共有スキャナークラスターデータベースへ保存されます。クラスター内の任意のノードで1回コマンドを実行すれば、全ノードが次のスキャンサイクルで変更を受け取ります。(Microsoft Learn)
ただし、将来的にMicrosoft Purviewポータルから同じ機能を構成できるようになった場合、ポータル側がその機能の「真のソース」になる場合があります。Microsoft Learnでは、PowerShellとポータルの間で設定は同期されず、ポータルで管理される機能をPowerShellで変更しようとすると無視されるルールが説明されています。(Microsoft Learn)
そのため、運用手順書には次を明記しておくと安全です。
- どの機能をPowerShellで管理しているか
Get-ScannerConfigurationの確認結果をどこに記録するか- ポータルで設定項目が表示された場合、どちらを正とするか
- 本番変更前に誰がレビューするか
GAまでに管理者がやるべきこと
GA予定が2026年8月であることを踏まえると、すでに情報保護スキャナーを利用している組織は、今のうちに「使うかどうか」ではなく「どの範囲で安全に使い始めるか」を決めておくとよいでしょう。
特に優先度が高いのは、次の5つです。
| 優先度 | 対応 | 具体的な作業 |
|---|---|---|
| 高 | スキャナー環境の棚卸し | バージョン、クラスター、対象リポジトリ、SQL Serverを一覧化 |
| 高 | SQL容量の見積もり | ファイル数、SIT一致数、スキャン頻度から増加量を試算 |
| 高 | 権限設計 | SQL直接参照、Power BI閲覧、部門別閲覧を分ける |
| 中 | パイロットレポート作成 | ラベル未設定ファイル、SIT上位、処理失敗一覧を作る |
| 中 | 運用手順の更新 | 有効化、無効化、確認、障害時対応、フル再スキャン判断を記載 |
まだスキャナーを導入していない組織では、いきなりCustom Reportingから始めるのではなく、まず情報保護スキャナーの基本構成を固めるべきです。スキャナーを実行するWindows Server、情報保護クライアント、SQL Server、秘密度ラベル、SharePoint Server要件などを満たす必要があります。(Microsoft Learn)
まとめ：Custom Reportingは「見える化」ではなく改善運用の土台
Microsoft PurviewのScanner data export for custom reportingは、情報保護スキャナーの結果をSQLベースで活用し、組織独自のレポートを作りやすくする更新です。CSVを集約する作業を減らし、ラベル未設定ファイル、SITの分布、保護状態の変化、スキャン間の差分を継続的に把握しやすくなります。
一方で、プレビュー中は組み込みダッシュボードがなく、SQL Serverの容量や読み取り負荷、権限管理、PowerShell設定の扱いを自社で設計する必要があります。特に大規模環境では、読み取り専用レプリカや段階的なパイロット展開を前提にした方が安全です。
まずは、既存スキャナーのバージョンとSQL Server構成を確認し、小さなリポジトリでCustom Reportingを有効化して、どの程度のデータ量とレポート価値が出るかを測定しましょう。その結果をもとに、GAに向けて本番展開範囲、レポート利用者、改善アクションの流れを決めるのが現実的な進め方です。
コメント