AIエージェントに「権限」をどう与え、統制するか｜Entra Agent IDとCopilot Studioの権限モデル
AIエージェントに仕事を任せるとき、そのエージェントは「誰の権限」で動いているのか——この問いに答えられないまま自律的に動くエージェントを増やすと、情報統制に穴が空きます。人間の従業員に社員アカウントを与え、権限を絞り、退職時に無効化するのと同じ管理を、AIエージェントにも適用する仕組みが「Microsoft Entra Agent ID」です。本記事では、AIエージェントに権限をどう与え、どう統制するかを、Copilot Studio と Copilot Cowork の権限モデルの違いを入り口に、実務目線で整理します。
株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIエージェント・AIプライベート）の支援を提供しているIT企業です。本記事は、AIエージェントを「導入する」段階のガイド「企業におけるAIエージェント活用の始め方」から一歩進み、エージェントを「安全に統制する」ための土台となる考え方を扱います。
そのエージェントは「使う人の権限」で動くのか、「自身の権限」で動くのか
AIエージェントの権限を考えるうえで、最初に押さえるべき分岐があります。エージェントが「使う人の権限の範囲」で動くのか、それとも「エージェント自身に与えられた権限」で動くのか——この違いです。同じ Microsoft のAI機能でも、ここが対照的です。
| 観点 | Copilot Cowork（使う人の権限で動く） | Copilot Studio の自律エージェント（自身の権限で動く） |
|---|---|---|
| 誰の権限で動くか | 使う本人の権限。本人が見られないものはエージェントも見られない | エージェントに与えられた権限。以後の利用者はエージェントの権限を借りる形になり得る |
| 典型的な用途 | 本人の作業を代行・支援する（自分の代わりに調べる・まとめる） | 不特定多数向けの受付・自律処理（社内問い合わせ対応など） |
| 権限のはみ出しリスク | 低い（本人の権限を超えない） | 設計次第で高くなる（過剰権限・なりすまし） |
| 必要になる統制 | 既存の利用者統制がそのまま効く | エージェント自身を「アイデンティティ統制」の対象にする必要がある |
Microsoft 365 Copilot の Copilot Cowork は、使う人の権限の範囲でのみ動きます。本人が開けないファイルは Cowork も開けず、秘密度ラベルや監査設定もそのまま引き継がれます。既存の利用者向けの統制が、そのまま効く世界です。
一方、Copilot Studio で作る自律型のエージェント——たとえば「社員なら誰でも使える問い合わせ対応エージェント」——は、エージェント自身に与えた権限で動く設計にできます。ここで「そのエージェントは何にアクセスできるのか」「誰が責任を持つのか」を管理しないと、人間には決して許さないような広い権限を持ったまま、無数のエージェントが社内に増えていくことになります。この“エージェント自身の権限”を人と同じように統制するために生まれたのが、Microsoft Entra Agent ID です。
なぜAIエージェントに「自身のID」が必要になったのか
これまでのAIエージェントは、外部のツールやコネクタを使って各システムにアクセスし、その認証は「ツール側のID」や「サービスプリンシパル（アプリ用のアカウント）」に依存していました。つまり、エージェント本体には固有の身元がなく、何が・どの権限で動いたのかを人単位・エージェント単位で追いにくい状態でした。
AIエージェントは、人間の従業員とは異なる性質を持ちます。Microsoft の説明を借りれば、エージェントは自動化やユーザー操作、API連携によって動的に生成され、特定のタスクのために数分だけ存在することもあれば、1日に何千回も作られては消えることもあります。こうした「人ではないが、権限を持って動く存在」を、Microsoft は非人間アイデンティティ（nonhuman identity）と呼び、人間のIDと同じ統制の枠組みに載せようとしています。その中核が Microsoft Entra Agent ID です。
Microsoft Entra Agent ID とは何か
Microsoft Entra Agent ID は、Microsoft Entra ID の認証・認可・ガバナンスの仕組みを、AIエージェントにまで拡張する枠組みです。エージェントに「アイデンティティ（身元）」を持たせ、人間のユーザーやアプリと同じように、認証・アクセス制御・ライフサイクル管理・監査の対象にします。
技術的には、エージェントのアイデンティティは Microsoft Entra ID 上の特殊なサービスプリンシパルとして表現されます。Entra Agent ID では、これを支える4種類のオブジェクトが導入されました。少し専門的ですが、統制を理解するうえで重要な骨格です。
| オブジェクト | 役割 |
|---|---|
| エージェントIDブループリント (agent identity blueprint) | エージェントIDを作るためのテンプレート（設計図）。ここに共通の権限やポリシーを定義しておくと、そこから作られる個々のエージェントIDに一貫して適用できる |
| ブループリントプリンシパル (blueprint principal) | ブループリントを各テナントで実体化させたもの。マルチテナント対応アプリがテナントごとにサービスプリンシパルを持つのと同じ発想 |
| エージェントID (agent identity) | 個々のエージェントの身元そのもの。固有のオブジェクトIDと表示名を持ち、Entra管理センターやTeams・Outlookなどに現れる。自前の認証情報は持たず、ブループリント経由でトークンを取得して動く |
| エージェントユーザー (agent user) | エージェントIDに紐づく「ユーザー的な」身元。エージェントIDやエージェントユーザーごとに、異なるアクセス権を割り当てられる |
ポイントは、ブループリント（設計図）から個々のエージェントIDを作り、権限やポリシーを親から子へ継承させるという構造です。これにより、大量のエージェントに対して一貫したセキュリティポリシーを適用し、不要になったエージェントを、権限の割り当てを残したまま放置する（＝孤児化する）ことなく退役させられます。認証には OAuth 2.0 のほか、エージェント間連携のための MCP（Model Context Protocol）や A2A（Agent-to-Agent）といった標準プロトコルにも対応します。
また、Entra Agent ID は Microsoft 製のエージェントに限りません。AWS Bedrock や n8n など他社プラットフォームで作られたエージェントも、Auth SDK（サイドカー）やワークロードID連携を通じて、同じガバナンスの傘の下に置けるという点も、統制の観点では重要です。どこで作られたエージェントであっても、統制された一つのIDを与えられます。
権限の2系統：OBO（利用者の権限）と共有接続（自律型）
Copilot Studio のエージェントを例に、権限の与え方には大きく2つの系統があることを見ていきます。この違いは、監査ログの残り方に直結するため、統制設計の要になります。まず前提として、Copilot Studio のエージェントは、作成した時点で自動的にエージェントIDが割り当てられます（公開時ではなく、作成時です）。手動でのアプリ登録やSDK設定は不要です。
① OBO（オンビハーフオブ）｜利用者の権限で動く
Copilot Studio の多くのコネクタは、OBO（on-behalf-of／代理）認証を使います。これは、エージェントが使っている利用者本人の権限で動く方式です。利用者は最初にコネクタを使うとき同意を求められ、以後はプラットフォームが接続とトークン更新を自動で管理します。
統制上の最大の利点は、監査ログに「利用者本人が行った操作」として記録され、そこにエージェントの文脈（どのエージェント経由か）も併記される点です。誰の権限で・どのエージェントが・何をしたかを、後から追跡できます。人がやったのと同じ足跡が残るため、統制と相性が良い方式です。
② 自律型（サービス接続）｜共有の接続で、不特定多数に対して動く
もう一方は、コネクタの接続を特定の利用者に紐づけず、エージェントに用意した共有の接続で動かす方式です。社員なら誰でも使える問い合わせ対応のような、自律型・不特定多数向けのエージェントで使われます。ここで一点、誤解しやすいので正確に整理します。エージェント自身の Microsoft Entra 上の認証は、この方式でも必ずログに記録されます（Entra管理センターで「AIエージェントによる認証」として確認できます）。「エージェントの活動が一切追えなくなる」わけではありません。
統制上の論点は、その一段手前のコネクタ接続のレイヤーにあります。OBOのように利用者本人の権限で動く場合と違い、共有の接続で動かすと、「その操作を実際にどの利用者が引き起こしたか」という利用者単位の紐づけが失われます。便利な反面、過剰権限やなりすましのリスク管理を別途しっかり行う必要があるということです。だからこそ、次章のガバナンスで「エージェント自身を統制の対象にする」ことが効いてきます。
公開時に権限がAgent IDへ紐づく
- 付与されるのは「コネクタを使える」スコープ
公開すると、そのエージェントが使う各コネクタぶんのAPI権限が Entra Agent ID に付与され、管理者は Microsoft Entra 管理センターで確認できます。これは「そのコネクタを使える」という範囲のスコープであって、メール本文やファイルそのものを読み取る（Mail.Read）ような生のリソース権限ではありません。 - IDを盗まれても、直接は悪用されにくい
実行時に Power Platform 側で高度なコネクタポリシー（ACP）とDLPが毎回再検証するため、仮に攻撃者がエージェントのIDを奪っても、そのスコープで Microsoft Graph や Outlook を直接叩くことはできません。 - トークンは誰も勝手に発行できない
テナント内の誰も（管理者であっても）このエージェントIDのトークンを発行できません。認証の仕組みは、Microsoft が管理する共有ブループリントが握っています。なお、これらの権限は条件付きアクセスの対象にもできますが、実行時の効き方には現時点で制約があります（後述の「正直な注意」をご覧ください）。
なお、Copilot Studio のアプリベースのエージェントは、テナント内で単一の共有ブループリントを使う設計です。権限は Power Platform 管理センターのレベルでまとめて管理され、DLP（情報漏洩対策）ポリシーや高権限コネクタのポリシーが自動的に適用されます。個々のエージェントごとにブループリントを設定する必要はありません。
どう統制するか｜エージェントを「人と同じ」ガバナンスに載せる
Entra Agent ID の本質は、人間のIDに対して行ってきた統制を、そのままエージェントに適用できることにあります。人の入退社管理・権限の最小化・アクセスの棚卸しを、エージェントにも行う——その主な手立てを整理します。
| 統制の手立て | 内容 |
|---|---|
| スポンサー（責任者）の割り当て | 各エージェントIDに、ライフサイクルとアクセスに責任を持つ人間のスポンサーを割り当てる。スポンサーが退職する場合、スポンサー権はそのマネージャーへ自動的に引き継がれ、常に誰か人間が責任を持つ状態を保つ |
| 条件付きアクセス | アクセスの「条件」を制御する。エージェントの文脈やリスク（ID Protection によるリスク評価を含む）を評価してからアクセスを許可する。ブループリント単位で適用すれば、そこから作られる全エージェントIDが継承する |
| アクセスパッケージ（最小権限） | エージェントに必要なリソース（セキュリティグループ、アプリのAPI権限、Entraロール）を、期限付きで割り当てる。期限が近づくとスポンサーに通知が届き、延長（再承認）するか、失効させるかを選ぶ。放置すれば自動で失効し、不要な権限が残らない |
| ライフサイクル管理 | My Account／My Access ポータルから、エージェントの有効化・無効化や、アクセス・活動状況の確認ができる。不要になったエージェントを、権限を残したまま放置しない |
| リスク検知（ID Protection） | リスクの高いエージェントを検知し、条件付きアクセスと連動させて、リスクに応じてアクセスを止める・追加認証を求める |
| 監査ログ | エージェントの認証と活動はすべてログに記録され、コンプライアンス・監査に使える |
とりわけ実務で効くのが、スポンサーと期限付きのアクセスパッケージの組み合わせです。「作ったが誰も責任を持たず、広い権限を持ったまま放置される野良エージェント」を防ぐには、人間の責任者を必ず紐づけ、権限に期限を設けて棚卸しを強制する——この2つが土台になります。人の入退社管理と、まったく同じ発想です。
統制しないと何が起きるか
「エージェントに権限を与える」という発想が抜け落ちると、次のような問題が積み上がります。いずれも、人間のID管理を怠ったときと同じ構図です。
- 過剰権限（over-permissioned）
「とりあえず動かすため」に広い権限を与えたまま運用され、必要以上のデータにアクセスできるエージェントが増える。 - 野良・孤児エージェント
作ったきり誰も責任を持たず、退役もされないエージェントが、権限を保持したまま残り続ける。 - なりすまし・追跡困難
共有の接続で動くエージェントは、コネクタのレイヤーで利用者単位の紐づけが失われ、「どの利用者が引き起こしたか」を後から追いにくい。
AIエージェントの活用が進むほど、社内のエージェント数は指数的に増えます。人間の従業員が数十人でも、エージェントは数百・数千になり得ます。そのすべてを「身元のわからない権限保持者」にしないための仕組みが、Entra Agent ID による統制です。
正直な注意｜導入前に押さえておきたいこと
強力な枠組みですが、導入にあたって知っておくべき前提もあります。
導入前の留意点
- 進化の途中にある領域
エージェントのアイデンティティは新しい分野で、Copilot Studio でのエージェントID自動割り当てなど、一部の機能はプレビュー段階のものも含みます。仕様や画面は更新が続くため、設計時には必ず最新の公式情報で確認します。 - 条件付きアクセスの「実行時の効き方」には範囲がある
エージェントIDに付与されたコネクタ権限を、条件付きアクセスの対象にできること自体は確かです。ただし、実行時にその条件付きアクセスが評価・強制されるのは、現時点では Microsoft Teams チャネルで動くエージェントに限られます。他のチャネルでは、管理者は権限を「見る」ことはできても、条件付きアクセスがまだ効かない場合があります。 - エージェントは「テナントの枠」を消費する
Copilot Studio が作る各エージェントIDは、Microsoft Entra 上の1つのディレクトリオブジェクトとして、テナントのリソース枠（既定で5万件、ドメイン検証済みなら30万件）を消費します。無秩序な量産を避け、不要なエージェントを退役させる運用が、そのまま容量管理にもつながります。 - ライセンス体系が段階的で、確認が要る
エージェントIDの土台自体は、Microsoft Entra の全顧客が利用できます。一方で、条件付きアクセス・ID Protection・IDガバナンスといったセキュリティ機能をエージェントに適用するには、追加のライセンスが必要です（Microsoft 365 E5／E7 や Microsoft Agent 365、Entra ID P1／P2 などの組み合わせ）。どの機能をどこまで使うかで必要なプランが変わるため、現状のご契約に合わせた見極めが欠かせません。 - 技術で縛る前に、運用ルールを
誰がエージェントを作ってよいか、どの権限まで許すか、責任者は誰か——こうした運用ルール（ガバナンス方針）がないまま機能だけ入れても、統制は根づきません。AIを安全に使う社内ルールづくりと一体で進めるのが定石です。
弊社の支援｜AIの活用と、その統制を一体で
弊社は、AIエージェントの企画・導入から、Entra Agent ID・条件付きアクセス・IDガバナンスによる統制、そしてお客様専用のAI基盤「AIプライベート」の構築までを、一貫して支援しています。AIを「使えるようにする」ことと、「安全に統制する」ことは、本来ワンセットです。片方だけでは、現場は使いこなせないか、統制が空回りします。
- 運用ルールから設計する
誰が・何を・どの権限で動かすかというガバナンス方針を、お客様の業務実態に合わせて整理し、技術設定に落とし込みます。 - 最小権限と責任者を必ず紐づける
スポンサー（責任者）の割り当てと、期限付きのアクセス権で、野良・孤児エージェントを生まない運用を組み立てます。 - お客様の管理下でAIを動かす
お客様の業務によりフィットさせた専用のAI基盤SaaSサービス「AIプライベート」を、Azureの基盤で一社ごとに構築。データも権限も、お客様の管理下に置いたまま活用します。 - 情報保護と一体で
Microsoft Purview の情報保護・ゼロトラストと束ねて、AIエージェントを含めた全体の情報統制を設計します。
AIエージェントを「まず使ってみる」段階の進め方は「企業におけるAIエージェント活用の始め方」で、情報保護の土台づくりは「Microsoft Purviewで情報漏洩と内部不正を止める」でご覧いただけます。データと権限の主権をお客様の側に残す——これが弊社の一貫した基本姿勢です。
よくあるご質問
こちらをクリックして「よくある質問」を表示
Microsoft Entra Agent ID とは何ですか？
Microsoft Entra ID の認証・アクセス制御・ガバナンスの仕組みを、AIエージェントにまで広げる枠組みです。AIエージェントに固有のアイデンティティ（身元）を与え、人間のユーザーと同じように認証・権限管理・ライフサイクル管理・監査の対象にします。技術的には、エージェントのアイデンティティは Microsoft Entra ID 上の特殊なサービスプリンシパルとして表現されます。
Copilot Cowork と Copilot Studio のエージェントは、権限の面で何が違いますか？
Copilot Cowork は「使う人の権限の範囲」でのみ動きます。本人が見られないものはエージェントも見られず、既存の利用者統制がそのまま効きます。一方、Copilot Studio で作る自律型のエージェントは「エージェント自身に与えた権限」で動く設計にでき、以後の利用者はその権限を借りる形になり得ます。後者は、エージェント自身を統制の対象にする必要があるため、Entra Agent ID による管理が重要になります。
OBO（代理）認証と、共有接続で動かす自律型は、どちらを使うべきですか？
監査の観点では、利用者本人の権限で動き、ログに「誰が・どのエージェント経由で」行ったかが残る OBO（オンビハーフオブ）のほうが統制と相性が良い方式です。共有の接続で動かす自律型は、不特定多数向けのエージェントで使われますが、コネクタのレイヤーでは「その操作を実際にどの利用者が引き起こしたか」の紐づけが失われるため、過剰権限やなりすましのリスク管理を別途しっかり行う必要があります（なお、エージェント自身の Entra 上の認証は、いずれの方式でもログに記録されます）。用途（誰が使うエージェントか）に応じて選び、自律型を使う場合はガバナンスを厚くするのが基本です。
エージェントに与えた権限を、あとから棚卸しできますか？
できます。アクセスパッケージを使うと、エージェントに必要な権限を期限付きで割り当てられます。期限が近づくと責任者（スポンサー）に通知が届き、延長（再承認）するか失効させるかを選べます。放置すれば自動的に失効するため、不要な権限が残りません。人間の従業員のアクセス棚卸しと同じ仕組みを、エージェントにも適用できます。
Microsoft 製以外のAIエージェントにも使えますか？
はい。Entra Agent ID は Microsoft 製のエージェントに限らず、AWS Bedrock や n8n など他社プラットフォームで作られたエージェントも、Auth SDK（サイドカー）やワークロードID連携を通じて、同じガバナンスの対象にできます。どこで作られたエージェントであっても、統制された一つのIDを与えられるのが狙いです。
導入に必要なライセンスは何ですか？
エージェントIDの土台自体は Microsoft Entra の全顧客が利用できます。ただし、条件付きアクセス・ID Protection・IDガバナンスといったセキュリティ機能をエージェントに適用するには、追加のライセンスが必要です（Microsoft 365 E5／E7 や Microsoft Agent 365、Entra ID P1／P2 などの組み合わせ）。どの機能をどこまで使うかで必要なプランが変わり、体系も更新されるため、導入時に最新の公式情報で確認します。弊社では、現状のご契約に合わせて、どこから始められるかをご提案します。
まだAIエージェントを本格導入していませんが、今から統制を考える必要はありますか？
あります。むしろ、本格的に増える前に「誰が作ってよいか・どの権限まで許すか・責任者は誰か」という運用ルールを先に決めておくことが、後の混乱を防ぎます。人間の入退社管理と同じで、増えてから整えるより、増える前に枠組みを用意しておくほうが、はるかに低コストで統制できます。まずは小さく試しながら、並行してガバナンスの土台を整えるのがおすすめです。
AIエージェントの導入と、その権限統制・情報保護のご相談、無料でのご相談は、お問い合わせよりお気軽にご連絡ください。現在お使いの Microsoft 365・Azure の環境に合わせて、どこから始めるべきかをご提案します。
関連サービス・関連コラム
- 関連コラム：企業におけるAIエージェント活用の始め方
- 関連コラム：Microsoft Purviewで情報漏洩と内部不正を止める
- セキュリティ強化支援（ゼロトラスト）
- Microsoft 365導入支援
- DX支援（デジタル化戦略コンサルティング）
まずは無料トライアルで、効果をご確認ください
「AIプライベート」は短期・低コストで試せます。帳票入力（AI-OCR）や電話受注（AI-Voice）の自動化、Azure/Microsoft 365・DXのご相談まで、お気軽にどうぞ。
