Microsoft Purview の Insider Risk Management を運用している管理者にとって、今回の更新で最も重要なのは、variant をより細かく作れるようになり、detection group に登録できる項目数も増える点です。具体的には、variant の上限が「1 indicator あたり 3 件」から「1 indicator あたり 10 件」へ拡大され、全 indicator 合計では 100 件まで作成できるようになります。あわせて、1 つの detection group に含められる項目数も 200 件から 500 件へ増えます。Microsoft 365 Roadmap の機能 ID 511798 では、対象製品は Microsoft Purview、プラットフォームは Web、対象クラウドは Worldwide Standard Multi-Tenant、プレビューは 2025年11月、一般提供は 2025年12月、状態は Launched とされています。更新時刻は UTC 2026年5月14日 23:15:59 で、日本時間では 2026年5月15日にあたります。(Microsoft)
この変更は、単なる数値上限の拡大ではありません。退職予定者のデータ持ち出し、個人メールへの送信、特定 SharePoint サイトからの共有、機密ファイル種別のコピーなどを、より業務実態に近い条件で分けて検知できるようになります。一方で、設定を増やしすぎるとアラートの解釈や運用ルールが複雑になります。この記事では、Microsoft Purview Compliance Portal の更新内容を、管理者・セキュリティ担当者・運用自動化を担当する開発者が確認すべき観点で整理します。
Microsoft Purviewのセキュリティ更新で何が変わるのか
今回の更新対象は、Microsoft Purview Insider Risk Management における variant limits と detection groups です。Insider Risk Management は、組織内の潜在的なリスク行動を検知・調査・対応するための Microsoft Purview の機能で、データ漏えい、知的財産の持ち出し、セキュリティ違反などのリスクをポリシーで管理できます。Microsoft Learn では、ユーザーは既定で仮名化され、ロールベースのアクセス制御や監査ログによってプライバシー保護を支援すると説明されています。(Microsoft Learn)
今回の変更点を整理すると、次のとおりです。
| 項目 | 変更前 | 変更後 | 実務上の意味 |
|---|---|---|---|
| 1つの built-in indicator に作成できる variant 数 | 3 | 10 | 同じ indicator を、宛先ドメイン、ファイル種別、サイト、キーワードなどの条件別に細かく分けやすくなる |
| 全 indicator を通じた variant 数 | 明示なし、または環境上の制約に依存 | 100 | テナント全体で variant が増えすぎないよう、設計上の上限を意識する必要がある |
| 1つの detection group に登録できる項目数 | 200 | 500 | 大量のドメイン、ファイルパス、キーワード、SharePoint サイトなどを分割せずに管理しやすくなる |
Microsoft 365 Roadmap は商用機能の予定日と説明を掲載する場であり、掲載情報は変更される可能性があると明記されています。したがって、実際の展開確認では、Microsoft Purview ポータル上の設定画面、Microsoft 365 管理センターのメッセージセンター、テナントでの表示状態をあわせて確認するのが安全です。(Microsoft)
variantとdetection groupの役割を整理する
今回の更新を正しく理解するには、まず variant と detection group の役割を分けて考える必要があります。
variantはbuilt-in indicatorを業務条件に合わせて細分化する設定
variant は、Microsoft Purview Insider Risk Management の built-in indicator をもとに、検知条件をより細かく調整するための仕組みです。
たとえば、built-in indicator に「組織外の受信者へ添付ファイル付きメールを送信する」検知がある場合、variant を使うことで次のように分けられます。
| variantの例 | 検知したい行動 | 運用上の狙い |
|---|---|---|
| 個人メール宛て送信 | gmail.com や yahoo.com などの個人メール宛てに添付ファイルを送る | 情報持ち出しの可能性を優先的に確認する |
| 競合ドメイン宛て送信 | 競合企業や注意先ドメインへの送信 | 法務・営業秘密の観点で重点監視する |
| 許可済み取引先を除外 | 通常業務で利用する取引先ドメインを除く | 誤検知を減らし、調査対象を絞る |
| 特定部門向け条件 | 研究開発、財務、人事など、部門別の重要データに合わせる | 一律ポリシーでは拾いにくいリスクを補う |
Microsoft Learn でも、variant は built-in indicator のプロパティを継承しつつ、異なるユーザーセットや条件に合わせて検知を調整する用途で説明されています。たとえば、個人ドメイン宛てのメールだけを検知することで、メール活動の false positive を減らす例が示されています。(Microsoft Learn)
detection groupは対象ドメインやファイル種別などをまとめる入れ物
detection group は、variant や global exclusion で使う条件グループです。Microsoft Learn では、detection group を使うことで built-in indicator や global exclusion の対象範囲を絞り、組織にとって重要な活動に焦点を当てられると説明されています。対応する detection type には、Domains、File paths、File types、Keywords、Sensitive info types、SharePoint sites、Trainable classifiers があります。(Microsoft Learn)
実務では、detection group を次のように使います。
| detection groupの種類 | 具体例 | 使いどころ |
|---|---|---|
| Domains | 個人メール、競合企業、取引先、外部共有先 | メール送信や外部共有のリスクを分類する |
| File paths | 開発端末上の特定フォルダー、共有ドライブ上の重要領域 | 特定フォルダーからのコピーや移動を重点確認する |
| File types | .zip、.ps1、.sql、.xlsx、CAD形式など | 持ち出されると影響が大きいファイル形式を絞る |
| Keywords | 案件名、製品コード、機密プロジェクト名 | プロジェクト単位の機密情報を検知に反映する |
| Sensitive info types | 個人情報、金融情報、認証情報など | 既存の機密情報分類と連動させる |
| SharePoint sites | 経営会議、研究開発、M&A、人事評価サイト | 重要サイトに関する操作を重点的に監視する |
| Trainable classifiers | 契約書、設計書、顧客情報などの分類器 | 内容ベースで検知対象を絞る |
今回、1 つの detection group に登録できる項目が 500 まで増えることで、これまで 200 件制限のために分割していたドメインリストやキーワードリストを、より自然な単位でまとめやすくなります。Microsoft Learn の detection group 作成手順でも、ドメイン、ファイルパス、ファイルタイプ、キーワード、機密情報の種類、SharePoint サイト、Trainable classifiers の各グループについて、最大 500 項目まで作成できる説明が掲載されています。(Microsoft Learn)
影響を受ける管理者と環境
今回の更新で直接影響を受けるのは、主に Microsoft Purview Insider Risk Management を使っている組織です。特に、以下のような環境では確認優先度が高くなります。
| 対象 | 確認すべき理由 |
|---|---|
| Insider Risk Management ポリシーを複数運用している組織 | variant 増加により、ポリシー複製ではなく条件分岐で整理できる可能性がある |
| detection group を上限近くまで使っている組織 | 200 件制限に合わせた分割グループを統合できる可能性がある |
| 退職者・高リスクユーザー・重要部門向けの個別監視をしている組織 | 条件別 variant を増やすことで、調査の優先順位付けがしやすくなる |
| SOC、内部監査、法務、コンプライアンス部門が共同で運用している組織 | 検知条件が増えると、アラート説明・エスカレーション基準・証跡管理の見直しが必要になる |
| 設定台帳や運用スクリプトで制限値を固定している組織 | 「3件」「200件」を前提にしたチェック、申請フォーム、棚卸し表を更新する必要がある |
注意したいのは、上限が増えたからといって、すべての環境で variant や detection group を増やすべきではないことです。上限拡大は「より細かく設計できる余地」が増える更新であり、検知精度や運用品質を自動的に高めるものではありません。
管理者が最初に確認すべき設定
Microsoft Purview 管理者は、まず既存構成を棚卸しするところから始めるのが安全です。いきなり新しい variant を追加すると、アラート量が増えたり、既存ポリシーとの違いを説明できなくなったりします。
既存variantの数と目的を確認する
最初に、Insider Risk Management の policy indicators で、どの built-in indicator に variant が作成されているかを確認します。
確認時は、数だけでなく、次の項目を記録してください。
| 確認項目 | 見るべきポイント |
|---|---|
| variant名 | 名前だけで目的が分かるか |
| 対象 built-in indicator | どの検知を細分化しているか |
| detection group | どの条件グループを使っているか |
| inclusion / exclusion の考え方 | 「選択したグループだけ検知」か「選択したグループを除外」か |
| 適用先ポリシー | どのポリシーで実際に使われているか |
| アラート実績 | 誤検知が多いか、重要アラートを拾えているか |
| 所有部門 | セキュリティ、法務、人事、事業部門の誰が条件を承認しているか |
Microsoft Learn では、variant 作成時に detection group を使って「選択したグループに関わる活動を無視する」または「選択したグループに関わる活動のみ検知する」を選べると説明されています。また、1 つの variant では、同じ detection type の detection group を最大 5 件まで追加できます。(Microsoft Learn)
detection groupの分割状態を確認する
次に、detection group が上限対策のためだけに分割されていないか確認します。
たとえば、次のようなグループ名がある場合は、統合候補です。
| 既存グループ名の例 | 見直し観点 |
|---|---|
| PersonalMailDomains-1、PersonalMailDomains-2 | 200 件制限のために分割していた可能性が高い |
| CompetitorDomains-A、CompetitorDomains-B | 重複や期限切れドメインがないか確認する |
| ProjectKeywords-Old、ProjectKeywords-New | 統合よりも、終了プロジェクトの削除が先かもしれない |
| HighRiskFileTypes-General、HighRiskFileTypes-Extra | 業務上の意味で分かれているのか、数の都合で分かれているのか確認する |
ただし、500 件に増えたからといって、すべてを 1 つにまとめるのは危険です。調査担当者が「なぜこのアラートが出たのか」を説明できる単位に保つ必要があります。
おすすめは、次のような基準で分ける方法です。
| 分け方 | 向いているケース |
|---|---|
| リスク種別で分ける | 個人メール、競合、禁止ドメイン、未承認 SaaS など |
| 部門・業務で分ける | 研究開発、人事、財務、営業秘密など |
| データ種類で分ける | ソースコード、契約書、顧客情報、設計図面など |
| 管理責任者で分ける | 法務管理、IT管理、事業部門管理など |
| 更新頻度で分ける | 毎月更新するドメインリストと、年1回見直す固定リストを分ける |
すべてのindicatorがvariant対応ではない点を確認する
variant の上限が 10 件に増えても、すべての built-in indicator で variant を作れるわけではありません。Microsoft Learn では、一部の built-in indicator、たとえば Microsoft Defender for Endpoint indicators などは variant をサポートしないと説明されています。また、applicable ではない detection group は variant の選択肢に表示されません。(Microsoft Learn)
そのため、展開計画を作るときは「作りたい variant」ではなく「対象 indicator が対応している variant」から逆算してください。
移行や展開でおすすめの進め方
今回の更新は、既存ポリシーを強制的に移行する変更ではなく、上限拡大によって設計の自由度が増える更新です。既存の variant や detection group が動作している場合、まずは現状維持で問題ありません。
ただし、これまで制限値に合わせて複雑な回避策を使っていた環境では、段階的に見直す価値があります。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 現状把握 | variant、detection group、適用ポリシー、アラート実績を棚卸しする | 設定台帳、現行構成図 |
| 統合候補の抽出 | 200 件制限対策で分割した detection group を洗い出す | 統合候補リスト |
| 設計方針の決定 | リスク種別、部門、データ種類、所有者のどれで分けるか決める | 命名規則、管理ルール |
| テスト用variant作成 | 既存 indicator に対して限定的に variant を追加する | テスト variant |
| ポリシー適用 | 新規または既存ポリシーで variant を選択する | 適用済みポリシー |
| アラート比較 | Activity explorer や User activity で検知結果を確認する | 誤検知・未検知の分析 |
| 本番展開 | 段階的に対象部門や条件を広げる | 展開記録、承認履歴 |
| 運用更新 | 手順書、申請フォーム、監査説明資料を更新する | 最新の運用ドキュメント |
Microsoft Learn では、variant をポリシーに追加した場合、ダッシュボードでアラートが生成され、Activity explorer や User activity タブで詳細を確認できると説明されています。また、built-in indicator とその variant を同じポリシーに適用し、それぞれがどの活動を検知するか確認してから variant に移行する方法も推奨されています。(Microsoft Learn)
展開時に注意すべき失敗パターン
上限いっぱいまで作ることを目的にしてしまう
variant が 10 件まで作れるようになったからといって、1 つの indicator に 10 件作る必要はありません。variant が増えるほど、アラートの理由説明、しきい値調整、監査対応、例外申請の管理が難しくなります。
判断基準はシンプルです。
「その variant によって、調査担当者の判断が速くなるか」
この問いに答えられない variant は、追加しないほうがよい場合があります。
detection groupを大きくしすぎる
1 グループ 500 項目まで登録できるようになると、ドメインやキーワードをまとめやすくなります。しかし、範囲が広すぎる detection group は、アラートの原因を見えにくくします。
たとえば「注意ドメイン」という 1 つのグループに、個人メール、競合企業、許可されていない SaaS、海外子会社、過去案件の取引先をまとめると、検知の意味が曖昧になります。
より実務的には、次のように分けるべきです。
| 避けたい設計 | 改善案 |
|---|---|
| 注意ドメイン全部 | Personal email、Competitor、Unapproved SaaS、Legacy partner などに分ける |
| 機密キーワード全部 | 製品コード、M&A、採用、人事評価、顧客名などに分ける |
| 重要サイト全部 | R&D、Finance、Legal、Executive など責任部門別に分ける |
global exclusionとpolicy-level variantを混同する
global exclusion はテナント内の複数ポリシーに横断的に影響する設定です。一方、variant は特定の built-in indicator や policy の検知条件を調整するために使います。Microsoft Learn でも、global exclusion はテナント内で作成するすべてのポリシーの trigger と indicator に適用され、detection group は built-in global exclusion を組織のニーズに合わせて調整する用途でも使えると説明されています。(Microsoft Learn)
誤検知を減らしたいからといって、すぐに global exclusion に入れるのは危険です。全ポリシーで検知されなくなる可能性があるためです。まずは policy-level の variant で影響範囲を限定し、調査結果を見てから global exclusion を検討するのが安全です。
しきい値やアラート量を見直さない
variant を増やすと、検知条件が細かくなる一方で、アラートの件数や重要度の分布が変わる可能性があります。Microsoft Learn では、Insider Risk Management の Intelligent detections 設定で、ファイルダウンロード活動のスコアブースト、アラート量、Defender for Endpoint アラートの取り込み、許可されていないドメインやサードパーティドメインの指定などを調整できると説明されています。(Microsoft Learn)
特に、既存ポリシーに新しい variant を追加する場合は、以下を確認してください。
| 確認項目 | 見るべきこと |
|---|---|
| 低・中・高アラートの比率 | 低アラートが急増していないか |
| false positive | 通常業務の活動が過剰に検知されていないか |
| true positive | 重要な活動を拾えているか |
| 調査時間 | 1件あたりの確認時間が増えていないか |
| エスカレーション率 | 法務・人事・SOCへの連携件数が妥当か |
| ケース化率 | アラートから実際のケースに進む割合が低すぎないか |
開発者・運用自動化担当者が確認すべきポイント
Microsoft Purview の設定そのものは管理者が行うことが多いですが、開発者や運用自動化担当者も無関係ではありません。特に、設定台帳、申請ワークフロー、CSV 管理、監査レポート、SIEM 連携、ダッシュボードなどを作っている場合は、今回の上限変更が影響します。
固定値を前提にしたチェックを見直す
社内ツールや Excel 台帳、PowerShell スクリプト、ワークフローで、次のような固定値を使っていないか確認してください。
| 旧前提 | 見直し内容 |
|---|---|
| variant は最大 3 件 | 1 indicator あたり 10 件、全体 100 件を前提に更新する |
| detection group は最大 200 項目 | 500 項目まで扱えるように入力検証や警告文を更新する |
| detection group は少数前提 | グループ数・項目数が増えても一覧性を保てる画面や台帳にする |
| アラート件数は現状程度 | variant 追加後の件数増加をダッシュボードで追跡する |
ただし、Microsoft 公式が公開していない API や内部仕様を前提にした自動化は避けるべきです。管理画面、公式ドキュメント、Microsoft 365 管理センターのメッセージを基準に運用してください。
命名規則と変更履歴を必ず整備する
variant と detection group は、数が増えるほど名前の品質が重要になります。
おすすめの命名規則は、次のように「用途」「対象」「条件」が分かる形式です。
| 種類 | 命名例 |
|---|---|
| ドメイン検知 | DOM-PersonalMail-JP-HighRisk |
| 競合ドメイン | DOM-Competitor-Global-LegalManaged |
| ファイルタイプ | FT-SourceCode-RnD |
| SharePoint サイト | SPO-MA-ConfidentialSites |
| キーワード | KW-ProjectPhoenix-FY2026 |
変更履歴には、最低限次の情報を残します。
| 記録項目 | 理由 |
|---|---|
| 変更日 | いつ検知条件が変わったか説明するため |
| 変更者 | 監査や問い合わせ対応のため |
| 承認者 | 法務・人事・事業部門の合意を示すため |
| 追加・削除した項目 | アラート変化の原因を追えるようにするため |
| 対象ポリシー | どの検知に影響したか確認するため |
| 期待する効果 | 誤検知削減、検知強化、統合など目的を明確にするため |
新しい上限を活用する実務シナリオ
個人メールへの持ち出し検知を細分化する
従来は、個人メール宛て送信を 1 つの条件で見るしかなかった環境でも、variant 上限の拡大により、より細かい分類がしやすくなります。
たとえば、次のように分けられます。
| variant | detection group | 期待する効果 |
|---|---|---|
| 個人メール宛て添付送信 | Free public domains、独自管理の個人メールドメイン | 典型的な持ち出しリスクを把握する |
| 退職予定者の個人メール送信 | 個人メールドメイン + 退職者ポリシー | 退職前後の高リスク行動を重点確認する |
| 高機密ファイルの外部送信 | 高リスク file types、sensitive info types | 内容面の重要度を加味する |
| 許可取引先除外 | 承認済み取引先ドメインを除外 | 通常業務の誤検知を減らす |
Microsoft Learn では、Domains detection group に Free public domains という特別なグループがあり、個人メールドメインへの業務データ持ち出しを把握する用途で説明されています。(Microsoft Learn)
重要SharePointサイトの監視を部門別に分ける
SharePoint サイトを 1 グループにまとめるのではなく、部門やリスク種別で分けることで、調査時の初動が速くなります。
| グループ | 対象 | 調査担当 |
|---|---|---|
| R&D confidential sites | 研究開発、設計、特許関連サイト | セキュリティ + 研究開発部門 |
| Finance restricted sites | 決算、予算、M&A 関連サイト | セキュリティ + 財務 |
| HR sensitive sites | 人事評価、給与、採用関連サイト | セキュリティ + 人事 |
| Executive sites | 役員会議、経営戦略サイト | セキュリティ + 経営企画 |
このように分けておくと、アラート発生時に「誰が判断すべきか」が明確になります。検知精度だけでなく、対応速度も改善しやすくなります。
大量キーワードをプロジェクト単位で管理する
detection group の 500 項目化は、キーワード管理にも効果があります。製品コード、開発コードネーム、顧客名、案件名、契約名など、機密性の高い語句を扱う組織では、200 件では不足しやすいためです。
ただし、キーワードを大量に登録すると、文脈に関係なく一致してしまう可能性があります。短すぎる略語、一般名詞、部門名だけのキーワードは、誤検知の原因になります。
おすすめは、次の基準で登録することです。
| 登録に向いているキーワード | 避けたいキーワード |
|---|---|
| 固有のプロジェクトコード | 一般的な部署名 |
| 外部非公開の製品コード | 2〜3文字の略語 |
| 契約書や仕様書に固有の案件名 | よく使う一般名詞 |
| 社外秘資料で一貫して使われる表現 | 表記ゆれが多すぎる語句 |
既存環境での確認チェックリスト
展開前に、次のチェックリストを使って確認してください。
| チェック項目 | 完了の目安 |
|---|---|
| Roadmap ID 511798 の対象機能を確認した | Microsoft Purview、Insider Risk Management、variant、detection group の更新だと把握している |
| 既存 variant を棚卸しした | どの indicator に何件あるか分かる |
| detection group の項目数を確認した | 200 件近くで分割していたグループを把握している |
| global exclusion と variant の使い分けを整理した | テナント全体に影響する除外を安易に追加しない方針がある |
| 変更承認フローを決めた | セキュリティ、法務、人事、事業部門の承認者が明確 |
| アラート比較期間を決めた | variant 追加前後で誤検知・検知漏れを比較できる |
| 台帳・手順書・申請フォームを更新した | 3件・200件の古い前提が残っていない |
| 調査担当者へ周知した | 新しい variant 名や検知条件を説明できる |
今回の更新でやるべきこと
今回の Microsoft Purview Compliance Portal の更新は、Insider Risk Management をより現実の業務リスクに合わせて調整しやすくするものです。variant が 1 indicator あたり 10 件、全体で 100 件まで拡大され、detection group も 1 グループ 500 項目まで扱えるようになることで、これまで分割や妥協が必要だった検知条件を整理しやすくなります。
一方で、上限拡大は「たくさん設定するための更新」ではありません。重要なのは、調査担当者がアラートの意味を説明でき、法務・人事・事業部門と合意した基準で対応できることです。
まずは、既存の variant と detection group を棚卸ししてください。そのうえで、200 件制限のためだけに分割していたグループを統合できるか、3 件制限で諦めていたリスク別 variant を追加すべきかを判断します。最初の展開対象は、個人メール宛て送信、重要 SharePoint サイト、機密ファイル種別など、効果を測定しやすいシナリオに絞るのがおすすめです。
コメント