Microsoft Purview billing modelsの2026年4月更新ポイントで最初に押さえるべき結論は、Microsoft Purviewの課金は「ユーザー単位ライセンス」だけで判断できないという点です。Microsoft 365やWindows/macOSエンドポイント中心の保護は従来どおりユーザー単位ライセンスで考えますが、Microsoft 365以外のデータソース、生成AIアプリ、ネットワークやブラウザー経由のDLP、データガバナンス、調査系機能では、従量課金制が関係します。
特にsecurity admins、identity teams、compliance teamsは、機能を有効化する前に「どのデータが対象か」「どの課金単位で測定されるか」「誰がAzure課金とライセンス利用を監視するか」を決めておく必要があります。4月のMicrosoft Purview更新では、DLP、Data Governance、Data Security Investigations、eDiscovery、Sensitivity labelsなどの実務領域に更新があり、ポリシー範囲の広げ方がそのままコスト管理にも影響しやすくなっています。(Microsoft Learn)
Microsoft Purview billing modelsで何が重要になったか
Microsoft公式の「Learn about Microsoft Purview billing models」は、Microsoft Purviewの課金を大きく2つのモデルで整理しています。1つはMicrosoft 365 E3/E5/A5/F5/G5などに代表されるユーザーごとのライセンスモデル、もう1つはAzureベースで利用量に応じて請求されるpay-as-you-go、つまり従量課金制モデルです。重要なのは、この2つが置き換え関係ではなく、補完関係にあることです。(Microsoft Learn)
たとえば、Microsoft 365 E5を契約しているからといって、AWS、Azure SQL、Box、Dropbox、Google Drive、Microsoft Fabricなど、Microsoft 365外にあるデータの保護やガバナンスまで自動的にすべて含まれるわけではありません。非Microsoft 365データソースや一部のAI・ネットワーク・ブラウザー関連機能では、従量課金制の確認が必要になります。(Microsoft Learn)
| 課金モデル | 主な対象 | 実務での見方 | 見落としやすい点 |
|---|---|---|---|
| ユーザーごとのライセンス | Microsoft 365、Windows/macOSエンドポイント、ユーザー単位での保護 | 既存のMicrosoft 365ライセンス設計と連動して考える | Microsoft 365外のデータソースまで自動的に対象になると誤解しやすい |
| 従量課金制モデル | 非Microsoft 365データソース、AIアプリ、ネットワーク、ブラウザー、データガバナンス、調査系機能など | Azureサブスクリプション、リソースグループ、利用量、課金単位で管理する | ポリシー範囲を広げると、利用量も広がる可能性がある |
| 両方の組み合わせ | Microsoft 365内外を横断する保護・調査・監査・ガバナンス | ライセンス担当、セキュリティ担当、コンプライアンス担当の共同管理が必要 | 「機能を有効化できる」ことと「予算管理できている」ことは別問題 |
2026年4月更新で注目すべき実務ポイント
2026年4月のMicrosoft Purviewの更新では、Collection Policies、Data Governance、Data Loss Prevention、Data Security Investigations、eDiscovery、Insider Risk Management、Sensitivity labelsなどに変更や追加がありました。課金モデルそのものだけを見るのではなく、新しい機能や条件指定によって、どの範囲のデータがポリシー対象になるかを確認することが重要です。(Microsoft Learn)
非Microsoft 365データと生成AI利用が課金設計の中心になる
従量課金制モデルは、Microsoft 365やWindows/macOS環境を超えて、非Microsoft 365の場所にあるデータセキュリティ、データガバナンス、データリスク、コンプライアンス保護を拡張するためのモデルです。公式ドキュメントでは、ネットワーク、DataOps、アプリケーションアーキテクチャ、AIアプリやエージェントを流れるデータも対象として説明されています。(Microsoft Learn)
実務では、次のような場面で課金確認が必要です。
| 利用シーン | 関係しやすいPurview機能 | 確認すべきこと |
|---|---|---|
| Google DriveやBox上の機密データを保護したい | Information Protection、Insider Risk Management | 対象データソース、保護ポリシーのスコープ、資産数 |
| 生成AIアプリへの機密情報送信を検出・制御したい | Communication Compliance、Audit、Data Loss Prevention、Data Security for Gen AI Applications | 監査レコード、テキストレコード、リクエスト数、プロンプトと応答の扱い |
| Microsoft Fabricの資産をガバナンス対象にしたい | Unified Catalog、Data Governance | ガバナンス対象資産数、DGPU、データ品質アクション |
| インシデント時に広範囲のデータを調査したい | Data Security Investigations、eDiscovery | 保存データ量、Compute Units、調査範囲、保持期間 |
| Edge for Businessやネットワーク経由でクラウドアプリを制御したい | DLP for cloud apps、Network Data Security | リクエスト数、対象アプリ、対象URL、例外条件 |
特に生成AI関連では、「ユーザーがAIに送ったプロンプト」「AIからの応答」「AIアプリ上のやり取り」が、監査、保持、通信コンプライアンス、DLP、eDiscoveryの対象になり得ます。Microsoft 365 Copilotと非Microsoft 365の生成AIアプリでは扱いが異なるため、どのAI利用を対象にしているのかをポリシー作成前に分けて整理する必要があります。(Microsoft Learn)
DLPとCollection Policiesはスコープ設計がより重要に
4月更新では、Collection Policiesで秘密度ラベルを条件として使えるプレビュー機能が示されています。これは、ブラウザーやネットワークのクラウドアプリ検出で、特定の秘密度ラベルが付いたアイテムに検出範囲を絞る設計に関係します。(Microsoft Learn)
また、DLPではアンマネージドクラウドアプリ向けにURL文字列を条件として使えるプレビューや、ブラウザー・ネットワークDLPルールでブロック時にメール通知する更新が含まれています。これらは単なる機能追加ではなく、どの通信やクラウドアプリ利用を対象にするかを細かく制御できるようになるという意味があります。(Microsoft Learn)
たとえば、すべての生成AIアプリを一律に対象にするとリクエスト数が増えやすく、調査や通知のノイズも増えます。一方で、URL条件や秘密度ラベル条件を使えば、重要な業務データや特定の高リスクアプリに絞った段階導入がしやすくなります。
従量課金で必ず確認すべき測定単位
Microsoft Purviewの従量課金で失敗しやすいのは、「機能名」だけを見てコストを判断することです。実際には、機能ごとに測定単位が異なります。資産数で測るもの、処理単位で測るもの、保存容量で測るもの、テキスト量で測るもの、リクエスト数で測るものがあります。(Microsoft Learn)
| 測定単位 | 何を数えるか | 主に関係する領域 | 実務上の注意点 |
|---|---|---|---|
| 資産 | ポリシーのスコープ内にあるテーブル、ファイル、リソースなど | Information Protection、Unified Catalog、DLPなど | 条件に一致したものだけでなく、ポリシーのスコープに入る場所の資産がカウント対象になる場合がある |
| 処理単位 | シグナルやデータを処理するためのコンピューティング量 | Insider Risk Management、Data Governance、Data Security Investigations | データ量だけでなく、処理の複雑さや選択した分析内容で変わる |
| データストレージ | 調査やeDiscoveryで保存されるデータ量 | Data Security Investigations、eDiscovery | 調査完了後も保存し続けると継続的に課金対象になり得る |
| テキストレコード | 1,000文字を1単位として数えるテキスト量 | Communication Compliance | 長いプロンプト、チャット、応答は複数レコードとして扱われる |
| リクエスト | デバイスやブラウザーからWebサイト/APIへ送信されるネットワーク呼び出し | Network Data Security、Edge for BusinessのDLP | 応答ではなく送信リクエストが対象。ファイル送信やAIプロンプト送信も確認が必要 |
| SCU / Compute Units | Security CopilotやData Security InvestigationsのAI処理容量 | Security Copilot、Data Security Investigations | 事前プロビジョニング、上限、処理場所、調査単位の消費量を確認する |
特に「資産」の考え方は重要です。公式ドキュメントでは、資産はポリシーの条件に一致するかどうかだけでなく、ポリシーのスコープ内にある場所に存在するかでカウントされる説明があります。たとえばFabricワークスペースを5つ対象にし、それぞれ50資産がある場合、対象資産数は250になります。(Microsoft Learn)
つまり、コストを抑えたい場合は「条件を厳しくする」だけでなく、ポリシーの対象場所そのものを適切に絞ることが大切です。
security admins、identity teams、compliance teams別の確認ポイント
Microsoft Purview billing modelsの理解は、請求担当だけの作業ではありません。実際の運用では、セキュリティ、ID、コンプライアンスの各チームが異なる観点で関与します。
| 担当チーム | 主な関心事 | すぐ確認すべき項目 |
|---|---|---|
| security admins | DLP、データ漏えい防止、インシデント調査、AIアプリ利用制御 | 対象アプリ、対象URL、秘密度ラベル、調査範囲、アラート量、リクエスト数 |
| identity teams | ライセンス割り当て、ロール、管理者権限、Azureサブスクリプション連携 | Global Adminの使用最小化、Security Reader/Global Readerの活用、グループベースのスコープ管理 |
| compliance teams | 監査、eDiscovery、保持、通信コンプライアンス、規制対応 | 監査レコード、保持対象、AIプロンプトと応答、レビューセット、エクスポート量 |
Usage centerは、この3チームの共通確認場所として重要です。Microsoft PurviewのUsage centerでは、従量課金の利用状況とユーザー単位ライセンスの利用状況を確認できます。アクセスにはGlobal Reader、Security Reader、Global Adminなどのロールが必要とされています。(Microsoft Learn)
ここで重要なのは、Global Adminを日常監視のために使い続けないことです。Microsoftは最小権限のロール利用を推奨しており、普段の確認はSecurity ReaderやGlobal Readerで足りるかを検討すべきです。(Microsoft Learn)
4月更新後に見直したいポリシー設計の手順
Microsoft Purviewの課金影響を抑えながら機能を活用するには、次の順序で確認すると失敗しにくくなります。
| 手順 | やること | 具体例 |
|---|---|---|
| 1 | 対象データを分類する | Microsoft 365内のSharePointか、Fabricか、Boxか、生成AIアプリかを分ける |
| 2 | 課金モデルを確認する | ユーザー単位ライセンスで足りるのか、従量課金が必要かを確認する |
| 3 | 測定単位を確認する | 資産数、処理単位、GB、テキストレコード、リクエスト数のどれかを見る |
| 4 | ポリシー範囲を絞る | 全社一括ではなく、部門、データソース、ラベル、URL条件で段階導入する |
| 5 | 事前見積もりを行う | Microsoft Purviewのコスト見積もりツールやAzure側の予算管理を使う |
| 6 | 有効化後に監視する | Usage center、Azure Cost Management、機能別レポートを定期確認する |
Microsoft公式ドキュメントでも、従量課金機能の月額コストを見積もるための価格情報とコスト見積もりツールが案内されています。見積もりは一度だけではなく、ポリシー範囲を変えるたびに見直すのが実務上安全です。(Microsoft Learn)
Data Security Investigationsは調査範囲と保存期間がコストに直結する
Data Security Investigationsは、4月更新でも注目度が高い領域です。公式ドキュメントでは、Data Security Investigationsの課金は専用のエンタープライズプランやライセンスではなく、保存データ量とAI分析に必要なコンピューティング容量の組み合わせに基づくと説明されています。(Microsoft Learn)
実務で注意すべき点は3つあります。
まず、調査対象に追加したデータはストレージメーターに影響します。調査が終わった後も不要な調査を残しておくと、保存データ量に応じたコストが続く可能性があります。
次に、AI分析ではCompute Unitsが使われます。ベクトル検索、カテゴリ分類、詳細な分析など、どの処理を使うかによって消費量が変わります。すべての調査で最初から大規模なAI分析を実行するのではなく、最初は対象範囲と分析カテゴリを絞り、必要に応じて広げる設計が現実的です。(Microsoft Learn)
最後に、コスト管理は調査開始前から始めるべきです。Data Security Investigationsには、調査前の見積もり、Azure側の予算・アラート、Usage dashboardによるストレージとCompute Unitsの確認といった管理ポイントがあります。(Microsoft Learn)
Data Security Investigationsで失敗しやすい例
| 失敗例 | なぜ問題か | 回避策 |
|---|---|---|
| インシデント時に全社データを一気に調査対象にする | 保存データ量とAI処理量が急増しやすい | 期間、ユーザー、場所、ラベルで初期スコープを絞る |
| 調査完了後も古い調査を残し続ける | 不要な保存データが課金対象になり得る | 調査完了時に削除・エクスポート・保全の判断を標準手順に入れる |
| AI分析を毎回フル実行する | Compute Unitsの消費が増えやすい | カテゴリ分類や検査は段階的に実行する |
| セキュリティチームだけで有効化する | Azure課金・権限・予算管理が抜けやすい | Azure管理者、ID管理者、コンプライアンス担当を事前に巻き込む |
eDiscoveryとAIアプリ対応では保持・エクスポート量も確認する
4月更新では、eDiscoveryに関してCustomer Key利用組織向けのCMK暗号化エクスポートのプレビュー、レビューセット数の上限増加、Advanced review set explorerの更新などが示されています。これらはコンプライアンスチームにとって便利な更新ですが、調査データの保存、レビュー、エクスポートの扱いをより丁寧に管理する必要があります。(Microsoft Learn)
また、生成AIアプリの利用が増えると、プロンプト、応答、監査ログ、保持対象、調査対象が増える可能性があります。Data Lifecycle Managementでは、Microsoft 365以外の生成AIプロンプトと応答が個別の対話として扱われる説明があります。(Microsoft Learn)
コンプライアンス担当は、「AI利用を監査できるか」だけでなく、次の点を確認しておくと安全です。
| 確認項目 | 実務での質問 |
|---|---|
| 保持対象 | どのAIアプリのプロンプト・応答を保持するのか |
| 削除方針 | 保持期限後にどう削除するのか |
| eDiscovery対象 | 非Microsoft 365 AIアプリのデータをどこまで調査対象にするのか |
| エクスポート | Export APIやエクスポート容量がどの程度発生しそうか |
| 暗号化 | Customer KeyやCMK要件があるか |
| 国・地域 | 調査データやAI処理の場所に制約があるか |
Usage centerで見るべき指標
Microsoft PurviewのUsage centerはプレビュー機能として説明されていますが、従量課金とユーザー単位ライセンスの両方を把握するための重要な入口です。Pay-as-you-go usageでは、機能別・ワークロード別のTotal Units Usedを確認でき、一部機能では一時停止と有効化の切り替えもできます。(Microsoft Learn)
特に確認したいのは次の4つです。
| 見るべき指標 | 確認する理由 |
|---|---|
| Total Units Used | 従量課金の利用量がどの機能で増えているかを把握する |
| ポリシー対象ユーザー数 | ライセンス不足や過剰なスコープ設定を見つける |
| ライセンス割り当て済みだがポリシー対象外のユーザー | 買っているが使っていないライセンスを見つける |
| 一時停止可能な機能 | 検証後に使わない機能を止めてコストを抑える |
Usage centerのPremium usageでは、ポリシーのスコープに入っているがライセンスがないユーザー、逆にライセンスはあるがポリシー対象になっていないユーザーを確認できます。これは、security adminsだけでなくidentity teamsが定期的に確認すべき項目です。(Microsoft Learn)
すぐに見直すべき組織と、急がなくてよい組織
すべての組織が同じ緊急度で対応する必要はありません。Microsoft Purview billing modelsの見直しは、データソース、AI利用、DLP導入状況、調査機能の使い方によって優先度が変わります。
| 優先度 | 組織の状態 | 推奨アクション |
|---|---|---|
| 高 | 非Microsoft 365データソースを保護・監査している | 従量課金の対象機能、資産数、処理単位を確認する |
| 高 | 生成AIアプリやシャドーAI対策を進めている | AIプロンプト、応答、DLP、監査、保持の課金単位を整理する |
| 高 | Data Security InvestigationsやeDiscoveryを本格利用する | 調査範囲、保存期間、Compute Units、エクスポート量を見積もる |
| 中 | Microsoft FabricやUnified Catalogを拡張している | ガバナンス対象資産とDGPUの扱いを確認する |
| 中 | Edge for BusinessやネットワークDLPを検証中 | リクエスト数、URL条件、通知ルールを小さく始める |
| 低 | Microsoft 365内の基本的な保護のみ利用している | 既存ライセンスとポリシー対象ユーザーの確認から始める |
実務でのおすすめ導入パターン
Microsoft Purviewの課金モデルを安全に運用するには、最初から全社展開しないことが重要です。特に従量課金が関係する機能は、対象範囲を広げるほど利用量も増えやすいため、段階導入が向いています。
まずは可視化から始める
最初の段階では、ブロックや自動適用よりも、監査、レポート、検出を中心に設計します。どのクラウドアプリが使われているか、どのデータソースに機密情報があるか、どのユーザーや部門でリスクが高いかを把握します。
この段階で重要なのは、スコープを「全社」ではなく「特定部門」「特定データソース」「特定ラベル」に絞ることです。たとえば、全Fabricワークスペースではなく、機密データを扱う部門のワークスペースだけを対象にします。
次にポリシーを限定適用する
次に、DLP、Information Protection、Insider Risk Management、Communication Complianceなどのポリシーを限定適用します。ここでは、ブロックよりも通知や監査から始めると、業務影響とコスト影響を同時に確認できます。
たとえば、生成AIアプリへの送信をいきなり全ブロックするのではなく、特定の秘密度ラベルが付いたファイル、または特定URLを含むクラウドアプリ利用だけを対象にして、検出件数とリクエスト数を見ます。
最後に自動化と強制制御を広げる
利用量、誤検知、業務影響、コストを確認できたら、段階的にポリシーを広げます。DLPのブロック、秘密度ラベルの自動適用、インシデント調査時のAI分析、eDiscoveryの高度なレビューなどは、いずれも価値が高い一方で、スコープ設計と運用ルールが甘いとコストや運用負荷が増えます。
管理者が今日確認すべきチェックリスト
最後に、Microsoft Purview billing modelsの2026年4月更新ポイントを踏まえて、管理者が今日確認すべき項目を整理します。
| チェック項目 | 確認済みならOK |
|---|---|
| Microsoft 365内と非Microsoft 365データソースを分けて一覧化している | |
| Purview機能ごとに、ユーザー単位ライセンスか従量課金かを整理している | |
| 従量課金機能の測定単位を把握している | |
| Azureサブスクリプションとリソースグループの管理者を決めている | |
| Usage centerを確認できるロールを割り当てている | |
| Global Adminの日常利用を避ける運用にしている | |
| DLPやAIアプリ対策のポリシー範囲を小さく始めている | |
| Data Security Investigationsの調査範囲と保存期間を管理している | |
| eDiscoveryやAIデータ保持のエクスポート量・保存量を見積もっている | |
| 月次で利用量、ライセンス不足、未使用ライセンスをレビューしている |
Microsoft Purviewの4月更新は、単に新機能を確認するだけでは不十分です。これからのPurview運用では、セキュリティポリシー、ID管理、コンプライアンス要件、Azure課金を一体で設計する必要があります。
まずは、現在有効化しているPurview機能を一覧化し、各機能について「対象データ」「課金モデル」「測定単位」「監視担当」を1行ずつ整理してください。そこまでできれば、次にやるべきことは明確です。高リスクな非Microsoft 365データソースと生成AI利用から優先して、ポリシー範囲を絞った検証を始めるのが安全な進め方です。
コメント