chatbot-flow-design

チャットボットのフロー設計

ウェブサイトのチャットボットや AI エージェントの会話フローを設計するための、シニアグロースプラクティショナーによる実践ガイドです。インテント認識のアーキテクチャ、分岐ロジック、フォールバック処理、人間へのエスカレーション、会話分析を扱います。ボットが対応できることを把握し、対応できない場合に適切な窓口へ案内できるようにするための手法です。

ウェブ上のチャットボットの多くは、次のいずれかの理由で失敗します。スクリプト型のボットは、ユーザーが想定外の言い回しをした瞬間に機能しなくなり、ユーザーは自分の状況に合わない決定木に沿って進まされます。構造のない LLM 搭載ボットは幻覚を起こします。料金、ポリシー、機能に関する質問に自信満々に答え、頻繁に回答を捏造するため、サポート負荷が増し、信頼が損なわれます。

うまく機能するチャットボットは、これとは異なる方法を取ります。ボットが対応できることとできないことを定義するインテントアーキテクチャを備えています。回答の根拠をナレッジベースに置くことで、事実を捏造しないようにします。不明確なインテントや対応範囲外のインテントに対して、明示的なフォールバック経路を用意します。ボットの役割を終えたら、スムーズに人間へ引き継ぎます。ボットが対応範囲を正直に示すため、ユーザーはボットを信頼します。

語り手は、チャットボットが信頼されるブランドの接点となるのを見届ける一方、責任上のリスクとなるのも見てきたシニアグロースプラクティショナーです。この二つの結果を分けるアーキテクチャについて、実践的かつ明確な意見を持ち、チャットボットへの投資が適切でない場合や、既存のチャットボットは調整ではなく再設計が必要な場合には、率直に指摘します。

このスキルを使用する場面：チャットボットを初めて企画するとき、幻覚を起こしたりエッジケースに対応できなかったりするチャットボットを監査するとき、インテントアーキテクチャやフォールバックパターンを設計するとき、または人間へエスカレーションするタイミングを決めるときです。

---

このスキルの対象範囲

このスキルでは、チャットボットの実装ではなく、会話フローのアーキテクチャとしてのチャットボット設計を扱います。グロースツールに関する区分は次のとおりです。

• ai-content-collaboration はコンテンツワークフローにおける AI を扱います。このスキルは、顧客対応の会話における AI を扱います。
• integration-orchestrator は、チャットボット導入におけるチーム横断の連携を扱います。このスキルは、会話設計そのものを扱います。
• pm-spec-writing は、ボットを構築するエンジニア向けの仕様書を扱います。このスキルは会話で何を実現するかを定め、pm-spec-writing はその内容を伝える方法を扱います。
• discovery-research-synthesis は、インテントアーキテクチャの基礎となる顧客調査を扱います。このスキルへのインプットであり、その一部ではありません。
• chatbot-flow-design（このスキル） は、インテントアーキテクチャ、ナレッジベースによる根拠づけ、フォールバックパターン、エスカレーションの原則を扱います。

対象となる読者：チャットボットを活用したグロースツールを提供するグロースマーケターやプロダクトマーケター、マーケティングやサポートの用途で会話フローを設計する社内チーム、クライアント向けにチャットボット業務を行う代理店です。

対象外：コンテンツワークフローにおける AI（ai-content-collaboration の対象）；チャットボットのエンジニアリング実装（pm-spec-writing を通じて引き継ぎます）；プラットフォーム固有のボット設定（実装側で扱います）；音声エージェントや IVR フロー（関連する原則は適用できますが、手法が異なります）。

---

チャットボットを導入する判断：チャットボットを導入する価値がある場合

チャットボットを設計する前に、チャットボットが適切なツールかどうかを判断してください。

チャットボットを導入する価値がある場合：

• 対象者が同じ質問を何度も繰り返す場合。FAQ形式のサポート、製品の機能に関する質問、見込み客の振り分けなどです。ボットが問い合わせ量に対応し、人間が例外に対応します。
• 人間が応答できない時間帯に、対象者がサイトを利用する場合。ボットがその対応の空白を有意義に埋めます。
• ボットが実際の知識（ドキュメント、製品仕様、価格ページ）に基づいて回答できる場合。根拠がなければ、ボットの回答はありきたりなものにとどまるか、最悪の場合は捏造になります。
• チームがボットを保守できる場合。チャットボットは劣化し、インテントはずれていき、ナレッジベースは更新が必要です。保守に取り組む意思がなければ、ボットは古くなり、負債になります。

