Microsoft TeamsのAI/Copilot更新で押さえるべきポイントは、Microsoft Foundryで作成したエージェントを、FoundryポータルからMicrosoft 365 CopilotとMicrosoft Teamsへ発行できるようになったことです。これにより、開発者はTeamsやMicrosoft 365 Copilot上で利用される業務エージェントを配布しやすくなります。一方で、管理者承認、Teamsアプリポリシー、Azure Bot Service、旧Agent Applicationモデルからの移行確認が必要です。
特に重要なのは、発行されるのがエージェントそのものの一時的なコピーではなく、安定したエンドポイントである点です。ユーザーは同じエージェントとして利用し続けられ、開発者は裏側で新しいバージョンへ切り替えられます。Microsoft Learn日本語版では、このドキュメントの最終更新日が2026年5月6日と表示されています。(Microsoft Learn)
Microsoft TeamsのAI/Copilot更新で何が変わるのか
今回の「Publish agents to Microsoft 365 Copilot and Microsoft Teams」は、Microsoft Foundryで作成したエージェントを、Microsoft 365 CopilotとMicrosoft Teamsの利用画面に届けるための発行手順です。
従来、エージェントを作っても、利用者が普段使うTeamsやCopilot上で見つけやすくするには、マニフェストやアプリ配布、承認フローを個別に意識する必要がありました。今回の更新では、Foundryポータルから発行フローを進められるため、開発者にとっては「作成・テスト後に配布する」までの流れが分かりやすくなっています。
ただし、これは単なる公開ボタンの追加ではありません。次のような運用設計に関わる変更です。
| 観点 | 変更内容 | 実務上の影響 |
|---|---|---|
| 配布先 | Microsoft 365 CopilotとMicrosoft Teamsに発行可能 | 利用者が日常の業務画面からエージェントを見つけやすくなる |
| 発行対象 | エージェントの安定したエンドポイント | バージョン更新時も同じエージェントとして利用継続できる |
| 承認 | 組織向け配布ではMicrosoft 365管理者の承認が必要 | 開発者だけで全社展開できるとは限らない |
| 管理 | TeamsのアプリポリシーやMicrosoft 365管理センターの制御対象 | 管理者は利用可能ユーザー、承認状態、ポリシーを確認する必要がある |
| 移行 | 旧Agent Applicationモデルとの違いがある | 既存エージェントはID、RBAC、エンドポイント変更の確認が必要 |
Microsoft 365 Copilotのリリースノートでも、Azure AI FoundryのエージェントをCopilot Agent Storeへ発行する流れが取り上げられており、開発者がエージェント配布を進めやすくする方向の更新として位置付けられています。(Microsoft Learn)
対象になるのはMicrosoft Foundryで作成・テスト済みのエージェント
この手順の前提は、Microsoft Foundry上に発行対象のエージェントバージョンがあり、Foundryポータルでテスト済みであることです。公式ドキュメントでは、発行前にエージェントが正しく応答するか、利用するツールが期待通り動くかを確認するよう示されています。(Microsoft Learn)
管理者や開発者が最初に確認すべき前提条件は、次の通りです。
| 確認項目 | 確認する理由 |
|---|---|
| Microsoft Foundryポータルへアクセスできるか | 発行操作はFoundryポータルから行うため |
| 発行したいエージェントバージョンがあるか | ユーザーに提供する実体を決める必要があるため |
| Foundryプロジェクトで必要なロールを持っているか | エージェントの作成・管理・発行に権限が必要なため |
| Azure Bot Serviceリソースを作成できるAzureサブスクリプションがあるか | 発行フローでAzure Bot Serviceリソースが作成または利用されるため |
Microsoft.BotServiceプロバイダーが登録済みか | 未登録だとBot Service作成で失敗する可能性があるため |
| TeamsやMicrosoft 365側のアプリ管理ポリシーが整っているか | 組織ユーザーが利用できるかどうかは管理設定にも左右されるため |
Azure CLIで確認・登録する場合は、公式手順にあるように次のコマンドを使います。
az provider register --namespace Microsoft.BotService発行フローは「直接発行」と「ダウンロードしてカスタマイズ」の2種類
Foundryポータルでエージェントを開き、PublishからPublish to Teams and Microsoft 365 Copilotを選択すると、発行用のダイアログが表示されます。ここでAzure Bot Serviceリソースが自動作成されるか、既存リソースがある場合は読み取り専用として表示されます。(Microsoft Learn)
発行時には、エージェントストアやTeams上でユーザーに見える情報を入力します。
| メタデータ | 入力内容 | 注意点 |
|---|---|---|
| Name | エージェントの表示名 | ユーザーが用途を判断しやすい名前にする |
| Publish version | major.minor.patch形式のバージョン番号 | 例：1.0.0、1.1.0 |
| Short description | 1文の短い説明 | 「何をしてくれるエージェントか」を明確にする |
| Description | 詳細説明 | できること、できないこと、対象業務を具体化する |
| Developer | 開発者名または組織名 | 組織名を使うと利用者が信頼しやすい |
| Developer website | 開発者サイトURL | HTTPSが必要 |
| Terms of use | 利用規約URL | 社内向けでも必要に応じて用意する |
| Privacy statement | プライバシーポリシーURL | データ利用範囲の説明に使う |
ここで失敗しやすいのが、説明欄に内部情報を書きすぎることです。公式ドキュメントでも、メタデータフィールドにはシークレット、APIキー、機密情報を含めないよう警告されています。これらはユーザーに表示される情報だからです。(Microsoft Learn)
直接発行はパイロットと組織展開で使い分ける
直接発行では、利用できる範囲を選びます。
| スコープ | 管理者承認 | 向いている用途 |
|---|---|---|
| あなただけ | 不要 | 個人検証、小規模な動作確認、開発中の試験利用 |
| 組織内のユーザー | 必要 | 部門展開、全社展開、本番運用 |
「あなただけ」を選ぶと、発行後すぐに利用できます。まず開発者やプロジェクトメンバーだけでテストし、回答品質、アクセス権、Teamsでの見え方を確認する場合に向いています。
一方、「組織内のユーザー」を選ぶと、Microsoft 365管理者による承認が必要です。承認後、エージェントは組織のエージェントストアに表示されます。また、テナント内のアプリポリシーによって、実際に誰がアクセスできるかが制御されます。(Microsoft Learn)
マニフェストをカスタマイズしたい場合はZIPをダウンロードする
ブランド表現、アプリ定義、配布前の調整が必要な場合は、Download & customizeを選びます。この方法では、エージェントマニフェストを含むZIPファイルをダウンロードし、必要に応じて内容を調整してからTeamsにアップロードします。
実務では、次のようなケースで使います。
- Teams上のアプリ表示を細かく調整したい
- 社内のアプリ審査フローに合わせてマニフェストを確認したい
- 本番展開前にセキュリティ部門や情シス部門のレビューを通したい
- 部門ごとに説明文や公開範囲を変えたい
Teamsでは、アプリ > アプリを管理する > アプリをアップロードするから、カスタムアプリとしてアップロード、または組織にアプリを送信できます。(Microsoft Learn)
管理者が確認すべきTeams側の設定
Microsoft Teamsにエージェントを発行しても、ユーザーが必ず使えるとは限りません。Teams管理センターやMicrosoft 365管理センター側で、アプリやCopilotエージェントの利用が許可されている必要があります。
MicrosoftのTeams管理ドキュメントでは、組織ユーザーにTeamsアプリやCopilotエージェントを使わせるには、組織全体のアプリ設定、個別アプリ設定、アプリ許可ポリシー、Teams管理センターとMicrosoft 365管理センターの設定を確認する必要があると説明されています。(Microsoft Learn)
管理者は、少なくとも次の観点で確認しましょう。
| 確認場所 | 確認内容 | 見落とすと起きること |
|---|---|---|
| Microsoft 365管理センター | 組織向けエージェントの承認依頼 | 開発者が発行しても、組織ユーザーに表示されない |
| Teams管理センター | アプリの許可・ブロック設定 | 特定ユーザーだけ利用できない |
| アプリ許可ポリシー | グローバルポリシーとカスタムポリシー | 部門・ユーザー単位で挙動が変わる |
| 統合アプリ管理 | TeamsとMicrosoft 365側の許可状態 | 管理方式によって確認場所が変わる |
| ユーザー割り当て | 対象ユーザーにポリシーが適用されているか | 検証担当だけ使えず原因調査に時間がかかる |
特に注意したいのは、組織がアプリ中心の管理、または統合アプリ管理へ移行している場合です。従来のアプリ許可ポリシーだけを見ても、実際の制御状態を判断できないことがあります。Teams管理ドキュメントでは、アプリ中心の管理へ移行済みの場合、従来の許可ポリシーが適用されなくなる旨も説明されています。(Microsoft Learn)
開発者が確認すべきエージェント設定
開発者にとって重要なのは、発行前に「どのバージョンをユーザーに出すか」を明確にすることです。Foundryエージェントには安定したエンドポイントがあり、ユーザーはそのエンドポイント経由でエージェントを利用します。
既定では「常に最新バージョンを使用する」設定になっているため、新しいエージェントバージョンを作ると、そのバージョンがMicrosoft 365 CopilotやTeamsで自動的に提供される可能性があります。本番運用では、安定性を優先して特定バージョンにピン留めする判断が重要です。(Microsoft Learn)
| 運用シーン | 推奨設定 |
|---|---|
| 開発中・検証中 | 常に最新バージョンを使用してもよい |
| 部門内パイロット | 最新追従またはピン留めを目的に応じて選ぶ |
| 全社本番展開 | 特定バージョンにピン留めするのが安全 |
| 法務・人事・経理など影響が大きい業務 | ピン留めし、リリース前レビューを必須にする |
また、Microsoft 365 CopilotやTeamsに発行するエージェントでは、Activity protocolやBotService系の認証方式が関係します。公式ドキュメントでは、TeamsやMicrosoft 365へ発行するエージェントにはActivity protocolが必要で、BotServiceまたはBotServiceRbac認証方式を使う旨が説明されています。(Microsoft Learn)
旧Agent Applicationモデルからの移行で注意すべき点
既存のAgent Applicationを使っていた組織では、今回の発行体験をそのまま適用できるとは限りません。Microsoft Foundryの新しいモデルでは、Agent ApplicationやDeploymentが別リソースとして分かれていた従来構成から、AgentオブジェクトにエンドポイントやIDなどの責務が集約される方向になっています。(Microsoft Learn)
移行時に特に注意したいのは、次の3点です。
| 注意点 | 内容 | 対応 |
|---|---|---|
| レガシーエージェントのID | agent.identityまたはinstance_identityがnullの場合、新しい発行モデルを使えない可能性がある | 同じ定義で新しいエージェントを作成する |
| エンドポイントURL | 旧Application endpointと新しいagent stable endpointで形式が異なる | 外部連携コードやWebhook設定を洗い出す |
| RBAC | Agent Applicationに付与したRBACは新しいAgentオブジェクトへ自動移行されない | 新しいエージェントIDに必要な権限を再割り当てする |
公式の移行ガイドでは、既存のAgent Applicationはすぐに停止するわけではなく、引き続き動作するとされています。ただし、新しいモデルの機能を使うには、新しいエージェントモデルへの移行確認が必要です。(Microsoft Learn)
実務では、いきなり既存の本番エージェントを置き換えるのではなく、次の順序で進めるのが安全です。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | 既存エージェントがレガシーか確認する | instance_identityがnullでないか |
| 2 | 同じ指示、ツール、モデル設定で新しいエージェントを作る | 回答品質が旧版と大きく変わらないか |
| 3 | 新しい安定エンドポイントでテストする | Teams、Copilot、外部ツール連携が動くか |
| 4 | Microsoft 365 CopilotとTeamsへ発行する | 管理者承認、アプリポリシー、表示名を確認 |
| 5 | 旧Agent Applicationを段階的に廃止する | 参照しているコードやURLをすべて更新したか |
発行後の更新は「再発行」とは限らない
公開済みエージェントを更新する場合、必ずTeamsやMicrosoft 365 Copilotへ再発行し直すわけではありません。新しいエージェントバージョンをロールアウトする場合は、Foundryポータルでバージョンセレクターを更新します。このとき、安定したエンドポイントURLは変わらないため、M365/Teamsへの再発行は不要とされています。(Microsoft Learn)
ただし、表示名、説明文、URLなど、ユーザーに見えるメタデータを変える場合は別です。Update agent Teams and Microsoft 365 Copilot display propertiesから表示プロパティを更新します。更新したフィールドは既存値を上書きし、変更していないフィールドは引き継がれます。
運用では、次のように分けて考えると混乱を防げます。
| 変更内容 | 主な操作 | 注意点 |
|---|---|---|
| プロンプトやツール設定を変えた | 新しいエージェントバージョンを作成し、バージョンセレクターで制御 | 本番では自動で最新版に流れないよう確認 |
| Teams上の表示名を変えた | 表示プロパティを更新 | 利用者向け案内文も更新する |
| 説明文や利用規約URLを変えた | メタデータを更新 | 古い説明との不整合を避ける |
| 利用対象を広げた | Microsoft 365管理センターやTeams管理センターで承認・ポリシー確認 | 開発者だけでは完結しない |
制限事項を理解してから展開する
この発行機能は便利ですが、現時点では制限があります。特に、Microsoft 365 CopilotとTeamsで挙動が同じではない点に注意が必要です。
| 制限 | 内容 | 実務上の注意 |
|---|---|---|
| Microsoft 365でのファイルアップロード | Microsoft 365に発行されたエージェントでは動作しない | ファイル投入が必要な業務はTeamsで検証する |
| Microsoft 365での画像生成 | Microsoft 365に発行されたエージェントでは動作しない | 画像生成を前提にした業務設計は避ける |
| Private Link | TeamsまたはAzure Bot Service統合ではサポートされない | 閉域接続前提のセキュリティ設計では要確認 |
| ストリーミング応答 | 公開済みエージェントではサポートされない | 長文応答のUXを事前に確認する |
| 引用 | 公開済みエージェントではサポートされない | 根拠提示が必須の業務では代替設計が必要 |
これらの制限は、社内FAQや検索支援のような用途では大きな問題にならない場合があります。一方、監査、法務、医療、金融、人事評価など、根拠提示やデータ境界が重要な用途では、公開前に利用シナリオを絞り込むべきです。制限事項は公式ドキュメントにも明記されています。(Microsoft Learn)
よくある失敗と対処法
Microsoft Teams向けにFoundryエージェントを発行する際は、開発環境では動くのに、Teamsや組織展開で詰まるケースがよくあります。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| 発行時にエラーが出る | メタデータやバージョン番号が不正 | バージョン番号、開発者名、必須項目を見直す |
| Azure Bot Serviceの作成に失敗する | 権限不足またはプロバイダー未登録 | Microsoft.BotService登録と権限を確認 |
403 AuthorizationFailedが出る | Bot Serviceリソースの作成・更新権限がない | 対象リソースグループでAzure Bot Service Contributorロールを確認 |
| 組織向けに発行したのに表示されない | Microsoft 365管理者の承認待ち | Microsoft 365管理センターのRequestsを確認 |
| 一部ユーザーだけ使えない | Teamsアプリポリシーで制限されている | Teams管理センターでユーザー適用ポリシーを確認 |
| Foundryでは動くがTeamsでは失敗する | エージェントIDに下流リソース権限がない | エージェントIDへ必要なRBACを付与 |
| 新版を作ったら本番挙動が変わった | 「常に最新バージョンを使用する」設定だった | 本番エージェントは特定バージョンにピン留めする |
トラブル調査では、まず「Foundry側の問題」か「Microsoft 365/Teams側の承認・ポリシー問題」かを切り分けましょう。Foundryでは正常でも、Microsoft 365管理センターの承認やTeamsのアプリポリシーで止まっていることがあります。
展開前チェックリスト
本番展開前には、開発者、Microsoft 365管理者、Teams管理者で同じチェックリストを共有しておくと、承認漏れや権限不足を防げます。
| 担当 | チェック項目 |
|---|---|
| 開発者 | エージェントがFoundryポータルで期待通り応答する |
| 開発者 | 本番提供するアクティブバージョンを決めている |
| 開発者 | 「常に最新」か「特定バージョン固定」かを明確にしている |
| 開発者 | メタデータに機密情報、APIキー、内部URLを含めていない |
| 開発者 | レガシーエージェントの場合、移行要否を確認している |
| Azure管理者 | Azure Bot Serviceを作成できる権限がある |
| Azure管理者 | Microsoft.BotServiceプロバイダーが登録されている |
| Microsoft 365管理者 | 組織向け発行の承認フローを確認している |
| Teams管理者 | アプリ許可ポリシーまたはアプリ中心管理の設定を確認している |
| セキュリティ担当 | サードパーティツール利用時のデータ共有範囲を確認している |
| 運用担当 | 障害時の問い合わせ先とロールバック方針を決めている |
まずは小さく発行し、ポリシー確認後に組織展開する
Microsoft TeamsのAI/Copilot更新として見ると、今回のFoundryエージェント発行機能は、業務エージェントを現場に届けるための重要な前進です。開発者はFoundryポータルから発行しやすくなり、利用者はTeamsやMicrosoft 365 Copilot上でエージェントを見つけやすくなります。
ただし、本番展開では「発行できる」と「安全に全社利用できる」は別物です。最初は「あなただけ」または小規模なパイロットで動作を確認し、アクティブバージョン、Teamsアプリポリシー、Microsoft 365管理センターの承認、エージェントIDのRBACを整理してから、組織向けに広げるのが現実的です。
次に取るべき行動は明確です。既存エージェントを使っている場合は、まずレガシーAgent Applicationかどうかを確認してください。新規エージェントを展開する場合は、テスト済みバージョンを固定し、管理者承認とTeams側ポリシーを先に確認してから発行しましょう。
コメント