JBS × Avanade テックブログ｜Entra Agent IDで考えるAIエージェントのID管理

JBSとアバナード株式会社（Avanade Japan K.K.）の共同企画として、AIエージェントの「管理と統制」をテーマにお届けしています。今回の主役は「AIエージェントのID管理」です。

社内にAIエージェントが増えてくると、まず必要になるのが"見える化"です。でも、見えるだけでは管理になりません。今回は、その先の話をします。

結論を先にお伝えすると、やることはとてもシンプルです。AIエージェントを、人間の社員と同じように"雇う"。社員証（ID）を発行し、職務に応じた権限を渡し、何をしたかを記録し、辞めたらアクセスを止める。当たり前の社員管理を、エージェントにも。というのが今回の主旨です。

※ 過去記事はこちら

「見える」の次は「決まっている」か
大前提：Microsoft Entra Agent ID で管理するエージェントには、責任主体がある
「人事の5機能」をAIエージェントに当てはめる
運用上の注意 ― まだ発展途上のところも
まとめ ―「デジタル社員」を本格採用する時代へ

この記事では、ひとつの具体例を最後まで追いかけます。営業部のAさんがCopilot Studioで作った「営業支援エージェント」です。便利なので部署で使われ始めた。けれど、半年後にAさんが退職したら、このエージェントは誰が責任を持つのでしょう。辞めたAさんが設定した権限がそのまま残り、誰のチェックも受けずに深夜の機密フォルダへアクセスし続けていたら、誰が気づくのでしょう。この「あるある」を、採用→配属→権限→監督→退職の5ステップで、ひとつずつ解消していきます。

「見える」の次は「決まっている」か

Agent 365のような仕組みを使えば、社内のエージェントを"見える化"できます。

ですが、見えることと、管理できていることは別です。実際に一覧を開くと、並んでいるのは「持ち主が分からないエージェント」や「リスクありと警告が出ているエージェント」ばかりです。"見えた"はずなのに、誰のもので何をしているのかは分からないまま、という組織がとても多いのです。

見えても、誰のものか決まっていなければ管理できない。その出発点が、エージェントにID（社員証）を与えることです。今回は「人と同じ枠組み」で、エージェントを正式に迎え入れていきます。

大前提：Microsoft Entra Agent ID で管理するエージェントには、責任主体がある

Microsoft Entra Agent ID の重要な考え方は、エージェントを「誰が責任を持って管理するものなのか」が分かる状態にすることです。それは、Agent Identity を人間の ID と同じような管理の流れで扱い、エージェントのライフサイクル全体を通じて監督する責任者を持たせるということです。

そして、Agent Identity や、その雛形である Agent Identity Blueprint には、少なくとも1つの Sponsor が必要です。Sponsor は、そのエージェントの目的、ライフサイクル判断、アクセスレビューなどに責任を持つユーザーまたは対応グループです。

つまり、エージェントは「誰の責任でもないまま動くもの」ではありません。少なくとも Microsoft Entra Agent ID の管理下では、どの責任主体がそのエージェントを管理するのかを持たせる設計になっています。これが、エージェントを人間の ID と近い考え方で管理する出発点です。

エージェントの動き方には、大きく2つあります。

あなたの代わりに動く
- たとえば「この商談メモをまとめて」と頼むと、あなたの権限を借りて資料を読みにいく動きです。
- 記録には「○○さんの代わりにエージェントが動いた」と残ります。
エージェント自身の ID で動く
- たとえば、毎晩決まった時刻にレポートを作って送る処理では、実行のたびに特定のユーザーの代理として動くのではなく、Agent Identity 自身の権限で動きます。

リスクが大きくなりやすいのは、2つ目です。ユーザーがその場で操作していなくても処理が進むため、誰がそのエージェントの目的や権限を見直すのかを決めておく必要があります。

そのため、 Microsoft Entra Agent ID では、Sponsor という責任主体を置き、エージェントのライフサイクルやアクセスを管理できるようにしています。

「人事の5機能」をAIエージェントに当てはめる

人事部が会社のために回している基本機能を5つに分けると、今のエージェント管理に欠けているものが見えてきます。

社員番号もなく、上司もおらず、職務範囲も決まっていない。退職手順もなく、誰が何をしたかの記録も残らない。まさに、この5つがまるごと空っぽの状態です。順に埋めていきましょう。

(1) 採用 ― IDを発行する

人を雇うとき、まず社員番号を発行します。エージェントも同じで、Microsoft Entra Agent ID を持たせることで、社内で識別し、権限を管理し、責任者をたどれる対象になります。

人でいえば、社員証や社員番号を持たせるようなものです。Aさんが作った営業支援エージェントに、まず"社員証"を発行しましょう。

実機で確認すると、作成したエージェントにEntra上の正式なID（社員証）が付き、責任者（Sponsor）も紐づきます。

(2) 配属 ― オーナーと責任者を決める

採用したら配属し、責任者を決めます。エージェントには、3つの「人間の役割」が公式に定義されています。

Owner
- 技術管理者。設定、構成、資格情報などを管理する人またはサービス。
Sponsor
- 業務上の責任者。目的、継続要否、アクセスレビュー、削除や停止の判断に責任を持つ人または対応グループ。
- 作成時に必須。
Manager
- 組織上の受け持ち先。主に agent user account の文脈で、アクセスパッケージの申請などに関わる人。

ここが、人間とエージェントの決定的な違いです。

人間は退職すれば物理的にいなくなりますが、エージェントは作った人が辞めても社内で動き続けます。そのため、「所属」を制度として持たせ、責任者が抜けたときに引き継ぐ仕組みが必要になります。

