2026.09.08 DX

チャットボットでヘルプデスクを一次受けする設計｜振り分け・FAQ整備・有人引き継ぎの実装判断

ヘルプデスクの一次受けをチャットボットに任せると決めたあと、実際に手が止まるのは「どの問い合わせを載せるか」「FAQをどう書き直すか」「答えられなかった質問を誰にどう渡すか」の三点です。ツールを選んで質問文を登録しただけのボットは、少し違う聞き方をされると答えられず、利用者が二度と使わなくなります。この記事では、社内ヘルプデスクにチャットボットを組み込む工程を、対象範囲の切り分け、回答粒度の設計、TeamsやSlackへの組み込み方式、有人エスカレーションで受け渡すコンテキスト、運用KPIと改善サイクルまで、設計の順序に沿って整理します。そもそも導入すべきかどうかの判断からたどりたい場合はAIヘルプデスクの導入判断と有人対応の線引きを整理した記事を、ヘルプデスクという業務そのものの範囲はヘルプデスクとは何かを解説した記事を先にご覧ください。

まとめ｜ヘルプデスクにチャットボットを置くときの一次受け設計の要点

チャットボットによる一次受けの成否は、ボットの賢さではなく、その手前の三つの設計で決まります。第一に対象範囲で、回答が文書に存在し担当者の判断を挟まない問い合わせだけを載せます。回答が状況によって変わる質問を無理に載せると、誤回答の火消しで担当者の手間が増えかねません。第二にFAQの回答粒度で、一つの質問に一つの答えが対応する形まで分解しておかないと、参照元が長文のままでは正しい箇所を引けません。第三に有人への引き継ぎで、会話履歴と直前に踏んだトピックを担当者へ渡す経路を作らないと、利用者は同じ説明を二度させられます。

設計の順序としては、問い合わせログの集計、上位質問の1問1答化、置き場所となるチャネルの決定、エスカレーション経路の実装、KPIの定義という並びになります。ここで先にツールを選ぼうとすると、要件が定まらないまま製品の機能表を眺めることになりがちです。運用開始後は、解決・エスカレーション・放棄というセッションの結果別に数字を追い、放棄された会話のログをFAQへ戻す循環を回します。この循環が止まったチャットボットは、公開直後の精度のまま古びていく一方です。以降の章では、この各工程で何を決めるのかを順に見ていきます。

ヘルプデスクにチャットボットを置く前に決める対象範囲の切り分け

最初の工程は、寄せられている問い合わせのうち、どこまでをボットに載せるかを線引きすることです。ここを曖昧にしたまま進めると、精度の議論が延々と終わりません。

問い合わせログから一次受けに載せる質問と有人に残す質問を分ける

直近1〜3か月分の問い合わせ履歴を集計し、件数の多い順に並べます。社内ヘルプデスクの問い合わせは上位の数十パターンに偏る傾向があり、その偏りの度合いがそのまま自動化の効き幅になります。並べたら、次の基準で機械的に振り分けてください。

回答が手順書やFAQに文書として存在し、誰が答えても同じ内容になる質問（ボットに載せる）
回答は決まっているが、利用者の権限や契約状況で分岐する質問（条件を聞き返す設計にすれば載せられる）
原因調査が要るトラブル、個別契約の解釈、金額の確定回答（有人に残す）
誤った回答が金銭・契約・セキュリティに直結する質問（有人に残す）

この振り分けは、後述するエスカレーションの条件設計とそのまま対になります。「載せない」と決めた質問こそ、ボットが受けたときに即座に人へ渡す対象だからです。効率化の施策としてどこから着手するかという優先順位づけの考え方は、ヘルプデスク効率化の着手順序を整理した記事が土台になります。

社外向けチャットボットとの違いと社内ヘルプデスクに特有の前提条件

社内ヘルプデスクのボットは、社外向けの問い合わせ窓口とは前提が違います。利用者が全員社員である以上、認証済みの状態で会話が始まり、所属部署や利用端末といった属性を最初から持てるのが大きな差です。この属性を使えば、同じ「経費精算のやり方」という質問に対して、部署ごとに異なる申請フローを出し分けられます。一方で、社内ならではの難しさもあるのが実際のところです。利用者は正式名称ではなく社内でしか通じない略称や旧システム名で質問してくるため、辞書を用意しないと検索が空振りします。

もう一つの違いは、失敗の許容度です。社外向けであれば答えられなかった質問は問い合わせフォームに逃がせば済みますが、社内では「使えないボット」という評判が数日で広まり、利用者が直接チャットで担当者を呼ぶ元の運用に戻ります。最初の公開範囲を一部門に絞り、上位質問の回答精度を確かめてから広げる進め方が現実的です。応答方式そのものの違い（シナリオ型と生成AI型の差）を技術面から確認したい場合は、AIチャットボットの仕組みと方式の違いを解説した記事を参照してください。

