2026年5月5日更新の「Microsoft Copilot documentation update: Add Submit to your org catalog content for Agent Builder」で最も重要なのは、Agent Builderで作成したエージェントを、作成者が組織カタログへ提出し、管理者の審査後にMicrosoft 365 Copilot Agent Storeの「Built by your org」へ公開できる流れが文書化されたことです。
これまでチームや特定ユーザーへの共有が中心だったAgent Builder製エージェントを、組織全体で見つけやすく配布するための導線が明確になります。対応すべきなのは、エージェント作成者だけではありません。Microsoft 365管理者、セキュリティ・法務担当、社内展開を担当する情報システム部門も、承認フロー、公開範囲、プライバシー文書、ナレッジソースの権限を確認しておく必要があります。
Microsoft Copilot documentation updateで何が変わるのか
今回のドキュメント更新は、MicrosoftDocsのm365copilot-docsリポジトリにあるPull Request #97「Add Submit to your org catalog content for Agent Builder」に基づくものです。PRでは、Agent Builderの新しい「Submit to your org catalog」フローを説明するために、2本の新規記事追加、既存記事2本の更新、TOC更新が行われています。PR上では、作成者がエージェントを管理者レビューへ提出し、承認後にMicrosoft 365 Copilot Agent Storeの「Built by your org」に公開できる流れを扱うと説明されています。(GitHub)
Microsoft 365 Copilot Blogでも、Agent Builderに「管理者レビューと承認を経て組織のAgent Storeカタログに公開する機能」が追加されると案内されています。Microsoftはこの機能について、組織内の高品質な内部エージェントをスケールさせつつ、IT管理者の統制を維持するための更新と位置づけています。(TECHCOMMUNITY.MICROSOFT.COM)
| 更新内容 | 実務上の意味 | 確認すべき担当 |
|---|---|---|
| Agent Builderから組織カタログへ提出できる流れを追加 | 個別共有だけでなく、組織承認済みエージェントとして配布しやすくなる | エージェント作成者、Microsoft 365管理者 |
| 管理者レビュー後にAgent Storeの「Built by your org」へ公開 | 利用者が承認済みエージェントをAgent Storeで探せる | Microsoft 365管理者、社内展開担当 |
| プライバシー声明・利用規約URLの扱いを明文化 | 公開前に法務・セキュリティ観点の確認が必要になる | 法務、セキュリティ、情報システム |
| 共有版とAgent Store版を別管理として整理 | Agent Builderで更新しても、Agent Store版は再承認まで更新されない | 作成者、管理者 |
| 既存の共有・公開関連ドキュメントを更新 | 社内手順書や教育資料の記載を見直す必要がある | 情報システム、IT企画 |
重要なのは、この更新が「すべての既存エージェントを自動的に組織公開する」という意味ではない点です。作成者が提出し、管理者がレビューして公開する流れです。したがって、影響は主に組織内でAgent Builder製エージェントを本格展開したい企業に出ます。
対応が必要な人
今回の変更は、Microsoft Copilotを利用する全ユーザーに即時対応を求めるものではありません。ただし、社内でAgent Builderの利用を進めている組織では、次の担当者が早めに確認すべきです。
| 対象者 | 対応が必要な理由 | 最初にやること |
|---|---|---|
| Agent Builderでエージェントを作るユーザー | 提出前に表示名、説明、作成者情報、URL、ナレッジ権限を整える必要がある | 公開候補のエージェントを棚卸しする |
| Microsoft 365管理者 | 申請されたエージェントをRequestsで審査し、公開・却下・範囲指定を行う | 承認担当、レビュー基準、公開範囲のルールを決める |
| セキュリティ担当 | エージェントが参照するデータ、ツール、権限を確認する必要がある | ナレッジソースと機密情報の確認観点を作る |
| 法務・コンプライアンス担当 | プライバシー声明と利用規約URLがAgent Storeに表示される | 社内で使う正式URLを決める |
| 社内展開・教育担当 | 利用者に「承認済みエージェント」の探し方を案内する必要がある | Agent Storeでの探し方と利用ルールを手順化する |
特に注意したいのは、作成者が「自分のチームで使えればよい」と考えて作ったエージェントを、そのまま組織公開に回すケースです。小規模共有では問題になりにくい表現、未整備の説明文、個人メールや会議情報を前提にした設計、アクセス権が限られたSharePointファイルなどは、組織公開ではトラブルの原因になります。
「共有」と「組織カタログ提出」の違い
今回のMicrosoft Copilot documentation updateで最も誤解しやすいのが、共有と組織カタログ提出は同じではないという点です。
Agent Builderで作成したエージェントは、特定ユーザーやグループに共有することもできます。一方、「Submit to your org catalog」は、管理者が審査したうえでAgent Storeに公開するための流れです。PRで追加された新規ドキュメントでも、共有版とAgent Store版は別エントリとして追跡され、更新サイクルも異なると整理されています。(GitHub)
| 比較項目 | 共有 | Submit to your org catalog |
|---|---|---|
| 主な用途 | テスト、部門内利用、限定ユーザーへの配布 | 組織全体または広い対象への正式配布 |
| 管理主体 | 作成者 | 作成者が提出し、管理者がAgent Store掲載を管理 |
| 対象範囲 | 指定したユーザー、グループ、チームなど | 管理者が設定した公開対象 |
| 管理者レビュー | 基本的には共有設定ベース | Microsoft 365 admin centerでレビュー |
| 更新反映 | 作成者がUpdateすると共有版に反映 | 再提出し、管理者承認後にAgent Store版へ反映 |
| 向いている場面 | 試作、パイロット、限定運用 | 本番運用、全社展開、承認済みエージェント化 |
実務では、まず共有で小さく検証し、利用者のフィードバックを受けてから組織カタログへ提出する流れが安全です。いきなり全社公開を目指すと、説明文の不足、権限不足、誤回答時の問い合わせ先不明などが表面化しやすくなります。
Agent Builder作成者が提出前に確認すべきこと
Agent Builderの新しい提出フローでは、エージェントが「組織で使える状態」になっていることが前提です。新規ドキュメント案では、提出前の条件として、エージェントが少なくとも一度公開済みであること、組織の標準・ルール・ポリシーに準拠していること、利用者がナレッジソースにアクセスできることなどが示されています。(GitHub)
提出前チェックリスト
| チェック項目 | 判断基準 | よくある失敗 |
|---|---|---|
| エージェントが公開済みか | Agent Builderで一度PublishまたはUpdateしている | 未公開のまま提出しようとしてメニューが使えない |
| 説明文が利用者目線か | 「何ができるか」「何に使うべきか」が80文字以内で伝わる | 「便利なエージェントです」のように用途が曖昧 |
| ナレッジソースの権限が適切か | 想定利用者がSharePointやファイルにアクセスできる | 作成者だけが見えるファイルを参照している |
| 個人のWork IQ情報を使う可能性を説明しているか | Teams会議、チャット、メールなどを参照する可能性を説明文で明示 | 利用者が参照範囲を理解しないまま使う |
| 作成者情報が正しいか | 個人名、チーム名、問い合わせ先が分かる | 退職・異動しやすい個人だけを窓口にしている |
| プライバシー声明・利用規約URLが正式か | 組織の正式なHTTPS URLを使う | 既定のプレースホルダーURLを残す |
| スタータープロンプトが実用的か | 利用者がすぐ試せる業務例になっている | 抽象的すぎて使い始められない |
組織カタログに載るエージェントは、単なる「自分用のCopilotカスタマイズ」ではなく、社内向けの小さな業務アプリに近い扱いになります。作成者は、名前や説明だけでなく、利用者が誤解しない導線まで整えるべきです。
提出時に必要な項目
新しい提出ページでは、提出ダイアログで入力するフィールドも整理されています。提出時の項目はすべて必須で、表示名、短い説明、開発者名、作成者Webサイト、プライバシー声明、利用規約を入力します。URL項目は有効なHTTPS URLである必要があります。(GitHub)
| 項目 | 最大文字数 | 実務での入力例 |
|---|---|---|
| Display name | 30文字 | HR FAQ Agent、営業提案レビュー支援 |
| Short description | 80文字 | 人事制度、休暇、福利厚生に関する社内FAQを回答します |
| Developer name | 32文字 | 情報システム部、HR Operations Team |
| Creator website | 2,048文字 | チームのSharePointサイト、社内サポートページ |
| Privacy statement | 2,048文字 | 組織のプライバシー声明ページ |
| Terms of use | 2,048文字 | 社内AI利用規程、サービス利用条件ページ |
ここで入力する「Creator website」は、外部公開サイトである必要はありません。社内利用のエージェントであれば、チームのSharePointサイトや社内問い合わせページのように、利用者が作成元やサポート窓口を確認できる場所が適しています。
About this agentの更新も確認する
既存の共有・管理ドキュメントも更新され、「About this agent」情報を編集する説明が追加されています。Short description、Creator website、Privacy statement、Terms of useなどは、提出ダイアログの事前入力にも使われます。提出を始める前に、Agent BuilderのヘッダーにあるMoreメニューから「About this agent」を確認しておくと、申請時の手戻りを減らせます。(GitHub)
ただし、「About this agent」に入力したからといって、Agent Store版が常に即時更新されるわけではありません。共有版には変更がすぐ反映される一方、Agent Store版の更新には再提出と管理者承認が必要です。この差を理解していないと、「修正したのにAgent Store上の説明が変わらない」という問い合わせにつながります。
作成者側の提出手順
Agent Builderから組織カタログへ提出する流れは、次のように整理できます。
| 手順 | 操作 | 注意点 |
|---|---|---|
| 1 | Microsoft 365 CopilotでAll agentsを開く | 対象エージェントを間違えない |
| 2 | 提出したいエージェントを選びEditを開く | 下書き変更がある場合は先にUpdateする |
| 3 | ヘッダーのMoreメニューからSubmit to your org catalogを選ぶ | 共有ダイアログや公開成功ダイアログからも開始できる場合がある |
| 4 | 提出ダイアログに必要情報を入力する | URLはHTTPSで、既定プレースホルダーを残さない |
| 5 | Continueを選択する | Agent Builderが更新版を保存・公開し、管理者レビューへ提出する |
| 6 | 状態を確認する | Waiting for approval、Approved、Rejected by your adminなどを確認 |
提出後は、同じMoreメニューから「Submit to your org catalog」を開くことでステータスを確認できます。承認済みの場合はAgent Storeへ移動でき、却下された場合は管理者コメントを確認して修正します。PR上のドキュメント案では、保留中の提出は1つのみで、保留中に再提出すると新しい提出が既存の提出を置き換えると説明されています。(GitHub)
管理者側で変わること
管理者側では、Microsoft 365 admin centerのRequestsに届いたエージェント申請を確認し、公開するか却下するかを判断します。Microsoft Learnの管理者向けドキュメントでは、申請されたエージェントについて、説明、所有者、データ、ツールなどを確認し、公開時には対象ユーザーやグループをスコープ指定できると説明されています。(Microsoft Learn)
管理者が見るべきポイントは、単に「便利そうか」ではありません。次の観点でレビューすると、公開後のトラブルを減らせます。
| レビュー観点 | 確認する内容 | 判断例 |
|---|---|---|
| 目的 | 何の業務を支援するエージェントか | 部門限定なのか、全社向けなのか |
| 所有者 | 誰が責任を持って更新・問い合わせ対応するか | 個人ではなくチーム所有に近い運用が望ましい |
| データソース | SharePoint、OneDrive、Graph connectorなどの参照先 | 未承認サイトや個人ファイルを参照していないか |
| ツール・アクション | エージェントが何を実行できるか | 外部サービス連携や書き込み系操作は慎重に確認 |
| 権限 | 利用者に代わってアクセスする範囲 | 必要最小限か、管理者同意が必要か |
| 公開範囲 | 全社、特定グループ、特定ユーザー | 最初はパイロットグループで公開する選択も有効 |
| インストール | ユーザーが任意でインストールするか、事前インストールするか | 全社展開前に問い合わせ体制を整える |
Requestsでは、Pending review、Pending update、Pending activateといった状態で申請を確認できます。公開する場合はPublish to storeからウィザードを進め、対象ユーザー、ポリシーテンプレート、権限を確認します。既存エージェントの更新申請では、承認されるまで以前のバージョンが利用者に残る点も重要です。(Microsoft Learn)
公開範囲とインストール範囲は分けて考える
管理者が特に注意すべきなのは、公開対象とインストール対象は同じではないという点です。
Microsoft 365 admin centerのエージェント詳細では、ユーザーが発見・インストールできる範囲と、事前インストールされる範囲を管理できます。Microsoft Learnでは、Published toはインストール・利用できるユーザーを制御し、Installed toは自動的に事前インストールされるユーザーを制御すると説明されています。(Microsoft Learn)
たとえば、人事FAQエージェントなら全社員が発見・インストールできるようにしつつ、新入社員には事前インストールする、といった使い分けができます。一方で、経営企画向けの分析支援エージェントを全社に公開すると、意図しない利用や問い合わせ増加につながる可能性があります。
公開範囲は、次の順で決めると安全です。
- まず作成部門内で共有して動作確認する
- 次に限定グループでAgent Store公開を試す
- 問い合わせ内容、誤回答、権限不足を確認する
- 問題が少なければ対象範囲を広げる
- 全社公開時は利用ルールと問い合わせ先を明示する
全社公開は「便利だから広げる」ではなく、「サポートできる状態になったから広げる」と考えるべきです。
移行は必要か
今回の更新は、既存エージェントの強制移行を求めるものではありません。すでに共有しているAgent Builder製エージェントは、引き続き共有版として管理できます。
ただし、次のようなエージェントは、組織カタログ提出の候補として見直す価値があります。
- 複数部門から利用希望が出ている
- 社内標準プロセスに関する回答を行う
- 人事、経費、ITヘルプデスクなど全社員が使う可能性がある
- Teamsやメールで毎回リンク共有している
- 作成者個人ではなく、部門として継続運用したい
一方、次のエージェントは、すぐに組織カタログへ出すべきではありません。
- 作成者個人のメールや会議情報に強く依存している
- 参照するSharePointサイトの権限設計が未整理
- 誤回答時の責任範囲や問い合わせ先が決まっていない
- 説明文やスタータープロンプトがテスト用のまま
- 法務・セキュリティ確認が必要な業務に使う
移行というより、共有から正式公開へ進めるための審査ルートが増えると捉えるのが実務的です。
設定確認で見るべきポイント
Microsoft 365管理者は、機能がロールアウトされた後に慌てて承認基準を作るのではなく、事前に運用ルールを決めておくとスムーズです。Agent Builder自体は、Microsoft 365 Copilotで宣言型エージェントを作るための機能で、SharePointやMicrosoft 365 Copilot connectorsなどをナレッジソースとして指定できます。作成場所や既知の制限もMicrosoft Learnで整理されています。(Microsoft Learn)
| 確認対象 | 確認内容 | 推奨アクション |
|---|---|---|
| Agent Builderの利用可否 | 誰がAgent Builderを使えるか | 作成可能ユーザーを部門・職種で整理する |
| 共有ポリシー | 組織全体への共有が許可されているか | 共有制限とカタログ提出の使い分けを明文化する |
| 承認担当 | Requestsを誰が見るか | AI管理者、Teams管理者、セキュリティ担当の役割を決める |
| レビュー基準 | 何を見れば公開可とするか | データ、権限、説明文、法務URL、所有者をチェック項目化する |
| 公開範囲 | 全社公開か、対象グループ公開か | 初回は限定グループで検証する |
| 法務URL | プライバシー声明・利用規約の正式URL | テンプレートとして作成者に配布する |
| サポート導線 | 利用者が問い合わせる場所 | Creator websiteや説明文に窓口を記載する |
| 更新運用 | 更新時の再承認フロー | 重要変更と軽微変更の判断基準を作る |
特にSharePointファイルをナレッジソースに使う場合は、エージェント共有とファイル権限を混同しないでください。Agent Builderの既知の制限では、SharePointファイルとフォルダーの自動共有には条件があり、組織全員への共有では手動の権限更新が必要になる場合があります。(Microsoft Learn)
失敗しやすいポイント
プレースホルダーURLを残したまま提出する
提出時にはCreator website、Privacy statement、Terms of useのURLが重要になります。ドキュメント案では、既定のプレースホルダーURLは本番提出に適さず、該当する場合はAgent Builderが警告を表示すると説明されています。(GitHub)
社内で使うURLを事前に決めておかないと、作成者ごとに別々のページを入れたり、個人のSharePointページを入れたりして、審査が止まりやすくなります。
共有版を更新しただけでAgent Store版も変わると思い込む
Agent Builderで変更を公開すると、共有版にはすぐ反映されます。しかし、Agent Store版は管理者が再承認するまで更新されません。承認済みエージェントを修正した場合は、再提出が必要です。(GitHub)
社内手順書には、「Agent Store公開後の更新は、Update後に再提出する」と明記しておきましょう。
ナレッジソースの権限を確認しない
エージェントがSharePointやOneDriveのファイルを参照していても、利用者がそのファイルにアクセスできなければ、期待どおりの回答が得られない可能性があります。管理者は、Data & Toolsで知識ソースやツールの内容を確認し、作成者は想定利用者の権限でテストする必要があります。Microsoft Learnでも、Data & Toolsタブはエージェントがアクセスできるデータや実行できることを理解するために使えると説明されています。(Microsoft Learn)
全社公開を急ぎすぎる
Agent Storeに載せると見つけやすくなりますが、そのぶん問い合わせも増えます。最初から全社公開するより、対象グループを絞って公開し、利用ログ、問い合わせ、誤回答、権限不足を確認してから広げる方が安全です。
所有者が個人に偏る
作成者が異動・退職すると、エージェントの更新や問い合わせ対応が滞る可能性があります。Agent Builder製エージェントの所有権移転には制約があるため、公開候補のエージェントはチーム運用を前提に、Creator websiteやDeveloper nameを部門単位で設計しておくのが現実的です。PRで更新された共有・管理ドキュメントでも、Agent Builderで作成した宣言型エージェントの所有権移転はサポートされない旨が記載されています。(GitHub)
社内運用に落とし込むならこう進める
今回のMicrosoft Copilot documentation updateを受けて、情報システム部門がまず行うべきことは、機能そのものの説明ではなく、申請から公開までの社内ルール化です。
作成者向けテンプレートを用意する
作成者に自由入力させると、説明文やURLの品質がばらつきます。次のようなテンプレートを配布すると、審査の手戻りを減らせます。
| 項目 | テンプレート例 |
|---|---|
| エージェント名 | 〇〇業務支援 Agent |
| 短い説明 | 〇〇部門向けに、△△に関する社内情報を回答します |
| 対象利用者 | 全社員／営業部／新入社員／管理職 |
| 参照データ | SharePointサイト名、フォルダー名、Graph connector名 |
| 利用上の注意 | 個人情報や機密情報の入力ルール、回答確認の必要性 |
| 問い合わせ先 | Teamsチャネル、SharePointサポートページ |
| 更新責任者 | 部門名、担当チーム名 |
管理者向けレビュー基準を作る
管理者レビューは、属人的に判断すると遅くなります。公開可否の基準を事前に決めておきましょう。
| 判定 | 条件例 |
|---|---|
| 公開可 | 説明文が明確、所有者が明確、ナレッジ権限が確認済み、法務URLが正式 |
| 条件付き公開 | 限定グループでの公開なら可、全社公開は追加検証後 |
| 差し戻し | 説明が曖昧、問い合わせ先不明、参照データ不明、URL未整備 |
| 却下 | 機密情報の扱いが不適切、業務リスクが高い、責任者不明 |
利用者向けに「承認済み」の意味を説明する
Agent Storeの「Built by your org」に出ているからといって、すべての回答が常に正しいわけではありません。承認済みとは、組織が一定の確認を行い、利用可能な範囲を定めたという意味です。
利用者向けには、次のように案内すると誤解を防げます。
- Agent Storeの「Built by your org」から社内承認済みエージェントを探せる
- 業務判断に使う場合は、必要に応じて原典や担当部門に確認する
- 権限がないデータはエージェントも参照できない場合がある
- 不適切な回答や古い情報を見つけたら、Creator websiteや指定窓口に連絡する
今すぐ確認すべきこと
今回の更新は、Agent Builderを「個人やチームの試作ツール」から「組織で管理して展開できる入口」へ近づける変更です。すぐに大規模な移行作業が必要というより、公開候補の選定、承認フロー、メタデータ、権限確認を整えることが重要です。
最後に、今日確認すべき項目を整理します。
- Agent Builderで作成済みのエージェントを棚卸しする
- 組織カタログに出す候補と、共有運用のままにする候補を分ける
- Privacy statementとTerms of useの正式URLを決める
- Creator websiteとして使う社内サポートページを用意する
- Microsoft 365 admin centerのRequestsを誰が確認するか決める
- 公開対象を全社にする前に、パイロットグループで検証する
- 共有版とAgent Store版の更新タイミングの違いを社内手順書に書く
Microsoft 365 Copilotのエージェント活用が進むほど、作るスピードだけでなく、公開後に安全に使い続ける仕組みが重要になります。Agent Builderの「Submit to your org catalog」は、そのための実務的な管理導線として位置づけるとよいでしょう。
コメント