Copilot Studioの構成はどう決める？データ・処理・利用画面から考える設計の基本

Copilot Studioの構成は、KnowledgeやToolなど、エージェントの機能だけでは決まりません。前回の記事では、「知りたい・実行したい・任せたい」という目的から、Knowledge、Tool、Topic、Agentなどの役割を整理しました。

しかし、実際に業務で使うエージェントを作るには、その先も考える必要があります。何の情報を参照するのか、どのシステムへ登録するのか、結果をどこへ残すのか、利用者がどの画面から使うのかによって、適した構成は変わります。

たとえば、社内規程を案内するだけであれば、Knowledgeとアクセス権の確認が中心になります。一方、問い合わせ内容を受け付け、台帳へ登録し、担当者へ通知する場合は、Tool、記録先、接続資格情報、失敗時の対応まで必要です。

一覧表示や入力内容の修正が必要なら、チャットだけで完結させず、Power Appsなどの画面と組み合わせます。

また、会社や顧客の情報を扱う場合は、データがあるかだけでなく、その情報を業務で利用してよいか、どこへ渡るか、誰の権限で処理するかも確認します。エージェントが動くことと、業務で安全に運用できることは同じではありません。

この記事では、前回整理したKnowledge、Tool、Agentなどを出発点として、参照する情報、実行する処理、正式な記録先、利用画面、権限や運用まで含め、Copilot Studioの構成を考える視点を整理します。

Knowledge、Tool、Topic、Agentの違いから確認したい場合は、先に第1弾の「Copilot Studioの設計はどう考える？Knowledge・Tool・Agentの違いと選び方」をご覧ください。

目次

Copilot Studioの構成は、業務全体から考える

Copilot Studioでエージェントを作るときは、KnowledgeやToolなど、エージェント内部の機能に目が向きやすくなります。しかし、業務で利用する構成を決めるには、エージェントの外側も含めて考える必要があります。

たとえば、問い合わせ対応を支援するエージェントでも、任せる仕事によって構成は異なります。

• マニュアルから回答を探すだけなら、Knowledgeを中心にする
• 問い合わせを登録するなら、Toolと記録先が必要になる
• 担当者へ通知するなら、Power Automateなどの処理を加える
• 入力内容を一覧で確認・修正するなら、Power Appsなどの画面を組み合わせる
• 顧客情報を扱うなら、利用条件、アクセス権、接続資格情報を確認する
• 処理に失敗した場合に備え、人への引き継ぎや再実行方法を決める

このように、同じ「問い合わせ対応エージェント」でも、回答だけを行う場合と、登録、通知、確認まで行う場合では、必要な構成が変わります。

構成を考えるときは、まず誰のどの仕事を、どこまでエージェントへ任せるかを明確にします。そのうえで、「エージェントの役割」「参照する情報」「処理と記録」「利用画面と運用」の4つの領域を確認します。

たとえば、顧客情報を利用できないと分かれば、参照する情報やエージェントの役割を見直します。Power Appsを利用する場合は、入力方法や記録先も変わります。Toolに必要な権限を確認した結果、実行方法や人による確認の入れ方を変えることもあります。

そのため、Copilot Studioの構成は、製品を順番に選ぶフローではありません。業務の目的を中心に、4つの領域を行き来しながら必要な構成を組み合わせるものとして考えます。

今回の記事では、構成を考える視点を次の4つの領域に整理します。

使うデータからKnowledgeとToolの役割を決める

Copilot Studioの構成では、エージェントに何をさせるかだけでなく、どのデータを、何のために使うかを確認します。

同じデータでも、文書から回答を探すのか、業務システムの最新値を取得するのかによって、必要な構成が変わります。

たとえば、返品条件を案内するだけなら、規程やFAQをKnowledgeとして参照できます。一方、実際に返品できるかを確認するために、購入日や契約内容を調べる場合は、業務システムから最新情報を取得するToolが必要です。

KnowledgeとToolは、どちらか一方だけを選ぶものではありません。返品条件はKnowledgeで確認し、注文情報はToolで取得するなど、一つの業務で組み合わせることもあります。

構成を決める前に、少なくとも次を確認します。

• 必要な情報がそろっているか
• 内容が正確で、現在も有効か
• 誰が情報を更新するか
• 利用者に参照権限があるか
• 回答だけに使うのか、判断や登録にも使うのか
• 情報がどのサービスや接続先へ渡るか
• 処理結果をどこへ保存・共有するか

すべての情報を理想的な状態へ整えてから試す必要はありません。情報が不足している場合は、対象業務を小さくしたり、検索や要約などの補助的な用途へ限定したりできます。

