AIチャットボットの作り方は、大きく「シナリオ型」と「生成AI型」の二つに分かれます。シナリオ型は、あらかじめ用意した質問と回答の流れに沿って、決められた答えを返す仕組みです。生成AI型は、利用者の自由な質問を理解し、資料をもとに文章を生成して答える仕組みです。どちらが優れているかではなく、回答に求められる正確さ、質問の幅、運用にかけられる手間によって向き不向きが決まります。
結論から言えば、答えが決まっていて誤りが許されない手続きの案内や、選択肢を順にたどる受付はシナリオ型、質問の言い回しや内容が幅広く、資料をもとに柔軟に答えたい問い合わせは生成AI型が向いています。実務では、両者を組み合わせ、定型の手続きはシナリオで確実に案内し、それ以外の質問を生成AIで受け、答えられない場合は人に引き継ぐ構成がよく採られます。
この記事は、問い合わせ対応や社内ヘルプデスクの負担を減らすためにチャットボットの導入を検討している方、既存のシナリオ型チャットボットを生成AI型に置き換えるか迷っている方に向けています。両者の違い、用途別の選び方、作り方の手順、公開後の改善方法、よくある失敗までを順に解説します。
シナリオ型と生成AI型の違い
シナリオ型チャットボット
シナリオ型は、「質問のカテゴリを選んでください」→「料金について」→「プランの変更方法」といったように、選択肢やキーワードで分岐をたどり、用意された回答を表示します。用語としては シナリオ型チャットボット と呼ばれます。
- 回答は人が書いたものなので、内容の正確さを管理しやすい
- 想定していない質問には答えられない
- 分岐が増えると、シナリオの作成と更新の手間が増える
- 利用者が自分の質問に合う選択肢を探す必要がある
生成AI型チャットボット
生成AI型は、利用者が自由に入力した質問を理解し、社内のマニュアルやFAQなどの資料を検索して、その内容をもとに回答の文章を生成します。資料を検索して回答に使う仕組みは、検索拡張生成（RAG）と呼ばれます。
- 言い回しが違う質問や、複数の内容が混ざった質問にも対応しやすい
- 資料を更新すれば、回答にも反映される
- もっともらしい誤りを答える可能性がある
- 回答の品質を確かめる仕組みと、誤りへの備えが必要
違いの比較
| 観点 | シナリオ型 | 生成AI型 | 併用型 |
|---|---|---|---|
| 回答の正確さの管理 | しやすい（回答を人が書く） | 工夫が必要（資料・指示・評価で管理） | 重要な手続きはシナリオで確実に |
| 対応できる質問の幅 | 想定した範囲のみ | 資料にある範囲で幅広く | 幅広く、重要部分は確実に |
| 利用者の使いやすさ | 選択肢を探す手間がある | 自由に質問できる | 両方の入口を用意できる |
| 初期の準備 | シナリオの設計と回答の作成 | 資料の整備と検索の調整、評価 | 両方の準備が必要 |
| 運用の手間 | シナリオの追加・修正 | 資料の更新、誤回答の確認と改善 | 両方の運用 |
| 利用ごとの費用 | ほぼかからないことが多い | 生成AIの利用料がかかる | 生成AIを使う部分だけかかる |
| 向いている用途 | 手続きの案内、受付、予約、診断 | 製品・規程・技術情報への質問対応 | 顧客サポート、社内ヘルプデスク全般 |
用途別の選び方
方式を選ぶときは、次の問いに順に答えていくと判断しやすくなります。
- 誤った回答の影響はどれくらい大きいか：料金、契約、法的な手続き、健康や安全に関わる案内など、誤りが大きな問題になる質問は、シナリオ型で人が書いた回答を返すか、生成AI型でも回答の範囲を厳しく絞ります。
- 質問の種類はどれくらい多様か：問い合わせの大半が少数の定型の質問なら、シナリオ型で十分です。質問の言い回しや内容が多様で、FAQを増やしても追いつかないなら、生成AI型が向いています。
- 回答のもとになる資料は整っているか：生成AI型は、資料の品質がそのまま回答の品質になります。マニュアルやFAQが古い、部署ごとにばらばら、といった状態なら、資料の整備から始める必要があります。
- 運用に誰がどれだけ時間を割けるか：シナリオ型はシナリオの更新、生成AI型は誤回答の確認と資料の更新に、継続的な手間がかかります。
- 途中で人に引き継ぐ必要があるか：解決できなかった質問を有人対応に引き継ぐ仕組みは、どちらの方式でも必要です。
この問いに答えると、たとえば次のような判断になります。
- 会員の住所変更や解約の手続き案内：手順が決まっていて誤りが許されないため、シナリオ型
- 製品の仕様や使い方への質問：質問が多様で、マニュアルが整っていれば生成AI型
- 社内の規程や手続きへの質問：規程を資料として生成AI型、ただし申請の手順はシナリオで確実に案内する併用型
- 店舗の予約受付：日時や人数を順に聞き取るためシナリオ型（予約システムとの連携が中心）
作り方の手順
ここでは、生成AI型を中心に、併用型まで含めた作り方の流れを示します。シナリオ型だけで作る場合も、1〜3と7〜9は共通です。
- 目的と対象を決める：誰の、どんな質問に答えるのかを決めます。「顧客からの製品の使い方の質問」「社員からの総務手続きの質問」のように絞ります。対象を広げすぎると、資料の整備も評価も終わりません。
- 過去の質問を集めて分類する：問い合わせ窓口のメールや記録から、実際の質問を集め、種類ごとに分類します。件数の多い質問と、誤りが許されない質問を把握します。
- 方式を決める：分類した質問ごとに、シナリオで答えるか、生成AIで答えるか、人が答えるかを決めます。
- 資料を整える：生成AIに参照させるマニュアル・FAQ・規程を集め、古い情報を削除し、矛盾を解消します。表や画像に頼った資料は、文章で補います。
- 検索と回答の仕組みを作る：資料を検索しやすい形に分割して登録し、質問に関係する部分を検索して回答を生成する仕組みを作ります。構築の詳しい手順は RAGシステムの構築手順 で解説しています。
- 回答のルールを決める：資料にないことは答えない、根拠となる資料名を示す、料金や契約の個別の判断は人に引き継ぐ、といったルールを指示に組み込みます。不適切な質問や範囲外の依頼への対応も決めます。
- 人への引き継ぎを設計する：解決しなかった場合に、問い合わせフォームや有人チャットに、それまでの会話を引き継げるようにします。引き継ぎの設計は チャットボットから有人対応へ：エスカレーション設計の勘所 で詳しく扱っています。
- 評価してから公開する：過去の質問から、典型的な例、難しい例、答えてはいけない例を集めて試し、回答の正確さを確認します。許されない誤りがないことを確かめてから公開します。
- 小さく公開する：最初は特定のページや一部の利用者に限って公開し、利用状況と回答の品質を見ながら範囲を広げます。
回答の正確さを守るための設計
生成AI型で最も気をつけるべきは、もっともらしい誤りへの備えです。設計の段階で、次の対策を組み合わせます。
- 回答の根拠を資料に限定する：指示で「提供された資料の内容だけで答え、資料にない場合はその旨を伝える」と明示します。
- 根拠を表示する：回答の下に、参照した資料名やリンクを示します。利用者が自分で確かめられ、誤りに気づきやすくなります。
- 答えない範囲を決める：料金の個別見積もり、契約の解釈、医療や法律の判断など、チャットボットが答えるべきでない話題を決め、人への引き継ぎに回します。
- 入力と出力を確認する仕組みを入れる：不適切な入力や、答えるべきでない内容の出力を検知して止める仕組みを ガードレール と呼びます。顧客向けのチャットボットでは特に重要です。
- 重要な手続きはシナリオで返す：解約や支払いなど、手順の誤りが問題になる質問は、生成AIに文章を作らせず、人が書いた回答やシナリオに誘導します。
設置場所と最初の画面の設計
チャットボットの使われ方は、どこに置き、最初に何を見せるかで大きく変わります。仕組みの作り込みと同じくらい、入口の設計に気を配ります。
- 困っている場面の近くに置く：サイトの全ページに置くより、ヘルプページ、料金ページ、申し込みフォームの途中など、質問が生まれやすい場所に置く方が利用されます。社内向けなら、社内ポータルや普段使うチャットツールの中から呼び出せるようにします。
- できることとできないことを最初に示す：「製品の使い方についてお答えします。ご契約内容の変更は担当者が対応します」のように、答えられる範囲を冒頭で伝えます。利用者の期待とのずれが減り、範囲外の質問で不満を持たれにくくなります。
- よくある質問をボタンで示す：自由入力欄だけだと、何を聞けばよいか迷う利用者もいます。件数の多い質問をいくつかボタンで示し、自由入力と併用します。併用型では、このボタンがシナリオへの入口にもなります。
- 人に相談する出口を常に見せる：画面のどこかに、問い合わせフォームや有人対応への入口を常に表示しておきます。出口が見えないと、チャットボットに閉じ込められたと感じさせてしまいます。
- 個人情報の入力を促さない：生成AI型では、利用者が氏名や会員番号、カード番号などを書き込んでしまうことがあります。入力しないよう注意書きを添え、必要な場合は認証済みの画面で扱います。
公開後の改善の回し方
チャットボットは、公開してからが本番です。公開後は次の流れで改善を続けます。
- 会話の記録を確認する：利用者の質問と回答を定期的に確認します。すべてを読むのが難しい場合は、利用者が「役に立たなかった」と評価した会話や、人に引き継がれた会話を優先して確認します。
- 原因を分類する：解決できなかった理由を「資料に答えがない」「資料はあるが検索で見つからない」「見つかったが回答が不正確」「対象外の質問」に分けます。
- 原因ごとに直す：資料に答えがなければ資料を追加し、検索で見つからなければ資料の書き方や分割を見直し、回答が不正確なら指示を調整します。対象外の質問が多いなら、対象を広げるかどうかを検討します。
- 直した結果を確かめる：評価用の質問で測り直し、改善と同時に悪化した例がないかを確認します。
- 資料の更新を業務に組み込む：製品の仕様や規程が変わったときに、チャットボットの資料も更新されるよう、更新の担当と手順を決めます。
確認の結果、よく聞かれる質問が見えてきたら、それをFAQページやシナリオとして整備し直すことも有効です。チャットボットの会話記録は、利用者が何に困っているかを知る貴重な情報源になります。
運用体制と費用の考え方
チャットボットの運用には、次の役割が必要です。
| 役割 | 主な作業 | 担い手の例 |
|---|---|---|
| 運用責任者 | 目的と対象範囲の決定、改善の優先順位付け | 問い合わせ窓口の責任者 |
| 資料の管理者 | マニュアル・FAQ・規程の更新と矛盾の解消 | 各分野の担当部署 |
| 会話の確認者 | 会話記録の確認、原因の分類、改善の提案 | 窓口の担当者 |
| 技術の担当者 | 検索・指示・連携の調整、評価の実施 | 開発会社または社内の開発担当 |
費用は、シナリオ型ではシナリオの作成とツールの利用料が中心になり、生成AI型ではこれに加えて、資料の整備、検索の仕組みの開発、評価の工数、利用ごとの生成AIの利用料がかかります。既製のチャットボットサービスを使うか、個別に開発するかでも費用の構造が変わります。比較の考え方は AIチャットボット導入の費用 で解説しています。
具体的な場面で考える（架空の例）
架空のオンライン英会話サービスを例にします。問い合わせ窓口には、レッスンの予約方法、講師の変更、料金プランの違い、支払い方法、退会手続き、システムの不具合など、さまざまな質問が届いていました。以前からシナリオ型のチャットボットを置いていましたが、選択肢が多すぎて利用者が目的の回答にたどり着けず、結局問い合わせフォームに流れていたとします。
- 過去の問い合わせを分類したところ、予約や講師の変更など操作方法の質問が多く、言い回しが多様であることが分かった。
- 操作方法の質問は、ヘルプページを資料とした生成AI型で答えることにし、根拠となるヘルプページのリンクを回答に付けた。
- 退会手続きと支払いに関する質問は、生成AIに答えさせず、シナリオで手順のページへ誘導することにした。
- システムの不具合の報告は、内容を聞き取ったうえで、会話の記録を添えて問い合わせ窓口に引き継ぐ流れにした。
- 公開前に、過去の質問から80件を選んで試し、退会や返金について生成AIが答えてしまう例がないことを確認した。
- 公開後は週に一度、人に引き継がれた会話を確認し、ヘルプページに記載がない質問を見つけてはページを追加した。
この例のように、質問の種類ごとに方式を分けることで、柔軟さと正確さを両立できます。
よくある失敗と避け方
- すべての質問を生成AIに答えさせる：誤りが許されない手続きまで生成AIに任せると、重大な誤案内のリスクを抱えます。質問の種類ごとに方式を分けます。
- 資料を整えずに始める：古い資料や矛盾する資料をそのまま参照させると、回答も古く矛盾したものになります。資料の整備は最初の、そして継続的な作業です。
- シナリオを増やし続ける：シナリオ型で質問の多様さに対応しようとすると、分岐が増えすぎて利用者も管理者も迷います。多様な質問は生成AI型に任せる判断が必要です。
- 人への引き継ぎがない：解決できない利用者が行き場を失うと、不満が大きくなります。どの方式でも、人につながる出口を用意します。
- 公開して終わりにする：会話の記録を確認しないと、誤回答や資料の不足に気づけません。確認の担当と頻度を決めます。
- 対象を広げすぎる：最初からすべての質問に対応しようとすると、資料の整備と評価が終わらず、公開が遅れます。件数の多い質問から始めます。
- 効果を問い合わせ件数だけで測る：問い合わせが減っても、利用者が解決できずに諦めただけかもしれません。解決できたかどうかの評価や、引き継ぎ後の内容もあわせて確認します。
導入前のチェックリスト
- 対象の利用者と、答える質問の範囲を決めたか
- 過去の質問を集め、種類ごとに分類したか
- 質問の種類ごとに、シナリオ・生成AI・人のどれで答えるかを決めたか
- 誤りが許されない質問と、答えない話題を決めたか
- 参照させる資料を整え、更新の担当を決めたか
- 回答のルール（資料にないことは答えない、根拠を示す）を決めたか
- 人への引き継ぎの方法を決めたか
- 公開前に評価する質問を用意したか
- 小さく公開して範囲を広げる計画を立てたか
- 会話記録の確認と改善の担当・頻度を決めたか
よくある質問
Q. 既存のシナリオ型チャットボットは捨てて、生成AI型に置き換えるべきですか？
必ずしも置き換える必要はありません。誤りが許されない手続きの案内など、シナリオ型が得意な部分は残し、質問の多様さに対応しきれていない部分を生成AI型で補う併用が現実的です。既存のシナリオの回答は、生成AI型の資料としても活用できます。
Q. 生成AI型は、誤った回答をゼロにできますか？
ゼロにすることは難しいのが実情です。そのため、根拠を資料に限定する、根拠を表示する、答えない範囲を決める、重要な手続きはシナリオで返す、人への引き継ぎを用意する、といった対策を組み合わせ、誤りが起きたときの影響を小さくする設計をします。
Q. FAQページがあれば、チャットボットは不要ではありませんか？
FAQページで十分に解決できているなら、急いでチャットボットを導入する必要はありません。利用者がFAQから答えを探せずに問い合わせている、FAQの数が多すぎて探しにくい、といった状況があるなら、チャットボットが入口として役立ちます。どちらにしても、FAQの内容を整えることが土台になります。
Q. 既製のチャットボットサービスと個別開発、どちらがよいですか？
対象の質問がFAQの範囲に収まり、既存の業務システムとの連携が不要なら、既製のサービスで始めるのが早く確実です。会員情報や注文情報と連携して個別の状況に答えたい、社内システムの権限に応じて答えを変えたい、といった要件がある場合は、個別開発が向いています。
Otsumuに相談できること
対象の質問が少数の定型の質問に収まり、FAQも整っているなら、既製のチャットボットサービスで始めるのが最も手早い方法です。この記事の手順に沿って過去の質問を分類し、件数の多い質問から対応していけば、自社だけでも十分に運用できます。
一方で、質問が多様でシナリオでは追いつかない、社内の多数の資料をもとに答えさせたい、会員情報や注文情報と連携して個別の状況に答えたい、誤りが許されない手続きと柔軟な回答を一つの窓口で両立させたい、といった場合は、方式の組み合わせと誤りへの備えを設計の段階から考える必要があります。
Otsumuでは、過去の質問の分類から一緒に行い、質問の種類ごとに方式を決めたうえで、必要な範囲に絞ってチャットボットを開発します。進め方は AIチャットボット開発 のページで紹介しています。社内資料の検索が中心になる場合は RAG開発 としてもご相談いただけます。
どの方式が自社に合うか判断したい段階でも構いません。30分の無料相談 で現在の問い合わせの状況を伺い、進め方を一緒に整理します。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01