チャットボットを導入する価値がない場合：

• 対象者が人間との会話を期待している場合。営業での会話、複雑なトラブルシューティング、デリケートな話題では、人間を最初に対応させるのが適切なことがよくあります。
• チームが実際の知識に基づいてボットを応答させられない場合。根拠のないボットは幻覚を起こすか、価値をもたらさないほどありきたりな回答に終始します。
• ボットが機能している人間の対応窓口に取って代わる場合。質の高い営業チャットを質の低いボットに置き換えると、体験が悪化します。
• 対象者が少なく、人間が直接会話するほうが効率的な場合。
• チームがボットを保守できない場合。古くなったボットは誤った回答をします。

判断すべきなのは「チャットボットを導入すべきか」ではなく、「この特定の対象者と会話に、チャットボットが適切なツールか」です。

詳細は references/chatbot-decision-criteria.md を参照してください。

---

スクリプト型ボット vs 幻覚を起こすボット vs 構造化された誘導型の会話

要となる枠組みです。

スクリプト型ボット。 固定された決定木です。「X については 1、Y については 2 を押してください」という形式です。ユーザーがスクリプトで想定されていない言い回しをした途端に機能しなくなります。チャットボット版の自動音声案内です。代償として、ユーザーの実際の質問は未回答のままになり、ボットはユーザーに合わない経路を進ませ、ボットがない場合より悪い体験を残します。

幻覚を起こすボット。 構造を持たず、LLM を搭載したボットです。価格、ポリシー、機能に関する質問に自信満々に回答し、頻繁に答えをでっち上げます。法的責任のリスクがあり、信頼を損ない、誤った回答が顧客に届けばサポートの負担が増します。代償として、ボットの自信満々な誤回答は、ボットがない場合よりもブランドに大きな損害を与え、チームは顧客からの苦情を通じて幻覚の発生を知ることになります。

構造化された誘導型の会話。 インテント設計、ナレッジベースに基づく回答、明確に定義されたフォールバック経路、人間への明示的なエスカレーションを備えた、LLM 搭載のボットです。ボットは、自分が知っていることと知らないことを把握し、適切な経路へ誘導します。代償として、事前の設計にはかなりの労力がかかり、実際に保守も必要ですが、ボットが対応範囲について誠実であるため、対象者はボットを信頼します。

見極めの基準です。想定範囲外の質問をボットにしてみてください。自信満々に答えをでっち上げる（幻覚型）、融通なく拒否する（スクリプト型）、それとも人間や別のリソースへ正直に誘導する（構造化された誘導型）でしょうか。目指すべきは 3 つ目の対応です。

---

インテントアーキテクチャ

ボットが対応できることとできないことを定義します。

原則。 ボットが対応できるインテントを明確に定めます。各インテントは、会話パターン（尋ねる質問、根拠とする知識、提供する回答）に対応します。インテントの範囲外のものはすべて、フォールバックに回します。

インテント設計パターン。

• 名前付きインテント。 「料金に関する質問」「機能の比較」「連携に関する質問」「サポートへのエスカレーション」「デモのリクエスト」など、それぞれのインテントを明示します。
• インテント階層。 上位カテゴリとサブインテントを設けます。「料金に関する質問」には、「プランの比較」「割引に関する問い合わせ」「請求に関する質問」などのサブインテントを含めます。
• インテントの境界。 各インテントの範囲を明確にします。範囲外のトピックはフォールバックに振り分けます。

インテントの網羅率。 ボットのインテントは、想定される会話の70～90％を網羅する必要があります。残りはフォールバックに回します。100％を網羅しようとすると、ボットが確実に扱えないほどインテントが肥大化することがよくあります。

インテントのメンテナンス。 製品の進化、対象ユーザーの変化、会話内容の変化に伴い、インテントは実態と乖離していきます。定期的に見直すことで、有用なインテントと改善が必要なインテントを把握できます。

詳細はreferences/intent-architecture-patterns.mdをご覧ください。

---

ナレッジベースによる根拠付け

ボットの回答は、根拠のない自信ではなく、実際の知識に基づく必要があります。

原則。 ボットの回答生成では、構造化されたナレッジベース（ドキュメント、製品仕様、料金ページ、サポート記事）を参照します。ボットは回答を作り出すのではなく、情報を検索して提示します。

根拠付けのパターン。

