Microsoft Purviewとは
Microsoft Purviewを一言で言うと、社内外に散らばるデータを「見つけて・把握して・守って・正しく使わせる」ための統合データガバナンス／コンプライアンス基盤 です。
もう少し噛み砕くと、
- どこにどんなデータがあるかを棚卸しして可視化（データマップ／カタログ）
- 機密や個人情報を分類して、アクセスや利用ルールを管理
- 監査・eDiscovery・DLPなどでリスク/規制対応まで一体でやる
など、「データの住所録＋保管庫＋ルールブック」をまとめたという感じ。
登場の経緯
Purview は最初から今の形だったわけじゃなく、「データを見つけて整理するガバナンス」と「データを守って監査するコンプライアンス」が別々に存在していた分断 を埋めるために統合されてきたサービスです。
まず Azure 側で、マルチクラウド/オンプレまで含めてデータ資産を棚卸し・可視化する 「Azure Purview」として 2021年9月にGAとなり、データカタログ/データマップの土台が整いました。
当時の解説記事を読むと、確かにAzure内に閉じた話ではあるものの、方向性は同じ。
引用：
一方で Microsoft 365 側には、機密分類・DLP・eDiscovery・監査などの情報保護/コンプライアンス機能群が別ブランドで存在していました。
そこで 2022年4月に Azure Purview と Microsoft 365 Compliance の系譜を「Microsoft Purview」へ一本化し、“見つける→理解する→分類して守る→監査まで”を一つの体験で扱える統合基盤として再編された、という流れです。
その後もAI時代の需要に合わせ、2024年9月に新しい Data Governance 体験（統合カタログやCopilot支援など）が GA して、統合ガバナンスの方向性がさらに強化されています。
参考：Google検索数
それでも話題になり始めたのは最近です。
- データ統合基盤の進歩やデータレイクハウスの革新が登場し、
- 必要性が先に叫ばれ、
- 実装に向けて動いていく中で、
- 少し遅れる形でガバナンスの重要性が叫ばれている
…という印象。
https://trends.google.co.jp/trends/explore?date=2021-08-01 2025-11-22&q=Microsoft Purview&hl=ja
メイン機能と役割
Purviewは、公式の整理で次の3つの領域に分かれています。
https://learn.microsoft.com/ja-jp/purview/purview
1. Data Security（データセキュリティ）
- 対象チーム：情報セキュリティ、セキュリティ担当
-
主な機能
- 機密情報の検出と保護（暗号化、DLP）
- アクセス制御とポリシー適用
-
ユースケース
- 社内の機密ファイルを自動分類し、持ち出しを防止
- クラウド間で共有するデータに暗号化を強制
2. Data Governance（データガバナンス）
- 対象チーム：データ利用者、データエンジニア、データスチュワード
-
主な機能
- データマップとカタログで資産を可視化
- データ血統（リネージ）追跡
-
ユースケース
- AI学習用データの棚卸しと品質確認
- 社内の分析担当者が必要なデータを検索・利用
3. Risk & Compliance（リスクとコンプライアンス）
- 対象チーム：リスク管理、法務、コンプライアンス担当
-
主な機能
- eDiscovery、監査ログ、レポート
- 法規制対応（GDPR、個人情報保護法など）
-
ユースケース
- 訴訟対応で必要なデータを迅速に検索・証拠保全
- 内部監査で「誰がいつどのデータにアクセスしたか」を確認
利用料金
Purview の料金はちょっとクセがあって、「Microsoft 365 側のライセンス課金」と「Azure の従量課金」 が混在します。
「どの機能を」「どのデータ領域に対して」使うかで課金モデルが変わる、という前提で見るのが正しいです。
ライセンス課金（主に M365 系）
情報保護・DLP・eDiscovery・監査など “コンプライアンス寄り” の機能は、E5 などの ユーザー単位ライセンス が前提になるものがあります。
従量課金（主に Azure 側）
データガバナンスやデータセキュリティを Microsoft 365 外まで広げて使う場合、Azure サブスクに紐づけた従量課金が基本です。
Purview の “ガバナンス側（データカタログ/データ品質/データプロダクト）” は、
2025年1月から新しい従量課金モデルに切り替わりました。新モデルのポイントは2つ。
1) 「管理したデータ資産数」で課金
Purview の新しいデータカタログでは、“ガバナンス概念にひもづけた資産” だけが課金対象になります。
- データマップにスキャンで入っているだけの資産：課金されない
- データプロダクトや重要データ要素として “管理対象” にした資産：課金対象
例：
500テーブルがデータマップにあるけど、200だけを「重要データ（CDE）」として管理にひもづけた
→ 課金対象は200だけ（残り300は無料枠扱い）
この設計はかなり現実的で、
「全部棚卸しはしたい。でも統治コストは重要なところにだけかけたい」
という企業の感覚に寄せられています。
2) データ品質など“ガバナンス処理”は DGPU で課金
データ品質チェックやヘルス管理のような計算が走る機能は、
DGPU（Data Governance Processing Unit）という処理単位で従量課金されます。
DGPU はPurview が1時間処理を回す計算資源の単位となっていて、
Basic / Standard / Advanced の性能SKUがあり、速く回したいほど単価も高くなるイメージです。
重要なのは、「カタログで管理する数（Governed Assets）」と「品質/ルールをどれだけ回すか（DGPU）」が別メーターで課金される ということ。
3) Data Map（クラシック）課金
一方で、現在 Classic Data Catalog（旧UI） を使っている場合は、課金は旧モデルのままです。 今から始める組織ならUnified Catalog が前提になるため、Classic Data Map のCU課金やスキャンvCore課金を気にする必要はほぼほぼないですが、切り替える組織は同意の作業が必要です。
詳細は以下。
ざっくり見積もり
2025年11月24日時点におけるPurview（Unified Catalog / 新課金モデル）について、
「まず1ドメインレベルでPoC的に始めるとき」の費用目安を算出してみました。
想定条件（PoC規模）
-
Governed Assets：200個
- イメージ：部門が業務で本当に重要と判断したテーブルやファイルだけをCDEとして管理対象
- 例：KPIの源泉テーブル、横断で使う基幹マスター、AI/RAGやレポートで必ず参照されるファクト、規制・監査に引っかかる可能性があるもの等
-
DGPU：20/月
- イメージ：重要領域にだけ軽い品質ルールを週1〜日1で実行する
- 例：特に重要領域の20資産に対して週1でNULL率とフォーマットをチェック、自由度の高い10資産に対して週3でルールを色々試す等
計算の考え方
Japan East の単価を使って、ざっくり次で見積もる。
- Governed Assets：¥2.5 / 資産・日 → 月30日換算で ¥75/ 資産・月
- DGPU（Basic）：¥2,265 / DGPU
よって、
-
Governed Assets費
200 × ¥75 ＝ 約¥15000 / 月 -
DGPU費
20 × ¥2,265 ＝ 約¥45000 / 月
合計： 約¥60000 / 月
200資産くらいの統治と軽い品質運用なら、コストは大きく跳ねない印象です。
コスト設計の考え方
1. まずは全部スキャン⇒棚卸しする
上で述べている通り、新モデルなら “スキャンするだけ” は課金対象外です。
以前（Classic）だと、スキャンや Data Map 維持だけで CU/vCore 課金が走っていたので、
「棚卸ししたいけどコストが気になって進まない」という壁がありました。
探索フェーズのコストが０に近いのは大きいですよね。
- 接続できるデータソースを広めに登録して粗くスキャン
- Data Map 上で資産分布と自動分類（PII/機密の有無）を眺めて現状把握
- この段階では“Govern（管理対象化）”はしない
みたいなイメージです。
2. ガバナンス対象は「重要な資産」に絞る
データ製品やCDEなど “ガバナンス概念にリンクされたテーブル/ビュー” が Governed Assets としてカウントされ、課金対象になるので、「価値/リスクが高いところだけ統治する」 のが自然に最適解になります。
- 経営KPIや部門横断で使われる“共通の数値の源泉”
- 個人情報/機密など規制・漏えいリスクが高い領域
- AI/RAGやレポートで大量に再利用される基盤データ
このような “外に出た瞬間の損失が大きい or 全社価値が大きい 箇所からGovernするのが筋と思われます。
3. DGPU は「段階設計」とする
DGPU は「計算処理を回した時に消費される処理単位（60分単位）」で、Basic/Standard/Advanced の性能レベルがあります。
どの領域でもそうですが、初期から全域・高頻度・重いルールを回すと無駄が出やすいので、段階設計が推奨されます。
とても簡単なイメージですが、
- 探索期：週1や月1で重要領域だけ軽いルール
- 重点期：CDE/プロダクト領域は日次に引き上げ
- 成熟期：全社展開＋自動化
のように、頻度・範囲・ルールの重さを段階的に上げるのが DGPU 最適化の王道と思われます。
4. 見積もりは公式 Pricing Calculator でやるのが確実
こちらも当然ですが、選択するリージョンやSKUで変動しますので、最終的な実額は公式Pricing/Calculatorで確認しましょう。
またPurview は更新・アップデートが早く、今後もこの波は続きそうなので、最新ニュースをキャッチアップしておくことも必要かと思います。
Discussion