MENU

Microsoft Purview 統合ガバナンスのCI/CD実践ガイド：Unified Catalog/Data MapのREST APIで非本番→本番へ昇格する方法

Azure

Microsoft Purview（統合ガバナンス）で、非本番環境で整備した用語集・ドメイン・CDE/OKRなどの“ガバナンス資産”を本番へCI/CDで昇格したい――しかしPurviewは「データソース依存」や「APIの提供範囲」の都合で、他サービスのような“丸ごとデプロイ”が難しい領域があります。本記事では、現時点で自動化できる範囲と公式APIの所在、実務で破綻しない部分CI/CDの作り方を整理します。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Microsoft Purviewで「非本番→本番」CI/CDが難しく見える理由

最初に押さえておきたいのは、Purviewの“本質”が「メタデータの収集・管理」と「ガバナンス運用の加速」にある点です。アプリコードのように“同一成果物を上位環境へそのまま配置”する世界ではなく、スキャン結果や資産の識別子がデータソースや構成に強く依存します。そのため、非本番で見えていたテーブルや列の構造・IDを、そのまま本番へコピーする前提が崩れやすいのが最大の罠です。

加えて、Purviewはポータル体験が「Classic（旧）」「新しいMicrosoft Purviewポータル（統合）」へ移行しており、機能が段階的に統合されてきました。Classicは“サポートモード”で、新機能は新ポータル側に寄っていく流れです。つまり「できること」と「APIの整備状況」が、時期と体験（Classic / 新ポータル）で変わりやすい点も、CI/CD設計をややこしくしています。

まず整理：Purviewの“どこ”をCI/CDしたいのか（Data Map と Unified Catalog）

Microsoft Purviewのデータガバナンスは、大きく2層で理解すると設計が一気に楽になります。

層役割代表的な対象CI/CD観点のポイント
Data Mapスキャンで技術メタデータを収集し、資産を“台帳化”する基盤データソース登録、スキャン、分類、リネージ、資産（entity）メタデータスキャンは環境差分が出るので「設定の自動化」と「再スキャン」が基本
Unified Catalogビジネス文脈でのガバナンス運用（データプロダクト、CDE、OKRなど）Governance domains、Glossary terms（統合）、Data products、CDE、OKR、アクセス要求/ポリシー等APIは拡充中だが“環境昇格の公式機能”は別途組み立てが必要

Data Mapはスキャンで集まる“技術メタデータの土台”で、Unified Catalogはそれを使って“ビジネス向けに意味付けし、アクセス・品質・価値を運用する層”です。Unified CatalogはSaaS体験として提供されることが明記されています。

また、Classicのデータガバナンス機能（Classic Data Catalogなど）は新規利用が推奨されない状態になっています。CI/CDをこれから作り込むなら「Classicで何を維持し、Unified側へどう寄せるか」を先に決めるのが現実的です。

「環境分離」の現実：複数アカウントを作れないケースが増えている

非本番→本番のCI/CDを語る前に、そもそもPurviewを“環境として分けられるのか”を確認する必要があります。新しいMicrosoft Purviewポータル体験は、組織（テナント）単位で単一のプライマリインスタンスとして提供される、という前提がFAQで説明されています。さらに、初回作成時期など条件によっては新規に複数アカウントを作れないケースがあるため、従来の「Dev Purview / Prod Purview」をそのまま作れないことがあります。

この制約があると、環境昇格（Non-Prod → Prod）を“別アカウント間コピー”として実現するのが難しくなります。代替として、同一インスタンスの中で「Domains / Collections」で分離する設計が主流になります。

（重要）「Domain」という言葉が2種類あるので混同しない

Purviewのドキュメントには“ドメイン”が複数の意味で登場します。CI/CDを組むときは、どちらのDomainを扱っているかを必ず区別してください。

