Microsoft Copilot Studio guidance documentationは、Microsoft Copilot StudioでAIエージェントを作る人向けの「作り方」だけでなく、計画、実装、ガバナンス、ALM、監視、改善までを含む公式ガイダンス集です。結論として、2026年5月時点で管理者・開発者がまず確認すべきなのは、新機能を試すことよりも、生成AIを使うエージェントを安全に本番展開できる設計になっているかです。特に、RAG、生成オーケストレーション、エージェントツール、Teams展開、環境分離、データポリシー、容量管理、評価指標の見直しが重要になります。(Microsoft Learn)
Microsoft Copilot Studio guidance documentationとは
Microsoft Copilot Studio guidance documentationは、Microsoft Copilot Studioのエンタープライズ導入に向けたベストプラクティス、実装、アーキテクチャの情報をまとめたMicrosoft Learn上の公式ドキュメントです。単なる操作マニュアルではなく、企業利用で問題になりやすい「誰が作るか」「どのデータに接続するか」「どの環境でテストするか」「公開後にどう監視するか」まで扱っています。(Microsoft Learn)
公式ガイダンスは大きく、Plan、Implement、Adopt、Manage、Improve、Extendの流れで整理されています。つまり、Copilot Studioを「チャットボット作成ツール」として見るのではなく、AIエージェントを継続的に設計・運用するプラットフォームとして扱う前提です。(Microsoft Learn)
| 領域 | 主な内容 | 実務で確認すべきこと |
|---|---|---|
| Plan | 目的、成功基準、リスク、チーム、アーキテクチャ | 何を自動化し、何を人に残すかを決める |
| Implement | RAG、生成オーケストレーション、ツール、チャネル公開 | 知識ソース、API、フロー、トピックをどう組み合わせるか |
| Adopt | 成熟度、AI戦略、組織文化 | 部門展開や利用定着の進め方 |
| Manage | ガバナンス、セキュリティ、ALM、監視 | 環境、権限、データポリシー、リリース手順 |
| Improve | KPI、分析、改善、プロンプト最適化 | 公開後に品質をどう測るか |
| Extend | Copilot Studio Kit、サンプル、SDK | 複数エージェントや開発者向け拡張 |
今回の要点は「AI機能追加」ではなく「本番運用の前提条件が明確になった」こと
Microsoft Copilot Studioは、従来のようにトピックを一つずつ作り込むチャットボットだけでなく、生成AI、ナレッジ検索、ツール実行、ワークフロー、外部システム連携を組み合わせるエージェント基盤として整理されています。公式ドキュメントでも、Copilot Studioはグラフィカルなローコードツールであり、エージェントとエージェントフローを構築できるものとして説明されています。(Microsoft Learn)
重要なのは、AIが回答するだけでなく、ユーザーの意図を解釈し、必要なナレッジやツールを選び、複数ステップの処理を実行する設計に近づいている点です。生成オーケストレーションは、LLMによる計画レイヤーを使って、ユーザー意図の解釈、複雑な要求の分解、ツールやナレッジの選択、複数ステップの実行を行う機能として説明されています。(Microsoft Learn)
そのため、管理者や開発者の確認ポイントも変わります。以前は「FAQに答えられるか」「Teamsに公開できるか」が中心でしたが、今後は「どのデータを根拠に回答するか」「どのアクションをAIに任せるか」「どこで承認を挟むか」「ログと評価で改善できるか」まで含めて設計する必要があります。
変更点として押さえたい主要ポイント
生成AIは、回答生成だけでなくオーケストレーションの中心になる
Copilot StudioのAI機能は、生成オーケストレーション、生成回答、生成ビルダー、Computer use、AIプロンプトなどに分かれています。公式ガイダンスでは、Copilot Studioは大量の固定トピックを手作業で作る前提ではなく、業務上重要な体験を作り込みながら、AIによるナレッジ、オーケストレーション、自動化と組み合わせる方向性が示されています。(Microsoft Learn)
開発者にとって大きいのは、トピック名、ツール名、説明文、入出力パラメーターの品質が、AIの判断精度に直結することです。生成オーケストレーションでは、ツールやトピックの名前・説明がユーザーの要求に合っているかによって、プランナーがどれを呼び出すかを判断します。曖昧な名前や重複した説明があると、誤ったツール選択や不要な実行につながります。(Microsoft Learn)
RAGの設計では「つながるか」より「信頼できる根拠になるか」を見る
RAGは、言語モデルの推論能力と、企業内の信頼できるナレッジを組み合わせ、モデルの記憶だけに頼らず、組織固有のコンテンツに基づいた回答を生成する設計パターンです。Copilot StudioのRAGでは、クエリ書き換え、コンテンツ取得、要約・回答生成、安全性とガバナンスの検証という流れで処理されます。(Microsoft Learn)
実務では、SharePointやDataverseにつなぐこと自体よりも、検索対象に古い文書や未承認文書が混ざっていないかを確認することが重要です。公式ガイダンスでは、SharePointやOneDrive、Dataverse、Graph connectors、Azure AI Search、カスタムデータなどの知識ソースごとに、認証、制約、セキュリティトリミングの考慮点が整理されています。(Microsoft Learn)
特に、Azure AI Searchのようにユーザーごとのセキュリティトリミングが前提にならない構成では、検索結果に含めてよいデータ範囲を別途設計する必要があります。反対に、SharePointやGraph連携ではユーザーのアクセス権に応じた結果取得が前提になるため、Microsoft 365側の権限設計が回答品質と情報漏えいリスクの両方に影響します。(Microsoft Learn)
Workflowsは便利だが、プレビュー扱いと容量消費に注意する
2026年5月6日更新の公式情報では、Copilot StudioのWorkflowsはpublic previewとして説明されています。新しいビジュアルキャンバス、AIアクション、エージェントの引き継ぎ、ノード単位のテストなどを備えた自動化作成の方法ですが、プレビュー機能は本番利用を前提とせず、機能制限や変更の可能性があると明記されています。(Microsoft Learn)
また、エージェントフローやワークフローの各アクションはCopilot Studio容量を消費します。環境のプリペイド容量を使い切ると、新しい実行がブロックされる可能性があるため、Power Platform管理センターで使用量を監視し、必要に応じて従量課金を検討する必要があります。(Microsoft Learn)
既存のPower Automateクラウドフローをエージェントフローに変換できる点も見逃せません。ただし、変換は一方向であり、Copilot Studio容量または従量課金が必要になります。既存フローをそのまま移行する前に、課金、環境、ソリューション配置、実行頻度を確認しておくべきです。(Microsoft Learn)
影響範囲：管理者、開発者、業務部門で見るべきポイントが違う
Microsoft Copilot Studioの更新やガイダンス強化は、開発者だけに影響するものではありません。生成AIを業務データと接続する以上、管理者、セキュリティ担当、業務部門、開発者が同じ前提で設計する必要があります。
| 立場 | 主な影響 | すぐ確認すべきこと |
|---|---|---|
| Microsoft 365 / Power Platform管理者 | 環境、ライセンス、容量、データポリシー、監査 | テナント・環境・エージェント単位の制御 |
| セキュリティ担当 | 情報漏えい、ログ、権限、外部接続 | Purview、Sentinel、DLP、データ保持 |
| 開発者 | RAG、ツール、MCP、プロンプト、ALM | 入出力、ツール説明、テスト、CI/CD |
| 業務部門 | 利用目的、成功基準、ナレッジ整備 | 何をAIに任せ、何を承認対象にするか |
| サポート担当 | Teams展開、問い合わせ対応、障害時の切り分け | バージョン表示、リセット手順、問い合わせ導線 |
この中でも特に重要なのが、管理者が「作成を許可するかどうか」だけでなく、「どのリスクレベルのエージェントを、どの環境で、どの権限とデータポリシーの下で作らせるか」を決めることです。公式ガイダンスでは、個人・チーム向けのCitizen Development Zone、IT承認済みのPartnered Development Zone、ミッションクリティカルなProfessional Development Zoneに分けるゾーン型ガバナンスが示されています。(Microsoft Learn)
管理者が確認すべき設定
環境を用途別に分ける
Copilot StudioのエージェントはPower Platform環境内で作成・管理されます。環境は、データ境界、セキュリティロール、データポリシー、ライフサイクル分離を決める論理コンテナーです。開発、検証、本番を同じ環境で扱うと、権限、データ、接続、公開範囲が混ざりやすくなります。(Microsoft Learn)
最低限、次のように分けて考えると安全です。
| 環境 | 目的 | 設定の考え方 |
|---|---|---|
| 個人・検証用 | アイデア検証、学習 | 外部公開や高リスクコネクタを制限 |
| 開発 | 業務エージェントの作成 | 作成者を限定し、必要な接続だけ許可 |
| テスト | 権限、ナレッジ、Teams表示、フロー実行を検証 | 本番に近い構成で利用者テスト |
| 本番 | 実利用 | 変更管理、監視、容量管理、問い合わせ導線を必須化 |
ALMガイダンスでも、健全なALM戦略には少なくとも開発、テスト、本番の3環境が含まれると説明されています。開発環境で変更し、テスト環境で検証し、問題がなければ本番へ展開する流れを前提にするべきです。(Microsoft Learn)
データポリシーで「使ってよい接続」を明確にする
Copilot Studioでは、テナント、環境、エージェントの各レベルで制御を考える必要があります。公式ガイダンスでは、データポリシーにより、未認証利用、チャネル、ナレッジソース、コネクタ、Application Insights連携、生成AIを使うエージェントの公開などを制御する考え方が示されています。(Microsoft Learn)
管理者が確認すべき代表的な項目は次のとおりです。
| 確認項目 | 判断基準 |
|---|---|
| 未認証ユーザー利用 | 社外公開が必要なエージェント以外は原則制限 |
| 公開チャネル | Teams、Web、SharePointなど必要最小限にする |
| ナレッジソース | SharePoint、Dataverse、Web、Azure AI Searchの利用可否を決める |
| コネクタ | 個人向けコネクタと業務システム接続を分離する |
| 生成AI機能 | データ移動や社内規程に合うか確認する |
| Application Insights | 監視に使う場合はログ設計と保持方針を決める |
「便利だから全部許可する」は危険です。Copilot Studioのエージェントは、会話だけでなく、外部システムの参照や処理実行にもつながります。データポリシーは、開発の邪魔をする設定ではなく、AIに任せてよい範囲を明文化するためのガードレールです。
ライセンスと容量を展開前に確認する
Copilot Studioでは、エージェントのメッセージ、エージェントフロー、ワークフロー、プレミアム機能、Power Automateやプロンプトビルダーなど、複数の容量・ライセンス要素が関係します。公式ガイダンスでも、ライセンス評価、コスト見積もり、環境単位のメッセージ容量割り当てを事前に行うことが推奨されています。(Microsoft Learn)
特に、ワークフローやエージェントフローを業務プロセスに組み込む場合は、次の3点を確認してください。
| 項目 | 確認内容 |
|---|---|
| 実行頻度 | 1日あたり何回実行されるか |
| 1実行あたりのアクション数 | どの程度容量を消費するか |
| 容量不足時の影響 | 新規実行が止まった場合、業務に支障が出るか |
小規模なFAQエージェントなら影響は限定的ですが、受注確認、チケット作成、承認依頼などに使うエージェントでは、容量不足が業務停止につながる可能性があります。
開発者が確認すべき実装上の注意点
AIに任せる処理と、決定的に実行する処理を分ける
生成オーケストレーションは便利ですが、すべての判断をAIに任せる設計は避けるべきです。公式ガイダンスでは、本番グレードのエージェントでは、決定的レイヤー、ハイブリッドレイヤー、AIオーケストレーターレイヤーのように制御層を分ける考え方が示されています。支払い、削除、権限変更などの不可逆な操作は、明示的な確認や承認を挟む設計が必要です。(Microsoft Learn)
判断基準はシンプルです。
| 処理 | 推奨設計 |
|---|---|
| FAQ回答、手順案内 | AIオーケストレーションやRAGで対応 |
| 社内規程の確認 | RAGを使いつつ、根拠リンクや引用を表示 |
| チケット作成、メール下書き | AIで補助し、実行前にユーザー確認 |
| 顧客情報更新、注文取消、権限付与 | 決定的フローと承認を必須にする |
| 金銭、法務、人事評価に関わる処理 | 人のレビューまたは業務システム側の制御を残す |
ツール名、説明文、入出力を雑に作らない
生成オーケストレーションでは、エージェントがツール、トピック、ナレッジを組み合わせて動きます。そのため、開発者は「動くフローを作る」だけでなく、「AIが正しく選べる部品として定義する」必要があります。公式ガイダンスでは、入力パラメーターには分かりやすい名前と説明を付け、出力変数を適切に定義することが推奨されています。(Microsoft Learn)
悪い例は、Flow1、GetData、ProcessRequestのような名前です。AIにとって、何をするツールなのか判断しづらくなります。良い例は、CreateServiceNowTicket、GetCustomerOrderStatus、SearchHRPolicyのように、対象と動作が分かる名前です。
さらに、似たツールを複数作る場合は、説明文で使い分けを明確にします。たとえば、返品状況を確認するツールと配送状況を確認するツールがあるなら、どちらも「注文情報を取得する」と書くのではなく、「返品受付後の処理状況を返す」「配送会社の追跡番号に基づいて配送状況を返す」のように区別します。
AIプロンプトとオーケストレーターを使い分ける
Copilot Studioでは、AIプロンプトとオーケストレーターは似ているように見えますが、役割が異なります。公式ガイダンスでは、AIプロンプトは出力形式、制約、ロジックを細かく制御したい場合に向き、オーケストレーターは一般的な推論、ツール選択、軽い整形に向くと説明されています。(Microsoft Learn)
たとえば、問い合わせ文から「顧客名」「契約番号」「緊急度」「依頼種別」をJSONで抽出する処理はAIプロンプト向きです。一方、「ユーザーの質問を見て、FAQ検索、注文API、チケット作成のどれを使うか判断する」処理はオーケストレーター向きです。
MCPは複数エージェントで共通化したい場合に有効
Model Context Protocol（MCP）は、AIモデルが外部ツール、データソース、ユーザー環境とやり取りするための標準化されたインターフェイスです。公式ガイダンスでは、複数のエージェントに対して、標準化され一元管理された方法でツールやリソースを公開したい場合にMCPが有効と説明されています。(Microsoft Learn)
一方で、プロトタイプ段階や単発のAPI呼び出しでは、直接APIを追加する方が早い場合があります。MCPは「大規模展開時の保守性」を高める選択肢であり、すべての連携を最初からMCP化すればよいわけではありません。
Computer useは本番利用時の実行環境を慎重に選ぶ
Computer use toolは、APIやスクリプトではなく、画面を見ながらエージェントが手順を実行するための機能です。レガシーアプリやデスクトップ専用業務など、通常のコネクタでは対応しづらい場面で有効です。(Microsoft Learn)
ただし、本番シナリオでは実行環境が重要です。公式ガイダンスでは、Microsoftホスト型マシンはプロトタイプ向け、BYOマシンはEntra IDやIntuneなどに対応するため本番シナリオ向けとされています。(Microsoft Learn)
移行・展開で失敗しやすいポイント
Copilot Studio for Teamsアプリだけに依存しない
公式概要では、2026年6月末以降、Copilot Studio for Teamsアプリでクラシックチャットボットを作成できなくなり、作成者はCopilot StudioのWebアプリへリダイレクトされると説明されています。既存の運用手順や社内教育資料がTeamsアプリ前提になっている場合は、Webアプリ前提の手順に更新しておく必要があります。(Microsoft Learn)
特に、情シスが現場部門に「Teamsからボットを作ってください」と案内している場合は注意が必要です。今後は、作成場所、権限、環境、公開先、レビュー手順をセットで案内する方が安全です。
Teams展開では会話の永続性を前提にする
Teamsに公開したエージェントは、Webチャットのようにセッションが自然にリセットされるとは限りません。公式ガイダンスでは、Teamsの会話は日をまたいで維持され、古いコンテキスト、トークン期限切れ、キャッシュされた古い内容、モデルのコンテキスト上限などが問題になる可能性があると説明されています。(Microsoft Learn)
そのため、Teams展開では次の設定を検討してください。
| 対策 | 目的 |
|---|---|
| 一定時間の非アクティブ後に状態をクリア | 古い会話文脈による誤動作を防ぐ |
/debug clearstateなどのリセット手順を案内 | サポート担当と利用者が自己解決しやすくする |
| 応答内にバージョン番号を表示 | 利用者が最新ロジックか確認できる |
| Force newest versionを必要に応じて使う | Teams側のキャッシュ影響を抑える |
| デスクトップとモバイルでAdaptive Cardを検証 | 表示崩れや操作不能を防ぐ |
Teamsは社内展開しやすい反面、長期セッションの扱いが難しくなります。公開前のテストでは、数分の会話だけでなく、数時間後・翌日・更新後の挙動まで確認することが重要です。
ALMで移行されない項目を見落とさない
Copilot StudioはPower Platformと同じ基盤上で動作するため、ソリューション、環境変数、接続参照、CI/CD、Git統合などのALM方針を適用できます。ただし、すべてが通常のソリューション展開で自動移行されるわけではありません。公式ガイダンスでは、Application Insights設定、手動認証設定、Direct Line / Webチャネルのセキュリティ設定、展開済みチャネル、共有設定などは、下流環境での展開後作業が必要な項目として挙げられています。(Microsoft Learn)
本番リリース前には、次のようなチェックリストを作ると安全です。
| チェック項目 | 確認内容 |
|---|---|
| ソリューションに含まれるか | トピック、アクション、ナレッジ、環境変数 |
| 展開後に手動設定が必要か | 認証、チャネル、共有、Webチャネルセキュリティ |
| 接続参照は正しいか | 開発用接続が本番に残っていないか |
| バージョン管理されているか | 変更履歴と戻し手順があるか |
| 本番公開前の承認があるか | セキュリティ、業務部門、運用担当の確認 |
公開後はKPIと評価で改善する
Copilot Studioのエージェントは、公開したら終わりではありません。公式ガイダンスでは、エージェントのパフォーマンスを理解し、ユーザー体験とビジネス目標を改善するために、組み込み分析、KPI、カスタム分析やレポートを活用できると説明されています。(Microsoft Learn)
見るべき指標は、単なる利用回数ではありません。実務では次のように分けて確認すると改善につながります。
| 指標 | 見る意味 |
|---|---|
| エンゲージメント率 | ユーザーが有効なトピックや処理に入れているか |
| 解決率 | 自己解決できているか |
| エスカレーション率 | 人への引き継ぎが多すぎないか |
| 放棄率 | 会話途中で離脱していないか |
| 未認識発話 | ナレッジやトピックに不足がないか |
| チャネル別分析 | Teams、Web、SharePointなどで差がないか |
また、評価は開発者だけの品質確認ではなく、ビジネス成果に直結します。公式の評価ガイダンスでは、エージェント評価は「動くか」だけでなく、出力品質を測るプロセスであり、サポートチケット削減、ユーザー満足度、リリース前の回帰テスト、投資対効果の説明に役立つとされています。(Microsoft Learn)
監視・監査・データ保持で確認すべきこと
運用段階では、Copilot Studioの分析ダッシュボードだけでなく、Application Insights、Microsoft Sentinel、Microsoft Purview、Power Platform管理センターを組み合わせて監視する設計が必要です。公式ガイダンスでは、利用状況やKPIの監視、カスタムイベントの送信、Sentinelによるアクティビティ監視、Purviewによる監査などが紹介されています。(Microsoft Learn)
会話履歴の扱いも重要です。公式ガイダンスでは、Copilotの会話トランスクリプトはDataverseのConversation Transcriptテーブルに保存され、保持期間は30日と説明されています。長期保存が必要な場合は、Azure Synapse Link for Dataverseを使ってAzure Data Lake Storage Gen2などにエクスポートする選択肢があります。(Microsoft Learn)
ここでの失敗例は、分析目的で会話ログを長期保存するつもりだったのに、保持期間やエクスポート設計を決めていなかったケースです。社内規程、監査要件、個人情報の扱いを踏まえ、保存するログ、保存期間、閲覧権限、削除方針を事前に決めておきましょう。
管理者・開発者向けの実務チェックリスト
Copilot StudioのAIエージェントを本番利用する前に、次の順番で確認すると抜け漏れを減らせます。
| 手順 | 確認内容 |
|---|---|
| 業務目的を決める | 何を解決するエージェントか、成功基準は何か |
| リスク分類を行う | 個人利用、部門利用、全社・ミッションクリティカルのどれか |
| 環境を分ける | 開発、テスト、本番を分離する |
| データポリシーを設定する | 利用できるコネクタ、チャネル、ナレッジソースを制御する |
| RAG対象を整理する | 古い文書、未承認文書、権限不備を除外する |
| ツールを設計する | 名前、説明、入力、出力、承認要否を定義する |
| Teams展開を検証する | 長期セッション、リセット、バージョン更新を確認する |
| ALMを整備する | ソリューション、環境変数、接続参照、手動設定を管理する |
| 容量を見積もる | メッセージ、フロー、ワークフローの実行量を確認する |
| 監視と評価を始める | KPI、ログ、会話分析、改善サイクルを運用に組み込む |
よくある疑問
すぐに既存エージェントを移行する必要はある？
必ずしも一律の移行が必要とは限りません。ただし、Teamsアプリでのクラシックチャットボット作成、Power Automateフローのエージェントフロー化、Teamsでの永続セッション、生成AI機能の利用範囲などは、既存運用に影響する可能性があります。まずは既存エージェントの公開先、利用データ、作成環境、接続、認証、監視状況を棚卸ししてください。(Microsoft Learn)
Workflowsは本番で使ってよい？
Workflowsはpublic previewとして説明されており、プレビュー機能は本番利用を前提とせず、制限や変更の可能性があります。本番業務で使う場合は、正式提供状況、代替手段、障害時の手動運用、容量消費を確認してから判断してください。(Microsoft Learn)
生成AIを有効にすればトピック設計は不要になる？
不要にはなりません。むしろ、トピック、ツール、ナレッジ、入力、出力、説明文をAIが正しく選べるように設計する必要があります。生成オーケストレーションでは、部品の名前や説明が重要であり、不要・重複・危険なツールを整理することが推奨されています。(Microsoft Learn)
管理者が最初に見るべき設定は？
最初に見るべきなのは、環境分離、データポリシー、作成者権限、公開チャネル、ナレッジソース、容量です。特に、テナント、環境、エージェントの各レベルで、生成AI機能、ナレッジソース、コネクタ、チャネル、認証をどう制御するかを決めておく必要があります。(Microsoft Learn)
まず着手すべきこと
Microsoft Copilot Studio guidance documentationの更新から読み取るべき実務上のポイントは、Copilot Studioを「すぐ作れるAIチャット」ではなく、企業データと業務処理に接続するAIエージェント基盤として扱うことです。最初にやるべきことは、新しいAI機能を片っ端から有効にすることではありません。
まず、既存または計画中のエージェントを棚卸しし、次の3点を確認してください。
- どのデータにアクセスし、誰の権限で回答するのか
- どの処理をAIに任せ、どの処理に確認・承認を挟むのか
- 開発、テスト、本番、監視、改善の流れが用意されているか
この3点が整理できていれば、RAG、生成オーケストレーション、エージェントフロー、MCP、Teams展開、Copilot Studio Kitなどの機能を安全に活用しやすくなります。反対に、ここを飛ばすと、回答品質、情報漏えい、容量不足、Teamsでの古い状態、リリース後の切り戻し不可といった問題が起きやすくなります。Copilot Studioを本番展開する前に、公式ガイダンスを「機能一覧」ではなく「運用設計書のチェックリスト」として読み直すことが、最も実用的な対応です。
コメント