Microsoft 365 Copilot 向けに Copilot Studio でエージェントを作成・運用している管理者がまず押さえるべき結論は、new agent experience は既存の classic experience を単純に置き換える画面変更ではなく、作成モデルとオーケストレーションの考え方が変わる新しいエージェント作成体験だという点です。2026年7月1日更新の Microsoft Learn では、Classic vs. new agent experience の比較として、作成方法、オーケストレーション、機能差、移行可否が整理されています。新規エージェントで Microsoft 365 データを活用した推論品質を重視するなら new experience の検証価値は高い一方、既存エージェントの精密な会話フロー制御や未対応機能を使っている場合は classic experience の継続利用が現実的です。(Microsoft Learn)
Microsoft 365 Copilot と Copilot Studio の「Classic vs. new agent experience」で何が変わるのか
今回の更新は、Microsoft 365 Copilot そのもののチャット画面だけを見る話ではありません。主な対象は、Microsoft Copilot Studio で Microsoft 365 Copilot を拡張するエージェントを作成・管理する担当者です。Copilot Studio では、Microsoft 365 Copilot に特化したエージェントや、Microsoft 365 Copilot / Teams などに公開できるカスタムエージェントを作成できます。Microsoft 365 Copilot を業務別の相談窓口、申請支援、社内ナレッジ検索、承認前チェックなどに拡張している企業では、今回の差分を早めに把握しておく必要があります。(Microsoft Learn)
new agent experience の中心は、従来の「トピック、トリガー、分岐、ノード」を組み立てる発想から、エージェントの目的・振る舞い・制約を自然言語の instructions で定義し、知識、ツール、スキル、モデル、Microsoft IQ、メモリなどを1つの Build 画面で構成する発想への移行です。Microsoft は new experience を production-ready preview と位置付けていますが、プレビューである以上、機能の変更や一部制限があり得る点は運用判断に含めるべきです。(Microsoft Learn)
classic experience と new experience の違い
classic experience と new experience の違いは、単に画面デザインが新しくなったことではありません。実務上は、エージェントの品質管理、設計方法、テスト方法、既存資産の扱いに影響します。
| 比較項目 | classic experience | new agent experience |
|---|---|---|
| 作成の基本単位 | Topics、Knowledge、Actions、Settings などを個別に設計 | Build タブで instructions、knowledge、tools、skills、model などを統合的に設定 |
| 会話設計 | 明示的なトピック、トリガー、条件分岐、ノードで制御 | 自然言語の instructions と推論で動作を制御 |
| オーケストレーション | classic / generative などを選択できる構成 | enhanced orchestration runtime をすべてのエージェントで使用 |
| 向いている用途 | 会話の各ステップを厳密に制御したい業務 | Microsoft 365 データを含む組織データに対して、より自然な推論や回答品質を重視する業務 |
| テスト・評価 | 機能や画面が分散しやすい | Preview、Evaluate、Monitor が作成画面の主要タブとして統合 |
| 移行可否 | new experience へ直接変換できない | classic experience へ戻して変換できない |
Microsoft の比較では、classic experience は左ナビゲーションに Topics、Knowledge、Actions、Settings などが分かれて表示される一方、new experience では上部に Build、Preview、Evaluate、Monitor タブが並びます。どちらの体験を使っているか迷った場合は、まずこの画面構成で判別できます。(Microsoft Learn)
new agent experience で評価すべき主な更新ポイント
instructions 中心の設計になる
new agent experience では、エージェントの名前、役割、トーン、目的、境界条件、回答スタイルなどを instructions として定義します。従来のように「この発話ならこのトピック」「この条件ならこのノード」という手順を細かく作るよりも、エージェントに期待する役割と判断基準を明確に書くことが重要になります。(Microsoft Learn)
たとえば、総務問い合わせエージェントを作る場合、classic experience では「休暇申請」「備品購入」「出張精算」などのトピックを分けて会話フローを設計しがちです。new experience では、「社内規程に基づいて回答する」「不明点は推測せず担当部署に確認を促す」「個人情報や給与情報は回答範囲を限定する」といった運用ルールを instructions に明記し、必要な knowledge や tools を接続する設計になります。
enhanced orchestration runtime が標準になる
new experience では、すべてのエージェントが enhanced orchestration runtime を使います。Microsoft は、このランタイムにより、特に Microsoft 365 データを扱う場面で推論と回答品質の向上が期待できると説明しています。一方で、classic experience のようにオーケストレーション方式を切り替える選択肢はありません。(Microsoft Learn)
これは管理者にとって重要です。会話フローを厳密に固定したい業務では classic experience のほうが検証しやすい場合があります。反対に、SharePoint、OneDrive、Teams、メール、予定表など、利用者ごとに参照可能な情報が変わる業務では、new experience の推論型の設計を試す価値があります。
Microsoft IQ との組み合わせが重要になる
new experience では、Microsoft IQ を使って Microsoft 365 アプリの組織データやコンテキストをエージェントに接続できます。Microsoft IQ は、メール、予定表、ファイル、Teams メッセージ、人物情報などの組織データにアクセスする文脈レイヤーとして説明されています。ただし、アクセスはユーザーの既存権限を尊重し、ユーザーが権限を持たないデータをエージェントが勝手に参照できるわけではありません。(Microsoft Learn)
この点は、Microsoft 365 Copilot のエージェントを全社展開する際の安心材料である一方、設計時の落とし穴にもなります。作成者のテストでは回答できたのに、一般ユーザーでは回答できない場合、エージェントの不具合ではなく、SharePoint や Microsoft 365 側のアクセス権が原因のことがあります。公開前に、管理者アカウントだけでなく、一般社員、部門ユーザー、権限のないユーザーなど複数のロールでテストしてください。
Skills、Tools、Knowledge、Memory の役割を分けて考える
new experience の Build タブでは、Model、Microsoft IQ、Skills、Tools、Knowledge、Connected agents、Memory などのコンポーネントを構成します。特に Skills は、外部サービスに接続する Tools とは異なり、特定タスクの処理方法を再利用可能な指示としてまとめる仕組みです。(Microsoft Learn)
使い分けの目安は次の通りです。
| 構成要素 | 使う場面 | 設計時の注意点 |
|---|---|---|
| Knowledge | SharePoint、ファイル、Web サイトなどの情報を根拠に回答させたい | 情報の鮮度、アクセス権、引用元の確認が必要 |
| Tools | API、コネクタ、ワークフローなどを呼び出して処理させたい | 認証、実行権限、誤実行時の影響を確認 |
| Skills | 定型的な判断手順や作業ルールを複数エージェントで再利用したい | 説明が曖昧だと適切なタイミングで呼び出されにくい |
| Memory | ユーザーごとの好みや過去の文脈を次回以降に活かしたい | プライバシー、保持期間、利用目的の説明が必要 |
Memory はエージェント単位でオン・オフでき、ユーザーごと・エージェントごとに保存されます。Microsoft Learn では、ユーザーがそのエージェントを28日間利用しない場合、そのユーザーのメモリは削除されること、Memory をオフにしても保存済みメモリ自体は削除されず、利用されなくなるだけであることが説明されています。(Microsoft Learn)
影響範囲：誰が対応すべきか
今回の Classic vs. new agent experience の更新で、特に影響を受けるのは次の担当者です。
| 対象者 | 影響 |
|---|---|
| Microsoft 365 管理者 | Microsoft 365 Copilot に表示・配布するエージェントの管理、権限、公開範囲の確認が必要 |
| Power Platform / Copilot Studio 管理者 | 環境、DLP、コネクタ、チャネル公開、maker 権限の見直しが必要 |
| エージェント作成者 | トピック中心の設計から instructions 中心の設計へ発想を切り替える必要 |
| セキュリティ担当者 | Microsoft IQ、Tools、Memory、外部コネクタ利用時のデータ保護ルール確認が必要 |
| 業務部門の責任者 | 既存の classic エージェントを維持するか、新規作成で new experience を使うかの判断が必要 |
Copilot Studio は Power Platform 環境内でエージェントを作成・管理するサービスであり、環境はデータ境界、セキュリティロール、データポリシー、開発・テスト・本番の分離に関わります。グローバル企業では、地域、部門、データ分類、外部連携の有無に応じて、環境単位でガバナンスを分ける設計が重要です。(Microsoft Learn)
設定変更で確認すべきポイント
まず「新規作成」と「既存運用」を分ける
管理者が最初にやるべきことは、既存の classic エージェントを一括で new experience に寄せようとしないことです。Microsoft の公式比較では、classic で作成したエージェントを new experience に転送できず、new experience で作成したエージェントも classic experience へ転送できないと明記されています。既存 classic エージェントは従来通り動作し、必要に応じて体験を切り替えながら使えるとされています。(Microsoft Learn)
そのため、設定変更の基本方針は次のようになります。
| 判断対象 | 推奨アクション |
|---|---|
| 既存 classic エージェント | すぐに作り替えず、利用状況、依存機能、会話フロー、公開チャネルを棚卸しする |
| 新規エージェント | Microsoft 365 データ活用や推論品質を重視するなら new experience を優先して検証する |
| 厳密な分岐が必要な業務 | classic experience の継続を含めて判断する |
| 全社展開予定の重要エージェント | new experience で作る場合も、開発・検証・本番の環境分離と評価テストを必須にする |
DLP とコネクタ制御を確認する
new experience では Tools、Skills、Knowledge、Microsoft IQ などの構成要素が扱いやすくなる一方、外部サービスや組織データへ接続する場面も増えます。Copilot Studio のデータポリシーでは、認証、知識ソース、アクション、コネクタ、スキル、HTTP リクエスト、公開チャネルなどを管理対象にできます。(Microsoft Learn)
特に確認したいのは、以下の3点です。
- 未認証チャットを許可していないか
- 外部 Web、HTTP、カスタムコネクタ、非 Microsoft サービスへの接続が業務ルールに合っているか
- Microsoft 365 Copilot や Teams へ公開するチャネルが、組織の配布ポリシーに合っているか
DLP は「公開後に問題が起きたら止める」ものではなく、作成者が誤って危険な構成を選ばないようにする予防策です。特にグローバルテナントでは、地域ごとに規制要件やデータ所在地の考え方が異なるため、開発環境、部門利用環境、本番環境でポリシーを分けておくと運用しやすくなります。
Evaluate と Monitor を運用プロセスに組み込む
new experience では、Preview、Evaluate、Monitor が作成体験に統合されています。Preview では公開前にチャット形式で応答や動作を確認でき、Evaluate ではテストケースに基づく反復的な品質評価ができます。Monitor では公開後の活動やパフォーマンス確認に使う画面が用意されています。(Microsoft Learn)
実務では、次のような基準を設けると失敗を減らせます。
| 確認タイミング | 確認内容 | 合格基準の例 |
|---|---|---|
| 作成直後 | instructions が曖昧でないか | 禁止事項、回答範囲、エスカレーション条件が書かれている |
| Preview | 主要な質問に正しく答えるか | 想定質問10〜20件で誤回答や過剰回答がない |
| Evaluate | 回答品質を継続的に測れるか | テストセットを作り、変更前後で品質を比較できる |
| 公開前 | 権限違い・外部送信・誤実行がないか | 一般ユーザー権限で期待通りに制限される |
| 公開後 | 利用状況やエラーを追えるか | Monitor や管理センターで問題検知できる |
移行期限はあるのか
2026年7月1日更新の Classic vs. new agent experience の公式ページでは、classic experience から new experience への強制移行期限や廃止日が示されているわけではありません。むしろ、既存の classic experience のエージェントはこれまで通り動作し、両方の体験を切り替えられると説明されています。(Microsoft Learn)
ただし、移行期限がないことと、移行計画が不要であることは別です。Microsoft の Copilot Studio 概要では、2026年6月末以降、Copilot Studio for Teams アプリで classic chatbot を作成することはできなくなり、Copilot Studio Web アプリへリダイレクトされると説明されています。これは classic agent experience 全体の廃止期限と同義ではありませんが、Teams アプリ中心で作成していた組織は作成導線の変更を確認しておくべきです。(Microsoft Learn)
管理者は「いつまでに全部移行するか」ではなく、まず「どのエージェントを classic のまま維持し、どの新規ユースケースを new experience で作るか」を決めるのが現実的です。特に変換パスがないため、new experience を使う場合は移行ではなく再設計・再作成になります。
管理者向けの実務チェックリスト
エージェント棚卸し
まず、現在のエージェントを一覧化します。確認項目は、作成体験、公開チャネル、所有者、利用部門、参照データ、使用コネクタ、認証方式、会話ログや分析の参照権限です。Microsoft 365 Copilot から利用されるエージェントは、公開後にユーザーの業務導線へ入り込みやすいため、所有者不明のまま放置しないことが重要です。
new experience のパイロット対象を選ぶ
最初の検証対象は、失敗しても業務影響が限定的で、かつ Microsoft 365 データ活用の効果が見えやすい用途が向いています。たとえば、社内FAQ、議事録やプロジェクト文書の検索補助、申請前の記入支援、社内手順の案内などです。顧客向け回答、法務判断、人事評価、医療・金融・安全に関わる用途は、最初のパイロットには向きません。
公開権限と配布方法を確認する
Microsoft 365 Copilot 向けエージェントは、公開しただけで全社ユーザーへ自動展開されるとは限りません。組織カタログへの登録、Teams / Microsoft 365 への配布、サイドローディングや公開ブロックの設定など、テナント管理者側のポリシーが関係します。Microsoft 365 Copilot で使うエージェントは、ユーザーが @メンションやサイドバーから利用できるため、配布範囲を小規模グループから段階的に広げる運用が安全です。(Microsoft Learn)
プレビュー機能の扱いを社内ルールに反映する
new agent experience は production-ready preview とされていますが、プレビュー機能は補足使用条件の対象です。Microsoft の補足条件では、プレビュー機能が変更または中止される可能性、GA されない可能性、SLA や限定保証から除外される場合があることが説明されています。重要業務に使う場合は、社内のリスク評価、代替手段、障害時対応、データ保持方針を確認してから公開してください。(Microsoft)
よくある失敗と回避策
既存 classic エージェントをそのまま移せると思い込む
最も多い誤解は、classic experience のエージェントを new experience に変換できると思い込むことです。公式情報では、両者の間に転送パスはありません。移行したい場合は、既存トピック、分岐条件、利用データ、ツール、公開設定を棚卸しし、new experience の instructions、knowledge、tools、skills として再設計する必要があります。(Microsoft Learn)
instructions を短く書きすぎる
new experience では自然言語で作れるため、作成が簡単に見えます。しかし、instructions が曖昧だと、回答範囲、判断基準、ツール呼び出し条件、禁止事項が不安定になります。たとえば「社内規程に答えるエージェント」だけでは不十分です。「根拠が見つからない場合は推測しない」「就業規則とFAQの内容が矛盾する場合は人事部へ確認を促す」「個人の評価や給与情報は回答しない」といった制約まで書くべきです。
作成者権限だけでテストする
Microsoft 365 データを扱うエージェントでは、作成者が見えるデータと利用者が見えるデータが異なります。作成者テストでは正しく見えても、一般ユーザーでは情報不足になることがあります。逆に、権限設計が甘いと、本来見せるべきでない情報の存在を示唆する回答になる可能性もあります。部署別、役職別、外部ユーザー相当など、複数の権限パターンでテストしてください。
Monitor を公開後の「おまけ」にする
new experience では Monitor が作成体験に組み込まれています。公開後に問題が起きてから見るのではなく、公開前に「誰が何を確認するか」「どのエラーを重大扱いにするか」「どの頻度でレビューするか」を決めておくべきです。特に Tools を使って外部システムへ処理を行うエージェントでは、誤実行や認証エラーの検知ルールを事前に決めておく必要があります。
どちらを選ぶべきか
new experience を選ぶべきなのは、新規にエージェントを作成し、Microsoft 365 データを含む組織データに対する推論、自然言語ベースの作成、組み込みの評価・監視を重視するケースです。たとえば、社内文書から回答し、必要に応じてツールを呼び出し、ユーザーごとの文脈に合わせて案内するようなエージェントは、new experience の検証対象になります。(Microsoft Learn)
classic experience を選ぶべきなのは、既存エージェントを維持・拡張したい場合、会話の流れを明示的に制御したい場合、または new experience に未対応の機能へ依存している場合です。特に、問い合わせフォームのように質問順序、分岐、確認、完了条件を厳密に固定したい業務では、classic experience のほうが管理しやすいことがあります。(Microsoft Learn)
次に取るべき行動は明確です。まず既存の Copilot Studio エージェントを classic / new、公開チャネル、利用データ、コネクタ、所有者で棚卸しします。そのうえで、新規ユースケースは new agent experience で小さく検証し、既存 classic エージェントは強制的に作り替えず、必要なものだけ再設計します。Microsoft 365 Copilot への展開では、DLP、認証、公開範囲、Evaluate、Monitor をセットで確認することが、今回の更新を安全に活かすための実務上の最短ルートです。
コメント