名称どこにある概念か用途CI/CDへの影響
Data Map の DomainsData Map の基盤構造（collectionsの上位概念として登場）組織/チームやライフサイクル（dev/test/prod）などの分離“環境分離”の現実解になりやすい。APIで作成・管理する前提の設計が組める
Unified Catalog の Governance domainsUnified Catalog の運用単位（ビジネス文脈）データの意味づけ・ガバナンス適用（用語、CDE、プロダクト等の所属）“ビジネス整理”の単位。環境分離目的で使うと運用が歪みやすい

Data MapのDomainsは「スキャンや管理境界」に関わり、ドキュメントでも“dev/test/prodのようなライフサイクル分離”に使えることが示唆されています。一方、Governance domainsはUnified Catalogの中で“ビジネス上の分類単位”として使います。

CI/CDで自動化できる範囲（できる／できない／注意が必要）

「全部を丸ごと昇格」は難しくても、“APIがあるところ”はスクリプト＋パイプラインでかなり自動化できます。現場での仕分けに使えるよう、対象をコンポーネント別に整理します。

コンポーネント自動化可否主に使うAPI/手段注意点
データソース登録条件付きで可能Scanning Data Plane（Data sources）接続情報（資格情報・ネットワーク）は環境依存。秘密情報の管理設計が必要
スキャン定義（ルールセット、スケジュール、トリガー）可能Scanning Data Plane（Scans/Triggers）“結果”はコピーせず、各環境で実行して台帳を作る
資産の説明（Description）、表示名、カスタム属性など可能Data Map Data Plane（Entity Create/Update、GraphQLも選択肢）ID（GUID）よりも安定キー（qualifiedName等）で突合する設計が重要
Classic Glossary（用語集/用語/カテゴリ）可能Data Map Data Plane（Glossary API）＋CSV Import/Export用語の親子関係や承認WFなど、差分反映の制約を理解しておく
Unified Catalog の Glossary terms / Data products / CDE / OKR / Business domains一部可能（プレビューを含む）Unified Catalog API（Public Preview）/ Purview Data Governance RESTGA範囲中心。プレビュー機能はAPI未提供のことがある
Enterprise Glossary（プレビュー機能）現時点で制約あり（公式には未整備の部分が残る）Classic APIで取得できないケースが報告されている
RBAC（コレクション権限、メタデータポリシー）可能Metadata policy data plane最小権限・役割設計を先に固め、冪等に適用できる形へ

補足として、Purviewは“DevOps/Gitリポジトリ連携でボタン一つ昇格”のようなネイティブCI/CDを提供していない、という趣旨の回答がMicrosoft Q&Aでも繰り返し説明されています。そのため、現実解は「APIでできるところを部分的に自動化して、昇格フローを自分で組む」です。

公式API仕様（ドキュメント）の所在まとめ

「どこを見ればよいか」が一番迷子になりやすいので、まず“公式の入口”をまとめます。WordPress貼り付け用に、URLはコード形式で記載します。

  • Microsoft Purview REST API（総合入口） https://learn.microsoft.com/en-us/rest/api/purview/
  • Data Map（資産メタデータ/Atlas系）: Entity（説明や属性の更新に必須） https://learn.microsoft.com/en-us/rest/api/purview/datamapdataplane/entity/create-or-update?view=rest-purview-datamapdataplane-2023-09-01
  • Data Map（Classic Glossary含む）: Glossary API https://learn.microsoft.com/en-us/rest/api/purview/datamapdataplane/glossary?view=rest-purview-datamapdataplane-2023-09-01
  • Scanning Data Plane（データソース登録・スキャン定義） https://learn.microsoft.com/en-us/rest/api/purview/scanningdataplane/data-sources?view=rest-purview-scanningdataplane-2023-09-01
  • Metadata Policy Data Plane（コレクション権限・メタデータポリシー） https://learn.microsoft.com/en-us/rest/api/purview/metadatapolicydataplane/metadata-policy?view=rest-purview-metadatapolicydataplane-2021-07-01-preview
  • API認証（データプレーン共通） https://learn.microsoft.com/en-us/purview/data-gov-api-rest-data-plane
  • Unified Catalog API（Public Preview）概要 https://learn.microsoft.com/en-us/rest/api/purview/unified-catalog-api-overview
  • Purview Data Governance（Unified Catalogのカタログ運用系REST） https://learn.microsoft.com/en-us/rest/api/purview/purviewdatagovernance/operation-groups?view=rest-purview-purviewdatagovernance-2025-09-15-preview
  • GraphQL API（Data Map向け・一括取得や差分比較で便利だがプレビュー） https://learn.microsoft.com/en-us/purview/data-gov-api-graphql
  • 新しいMicrosoft PurviewポータルのFAQ（新旧ポータル/エンドポイント/アカウント制約） https://learn.microsoft.com/en-us/purview/data-governance-purview-portal-faq

