Microsoft Purview で Azure SQL に自動的に感度ラベルを付けたいのに、スキャンも分類も成功しているのにラベルだけ付かない……。そんな状況は、実は「設定ミス」ではなく、製品仕様による制限が原因であることが多くあります。本記事では、このよくハマる落とし穴を、Azure SQL／Purview Data Map／自動ラベル付けポリシーの仕組みから整理し、現場で使える対処法と検証手順までまとめて解説します。
Microsoft Purview と Azure SQL 自動ラベル付けの全体像
まずは、今回のトラブルの元になっている構成を整理します。Microsoft Purview は大きく分けて、
- ガバナンス側（Data Map / Unified Catalog）：データ資産の登録・スキャン・分類
- 情報保護側（Microsoft Purview Information Protection / 旧 MIP）：感度ラベル・機密情報の種類（SIT）・自動ラベル付けポリシー
という二つのレイヤーで動いており、その橋渡しとして自動ラベル付けポリシーが存在します。Azure SQL の場合は、
- Azure SQL データベースを Purview Data Map に登録し、スキャンを実行
- スキャンにより、テーブル／列に分類（classification）やSIT 検出結果が付く
- Information Protection 側で定義した自動ラベル付けポリシーが、検出結果を条件に感度ラベルを自動適用
- ラベルは Data Map 上のメタデータとして保持され、Azure SQL の資産に紐付く
つまり、「スキャン・分類」と「ラベル付け」は別コンポーネントであり、両者が使っている“条件”の種類が違うことが、今回の問題の本質です。
今回のシナリオのおさらい
質問の前提条件を整理しつつ、どこまでが正しく出来ていて、どこにギャップがあるのかを確認します。
やりたいこと
- Microsoft Purview の自動ラベル付けポリシーを使って、特定の Azure SQL データベース／テーブルに対し、
- Purview ガバナンス側で作成したカスタム分類ルールのヒット結果をもとに、
- 目的の感度ラベルを自動適用したい。
すでに実施済みの設定
- 感度ラベルのスコープを「ファイルとその他のデータ資産 (Files & other data assets)」に設定して公開済み
- Azure SQL を対象にした自動ラベル付けポリシーを作成済み
- ラベルに紐づく保護ポリシー（アクセス制御）も作成済み
- Purview ガバナンス側でカスタム分類ルールを作成し、スキャン規則セットに含めて Azure SQL のスキャンを実施
- スキャンは成功しており、データ マップ上で Azure SQL の資産が可視化・分類済み
- ライセンスは Microsoft 365 E5（自動ラベル付け要件を満たす）
発生している事象
- 自動ラベル付けポリシーの条件追加画面で選べるのは、
「コンテンツに含まれる」→「機密情報の種類（Sensitive info types）」のみ - Purview ガバナンス側で定義したカスタム分類ルールは候補に出てこない
- その結果、Azure SQL 資産に感度ラベルが自動適用されない
つまり、スキャンと分類は正しく動いているのに、ラベルをトリガーする条件として分類ルールが使えない、という詰まり方です。
用語整理：分類・SIT・感度ラベル・自動ラベル・保護ポリシー
この問題は、似た言葉が多く登場するため混乱しやすいです。Purview における役割を一度表で整理しておきます。
| 要素 | Purview 内の位置づけ | 主な役割 | 自動ラベルの条件に使えるか |
|---|---|---|---|
| 分類 (Classification) | Purview Data Map（ガバナンス） | データ資産の中身を表すタグ（例：銀行口座番号、マイナンバー） | いいえ：ポリシー条件として直接は指定できない |
| カスタム分類ルール | Data Map の分類ルール（正規表現 / キーワード / ML） | 独自パターンを元に分類を自動付与 | いいえ：自動ラベルの条件としてはサポートされない |
| 機密情報の種類（SIT） | Information Protection（MIP）側の検出器 | クレジットカード番号など、機密情報パターンを検出 | はい：自動ラベルの唯一の条件 |
| 感度ラベル | Information Protection + Data Map | 「極秘」「社外秘」など機密度を表すラベル。暗号化やアクセス制御設定も持つ | いいえ：条件ではなく、条件の結果として適用される |
| 自動ラベル付けポリシー | Information Protection のポリシー | SIT の検出などの条件に応じて、対象資産へ感度ラベルを自動適用 | – |
| 保護ポリシー | ラベルに紐づくアクセス制御 | ラベルが付与された後の暗号化・閲覧権限・エクスポート制御など | いいえ：ラベル適用のトリガーではない |
ポイントは、自動ラベル付けポリシーが条件として理解できるのは「機密情報の種類（SIT）」だけであり、Data Map 側で作ったカスタム分類ルールは条件として参照できないことです。ここが今回の「仕様による壁」になります。
なぜカスタム分類ルールでは Azure SQL に自動ラベルが付かないのか
自動ラベル付けポリシー UI が示す通り、条件は SIT のみ
Azure SQL を対象にした自動ラベル付けポリシーを作成し、ルールの条件追加画面に進むと、選べるのは次のような構成だけです。
- 条件の種類：コンテンツに含まれる（Content contains）
- 条件の詳細：機密情報の種類（Sensitive info types） の選択
ここには、Purview ガバナンス側で作成したカスタム分類ルールは一切表示されません。この挙動は個別環境の不具合ではなく、Microsoft Q&A でも公式に「製品仕様による制限」と説明されています。
Q&A では、次のような趣旨の回答がされています：
- Purview の自動ラベル付けポリシーが条件として使用できるのは、機密情報の種類（SIT）のみ
- SIT には、組み込みの SIT と、Microsoft 365 側で定義・公開したカスタム SIT の両方が含まれる
- 一方で、Purview ガバナンス側で作成したカスタム分類ルール（正規表現 / キーワード / ML クラスifier）は、ポリシー条件として選択できない
つまり、いくら Data Map のスキャンでカスタム分類がヒットしても、その結果だけでは自動ラベル付けポリシーが「条件を満たした」と認識してくれないため、ラベルは発火しません。
Data Map プレビュー仕様の追加制約（組み込み SIT のみに依存）
さらにややこしいのが、Data Map 側の仕様です。公式ドキュメントでは、Purview Data Map における自動ラベル付けについて、以下のように説明されています。
- Data Map のスキャンはシステム定義およびユーザー定義の分類を検出し、資産に分類を付与する
- Azure Storage や Azure SQL に対する自動ラベル付けは、スキャンで検出された「Microsoft のアウト・オブ・ボックス分類」を基に実行される
- FAQ では、スキーマ化されたデータ資産（SQL など）に対しては「カスタム SIT は現時点ではサポートされない」と明記されている
このため、Azure SQL の列に対する自動ラベル付けは現時点（プレビュー期）では、
- Information Protection 側の自動ラベル付けポリシー：条件として SIT（特に組み込み SIT）を使用
- Data Map 側のスキャン：組み込みの分類（≒組み込み SIT ベース）を検出し、その結果をもとにラベル付与
という構造に縛られます。「カスタム分類ルールだけで何とかする」「完全に独自パターンのカスタム SIT だけで Azure SQL を自動ラベル」というのは、まだ難しい（もしくはサポート外の挙動に依存する）と考えた方が安全です。
整理すると：今回の“ラベルが付かない”根本原因
ここまでをまとめると、今回 Azure SQL に感度ラベルが付かなかった原因は単純で、
- 自動ラベル付けポリシーがカスタム分類ルールを条件として認識できない
- ポリシー条件には機密情報の種類（SIT）しか使えない
- そのため、分類ルールがどれだけヒットしていても、ポリシーが発火しない
という仕様上の制限によるものです。「スキャンはうまくいっているのにラベルだけ付かない」という現象は、この構造を知らないと非常にハマりやすいポイントです。
対応方針：SIT ベースで自動ラベル付けを設計し直す
では、どうすれば Azure SQL に自動ラベルを付けられるのでしょうか。現時点で取り得る現実的なアプローチは、次の二段階に分けて考えると整理しやすくなります。
- 自動ラベル付けポリシーの条件は SIT に寄せる
- 分類結果は「発見・可視化」のために使う
ステップ 1：ラベルのスコープと公開範囲の見直し
まずは基本の確認です。Azure SQL を自動ラベル対象にするためには、感度ラベル側に次の設定が必要です。
- ラベルのスコープに「ファイルとその他のデータ資産 (Files & other data assets)」が含まれていること
- ラベルが自動ラベル付けポリシーを作成・管理するユーザー／グループに公開されていること
- ラベルの優先順位（順序）が、同じ資産に複数ラベルがヒットした場合の挙動として妥当であること
これらはすでに満たしている前提ですが、特に大規模テナントでは「別の管理者がラベル順序を変えてしまっていた」なども起こりがちなので、トラブルシュート時には必ず再確認しておきましょう。
ステップ 2：自動ラベル付けポリシーを SIT 条件で作り直す
次に、問題の中心である自動ラベル付けポリシーの条件を、カスタム分類ルールではなく SIT ベースに置き換えます。
- Purview ポータルで Information Protection > ポリシー > 自動ラベル付けポリシー を開く
- Azure SQL 用に作成したポリシーを編集（または新規作成）
- 対象の場所として、Azure SQL や Azure Storage などの非 M365 ロケーションを指定
- ルール編集画面で、条件に「コンテンツに含まれる > 機密情報の種類」を選択
- 利用可能な SIT の中から、Azure SQL に格納されているデータに対応するものを選択
（例：クレジットカード番号、銀行口座番号、国民識別番号 など） - 条件を満たした場合に適用する感度ラベルとして、目的のラベルを指定
- ポリシーを有効（Active）にして保存
ここでも重要なのは、条件に指定できるのは SIT だけという点です。分類ルールや分類名を検索してもヒットしません。
ステップ 3：スキャン規則セットで SIT 検出を有効にする
自動ラベル付けポリシーで SIT を条件として指定しただけでは不十分で、スキャン側がその SIT を検出してくれている必要があります。具体的には、
- Purview Data Map で Azure SQL ソースに紐づくスキャン規則セットを開き、対象となる SIT を有効化する
- スキャンを再実行し、Data Map 上で対象テーブル／列に該当 SIT の検出結果（検出件数）が表示されていることを確認
ここで SIT が一件も検出されていなければ、自動ラベル付けポリシーが発火することはありません。逆に言うと、Data Map 上で SIT 検出が確認できれば、自動ラベルの条件に必要な“燃料”は揃った状態です。
ステップ 4：ラベル適用結果の確認
最後に、実際にラベルが付いているかを確認します。
- Purview 統合カタログ（Unified Catalog）で Azure SQL の該当テーブル／列を開く
- 右側のプロパティ ペインに感度ラベルが表示されているか確認
- ラベルでフィルタリングして、Azure SQL のラベル付き資産だけを絞り込んでみる
ここまで問題なく進めば、SIT の検出 → 自動ラベル → Data Map 上でのラベル確認という一連の流れが成立しているはずです。
よくある勘違い・設定漏れとチェックリスト
実案件でよく見かける「ハマりポイント」を、チェックリスト形式で整理しておきます。
| チェック項目 | OK 状態 | よくある NG パターン |
|---|---|---|
| ラベルのスコープ | 「ファイルとその他のデータ資産」が有効 | メール／ドキュメントのみが有効で、Data Map 用スコープがオフ |
| ラベルの公開範囲 | ポリシー作成者・スキャン実行者に公開済み | 別のグループにのみ公開されており、管理者自身にラベルが見えていない |
| ポリシーの条件 | 「コンテンツに含まれる > 機密情報の種類」になっている | 分類名やカスタム分類ルールを探しているが候補に出ず放置 |
| SIT の検出 | Data Map 上で対象 SIT の検出件数が確認できる | スキャン規則セットで SIT が無効、またはスキャンが実行されていない |
| ポリシー状態 | ステータスが「オン（Active）」 | シミュレーションモードのまま／作成だけして有効化していない |
| ラベル優先度 | 期待するラベルがより高い順序（優先度）に配置されている | 別のラベルが先に条件を満たし、意図しないラベルが適用されている |
| 保護ポリシー | ラベル適用後のアクセス制御として正しく動作 | 保護ポリシーがラベル適用のトリガーだと誤解している |
カスタム分類ルールはどう使えばいいのか？
ここまで読むと「結局カスタム分類ルールは無意味なのか？」と思われるかもしれませんが、実際には自動ラベルとは別の役割で非常に有用です。
カスタム分類ルールの主な使いどころ
- データ探索・インベントリ作成：
業務固有の列名や値パターン（例：社内の社員番号フォーマット、独自顧客 ID）を基に、どのデータソースにどの程度存在するかを一気に洗い出す。 - データスチュワード向けのナビゲーション：
カタログ上で「給与関連」「医療関連」など、業務の意味に紐づく分類で検索しやすくする。 - リスク評価・レポート：
Data Estate Insights などで、「特定の分類が付いている資産が、どのクラウド／どのリージョンにどれだけあるか」を把握する。
一方で、現時点の仕様では、カスタム分類ルールをそのまま「自動ラベルのトリガー」として使うことはできないため、
- ラベルによるアクセス制御が必須なシナリオ
- Azure SQL の列レベルでラベルを粒度良く付けたいシナリオ
では、どうしてもSIT ベースの設計を併用する必要があります。
どうしても SIT 化が難しい場合の回避策
「既存の分類ロジックが SIT に落とし込みにくい」「組み込み SIT ではカバーしきれない」というケースも多々あります。その場合の現実的な回避策としては、次のような運用が考えられます。
- Data Map で分類結果をフィルタし、対象資産に対して人手でラベルを付与する運用
→ ただし、現行の Data Map はラベルの手動付与はサポートしておらず、自動ラベル前提の設計であることに注意が必要です。実際には、元のファイル側でラベルを付けてからスキャンさせるなどの工夫が必要になります。 - ラベルではなく分類結果を起点としたガバナンスを徹底する
権限管理やアクセスフローを、厳密なラベル前提ではなく、「分類が付いた資産には原則このアクセス レベルにする」といった運用ポリシーで補う。 - Azure SQL 側のローカル分類／ラベル機能と組み合わせる
SQL Server / Azure SQL 側の「Data Discovery & Classification」機能を利用し、Purview とは独立したラベルや監査レポートでリスクを管理する。
ただし、「感度ラベルを前提にした暗号化・アクセス制御」を行いたい場合は、最終的には SIT ベースのアプローチが必要になる点は変わりません。
すぐ試せる最小構成の検証シナリオ
本番データでいきなり試すと原因切り分けが難しくなるので、まずは極力シンプルなパターンで動作確認することをおすすめします。
検証シナリオ例
- 単純なパターンの SIT を選定
例として、組み込みの「クレジットカード番号」の SIT を使う。 - Azure SQL にテストテーブルを作成
CREATE TABLE dbo.TestSensitiveData ( Id INT IDENTITY PRIMARY KEY, CardNumber NVARCHAR(50) ); INSERT INTO dbo.TestSensitiveData (CardNumber) VALUES ('4111-1111-1111-1111'); -- テスト用のダミー番号 - Purview Data Map で Azure SQL ソースを登録し、スキャン規則セットで当該 SIT を有効化
- スキャンを実行し、Data Map 上で当該列に SIT の検出結果が付いていることを確認
- Information Protection 側で自動ラベル付けポリシーを作成
- 対象：テスト用 Azure SQL データベースのみ
- 条件：コンテンツに含まれる → 機密情報の種類 → クレジットカード番号
- アクション：任意の感度ラベルを適用
- 再度スキャンを実行し、Data Map 上でテストテーブル／列に感度ラベルが付いているかを確認
このような検証を一度通しておくと、
- 自動ラベル付けポリシーと Azure SQL の連携自体が動いているか
- SIT ベースの条件が正しく機能しているか
をシンプルな条件で確認できるため、本番の複雑なシナリオでトラブった際の「動く状態」の比較対象として非常に役立ちます。
実案件での設計パターン例
最後に、実務でよくあるユースケースをもとに、どう設計するかの例を挙げておきます。
パターン 1：法律・規制で定義された情報を優先（組み込み SIT 中心）
- クレジットカード番号、銀行口座番号、パスポート番号、国民 ID など
- これらは多くが組み込み SITとしてすでに用意されている
- まずはこれら SIT を条件に自動ラベルを構成し、「規制上明確に保護が必要なデータ」からラベル適用を進める
パターン 2：業務固有データは分類でカバーしつつ、ラベルは粗めに設計
- 社員 ID、給与ランク、社内グレードなど、明確な法令ベースではないが重要なデータ
- これらはカスタム分類ルールで検出し、どこにどれだけ存在するかを可視化する
- 自動ラベルは、「規制対象 + 社内高度機密を同じラベルで扱う」など、やや粗めにマッピングする
パターン 3：段階的導入（まずは可視化 → 次にラベル → 最後に保護ポリシー）
- フェーズ 1：分類・検出
カスタム分類ルール + 組み込み分類を駆使して、どの資産に何が含まれているかを把握。 - フェーズ 2：SIT ベースの自動ラベル
組み込み SIT を中心に、自動ラベル付けポリシーを段階的に ON。 - フェーズ 3：保護ポリシーの適用
ラベルに紐づく暗号化やアクセス制御を徐々に厳しめにしていく。
このように、「分類で詳細に見る」「ラベルはやや粗くても確実に付ける」「保護は段階的に強化する」という三層構造で設計すると、Azure SQL も含めたデータ保護の運用が安定しやすくなります。
まとめ：今回押さえておきたい要点
- Purview の自動ラベル付けポリシーは、条件として「機密情報の種類（SIT）」しか使えない
- カスタム分類ルール（Purview ガバナンス側）は、自動ラベルの条件としては利用不可であり、今回ラベルが付かなかった原因はここにある
- Azure SQL に対する自動ラベル付けは、現時点では組み込み SIT を中心とした設計に寄せる必要がある
- カスタム分類ルールは、自動ラベルのトリガーではなく、データ探索・リスク可視化のための強力なツールとして使う
- 本番導入前に、シンプルな SIT で最小構成の検証シナリオを回しておくと、トラブルシュートが格段に楽になる
「カスタム分類ルールを作ったのに自動ラベルが動かない」というのは、Purview / Data Map / Information Protection の境界が分かりづらいがゆえに、多くの組織で繰り返し発生しているテーマです。本記事の内容を踏まえて、まずは SIT ベースで確実に動く構成を押さえた上で、分類・ラベル・保護ポリシーを段階的に整えていくのがおすすめです。
コメント