チャットボットが答えられるFAQ・ナレッジの整備と回答粒度の設計

参照元の質は、回答精度に直結します。生成AIを用いる構成でも、根拠となる文書が読みにくければ引用箇所を誤ります。ここでの作業は、既存のマニュアルをそのまま食わせることではなく、書き直しです。

回答が一意に決まる粒度までFAQを分解して参照元に登録する手順

社内マニュアルは、章立てされた長文で書かれていることがほとんどです。この形のまま参照元に登録すると、ボットは長い章の一部を切り出して返し、前提条件の記述を落とします。避けるには、一つの質問に一つの答えが対応する形まで分解します。目安として、次の状態を満たすように書き直してください。

観点	登録前によくある状態	書き直した後の状態
単位	「経費精算マニュアル」1本	「交通費を申請する手順」など質問単位
前提	本文冒頭にまとめて記載	各回答の中に対象者・条件を明記
回答の長さ	数千字の章	200〜400字で完結
参照先	「詳細は別紙参照」	該当ページのURLを回答内に記載

分解の順序は、前章で作った件数順のリストに従います。上位20件から着手し、それが片付いたら次の20件へ進む形が、工数の見通しを立てやすい進め方です。FAQを蓄積する器そのものの選び方や作り方は社内FAQシステムの作り方と選び方を整理した記事で、生成AIに参照させる構成の考え方はAIを組み込んだFAQシステムの記事で補完できます。

表記揺れ・略語・部署固有語を吸収する辞書と並記の仕組みを用意する

社内の質問文には、正式名称がほとんど出てきません。「勤怠」と「就業システム」、「VPN」と「リモート接続」、旧称のまま呼ばれ続けているシステム名などが混在します。この揺れを吸収する手段は二つあります。一つは同義語辞書を持ち、質問文を正規化してから検索する方法です。もう一つは、FAQ側の質問文に呼ばれ方のバリエーションを並記しておく方法で、辞書を持たない構成でも効果があります。

どちらを採るにせよ、揺れの一覧は机上では作れません。公開後に実際の質問文を眺め、拾えなかった語を足していく前提で設計します。ここで蓄積した表記の対応関係は、ボットの外でも使える資産になり、社内検索や新任担当者の教育にも効いてくるはずです。組織としてのナレッジの貯め方という枠組みで捉え直すなら、ナレッジマネジメントの進め方を解説した記事の考え方と接続します。

TeamsやSlackなど社内チャネルへのチャットボット組み込み方式の選択

どれだけ回答精度を上げても、利用者がボットの置き場所まで移動しなければ使われません。社員が普段いる場所に置くのが原則で、多くの企業ではビジネスチャットがその場所になります。

ネイティブチャネルへの公開とAPI経由でのカスタム組み込みの使い分け

組み込みには、製品が用意した公開先へそのまま出す方法と、APIで自社のアプリケーションに埋め込む方法があります。Microsoft Copilot Studioを例にとると、TeamsやMicrosoft 365 Copilot、SharePoint、Power Pagesにはネイティブに配置でき、これらにはチャットの表示部分があらかじめ組み込まれています。対して自社Webアプリや独自の社内ポータルへ載せる場合はDirect Line APIを用い、表示部分は自前で選ぶ必要があります（Microsoft Learn「エージェントをチャネルやクライアントに公開する」・2026年9月時点）。同ドキュメントは、Direct Line APIがHTTP GETによる取得とWebSocketによるリアルタイム配信の双方に対応する点、チャネルやクライアントによってはMarkdownやアダプティブカードといった表示形式に対応しない場合がある点にも触れています。

判断としては、既にTeamsが全社利用されているならネイティブ配置を選び、開発を挟まないのが早道です。カスタム組み込みが要るのは、基幹システムの画面内から呼び出したい、社外の顧客向け画面と共用したい、といった要件が先にある場合に限られます。

Slackに載せる場合に押さえる応答時間・再送・スコープの技術要件

Slackを社内の主要チャネルにしている企業では、Slackアプリとしてボットを実装します。Slack公式ドキュメントによれば、Events APIはプッシュ型で、指定したリクエストURLへイベントがHTTP POSTで送られます。受け側は3秒以内にHTTP 200を返す必要があり、応答が無い場合は即時・1分後・5分後の最大3回まで再送される仕様です。また、受け取りたいイベントに対応するOAuthスコープの付与が要り、ワークスペースとアプリの組み合わせあたり60分間で30,000イベントという上限が設けられています（Slack Developer Docs「Events API」・2026年9月時点）。

