Copilotで作ったエージェント、社内公開して大丈夫？公開前のチェックリスト

自分の画面では、規程の質問に正しく答えた。チームに共有するだけなら、もう使えるように思えるかもしれません。でも、同僚の権限では資料が見えない。説明していない使い方もされる。共有した後に初めて分かる問題があります。

Copilotエージェントの公開前には、共有先の利用者として、回答品質・データ権限・運用担当を確認します。 画面上で共有できることと、業務で使ってよいことは別の判定です。

本記事は、Microsoft 365 CopilotのAgent Builderで作ったエージェントを、部門や組織へ広げたい担当者向けです。Copilot Studioを含む場合は製品ごとの設定を確認し、以下の業務チェックを組み合わせます。

この記事の要点

「共有」「公開」「組織の承認」は同じ意味ではない

Agent Builderではエージェントの共有・管理ができます。一方、組織カタログの「Built by your org」へ掲載を申請する経路では、管理者の審査があります。社内共有のすべてに、同じ管理者承認が必ず入るわけではありません。 Microsoft：共有と管理、組織カタログへの申請

最初に確認するのは、自社で使う作成機能、配布経路、管理ポリシーです。Agent BuilderとCopilot Studioの画面や権限を、一つの共通手順として扱わないようにします。

また、製品の審査経路があることだけで、自社の経理や営業の正解が検証されたことにはなりません。業務の受け入れ判断を誰が行うかは、別に決めます。

以下はAIworkerが提案する公開前チェックです。Microsoftの認定制度ではありません。公式仕様は2026年9月28日に確認しています。

公開前チェック①：用途を1文で説明できるか

「総務の質問に答える」だけでは対象が広すぎます。架空例なら「現行の備品申請手順を案内する。購入の承認や申請の代理送信はしない」と書きます。

説明欄には利用者、参照する資料、できないこと、問い合わせ先を置きます。初めて開く人が、任せてよい仕事を判断できるかを、作成者以外に読んでもらいます。

利用者が質問を工夫しなければ正解できない場合は、その条件も明記します。作成者だけが知っている入力のコツは、公開条件として残す必要があります。

公開前チェック②：利用者の権限で試したか

作成者が管理者権限を持っていると、一般利用者と見える範囲が違う場合があります。想定利用者の権限でテストし、エージェントを使う権限と、参照データへアクセスする権限をそれぞれ確認します。

ここで試すのは、次のような条件です。

• 部門の利用者が、許可された資料の回答を得られるか。

• 対象外の部門や利用者に、見せてはいけない情報が表示されないか。

• 資料へアクセスできないときに、もっともらしい回答で埋めないか。

• 接続先がある場合、どの認証と権限で処理が実行されるか。

これは業務テストの観点です。プロンプトに「秘密を漏らさない」と書くだけで、アクセス制御の代わりにはできません。 実際の構成に応じて管理者が確認します。

公開前チェック③：答えられない質問でも動きを確認したか

説明用の備品申請エージェントなら、正しい質問だけでなく「規程にない購入」「金額や部署が不明」「古い案内との矛盾」を用意します。

通常の質問

• 入力例：備品の申請先は？

• 期待する動きの例：現行手順の根拠を示す

情報不足

• 入力例：これを買ってよい？

• 期待する動きの例：判断に必要な条件を確認する

規程に記載なし

• 入力例：未掲載の品目を買いたい

• 期待する動きの例：担当窓口へ案内する

対象外の実行

• 入力例：上司の代わりに承認して

• 期待する動きの例：承認を代行せず範囲外と伝える

入力例と期待する動きは、実際の社内規程に置き換えます。テストの正解は、業務担当者が先に定めます。 AIの回答を見てから、都合よく合格条件を変えないことが大切です。

Microsoftもテスト戦略に、通常の動作以外のシナリオや継続的な確認を含めています。Microsoft：テスト戦略

公開前チェック④：更新の反映先と再評価を決めたか

共有版と、組織カタログで承認された版は、更新の扱いが異なります。組織カタログ版の変更を反映するには、再申請が必要です。配布経路と版を対応づけて管理してください。Microsoft：組織カタログ版の更新

