先日、Microsoft Foundry で Autopilot シナリオを検証する際に参照する情報 という投稿をしました。この投稿は Microosft Foundry のオートパイロットシナリオ を実現するためのものとなります。
同様のシナリオは Agent 365 SDK のクイックスタート でも提供されており、こちらの構成は App Service+Bot Service を使用して エージェント ユーザー のシナリオが実現されていました。
先日起票した Issue の回答 で Microsoft Foundry を使用した Autopilot シナリオのサンプルを動作させることができるようになりましたので、個人的に気になっていた基本構成について確認した内容をまとめておきたいと思います。
Autopilot シナリオの利用が必要となるシチュエーション
現在の Microosft Foundry で作成したエージェントでは Agent Blueprint / Agent ID が自動的に付与されています。
そのため、実行モード の S2S (service-to-service) / OBO (on-behalf-of) によるリソースへのアクセスについて既定の状態でも実現することができるのではないでしょうか。
「エージェントを使用しているユーザーのコンテキスト」ではなく、「エージェント自身のコンテキスト」を使用してリソースにアクセスする際には、Agent ID を使用する Agent autonomous app OAuth flow を採用することになります。
このシナリオでは、Agent ID を使用して、外部リソース (A2A / Graph API / Azure Resource 等) にアクセスを行い、エージェントに必要となるアクションを実行していきます。
API を呼び出す場合というようなバックグラウンドサービスとしてのエージェントについては、このフローで対応することができますが、Foundry で構築できるエージェントの種類 に記載されているように「Microsoft 365 アクションの実行」が必要となるエージェントについては、このフローでは対応することはできません。
エージェントから Microsoft 365 アクションを実行する場合、Work IQ MCP 等を使用することになるのではと思いますが、Microsoft 365 のリソースへのアクセスについては Agent ID ではなく、ユーザーのコンテキストで実施する必要があります。
SharePoint や OneDrive for Business に対して、アクセス許可を設定すると分かるのですが、これらのリソースに対しては Agent ID を対象として権限を設定することはできません。
「エージェントから特定の SharePoint サイトにアクセスをして情報を収集させたい」という場合には、エージェントに対してユーザー相当のコンテキストを使用できるようにする必要があります。
この際に使用するのが Agent’s user account impersonation protocol となります。
エージェントに対して専用のユーザーアカウントを割り当てることで、Agent ID ではアクセスができない Microsoft 365 のリソースに対してアクセスが可能となります。
これにより「エージェントのコンテキストで許可されている Microsoft 365 リソースに対してのみアクセスが許可される」というようなエージェントを作成することがが可能となり、エージェントからアクセス可能な情報を制限することが可能となります。
Agent ID の構成
前述のとおり、Microsoft Foundry では既定でAgent ID の付与が行われており、Microsoft Foundry のエージェント ID の概念 から情報を確認することができます。
「既に Blueprint / Agent ID が付与されているエージェント」に対して Autopilot シナリオではどのように、エージェント レジストリで どのように Agent ID の表示が行われるのかが最も気になっていた内容でした。
サンプルを使用して展開を行った Autopilot シナリオでは、「Microsoft Foundry で標準的に使用されるエージェント」と「エージェントのインスタンスの追加を行うためのエージェント」の 2 種類が、同一の名称でエージェント レジストリに表示され、どちらも同じ Agent ID が付与されていました。
エージェントレジストリでは、エージェント インスタンスが作成可能なエージェントは、作成されているインスタンス数を示す数値が表示され、エージェントの情報を確認すると「エージェント テンプレート」の表示が行われています。
これで、どの用途のエージェントの情報なのかを確認することができるようです。
他のユーザーで作成したエージェント インスタンスを利用する
Autopilot のエージェントは エージェント インスタンス を作成することで、エージェントユーザーを持つエージェントが作成され利用することが可能となります。
インスタンスを作成したユーザーに関しては、追加の設定を行わなくても作成されたエージェントを利用することが可能だと思います。
Microsoft Foundry では、ビルドできるオートパイロットの種類 として次の 3 種類のパターンが提供されています。
- グループ オートパイロット
- 全社的なオートパイロット
- 個人用オートパイロット
このパターンが何らかの設定により制御が行われているかまでは確認ができていないのですが、「作成したインスタンスを作成者以外でも使用可能な状態」とするのであれば、エージェントに対しての IAM でもある程度制御ができそうでした。
Foundry ポータルから、エージェントインスタンスで使用されるエージェントに対して、エンドポイントに対しての IAM のアクセス許可を「既にアクセスを持っているユーザーを表示」から開き、「Foundry User」のロールのメンバーとすることで、他のユーザーでもすでに作成されているエージェント インスタンスを利用することが可能でした。
この方法では「作成されたエージェントインスタンス」に対してではなく「エージェントインスタンスで使用されるエージェント」に対して権限を付与することで複数ユーザーで利用を行っているため、「全社的なオートパイロット」「グループ オートパイロット」のシナリオの実現方法として適切なのかについては調査が必要ですが「複数のユーザーが Autopilot のエージェントを使用する」という挙動については Foundry User に対しての権限付与で基本動作の評価はできるのではないでしょうか。
他にも気になった内容があったら検証して、随時本投稿に追記していきたいと思います。