Microsoft Copilot Studio で社内のFAQ問い合わせエージェントを作ってみた
製造ビジネステクノロジー部の小林です。
最近私の周りで Microsoft Copilot Studio のお話をよく聞きます。
GitHub Copilot はよく使いますが Microsoft Copilot はまだ使ったことがないため実際に使ってみました。
今回は社内の問い合わせ対応エージェントを 1 つ作って公開するところまでを一通りやってみます。
Copilot Studio とは
Copilot Studio は、AI エージェントとワークフローを作って運用するためのローコードスタジオです。
少し混乱したのは、「Copilot」という名前が付く製品同士の区別でした。整理するとこうなります。
| 名前 | 何なのか | 立場 |
|---|---|---|
| Microsoft 365 Copilot | Word / Excel / Teams などに組み込まれた AI アシスタント | 使う側の製品 |
| Copilot Chat | 汎用のチャット。ChatGPT に近い使い方 | 使う側の製品 |
| Copilot Studio | エージェントを作る側のツール | 作る側の製品 |
つまり Copilot Studio は「Copilot を使うツール」ではなく「自分の会社用の Copilot を作るツール」です。
何が嬉しいのか
エージェントを自前で実装する場合、だいたい次のものを用意することになります。
- LLM の API キー管理と呼び出し実装
- 社内ドキュメントを検索可能にする RAG の基盤（ベクトル DB、埋め込み、更新処理）
- 社内システムと連携するためのツール / API 連携
- 認証、権限、ログ、監査
- Teams なり Web なりへの配信口
SharePoint や Web サイトを「ナレッジ」として指定すれば検索の仕組みは自動で構築されますし、1400 以上あるコネクタ経由で外部システムを呼び出せます。
公開先には Teams や Microsoft 365 Copilot、Web サイトが最初から用意されています。Entra ID の認証をそのまま利用できる点も、社内向けに作るうえでは利点です。
一方で、データや利用者が Microsoft 365 / Power Platform の外にある場合は、これらの利点が活かしにくくなります。その場合は別の基盤を検討する方が適していると思います。
ホーム画面の 3 つの選択肢
ホーム画面のカードは、作れるものの種類に対応しています。
- Agent: 会話を受けて、質問に答えたり行動したりする AI アシスタント。指示（instructions）とナレッジとツールを与えて作る
- Workflow: トリガー・アクション・AI ステップを並べる自動化。ドラッグ & ドロップのデザイナーで作る。各ステップ自体が推論できるのが従来の自動化との違い
- Agent flow（Other ways to build の中）: Power Automate に近い従来型のフロー。単体実行もできるし、エージェントに持たせるツールにもできる
ざっくりした使い分けはこうです。
- 人が話しかけてくる入口が欲しい → Agent
- 起点がイベントや定期実行で、決まった手順を回したい → Workflow
- エージェントに外部システムと連携する手段を持たせたい → Agent flow をツールとして割り当てる
ハーネスという概念
作ったものはすべてハーネスと呼ばれる実行エンジンの上で動き、選んだハーネスによって推論の仕方・機能・課金方式が変わります。
- GitHub Copilot ハーネス: 推論重視。複数ステップの作業や複雑な業務プロセス向け。ホーム画面の Agent / Workflow カードはこちら
- 標準ハーネス: ルールベース。トピックを設計して会話を構造化・再現する従来型。「Other ways to build」から作る
- Copilot チャットハーネス: 社内ナレッジで Microsoft 365 Copilot Chat を拡張する
ホーム画面の Agent カードに GitHub Copilot というバッジが付いているのはこのことを表しています。サインアップ直後の画面で「Uses Copilot Credits」と書かれていたのも、GitHub Copilot ハーネスが従量課金だからです。
ハンズオン: 社内 FAQ エージェントを作る
題材は「社内の問い合わせ対応エージェント」にします。公開されているドキュメントをナレッジに繋いで、それを根拠に回答させる、という構成です。
1. エージェントを作る
ホーム画面の Agent カードを選択すると、エージェントの編集画面（Build）が開きます。
画面の構成はシンプルで、左側がエージェントの中身、右側が周辺の設定です。
左側には名前と Instructions（指示）の入力欄があります。Instructions は空の状態で開き、入力欄には何を書けばよいかのガイドが表示されています。
- エージェントの役割とゴール
- 対応する範囲と、対応しない範囲
- 回答のトーンとスタイル
- 質問を返すべき場面、ナレッジを使う場面、行動を起こす場面
Contoso 社の IT サポート担当を例にしたサンプルも載っているので、書き方に迷ったらこれをなぞるとよさそうです。
右側のパネルには次の項目が並びます。
- Model: エージェントが使うモデル。既定で Claude Opus 5 が選択されていました
- Channels: 利用者がエージェントと会話する場所（Teams や Web など）
- Skills: 構造化された指示で振る舞いを定義する
- Tools: 外部システムやアクションと接続する
- Knowledge: 回答の根拠にするデータソース。既定で「Search all websites」が入っています
- Connected agents: 他のエージェントと連携させる
- Memory（プレビュー）: やり取りや文脈を記憶させる。既定はオフ
画面上部には Build / Preview / Evaluate / Monitor のタブと Publish ボタンがあり、作る・試す・評価する・運用を見る、という一連の流れがそのままタブになっています。
今回は Instructions に次の内容を入力しました。
あなたは社内の問い合わせ窓口です。勤怠・経費精算・情報システムに関する質問に答えます。
回答は必ず Knowledge に登録されたドキュメントに基づいて行ってください。
根拠が見つからない場合は推測せず「分かりません」と答え、担当部署の連絡先を案内してください。
回答は簡潔にし、参照元を示してください。
2. ナレッジを繋ぐ
エージェントは「ナレッジ」として指定したデータソースを根拠に回答します。指定できるのは主に次のあたりです。
- SharePoint / OneDrive のサイトやフォルダ
- 公開 Web サイト（URL 指定）
- アップロードしたファイル（PDF、Office ドキュメントなど）
- Dataverse や各種コネクタ経由の外部データ
Build 画面の Knowledge には、既定で「Search all websites」が入っています。これは Web 全体を検索対象にするものです。今回は社内ドキュメントだけを根拠に回答させたいので、これは削除しておきます。ここを残したままだと、ドキュメントに書かれていない質問にも Web 検索の結果で答えてしまい、検証になりません。
ナレッジに登録する社内ドキュメントは、架空の会社の社内ルールとして自作しました。勤怠・経費精算・情報システムの 3 章構成で、次のような内容です。
架空の会社の社内ルール
株式会社サンプル 社内ルールまとめ（2026 年 4 月改定版）
■ 1. 勤怠
1-1. 所定労働時間
所定労働時間は 1 日 8 時間、休憩は 60 分とします。
1-2. フレックスタイム制
コアタイムは 11:00 から 15:00 です。フレキシブルタイムは 6:00 から 22:00 の間で設定できます。
1-3. 勤怠の打刻
出退勤の打刻は勤怠システム「サンプル勤怠」から行います。打刻の修正が必要な場合は、当月末までに直属の上長へ申請してください。翌月以降の修正は人事部への申請が必要です。
1-4. 有給休暇
有給休暇は入社時に 10 日付与され、以降は勤続年数に応じて増加します。取得する場合は原則として 3 営業日前までに申請してください。
1-5. 遅刻・欠勤の連絡
遅刻または欠勤する場合は、始業時刻の 30 分前までに直属の上長へチャットで連絡してください。
■ 2. 経費精算
2-1. 申請期限
経費の申請期限は、支出が発生した月の翌月 10 日までです。期限を過ぎた場合は、理由書を添えて経理部へ申請してください。
2-2. 領収書
1 件 5,000 円以上の支出は領収書の添付が必須です。5,000 円未満の場合は、利用日・金額・内容が分かる明細で代替できます。
2-3. 交通費
公共交通機関の実費を精算します。タクシーの利用は、終電後の移動または重量物の運搬がある場合に限り認められます。
2-4. 書籍購入
業務に関連する書籍は 1 人あたり月 10,000 円まで会社負担で購入できます。購入した書籍は個人の所有物となります。
2-5. 精算の振込日
承認された経費は、申請月の翌月 25 日に給与と合わせて振り込まれます。
■ 3. 情報システム
3-1. 貸与端末
入社時にノート PC を 1 台貸与します。標準構成は macOS または Windows から選択できます。
3-2. 端末の故障
貸与端末が故障した場合は、情報システム部へ問い合わせてください。代替機の貸出は原則として申請の翌営業日から可能です。
3-3. パスワード
社内システムのパスワードは 12 文字以上とし、多要素認証を必ず有効にしてください。
3-4. ソフトウェアの導入
業務で必要なソフトウェアを導入する場合は、事前に情報システム部の承認が必要です。承認には通常 3 営業日かかります。
3-5. 問い合わせ窓口
情報システムに関する問い合わせは、社内チャットの #helpdesk チャンネルで受け付けています。
■ 4. 各部署の連絡先
勤怠に関する問い合わせ: 人事部（jinji@example.com）
経費精算に関する問い合わせ: 経理部（keiri@example.com）
情報システムに関する問い合わせ: 情報システム部（#helpdesk チャンネル）
自作したのは、後のテストで何が書いてあって何が書いていないかを完全に把握しておきたかったからです。公開 Web サイトを指定する方法だと、エージェントが答えられなかったときに、ドキュメントに情報がないのか検索がうまくいかなかったのかを切り分けにくくなります。
ドキュメントには 2 つ仕掛けを入れています。1 つは、コアタイムや金額のように、回答の正誤をそのまま照合できる具体的な数値を入れたことです。
もう 1 つは、育児休業や住宅手当といった話題をあえて一切書かなかったことです。後者は「書かれていないことを聞かれたときの振る舞い」を確認するために使います。
作成したドキュメントを Word 形式で保存し、Knowledge にアップロードします。
3. テストする
画面上部の Preview タブから、公開前に会話を試せます。用意したドキュメントに合わせて、次の 3 つの観点で質問しました。
1 つ目は、ドキュメントに書いてあることを正しく答えられるかです。
コアタイムは何時から何時までですか？
2 つ目は、ドキュメントに書かれていないことを聞いたときの振る舞いです。育児休業はドキュメントに一切書いていない話題です。
育児休業は何日取れますか？
ここで推測で答えてしまうと、根拠のない回答を返す窓口になってしまいます。Instructions に書いた「根拠が見つからない場合は推測せず分かりませんと答え、担当部署の連絡先を案内する」が効いているかどうかを、ここで確認します。
3 つ目は、複数の記載を踏まえないと答えられない質問です。
終電後に帰宅するために使った 3,000 円のタクシー代は経費で精算できますか？領収書は必要ですか？
この質問は「タクシーは終電後なら可」と「5,000 円未満は領収書不要」という別々の項目を組み合わせる必要があります。単純な検索結果の引用ではなく、複数の条文を読んだうえで判断できるかどうかが分かります。
今回はいずれのテストも合格でした！
4. 評価する
Preview タブでの手動テストは、質問を思いついた順に投げていくものなので、Instructions を直すたびに同じ質問をもう一度投げ直す必要があります。Evaluate タブを使うと、この確認を自動化できます。
Evaluate は、テストケースをまとめて実行し、エージェントの回答を採点する機能です。実行すると Copilot Studio が実際にエージェントへ質問を送り、返ってきた回答を評価してスコアを出します。
Create your first evaluation を選ぶと、テストケースの作り方を 3 つから選べます。
-
CSV をアップロードする: 用意されたテンプレートに沿って会話を記述したファイルを読み込ませます。上限は 5MB です
-
Quick conversation set: エージェントの説明・Instructions・トピックをもとに、会話を 10 件自動生成します
-
自分で質問を書く: 画面上で直接質問を入力します
-
CSV をアップロードする: 用意されたテンプレートに沿って会話を記述したファイルを読み込ませます。上限は 5MB です
-
Quick conversation set: エージェントの説明・Instructions・トピックをもとに、会話を 10 件自動生成します
-
自分で質問を書く: 画面上で直接質問を入力します
数十件規模のテストセットを作るなら CSV、とりあえず動かしてみたいなら Quick conversation set が便利そうです。Quick conversation set は、自分が思いつかなかった質問を出してくれる点でも役に立ちます。
今回は確認したい観点が決まっているので、自分で質問を書く方法を選びました。使ったのは、3 のステップで手動で投げた質問です。
3 問と、それぞれに期待する回答を入力すると、テストケースが 1 件できました。
ここで少し戸惑ったのは、テストケースの単位が 1 往復の質問と回答ではなく、会話（Conversation）だったことです。3 問を入力したので 3 件のテストケースができると思っていたのですが、一覧には 1 行だけ表示され、Total messages が 6 になっています。
テストケースの行を開くと、中身を確認できます。
入力した 3 つの質問と、それぞれに対する期待する回答が交互に並び、合計 6 メッセージで 1 つの会話を構成していました。画面右下にも「3/6 question-answer pairs」と表示されています。期待する回答の側には Reference というラベルが付いており、この回答が採点時の参照情報として扱われることが分かります。
右側の Configure test set では、テストセットの名前と採点方法を設定します。
- Data type: Conversation。テストケースの単位が会話であることを示しています
- Test method: 選べたのは General quality のみでした。関連性や網羅性といった品質基準を満たしているかを判定する方式です
- User profile: 評価の実行に使うユーザープロファイル。必要な接続を持つ認証済みプロファイルの利用が推奨されています
注意したいのは、General quality の説明にある「Doesn't compare to expected responses」という一文です。期待する回答を Reference として登録していても、この方式はそれとの照合を行わず、回答そのものの品質を判定します。「コアタイムは 11:00 から 15:00 と答えたか」を厳密に突き合わせたい場合は、この方式では確認できません。
設定が終わったら Evaluate を実行します。実行前に、評価に使うアカウントを選ぶダイアログが表示されました。
評価はエージェントと実際に会話して回答を集めるため、「誰として質問を送るか」を指定する必要があります。アカウントを選ぶまで Run は押せません。
認証済みのアカウントを選ぶよう促されているのは、エージェントが Tools で外部システムに接続している場合、その接続を自分の資格情報で行う必要があるためです。
今回のエージェントは Knowledge にドキュメントを置いているだけなので、自分のアカウントを選ぶだけで実行できました。
評価結果は 0% だった
実行は 57 秒で終わり、結果は Score 0% の Fail でした。
Evaluation summary には、実行時間、テストケース数、使用したテストセット、実行したユーザープロファイルが記録されます。テストケースの行を開くと、実際の会話と判定理由を確認できます。
エージェントの回答自体は 3 問とも意図したとおりでした。
それでも判定は Fail です。Test case details に表示された理由は次の 2 行でした。
One or more questions not answered
Further checks skipped because relevance failed
答えられていない質問が 1 つ以上あるため、関連性の判定で落ち、それ以降のチェックは行われなかった、という内容です。該当するのは 2 問目の育児休業で、エージェントは「分かりません」と答えています。
つまり、Instructions に書いたとおりに「根拠がないので分かりません」と答えた振る舞いが、General quality の観点では「質問に答えていない」と判定されたことになります。こちらの意図としては期待どおりの動作ですが、採点する側から見れば未回答です。
評価を使う場合は、この性質を踏まえてテストセットを分けるのがよさそうです。答えられるはずの質問だけを General quality で評価し、答えないことが正解の質問は別の方法で確認する、という形です。
なお、画面にも「Evaluations use Copilot Credits.」と表示されているとおり、評価の実行はクレジットを消費します。テストケースを増やすほど 1 回の実行コストも増えるので、最初は確認したい観点を絞るのがよさそうです。
5. 公開する
画面右上の Publish を選び、続いて共有の設定を行います。公開先として選べるのは Teams、Microsoft 365 Copilot、デモ用 Web サイト、独自サイトへの埋め込みなどです。
共有の単位は 2 つに分かれています。
1 つは個人やグループの指定です。上部の入力欄に名前・グループ・メールアドレスを入れて招待します。作成直後は自分だけが Owner として登録されている状態でした。
もう 1 つは組織全体に対する設定です。Everyone in your organization の行で、組織の全員にどこまで許可するかを選びます。初期値は「No permissions, unless specified」で、明示的に招待した人以外はアクセスできません。
選択肢はこの 2 つでした。
- End user access: 接続を管理し、エージェントと会話するか、自分の代わりに自律的に動かすかを設定できる
- No permissions, unless specified: 既定値。個別に招待した人だけが使える
End user access を組織全体に付けると、テナントの全員がこのエージェントを使えるようになります。社内ドキュメントを根拠に回答するエージェントの場合、ナレッジに置いたドキュメントの内容がそのまま全員に見える状態になります。
今回はは既定のまま、必要な相手を個別に招待するようにしました。
左下の Copy link (Microsoft Teams) で、Teams で開くためのリンクを取得できます。横のドロップダウンから他の形式のリンクも選べます。
Teams では開けなかった
取得したリンクを Teams に貼って開いてみたところ、「このアプリが見つかりません。」と表示されました。
リンクの形式自体は Teams のアプリを開くためのもの（https://teams.microsoft.com/l/app/?titleId=...）で正しいので、アプリが Teams 側に存在していない状態です。
原因の特定には至りませんでしたが、考えられる要因としては、公開が完了していない、Teams チャネルが追加されていない、反映待ち、テナントのアプリ許可ポリシーで制限されている、といったものが挙げられます。
チャネルを選び直す
ここで、GitHub Copilot ハーネスのエージェントが対応しているチャネルを確認しました。
現時点で利用できるのは次の 4 つです。
- Microsoft 365 Copilot
- Microsoft Teams
- デモ Web サイト
- Web アプリケーション（iframe で自分のサイトに埋め込む）
Slack、WhatsApp、Facebook、Telegram といったメッセージングチャネルや、SharePoint、コンタクトセンター系のチャネルは、いずれも現時点では利用できません。
標準ハーネスはルールベースの従来型で、Azure Bot Service 経由で Slack などにも接続できます。ただしその場合は Azure 側にボットを用意する必要があり、構築方法が異なります。
今回はデモ Web サイトを選びました。アプリのインストールを伴わないので、Teams のような制限を受けにくく、URL を開くだけでブラウザ上で会話できます。
デモ Web サイトは認証設定に阻まれる
Channels からデモ Web サイトを追加しようとすると、次のメッセージが表示されました。
The Web channel is unavailable because this agent requires authentication.
Switch to "No authentication" in the agent's settings to enable it.
エージェントが認証を要求する設定になっているため、Web チャネルが使えないという内容です。Agent settings の Safety & access を開くと、Authentication の選択肢は次の 2 つでした。
- Authenticate with Microsoft: Microsoft Entra ID で認証する
- No authentication: 認証なし
ここで No authentication に切り替えると、デモ Web サイトが選べるようになります。
ただし、認証なしにすると、URL を知っている人は誰でもエージェントと会話できます。社内ドキュメントを根拠に回答するエージェントの場合、リンクが渡った相手にはナレッジの内容も引き出せる状態になるということです。
今回ナレッジに入れているのは架空の会社のサンプル文書なので問題ありませんが、本物の社内規程で同じことをするのは避けるべきです。実運用では認証を有効にしたまま、Teams や Microsoft 365 Copilot に公開するのが本筋になります。
設定を変えて Add a channel を開き直すと、選べるチャネルが変わりました。
ここで一度つまずいたのが、リンクが淡色表示のままで Open demo website を押せなかった点です。Agent settings の上部に「Changes to settings take effect after you save and publish the agent.」と書かれているとおり、設定の変更は保存して公開するまで反映されません。保存して Publish を実行すると、リンクが有効になりました。
発行された URL を開くと、チャットウィンドウを備えたページが表示され、ブラウザ上でエージェントと会話できました。
App チャネルは開発者向けの入口だった
チャネル一覧にある App は、Web アプリへの埋め込み用の iframe スニペットに加えて、開発者向けの接続手段も提供していました。
- Microsoft 365 Agents SDK: Python / JavaScript / .NET から認証済みエージェントを自分のアプリに組み込むための接続文字列。保存して公開すると発行されます
- Agents Client SDK: iOS / Android / Windows のネイティブアプリ向け SDK
Copilot Studio で作ったエージェントを、そのまま自前のアプリケーションから呼び出せるということです。画面上でエージェントを組み立て、コードからは接続文字列で利用する、という分担ができます。
料金で注意したいポイント
GitHub Copilot ハーネスは 2026 年 8 月 3 日から、Copilot Credits による従量課金になっています。
事前に押さえておきたいのは次の 2 点です。
- 課金は「作り始めた時点」から始まる。標準ハーネスは公開後から課金でしたが、GitHub Copilot ハーネスは自然言語での作成、プレビュー、テスト、評価の作成、すべてがクレジットを消費します。つまり今回のハンズオンも消費しているということです
- クレジットは体験全体をカバーする。LLM のトークンだけでなく、ナレッジや MCP を含むツールの利用、ハーネス自体にも課金されます
消費量は Copilot Studio の Monitor ページで確認できます。環境全体・テナント全体の消費は Power Platform 管理センターの Licensing > Copilot Studio 側です。
まとめ
今回は初めて Copilot Studio を触ってみました。UI がシンプルで、ノーコードでもチャットボットを構築できる手軽さが印象的でした。ナレッジソースを登録してトピックを設定するだけで、想定していたよりも短時間で動くものが仕上がりました。
一方で、より実務に近い使い方をするなら、回答精度のチューニングや外部システムとの連携が次の課題になりそうです。
次回は Workflow を試し、トリガーを起点とした複数ステップの自動化を組んでみたいと思います。
