企業向けAIチャットボットの構築：A〜Zまで徹底解説

技術からではなく、課題から始める

チャットボット開発で最もよくある失敗は、「どのAIモデルを使うべきか」という問いから始めてしまうことです。本来問うべきなのは、チャットボットが何を解決し、誰の役に立ち、成功を何で測るのかということです。デザインの提案や概算見積りを行うチャットボットを求める家具チェーンと、配送状況の照会が必要な物流会社、休暇制度に関する質問に答えたい人事部門とでは、求められる要件がまったく異なります。

まずは過去3か月にお客様や社員から最も多く寄せられた質問を、Facebookページの受信箱、Zalo、メール、電話窓口から洗い出してみてください。多くの場合、送料、返品・交換、注文状況といった少数のテーマが質問の大半を占めています。リリース初日からチャットボットを「何でも知っている」状態にしようとするのではなく、そこを最初のバージョンの対象範囲とするのが合理的です。

アーキテクチャの選択：シナリオ型、言語モデル、RAG

現在、主なアプローチは3つあり、それぞれ適した複雑さと予算の水準が異なります。必ずしも「最も賢い」選択肢を選ぶ必要はなく、十分に役立ち、管理しやすいものを選ぶことが大切です。

実際には、効果を上げている多くのシステムがこれらを組み合わせています。予約や注文照会のようにルールが明確なタスクは固定のフローやAPI呼び出しで処理し、自由な質問はRAGに任せるという形です。機微なデータを扱う場合は、外部サービスにデータを送るのではなく、LlamaやQwenといったオープンソースモデルを自社のインフラ上で運用することも検討できます。

• シナリオ型チャットボット：ボタンとあらかじめ設計した会話フローを使います。低コストで、設計した範囲内では正確ですが、シナリオ外の質問には柔軟に対応できません。
• 大規模言語モデル（LLM）を使うチャットボット：GPT、Claude、Geminiなどのモデルを直接呼び出し、自然な言葉による質問を理解します。柔軟性は高いものの、企業固有の知識がなければ誤った回答をしやすくなります。
• RAG（Retrieval-Augmented Generation）：回答する前に、企業のナレッジベースから関連する文書の一部を検索し、根拠としてモデルに渡します。多くの企業にとってバランスの取れた選択肢です。

データの準備：正確な回答の土台

チャットボットがうまく答えられるのは、与えられたデータの範囲内に限られます。保証規定の異なる3つのバージョンがGoogleドライブのあちこちに散らばっていれば、チャットボットは研修を受けていない新入社員と同じように矛盾した回答をしてしまいます。そのため、データ準備のフェーズは、多くの場合プログラミング以上に手間がかかります。

実際の会話履歴をもとに、模範解答付きの質問サンプル集を作成することも忘れないでください。このデータセットは、リリース前のテストや、文書の更新・モデル変更のたびに行うテストに活用します。

• 情報源の収集と選別：FAQ、製品カタログ、価格表、各種規定、そして最も優秀な営業担当者の接客トーク。
• クレンジングと標準化：古い文書を取り除き、用語を統一し、各規定の適用開始日を明記します。
• 適切な分割：何十ページもあるPDFをそのまま投入するのではなく、テーマごとに文書を分割して検索の精度を高めます。
• 担当者の割り当て：コンテンツのグループごとに、価格や規定が変わったときに更新する責任者を決めておきます。

コミュニケーションチャネルや社内システムとの連携

チャットボットの真の価値は、つながる力にあります。一般的な回答しかできないチャットボットはすぐに使われなくなりますが、注文や在庫を照会したり、予約を作成したりできるチャットボットは本当に時間の節約になります。

ベトナム市場では、お客様がすでにメッセージのやり取りに慣れているWebサイト、Zalo公式アカウント、Facebook Messengerが優先されることが一般的です。バックエンドでは、APIを通じてCRM、販売管理ソフト、ERP、チケット管理システムなどと連携できます。注文の作成や予約の変更といったデータを書き込む操作には、実行前にユーザーへの明確な確認ステップを設けるべきです。

もうひとつの必須要件が、有人対応への引き継ぎです。お客様が苛立っているとき、苦情を申し立てたいとき、あるいは対応範囲を超える質問をされたときには、お客様が最初から説明し直さなくて済むよう、会話の文脈をすべて添えてスタッフに引き継がなければなりません。

品質管理、セキュリティ、「ハルシネーション」のリスク

言語モデルは、もっともらしく聞こえるものの事実と異なる回答をつくり出すことがあり、これは一般に「ハルシネーション」（幻覚）と呼ばれています。価格や保証条件についての誤った回答は実害につながりかねないため、設計段階から何層ものチェックを組み込む必要があります。

リリース前には質問サンプル集でテストを行い、カスタマーサポートチームにチャットボットを「困らせる」質問を試してもらいましょう。まずWebサイトだけ、あるいはスタッフが監視できる営業時間内だけといった形で段階的にリリースすれば、影響が小さいうちに問題を発見できます。

• 提供された文書に基づいてのみ回答し、確信がないときは「その情報はまだ持ち合わせていません」と明確に伝え、関連する規定ページへのリンクを添えます。
• 承認ルールが整っていないうちは、価格、割引、法的な事項についてチャットボットが独自に約束しないようにします。
• 身分証番号や口座番号などの機微な情報の収集は最小限にとどめ、個人データ保護に関する現行の規定を遵守します。
• データへのアクセス権を分ける：顧客対応用のチャットボットが社内文書にアクセスできないようにします。

効果測定と継続的な改善

チャットボットは、一度つくったら終わりのプロジェクトではありません。リリース後は、メッセージ数を数えるだけでなく、当初の目標に結びついた指標を定期的に確認しましょう。

チャットボットがまだ答えられない質問こそが、次にやるべきことのリストです。文書を補充する、矛盾する内容を修正する、新しい処理フローを設計するといった対応につなげます。GREEN TECHは、データの調査、プロトタイプの構築から、リリース後のチャットボットの運用・最適化まで、企業に伴走することが多くあります。

• 自己解決率：スタッフへの引き継ぎなしで完結した会話の割合。
• 正確性：毎週ランダムに抽出した会話サンプルを確認した際の正答率。
• 満足度：会話後の簡易評価に加え、否定的なフィードバックを丁寧に読み込みます。
• ビジネス成果：チャットボット経由で生まれた見込み客、予約、注文の数。
• コスト：手作業で対応する場合と比較した、会話1件あたりの運用コスト。