Unified Catalog API（Public Preview）は、OKR、Business domains、CDE、Data products、Glossary terms、Data access policiesなどのAPI提供が示され、ただし“GA機能のみ対象”で、Data Asset/ Critical Data Column系はロードマップ、といった但し書きが入っています。CI/CDで「Unified側も自動化したい」場合は、このページを“最初の基準点”にするのが最短です。

環境間デプロイの最短ルート：Purviewを「Metadata as Code」に寄せる

PurviewのCI/CDは、アプリのデプロイというより「ガバナンス定義をコード（JSON/YAML）として管理し、APIで冪等に適用する」アプローチがうまくいきます。ポイントは“スキャン結果をコピーしない”ことです。環境が変わればデータソースも変わるため、スキャンは各環境で実行し直し、その上に“人が付けた意味”を再適用します。

推奨アーキテクチャ（運用が破綻しにくい構成）

レイヤー管理対象管理方法パイプラインでの扱い
インフラ/基盤ネットワーク、ID、Key Vault、プライベートエンドポイント等Bicep/TerraformなどIaC最初に適用（ここが不安定だと以降が全部止まる）
Data Map設定Domains/Collections、データソース、スキャン、トリガーREST（Scanning/Data Map）“設定”を適用 → 各環境でスキャン実行
カタログの人手メタデータDescription、Owner、カスタム属性、分類、タグ、用語付与REST/GraphQL（Data Map）スキャン後に上書き（Upsert）
Unified運用定義Governance domains、Glossary terms、Data products、CDE、OKR等Unified Catalog API / PurviewDataGovernanceAPI対応範囲から段階的に自動化（未対応は手順化）

“最短ルート”は、やれる範囲を明確に分割し、手動が残る部分は最初からチェックリスト化して事故を防ぐことです。Purviewは権限や境界（コレクション/ドメイン）が絡むので、いきなり全部自動化より、段階的に「壊れない昇格」を作る方が成功します。

リポジトリ設計例（そのまま真似できる形）

purview-metadata/
  env/
    nonprod/
      scanning/
      datamap/
      unified/
    prod/
      scanning/
      datamap/
      unified/
  scripts/
    export/
    deploy/
    diff/
  pipelines/
    azure-pipelines.yml
    github-actions.yml

ここでのコツは、「非本番からExportしたものをそのままProdへImport」ではなく、Prod用の“望ましい状態（Desired State）”をリポジトリに置くことです。非本番は実験場で、Prodへ出すものはレビュー済みの定義――この線引きができると、CI/CDの品質が一段上がります。

APIで“触れる領域”を具体化：どのAPIで何をUpsertするか

資産の説明（Description）や属性の更新：Data Map Entity API

「説明を付けた」「オーナーを付けた」「表示名を整えた」といったメタデータは、Data Map側のEntity更新で扱いやすい領域です。EntityのCreate/Update APIは、GUIDや一意属性（例：qualifiedName）を使った更新が可能で、CI/CDでは“冪等（何度当てても同じ状態になる）”を作りやすいのが利点です。

実務の鉄則：ID（GUID）前提で作らないこと。環境が変わるとGUIDが変わります。代わりに、以下のような“安定キー”で突合し、Upsertする設計に寄せます。

  • qualifiedName（ただし、サーバー名やDB名が環境で変わるなら変換ルールが必要）
  • （可能なら）自社で付ける管理用カスタム属性（例：assetCode、systemIdなど）
  • 検索 → 1件に特定 → 更新、の二段階（GraphQLを併用すると取り回しが良い）

