業務チャットボットの導線設計とベストプラクティス

まず結論

チャットボットを実務で役立つ形にするには、モデル選定より前に、役割・知識ソース・権限・引き継ぎ条件・評価方法を決めることが重要です。

1. 用途を 1 つに絞るほうが強い
2. 何を根拠に答えるか（正本）を決める
3. 出典が出せない答えと、人に渡すべき答えを分ける
4. 高リスク処理ほど権限と確認段階を厳しくする
5. 会話ログと評価セットがないと改善は勘任せになる
6. Web サイト向けなら、会話を長く続けるよりページ案内と問い合わせ導線を重視する

最初に決めるべきは「誰の、何の仕事を減らすか」

最初の 1 本として作りやすいのは、対象が狭く、答えの正本が決めやすいものです。たとえば製品 FAQ の一次回答や問い合わせ前のサービス案内です。契約判断や金額確定のような高リスク領域は、最初から主戦場にしないほうが安全です。

会話設計はモデル選定より先

会話の入口を固定する

最初のメッセージで対応範囲を明示し、ボタンやクイックリプライで「料金を知りたい」「対応可否を知りたい」のように分岐を置くと、自由入力だけより安定します。

聞く情報は最小限に

ユーザーに質問する項目は、答えやルーティングを変えるものだけに絞ります。すぐ使わない情報は後ろに回します。

回答の終わり方を決める

良い回答は「結論 → 根拠/参照元 → 次に取れる行動」の順で終わります。特に Web サイト向けでは、会話内で完結させるより、該当ページへの移動や問い合わせフォームへの誘導のほうが価値になります。

ナレッジ設計が品質の大半を決める

• 正本を決める: どの文書を正本にするか、誰が更新するか、更新頻度はどうか
• 意味単位で切る: PDF をそのまま突っ込まず、1つの手順・1つのFAQ のような塊で扱う
• 出典と更新日を見せる: どのページを見て答えたか、いつ更新された情報かを表示する
• 最新情報は外部検索に分ける: 営業日や価格改定など鮮度が重要なテーマは固定ナレッジだけで答えない

安全設計のポイント

• prompt injection を前提にする: 外部文書を読ませるボットでは、ツール実行権限を最小化する
• 権限は最小化する: 部署ごとの閲覧権限、顧客ごとの情報分離を先に決める
• 個人情報と認証は別レイヤで扱う: 認証はアプリ側、取得できる情報は絞る、監査ログを残す
• 安全設計は最初から: リリース前の最終チェックではなく、最初から仕様に組み込む

人に渡す条件を明文化する

「分からなければ担当者へ」だけでは不十分です。以下の条件を明確にしましょう。

• 認証が必要な質問
• 契約や金額の確定が必要な質問
• 出典が出せない質問
• 2回以上うまく案内できなかった質問
• 苦情や緊急性の高い相談

引き継ぎ時には「会話履歴・取得済み項目・参照したページ・詰まった理由・次に確認してほしい点」の 5 つを渡すと手戻りが減ります。

評価なしの改善は運任せ

最低限ほしい指標:

• 会話成果（ユーザーの目的が達成できたか）
• ツール利用の正しさ
• 出典の有無・誤答率
• 引き継ぎ率・離脱率
• 問い合わせ率・自己解決率・対応時間

改善は「評価セットを作る → 現状計測 → 失敗例分類 → 修正 → 再評価 → 本番監視」のループで回します。

よくある失敗

• 何でも答える総合窓口にしてしまう
• 正本と更新責任者がいない
• 出典なしで断定する
• 高リスク処理をいきなり実行させる
• 人への引き継ぎ条件が曖昧
• 評価セットがない
• 最初からマルチエージェントにする

90日で土台を作る進め方

まとめ

チャットボット作成のベストプラクティスは、モデル選定より前に、役割・知識・権限・引き継ぎ・評価を決めることです。チャットボットを「よく話すもの」ではなく「業務のどこを短くし、どこで人につなぐか」を整理するものとして設計しましょう。