社内問い合わせのチャットボット化、任せられる業務と任せてはいけない業務の線引き

「情報システム部門への問い合わせが多すぎて、本来の仕事が進まない」「総務が同じ質問に何度も答えている」。こうした課題からAIチャットボットの導入を検討する企業が増えています。

ただ、私たちが相談を受ける中でよくあるのが、「社内問い合わせ全般をチャットボットに置き換えたい」という漠然とした要望です。この状態で開発に進むと、ほぼ確実に「使われないチャットボット」ができあがります。問い合わせの中には、AIに任せると業務が悪化する種類のものが混ざっているからです。

この記事は、社内ヘルプデスクや総務・人事・情シスの問い合わせ対応を効率化したい担当者に向けて、業務ごとの線引きの考え方を整理したものです。導入前の要件定義で判断材料として使えるレベルまで具体化します。

線引きの2軸：正解の一意性と、誤答したときの影響度

私たちが要件定義の初期に必ず確認するのは、次の2点です。

軸1：その質問に対する正解が一意に定まるか

「有給休暇の申請期限は何日前までか」は、就業規則を見れば一意に定まります。一方「この経費は交際費で処理すべきか会議費か」は、金額・参加者・目的といった前提条件で答えが変わり、最終的には経理担当者の判断が入ります。前者はAIに向き、後者は向きません。

軸2：間違った回答が出たときに、誰がどれだけ困るか

「社内Wi-Fiのパスワードの場所」を間違えても、聞いた人が「違いました」と再質問するだけです。しかし「この情報は社外に開示してよいか」を誤って「問題ありません」と答えたら、取り返しがつきません。

この2軸で分類すると、多くの社内問い合わせは3つのゾーンに分かれます。

ゾーン1：任せてよい業務（正解が一意・誤答の影響が小さい）

規程・マニュアルの参照系

就業規則、経費精算のルール、各種申請フローの手順、システムの操作方法。これらは「文書のどこに書いてあるかを探す」作業であり、AIが最も得意とする領域です。

具体例を挙げます。ある製造業の情報システム部門では、月間の問い合わせのうち約4割が「パスワードのリセット手順」「VPNの接続方法」「プリンタの設定」の3種類でした。手順書は社内ポータルに存在しているのに、どこにあるか分からず電話がかかってくる。この種の問い合わせは、社内文書を検索対象にしたRAG（検索拡張生成）型のチャットボットで十分に対応できます。

定型の一次切り分け

「PCが起動しない」という問い合わせに対して、「電源ランプは点灯していますか」「ACアダプタは接続されていますか」と順に確認していく作業。これは判断ではなく手順の実行なので任せられます。切り分けの結果を整理した状態で担当者にエスカレーションできれば、それ自体が工数削減になります。

社内用語・略語の説明

中途入社者や異動者が最初につまずくのが社内固有の略語です。「SPRって何ですか」と聞くのは気が引ける、という心理的ハードルがあるため、人に聞かれないまま放置されがちです。チャットボットはこの種の「聞きにくい質問」の受け皿として機能します。

ゾーン2：任せてはいけない業務

個別事情の判断が入る労務・人事の相談

「育児休業から復帰する際、時短勤務は何時間まで選べますか」という質問は、一見すると規程の参照です。しかし実際には、その人の職種、部署の体制、子の年齢、配偶者の就業状況などで結論が変わります。制度の概要説明までは可能ですが、「あなたの場合はこうなります」に踏み込ませてはいけません。

この領域で怖いのは、AIが規程の一般論を答えたのを従業員が「自分に適用される回答」と受け取ってしまうことです。後から人事が「実際は違います」と訂正すると、制度への不信につながります。

ハラスメント・メンタルヘルスの相談

言うまでもありませんが、対人の窓口を機械に置き換えてよい領域ではありません。相談窓口の連絡先を案内するところまでに限定すべきです。

法務・コンプライアンスの可否判断

「この契約書のこの条項は問題ないか」「この表現は景表法に触れないか」。専門家の判断領域であり、誤答時の影響が事業リスクに直結します。

未確定・変更中の情報に関する質問

制度改定の途中、システム移行期間中など、情報が流動的な期間の問い合わせは、AIが古い文書を根拠に回答してしまう危険があります。私たちが構築する際は、こうしたトピックを一時的に回答対象外にして「担当者に確認してください」と返す設計を入れることが多いです。

