【Copilot Cowork セキュリティ 第3回】Microsoft Entra ID で実現する AI 時代のアクセス制御

はじめに

こんにちは、DXソリューション営業本部の土屋です。

社内 AI の導入や Copilot Cowork の活用が進む中、IT 管理者が最も配慮すべきことのひとつが、「データの過共有（情報漏えい）リスク」です。

Copilot Cowork は、ユーザーの代わりに複雑なタスクを進める AI エージェントです。だからこそ、「どのユーザーが、どの権限で、どのデータにアクセスできるのか」を、ユーザー側の ID 基盤で正しく制御できているかが、安全運用の重要なポイントになります。
こうした AI 時代のアイデンティティ管理を支える土台となるのが Microsoft Entra ID です。特に、ユーザーの認証・認可とアクセス条件を管理する基盤として、Copilot Cowork を安全に利用するための重要な防衛ラインになります。

Copilot Cowork の過共有を防ぐアプローチ

Copilot Cowork は、ユーザーがチャットからタスクを委任すると、そのユーザーの権限を借りて、SharePoint や Teams などのリソースへアクセスします。これは OBO（On-Behalf-Of）と呼ばれる動作です。
つまり、Copilot Cowork の安全性は「ユーザー側の ID と権限がどれだけ正しく整理されているか」で決まるということです。
この前提に立つと、Entra ID で実装すべき防衛ラインは大きく 2 つに整理できます。

1. アクセスレビュー
   データソース側の権限を最小化・棚卸しし、AI が参照できる情報の範囲を絞る。
2. 条件付きアクセス
   場所・デバイス・サインインリスクに応じて、Copilot Cowork へのアクセス自体を動的に制御する。

「データ側を絞る」と「入口を絞る」――この 2 軸を組み合わせることで、Copilot Cowork による過共有リスクを実用的なレベルまで抑え込むことができます。それぞれ詳しく見ていきましょう。

アクセスレビュー ― データソース権限の定期棚卸し

AI に社外秘データや本来参照すべきでない情報を見せないための最も本質的なアプローチは、Copilot Cowork が参照し得るデータソースのアクセス権を、常に「最小権限」に保ち続けることです。

Copilot Cowork は、ユーザーの権限を前提に Microsoft 365 上の情報へアクセスします。対象となるデータソースには、SharePoint、Teams、OneDrive など、業務で日常的に利用されるさまざまな場所が含まれます。
そのため、特定の SharePoint サイトだけでなく、Teams のチームメンバーシップ、Microsoft 365 グループ、セキュリティグループ、OneDrive や SharePoint へのアクセスに関係するグループ所属や共有設定など、データへ到達するための権限全体を棚卸しする視点が重要です。

ここで活躍するのが、Microsoft Entra ID のアクセスレビュー機能です。アクセスレビューを利用することで、特定のグループやアプリケーション、アクセスパッケージなどに対して、ユーザーが引き続きアクセス権を持つべきかを定期的に確認できます。

アクセスレビューを用いることで、以下のような権限管理を継続的に行えます。

■ 不要なデータアクセス権の定期的な見直し
データソースへのアクセス権を、Microsoft 365 グループやセキュリティグループなどに紐付けておき、そのグループに対して定期的なアクセスレビュー、つまり棚卸しを設定します。

業務変更、異動、プロジェクト終了、外部ユーザーとの協業終了などによってアクセスが不要になったユーザーをレビュー対象とし、不要と判断された場合は、グループから除外することで権限を整理できます。

たとえば、SharePoint サイトの閲覧権限、Teams チームへの参加権限、プロジェクト用 Microsoft 365 グループへの所属などを定期的に見直すことで、ユーザーに不要なデータアクセス権が残り続ける状態を防ぎます。


これにより、手作業では見落としがちな不要権限を継続的に削減できます。

■ AI が参照できる情報範囲の縮小
アクセスレビューによって不要なユーザーがグループから除外されると、そのユーザーは対象データソースへのアクセス権を失います。
その結果、Copilot Cowork がそのユーザーの権限で動作した場合でも、該当ユーザーがアクセスできないファイル、チーム、サイト、コンテンツは参照できません。

つまり、データソース側の権限を適切に整理することが、そのまま AI が参照できる情報範囲の制御につながります。
AI 経由で機密情報を参照しようとしても、そもそもユーザーに閲覧権限がなければ、Copilot Cowork もその情報を扱うことはできません。

このように、アクセスレビューは「AI に何を見せるか」を直接制御する機能というよりも、AI が利用する前提となるユーザーのデータアクセス権を継続的に正しく保つための仕組みです。
SharePoint、Teams、OneDrive などの各データソースに対して、不要な権限を残さない運用を続けることが、Copilot Cowork の過共有リスクを抑えるうえで非常に重要です。

条件付きアクセス ― 特定の条件で Copilot 利用を制御する

ユーザーのアクセス場所、利用端末、サインインリスクなどの条件に応じて、アクセス可否を動的に制御する仕組みが Microsoft Entra ID の条件付きアクセスです。

Copilot Cowork は、ユーザーの権限を前提に Microsoft 365 上の情報へアクセスします。
そのため、ユーザーがどのような環境から Copilot Cowork を利用しているのかを判定し、リスクの高い状況では利用を制限することが重要です。

