社内のIT問い合わせをチャットで一次対応する

処理の起点を決める

社員が Teams でエージェントに話しかけたことが起点です。定時実行やメール監視ではありません。

Copilot Studio で作ったエージェントは Teams に公開できます。公開すると、生成的回答の呼び出しはエージェントと会話しているユーザー本人の資格で実行されます。認証は既定で「Microsoft で認証する」が設定されており、Teams、Power Apps、Microsoft 365 Copilot で動きます。

重要な制約があります。 SharePoint をナレッジソースにした生成的回答は、Teams の1対1チャットで利用できます。グループチャットとチャネルの投稿ではまだ利用できません。「部署のチャネルに置いて全員で使う」構成は成り立ちません。 1人ずつのチャットで使う前提で設計してください。

入力データを集める

社員名簿や資産管理台帳を自動で引くことは、最初の構成には入れません。連携先が増えるほど権限設計が複雑になります。

データの取得方法を決める

手順書： Copilot Studio の「知識を追加」から SharePoint を選び、サイトまたはフォルダのURLを登録します。登録したURLとその下位パスが検索対象になります。親フォルダ、兄弟フォルダ、別サイトは、個別に登録しない限り検索されません。 例えば contoso.sharepoint.com/sites を登録すると contoso.sharepoint.com/sites/policies も含まれます。

社内FAQ： SharePoint リストをナレッジソースとして追加すると、リストへのリアルタイム接続になり、常に最新のデータが参照されます。1度に選べるのは10個までで、10個以内に収めることが推奨されています。1つのリストが35,000行を超えると、回答品質と応答時間に影響します。

古い文書を除く： ナレッジソースの詳細設定で、タイトル、作成者、更新者、更新日で絞り込み条件を作れます。「更新日が指定日以降」という条件を入れておくと、廃止された手順書を参照させずに済みます。

AIへ渡す前に整形する

1. 手順書の置き場所を1か所にまとめる … 複数サイトに散っているとURLを個別に登録する必要があります。エージェント用のサイトを作り、そこに集約するのが確実です
2. 文書内のリンクを本文に展開する … 登録した文書に含まれるハイパーリンクは辿られません。 「詳細は別紙参照」と書いてある手順書は、参照先を独立したナレッジソースとして登録するか、本文に内容を書き足します
3. 暗号化された文書を外す … 暗号化を伴う秘密度ラベル、Double Key Encryption、パスワード保護されたファイルは、権限があっても内容を読み取れず「回答なし」になります。対象から外し、平文で置き直します
4. 廃止された手順書を消す … 古い手順を回答されるのが最悪の事故です。改訂履歴のない手順書は、この機会に一度棚卸しします

AIに処理させる

障害の原因を推定させることはしません。 手順書に書かれていることを案内する役割に限定します。

指示内容を固定する

Copilot Studio のエージェントの指示（instructions）に、次のような内容を書きます。

あなたは社内の情報システム部のヘルプデスク担当です。
社員からのIT問い合わせに、登録された手順書とFAQだけを根拠に回答してください。

【厳守事項】
- 登録されたナレッジソースに書かれていないことは答えないでください。
  一般的なIT知識やインターネット上の情報で補わないでください。
  該当する記載がない場合は「手順書に記載がないため担当者へ引き継ぎます」と返してください。
- 回答には必ず参照した文書のリンクを付けてください。
- パスワードや認証コードを聞き出さないでください。
  社員が入力しようとした場合は止めてください。
- 端末やシステムの設定変更を、社員に代わって実行しないでください。
  手順を案内するだけにしてください。
- チケットを起票する前に、次の項目が埋まっているか確認してください。
  端末名／OSのバージョン／発生した日時／エラーメッセージ／すでに試したこと
- 障害の原因を推測して伝えないでください。

「一般的なIT知識で補わない」の1行が要点です。 これを外すと、自社の設定と違う一般論を回答してしまいます。エージェント側でも、Web検索と「一般知識を使用する」の設定を無効にします。トピック単位の生成的回答ノードにも同じ設定があるため、両方を切ってください。これらを切ると、絞り込んだナレッジソースに答えがない場合に「回答なし」が返るようになります。

出力形式を固定する

会話の回答は自然文ですが、チケット起票へ渡す部分は項目を固定します。

{
  "category": "パスワード | ネットワーク | 端末 | プリンタ | 権限申請 | ライセンス | その他",
  "summary": "",
  "device_name": "",
  "os_version": "",
  "occurred_at": "",
  "error_message": "",
  "steps_tried": [],
  "answered_by_ai": true,
  "escalation_reason": "",
  "referenced_documents": []
}

answered_by_ai と escalation_reason を必ず残します。これが「何が答えられていないか」の一覧になり、手順書を足す優先順位になります。

システムへ連携する

チケット起票は、Copilot Studio からエージェントフローを呼び出して行います。フローを呼べるようにするには、次の条件をすべて満たす必要があります。

条件を満たしたフローを、エージェント全体のツールとして、またはトピック単位のツールとして追加します。追加時の説明文は、エージェントがいつ呼ぶかを判断する材料になるため、具体的に書いてください。

チケット管理システムへの登録方法は製品によって異なります。この部分は利用環境に応じた個別確認が必要です。

人が確認する

回答は人が確認しません。チケット対応は人が行います。

回答を全件確認する構成では、情シスの工数が減りません。ここで確認を挟まずに済む理由は3つです。

• 回答の根拠が、情シス自身が書いた手順書に限定されている
• 出典リンクが付いており、社員が原文を確認できる
• 設定変更をAIが実行せず、案内するだけである

ただし、次は人が対応します。

• 手順書に答えがない問い合わせ（チケットとして情シスへ）
• 権限の付与、ライセンスの割り当て、アカウントのロック解除などの実行を伴うもの
• 障害の切り分けと復旧

公開直後の2週間は、回答された会話を全件読んでください。 誤った案内が出ていないかを見るためです。件数が読める量のうちに見ておかないと、あとから遡れません。

例外に対処する

記録を残す

• 質問と回答（会話の記録）
• 参照された文書
• answered_by_ai と escalation_reason
• チケットに起票された内容と、その後の対応結果

SharePoint をナレッジソースにした場合、会話の記録には参照した文書の中身（search_results）が含まれません。 質問と回答は記録されます。「どの文書を根拠にしたか」を後から追う必要があるなら、回答に付く出典リンクを別途記録する設計にしてください。

回答できなかった質問の一覧が、手順書の不足リストになります。月次でこれを見て、多いものから手順書を足していく運用が、この構成の本体です。