Agentを業務利用者のMicrosoft 365 CopilotやTeamsへ届けられると、独自UIの開発負担は減る。しかし公開処理は単なるリンク共有ではない。Teams manifest、カタログ申請、認証、公開範囲、active versionの切替が別々に動くため、誰が何を承認するかを明確にしなければ、未評価版が全社へ露出する。
何が変わったか
Foundry Agent ServiceのAgentをMicrosoft 365 CopilotおよびTeamsへ公開する統合導線がEarly Access Previewとして追加された
| 項目 | 内容 |
|---|---|
| 対象 | Microsoft Foundry |
| API・機能 | Agent publishing |
| 変更種別 | 提供開始 |
| 重要度 | 高 |
| 対応期限 | 期限なし |
変更前後の差
従来は独自チャネル統合や別のCopilot Studio経路が必要だった。新しい公開機能はFoundry Agentのstable endpointを使い、Microsoft 365 CopilotとTeams向けpackageを作成・提出する。自分だけの公開は管理者承認不要だが、組織公開はMicrosoft 365管理者の承認を必要とする。
誰に影響するか
全社ヘルプデスク、社内検索、営業支援、規程案内などをTeamsへ配布する組織に影響する。公開後にactive versionを切り替えるとstable endpointのまま実体が変わり得るため、公開時の評価だけでは不十分である。
期限
導入期限はなく、Early Access Previewである。重要業務は限定利用で検証し、GA前提の固定運用を避ける。
必要な対応
公開用Agentのactive versionを評価済みに固定し、個人テスト、パイロット、組織公開の段階を分ける。app metadataへsecretや内部情報を入れない。private network環境では対応するREST API手順と通信条件を確認する。
実装・移行手順
- 公開対象の利用者と業務範囲を決める
- 評価済みAgent versionをactiveに設定する
- 認証方式とstable endpointを確認する
- 自分だけの公開で表示・権限・会話を試験する
- 管理者へpackageとリスク説明を提出する
- 組織公開後もversion切替ごとに回帰試験する
失敗しやすい点
個人テスト成功を全社公開の承認とみなす、active versionを無通知で切り替える、manifestへ機密情報を含める、ネットワーク制限下でPortal操作だけを想定することが問題になる。
リスク
未承認利用者への公開、古い説明文と新versionの不一致、認証失敗、カタログ反映遅延、Preview仕様変更、廃止後もTeams側に残ることがある。
評価方法
- 公開承認までの時間
- 利用者別認証成功率
- Agent version別回答品質
- 組織公開後のエラー率
- 未承認アクセス件数
- 廃止完了までの時間
ロールバック
Microsoft 365管理者側で公開を取り下げ、対象Agentのactive versionを直前の評価済み版へ戻す。stable endpointを削除する前に、Teams・Copilot側の登録解除を確認する。
編集部分析
チャネル公開とAgentデプロイは別の変更である。stable endpointは利用者URLを安定させるが、内部versionの変更を見えなくする。公開後のversion governanceが導入前より重要になる。
実務チェックリスト
- [ ] 個人・パイロット・組織公開を分けた
- [ ] 管理者承認を得た
- [ ] active versionを記録した
- [ ] manifestに秘密情報がない
- [ ] 認証を利用者権限別に試した
- [ ] 公開取り下げ手順がある