Microsoft Purview Information Protection scannerの2026年4月更新でまず押さえるべき結論は、インストール手順そのものよりも、アップグレード判断、認証方式、スキャナー機能の管理、レポート設計への影響が大きいという点です。特に2026年4月22日に公開された3.2.89.0 Previewでは、スキャナー機能をクラスター単位で制御する仕組み、-FeatureSettings、Custom Reporting、Microsoft Graph連携が追加されています。既存環境の管理者は、いきなり本番適用するのではなく、現在のクライアントバージョン、認証方式、SQL Server構成、DLPポリシー、スキャン対象リポジトリを棚卸ししてから検証環境で確認するのが安全です。(Microsoft Learn)
2026年4月更新の要点は「スキャナーをどう運用管理するか」にある
Microsoft公式の「Configure and install the Microsoft Purview Information Protection scanner」は、Microsoft Purview Information Protection scannerの設定・インストール手順をまとめた中核ドキュメントです。ページ内では、スキャナーが以前のAzure Information Protection unified labeling scanner、またはオンプレミススキャナーと呼ばれていたこと、設定の流れとしてスキャナー設定、インストール、Microsoft Entraトークン取得、分類と保護の適用設定を行うことが示されています。(Microsoft Learn)
2026年4月時点で実務上重要なのは、次の4点です。
| 更新・注目点 | 実務への影響 | まず確認すべきこと |
|---|---|---|
| 3.2.89.0 Previewの公開 | 新機能を試せるが、本番標準にする前に検証が必要 | 検証環境、ロールバック手順、既存ジョブへの影響 |
-FeatureSettingsによる機能制御 | スキャナークラスター単位で機能の有効・無効を管理できる | PowerShell運用者、変更承認フロー |
| Custom Reporting Preview | スキャン結果をSQLベースで分析しやすくなる | SQL Serverの容量、読み取り負荷、Power BI連携方針 |
| Microsoft Graph連携の追加 | カスタム権限のユーザー・グループ参照が変わる | アップグレード後の再認証、アプリ権限、Entra管理者との連携 |
ここで注意したいのは、4月更新のすべてが本番運用向けのGA機能ではないことです。Microsoftのリリースノートでは、3.2.89.0はPreviewとして公開されており、Preview機能には一般提供版とは異なる扱いが含まれます。Microsoft Download Centerで公開されているGA版は3.2.57.0で、2026年3月26日公開、サポート期限は2027年3月26日とされています。(Microsoft Learn)
Microsoft Purview Information Protection scannerとは
Microsoft Purview Information Protection scannerは、オンプレミスのファイル共有やSharePoint Server上のファイルをスキャンし、機密情報の検出、秘密度ラベルの適用、必要に応じた保護を行うためのコンポーネントです。Microsoft 365アプリに組み込まれたラベル機能だけでは届きにくい、古いファイルサーバー、部門共有、オンプレミスSharePointの文書に対して、データ保護の範囲を広げる目的で使います。(Microsoft Learn)
たとえば、次のような課題に向いています。
| 課題 | scannerでできること |
|---|---|
| ファイルサーバーに機密文書が散在している | 共有フォルダーをスキャンし、機密情報タイプに一致するファイルを検出する |
| ラベル未適用の古いOffice文書が多い | 条件に基づいて秘密度ラベルを自動適用する |
| オンプレミスSharePointにもDLPの観点を入れたい | DLPポリシーと組み合わせて、潜在的な情報漏えいリスクを検出する |
| 監査・棚卸し用のレポートを作りたい | スキャン結果や分類結果を確認し、レポート設計に活用する |
クラウド上のSharePoint OnlineやOneDriveを直接置き換える機能ではありません。スキャン対象の設計では、オンプレミスのファイル共有、ローカルパス、UNCパス、オンプレミスSharePoint URLなどを正しく切り分ける必要があります。公式手順では、ワイルドカードやWebDAVの場所はサポートされず、OneDriveの場所をリポジトリとしてスキャンすることもサポートされないとされています。(Microsoft Learn)
Configure and installの基本フロー
Microsoft Purview Information Protection scannerの導入は、ポータル操作だけで完結するものではありません。Microsoft Purviewポータルでスキャナークラスターやスキャンジョブを作成しつつ、Windows Server上ではPowerShellでインストールや認証設定を行います。
基本の流れは次のとおりです。
| 手順 | 主な作業 | 主な担当 |
|---|---|---|
| 前提条件の確認 | Windows Server、SQL Server、サービスアカウント、ラベル、ネットワーク接続を確認 | security admins、identity teams、インフラ担当 |
| スキャナークラスター作成 | Microsoft Purviewポータルでクラスター名を作成 | compliance teams、security admins |
| コンテンツスキャンジョブ作成 | スキャン対象、スケジュール、ラベル適用、DLP利用有無を設定 | compliance teams |
| scannerのインストール | Windows Server上でInstall-Scannerを実行 | インフラ担当、security admins |
| Microsoft Entra認証設定 | アプリ登録、API権限、Set-Authenticationを設定 | identity teams |
| 検出モードで初回スキャン | 影響を確認するため、まずレポート中心で実行 | security admins、compliance teams |
| 分類・保護の適用 | 検証後にスケジュールやEnforceを有効化 | compliance teams、業務部門承認者 |
ポータルでスキャナー設定を行う場合、Compliance Administrator、Compliance Data Administrator、Security Administrator、Organization Managementなどのロールでサインインし、Settings > Information Protection > Information protection scannerからスキャナークラスターとコンテンツスキャンジョブを作成します。(Microsoft Learn)
インストール時の代表的なコマンドは次の形式です。
Install-Scanner -SqlServerInstance SQLSERVER1 -Cluster EuropeSQL Serverの名前付きインスタンスを使う場合は、次のように指定します。
Install-Scanner -SqlServerInstance SQLSERVER1\SCANNER -Cluster EuropeSQL Server Expressを検証用途で使う場合は、次の形式です。
Install-Scanner -SqlServerInstance SQLSERVER1\SQLEXPRESS -Cluster Europeただし、本番ではSQL Serverの容量、可用性、スキャン対象ファイル数、レポート負荷まで考慮する必要があります。前提条件では、SQL Server 2016以降が最小要件として示され、インストール時にはSQL Server側のSysadmin権限が必要です。Microsoftは小規模構成を除き、scannerサービスとSQL Serverを別マシンに分けることも推奨しています。(Microsoft Learn)
2026年4月22日の3.2.89.0 Previewで変わったこと
スキャナー機能をクラスター単位で制御できるようになった
3.2.89.0 Previewでは、Microsoft Purview Information Protection scannerに「admin-controlled feature configuration」が追加されました。これは、スキャナー管理者がPowerShellを使って、対応する機能をクラスター単位で有効化、無効化、設定できる仕組みです。設定は共有スキャナークラスターDBのdbo.Featuresテーブルに保存され、同じクラスター内の各ノードが次回スキャンサイクルで設定を取得します。サービス再起動は不要とされています。(Microsoft Learn)
実務上は、複数ノードでscannerを運用している組織ほどメリットがあります。従来は、各ノードの設定差分や、誰がどの機能を有効化したかを管理しにくい場面がありました。クラスター単位のFeatureSettingsで管理できれば、設定の一貫性を保ちやすくなります。
ただし、Microsoft PurviewポータルとPowerShellの両方で同じ機能を扱えるようになった場合は、ポータル側の設定が優先されます。Microsoftは、ポータルで管理された機能についてはPowerShellから変更できない場合があると説明しています。(Microsoft Learn)
-FeatureSettingsパラメーターが追加された
3.2.89.0 Previewでは、Install-ScannerとSet-ScannerConfigurationに-FeatureSettingsハッシュテーブルパラメーターが追加されています。これにより、新規インストール時または既存クラスターの設定変更時に、サポート対象機能をまとめて指定できます。(Microsoft Learn)
既存クラスターでCustom Reportingを有効化する例は次のとおりです。
Set-ScannerConfiguration -FeatureSettings @{CustomReporting="On"}新規インストール時に有効化する例は次のとおりです。
Install-Scanner -SqlServerInstance SQLSERVER1 -Cluster Europe -FeatureSettings @{CustomReporting="On"}現在公式ドキュメントで明示されている対応機能はCustomReportingで、既定値はOffです。未知の機能名を指定すると、サポート対象機能の一覧を示したエラーで終了し、その呼び出し内の設定は適用されないと説明されています。(Microsoft Learn)
Custom Reporting PreviewでSQLベースの分析がしやすくなった
Custom Reportingは、スキャン結果をより詳細にSQL Server上で扱えるようにするPreview機能です。従来はスキャンごとのCSVやTXTレポートを組み合わせて分析する必要があり、継続的な傾向分析や差分確認には手間がかかりました。Custom Reportingでは、ラベル状態、保護状態、検出された機密情報タイプ、前回スキャンとの差分などをスキャナークラスターDBに格納できるようになります。(Microsoft Learn)
たとえば、次のような問いに答えやすくなります。
| 分析したい問い | Custom Reportingで見やすくなる情報 |
|---|---|
| どのリポジトリに機密情報タイプが集中しているか | ファイルごとのSIT一致数、リポジトリ別の集計 |
| 前回スキャン後にラベルが変わったファイルはどれか | 現在のラベル、前回ラベル、スキャンセッションID |
| 未ラベルだが機密情報を含むファイルはどれか | ラベル未設定状態とSIT一致情報の組み合わせ |
| 保護済みに変わったファイルはどれか | 現在と前回の保護状態 |
| Power BIで監査ダッシュボードを作れるか | SQLベースのレポートデータ |
一方で、Custom Reportingを有効にすると、スキャン対象ファイル数や機密情報タイプの一致数に応じて、SQL Server上のデータ量と読み取り負荷が増えます。Microsoftは、本番環境で利用する場合、スキャン処理とレポート参照が同じDBリソースを奪い合わないよう、SQL Server EnterpriseのAlways On可用性グループと読み取り可能なセカンダリレプリカの利用を推奨しています。(Microsoft Learn)
つまり、Custom Reportingは「便利そうだからオンにする」機能ではありません。大規模ファイルサーバーを扱う組織では、SQL Serverの容量見積もり、インデックス、レポート更新間隔、Power BIなどの参照先、監査データの保管期間を先に決める必要があります。
証明書ベース認証は導入候補だが、Preview扱いに注意
3.2.57.0では、Microsoft Purview Information Protection scanner、client、Set-Authentication PowerShell cmdlet向けに証明書ベース認証のPreviewサポートが追加されました。従来のクライアントシークレット方式では、期限切れや秘匿管理が課題になりがちです。証明書ベース認証は、組織のPKIや証明書ライフサイクル管理と連携しやすい点で、identity teamsにとって検討価値があります。(Microsoft Learn)
公式手順では、証明書ベース認証の前提として、scannerがインストール済みであること、scannerを実行するWindows Serverへの管理者アクセス、Microsoft Entraアプリ登録へのアクセス、Windows PowerShell 5.1が必要とされています。CA発行証明書を使う場合は、RSA、2048ビット以上、Digital Signature、組織ポリシーに沿った有効期間などの条件が示されています。(Microsoft Learn)
証明書認証で特に失敗しやすいのは、秘密キーの読み取り権限です。scannerサービスアカウントが証明書の秘密キーを読み取れないと、Keyset does not existエラーにつながります。また、自己署名証明書を作る場合、CNGプロバイダーではなくMicrosoft Enhanced RSA and AES Cryptographic Providerを指定しないと、同じく認証失敗の原因になると説明されています。(Microsoft Learn)
証明書ベース認証へ移行する場合の流れは、証明書作成、Microsoft Entraアプリ登録への公開キーアップロード、Set-Authenticationの証明書パラメーター指定、scannerサービス再起動です。既存のシークレットベース構成は新しい認証構成で上書きされます。(Microsoft Learn)
$pscreds = Get-Credential CONTOSO\ScannerService
Set-Authentication `
-AppId "your-app-id-guid" `
-TenantId "your-tenant-id-guid" `
-DelegatedUser "[email protected]" `
-CertificateThumbprint "your-certificate-thumbprint" `
-CertificateStoreLocation LocalMachine `
-CertificateStoreName My `
-OnBehalfOf $pscreds本番適用前には、証明書失効時の復旧手順、証明書更新の担当、秘密キーのバックアップ、Entraアプリ登録の棚卸しを必ず決めておきましょう。
Microsoft Graph連携で再認証が必要になるケースがある
3.2.89.0 Previewでは、カスタム権限のユーザーやグループ参照にMicrosoft Graphが統合されました。これにより、従来のクラシックなOutlook contact pickerへの依存がなくなるとされています。一方で、アップグレード後にClear-Authenticationを実行してからSet-Authenticationを再実行し、Microsoft Graph接続に必要なアクセストークンを取得する必要があると説明されています。(Microsoft Learn)
これはidentity teamsにとって見落としやすいポイントです。scannerのアップグレード作業をsecurity adminsだけで進めると、Entraアプリ権限、管理者同意、トークン更新、委任ユーザーのポリシー割り当てが後回しになり、スキャンやラベル適用が止まる可能性があります。
アップグレード計画には、次の確認を入れてください。
| 確認項目 | 見落とすと起きる問題 |
|---|---|
| Entraアプリ登録の所有者 | 認証更新時に誰も変更できない |
| APIアクセス許可と管理者同意 | Set-Authentication後に必要なトークンを取得できない |
| DelegatedUserのラベルポリシー | scannerが想定するラベルを取得できない |
| サービスアカウントの権限 | ファイル読み取り、書き込み、保護適用に失敗する |
| 既存シークレットの期限 | 突然scannerが無人実行できなくなる |
アップグレード時は2.x系と3.x系で手順が違う
Microsoft公式のアップグレード手順では、Azure Information Protection unified labeling client 2.xからMicrosoft Purview Information Protection client 3.xへ移行する場合、サービス名やコンポーネント名の変更に伴って追加の手順が必要とされています。手順を省略するとscannerが動作しなくなる可能性があるため、2.x系からの移行では特に慎重に進める必要があります。(Microsoft Learn)
2.x系からのアップグレードでは、既存構成の確認、旧scannerサービス停止、旧scannerアンインストール、サーバー再起動、AIP unified labeling clientのアンインストール、3.xクライアントのインストール、scanner再インストール、DB更新、サービス開始という流れになります。(Microsoft Learn)
一方、既存のMicrosoft Purview Information Protection client 3.xから新しい3.xへ上げる場合は、scannerサービスを停止し、最新クライアントをインストールし、1台のノードでUpdate-ScannerDatabaseを実行し、各ノードのサービスを開始する流れです。(Microsoft Learn)
アップグレード前に確認すべき判断基準は次のとおりです。
| 現在の状態 | 推奨される進め方 |
|---|---|
| AIP unified labeling client 2.xを利用中 | 3.xへの移行手順を別プロジェクトとして扱う |
| Purview client 3.xの古いGAを利用中 | サポート期限、修正内容、DB更新要否を確認して計画アップグレード |
| 3.2.57.0 GAを利用中 | 本番継続の基準にしつつ、Preview機能は検証環境で確認 |
| 3.2.89.0 Previewを試したい | 検証環境でCustom Reporting、FeatureSettings、Graph再認証をテスト |
| scannerが複数ノード構成 | 1台だけでDB更新し、サービス停止・開始順序を明確にする |
導入前に確認すべき前提条件
scannerのトラブルは、製品不具合よりも前提条件の不足で起きることが多いです。特にWindows Server、SQL Server、サービスアカウント、ラベルポリシー、ネットワーク接続は、導入前に担当を分けて確認しておきましょう。
| 項目 | 確認内容 | 実務上の注意 |
|---|---|---|
| Windows Server | scannerを実行するサーバーのOS、CPU、メモリ、ディスク | 前提条件では4コア、8GB RAM、平均10GBの一時ファイル領域が示されている |
| SQL Server | バージョン、インスタンス、照合順序、権限、容量 | 大規模環境ではscannerとSQL Serverの分離を検討する |
| サービスアカウント | ADアカウントでありMicrosoft Entra IDへ同期されているか | ラベル取得、ファイルアクセス、無人実行に関わる |
| リポジトリ権限 | ファイル共有、ローカルファイル、SharePointの読み取り・書き込み権限 | Discoveryのみなら読み取りで足りるが、ラベル適用や保護には追加権限が必要 |
| ラベル構成 | scanner用DelegatedUserにラベルポリシーが割り当てられているか | ラベルが公開されていないと自動分類・保護が機能しない |
| ネットワーク | 必要なMicrosoftサービスURLへHTTPS通信できるか | インターネット接続不可の環境では代替構成が必要 |
| PowerShell | Windows PowerShell、PurviewInformationProtectionモジュール | 一部設定はポータルではなくPowerShellが必須 |
| SharePoint | 対象バージョン、URL、権限、長いパスへの対応 | ルートURL配下の検出には追加権限が必要になる |
サービスアカウントは、scannerサービスの実行、Microsoft Entra IDへの認証、scannerポリシーのダウンロードに使われます。公式前提条件では、このアカウントはActive Directoryアカウントであり、Microsoft Entra IDへ同期されている必要があるとされています。(Microsoft Learn)
また、本番ネットワークではMicrosoft Purview Information Protection clientの現在のGA版をWindows Serverにインストールする必要があり、scannerにはPowerShellモジュールだけでなくフルクライアントが必要です。(Microsoft Learn)
コンテンツスキャンジョブ設定で失敗しやすいポイント
初回はManual、Policy only、Enforce Offで始める
公式手順では、初期構成としてスケジュールはManual、検出する情報タイプはPolicy only、秘密度ラベルポリシーの強制はOff、コンテンツに基づくラベル付けはOn、再ラベルはOffなどが示されています。これは、いきなりファイルを書き換えたり保護を適用したりするのではなく、まず検出結果と影響範囲を確認するためです。(Microsoft Learn)
実務では、次の順序が安全です。
| フェーズ | 設定の考え方 | 目的 |
|---|---|---|
| 検証 | 小さな共有フォルダー、Manual、Enforce Off | ラベル条件、権限、ログ出力を確認 |
| パイロット | 部門共有、Manualまたは限定スケジュール | 誤検知、業務影響、処理時間を確認 |
| 展開 | 対象を拡大、Schedule Alwaysを検討 | 継続スキャンで新規・変更ファイルを検出 |
| 適用 | Enforce On、DLP連携、保護適用 | 実際の分類・保護を運用に組み込む |
DLPルールはポリシーがある場合だけ有効化する
Microsoft Purview Information Protection scannerでは、DLPポリシーを使ってファイル共有やSharePoint Server上のファイルに対する潜在的なデータ漏えいを検出できます。ただし、公式ドキュメントでは、Microsoft 365側でDLPポリシーが構成されていない場合にEnable DLP rulesをOnにしないよう明記されています。DLPポリシーなしで有効化すると、scannerがエラーを生成します。(Microsoft Learn)
これはcompliance teamsとsecurity adminsの連携が必要なポイントです。DLPポリシーの目的、テストモードか適用モードか、権限変更が発生するか、影響を受けるデータ所有者は誰かを事前に決めてから有効化しましょう。
リポジトリ指定ではワイルドカードを使わない
ファイル共有の指定は\\Server\Folder、ローカルパスはC:\Folder、SharePointライブラリはURLで指定します。公式手順では、ワイルドカードとWebDAVの場所はサポートされないとされています。また、OneDriveの場所をリポジトリとしてスキャンすることもサポートされません。(Microsoft Learn)
悪い例は次のような指定です。
\\Server\*\Finance現実的には、対象共有を棚卸ししてから、スキャン対象を段階的に追加します。大規模な組織では、部門、地域、データ種別ごとにクラスター名やコンテンツスキャンジョブ名を設計しておくと、後のレポート分析や障害調査が楽になります。
パフォーマンス設計ではネットワーク、CPU、ログレベルを見直す
scannerはファイルを読み取り、内容を検査し、必要に応じて暗号化やラベル適用を行います。そのため、ネットワーク、CPU、ファイルサイズ、保護状態、ログレベルが処理時間に影響します。Microsoftは、scannerマシンとスキャン対象データストアの間に高速で信頼できるネットワーク接続を用意すること、CPUリソースを監視すること、複数scannerの導入を検討することなどを案内しています。(Microsoft Learn)
特にログレベルは見落としやすい設定です。Debugはトラブルシューティングには有効ですが、scannerを大きく遅くする可能性があります。通常運用ではInfoやError、性能優先ではOffを検討し、問題調査時だけDebugに切り替える運用が現実的です。(Microsoft Learn)
| パフォーマンス要因 | 改善の考え方 |
|---|---|
| ネットワーク距離 | scannerを対象ファイルサーバーと同じLANまたは近いネットワークセグメントに置く |
| CPU不足 | スキャンサイクル中のCPU使用率を監視し、ノード追加を検討する |
| PDFや大容量ファイル | Officeファイルより時間がかかる前提で処理時間を見積もる |
| 保護済みファイル | 復号・再保護の負荷を考慮する |
| カスタム正規表現 | greedy quantifierを避け、タイムアウトやメモリ消費を抑える |
| Debugログ | 常時有効にせず、調査時だけ使う |
| Custom Reporting | SQL Serverの書き込み量とレポート参照負荷を見積もる |
グローバル展開ではポータル利用可否とリージョン事情を確認する
対象読者がグローバル組織のsecurity admins、identity teams、compliance teamsである場合、すべての環境で同じ手順が使えるとは限りません。Microsoftは、ほとんどの顧客は管理ポータルで手順を実行するものの、管理ポータルへアクセスできない環境ではPowerShellのみで構成する必要があると説明しています。例としてAzure China 21Vianet環境ではPowerShell手順を参照するよう案内されています。(Microsoft Learn)
グローバル展開で確認すべき点は次のとおりです。
| 観点 | 確認すること |
|---|---|
| 管理ポータル | 各リージョン、各テナントでMicrosoft Purviewポータルの該当ページにアクセスできるか |
| ID基盤 | オンプレAD、Microsoft Entra ID同期、サービスアカウントのUPNが整合しているか |
| データ所在地 | どの国・地域のファイルサーバーをどのscannerでスキャンするか |
| ネットワーク | scannerとデータストアの距離、帯域、プロキシ、HTTPS許可先 |
| 変更管理 | ラベル適用、DLP、権限変更に各国の承認プロセスが必要か |
| 監査 | レポート保存先、参照権限、SQLデータの保持期間 |
特にCustom Reportingを使う場合、スキャナークラスターDBにより詳細なスキャン情報が保存されます。グローバル環境では、どの地域のデータをどのSQL Serverに保存し、誰がレポート参照できるのかを明確にしましょう。
役割別の対応ポイント
security adminsがやるべきこと
security adminsは、scannerを単なるインストール対象ではなく、データ保護基盤の一部として管理する必要があります。まず、現在のscannerバージョン、スキャン対象、サービス状態、エラー傾向、レポート出力先を棚卸しします。次に、3.2.57.0 GAへの更新状況と、3.2.89.0 Previewの検証要否を分けて判断します。
| やること | 目的 |
|---|---|
| 現在のクライアントバージョンを確認 | サポート期限と修正適用状況を把握する |
| 2.x系利用有無を確認 | 3.x移行時の追加手順を見落とさない |
| scannerサービスの稼働状況を確認 | ノード停止や認証失敗を早期に発見する |
| Debugログ常時有効化を避ける | スキャン性能の低下を防ぐ |
| Custom Reportingを検証環境で試す | レポート要件とSQL負荷を見積もる |
identity teamsがやるべきこと
identity teamsは、Microsoft Entraアプリ登録、サービスアカウント、DelegatedUser、証明書、API権限を管理します。2026年4月更新ではMicrosoft Graph連携や証明書ベース認証が関係するため、アップグレード作業に早い段階から参加すべきです。
| やること | 目的 |
|---|---|
| Entraアプリ登録の所有者を明確化 | 認証更新時に作業不能になるのを防ぐ |
| クライアントシークレット期限を棚卸し | 無人実行の突然停止を防ぐ |
| 証明書ベース認証を検証 | シークレット依存を減らす選択肢を評価する |
| Microsoft Graph連携後の再認証を計画 | アップグレード後のトークン不足を防ぐ |
| DelegatedUserのラベルポリシーを確認 | scannerが必要なラベルを取得できるようにする |
compliance teamsがやるべきこと
compliance teamsは、ラベル設計、DLPポリシー、スキャン対象、レポート要件を整理します。特にDLPを有効化する場合は、検出だけなのか、権限変更まで含むのかを明確にする必要があります。
| やること | 目的 |
|---|---|
| 自動ラベル条件を確認 | 誤検知・過検知を抑える |
| 初回スキャンはDiscovery中心で行う | 業務影響を把握する |
| DLPポリシー有無を確認 | DLP未構成でscannerエラーを出さない |
| データ所有者を特定 | 検出結果の是正依頼を回せるようにする |
| Custom Reportingの指標を決める | SQLデータを監査・経営報告に活かす |
2026年4月更新を受けた推奨アクション
まず本番環境では、GA版である3.2.57.0を基準に、サポート期限、既存不具合、証明書ベース認証Previewの検証要否を確認します。3.2.89.0 Previewは、Custom ReportingやFeatureSettingsを評価したい組織にとって重要ですが、いきなり本番適用するのではなく、検証環境でスキャンサイクル、DB負荷、再認証、レポート接続を確認してから判断します。(Microsoft Learn)
次に、既存scannerがある場合はアップグレード手順を必ず分岐させます。AIP unified labeling client 2.xからの移行と、Purview Information Protection client 3.x内の更新では手順の重さが違います。2.xから3.xへ移行する場合は、サービス名やcmdlet、Office Add-in削除などの影響を含め、変更管理として扱うべきです。(Microsoft Learn)
最後に、スキャンの目的を明確にします。機密情報の棚卸しだけならDiscoveryから始めれば十分です。自動ラベルや保護を適用するなら、ラベル条件、再ラベル可否、DLPポリシー、サービスアカウント権限、データ所有者の承認をそろえる必要があります。Custom Reportingを使うなら、単に「レポートが増える」ではなく、どの部門がどの指標を見て、どの是正アクションにつなげるのかまで決めておくことが重要です。
まとめ：4月更新は「導入手順」より「運用設計」の見直しが重要
Microsoft Purview Information Protection scannerの2026年4月更新ポイントは、インストールコマンドの変更だけを追うより、スキャナー運用全体を見直す視点で捉えるべきです。
特に重要なのは、3.2.89.0 Previewで追加されたFeatureSettings、Custom Reporting、Microsoft Graph連携、そして3.2.57.0で追加された証明書ベース認証Previewです。security adminsはバージョンとスキャン運用を棚卸しし、identity teamsはEntraアプリ登録と認証方式を確認し、compliance teamsはラベル・DLP・レポート要件を整理しましょう。
次に取るべき行動はシンプルです。既存環境のバージョン、認証方式、スキャン対象、SQL Server構成を一覧化し、GA版への更新計画とPreview機能の検証計画を分けて作成してください。そのうえで、小さな検証用リポジトリからDiscoveryモードで動かし、結果、権限、処理時間、レポート負荷を確認するのが、もっとも安全で実務的な進め方です。
コメント