問い合わせ対応をAIチャットボットで自動化する設計と導入手順

問い合わせ対応をAIで自動化するときに最初にやるべきことは、ツール選びではなく「どの問い合わせを、どこまでボットに任せるか」を決めることです。問い合わせの中身を種類ごとに分け、ボットが答えてよい範囲と、必ず人が受けるべき範囲を線引きし、その境目で人へスムーズに引き継げる設計にしておけば、生成AIのチャットボットは窓口の負担を確実に減らします。逆にこの線引きを曖昧にしたまま導入すると、答えられない質問に無理に答えてしまう、利用者がボットとのやり取りに疲れて結局電話をかけてくる、といった形で、かえって対応コストが増えることがあります。

この記事は、カスタマーサポートや問い合わせ窓口の責任者、問い合わせ対応の効率化を任された事業担当者、そしてAIチャットボットの導入を検討している経営者に向けて書いています。問い合わせの棚卸しと分類の方法、FAQやナレッジの整え方、回答範囲の決め方、有人対応への引き継ぎ設計、公開前の評価と公開後の改善までを、導入の順番に沿って説明します。

読み終えたときに、自社の問い合わせのうちどこから自動化を始めるべきか、導入前に何を準備すればよいか、どんな状態なら公開してよいかを判断できることを目指しています。

問い合わせ対応のAI自動化でできること・できないこと

最初に、生成AIを使ったチャットボットが問い合わせ対応で得意なことと苦手なことを整理しておきます。ここを把握しておくと、後の「回答範囲の線引き」が判断しやすくなります。

得意なのは、手元にある文書やFAQの内容を、質問者の言葉づかいに合わせて言い換えながら答えることです。従来のシナリオ型チャットボットは、用意した選択肢やキーワードに当てはまらない質問には答えられませんでしたが、生成AI型は「返品ってできますか」「届いた商品が違ったんですけど」のように表現が揺れていても、意図を汲み取って該当する案内を返せます。営業時間外や深夜の一次対応、同じ質問の繰り返しへの対応、問い合わせフォームに書く前の自己解決支援などで効果が出やすい領域です。

苦手なのは、手元の情報にないことを正確に答えること、個別の契約内容や注文状況を確認して判断すること、感情的になっている相手をなだめること、そして例外的な判断が必要な対応です。生成AIはもっともらしい文章を作るのが得意な分、根拠のない回答も自然な文章で出してしまいます。返金の可否や補償の約束、法的な見解のように、間違えると損害や信頼低下につながる内容は、仕組みとしてボットに答えさせない設計が必要です。

生成AI型とシナリオ型の違いや作り方の全体像は、AIチャットボットの作り方：シナリオ型と生成AI型の違いと選択で詳しく扱っています。

導入前に問い合わせを棚卸しして分類する

自動化の対象を決めるために、まず直近の問い合わせを棚卸しします。メール、フォーム、電話の対応記録、チャットのログなど、手元にある記録をできるだけ集めます。量が多い場合は、直近数か月分から一定数を抜き出して分類するだけでも傾向はつかめます。

分類の軸を決める

分類は「何についての問い合わせか（テーマ）」と「答えるために何が必要か（必要情報）」の二つの軸で行うと、自動化の判断に直結します。

テーマの例は、料金・支払い、配送・納期、使い方・操作方法、アカウント・ログイン、解約・変更、不具合報告、要望・意見などです。必要情報の軸は、次の四段階に分けると整理しやすくなります。

1. 公開情報だけで答えられる（FAQや利用規約、マニュアルに書いてある）
2. 社内文書を見れば答えられる（公開していない手順書や社内ルールが必要）
3. 個別のデータを見ないと答えられない（注文状況、契約プラン、利用履歴など）
4. 人の判断が必要（例外対応、補償、クレーム、法的判断など）

1はボットの最初の対象です。2は社内文書を整備して参照させれば対象になります。3はシステム連携と本人確認の設計が必要なので、初期段階では「確認方法の案内」までにとどめるのが現実的です。4はボットに答えさせず、有人へ引き継ぐ対象として扱います。

