Microsoft 365 Copilot WorkflowsでDSR（Data Subject Request／データ主体要求）に対応する管理者は、まず「対象ユーザーのWorkflowsデータがどのPower Platform環境にあるか」を確認する必要があります。2026年4月22日に更新されたMicrosoft公式ドキュメントでは、新しい Microsoft 365 Copilot Workflows environment にあるデータはAPIベースで処理すること、さらにDSR対応に必要なRBACロールが明確化されました。(Microsoft Learn)
結論から言うと、これまでのPower AutomateやDataverseの延長で手作業だけに頼る運用では不十分です。Microsoft 365管理者、Power Platform管理者、職場ITチームは、DSR対応手順に「環境IDの確認」「専用環境かPDE/既定環境かの判定」「API実行権限の準備」を追加しておく必要があります。
2026年4月更新の要点：DSR対応は「環境の特定」から始まる
今回の更新で最も重要なのは、Microsoft 365 Copilot Workflowsのデータ保存先が一律ではない点です。Microsoft公式ドキュメントでは、Workflows artifactsは通常、次のいずれかに存在すると説明されています。
| 確認項目 | 内容 | 管理者が取るべき対応 |
|---|---|---|
| 既定環境またはPDE | テナントのDefault environment、またはユーザーのPersonal Development EnvironmentにあるWorkflowsデータ | Dataverseテーブルや環境スコープAPIで確認・エクスポート・削除を行う |
| Microsoft 365 Copilot Workflows environment | 2026年4月以降の新しいフローで使われる可能性がある専用環境 | DSR対応はAPIベースで実施する |
| Environment ID | Power Platform admin centerのInventoryでユーザーのメールアドレスを使って確認 | DSRケースごとにEnvironment IDを記録する |
Microsoft Learnでは、Power Platform admin centerのInventoryでユーザーのメールアドレスをフィルターし、Workflows agentsが表示されるEnvironment IDを確認する流れが示されています。Environment ID列の値でPDE/既定環境を特定する場合と、Microsoft 365 Copilot Workflows environmentのEnvironment IDを含むURLリンクとして表示される場合があるため、画面上の見え方だけで判断しないことが重要です。(Microsoft Learn)
Microsoft 365 Copilot Workflowsとは何か
Microsoft 365 Copilot Workflowsは、Microsoft 365 Copilot内のWorkflows agentを通じて、ユーザーが自然言語で業務フローを作成・編集・管理できる仕組みです。たとえば「毎週月曜にTeamsへ進捗確認を投稿して、Plannerのタスクを確認する」といった自動化を、ユーザーが説明文から生成できるようにするものです。(Microsoft Learn)
ただし、業務自動化である以上、作成者、接続情報、承認履歴、実行履歴、プロンプト、会話履歴など、個人データや業務データに関わる情報が含まれる可能性があります。そのため、退職者対応、GDPRなどのプライバシー対応、社内の個人データ削除依頼において、Workflows agentで作成されたフローもDSR対応の対象として扱う必要があります。
今回明確化された主な変更ポイント
2026年4月22日の更新は、単なる表記変更ではなく、管理実務に影響する内容です。特に、以下の4点はDSR対応手順書に反映すべきです。
| 更新ポイント | 実務上の意味 |
|---|---|
| 新しいMicrosoft 365 Copilot Workflows environmentがDSR対象として明記された | 既存のPower Automate画面だけを見ても、対象データを見落とす可能性がある |
| 専用環境のDSRはAPIベースと明記された | UI操作だけで完結する前提を改め、API実行手順を準備する必要がある |
| DSR用のRBACロールが提示された | 読み取り用、読み取り・削除用の権限設計を分けられる |
| PDE/既定環境向けのDataverseテーブルとAPIが整理された | 既存環境ではUI確認とAPI自動化を使い分けられる |
特に注意したいのは、新しいMicrosoft 365 Copilot Workflows environmentに対するDSRが「strictly API-based」とされている点です。つまり、管理者がPower PlatformやPower Automateの画面だけを確認して「対象データなし」と判断するのは危険です。(Microsoft Learn)
新しいMicrosoft 365 Copilot Workflows environmentの特徴
Microsoft 365 Copilot Workflows environmentは、一般的なPower Platform環境とは扱いが異なります。Microsoft公式ドキュメントでは、Workflows agentsの実行に必要なランタイム操作を支える特殊目的のPower Platform環境と説明されています。Copilotライセンスを持つユーザーがWorkflows agentsを初めて使うと、Power Platformがこの環境を自動作成します。(Microsoft Learn)
管理者が押さえるべき特徴は次のとおりです。
| 特徴 | 管理上の注意点 |
|---|---|
| テナントごとに1つ作成される | 部門ごと、ユーザーごとに作成される通常環境とは異なる |
| Power Platform admin centerの環境一覧やMakerポータルには表示されない | 通常の環境一覧だけで棚卸しを終えない |
| Workflows agentsで作成されたフローのみ格納される | 汎用的なアプリ、ボット、カスタムフロー作成用の環境ではない |
| 削除できない | 不要になったから環境ごと削除する、という運用はできない |
| テナント管理者はDSR export/deleteのための環境管理権限を持つ | DSR対応の責任範囲を管理者側で明確にする |
また、この環境には固定のDLPポリシーが適用されます。Microsoft Teams、Outlook、Planner、Approvals、SharePoint、AI action、AI promptなど、Workflows agentsで利用される一部コネクタ以外はブロックされると説明されています。一方で、テナントレベルや環境レベルのDLPポリシーは、この専用環境には適用されない点に注意が必要です。(Microsoft Learn)
DSR対応に必要なRBACロール
今回の更新では、Workflows agentのDSR対応に使うロール名とRole IDも示されています。ロールは大きく、読み取り中心のロールと、読み取り・削除まで行う管理者ロールに分かれます。
| 用途 | ロール名 | Role ID | 割り当てスコープ |
|---|---|---|---|
| DSRの読み取り操作 | Workflows agent Data Subject Rights Environment Reader | 38a014c1-0485-4e5e-b784-782ea373b34b | /tenants/{0}/environments/{1} |
| DSRの読み取り・削除操作 | Workflows Agent Data Subject Rights Administrator | 363ee124-fdb2-406f-9272-ebf239730ed2 | /tenants/{0} |
環境単位でエクスポート中心の対応を行う場合はReader、削除まで含むDSR対応ではAdministratorが必要になります。権限を広く付与しすぎると監査上のリスクが増えるため、実務では「DSR受付担当」「API実行担当」「削除承認者」を分け、必要な期間だけロールを付与する運用が望ましいです。(Microsoft Learn)
なお、Power Platform RBACの公式ドキュメントでは、このRBAC関連機能がプレビューとして扱われている箇所があります。プレビュー機能は仕様変更や制限があり得るため、本番運用に組み込む際は、対象テナントで利用可能か、監査ログや承認フローと整合するかを事前に確認してください。(Microsoft Learn)
管理者向け：DSR対応の実務フロー
Microsoft 365 Copilot WorkflowsのDSR対応では、最初にAPIを呼ぶのではなく、対象データの所在を切り分けることが重要です。次の流れで進めると、見落としを減らせます。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 受付 | 対象ユーザー、依頼種別、期限、対象地域を確認 | DSRチケット |
| 環境確認 | Power Platform admin centerのInventoryでユーザーのメールアドレスを検索 | Environment ID |
| 環境判定 | 専用Workflows environmentか、PDE/既定環境かを判定 | 対応ルートの決定 |
| 権限確認 | 必要なRBACロール、サービスプリンシパル、実行者を確認 | 権限付与記録 |
| エクスポート | DSR APIまたはDataverse/APIで対象データを取得 | エクスポート結果 |
| 削除・再割り当て | 削除、所有者変更、コピー、接続再作成などを実施 | 処理結果 |
| 記録 | 実行日時、担当者、API、対象Environment IDを保存 | 監査証跡 |
このフローで特に重要なのは、Environment IDをDSRチケットに残すことです。グローバル企業では、ユーザーの勤務地、テナントの既定リージョン、データ保存先が直感的に一致しないケースがあります。Microsoft 365 Copilot Workflows environmentは、組織のMicrosoft Entraテナントの既定リージョン、またはそれに近いリージョンにDataverse付きで作成されると説明されています。(Microsoft Learn)
専用環境ではAPIベースでエクスポート・削除する
Microsoft 365 Copilot Workflows environmentにあるDSRデータは、公式ドキュメント上でAPIベースの対応が前提とされています。Power Platform APIのDSR Complianceには、承認、接続、フロー、プロンプト、会話トランスクリプト、フロー実行アクション、実行履歴データなどを扱う操作が用意されています。(Microsoft Learn)
実務では、次のように準備しておくと対応が速くなります。
API対応前に準備するもの
| 準備項目 | 具体例 |
|---|---|
| サービスプリンシパル | DSR対応用のEntra IDアプリ登録を用意する |
| 認証情報 | 証明書またはクライアントシークレットを安全に管理する |
| RBAC割り当て | ReaderまたはAdministratorを必要なスコープに付与する |
| 実行ログ | API呼び出し日時、対象ユーザー、Environment ID、レスポンス概要を保存する |
| 承認フロー | 削除APIの実行前に法務・セキュリティ・業務部門の承認を取る |
削除処理は、単にAPIを実行すればよいわけではありません。対象フローが業務で使われている場合、削除によって通知、承認、Plannerタスク、SharePoint更新などが停止する可能性があります。削除要求であっても、業務影響を確認し、必要に応じて所有者変更やコピーを検討してください。
PDE/既定環境ではDataverseテーブルと環境スコープAPIを確認する
すべてのWorkflowsデータが新しい専用環境にあるとは限りません。PDEや既定環境にある場合、Microsoft公式ドキュメントでは、標準のPower Automate UIに表示されないDataverseエンティティがあるため、Power AppsまたはMakerポータルのTablesビューを使って確認する方法が示されています。(Microsoft Learn)
確認対象として挙げられている主なデータは次のとおりです。
| 対象データ | Dataverseテーブル |
|---|---|
| Process | Workflows |
| Process | AI Flows |
| ConnectionReference | Connections |
| AI Model | AI Prompts – AI Model |
| AI Configurations | AI Prompt Prompt Data |
| WorkflowMetadata | WorkflowMetadata |
| FlowRun | Flow Run |
| AI FlowRun | Flow Run |
| Approvals | Approvals |
Approvalsについては、28日間の自動削除保持ポリシーの対象とされています。DSR対応時に過去データが見つからない場合でも、単純に「取得漏れ」と判断せず、保持ポリシーや削除済みデータの扱いを確認する必要があります。(Microsoft Learn)
複数ユーザーや複数拠点のDSRを処理する場合は、UI確認よりも環境スコープAPIを使った一括処理が向いています。公式ドキュメントでは、会話トランスクリプト、フロー実行アクション、フロー実行、実行履歴カスタマーデータを環境スコープで取得するAPIが案内されています。(Microsoft Learn)
退職者対応では「削除」だけでなく「再割り当て」を検討する
DSR対応では、対象ユーザーのデータを削除する場面が多くあります。しかし、Workflows agentで作成されたフローが業務で使われている場合、即削除すると業務停止につながることがあります。
MicrosoftのPower Automate向けDSR削除ガイドでは、退職者や個人データ削除を要求したユーザーが広く使われているフローを作成していた場合、削除ではなくコピー、別所有者への割り当て、新しい接続の確立を検討する流れが示されています。コピー時には、元ユーザーへの個人識別子リンクを削除できると説明されています。(Microsoft Learn)
実務では、次の判断基準を使うとよいでしょう。
| 状況 | 推奨対応 |
|---|---|
| フローが個人作業用で、他ユーザーに影響しない | 削除を検討 |
| 部門の承認や通知に使われている | 所有者変更またはコピーを検討 |
| 接続が退職者アカウントに依存している | 新しい所有者で接続を再作成 |
| 法的削除要求があるが業務影響が大きい | 法務・セキュリティ・業務責任者で対応方針を決める |
| データ所在が不明 | InventoryでEnvironment IDを確認してから判断 |
職場ITチームと業務ユーザーが知っておくべきこと
Microsoft 365 Copilot Workflowsは、管理者だけの問題ではありません。業務ユーザーが自然言語で自動化を作れるようになるほど、作成者本人が「どの環境に何が保存されたか」を意識しないまま業務フローが増えていきます。
業務ユーザーに案内するなら、次の3点を明確にすると運用しやすくなります。
| 伝えること | 理由 |
|---|---|
| 業務で使うWorkflowsは個人用ではなくチーム資産として扱う | 退職・異動時に業務が止まるのを防ぐ |
| 重要なフローを作ったら管理者またはチームに共有する | DSRや障害対応時に所在を追跡しやすい |
| 削除依頼がある場合も勝手に削除せずITに相談する | 承認履歴、接続、実行履歴など周辺データが残る可能性がある |
特に、Microsoft 365 Copilot WorkflowsはPower Automateの通常画面にすべてが見えるとは限りません。「画面にないから存在しない」と判断しないことが、DSR対応の基本になります。
失敗しやすいポイント
Power Automateの画面だけで確認を終える
PDE/既定環境のWorkflows agent関連データは、標準のPower Automate UIに表示されないDataverseエンティティに保存される場合があります。Inventory、Dataverseテーブル、環境スコープAPIを組み合わせて確認する必要があります。(Microsoft Learn)
専用環境を通常環境と同じように扱う
Microsoft 365 Copilot Workflows environmentは、環境一覧やMakerポータルに表示されない特殊な環境です。削除もできず、固定DLPポリシーで管理されます。通常のPower Platform環境管理ルールをそのまま当てはめると、確認漏れや誤った運用判断につながります。(Microsoft Learn)
RBACロールを広く付与しすぎる
DSR対応には強い権限が必要ですが、削除権限を常時付与するのは避けるべきです。読み取り用のEnvironment Readerと、削除まで可能なAdministratorを分け、申請・承認・実行・記録の流れを明確にしておくことが重要です。(Microsoft Learn)
海外拠点のDSR期限を日本基準だけで管理する
グローバル企業では、GDPRなど地域ごとの要求期限や社内規程が異なる場合があります。Microsoft 365 Copilot Workflowsのデータ所在確認はテナントと環境単位で行い、DSRチケットには依頼元地域、対象ユーザー、期限、Environment ID、実行結果を残しておくと監査対応がしやすくなります。
今すぐ見直すべき運用チェックリスト
Microsoft 365 Copilot Workflowsを利用している組織は、次の項目をDSR運用手順に追加してください。
| チェック項目 | 完了の目安 |
|---|---|
| Power Platform admin centerのInventoryでWorkflows agentsを検索する手順を文書化した | 管理者が同じ手順でEnvironment IDを確認できる |
| 専用環境とPDE/既定環境の対応ルートを分けた | DSRチケットに「対応ルート」を記録できる |
| DSR用RBACロールの付与手順を用意した | ReaderとAdministratorを使い分けられる |
| API実行用のサービスプリンシパルを準備した | 手作業に依存せずエクスポートできる |
| 削除前の業務影響確認フローを作った | 重要な業務フローを誤って止めない |
| 実行ログと証跡の保存先を決めた | 監査時に説明できる |
| 業務ユーザー向けにWorkflows作成時の注意点を案内した | 退職・異動・削除依頼時の混乱を減らせる |
まとめ：Microsoft 365 Copilot WorkflowsのDSR対応はAPI前提で再設計する
2026年4月22日のMicrosoft公式更新で、Microsoft 365 Copilot WorkflowsのDSR対応は、より明確に「環境判定」と「API対応」を前提とする形になりました。特に、新しいMicrosoft 365 Copilot Workflows environmentにあるデータはAPIベースで扱う必要があり、RBACロール、Environment ID、DSR Compliance APIの準備が欠かせません。
管理者が次に取るべき行動は明確です。まず、既存のDSR手順書にMicrosoft 365 Copilot Workflowsを追加し、Power Platform admin centerのInventoryでEnvironment IDを確認する手順を標準化してください。そのうえで、専用環境向けのAPI実行体制、PDE/既定環境向けのDataverse確認手順、削除前の業務影響確認を整備しておくことが、見落としのないDSR対応につながります。
コメント