Copilot Studio で Microsoft Teams にノーコードの IT ヘルプデスクエージェントを作る方法

要点：Microsoft Copilot Studio を使えば、開発者でなくても、繰り返し寄せられる IT の質問に Microsoft Teams の中で直接答えるエージェントを作れます。回答の根拠は SharePoint 上のナレッジソースです。「VPN にどうつなぐのか」という層の量は確実に吸収できます。ただし障害の切り分けはできず、人への引き継ぎは後付けではなく初日に作り込む必要があります。

120 人規模の会社の IT マネージャーが月曜の朝に Teams を開くと、ダイレクトメッセージが 11 件。うち 4 件は「自宅から VPN にどうつなぐか」という同じ質問。2 件は新入社員からの経費精算システムの場所の問い合わせ。1 件はプリンター。1 件はゲスト Wi-Fi のパスワード。残り 3 件が本当の問題です。

その 3 件こそが仕事です。残りの 8 件は「中断税」——1 件あたり 30 秒でも、合計すれば 1 日 1 時間のコンテキストスイッチであり、しかもそれが、本当の問題も解ける社内でただ一人の人間に集中します。

Microsoft Copilot Studio はまさにこの隙間を狙っており、その売り文句は「開発者は要らない」です。この売り文句はおおむね正しく、ただし具体的で重要な天井があります。

なぜ同じ 5 つの IT の質問が毎日あなたを中断させるのか

「IT 役を担っている人」に届いた過去 1 か月分の Teams の DM を眺めると、形はいつも同じです。ごく少数の質問が量の大半を占め、それらには安定した正しい答えがあり、そして別々の人から予測できないタイミングで届きます。この組み合わせがコストを生みます——四半期に 1 度の質問は自動化に値しませんが、週に 4 回来て、答えは既に書かれていて変わらない質問は、値します。

ドキュメントで解決しない理由は「質問がどこで起きるか」にあります。火曜の朝 8 時 40 分、Teams の中で、会議に向かう途中に VPN のプロンプトにぶつかる。イントラネットを開き、検索を探し、クエリを組み立てるのは、「この人なら返してくれる」と分かっている相手に「VPN どうやってつなぐんでしたっけ」と打つより手間なのです。だから毎回そうします——つまり、これを直すものは何であれ、質問が既に発せられているその場所で答えなければなりません。M365 の会社なら、それは Teams です。

Copilot Studio でコードを書かずに実際に作れるもの

Copilot Studio は、会話型エージェントを構築するためのマイクロソフトのローコード環境です。ビジュアルなキャンバス上で作業し、振る舞いを自然言語で記述し、何を根拠に答えるべきかを指定して公開します。公開先には Microsoft Teams が含まれ、そこでは社員が人に話しかけるように会話できる存在として現れます。

具体的な機能、コネクタの一覧、ライセンス体系は製品の進化に伴って変わります。特定の機能に業務フローを賭ける前に、マイクロソフトの最新ドキュメントで現状を確認してください。この記事が扱うのは構築の「形」であり、賞味期限のある機能一覧ではありません。

トピック、トリガー、そして本物のナレッジソースにつなぐこと

仕事の大半は 2 つの仕組みが担います。

トピックは、あなたが定義する会話フローです。トリガーとなる言い回しの集合と、エージェントがそれを認識したときに何をするか。「パスワードをリセットしたい」「パスワードを忘れた」「アカウントがロックされた」を、すべて同じスクリプト化された応答へ導けます。その中には実際のリセットリンクと実際のポリシーが入ります。この部分は決定論的です——答えを書いたのはあなたなので、何を言うか正確に分かっています。

ナレッジソースは、スクリプト化しなかったすべてを引き受けます。エージェントにコンテンツ——SharePoint サイト、アップロードした文書、指定した Web ページ——を指し示すと、一般知識ではなくその素材から回答を生成します。これが構築を現実的にします。すべての質問のすべての言い回しを先回りする必要はありません。あなたが既に維持している IT ポリシーのページが、そのまま回答集になるからです。

どこで人に引き継ぐか——そしてなぜその引き継ぎが初日から必要なのか

最初に作るべき最も重要なものは、出口です。

「分かりません、チケットを起票します」と言えないエージェントは必ず推測します。そして会社の名前を背負ったツールが自信満々に出す誤答は、ツールが無い場合よりも大きな害をもたらします。社員は、社内の Teams に現れるものを、Web サイトのチャットボットよりはるかに強く信頼します。そしてその信頼は一度しか使えません。

回答より先にエスカレーション経路を作ってください。どの会話にも、人に届く見える道が要ります——常時表示される「担当者と話す」の選択肢、質問を照合できなかったときの自動引き継ぎ、そして会話を一緒に持っていくチケット。受け取った人がゼロから始めずに済むように。ServiceNow、ServiceDesk Plus、Jira などでサービスデスクを運用しているなら、引き継ぎ先はそこであるべきです。

実践的な構築手順——繰り返し質問のリストから動く Teams エージェントまで

これは再現可能な手順であり、全体としてプロジェクトではなく数回の午後で終わる作業です。

