Microsoft Purview Data MapのData classificationは、データ資産に「個人名」「クレジットカード番号」「社員ID」などの論理的な分類タグを付け、検索・把握・ガバナンス・リスク判断に使う仕組みです。最初に押さえるべき結論は、分類はアクセス制御や暗号化そのものではなく、保護・監査・DLP・感度ラベル運用を正しく設計するための土台だという点です。Microsoft公式ドキュメントでも、分類によりデータ資産を理解・検索・管理しやすくし、重要データや機密データのリスク把握に役立つと説明されています。(Microsoft Learn)
今回確認すべきポイントは、Microsoft Purview Data Mapで分類を自動適用する範囲、手動で補うべき範囲、カスタム分類を作る判断基準、再スキャン時に既存タグがどう扱われるかです。特に管理者は「スキャンルールセットに何を含めるか」、開発者やデータエンジニアは「列名・データ形式・正規表現の設計が誤検出や未検出に直結すること」を理解しておく必要があります。
Microsoft Purview Data MapのData classificationとは
Microsoft Purview Data MapにおけるData classificationは、データ資産を業務上の意味に基づいて分類する機能です。たとえば、Passport Number、Driver’s License Number、Credit Card Number、SWIFT Code、Person’s Nameのように、データの種類を識別するタグを資産に付与します。Data Mapには200以上の組み込みシステム分類があり、必要に応じて自社固有のカスタム分類も作成できます。分類はスキャン時に自動適用できるほか、スキャン後にMicrosoft Purviewガバナンスポータル上で手動編集することもできます。(Microsoft Learn)
重要なのは、Data classificationを「機密度ラベル」と混同しないことです。分類は「データの中身の種類」を示すタグであり、感度ラベルは「業務影響や保護レベル」を示すラベルです。Microsoft Purview Data Mapで感度ラベルを使うには、同じMicrosoft Entraテナント内に少なくとも1つのMicrosoft 365ライセンスまたはアカウントが必要です。(Microsoft Learn)
Microsoft Purviewのセキュリティ更新として見るべき変更点
Data classification自体は、単独でファイルを暗号化したり、ユーザーのアクセスを遮断したりする機能ではありません。ただし、データ保護の出発点としては非常に重要です。どこに個人情報・金融情報・識別子・社内独自IDがあるかを把握できなければ、DLP、アクセス制御、保持ポリシー、監査、感度ラベルの設計も曖昧になります。
今回の公式情報から、管理者が実務上の変更点として整理すべきポイントは次のとおりです。
| 確認ポイント | 実務上の意味 | 管理者が取るべき対応 |
|---|---|---|
| 分類はデータ資産の意味を表すタグ | 「機密」「社外秘」ではなく、「何のデータか」を識別する | 既存のセキュリティ分類表とData Mapの分類名を対応付ける |
| システム分類とカスタム分類を使い分ける | Microsoft標準で足りない社内IDや業務コードは自作が必要 | まずシステム分類を棚卸しし、不足分だけカスタム分類を作る |
| 自動分類はスキャンルールセットに依存する | スキャン対象に含めた分類だけが比較・適用される | データソース別に不要な分類を外し、スキャン負荷とノイズを減らす |
| テーブル資産には自動で分類が付かない場合がある | 列には自動分類されても、テーブル単位では手動補完が必要 | 重要テーブルは手動分類の運用ルールを決める |
| 再スキャンで既存タグの扱いが変わる | 手動適用・手動削除・ファイルサイズにより保持/削除が変わる | 本番再スキャン前に既存分類の差分を確認する |
Microsoft公式ドキュメントでは、スキャン時にData Mapがシステム分類またはカスタム分類ルールを使ってデータを分類できること、また分類がファイル資産や列資産に自動適用されることが説明されています。一方で、テーブル資産には自動で分類が割り当てられず、必要に応じて手動適用する必要があります。(Microsoft Learn)
影響範囲は「管理者」「セキュリティ担当」「開発者」で異なる
Data classificationの影響は、Microsoft Purviewの管理者だけに閉じません。分類結果は検索、カタログ、データ利用判断、保護方針の検討に関わるため、データを作る人・管理する人・守る人の全員に影響します。
Microsoft Purview管理者への影響
管理者が最も注意すべきなのは、スキャンルールセットの設計です。Data Mapは、スキャン時に対象データをスキャンルールセット内の分類と照合します。対象分類を増やしすぎるとスキャンが重くなり、関係のない分類が大量に付くとカタログ利用者にとってノイズになります。Microsoft公式情報でも、特定の種類や地域のデータに限定される場合は、不要な分類を外したカスタムルールセットを使うことでスキャンを高速化できるとされています。(Microsoft Learn)
たとえば、日本国内の顧客管理データだけを扱うデータソースに、海外の納税者番号や州コードの分類を大量に含める必要はありません。逆に、グローバル顧客データを扱う場合は、地域ごとの識別番号や住所関連の分類を落としすぎると検出漏れにつながります。
セキュリティ・コンプライアンス担当への影響
セキュリティ担当者は、Data classificationを「保護済み」の証拠として扱わないように注意が必要です。分類は、あくまでデータの種類を示すメタデータです。MicrosoftのFAQでは、分類と感度ラベルの違いとして、分類はMicrosoft Purview Data Map内で適用されるデータ型識別であり、感度ラベルはデータが移動しても付随するラベルであると説明されています。(Microsoft Learn)
したがって、「Credit Card Numberに分類されたから安全」ではありません。むしろ、Credit Card Numberが検出された資産に対して、誰がアクセスできるのか、外部共有されていないか、DLPポリシーや感度ラベルの対象にすべきかを判断するための入口になります。
開発者・データエンジニアへの影響
開発者やデータエンジニアにとって重要なのは、データの設計が分類精度に影響することです。たとえば、社員IDをEMPLOYEE＋GUIDのような一貫した形式で保存していれば、正規表現によるカスタム分類ルールを作りやすくなります。列名もEmployee_IDやEmployeeIDのように命名規則が揃っていれば、列パターンを組み合わせて誤検出を減らせます。Microsoft公式ドキュメントでも、カスタム分類ルールではデータパターンと列名パターンを使い、スキャンシステムが実データと列名を調べて分類を判断する例が示されています。(Microsoft Learn)
管理者が確認すべき設定
Microsoft Purview Data MapのData classificationを安全に運用するには、分類を作る前に「何を検出したいのか」「検出結果を何に使うのか」を決める必要があります。設定だけ先に進めると、後から分類名の統一、誤検出、スキャン負荷、権限不足でつまずきます。
| 確認項目 | 確認する場所 | 実務上のチェックポイント |
|---|---|---|
| システム分類の利用可否 | Data Map > Annotation management > Classifications | MICROSOFTプレフィックスの標準分類で要件を満たせるか確認する |
| カスタム分類の必要性 | Annotation management > Classifications | 社員ID、会員番号、独自契約番号など標準分類にないデータだけ作成する |
| 分類ルール | Annotation management > Classification rules | 正規表現、辞書、列名パターン、しきい値を確認する |
| スキャンルールセット | スキャン作成時のScan rule set | データソースに関係する分類だけを含める |
| 権限 | コレクション、ドメイン、データソース | スキャン実行者や分類作成者に必要なロールがあるか確認する |
| 再スキャンの影響 | スキャン履歴、分類詳細 | 手動分類、手動削除、既存タグの保持/削除を事前に確認する |
カスタム分類を作成するには、ドメインまたはコレクションに対するData CuratorまたはData Source Administratorの権限が必要です。スキャン実行時も、対象ソースが登録されているコレクションで少なくともData Source Administrator権限が必要です。(Microsoft Learn)
カスタム分類を作るべきケースと作らない方がよいケース
カスタム分類は便利ですが、増やしすぎると運用が複雑になります。Microsoftのベストプラクティスでも、利用可能なシステム分類で要件を満たせない場合にのみカスタム分類を作ることが推奨されています。(Microsoft Learn)
カスタム分類を作るべきケース
次のようなデータは、カスタム分類の候補になります。
- 社員ID、会員ID、顧客番号など、自社固有の識別子
- 製品コード、契約番号、店舗コードなど、業務上重要なコード体系
- 標準分類では検出できないが、監査・検索・棚卸しで重要なデータ
- データ形式や列名に一貫性があり、正規表現で表現しやすいデータ
たとえば、社員IDがEMP-2026-000123のように固定形式で保存されているなら、正規表現で検出できます。さらに列名がemployee_id、emp_id、staff_idなどに統一されていれば、列名パターンを併用して誤検出を抑えられます。
カスタム分類を作らない方がよいケース
一方で、次のような場合はカスタム分類を急いで作るべきではありません。
- 検出したいデータの定義が部門ごとに違う
- 値の形式が一定していない
- 辞書に登録すべき値が頻繁に増減する
- 検出結果を何に使うか決まっていない
- 既存のシステム分類で十分に代替できる
特に「とりあえず全部分類する」という発想は危険です。分類ラベルが多すぎると、カタログ検索の精度が落ち、利用者がどのデータを信頼すべきか判断しにくくなります。分類は多ければよいのではなく、意思決定に使える粒度で設計することが重要です。
正規表現・辞書・しきい値の設計ポイント
カスタム分類ルールでは、正規表現または辞書を使えます。Microsoft公式ドキュメントでは、データ要素を一貫した正規表現で表せる場合はRegular expression、分類対象の値を網羅したリストがある場合はDictionaryを使う考え方が示されています。辞書方式は.csvと.tsvに対応し、ファイルサイズ上限は30MBです。(Microsoft Learn)
| 方式 | 向いているデータ | 注意点 |
|---|---|---|
| 正規表現 | 社員ID、契約番号、製品コードなど形式が決まっている値 | パターンが広すぎると誤検出し、狭すぎると検出漏れが起きる |
| 辞書 | 支店コード、部門名、固定された識別語など候補値が明確なデータ | 候補値が不完全だと検出漏れが起きる。将来の値追加も考慮する |
| 列名パターン併用 | 同じ形式の値が複数列に存在するデータ | データパターンとのAND条件になるため、列名揺れに注意する |
Minimum match thresholdも重要です。これは、列内のデータ値のうち、どの程度がパターンに一致したら分類を適用するかを示すしきい値です。システム分類では60%で変更できません。カスタム分類では設定可能ですが、Microsoftは誤検出を避けるため少なくとも60%を推奨しています。ただし、1件でも一致したら検出したい高リスクデータでは、要件に応じて低い値を使う余地があります。(Microsoft Learn)
カスタム分類の制約を見落とさない
カスタム分類には、展開前に確認すべき制約があります。特に重要なのは、カスタム分類がすべてのファイル形式に適用されるわけではない点です。
Microsoft公式ドキュメントでは、カスタム分類はSQLやCosmos DBなどの構造化データソース、およびCSV、JSON、Parquetなどの構造化ファイルタイプにのみ適用され、DOC、PDF、XLSXなどの非構造化ファイルタイプには適用されないと説明されています。また、カスタム分類ルールは英語のみサポートされています。(Microsoft Learn)
この制約を知らないまま展開すると、「PDFに社員番号が含まれているのにカスタム分類されない」「日本語の辞書ルールを作ったのに期待通りに動かない」といった誤解につながります。非構造化ファイルを対象にしたい場合は、システム分類で検出できる範囲、感度ラベル、DLP、別の検査プロセスとの組み合わせを検討してください。
再スキャン時の挙動は移行前に必ず確認する
Microsoft Purview Data Mapでは、分類タグは初回スキャン時にサンプリングとパターン照合によって自動適用されます。その後の再スキャンでは、手動適用された分類は削除されず、手動削除された分類は再適用されません。また、同じスキャンルールを使い続ける後続スキャンでは分類タグが更新される場合があります。(Microsoft Learn)
特に注意すべきなのは、ファイル種類とサイズによって、前回スキャンの分類タグが保持されるか削除されるかが変わる点です。
| 対象 | サイズ条件 | 前回スキャンの分類タグ |
|---|---|---|
| SQLなどサイズのないファイルタイプ | すべて | 保持 |
| Word、Excel、PowerPoint、PDF、TXTなど | 20MB超 | 保持 |
| Word、Excel、PowerPoint、PDF、TXTなど | 20MB未満 | 削除 |
| GZ | 400KB超 | 保持 |
| GZ | 400KB未満 | 削除 |
| 拡張子なし、または構造化ファイルタイプ | 1MB超 | 保持 |
| 拡張子なし、または構造化ファイルタイプ | 1MB未満 | 削除 |
この挙動は、移行や大規模な再スキャンで影響が出やすいポイントです。たとえば、旧ルールで分類済みだった小さなPDFやExcelファイルを再スキャンした結果、分類タグが消えたように見える場合があります。実際にはファイルサイズ条件や再スキャン仕様による可能性があるため、分類数の増減だけで「データが消えた」「スキャンが失敗した」と判断しないようにしてください。
展開前に実施したいチェックリスト
本番展開では、いきなり全データソースをスキャンしないことが大切です。代表的なデータソースで小さく検証し、分類精度、スキャン時間、分類ノイズ、再スキャン差分を確認してから対象を広げます。
| フェーズ | 実施内容 | 判断基準 |
|---|---|---|
| 事前設計 | 検出したいデータ種類を一覧化する | 検出結果を検索、監査、DLP、ラベル設計のどれに使うか説明できる |
| 標準分類確認 | MICROSOFTプレフィックスのシステム分類を確認する | 標準分類で足りるものと足りないものを分けられる |
| カスタム分類設計 | 名前空間、正規表現、辞書、列名パターンを設計する | 誤検出を減らす条件が入っている |
| テスト | サンプルデータで分類ルールを検証する | 期待する列だけに分類が付く |
| パイロットスキャン | 一部ソースでスキャンルールセットを実行する | 分類数、スキャン時間、誤検出、未検出を確認できる |
| 本番展開 | ソース別にスケジュールを分けて展開する | 業務時間帯、コスト、容量、運用担当者を考慮している |
| 運用監視 | 分類詳細とスキャン履歴を確認する | Applied by、Applied time、Classification typeを追跡できる |
カスタム分類名は、会社名や部門名を含む名前空間を使うと管理しやすくなります。Microsoft公式ドキュメントでも、<company name>.<business unit>.<custom classification name>のような命名規則が推奨されています。たとえば、架空企業ContosoのHR部門の社員IDならCONTOSO.HR.EMPLOYEE_IDのように設計します。(Microsoft Learn)
失敗しやすいポイント
Data classificationの導入でよくある失敗は、機能不足ではなく設計不足から起きます。以下のポイントは、特に本番展開前に確認してください。
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| 分類タグが多すぎて検索しにくい | 関係のないシステム分類を大量に含めている | データソース別・地域別にスキャンルールセットを分ける |
| テーブルに分類が付かないと誤解する | 自動分類は主に列やファイルに適用される | 重要テーブルは手動分類の運用を決める |
| カスタム分類がPDFに適用されない | カスタム分類の対象が構造化データ中心であることを見落としている | 対象ファイル形式を事前に確認する |
| 社員IDが誤検出される | 正規表現が広すぎる、列名条件がない | データパターンと列名パターンを併用する |
| 再スキャン後にタグが減って混乱する | 再スキャン時の保持/削除条件を確認していない | 本番前に分類差分のベースラインを取る |
| 分類を保護機能と誤認する | 分類と感度ラベル、DLP、暗号化の役割を混同している | 分類結果を保護ポリシー設計の入力情報として扱う |
Microsoft Purview Data Mapは、Data Map自体がメタデータ、分類、リネージなどを扱う基盤であり、容量単位や操作スループット、メタデータストレージが利用量や課金に関係します。大規模展開では、スキャンと取り込みがコストや容量に影響する可能性も考慮しておくべきです。(Microsoft Learn)
管理者と開発者が次にやるべきこと
まず、現在のデータソースを「顧客データ」「従業員データ」「財務データ」「ログ・運用データ」のように分け、各データソースで検出すべき分類を決めます。次に、システム分類で足りるものと、カスタム分類が必要なものを分けます。この時点で、検出結果を誰が見るのか、何の判断に使うのかも明確にしてください。
開発者やデータエンジニアは、列名とデータ形式の標準化を進めると分類精度を上げやすくなります。たとえば、社員IDをアプリごとにemployeeNumber、emp_no、staffCodeとばらばらに持つより、データ契約や命名規則を決めた方が、Microsoft Purview側のカスタム分類ルールをシンプルにできます。
管理者は、次の順序で進めると失敗しにくくなります。
- 重要データの種類を洗い出す
- Microsoft Purview Data Mapのシステム分類を確認する
- 不足分だけカスタム分類を設計する
- サンプルデータで正規表現・辞書・列名パターンをテストする
- 小規模なデータソースでパイロットスキャンを実行する
- 分類結果、誤検出、未検出、再スキャン差分を確認する
- 本番スキャンのスケジュール、権限、監視方法を決める
Data classification in Microsoft Purview Data Mapは、導入しただけでデータ保護が完了する機能ではありません。しかし、データ資産の中身を把握し、どこに重要情報があるかを見える化するうえで欠かせない基盤です。次に取るべき行動は、全社一斉展開ではなく、重要なデータソースを1つ選び、スキャンルールセットとカスタム分類の小さな検証から始めることです。分類の精度と運用ルールを固めてから対象を広げれば、Microsoft Purviewを検索しやすく、監査しやすく、保護方針につなげやすいデータガバナンス基盤として活用できます。
コメント