GraphQL APIは、関連情報（分類/用語/関連資産など）を1回のクエリで引けるため、Exportや差分比較に向きます。ただしプレビューなので、運用に入れるなら「RESTが正、GraphQLは補助」の位置づけが無難です。

Classic Glossary：Data Map Glossary API（＋CSV Import/Export）

Classic Glossaryは、Data MapのGlossary APIで操作できます。APIリファレンスには、用語作成、カテゴリ作成、用語の資産割り当てなどの操作がまとまっています。

運用的に“丸ごと移す”が必要なら、CSVによるImport/Exportも選択肢です。特に初期移行や大量投入ではCSVが楽な場面があります。一方で、差分適用や親子関係の更新などに制約があるので、長期運用はAPIベースのUpsertに寄せる方がCI/CDとしては強くなります。

スキャン/データソース登録：Scanning Data Plane API

「スキャンやデータソース登録は手動」と思われがちですが、Scanning Data Planeにはデータソースやスキャンを作成/更新するAPIが用意されています。したがって、“設定としてのスキャン”はコード化できます。

ただし、ここでいう“手動が残る”のは、資格情報・ネットワーク・実行権限（MIやIR、接続先FWなど）が環境ごとに違うからです。スキャン設定だけ流し込んでも、接続できなければ意味がありません。CI/CDでは次の分離が効きます。

  • パイプライン：データソース/スキャン定義を作成（API）
  • 環境固有：秘密情報（Key Vault）、ネットワーク許可、MI付与、実行前提条件
  • 実行：スキャンを起動し、結果は各環境で生成する

RBAC（コレクション権限）：Metadata policy data plane

Purviewの自動化は「権限で詰まる」ことが多いので、RBACもコード化した方が運用が安定します。Metadata policy data plane APIは、コレクションに対するメタデータポリシーを扱うためのAPIが公開されています。

また、APIを叩くサービスプリンシパルにどのデータプレーン権限が必要かは、公式チュートリアルで整理されています。Data Curator（Catalog）、Data Source Administrator（Scanning）、Collection Admin（Account/Metadata policy）、Policy Author（DevOps policies）など、役割ごとに必要権限が異なる点は必ず踏まえてください。

Unified（統合ポータル）固有コンポーネント：APIは“出てきた”が、CI/CDは自前で組む

以前は「Unified側は公式APIがない」と整理されがちでしたが、現在はUnified Catalog API（Public Preview）やPurview Data Governance REST（プレビュー）が整備され、OKR・Business domains・CDE・Data products・Terms・Policiesなどの操作グループが参照できる状態になっています。

一方で、ここが最重要ポイントです。

  • “環境昇格（Non-Prod → Prod）”という公式のデプロイ機能（例：差分比較→承認→昇格）が提供されているわけではありません。
  • UnifiedのAPIはプレビューを含み、GA機能に限定される・未提供領域が残る、といった前提があります。

つまり、Unified側の要素も含めて自動昇格をやりたいなら、Data Mapと同じく「Export → JSON管理 → Upsert」を自前で作るのが現実解です。

Enterprise Glossary（プレビュー）の扱いは要注意

用語集まわりは、Classic GlossaryとUnified/Enterprise Glossaryが混在しやすい領域です。Microsoft Q&Aでは、Atlas（Classic）APIで取得できるのはClassic Glossary中心で、新しいEnterprise Glossary（プレビュー）はAPIでアクセスできない（少なくともドキュメントが整っていない）という趣旨の回答が出ています。APIベースのCI/CDを本番運用するなら、まず「どの用語機能を使うか」を固定し、混在させないのが安全です。

実装テンプレ：Non-Prod → Prod “昇格”パイプラインの作り方

ここからは、Azure DevOps/GitHub Actionsのどちらでも組める“考え方のテンプレ”を提示します。Purviewに最適化されたCI/CDは、だいたい次の4段階に収束します。

