Microsoft 365 CopilotのAgent Builderで作成したカスタムエージェントを、組織のAgent Storeに申請できるようになります。結論から言うと、この更新のポイントは「作成者が自由に全社公開する」のではなく、Microsoft 365管理センターで管理者が確認・承認してから、Agent Storeの“Built by your org”に公開できるようになる点です。これにより、便利な社内エージェントを広く配布しやすくなる一方で、管理者はデータアクセス、利用範囲、公開可否、更新時の再承認を管理する必要があります。Microsoft 365 Roadmap ID 557173では、対象製品がMicrosoft CopilotとMicrosoft 365 admin center、対象プラットフォームがDesktop/Web、クラウドがWorldwide、ステータスがLaunched、一般提供が2026年5月とされています。更新時刻はUTCで2026年5月29日22:30のため、日本時間では2026年5月30日相当です。(Microsoft)
Microsoft 365 CopilotのAgent Store申請機能で何が変わるのか
今回の更新では、Microsoft 365 CopilotのAgent Builderで作成したカスタムエージェントを、作成者が組織カタログへ送信できるようになります。送信されたエージェントは、Microsoft 365管理センターで管理者が確認し、承認後にAgent Storeの「Built by your org」セクションへ公開されます。Microsoft Learnでも、Agent Builderで作成したエージェントを組織カタログに送信し、管理者が承認後にAgent Storeへ発行する流れが説明されています。(Microsoft Learn)
これまでAgent Builderで作成したエージェントは、主に特定のユーザーやグループへの共有が中心でした。今回の変更により、業務部門が作った便利なエージェントを、管理者の統制下でより広いユーザーに届けやすくなります。
ただし、これは「誰でもすぐ全社公開できる機能」ではありません。管理者のレビュー、公開範囲の指定、必要に応じたプレインストールやピン留めなど、IT部門によるガバナンスが前提になります。
| 観点 | 従来の共有 | 今回の組織カタログ送信 |
|---|---|---|
| 主な目的 | パイロット利用、特定チーム内での共有 | 承認済みエージェントの組織内展開 |
| 配布方法 | 共有リンク | Agent Storeの「Built by your org」 |
| 管理者レビュー | 基本的になし | Microsoft 365管理センターで確認 |
| 公開範囲 | 指定ユーザー、グループ、チーム | 管理者が可用性を制御 |
| 更新反映 | 共有版は発行後すぐ反映 | Agent Store版は再送信と再承認が必要 |
| 向いている用途 | 試作、部門内検証、小規模運用 | 全社・複数部門向けの正式展開 |
共有版とAgent Store版は別々に追跡され、共有版の更新がAgent Store版へ自動反映されるわけではありません。Microsoft Learnでは、共有版は反復やテストに使え、Agent Store版に反映するには管理者レビューへ再送信する必要があると説明されています。(Microsoft Learn)
影響を受けるユーザーと組織
この更新の影響を受けるのは、主に次の3者です。
- Agent Builderでエージェントを作成する業務ユーザー、開発者、部門IT担当者
- Microsoft 365管理センターでエージェントを審査・公開する管理者
- Agent Storeから組織承認済みエージェントを探して利用するエンドユーザー
特に影響が大きいのは、すでに部門ごとにMicrosoft 365 Copilotエージェントを試作している組織です。これまでは「便利なエージェントがあるが、どこで見つければよいか分からない」「リンク共有では利用状況や品質管理が難しい」といった課題がありました。今回の仕組みを使うと、承認済みエージェントをAgent Store内で発見しやすくなります。
一方で、管理者側には新しい運用負荷が生まれます。承認依頼が増えると、エージェントの目的、データソース、アクセス権限、所有者、更新頻度を判断するプロセスが必要になります。レビュー基準を決めずに運用を始めると、申請が滞留したり、同じようなエージェントが乱立したりする可能性があります。
管理者が確認すべき主なポイント
管理者は、送信されたエージェントをMicrosoft 365管理センターの「Agents > All agents > Requests」から確認します。Microsoft Learnでは、管理者が説明、所有者、データ、ツールなどの詳細を確認し、発行または拒否できること、公開時に対象ユーザーを特定のユーザー・グループまたは全員に限定できることが説明されています。(Microsoft Learn)
エージェントの目的と重複を確認する
まず見るべきなのは、エージェントが何を解決するものかです。
例えば「営業提案書作成支援エージェント」と「営業資料ドラフト作成エージェント」が別々に申請された場合、機能が重複している可能性があります。このまま両方を公開すると、ユーザーはどちらを使うべきか迷います。
承認前には、次の観点で整理すると判断しやすくなります。
| 確認項目 | 判断基準 | 例 |
|---|---|---|
| 業務目的 | 明確な利用シーンがあるか | 新入社員向けFAQ、営業提案書の下書き、社内規程検索 |
| 対象ユーザー | 全社向けか、部門限定か | 人事エージェントは全社、営業支援は営業部門限定 |
| 既存エージェントとの重複 | 似た機能がないか | FAQ系エージェントが複数存在しないか |
| 所有者 | 継続的に保守できる担当がいるか | 部門名だけでなく責任者または管理チームを明確化 |
| 更新頻度 | 情報が古くなりやすいか | 規程、価格、製品情報を扱う場合は定期見直しが必要 |
データソースとアクセス権限を確認する
Copilotエージェントは、ナレッジソースとしてSharePoint、OneDrive、Graphコネクタなどの情報を参照する場合があります。管理者は、エージェントがどのデータに基づいて回答するのか、利用者がそのデータへアクセスしてよいのかを確認する必要があります。
Microsoft Learnでは、申請時に管理者が表示名、説明、構成された機能、ナレッジソース、秘密度ラベル、開発者情報、宣言型エージェントのメタデータなどを確認すると説明されています。(Microsoft Learn)
特に注意したいのは、次のようなエージェントです。
- 人事評価、給与、個人情報に関わる資料を参照するエージェント
- 経営会議、未公開製品、契約情報を含むSharePointサイトを参照するエージェント
- 部門内だけで使う前提のナレッジを全社向けに公開しようとしているエージェント
- 個人の会議、メール、チャットなどの作業データを参照する可能性があるエージェント
エージェントを公開しても、ユーザーが元データへアクセスできなければ期待した回答が得られない場合があります。Microsoft Learnでも、エージェントをインストールするユーザーが使用するナレッジソースにアクセスできることを、送信前の前提条件として挙げています。(Microsoft Learn)
公開範囲と展開方法を決める
管理者は、承認時に誰がエージェントを利用できるかを制御できます。全社公開が便利に見えても、最初から全員に展開するのはリスクがあります。
実務では、次の順序で展開するのが安全です。
| 段階 | 対象 | 目的 |
|---|---|---|
| 検証 | 作成者と少人数のテストグループ | 回答品質、権限、参照データの確認 |
| 部門展開 | 関係部門のユーザー | 実業務での利用価値と問い合わせ傾向を確認 |
| 全社展開 | 全ユーザーまたは広範なグループ | 安定運用できるエージェントのみ公開 |
| 定着化 | 必要に応じてピン留めや案内 | よく使うエージェントを見つけやすくする |
Microsoft 365管理センターでは、発行ウィザードでユーザーやグループの選択、ポリシーテンプレートの適用、アクセス許可の確認、必要に応じた管理者同意を行います。(Microsoft Learn)
Agent Builder作成者・開発者が送信前に準備すべきこと
作成者側は、エージェントを「動く状態」にするだけでは不十分です。Agent Storeへ申請する場合は、他のユーザーが見つけ、理解し、安心して使える状態に整える必要があります。
送信前に最低限チェックする項目
Microsoft Learnでは、組織で使用する準備ができていること、組織の標準やポリシーに準拠していること、対象ユーザーがナレッジソースへアクセスできることなどが、送信前の前提として示されています。(Microsoft Learn)
実務では、次のチェックリストを使うと申請差し戻しを減らせます。
| チェック項目 | 悪い例 | 良い例 |
|---|---|---|
| 表示名 | 「営業AI」「テスト用」 | 「営業提案書ドラフト支援」 |
| 簡単な説明 | 「便利なエージェントです」 | 「製品資料と提案テンプレートを基に、営業提案書の初稿を作成します」 |
| ナレッジソース | 個人のOneDrive内ファイル | 部門管理のSharePointサイト |
| スタータープロンプト | 作成者しか分からない表現 | 「新規顧客向け提案書の構成を作成する」 |
| 所有者情報 | 個人名だけ | 部門名、問い合わせ先、管理チーム |
| 利用上の注意 | 記載なし | 「価格・契約条件は必ず最新の公式資料で確認してください」 |
申請時に必要なメタデータを整える
Agent Builderから組織カタログへ送信する際、表示名、簡単な説明、開発者名、作成者Webサイト、プライバシーに関する声明、使用条件などを入力します。Microsoft Learnでは、表示名は30文字、簡単な説明は80文字、開発者名は32文字、各URLは有効なHTTPS URLである必要があると説明されています。(Microsoft Learn)
ここで手を抜くと、公開後の利用率が下がります。Agent Store上でユーザーが最初に見るのは、エージェントの名前と説明です。説明文には「何ができるか」だけでなく、「何に使ってはいけないか」も短く含めると、誤用を減らせます。
例えば、社内規程検索エージェントなら次のように書くと実用的です。
就業規則、休暇、申請手続きに関する社内文書を検索し、該当箇所を要約します。最終判断が必要な場合は人事部へ確認してください。
この説明なら、用途と限界が分かります。逆に「人事のことなら何でも答えます」のような表現は、過度な期待や誤回答時のトラブルにつながりやすくなります。
管理者レビューの流れ
管理者レビューは、単なる承認ボタンの処理ではありません。組織のデータ保護、業務影響、ユーザー体験を確認するプロセスです。
基本的な流れは次の通りです。
| 手順 | 実施者 | 内容 |
|---|---|---|
| エージェント作成・テスト | 作成者 | Agent Builderで作成し、意図した回答が得られるか確認 |
| 組織カタログへ送信 | 作成者 | 最新の発行済みバージョンを申請 |
| 申請内容の確認 | 管理者 | 機能、データソース、アクセス権、説明、所有者を確認 |
| 公開可否の判断 | 管理者 | 発行、拒否、修正依頼を判断 |
| 公開範囲の設定 | 管理者 | 全員、特定ユーザー、セキュリティグループなどを指定 |
| 展開後の監視 | 管理者・所有者 | 利用状況、問い合わせ、更新要否を確認 |
Microsoft Learnでは、保留中の要求を確認する手順として、Microsoft 365管理センターへサインインし、「Agents > All agents > Requests」を開き、要求されたエージェントの詳細を表示し、機能、データソース、セキュリティとアクセス許可、カスタムアクションを確認すると説明されています。(Microsoft Learn)
更新時は再承認が必要になる
見落としやすいのが、公開後の更新です。Agent Builderでエージェントを修正しても、Agent Store版が自動で更新されるわけではありません。Microsoft Learnでは、Agent Builderで発行した変更はAgent Storeへ自動反映されず、更新をAgent Storeへ発行するには再送信が必要だと説明されています。(Microsoft Learn)
この仕様は、ガバナンス上は重要です。なぜなら、承認後に作成者がナレッジソースや動作を大きく変えてしまうと、管理者が確認していないエージェントが実質的に全社配布されることになるからです。
更新運用では、次のルールを決めておくと混乱を防げます。
- 軽微な文言修正でもAgent Store版へ反映する場合は再申請する
- ナレッジソース追加、外部アクション追加、権限変更は必ず重点レビューする
- 申請コメントに「何を変更したか」を作成者が明記する
- 公開済みエージェントには所有者とレビュー周期を設定する
- 古いエージェントは放置せず、廃止・統合の判断を行う
Microsoft Learnでは、更新申請は同じエージェントの更新として扱われ、管理者はレビューを容易にするため増分変更を確認できると説明されています。承認されるまでは、Agent Storeからインストールしたユーザーには最後に承認されたバージョンが表示されます。(Microsoft Learn)
共有とAgent Store公開を使い分ける判断基準
今回の機能が追加されても、すべてのエージェントをAgent Storeへ出す必要はありません。むしろ、目的に応じた使い分けが重要です。
共有で十分なケース
次のような場合は、まず共有で運用する方が向いています。
- まだ試作段階で、回答品質を検証中
- 利用者が数名から十数名程度
- 部門内の一時的なプロジェクトで使う
- ナレッジソースやプロンプトを頻繁に変更する
- 管理者レビューに出す前に利用価値を確認したい
例えば、営業企画チームが新しい提案テンプレートを試すために作成したエージェントなら、最初はチーム内共有で十分です。回答が安定し、他部門でも使えると判断できてから組織カタログへ送る方が安全です。
Agent Store公開に向いているケース
次のようなエージェントは、Agent Store公開の候補になります。
- 全社または複数部門で継続利用する
- 業務標準として案内したい
- ナレッジソースが管理されたSharePointサイトにある
- 所有者と保守体制が明確
- 説明、利用条件、プライバシー情報を整備済み
- 管理者が公開範囲や展開方法を制御したい
代表例としては、社内ITヘルプデスク、就業規則検索、営業提案支援、製品FAQ、オンボーディング支援などが挙げられます。
展開時に失敗しやすいポイント
申請基準を決めないまま公開を始める
申請機能が利用できるようになると、現場から多くのエージェントが送られてくる可能性があります。管理者が都度判断していると、承認基準がぶれます。
最低限、次のような社内ルールを用意しておきましょう。
| ルール項目 | 決めておく内容 |
|---|---|
| 申請条件 | どの状態なら組織カタログへ申請できるか |
| 必須メタデータ | 表示名、説明、所有者、問い合わせ先、利用条件 |
| 禁止データ | 個人情報、機密情報、未承認の外部データなど |
| レビュー担当 | IT管理者、セキュリティ担当、業務主管部門 |
| 更新ルール | どの変更で再レビューが必要か |
| 廃止基準 | 利用が少ない、所有者不在、情報が古い場合の扱い |
ナレッジソースの権限を後回しにする
エージェントの品質は、参照するデータの整理状況に大きく左右されます。SharePointサイトの権限が複雑だったり、古い資料が混在していたりすると、ユーザーによって回答が変わったり、期待した情報が出なかったりします。
公開前には、エージェント側だけでなく、元データ側も確認してください。
- 参照先SharePointサイトの所有者は明確か
- 古い資料や重複ファイルが残っていないか
- 利用対象者が必要なファイルへアクセスできるか
- 秘密度ラベルや共有設定が意図通りか
- 個人のOneDriveに依存していないか
Microsoft Learnでも、管理されたナレッジソースを使い、対象ユーザーがアクセスできるSharePointサイトなどを優先することがベストプラクティスとして示されています。(Microsoft Learn)
公開後の問い合わせ先を決めていない
Agent Storeに公開されたエージェントは、利用者から見ると「会社が承認した公式ツール」のように見えます。そのため、回答が不自然な場合や利用方法が分からない場合の問い合わせ先を明確にしておく必要があります。
エージェントの説明や作成者情報には、少なくとも次の情報を入れると運用しやすくなります。
- 管理部門またはチーム名
- 問い合わせ先のTeamsチャネルまたはSharePointページ
- 利用対象者
- 参照している主な情報源
- 回答をそのまま最終判断に使ってよいかどうか
管理者が今すぐ確認すべき設定と運用
今回の機能は、ロールアウト前に必須対応が発生するタイプではありません。ただし、組織内でAgent Builderの利用が進んでいる場合は、早めに運用設計をしておくべきです。
Microsoft 365管理センターの確認箇所
まず、Microsoft 365管理センターでエージェント管理の導線を確認します。
| 確認場所 | 確認する内容 |
|---|---|
| Agents > All agents > Requests | 申請中、更新待ち、アクティブ化待ちのエージェント |
| Agents > All agents | 公開済み・共有済みエージェントの一覧 |
| エージェント詳細 | 所有者、説明、機能、データソース、権限 |
| 発行ウィザード | 利用可能ユーザー、グループ、ポリシー、アクセス許可 |
| ピン留め設定 | 重要エージェントをユーザーに見つけやすくする設定 |
エージェントレジストリでは、Microsoft製、外部パートナー製、作成者による共有、組織によって発行されたカスタムエージェントなどを一覧管理できます。Microsoft Learnでは、エージェントレジストリが管理者による監視・管理・ガバナンスを支援すると説明されています。(Microsoft Learn)
公開範囲はセキュリティグループで管理する
実務では、個別ユーザーを直接指定するより、セキュリティグループで公開範囲を管理する方が運用しやすくなります。
例えば、営業部向けエージェントなら「SG-Copilot-Agent-Sales」、人事向けなら「SG-Copilot-Agent-HR」のようなグループを作り、承認時にそのグループへ公開します。異動や退職時の管理もしやすく、棚卸しも簡単です。
ピン留めは本当に重要なものに絞る
管理者は、展開されたエージェントをMicrosoft 365 Copilot内でピン留めできます。Microsoft Learnでは、管理者がMicrosoft 365管理センターで最大3つのエージェントをピン留めでき、すべてのユーザーまたは特定ユーザー・グループに対して設定できると説明されています。(Microsoft Learn)
便利だからといって多くのエージェントを目立たせると、ユーザー体験が悪くなります。ピン留めは、社内ITヘルプデスク、全社FAQ、よく使う申請支援など、利用頻度が高く業務影響の大きいものに限定するのが現実的です。
開発者・作成者向けの実務チェックリスト
Agent Builderで作成したエージェントをAgent Storeへ申請する前に、次のチェックを行いましょう。
| 分類 | チェック内容 |
|---|---|
| 品質 | 想定質問を10〜20件程度テストしたか |
| 説明 | ユーザーが用途を理解できる表示名と説明になっているか |
| データ | 参照先が部門管理または組織管理のデータになっているか |
| 権限 | 利用対象者がナレッジソースへアクセスできるか |
| セキュリティ | 機密情報や個人情報を不用意に扱っていないか |
| 保守 | 所有者、問い合わせ先、更新担当が決まっているか |
| 申請情報 | プライバシーに関する声明、使用条件、作成者情報を整備したか |
| 更新計画 | いつ誰が内容を見直すか決めているか |
特に、エージェントの「短い説明」は軽視されがちです。しかしAgent Storeでユーザーがインストールするかどうかを判断する重要な情報です。80文字以内で、用途、参照データ、注意点をできるだけ具体的に書きましょう。
移行・展開で考えるべきこと
既存の共有エージェントをすべてAgent Storeへ移行する必要はありません。まずは利用実績があり、問い合わせが少なく、ナレッジソースが整理されているエージェントから移行候補にします。
おすすめの進め方は次の通りです。
| フェーズ | 実施内容 |
|---|---|
| 棚卸し | 現在共有されているAgent Builderエージェントを一覧化 |
| 分類 | 試作、部門利用、全社候補、廃止候補に分類 |
| 整備 | 名前、説明、所有者、データソース、権限を修正 |
| パイロット | 少人数または部門単位でAgent Store公開 |
| 本展開 | 利用状況と問い合わせを見て対象範囲を拡大 |
| 継続管理 | 定期レビュー、更新申請、不要エージェントの整理 |
この流れにすると、現場の創意工夫を止めずに、IT管理者が安全性と品質を確保できます。
まず取るべき次のアクション
今回のMicrosoft 365 Copilot更新は、Agent Builderで作成した社内エージェントを、管理者の承認を経てAgent Storeで発見・利用できるようにする重要な変更です。便利なエージェントを組織に広げやすくなる一方で、データアクセス、公開範囲、更新時の再承認、所有者管理を曖昧にすると、エージェントの乱立や誤用につながります。
まずは、Microsoft 365管理センターで「Agents > All agents > Requests」の確認手順を管理者内で共有し、社内のAgent Builder利用状況を棚卸ししてください。そのうえで、申請基準、レビュー担当、公開範囲、更新ルールを決めます。開発者や業務部門には、Agent Storeへ出す前に「業務目的」「管理されたナレッジソース」「所有者」「説明文」「利用上の注意」を整えるよう案内すると、承認後の運用が安定します。
なお、Microsoft 365 Roadmapは商用機能の予定や説明を示すもので、リリース日や内容は変更される可能性があります。実際の展開状況は、自社テナントのMicrosoft 365管理センターと最新の公式ドキュメントで確認しながら進めるのが安全です。(Microsoft)
コメント