実装上の含意は明確で、生成AIの応答を待ってから返すと3秒に間に合いません。受信を即座に確認応答し、回答生成は非同期に進めて後からメッセージを投稿する形にします。公開URLを外に出せない環境では、WebSocket接続でイベントを受けるSocket Modeという選択肢もあります。こうした連携部分の作り込みや社内システムとの接続まで含めて設計するなら、社内データに合わせたAIチャットボット開発のように、要件定義から実装までを受託で進める方法が現実的です。既製ツールをそのまま入れるか開発を伴うかの分岐は、ヘルプデスクツールの種類と選び方をまとめた記事で比較軸を確認できます。

有人エスカレーションの引き継ぎ設計と受け渡すコンテキストの決め方

一次受けの設計で最も差がつくのが、答えられなかったときの渡し方です。ここが雑だと、利用者はボットに説明した内容を担当者へもう一度説明することになり、体験としては元の運用より悪化します。

引き継ぎのきっかけと担当者へ渡すコンテキストの中身を先に決める

エスカレーションのきっかけは二種類に整理できます。利用者が「担当者につないで」と明示的に求める場合と、ボットが質問の意図を判定できずに行き詰まる場合です。Microsoft Copilot Studioでは前者を暗黙的トリガー、後者を含めた設計上の明示的な分岐を明示的トリガーと呼び、「会話の転送」ノードを置いた地点で引き継ぎが始まります。引き継ぎの際は会話の全履歴と関連する変数を共有でき、既定で用意される変数には、直前に発動したトピックを示すva_LastTopic、発話内容のva_LastPhrases、会話を一意に識別するva_ConversationId、担当者だけに見せる補足を入れるva_AgentMessageなどがあります（Microsoft Learn「ライブエージェントに引き継ぐ」・2026年9月時点）。

製品が違っても、設計として決めるべきことは変わりません。渡すのは、会話の全文、利用者の識別情報、直前に踏んだ質問カテゴリ、そして「なぜ引き継いだのか」の理由です。この四つが担当者側の画面に出れば、担当者は状況を読んだ状態で会話を再開できます。誰が受けるのかという受け手側の体制、つまり一次・二次・三次の切り分けについては、社内ヘルプデスクの体制設計を解説した記事で整理しています。

ボットと有人窓口のどちらを前面に置くかで構成が二つに分かれる

引き継ぎの構成は、利用者から見てどちらが前面に立つかで二つに分かれます。同ドキュメント群では、問い合わせ窓口側のチャット画面を前面に置き、裏でボットが応答する構成をBot-as-an-Agent、ボットを前面に置いて裏の窓口システムと連携する構成をBot-in-the-Loopと呼んで区別しています。前者は設定が簡単で、既存の窓口システムが持つ引き継ぎ機能や監督者機能をそのまま使える一方、ボットの応答画面の見せ方を細かく制御できません。後者は表示を作り込め、担当者への助言機能も設計できますが、システム間の経由点が増え、実装の難度が上がります。

社内ヘルプデスクの場合、有人窓口としてコンタクトセンター製品を持っていない企業がほとんどです。その場合は、ボットを前面に置いたうえで、引き継ぎ先を既存のチャットチャネルやチケット管理システムにする構成が落としどころになります。引き継ぎ時に会話ログを本文に埋めたチケットを自動起票すれば、担当者は問い合わせ一覧の中で通常の依頼として処理でき、専用の受け口を新設せずに済みます。

運用で効果を出すKPI設計と未回答ログからの改善サイクルの回し方

公開して終わりにすると、チャットボットは公開時点の精度で固定されます。運用側で見る数字と、その数字を改善に戻す経路を、公開前に決めておきます。

セッションの結果別に一次完結率とエスカレーション率のKPIを定義する

測りたいのは「何件受けたか」ではなく「何件を最後まで片付けたか」です。Microsoft Copilot Studioの監視画面では、セッションの結果を解決（Resolved）、エスカレーション（Escalated）、放棄（Abandoned）に分類し、トピック単位でその内訳を見られます。同ドキュメントは、エスカレーションと放棄の割合が高いトピックを改善の優先対象として扱うよう案内しています。あわせて、会話は非アクティブ状態が30分続くとタイムアウトすること、監視データは最大360日、会話の記録は直近28日を対象に参照できること、分析結果の反映には最大1時間ほどかかることも明記されています（Microsoft Learn「監視の概要」・2026年9月時点）。

この三分類は、製品を問わず社内ヘルプデスクのKPIとしてそのまま使えます。追う数字を並べると次のようになります。

一次完結率（解決で終わったセッション ÷ 全セッション）
エスカレーション率（有人へ渡ったセッション ÷ 全セッション）
放棄率（回答に至らず離脱したセッション ÷ 全セッション）
担当者の対応件数（導入前との比較）

