Microsoft Purview Information Protection scannerを導入する前に最初に確認すべきことは、「スキャナー用サーバー」「サービスアカウント」「SQL Server」「Microsoft Purview Information Protectionクライアント」「秘密度ラベル」の5点です。2026年5月の公式更新では、これらの前提条件に加えて、スキャナー機能をクラスター単位で制御する仕組みと、Custom Reportingのプレビュー機能が重要な確認ポイントになりました。
特に注意したいのは、今回の更新が「スキャナーを入れればすぐ保護が自動化される」という話ではない点です。導入後は、まず検出モードでファイル共有やSharePoint Server上の機密情報を可視化し、ラベル適用や保護の影響を確認してから本番適用へ進めるのが安全です。
Microsoft Purview Information Protection scannerで押さえるべき結論
Microsoft Purview Information Protection scannerは、オンプレミスのファイル共有やSharePoint Server上のファイルをスキャンし、秘密度ラベルの検出、分類、必要に応じた保護を行うためのコンポーネントです。Windows Server上のサービスとして動作し、SMB/NFSのUNCパスやSharePoint Serverを対象にできますが、リアルタイム監視ではなく、設定したリポジトリを巡回してスキャンする仕組みです。(Microsoft Learn)
今回の更新で実務上見るべきポイントは、前提条件そのものが大きく置き換わったというより、スキャナー運用時に確認すべき項目が増えたことです。具体的には、PowerShellからスキャナークラスター単位で機能を有効化・無効化・構成できるFeatureSettingsと、スキャン結果をSQL Server上のスキャナークラスターDBに蓄積しやすくするCustom Reportingのプレビューが追加の検討対象になります。(Microsoft Learn)
| 確認項目 | 今回のポイント | 実務での判断基準 |
|---|---|---|
| 既存の前提条件 | Windows Server、サービスアカウント、SQL Server、クライアント、秘密度ラベルの準備が必要 | 導入前チェックリストとして必ず確認する |
| FeatureSettings | PowerShellでクラスター単位の機能制御が可能 | 本番反映前に検証環境で動作と影響を確認する |
| Custom Reporting | スキャン結果をSQLベースで分析しやすくするプレビュー機能 | レポート用途が明確な場合のみ段階的に有効化する |
| SQL Server負荷 | レポート用データによりDB容量と読み取り負荷が増える可能性 | DBAと容量、バックアップ、読み取り負荷を事前に設計する |
| 移行・アップグレード | AIP統合ラベルスキャナー2.x系からの移行では手順が異なる | 既存環境は上書き更新ではなく、公式手順に沿って移行する |
対象者と影響範囲
この更新の影響を受けるのは、Microsoft Purviewを使ってオンプレミスのファイルサーバーやSharePoint Serverの情報保護を進める組織です。特に、秘密度ラベルの自動適用、機密情報の棚卸し、監査用レポート、保護状態の可視化を運用に組み込みたい管理者は確認が必要です。
| 立場 | 確認すべきこと |
|---|---|
| Microsoft Purview管理者 | 秘密度ラベル、スキャナークラスター、コンテンツスキャンジョブの設定 |
| Windows Server管理者 | スキャナーを実行するサーバー要件、ネットワーク疎通、サービス稼働 |
| SQL Server管理者 | スキャナーデータベース、容量、権限、Custom Reporting時の読み取り負荷 |
| セキュリティ管理者 | 検出モードから保護適用へ移る判断、DLPポリシーとの整合性 |
| SharePoint管理者 | SharePoint ServerのURL、アクセス権、リストしきい値、承認済みコンテンツの扱い |
| 開発者・BI担当者 | Custom Reportingのデータ構造、Power BIやSQLベースの分析設計 |
一方で、クラウド上のSharePoint OnlineやOneDriveのみを対象にしている場合は、このスキャナーを使う場面は限定的です。スキャナーのリポジトリ設定ではUNCパスやSharePoint ServerのURLを指定しますが、ワイルドカード、WebDav、OneDriveの場所はサポート対象外とされています。(Microsoft Learn)
導入前に確認すべき前提条件
Information Protection scannerの導入で失敗しやすいのは、インストールコマンドそのものではなく、事前準備の不足です。特にサービスアカウントの権限、SQL Serverの準備、秘密度ラベルの公開状態、対象リポジトリへのアクセス権が不足していると、スキャンは開始できても期待した分類や保護まで進みません。
スキャナー用Windows Server
スキャナーを実行するサーバーには、Windows Server環境が必要です。公式情報では、4コアプロセッサ、8GB RAM、10GBの一時領域が目安として示されています。対応OSにはWindows Server 2025、2022、2019、2016が含まれますが、Server CoreやNano Serverはサポートされません。(Microsoft Learn)
ネットワーク面では、Microsoft Purview関連サービスへHTTPS 443で接続できる必要があります。ファイアウォールやプロキシを使っている環境では、必要なMicrosoftサービスへの通信が遮断されていないかを先に確認してください。スキャナーがNFSを対象にする場合はNFS関連サービス、.zipファイル内のOffice文書をスキャンする場合はOffice iFilterも確認対象です。(Microsoft Learn)
サービスアカウント
スキャナーは専用のサービスアカウントで動作させるのが基本です。このアカウントはActive Directory上のアカウントであり、Microsoft Entra IDと同期されている必要があります。また、スキャン対象のファイル共有やローカルファイルに対しては読み取り、書き込み、変更権限が必要になります。SharePoint Serverを対象にする場合は、対象サイトに対する十分な権限が必要です。(Microsoft Learn)
検出だけを行う場合は読み取り権限で足りるケースがありますが、ラベルの適用、再ラベル、保護の変更まで行う場合は書き込み権限が必要です。保護されたファイルを再分類したり保護を解除したりする場合は、スーパーユーザー権限が必要になることがあります。(Microsoft Learn)
実務では、次のように分けて考えると判断しやすくなります。
| 運用目的 | 必要な権限の考え方 |
|---|---|
| 機密情報の棚卸しのみ | 原則として読み取り中心。検出モードで影響を確認する |
| ラベルの自動適用 | 対象ファイルへの書き込み・変更権限が必要 |
| 保護されたファイルの再分類 | スーパーユーザー権限を含めた設計が必要 |
| SharePoint Serverのスキャン | サイト、ライブラリ、承認状態に応じた権限確認が必要 |
SQL Server
スキャナーは、スキャナークラスターの構成やスキャン結果を管理するためにSQL Serverを使用します。SQL Serverはローカルでもリモートでも利用できますが、本番環境では小規模構成を除き、スキャナー用サーバーとは別にSQL Serverを用意することが推奨されています。SQL Server 2016以降が必要で、SQL Server Expressはテスト用途向けと考えるべきです。(Microsoft Learn)
SQL Serverのサイズ設計では、対象ファイル数とファイル名の平均長が重要です。公式情報では、データベースサイズの目安として「100KB + ファイル数 ×（1000 + 4 × 平均ファイル名長）」という考え方が示されています。たとえば平均ファイル名長が250バイトで100万ファイルを扱う場合、目安は約2GBです。(Microsoft Learn)
Custom Reportingを有効化する場合は、さらに注意が必要です。スキャン結果をSQLベースで分析しやすくなる一方で、データベースへの書き込み量やレポート用クエリの読み取り負荷が増える可能性があります。大規模環境では、レポート処理を本番スキャナーDBのプライマリに直接集中させない設計を検討してください。(Microsoft Learn)
Microsoft Purview Information Protectionクライアントと秘密度ラベル
スキャナーを利用するには、Microsoft Purview Information Protectionクライアントのフル版が必要です。PowerShellモジュールだけではスキャナーの前提条件を満たせません。また、スキャナーアカウントに対して、少なくとも1つの秘密度ラベルがMicrosoft Purviewポータルで公開されている必要があります。(Microsoft Learn)
この点は見落とされがちです。サーバーやSQL Serverの準備が完了していても、スキャナーアカウントがラベルポリシーの対象になっていないと、期待したラベル適用はできません。導入前に、スキャナー用アカウントで利用できる秘密度ラベル、ポリシー、既定ラベル、自動ラベル条件を確認してください。
2026年5月更新で確認したいFeatureSettings
FeatureSettingsは、スキャナークラスター単位で機能を制御するための設定です。PowerShellから一度設定すると、その設定は共有スキャナークラスターデータベースに保存され、クラスター内の各ノードが次回のスキャンサイクルで設定を取得します。サービス再起動は不要とされています。(Microsoft Learn)
管理者にとってのメリットは、複数ノード構成でも機能の有効・無効状態をそろえやすいことです。従来のように各ノードで設定差分が生まれると、同じリポジトリをスキャンしているのに結果が異なる、レポートにばらつきが出る、といった運用トラブルにつながります。クラスター単位の制御は、こうした設定不整合を減らす目的で確認すべき機能です。
代表的なPowerShell例は次のとおりです。
Set-ScannerConfiguration -FeatureSettings @{CustomReporting=$true}
Get-ScannerConfiguration
Set-ScannerConfiguration -FeatureSettings @{CustomReporting=$false}FeatureSettingsは、Install-Scanner、Set-ScannerConfiguration、Get-ScannerConfigurationで扱えます。無効化しても既存データは削除されません。ただし、ポータル側で同じ設定が提供されるようになった場合、ポータルが信頼できる設定元として優先される点に注意が必要です。(Microsoft Learn)
Custom Reportingで何が変わるのか
Custom Reportingは、スキャン結果をより詳細にSQL Server上で扱えるようにするプレビュー機能です。従来のスキャナー運用では、スキャンごとのCSVやテキストレポートを確認し、必要に応じて手作業や別ツールで集計する場面がありました。Custom Reportingを有効にすると、ファイルのラベル状態、保護状態、検出された機密情報の種類などをスキャナークラスターDBに格納し、Power BIやSQLベースのレポートに活用しやすくなります。(Microsoft Learn)
Custom Reportingでは、dbo.ScannerFilesにラベル名、以前のラベル、保護状態、分類数、最新スキャンセッションIDなどの情報が追加されます。また、検出された機密情報の種類をファイル単位・スキャン単位で扱うdbo.MatchedClassificationActionや、変更追跡や監査に使えるdbo.ScannedFilesArchiveも利用されます。(Microsoft Learn)
| レポートで見たいこと | Custom Reportingで確認しやすくなる情報 |
|---|---|
| どのリポジトリに機密情報が多いか | ファイル単位の機密情報種類、件数、信頼度 |
| 未ラベルのまま機密情報を含むファイルはあるか | ラベル状態と検出結果の組み合わせ |
| ラベルが変更されたファイルはどれか | 現在のラベルと以前のラベル |
| 保護状態が変わったファイルはどれか | 現在の保護状態と以前の保護状態 |
| スキャン後の傾向をBIで見たい | SQL ServerやPower BI向けの集計元データ |
ただし、Custom Reportingは万能なダッシュボードではありません。公式情報でも、組み込みダッシュボードは提供されないこと、追加されるデータによりDB容量と読み取り負荷を考慮する必要があることが示されています。大規模環境では、SQL Server EnterpriseのAlways On構成などで、レポート用途を読み取り専用レプリカへ逃がす設計が推奨されています。(Microsoft Learn)
導入手順で管理者が確認すべき流れ
Information Protection scannerの導入は、インストール前の設計、ポータル設定、PowerShellでのインストール、認証、検出モード、本番適用の順で進めると安全です。最初から自動ラベル適用や保護を有効にすると、想定外のファイル変更が起きる可能性があります。
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 対象の棚卸し | ファイル共有、SharePoint Server、スキャン対象外にする場所を整理 | OneDrive、WebDav、ワイルドカード指定は前提にしない |
| ラベル確認 | スキャナーアカウントに公開される秘密度ラベルを確認 | 管理者本人ではなくスキャナーアカウントの適用範囲を見る |
| スキャンジョブ作成 | Microsoft Purviewポータルでクラスターとコンテンツスキャンジョブを作成 | 最初は手動実行、強制適用オフで始める |
| リポジトリ追加 | UNCパスやSharePoint Server URLを登録 | SharePointでは権限、URL長、承認済みコンテンツを確認 |
| スキャナーインストール | Install-ScannerでSQL Serverとクラスターを指定 | ローカル管理者権限とSQL権限が必要 |
| 認証設定 | Microsoft Entraトークンを取得し、Set-Authenticationを構成 | シークレット期限切れによる停止に注意 |
| 検出モード実行 | レポートのみで機密情報と影響範囲を確認 | 最初の実行結果を基準に除外条件を見直す |
| 本番適用 | Enforceをオンにし、必要に応じてスケジュール実行へ移行 | ラベル変更や保護適用の影響を段階的に確認 |
Microsoft Purviewポータルでスキャナー設定を行う場合、コンテンツスキャンジョブの初期設定では、スケジュールをManual、秘密度ポリシーの強制をOff、コンテンツに基づくラベル付けをOnにする構成が示されています。最初は「検出して報告する」状態で始め、結果を確認してから分類や保護の適用へ進めるのが実務上の安全策です。(Microsoft Learn)
DLPポリシーと組み合わせる場合も注意が必要です。DLPルールをオンにするのは、対象となるDLPポリシーを実際に使う場合に限るべきです。DLPポリシーがない状態でDLPルールを有効化すると、スキャナーエラーにつながる可能性があります。(Microsoft Learn)
移行・アップグレード時の注意点
既存環境でAzure Information Protection統合ラベルスキャナーを使っている場合は、移行手順の確認が重要です。特にAIP統合ラベルクライアント2.x系からMicrosoft Purview Information Protectionクライアント3.x系へ移行する場合、サービス名やコンポーネント名が変わるため、単純な上書き更新ではなく、公式手順に沿った移行が必要です。(Microsoft Learn)
2.x系から3.x系へ移行する場合は、既存構成の確認、AIPScannerサービス停止、旧スキャナーのアンインストール、再起動、3.xクライアントのインストール、Install-Scanner、Update-ScannerDatabase、MIPScannerサービス開始という流れになります。3.x系の旧バージョンから最新版へ更新する場合も、MIPScannerサービス停止、クライアント更新、データベース更新、サービス開始を計画的に行います。(Microsoft Learn)
バージョン選定では、一般提供版とプレビュー版を混同しないことが大切です。Microsoft Purview Information Protectionクライアント3.2.57.0は一般提供版として案内され、3.2.89.0はFeatureSettingsやCustom Reportingなどを含むプレビューとして案内されています。Custom Reportingを使う場合は、プレビュー機能の利用可否、検証範囲、本番適用の判断基準を社内で確認してください。(Microsoft Learn)
展開時に起きやすい失敗と対策
Information Protection scannerは、技術的にはPowerShellで導入できますが、運用面では複数部門の調整が必要です。以下のような失敗は、導入初期によく起こります。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| スキャナーアカウントにラベルが公開されていない | ラベル適用や分類が期待どおり動かない | スキャナーアカウントを対象にしたラベルポリシーを確認する |
| 最初から強制適用を有効にする | 想定外のラベル変更や保護適用が起きる | 初回は検出モードで実行し、レポートを確認する |
| SQL Serverを小さく見積もる | スキャン対象増加やCustom ReportingでDB負荷が高まる | ファイル数、平均ファイル名長、レポート負荷を見積もる |
| DLPルールを不用意にオンにする | DLPポリシー不整合でエラーになる | DLPポリシーを使う場合だけ有効化する |
| SharePointの制限を見落とす | 一部コンテンツがスキャンされない | リストしきい値、承認状態、URL長、権限を確認する |
| ノードごとに設定差がある | スキャン結果やレポートにばらつきが出る | FeatureSettingsでクラスター単位の設定を確認する |
SharePoint Serverでは、SharePoint 2019、2016、2013が対象として示されています。スキャナーは公開済みバージョンを検査し、コンテンツ承認が有効なライブラリでは承認済みファイルを扱います。また、SharePointのリストビューしきい値やURL長の設定も影響します。(Microsoft Learn)
ファイルパスにも注意が必要です。スキャナーはOffice形式など複数のファイル種類を扱えますが、パス長の制限やWindows側の長いパス設定が問題になることがあります。古いファイルサーバーや深いフォルダー階層を持つ環境では、事前に代表的なパスを確認しておくと、スキャン漏れやエラーの原因を減らせます。(Microsoft Learn)
代替構成で確認すべきこと
すべての環境が、インターネット接続、Microsoft Entra ID同期、ローカルログオン、SQL sysadmin権限をそろえられるとは限りません。公式情報では、標準構成が最も簡単で推奨される一方、インターネット接続できないコンピューター、Microsoft Entra ID同期ができない環境、ローカルログオンができないサービスアカウント、sysadmin権限を付与できないSQL Serverなどの代替構成も示されています。(Microsoft Learn)
たとえばSQL sysadmin権限を使えない場合、手動でデータベースを作成し、スキャナーサービスアカウントやインストール担当アカウントにdb_ownerロールを付与する構成が必要になります。データベース名には、クラスター名を含む形式が使われます。(Microsoft Learn)
また、オフラインに近い環境では、ポリシーのインポートやレポート保存場所の運用設計が重要になります。スキャナーはインポート済みポリシーに基づいてラベルを適用できますが、暗号化を含む保護やポリシー更新の扱いは慎重に設計する必要があります。(Microsoft Learn)
開発者・BI担当者が準備すべきレポート設計
Custom Reportingを使う場合、開発者やBI担当者は「何を可視化したいか」を先に決めてからSQLやPower BIの設計に入るべきです。スキャンデータが増えるほど、後から目的に合わないクエリを量産するとDB負荷が高まり、スキャナー本来の運用に影響します。
実務で役立つレポート例は次のとおりです。
| レポート例 | 目的 |
|---|---|
| 未ラベルかつ機密情報を含むファイル一覧 | 優先的に対応すべきリスクの洗い出し |
| リポジトリ別の機密情報件数 | 部門・共有フォルダー単位のリスク傾向把握 |
| ラベル変更履歴 | 自動ラベル適用の影響確認 |
| 保護状態の変化 | 暗号化や保護解除の監査 |
| スキャンエラー傾向 | 権限不足、パス長、ファイル形式問題の特定 |
Custom Reportingでは、スキャナークラスターDB内のテーブルをもとに、現在のラベル状態、以前のラベル状態、保護状態、検出された機密情報の種類や件数を分析できます。ただし、公式情報では、レポート用途の読み取り負荷を考慮し、必要に応じて読み取り専用レプリカを活用する考え方が示されています。(Microsoft Learn)
管理者が次に取るべき行動
Microsoft Purview Information Protection scannerをこれから導入する場合は、まずスキャン対象を一覧化し、対象ごとに「検出のみ」「ラベル適用」「保護まで実施」のどこまで行うかを決めてください。そのうえで、Windows Server、サービスアカウント、SQL Server、クライアント、秘密度ラベルの前提条件を確認します。
既存環境を更新する場合は、現在のクライアントバージョンとスキャナー構成を確認し、AIP 2.x系からの移行なのか、Purview 3.x系内のアップグレードなのかを切り分けます。Custom Reportingを使いたい場合は、3.2.89.0以降のプレビュー機能であることを踏まえ、検証環境でSQL容量、レポート負荷、PowerShell設定、運用手順を確認してから本番展開を判断するのが安全です。
導入時の基本方針は明確です。最初は検出モードで実行し、レポートを見て対象範囲とラベル条件を調整し、影響を把握してから強制適用へ進めます。Information Protection scannerは、設定すれば終わりのツールではなく、ファイルサーバーやSharePoint Server上のデータ保護を継続的に改善するための運用基盤として設計することが重要です。
コメント