「テストした版」と「利用者が使う版」が違えば、合格記録の意味が薄れます。確認日、配布経路、指示と知識源の版、結果、確認者をセットで残します。

知識源が更新されたときも、影響する質問を再テストします。変更対象だけでなく、以前できていた仕事が崩れていないかも確認します。

公開前チェック⑤：問題を報告する先があるか

利用者は、誤回答を見つけても、誰へ知らせればよいか分からないと使うのをやめてしまいます。エージェントの案内に、問い合わせ先と報告してほしい情報を置きます。

報告には、発生日時、質問の種類、困った結果、参照した資料の版などを使います。会話全文の収集が必要な場合は、機密・個人情報の扱いと閲覧者を先に決めます。

担当者が不在のときの代行と、一時停止の判断者も必要です。公開した本人の善意だけで問い合わせを処理する形にしないようにします。

公開の確認項目を自社環境に合わせたい場合は、利用製品と配布方法を添えてご相談ください。

▶️ Copilotエージェントの業務利用について問い合わせる

ページ下部の「お問い合わせ」にある「ご相談・ご質問」欄に「Copilot公開前チェックの記事を見た」とご記入ください。

共有ボタンを押す前に残す判定メモ

次はAIworkerの提案様式です。すべてに丸を付けることより、未確認のまま利用範囲を広げないことを重視します。

エージェント名／識別子：
作成機能と配布経路：
利用者・対象業務・対象外の依頼：
公開する版／確認した日：
知識源と権限の確認者：
通常・情報不足・対象外・権限差のテスト結果：
業務上の受け入れ判断者：
保守担当／不在時の連絡先：
停止条件と代替窓口：
未確認事項／対応担当／期限：
結論：限定試行・部門利用・差し戻し

重大な情報漏えい、許可していない実行、重要な誤案内が再現する場合は、公開範囲を広げる前に原因を解消します。限定試行も、重大な問題を放置してよいという意味ではありません。

権限設計そのものを整理したい場合は、生成AI・AIエージェントの権限設計を参照してください。

よくある質問（FAQ）

Q. 管理者に承認されれば、業務テストは省けますか？

省けません。組織の公開手続きと、対象業務で回答や処理が正しいかの確認は別に行います。

Q. Agent BuilderとCopilot Studioは同じ手順で公開できますか？

同じとは限りません。作成機能、チャネル、管理ポリシーごとの公式手順を確認し、本記事の業務チェックを組み合わせます。

Q. テスト用チャットで正解したら十分ですか？

十分とは言えません。想定する利用者と配布先で、権限差、対象外の依頼、参照不能も確認します。

Q. すべての社員に共有して反応を見てもよいですか？

最初に利用範囲と不具合時の影響を判断します。改善対応を担える担当者と利用者を決め、限定した範囲から検証する方法があります。

Q. 公開後に指示文だけ直した場合も再確認が必要ですか？

回答や動作に影響する変更なら再確認します。配布経路による更新手続きと、以前のテスト結果への影響を確認してください。

作成研修から、業務で使える状態まで整えたい方へ

AIworkerでは、法人向けAI研修、業務に合わせた開発、運用定着を支援しています。研修で作成したエージェントを実務へ移す際の評価と運用もご相談いただけます。

相談時には、Agent BuilderかCopilot Studioか、誰へ共有したいか、どの確認で止まっているかをお伝えください。 製品固有の対応範囲は現状を伺って整理します。

▶️ Copilotの研修・業務利用を相談する

運用全体も整理したい方へ

社内AIエージェントの運用ルールと公開判定の記入例で、品質・責任者・保守体制をまとめて確認できます。

著者情報

株式会社AIworker

企業の生成AI活用を、研修・業務設計・AI開発・定着支援まで一貫して支援しています。

https://ai-worker.net/

この記事が参考になりましたら、今後の記事づくりの励みになるので、スキをお願いします。

参考資料

公式情報の確認日：2026年9月28日。提供状況や画面は変更される場合があります。

• Microsoft：Agent Builderの共有と管理

• Microsoft：組織カタログへの申請

• Microsoft：テスト戦略

#AIエージェント #AI活用 #DX推進 #AIガバナンス #Copilot