Microsoft Copilot Studioで社内FAQボットを作る方法｜Teams配布までの最短手順とガバナンス

2025-12-15

Microsoft Copilot Studioで社内向けFAQボットを作り、Teamsに配布する手順を初心者向けに解説。SharePointを知識源にした生成的回答、DLP設定、OAuth同意フィッシング対策、セキュリティとガバナンスの注意点まで詳しく整理します。

Copilot Studio Microsoft Teams 社内FAQ AIガバナンス 情シス

Microsoft Copilot Studioで「社内FAQボット」を作ると何が解決するか

「同じ質問に毎日何度も答えている」「社内規程や手順が散らばっていて、探すだけで時間が溶ける」――このようなムダは、情シス・人事・総務・営業企画など、あらゆる部門で起きています。

Microsoft Copilot Studioを使えば、社内のFAQボット(エージェント)を ローコード で作成し、Microsoft Teamsに配布して"社内の入口"に設置できます。さらに、SharePoint上の規程や手順書を参照し、要点をまとめて回答する仕組み(生成的回答)も実装できます。

本記事では、初心者でも迷わないように「作成 → テスト → Teams配布 → 運用と統制」までを一気通貫で解説します。

前提知識と用語のやさしい定義

  • Copilot Studio:Microsoftのローコードでエージェント(会話ボット)を作成・管理・配布できるサービス
  • エージェント:ユーザーの質問に応答したり、あらかじめ決めた会話フローで案内する"社内向け窓口"
  • トピック:よくある質問の"型"を定義する単位(例:「パスワードリセット」「経費精算」など)
  • 生成的回答(Generative answers):知識ソース(例:SharePointのURL)を検索し、要点を要約して回答する仕組み
  • 知識ソース:生成的回答が参照する情報源(SharePoint/OneDriveのURLなど)
  • 環境(Environment):Power Platformの論理的な作業領域。エージェントや関連資産を、部門・用途・本番/検証などで分離できる
  • DLP(Data Loss Prevention)ポリシー:コネクタ(外部接続)を許可/禁止するなど、データ持ち出しを抑止する統制

まず押さえる要点

社内FAQボットを 使われる状態 にする要点は、次の3つです。

  1. 「回答の根拠」を明確にする:どの規程・どのページを参照したかを示せる設計にする
  2. 「守備範囲」を絞る:最初から全部門の質問を受けない
  3. 「統制」を先に決める:誰が作る/公開する/更新するか、データはどこまで扱うか

Copilot Studioは配布が簡単なぶん、統制が弱いと"野良ボット"が増えがちです。DLPや権限、公開プロセスを最初に設計すると手戻りが減ります。

似た選択肢との比較

Copilot Studio(推奨:社内FAQの入口をTeamsに置きたい)

  • 長所:Teams配布・管理・分析が一体で、ローコードで運用しやすい
  • 注意:権限設計・DLP・同意(Consent)など、IT統制を無視すると事故が起きやすい

汎用チャットAI(個人利用中心:ChatGPT等)

  • 長所:すぐ使える、自由度が高い
  • 注意:社内の配布/更新/監査の仕組みを自力で整える必要があり、組織運用には設計が要る

フルスクラッチのBot開発(推奨:複雑な要件・独自UIが必須)

  • 長所:要件に合わせて作り込める
  • 注意:初期開発と保守運用のコストが大きい

準備(必要なアカウント/料金プラン/権限/注意点)

ライセンスと利用開始条件(必ず公式で確認)

Copilot Studioの利用には、管理者が割り当てるライセンスや、Copilot Credits(クレジット)に関する前提条件があります。プランや条件は更新されることがあるため、導入判断の前に必ず公式ドキュメントを確認してください。

権限(最低限)

  • 作成者(Maker):エージェントを作成・編集できる人
  • 管理者(Admin):環境、DLP、アクセス管理など統制を担う人

環境やデータポリシーはPower Platform管理側の設計が関与するため、情シス(またはPower Platform管理者)を巻き込むのが安全です。

