社内FAQチャットボット導入の進め方|対象範囲・ナレッジ整備・効果測定
社内FAQチャットボット導入を成功させるため、対象業務の選び方、元文書とナレッジの整備、権限と回答範囲、未回答ログ、導入前後の指標を順番に解説します。
社内FAQチャットボット導入では、全社の文書を一度に登録するのではなく、問い合わせ頻度が高く、正本と担当者が明確な業務を選び、小さな範囲から始めます。
経費申請、休暇申請、社内ツールの操作など、同じ質問が繰り返される業務は初期対象の候補です。一方、個人の評価、個別の労務判断、契約の解釈、閲覧権限が限定された情報は、誤答や情報開示の影響が大きいため、原則として有人対応へ切り分けます。社内FAQチャットボットの導入では、対象業務、文書の正本、更新責任、回答根拠、権限の境界、未回答時の窓口を順番に決めることが重要です。

対象業務を頻度と安全性で選ぶ
最初の対象は、問い合わせ件数だけで決めません。回答の正しさを正本で確認できるか、更新責任者を置けるか、適用範囲を説明できるか、答えられない場合の担当部署が決まっているかを確認します。
- 申請方法や提出先が正本に明記されている
- 参照する規程やマニュアルの版を特定できる
- 全社員向けか、部署・役職などの条件付きかを説明できる
- 例外条件と、誤答した場合の影響を把握できる
- 未回答や誤回答の報告を受ける担当者がいる
- 回答できない場合に案内する有人窓口がある
例えば経費申請は、申請手順の正本、対象者、提出先、例外窓口が決まっていれば候補にできます。反対に、規程が複数あり、どれが現行版か分からない業務は、問い合わせが多くても公開対象にできません。先に担当部署が正本を確定し、適用開始日と対象者を整理します。
候補を探す際は、問い合わせメール、フォーム、既存の対応記録、マニュアルの目次から質問を集めます。「経費を出したい」のように制度名を含まない表現、社内で使われる略語、誤字、条件が不足した質問も残します。文書の見出しをそのまま質問に置き換えるだけでは、社員が実際に入力する表現とのずれを把握できません。
収集した質問は、頻度、正本の有無、誤答時の影響、有人窓口の有無で優先順位を付けます。頻度が高くても、個人評価、個別の労務判断、契約解釈、機密情報を含む質問は、一般的な制度説明と個別判断を分け、個別判断を有人対応へ渡します。
導入会議で目的と担当範囲を決める
FAQを登録する前に、誰のどの質問を、どの正本に基づいて案内するのかを合意します。利用者、対象業務、正本、内容決定者、文書更新者、FAQ登録者、ログ確認者、例外相談の担当者を明記し、共通手順と部署固有の例外を切り分けます。
導入目的を「問い合わせを減らす」だけにすると、回答後に社員が正しい手続きへ進めたか、判断が必要な質問を適切に人へ渡せたかを評価できません。目的には、正しい手順への到達、根拠の確認、有人窓口への適切な切替も含めます。
担当範囲は、内容を決める人とシステムへ登録する人を分けて記録します。FAQ登録者が規程の意味を独自に解釈しないよう、内容に疑義がある場合の確認先も決めます。担当者が不在のときに確認を止めるのか、代替担当者が承認するのかも導入時に決定します。
会議の記録には、対象にする質問だけでなく、対象外とした業務と理由も残します。「正本が定まらない」「権限を確認できない」「個別判断が必要」といった理由を記録しておけば、後から対象範囲を見直す際にも同じ判断基準を使えます。
文書を棚卸しし、正本と更新責任を決める
文書を集めただけでは、古い規程、重複した手順、部署限定の資料が混在します。文書名、版、適用開始日、対象者、所有部署、更新日、次回確認日、責任者、例外時の窓口を一覧にし、回答の根拠として使う正本を確定します。
- 正本:内容の最終判断に使う文書と版を一つに定める
- 更新責任:内容を決める人とFAQ登録を直す人を明確にする
- 適用範囲:全社員、部署、役職、雇用形態などの条件を記載する
- 更新条件:文書改定時と定期確認日に行う作業を決める
- 例外:通常手順から外れる場合の相談先を示す
複数の文書が矛盾している場合は、AIに優先順位を推測させません。担当部署が正本を確定し、旧版を回答対象から外すまで、該当する回答の公開を保留します。正本を決めた日、確認者、旧版の扱いも記録します。
長いマニュアルは、質問、短い回答、適用条件、実行手順、根拠箇所、対象外条件、有人窓口の単位に分けます。例えば「経費を出したい」という質問には、必要な申請区分や対象者だけを確認し、条件がそろった場合に手順を案内します。条件が不足したままなら、推測せず担当窓口へ切り替えます。具体的な整理方法は、チャットボット用FAQの作り方で確認できます。
PDFや画像から内容を転記する場合は、数字、日付、固有名詞、提出先を目視で照合します。元文書とFAQの対応表を作り、文書が変わったときに、影響するFAQ、代表的なテスト質問、更新日、確認者をまとめて更新できるようにします。
更新責任者だけでなく代替担当者も決めます。引き継ぐ項目は、正本の保管場所、FAQ登録の手順、確認周期、ログの確認方法、例外窓口、回答の停止・再開条件です。担当者変更後には代表質問を実行し、根拠表示と切替先が記録どおりか確認します。
権限と回答範囲を決め、根拠を表示する
社内情報は、すべての社員が同じ内容を閲覧できるとは限りません。部署、役職、雇用形態、案件への参加状況などの条件を整理し、回答範囲を公開前に決めます。利用予定の仕組みに権限分離機能があると想定せず、自社の利用環境と製品仕様で確認できた範囲だけを運用条件にします。
- そのまま案内する情報:全社員向けの手順や公開済みの規程
- 条件を確認して案内する情報:部署、役職、申請区分などによって内容が変わる情報
- 担当者へ引き継ぐ情報:個別評価、機密情報、例外対応、契約や労務など判断が必要な質問
休暇申請で部署ごとに提出先が異なる場合は、全社員共通の制度説明と部署別の提出手順を分けます。所属を確認できない環境では、利用者の自己申告だけを根拠に個別の提出先を断定せず、確認できる担当部署を案内します。
回答には、社内で表示できる範囲で正本名、該当箇所、版または確認日を添えます。根拠がない、必要な条件が不足している、権限を確認できない場合は、回答を推測で補いません。確認が必要な項目と有人窓口を明示します。根拠を確認できない場合の設計は、AIの回答精度と情報整合性も参考になります。
人事評価について尋ねられた場合は、制度の一般説明と個人の評価判断を分けます。一般説明には根拠となる規程を示し、個人の評価理由や今後の判断は人事担当者へ渡します。個人情報を必要以上に入力しないこと、機密情報を質問文へ貼り付けないことも利用ルールに含めます。
答えられない場合の文章は、単に「回答できません」で終わらせません。回答できない理由、追加で確認すべき条件、相談先、受付方法を示します。ただし、権限がない利用者へ根拠文書の内容を要約して見せることがないよう、表示範囲も確認します。
公開前に実際の質問でテストする
公開前テストでは、FAQに登録した文章をそのまま入力するだけでは不十分です。社員が使う短い表現、言い換え、略語、誤字、条件不足、複数制度にまたがる質問を用意し、期待する回答、根拠、切替先を記録します。
- 「経費を出したい」のように条件が不足した質問
- 部署や雇用形態によって提出先が変わる質問
- 古い文書と新しい正本が混在する質問
- 個人の評価、給与、契約などの判断を求める質問
- 部署限定の資料について全社員向けの回答を求める質問
- 根拠文書と確認日が正しく表示される質問
- 回答できない場合に担当部署へ切り替える質問
テスト表には、質問番号、入力例、期待回答、根拠文書、適用条件、切替先、判定、確認者を記載します。正しい回答が返るかだけでなく、必要な条件を確認できるか、不要な情報を求めないか、対象外の質問で回答を止められるかも確認します。
テスト中に、根拠のない補足、権限を越えた情報開示、個別判断の断定が見つかった場合は公開を保留します。FAQの文章だけを直して終わらせず、原因が正本、適用範囲、権限、質問条件のどこにあるかを記録します。
旧版との競合が見つかった場合は、旧版を回答対象から外したことを確認し、影響する代表質問を再実行します。現在の環境で確認できないログ、権限、連携機能は、利用できる前提にせず、担当者による確認や有人窓口への切替など、実行可能な手順を決めます。
小規模導入を進める
導入は、問い合わせ履歴の収集、対象業務の選定、正本と責任者の確定、FAQ作成、権限・未回答テスト、限定公開の順に進めます。最初は一部署の経費申請や社内ツール操作など、責任分界と回答根拠を確認しやすい範囲に限定します。
限定公開の開始前に、対象業務、利用者の範囲、対象外の質問、誤回答の報告方法、有人窓口を案内します。正本、更新責任者、例外窓口、回答できない条件のいずれかが空欄の業務は、公開対象から外します。
開始日には、チャットボットが個別判断を代行するものではないことも伝えます。利用者が回答を確認できるよう、根拠の見方と、内容に疑問がある場合の報告先を示します。誤回答の報告を受けた担当者は、質問、回答、根拠、利用者範囲、切替の有無、対応日を確認します。
限定公開中は、利用者が迷わず質問できるかも観察します。制度名を知らない言い方、略語、誤字が多い場合は、利用者の表現をFAQ候補やテスト質問へ反映します。ただし、対象外の質問まで回答させるために範囲を広げず、有人対応へ渡す理由も記録します。
未回答ログを分類して改善する
公開後は質問数だけでなく、未回答、有人切替、誤回答の報告を確認します。ログを確認する担当者、確認周期、閲覧範囲、保存期間、個人情報を含む場合の扱いは、自社の規程と利用環境に合わせて決めます。
- FAQ不足:正本に情報はあるが、回答単位に整理されていない
- 文書不足:回答の根拠となる正本が存在しない
- 条件不足:部署、対象者、申請区分などの確認が必要
- 権限:利用者の閲覧権限を確認できない
- 対象外:個別判断や相談など、チャットボットでは扱わない
- 更新・矛盾:文書の改定、旧版参照、正本同士の不一致がある
分類後に、FAQを追加するのか、元文書を修正するのか、必要な条件を聞き返すのか、担当者へ切り替えるのか、回答を停止するのかを決めます。未回答をすべてFAQ追加で解消しようとすると、正本がない質問や権限外の質問まで回答対象に含めることになります。
記録には、質問の分類、分類理由、根拠文書の版、変更内容、担当部署、確認者、次回確認日を残します。個人情報を保存する必要がない場合は、業務や原因を特定できる必要最小限の情報へ置き換えます。会話ログを改善へつなげる方法は、会話ログ分析の方法で詳しく確認できます。
改定後は代表質問を再テストします。同じ未回答が再発した場合は、FAQを増やす前に、分類が正しいか、正本が更新されているか、適用条件や権限が変わっていないかを順に確認します。元文書の説明不足が原因なら、FAQだけで補わず、文書の所有部署へ修正を依頼します。
改善の優先順位は、誤案内した場合の影響、再発の有無、正本を修正できるか、切替先が受け付けられるかで決めます。すぐに回答を追加できない場合でも、対象外となる理由と代替窓口を示せば、利用者は次の行動を選べます。
効果を測定し、維持・縮小・停止を判断する
効果測定では、導入後の会話数だけで成功と判断しません。対象業務について、導入前に把握できる問い合わせ件数や担当者の確認負荷を記録し、導入後も同じ対象と定義で比較します。
- 対象業務の質問件数と分類
- 未回答、有人切替、誤回答が発生した理由
- 担当者による回答修正の状況
- 正本とFAQの更新状態
- 回答後に必要な申請や手続きへ進めたか
- 利用者から報告された誤回答と修正状況
会話が終了したことを、そのまま自己解決と数えないことが重要です。申請ページへ進んだか、必要な手続きを完了できたか、有人窓口へ適切に切り替わったかを分けて確認します。取得できない指標は推測せず、未確認である理由を記録します。指標の定義は、チャットボット効果測定の方法も参考にしてください。
正本が更新され、担当者がログを確認し、根拠表示と有人窓口が機能している場合は、現在の範囲を維持できます。関連業務へ拡大する場合も、新しい業務ごとに正本、更新責任、権限、例外条件を確認し、代表質問を再テストします。
文書更新が止まった、権限を確認できない、重要な誤回答を止められない、有人窓口が機能していない場合は、対象を縮小します。改善まで影響を管理できない場合は、該当業務に関するチャットボット回答を停止する判断が必要です。
停止時には、停止日、理由、影響する質問、利用者への告知、代替窓口、再開条件、確認者を記録します。再開前に、正本の確定、権限範囲の確認、代表質問の再テスト、切替先の稼働を確認します。回答数を増やすことではなく、社員が正しい根拠へ到達し、判断が必要な場面で担当者へ相談できることを基準にします。
対象業務、正本、更新責任、有人対応の境界を整理した後は、その条件をSocratesでどこまで運用できるか、確認済みの機能範囲に基づいて確認・相談できます。導入前に決めた判断基準を共有すると、必要な運用条件を具体的に切り分けられます。
導入手順
- 問い合わせ履歴から、社員が実際に使う質問を集める
- 頻度、正本の有無、誤答時の影響で対象業務を選ぶ
- 利用者、対象外の質問、有人窓口を決める
- 正本、版、適用範囲、更新責任者、例外条件を整理する
- 文書を質問、回答、条件、手順、根拠の単位に分ける
- 権限、未回答、旧版との競合、有人切替をテストする
- 一部署または一業務で限定公開する
- ログと指標を確認し、維持・拡大・縮小・停止を判断する
公開前の確認表には、対象業務、利用者の範囲、正本の名称と版、適用開始日、更新責任者、有人窓口、代表質問、期待回答、回答できない条件を記入します。各項目に確認者と確認日を付け、空欄が残る業務は限定公開の対象から外します。
テスト表には、質問番号、入力例、期待回答、根拠文書、切替先、判定、確認者を残します。「経費を出したい」のような条件不足の質問では、必要な条件だけを確認できるか、条件がそろわない場合に窓口へ渡せるかを確認します。
文書を更新したときは、正本の版と適用開始日を確認し、影響するFAQと代表質問を再テストします。旧版を参照した回答が見つかった場合は、FAQを直すだけでなく、旧版を回答対象から外したこと、影響範囲、確認者を記録します。
定例確認では、未回答の多い質問、有人切替の理由、正本の版、次回確認日、権限別の回答結果を照合します。正本の改定がFAQ担当者へ伝わらない、ログ担当者がいない、有人窓口が受け付けていない状態では、対象範囲を広げません。
担当者変更時は、正本の場所、更新責任者、代替担当者、FAQ登録者、ログ担当者、例外窓口、確認周期、停止・再開条件を引き継ぎます。引き継ぎ後に代表質問を実行し、正本名、確認日、権限境界、有人窓口の案内が記録と一致するか確認します。
社内向けの対象範囲と運用条件を、FAQチャットボット全般の工程と照合したい場合は、FAQチャットボット導入ガイドも確認してください。
FAQ
Q1. 社内文書を全部登録すれば精度は上がりますか?
文書の量だけでは判断できません。正本であること、適用範囲が明確であること、更新責任者がいることを確認し、対象業務に必要な文書から登録します。
Q2. 人事や評価の質問にも答えられますか?
制度の一般説明と、個人に対する評価判断を切り分けます。一般説明には確認できる根拠を示し、個別事情や評価理由については推測せず、人事担当者へ切り替えます。
Q3. FAQはいつ更新すればよいですか?
元文書が改定されたときと、あらかじめ決めた定期確認日に照合します。FAQだけでなく、代表質問、根拠の版、確認日、確認者も更新します。
Q4. 未回答をなくすにはFAQを増やすべきですか?
未回答には、FAQ不足、正本不足、条件不足、権限外、対象外、版の不一致があります。原因を分類してから、FAQ追加、元文書の修正、条件確認、有人切替、回答停止を選びます。
Q5. 小さく始める対象はどう選びますか?
問い合わせ頻度が高く、正本と更新責任者が明確で、誤答の影響を管理できる定型手順から始めます。具体的な導入工程は、FAQチャットボット導入ガイドでも確認できます。
この記事と合わせて読みたい
社内FAQチャットボット導入では、回答数の多さだけでなく、正しい根拠を更新し、答えられない質問を適切に有人対応へ切り替えられるかを確認します。対象を限定して公開し、未回答ログと文書更新の状況を基に、維持・拡大・縮小・停止を判断してください。