(3) 権限 ― 必要な分だけ渡す

職務に必要な分だけ権限を渡します。例えば、営業支援エージェントには「SharePointの「営業資料」だけを見せ、人事情報には絶対に触らせない」といった範囲を絞ります。

細かく見えても、やることは一つです。「どのデータに・どこまで触れてよいか」をリストで決めるだけです。あとはエージェントが、そのリストの範囲だけで動きます。

Microsoft Entra ID で保護されたリソースについては、トークンに含まれる権限、SharePoint など各サービス側の権限、条件付きアクセスの範囲で動きを制御できます。「営業資料だけ」を、お願いではなく"設計"で担保できます。

ここで、人間とエージェントの違いを正確に整理しておきます。

「人間なら悪用しないはず」と言いたいわけではありません。人間でも、悪意があれば権限を悪用できます。だからこそ、人間にも"最小権限"は欠かせません。ただ、人間の場合は、良心や社内ルール、「やったら咎められる」という抑止が、ある程度のブレーキになります。

エージェントには、そのブレーキがありません。渡した権限は、渡したぶんだけそのまま使われます。しかも、悪意がなくても事故は起きます。たとえば、以下のようなケースです。

巧妙な指示文にだまされる（プロンプトインジェクション）
設定ミスや、プログラムのちょっとしたバグ

こうしたとき、そのエージェントが持っている権限の範囲が、そのまま"事故の届く範囲"になります。営業支援のつもりのエージェントが人事フォルダまで触れる状態なら、その分だけ漏えいのリスクが広がってしまいます。しかも速くて自動なので、被害も一気に広がります。

だからこそ、人にもエージェントにも最小権限は必要で、エージェントの場合は「最初から渡さない」設計が、最初の歯止めになります。権限を「お願い」ではなく「設計」で絞る理由は、ここにあります。

そして、権限を定めることは、そのエージェントが業務のどこまでつながってよいかを定めることでもあります。エージェントは、MCP や Work IQ などを通じて、Microsoft 365 のデータや社内のツールに接続できます。だからこそ、「どのデータを読めるのか」「どのツールを呼べるのか」「どの操作まで実行してよいのか」を、最初に決めておく必要があります。

アクセス制御とは、エージェントが使える道を決める仕組みです。水道でいえば、蛇口の太さだけでなく、どの蛇口を開けてよいかまで決めるものです。この範囲を決めずに、エージェントが社内データや外部ツールへ自由につながれる状態になると、会社はそのAIを十分に把握できません。誰が承認したのか、どのデータに触れるのか、あとから追えるのかが曖昧になります。

(4) 監督 ― 働いている間、足跡を残して見守る

採用して、配属して、権限を渡したら、次に必要なのは、働いている間の見守りです。

エージェントは、一度動き始めると、人が毎回画面の前で見ているとは限りません。定期的にレポートを作ったり、別のサービスを呼び出したり、ユーザーの代わりに資料を読みにいったりします。

だから、エージェント管理では「権限を渡して終わり」では不十分です。大事なのは、会社のルールから外れそうな動きを止められること。そして、あとから何が起きたのかを追えることです。

たとえば、営業支援エージェントが、普段は使わない人事系のデータにアクセスしようとしたとします。

このとき、条件付きアクセスを使えば、エージェントの状態やアクセス先を見て、許可するか、止めるかを判断できます。つまり、「営業支援エージェントは営業系のリソースだけにする」「高リスクと判断されたエージェントは止める」といったルールを、人の注意ではなく仕組みとして置けます。

ただし、止めるだけでは足りません。あとから説明できるように、足跡も必要です。

Microsoft Entra では、エージェントのサインインや、Agent Identity に対する管理操作がログに残ります。これにより、どのエージェントが、いつ、どのリソースにアクセスしようとしたのかを追いやすくなります。

一方で、Entra のログだけですべてが分かるわけではありません。ファイルの中身をどこまで読んだのか、機密情報に触れたのかまで確認したい場合は、SharePoint、Microsoft Purview、Microsoft Defender など、データやセキュリティ側の記録も合わせて見ます。

監督とは、エージェントを疑い続けることではありません。会社のルールの中で動いているかを確認できるようにし、危ない動きがあれば止め、あとから説明できる記録を残すことです。

AIは、動けばよいわけではありません。会社で使うなら、「なぜ動けたのか」「どこまで触れたのか」「誰が見直せるのか」を説明できる状態にしておく必要があります。

(5) 退職 ― 辞めたら、きちんと止める

人に入社・異動・退職の手続きがあるように、エージェントにも"出口"の手続きが要ります。

むしろ難しいのは、入口より出口です。作るときは、目的がはっきりしています。営業資料をまとめたい、問い合わせに答えたい、定期レポートを作りたい、といった勢いで作られます。

ですが、半年後、そのエージェントを作ったAさんが退職したらどうなるでしょうか。Aさんが Owner や Sponsor だった場合、その営業支援エージェントは止まるのか、動き続けるのか、誰が権限を見直すのか、誰が不要だと判断するのか、といったことを考える必要があります。

ここを曖昧にすると、誰の管理にも残っていないエージェントが、社内のデータへアクセスし続ける状態になってしまいます。

Microsoft Entra Agent ID では、個別のエージェントを無効化して、アクセスやトークン発行を止められます。管理者は Microsoft Entra 管理センターから、Owner や Sponsor は My Account ポータルから、対象の Agent Identity を管理できます。

退職したAさんのエージェントを停止し、本当にアクセスが止まるかを確認してみます。

停止すると、確認ダイアログが表示され、「アクセスとトークン発行をブロックする」と明示されます。