「同じ質問への回答に毎日追われている」「夜間や休日の問い合わせを翌営業日まで待たせてしまう」。こうした問い合わせ対応の負担を減らす手段として、AIチャットボットを検討する企業が増えています。ただし、どこまで自動化できるかは問い合わせの内容やFAQの整備状況で変わり、導入すれば一定の削減率が得られるものではありません。
この記事では、中小企業が問い合わせ対応を安全に自動化するための進め方を、FAQ整備、方式の選び方、有人対応への引き継ぎ、個人情報の扱い、効果測定の順に整理します。チャットボットの種類と費用の目安を先に知りたい方は、AIチャットボットの種類と費用の目安をまとめた記事もあわせてご覧ください。
問い合わせ対応で起きやすい課題
問い合わせを人手だけで受けている企業では、次のような課題が起きやすくなります。まず対応時間です。内容の確認、回答の調査、返信文の作成、送信前の確認と作業が続くため、問い合わせが集中する時間帯や繁忙期には、返信が遅れることがあります。
次に属人化です。経験のある担当者なら早く正確に答えられる質問でも、その人が不在だと他のスタッフが答えられなかったり、回答の内容にばらつきが出たりします。担当者の退職で対応のノウハウが失われることもあります。
さらに営業時間外の空白があります。営業時間外の問い合わせには翌営業日まで返信できないため、急いでいる顧客を待たせてしまいます。ECサイトや予約サービスでは、購入や予約の判断に影響することもあります。
AIチャットボットの仕組みと方式の違い
チャットボットの回答方式は、大きく3つに分けて考えると整理しやすくなります。製品によっては複数の方式を組み合わせており、機能や費用は製品とプランごとに異なります。
| 方式 | 回答の作り方 | 必要な準備 | 得意なこと | 失敗しやすい点 |
|---|---|---|---|---|
| ルール/シナリオ型 | あらかじめ設計した分岐や選択肢に沿って案内する | 会話の流れと回答文の設計 | 手順が決まっている案内、受付項目の聞き取り | 想定外の質問に答えられない |
| FAQ検索型 | 登録したQ&Aから、質問に近いものを探して返す | Q&Aの整備、言い換えの追加 | 営業時間、送料、操作方法など定型の質問 | 登録がない質問や、複数の内容を含む質問に弱い |
| 生成AI型(RAG構成を含む) | 生成AIが文章を生成する。RAGを組み合わせる場合は、関連する承認済み文書を検索して回答の根拠として用いる | 回答範囲の設定、評価。RAGを使う場合は参照文書の整理と公開範囲の管理 | 言い換えの多い質問、文書をまたぐ説明 | 誤回答、古い文書の参照、情報の取り違え |
自然言語処理や生成AIを利用すると、「返品したい」「商品を送り返すには」のような言い換えを含む質問に対応しやすくなります。ただし意図の取り違えや誤回答が起きるため、実際の問い合わせパターンで検証し、回答できない質問は有人対応に切り替える設計が必要です。
有人対応への引き継ぎを設計する
自動化の範囲と同じくらい重要なのが、人に引き継ぐ条件です。感情の読み取りに頼るよりも、まず次のような明示的なルールを決めておくと運用が安定します。
- 利用者が担当者との会話を希望したとき
- 同じ内容で回答が解決につながらないやり取りが続いたとき
- 料金、契約、返金、障害、苦情に関する内容のとき
- 本人確認が必要な内容のとき
- 参照できる根拠が見つからないとき
AIによる感情推定を組み込める製品もありますが、誤判定があるため補助的なシグナルとして扱います。怒りや緊急性を正確に判定できるものではなく、これだけでクレームの深刻化を防げるわけでもありません。
チャットの履歴を担当者に引き継げるかどうかは、製品の機能と連携の設定、担当者の閲覧権限によって異なります。導入前に、担当者の画面に何が表示されるかを確認してください。
夜間の対応も分けて考えます。チャットボットが夜間にできるのは、自動の受付と一次回答です。有人の判断が必要な問い合わせは、夜間に解決するわけではありません。「翌営業日に担当者から連絡します」のように、次の対応と時期を利用者に示しておきます。
生成AI・RAGを使うときの設計
生成AIを使う際、AIモデルの外にある文書(FAQやマニュアルなど)を検索し、回答の根拠として参照する構成にRAG(検索拡張生成)があります。すべての生成AIチャットボットがRAGを実装しているわけではありません。経済産業省のAI事業者ガイドライン(第1.2版)でも、RAGの活用によるハルシネーション(もっともらしい誤回答)の抑制や、根拠の透明性向上が期待されるとしています。ただし、文書を読み込ませただけで正確に答えられるようになるわけではなく、RAGを使っても誤回答や情報漏えいを完全には防げません。
社外向けに使う場合は、次の点を設計します。
- 参照文書の鮮度と公開範囲:古い文書や社外秘の文書を検索対象に入れない
- 根拠の表示:回答の元になった文書やページを示し、利用者と担当者が確認できるようにする
- 回答できないときの動作:根拠が確認できない場合は回答を作らず、「確認できないため担当者に引き継ぎます」と案内する
- 変動する情報の照合:料金、在庫、納期、返品条件などは、最新の承認済み情報や、権限を設定した社内システムと照合する
- 処理の実行:返品受付、返金、個人情報の閲覧、契約変更などは、本人確認、API側の認可、利用者の確認、必要に応じて有人の承認を前提にする
導入ステップ──FAQ整備から試験・運用まで
ツールを選ぶ前の準備が、回答の品質を左右します。次の4ステップで進めます。
頻度・難度・機密性で質問を分類
機能・費用・データの扱いを比較
評価用の質問で検証し範囲を限定
責任者を決めログとFAQを見直す
ステップ1:FAQ整備
メールや電話の記録など過去の問い合わせを、頻度、回答の難しさ、機密性、更新の頻度で分類します。頻度が高く、機密性が低く、回答が変わりにくい質問から自動化の候補にします。実データを分析するときは、氏名や連絡先などをマスキングしておきます。
回答文には、管理責任者、最終確認日、出典(利用規約、最新のヘルプなど)を持たせます。社内の手順書を元にする場合は、AIで業務マニュアルを更新・管理する方法も参考にしてください。
ステップ2:ツール選定
料金、問い合わせチャネル、有人への引き継ぎ、CRM連携、ログと保持期間、権限、AI学習の利用条件、利用上限、対応言語を比較します。確認項目と製品の例は、後の「製品を比較するときの確認項目」で整理します。
ステップ3:小規模な試験
公開範囲を一部のページや社内利用に絞り、評価用の質問セットで確認します。試験の期間は固定せず、問い合わせの量を見て、判断に足りる件数が集まる長さに設定します。評価セットには次のパターンを含めます。実データを使う場合は、プライバシーへの対策も行います。
- 典型的な質問、言い換え、誤字を含む質問
- 1回の入力に複数の用件が入った質問
- 参照できる根拠がない質問
- 規約や料金の変更前後で答えが変わる質問
- 本人確認が必要な質問、クレーム
- AIへの指示を書き換えようとする悪意のある入力
ステップ4:運用体制の整備
導入後の体制も決めておきます。回答の責任者、ログを確認する担当と頻度、FAQを更新するタイミング(料金改定、新商品、規約変更など)、重大な誤回答が見つかったときの停止と是正の手順です。必要な保守の工数は、問い合わせの量と情報の更新頻度によって異なります。
問い合わせログの分類や、追加すべきFAQ候補の抽出にAIを使える製品もあります。提案された内容は、担当者が確認してから反映します。
業種別:どんな質問を自動化しやすいか
以下は想定される流れの例です。実装済みの仕組みや当社の実績、改善の達成を示すものではありません。
| 業種 | 自動化しやすい質問 | 慎重に設計する質問 | 有人対応を検討する場面 |
|---|---|---|---|
| EC | 営業時間、送料、返品の手順、注文状況の確認ページへの案内 | 個人の注文状況の提示(認証と権限の確認が必要) | 返金の可否、配送事故、苦情 |
| SaaS | 機能の使い方、ヘルプ記事への案内 | 解約、契約条件、請求(本人確認や有人対応の要否を判断する) | 障害、データに関する相談、契約の変更 |
AIチャットボット導入時の個人情報保護とセキュリティ
チャットボットは便利な窓口である一方、個人情報を扱う業務システムでもあります。ここでは一般的な確認事項を整理します。個別の判断は、利用するサービスの契約内容を確認したうえで、必要に応じて専門家にご相談ください。
問い合わせ履歴に含まれる情報
問い合わせ履歴には、氏名、メールアドレス、電話番号、注文番号、契約情報、相談内容などが含まれることがあります。FAQの分析に使う前に、マスキング、匿名化や仮名化を検討し、チャットで集める項目も必要最小限にします。
あわせて、利用目的の特定と通知・公表、ログの保存期間、アクセス権限、契約終了時のデータの出力と削除、委託先の管理についても確認します。
外部の生成AIサービスに個人データを入力するとき
個人情報保護委員会のよくある事例集では、生成AIサービスに個人情報を含むプロンプトを入力する場合、特定した利用目的の達成に必要な範囲内であることを十分に確認し、個人データを含む場合は、サービス提供事業者がそのデータを機械学習に利用しないこと等を十分に確認する必要があるとしています。2023年6月の注意喚起では、本人の同意なく入力した個人データが、応答結果の出力以外の目的で取り扱われる場合、法の規定に違反する可能性があることも示されています。
実務では、契約条件と管理画面の設定で、入力データの学習利用の有無、保存の有無と期間を確認します。第三者提供や外国での取扱いに関する確認が必要かどうかは、サービスの提供形態によって異なるため、個別に検討します。常に同意が必要というわけではなく、同意があれば何でも許されるわけでもありません。
なお、2026年7月に改正個人情報保護法が公布され、政令・規則・ガイドライン等の整備が進められています。導入時には最新の公表内容を確認してください。
利用者への案内
AIが対応していること、担当者への問い合わせ経路、有人の対応時間、入力された情報の使い方を、チャットの画面などで分かりやすく示します。AI事業者ガイドラインでも、AIの利用にあたって適切なタイミングで人間の判断を介在させることや、関係者への適切な情報提供が挙げられています。
RAGの権限設計とセキュリティ対策
RAGでは、検索の対象がそのまま回答の材料になります。社外に公開してよい文書かを確認し、社内の機密情報が混ざらないようにします。会員向けに使う場合は、ユーザーごとの参照権限と、履歴の表示範囲も設計します。
技術面の参考としては、OWASPのTop 10 for LLM Applicationsがあります。プロンプトインジェクション(入力や参照文書に紛れた指示で、本来の制約を外させようとする攻撃)、機密情報の漏えい、過剰な権限の付与、誤情報などのリスクが整理されています。次の対策を確認しておきます。
- 入力や参照文書の内容を信頼せず、AIに渡す権限を必要最小限にする
- 機密情報を誤って出力しないよう、参照先と出力を制御する
- APIキーを画面側のコードに置かず、サーバー側で管理する
- ログを監査できるようにしておく
- 依存するサービスの障害時に備え、フォームや電話など代替の経路を用意する
取引先からセキュリティ対策の説明を求められる場合は、セキュリティチェックシートへの回答の考え方も参考になります。
製品を比較するときの確認項目
シナリオ型やFAQ型と生成AI型では、できることが異なります。製品名やランキングから選ぶ前に、次の確認項目で自社の要件と照らし合わせます。
| 確認項目 | 確認すること |
|---|---|
| 回答方式 | シナリオ、FAQ、生成AIのどれか。回答範囲を限定できるか |
| チャネル | Webチャット、LINE、メール、電話など、自社の窓口に対応するか |
| 有人引き継ぎ | 引き継ぎの条件設定、履歴の共有、営業時間外の動作 |
| 連携 | CRM、注文管理、予約などとの連携方法と権限 |
| データの扱い | AI学習への利用条件、ログの保持期間、データの削除、管理者権限 |
| 課金 | 席数、会話数、解決件数、API利用量のどれに応じて増えるか。利用上限 |
| 対応言語 | 必要な言語と、自社の用語での回答精度。自社の質問で検証する |
参考として、4製品について、各社の公式情報で確認できた範囲を整理します(確認日:2026年11月6日)。特定の製品を推奨するものではなく、日本語の精度や費用の優劣を比較したものでもありません。機能と料金は変更され、プランによっても異なるため、導入時には最新の公式情報を確認してください。
| 製品 | 公式情報で確認できた特徴 | 有人対応 | 料金の情報 |
|---|---|---|---|
| Zendesk | 問い合わせ管理の機能を持つカスタマーサービス製品。AIエージェントを提供 | AIで解決できない場合に担当チームへ引き継ぐと案内 | 公式の料金ページに掲載。AIエージェントは自動解決ごとの従量課金と説明 |
| Intercom | RAGを用いるAIエージェント「Fin」を提供 | 有人を希望された場合などのエスカレーションを説明 | 成果ごとの課金。回答後に追加の支援要請がないケースに加え、設定した手順による有人引き継ぎや見込み客の選別など、複数の成果区分が課金対象となる場合がある。区分・単価・契約条件は公式情報で確認 |
| ChatPlus(チャットプラス株式会社) | 有人対応を含む対話プラットフォーム「Chat Plus」、生成AIを使う「AI Agent Plus」などを提供 | AI Agent Plusの紹介で、有人への切り替えを説明 | 公式サイトと資料で要確認 |
| hachidori | LINE、Webチャット、LINE WORKSに対応するチャットボット開発ツール。機能ページにシナリオ、FAQ、外部システムとのAPI連携を掲載。生成AIによる回答機能の記載は確認できず | チャットボットと有人チャットの組み合わせを掲載 | 公式サイトに記載なし。問い合わせで確認 |
「解決」の定義も製品によって異なります。Intercomのように、追加の依頼がなければ解決として扱う考え方の場合、利用者があきらめて離脱した会話が含まれる可能性もあります。製品の画面に出る解決率と、次章で扱う自社の自己解決率は分けて確認します。また、Intercomの説明では、設定した手順による引き継ぎと、既定の動作によるエスカレーションで課金の扱いが異なります。「解決」の定義や課金条件は製品ごとに異なるため、単純には比較できません。
導入効果を評価するKPIと費用対効果
効果は他社の数値ではなく、自社の導入前後の実測で判断します。分母、比較期間、集計対象を揃えたうえで、自動化の割合と品質の両方を見ます。
| KPI | 定義・注意点 |
|---|---|
| 一次回答率 | 受け付けた問い合わせのうち、チャットボットが最初の回答を返した割合。解決率ではない |
| 自己解決率 | ボットとのやり取りの後、追加の有人対応や再問い合わせなしで解決した割合。観測する期間と確認方法を決めておく |
| 有人引き継ぎ率 | 総対応件数に占める、担当者への引き継ぎ件数の割合。極端に低ければ良いわけではない(引き継ぎが必要な問い合わせを止めている可能性がある) |
| 誤回答率・再問い合わせ率 | 人によるレビューなどで測る。自動化率だけでなく、品質の悪化を監視する |
| 平均対応時間 | ボット、有人、転送、回答のレビューを含め、集計対象と比較期間を揃える |
| 顧客満足度(CSAT等) | 実測のアンケートで測る。回答数と調査方法も確認する |
| 運用費用 | サービス利用料、従量課金、API費用、初期構築費、保守運用に要する人件費。工数削減額との重複計上に注意 |
工数削減と費用対効果の考え方
導入の効果は、同じ対象・同程度の問い合わせ量を比較して評価します。有人対応、転送後の対応、誤回答の訂正、FAQ更新・品質監査などの作業を、重複しない区分で集計してください。
削減できた総作業時間 = 導入前の問い合わせ対応作業時間 −(導入後の有人対応作業時間 + 導入によって新たに必要になった品質監査・FAQ更新などの作業時間)
この差を人件費単価で換算すると、再配置可能な労働時間の経済価値を推定できます。ただし、人員配置や勤務時間が変わらなければ、同額の現金支出削減を意味するとは限りません。
費用対効果を比較する際は、システムの月額料金、従量課金、API利用料、初期設定費用なども別途考慮します。人件費は、作業時間の換算と費用項目で二重に計上しないようにしてください。費用の目安は、導入形態別の費用の目安も参考にしてください。
まとめ
AIチャットボットによる問い合わせ対応の自動化は、定型の質問への一次回答を任せ、人が判断すべき問い合わせに時間を使うための取り組みです。FAQ整備、ツール選定、小規模な試験、運用体制の整備の順に進め、根拠のない質問や本人確認が必要な内容は有人対応へ引き継ぐ設計にします。
個人情報の扱い、誤回答への対策、効果の測り方は、導入前に決めておきます。まずは過去の問い合わせを分類し、自動化しやすい質問と人が答えるべき質問を分けるところから始めてみてください。
株式会社アイ・エス・プライムでは、ツール選定や社内のAI利用ルール整備のご相談から、LLM APIを活用した業務自動化システムの設計・開発まで対応しています。「どこまで自動化すべきか分からない」という段階でもご相談ください。





