Classic Microsoft Purview governance portalを調べている管理者が最初に押さえるべき答えは、これは従来のMicrosoft Purviewデータガバナンス向けポータルであり、新規導入で中心に据えるべき画面ではないという点です。Microsoftは、Microsoft Purview Data Catalog（classic）、Data Health Insights（classic）、Purview Workflow（classic）を新規顧客向けに受け付けておらず、これらはサポートモードになっていると説明しています。既存環境ではすぐに使えなくなるわけではありませんが、管理者は新しいMicrosoft Purviewポータルへの移行、アクセス権限、ファイアウォール、プライベートエンドポイント、APIや自動化処理への影響を早めに確認する必要があります。(Microsoft Learn)
Classic Microsoft Purview governance portalとは
Classic Microsoft Purview governance portalは、従来のMicrosoft Purviewデータガバナンス機能を操作するためのポータルです。主にデータカタログ、データ資産の検索、用語集、Data Map、スキャン、コレクション単位のアクセス制御などを扱ってきた画面です。
クラシックポータルには、直接 https://web.purview.azure.com からアクセスする方法と、Azure portalでMicrosoft Purviewアカウントを開いて起動する方法があります。利用には、アクティブなMicrosoft Purviewアカウントと、クラシックポータルにアクセスするための権限が必要です。(Microsoft Learn)
クラシックポータルのホーム画面では、データソース数、資産数、用語集の用語数などのカタログ分析、データ資産検索、ロールに応じたクイックアクセス、最近アクセスした資産、ドキュメントや状態ページへのリンクなどを確認できます。表示される機能は、ルートコレクションで割り当てられているユーザーロールによって変わります。(Microsoft Learn)
つまり、Classic Microsoft Purview governance portalは単なる旧UIではなく、既存のデータカタログ運用、スキャン、メタデータ管理、コレクションベースの権限管理に関わる運用基盤です。そのため、移行時は「画面が変わるだけ」と考えると、権限不足、スキャン失敗、ネットワーク遮断、利用者の混乱が起きやすくなります。
2026年6月時点で押さえるべき変更点
2026年6月時点での重要な流れは、クラシックポータルの機能を維持し続けることではなく、新しいMicrosoft Purviewポータルを前提にした運用へ寄せていくことです。
新しいMicrosoft Purviewポータルは、データガバナンス、データセキュリティ、リスク、コンプライアンスを統合的に扱う入口として提供されています。Microsoftは、新ポータルを単一のエントリーポイントとして、設定、検索、ロールと権限管理を一元化すると説明しています。(Microsoft Learn)
一方で、既存のMicrosoft Purviewアカウントは、移行後もクラシックポータルと新ポータルの両方からアクセスでき、クラシック側でスキャンやキュレーションを続けた場合でも、更新されたメタデータや構成は両方のポータルで表示されるとされています。(Microsoft Learn)
ただし、MicrosoftはすべてのMicrosoft Purview顧客に対して、できるだけ早くアップグレードを開始することを推奨しており、新機能や新しい機能強化は新ポータル側で提供されると説明しています。(Microsoft Learn)
また、2026年6月のMicrosoft Purview更新では、Endpoint DLPのデバイス構成やポリシー同期属性を、Microsoft Purviewポータルからの一時的なエクスポートに頼らず、Microsoft DefenderポータルのAdvanced Huntingで大規模に確認できる更新も示されています。クラシックポータルの直接的な機能追加ではありませんが、Purview関連の監視・調査導線が新しい管理体験へ移っていることを示す実務上重要なサインです。(Microsoft Learn)
影響範囲は管理者・開発者・利用部門にまたがる
Classic Microsoft Purview governance portalの扱いが変わると、影響はポータル利用者だけに留まりません。特に、権限、ネットワーク、API、自動化、教育資料に波及します。
| 対象 | 想定される影響 | 優先して確認すべきこと |
|---|---|---|
| Purview管理者 | 新ポータルへのアップグレード、主アカウント選定、ロール再確認が必要になる | アカウント構成、コレクション、ロール、管理者権限 |
| セキュリティ管理者 | DLPやデータセキュリティ機能の導線が新ポータルやDefender側へ広がる | DLP監視、監査、Advanced Huntingの運用手順 |
| ネットワーク管理者 | 新しいポータルURLやAPIエンドポイントの許可が必要になる | ファイアウォール、プロキシ、DNS、プライベートエンドポイント |
| 開発者・自動化担当 | APIエンドポイントやスクリプト内の固定URLが影響を受ける可能性がある | API呼び出し先、認証、サービスプリンシパル、CI/CD |
| データスチュワード | 画面構成や用語集・データ製品の操作場所が変わる | 新ポータルでの検索、キュレーション、用語集運用 |
| 一般利用者 | 検索画面やデータ資産へのアクセス手順が変わる | 新旧ポータルの使い分け、アクセス不可時の問い合わせ先 |
特に注意すべきなのは、クラシックポータルが残っている間に「まだ移行しなくてよい」と判断してしまうことです。実際には、ネットワーク許可、権限設計、利用者教育、スクリプト修正には時間がかかります。クラシックポータルが使える期間は、移行を先送りするためではなく、影響を検証するための猶予期間と考えるべきです。
管理者が最初に確認すべき設定
アクセス権限はAzure IAMとPurview内ロールを分けて確認する
クラシックポータルのアクセス権限は、Azure IAMだけでは判断できません。直接 https://web.purview.azure.com にアクセスする場合は、Microsoft Purview Data Mapのコレクションに対する少なくともReaderロールが必要です。一方、Azure portal経由でクラシックポータルを開く場合は、Azure側のAccess Control（IAM）でReaderロールが必要です。(Microsoft Learn)
クラシック環境では、コレクションを使ってデータソース、資産、その他の成果物を階層化し、アクセス制御を管理します。Microsoftは、クラシックポータル内のリソースアクセスはData Mapのコレクションで管理されると説明しています。(Microsoft Learn)
| 確認項目 | 実務での見方 |
|---|---|
| Azure IAM Reader | Azure portalからPurviewアカウントを開けるか |
| Collection administrator | コレクションやロール割り当てを管理できるか |
| Data curator | 資産編集、分類、用語集管理、インサイト確認が必要な担当者か |
| Data reader | データ資産を検索・閲覧するだけの利用者か |
| Data source administrator | データソース登録、スキャン、自己ホステッド統合ランタイム、マネージドプライベートエンドポイントを扱う担当者か |
| Policy author | データポリシーの作成・更新・削除に関わる担当者か |
| Workflow administrator | ワークフロー作成や公開に関わる担当者か |
失敗しやすいのは、全員に強い権限を付けて一時的に解決してしまう運用です。移行前こそ、最小権限の原則で「閲覧だけの人」「資産を編集する人」「スキャンを管理する人」「権限を付与する人」を分けて棚卸ししてください。
サービスプリンシパルでMicrosoft Purviewアカウントを作成した場合は、ユーザーにルートコレクションのCollection admin権限を付与しなければ、クラシックポータルにアクセスしてユーザー権限を割り当てられない点にも注意が必要です。(Microsoft Learn)
新ポータル側のロール体系も確認する
新しいMicrosoft Purviewポータルでは、クラシックポータルのコレクション単位の権限だけでなく、テナントまたは組織レベルの権限、Unified Catalog権限、Data Mapのドメイン・コレクションレベルの権限を組み合わせてアクセスを制御します。(Microsoft Learn)
新ポータルでは、Purview Administrators、Data Source Administrators、Data Governanceなどのテナントレベルのロールグループも関係します。管理者は、クラシック側のCollection administratorやData curatorをそのまま移せると考えず、新しいロール体系で誰が何をできるべきかを再設計してください。(Microsoft Learn)
特に、Unified Catalogでは検索結果がユーザーのData Map権限やAzure・Microsoft FabricリソースのRead権限に左右されます。Microsoftは、AzureでRead権限を持つユーザーが、意図しない資産にUnified Catalog上でアクセスできる可能性があるため、不要な権限を削除する必要があると説明しています。(Microsoft Learn)
ファイアウォールとエンドポイントの確認は移行前に必須
Classic Microsoft Purview governance portalを使っている組織では、従来のポータルとエンドポイントだけを許可しているケースがあります。移行後は、新ポータルと新APIエンドポイントへの通信許可が必要です。
| 種類 | 代表的な確認対象 |
|---|---|
| クラシックポータル | web.purview.azure.com |
| クラシックエンドポイント | https://[accountname].purview.azure.com/ |
| 新ポータル | purview.microsoft.com |
| 新APIエンドポイント | api.purview-service.microsoft.com |
Microsoftは、アップグレード前はクラシックポータルのレガシーエンドポイントを使い、アップグレード後はレガシー体験と新しい体験の両方からアクセスできると説明しています。そのうえで、新しい体験を使うには、企業ファイアウォールで新しいポータルとエンドポイントへのアウトバウンド通信を許可する必要があります。(Microsoft Learn)
ネットワーク管理者に依頼するときは、「Purviewの新ポータルを許可してください」だけでは不十分です。プロキシ、SSLインスペクション、DNS、条件付きアクセス、社内ブラウザ制限、VDI環境を含めて確認してください。
プライベートエンドポイント利用環境は特に注意する
Microsoft Purviewアカウントでパブリックネットワークアクセスを無効にし、プライベートエンドポイントを使っている場合は、移行前の確認が重要です。Microsoftは、取り込み用プライベートエンドポイントは継続利用できる一方、新しい体験ではplatform private endpointを使うと説明しています。(Microsoft Learn)
既存のアカウントエンドポイントに対してファイアウォール許可リストを設定している場合は、新しいplatform private endpoint向けに {tenant id}-api.purview-service.microsoft.com や api.purview-service.microsoft.com の設定確認が必要です。Microsoftは、設定の容易さの観点から {tenant id}-api.purview-service.microsoft.com の利用を推奨しています。(Microsoft Learn)
また、platform private endpointへ切り替えた後も、クラシックポータルにアクセスできるユーザー向けに古いエンドポイントは並行稼働します。すでに実行中のスキャンは完了まで既存エンドポイントを使い、新しいスキャンは新しいplatform endpointを使います。(Microsoft Learn)
注意すべきなのは、Azure Data Factory、Azure Machine Learning、Azure Synapseのリネージ接続です。Microsoftは、これらの接続は現在platform private endpointでサポートされておらず、切り替え後に動作しない可能性があると説明しています。(Microsoft Learn)
複数のMicrosoft Purviewアカウントがある場合の判断基準
複数のMicrosoft Purviewアカウントを同じMicrosoft Entraテナント内で使っている場合、新しい体験では単一のテナントレベルまたは組織全体のアカウントが主アカウントになります。Microsoftは、複数アカウントがある場合、1つのアカウントを新しい体験へアップグレードし、他のアカウントをドメインとして統合していく流れを説明しています。(Microsoft Learn)
主アカウントの候補は、次の順で判断すると失敗しにくくなります。
| 判断基準 | 優先する理由 |
|---|---|
| 本番利用されているアカウント | 利用者、スキャン、権限、用語集が最も実運用に近い |
| 利用者数が多いアカウント | 影響範囲を把握しやすく、教育効果も高い |
| 日常業務への依存度が高いアカウント | 移行後の業務停止リスクを下げやすい |
| メタデータ品質が高いアカウント | Unified Catalog移行後の検索・活用に向いている |
| 管理者と所有者が明確なアカウント | 移行時の承認、問い合わせ、権限整理が進めやすい |
Microsoftも、複数アカウントから主アカウントを選ぶ場合は、本番アカウント、エンドユーザーが最も使うアカウント、日常業務上最も重要なアカウントを選ぶことを提案しています。(Microsoft Learn)
開発者が確認すべきAPI・自動化のポイント
開発者や運用自動化担当者は、ポータル画面の変更だけでなく、API、スクリプト、サービスプリンシパル、マネージドID、ネットワークの前提を確認する必要があります。
特に次のような実装は見直してください。
| 確認対象 | 見直す理由 |
|---|---|
web.purview.azure.com を含む社内ドキュメント | 利用者をクラシックポータルへ誘導し続ける可能性がある |
https://[accountname].purview.azure.com/ 固定のスクリプト | 新エンドポイント移行後の影響確認が必要 |
| ファイアウォール許可済みのFQDN一覧 | 新ポータルや新APIがブロックされる可能性がある |
| サービスプリンシパルのロール | Data Mapやコレクション権限が不足する可能性がある |
| スキャン実行ジョブ | エンドポイント切り替え前後で動作確認が必要 |
| リネージ連携 | platform private endpointで未サポートの接続がないか確認が必要 |
| 利用者向けリンク集 | 新旧ポータルの混在で問い合わせが増える可能性がある |
Microsoftは、既存アカウントを新しい体験へアップグレードした場合でも、現在のエンドポイントと新しいエンドポイントの両方からアクセスできるため、Microsoft Purview API利用に即時影響はないと説明しています。ただし、これは「何もしなくてよい」という意味ではありません。API呼び出し、認証、権限、ネットワーク許可、監視ログを含めて、移行前後で同じ結果になるかを検証する必要があります。(Microsoft Learn)
移行・展開の実務手順
Classic Microsoft Purview governance portalから新しいMicrosoft Purviewポータルへ移行する際は、いきなり全社展開せず、棚卸し、検証、教育、切り替えの順に進めるのが安全です。
| 手順 | 実施内容 | 完了の目安 |
|---|---|---|
| 現状把握 | Purviewアカウント、リージョン、コレクション、ロール、データソース、スキャン、用語集を一覧化する | 管理対象が表で確認できる |
| 影響分類 | 管理者、開発者、データスチュワード、一般利用者ごとに影響を分ける | 問い合わせ先と影響範囲が明確 |
| ネットワーク確認 | 新ポータルと新APIエンドポイントを許可する | 社内ネットワークから新ポータルへ接続できる |
| 権限整理 | クラシック側ロールと新ポータル側ロールを照合する | 過剰権限と権限不足が洗い出されている |
| パイロット | 管理者と一部利用者で検索、スキャン、用語集、キュレーションを検証する | 主要業務が新ポータルで再現できる |
| 自動化検証 | API、スクリプト、ジョブ、監視を検証する | 失敗時のログと復旧手順がある |
| 教育・周知 | 画面差分、アクセスURL、問い合わせ先を案内する | 利用者が次に使うURLを理解している |
| 段階展開 | 部門単位または用途単位で新ポータル利用を広げる | クラシック依存を減らせている |
移行計画では、管理者だけでなく、データを検索する利用者の行動も想定してください。たとえば、営業部門が顧客データを探す、経理部門が承認済みデータセットを確認する、開発チームがスキャン結果を参照するといった具体的な業務シナリオで検証すると、単なるログイン確認では見つからない問題を発見できます。
失敗しやすいポイントと回避策
グローバル管理者なら何でもできると思い込む
新しいMicrosoft Purview体験へのアップグレードでは、Purview Administratorロールが関係します。Microsoftは、グローバル管理者または課金管理者がアップグレードを試みるとエラーになる場合があると説明しています。(Microsoft Learn)
対策として、Microsoft 365管理センターやMicrosoft Purview側で、Purview Administrator、Data Governance、Data Source Administratorsなどの役割を事前に整理してください。
クラシックポータルのURLだけを社内手順に残す
クラシックポータルを継続利用できる間も、社内手順書、ブックマーク、Teams投稿、SharePointページ、運用Runbookがすべて web.purview.azure.com のままだと、利用者は新ポータルへ移行できません。
対策として、「新規操作は新ポータル」「既存の特定作業は当面クラシック」といった使い分けを明記し、最終的には新ポータル中心の手順へ統一します。
プレビュー機能の言語表示で問い合わせが増える
クラシックポータルではMicrosoft Purviewが18言語にローカライズされていますが、一般公開されている機能のみがローカライズ対象で、プレビュー機能は選択言語に関係なく英語表示になると説明されています。(Microsoft Learn)
日本語環境の利用者に展開する場合は、画面が英語で表示される可能性がある機能を事前に知らせ、操作手順書では英語ラベルも併記すると問い合わせを減らせます。
移行を「画面変更」とだけ捉える
Microsoft Purviewは、データ資産、分類、用語集、スキャン、権限、DLP、監査、リスク管理と関係します。画面だけを見て移行可否を判断すると、裏側のAPI、ネットワーク、権限、ジョブ、利用者教育を見落とします。
対策として、移行タスクを「UI」「権限」「ネットワーク」「API」「データ運用」「教育」に分けて管理してください。
今すぐ対応すべき組織の判断基準
次のいずれかに該当する場合は、Classic Microsoft Purview governance portalの整理と新ポータル移行準備を優先度高で進めるべきです。
| 状況 | 優先度 | 理由 |
|---|---|---|
| 複数のMicrosoft Purviewアカウントを運用している | 高 | 主アカウント選定と統合方針が必要 |
| プライベートエンドポイントを使っている | 高 | platform private endpoint、DNS、ファイアウォール確認が必要 |
| スキャンやAPIを自動化している | 高 | エンドポイント、権限、実行ジョブへの影響確認が必要 |
| データカタログを業務部門が日常利用している | 高 | 利用者教育と問い合わせ対応が必要 |
| クラシック用語集やData Estate Insightsを使っている | 中 | Unified Catalog側での見え方と運用整理が必要 |
| PoCや検証用途のみで使っている | 中 | 新ポータル前提で再構成した方が将来の手戻りが少ない |
| ほぼ使っていないがアカウントだけ残っている | 中 | 放置すると権限や課金、棚卸しの盲点になりやすい |
まず実施すべきチェックリスト
公開情報を読んだあとに管理者が取るべき行動は、次の順番が現実的です。
https://web.purview.azure.comを使っている利用者、部門、運用手順を洗い出す- Microsoft Purviewアカウントが単一か複数かを確認する
- ルートコレクション管理者、Data curator、Data reader、Data source administratorを棚卸しする
- サービスプリンシパル、マネージドID、スキャンジョブ、API呼び出しを一覧化する
purview.microsoft.comとapi.purview-service.microsoft.comへの通信可否を確認する- プライベートエンドポイント利用環境ではplatform private endpoint移行要否を確認する
- 新ポータルで検索、スキャン、用語集、データ資産の閲覧ができるかをパイロット検証する
- 社内手順書、問い合わせ先、教育資料を新ポータル前提に更新する
Classic Microsoft Purview governance portalは、既存環境ではまだ重要な役割を持ちます。しかし、今後のMicrosoft Purview運用は新しいMicrosoft PurviewポータルとUnified Catalogを前提に設計するのが現実的です。まずは、現在のクラシック依存を棚卸しし、権限、ネットワーク、API、利用者教育の4点から移行準備を始めてください。
コメント