• 検索拡張生成（RAG）。 ボットは回答を生成する前にナレッジベースを検索し、関連する情報を探します。回答は検索された情報に基づきます。
• 信頼できる情報源の設計。 ナレッジベースを正式な情報源とします。ボットが回答する際には、その根拠となる情報源を特定します。
• 引用の徹底。 ボットは情報源を引用できます（「料金ページによると、……」など）。回答の出所が分かることは、対象ユーザーにとって有益です。
• ナレッジベースのメンテナンス。 製品の進化に合わせてナレッジベースを更新し、ボットの回答を最新の状態に保ちます。

幻覚を起こすボットの失敗例。 根拠付けがありません。LLMは何もないところから、もっともらしい回答を自信たっぷりに生成します。チームが誤った回答に気付くのは、顧客から苦情が寄せられたときです。

構造化されたガイドによる成功例。 回答に根拠があります。ボットの回答は正式な情報源と一致します。顧客向けの回答精度が維持されます。

詳細はreferences/knowledge-base-grounding-patterns.mdをご覧ください。

---

分岐と条件ロジック

ユーザーの入力に応じて、ボットが会話をどう適応させるかを説明します。

原則。 ボットの会話は、ユーザーの入力（認識されたインテント、以前の回答、ユーザー属性）に応じて分岐できます。分岐によって、会話に適応性を持たせることができます。

分岐パターン。

• インテント駆動型の分岐。 インテントごとに、異なる会話フローへ進みます。
• コンテキスト駆動型の分岐。 「プランAとプランBのどちらについてお尋ねですか？」と尋ね、プランごとの情報に振り分けます。
• ユーザー属性による分岐。 ログイン中のユーザーには匿名ユーザーとは異なる回答を提示したり、エンタープライズの訪問者にはSMBの訪問者とは異なる回答を提示したりする場合があります。
• 複数ターンにわたる分岐。 会話はターンを重ねるごとに深まり、後のターンではそれまでのコンテキストを踏まえます。

分岐の徹底。 各分岐は価値を加える必要があります。必要のない確認を求めるなど、見せかけだけの分岐は、会話に手間を増やします。

分岐の限度。 分岐が深すぎるボットは、ユーザーを離脱させてしまいます。ユーザーが解決を求めるまでの実用的な限度は、多くの場合3～5ターンです。

詳細はreferences/branching-and-conditional-logic.mdをご覧ください。

---

フォールバックのパターン

意図が不明確な場合や、対応範囲外の場合にどうするかを説明します。

基本原則。 すべての会話にはフォールバックの手順があります。ボットには、「わかりません」「お役に立てるかどうかわかりません」「担当者におつなぎします」といった返答が用意されています。

フォールバックのパターン。

• 確認の質問。 「お探しの内容について、もう少し詳しく教えていただけますか？」と尋ねて、ユーザーに意図を明確にしてもらいます。問題を解決できることもあります。
• 意図の候補を提示。 「X、Y、Zについてお手伝いできます。そのいずれかについてお尋ねですか？」と、ボットが対応できる内容を示します。
• リソースへの誘導。 「ご質問にはお答えできませんが、関連する内容を掲載した[ドキュメントページ]はこちらです。」
• 担当者へのエスカレーション。 「対応できる担当者におつなぎします。」

フォールバックの運用ルール。 複数のフォールバック層を用意します。まず、確認を試みます。1回のやり取りで意図が明確にならなければ、別の選択肢を提案するか、エスカレーションします。ユーザーに確認を5回も繰り返させてはいけません。

フォールバックで正直さを示す原則。 知らないことを認めるボットは、自信があるふりをするボットよりも信頼されます。ユーザーは、あらかじめ伝えられた制約には寛容ですが、自信たっぷりに伝えられた誤答には厳しく反応します。

詳細はreferences/fallback-pattern-design.mdを参照してください。

---

担当者へのエスカレーション

どのような場合に、どのように、どんなコンテキストを引き継ぐかを説明します。

基本原則。 人による対応が必要な会話もあります。ボットは、対応範囲を超えた場合、ユーザーから希望があった場合、または会話のパターンからユーザーが不満を感じていると判断した場合にエスカレーションします。

エスカレーションのトリガー。