注意したいのは、エスカレーション率を下げること自体を目標にしない点です。有人に残すと決めた質問が正しく人へ渡っているなら、その分の率は下がらなくて構いません。改善の対象は、載せると決めたはずの質問が解決できていない場合と、放棄が積み上がっている場合に絞られます。

未回答・放棄のログをFAQへ戻す週次の見直し体制と担当を決める

改善の材料は、答えられなかった会話のログにあります。週次で放棄された会話と低評価がついた回答を抽出し、原因を三つに仕分けします。参照元に答えが無いのか、答えはあるが質問文と結びつかなかったのか、そもそも有人に残すべき質問だったのかです。一つ目はFAQの追記、二つ目は表記の並記や辞書への追加、三つ目は分岐の見直しで対処します。

この作業を担当する人と時間を、運用体制として先に確保してください。誰の担当でもないまま放置されたボットは、半年ほどで「聞いても無駄なもの」になります。逆に、月に数時間の見直しを続けたボットは、質問が集まるほど回答範囲が広がり、担当者の負荷が下がり続けるはずです。導入プロジェクト全体の進め方と費用の目安は、チャットボット導入の手順と費用相場を解説した記事で確認できます。

チャットボットでヘルプデスクを一次受けする条件と見送るべき場面

ここまでの設計を踏まえて、着手してよい状態と、いま進めるべきでない状態を言い切ります。判断を先送りにするより、条件を満たしてから動くほうが結果的に早く立ち上がります。

着手してよい条件は反復率・ナレッジ・置き場所・運用担当の四つがそろうか

一つ目は反復率で、上位20件程度の質問が全体の3割以上を占めているかどうかです。問い合わせが毎回異なる内容ばかりの職場では、一次受けの自動化より、担当者の調査を助ける社内検索の整備が先に効きます。二つ目はナレッジの存在で、上位質問の回答がすでに文書としてあるか、少なくとも担当者の頭の中から書き出せる状態にあることです。三つ目は置き場所で、社員が日常的に開くチャットやポータルがあることです。四つ目は運用担当で、公開後にログを見てFAQを直す人が決まっていることを指します。

四つそろっていれば、上位20件のFAQ化と一部門への試験公開から着手して構いません。そろっていない項目があるなら、その項目を埋める作業がプロジェクトの第一歩になります。

全社展開を見送る、あるいは段階導入へ切り替えるべき三つの場面

次のいずれかに当てはまるなら、全社展開をいったん止めます。回答が担当者ごとに違う状態が放置されている場合、ボットに載せると社内に誤った回答が広まります。先にFAQの内容を確定させ、有人の回答をそろえるほうが先決です。問い合わせの大半が原因調査を伴うトラブルである場合も、一次受けの効果は小さく、チケット管理や資産管理の整備に投資したほうが担当者の負荷は下がります。参照させたい情報が人事評価や給与など機微なものに寄っている場合は、権限に応じた出し分けを実装できる構成かどうかを先に検証してください。

そして、導入そのものの是非にまだ迷いがあるなら、本記事の設計論より前の段階です。効果の見積もり方と有人対応の線引きから整理したAIヘルプデスクの導入判断をまとめた記事に戻り、自社の問い合わせ構成で効果が出るかどうかを先に確かめることをおすすめします。

ヘルプデスクのチャットボット導入でよくある質問と回答（設計・運用）

FAQは何件そろえてから公開すればよいですか？

件数の絶対値ではなく、問い合わせ上位のカバー率で判断します。上位20件の質問に対する回答が1問1答の形で用意できていれば、それだけで全問い合わせの3割前後を受けられる職場は珍しくありません。数百件を作り込んでから公開するより、上位から順に載せて実際の質問を見ながら足すほうが、無駄な整備を避けられます。

TeamsとSlackのどちらに置くか迷っています。基準はありますか？

社員が普段開いているほうに置く、という基準で決めて構いません。両方が使われている場合は、情シスへの問い合わせが実際に飛んできているチャネルを選びます。設置先を増やすとFAQの参照元を共通化する設計が要り、初期の手間が増えるため、まず片方で運用を固めてから広げる順序が扱いやすくなります。

有人に引き継ぐとき、担当者には何が見えているべきですか？

会話の全文、質問した社員の識別情報、直前に踏んだ質問カテゴリ、引き継ぎの理由の四点です。これらが担当者の画面に出ていれば、利用者に同じ説明をさせずに会話を再開できます。専用のオペレーター画面を持たない場合は、これらを本文に埋めたチケットを自動起票し、既存の問い合わせ管理の流れに乗せる構成が現実的です。