想定読者
- Copilot Studio で社内向けエージェントを作成している人
- エージェントを Teams や社内ユーザー向けに公開しようとしている人
- Power Automate や外部サービス連携を含むエージェントを運用する人
- 情シス・管理者として、Copilot Studio のガバナンスを整えたい人
この記事の目的
Copilot Studio のエージェントを公開する前に表示される Agent status の意味を整理し、
「何を直せば本番公開してよい状態になるのか」を実務目線で解説します。
本文
Copilot Studio でエージェントを作っていると、公開前に Agent status のようなチェック画面が表示されることがあります。
これは一言でいうと、エージェントを本番公開する前の事前レビュー／品質・リスクチェック機能です。
エージェントが「公開してよい状態なのか」「まだリスクが残っているのか」を、認証・権限・モデル・評価といった観点で確認できます。
特に Copilot Studio は、単なるチャットボットではなく、Power Automate のフローや外部サービス、社内データに接続できる“業務実行型エージェント”になりつつあります。
そのため、公開前に見るべきポイントは「回答が自然か」だけではありません。
むしろ重要なのは、次の問いです。
このエージェントは、誰の権限で、何にアクセスし、どこまで実行できるのか？
ここを確認せずに公開すると、便利なはずのエージェントが、意図しない情報取得や処理実行のリスクを持つことになります。
Agent status とは何か
Agent status は、エージェントに対して自動的にチェックを行い、公開前に確認すべき問題を一覧化する機能です。
Microsoft の説明では、Agent status summary は、エージェントが Blocked / At risk / Ready のどの状態にあるか、どの問題が Draft / Published に該当するか、重大度別にどのような問題があるかを確認するためのものです。
なお、プレビュー機能として提供されているため、表示内容や仕様は今後変更される可能性があります。
Copilot Studio では、エージェントのセキュリティ状態について、認証・ポリシー・コンテンツモデレーションなどの観点で保護状態を確認できる仕組みも用意されています。Microsoft は、認証やポリシーに問題がある場合、エージェントの保護状態として Needs review が表示されると説明しています。
つまり Agent status は、単なるエラー表示ではなく、本番利用前の品質ゲートとして見るべき機能です。
Agent status が見ている主な4つの観点
今回の画面では、主に以下の4種類の観点がチェックされています。
| 観点 | 見ていること | 実務上の意味 |
|---|---|---|
| 認証・資格情報 | トリガーやフローが作成者の資格情報で動いていないか | 他ユーザーが作成者の権限で処理できるリスクがないか |
| モデル | 実験的モデルを使っていないか | 本番利用に耐える安定性・継続性があるか |
| 評価 | Agent Evaluation を実行済みか | 手動テストだけでなく、再現性ある品質確認をしているか |
| Editor 権限 | 編集者がフローや接続にアクセスできる状態か | 共同編集者にどこまで触らせてよいか |
ここで大事なのは、Agent status が「壊れているかどうか」だけを見ているわけではないことです。
公開できるとしても、リスクが残っていれば At risk として表示される可能性があります。
つまり、動くかどうかではなく、本番運用してよい設計になっているかを見ていると考えると理解しやすいです。
画像に表示されている4件の意味
今回の画面に表示されている内容は、大きく4つに分けられます。
1. Trigger で共有されたデータ・資格情報の警告
最も重要なのが、Trigger に関する資格情報の警告です。
表示されているメッセージは、ざっくり言うと次の意味です。
トリガーやフローが作成者の資格情報で動く設定になっている場合、他のユーザーがその作成者の権限でデータ取得や処理を実行できる可能性があります。
これはかなり重要です。
Copilot Studio のエージェントは、Power Automate フローやコネクタと連携できます。
その際、ツールの認証方式として大きく次の2つがあります。
| 認証方式 | 意味 | 向いている場面 | 注意点 |
|---|---|---|---|
| エンドユーザー資格情報 | 利用者本人の資格情報で接続する | 利用者ごとにアクセス権限を分けたい場合 | 初回認証や権限設定が必要 |
| 作成者提供の資格情報 | 作成者の資格情報で接続する | 共有リソースに接続したい場合 | 作成者の権限で他ユーザーが処理できる可能性がある |
Microsoft は、Maker-provided credentials を使う場合、エージェント利用時にエンドユーザーではなく作成者の資格情報で接続サービスに認証されると説明しています。
また、ツール追加時の認証方式として、End user credentials は利用者本人の権限でアクセスさせる方式、Maker-provided credentials は作成者の資格情報を使う方式として整理されています。
たとえば、作成者が SharePoint、Outlook、Teams、外部APIなどに強い権限を持っている場合、
エージェント利用者が本来アクセスできない情報を、作成者権限経由で取得できてしまう設計になる可能性があります。
社内向けに言うなら、この警告はこういう意味です。
このエージェントは、誰の権限で外部サービスやフローを実行するのかを確認してください。
特に、メール送信、ファイル取得、リスト更新、承認処理、外部システム登録などを行うエージェントでは、この観点は最優先で確認すべきです。
2. Experimental models の警告
次に、Experimental models の警告です。
これは、エージェントが 実験的モデルを利用しているため、本番利用には推奨されないという意味です。
Microsoft は、Copilot Studio のプレビューモデルについて、既定モデルほど完全なテストプロセスを経ておらず、速度低下やタイムアウトが発生する可能性があり、本番用途には使うべきではないと説明しています。
PoC や検証用途であれば、Experimental model を試す価値はあります。
新しいモデルの性能を早く検証できるからです。
しかし、社内全体公開や顧客向け運用では話が変わります。
| 利用場面 | Experimental model の扱い |
|---|---|
| 個人検証 | 利用してもよい |
| PoC | 目的を明確にすれば利用可 |
| 部門内の限定公開 | 慎重に判断 |
| 全社公開 | 原則避ける |
| 顧客向け本番運用 | 原則避ける |
本番運用では、モデルの精度だけでなく、応答時間、継続提供、仕様変更リスクも重要になります。
そのため、Agent status で Experimental model の警告が出ている場合は、基本的には 本番推奨モデルに戻すのが安全です。
3. Evaluation 未実行の警告
次に、以下のような警告です。
No evaluation has been run on this agent.
これは、Agent Evaluation をまだ実行していないという意味です。
手動でテストチャットをして「なんとなく大丈夫そう」と判断するだけでは、本番品質の確認としては弱いです。
なぜなら、生成AIエージェントは入力の揺れによって回答が変わるためです。
Microsoft は、Agent Evaluation について、テストセットを使ってエージェントの動作を評価し、ビジネス要件や品質要件を満たしているかを検証する機能だと説明しています。
また、評価ではテストセットを選択し、Copilot Studio がその中の各テストケースをエージェントに対して実行する仕組みになっています。
つまり Agent Evaluation は、エージェントの品質確認を「勘」ではなく「テストケース」で行うための機能です。
今回のような AIニュース配信エージェントであれば、たとえば次のような観点で評価するとよさそうです。
| テスト観点 | 確認すること | テスト例 |
|---|---|---|
| 日付条件 | 指定期間内のニュースだけを扱えるか | 今日から1日以内のニュースのみ取得できるか |
| 情報源 | 信頼できるソースを使っているか | 公式情報・大手メディア・一次情報を優先できるか |
| 出力形式 | メール本文として読みやすいか | 件名、要約、リンク、影響が整理されているか |
| 重複排除 | 同じニュースを複数回出していないか | 同一ニュースを別媒体から重複掲載していないか |
| 禁止事項 | 未確認情報を断定していないか | 噂や観測記事を事実として書いていないか |
| 業務適合性 | 読者にとって意味のある示唆があるか | 「何が変わるか」「何をすべきか」が書かれているか |
特にニュース配信エージェントの場合、単にニュースを拾うだけでは価値が弱いです。
重要なのは、
「何が起きたか」
「誰に影響するか」
「業務上、何を見ておくべきか」
まで整理できることです。
Agent Evaluation は、その品質を継続的に確認するための入り口になります。
4. Editor 権限に関する Info
最後に、Editor 権限に関する Info です。
これは警告というより、注意喚起に近いものです。
意味としては、Editor 権限を持つユーザーは、このエージェントで使われているフローやトリガーの埋め込み接続にアクセスできる可能性があるということです。
Copilot Studio では、エージェントを他のユーザーと共有し、編集権限を付与できます。Microsoft も、エージェント共有やセキュリティロールの割り当てについて説明しています。
ここで注意したいのは、Editor 権限は単に「プロンプトを直せる権限」ではないということです。
実務上は、次のように考えるべきです。
| 権限 | できることのイメージ | 注意点 |
|---|---|---|
| 利用者 | エージェントを使う | 原則、編集はできない |
| 共同編集者 / Editor | エージェントの構成を編集できる | フローや接続周りにも影響する可能性がある |
| 管理者 | 環境・ポリシー・認証設定を管理する | 組織全体のガバナンスを設計する |
つまり、共同編集者を増やすときは、
「この人にエージェントの会話設計を触らせてよいか」だけでは不十分です。
あわせて、次の観点も確認する必要があります。
- フローを編集してよいか
- 接続情報を見せてよいか
- トリガー設定を変更してよいか
- 外部サービス連携を変更してよいか
- 本番公開前の品質確認を任せてよいか
特に本番エージェントでは、Editor 権限は最小限にするのが基本です。
実務ではどう見ればよいか
Agent status が表示されたら、まずは次の順番で確認するとよいです。
実務的には、次の5点を見ればOKです。
| 優先度 | 確認項目 | 対応 |
|---|---|---|
| 高 | Experimental model を使っていないか | 本番推奨モデルに戻す |
| 高 | フロー／トリガーが誰の資格情報で動くか | 作成者権限か、利用者権限かを確認 |
| 高 | 作成者提供の資格情報が必要か | 原則はエンドユーザー資格情報を優先 |
| 中 | Agent Evaluation を実行済みか | テストセットを作成して評価する |
| 中 | Editor 権限が広すぎないか | 共同編集者を最小限にする |
今回の AIニュース配信エージェントで特に見るべきこと
今回のエージェントが「AIニュース配信エージェント」なのであれば、特に見るべきは 認証・資格情報です。
なぜなら、ニュース配信エージェントは、単に情報を取得するだけでなく、メール配信やTeams投稿、SharePoint保存、Power Automate フロー実行などと組み合わされやすいからです。
たとえば、次のような構成になっている場合は注意が必要です。
このとき確認すべきポイントは、以下です。
| 処理 | 確認ポイント |
|---|---|
| ニュース取得 | どのAPI・サイトにアクセスしているか |
| 要約生成 | 未確認情報を断定しない指示になっているか |
| メール送信 | 誰のメールアカウントで送信されるか |
| 配信先 | 意図しない宛先に送られないか |
| フロー実行 | 作成者権限で動いていないか |
| ログ | 送信履歴・取得履歴を確認できるか |
特にメール送信が絡む場合は、
「他の人が使ったときに、作成者のメールアカウントから送信されないか」
を必ず確認した方がよいです。
AIニュース配信は便利ですが、誤送信や権限の取り違えが起きると、社内展開の信頼を一気に失います。
公開前チェックリスト
最後に、Copilot Studio エージェントを公開する前のチェックリストを整理します。
認証・権限
- フローやトリガーが誰の資格情報で動くか確認した
- 作成者提供の資格情報を使う必要性を説明できる
- 可能な場合はエンドユーザー資格情報にしている
- 作成者アカウントに過剰な権限が付与されていない
- 利用者が本来見られない情報にアクセスできない
モデル
- Experimental model を本番利用していない
- 本番推奨モデルに設定している
- 応答品質だけでなく、応答時間も確認した
評価
- Agent Evaluation を1回以上実行した
- テストケースを複数用意した
- 想定外の質問に対する回答も確認した
- 未確認情報を断定しないことを確認した
- 出力形式が業務利用に耐えることを確認した
共同編集・運用
- Editor 権限を持つ人を最小限にしている
- フローや接続を触れる人を把握している
- 本番公開後の変更ルールを決めている
- 変更時に再評価する運用を決めている
まとめ
Copilot Studio の Agent status は、単なるエラー一覧ではありません。
本番公開前に、エージェントが安全に使える状態かを確認するための 事前レビュー機能です。
特に見るべきポイントは、次の4つです。
| 観点 | 見るべきこと |
|---|---|
| 認証・資格情報 | 誰の権限でフローや外部サービスを実行するか |
| モデル | 本番利用に適したモデルを使っているか |
| 評価 | テストセットによる品質確認を実施したか |
| Editor 権限 | 共同編集者が接続やフローに触れる範囲は適切か |
Copilot Studio エージェントは、今後ますます「会話するだけのボット」から「業務を実行するエージェント」へ進化していきます。
だからこそ、本番公開前には、次の問いを必ず確認すべきです。
このエージェントは、誰の権限で、何を実行し、どこまで影響を与えるのか？
ここを押さえておけば、Copilot Studio は単なる便利ツールではなく、安心して業務に組み込めるエージェント基盤になります。
次にやること
まずは、公開前のエージェントで以下を確認してください。
- Experimental model を使っていないか確認する
- フロー／トリガーが誰の資格情報で動くか確認する
- 可能ならエンドユーザー資格情報に寄せる
- Agent Evaluation を実行する
- Editor 権限を持つ人を最小限にする
AIニュース配信エージェントの場合は、特に メール送信・ニュース取得フローが作成者権限で動いていないかを最優先で確認するのがおすすめです。