• ユーザーからの依頼。 「担当者と話したい」と言われた場合、ボットはすぐにエスカレーションします。
• 対応範囲外の意図。 ユーザーの意図が対応範囲外だとボットが認識した場合、意図のコンテキストを添えてエスカレーションします。
• フォールバックの繰り返し。 意図が不明確なやり取りが2～3回続いた場合、ボットは繰り返しを続けずにエスカレーションします。
• 感情に基づく判断。 ユーザーの感情から不満がうかがえる場合、ボットは対応を続けずにエスカレーションします。
• 重大な影響を伴う話題。 キャンセル、苦情、セキュリティなどの機微な話題は、原則としてエスカレーションします。

エスカレーション時のコンテキストの引き継ぎ。 エスカレーションする際、ボットは会話履歴と認識した意図を担当者に渡します。担当者は最初からやり直すのではなく、ボットが対応したところから引き継ぎます。

エスカレーション品質のテスト。 担当者はコンテキストをスムーズに引き継げるでしょうか。それとも、ユーザーにすべてを繰り返してもらう必要があるでしょうか。後者は、引き継ぎに問題があることを示しています。

詳細はreferences/escalation-to-human-patterns.mdを参照してください。

---

会話分析

ボットが適切にできていることと、できていないことを測定します。

基本原則。 意図ごと、フォールバックごと、エスカレーションごとにボットのパフォーマンスを追跡します。データは、保守や設計の改善に役立ちます。

会話の指標。

• 意図認識率。 会話のうち、意図が正しく分類された割合はどれくらいでしょうか？
• 意図ごとの解決率。 意図Xから始まる会話のうち、正常に解決した（ユーザーが必要としていた回答を得た）割合はどれくらいでしょうか？
• フォールバック率。 フォールバックに至った会話の割合はどれくらいでしょうか？ フォールバック率が高い場合、意図の不足が疑われます。
• 意図ごとのエスカレーション率。 各意図の会話のうち、エスカレーションされた割合はどれくらいでしょうか？ エスカレーション率が高い場合、その意図はボットで対応すべきではない可能性があります。
• ユーザー満足度。 実施可能であれば、会話後のアンケートで測定します。有用ですが限界もあり、多くのユーザーは回答しません。

診断への活用。

• フォールバック率が高い：意図が不足している、または不明確です。意図のセットを拡充または調整します。
• 意図ごとの解決率が低い：ナレッジベースが不十分です。グラウンディングを改善します。
• 意図ごとのエスカレーション率が高い：その意図はボットでの対応に適していない可能性があります。
• 会話中にフォールバックが繰り返される：確認の質問がうまく機能していません。確認方法を再設計します。

詳細はreferences/conversation-analytics-patterns.mdを参照してください。

---

よくある失敗パターン

まずは概要です。診断については、references/common-chatbot-failures.md を参照してください。

• 「ボットが料金についてでたらめな回答をします。」ハルシネーションを起こすボットのパターンです。料金に関する信頼できる情報源に基づいていません。
• 「ボットが融通が利かず、役に立たないとユーザーに言われます。」スクリプト型ボットのパターンです。インテントが実際の質問をカバーしていません。
• 「ボットがリードの選別を誤るため、営業チームが怒っています。」インテント認識またはルーティングロジックに問題があります。選別のフローを監査してください。
• 「チャットボットの導入後、サポートチケットが増えています。」ボットが誤った回答をして、ユーザーをサポートに誘導しています。情報の根拠と問題解決の流れを監査してください。
• 「ユーザーが会話の途中で離脱します。」ボットがループしているか、フォールバックのパターンが不十分です。
• 「ボットが実際に何をしているのか分かりません。」分析機能が不足しています。さらなる変更を加える前に、計測できるようにしてください。
• 「導入時はボットの品質が高かったのに、劣化しました。」メンテナンスが滞っています。ナレッジベースまたはインテントセットが古くなっています。
• 「ボットは何でも人間にエスカレーションします。」エスカレーションのロジックが寛容すぎます。ボットが対応できる範囲を広げるべきです。
• 「ボットは何でも自分で対応しようとします。」エスカレーションのロジックが厳しすぎます。ボットはもっとエスカレーションすべきです。
• 「5分前に何を尋ねたかボットが覚えていない、とユーザーから苦情が寄せられます。」会話のコンテキストがターンをまたいで保持されていません。

---

フレームワーク：チャットボットのフロー設計における12の考慮事項

チャットボットを設計または監査する際は、次の12項目を確認してください。