条件付きアクセスを用いることで、通常業務では Copilot Cowork の利用を許可しつつ、リスクの高いアクセス条件ではブロックしたり、追加認証を要求したりする制御が可能になります。

■ リスクの高い状況での Copilot 利用を抑止
たとえば、以下のような条件を組み合わせて、Copilot Cowork の利用を制御できます。

・社外ネットワーク、または未許可 IP アドレスからのアクセス
・会社が管理していない端末、または準拠していない端末からの利用
・サインインリスクが高いと判定された場合
・特定の国や地域からのアクセス
・多要素認証や準拠端末など、組織が求めるアクセス条件を満たせない場合

このような条件を組み合わせることで、社内の通常業務環境では利便性を維持しながら、リスクの高い環境からの AI 利用を抑止できます。

★ 検証上の設計ポイント
条件付きアクセスで Copilot Cowork の利用を制御する場合、ポリシーの対象にするリソース設計が重要になります。

Copilot Cowork は、単一の画面や単一のアプリだけで完結するものではなく、裏側で複数の Microsoft 365 サービスや Copilot 関連の基盤サービスと連携しながら動作しています。
そのため、条件付きアクセスの対象リソースとして Copilot Cowork のみを指定した場合、環境や呼び出し経路によっては、期待したタイミングでアクセス制御が適用されないケースがあります。

対象リソースを適切に設計することで、未許可のネットワークや非準拠デバイスからの利用など、制限したいアクセスをより明確に制御できます。
条件付きアクセスは、Copilot Cowork の利用を制御するうえで有効な手段ですが、期待通りにブロックできているかどうかは、実際の操作画面で検証することが重要です。

適切にポリシーが適用されると、条件に該当するアクセスは以下のようにブロックされます。

前章のアクセスレビューが「AI に見せるデータ範囲を絞る」対策だとすれば、条件付きアクセスは「リスクの高い入口から AI を使わせない」ための対策です。
この 2 つを組み合わせることで、Copilot Cowork の利便性を活かしながら、過共有や不適切な利用のリスクを現実的に抑えることができます。

補足：Microsoft Entra Agent ID はどこで関係するのか

ここまで見てきたように、Copilot Cowork の安全運用でまず重要になるのは、ユーザー側の権限管理です。
つまり、アクセスレビューでデータソース側の権限を整理し、条件付きアクセスでリスクの高い利用経路を制御することが基本になります。

一方で、AI エージェントのセキュリティを考えるうえで、Microsoft Entra Agent ID という考え方も登場します。
Agent ID は、AI エージェントに対して ID を付与し、ユーザーやアプリケーションと同様に ID 基盤の中で管理していくための考え方です。
ただし、Copilot Cowork のようにユーザーがチャットから操作する対話型のエージェントでは、必ずしも Agent ID を制御の中心として考えられるとは限りません。

Copilot Cowork では、ユーザーがエージェントに指示を出すと、エージェントはそのユーザーの権限を前提に SharePoint や Teams などへアクセスします。
これは OBO（On-Behalf-Of）と呼ばれる動作で、アクセスの主体は、エージェント自身ではなく、操作しているユーザーとして扱われます。
そのため、対話型の Copilot Cowork を安全に使ううえでは、Agent ID だけを見て制御しようとするのではなく、ユーザーの ID、条件付きアクセス、データソース側の権限管理を中心に設計することが重要です。

Agent ID がより重要になるのは、人が毎回チャットで操作するのではなく、バックグラウンドで自律的に処理を行うようなエージェントを設計する場面です。
たとえば、社内システムやワークフローから自動実行されるカスタムエージェントでは、エージェント自身の ID をどのように管理し、どのリソースへアクセスさせるかが重要な設計ポイントになります。

つまり、本記事で扱っている Copilot Cowork の過共有対策においては、Agent ID は補足的に理解しておきたい要素です。
まず優先すべきは、ユーザーに不要なデータアクセス権を残さないこと、そしてリスクの高い条件では Copilot Cowork の利用を制御できるようにすることです。
この前提を押さえたうえで、将来的に自律型エージェントを設計する場合には、Agent ID による管理も検討していく、という整理が現実的です。

終わりに

Copilot Cowork を安全に活用するうえで重要なのは、AI そのものを特別扱いして制御しようとすることではなく、まずユーザー側の ID とデータ権限を正しく管理することです。

Copilot Cowork は、ユーザーの権限を前提に SharePoint、Teams、OneDrive などの情報へアクセスします。
そのため、不要な権限が残ったままでは、AI 経由で本来見せるべきではない情報が参照されるリスクがあります。

このリスクを抑えるために有効なのが、Microsoft Entra ID のアクセスレビューと条件付きアクセスです。
アクセスレビューによって、SharePoint、Teams、OneDrive などのデータソースへ到達する権限を定期的に棚卸しし、不要なアクセス権を削減する。
そして条件付きアクセスによって、場所、デバイス、サインインリスクなどに応じて Copilot Cowork の利用を制御する。

この「データ側を絞る」と「入口を絞る」という 2 つの対策を組み合わせることで、Copilot Cowork の利便性を活かしながら、過共有リスクを現実的に抑えることができます。

Agent ID は今後の自律型エージェント管理において重要な考え方ですが、少なくとも対話型の Copilot Cowork では、まずユーザー ID とデータ権限の管理を徹底することが安全運用の出発点になります。