Microsoft Purview Information Protection Scanner（IPスキャナー）で、テストと本番を分けて複数クラスター／複数コンテンツスキャンジョブを運用したいのに「Scanが出ない」「同時に走らない」と悩むケースは多いです。原因と設計のコツ、具体的な切り分け手順をまとめます。
まず押さえるべき前提：Microsoft Purview の「Information Protection Scanner」とは
ここで扱うのは、Microsoft Purview の機能のうち、オンプレミスやIaaS上のファイル共有（SMB）やSharePoint Server等を対象に、機密ラベルの自動適用や検出（検査）を行う Information Protection Scanner（IPスキャナー） です。Purview の「データマップのスキャン」とは別物で、実行主体はWindows Server上で動作するスキャナーサービス（スキャナーVM/マシン）になります。
このスキャナーは、ポータル上の設定（クラスター、コンテンツスキャンジョブ、リポジトリ）と、実行ノード（スキャナーVM）と、構成／状態を保持するSQL Server データベースが組み合わさって動きます。「クラスター＝論理的な実行グループ」「ノード＝実行エージェント」と捉えると設計が整理しやすくなります。
結論：複数クラスターは作れる。だが「1ノード＝1クラスター」が強い制約
テスト用フォルダーは既存クラスターで問題なくスキャンできた。次に本番用フォルダーを追加するにあたり、テスト／本番を分けて 別クラスター＋別コンテンツスキャンジョブ を作りたい――この設計自体は一般的で、運用や切り分けの観点でも有効です。
ただし、実装段階でつまずきやすいのが次の制約です。
- スキャナーノード（スキャナーVM/マシン）1台は、同時に1つのクラスターにしか紐づけられません。
- 同じマシン上で
Install-Scanner -Cluster <別クラスター名>のように再インストール／再登録を行うと、そのノードは新クラスターへ“付け替え” されます。 - 結果として旧クラスター側にはオンラインなノードが存在しなくなり、旧ジョブでは実行できない（UI上の挙動も変わる）状態になりがちです。
なぜ「Scan」ボタンが消えるように見えるのか
Purview ポータルで「Scan（Scan now）」ボタンが最新のジョブにしか出ない／以前のジョブでは出なくなる、という現象は、UIの不安定さというより「実行できるノードがそのクラスターに居ない」状態で説明できることが多いです。つまり、旧クラスター側のジョブから見ると、実行主体（ノード）が消えたため、実行ボタンや実行状態の見え方が変わります。
| やりたいこと | よくあるやり方 | 起きること（落とし穴） |
|---|---|---|
| テスト／本番を別クラスターで分けたい | 同じスキャナーVMでクラスターを作り直す | ノードが新クラスターに付け替わり、旧クラスターが「ノードなし」になりやすい |
| テストと本番を同時にスキャンしたい | テストジョブと本番ジョブを作る（ノードは1台） | ノードは同時に1つの実行しかできず、スキャンが直列（キュー待ち）になる |
| テストと本番を分離しつつ並列化したい | クラスターごとに別スキャナーVMを用意する | 王道。切り分けも性能も安定する（VM/運用コストは増える） |
「並列実行できない」の正体：スキャナーVM＝実行枠（1台につき同時1本）
スキャナーは、実行のイメージとしては 「セルフホステッド Integration Runtime（IR）のような実行エージェント」に近く、1つのノード（=1台）につき、同時に走れるスキャンは基本1本と考えると整理できます。
このため、テストと本番が同じノード（同じ実行枠）を共有していると、スキャン要求は順番待ちになり、見た目として「同時に動かせない」と感じます。逆に言えば、並列で回したいなら次のいずれかが必要です。
- 同一クラスター内にノードを複数台追加して処理を分散する
- テスト用クラスターと本番用クラスターを分け、クラスターごとに別ノードを割り当てる（推奨）
Always（常時）運用がキュー詰まりを起こしやすい理由
コンテンツスキャンジョブを「Always」にすると、変更検知のたびに実行要求が発生します。複数ジョブを同一ノードで「Always」にしていると、実行要求が積み上がり、キュー詰まり・遅延・“いつまでも終わらない”ような状態になりがちです。
Alwaysを使うなら、環境ごとにノードを分ける（テスト用／本番用）か、どうしても共有するなら「Alwaysをやめてスケジュール実行にする」「実行時間をずらす」「対象範囲を分割する」といった設計が必要になります。
おすすめ構成：テスト／本番を分けるなら「2クラスター × 2ノード（2VM）」
テストと本番を分ける狙いが「影響範囲の分離」「切り分けの容易さ」「本番優先の性能確保」であるなら、最も事故が少ないのは クラスターもノードも分ける構成です。イメージは次のとおりです。
| 要素 | テスト環境 | 本番環境 |
|---|---|---|
| クラスター名（例） | MIPScanner-TEST | MIPScanner-PROD |
| スキャナーVM（ノード） | ScannerVM-TEST（1台〜） | ScannerVM-PROD（1台〜） |
| SQL Server DB | ScannerTestDB（別DB） | ScannerProdDB（別DB） |
| 対象リポジトリ | テスト用ファイル共有／検証用フォルダー | 本番用ファイル共有／本番フォルダー |
| スキャン方式 | 手動 or スケジュール（短時間） | スケジュール or Always（要件に合わせて） |
構築の流れ（やることを順番に整理）
- クラスターを2つ作る（TEST / PROD）。
- SQL Server にDBを2つ用意する（1クラスター＝1DB。DBの共用は不可）。
- 各スキャナーVMで、該当クラスター名とDBを指定して Install-Scanner を実行し、ノードを登録する。
- 各ノードで 認証設定（Set-Authentication 等）を行う（ノード単位で必要）。
- Purview ポータルで、各クラスターに対して コンテンツスキャンジョブを作成し、対象リポジトリを紐づける。
- 「手動/スケジュール/Always」を要件に合わせて設定し、並列に回ることを確認する。
PowerShell 例（概念の確認用）
コマンドレット名やパラメーターはスキャナーの世代・モジュールで差が出ることがあります。まずは対象VMで Get-Command *Scanner* 等で利用可能なコマンドを確認し、公式の手順に合わせてください。ここでは「クラスター名を指定して登録する」「ノードごとに認証する」という流れが伝わるよう、代表例として記載します。
# 1) スキャナーをクラスターに登録（例）
Install-Scanner -Cluster "MIPScanner-TEST" -SqlServer "SQL01" -Database "ScannerTestDB"
# 2) 認証設定（例：Entra ID のアプリ登録を利用）
Set-Authentication -TenantId "<TenantId>" -AppId "<ClientId>" -CertificateThumbprint "<Thumbprint>"
# 3) 状態確認（例）
Get-ScanStatus -Verbose
SQL Server は共有していい？「同一インスタンスにテストDB＋本番DB」は可能
テスト用／本番用でクラスターを分けると、SQL Server 側も分ける必要があるのかが気になります。結論から言うと、同一 SQL Server インスタンスに、クラスターごとの別DBを置く構成は可能です。ただし、クラスターごとに別DBが必須で、DBそのものを共用するのは避けるべきです（設定や状態が衝突し、切り分けも困難になります）。
| 観点 | 同一SQLインスタンスに2DB | SQLも分離（別インスタンス/別サーバー） |
|---|---|---|
| 構築コスト | 低い（DB追加だけで済む） | 高い（サーバー/運用が増える） |
| 単一障害点 | SQL障害でTEST/PRODが同時に影響 | 影響範囲を限定しやすい |
| 負荷競合 | テストの重いスキャンが本番に影響する可能性 | 競合しにくい |
| 分離要件（監査/権限） | DB単位で最小権限・監査を設計すれば対応可能なことも多い | より強固（組織要件が厳しい場合に有利） |
現実的には「初期は同一SQLインスタンス＋DB分離」で始め、本番の可用性（HA）や負荷が問題になった段階で、SQL の高可用性（Always On 等）やサーバー分離を検討するのが進めやすいです。
新しいスキャナーVMを追加したら、認証（トークン設定）はやり直す？
結論は はい です。スキャナーは ノード単位で認証情報を保持して動作するため、同じアプリ登録（Entra ID）や同じサービスアカウントを使う設計でも、新VM側で改めて認証設定（トークン取得/証明書紐づけ）が必要になります。
| 項目 | どこに紐づくか | 新VM追加時に必要？ | 理由 |
|---|---|---|---|
| クラスター | Purview ポータル + SQL DB | 不要（既存を使える） | クラスター自体は論理構成。ノードを追加するだけ |
| SQL DB | SQL Server | 不要（同じDBに接続） | 同じクラスターに参加させるなら同じDBを参照する |
| 認証設定（Set-Authentication 等） | 各ノード（ローカル） | 必要 | ノードがクラウドサービスへ認証するための設定はローカルに持つ |
| リポジトリへのアクセス権 | ファイル共有/SharePoint/サービスアカウント | 必要 | 新VMの実行コンテキストで実際に読み取りできる必要がある |
特にテスト／本番で分離している場合、アプリ登録や証明書を共用するか、環境ごとに分けるかは組織のポリシー次第です。強い分離が必要なら、本番用は本番用のアプリ登録・証明書・サービスアカウントまで分けると監査や権限管理が楽になります。
「Error」表示や状態不整合の切り分け：まず確認するポイント
スキャナー周りの“Error”は、原因が「認証」「DB接続」「ノード登録」「対象リポジトリ権限」「サービス停止」など複数レイヤーに分かれます。闇雲に設定を触るより、上から順に潰していく方が復旧が早いです。
| 症状 | よくある原因 | 確認・対処（例） |
|---|---|---|
| 旧ジョブで「Scan」が出ない | 旧クラスターにオンラインなノードがいない／ノードが別クラスターに付け替わった | ポータルでクラスターのノード状態を確認。必要なら旧クラスター用ノードを用意する |
| スキャンが同時に走らない | ノードが1台で、実行が直列（キュー待ち） | 並列化したいならノードを増やす（クラスターごとにVMを分けるのが確実） |
| ジョブが「Queued / In progress」から動かない | Always の要求が積み上がり／ノード不足／サービス停止 | Alwaysを見直す、対象を分割、ノード追加、サービス状態の確認 |
| クラスターが Offline / Error | スキャナーサービス停止、SQL接続不可、認証失効 | Get-Service でサービス確認、SQL疎通、認証の再設定 |
Get-ScanStatus -Verbose に別環境のノード名が混在 | クラスター分離が崩れ、別クラスター/別DBの情報が混線 | 各VMのクラスター名・DB接続先を再確認。不要ノードの整理、サービス再起動 |
| ポータル上の状態が更新されない | サービスがハング／通信断／キャッシュ | スキャナーサービス再起動、しばらく待って再表示、イベントログ/ログ確認 |
「最後はサービス再起動で直った」を再現性ある手順にする
実際の現場では、構成が正しくても一時的な通信断やハングで状態がズレ、ポータル上は Error や Offline に見えることがあります。今回のケースでも、新スキャナーVM側でスキャナーサービスを再起動したことで状態が正常化し、テスト用VMと本番用VMで並列スキャンが実現できました。
ただし、再起動は「万能薬」ではありません。次の3点をセットで実施すると、再発防止につながります。
- どのVMがどのクラスターに紐づいているかを明文化（運用台帳）する
- SQL DB 名をクラスター名と揃えて、接続先の取り違えを防ぐ
- Always運用は本番だけに絞る、または対象を分割し、キュー詰まりを作らない
実務で使える「チェックリスト」：テスト／本番を分けるときの落とし穴を先に潰す
次のチェックを満たしていれば、複数クラスター／複数コンテンツスキャンジョブの運用はかなり安定します。
- テストクラスターと本番クラスターで ノード（VM）を分けた
- SQL Server は共有でもよいが、DBは必ず分けた（TEST/PRODで別DB）
- 各VMで 認証設定（Set-Authentication 等）を実施し、期限管理も行っている
- ファイル共有の権限は、スキャナーの実行アカウントに最小権限で付与している
- 本番ジョブは負荷と影響を考慮して、スケジュール/Alwaysを慎重に選んだ
「設定後、テスト配下は再スキャンされる？」への答え
一般に、スキャンはジョブ設定（手動/スケジュール/Always）に従って実行され、新規・更新分を中心に再評価が走ります。クラスターやDBを作り直した場合は、前回状態を引き継がないことも多いため、結果として「再スキャンされた」ように見えることがあります。
テスト環境で検証するときは、次のように運用すると安心です。
- 最初は小さなテストフォルダーで動作確認し、対象範囲を段階的に広げる
- 除外条件（不要な拡張子、アーカイブ等）を設定し、スキャン時間の予測可能性を上げる
- 初回フルに近いスキャンが走る可能性を前提に、テスト時間帯を確保する
運用のコツ：本番で“止まらないスキャナー”にするために
最後に、テストから本番へ移行するときに差が出やすいポイントをまとめます。
- 本番は冗長化を意識：本番クラスターにノードを2台以上用意できると、片系停止時もスキャンが継続しやすい
- SQL はボトルネックになり得る：CPU/IO、バックアップ、メンテ時間帯を把握し、必要ならHAを検討
- ジョブ設計は“分割”が効く：巨大な共有を1ジョブで抱えず、部門別/パス別に分けて影響を限定
- トラブル時は「ノード→DB→認証→権限」の順：原因の層を意識すると復旧が早い
まとめ
Microsoft Purview Information Protection Scanner で「複数クラスター／複数コンテンツスキャンジョブ」を運用すること自体は問題ありません。むしろテスト／本番の分離には有効です。一方で、1ノード＝1クラスターという制約が強く、同じVMでクラスターを作り替えると旧クラスターのジョブで「Scan」が出なくなるなど、意図しない挙動に見えやすくなります。
並列実行を実現したいなら、クラスターごとに 別スキャナーVM（別ノード） を用意し、DBも分け、各ノードで認証設定を行う――この王道構成が最短です。加えて、Always運用のキュー詰まりやSQLの単一障害点といった運用課題も先回りして設計すれば、安定したスキャン基盤になります。
コメント