1. チャットボットを採用するかどうか。 この対象者や会話にチャットボットは適切なツールでしょうか。それとも、別のチャネルのほうが適しているでしょうか。
2. スクリプト型でもハルシネーション型でもなく、構造化されたガイド付き会話にする。 インテントアーキテクチャ、ナレッジベースに基づく回答、適切なフォールバック運用を検討します。
3. インテントアーキテクチャを適切に設計する。 範囲が明確なインテントに名前を付け、想定される会話の70～90％をカバーすることを目標にします。
4. ナレッジベースに基づいて回答する。 回答は信頼できる情報源から取得し、ボットが回答を捏造しないようにします。
5. 分岐に価値を持たせる。 各分岐は実際のニーズに応えるものとし、深さは3～5ターンに制限します。
6. 複数段階のフォールバックパターンを用意する。 明確化、インテントの提案、リソースへの引き継ぎ、人間へのエスカレーションを用意します。
7. エスカレーションのトリガーを定義する。 ユーザーからの要望、対応範囲外の内容、フォールバックの繰り返し、感情に基づく判断、重要度の高い状況を対象とします。
8. エスカレーション時にコンテキストを適切に引き継ぐ。 人間の担当者がボットの続きから対応できるようにします。
9. 分析機能を導入する。 インテントごとの認識率、解決率、フォールバック率、エスカレーション率を計測します。
10. メンテナンスの頻度を定める。 ナレッジベースを更新し、インテントセットを監査し、ボットの品質を検証します。
11. ブランドの語り口に一貫性を持たせる。 ボットの話し方を、表現するブランドに合わせます。
12. 対象者との適合性を正直に判断する。 ボットが実際に支援できる対象者にサービスを提供し、適合しない対象者は速やかにエスカレーションします。

このフレームワークを活用すると、自分が把握していることを理解し、実際の知識に基づいて回答し、適切にエスカレーションし、対応範囲を正直に伝えることで信頼を築くチャットボットを実現できます。

---

参考ファイル

• references/chatbot-decision-criteria.md - チャットボットの導入が妥当な場合と、そうでない場合について説明します。構築を正当化する条件を示します。
• references/intent-architecture-patterns.md - ボットが対応できることとできないことの定義について説明します。名前付きインテント、階層、境界、カバレッジを扱います。
• references/knowledge-base-grounding-patterns.md - 検索拡張生成、信頼できる情報源の設計、引用の徹底、ナレッジベースの保守について説明します。
• references/branching-and-conditional-logic.md - ボットが会話に応じてどのように対応を変えるかについて説明します。インテント主導、コンテキスト主導、ユーザー属性、複数ターンにわたる分岐を扱います。
• references/fallback-pattern-design.md - インテントが不明確な場合や、対応範囲外の場合に何が起こるかを説明します。多層的なフォールバックパターンを扱います。
• references/escalation-to-human-patterns.md - エスカレーションのタイミング、方法、共有するコンテキストについて説明します。エスカレーションのトリガーと引き継ぎの品質を扱います。
• references/conversation-analytics-patterns.md - インテントごとの指標、診断への活用、保守に役立つデータについて説明します。
• references/chatbot-anti-patterns.md - チャットボットのように見えて、信頼を損なうパターンについて説明します。
• references/common-chatbot-failures.md - 診断と対処法を含む、10 種類以上の失敗パターンについて説明します。

---

まとめ：チャットボットは、自分が何を知らないかを把握しているときに導入する価値があります

継続的に価値を生み出すチャットボットとは、利用者から信頼されるものです。すべての質問に答えられるからでも、無限の能力があるからでもありません。対応範囲を正直に伝え、実際の知識に基づいて回答し、ボットの役割を終えたら人間にエスカレーションするからです。

それが最低限満たすべき基準です。この基準を下回るのは、スクリプト型ボット（エッジケースに対応できない硬直的なツリー構造）や、幻覚を起こすボット（構造がなく、でたらめを生成する LLM）です。この基準を上回るのは、インテントアーキテクチャ、ナレッジベースによるグラウンディング、フォールバックの徹底、エスカレーションパターンを組み合わせ、利用者が信頼できるツールとなった、構造化されたガイド付き会話です。

大切なのは設計上の選択です。ボットにできることを定義するインテント。幻覚を防ぐナレッジベースによるグラウンディング。不明な事柄に適切に対処するフォールバックパターン。身を引くタイミングを判断するエスカレーションのロジック。機能していることと、そうでないことを明らかにする分析。ボットが体現するブランドとの一貫性を保つ保守の徹底です。