Microsoft PurviewでMicrosoft Fabric Lakehouseテーブルにデータ品質（DQ）ルールを付けようとすると、列の型が「Unsupported」になり選択できないことがあります。本記事では原因と、Purview側でのスキーマ再取り込み・回避策まで具体的に解説します。
起きている現象：Fabric Lakehouseテーブルの列が「Unsupported」になりDQルールを作れない
現場でよく見かける症状は次のとおりです。
- PurviewでFabric Lakehouseテーブルを開くと、テーブル全体または一部列のスキーマ（データ型）が空、もしくはUnsupported（サポート対象外）と表示される
- Data Quality（DQ）のルール作成画面で、該当列が候補に出てこない／選べない
- 一方で、プロファイリング（統計情報の取得：NULL件数、最小・最大、ユニーク数など）は正常に実行できる
この「プロファイリングは動くのに、DQルールが作れない」というギャップが、原因の切り分けを難しくします。
先に結論：多くは「DQエンジン側の型マッピング不足」と「Purviewに取り込まれたスキーマ情報の不整合」
Microsoft PurviewのDQは、ルールを定義するために列のデータ型を“DQで扱える型”へマッピングして解釈します。Fabric Lakehouse（Spark/Delta）の型は幅広く、しかも進化が速いため、Purview側のDQ機能が参照する型マッピングが追いつかないケースがあります。
その結果として、Purviewの画面上は次のような状態になります。
- プロファイリング：実データを読み、統計値を計算するだけなので動く
- DQルール：型が確定しない（Unsupported扱い）ため、ルール対象列として提示できず止まる
なぜ「プロファイリングはOK」で「DQルールはNG」なのか
同じデータを見ているのに挙動が違う理由は、処理の前提が違うからです。違いを一度整理すると、問題の理解と説明がスムーズになります。
| 観点 | プロファイリング（統計） | DQルール（検証） |
|---|---|---|
| 目的 | データの傾向を把握する（NULL率、分布、最大・最小など） | ルールに照らして合否判定する（範囲、正規表現、参照整合性など） |
| 必要情報 | 列値を読み取れれば実行できる | 列の型が確定していることが前提（数値・日付・文字列など） |
| 型が曖昧な場合 | 値を読める限り統計は計算できる | 型不明だと「どのルールを当てられるか」が判断できず、列が候補から外れる |
| よくある失敗 | 権限や接続が不足してプロファイルが取れない | スキーマが空／Unsupportedでルール対象にならない |
つまり、今回の現象は「接続できていない」のではなく、“DQルール用の型解釈”の段階で弾かれていると考えるのが近道です。
原因の詳細：Fabric Lakehouseの一部Sparkデータ型がPurview DQに未対応・未整備な場合がある
Fabric Lakehouseのテーブルは、内部的にはDelta Lake（Parquet + トランザクションログ）として管理され、Sparkのスキーマ（例：int, string, timestamp, decimal, array, struct など）を持ちます。
一方、PurviewのDQは、ルール定義のために「数値型」「文字列型」「日付/時刻型」などのカテゴリに落とし込む必要があります。この変換がうまくいかないと、Purview画面上で「Unsupported」と表示され、ルール作成画面の候補から消えることがあります。
特に現場で詰まりやすいのは次のパターンです。
- 整数型（例：
int）が環境や取り込み経路によってUnsupportedになる - 同じ列でも、スキャンのタイミングやスキーマ進化（Schema evolution）後に、Purviewが古い型情報を保持してしまう
- 複合型（
array,map,struct）や、精度が大きすぎるdecimalなど、DQルールの前提に合わない型が含まれている - Lakehouseのテーブル定義が曖昧（自動推論・書き込み時に列型が揺れる）で、Purview側の解釈が安定しない
まず試す対処：Purviewでスキーマを明示的に再取り込みする
多くのケースでは、Purviewポータル側でスキーマ情報を再取り込み（再同期）するだけで改善します。ポイントは「DQルールが見ているスキーマ」を最新化することです。
手順：Schema managementをオンにしてImport schemaを実行
- Purviewポータルで対象のFabric Lakehouseテーブル（アセット）を開く
- 画面上部の「スキーマ」（Schema）タブを開く
- 可能であれば「Schema management」のトグルをオンにする
- 「Import schema」（スキーマのインポート）をクリックし、列定義とデータ型を再読み込みする
- スキーマ更新後、Unsupportedだった列の型が正しく表示されるか確認する
- 再度DQルール作成を開き、対象列が選択できるか確認する
スキーマが正しく表示されるようになったら、DQルール作成とDQスキャン（またはルール評価）の再実行まで一気に進めるのが効率的です。
スキーマ再取り込みが効く理由
Purviewはスキャン結果やメタデータをキャッシュ・蓄積します。Lakehouse側でスキーマが変わったり、初回スキャン時に何らかの理由で型が正しく取り込めなかったりすると、Purview上の表示が「空」や「Unsupported」のまま残ることがあります。Import schemaは、このズレを埋めるための“再同期”として有効です。
確認用：Lakehouse側の「本当のスキーマ」を把握する
Purview側の表示だけを見ていると、どこでズレたかが分かりません。まずはLakehouse（Spark/SQL）で、テーブルの実スキーマを確認しておくと切り分けが早くなります。
Sparkでスキーマを確認する例
# PySpark（概念）
df = spark.table("original_table")
df.printSchema()Spark SQLでスキーマを確認する例
DESCRIBE TABLE original_table;ここでLakehouse側ではintやstringとして正しく定義されているのに、PurviewでUnsupportedになる場合は、Purview側の取り込み・マッピングがボトルネックになっている可能性が高いです。
改善しない場合の切り分けチェックリスト
Import schemaでも解消しない場合は、次の観点で原因を絞り込みます。運用チームやデータ基盤チームに確認を依頼する際のチェック項目としても使えます。
| チェック項目 | 確認ポイント | よくある対策 |
|---|---|---|
| スキャンの鮮度 | Purviewの最終スキャン時刻が古くないか | 手動で再スキャン、またはスキャンスケジュールを短くする |
| 権限 | Purviewのスキャン/参照権限が十分か（Lakehouse側アクセス含む） | 必要なロール付与、接続（credential）見直し |
| スキーマ進化 | 書き込みで列追加・型変更が頻繁に起きていないか | DQ対象は固定スキーマの“DQ用テーブル”に寄せる |
| 複合型の混在 | array/map/structなどが列に含まれていないか | DQ対象列をフラット化し、別テーブル/ビューに出す |
| decimal精度 | 精度・スケールが極端（例：DECIMAL(38, 18)など）ではないか | DQ用にDECIMAL(18, 2)などへcastし、精度を現実的にする |
| 列名・予約語 | スペース、記号、予約語、重複名などがないか | DQ用に列名を正規化（snake_case等） |
| Shortcutの参照 | OneLake shortcut経由で外部ストレージを参照していないか | まずはネイティブテーブルで再現確認し、差分を比較する |
ワークアラウンド：DQ対象だけ「DQが得意な型」に寄せる
現実には「Lakehouseはそのまま使いたいが、DQだけ先に回したい」場面が多いはずです。その場合は、DQに渡す“入口”を整える発想が有効です。
よくあるUnsupported型と、実務的な寄せ方
| Lakehouse側の型・状況 | DQで詰まりやすい理由 | 回避の例 | 注意点 |
|---|---|---|---|
| int / integer がUnsupported扱い | DQ側の型カテゴリにマッピングされないことがある | BIGINTへcast、またはDECIMAL(18,0)へcast | 下位互換は保ちやすいが、アプリ側の型期待に注意 |
| string がUnsupported扱い | 文字列長やエンコーディング等の扱い差で判定が揺れることがある | DQ用テーブルではVARCHAR相当として扱える層（Warehouse等）に載せ替え | 正規表現やトリムなど前処理で精度が上がる |
| timestamp_ntz など派生の時刻型 | DQが想定するtimestampと一致しない | TIMESTAMPへcast、タイムゾーン方針を決める | 変換時の時差・サマータイムの扱いに注意 |
| struct/array/map | 列の中にネスト構造があり、単一列ルールが作りにくい | 必要な要素を抽出してフラット列にする | どの要素を品質管理対象にするかを設計で決める |
例：Spark SQLでDQ用テーブルを作り、型を単純化する
Lakehouse直でDQが難しい場合でも、同じLakehouse内に「DQ用の派生テーブル」を用意すると運用が安定します。たとえば、次のようにcastとフラット化を行います。
-- DQ用に型を寄せたテーブルを作成する例（概念）
CREATE OR REPLACE TABLE dq_ready_table AS
SELECT
CAST(order_id AS BIGINT) AS order_id,
CAST(customer_id AS STRING) AS customer_id,
CAST(amount AS DECIMAL(18,2)) AS amount,
CAST(order_date AS TIMESTAMP) AS order_date,
TRIM(CAST(email AS STRING)) AS email,
CAST(address.city AS STRING) AS city
FROM original_table;この「dq_ready_table」をPurviewでDQ対象にすると、Unsupportedが出にくく、ルール設計もしやすくなります。
スキーマが直った後にやること：DQルール作成とスキャン結果の見方
Unsupportedが解消すると、ようやくDQルールが“設計可能な状態”になります。ここから先で迷わないために、作業の流れと、よく使うルール例をまとめます。
DQルール作成の基本フロー
- Purviewで対象アセット（テーブル）を開き、Data Qualityのルール作成画面へ移動
- ルールセット（Rule set）を新規作成し、対象列を選択
- ルール種類（例：必須、範囲、形式、重複など）を選び、条件としきい値を設定
- DQスキャン/評価を実行し、結果（合格率、違反件数、サンプル）を確認
- NGが多い場合は、ルールを緩めるのではなく、まずは前処理（トリム、置換、欠損補完）で品質を上げる
すぐ使えるDQルール例
| 対象列の例 | よくあるルール | 判定イメージ | 実務メモ |
|---|---|---|---|
| order_id（数値） | 必須 + 一意性 | NULL禁止、重複禁止 | 一意性は全件判定が重いので、運用開始時は日次・バッチで回すのが現実的 |
| amount（金額） | 範囲（0以上） | マイナス金額を除外 | 返金など例外があるなら、例外フラグ列を用意してルールを分岐させる |
| email（文字列） | 形式（正規表現） | メール形式のみ許可 | 前処理で空白除去・小文字化してから判定すると誤検知が減る |
| order_date（日付） | 範囲（未来日禁止） | 現在日時より後はNG | 時刻・タイムゾーン方針を決めないと「未来」判定が揺れる |
推奨回避策：Fabric WarehouseまたはSynapse SQL系にロードしてPurviewでDQを実行する
Import schemaでも改善しない、または複合型・スキーマ進化が激しくて安定しない場合は、DQ対象だけWarehouse / Synapse SQL系へ取り込む運用が堅実です。SQL系のデータ型はDQルールの前提と親和性が高く、列がUnsupportedになりにくい傾向があります。
この方式が向くケース
- DQルールをビジネス部門が運用し、UI上で列選択・ルール編集を頻繁に行う
- 数値・日付・文字列など、典型的な業務データが中心
- DQ結果を監査証跡として残したい（いつ、どのルールで、どれだけ落ちたか）
- Lakehouse側のスキーマ進化を止められない（分析の自由度を優先したい）
LakehouseとWarehouseを併用する「現実解」の設計
Lakehouseを捨てる必要はありません。次のように役割を分けると、コストと効果のバランスが取りやすくなります。
| 領域 | 主な役割 | 向いている理由 | 運用上のコツ |
|---|---|---|---|
| Lakehouse | データ取り込み・加工・分析の自由度確保 | Spark/Deltaの柔軟性が高い | 品質管理に必要な列は「DQ用テーブル」に切り出す |
| Warehouse / SQLプール | DQルール適用・業務レポート・ガバナンス向け整形 | 型が安定し、DQルール設計がしやすい | ロード頻度（毎時/毎日）とSLAを先に決める |
| Purview | カタログ、検索、責任者、用語集、ラインエージ | 資産管理・統制の“台帳”として強い | DQ結果の格納先と可視化先を統一する |
Lakehouse直でDQを続けたい場合の実務的テクニック
「どうしてもLakehouse直でルールを回したい」場合は、DQの“失敗を誘発する要因”を先回りで潰すのがポイントです。
スキーマを安定させるためのコツ
- 自動推論に頼りすぎない：初回書き込み時の推論がズレると、以降の型修正が難しくなります。可能ならCREATE TABLEで明示する
- Schema evolutionを運用ルール化：列追加・型変更を自由にすると、Purview側の取り込みが追従できずUnsupportedを生みやすい
- 品質管理対象の列だけ固定：分析用の自由列と、業務品質で守る列を分ける（「DQ対象は固定列」）
- 複合型はDQの前にフラット化：DQは“列単位”で考えると設計しやすい
DQルール設計のコツ（Unsupported回避だけでなく精度を上げる）
- 数値チェックは「範囲」だけでなく、外れ値（上位・下位パーセンタイル）の考え方も入れる
- 文字列は「正規表現」より前に、トリム・小文字化・全角半角統一など前処理でブレを減らす
- 参照整合性は、マスタ側の鮮度と欠損の扱い（NULLを許すか）を先に合意する
- DQの合格率は100%を目標にしない。現実の運用では段階的に基準を上げる方が定着する
よくある質問
プロファイリングが取れているなら、DQも本来は動くはずでは？
結論：動くとは限りません。プロファイリングは値の統計計算が中心で、DQは「列型に応じたルール適用」が中心です。DQは型に強く依存するため、スキーマの取り込みや型マッピングで止まることがあります。
Import schemaをすると、手動で編集したスキーマは消えますか？
環境や設定によって挙動が異なることがあります。運用上は、Import schemaの前に「手動で付与した説明・属性がどこに保存されているか」を確認し、再同期後に影響がないかをチェックするのが安全です。
Unsupportedになる列だけ除外してDQを回すのはアリ？
短期的には有効ですが、放置すると「品質管理の穴」になります。推奨は、除外ではなく、DQ用に型を寄せた派生列（cast列）を用意して管理対象に戻すことです。
最短で復旧したい場合、どの順番で試すべき？
次の順で試すと、手戻りが少なくなります。
- PurviewでSchema managementをオン → Import schema
- 改善しない列の型を確認し、DQ用テーブルでcast
- 複合型やスキーマ進化が原因なら、Warehouse/Synapse側にDQ対象を寄せる
まとめ：Purviewの“スキーマ解釈”を整えると、DQルール設定の詰まりは解消しやすい
Fabric Lakehouseテーブルでスキーマが検出されずDQルールを作れない場合、まず疑うべきは「接続」ではなくスキーマと型マッピングです。Purview上でのスキーマ再取り込み（Import schema）で直ることが多く、それでも難しければDQ対象だけ型を単純化した派生テーブル、またはWarehouse/Synapse SQL系へロードする回避策が現実的です。
| 優先度 | やること | 狙い |
|---|---|---|
| 高 | PurviewでImport schemaを実行してスキーマを再同期 | Unsupported/空スキーマを解消してDQルール対象に戻す |
| 中 | DQ用テーブル（cast・フラット化）をLakehouse内に作る | 型揺れ・複合型の影響を隔離して安定運用 |
| 中 | Warehouse/Synapse SQL系にDQ対象を寄せる | SQL型で型サポートを取りに行き、ルール運用を簡単にする |
| 低 | Lakehouseはカタログ用途に残し、DQは別基盤で実行して結果連携 | ガバナンスと処理基盤を分離し、将来の拡張に備える |
コメント