TeamsとSharePointの前提

  • Teams:Copilot Studioのエージェントは、公開後にTeamsへ追加・配布できます
  • SharePoint:生成的回答で参照するURL(サイト/ライブラリ)を決めます。参照権限がないと回答品質が落ちるため、「誰が読むべきか」を先に設計します

手順:Teamsで社内FAQボットを作って配布する(コピペ例つき)

以下は「経費精算・出張申請」など、社内の定型質問が多い領域を例にします。

Step 0:スコープを決める(最重要)

最初は 1部門・20質問程度を目標にしてください。対象ドキュメント(SharePointのURL)も、最初は1サイト に絞るのが無難です。

Step 1:Copilot Studioで新規エージェントを作成

Copilot Studioを開き、社内FAQ用のエージェントを新規作成します。名前は「経費・出張FAQ(試験)」のように、用途と段階(検証/本番)が分かる命名がおすすめです。

Step 2:初期メッセージ(挨拶)を用意する

ユーザーが最初に迷わないように「できること」と「できないこと」を明記します。

コピペ例(挨拶メッセージ)

こんにちは。経費・出張に関する社内FAQボットです。

できること:
- 経費精算・出張申請の手順、申請期限、必要書類の案内
- 規程(SharePoint)に基づく要点の整理

できないこと:
- 規程に記載のない判断(例外承認の可否など)
- 個人情報や機密情報の入力を前提にした対応

回答の最後に、参照した規程ページ(URL)を案内します。

Step 3:代表的なFAQを「トピック」として作る

最初から生成的回答に頼り切るより、頻出の質問はトピックで"型"を作ると安定します。

例:トピック候補

  • 「経費精算の締め日はいつ?」
  • 「領収書がない場合の扱いは?」
  • 「出張申請の承認フローは?」

コピペ例(不足情報の聞き返しテンプレ)

確認させてください。どちらのケースに近いですか?

1) 国内出張 / 2) 海外出張
3) 立替払いあり / 4) 会社カード利用

番号で回答してください。該当する規程の範囲で案内します。

Step 4:SharePointを知識ソースにして「生成的回答」を使う

生成的回答では、SharePointのURLを知識ソースとして指定し、質問に応じて検索・要約する動きができます。

設計のコツ

  • URLは「規程サイト」など、権威ある一次情報に寄せる
  • 対象を広げすぎない("サイト全体"はノイズが増えやすい)
  • 回答には「根拠(参照先)」を必ず付ける運用にする

Step 5:テスト(想定質問で品質確認)

テストでは、次を確認します。

  • 規程に沿った回答になっているか
  • 「分からない」「担当に確認してほしい」と言えるか(断定しないか)
  • 参照先URLが期待どおりか

Step 6:公開(Publish)してTeamsに配布する

エージェントを公開し、Teamsへ追加して配布します。

運用の推奨

  • まず検証用チーム(テスト用Teams)で社内パイロット
  • 問い合わせが多い1部門でKPI(削減時間、一次回答率)を見てから拡大

Step 7:分析と改善(ログの見方を決める)

どの質問が多いか、回答が役に立ったかを見て、トピック追加や知識ソースの整備につなげます。改善サイクルは「よく聞かれるのに答えられていない質問」を優先すると効果が出やすいです。

ビジネスでの具体例(職種別)

情シス/ヘルプデスク

  • 「パスワードリセット」「端末紛失時の初動」「VPN接続」などの一次対応をボットに寄せる
  • ルール変更時はSharePointの手順書を更新し、ボットはそれを参照して案内する(更新の一元化)

人事/総務

  • 「慶弔・休暇・在宅勤務」「福利厚生」「年末調整の提出物」など、時期により質問が急増する領域で活用
  • "例外判断"は人が対応し、ボットは規程の範囲で案内に徹する(断定を避ける)

営業企画/営業オペレーション

  • 「値引き申請」「見積テンプレ」「CRM入力ルール」など、手順とルールが中心の問い合わせに強い
  • 参照元を営業向けの正式ドキュメントに固定し、口頭ルールの混入を防ぐ