段階目的実施内容成功のコツ
Export非本番の定義を取得APIで取得（Data Map / Unified）しJSON化Exportは“参考”、最終成果物はリポジトリ上のDesired State
Normalize環境差分を吸収名前変換・URL差し替え・属性の絞り込み変換ルールをコード化（例：nonprod→prodの正規表現）
Deploy（Upsert）本番へ冪等に反映存在確認→作成/更新（Upsert）“名前ベース突合”と“1件に特定できない時は失敗”を徹底
Verify品質担保サンプル資産で説明/用語付与の確認、スキャン結果確認手戻りが大きい箇所は自動テスト（APIで読み戻して検証）

最小のパイプライン例（概念）

stages:
- stage: Validate
  jobs:
  - job: Lint
    steps:
    - checkout: self
    - script: python scripts/diff/validate_schema.py env/prod

* stage: Deploy
  jobs:

  * job: PurviewDeploy
    steps:

    * checkout: self
    * script: |
      python scripts/deploy/apply_scanning.py env/prod/scanning
      python scripts/deploy/apply_datamap_metadata.py env/prod/datamap
      python scripts/deploy/apply_unified_catalog.py env/prod/unified

PurviewのCI/CDで効く実務ルールを、もう少し踏み込みます。

  • Upsertの単位を小さく：GlossaryもCDEも、巨大一括投入より小分けにして失敗地点を特定できるようにします（API側でも小バッチ推奨の記載があります）。
  • 突合キーは“名前＋所属”：用語なら「domain + termName」、CDEなら「domain + CDE名」など、運用上ユニークになるキーを決め、重複時は失敗させます。
  • 人間の承認ゲートを残す：ガバナンス定義は“仕様”です。データアクセスや統制に直結するため、PRレビュー＋承認（もしくはリリース承認）を挟む方が事故が減ります。

「手動が残る領域」を最初から設計に組み込む

Purviewの昇格で“最後に残る手動”は、たいてい次のカテゴリに集約されます。ここを最初から割り切ることで、運用の再現性が上がります。

手動になりやすい領域なぜ自動化しづらいか現実的な落としどころ
接続資格情報（パスワード/キー/証明書）秘密情報は環境で別物Key Vault運用＋パイプラインには参照のみ持たせる
ネットワーク（FW許可、Private Endpoint、DNS）インフラの都合が環境で違うIaCの責務に切り出し、Purviewの昇格対象から外す
初回スキャン結果の品質ソースの状態次第で結果が変わるスキャン後の検証チェック（件数・重要資産の存在）を標準化
プレビュー機能（Enterprise Glossary等）APIが未整備/変更リスク本番CI/CDではGA機能中心にし、プレビューは手順化

特に新ポータルは、Classicポータルと併存しながら移行が進む構造です。両方のポータルでスキャン/キュレーションした内容が相互に見えることはFAQで説明されていますが、運用手順としては“どの画面で何を管理するか”を決めてブレを減らすのが重要です。

最後に：PurviewのCI/CDは「全部自動」ではなく「壊れない昇格」を狙う

Microsoft Purview（統合ガバナンス）で非本番→本番のCI/CDを実現するコツは、次の3点に集約されます。

  • スキャン結果はコピーせず、各環境で再生成：CI/CD対象は“スキャン設定＋人手メタデータ”に寄せる。
  • APIがあるところから段階的に自動化：Data Map（Entity/Glossary）、Scanning、Metadata policyは実装しやすい。Unified側もAPIは整ってきたが、プレビュー前提で設計する。
  • “環境分離”そのものを再検討：新ポータルは単一インスタンス前提が強く、複数アカウントが作れない/使えないケースがある。Domain/Collectionでの分離を軸に設計した方が長期運用で詰まりにくい。

「ネイティブCI/CDがないから無理」と結論づけるより、Purviewの特性に合わせて“Metadata as Code”を組み、Upsertできる範囲を確実に自動化する――この路線が、最も実務的で再現性の高いアプローチです。

Azure
CI/CD REST API Microsoft Purview Unified Catalog Data Map

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次