Microsoft Purviewの「Data Lifecycle Management – DLM Meter Change」は、非Microsoft 365系の生成AIプロンプトや応答をPurviewの保持ポリシーで管理している組織に影響する課金モデル変更です。結論から言うと、管理者は従来メーターから新メーターへの移行準備、対象AIアプリの棚卸し、保持ポリシーの範囲確認、コスト見積もりの更新を早めに行う必要があります。Microsoft 365ロードマップでは、この変更はMicrosoft Purview向け、Web、Worldwide、General Availability、2026年6月提供予定、ステータスはIn developmentとして掲載されています。(Microsoft)
Microsoft PurviewのDLM Meter Changeとは
Microsoft PurviewのDLM Meter Changeは、Data Lifecycle Management（DLM）で管理される生成AI関連データの課金方法を見直す更新です。
DLMは、組織内のデータを「必要な期間だけ保持し、不要になったら削除する」ためのMicrosoft Purviewの機能です。保持ポリシーや保持ラベルを使い、メール、Teams、SharePoint、OneDrive、CopilotやAIアプリのやり取りなどを、業務・法務・規制要件に合わせて管理します。Microsoftのサービス説明でも、DLMとRecords Managementは保持ポリシー、保持ラベル、保持ラベルポリシーを使って保持と削除の設定を適用すると説明されています。(Microsoft Learn)
今回の変更で特に重要なのは、非Microsoft 365の生成AIアプリにおけるプロンプトと応答です。Microsoftのロードマップでは、DLMの課金が保持されたデータ量を基準にし、非Microsoft 365生成AIのプロンプトと応答が合計1GBの保持データになる場合、1GBあたり月額0.25ドル、日額換算で約0.0082ドルとして課金される例が示されています。さらに、更新後モデルでは、DLMポリシーで管理されるテキストメッセージ量に基づき、100万テキストメッセージあたり月額6ドル相当で計算されると説明されています。(Microsoft)
変更内容の要点
| 項目 | 内容 |
|---|---|
| 対象サービス | Microsoft Purview |
| 機能 | Data Lifecycle Management（DLM） |
| 変更名 | DLM Meter Change |
| 対象データ | 主に非Microsoft 365生成AIのプロンプトと応答 |
| 提供予定 | 2026年6月のGeneral Availability |
| 対象クラウド | Worldwide（Standard Multi-Tenant） |
| 管理画面 | Web |
| 管理者対応 | 従来メーターから新メーターへの移行が必要 |
| コスト影響 | Microsoftの現時点の分析では、全体としてコスト中立または低下が見込まれる |
何が変わるのか：件数だけでなく「保持される量」を見る必要がある
今回のDLM Meter Changeで押さえるべきポイントは、課金の見方がより「保持・管理されているデータ量」に寄ることです。
従来の説明では、DLMのPay-as-you-go課金について、非Microsoft 365 CopilotまたはAIアプリのプロンプト・応答が保持ポリシーの対象になる場合、それぞれのプロンプトと応答が個別のinteractionとして扱われる、という整理がされています。Microsoft Purviewの課金モデル説明でも、DLMはAI interactions向けの保持ポリシーを対象とし、非Microsoft 365の生成AIプロンプトと応答が別々のinteractionとして保持・削除されると説明されています。(Microsoft Learn)
今回のロードマップ更新では、これに加えて、保持されたデータ量やDLMポリシーで管理されるテキストメッセージ量を基準にした新しい計算モデルが示されています。実務上は、次のように考えると分かりやすいです。
| 観点 | 旧来の見方 | 新しい見方で重視すべきこと |
|---|---|---|
| 利用量の把握 | プロンプト・応答の件数を中心に見る | 保持対象になったプロンプト・応答の量、保持期間、削除タイミングを見る |
| コスト見積もり | AI interaction数から概算する | 保持データ量または管理対象テキストメッセージ量から再計算する |
| ポリシー設計 | 対象アプリを広く含める | 本当に保持が必要なアプリ・ユーザー・期間を絞る |
| 運用リスク | 取得漏れや過保持 | 不要データの長期保持によるコスト増、法務・プライバシーリスク |
特に、生成AIの利用が増えている企業では、プロンプトと応答は短文ばかりとは限りません。ソースコード、契約書ドラフト、議事録、分析レポート、顧客対応文面など、長いテキストがAIアプリに入力されるケースがあります。単純な「利用回数」だけで予算を見積もると、保持データ量の実態とずれる可能性があります。
影響を受けやすい組織
今回の変更は、すべてのMicrosoft Purview利用企業に同じ大きさで影響するわけではありません。特に確認が必要なのは、次のような組織です。
| 組織の状況 | 確認すべき理由 |
|---|---|
| ChatGPT Enterprise、Google Gemini、DeepSeekなど外部AIアプリの利用を許可している | Other AI AppsやEnterprise AI appsとして保持対象になっている可能性がある |
| Microsoft PurviewでAIアプリ向けの保持ポリシーを設定している | DLMポリシーの対象データがそのまま課金対象になり得る |
| DSPM for AIやActivity explorerでAI利用を監視している | AIアプリの可視化・収集設定とDLM保持設定が関係する |
| 法務・監査目的でプロンプトと応答を長期間保持している | 保持期間が長いほど、ストレージ上の対象データ量が増えやすい |
| 部門ごとにAIアプリ利用ポリシーが異なる | アプリ・ユーザー・地域ごとの収集範囲を見直す必要がある |
逆に、Microsoft 365 Copilotの利用だけで、非Microsoft 365の生成AIアプリをPurviewのDLM保持対象にしていない場合、今回の変更による直接的な課金影響は限定的と考えられます。ただし、AIアプリ利用の実態はシャドーIT化しやすいため、管理者は「使っていないはず」ではなく、Activity explorerやDSPM for AIの情報を使って確認することが重要です。
管理者が最初に確認すべき設定
Microsoft Purview管理者は、まずDLMの保持ポリシーとAIアプリの収集設定を確認してください。
Microsoftのドキュメントでは、AIアプリのプロンプトと応答を保持するには、Retention policiesを使って自動的に保持または削除できると説明されています。また、AIアプリのやり取りはユーザーのメールボックス内の隠しフォルダーに保存され、ユーザーや管理者が直接参照するための場所ではなく、eDiscoveryなどのコンプライアンスツールで検索するための保存先として扱われます。(Microsoft Learn)
確認する場所と見るべきポイント
| 確認項目 | 見るべきポイント |
|---|---|
| Data Lifecycle Managementの保持ポリシー | Microsoft Copilot experiences、Enterprise AI apps、Other AI appsが含まれているか |
| ポリシーのスコープ | 全ユーザー対象か、特定部門・グループだけか |
| 保持期間 | 1年、3年、7年、無期限など、業務要件に対して長すぎないか |
| 削除設定 | 保持のみ、削除のみ、保持後削除のどれか |
| Collection policy | 非Microsoft 365 AIアプリのプロンプト・応答を収集する設定になっているか |
| Azure課金連携 | Pay-as-you-go利用に必要なAzureサブスクリプション連携が整っているか |
| 予算アラート | Purview関連の消費課金を監視できるようにしているか |
保持ポリシーの作成画面では、Microsoft Copilot experiences、Enterprise AI apps、Other AI appsなどの場所を選択できます。Microsoftの保持ポリシー作成ドキュメントでは、Microsoft Copilot experiencesにはMicrosoft 365 Copilot、Security Copilot、Copilot in Fabric、Copilot Studioなどが含まれ、Enterprise AI appsにはEntra登録済みAIアプリ、ChatGPT Enterprise、Microsoft Foundryなどが含まれ、Other AI AppsにはChatGPT、Google Gemini、Microsoft Bing、DeepSeekなどが含まれると説明されています。(Microsoft Learn)
非Microsoft 365生成AIアプリではCollection policyの確認が必須
今回の変更で見落としやすいのが、Collection policyです。
Microsoftのドキュメントでは、Microsoft 365 CopilotとCopilot Studio以外のAIアプリでプロンプトと応答を保持するには、まず対象AIアプリ用のcollection policyが必要で、そのポリシーでcontent captureを含める必要があると説明されています。(Microsoft Learn)
Collection policyは、Purviewに取り込むイベントを制御する仕組みです。たとえば、すべての生成AIプロンプト・応答を取り込むのか、特定の分類子に一致したものだけを取り込むのか、特定のアプリやデータソースだけを対象にするのかを設計できます。Microsoftの説明では、Collection policiesはActivity explorer、Insider Risk Management、eDiscovery、Data Lifecycle ManagementなどのPurviewソリューションで利用されるデータの取り込みに関係します。(Microsoft Learn)
content captureの扱いに注意
AI interactionsのcontent captureを有効にすると、検出されたプロンプトと応答を保存し、後続のPurviewポリシーやソリューションで利用しやすくなります。一方で、取り込む量が増えるため、保持対象データ量も増える可能性があります。
MicrosoftのCollection policy説明では、AI interactionsのcontent captureは、Copilot experiences、Enterprise AI、生成AIカテゴリの unmanaged cloud apps、All unmanaged AI apps adaptive app scopeに適用されると説明されています。また、AIコンテンツをキャプチャするには、Content contains classifiers条件をAllに設定する必要があるとされています。(Microsoft Learn)
そのため、管理者は次のように判断するとよいでしょう。
| 判断ポイント | 推奨される対応 |
|---|---|
| 監査・法務要件でプロンプト全文が必要 | content captureを有効化し、保持期間を明確にする |
| 機密情報検出だけで足りる | 全文キャプチャではなく、必要最小限の収集にできないか検討する |
| AIアプリ利用が急増している | 対象アプリ・対象ユーザーを段階的に広げる |
| 部門ごとに規制要件が異なる | 地域・部門・ユーザーグループ単位でスコープを分ける |
| コスト予測が難しい | 短い保持期間で試算し、利用量を確認してから拡大する |
移行でやるべきこと
Microsoftのロードマップでは、顧客はlegacy meterからnew meterへ移行する必要があると明記されています。さらに、Microsoftの現時点の分析では、新しい課金モデルにより全体のコスト影響は中立または低下が見込まれるとされています。ただし、これは全顧客に一律でコストが下がるという意味ではありません。保持期間、対象アプリ、プロンプト・応答の長さ、収集範囲によって結果は変わります。(Microsoft)
移行前チェックリスト
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | AIアプリの利用実態を棚卸しする | 公式許可アプリだけを見て、部門利用の外部AIを見落とす |
| 2 | DLM保持ポリシーの対象場所を確認する | Other AI Appsが全ユーザー対象になっていることに気づかない |
| 3 | Collection policyのcontent capture設定を確認する | キャプチャ範囲が広すぎて保持データ量が増える |
| 4 | 保持期間を業務要件と照合する | 「念のため長期保持」がコストとリスクを増やす |
| 5 | 新メーターで概算コストを再計算する | 旧メーターの見積もりをそのまま使い続ける |
| 6 | Azure課金・予算アラートを確認する | 月末請求で初めて増加に気づく |
| 7 | 法務・セキュリティ・利用部門と合意する | ITだけで保持期間を決め、監査要件とずれる |
コスト見積もりの考え方
ロードマップで示された例では、非Microsoft 365生成AIのプロンプトと応答が合計1GBの保持データになる場合、1GBあたり月額0.25ドルとして扱われます。また、DLMポリシーで管理されるテキストメッセージについて、100万件あたり月額6ドル相当という説明もあります。(Microsoft)
実務では、次の3つを組み合わせて見積もるのが現実的です。
| 見積もり要素 | 例 |
|---|---|
| 対象ユーザー数 | 生成AIアプリを利用する従業員数、部門数 |
| 1人あたりの利用量 | 1日あたりのプロンプト数、応答数、平均文字数 |
| 保持期間 | 30日、90日、1年、3年など |
たとえば、開発部門ではコードやエラーログを含む長文プロンプトが多く、営業部門ではメール文面や提案書要約が多い、といった差が出ます。全社平均だけで見積もるより、部門別に高利用グループを分けて試算するほうが精度が上がります。
また、PurviewのPay-as-you-goモデルはAzureベースの課金として扱われます。Microsoftの課金モデル説明では、Pay-as-you-goは非Microsoft 365データソースや一部機能にPurviewの保護機能を拡張する消費課金モデルであり、Microsoft 365テナントを有効なAzureサブスクリプションに関連付ける必要があると説明されています。(Microsoft Learn)
展開時の注意点
DLM Meter Changeへの対応は、単に課金メーターを切り替えるだけでは不十分です。保持ポリシーはコンプライアンス、eDiscovery、監査、データ削除に関わるため、設定変更の影響を慎重に確認する必要があります。
保持ポリシーはすぐ反映されない
Microsoftの保持ポリシー作成ドキュメントでは、保持ポリシーを作成して送信した後、ポリシーが適用されるまで最大7日かかる場合があると説明されています。ポリシーの配布状態はPurviewポータルのRetention policiesページで確認できます。(Microsoft Learn)
そのため、2026年6月の一般提供予定に合わせて対応する場合、月末ぎりぎりに設定を見直すのではなく、少なくとも数週間前から次の作業を進めるべきです。
| 時期 | 実施内容 |
|---|---|
| 事前調査 | AIアプリ利用状況、既存DLMポリシー、Collection policyを確認 |
| 移行準備 | 対象アプリ、対象ユーザー、保持期間、削除方針を見直す |
| テスト展開 | 一部部門または限定スコープで新しい見積もりを検証 |
| 本番展開 | ポリシー変更、課金監視、予算アラートを有効化 |
| 展開後 | 請求、保持量、eDiscovery検索結果、利用部門の影響を確認 |
複数ポリシーが重なると、長い保持が優先される場合がある
AIアプリのプロンプトと応答は、他の保持ポリシー、Litigation Hold、eDiscovery holdなどの影響を受ける場合があります。Microsoftのドキュメントでは、同じ場所に複数のポリシーが適用される場合、保持の原則によって競合が解決され、たとえば複数の保持ポリシーやeDiscovery holdのうち最も長い期間保持されると説明されています。(Microsoft Learn)
つまり、DLMポリシー上は90日で削除する設定にしていても、別の保持ポリシーや法的保持がある場合、実際には削除されないことがあります。コストを下げる目的でDLMの保持期間だけを短縮しても、別の保持設定が残っていれば期待した効果が出ない可能性があります。
開発者・アプリ担当者が確認すべきこと
この変更は管理者だけの問題ではありません。生成AIアプリを導入・開発・連携している開発者やアプリ担当者も、Purview側のDLM設定を理解しておく必要があります。
特に、社内アプリや業務システムから外部AIモデルを呼び出している場合、プロンプトや応答がどのようにログ化され、Purviewの収集対象になるかを確認してください。MicrosoftのDSPM関連ドキュメントでは、Collection policyはCopilot in FabricやSecurity Copilot、非Copilot AIアプリのプロンプトと応答をキャプチャし、Microsoft Purviewソリューションで管理できるようにするポリシーと説明されています。(Microsoft Learn)
開発・運用での実務ポイント
| 役割 | 確認すべきこと |
|---|---|
| アプリ開発者 | プロンプト・応答に不要な個人情報や機密情報を含めない設計にする |
| API連携担当 | AIアプリの通信経路、認証方式、Entra登録の有無を整理する |
| セキュリティ担当 | AIアプリの利用状況、DLP、監査ログ、Activity explorerを確認する |
| 法務・監査担当 | プロンプト・応答をどの期間保持すべきか明文化する |
| 情シス管理者 | DLMポリシー、Collection policy、Azure課金を横断的に確認する |
開発側で特に避けたいのは、「あとで監査に必要になるかもしれない」という理由で、すべてのプロンプトと応答を長期間保存する設計にすることです。保持はコンプライアンス上必要な一方で、不要な長期保持はコスト、情報漏えい時の影響、削除要求対応の負荷を増やします。
よくある誤解
Microsoft 365 Copilotだけを使っていれば必ず課金されるのか
今回のロードマップで中心に示されているのは、非Microsoft 365生成AIのプロンプトと応答です。Microsoftの課金モデル説明でも、生成AIアプリとエージェント向けのPay-as-you-go機能について、Microsoft 365 Copilot experiencesは課金されないと説明されています。(Microsoft Learn)
ただし、Security Copilot、Copilot in Fabric、Copilot Studio、非Microsoft 365 AIアプリなどを含めた全体の構成によって、別のPurview課金やAI関連課金が発生する可能性があります。自社の利用サービス単位で確認してください。
保持期間を短くすれば必ずすぐ削除されるのか
すぐには削除されません。Microsoftのドキュメントでは、AIアプリのメッセージはExchangeサービスのタイマージョブで定期的に評価され、通常1〜7日で処理されると説明されています。また、保持期間後の削除にもSubstrateHoldsフォルダーでの保持や次回ジョブ実行が関係します。(Microsoft Learn)
さらに、別の保持ポリシー、Litigation Hold、eDiscovery holdがある場合、完全削除は停止される可能性があります。コストや削除要件を確認する際は、DLMポリシーだけでなく、関連する保持設定全体を見る必要があります。
コストは必ず下がるのか
必ず下がるとは言えません。Microsoftはロードマップ上で、現時点の分析では新しい課金モデルにより全体的なコスト影響は中立または低下が見込まれるとしています。ただし、これは全テナント・全ユースケースで保証されるものではありません。(Microsoft)
特に、長文プロンプトが多い、対象AIアプリが多い、保持期間が長い、全ユーザー対象でcontent captureを有効化している、といった環境では、個別に試算する必要があります。
実務でおすすめの対応方針
DLM Meter Changeに備えるなら、最初から全社一括で大きく設定変更するより、影響範囲を可視化してから段階的に見直すのが安全です。
まず、Purviewポータルで既存のDLM保持ポリシーを確認し、AIアプリ関連の場所が含まれているかを確認します。次に、Collection policyでどのAIアプリのプロンプト・応答を収集しているかを確認します。そのうえで、保持が必要なデータと、監査目的では不要なデータを分けます。
特に重要なのは、次の3つです。
| 優先度 | 対応 |
|---|---|
| 高 | legacy meterからnew meterへの移行要件を確認する |
| 高 | Enterprise AI appsとOther AI Appsの保持ポリシー範囲を確認する |
| 高 | content captureの対象と保持期間を見直す |
| 中 | 部門別にAI利用量を把握し、概算コストを再計算する |
| 中 | Azure予算アラートや請求確認フローを整備する |
| 中 | 法務・監査部門と保持期間の根拠を文書化する |
| 低 | 将来的なAIアプリ追加時の標準チェックリストを作る |
まとめ：Microsoft PurviewのDLM Meter Changeは「課金」だけでなくAIデータ保持設計の見直しポイント
Microsoft PurviewのData Lifecycle Management – DLM Meter Changeは、単なる価格表の更新ではありません。生成AIアプリのプロンプトと応答を、どの範囲で収集し、どの期間保持し、いつ削除するのかを見直すきっかけになります。
管理者が次に取るべき行動は明確です。まず、PurviewのDLM保持ポリシーでMicrosoft Copilot experiences、Enterprise AI apps、Other AI Appsがどう設定されているかを確認してください。次に、Collection policyのcontent capture設定と対象AIアプリを確認します。そのうえで、新メーターを前提に保持データ量、対象ユーザー、保持期間からコストを再試算し、Azure課金と予算アラートを整備します。
AI活用が広がるほど、プロンプトと応答は重要な業務データになります。過不足のない保持設計を行うことが、コンプライアンス、コスト管理、情報漏えいリスク低減のすべてにつながります。
コメント