よくある失敗と回避策

1. 回答が"それっぽい"が誤っている

  • 原因:知識ソースが古い/複数あり矛盾している
  • 対策:一次情報(最新の規程・手順)に寄せ、更新元を一本化する

2. 参照範囲が広すぎてノイズが増える

  • 原因:SharePointの上位URLを丸ごと指定
  • 対策:対象サイト/ライブラリを絞る(まずは1サイト)

3. 共有したのに、部署によっては回答できない

  • 原因:参照権限が無い、または閲覧者がバラバラ
  • 対策:Teams配布範囲とSharePoint権限をセットで設計する

4. いきなり社内に無秩序にボットが増える

  • 原因:作成者が多く、公開ルールが無い
  • 対策:環境分離、承認フロー、DLPで"作れる範囲"を統制する

セキュリティ/コンプライアンス観点(社内利用の注意)

1) DLPでコネクタとデータ流出経路を制御する

Power PlatformのDLPポリシーで、利用可能なコネクタやデータ移動の組み合わせを制御できます。特に「外部サービスへデータが出る経路」を先に塞ぐのが基本です。

2) 同意(Consent)を軽視しない(OAuth同意フィッシングの観点)

近年、OAuthの同意画面を悪用するフィッシングが報告されています。研究者により、Copilot Studioのエージェントを"見た目は正規"に見せたまま、同意操作へ誘導する手口(いわゆるOAuth同意フィッシング)が指摘されています。

実務的な対策(最低限)

  • ユーザーのアプリ同意を制限/無効化し、管理者承認フローを整備する
  • "ログインを促すボタン"や外部URLへの誘導は、社内ボットでは原則禁止(例外はセキュリティ審査)
  • 管理対象の環境でのみ作成・公開させ、野良エージェントの流通を抑止する

3) 個人情報・機密情報の入力を前提にしない

社内FAQの第一段階では「規程や手順の案内」に用途を絞り、個人情報・機密情報を入力させない設計にします。必要な場合は、社内規程(データ分類・保管・ログ)に沿って別途審査してください。

FAQ

Q1. Copilot Studioは無料で使えますか?

ライセンスやクレジットの前提条件があります。導入判断は、必ず公式のライセンス/課金ドキュメントを確認してください。

Q2. Teamsに配布すると、誰でも勝手に使えますか?

配布範囲(Teams/アプリ)と、参照するSharePoint権限が揃っていないと"使える人/使えない人"が混在します。設計段階で対象ユーザーと権限をセットで定義してください。

Q3. 生成的回答は、必ず根拠(参照先)を出せますか?

機能としての挙動は公式情報を確認してください。実務としては「参照先URLを案内する」ルールを徹底し、挨拶メッセージや回答テンプレで誘導するのが安全です。

Q4. "間違った回答"をゼロにできますか?

ゼロは現実的ではありません。だからこそ、(a)スコープを絞る、(b)一次情報に寄せる、(c)断定しない返答設計、(d)問い合わせ導線(人に繋ぐ)を用意、の4点でリスクを下げます。

まとめ(次のアクション)

Copilot Studioで社内FAQボットを作る価値は、「Teamsという入口に、一次情報を参照する窓口を置ける」点にあります。一方で、拡散しやすいからこそ 最初に統制を決めるのが成功の分かれ目です。次のアクション(おすすめ順)

  1. 1部門・20質問・1つのSharePointサイトにスコープを限定して試作
  2. Teamsの検証チームでパイロット配布し、よくある質問を収集
  3. DLPと同意(Consent)の方針を確定し、本番環境・公開プロセスを整備
  4. 運用(更新責任者、改訂頻度、FAQ棚卸し)を回しながら拡大

参考(公式・一次情報中心)

※本記事は一般的な情報提供であり、法務・監査の個別助言ではありません。最終判断は社内ルールおよび専門家にご確認ください。