ゾーン3：条件付きで任せられる業務

実務で最も判断が難しいのがこのゾーンです。設計次第で成功も失敗もします。

経費精算・稟議の可否判断

「一般的な判断基準を示す」「該当しそうな規程の該当箇所を提示する」までは有用です。ただし「この支出は承認されます」という結論は出させない。回答の末尾に必ず「最終判断は経理担当にご確認ください」を付ける設計にします。

取引先・顧客情報の照会

技術的には可能ですが、アクセス権限の制御が前提になります。営業担当Aが担当外の顧客の情報を引き出せてしまう状態は、情報統制上の問題です。チャットボットが参照する情報を、質問者の権限に応じて絞る仕組みが必要で、これは基幹システムとの連携を伴うため実装コストが上がります。

過去の類似案件の検索

「同じような仕様の案件を過去にやっていないか」という問い合わせは、ナレッジ活用の観点で価値が高い領域です。ただし社内の議事録や提案書は表記がばらついており、検索精度が出にくい。導入前に、対象文書がどの程度整っているかの確認が要ります。整っていない場合は、まず文書側の整備が先です。

「答えない」設計が信頼を決める

多くの導入失敗は、回答精度そのものより「答えるべきでない質問に答えてしまう」ことに起因します。従業員が一度でも明確な誤答を経験すると、そのチャットボットは使われなくなります。

そのため私たちは、以下のような制御を設計に組み込みます。

• 回答の根拠となった社内文書名とセクションを必ず併記する。従業員が自分で検証できる状態を作る
• 参照した文書との関連度が低い場合は、回答を生成せず「該当する情報が見つかりませんでした」と返す
• 労務・法務・ハラスメントなど、あらかじめ定めたトピックは検出して担当窓口の案内に切り替える
• 回答の末尾に、担当部署へのエスカレーション手段を常に置く

「AIが答えられなかった」ことは失敗ではありません。答えられない質問を人に渡す動線が整っていれば、それは正常動作です。

導入前にやるべき棚卸し

線引きを決めるには、まず現状の問い合わせを把握する必要があります。最低限、次の作業をおすすめしています。

1. 直近1〜3か月の問い合わせログを集める

メール、チャット、電話メモ、何でも構いません。件数の多い順に並べます。

2. 上位20〜30件を上記の3ゾーンに分類する

ここで「ゾーン1が全体の何割か」が見えます。経験的に、ゾーン1が問い合わせ件数の3割を下回る場合は、チャットボット導入の効果は限定的です。まず業務プロセス側の見直しを検討したほうがよいケースもあります。

3. ゾーン1の質問に対して、根拠となる社内文書が存在するか確認する

「規程はあるが最新版がどれか分からない」「手順書が個人のローカルにある」という状態では、AIに読ませる元データがありません。この場合、文書整備が最初のタスクになります。ここを飛ばして導入すると、AIが古い情報を自信ありげに回答する状態が生まれます。

チャットボット化が向かない組織状況

正直に書きます。次のような状況では、導入を急がないほうがよいと考えています。

• 問い合わせの内容が毎回違う：定型化できる質問が少ない組織では投資回収が難しい
• 社内文書が整備されていない、更新されていない：AIは元データの品質を超えられません
• 問い合わせ対応の担当者が明確でない：エスカレーション先がないと、答えられない質問が宙に浮きます
• 問い合わせ件数自体が少ない：月に数十件程度なら、FAQページの整備で足りることも多いです

「AIを入れれば問い合わせが減る」のではなく、「整理された情報があるから、AIが答えられる」という順序です。この順序を逆にした導入が、使われないチャットボットの主な原因だと私たちは見ています。

まとめ

社内問い合わせのチャットボット化は、対象業務の選定で成否がほぼ決まります。判断軸は「正解が一意に定まるか」「誤答時の影響がどれだけ大きいか」の2つ。規程・マニュアルの参照系から始め、個別判断が入る領域と対人相談は人に残す。この線引きを最初に明文化しておくことが、現場に定着する導入の前提条件になります。

私たちは要件定義の段階で、この分類作業をお客様と一緒に行うことを標準にしています。どこまでを任せるかの合意がないまま開発に入ると、後から「これも答えられるはずだ」という期待とのずれが生じるためです。導入を検討されている場合は、まず手元の問い合わせログを並べてみることから始めてみてください。