Microsoft Foundry / Azure OpenAIで作成したエージェントは、検証後にMicrosoft 365 CopilotやMicrosoft Teamsへ公開し、ユーザーが普段使う業務画面から利用できるようになりました。2026年4月22日に更新されたMicrosoft公式ドキュメントでは、Foundryポータルからの公開手順、公開範囲、管理者承認、バージョン更新、制限事項が整理されています。ポイントは、公開されるのはエージェントの安定したエンドポイントであり、利用者側の入口を変えずに新しいエージェントバージョンへ切り替えられることです。(Microsoft Learn)
Microsoft 365管理者や職場のITチームにとっては、「誰に公開するか」「管理者承認が必要か」「TeamsとMicrosoft 365 Copilotで何が使えるか」を事前に確認することが重要です。業務ユーザーにとっては、社内で作ったAIエージェントをTeamsやCopilotの画面から探して使えるようになるため、問い合わせ対応、ナレッジ検索、文書要約、業務支援などの活用が進めやすくなります。
Microsoft Foundry / Azure OpenAIの最新動向: Publish agents to Microsoft 365 Copilot and Microsoft Teamsで何が変わったか
今回注目すべき更新は、Microsoft Foundryで作成・テストしたエージェントを、Microsoft 365 CopilotとMicrosoft Teamsの利用画面へ公開する流れが明確化された点です。Microsoft Learnの該当記事は2026年4月22日に更新されており、Foundryポータルから公開する手順、公開オプション、更新方法、制限事項、トラブルシューティングがまとめられています。(Microsoft Learn)
従来の「AIエージェントを作ったが、どう社内展開するか分からない」という課題に対し、今回の内容はかなり実務寄りです。単にエージェントを作るだけでなく、次のような運用判断まで含めて考えられるようになっています。
| 観点 | 2026年4月更新で押さえたいポイント |
|---|---|
| 公開先 | Microsoft 365 CopilotとMicrosoft Teamsから利用・発見できる |
| 公開方法 | Foundryポータルから公開する |
| 公開対象 | 自分だけ、または組織内ユーザー向けに公開できる |
| 管理者承認 | 組織向け公開ではMicrosoft 365管理者による承認が必要 |
| バージョン管理 | 安定したエンドポイントを維持しながら、アクティブなエージェントバージョンを切り替えられる |
| 注意点 | Microsoft 365側ではファイルアップロードや画像生成など一部機能に制限がある |
特に大きいのは、エージェントの「安定したエンドポイント」を中心に公開・更新を管理する設計です。利用者は同じエージェントとして使い続けられ、開発側は背後のバージョンを切り替えられます。これにより、PoCから本番展開へ移るときの運用負荷を下げやすくなります。
公開されるのは「エージェントそのもの」ではなく安定したエンドポイント
Microsoft Foundryの新しいエージェント運用で重要なのは、エージェントの安定したエンドポイントという考え方です。Microsoftの説明では、Microsoft 365 CopilotやTeams、既存アプリなどからエージェントを利用する場合、利用者はエージェントの安定したエンドポイントとやり取りします。エージェントのバージョンが変わっても、利用者側は一貫したエージェントとして操作できます。(Microsoft Learn)
これは、社内展開では非常に重要です。たとえば、総務部門向けの「社内規程問い合わせエージェント」をTeamsに公開した後、回答精度を上げるためにプロンプトやツール設定を修正したとします。このとき、ユーザーに新しいリンクを配り直したり、別アプリとして再案内したりする運用は避けたいところです。
安定したエンドポイントを使えば、ユーザー側の利用体験を大きく変えずに、開発・管理側で新しいバージョンへ切り替える運用がしやすくなります。
公開前に確認すべき前提条件
Microsoft FoundryからMicrosoft 365 CopilotやTeamsへエージェントを公開する前に、いくつかの前提条件を満たす必要があります。Microsoft公式ドキュメントでは、Foundryポータルへのアクセス、テスト済みのエージェントバージョン、Azure AI Userロール、Azure Bot Serviceリソースを作成できるAzureサブスクリプション、Microsoft.BotServiceプロバイダーの登録などが挙げられています。(Microsoft Learn)
実務では、次のチェックリストを使うと公開前の抜け漏れを減らせます。
| 確認項目 | 実務での確認ポイント |
|---|---|
| Foundryプロジェクト | 公開対象のエージェントが対象プロジェクト内にあるか |
| テスト状況 | Foundryポータル内で想定質問、権限、ツール連携を検証済みか |
| ロール | 公開作業者にAzure AI Userなど必要な権限があるか |
| Azure Bot Service | サブスクリプションで作成可能か |
| リソースプロバイダー | Microsoft.BotServiceが登録されているか |
| エージェントID | 新しいモデルのエージェントとして一意のIDを持っているか |
| 公開範囲 | 自分だけにするか、組織向けにするか決まっているか |
| 管理者承認 | 組織向け公開の場合、Microsoft 365管理者の承認フローを用意しているか |
公開作業でつまずきやすいのは、AIエージェントそのものの品質ではなく、Azure側の権限、Bot Serviceの作成、Microsoft 365管理者承認、アプリポリシーの設定です。開発担当者だけで完結させず、Microsoft 365管理者とAzure管理者を早い段階で巻き込むのが現実的です。
公開手順の全体像
Microsoft FoundryからMicrosoft 365 CopilotとTeamsへ公開する流れは、大きく分けると「アクティブバージョンの選択」「公開メタデータの入力」「公開範囲の選択」「必要に応じた管理者承認」です。
アクティブなエージェントバージョンを選ぶ
FoundryポータルのPublishメニューでは、エンドポイントURL、アクティブバージョン、TeamsとMicrosoft 365 Copilotへの公開リンクを確認できます。公開前には、利用者に提供したいエージェントバージョンを選択します。(Microsoft Learn)
ここでの判断は重要です。開発中の最新版をそのまま公開すると、未検証の変更がMicrosoft 365やTeamsの利用者に届く可能性があります。業務利用では、以下のように使い分けると安全です。
| 運用方針 | 向いているケース | 注意点 |
|---|---|---|
| 常に最新バージョンを使う | 小規模な検証、開発チーム内の試用 | 新しい変更がすぐ反映されるため、品質管理が必要 |
| 特定バージョンに固定する | 本番運用、全社展開、重要業務 | 新バージョンを出した後に切り替え作業が必要 |
Microsoftの関連ドキュメントでは、既定では最新バージョンへルーティングされ、特定バージョンに固定すると新しいバージョンを作成しても提供内容は変わらないと説明されています。TeamsやMicrosoft 365へ公開する本番エージェントでは、安定性を重視して特定バージョンに固定する判断が有効です。(Microsoft Learn)
公開メタデータを入力する
公開時には、エージェント名、公開バージョン、短い説明、詳細説明、開発者名などを入力します。必要に応じて、開発者Webサイト、利用規約、プライバシーステートメントのURLも設定できます。これらのURLはHTTPSが必要です。(Microsoft Learn)
メタデータは単なる説明欄ではありません。ユーザーがエージェントストアで「使うべきか」を判断する材料になります。名前や説明が曖昧だと、せっかく公開しても使われません。
悪い例は「社内AI」「業務支援Bot」のように用途が広すぎる名前です。良い例は「経費精算ルール確認エージェント」「営業提案書レビュー支援」「Microsoft 365問い合わせヘルプ」のように、利用シーンが一目で分かる名前です。
説明文では、次の3点を明確にすると利用率が上がります。
| 項目 | 書くべき内容 | 例 |
|---|---|---|
| 何をするか | エージェントの主な役割 | 社内規程に基づいて経費精算ルールを案内します |
| 何ができないか | 誤用を防ぐ境界線 | 最終的な承認判断や例外処理は担当部門に確認してください |
| 使いどころ | 最初に聞くべき質問例 | 「出張時の日当ルールを教えて」と質問できます |
また、Microsoft公式ドキュメントでは、メタデータ欄にシークレット、APIキー、機密情報を含めないよう警告しています。これらの項目はユーザーに表示されるため、社内限定の公開であっても秘匿情報を入れてはいけません。(Microsoft Learn)
公開範囲は「自分だけ」と「組織内」で運用が大きく変わる
公開オプションでは、Direct publishとして「Just you」と「People in your organization」を選べます。前者は自分向けにすぐ利用でき、管理者承認は不要です。後者は組織向け公開で、Microsoft 365管理者の承認が必要です。承認後、エージェントは組織で作成されたエージェントとして表示されます。(Microsoft Learn)
| 公開範囲 | 使えるタイミング | 管理者承認 | 向いている用途 |
|---|---|---|---|
| 自分だけ | 公開後すぐ | 不要 | 個人テスト、少人数検証、デモ |
| 組織内ユーザー | 管理者承認後 | 必要 | 部門展開、全社展開、本番利用 |
IT部門がまず選ぶべきなのは、多くの場合「自分だけ」です。まず作成者や検証メンバーで動作を確認し、回答品質、権限、ログ、誤回答時の案内、利用者向け説明を整えてから組織向け公開に進むのが安全です。
一方で、業務部門が本番利用を前提にしている場合は、最初から組織向け公開の承認手順を確認しておくべきです。承認者が不明、アプリポリシーで制限されている、公開後にユーザーが見つけられない、といった問題は導入直前に発覚しやすいからです。
Direct publishとDownload & customizeの使い分け
公開方法には、Foundryから直接公開する方法と、マニフェストをダウンロードしてカスタマイズする方法があります。Microsoft公式ドキュメントでは、直接公開する方法に加え、ZIP形式でエージェントマニフェストをダウンロードし、Teams側でアップロードする流れも示されています。(Microsoft Learn)
| 方法 | 特徴 | 向いているケース |
|---|---|---|
| Direct publish | Foundryポータルからそのまま公開できる | まず試したい、標準的な公開で十分 |
| Download & customize | マニフェストを編集してTeamsにアップロードする | アプリ定義を細かく調整したい、社内配布前に追加確認したい |
一般的な社内展開では、まずDirect publishで検証し、ブランド表記や配布ルールなどを細かく管理したい場合にDownload & customizeを検討するとよいでしょう。
ただし、マニフェストを編集する場合は、Teamsアプリ管理や組織のアプリ提出ルールを理解している担当者が扱うべきです。業務部門だけで進めると、公開後にアプリ管理ポリシーや承認フローで止まる可能性があります。
Microsoft 365管理者が見るべき承認ポイント
組織向けに公開されたエージェントは、Microsoft 365管理者が管理センターで確認・承認します。Microsoft公式ドキュメントでは、組織スコープのエージェントはMicrosoft 365 admin centerで承認され、承認後にエージェントストア上の「Built by your org」に表示されると説明されています。(Microsoft Learn)
管理者は、単に「公開してよいか」だけでなく、次の観点で確認する必要があります。
| 確認観点 | 見るべき内容 |
|---|---|
| 業務目的 | 何の業務を支援するエージェントか |
| 利用対象 | 全社向けか、特定部門向けか |
| データアクセス | どのデータ、ツール、Azureリソースへアクセスするか |
| 権限 | エージェントIDに過剰なRBAC権限が付いていないか |
| 説明文 | ユーザーに誤解を与えない説明になっているか |
| 制限事項 | できないことや注意点が明記されているか |
| 問い合わせ先 | 不具合や誤回答時の連絡先が分かるか |
特に重要なのは、エージェントのIDに付与された権限です。Microsoft FoundryのRBAC関連ドキュメントでは、Microsoft Entra ID認証を使う場合にRBACロールが適用され、必要最小限の権限を割り当てる考え方が示されています。(Microsoft Learn)
社内向けAIエージェントでは、「便利だから広める」よりも、「どの情報にアクセスできるか」「誰が利用できるか」「誤回答時にどう扱うか」を先に決めることが重要です。
バージョン更新時は再公開が必要とは限らない
公開済みエージェントを更新する場合、必ずしもMicrosoft 365やTeamsへ再公開する必要はありません。Microsoft公式ドキュメントでは、新しいエージェントバージョンをロールアウトする場合、Foundryポータルのバージョンセレクターを更新すればよく、安定したエンドポイントURLは同じままだと説明されています。(Microsoft Learn)
この仕組みは、運用設計に大きく影響します。たとえば、次のような更新パターンを分けて考えると分かりやすいです。
| 更新内容 | 主な作業 | 再公開の考え方 |
|---|---|---|
| 回答ロジックやプロンプトの改善 | 新しいエージェントバージョンを作成し、アクティブバージョンを切り替える | エンドポイントは維持できる |
| 表示名や説明文の変更 | Teams/Microsoft 365 Copilot上の表示プロパティを更新する | メタデータ更新が必要 |
| 利用対象の変更 | 管理者承認やアプリポリシーを確認する | Microsoft 365管理者の確認が必要 |
| 連携ツールの権限変更 | エージェントIDやAzureリソースのRBACを見直す | 動作検証が必要 |
注意したいのは、「Always use latest」を選んでいる場合です。新しいバージョンを作成すると、Microsoft 365やTeamsで提供される内容が自動的に変わる可能性があります。Microsoft公式ドキュメントでも、既定では新しいバージョンが自動的に提供され、特定バージョンに固定している場合はセレクターの更新が必要と説明されています。(Microsoft Learn)
本番エージェントでは、検証環境や検証用公開で「Always use latest」を使い、本番公開では特定バージョンに固定する運用が安全です。
制限事項: Microsoft 365とTeamsで同じ機能が使えるとは限らない
Microsoft FoundryのエージェントをMicrosoft 365 CopilotやTeamsに公開できるとはいえ、すべての機能が同じように使えるわけではありません。Microsoft公式ドキュメントでは、Microsoft 365へ公開されたエージェントではファイルアップロードと画像生成が動作しない一方、Teamsでは動作するとされています。また、TeamsやAzure Bot Service連携ではPrivate Linkがサポートされず、公開済みエージェントはストリーミング応答や引用に対応しないとされています。(Microsoft Learn)
| 制限事項 | 実務への影響 | 対応方針 |
|---|---|---|
| Microsoft 365側でファイルアップロードが使えない | 文書をアップロードして処理する用途に向かない場合がある | Teamsでの利用や別導線を検討する |
| Microsoft 365側で画像生成が使えない | 画像生成エージェントとしての展開には制約がある | Teamsでの動作確認を行う |
| Private Link非対応 | ネットワーク分離要件が厳しい環境では注意が必要 | セキュリティ要件を事前確認する |
| ストリーミング応答非対応 | 長文回答の体感速度に影響する可能性がある | 回答を短く設計し、段階的に質問させる |
| 引用非対応 | 根拠提示が重要な業務では注意が必要 | 回答内で参照元の扱いを別途設計する |
この制限を知らずに導入すると、「Foundryのテスト画面ではできたのに、Microsoft 365 Copilotでは期待通りに動かない」というギャップが起きます。特に文書アップロード、画像生成、根拠提示を重視するユースケースでは、公開先ごとの動作確認が必須です。
失敗しやすいポイントと対策
Microsoft Foundry / Azure OpenAIのエージェント公開では、エージェントの作成よりも、公開後の権限・承認・表示・バージョン管理でつまずくことが多くなります。Microsoft公式ドキュメントでも、無効なメタデータ、Bot Service作成失敗、管理者承認待ち、エージェントIDの権限不足、ユーザーがエージェントを見つけられない問題などがトラブルシューティングとして挙げられています。(Microsoft Learn)
| ありがちな失敗 | 原因 | 対策 |
|---|---|---|
| 公開エラーが出る | メタデータやバージョン番号に問題がある | エージェント名、説明、開発者名、バージョン形式を確認する |
| Bot Service作成に失敗する | 権限不足、またはMicrosoft.BotService未登録 | Azure側の権限とリソースプロバイダー登録を確認する |
| 組織向けに公開したのに表示されない | 管理者承認待ち、またはアプリポリシーの制限 | Microsoft 365 admin centerで承認状況を確認する |
| Foundryでは動くが公開後に失敗する | エージェントIDに必要なAzureリソース権限がない | エージェントIDへ必要なRBACロールを付与する |
| ユーザーが見つけられない | 公開範囲や共有リンクの案内が不十分 | 自分向け公開ならリンク共有、組織向けなら承認と表示場所を案内する |
| 新バージョンで品質が落ちる | 最新版が自動反映されている | 本番では特定バージョン固定を検討する |
現場で特に見落とされやすいのは、エージェントのIDに対する権限です。公開前に動いたとしても、公開後に別のIDや権限状態で下流リソースへアクセスできず失敗することがあります。Azure Storage、Azure AI Search、社内APIなどを使うエージェントでは、利用するリソースごとにRBACを確認してください。
旧モデルからの移行で注意すべきこと
Microsoft Foundryでは、旧来のAgent Applicationを使った公開モデルから、新しいエージェントオブジェクトモデルへの移行も整理されています。Microsoftの移行ガイドでは、新しいモデルではAgent ApplicationやDeploymentの責務がAgentオブジェクトに統合され、エージェント作成時点で安定したエンドポイントと一意のIDを持つことが重要な変更点として説明されています。(Microsoft Learn)
移行時のポイントは、既存のAgent Applicationがすぐに止まるわけではない一方、新しい公開体験や安定したエージェントエンドポイントを使うには、新モデルのエージェントを前提に考える必要があることです。Microsoftの移行ガイドでは、既存のAgent Applicationsは引き続き動作し、Microsoft 365やTeamsへ公開済みのものも継続して機能するとされています。(Microsoft Learn)
ただし、レガシーエージェントには注意が必要です。移行ガイドでは、agent.identityがnullのレガシーエージェントは新モデル経由でTeams/Microsoft 365へ公開できず、一意のIDを得るには同じ定義で新しいエージェントを作成する必要があると説明されています。(Microsoft Learn)
既存環境を持つ組織は、次の順で棚卸しすると移行計画を立てやすくなります。
| 棚卸し項目 | 確認内容 |
|---|---|
| 既存Agent Application | どの業務で使われているか |
| 公開先 | Teams、Microsoft 365 Copilot、既存アプリのどこで使われているか |
| エンドポイント | 旧URLを参照しているコードや連携がないか |
| IDとRBAC | 新しいエージェントIDに必要な権限を付け直す必要があるか |
| 業務影響 | 旧アプリを停止する前に新エージェントで十分検証したか |
移行では、「同じエージェント名で作り直せば終わり」と考えないことが大切です。エンドポイントURL、ID、RBAC、Teams/Microsoft 365側の表示、ユーザー案内まで含めて移行計画を作る必要があります。
業務ユーザー向けエージェント公開で使いやすくする設計
エージェントをMicrosoft 365 CopilotやTeamsに公開できても、ユーザーが使い方を理解できなければ定着しません。IT部門は、公開前に「業務ユーザーが最初に何を聞けばよいか」まで設計しておくべきです。
たとえば、社内FAQエージェントなら、説明欄や社内案内に次のような質問例を入れると使い始めやすくなります。
| エージェント用途 | 最初の質問例 |
|---|---|
| 社内規程確認 | 「在宅勤務の申請条件を教えて」 |
| 経費精算 | 「新幹線の領収書がない場合の申請方法は？」 |
| 営業支援 | 「この提案書の改善点を3つ挙げて」 |
| ITヘルプデスク | 「Teams会議の録画が見つからない時の確認手順は？」 |
| 人事問い合わせ | 「育児休業の申請に必要な書類を教えて」 |
また、AIエージェントは万能ではありません。業務利用では、次のような注意文を入れると誤用を減らせます。
| リスク | ユーザー向けに伝えるべきこと |
|---|---|
| 誤回答 | 重要な判断は担当部署や公式文書で確認する |
| 古い情報 | 更新日や対象期間を確認する |
| 権限不足 | 見えない情報は回答できない場合がある |
| 機密情報 | 不要な個人情報や機密情報を入力しない |
| 業務外利用 | 想定用途以外の質問では正確に回答できない可能性がある |
公開後の利用率を上げるには、エージェントの性能だけでなく、名前、説明、質問例、問い合わせ先、制限事項の明示が欠かせません。
Microsoft 365管理者・ITチーム・業務部門の役割分担
Microsoft Foundry / Azure OpenAIのエージェント公開は、開発者だけの作業ではありません。Microsoft 365管理者、Azure管理者、業務部門、セキュリティ担当が関わるほど、本番展開は安定します。
| 役割 | 主な担当 |
|---|---|
| 業務部門 | ユースケース定義、回答内容の確認、質問例の作成 |
| 開発者・AI担当 | エージェント作成、ツール連携、テスト、バージョン管理 |
| Azure管理者 | Azureリソース、Bot Service、RBAC、リソースプロバイダー確認 |
| Microsoft 365管理者 | 組織向け公開の承認、アプリポリシー、利用対象の管理 |
| セキュリティ担当 | データアクセス、機密情報、監査、利用ルールの確認 |
PoCでは1人が複数の役割を兼ねても問題ありません。しかし、本番運用では承認者、問い合わせ先、更新責任者、障害時の対応者を明確にしておくべきです。特に全社向けに公開するエージェントは、アプリと同じようにライフサイクル管理する必要があります。
導入前に決めておきたい運用ルール
エージェントを公開する前に、最低限次の運用ルールを決めておくと、公開後の混乱を減らせます。
| ルール | 決める内容 |
|---|---|
| 公開基準 | どのテストを通過したら公開できるか |
| バージョン管理 | 本番では最新版自動反映か、特定バージョン固定か |
| 承認フロー | 組織向け公開を誰が承認するか |
| メタデータ管理 | 表示名、説明、利用規約、プライバシー文書を誰が更新するか |
| 権限管理 | エージェントIDに付与するRBACを誰が確認するか |
| 利用者サポート | 問い合わせ窓口、不具合報告、改善要望の受け口 |
| 廃止基準 | 使われなくなったエージェントをどう停止・削除するか |
小さく始めるなら、「自分だけ」公開で検証し、次に部門内ユーザーへ案内し、最後に組織向け公開へ進める段階的な展開が現実的です。いきなり全社公開すると、想定外の質問、権限不足、説明不足、管理者承認の遅れが同時に発生しやすくなります。
2026年4月更新の実務的な意味
2026年4月22日に更新された「Publish agents to Microsoft 365 Copilot and Microsoft Teams – Microsoft Foundry」は、Microsoft Foundry / Azure OpenAIで作ったエージェントを、社内利用の入口であるMicrosoft 365 CopilotとTeamsへ展開するための実務ガイドとして重要です。(Microsoft Learn)
今回のポイントを整理すると、次の通りです。
| 重要ポイント | 実務での意味 |
|---|---|
| Foundryポータルから公開できる | 開発後の社内展開手順が分かりやすくなる |
| 安定したエンドポイントを公開する | 利用者の入口を変えずにバージョン更新しやすい |
| 自分だけ・組織内の公開範囲を選べる | PoCから本番展開へ段階的に進められる |
| 組織向け公開には管理者承認が必要 | Microsoft 365管理者との連携が必須 |
| メタデータがユーザーに表示される | 名前や説明の品質が利用率に直結する |
| Microsoft 365とTeamsで制限が異なる | 公開先ごとの検証が必要 |
| 旧モデルからの移行観点がある | 既存Agent Application利用組織は棚卸しが必要 |
次に取るべき行動は、まず自社のエージェント候補を1つ選び、Foundry上でテスト済みバージョンを作ることです。そのうえで、「自分だけ」公開でMicrosoft 365 CopilotやTeamsからの見え方を確認し、メタデータ、権限、制限事項、管理者承認フローを整えてから組織向け公開へ進めるのが安全です。
Microsoft Foundry / Azure OpenAIの価値は、エージェントを作るだけでは発揮されません。ユーザーが普段使うMicrosoft 365 CopilotやTeamsに自然に組み込み、管理者が安全に承認・運用できる状態を作って初めて、業務改善につながります。
コメント