▼ この記事の内容
チャットボット作成は、ツール選定より先に目的、対象質問、回答根拠、有人切替、更新責任者を決めることが重要です。誤回答や更新停止を防ぐには、6ステップで小さく作り、方式比較と公開後の改善指標まで確認します。
チャットボット作成は、画面上で会話を組む作業だけでは進めにくくなっています。生成AI型やRAG型を使う場合ほど、回答根拠と有人切替を先に決める必要があります。
目的が曖昧なまま作り始めると、FAQの古さ、誤回答、更新担当の不在が公開後に表面化します。問い合わせ削減を狙ったはずが、現場の確認作業を増やす状態にもなります。
この記事では、チャットボット作成で判断が止まりやすい項目を、目的、方式、運用、成果指標の順に整理します。ツールを選ぶ前に、自社で決めるべき範囲が分かるはずです。
作成前に運用まで確認したい方は、先にこちらから全体像を把握できます。
チャットボット作成は何から始めるべきか
チャットボット作成は、ツール選定ではなく目的、対象質問、回答根拠、有人切替、更新責任者の決定から始めます。先に運用条件を決めると、作った後に誤回答や更新停止で止まるリスクを下げられます。
最初に決めるのはツールではなく目的と対象質問
チャットボット作成で最初に決めるべき項目は、何を自動化するかです。問い合わせ削減、商談前の案内、社内FAQ対応では、必要な質問設計が変わります。
目的が曖昧なままツールを選ぶと、作成画面では進んでも質問の優先順位が決まりません。CS部門なら頻出問い合わせ、営業部門なら商談前に繰り返す説明から選ぶと絞れます。
判断には「作成前5点チェック」を使うのが有効です。目的、対象質問、回答根拠、逃がし先、更新者を1枚で埋めると、作る範囲と作らない範囲が分かれます。
最初の対象質問は、件数が多い質問と回答が安定している質問を優先します。例外判断が多い質問は、チャットボットで完結させず有人対応へ渡す設計が適しています。この段階では、対象質問を増やすより、答えない質問を明確にするほうが運用後の手戻りを減らせます。
回答根拠、有人切替、更新責任者を先に決める
チャットボット作成では、回答根拠、有人切替、更新責任者を先に決めます。業務利用では、誰が承認した情報で、どの範囲まで答え、回答できない質問をどこへ渡すかを作成前に定義する必要があります。
回答根拠とは、チャットボットが参照するFAQ、商品資料、社内ナレッジ、ヘルプ記事を指します。承認されていないメモまで混ぜると、回答の根拠を社内で説明しにくくなります。
有人切替は、チャットボットが回答できない質問をどこへ渡すかを決める設計です。費用、契約、個別トラブルのような判断が必要な質問は、最初から担当部署へ渡す方が安定します。
更新責任者は、公開後に質問ログを見て回答文を直す人です。Microsoft LearnのCopilot Studioの導入ガイドでも、作成後のテストと公開確認が案内されています。
参考：Copilot Studio を使い始める｜Microsoft Learn
回答根拠、有人切替、更新責任者を先に決めるでは、判断条件、関係者、確認データ、運用会議で見る指標をそろえると、自社で再現しやすい改善項目へ落とし込めます。
作れる状態と業務で使える状態は分けて考える
チャットボットは短時間で作れても、業務で使えるとは限りません。業務で使うには、回答品質、例外処理、更新運用、成果指標まで決める必要があります。
ノーコードツールなら、画面上の会話フローやFAQ登録は早く進みます。一方で、誰が回答を承認するかを決めないと、公開前チェックで差し戻しが増えます。
弊社が支援した営業組織では、ベテランの説明をFAQ化する前に、商談で何を見て判断しているかを質問単位に分解しました。回答文だけを登録するのではなく、判断基準、例外条件、担当者への引き継ぎ条件まで整理すると、チャットボットで答える範囲を決めやすくなります。
業務利用の判断軸は、作成時間ではなく運用後に直せるかです。次のセクションでは、目的定義から公開後の改善までを、実際の作成ステップに分けて整理します。
作れる状態と業務で使える状態は分けて考えるでは、判断条件、関係者、確認データ、運用会議で見る指標をそろえると、自社で再現しやすい改善項目へ落とし込めます。
チャットボットの作り方6ステップ
チャットボットの作り方は、目的定義、材料整理、方式選定、会話設計、テスト、公開後改善の順で進めます。先にFAQや社内ナレッジを棚卸しすると、方式選定の判断が具体化します。
ステップ1｜目的と利用チャネルを決める
最初のステップは、チャットボットを使う目的と設置チャネルを決めることです。Webサイト、社内ポータル、営業資料ページでは、利用者の質問と期待する返答が異なります。
問い合わせ削減が目的なら、営業時間、料金、手続きなど定型質問を優先します。リード獲得が目的なら、資料請求前の不安や比較検討中の質問を拾う設計が必要です。
このステップの成果物は、利用目的、対象ユーザー、設置チャネル、有人対応へ切り替える条件をまとめた要件メモです。判断者は、問い合わせ削減ならカスタマーサポート責任者、リード獲得なら営業やマーケティング責任者、社内利用なら情報システム部門や業務部門の責任者になります。
失敗条件は、目的が「便利にしたい」など曖昧なまま進み、FAQ整備、シナリオ設計、KPI設定の基準が決まらない状態です。チャネルを先に決めると、会話の長さや有人切替の導線も決めやすくなります。社内利用なら権限管理、外部サイトならフォーム連携や営業通知まで確認します。
ステップ2｜FAQ、問い合わせ履歴、社内ナレッジを棚卸しする
作成前の材料整理は、チャットボットの回答品質を左右します。FAQ、問い合わせ履歴、社内ナレッジを棚卸しし、回答に使える情報と承認が必要な情報を分けます。
よくある失敗は、担当者の記憶だけで質問を作ることです。実際の問い合わせ履歴を見れば、同じ質問でも利用者の言い回しや前提条件が違うことに気づけます。
棚卸しの成果物は、質問、回答、根拠資料、更新日、承認者を並べた一覧です。FAQが存在しない場合は、最初からAIに任せず、頻出質問の定義から始めます。
ステップ3｜シナリオ、FAQ、AI、RAGの方式を選ぶ
方式選定では、質問の自由度と回答根拠の管理方法を見ます。定型案内ならシナリオ型、既存FAQがあるならFAQ型、自然文対応が必要ならAI型や生成AI型が候補になります。
社内資料や商品資料を参照させたい場合は、RAG型も検討対象です。RAGは検索で見つけた社内ナレッジをもとに回答を作る考え方で、根拠範囲の管理が重要になります。
方式は高機能なものを選べばよいわけではありません。承認済み情報の範囲、更新担当、回答不可時の処理まで運用できる方式を選ぶのが実務では有効です。
ステップ4｜会話フローと回答不可時の動きを設計する
会話フローは、利用者が質問してから解決または有人対応へ進むまでの流れです。最初の選択肢、質問の言い換え、回答後の次アクションを順番に設計します。
回答不可時の設計は、生成AI型やRAG型ほど重要です。根拠がない質問には推測で答えず、回答できない理由と次の相談先を示すほうが業務上の事故を避けられます。
営業サイトでは、料金や個別提案に関する質問を無理に自動回答しない判断も必要です。問い合わせフォーム、担当者連携、資料導線のどれへ渡すかを事前に決めます。
ステップ5｜テスト質問で回答品質と有人切替を確認する
公開前テストでは、想定質問だけでなく言い換え質問も確認します。同じ意味の質問に対して、回答の根拠、表現、有人切替が安定しているかを見ます。
テスト質問は、正しく答えてほしい質問、答えてはいけない質問、有人に渡す質問に分けます。この3分類で確認すると、単なる動作確認で終わりにくくなります。
社内FAQなら、制度変更前後の古い表現が残っていないかも確認します。外部サイトなら、誤解を招く断定や営業担当者が補足すべき内容を自動回答していないかを見ます。
ステップ6｜公開後に質問ログを見て改善する
公開後は、質問ログを見てFAQ追加と回答修正を続けます。未回答質問、途中離脱、有人転送が多い質問を見れば、改善すべき箇所が具体化します。
改善担当が決まっていないと、公開後のログ確認は後回しになります。週次または月次で確認日を決め、回答文の修正と承認を同じ流れに入れることが必要です。
作成手順を回した後は、方式ごとの向き不向きを改めて見直します。質問量、根拠資料、更新体制によって、適した作成方法は変わります。
作成方法の種類と選び方
チャットボットの作成方法は、質問の定型度、必要な回答根拠、更新できる体制で選びます。早く作れる方式ほど、想定外の質問や古い情報への対応を別に設計する必要があります。
シナリオ型は定型案内や予約受付に向く
シナリオ型は、選択肢に沿って利用者を案内する作成方法です。営業時間案内、資料請求、予約受付のように、質問の流れが決まっている業務に向きます。
強みは、回答内容を管理者が細かく固定できる点です。Web問い合わせなら、目的別に選択肢を分けるだけで、担当部署への振り分けを始めやすくなります。
一方で、自由入力の質問が多い業務では、利用者が選択肢に当てはめられず離脱します。FAQが増えてきた段階では、登録済みの質問と回答を使う方式も候補になります。
FAQ型は問い合わせ履歴とQ&Aがある場合に向く
FAQ型は、登録済みの質問と回答をもとに返答する作成方法です。問い合わせ履歴やQ&Aが蓄積している場合、回答根拠を管理しながら始めやすくなります。
社内向けの問い合わせでは、部署ごとに回答の承認者が違うことがあります。その場合は、FAQの作成者、承認者、更新日を分けて管理すると、古い回答の放置を避けやすくなります。
FAQの量が多く、比較軸を整理したい場合は、FAQシステムを比べるときの選定軸を確認すると判断しやすくなります。社内利用を前提にするなら、社内FAQシステムの比較で見るべき条件も合わせて整理すると、次の方式選定につながります。
営業AI・営業DX FAQシステム比較は機能数より回答根拠と更新運用で失敗を防ぐ
営業AI・営業DX 社内FAQシステム比較｜4類型の選び方と失敗しない導入判断軸
AI型と生成AI型は自然文対応より根拠管理を先に見る
AI型や生成AI型は、利用者の自然な文章を受け取りやすい作成方法です。ただし業務利用では、自然に答えることより、何を根拠に答えるかを先に決める必要があります。
よくあるケースとして、利用者が規程外の質問を入力し、もっともらしい返答だけが返ることがあります。回答不可の文言、有人切替の条件、参照してよい情報範囲を決めておくと、誤回答時の対応を整理しやすくなります。
生成AIを使う場合でも、承認済みナレッジが少ない段階では効果を断定できません。まずはFAQ型で回答根拠を整え、自然文対応が必要な質問だけをAI型に広げる判断が現実的です。
RAG型は社内ナレッジを参照させたい場合に候補になる
RAG型は、社内ナレッジや文書を参照しながら回答させたい場合に候補になります。規程、マニュアル、提案資料のように、回答根拠を文書単位で管理したい業務に向きます。
導入時の注意点は、文書を入れれば正しく答えるわけではない点です。古い資料、重複した資料、承認前の資料が混ざると、回答の根拠がずれて利用者の不信につながります。
RAG型を選ぶ場合は、検索対象の文書、更新責任者、回答不可時の逃がし先を先に決めます。方式ごとの向き不向きをつかんだ後は、自社の条件に合わせて比較表で絞り込むと判断しやすくなります。
自社に合う作成方法の比較表
自社に合うチャットボット作成方法は、導入難易度だけでは判断できません。回答根拠、更新責任、回答不可制御、保守体制を並べると、公開後に運用できる方式が見えます。
回答根拠と更新責任で方式を比較する
自社に合う作成方法は、回答根拠、更新責任、回答不可制御、保守体制で比較します。業務利用で社内外の質問に答える場合は、導入難易度だけで選ぶと、公開後の修正責任が曖昧になります。
比較では、誰が何を根拠に回答を承認するかを先に見ます。社内FAQ、商品資料、問い合わせ履歴の整備状況によって、選ぶべき方式は変わります。
| 作成方法 | 向いている用途 | 見るべき運用条件 | 注意点 |
|---|---|---|---|
| シナリオ型 | 定型案内、予約受付、部署振り分け | 会話分岐を更新する担当者 | 自由入力が多い質問には合いにくくなります |
| FAQ型 | 問い合わせ履歴やQ&Aの自動回答 | 回答文、根拠資料、更新日の管理 | 古いFAQが残ると誤回答につながります |
| AI型 | 自然文の質問への対応 | 回答不可時の文言と有人切替 | 根拠が弱いまま広げると説明責任が増えます |
| 生成AI型 | 文章生成を含む柔軟な回答 | 参照範囲、禁止回答、承認済み情報 | もっともらしい回答を制御する設計が必要になります |
| RAG型 | 社内ナレッジや文書を参照する回答 | 文書管理、権限、更新責任者 | 資料の鮮度と重複管理が運用品質を左右します |
表で最初に見るべき列は、向いている用途ではなく運用条件です。運用条件を満たせない方式は、初期構築が簡単でも公開後に改善が止まりやすくなります。
ノーコードツールは早く試せるが運用設計が別途必要
ノーコードツールは、短期間でチャットボットを試したい場合に有効です。画面上で会話フローやFAQを登録できるため、初期検証の負荷を抑えられます。
一方で、早く作れることと業務で使い続けられることは別です。回答文の承認、更新日管理、有人切替の基準を決めないと、担当者の個別判断に戻ります。
問い合わせ件数が少ない段階では、ノーコードで小さく試す進め方が合います。公開範囲を絞り、質問ログを見て方式を広げると、過剰な初期投資を避けられます。
APIや自社開発は自由度が高いが保守体制が必要
API連携や自社開発は、既存システムと深くつなぎたい場合に候補になります。CRM、会員DB、社内ポータルと連携するなら、自由度の高さが判断材料になります。
ただし、開発できることと保守できることは分けて見ます。仕様変更、権限管理、ログ監視、障害対応を担う人がいない場合、運用負荷が後から表面化します。
自社開発を選ぶ条件は、独自要件が明確で、保守担当と改善予算があることです。標準的なFAQ対応なら、既存ツールで運用を固めてから拡張する方が現実的です。
生成AI連携は回答不可制御と承認済み情報の範囲設定が重要
生成AI連携では、自然な文章で答える前に、答えてよい範囲を決めます。承認済み情報だけを参照させる設計がないと、業務回答として説明しにくくなります。
よくある不安は、利用者の質問に対してもっともらしい誤回答が返ることです。回答不可時の文言、根拠がない質問の扱い、有人に渡す条件を先に決めるとリスクを下げられます。
生成AI型やRAG型は、ナレッジの鮮度を保てる組織に向きます。方式を絞った後は、導入前に自動回答範囲、承認者、逃がし先、更新担当を確認する流れに進みます。
導入前に確認すべき質問
導入前には、どの質問を自動回答するか、誰が回答文を承認するか、回答できない時にどこへ渡すかを確認します。質問で意思決定を整理すると、作成後の運用負荷を見積もりやすくなります。
どの質問を自動回答し、どの質問を有人に渡すか
自動回答する質問と有人に渡す質問の線引きは、失敗回避の前提です。定型回答できる質問だけを自動化し、個別判断が必要な質問は人へ渡します。
営業サイトなら、機能概要や資料請求前の不明点は自動回答しやすい領域です。個別見積もり、契約条件、導入可否の判断は営業担当へ渡すほうが安全です。
線引きが曖昧なままだと、チャットボットが答えすぎる状態になります。利用者の信頼を守るには、回答できない質問をどこへ逃がすかまで決めます。
誰が回答文と根拠ナレッジを承認するか
回答文と根拠ナレッジは、業務責任を持つ担当者が承認する必要があります。作成担当者だけで回答を作ると、現場の最新ルールや営業判断とずれる可能性があります。
承認者は、FAQごとに決めると管理しやすくなります。料金は営業責任者、社内規程は人事や総務、技術仕様は開発やプロダクト担当が見る形です。
承認フローを決めると、更新時の迷いも減ります。回答文を直す人、根拠資料を確認する人、公開可否を判断する人を分けておくと運用が安定します。
回答できない時にどこへ逃がすか
回答できない時の逃がし先は、チャットボット作成前に決めるべき項目です。未回答を放置せず、有人窓口、フォーム、チケット、担当者通知へつなげます。
利用者は、回答がないこと自体より次に何をすればよいか分からない状態に不満を持ちます。回答不可の文言には、相談先と必要な情報を短く入れるのが有効です。
社内FAQでは、担当部署が分からない質問を総務や情シスへ集めすぎる失敗があります。カテゴリ別の逃がし先を決めると、担当者の負担が偏りにくくなります。
更新担当、承認フロー、改善頻度を決める
更新担当、承認フロー、改善頻度は、導入前に決めておく必要があります。公開後に誰が直すか不明なチャットボットは、古い回答を抱えたまま運用されやすくなります。
月次で質問ログを確認し、未回答質問と誤回答候補を一覧化します。回答文の修正は担当者が行い、業務責任者が承認してから公開する流れにします。
ツール選定だけでなく、運用定着まで含めて考えたい場合は、導入前の確認観点を早めに整理する必要があります。営業改善プログラム「FAZOM」の支援範囲を確認する入口として、以下の資料を参照できます。
失敗しやすい作成パターンと回避策
チャットボット作成の失敗は、ツールの不具合より運用設計の不足から起きやすくなります。古いFAQ、回答不可制御不足、改善担当不在、KPI未設定を先に潰すことが重要です。
FAQが古いまま公開して誤回答が増える
古いFAQをそのまま使うと、チャットボットは誤った情報を速く返す仕組みになります。作成前には、回答文だけでなく根拠資料の更新日と承認者を確認します。
弊社の支援現場でも、FAQはあるのに制度変更や価格改定が反映されていないケースがあります。担当者が古いページを参照していた場合、利用者への案内がずれます。
回避策は、公開前にFAQを棚卸しし、回答ごとに根拠資料と更新日を持たせることです。公開後もログ確認とFAQ更新を同じ運用に入れる必要があります。
回答できない質問まで無理に自動化する
回答できない質問まで自動化すると、誤回答と利用者不満が増えます。チャットボットは全件回答を目指すより、答える範囲と逃がす範囲を明確にしたほうが安定します。
導入責任者は、有人対応を減らしたい気持ちから自動回答範囲を広げがちです。ですが、個別見積もりや契約判断まで自動化すると、後から人が訂正する負担が増えます。
回避策は、回答不可時の文言と有人切替先を先に設計することです。答えない判断を組み込むと、利用者は次の行動を取りやすくなります。
公開後のログ確認とFAQ追加が止まる
公開後のログ確認が止まると、チャットボットは利用者の質問変化に追いつけません。未回答ログ、検索語、有人転送理由を見て、FAQ追加と回答修正を続ける必要があります。
よくあるケースとして、初回公開まではプロジェクト化されても、運用開始後に担当が曖昧になります。結果として、同じ未回答質問が何度も発生し、現場の信頼が下がります。
回避策は、改善頻度と担当者を作成時点で決めることです。週次で多い質問を拾い、月次で承認済みFAQへ反映するだけでも改善サイクルが作れます。
成果指標を決めずに問い合わせ削減だけを期待する
KPI未設定のチャットボット作成は、公開後に改善判断ができません。問い合わせ削減だけでなく、解決率、未回答率、有人転送率、FAQ更新件数を分けて見ます。
問い合わせ件数が減っても、重要な相談まで減っていれば営業やCSには悪影響です。リード獲得目的なら、フォームCV後のMQL、SQL、商談化まで確認します。
回避策は、作成前に成果指標を決め、公開後のログと結びつけることです。次は、作成後にどの指標を見るべきかを具体的に整理します。
作成後に成果を見る指標とFAZOM接続
チャットボット作成後の成果は、問い合わせ数の減少だけで判断しないほうが実態に近づきます。解決品質、更新運用、CV後の商談化を分けて見ると、改善すべき箇所が明確になります。
解決率、未回答率、有人転送率を分けて見る
業務利用のチャットボットでは、解決率、未回答率、有人転送率を分けて見ると判断しやすくなります。問い合わせ削減だけを見ると、誤回答やたらい回しを見落とします。
解決率は、利用者が自己解決できた割合を示します。未回答率は、回答候補がない質問の多さを示し、FAQやナレッジの不足を見つける起点になります。
有人転送率が高い場合は、チャットボットの対象範囲が広すぎる可能性があります。次は回答ログを見て、FAQ更新と根拠情報の鮮度を管理する流れへ進みます。
FAQ更新件数と回答根拠の鮮度を管理する
チャットボットの回答品質は、公開時の設定よりも公開後の更新運用で差が出ます。FAQ更新件数と回答根拠の鮮度を追うと、回答の古さを早期に見つけられます。
よくある運用では、月次で未回答ログを確認し、質問文、回答文、根拠ナレッジをセットで直します。承認者を決めておくと、現場判断だけで回答が増えるリスクを抑えます。
更新件数がゼロのまま未回答率が残る場合は、改善担当が決まっていない可能性があります。リード獲得目的で使う場合は、次にフォームCV後の指標まで確認します。
リード獲得ではフォームCV後の商談化まで見る
リード獲得目的のチャットボットでは、フォームCVの件数だけでなくMQL、SQL、商談化まで見ます。問い合わせ対応専用なら、営業指標ではなく解決品質を優先します。
フォームCVが増えても、商談につながらない場合は、質問設計とCTAの約束がずれている可能性があります。入力直前の案内文が、読者の課題と次の行動を正しくつないでいるかを確認します。
営業チームが使う場合は、CV後の対応履歴も合わせて見る必要があります。件数だけで成功扱いせず、lead quality、SQL、opportunity、wonへの接続まで追うと判断がぶれにくくなります。
承認済みナレッジと更新運用を確認したい場合の次アクション
チャットボット作成で不安が残る場合は、ツール機能より先に承認済みナレッジと更新運用を確認します。成果保証ではなく、運用まで設計できるかを見極めることが現実的です。
営業改善プログラム「FAZOM」は営業AI単体ではなく、改善が現場の業務に組み込まれる状態を支援するプログラムです。チャットボットの目的が営業接点やリード獲得に近い場合は、回答後の改善ループまで含めて検討します。
自社の回答根拠や更新運用を、作成前にどこまで確認すべきか迷う場合があります。営業改善の実行と定着まで含めて確認したい場合は、以下の資料を参照できます。
よくある質問
チャットボット作成は何から始めるべきですか
目的、対象質問、回答根拠、有人切替、更新責任者を先に決めます。ツール選定は、その後に自社の運用条件へ合う方式を絞る流れで進めます。具体的な進め方は組織の現状に応じて調整します。
チャットボットは無料で作成できますか
無料で試せるツールはあります。ただし業務利用では、FAQ管理、権限、更新担当、有人対応の設計が必要になるため、試作と本運用は分けて考えます。まずは現状の課題を整理することから始めます。
AIチャットボットとFAQ型チャットボットは何が違いますか
FAQ型は登録済みの質問と回答をもとに返答します。AI型は自然文対応に強い一方で、回答根拠、参照範囲、誤回答時の制御を設計する必要があります。定着には週次での振り返りが効果的です。
まとめ
チャットボット作成は、目的、対象質問、回答根拠、有人切替、更新責任者を決めてから進めます。シナリオ型、FAQ型、AI型、生成AI型、RAG型のどれを選ぶ場合でも、公開後に誰が直すかまで決めることが重要です。
方式選定だけで進めると、古いFAQ、回答不可時の迷い、ログ未確認が残ります。作成時点で解決率、未回答率、有人転送率、FAQ更新件数を見る設計にしておくと、問い合わせ削減だけに偏らず改善判断がしやすくなります。
現状のまま作成を急ぐと、公開後に誤回答の確認、FAQ修正、担当部署への差し戻しが増えます。利用者が同じ質問を繰り返し、担当者がログを追い直す状態になる前に、回答根拠と更新運用を確認する必要があります。
営業接点やリード獲得まで含めて運用設計を確認したい場合は、営業改善プログラム「FAZOM」のサービス資料から支援範囲を確認できます。担当者自身が、作成前の論点整理と社内説明を進めやすくなります。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
※具体的な数値は導入企業の許可を得た範囲で一部加工しています
