Microsoft Purviewの「Insider Risk Management for agents」は、AIエージェントを人間の内部関係者と同じようにリスク管理の対象へ広げる重要な更新です。結論から言うと、管理者はAIエージェントの棚卸し、Microsoft 365 E7またはAgent 365のライセンス確認、DSPMのAI observability、Insider Risk Managementポリシー、監査ログ、DLP、権限設計を早めに確認する必要があります。Microsoft 365 Roadmap ID 516032では、AIエージェントが企業データへアクセスし、操作し、意思決定に近い動作を行う前提で、エージェント向けのリスク指標とリスクスコアをInsider Risk Managementに拡張する内容が示されています。(Microsoft)
Microsoft PurviewのInsider Risk Management for agentsとは
Microsoft Purview: Insider Risk Management-Insider risk management for agentsは、従来は主にユーザーの内部リスクを検知・調査するために使われてきたMicrosoft Purview Insider Risk Managementを、AIエージェントの活動にも拡張する機能です。
AIエージェントは、単なるチャットボットやワークフロー自動化を超え、ユーザーの意図を解釈し、SharePoint、OneDrive、Teams、Exchange、業務アプリなどの企業データへアクセスし、場合によってはユーザーの代わりに処理を実行します。そのため、情報漏えい、権限過多、機密データの過剰共有、不適切な外部送信といったリスクは、人間の従業員だけでなくエージェントにも発生します。
今回の更新では、AIエージェントの活動をもとにした専用のインジケーターやリスクスコアを使い、知的財産の持ち出し、データ漏えい、セキュリティ違反などの兆候を相関分析できるようにすることが主な狙いです。Roadmap API上では、プレビューが2025年12月、一般提供が2026年6月予定、対象はWorldwideのWeb版Microsoft Purviewとして掲載されています。(Microsoft)
今回の変更点
今回のポイントは、「AIエージェントを管理する画面が増えた」というだけではありません。企業データへアクセスするエージェントを、監査・DLP・リスク分析・ポリシー適用の対象として扱う方向へMicrosoft Purviewが拡張されます。
| 観点 | 従来の中心 | 今回の更新後に意識すべきこと |
|---|---|---|
| リスク管理の対象 | 従業員、契約社員、管理者などのユーザー活動 | AIエージェントのアクセス、操作、会話、ツール実行も確認対象になる |
| 検知の考え方 | ユーザーのファイル操作、共有、DLPアラート、異常行動 | エージェント固有の活動からリスクシグナルとスコアを評価する |
| 管理画面 | Insider Risk Management、DLP、監査ログなどを個別に確認 | DSPMのAI observabilityやApps and agentsからエージェントの状態を確認する |
| ポリシー | 人間ユーザーやグループを中心にスコープ設定 | エージェントインスタンスをユーザーのようにポリシーへ含める設計が必要 |
| 調査 | ユーザー、ファイル、アラートを起点に調査 | エージェント所有者、実行内容、アクセスデータ、会話・ツール呼び出しを合わせて確認する |
MicrosoftのMessage Center情報では、DSPM – AI ObservabilityとInsider Risk Management for agentsは、プレビューから一般提供へ移行し、Microsoft 365 E7またはAgent 365のサブスクリプションを持つ管理者が、AIエージェント活動の監視、リスクのある行動の特定、組織ポリシーに沿ったガバナンス適用を行えるようになるとされています。一般提供のロールアウトは、更新後の案内では2026年6月中旬から7月末にかけてWorldwideで進む予定です。(Microsoft 365 Message Center Archive)
影響を受ける組織
影響が大きいのは、すでにAIエージェントを業務に組み込んでいる組織、またはこれから展開する組織です。特に、エージェントが社内文書、顧客情報、営業資料、設計情報、契約書、ソースコード、財務データなどにアクセスする場合は、単なる利便性向上施策ではなく、データセキュリティ施策として扱う必要があります。
Microsoft Learnでは、Microsoft 365 Copilot agents、Microsoft Security Copilot agents、Copilot Studio agents、Entra-registered agents、Microsoft Foundry agents、ChatGPT Enterprise agentsなど、複数のAIエージェント種別に対してMicrosoft Purviewのデータセキュリティやコンプライアンス管理の対応状況が整理されています。特にMicrosoft Copilot Studio agentsやMicrosoft Foundry agentsでは、データ分類、秘密度ラベル、DLP、Insider Risk Managementの対応が示されています。(Microsoft Learn)
影響が大きいケース
次のいずれかに当てはまる組織は、早めに設定確認を始めるべきです。
- Copilot StudioやMicrosoft 365 Copilot agentsを本番業務で使っている
- エージェントがSharePoint、OneDrive、Teams、Exchangeのデータを参照する
- エージェントに外部サービスや社内APIを実行させている
- AIエージェントの利用部門が増えており、誰が何を作ったか把握しにくい
- DLP、秘密度ラベル、Insider Risk Managementをすでに運用している
- 監査、法務、情報システム、セキュリティ部門がAI利用状況の説明責任を負う
影響が限定的なケース
現時点で企業データへアクセスするAIエージェントを使っていない組織では、すぐに業務影響が出る可能性は高くありません。ただし、Microsoft 365 Copilot、Copilot Studio、Agent 365の導入を計画している場合は、導入後に慌てて監査やポリシーを整えるのではなく、先にエージェントの管理方針を決めておくほうが安全です。
管理者が最初に確認すべき設定
Microsoft PurviewでAIエージェントのリスクを管理する場合、最初に見るべきなのは「どの機能をオンにするか」ではなく、何を監視対象にし、誰が確認し、どの状態をリスクと判断するかです。
| 確認項目 | 確認する内容 | 実務上のポイント |
|---|---|---|
| ライセンス | Microsoft 365 E7またはAgent 365の利用可否 | テナントにSKUがあるだけでなく、必要なユーザーへ割り当てられているか確認する |
| 監査ログ | Microsoft Purview Auditが有効か | Copilotやエージェントの会話・操作を追跡する前提になる |
| エージェント一覧 | どのエージェントが存在し、誰が所有しているか | 不明なエージェントや放置されたエージェントを洗い出す |
| DSPM | DSPM > AI observabilityで活動が見えるか | リスクの高いエージェント、過剰共有、外部流出につながる動きを見る |
| IRMポリシー | エージェントをポリシー対象に含めているか | 人間ユーザーだけを対象にした既存ポリシーでは漏れが出る |
| DLPポリシー | エージェント経由の共有・送信を検知または制御できるか | ブロック時に後続ワークフローへ影響が出るため、所有者への通知も必要 |
| 秘密度ラベル | 暗号化ラベルや権限設定がエージェント利用と矛盾しないか | エージェントに必要以上のVIEW/EXTRACT権限を与えない |
| RBAC | 誰がアラートや調査情報へアクセスできるか | グローバル管理者に頼らず、最小権限で役割を分ける |
Microsoft Learnでは、Agent 365のエージェントインスタンス作成時に、監査、機密データ検出、AI規制向け評価が自動的に有効化され、その他の機能ではエージェントインスタンスをユーザーのようにポリシーへ含める考え方が示されています。また、Agent 365向けの開始手順として、Microsoft Purviewポータルの「DSPM > AI observability」へ進み、過去30日の活動があるエージェント、リスクレベル、推奨される修復策を確認する流れが案内されています。(Microsoft Learn)
DSPMとAI observabilityで見るべきポイント
AIエージェントの管理では、まずDSPMのAI observabilityを入口にするのが現実的です。個別の監査ログを最初から追うより、どのエージェントが高リスクなのか、どのアクティビティが目立つのかを把握しやすいためです。
確認すべき観点は、主に次の3つです。
| 観点 | 見るべき内容 | 判断基準の例 |
|---|---|---|
| 過剰共有 | エージェントが必要以上のファイルやサイトへアクセスしていないか | 部門外の機密サイト、全社公開された機密ファイルへのアクセスが多い |
| 外部流出 | 機密情報が外部サービス、外部ユーザー、非承認アプリへ渡っていないか | 顧客情報、契約書、技術資料が外部連携先へ送られている |
| 不適切な動作 | 倫理・コンプライアンス上問題のある会話や操作がないか | 機密情報の要約、競合情報の不適切利用、ポリシー回避を促す指示がある |
ここで重要なのは、AI observabilityの結果を「検知して終わり」にしないことです。リスクが高いエージェントが見つかったら、エージェントの所有者、利用部門、参照データ、実行できるアクション、DLPや秘密度ラベルの適用状況まで確認します。
Microsoft Learnでは、現在のDSPMは従来のDSPM for AIやDSPMの機能を統合した新しい中心的なソリューションとして説明されており、Apps and agents、Activity explorerのAI activities、Data risk assessmentsなどの移行先も整理されています。(Microsoft Learn)
Insider Risk Managementポリシーで確認すべきこと
Insider Risk Management for agentsを使う場合、既存の人間向けポリシーをそのまま流用するだけでは不十分です。AIエージェントは、人間と違って短時間に大量のデータへアクセスしたり、複数のツールを連続実行したりするため、しきい値やスコープの考え方を変える必要があります。
ポリシー作成前に決めること
まず、次の内容を管理者、セキュリティ担当、法務・コンプライアンス担当、業務部門で決めておきます。
- どのエージェントを監視対象にするか
- どのデータを高リスクとみなすか
- どの操作をアラート対象にするか
- アラート確認者と調査担当者を誰にするか
- エージェント所有者へどのタイミングで連絡するか
- 誤検知だった場合のクローズ基準をどうするか
Microsoft Learnでは、Agent 365のInsider Risk Management連携について、エージェントインスタンスをユーザーと同じようにポリシーへ明示的に指定でき、データ流出などの組み込みトリガーイベントをサポートすると説明されています。(Microsoft Learn)
既存ポリシーの見直しポイント
既存のInsider Risk Managementポリシーがある場合は、次を確認します。
| 既存設定 | 見直しポイント |
|---|---|
| 対象ユーザー | 人間ユーザーだけでなく、エージェントインスタンスや関連グループを含める必要があるか |
| DLP連携 | 高重要度DLPアラートがIRMで正しく扱われる設定になっているか |
| アラートしきい値 | エージェントの高速処理によってアラートが過剰発生しないか |
| 優先ユーザー | 重要データへアクセスする部門・役職・エージェント所有者を考慮しているか |
| 調査フロー | エージェントの所有者、作成者、実行ユーザーを切り分けられるか |
Insider Risk Managementでは、監査ログ、権限、インジケーター、ポリシー、DLP連携などの前提設定が重要です。Microsoft Learnでも、監査を有効にすること、適切なロールグループへ割り当てること、ポリシーインジケーターを選ぶこと、DLPとIRMの対象ユーザーを正しく揃えることが推奨されています。(Microsoft Learn)
DLP・秘密度ラベル・監査ログの注意点
AIエージェントのリスク管理では、Insider Risk Managementだけを見ても十分ではありません。エージェントはファイル、メール、チャット、API、外部サービスを横断するため、DLP、秘密度ラベル、監査ログと組み合わせて初めて実効性が出ます。
DLPは「ブロックした後」まで設計する
Microsoft Learnでは、Agent 365のDLPについて、エージェントインスタンスをDLPポリシーへユーザーのように明示的に指定できる一方、エージェント自身はブロック動作を認識しないため、エージェント所有者がポリシーの影響を監視する必要があると説明されています。(Microsoft Learn)
これは実務上かなり重要です。たとえば、営業支援エージェントが提案書を自動生成する処理で、DLPにより顧客情報の外部送信がブロックされたとします。このとき、人間なら画面の警告を見て対応できますが、エージェントは後続処理を失敗したまま進める可能性があります。
そのため、DLPポリシーを作るときは次を決めておきます。
- ブロック時に誰へ通知するか
- エージェントの実行ログとDLPアラートをどう紐づけるか
- 業務影響が大きい場合は警告から始めるか、即ブロックするか
- 例外申請を誰が承認するか
- 誤検知時にポリシーをどう調整するか
秘密度ラベルはエージェントの権限とセットで見る
Agent 365の文書では、エージェントインスタンスがファイルへアクセスするには明示的な共有が必要であり、暗号化された秘密度ラベルがある場合は、エージェントにVIEWとEXTRACTの使用権限を明示的に与える必要があるとされています。また、Agent 365が新しく作成したコンテンツは、ソースアイテムの秘密度ラベルを自動継承しない点にも注意が必要です。(Microsoft Learn)
つまり、「ラベルを設定しているから安心」ではありません。エージェントが作成した出力ファイル、要約文、メール下書き、添付ファイルに、どのラベルを付けるかを別途設計する必要があります。
開発者・エージェント所有者が確認すべき実装上の注意点
管理者だけでなく、AIエージェントを作る開発者や業務部門のエージェント所有者も確認すべき点があります。特にカスタムエージェントや外部連携エージェントでは、可観測性のためのテレメトリが正しく送られていないと、PurviewやDefender側で期待どおりに活動が見えません。
テレメトリが見えない原因を先に潰す
Agent 365の可観測性ドキュメントでは、エージェントコードから送られたテレメトリが、Microsoft Defender、Microsoft Purview、Microsoft 365管理センターに流れる構造が説明されています。データはinvoke_agentなどの有効なスパンに依存し、Microsoft Purviewではエージェント実行に対してDLP、保持、通信コンプライアンスなどのポリシールールを構成できます。(Microsoft Learn)
開発者は、少なくとも次を確認してください。
| 確認項目 | 失敗しやすいポイント |
|---|---|
| Entra登録 | エージェントIDとアプリIDが一致せず、403 Forbiddenになる |
| 権限・同意 | テナント管理者の同意がなく、必要なロールやスコープがトークンに入らない |
| スパン属性 | gen_ai.operation.nameが欠落し、データが下流に表示されない |
| ライセンス | テナント内にMicrosoft 365 E7またはMicrosoft Agent 365の割り当てユーザーがなく、リクエストが取り込まれない |
| 検証 | HTTP 200 OKだけを見て「取り込み成功」と誤解する |
| サイズ・レート制限 | 1MB超過や429へのリトライ設計がない |
特に注意したいのは、HTTP 200 OKが返っても、下流の画面にデータが表示される保証にはならない点です。ドキュメントでは、ライセンス割り当てがない場合にリクエスト全体が通知なしで破棄されるケースや、200 OKは取り込み成功の証拠ではないことが明記されています。(Microsoft Learn)
展開時のおすすめ手順
本番展開では、いきなり全エージェントを対象に厳しいポリシーを適用するより、リスクの高いエージェントから段階的に進めるほうが安全です。
| フェーズ | 実施内容 | 成功条件 |
|---|---|---|
| 棚卸し | 利用中・開発中のAIエージェントを一覧化する | 所有者、用途、参照データ、実行権限が分かる |
| 可視化 | DSPM > AI observabilityで活動を確認する | 高リスク活動や過剰共有の傾向を説明できる |
| ポリシー設計 | IRM、DLP、秘密度ラベル、監査の方針を決める | どの操作で警告・ブロック・調査するか決まっている |
| パイロット | 重要データへアクセスする一部エージェントで検証する | 誤検知、業務影響、通知フローを確認できる |
| 本番展開 | 対象部門・対象エージェントを広げる | アラート対応者とエージェント所有者が運用できる |
| 定期見直し | 月次または四半期でポリシーを調整する | 新しいエージェントや利用増加に追随できる |
最初の対象としては、全社で使う汎用エージェントよりも、機密データに触れるエージェントを選ぶのがおすすめです。たとえば、契約書レビュー、顧客対応、営業提案、財務分析、ソースコード要約、人事関連問い合わせなどは、アクセスするデータの重要度が高く、ポリシー設計の効果を確認しやすい領域です。
失敗しやすいポイント
AIエージェント管理でよくある失敗は、技術設定よりも運用設計の抜けです。機能を有効にしても、対象範囲や責任者が曖昧なままでは、アラートが出ても対応できません。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| エージェントの所有者が不明 | アラートが出ても確認先がない | 作成時に所有者、代替担当、利用部門を登録する |
| ライセンスを購入しただけで満足する | テレメトリや管理機能が期待どおり動かない | 対象ユーザーへの割り当てまで確認する |
| 既存IRMポリシーだけで対応する | エージェント活動がスコープ外になる | エージェントインスタンスを明示的に対象へ含める |
| DLPを即ブロックにする | 業務フローが止まり、原因調査が難しくなる | 重要度に応じて監査、警告、ブロックを段階化する |
| 暗号化ラベルを過信する | エージェントが必要以上にアクセスできる、または必要な処理ができない | VIEW/EXTRACT権限と出力物のラベル付けを設計する |
| リスクスコアだけで判断する | 誤検知や文脈不足で過剰対応になる | ログ、データ内容、所有者確認を含めて調査する |
Microsoftは、Insider Risk Managementのインサイトだけに依存せず、組織側で完全な調査を行う必要があると説明しています。また、利用にあたっては、個人識別や是正措置に関係する法令を含め、適用される法律への準拠は顧客側の責任である点も明記されています。(Microsoft Learn)
プライバシーと権限設計の注意点
Insider Risk Management for agentsを導入すると、エージェント活動だけでなく、そのエージェントを使ったユーザーや関連するデータの調査も可能になります。便利な一方で、アクセスできる担当者を広げすぎると、プライバシーや内部統制上の問題につながります。
Microsoft PurviewのInsider Risk ManagementとCommunication Complianceは、プライバシー・バイ・デザインとして、仮名化、ロールベースアクセス制御、管理者による明示的なオプトイン、監査ログを中核原則にしています。さらに、既定ではグローバル管理者がInsider Risk ManagementやCommunication Complianceの機能へアクセスできない設計になっており、必要な担当者だけが役割に応じてアクセスすることが推奨されています。(Microsoft Learn)
実務では、次のように役割を分けると運用しやすくなります。
| 役割 | 主な担当 |
|---|---|
| Purview管理者 | 機能有効化、ロール割り当て、全体設定 |
| Insider Risk Management管理者 | ポリシー作成、インジケーター設定、しきい値調整 |
| アナリスト | アラート確認、一次トリアージ |
| 調査担当 | ケース調査、証跡確認、関係者ヒアリング |
| エージェント所有者 | 業務影響の確認、エージェント設定の修正 |
| 法務・コンプライアンス | 調査基準、通知方針、規程との整合性確認 |
いま取るべき次のアクション
Microsoft PurviewのInsider Risk Management for agentsは、AIエージェントの普及に合わせて、データセキュリティと内部リスク管理の対象を広げる更新です。管理者が最初にやるべきことは、機能名を追いかけることではなく、自社のどのエージェントが、どのデータへ、どの権限でアクセスしているかを見える化することです。
まずは次の順番で進めてください。
- 利用中・導入予定のAIエージェントを棚卸しする
- Microsoft 365 E7またはAgent 365のライセンス割り当てを確認する
- Microsoft Purview Audit、DSPM、AI observabilityで活動が見えるか確認する
- Insider Risk Managementポリシーにエージェントを含める設計を行う
- DLP、秘密度ラベル、RBAC、監査ログを合わせて見直す
- 高リスクエージェントからパイロット展開し、アラート量と業務影響を調整する
AIエージェントは業務効率化の強力な手段ですが、企業データに触れる以上、管理対象としては「便利なツール」ではなく「デジタルな内部関係者」と考えるべきです。Microsoft Purviewの更新を機に、エージェントの利用状況、権限、監査、リスク対応を一体で見直しておくことが、今後の安全なAI活用につながります。
コメント