社内チャットボットは3タイプに分かれ、選ぶべきタイプは「答えの元になる文書が更新されるか」で決まります。
答えがほぼ固定なら、FAQ型やシナリオ型が候補です。規程や手順書が変わり続けるなら、生成AI型が合います。ただ、機能だけで決めても定着はしません。
費用は製品名より、対象業務数や連携先で変わります。さらに、投資回収には問い合わせ以外の用途も必要です。
社内チャットボットとは（社外向けとの違い）
社内チャットボットは、従業員の質問に自動で答える窓口です。回答の元には、社内規程、マニュアル、FAQなどを使います。「有給休暇の申請方法」や「端末を紛失したときの連絡先」が代表例です。
社外向けとの違いは、扱う情報と利用者です。社外向けは商品案内や顧客対応が中心です。社内向けは、公開範囲の異なる文書や個社固有の略語を扱います。
そのため、社内向けでは「誰に何を見せるか」が重要です。回答精度だけでは足りません。認証、権限管理、ログ、情報の更新責任まで設計対象になります。
効果は立場で分かれます。従業員側は、規程や手順書を探す時間と、担当者の返信を待つ時間が減ります。夜間や休日でも定型の情報には到達できます。経営側は、総務や情シスなど特定の担当者への質問集中が緩みます。さらに、未回答ログから「どの文書が足りないか」を把握できます。
導入目的も分けます。「問い合わせを減らす」と「情報を探す時間を減らす」は別の課題です。
属人化と回答のばらつきを解消する
社内チャットボットには、担当者が持つ知識を組織のナレッジとして蓄積し、問い合わせ対応の属人化を防ぐ効果があります。同じ質問への回答元を揃えれば、担当者ごとの説明のばらつきも抑えられます。特に総務や情シスなど、効果の主語は問い合わせを受けるバックオフィスです。
実務では、担当者が退職・異動する前に「頻出質問への回答」「例外の判断条件」「参照する規程」「担当窓口へ切り替える条件」を書き出してもらいます。チャットやメールの回答履歴も集め、個人の経験だけに残っている判断をFAQまたは元文書へ移します。
ただし、知識を登録するだけでは引き継ぎになりません。誰が更新するか、どの文書を正本とするかまで決めて初めて、退職後も同じ基準で回答できます。
3つのタイプ：FAQ型・シナリオ型・生成AI型
比較では、画面より「回答の元」と「更新方法」を見ます。
| タイプ | 回答の元 | メンテナンス | 向く用途 | 費用の性質 |
|---|---|---|---|---|
| FAQ型 | 登録した質問と回答 | FAQごとに追加・修正する | 定型質問、規程案内、窓口案内 | 登録量と運用支援の範囲で変わる |
| シナリオ型 | 選択肢と分岐ルール | 分岐や文言を直す | 申請案内、切り分け、手続き誘導 | シナリオ数と連携処理で変わる |
| 生成AI型 | 文書やデータベース | 元文書と検索設定を更新する | 横断検索、要約、個別質問への回答 | 文書量、利用量、モデル、基盤運用で変わる |
社内利用の生成AI型では、検索拡張生成を意味するRAGがよく使われます。
実際の製品は複数方式を併用します。自作する場合の手順では、最初に分類器を置く考え方も解説しています。
FAQ型・シナリオ型が放置される構造
FAQ型は、登録済みの質問には安定して答えます。ただ、規程が変わるたびに回答も直す必要があります。元文書とFAQが別管理なら、「規程は新しいが、回答は古い」という状態が生まれます。
シナリオ型も同じです。制度や申請経路が変われば、分岐を見直します。担当者が異動すると、「どの分岐を直すべきか」が分からなくなります。
放置の原因は、更新箇所が二重になる構造です。運用前に「元文書を直した人が、回答も直す」と責任を決めます。
一方で、答えが固定された少数の手続きには適しています。選択肢を順に示したい業務なら、生成AIよりシナリオの方が明快です。
生成AI型（RAG）は文書の更新が回答の更新になる
RAGは、登録した文書を検索してから回答を生成します。元文書を差し替えると、検索対象も更新できます。「文書の更新が回答の更新になる」点が、FAQ型との大きな違いです。
ただ、古い版が残れば、古い根拠も検索されます。表や添付資料が読めなければ、回答の材料が欠けます。
運用では「正本はどれか」「更新者は誰か」「回答に根拠を表示するか」を決めます。生成を始める前の文書管理が、回答品質を左右します。
また、禁止事項や例外条件には、固定文やシナリオを組み合わせます。3タイプは排他的ではありません。
FAQシステム・検索型FAQとの違いと使い分け
FAQシステムや検索型FAQも、よくある質問と回答を蓄積して自己解決を促す仕組みです。登録済みの答えを安定して見せたい点では、FAQ型チャットボットと目的が重なります。
違いは探し方です。検索型FAQは、カテゴリやキーワード、候補一覧から利用者が答えを選べます。チャットボットは、自然文の質問や選択肢を通じて答えへ案内します。質問が定型ならFAQ型やシナリオ型、言い回しが多く文書を横断するなら生成AI型、一覧性を重視するなら検索型FAQが候補です。
Q&Aが数百件を超え、利用者が回答候補を比較したい場合は、カテゴリ、絞り込み、検索結果一覧を備えたFAQシステム側が向きます。一方、質問数が限られ、業務画面や社内チャットからその場で聞く用途なら、チャットボットの短い動線が有効です。両方を併用する場合も、回答の正本は共通化します。
社内特化型か社内外両対応型か
社内向けチャットボットは、社外向けの派生ではなく、権限、認証、社内文書、運用責任を扱う別カテゴリです。その上で製品は、社内利用に特化した型と、顧客対応を含む社内外両対応型に分けて比較できます。
社内特化型は、社内用語、組織情報、ビジネスチャット、従業員認証との適合を確認します。社内外両対応型は、窓口を共通管理しやすい一方、社内文書と公開情報を混ぜない権限分離が必要です。「将来は顧客対応にも使う」だけで決めず、最初の利用者と回答元を基準に選びます。
テンプレート搭載は初期構築工数を左右する
社内向け製品には、人事、総務、情シスなどの質問テンプレートを搭載したものがあります。ゼロから質問を洗い出す必要が減るため、初期構築工数を比べる重要な軸です。
選定時はテンプレートの件数ではなく、自社の規程や申請経路へ一括で置換できるか、不要項目を外せるか、回答元を更新しやすいかを試します。テンプレートは完成品ではなく、聞き漏らしを防ぐ下書きとして使います。
主な機能は設定・分析・改善の流れで見る
社内チャットボットの主な機能には、会話の分岐を作るシナリオ設定、質問と回答を登録するテンプレート、利用状況を集計するダッシュボード、質問履歴や未回答を調べるログ解析があります。生成AI型では、文書の取り込み、検索、出典表示も比較対象です。
機能表では有無だけを見ず、「設定する→公開する→ログで問題を見つける→回答元を直す」という一連の作業を同じ担当者が回せるか確認します。実務では、試用期間中に一つの回答を登録し、公開後のログから修正するところまで操作します。
ハイブリッド型
ハイブリッド型は、決めた質問へ登録済み回答を返すFAQ・シナリオ型と、社内文書を検索して文章を生成する方式を組み合わせた型です。規程の確定回答は登録済み文面、表現が多様な検索は生成AI型というように使い分けます。
選定時は「AI搭載」という名称ではなく、どの質問がどの方式へ送られ、回答できない場合にどう切り替わるかを確認します。重要手続きは固定回答を優先し、原文更新時の反映方法を試します。
RAGの構成（埋め込み・ベクトルDB・検索の連結）
RAGは検索拡張生成、つまり社内資料を検索し、その結果を根拠に文章を作る仕組みです。文書は小さなまとまりに分け、「埋め込み」と呼ばれる意味の近さを計算できる数値表現へ変換します。ベクトルDBは、その数値を保存して質問に近い箇所を探すデータベースです。
質問、検索、回答生成を連結するだけでは足りません。文書の権限、有効日、部署、版を検索条件へ入れ、回答には参照箇所を表示します。同じ質問で古い規程が選ばれないかをテストします。
ハルシネーションをどう抑えるか
ハルシネーションは、AIが根拠のない内容をもっともらしく答える現象です。抑制には、参照先を承認済み文書へ限定し、根拠を表示し、根拠が弱いときは回答しない条件を設けます。
完全にゼロになる前提にはしません。給与、法務、安全、契約など影響が大きい質問は固定回答か有人確認へ切り替え、誤答ログを「検索失敗」「資料不足」「生成時の誤り」に分けて直します。
製品を型で分ける——どのタイプから見るか
製品数ではなく、自社の回答元と運用方法に合う型から比較します。以下は順位表ではなく、各社の公式サイトで公表されている機能を、この記事の3タイプへ対応づけたものです。実際には複数タイプを併用する製品があります。
| 製品名 | どのタイプか | 公表されている得意領域 | 確認すべき点 |
|---|---|---|---|
| HiTTO | FAQ型 | 社内情報をカテゴリで整理し、登録した回答を案内する社内向けAIチャットボット | 自社の規程への置換方法、回答の更新担当、利用するチャットとの連携 |
| PEP AI-FAQ | FAQ型 | FAQのタグ生成、SlackやMicrosoft Teamsなどとの連携 | 既存FAQの移行方法、タグの修正手順、未回答時の有人導線 |
| ChatPlus | シナリオ型・FAQ型 | シナリオ設定、ツリー編集、Q&A、有人対応 | 社内認証と権限分離、シナリオ変更の担当、有人対応の受付時間 |
| WisTalk | 生成AI型・FAQ型 | PDFやMicrosoft Office文書を使う生成AI自動回答とQ&A検索 | 対応する文書形式、出典の示し方、古い文書を除外する運用 |
| Helpfeel | FAQ型・生成AI型 | 意図予測検索、社内文書を使う回答生成、社内ヘルプデスク | FAQと文書の正本管理、アクセス制限、利用者の入口 |
| OfficeBot | 生成AI型 | 社内規程やマニュアルなどの既存データを使うRAG型のナレッジ検索 | 文書ごとの閲覧権限、回答根拠、検索対象の更新方法 |
| AI-FAQボット | FAQ型 | Excelや管理画面でのFAQ管理、社内ポータルやビジネスチャットとの連携 | QAの初期整備、連携先ごとの仕様、回答不能時の引き継ぎ |
最初に二つの型まで絞り、同じ質問、同じ文書、同じ権限条件で試します。比較表の機能名だけで決めず、回答登録から未回答ログの修正までを担当予定者が一巡できるかを確認します。
何に使われているか：部署別の適用
向くのは、同じ質問が集まりやすい部署です。ただ、「文書が散らばっている」業務も候補です。
人事・総務・情シスの問い合わせ対応
人事では、休暇、勤怠、福利厚生、入退社の案内に使えます。総務では、備品、施設、押印、郵送などが対象です。情シスでは、アカウント、端末、ソフトウェアの一次案内を担います。
メールやチャットの履歴から、「繰り返される質問」と「確認が必要な質問」を分けます。
前者は自動回答に向きます。後者は、必要情報を聞き取って窓口へ渡します。「端末が動かない」なら、機種や症状を確認します。
しかし、人事情報を全社員へ同じように返してはいけません。役職や雇用区分で回答が違うなら、「回答できる範囲」を先に定義します。
ナレッジ検索・夜間休日対応
ナレッジ検索は、複数の規程や手順書を横断します。「資料名は分からないが、内容は知りたい」場面に向きます。出典があれば原文も確認できます。
夜間休日は、担当者が不在でも定型情報を返せます。ただ、緊急連絡や事故対応まで完結させる設計は危険です。「緊急時は指定窓口へ連絡」と明確に切り替えます。
また、回答不能を隠しません。「該当文書が見つからない」と返し、未回答ログから不足文書を探します。
テレワーク・多拠点の情報格差を縮める
社内チャットボットは、テレワークや多拠点でも同じ窓口から情報へ到達できるため、近くに詳しい人がいる拠点と、そうでない拠点の情報格差を縮めます。夜間休日だけでなく、勤務場所や時差による待ち時間も減らせます。
ただし、全員へ同じ回答を返すとは限りません。拠点ごとに制度や連絡先が違う場合は、所属情報に応じて回答を出し分け、共通規程と拠点固有ルールのどちらを根拠にしたか表示します。
オンボーディング・新人教育に使う
新人が繰り返し尋ねる社内用語、申請手順、ツールの使い方は、チャットボットと相性がよい領域です。教育担当者の説明を共通化し、新人が質問をため込まずに自己解決できる状態を作れます。
入社初日、1週目、1か月目で必要な情報を分け、回答から研修資料や正本へ移れるようにします。質問ログは「新人が理解できない箇所」を示すため、研修資料そのものの改訂にも使います。
業務システム連携で質問から申請まで完結させる
チャットボットは回答だけでなく、勤怠、経費、ワークフローなどの業務システムと連携できます。「休暇の条件を聞く→残日数を確認する→申請画面を開く」のように、質問から手続きまでを一つの動線にできます。
選定時は、リンクを返すだけか、入力内容を引き継げるか、申請実行まで許可するかを分けて確認します。更新を伴う操作では、本人確認、確認画面、操作ログ、取り消し方法が必要です。連携範囲が費用を動かすため、問い合わせ件数と手戻りが多い手続きから優先します。
営業部門での使い方
営業部門では、商品仕様、最新カタログ、提案資料、競合との違い、見積承認の手順を探す用途に使えます。顧客へ直接回答させる前に、社内の情報検索と提案準備から始めると、誤送信の影響を抑えられます。
実務では、商品担当が正本資料と有効期限を管理し、チャットボットの回答から必ず原文へ戻れるようにします。価格や契約条件は回答だけで確定せず、承認フローへつなぎます。
繁忙期の問い合わせ（年末調整・入社シーズン・人事評価）
年末調整、入社手続き、人事評価は、短期間に同じ質問が集中します。年に一度の手続きは利用者が操作を覚えておらず、担当者も通常業務と同時に回答を求められます。
繁忙期の前に前年ログと制度変更を照合し、期限、対象者、必要書類、差し戻し理由を整備します。終了後は質問数だけでなく、回答できなかった質問と制度説明の分かりにくさを次年度の改善へ残します。
多言語対応・外国籍の従業員
多言語対応は、日本語の回答をその場で翻訳するだけでは不十分です。就業規則や安全手順では、用語の意味、対象国・雇用区分、原文の優先関係を決める必要があります。
実務では、対象言語ごとに頻出質問を確認し、重要回答は担当部門が翻訳を承認します。機械翻訳した回答には原文への導線を付け、解釈が分かれる質問は有人窓口へ渡します。
聞くハードルが下がる（人に聞かなくて済む）
チャットボットには、忙しい同僚へ声をかける心理的負担や、同じことを再度聞く気まずさを減らす価値があります。一方、近くの先輩なら3秒で答えられる状況では、ボットを開いて入力する方が遅いこともあります。
この二つは矛盾しません。人へ聞きにくい、時間帯が合わない、回答が人で変わる質問をボットへ寄せ、即答できる現場知は会話を残します。導入前に、質問ごとに「人の方が速い」「ボットの方が聞きやすい」を分けます。
導入事例は削減率だけでなく工数の行き先まで見る
公表されている導入事例では、情シス・人事・総務への定型問い合わせの一次対応を肩代わりし、問い合わせ件数や対応時間の削減率で効果を示す型が一般的です。比較するときは他社の数字をそのまま自社へ当てはめず、部門、対象業務、導入前の件数・時間、導入後の件数・時間、測定期間を揃えて読みます。
| 部門 | 対象にしやすい業務 | 導入前に測る工数 | 導入後に確認する変化 | 削減後の時間の使い道 |
|---|---|---|---|---|
| 情シス | アカウント、端末、ソフトウェアの一次案内 | 受付、聞き取り、回答、引き継ぎの時間 | 自動回答で完了した割合と有人対応時間 | 障害予防、端末管理、セキュリティ改善 |
| 人事 | 休暇、勤怠、福利厚生、入退社案内 | 制度説明、規程検索、個別返信の時間 | 自己解決率と個別相談へ移った割合 | 制度改善、採用、育成、個別支援 |
| 総務 | 備品、施設、押印、郵送の案内 | 窓口対応、資料探索、担当振り分けの時間 | 定型質問の削減率と解決までの時間 | 職場環境の改善、申請手順の整理 |
削減率を出すだけでは、効果の説明は途中です。減った工数が、文書整備、予防対応、制度改善など何に振り替わったかまで記録すると、チャットボットが単なる窓口削減ではなく業務改善へつながったかを判断できます。
一方、この記事の発信元であるARCHECO（AIプロダクトの実装と運用を手がける会社）の社内RAG実測では、回答精度95%でも、公開から1か月でアクセスがほぼゼロになりました。削減率を測れる状態に至る前に、「置き場所」と「答えに着くまでの速さ」で利用が止まった例です。事例を評価するときは、精度や削減率に加え、普段の動線に入口があるか、回答表示まで何秒か、利用が継続したかを対比します。
導入した企業の事例
公表事例では、エス・エム・エスが営業部門の社内問い合わせへチャットボットを導入し、問い合わせ数を25%削減、事務処理を月400時間短縮したとしています。リコージャパン大阪支社の公表事例では、経理部門で公開後3か月に約1,300件がチャットボットへ寄せられ、部門代表電話が1日30〜40件から1〜2件程度になりました。
数値だけを自社の効果予測へ転用してはいけません。対象部門、導入前の問い合わせ経路、登録内容、周知方法が異なるためです。自社では導入前の問い合わせ件数と対応時間を同じ定義で測り、削減後の時間がどの業務へ移ったかまで確認します。
費用と導入形態
社内チャットボットの費用は、単一の相場では決まりません。初期設定、利用範囲、連携、運用支援で変わります。
費用相場は初期費用と月額費用に分けて比べる
費用は、環境構築や初期設定にかかる初期費用と、利用枠や保守運用にかかる月額費用に分けて考えます。初期費用には要件整理、FAQ・文書の整備、シナリオ作成、認証や連携の設定が含まれ得ます。月額費用には利用者数、質問数、生成AIの利用量、ログ保存、サポートが反映されます。見積書では、同じ作業が初期と月額のどちらに入っているかを揃えます。
価格の段を作る主な変数は、AI型かルール型か、標準機能で済むか個別カスタマイズが必要か、連携先がいくつあるか、部署・役職・雇用区分ごとに権限をどこまで細かく分けるかです。生成AI型ではモデル利用量と検索基盤の運用も加わります。「利用者数だけ」で相場を比べず、この変数ごとに必要・不要を決めて見積もります。
クラウド型とオンプレミス型
クラウド型は、提供事業者の環境を利用します。「まず一部門で始める」場合に選びやすい形です。
一方で、保存場所、学習利用の有無、ログの扱いを確認します。社内規程と合わなければ、利用できる文書を限定する判断も必要です。
オンプレミス型は、自社管理の環境へ置きます。運用方針に合わせやすい反面、保守範囲は広がります。「社内に置くから安全」とは限りません。
選択基準は機密性だけではありません。既存認証との接続、運用担当者、将来の用途を含めて比べます。
実務では、クラウド型なら障害対応、更新、バックアップをどこまで提供事業者が担うかを確認します。オンプレミス型なら、モデルや検索基盤の更新、監視、脆弱性対応を誰が担うかまで工数に含めます。
費用を動かす変数（対象業務数・連携先・権限管理）
費用を大きく動かすのは、対象業務数です。全社へ広げると、文書整理、評価、運用担当も増えます。
次が連携先です。社内チャット、文書保管、認証、申請システムとつなぐほど設計が増えます。「回答するだけ」と「申請まで進める」でも範囲は異なります。
権限管理も重要です。全社員が同じ文書を見るなら単純です。部署や役職ごとに検索対象を分けるなら、権限情報との連動が必要になります。
見積もりは、「何業務を扱うか」「何とつなぐか」「権限をどう分けるか」を揃えて比較します。
料金の考え方
料金は、初期構築、月額利用、利用量に応じた従量、運用工数に分けます。金額を動かすのは利用者数、質問回数、登録文書量、生成AIの処理量、外部連携、権限分割、サポート範囲です。
製品比較では同じ利用想定を渡し、初年度と平常年度を分けます。ツール料金だけでなく、文書整備、回答レビュー、問い合わせ窓口の工数を含めて総費用を見ます。
導入までにかかる期間
期間は製品の設定日数より、質問と正本資料の整理、権限確認、利用者テストで変わります。対象を一部門の頻出質問に絞れば短く始められますが、全社文書や業務連携を一度に含めると確認期間が延びます。
計画は「資料準備」「試作」「利用者テスト」「修正」「公開」に分け、各段階の完了条件を置きます。公開日を先に固定する場合は、未確認の文書を対象外にする判断も用意します。
トライアル・PoCで何を見るか
トライアルやPoC（概念実証）では、デモ質問の正答率だけを見ません。実際の言い換え、曖昧な質問、権限外の質問、根拠がない質問を入れ、止まり方と有人窓口への切り替えを確認します。
対象者を業務担当、一般利用者、運用担当に分け、回答到達時間、根拠の妥当性、未回答の分類、文書更新の手間を記録します。本導入の合否基準は開始前に決めます。
既製ツールを買うか、自社基盤を作るか
既製ツールは、用途が明確な場合に向きます。自社基盤は、文書や権限が複雑な場合に向きます。
判断の3軸：文書の更新頻度・権限の分割・広げる予定
判断軸は3つです。答えの元になる文書の更新頻度、部署別の閲覧権限、問い合わせ後の拡張予定です。
| 判断軸 | 既製ツールが向く場合 | 自社基盤が向く場合 |
|---|---|---|
| 文書の更新頻度 | 答えが固定的で、FAQを個別更新できる | 規程や手順書が頻繁に変わり、文書更新を回答へ反映したい |
| 権限の分割 | 利用者へ同じ情報を見せられる | 部署や役職ごとに検索対象を厳密に分けたい |
| 広げる予定 | 定型問い合わせへの回答で範囲が閉じる | 検索、要約、ドラフト生成へ同じ基盤を広げたい |
3軸のうち、1つでも右側に当てはまるなら、基盤構築が有力になります。個別更新や追加連携を重ねるより、文書と権限を共通化した方が総費用を抑えやすいからです。
ただし、対象文書が少なく、用途も固定なら既製ツールが合理的です。必要な運用を先に決めます。
基盤として構築する場合の中身はこちらで、文書検索、権限制御、業務への接続範囲を確認できます。
代表的な既製ツールのタイプ別整理
製品は複数タイプを兼ねます。以下は順位ではなく、公式サイトの公表機能による整理です。
- FAQ型を中心に見るなら、HiTTOがあります。社内情報をカテゴリで整理し、必要な回答を登録する社内向けAIチャットボットです。
- FAQ管理と社内チャット連携を見るなら、PEP AI-FAQがあります。FAQのタグ生成に加え、SlackやMicrosoft Teamsなどとの連携が案内されています。
- シナリオ型を含む対話設計を見るなら、ChatPlusがあります。シナリオ設定、ツリー編集、Q&A、有人対応などが公表されています。
- 生成AI型とQ&Aの併用を見るなら、WisTalkがあります。PDFやMicrosoft Office文書を回答用データとして準備でき、生成AI自動回答とQ&A検索の併用が案内されています。
比較時は「生成AI搭載」だけで決めません。回答の元、権限、出典、未回答時の動作を確認します。
Slack・Teamsなど普段のビジネスチャットと連携できるか
SlackやMicrosoft Teamsなど、普段使うビジネスチャットから質問できることは主要な選定軸です。別サイトへ移動せず、質問が生まれた場所で使えるため、利用までの動線を短くできます。
国内の社内連絡でLINE WORKSを使っている場合も同じです。Microsoft Teams、Slack、LINE WORKSのうち、既存の問い合わせが実際に集まる場所へ入口を置けるかを確認します。
連携の有無だけでなく、個人認証を引き継げるか、部署別権限が回答へ反映されるか、スレッド内で出典を開けるか、障害時の案内を出せるかを試します。通知を増やすのではなく、既存の質問先を置き換えられるかで判断します。
回答できないとき有人窓口へエスカレーションできるか
自動回答で解決できない質問を有人窓口へ渡す機能も、選定時に確認すべき軸です。緊急、個別判断、機密情報を含む相談は、無理に自動化せず担当者へ切り替えます。
確認するのは、単に連絡先を表示できるかだけではありません。質問文、参照済みの回答、利用者の同意を得た属性情報を引き継げるか、担当部署を自動で振り分けられるか、受付番号を返せるかを見ます。引き継ぎ後に同じ説明をやり直させないことが実務上の基準です。
導入で失敗しないポイント
導入前は質問とセキュリティを整理します。導入後は、利用動線と応答時間を見ます。
質問の洗い出しとセキュリティ確認
最初に、問い合わせ履歴から実際の質問を集めます。「よくある質問」だけでなく、「答えてはいけない質問」と「人へ渡す質問」も分けます。
評価には、略語、曖昧な表現、情報が足りない質問も含めます。正しさ、根拠、拒否の適切さを確認します。
セキュリティでは、データの保存先、通信、認証、権限、ログを見ます。また、入力内容がモデルの学習に使われるかも確認します。
しかし、確認票を埋めるだけでは運用できません。「機密情報を入力したらどうするか」「誤回答を誰が直すか」まで決めます。事故時の停止手順と連絡先も必要です。
公開は対象部署を絞ります。未回答ログを見て、文書不足と検索不良を分けます。
導入手順：小さく始めて運用を固める
社内チャットボットは、課題設定、質問収集、方式選定、構築、試験、公開、改善の順で進めます。最初から全社の質問を網羅せず、問い合わせ履歴に多い上位20〜30件からスモールスタートします。
1. 問い合わせ件数と検索時間を基に、対象部署と導入目的を決める
2. 頻出質問の上位20〜30件、根拠文書、答えてはいけない質問を揃える
3. 質問が定型か、文書が更新されるかを見て、AI型・FAQ型・シナリオ型を選ぶ
4. 権限、出典表示、有人窓口への切り替えを設定する
5. 実際の言い回しで試験し、限定公開する
6. 利用ログと未回答ログを見て、対象範囲を広げる
質問が定型ならFAQ型やシナリオ型、表現が多様で文書横断が必要なら生成AI型が基本です。方式ありきではなく、集めた質問から決めます。
導入規模は人数より質問の反復と業務の集中で決める
導入規模は従業員数だけでは決まりません。少人数でも、情シス・人事・総務の特定担当者へ同じ質問が繰り返され、回答の根拠文書があるなら対象になります。反対に、人数が多くても質問の大半が個別判断なら、自動回答できる範囲は限られます。
最初の規模は、対象部門を一つ、業務を一つに絞り、問い合わせ件数、対応時間、回答率、解決率を導入前後で比べられる範囲にします。人数ではなく、「反復する質問量」「文書を探す時間」「担当者への集中」の三つを基準に、効果を確認してから横展開します。
運用担当者を置き、レビュー頻度を決める
導入後の失敗要因として共通するのは、メンテナンスが止まることです。そのため、公開前に業務部門の運用担当者と、システム・セキュリティを支える担当者を置きます。
運用の軸は「元文書の更新者と回答の更新者を同じにする」です。規程を改訂した担当者が、FAQ、シナリオ、検索対象への反映まで完了させます。別担当にする場合も、元文書の更新を起点に自動で依頼が届く流れにします。
公開直後の1〜2か月は週1回、安定後は月1回を目安に、未回答、低評価、古い根拠、権限エラーをレビューします。制度改定や組織変更の直後は臨時レビューを行います。頻度は目安なので、質問量と更新頻度に合わせて調整します。
社内周知は初期1〜2か月の利用導線まで設計する
周知不足も、導入後に使われなくなる代表的な要因です。公開時には対象業務、使える質問例、回答できない範囲、有人窓口を社内ポータルやビジネスチャットで告知します。
ただし、告知を一度流すだけでは習慣になりません。初期1〜2か月は、従来の問い合わせ窓口で頻出質問を受けた際にチャットボットの回答リンクを返し、申請画面や規程ページにも入口を置きます。SlackやTeamsなら、質問が集まるチャンネルに固定し、別画面を探させません。
利用促進で効くのは、告知回数より「置き場所」と「答えに着くまでの速さ」です。起動数だけでなく、入口別の利用率と回答表示までの時間を見て、使われる導線へ寄せます。
未回答ログを定期抽出してFAQと文書を足す
未回答ログからFAQを追加することは、運用改善の基本です。公開直後は週1回、安定後は月1回を目安に抽出し、「回答元がない」「検索できない」「権限で見せられない」「人の判断が必要」に分類します。
回答元がない質問はFAQまたは元文書へ追加し、検索できない質問は表記ゆれや文書構造を直します。すべてを自動回答へ寄せず、人へ渡すべき質問はエスカレーション条件を整えます。
回答率には導入前に目標を置きます。ただし、拒否すべき質問まで回答させると数字だけが良くなるため、「回答対象の質問に対する有効回答率」と「有人対応へ正しく切り替えた率」を分けます。
KPIは削減だけでなく増えた行動も測る
効果測定では、問い合わせ件数、自己解決率、回答率、解決までの時間、利用率を追います。導入後に数字を眺めるのではなく、導入前の件数と時間を測り、対象部署と期間を揃えて目標を置きます。
回答率は「質問に何らかの回答を返した割合」、解決率は「回答後に有人窓口へ移らず目的を終えた割合」と定義して分けます。実務では、回答後の評価、同じ利用者の再質問、有人窓口への遷移をログで確認し、自社の導入前値を基準に改善幅を設定します。
投資回収を見るなら、削減率だけでは不十分です。「検索から原文を開いた回数」「不足文書を新規作成した件数」「要約やドラフトへ広がった利用」「新人が自己解決できた質問」など、導入によって増えた望ましい行動も測ります。
月次では、削減した対応時間と、文書整備・レビュー・基盤運用に使った時間を並べます。利用が増えても担当者工数が減らない場合は、個別判断の質問が多いのか、有人窓口への引き継ぎが重いのかを確認します。
使われなくなる本当の原因：精度ではなく置き場所と速さ
「FAQを登録すれば問い合わせは減る」という考えは間違いではありません。実際、削減効果は出ます。
ただ、ARCHECOの記録では、精度95%の社内RAGが公開から1か月でアクセスほぼゼロになりました。敗因は精度ではありません。「置き場所」と「速さ」でした。
チャットボットは、現場が普段使う動線にありませんでした。利用者は、別の画面を開いて質問する必要がありました。その手間だけで、従来の質問先へ戻ります。
さらに、近くの先輩は3秒で答えました。正確でも、開くまでに時間がかかる仕組みは選ばれません。利用を決めたのは、ベンチマーク上の精度ではなく「答えに着くまでの速さ」でした。
対策は、質問が生まれる場所へ置くことです。起動から回答表示までの待ち時間も測ります。
この実測は、公開済みの社内RAGが使われなくなる原因の記事にも記録しています。導入後は精度と同時に、アクセス数、再利用、回答までの動線を見ます。
使ってもらうための仕掛け
利用開始時は、マニュアル配布だけでなく、普段使うTeamsやSlack、社内ポータルなど目につく場所へ置きます。用途が分かる呼び名を付け、答えられる質問例と、答えられない場合の窓口を知らせます。
初週は部門会議で実演し、未回答へ早く対応します。周知回数ではなく、利用者が最初の成功体験へ到達したかを見て、検索語や入口を改善します。
この記事では、導入後に使われ続ける条件を語ります
ここまでが社内チャットボットの教科書です。この記事では、製品名の比較ではなく、導入後に使われ続ける条件と、問い合わせ削減の先にある投資回収を語ります。
問い合わせ削減で終わらせない（投資回収の設計）
問い合わせ削減は、導入効果を確認する分かりやすい出発点です。担当部門へ集中していた反復質問を減らせれば、日々の負担は確かに軽くなります。
問い合わせ削減だけでROIを測ると、多くの場合は合いません。一方で、文書整備、運用、評価の負担は続きます。
投資を回収するには、同じ基盤を別の業務へ広げる設計が要ります。規程の検索、議事録の要約、文書ドラフトの生成が候補です。「質問に答える仕組み」を「情報を使う仕組み」へ変えます。
用途ごとに別のAIを増やさず、文書の取り込み、権限管理、ログ、評価を共通化します。
ただ、何でも同時に始める必要はありません。最初は問い合わせ対応で、文書と権限の土台を作ります。次に検索、要約、ドラフトへ広げます。この順番で進めて初めて、投資に見合う範囲まで用途が広がります。
質問を洗い出す——履歴分析だけでは足りない
問い合わせ履歴には、実際に人へ聞いた質問しか残りません。聞く相手が分からず諦めた質問、検索で迷った言葉、新入社員だけが困る手順は漏れます。履歴分析に加え、利用者アンケート、担当者へのヒアリング、業務観察を組み合わせます。
実務では「直近で人に聞かず諦めたこと」「同じページを何度も探したこと」を尋ねます。集めた質問は件数だけでなく、解決しない場合の業務影響で優先順位を付けます。
まとめ：答えに着くまでの速さへ戻る
社内チャットボットを選ぶとき、精度や機能表だけでは利用の成否は決まりません。冒頭で触れた有給休暇や端末紛失の質問も、正しい答えが、質問が生まれた場所ですぐ返ることに価値があります。型を選び、権限と文書を整えたうえで、答えに着くまでの速さを実測することが選定の結論です。
この先：回答窓口から業務の入口へ
社内チャットボットは、質問への回答だけでなく、検索、要約、申請の入口を共通化する方向へ進みます。生成AI型と固定回答型の境界は残り、影響の大きい手続きほど人の承認も必要です。製品の機能数より、文書、権限、ログを次の用途へ再利用できる設計が重要になります。
よくある質問
社内チャットボットとは何ですか？
従業員の質問に自動で答える社内向けの窓口です。回答の元には社内規程、マニュアル、FAQなどを使い、有給休暇の申請方法や端末を紛失したときの連絡先といった質問に答えます。社外向けと違い、公開範囲の異なる文書や個社固有の略語を扱うため、認証、権限管理、ログ、更新責任まで設計対象になります。
3つのタイプはどう選び分けますか？
FAQ型、シナリオ型、生成AI型の3つがあり、選ぶ基準は答えの元になる文書が更新されるかです。答えがほぼ固定ならFAQ型やシナリオ型が向きます。規程や手順書が変わり続けるなら、文書の更新がそのまま回答の更新になる生成AI型が合います。実際の製品は複数方式を併用します。
費用相場はどのくらいですか？
実額の相場では比較できません。費用は環境構築などの初期費用と、利用枠や保守運用の月額費用に分けて考えます。金額を動かすのは、対象業務数、連携先の数、権限をどこまで細かく分けるか、標準機能で済むかどうかです。生成AI型ではモデルの利用量と検索基盤の運用も加わります。
AIチャットボットとは何が違いますか？
社内チャットボットは利用目的を示す言葉で、AIチャットボットは回答技術を示す言葉です。社内向けにはAI型とルール型の両方があります。生成AI型を選ぶ場合も全てを生成させる必要はなく、禁止事項は固定回答、検索結果には出典を表示、というように役割を分けます。
何人規模から導入すべきですか？
従業員数だけでは決まりません。少人数でも、情シスや人事の特定担当者へ同じ質問が繰り返され、回答の根拠文書があるなら対象になります。反対に人数が多くても、質問の大半が個別判断なら自動回答できる範囲は限られます。質問の反復、文書を探す時間、担当者への集中の3つで判断します。
導入しても使われなくなるのはなぜですか？
原因は精度ではなく、置き場所と答えに着くまでの速さです。回答精度95%の社内RAGが、公開から1か月でアクセスほぼゼロになった記録があります。別の画面を開く手間だけで従来の質問先へ戻り、近くの先輩が3秒で答えるなら正確でも選ばれません。質問が生まれる場所へ置き、回答表示までの時間を測ります。
既製ツールと自社基盤はどちらを選びますか？
判断軸は3つです。答えの元になる文書の更新頻度、部署別の閲覧権限、問い合わせ後の拡張予定です。文書が頻繁に変わる、権限を厳密に分けたい、検索や要約へ広げたい、のいずれかに当てはまるなら自社基盤が有力です。対象文書が少なく用途も固定なら、既製ツールが合理的です。
SlackやMicrosoft Teamsから使えますか？
普段のビジネスチャットから質問できることは主要な選定軸です。別サイトへ移動せず、質問が生まれた場所で使えるため動線が短くなります。連携の有無だけでなく、個人認証を引き継げるか、部署別権限が回答へ反映されるか、スレッド内で出典を開けるかまで試します。
効果はどう測ればよいですか？
問い合わせ件数、自己解決率、回答率、解決までの時間、利用率を、導入前の値と対象部署・期間を揃えて比べます。回答率と解決率は定義を分け、拒否すべき質問まで答えさせて数字だけ良くなる状態を防ぎます。削減した対応時間と、文書整備やレビューに使った時間も並べて見ます。
問い合わせ削減だけで投資回収できますか？
多くの場合は合いません。文書整備、運用、評価の負担は続くためです。回収するには、規程の検索、議事録の要約、文書ドラフトの生成など、同じ基盤を別の業務へ広げる設計が要ります。最初に問い合わせ対応で文書と権限の土台を作り、次に用途を広げる順番で進めます。
削減で終わらせない基盤設計から、ARCHECOは入ります。
Yuki Susai
柳田恒平