ただし、顧客情報や個人情報を使った処理へ進む場合は、システム上で保護されるかだけでなく、契約や業務上、その情報を利用してよいかも確認します。

Copilot Studioの構成では、利用できるデータがあるかだけでなく、どこから取得し、どこへ渡し、誰の権限で使うかまで決めることが重要です。

業務データの確認方法は「Copilot活用では業務データをどう見る？今ある情報から進め方を判断する」、会社や顧客情報の利用判断は「Copilotに会社や顧客の情報を入力して大丈夫？業務で判断するポイント」で詳しく整理しています。

処理・記録先・利用画面を業務に合わせて選ぶ

使うデータと利用条件を確認したら、エージェントが行う処理、結果の記録先、利用者が操作する画面を決めます。

最初から製品を選ぶのではなく、まず業務上必要な処理を整理します。

• 情報を取得する
• データを登録・更新する
• 担当者へ通知する
• 承認を依頼する
• 自動処理できない場合は人へ引き継ぐ

単一のサービスから情報を取得・登録する場合は、標準コネクタを利用できる可能性があります。複数の処理をつなぐ場合は、Power Automateやエージェントフローを検討します。既存の方法では接続できない場合は、APIやカスタムコネクタも候補になります。

ただし、接続できることと、自動化すべきことは同じではありません。例外が多い処理や人の判断が必要な処理は、必要な情報を整理して担当者へ引き継ぐ方法も考えます。

次に、処理結果をどこへ残すかを決めます。

重要なのは、エージェントから使いやすい保存先ではなく、業務上どこを正式な記録元にするかで決めることです。既存の問い合わせ管理システムがある場合、同じ情報を別の台帳へ登録すると二重管理になる可能性があります。

最後に、利用画面を選びます。

• 質問と回答だけで完了するなら、TeamsやMicrosoft 365 Copilotなどのチャット
• 一覧表示や内容の修正が必要なら、Power Appsなどのアプリ
• 多項目の入力が必要なら、フォームや業務画面
• 社外利用者が使うなら、認証を含むPower PagesやWeb画面

何でもチャットで完結させる必要はありません。会話や案内はエージェントへ任せ、一覧、入力、修正、正式な記録には適した画面やシステムを組み合わせます。

Microsoft Learnの「計画と設計の統合戦略」では、Copilot Studioで利用できる連携方法が整理されています。Power Platformコネクタ、HTTP要求、エージェントフローなどの特徴と、選定時の考慮事項を確認できます。

Copilot Studioの構成では、処理する、記録する、利用するを分けて考え、既存業務やシステムを生かして組み合わせることが重要です。

本番化する前に、権限・失敗時・運用を確認する

エージェントが想定どおりに回答し、Toolを実行できても、それだけで本番運用へ進めるとは限りません。

本番化する前に、誰が利用し、誰の権限で動き、失敗した場合にどう対応するかを確認します。

• 認証とアクセス権
  エージェントを誰が利用できるかを決めます。Knowledgeとして参照する情報についても、利用者が本来アクセスできる範囲を超えていないか確認します。
• Toolの接続資格情報
  データの取得や登録を、利用者本人の接続で行うのか、作成者が設定した接続で行うのかを確認します。必要以上に強い権限を与えず、対象業務に必要な範囲へ絞ります。
• 重要な処理の確認
  登録、更新、外部送信、承認など、実行後に影響が残る処理には、必要に応じて人による確認を入れます。AIが処理方法を選べることと、確認せずに実行してよいことは分けて考えます。
• 失敗時の対応
  ToolやPower Automateが失敗した場合に、利用者へ何を伝えるかを決めます。二重登録を防ぐ方法や、途中まで処理された場合の確認方法、人へ引き継ぐ条件も整理します。
• 所有者と更新担当者
  エージェントの所有者だけでなく、Knowledge、Tool、接続、業務ルールを誰が更新するかを決めます。担当者が異動した場合にも運用を続けられる状態にします。
• 公開後の確認
  利用数だけでなく、回答できなかった質問、Toolの失敗、処理時間、業務上の成果を確認します。利用結果をもとに、改善、用途変更、継続、停止を判断します。

すべての項目を試作前に確定する必要はありません。まず小さく試し、回答や処理が成立するかを確認します。ただし、利用者や対象範囲を広げる前には、権限、失敗時の対応、運用責任を明確にします。

Copilot Studioの構成は、エージェントを作って公開すれば完成ではありません。安全に動かせるか、失敗したときに止められるか、公開後も維持・改善できるかまで含めて設計することが重要です。

公開後の評価や、改善・継続・用途変更・停止の判断については、「Copilot・AIエージェントの効果をどう測る？利用・品質・業務成果から判断する」で詳しく整理しています。