1. 何かを作る前に、まず質問を数える。過去 1 か月の IT 関連の Teams DM とメールを見返して集計します。記憶からではなく、実際に数えてください。探しているのは、3 回以上尋ねられ、かつ答えが安定している質問です。たいていの会社で 5〜8 個見つかります。そのリストがスコープであり、この集計は後で比べるためのベースラインにもなります。

2. 答えは「ポリシー」ではなく「答え」として書く。各質問について、同僚に実際に返信するであろう文面を書きます。「社内ポータルアプリを開いて、VPN の下の［接続］を押し、スマホの MFA を承認してください」——「リモートアクセスはアクセス制御ポリシーに従って払い出されます」ではなく。1 か所にまとめ、1 質問 1 見出しで。この文書がエージェントの品質のすべてです。

3. その文書を、エージェントが読めてあなたが編集できる場所に置く。IT サイト配下の SharePoint ページやドキュメントライブラリ 1 つで十分です。要点は、後で答えを更新する作業が「ページの編集」であって「構築ツールを開き直すこと」ではない、という点です。これがエージェントを 6 週間で陳腐化させないための仕掛けです。

4. エージェントを作成し、そのソースを指定する。Copilot Studio で新しいエージェントを作り、役割を平易な言葉で指示します——承認済みの IT ナレッジソースに基づいて社員の社内 IT の質問に答え、自信が無いときは人に引き継ぐ——そして SharePoint の場所をナレッジソースとして追加します。そのソースに対してエージェントがどう認証するかを確認してください。それが、読める範囲に誰の権限が適用されるかを決めます。

5. 量の多い上位 2〜3 問を明示的なトピックとして書く。VPN のもの、パスワードのもの、リストの一番上にあるもの。これらは毎回一字一句正しくあってほしい答えで、正確なリンクも含みます。残りはナレッジソースに任せて構いません。

6. エスカレーション用のトピックを作る。「担当者と話す」のトリガー、照合できなかった質問のためのフォールバック、そして会話の記録を添えてチケットシステムへ渡す経路。

7. 実際の質問で、人が実際に打つ言い回しでテストする。「VPN 接続を確立するにはどうすればよいですか？」ではなく、「vpn つながらない」「vpn 入れない」「在宅 vpn??」。整った質問しか扱えないエージェントは、現実に触れた瞬間に失敗します。

8. まず少人数のパイロットに向けて Teams に公開する——5〜10 人、できれば「いつも質問してくる人」を 1 人入れて。2 週間動かし、サマリー指標ではなく会話そのものをすべて読みます。ここで、よくある質問だと気づいていなかった 2 つと、静かに間違っていた 1 つの答えが見つかります。

9. その後に展開し、毎月ログを読み続ける。照合できなかった質問が次に何を足すべきかのキューであり、誰も見返さないエージェントは、静かに古びていくエージェントです。

自作の Copilot Studio エージェント vs 有人ヘルプデスク vs 開発者が作るボット

• 自作の Copilot Studio エージェント。開始コストが最も低く、開発者不要で、質問が既に発生している Teams の中にネイティブに存在します。既知で、文書化されていて、安定している質問はよく処理します。限界は本物です。障害の切り分けはせず、明示的に接続したもの以外あなたのシステムを操作できず、品質の上限は背後の文書の品質そのものです。誰かが責任を持つ用意のある会社での、一次情報系の量に最適です。
• 有人ヘルプデスク。エージェントが答えられなかったものに答えます——診断、判断、アカウント変更、あるいは「それはセキュリティインシデントか」の見極めを要するもの。あなたが何も書かなくてもスケールし、あなたがカバーしない時間帯を埋め、単に答えるだけでなく解決に責任を負います。コストは契約と、ユーザー単位またはチケット単位の料金です。本当に減らしたい量が「切り分けの量」であるときに正解になります。
• 開発者がモデル API 上に作るボット。柔軟性は最大——任意の連携、独自ロジック、記述できる振る舞いは何でも。同時に保有コストも最大です。誰かが作り、ホストし、守り、保守し、来年もそこにいる必要があります。要件が既製プラットフォームに本当に収まらないときに正解です。この道筋はSlack で Claude を使って IT ヘルプデスクボットを作るで詳しく書きました。

M365 ベースの中堅中小企業にとって正直な答えは、1 つ目 + 2 つ目です。エージェントが繰り返しの情報系の量——チケット「件数」の大半でありながら難易度のほとんどを占めない部分——を吸収し、有人デスクが残りを引き受けます。そちらが元々の本当の仕事でした。

ノーコードのエージェントが行き止まる場所

答えはするが、診断はしない。「PC が遅い」に文書化された答えはありません——答えに到達するには、判断を含む往復が要ります。エージェントは一般論を返し、まずユーザーの時間を、次にあなたの時間を浪費します。

接続していない限り何も変更できず、その接続こそがリスクの所在。ポリシーのページを読むのは低リスクです。パスワードのリセット、グループへの追加、アカウントのロック解除は特権操作であり、それを会話型エージェントに配線するのはノーコードの作業ではなくセキュリティ設計の判断です。「開発者は不要」という枠組みが十分でなくなるのは、まさにここです。