件数と手間で優先順位をつける

分類ができたら、テーマごとに「件数」と「1件あたりの対応の手間」を大まかに見積もります。件数が多く、答えが公開情報で完結し、1件あたりの手間は小さくても繰り返しが負担になっている領域が、最初に自動化すべき候補です。件数は少なくても1件ごとに調べ物が多い問い合わせは、ボットよりも担当者向けの検索支援の方が効果が出る場合があります。

例えば、架空の例として、会員制のオンライン学習サービスを運営する会社を考えます。問い合わせを分類したところ、「ログインできない」「領収書の発行方法」「プラン変更の手順」が件数の上位を占め、どれもヘルプページに答えが書いてあったとします。一方で「受講期限を延長してほしい」という相談は件数こそ少ないものの、個別の事情を聞いて判断する必要がありました。この場合、前者の三つをボットの初期対象にし、期限延長は「担当者が個別に確認します」と案内して有人に引き継ぐ、という切り分けになります。

FAQとナレッジを整備する

生成AIのチャットボットは、参照する情報の質以上の回答はできません。ボットの精度を決めるのは、モデルの性能よりもFAQやマニュアルの整い具合であることがほとんどです。

回答の元になる文書を一か所に集める

ヘルプページ、利用規約、料金表、社内の対応マニュアル、過去の回答テンプレートなど、回答の根拠になる文書を洗い出し、どれを正とするかを決めます。同じ内容が複数の場所に書かれていて食い違っている状態は、ボット導入前に必ず解消しておきます。古い料金表と新しい料金表が両方残っていると、ボットはどちらを根拠にするか判断できません。

社内文書を検索して回答させる仕組みは一般にRAGと呼ばれ、文書の集め方や分け方が回答精度に直結します。

FAQは「質問の言い方」と「答えの条件」を書く

ボット向けにFAQを整備するときは、人が読むFAQとは少し書き方を変えます。ポイントは次の三つです。

• 一つの項目には一つの質問と一つの答えだけを書く。複数の条件分岐を一項目に詰め込まない
• 質問者が実際に使う言い方を併記する（「解約」「退会」「やめたい」「止めたい」など）
• 答えが変わる条件を明記する（「年額プランの場合は」「購入から○日以内であれば」のように、条件の書き方そのものを明確にする）

FAQを「人が読んで分かる」から「機械が参照しても誤解しない」水準に引き上げる作業は地味ですが、ここに時間をかけるほど公開後の修正が減ります。

更新の担当と手順を決める

料金改定や仕様変更があったとき、誰がどの文書を更新し、ボットにいつ反映するのかを決めておきます。更新の仕組みがないと、公開直後は正確だったボットが数か月後には古い情報を案内するようになります。

回答範囲の線引きとボットの振る舞いを決める

棚卸しと文書整備ができたら、ボットが「答えること」「答えずに案内すること」「答えずに人へ引き継ぐこと」を明文化します。これはボットの仕様書の中心になる部分です。

三つの対応区分を定義する

振る舞いのルールを文章にする

生成AIに対しては、システムプロンプトで振る舞いのルールを与えます。例えば「参照文書に書かれていないことは推測で答えず、分からないと伝える」「料金や期限は必ず参照文書の表記どおりに答える」「返金や補償を約束する表現は使わない」「怒りや不満が強い場合は謝意を示したうえで担当者への引き継ぎを提案する」といったルールです。

ただし、プロンプトの指示だけで完全に制御できるわけではありません。重要な制約は、特定の話題を検知したら回答生成をせず定型文を返す、根拠となる文書が見つからない場合は回答しない、といった仕組み側の制御と組み合わせます。こうした安全装置はガードレールと呼ばれます。

有人対応への引き継ぎを設計する

問い合わせ対応の自動化で利用者の満足度を左右するのは、ボットが答えられなかったときの体験です。「分かりません」で終わる、同じ説明を最初から繰り返させられる、引き継ぎ先が見つからない、という状態はボットがない場合よりも不満が大きくなります。

