Microsoft Purview Information Protection scannerで管理者が最初に確認すべき結論は、「オンプレミスのファイル共有やSharePoint Server上の機密データを、秘密度ラベルで検出・分類・保護するためのスキャナー」であり、2026年5月の公式更新ではクラスター単位の機能制御とCustom Reportingプレビューが特に重要です。既存環境では、すぐに本番適用する前に、スキャナークライアントのバージョン、SQL Server容量、サービスアカウント権限、認証方式、フル再スキャンの要否を確認してください。
Microsoft Purview Information Protection scannerはリアルタイム監視ツールではありません。指定したデータストアを周期的にクロールし、条件に合うファイルを検出・分類・ラベル付けします。そのため、DLPや監査基盤のように「即時ブロック」を期待するのではなく、オンプレミス上に残る機密ファイルを棚卸しし、秘密度ラベルと保護状態を継続的に整える仕組みとして設計するのが現実的です。Microsoft公式情報では、スキャナーはWindows Server上のサービスとして動作し、SMBまたはNFSプレビューのUNCパス、メインストリームサポート中のSharePoint Serverドキュメントライブラリやフォルダーを対象にできます。(Microsoft Learn)
Microsoft Purview Information Protection scannerとは
Microsoft Purview Information Protection scannerは、Microsoft Purviewの秘密度ラベルをオンプレミスのデータストアに適用するためのスキャナーです。Microsoft 365上のSharePoint OnlineやOneDriveだけでなく、社内ファイルサーバーやSharePoint Serverに残っているファイルを検出・分類・保護したい場合に使います。
主な役割は次の3つです。
| 役割 | できること | 実務での使いどころ |
|---|---|---|
| 検出 | 機密情報を含むファイルを探す | 個人情報、契約情報、財務情報が古い共有フォルダーに残っていないか確認する |
| 分類 | 条件に応じて秘密度ラベルを判定する | 「社外秘」「機密」「個人情報」などの分類ルールを統一する |
| 保護 | 必要に応じてラベルや暗号化を適用する | 特定部門だけが閲覧できるようにする、保護されていないファイルを是正する |
スキャナーは、Windowsでインデックス化できるファイルを検査し、Windows IFilter、機密情報の種類、パターン検出、正規表現などを使ってラベル付けの要否を判断します。また、Microsoft Purview Information Protection clientを使用するため、クライアントが分類・保護できるファイル種別と密接に関係します。(Microsoft Learn)
2026年5月の公式更新で注目すべき変更点
2026年5月のMicrosoft Purview公式更新では、Information Protection Scannerに関して、管理者がPowerShellからクラスター単位のスキャナー機能を有効化・無効化・構成できるプレビュー機能と、スキャン結果をSQLベースで活用しやすくするCustom Reportingプレビューが案内されています。(Microsoft Learn)
クラスター単位の機能制御が追加された
新しい「scanner feature control」では、スキャナー管理者がクラスター単位で機能を管理できます。設定は共有スキャナークラスターデータベースに保存されるため、1つのノードからPowerShellコマンドを実行すれば、同じクラスター内の全ノードに反映されます。Microsoft公式情報では、変更は次回のスキャンサイクルで反映され、サービス再起動は不要とされています。(Microsoft Learn)
代表的な使い方は次のとおりです。
Set-ScannerConfiguration -FeatureSettings @{CustomReporting=$true}新規インストール時に有効化する場合は、Install-Scannerに-FeatureSettingsを付けます。
Install-Scanner -SqlServerInstance SQLSERVER1 -Cluster Europe -FeatureSettings @{CustomReporting=$true}現在の状態は次のコマンドで確認できます。
Get-ScannerConfigurationここで重要なのは、PowerShellとMicrosoft Purviewポータルの関係です。公式情報では、当初はPowerShellで構成される機能でも、将来ポータル側で構成可能になった場合は、ポータルがその機能の信頼できる構成元になります。ポータル管理の機能に対してPowerShellから変更を試みると警告され、クラスター状態は変更されません。(Microsoft Learn)
Custom ReportingプレビューでSQLベースの分析がしやすくなった
Custom Reportingは、スキャン結果をスキャナークラスターデータベース上で分析しやすくするプレビュー機能です。従来はスキャンごとのCSVやTXTレポートをつなぎ合わせて、ファイルのラベル状態、保護状態、機密情報の種類の一致状況を分析する必要がありました。Custom Reportingを有効にすると、追加のテーブルや列にデータが書き込まれ、Power BIやSQLベースのレポート基盤から参照しやすくなります。(Microsoft Learn)
Custom Reportingで確認しやすくなる内容は、たとえば次のようなものです。
| 確認したいこと | Custom Reportingで見やすくなる情報 |
|---|---|
| どのリポジトリに機密情報が多いか | ファイルごとのSIT一致数、SIT種別、信頼度 |
| ラベルが変わったファイルはどれか | 現在のラベル、前回スキャン時のラベル |
| 未ラベルなのに機密情報を含むファイルはどれか | ラベル状態とSIT一致状況の組み合わせ |
| 保護状態が変わったファイルはどれか | 現在と前回の保護状態 |
| 部門別・共有フォルダー別にリスクを見たい | SQLやPower BIによる任意の集計 |
Custom ReportingはMicrosoft Purview Information Protection client and scannerのバージョン3.2.89.0以降で利用でき、機能制御によって有効化します。ただしプレビュー段階では組み込みダッシュボードは提供されず、管理者側でSQLやPower BIなどを使ってレポートを作成する前提です。(Microsoft Learn)
影響範囲：誰が何を確認すべきか
今回の更新は、エンドユーザーのOffice操作を直接変えるものではありません。影響が大きいのは、オンプレミスのデータ保護を運用しているMicrosoft Purview管理者、セキュリティ管理者、インフラ管理者、レポート基盤を作る開発者です。
| 対象者 | 影響 | 確認すべきこと |
|---|---|---|
| Purview管理者 | スキャン設定、秘密度ラベル、スキャナークラスター管理に影響 | ラベル条件、Enforce設定、Relabel設定、機能制御の管理元 |
| セキュリティ管理者 | 機密データの可視化と是正判断に影響 | 未ラベルファイル、保護されていないファイル、SIT検出結果 |
| インフラ管理者 | Windows Server、SQL Server、ネットワーク、サービスアカウントに影響 | サーバー要件、SQL容量、ポート、SharePointしきい値 |
| 開発者・データ担当者 | SQLやPower BIでのレポート作成に影響 | 読み取り負荷、レポート更新頻度、読み取り専用レプリカの利用 |
| 監査・コンプライアンス担当 | 証跡確認や改善状況の把握に影響 | ラベル変更履歴、保護状態、機密情報の分布 |
特にCustom Reportingを有効化する場合、スキャナーデータベースの読み書き負荷が増えます。公式情報では、レポートクエリがスキャナーの運用上の読み書きと競合する可能性があるため、本番環境ではSQL Server EnterpriseとAlways On可用性グループを使い、Power BIなどのレポート処理を読み取り専用セカンダリレプリカへ逃がす構成が推奨されています。なお、スキャナー本体は常にプライマリデータベースを読み書きします。(Microsoft Learn)
管理者が確認すべき前提条件
Microsoft Purview Information Protection scannerを安定運用するには、機能を有効化する前に前提条件を確認する必要があります。スキャナーは単なるエージェントではなく、Windows Server、SQL Server、Microsoft Entra ID、Purviewの秘密度ラベル、サービスアカウント権限が組み合わさって動くためです。
Windows Serverとネットワーク要件
公式情報では、スキャナーを実行するWindows Serverとして、Windows Server 2025、2022、2019、2016の64ビット版が記載されています。Server CoreとNano Serverはサポートされません。また、スキャン対象データストアに対して高速で信頼できるネットワーク接続が必要です。インターネット接続が可能な構成では、Azure Rights ManagementやInformation Protection関連のURLへHTTPS 443で通信できる必要があります。(Microsoft Learn)
NFS共有をスキャンする場合は、スキャナーマシン上でNFS用サービスを有効にする必要があります。.zipファイル内の機密情報を検査したい場合は、Windows Server上のスキャナーにMicrosoft Office iFilterが必要です。(Microsoft Learn)
サービスアカウント権限
スキャナーサービス用のアカウントは、Windows Server上でサービスを実行し、Microsoft Entra IDに認証し、スキャナーポリシーを取得するために使われます。通常はActive Directoryアカウントであり、Microsoft Entra IDへ同期されている必要があります。(Microsoft Learn)
権限設計で失敗しやすいのは、Discovery modeと実際のラベル適用・保護適用を同じ権限で考えてしまうことです。Discovery modeだけなら読み取り権限で足りる場合がありますが、分類や保護を適用するには、ファイル共有やローカルファイルに対するRead、Write、Modify権限が必要です。SharePointでは、条件に合うファイルに分類・保護を適用するためにFull Control権限が必要とされています。(Microsoft Learn)
暗号化済みファイルの再保護や保護解除まで行う場合は、スキャナーアカウントをAzure Rights Managementサービスのsuper userにする必要があります。オンボーディング制御を使って段階展開している場合は、その対象にスキャナーアカウントを含めることも忘れないでください。(Microsoft Learn)
SQL Serverと容量設計
スキャナー構成データはSQL Serverに保存されます。公式情報では、SQL Server 2016以降のEnterprise、Standard、Expressが記載されていますが、SQL Server Expressはテスト環境向けとされています。本番では、スキャナーサービスとSQL Serverを別マシンに置き、スキャナーデータベース専用のSQLインスタンスを用意する構成が推奨されます。(Microsoft Learn)
容量見積もりでは、ファイル数と平均ファイル名長が効きます。公式ドキュメントでは、スキャナー構成データベースの容量目安として次の式が示されています。
100 KB + <file count> * (1000 + 4 * <average file name length>)たとえば、平均ファイル名長が250バイトで100万ファイルをスキャンする場合、2GB程度のディスク領域が目安とされています。Custom Reportingを有効化する場合は、これに加えてSIT一致情報や履歴アーカイブ用の追加データが増えるため、実測ベースで余裕を持った容量設計が必要です。(Microsoft Learn)
展開時の基本手順
新規展開では、最初からラベル適用を本番実行するのではなく、Discovery modeで影響を確認してからEnforceを有効化する流れが安全です。初期設定では、Microsoft Purviewポータルでスキャナークラスターを作成し、Content scan jobで対象リポジトリを指定します。初期構成ではScheduleをManual、Info types to be discoveredをPolicy only、Enforce sensitivity labeling policyをOffにする構成が案内されています。(Microsoft Learn)
基本の流れは次のとおりです。
| 手順 | 作業 | 注意点 |
|---|---|---|
| 事前確認 | Windows Server、SQL Server、サービスアカウント、ラベルを確認 | PowerShellモジュールだけでなくフルクライアントが必要 |
| クラスター作成 | Microsoft Purviewポータルでスキャナークラスターを作成 | 地域名や用途が分かる名前にする |
| Content scan job作成 | スキャン対象と初期設定を登録 | 最初はEnforce Offで影響を確認 |
| スキャナーインストール | PowerShellでInstall-Scannerを実行 | SQLインスタンス名とクラスター名を正しく指定 |
| 認証構成 | Microsoft Entraトークンまたは証明書認証を構成 | クライアントシークレットの期限切れに注意 |
| Discovery実行 | Start-Scanまたはポータルからスキャン開始 | レポートと検出結果を確認 |
| 本番適用 | Enforce On、必要に応じてRelabel設定 | 変更後はフル再スキャンの要否を判断 |
スキャナーのインストールはPowerShellで行います。たとえば、SQL Serverの既定インスタンスを使い、クラスター名をEuropeにする場合は次のように実行します。(Microsoft Learn)
Install-Scanner -SqlServerInstance SQLSERVER1 -Cluster Europe名前付きインスタンスの場合は次の形式です。
Install-Scanner -SqlServerInstance SQLSERVER1\SCANNER -Cluster Europeインストール後、Windowsのサービスには「Microsoft Purview Information Protection Scanner」として登録され、作成済みのスキャナーサービスアカウントで実行されます。(Microsoft Learn)
移行・アップグレード時の注意点
既存環境で最も注意すべきなのは、Azure Information Protection unified labeling client 2.xからMicrosoft Purview Information Protection client 3.xへ移行するケースです。公式情報では、サービス名やコンポーネント名が変更されるため、2.xから3.xへのアップグレードには追加の手順が必要とされています。手順を省略するとスキャナーが動作しなくなる可能性があります。(Microsoft Learn)
AIP 2.xから3.xへ移行する場合
移行前に、少なくともSQLデータベース名とクラスター名を確認します。
Get-AIPScannerConfigurationその後、旧スキャナーサービスを停止し、旧サービスをアンインストールしてから、Windows Serverを再起動します。
Net Stop AIPScanner
Uninstall-AIPScannerAIP 2.xクライアントを削除し、Microsoft Purview Information Protection client 3.xをインストールした後、スキャナーを再インストールします。
Install-Scanner -SqlServerInstance SQLSERVER1\SCANNER -Cluster EU続いて、新しいサービス名で停止し、1つのスキャナーノードからデータベースを更新します。
Net Stop MIPScanner
Update-ScannerDatabase
Net Start MIPScanner複数ノード構成では、各ノードでMIPScannerサービスを開始します。公式手順でも、2.xから3.xへの移行では各ステップを順番に実施することが強調されています。(Microsoft Learn)
既存の3.xから最新版へ上げる場合
すでにMicrosoft Purview Information Protection client 3.xを使っている場合は、2.xからの移行より手順は簡単です。各ノードでMIPScannerを停止し、最新クライアントをインストールし、1つのノードでUpdate-ScannerDatabaseを実行してからサービスを開始します。(Microsoft Learn)
Net Stop MIPScanner
Update-ScannerDatabase
Net Start MIPScannerただし、Custom ReportingやFeatureSettingsを使う場合は、対象機能に必要なクライアントバージョンを満たしているか確認してください。リリース情報では、3.2.57.0が2026年3月26日にリリースされ、3.2.89.0 Previewが2026年4月22日にリリースされています。3.2.89.0 Previewでは、スキャナー機能制御、Custom Reporting、Microsoft Graph統合などが追加されています。(Microsoft Learn)
Custom Reportingを有効化する前の判断基準
Custom Reportingは便利ですが、すべての環境で即時有効化すべき機能ではありません。特に、ファイル数が多い、スキャン頻度が高い、Power BIの自動更新を短い間隔で回したい、SQL Serverを他システムと共有している、といった環境では慎重に検証してください。
| 判断項目 | 有効化しやすい環境 | 慎重に検証すべき環境 |
|---|---|---|
| ファイル数 | 数十万〜少数百万件でSQLに余裕がある | 数千万件規模、またはファイル名が長い |
| レポート用途 | 月次・週次の棚卸し、改善状況確認 | リアルタイムに近い高頻度ダッシュボード |
| SQL構成 | 専用SQL、十分なCPU・メモリ・ストレージ | 共有SQL、リソース逼迫、バックアップ時間が長い |
| 運用体制 | SQL担当とPurview担当が連携できる | スキャナー管理者だけでSQL運用も兼務 |
| 可用性 | Always Onや読み取り専用レプリカを検討できる | 単一SQLでスキャンと分析を同時実行する |
有効化後は、次回スキャンサイクルから追加データが書き込まれます。無効化しても既存データは削除されず、新規書き込みが止まるだけです。そのため、本番前に検証クラスターで「1回のスキャンでどの程度データが増えるか」「Power BI更新時にスキャン時間が伸びるか」を測るのが安全です。(Microsoft Learn)
認証方式はクライアントシークレットだけで考えない
従来の運用では、Microsoft Entraアプリ登録とクライアントシークレットを使った無人認証が一般的です。ただし、シークレットは期限切れや漏えい管理が課題になります。公式情報では、証明書ベース認証がPublic Previewとして案内されており、スキャナー、管理者権限、Microsoft Entraアプリ登録、Windows PowerShell 5.1が前提として示されています。(Microsoft Learn)
本番環境では、自己署名証明書よりも組織のCAで発行した証明書を使う方が管理しやすくなります。証明書要件としては、RSA、最小2048ビット、デジタル署名用途、Local MachineのPersonalストアへの配置などが示されています。スキャナーサービスアカウントには秘密キーの読み取り権限が必要で、権限が不足すると「Keyset does not exist」エラーの原因になります。(Microsoft Learn)
シークレット認証から証明書認証へ移行する場合は、証明書を作成・構成し、Set-Authenticationを証明書パラメーター付きで実行します。その後、スキャナーサービスを再起動します。(Microsoft Learn)
Restart-Service -Name "Microsoft Purview Information Protection Scanner"スキャン運用で失敗しやすいポイント
最初からEnforce Onにしない
最初のスキャンではDiscovery modeを使い、どのファイルにどのラベルが適用される見込みかを確認してください。公式手順でも、まずDiscovery scanを実行し、レポート確認後に分類と保護の適用へ進む流れが示されています。(Microsoft Learn)
レポートは次の場所に保存されます。
%localappdata%\Microsoft\MSIP\Scanner\ReportsTXTのサマリーファイルにはスキャン時間、スキャンファイル数、情報タイプに一致したファイル数などが含まれます。CSVにはファイルごとの詳細が出力され、フォルダーには各スキャンサイクルにつき最大60件のレポートが保持されます。管理ポータルは直近スキャンの情報を表示するため、過去スキャン結果を追う場合はローカルレポートやCustom Reportingの活用を検討してください。(Microsoft Learn)
設定変更後にフル再スキャンを忘れない
スキャナーは2回目以降のスキャンでは、基本的に新規または変更されたファイルだけを検査します。ラベルポリシーやEnforce設定を変えた場合、既存ファイル全体へ変更を適用したいならフル再スキャンが必要です。公式情報でも、EnforceをOffからOnへ変更した場合は、ラベルをコンテンツ全体へ適用するためにフル再スキャンを実行するよう案内されています。(Microsoft Learn)
SharePoint Serverではしきい値とURL長に注意する
SharePoint Serverをスキャンする場合、大規模リストや長いファイルパスでつまずくことがあります。公式情報では、大規模SharePointファームでは既定値5,000のリストビューしきい値を増やす必要がある場合があるとされています。また、SharePointの長いパスではhttpRuntime.maxUrlLengthが既定の260文字より大きい値になるよう確認が必要です。(Microsoft Learn)
OneDriveをオンプレミスリポジトリのように指定しない
スキャナーのリポジトリ指定では、ネットワーク共有、ローカルパス、SharePoint Server URLなどを扱えます。ただし、公式手順ではワイルドカードとWebDavロケーションはサポートされず、OneDriveロケーションをリポジトリとしてスキャンすることもサポートされないとされています。OneDriveやSharePoint Onlineの自動ラベル付けとは役割を分けて考えてください。(Microsoft Learn)
開発者・レポート担当者が見るべきデータ設計
Custom Reportingを使う場合、開発者やデータ担当者は「スキャン結果をどう見せるか」だけでなく、「どのタイミングで、どのDBに、どの負荷で問い合わせるか」を設計する必要があります。
Custom Reportingでは、dbo.ScannerFilesに現在ラベル名、前回ラベル、保護状態、SIT一致数、最終スキャンセッションID、ファイルステータスなどの追加列が入ります。また、dbo.MatchedClassificationActionにはファイルごとの一致した機密情報の種類、件数、信頼度が保存されます。dbo.ScannedFilesArchiveには、スキャンセッションに紐づく履歴情報が保存され、変更追跡や監査に使えます。(Microsoft Learn)
レポート設計では、次のような観点を先に決めておくと失敗しにくくなります。
| 設計項目 | 推奨する考え方 |
|---|---|
| 更新頻度 | スキャンサイクルに合わせる。必要以上に短いPower BI更新は避ける |
| 接続先 | 可能なら読み取り専用レプリカを使う |
| 指標 | 「未ラベル件数」「高リスクSIT件数」「前回からの改善数」を優先する |
| 粒度 | 経営層向けは部門・リポジトリ単位、運用者向けはファイル単位 |
| 権限 | レポート閲覧者がファイルパスや機密情報種別を見てよいか確認する |
| 保持 | 監査に必要な期間とSQL容量のバランスを決める |
特にファイルパスは、組織名、案件名、顧客名、部門名などを含むことがあります。レポートを広く共有する場合は、スキャン結果そのものが機密情報になり得る点に注意してください。
管理者向けチェックリスト
本番環境でMicrosoft Purview Information Protection scannerを運用する前に、次の項目を確認してください。
| 確認項目 | チェック内容 |
|---|---|
| クライアントバージョン | Custom ReportingやFeatureSettingsに必要なバージョンを満たしているか |
| サービスアカウント | Entra ID同期、ライセンス、リポジトリ権限、super user要否を確認したか |
| SQL Server | 専用インスタンス、容量、バックアップ、読み取り負荷対策を設計したか |
| スキャン対象 | UNCパス、SharePoint Server URL、対象外のOneDriveやWebDavを混同していないか |
| ラベル条件 | 自動分類条件が実態に合っているか |
| 初回実行 | Discovery modeで結果を確認してからEnforce Onにする計画か |
| 変更後の再スキャン | Enforceやラベル条件を変更した後、フル再スキャンを実施するか |
| 認証 | クライアントシークレット期限、または証明書ベース認証の運用を決めたか |
| レポート | CSV運用かCustom Reportingか、Power BI連携の負荷を見積もったか |
| 障害対応 | ログ、レポート保存場所、Get-ScanStatus、Export-DebugLogsの利用手順を用意したか |
まず取るべき対応
Microsoft Purview Information Protection scannerをすでに使っている場合は、まず現在のクライアントバージョン、クラスター名、SQL Server構成、スキャン対象、Enforce設定を棚卸ししてください。AIP 2.x系が残っている場合は、3.xへの移行手順を省略せず、サービス名変更とUpdate-ScannerDatabaseを含めて計画します。
これから導入する場合は、最初からラベル適用を自動化するのではなく、Discovery modeで「どこに、どの種類の機密情報が、どの程度残っているか」を把握することが第一歩です。そのうえで、秘密度ラベルの条件を調整し、必要な範囲だけEnforce Onに切り替えます。
2026年5月の更新で追加されたCustom Reportingは、オンプレミス上の機密データを継続的に可視化する強力な選択肢です。ただし、プレビュー機能であり、SQL負荷やレポート権限の設計が欠かせません。小さな検証クラスターでCustom Reportingを有効化し、スキャン時間、DB増加量、Power BI更新負荷を確認してから本番展開するのが、最も安全で実務的な進め方です。
コメント