深刻度の感覚が無い。「見覚えのないファイルにマクロを有効にしろと言われた」と報告するユーザーに必要なのは、ナレッジベースの回答ではなく即座の人間です。エージェントは不便とインシデントを区別しません。あなたのエスカレーションのロジックが区別しなければ、本物のセキュリティ事象にチャットボットが返答することになります。

知識はあなたの文書の質そのものであり、文書は腐る。3 月には正しかった VPN の答えは、9 月のクライアント更新で誤りになります。どちらであろうとエージェントは同じ自信で答え続けます。この文書のオーナーシップこそが、これを回す本当の継続コストです。

ここを外さない——データソースの権限、ライセンス、そしていつ IT を呼ぶか

ナレッジソースの権限は、何よりも先に正すべきもの。エージェントが SharePoint にどう認証するかが、尋ねたユーザー自身のアクセス権に従うのか、より広い権限で読むのかを決めます。仮定せず、低権限アカウントで明示的に検証してください。そして隣接する問題も意識してください。SharePoint の権限が既に緩いなら、それを検索できるエージェントは既存の共有過多に極端に出くわしやすくします——これは先に直すべき既往症であり、Copilot 展開に向けた Microsoft 365 テナントの準備に書きました。

展開を計画する前に——パイロットの後ではなく——ライセンスを確認する。Copilot Studio のライセンスと容量のモデルは Microsoft 365 のライセンス数とは別立てで、複数回改定されています。全社展開を決める前に、現行モデルと、想定メッセージ量が実際にいくらになるかを確認してください。パイロットが止まる最も一般的な原因がこれです。

Power Platform のガバナンスを適用する。データ損失防止ポリシー、環境戦略、そしてテナント内で誰がエージェントを作成・公開してよいか。これが無いと「開発者不要」は、部署ごとに作られ、それぞれ別の文書を指し、別の答えを返す、管理されないエージェント群になります。

作る前に誰が所有するかを決める。オーナーのいないエージェントは、親しみやすい UI を持った負債です。

方式の選定、エスカレーションのロジック設計、エージェントに何を触らせてよいかの審査は AI+ サポートの仕事です——構築そのものよりレディネス評価が重要です。その下のテナント衛生、SharePoint の権限、日々の保守は通常のマネージド IT サポートです。そしてエージェントが引き継ぐとき、引き継ぎ先が実在している必要があります。当社の 24×7 多言語ヘルプデスクは ITIL ベースのデスクで、エージェントが閉じられないチケットを英語・北京語・広東語で引き受け、ServiceNow、ServiceDesk Plus、Jira と連携します。

よくある質問

本当に開発者は不要ですか？

ここで説明した構築——SharePoint のソースから文書化された質問に答え、Teams に公開し、引き継ぎを備えたエージェント——であれば、本当に不要です。変わるのは、エージェントに*操作させたい*ときです。パスワードのリセット、グループメンバーの変更、アカウントの作成。これらにはコネクタ、権限設計、セキュリティレビューが要り、その時点で、コードの量に関係なく、それを専門にやっている人が必要になります。

Copilot Studio にはどの Microsoft 365 ライセンスが必要ですか？

Copilot Studio のライセンスは標準の Microsoft 365 ライセンスとは別立てで、そのモデル——容量、メッセージパック、他の Copilot ライセンスとの抱き合わせ——は複数回改定されています。マイクロソフトの現行ライセンスページを確認し、パイロットの後ではなく展開の前に、想定メッセージ量の価格を見積もってください。コストは人数ではなく利用量に比例するからです。

ユーザーがアクセスできないはずのファイルをエージェントが見てしまうことはありますか？

それはナレッジソースへの認証をどう設定したかに完全に依存します。だからこそ最初に検証すべきなのです。意図的に低権限のアカウントでテストし、そのアカウントが直接開けないものをエージェントが提示しないことを確認してください。加えて、SharePoint の権限が既に広すぎるなら、それが可視化されるのがこの瞬間です。エージェントの口の堅さに頼るのではなく、権限を直してください。

誤った回答をしていることに、どうやって気づきますか？

ログを読むことで、特に最初の 1 か月は。指標が教えるのは量と自己解決率であって、「クライアント更新以降 VPN の答えがずっと誤っている」ことは教えてくれません。誰かが会話のサンプルと未照合の質問すべてを読む月次レビューを設定してください。あわせて、チャットの中で「それは違う」と言える分かりやすい手段を社員に与え、その報告を最も価値の高いシグナルとして扱ってください。

Slack で Claude や ChatGPT を使って IT ボットを作るのと何が違いますか？

ツール、プラットフォーム、そして作る人が違います。開発者がモデル API 上に作るボットはより柔軟ですが、作って生かし続ける開発者が要ります。Teams の Copilot Studio は IT マネージャーがコードを書かずに使えるキャンバスで、代償はプラットフォームが対応する範囲内で作ること——そして既に M365 の会社なら、社員は何もインストールせず何も学ばずに使えます。