引き継ぎの設計では、次の三点を決めます。

1. 引き継ぐ条件：利用者が人との対応を求めたとき、同じ質問が繰り返されたとき、特定の話題（返金、解約の引き止め、事故、個人情報など）が出たとき、ボットの回答に対して否定的な反応が続いたとき
2. 引き継ぎの手段：営業時間内ならチャットで有人に切り替える、時間外ならフォームやメールで受け付けて返信時期を伝える、緊急性が高い内容は電話番号を案内する
3. 引き継ぐ情報：会話の要約、利用者が入力した情報、ボットが提示した回答、分類結果。担当者が最初から聞き直さずに済む状態にする

エスカレーションの条件や引き継ぎ情報の具体的な設計は、チャットボットから有人対応へ：エスカレーション設計の勘所で詳しく解説しています。

導入手順：小さく始めて段階的に広げる

ここまでの準備を踏まえ、導入は次の順番で進めます。最初から全テーマを対象にせず、効果が見えやすい範囲から始めて広げるのが基本です。

1. 目的と指標を決める：問い合わせ件数の削減、時間外の自己解決、担当者の対応時間短縮など、何を良くしたいのかを一つか二つに絞る
2. 初期対象のテーマを選ぶ：棚卸しで選んだ、件数が多く公開情報で答えられるテーマに限定する
3. 参照文書を整備する：対象テーマのFAQとマニュアルを、前述の書き方で整える
4. 回答範囲と引き継ぎ条件を決める：三つの対応区分と引き継ぎの手段・情報を文書化する
5. 評価用の質問セットを作る：過去の実際の問い合わせから、回答すべきもの・引き継ぐべきもの・答えてはいけないものを混ぜて用意する
6. 試作して社内で試す：担当者が利用者になりきって質問し、回答の正確さと引き継ぎの動きを確認する
7. 限定公開する：特定のページや一部の利用者だけに公開し、ログを確認する
8. 本公開と改善のサイクルを回す：回答できなかった質問、低評価の回答、引き継ぎ理由を定期的に見直し、文書とルールを更新する

5の評価用質問セットは、公開判断の基準になる重要な準備です。質問セットは一度作って終わりではなく、公開後に寄せられた実際の質問のうち、答えられなかったものや誤答したものを追加していくと、改善のたびに同じ基準で良くなったかどうかを確かめられます。7の限定公開では、対象のページを絞るほか、ボットの回答の下に「解決した・解決しない」のボタンを置き、利用者の反応を集めておくと本公開の判断材料になります。生成AIの出力をどう採点するかは、生成AIの出力品質をどう評価するかで詳しく扱っています。

公開前チェックリスト

限定公開や本公開の前に、次の項目を確認します。

• 評価用の質問セットで、回答すべき質問に正しく答えられている
• 参照文書にない質問に対して、推測で答えず「分からない」と伝えている
• 返金・補償・法的判断に関わる質問で、約束や断定をしていない
• 引き継ぎの条件に当てはまる会話で、有人窓口が案内されている
• 時間外の引き継ぎで、返信の目安と受付方法が伝わっている
• 引き継ぎ時に会話の要約と入力情報が担当者に渡っている
• 利用者が個人情報を入力した場合の扱いが決まっていて、利用目的が表示されている
• 会話ログの保存期間と閲覧できる人が決まっている
• 参照文書の更新手順と担当者が決まっている
• ボットであることが利用者に分かる表示になっている

よくある失敗と避け方

全部の問い合わせを最初から対象にする

対象を広げすぎると、文書整備が追いつかず、どのテーマも中途半端な精度になります。最初は件数上位の数テーマに絞り、精度が安定してから広げます。

ボットの回答を正解かどうかだけで評価する

正確に答えた回答でも、利用者が知りたかったことに届いていなければ、結局問い合わせは発生します。ボットの会話後にフォームや電話での問い合わせがあったかどうか、つまり「その会話で解決したか」を追える仕組みを用意しておくと、改善の手がかりが増えます。

