Microsoft Purview Data Governanceの課金で最初に確認すべきことは、Unified Catalogは「管理対象にした資産数」と「データ品質・ヘルス管理の処理量」で課金されるという点です。2026年4月24日に更新されたMicrosoft公式ドキュメント「Billing in Microsoft Purview Data Governance」では、Unified Catalog、Data Map、DGPU、スキャン課金の扱いが整理されており、security admins、identity teams、compliance teamsが予算管理や利用統制を見直すうえで重要な内容になっています。(Microsoft Learn)
特に注意したいのは、Data Mapに資産をスキャンしただけでは必ずしも課金対象にならない一方、データプロダクトや重要データ要素などのガバナンス概念に紐づけた資産は「governed assets」として日次でカウントされることです。この記事では、2026年4月更新時点の公式情報をもとに、何が課金対象になるのか、どこでコストが増えやすいのか、運用チームが今すぐ確認すべきポイントを実務目線で整理します。
Microsoft Purviewの最新動向: Billing in Microsoft Purview Data Governanceで何が変わったか
Microsoft Purview Data Governanceの課金は、従来の「データカタログを作るための技術基盤」だけを見る発想から、実際にガバナンス対象として管理・活用する資産に対して課金を把握する発想へ移っています。
2026年4月24日更新の公式ドキュメントでは、Microsoft Purview Data Governanceの対象として、主に次の2つが説明されています。
| 項目 | 役割 | 課金上の見方 |
|---|---|---|
| Microsoft Purview Unified Catalog | データプロダクト、重要データ要素、用語、データ品質などを使ってデータを管理する領域 | 管理対象になった一意の資産数、DGPU消費量を見る |
| Microsoft Purview Data Map | データ資産の検出、メタデータ収集、基盤マップとして機能する領域 | 一定条件を満たす場合、Unified Catalog利用者にはData Mapやスキャン課金が適用されない |
公式ドキュメントでは、Unified Catalogの課金は大きく2つのメーターで構成されると説明されています。1つ目は1日あたりの一意のgoverned assets数、2つ目はData health managementなどで消費するData Governance Processing Unit（DGPU）です。(Microsoft Learn)
ここで重要なのは、「Microsoft Purviewに登録されている資産数」そのものではなく、Unified Catalog上でガバナンス概念に関連付けた資産が課金判断の中心になるという点です。セキュリティ管理者やコンプライアンス担当者は、単にスキャン対象を減らすのではなく、「どの資産を正式な管理対象にするか」を設計する必要があります。
2026年4月更新で押さえるべき要点
今回の公式情報から、実務担当者が優先して確認すべきポイントは次の5つです。
| 確認ポイント | 実務上の意味 |
|---|---|
| Pay-as-you-go課金が前提 | Azureサブスクリプションとリソースグループの準備が必要 |
| governed assetsは日次でカウント | 月末だけでなく日々の管理対象数がコストに影響する |
| Data Mapにあるだけでは課金対象とは限らない | スキャン済み資産とガバナンス対象資産を分けて考える |
| DGPUはデータ品質・ヘルス管理で発生 | ルール数、実行頻度、データ量、ソース種別がコスト要因になる |
| Usage monitoringで部門別把握が可能 | ガバナンスドメイン別の利用状況を確認し、チャージバック設計に使える |
Microsoft PurviewのPay-as-you-goは、Microsoft 365やWindows/macOSエンドポイント向けのユーザーライセンス型課金を置き換えるものではなく、補完するモデルです。Microsoft公式ドキュメントでは、Pay-as-you-goは非Microsoft 365データソースや一部機能に対して利用量ベースで課金されるモデルとして説明されています。(Microsoft Learn)
つまり、Microsoft 365 E5などのライセンスを持っている企業でも、Azure SQL、AWS、Google Drive、Microsoft Fabricなどの外部・非Microsoft 365領域にMicrosoft Purviewの保護やガバナンスを拡張する場合は、Pay-as-you-goの課金確認が必要です。
課金開始前に必要な前提条件
Microsoft Purview Data GovernanceのPay-as-you-goを利用するには、Microsoft Purviewと同じテナント内にあるAzureサブスクリプションと、そのサブスクリプション内のAzureリソースグループが必要です。公式ドキュメントでは、既存のサブスクリプションやリソースグループがある場合は、それをMicrosoft Purviewでも利用できると説明されています。(Microsoft Learn)
新規のData Governance利用者がPay-as-you-go機能を有効化する場合、Microsoft 365テナントをAzureサブスクリプションに関連付けます。Microsoft公式の有効化手順では、Global Administratorロールを持つアカウントのみがPay-as-you-goモデルを有効化できるとされています。(Microsoft Learn)
管理チーム別に確認すべきこと
| 担当チーム | 確認すべき内容 | 見落としやすい点 |
|---|---|---|
| Security admins | 非Microsoft 365データソースに対する保護・分類・ガバナンスの範囲 | 保護対象を広げるとPay-as-you-go課金が発生する可能性がある |
| Identity teams | 有効化に必要な管理者ロール、テナントとAzureサブスクリプションの関係 | Global Administratorに依存する作業がある |
| Compliance teams | データプロダクト、重要データ要素、用語、データ品質ルールの設計 | ガバナンス概念に紐づけた時点でgoverned assetsとして扱われる可能性がある |
| FinOps / IT管理 | Azure Cost Managementでの請求確認、利用量モニタリング | Microsoft Purviewポータルだけでは実請求の全体像を見落とす場合がある |
実務では、Purview担当者だけで有効化を進めると、あとから「どの部門の利用分なのか」「誰が課金を承認したのか」が曖昧になりがちです。初期設定前に、Azureサブスクリプションの所有部門、コストセンター、タグ付け方針、請求確認担当を決めておくと運用が安定します。
governed assetsとは何か
Microsoft Purview Data Governanceの課金を理解するうえで最も重要な用語が、governed assetsです。
公式ドキュメントでは、Unified Catalogでデータ資産を積極的に管理・キュレーションし、データプロダクト、重要データ要素、用語、データ品質などのガバナンス概念に関連付けることで、その資産がgoverned assetになると説明されています。単にData Mapに収集されているだけで、ガバナンス概念に関連付けられていない技術資産はgoverned assetではありません。(Microsoft Learn)
たとえば、SQL Serverに200個のテーブルがある場合でも、そのうち20個だけをデータプロダクトに紐づけているなら、governed assetsとしてカウントされるのは原則としてその20個です。公式ドキュメントでも、200テーブルすべてではなく、データプロダクトにリンクされた20テーブルが課金対象の考え方になる例が示されています。(Microsoft Learn)
課金対象になる例・ならない例
| 状況 | 課金上の扱い |
|---|---|
| Data Mapにテーブルをスキャンしただけ | governed assetではないため、Unified Catalogのgoverned asset課金対象にはならない |
| テーブルをデータプロダクトに紐づけた | governed assetとしてカウントされる |
| 同じテーブルを複数のデータプロダクトで参照した | 一意の資産として1日1回だけカウントされる |
| データプロダクトだけを作り、テーブルやレポートを紐づけていない | governed assetsは発生しない |
| サーバー全体を誤ってデータプロダクトに紐づけた | サーバーが1つの資産としてカウントされ、配下の全テーブルが自動的に個別カウントされるわけではない |
この考え方は、コスト最適化だけでなく、ガバナンス品質にも関係します。すべての資産を機械的にデータプロダクトへ紐づけると、利用者にとって探しにくいカタログになり、コストも増えます。逆に、重要資産だけを厳選しすぎると、監査やデータ品質管理の対象が不足します。
実務では、次のような基準でgoverned assetsにするかどうかを判断するとよいでしょう。
| 判断基準 | governed assetsに向いている例 |
|---|---|
| 業務上の重要度 | 売上、顧客、契約、請求、従業員、監査対象データ |
| 利用頻度 | 複数部門が定期的に参照するテーブル、レポート、ダッシュボード |
| リスク | 個人情報、機密情報、規制対象データを含む資産 |
| 品質管理の必要性 | 欠損、重複、形式不一致が業務影響を与えるデータ |
| 所有者の明確さ | データオーナーや管理部門が決まっている資産 |
Data Mapとスキャン課金の扱い
2026年4月更新ポイントとして、Data Mapとスキャン課金の扱いも見逃せません。
公式ドキュメントでは、Unified Catalogは既存のData Map上で動作しており、Unified Catalog利用者がMicrosoft Purviewの課金モデルに同意する、または無料版からEnterprise tierへアップグレードすると、Data Mapおよびスキャン課金はUnified Catalog利用者には適用されないと説明されています。(Microsoft Learn)
これは、セキュリティ管理者にとって大きな意味があります。データ資産の可視化を進めるためにData Mapへスキャンすることと、Unified Catalogで正式なgoverned assetsとして管理することを分けて考えられるためです。
ただし、「スキャンは気にしなくてよい」と短絡的に捉えるのは危険です。スキャン範囲が広すぎると、メタデータ管理、アクセス権確認、所有者整理、データ分類の運用負荷が増えます。コストだけでなく、管理可能な範囲かどうかを見ながら設計する必要があります。
スキャン設計で失敗しやすいパターン
| 失敗パターン | 起きる問題 | 対策 |
|---|---|---|
| 最初から全データソースをスキャンする | 所有者不明の資産が大量に出て、整理が追いつかない | 重要な業務領域から段階的に開始する |
| governed assetsの基準を決めない | 何を正式管理対象にしたか説明できない | データプロダクト化の基準を文書化する |
| 部門ごとの責任者を決めない | カタログは増えるが品質改善が進まない | ガバナンスドメイン単位でオーナーを置く |
| 請求確認をAzure管理者だけに任せる | Complianceチームが利用量を把握できない | Purview管理者とAzure請求管理者で定例確認する |
DGPUとは何か
Microsoft Purview Data Governanceでは、データ品質やデータヘルス管理の実行に応じて、Data Governance Processing Unit（DGPU）が消費されます。
公式ドキュメントでは、DGPUはデータ品質やデータヘルス管理などのコンピュートを必要とする機能を実行する、フルマネージドのコンピュート単位と説明されています。1 DGPUは60分のコンピュート時間に相当し、Basic、Standard、Advancedの3つの性能オプションがあります。Basicが既定の性能オプションです。(Microsoft Learn)
DGPU消費量は、主に次の要素で変わります。
| 要素 | コストに影響する理由 |
|---|---|
| ルールの種類 | 空白チェックのような単純なルールと、複数列の重複チェックや参照テーブル照合では処理負荷が異なる |
| データ量 | レコード数が増えるほど処理時間や処理単位が増える可能性がある |
| データソースの種類 | 同じデータ量でもソース種別によってDGPU生成量が異なる可能性がある |
| 実行頻度 | 日次、時間単位、手動実行などの頻度が累積コストに直結する |
| SKU選択 | Basic、Standard、Advancedの性能オプションにより単価や処理能力が変わる |
たとえば、データ品質ジョブを1日に100回実行し、各実行が0.02 DGPUを消費する場合、その日の合計消費量は2 DGPUになります。公式ドキュメントでも、このような計算例が示されています。(Microsoft Learn)
Data health managementのコストを抑える考え方
Data health controls、セルフサービス分析、Health management内のレポートはBasic SKUを使用すると説明されています。公式ドキュメントでは、コントロールジョブは初期プロビジョニング時に日次実行としてスケジュールされ、少なくとも1つのbusiness domainが存在する場合に実行されるとされています。不要なコントロールは非アクティブ化でき、スケジュールも調整できます。(Microsoft Learn)
この仕様を踏まえると、コスト最適化の基本は「使わない機能を止める」だけではありません。どのデータ品質・ヘルス指標を、どの頻度で、どの部門責任で更新するかを決めることが重要です。
実務で使いやすいDGPU最適化の手順
| 手順 | 実施内容 |
|---|---|
| 対象資産を絞る | まずは重要なデータプロダクトや監査対象データに限定する |
| ルールを分類する | 空白チェック、形式チェック、重複チェック、参照テーブル照合などに分ける |
| 実行頻度を決める | 毎日必要なルールと週次・月次で十分なルールを分ける |
| 初回実行後に消費量を見る | Usage monitoringやAzure Cost Managementで想定との差を確認する |
| 不要なコントロールを停止する | 利用されていないヘルスコントロールや重複ルールを無効化する |
| 部門別に説明できる形にする | ガバナンスドメイン単位で利用量を見て、チャージバックに備える |
データ品質ルールは「増やすほど安心」ではありません。実行されても誰も確認しないルール、アラートが出ても改善責任者がいないルールは、コストだけでなく運用品質も悪化させます。
Usage monitoringで見るべき指標
Microsoft PurviewのData Governance Administrator向けには、Unified CatalogのUsage monitoringが提供されています。公式ドキュメントでは、Usage monitoringはgoverned assetsとDGPU消費量をガバナンスドメイン別に把握し、組織内のチャージバックモデル作成にも使える管理者向けビューと説明されています。(Microsoft Learn)
ただし、Usage monitoringは実際の請求書そのものではありません。公式ドキュメントでは、実際の請求はMicrosoft Azureポータルで確認すると説明されています。(Microsoft Learn)
運用では、次のように役割を分けると混乱を避けやすくなります。
| 確認場所 | 主な用途 |
|---|---|
| Microsoft Purview Usage monitoring | ガバナンスドメイン別のgoverned assets、DGPU消費傾向を見る |
| Azure Cost Management + Billing | サブスクリプションに紐づく実請求、予算、アラートを確認する |
| Microsoft Purviewのデータプロダクト管理画面 | どの資産がどのガバナンス概念に紐づいているか確認する |
| データ品質ジョブ管理画面 | ルール、実行頻度、失敗状況、処理負荷を確認する |
特にグローバル企業では、地域、事業部、データドメインごとにコスト配賦が必要になることがあります。Usage monitoringで部門別の利用状況を確認し、Azure側の請求情報と照合する運用を作っておくと、予算超過の説明がしやすくなります。
セキュリティ・ID・コンプライアンス担当者が確認すべき実務チェックリスト
Microsoft Purview Data Governanceの課金は、IT部門だけの問題ではありません。データを保護するsecurity admins、権限とテナントを管理するidentity teams、規制対応や監査を担うcompliance teamsが、それぞれの観点で確認する必要があります。
Security admins向けチェック
| 確認項目 | 判断ポイント |
|---|---|
| 重要データソースの一覧 | Azure SQL、Microsoft Fabric、AWS、Google Driveなど、対象範囲を明確にする |
| スキャン範囲 | 可視化したい範囲と、実際に管理する範囲を分ける |
| データ分類 | 機密情報や個人情報を含む資産を優先的に管理する |
| データ品質ルール | セキュリティ上重要な欠損、重複、形式不一致を優先する |
| 利用量監視 | DGPU消費量が急増していないか定期確認する |
Identity teams向けチェック
| 確認項目 | 判断ポイント |
|---|---|
| Global Administratorの関与 | Pay-as-you-go有効化に必要な権限を確認する |
| Azureサブスクリプション | Microsoft Purviewと同じテナント内で利用できるか確認する |
| リソースグループ | 請求・管理単位として適切な名前と責任者を設定する |
| Data Governance Administrator | Unified Catalogの設定・利用量確認を担う担当者を決める |
| 権限の棚卸し | Purview管理者、データオーナー、閲覧者の権限を分離する |
Compliance teams向けチェック
| 確認項目 | 判断ポイント |
|---|---|
| governed assetsの基準 | 監査・規制・業務影響をもとに対象資産を定義する |
| データプロダクト設計 | 利用者が理解できる単位でデータ資産を束ねる |
| 重要データ要素 | KPI、規制報告、顧客情報など重要項目を明確化する |
| 用語集・データ品質 | 用語定義と品質ルールをセットで管理する |
| 証跡 | 誰が何をgoverned assetにしたか説明できる状態にする |
コストが増えやすい運用パターン
Microsoft Purview Data Governanceの課金で失敗しやすいのは、価格表の見落としよりも、運用設計の曖昧さです。
すべてのテーブルをデータプロダクトに入れてしまう
データプロダクトは、利用者にとって意味のある業務単位で設計すべきです。データベース内の全テーブルを機械的に紐づけると、governed assetsが増えるだけでなく、利用者が必要なデータを見つけにくくなります。
おすすめは、最初に「Goldレイヤー」「公式レポート」「監査対象データ」「主要KPIに関係するテーブル」などに絞ることです。
データ品質ルールを細かく作りすぎる
空白チェック、形式チェック、重複チェック、参照整合性チェックをすべての列に設定すると、DGPU消費量が増える可能性があります。重要なのは、業務リスクが高い列から優先することです。
たとえば、顧客ID、請求金額、契約開始日、国・地域コード、メールアドレスなど、誤りが下流業務に影響する項目を先に管理すると効果が出やすくなります。
スケジュール実行を見直さない
初期設定のまま日次実行を続けると、利用されていないコントロールやルールでもコストが積み上がります。公式ドキュメントでは、スケジュール調整や個別コントロールの非アクティブ化により、DGPU消費を管理できると説明されています。(Microsoft Learn)
日次で見るべきもの、週次で十分なもの、月次でよいものを分けるだけでも、運用負荷とコストを抑えられます。
実請求と利用量ビューを混同する
Usage monitoringは利用状況を把握するために便利ですが、実際の請求確認はAzureポータル側で行います。Microsoft公式FAQでも、コストはMicrosoft Purviewテナントに紐づいたサブスクリプションのCost Managementで確認でき、Data Governance AdministratorはUsage monitoringレポートも利用できると説明されています。(Microsoft Learn)
そのため、月次レビューでは「Purview上の利用傾向」と「Azure請求」の両方を見る必要があります。
日本を含むグローバル運用での注意点
Unified Catalogは複数リージョンで展開されています。Microsoft公式のリージョン情報では、Japan Eastを含む複数のリージョンでUnified Catalogが利用可能で、Billing start dateが2025年1月6日とされています。一方で、一部リージョンはTBDとして記載されています。(Microsoft Learn)
グローバル企業では、次の点を確認してください。
| 観点 | 確認内容 |
|---|---|
| リージョン | 自社テナント・データ所在地でUnified Catalogが利用可能か |
| 請求開始日 | 対象リージョンで課金がいつから適用されるか |
| データ所在地 | データ主権や規制要件に合うリージョンか |
| 管理者配置 | 各地域のデータオーナー、Purview管理者、請求確認者が決まっているか |
| 言語・用語 | グローバル共通用語と地域固有用語をどう管理するか |
特にコンプライアンスチームは、データガバナンスの対象範囲を「本社の標準」だけで決めるのではなく、地域ごとの規制、データ分類、監査要件を反映させる必要があります。
すぐに実施すべき確認ステップ
Microsoft Purview Data Governanceの2026年4月更新を受けて、既存利用者と新規導入予定者は次の順序で確認すると効率的です。
| ステップ | 実施内容 | 担当 |
|---|---|---|
| 1 | Microsoft PurviewとAzureサブスクリプションの関連付け状況を確認する | Identity / Azure管理者 |
| 2 | Pay-as-you-goの同意・有効化状況を確認する | Global Administrator / Purview管理者 |
| 3 | governed assetsの一覧を確認する | Data Governance Administrator |
| 4 | データプロダクト、重要データ要素、用語、データ品質の紐づけを棚卸しする | Compliance / データオーナー |
| 5 | DGPUを消費するデータ品質・ヘルス管理ジョブを洗い出す | Security / Data Governance |
| 6 | Usage monitoringでドメイン別の利用傾向を見る | Purview管理者 |
| 7 | Azure Cost Managementで実請求と予算アラートを確認する | FinOps / Azure管理者 |
| 8 | 不要なルール、過剰なスケジュール、誤った資産紐づけを修正する | 各データオーナー |
最初にやるべきことは、価格表を細かく読むことではなく、自社で何がgoverned assetになっているかを確認することです。次に、DGPUを消費するジョブの頻度と目的を確認します。この2つを押さえると、課金の大きな要因を説明しやすくなります。
まとめ：Microsoft Purviewの課金は「管理対象の設計」で決まる
Microsoft Purview Data Governanceの2026年4月更新で確認すべきポイントは、Unified Catalogの課金がgoverned assetsの日次カウントとDGPU消費量を中心に整理されていることです。Data Mapに資産をスキャンしただけでは必ずしもUnified Catalogのgoverned asset課金対象にならず、データプロダクト、重要データ要素、用語、データ品質などのガバナンス概念に紐づけた資産が重要になります。
security adminsは、重要データソースとデータ品質ルールの範囲を確認してください。identity teamsは、Pay-as-you-go有効化に必要なAzureサブスクリプション、リソースグループ、管理者ロールを確認する必要があります。compliance teamsは、どの資産を正式な管理対象にするか、監査や規制対応の観点から基準を決めることが重要です。
次に取るべき行動は明確です。まず、現在のgoverned assetsとDGPU消費量を確認し、不要な紐づけや過剰なデータ品質ジョブを見直してください。そのうえで、Azure Cost ManagementとUsage monitoringを組み合わせ、部門別・ドメイン別に説明できる課金管理の仕組みを整えることが、Microsoft Purviewを安全かつ継続的に活用するための第一歩です。
コメント