Data Quality in Microsoft Purview Unified Catalogは、Microsoft Purview上でデータ資産の品質を「見える化し、ルールで評価し、問題を改善アクションにつなげる」ための機能です。結論から言うと、2026年5月時点で管理者が優先して確認すべきポイントは、スタンドアロンのデータ資産スキャン、増分データ品質スキャン、しきい値設定の一般提供化、そしてそれらに伴う権限・接続・課金・スキーマ管理の見直しです。Microsoft PurviewをAI活用やデータガバナンスの基盤として使う組織では、単にカタログへ登録するだけでなく、「そのデータは業務で使ってよい品質か」を継続的に判断できる運用へ移す必要があります。(Microsoft Learn)
Data Quality in Microsoft Purview Unified Catalogとは
Data Quality in Microsoft Purview Unified Catalogは、Microsoft Purview Unified Catalog内でデータ資産、データ製品、ガバナンスドメイン単位のデータ品質を評価・監視する機能です。列レベルにデータ品質ルールを適用し、その結果をデータ資産、データ製品、ガバナンスドメインへ集計することで、組織全体のデータ品質を把握できます。(Microsoft Learn)
従来のデータカタログ運用では、「どこにデータがあるか」「誰が所有しているか」は整理できても、「そのデータをレポート、AI、業務判断に使ってよいか」までは別ツールや手作業で確認するケースが多くありました。Microsoft PurviewのData Qualityは、このギャップを埋めるために、プロファイリング、ルール、スキャン、スコア、アラート、改善アクションをUnified Catalogの文脈で扱えるようにします。
実務では、次のような問いに答えるための機能だと考えると分かりやすいです。
| 確認したいこと | Data Qualityでできること |
|---|---|
| 顧客マスタに空欄が多くないか | Empty/blank fieldsルールやCompleteness評価で確認する |
| IDやメールアドレスが重複していないか | Unique valuesやDuplicate rowsルールで確認する |
| 日付、郵便番号、コード値の形式が正しいか | String format matchやCustomルールで確認する |
| データが最新状態か | Freshnessルールやしきい値で確認する |
| 品質低下を誰に通知するか | アラートとデータ品質アクションで担当者に通知・割り当てる |
Microsoft PurviewのData Qualityは、ノーコードまたはローコードで使える標準ルール、AI支援によるルール提案、ADF式やSQL式を使ったカスタムルールを備えています。標準ルールだけで始められる一方、業務固有の条件が必要な場合はSpark SQLベースのカスタムSQLルールも利用できます。(Microsoft Learn)
2026年5月の公式情報で押さえる変更点
2026年5月のMicrosoft Purviewの更新情報では、Data Governance領域で3つのData Quality関連機能が一般提供として示されています。スタンドアロンのデータ資産に対するデータ品質スキャン、増分データ品質スキャン、データ品質ルールおよびデータ資産のしきい値設定です。(Microsoft Learn)
| 変更点 | 何が変わるか | 実務上の意味 |
|---|---|---|
| スタンドアロンデータ資産のデータ品質スキャンがGA | データ製品に関連付ける前のデータ資産でも品質を評価できる | データ製品化する前に「使えるデータか」を判断しやすくなる |
| 増分データ品質スキャンがGA | 時間ベースのフィルターで、新規・更新分を中心にスキャンできる | 全件スキャンの頻度を下げ、直近データの品質監視を効率化できる |
| データ品質しきい値がGA | ルール単位、データ資産単位で許容スコアを設定できる | 重要データと参考データで異なる品質基準を運用できる |
特に重要なのは、Data Qualityが「データ製品に紐づいた資産だけを評価する機能」から、「データ製品化の前段階でも品質を評価し、継続的に監視する機能」へ広がっている点です。データ活用の現場では、まだ整理されていないデータをいきなり業務利用するのではなく、先に品質スコアを見て、改善・保留・アーカイブを判断する流れを作れます。(Microsoft Learn)
影響範囲：管理者・開発者・データスチュワードが受ける影響
今回の更新は、単なる画面機能の追加ではありません。Microsoft Purviewを運用する管理者、データ基盤を扱う開発者、データ品質を管理するデータスチュワードの作業範囲に影響します。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| Microsoft Purview管理者 | 権限、課金、ネットワーク、リージョンの確認が必要 | Data Quality Steward、Data Health Reader、Data Product Ownerなどの割り当て |
| データスチュワード | ルール設計、スコア確認、改善アクションの管理が必要 | どの列にどのルールを適用するか、しきい値を何％にするか |
| データエンジニア | スキーマ変更、接続方式、スキャン失敗時の調査に関与 | マネージドID、プライベートエンドポイント、スキーマインポート |
| BI・AI担当者 | 品質スコアを利用可否判断に使える | レポートやAI用データの最低品質基準 |
| 開発者 | APIや自動化の利用可能性を検討する | Data Quality REST APIはプレビュー機能として案内されているため、本番自動化ではサポート範囲を確認 |
Data Qualityを展開する際は、データ品質担当だけに任せるのではなく、Purview管理者、Azure管理者、ネットワーク管理者、データ所有者を含めて設計する必要があります。特に、データソースへの読み取り権限、マネージドID、プライベートエンドポイント、スキャンスケジュールは、運用開始後に問題になりやすいポイントです。(Microsoft Learn)
導入前に確認すべき前提条件
Unified Catalogを使えるリージョンか確認する
Microsoft Purview Unified Catalogはリージョンごとに利用可否が管理されています。日本向け環境ではJapan Eastが利用可能リージョンとして掲載されていますが、組織のPurviewアカウントがどのリージョンにあるか、Unified CatalogのEnterprise機能を利用できる状態かを先に確認してください。(Microsoft Learn)
特にグローバル企業では、データ所在地、契約、課金、管理対象リージョンが一致していない場合があります。Data Qualityのスキャン対象が複数リージョンにまたがる場合、技術的に接続できるかだけでなく、データレジデンシーや社内ポリシーも確認が必要です。
必要なロールを割り当てる
Data Qualityの機能を使うには、役割に応じた権限が必要です。たとえば、データ品質ルールの作成やスキャンの実行にはData Quality Steward、既存ルールの閲覧にはData Quality Reader、Health management領域の閲覧にはData Health Readerが関係します。(Microsoft Learn)
| 作業 | 必要な権限の例 | 注意点 |
|---|---|---|
| データ品質ルールを作成・管理する | Data Quality Steward | ルール作成だけでなく、スキャンやスケジュール設定にも関係する |
| データ品質の結果を見る | Data Quality Reader、Data Quality Metadata Readerなど | プロファイル詳細やエラー記録の閲覧範囲に差がある |
| データ製品へ資産を追加する | Data Product Owner、Data Stewardなど | Data Map側の読み取り権限も必要になる場合がある |
| ガバナンスドメイン全体を管理する | Governance Domain Owner | 少なくとも複数名を割り当て、属人化を避ける |
よくある失敗は、Purview側のロールだけを付与し、Azureリソース側の読み取り権限を忘れることです。Unified Catalogで見えている資産でも、スキャンやプロファイリングに必要なデータソース側のアクセス権がなければ、ジョブは失敗します。
対応データソースとファイル形式を確認する
Data Qualityは複数のクラウドデータソースに対応しています。公式情報では、Azure Data Lake Storage Gen2、Azure SQL Database、Azure SQL Managed Instance、Azure Synapse、Azure Databricks Unity Catalog、Snowflake、Google BigQuery、Fabricなどがデータプロファイリングとデータ品質スキャンの対象として整理されています。(Microsoft Learn)
ただし、すべてのデータソースで同じ機能が使えるわけではありません。たとえば、Google BigQueryはデータプロファイリングとデータ品質スキャンに対応していますが、仮想ネットワークサポートはありません。OracleやSQL Serverのオンプレミス環境は、データ品質スキャンには対応する一方、プロファイリングは対応表でNoとされています。(Microsoft Learn)
ファイル形式ではDelta、Parquet、Iceberg Avro、Iceberg Orcがサポート対象として示されています。Parquetを使う場合は、任意の複雑なディレクトリ階層ではなく、SparkPartitionsで終わる構造や列パーティション構造など、サポートされるリソースセットパターンに合わせる必要があります。(Microsoft Learn)
展開手順：Data Qualityを本番運用に乗せる流れ
Data Qualityは、いきなりルールを大量に作るよりも、ライフサイクルに沿って段階的に展開する方が失敗しにくくなります。Microsoftの概要ページでは、権限付与、Data Mapへの登録とスキャン、データ製品への追加、データソース接続、プロファイリング、ルール設定、データ品質スキャン、結果確認、継続監視という流れが示されています。(Microsoft Learn)
| 手順 | 作業 | 実務での判断基準 |
|---|---|---|
| 1 | Data Quality Stewardなどの権限を割り当てる | 最小権限で始め、運用担当と閲覧担当を分ける |
| 2 | Data Mapにデータソースを登録・スキャンする | 対象資産がCatalogに表示されるか確認する |
| 3 | データ資産をデータ製品へ追加、またはスタンドアロン資産として扱う | 既に用途が明確ならデータ製品へ、評価段階ならスタンドアロンで始める |
| 4 | データソース接続を設定する | 読み取り権限、マネージドID、ファイアウォール、VNetを確認する |
| 5 | データプロファイリングを実行する | 空欄率、重複、一意性、分布を見てルール候補を決める |
| 6 | データ品質ルールを作成する | 重要列から始め、すべての列にルールを付けない |
| 7 | 品質スキャンを実行・スケジュールする | 初回は手動、安定後に日次・週次へ移行する |
| 8 | スコア、アクション、アラートを確認する | しきい値未満の資産を改善対象として管理する |
最初の対象は、全データではなく、業務影響の大きいデータに絞るのが現実的です。たとえば、経営ダッシュボードで使う売上テーブル、顧客マスタ、AI検索やRAGの根拠データ、監査対象のトランザクションデータなどから始めると、品質改善の効果を説明しやすくなります。
データソース接続で確認すべき設定
Data Qualityの接続設定は、プロファイリングやデータ品質スキャンのために必要な認証を構成する工程です。Microsoft Purviewは、メタデータ検出、プロファイリング、品質スキャンに必要な読み取りレベルの権限を必要とします。Azure Data Lake Storage Gen2ではMicrosoft Purview Managed IdentityにStorage Blob Data Reader、Azure SQL Databaseではdb_datareaderを割り当てる例が示されています。(Microsoft Learn)
ネットワーク面では、Azure Storageのファイアウォールを開く、Trusted Azure Servicesを許可する、またはMicrosoft Purview Data Quality managed virtual networkとプライベートエンドポイントを使う選択肢があります。閉域構成のデータソースを扱う場合は、ガバナンスドメイン所有者だけでなく、Azure StorageやSQL Server側の所有者によるプライベートエンドポイント承認も必要になります。(Microsoft Learn)
注意したいのは、仮想ネットワーク保護された資産ではテスト接続が現在サポートされていない点です。設定直後に画面上のテストだけで完了判断せず、実際のプロファイリングやスキャンジョブが動作するかを検証してください。(Microsoft Learn)
ルール設計：標準ルールとカスタムルールの使い分け
Data Qualityで最も重要なのは、どのルールをどの列に適用するかです。標準ルールは便利ですが、むやみに全列へ適用すると、スキャンコスト、運用負荷、誤検知が増えます。まずは、業務上の「品質が悪いと困る列」から選ぶべきです。
| ルール | 向いている用途 | 具体例 |
|---|---|---|
| Empty/blank fields | 必須項目の欠損確認 | 顧客ID、請求先コード、取引日 |
| Unique values | 一意であるべき列の確認 | 顧客ID、注文番号、社員番号 |
| Duplicate rows | 複数列の組み合わせ重複確認 | 顧客ID＋契約ID、伝票番号＋明細番号 |
| String format match | 形式チェック | メールアドレス、郵便番号、コード値 |
| Data type match | 型の不整合確認 | 数値として扱う金額列、日付列 |
| Table lookup | 参照整合性の確認 | 部門コードが部門マスタに存在するか |
| Freshness | 更新遅延の確認 | 日次更新される売上集計テーブル |
| Custom / Custom SQL | 業務固有ルール | 金額が0以上、開始日が終了日以前、ステータス遷移の妥当性 |
Microsoft Purviewでは、すぐに使えるルールに加え、ADF式、正規表現、SQL式を使ったカスタムルールを作成できます。カスタムSQLルールではSpark SQL述語を使えるため、平均値、中央値、標準偏差、ウィンドウ関数などを使った高度な検証も可能です。(Microsoft Learn)
ただし、カスタムSQLルールには制限があります。JOINはサポートされず、INSERT、UPDATE、DELETE、GRANT、TRUNCATE、DROP、ALTERのようなデータ変更や権限制御に関わるSQL操作は使えません。また、データ資産名をSQL式で参照する場合は、英数字とアンダースコアのみ、64文字以内などのサニタイズ規則を意識する必要があります。(Microsoft Learn)
データプロファイリングはルール作成前に必ず実行する
Data Qualityのルールは、思いつきで作るよりも、データプロファイリングの結果を見てから設計する方が精度が上がります。プロファイリングでは、分布、最小値、最大値、標準偏差、一意性、完全性、重複などの統計的な情報を列単位で確認できます。(Microsoft Learn)
たとえば、顧客メールアドレス列を見たときに、空欄が5％、n/aのような値が2％、明らかに形式不正な値が1％あると分かれば、次のようにルールを分けられます。
| 観点 | ルール例 | 判断 |
|---|---|---|
| 空欄を許容するか | Empty/blank fields | 業務上必須なら不合格、任意なら対象外 |
| ダミー値をどう扱うか | Custom ruleのFilter expression | n/aやtestを無視するか、失敗扱いにするか決める |
| 形式不正をどう検知するか | String format matchまたはregex | メール形式のチェックを適用する |
| 重複をどう見るか | Unique values | 顧客IDでは必須、メールアドレスでは業務要件次第 |
なお、プロファイリングでは現在、1バッチあたり50列をプロファイルできるとされているため、列数が多い資産では重要列を優先して複数バッチに分ける必要があります。また、データソース側のスキーマを変更した場合は、プロファイリングやスキャン前にスキーマインポートを実行する必要があります。(Microsoft Learn)
増分データ品質スキャンの使いどころ
増分データ品質スキャンは、時間ベースのフィルターを使って新規または更新されたデータを中心に評価する機能です。フルスキャン、増分スキャン、または両方を選べるため、過去データ全体を毎日スキャンする必要がないデータ資産で特に有効です。(Microsoft Learn)
実務では、次のように使い分けると運用しやすくなります。
| データの性質 | 推奨スキャン | 理由 |
|---|---|---|
| 毎日追加される売上・ログ・注文データ | 増分スキャンを日次、フルスキャンを月次 | 直近の異常を早く検知しつつ、全体整合性も定期確認する |
| 履歴データがほぼ変わらないマスタ | フルスキャンを週次または月次 | 更新頻度が低ければ増分の効果が小さい |
| 重複検知が重要なデータ | フルスキャン中心 | 重複検知など一部ルールは全体評価が必要 |
| AI用の根拠データ | 増分スキャンとしきい値アラート | 新しく投入された低品質データがAI出力に影響する前に検知する |
増分スキャンでは、日時列または日付列を指定します。公式情報ではdatetime列の利用が推奨されており、日付列だけでは直近24時間を正確に切り出せないため、日次スキャンの構成に制約が出る場合があります。また、オンプレミスデータソースでは増分データ品質スキャンはサポートされていません。(Microsoft Learn)
しきい値とアラートは「80点なら合格」で統一しない
Data Qualityのしきい値は、「どの品質スコアなら業務上許容できるか」を定義する基準です。2026年5月の更新では、データ品質ルールとデータ資産に対する構成可能なしきい値が一般提供として示されています。(Microsoft Learn)
重要なのは、すべての列や資産に同じしきい値を使わないことです。たとえば、請求金額や金融取引の正確性は100％に近い基準が必要ですが、商品説明文の任意入力項目では80〜90％でも許容できる場合があります。Microsoftの説明でも、メールアドレスは99〜100％の完全性が必要になり得る一方、説明列では80〜90％が許容される例が示されています。(Microsoft Learn)
| データ項目 | しきい値の考え方 | 例 |
|---|---|---|
| 請求金額、会計仕訳、監査対象データ | 原則として非常に高い基準 | Accuracy 100％、型不整合0件を目標 |
| 顧客ID、注文ID、社員番号 | 一意性と欠損を厳しく見る | Unique 100％、Empty 0件 |
| メールアドレス、住所、電話番号 | 業務用途に応じて高めに設定 | 連絡用途ならCompleteness 95％以上など |
| 説明文、備考欄 | 欠損許容を明確化 | 必須でなければルール対象外も検討 |
| AI検索・RAGの根拠データ | 誤情報の混入を重視 | Freshness、形式、参照整合性を組み合わせる |
アラートは、スコアが指定値を下回った場合や、前回スキャンから一定割合以上低下した場合に通知できます。通知先は個人だけでなく、メールエイリアスや配布グループを使うと、担当者異動や休暇に強い運用になります。(Microsoft Learn)
スコアの読み方：数字だけで判断しない
Data Qualityスコアは、基本的にはルールを通過したレコード数を評価対象レコード数で割って計算されます。列スコア、データ資産スコア、データ製品スコア、ガバナンスドメインスコアへ集計されるため、経営層やデータオーナーは全体像をつかみやすくなります。(Microsoft Learn)
ただし、スコアは万能ではありません。たとえば、空欄を許容する列にEmpty/blank fieldsルールを設定していなければ、Unique valuesやFormat matchの評価でnullが無視されることがあります。逆に、必須項目なのに空欄チェックを設定していないと、見かけ上のスコアが高く出る可能性があります。(Microsoft Learn)
運用では、次の3つをセットで見ることが重要です。
| 見るもの | 判断できること |
|---|---|
| スコア | 現在の品質状態が基準を満たしているか |
| ルール履歴 | 品質が改善しているか、悪化しているか |
| アクション | 誰が何を直すべきか |
Data Qualityでは、しきい値を下回ったルールやグローバルスコア、失敗・スキップされたジョブ、プロファイル列の外れ値、nullの多さなどからアクションが生成されます。アクションには重要度があり、担当者へ割り当ててステータス管理できます。(Microsoft Learn)
移行・展開時に失敗しやすいポイント
データ製品化の前にスタンドアロン資産で品質を見る
スタンドアロンデータ資産のData Qualityスキャンが一般提供されたことで、データ製品に関連付ける前の段階でも品質評価を実行できます。これは、データ製品を作ってから品質問題に気づくのではなく、候補資産の段階で「使う・直す・保留する」を判断できるという意味で大きな変更です。(Microsoft Learn)
ただし、スタンドアロン資産とデータ製品に関連付けた資産では、品質期待値が異なる場合があります。たとえば同じ顧客プロファイルでも、マーケティング用途ではメールアドレスが重要で、請求用途では住所や請求先情報が重要です。公式情報でも、同じデータ資産を複数のデータ製品に関連付ける場合、対象データ製品の文脈でローカルにデータ品質スキャンを実行する必要があると説明されています。(Microsoft Learn)
スキーマ変更後はスキーマインポートを忘れない
データソース側で列追加、列名変更、型変更があった場合、Data Quality側のスキーマが古いままだとジョブが失敗することがあります。その場合は、Data Qualityの概要ページからSchema managementを有効にし、Import schemaを実行します。スキーマインポートは、パブリックネットワーク上のデータソースだけでなく、プライベートエンドポイント背後のデータソースにも対応しています。(Microsoft Learn)
スキーマ変更が頻繁な開発・検証環境では、ルールのバインド先となる技術的な列名が変わっていないかも確認してください。表示名だけを見ていると、ルールが古い列名を参照したままになり、スキャン失敗の原因になります。
1資産あたり有効ルール数は200まで
データ品質スキャンでは、1つのデータ資産に対してアクティブにできるデータ品質ルールは最大200個です。200個を超えるルールがONの状態だとスキャンが失敗します。必要に応じて、同じ資産を複数のデータ製品に追加してルールを分散する、または使わないルールをOFFにする運用が必要です。(Microsoft Learn)
「すべての列に欠損、型、形式、重複、一意性を一括で付ける」と、すぐに上限へ近づきます。ルールは網羅性よりも、業務上の重要列と重要条件に絞る方が実用的です。
スケジュールは30資産単位で考える
データ品質スキャンは手動実行だけでなく、定期実行もできます。ただし、1つのスケジュールには全データ製品をまたいで30資産を超えて追加できません。大量のデータ資産を監視する場合は、30資産単位で複数スケジュールを作る設計が必要です。(Microsoft Learn)
また、資産レベルでは週次スキャンの自動スケジュールが既定で有効になると説明されています。不要なスキャンが課金や運用ノイズにつながる場合は、対象資産ごとに無効化するか、明示的なスケジュールへ整理してください。(Microsoft Learn)
課金はDGPUと管理対象資産を意識する
Microsoft Purview Data Governanceでは、Unified Catalogの管理対象資産数と、データ品質・データヘルス管理の処理に使うDGPUが課金に関係します。Data Qualityの使用量はDGPUの従量課金メーターに基づいて課金され、データ量、ルール種類、ソース種別などで消費量が変わります。(Microsoft Learn)
ジョブ監視画面では、完了したデータ資産ジョブの詳細から消費処理単位を確認できます。コストを抑えるには、初期導入時に全社一括展開するのではなく、重要データ資産でルール設計とスキャン頻度を検証し、消費量を見ながら範囲を広げるのが安全です。(Microsoft Learn)
管理者と開発者の確認チェックリスト
Data Quality in Microsoft Purview Unified Catalogを本番展開する前に、以下を確認してください。
| 確認項目 | 管理者の対応 | 開発者・データ担当の対応 |
|---|---|---|
| 利用リージョン | Unified Catalogが対象リージョンで使えるか確認 | データ所在地とスキャン対象を整理 |
| 権限 | Data Quality Steward、Reader、Domain Ownerを割り当て | 必要なデータソース権限を申請 |
| 接続 | マネージドID、VNet、プライベートエンドポイントを確認 | 接続テストではなく実ジョブで検証 |
| スキーマ | スキーマ変更時のImport schema手順を決める | 列名・型変更の影響を事前共有 |
| ルール | 1資産200ルール上限を考慮 | 重要列からルールを設計 |
| スキャン | 手動、定期、増分、フルの使い分けを決める | 日時列が増分スキャンに使えるか確認 |
| しきい値 | 業務重要度に応じて基準を設定 | 80点一律ではなく用途別に定義 |
| アラート | 配布グループや運用窓口を設定 | 通知後の修正フローを決める |
| 課金 | DGPU消費とスケジュールを監視 | 大量データ・複雑ルールは事前検証 |
| 移行 | スタンドアロン資産からデータ製品への流れを設計 | 品質スコアを見て製品化可否を判断 |
まず何から始めるべきか
最初にやるべきことは、Microsoft Purview上のすべてのデータにルールを付けることではありません。まずは、業務影響が大きく、品質問題が起きると被害が分かりやすいデータ資産を3〜5個選びます。次に、Data Quality Stewardを割り当て、データソース接続を作成し、プロファイリングを実行します。その結果を見て、必須列、重複してはいけない列、形式が重要な列、鮮度が重要なテーブルを決めます。
その後、標準ルールで評価を始め、必要に応じてカスタムルールやSQL式を追加します。運用が安定したら、しきい値、アラート、増分スキャン、定期スキャンを設定し、データ品質アクションを担当者へ割り当てる流れに移行します。
Data Quality in Microsoft Purview Unified Catalogは、カタログを「探すための場所」から「信頼できるデータを判断する場所」へ進化させる機能です。管理者は権限、接続、ネットワーク、課金を整え、データ担当者は業務に即したルールとしきい値を設計することで、AIやBIで使うデータの信頼性を継続的に高められます。
コメント