引き継ぎ先の体制を変えずに導入する

ボットから有人へ引き継がれた問い合わせは、ボットが答えられなかった難しい内容が中心になります。担当者の一件あたりの対応時間はむしろ長くなることもあるため、引き継ぎ後の対応手順や人員の配置も合わせて見直します。

公開後のログを見ない

公開して終わりにすると、回答できなかった質問が蓄積されるだけで精度は上がりません。週に一度など頻度を決めて、未回答の質問と低評価の回答を確認し、FAQの追加や修正につなげます。ログの確認から改善までを担当者の業務として位置づけることが大切です。

チケット管理と切り離して考える

ボットの会話と、有人対応の記録が別々の場所にあると、同じ利用者の問い合わせを追えなくなります。既存の問い合わせ管理の仕組みとの連携は早い段階で検討します。サポート全体の自動化の考え方はカスタマーサポート対応の自動化：チケット分類と回答下書きのAI活用も参考になります。

よくある質問

Q. 問い合わせ件数が少なくてもAIチャットボットを入れる意味はありますか？

件数が少ない場合、ボット導入の手間に見合う削減効果は出にくいことがあります。ただ、営業時間外の問い合わせが機会損失になっている、少人数で対応していて担当者が本来業務に集中できない、といった事情があれば検討の価値はあります。まずはFAQページの整備と検索性の改善から始め、それでも同じ質問が繰り返されるならボットを検討する、という順番も有効です。

Q. 既存のFAQページがあれば、すぐにボットを公開できますか？

既存のFAQをそのまま参照させても動きはしますが、人が読む前提で書かれたFAQは、条件分岐が一つの項目に混在していたり、古い情報が残っていたりすることが多く、そのままでは誤回答の原因になります。対象テーマのFAQを見直し、評価用の質問で確認してから公開することをおすすめします。

Q. 生成AIが間違った回答をしたときの責任はどう考えればよいですか？

ボットの回答も企業の案内として受け取られるため、誤った案内による影響は運営者が負うことを前提に設計します。重要な判断を伴う質問は答えさせない、回答には参照元を示す、ボットの回答であることを明示する、といった対策を組み合わせます。利用規約や表示の文言については、法務の専門家に確認してください。

Q. 開発せずにSaaSのチャットボットツールで済ませてもよいですか？

対象が公開FAQの範囲で、既存システムとの連携が不要なら、SaaSのツールで十分なことは多いです。注文状況の照会や社内システムとの連携、独自の引き継ぎフローが必要になると、個別開発やカスタマイズが選択肢に入ります。比較の考え方はAIチャットボット導入の費用：SaaS利用と個別開発の比較で解説しています。

Otsumuに相談できること

問い合わせの種類が限られていて、公開しているFAQで答えが完結し、既存システムとの連携も必要ないのであれば、市販のチャットボットツールを使って自社で導入することは十分可能です。この記事の棚卸しと分類、FAQの書き直し、回答範囲の線引きを社内で進め、限定公開から始めれば、外部に頼まなくても成果を出せるケースは少なくありません。

一方で、注文や契約のデータと連携して個別の状況に答えたい、社内の手順書や過去の対応記録まで参照させたい、有人対応への引き継ぎを既存の問い合わせ管理と連動させたい、といった要件がある場合は、設計と開発の工夫が必要になります。また、どの問い合わせから自動化すべきか、社内で判断がつかないときも、外部の視点を入れた方が早く進むことがあります。

Otsumuでは、問い合わせの棚卸しと回答範囲の設計から、生成AIを使ったチャットボットの開発、公開後の改善までを一貫して支援しています。目的から逆算して必要な機能に絞り、AIを活用した少人数の開発で、小さく試して効果を確かめながら広げる進め方を取ります。詳しくはAIチャットボット開発のページをご覧ください。

自社の問い合わせのどこから自動化できそうか、まずは状況を伺いながら一緒に整理することもできます。30分の無料相談からお気軽にご連絡ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01