カスタム Copilot エージェントは、作ることより「どう配るか」で定着率が決まります。2026年4月10日に更新された Microsoft 365 ロードマップ ID 557947 では、ユーザーが自作エージェントを Microsoft Teams のチームへ直接共有し、必要に応じてそのチームの主要チャネルへ通知できる機能が Launched として公開されています。結論からいうと、この更新で Teams は、社内 Copilot ツールを「見つけてもらう」「配る」「使い始めてもらう」ための実用的な配布レイヤーになりました。(Microsoft)
ただし、ここは誤解しやすいポイントです。Microsoft 365 Copilot の Agent Builder による共有は、あくまで限定的な直接共有が基本で、Microsoft の説明でも共有リンクを開くとブラウザーで利用が始まる設計です。さらに、Agent Builder で作成したエージェントは現時点で Teams Chat では使えない既知の制限があります。つまり今回の価値は、「Teams がそのまま実行基盤になった」ことより、「Teams が社内配布と周知の導線になった」ことにあります。(Microsoft Learn)
2026年4月10日更新で何が変わったのか
今回のアップデートで押さえるべき変化はシンプルです。Microsoft のロードマップでは、ユーザーは共有ダイアログから Teams のチームを検索し、そのチームにカスタム Copilot エージェントを直接共有できるようになりました。さらに、必要に応じてチームの主要チャネルへ通知を送れるため、共有した瞬間に「誰に向けたエージェントか」と「どこから使い始めるか」を同時に伝えやすくなります。ロードマップ上の記載は Worldwide の標準マルチテナント向け、General Availability、Web 対応です。(Microsoft)
あわせて重要なのが、Microsoft 365 Copilot で作成したエージェントは既定では Only you、つまり作成者だけが使える状態で始まる点です。今回の Teams 共有は、この「自分専用の試作品」を、個人配布ではなくチーム単位の社内ツールへ引き上げるための一歩と見ると理解しやすいです。(Microsoft Learn)
Teams 共有が内部 Copilot ツールの配布レイヤーになる理由
ここでいう「配布レイヤー」とは、エージェントを作ったあとに、誰に知らせるか、どこから見つけてもらうか、最初の利用までどうつなぐかを担う層のことです。社内 AI ツールは精度だけでは広まりません。共有先のまとまり、周知の導線、管理者統制の3つが揃って初めて定着します。
共有先が「人」ではなく「業務単位」になる
Microsoft 365 Copilot の共有設定では、特定ユーザーだけでなく、セキュリティ グループ、Microsoft 365 グループ、Teams のチームを共有先として指定できます。これが大きいのは、配布単位を「個人」から「業務のまとまり」に変えられるからです。たとえば、情シスの FAQ エージェントを情報システム部のチームへ、営業提案の下書き支援エージェントを営業企画チームへ、入社手続き案内エージェントを人事オンボーディングのチームへ、という形で用途と受け手を一致させやすくなります。(Microsoft Learn)
個人宛てのリンク配布は、どうしても「誰に送ったか」「異動後どうするか」「新メンバーに再案内したか」が散らばりがちです。Teams のチーム単位で共有できると、配布対象を業務単位で揃えやすく、説明コストも下げられます。
告知と利用開始の導線がひと続きになる
Teams 共有の実務上の強みは、通知まで一緒に設計できることです。Microsoft の説明では、チームに共有する際、通知メッセージをチームのホームチャネルへ投稿できます。これにより、エージェントの存在を知らせる投稿が、そのまま初回利用の入口になります。(Microsoft Learn)
社内ツールが使われない典型例は、「作った人しか存在を知らない」「URL はあるがどこに貼ったか分からない」「使い方の最初の一歩が曖昧」という状態です。Teams のチャネル通知は、この3つを同時に潰せます。普段そのチームが会話している場所に出せるため、メールやポータルのお知らせ欄よりも見落とされにくいのが実務上の利点です。
限定公開から本番配布へ自然に昇格できる
Microsoft は、Microsoft 365 Copilot の共有を「限定的な直接アクセス」、Copilot Studio による公開を「正式な配布」と明確に分けています。共有はチーム内コラボレーションやフィードバック、限定運用に向き、組織全体への正式展開や複数チャネル連携は Copilot Studio の役割です。(Microsoft Learn)
この整理に当てはめると、Teams への直接共有はちょうど中間レイヤーです。
個人の試作品 → Teams チームでの限定展開 → Copilot Studio での正式公開、という順番が作れます。
この順番が強いのは、いきなり全社展開しなくていいからです。まず1チームで使ってもらい、質問の偏りや説明不足を直し、それから公開範囲を広げるほうが、失敗コストが小さくなります。
管理者統制を残したまま広げられる
Teams へ直接共有できるようになっても、無制限な野良配布になるわけではありません。Microsoft 365 管理センターでは、管理者がエージェントを有効化、無効化、割り当て、ブロック、削除できます。Agent Builder の共有自体も、全ユーザーに許可するか、特定ユーザーやグループだけにするか、完全に無効化するかを組織単位で制御できます。(Microsoft Learn)
さらに、Microsoft 365 Copilot は、各ユーザーが少なくとも閲覧権限を持つ組織データだけを提示し、プロンプトや応答、Microsoft Graph 経由でアクセスしたデータは基盤モデルの学習には使われません。Teams が配布の入口になっても、データ境界そのものが緩むわけではない、というのは導入判断で大きな安心材料です。(Microsoft Learn)
要するに、今回の機能で整理しやすくなったのは次の3層です。
- 作成レイヤー: Microsoft 365 Copilot Agent Builder や Copilot Studio
- 配布レイヤー: Teams のチーム共有とチャネル通知
- 統制レイヤー: Microsoft 365 管理センターと Teams 管理センター
この3層を分けて考えると、「誰でも勝手に広められるのでは」という不安と、「せっかく作ったのに使われない」という不満を同時に整理しやすくなります。(Microsoft Learn)
どの配布方法を選ぶべきか
Microsoft の一次情報を踏まえると、共有 と 公開 は同じではありません。Microsoft 365 Copilot の共有は限定的な直接アクセス向けで、Copilot Studio で公開したエージェントは Teams app store の「Built with Power Platform」や、管理者承認後の「Built for your org」、Microsoft 365 Agent Store などを通じて見つけやすくできます。さらに Teams の setup policy を使えば、管理者がインストールやピン留めまで実行できます。(Microsoft Learn)
| 状況 | 最初に選ぶ方法 | 判断理由 |
|---|---|---|
| 同じチーム内で素早く試したい | Teams に直接共有 | チーム単位で配れて、チャネル通知まで一気に進めやすい |
| 複数チームへ段階展開したい | 特定ユーザー・グループ・Teams 共有 | 対象を絞ったまま改善できる |
| Teams 内で継続的に見つけてもらいたい | Copilot Studio 公開 + Teams 側の発見性強化 | 毎回リンクを配り直さずに導線を作りやすい |
| 全社標準ツールにしたい | 管理者承認 + Agent Store / Teams app store + ピン留め | 配布規模、統制、初期利用率を両立しやすい |
特に覚えておきたいのは、「共有した」ことと「全員に見つかる」ことは別だという点です。Copilot Studio の説明でも、共有済みユーザー向け表示と、組織向け表示は分かれています。全社展開を狙うなら、最初から公開導線まで設計したほうが手戻りが少なくなります。(Microsoft Learn)
Teams 共有を成功させる導入手順
1チーム1用途に絞る
最初から「何でも答える社内万能エージェント」を目指すと、質問の幅が広がりすぎて失敗しやすくなります。最初は、1つのチームに対して1つの用途に絞るのが安全です。
たとえば、次のような切り方です。
- 経理チーム向け: 経費精算と請求書処理の質問対応
- 情シスチーム向け: PC・アカウント・申請手順の案内
- 営業チーム向け: 提案書テンプレートと過去提案の参照支援
共有先は「使う人が集まる Teams チーム」にする
今回の機能の価値は、共有先を Teams チームにできることです。逆に言えば、雑に広く配るより、実際にその業務を行うチームへ出したほうが効果が出ます。共有対象が曖昧だと、誰にも刺さらないエージェントになりやすいです。(Microsoft Learn)
通知文に「最初の質問例」を入れる
チャネル通知だけでは不十分です。投稿を見たメンバーが次の行動を取りやすいように、最初の質問例を3つほど添えてください。たとえば、次のような書き方です。
このエージェントでできること
- 「経費精算の締め日はいつ？」
- 「出張申請の流れを3行で教えて」
- 「関連する社内規程の場所も教えて」
これだけで、初回利用率はかなり変わります。社内 AI ツールは「使えるかどうか」より「何を聞けばいいか分からない」で止まることが多いからです。
参照元データの権限を先に確認する
エージェント本体を共有しても、SharePoint や OneDrive の参照元にメンバーがアクセスできなければ、期待した答えは返りません。Microsoft も、ユーザーが知識ソースにアクセスできない場合、その内容は応答に含まれないと明記しています。しかも、自動共有できるのは選択したファイルやフォルダー単位で、サイト全体の権限が自動で開くわけではありません。(Microsoft Learn)
需要が広がったら「共有」から「公開」へ上げる
他チームから「うちでも使いたい」が出始めたら、限定共有のまま回し続けるより、Copilot Studio 公開や管理者承認、Teams でのピン留めを検討するタイミングです。共有で回すフェーズと、正式な社内ツールとして配るフェーズは分けたほうが、説明責任も保守も楽になります。(Microsoft Learn)
失敗しやすいポイントと対策
Teams に共有したのに Teams チャットで使えない
ここは最も誤解されやすいところです。Microsoft 365 Copilot の Agent Builder で共有したエージェントは、共有リンクを開くとブラウザーウィンドウで開きます。しかも、Agent Builder で作成したエージェントは現時点で Teams Chat では使えません。Teams 共有は、Teams ネイティブ実行というより Teams 起点の配布 と捉えるべきです。(Microsoft Learn)
共有したのに答えが薄い、または空振りする
原因の多くは権限です。Microsoft 365 Copilot は、ユーザーが閲覧権限を持つデータしか出せません。さらに Agent Builder の共有では、特定ユーザー向け共有で SharePoint のファイルやフォルダーを共有できても、サイト全体のアクセス権が自動付与されるわけではありません。答えが薄いときは、まずプロンプト改善ではなく参照元の権限を疑うほうが早いです。(Microsoft Learn)
一部のメンバーだけエラーになる
Microsoft は、エージェントの機能によって必要なライセンスが変わり、適切なライセンスがない場合はエラーになる可能性があると案内しています。チームへ共有したのに使えない人がいる場合、まず共有漏れではなく、ライセンスや利用可能機能の差を確認したほうが確実です。(Microsoft Learn)
管理者ポリシー変更後に更新できない
管理者が共有ポリシーを変更したあと、既存の共有はそのまま残る一方で、新しい共有や更新時に制限へ引っかかることがあります。Microsoft も、共有ルール変更は新しい共有操作に適用され、既存アクセスは自動では取り消されないと説明しています。運用中のエージェントが急に更新できなくなったら、機能不具合より先に共有ポリシーとの整合性を確認してください。(Microsoft Learn)
全社向けにしたいのに、共有だけでは埋もれる
限定共有は便利ですが、発見性には限界があります。Copilot Studio の説明でも、共有済みユーザー向けの表示と、組織向け表示は別です。さらに Teams 側では、管理者が setup policy でインストールやピン留めを行えるため、本気で使ってほしい標準ツールは公開と配布ポリシーまでセットで考えたほうが定着します。(Microsoft Learn)
次に取るべき行動
まずやるべきことは、1つの業務テーマでカスタム Copilot エージェントを作り、最も相性の良い Teams チームへ直接共有してみることです。通知には「このエージェントで何を聞けるか」の例を必ず添え、SharePoint や OneDrive の権限も一緒に確認してください。ここで利用が定着し、別チームから横展開の要望が出たら、Copilot Studio の公開、管理者承認、Teams でのピン留めへ進める。この順番が、速さと統制を両立しやすい進め方です。(Microsoft Learn)
コメント