会話フローチャートの作り方：設計のコツと省略すべきタイミング

会話フローチャートとは実際何なのか

会話フローチャートとは、自動化された会話が顧客の最初のメッセージから解決に至るまでの流れを示す図です。すべてのボックスは1つのステップであり、すべての矢印は遷移であり、すべてのひし形は、背後にある会話型AIが「顧客が次に何を求めているか」を判断するポイントです。

私は日々AIエージェントを構築する仕事をしていますが、設定を1行も書く前に、どのエージェントもホワイトボード上のフローチャートから始まります。理由はシンプルです。フローを書き出すことは、自分が何を分かっていないかを見つける最も安上がりな方法だからです。「注文の追跡」という会話を理解しているつもりでも、「2つ注文したのに1つしか届いていない」という分岐を描こうとした瞬間、実際に稼働しているボットなら深夜2時にぶつかっていたであろうギャップに気づかされます。

このチャートは同時に3つの役割を果たしています。思考のためのツール（エッジケースを表に引き出す）、仕様書（エンジニアリングとオペレーションが同じ絵を共有できる）、そしてカバレッジマップ（どの顧客インテントに経路があり、どれが崖から落ちているかを文字通り見て取れる）です。これらの役割は、最終的にスクリプト化されたボットを作るにせよ、ルールベースのチャットボットを作るにせよ、最新のAIエージェントを作るにせよ、変わらず重要です。

構成要素：すべてのフローチャートに必要な5つのパーツ

図作成ツールの見た目の美しさを取り払えば、優れたサポート用フローチャートはすべて同じ5つのパーツでできています。1つでも欠けると、フローに漏れが生じます。

エントリーポイント。 会話が始まる場所です。これが1つの入り口だけということはほとんどありません。顧客はライブチャットウィジェットから入ってくることもあれば、メールに返信することも、SNSでDMを送ってくることもあります。エントリーポイントが1つだけだと想定したフローチャートは、誰かが言葉抜きでスクリーンショットだけを送ってきた瞬間に破綻しがちです。

インテント検出（判断ノード）。 図の中のひし形であり、最も難しい部分です。ここでシステムは、顧客が入力した内容から本当は何を求めているのかを判断します。「荷物はどこですか」「まだ発送されていません」「追跡では配達済みとなっているが届いていません」は3つの異なる文章ですが、すべて「注文状況」という1つのインテントにマッピングされます。このマッピングを正しく行うことが、作業全体の80%を占めます。

分岐。 インテントごとに1つの経路があります。注文状況はある方向へ、返金リクエストは別の方向へ、「サブスクリプションを解約したい」はまた別の方向へ進みます。それぞれの分岐は、独自のステップと質問を持つ小さなサブフローです。

フォールバック。 インテント検出が何も返せなかった場合に何が起きるかです。これはチームが忘れがちな部分でありながら、顧客が最も気づきやすい部分でもあります。「申し訳ありませんが、理解できませんでした」がループするのは、ボットを嫌われる最速の方法だからです。本当に機能するフォールバックは、より賢い形で聞き直すか、素直に道を譲るかのどちらかです。

エスカレーション。 有人対応へのきれいな出口です。これは失敗状態ではなく、機能です。優れたフローは「人に引き継ぐ」ことを、独自のトリガー条件（低い確信度、怒りの感情、VIP顧客、意図的に除外したトピックなど）を持つ第一級の分岐として扱い、ボットが処理できなかったものすべての捨て場にはしません。ここでうまく機能するAIエスカレーションこそが、静かに信頼を積み重ねていく部分です。

作り方：ステップバイステップ

始めるのに特別なソフトウェアは必要ありません。ホワイトボード、付箋の束、あるいはLucidchartやdraw.ioのような図作成ツールがあれば、ロジックを組み立てるには十分です。ここでは、私が実際に踏んでいるプロセスを紹介します。

1. 想像ではなく、実際のチケットから上位インテントを洗い出す。 直近数百件の会話を取り出してクラスタリングしてください。ほとんどの場合、10〜15個のインテントで全体の80%をカバーできることが分かります。まずはそれらから構築し、初日にロングテールまで網羅しようとしないでください。

2. エントリーポイントを設定する。 会話が始まりうる各チャネルについて、すでに持っているコンテキスト（Shopifyの注文番号、ログイン済みアカウント、あるいは何もない状態）をメモしてください。これによって、まだ聞く必要がある質問が変わってきます。

3. 判断ごとに分岐する。 各インテントについて、ステップを並べていきます。それぞれの判断ノードは、本当に二者択一か、少数の選択肢に絞ってください。1つのノードから8本もの矢印が出ているなら、それは実は複数のインテントがトレンチコートを着て1つに見えているサインなので、分割しましょう。

4. フォールバックとエスカレーションを明確に書き出す。 すべての分岐について、次の2つの質問に答えてください。顧客が台本にないことを言った場合どうなるか、そして何が起きたら人に引き継ぐトリガーになるか。フローを「完成」と見なす前に、これらの経路を書き出しておきましょう。

5. 実際のチケットでテストする。 過去の実際の会話を50件取り出し、それぞれを手作業でチャートに沿って進めてみてください。このステップこそが、顧客との接触に耐えるフローチャートと、見た目は整っていても最初の週で破綻するフローチャートを分けるものです。私たちは、実際のキューでAIを何年も運用してきた中でこれを痛感しました。デモでは完璧に見えるボットでも、雑然とした実際の会話では静かに間違った答えを返すことがあります。だからこそ私たちは今、実際の人間に返信する前に過去のチケットに対してシミュレーションを行っています。

厳格なフローチャートが破綻する場所

ここからが本音の部分です。手作業で組んだフローチャートは、1つの大きな前提を置いています。それは、顧客が図の通りに振る舞うというものです。しかし現実はそうなりません。

典型的な失敗は、ボットをリリースしたことがある人なら誰もが知っているチャットボットの問題です。「注文の追跡」用に美しい分岐を作ったとします。ところが顧客は「ねえ、私の荷物発送された？あと住所変更できる？」と入力してきます。これは1つの文に2つのインテントが含まれており、しかもインテントノードが見たことのない言い回しなので、フローは「すみません、理解できませんでした」で行き止まりになります。これを現実世界のあらゆる言い回しのバリエーション分だけ掛け合わせると、デモでは動くのに本番では顧客をイライラさせるボットが出来上がります。

顧客が実際に求めているトレードオフは「スクリプト通りか、何でもありか」ではありません。私が話を聞いたあるCXリーダーは、本当の目標をこれ以上ないほど明確に言い表していました。

「AIがすべての質問に100%答えられるようになることは決してありません……私が必要としているのは、自分が自信を持って対応できるチケットだけを処理し、それ以外はすべて手をつけずに残しておくAIです。」

あるD2Cサプリメントブランドのカスタマー体験（CX）責任者

これがすべての本質です。フローチャートの価値は、厳格な分岐そのものにあったのではなく、ガードレールにありました。これが対応範囲で、これがエスカレーションのタイミングで、これは絶対に触らないという線引きです。最新のAIエージェントを使えば、脆い部分を捨てながらそのガードレールを保つことができます。エージェントは自然言語からインテントを理解するため、「私の荷物どこ」と「注文まだ届いてないんだけど??」を同じものとして扱い、確信があるときだけ回答し、残りは人に引き継ぎます。レーンは同じまま、行き止まりはなくなります。

フローチャートを台無しにするミス

こうしたプロジェクトを重ねるうちに、同じ失敗パターンが何度も現れます。

• フォールバック経路がない。 最もよくある失敗です。「理解できませんでした」への答えを持たないフローは、顧客をループに閉じ込めてしまいます。フォールバックは最後ではなく、最初に設計してください。
• エスカレーションを何でも入れる引き出しにしてしまう。 「人と話す」が処理できなかったものすべての行き先になっていると、キューはボットが本来対応できたはずのもので埋まり、顧客は理由もなく待たされることになります。エスカレーションには、それ自体の本物のトリガーが必要です。
• 想像上のインテント向けに作ってしまう。 実際のチケットではなくブレインストーミングから描かれたフローチャートは、変わっているのによくあるケースを必ず見逃します。データから始めましょう。
• 1つの巨大なチャート。 40個ものインテントを1つのフローで処理しようとすると、保守不能なスパゲッティ状態になります。インテントごとのサブフローに分割し、それぞれを読みやすく保ちましょう。
• 現実に対してテストしたことがない。 実際の会話で一度も検証されていないチャートは、計画ではなく単なる仮説です。特にチケットのトリアージとルーティングロジックは、自分では書いていないメッセージで負荷テストする必要があります。

このミスには、内製か購入かというバージョンもあります。フローエンジン全体を自分たちの手でコーディングしようとするケースです。別の道を選んだあるチームは、私たちにこう語ってくれました。「独自のLLMアプリケーションを書くこともできましたが、そこに時間を投資したくありませんでした。メンテナンスの必要がないものが欲しかったのです。」フローチャート自体は自分で持つ価値がありますが、その下にある配管部分はたいてい違います。

フローチャートから、すべてを描き直すことなく実際に動くエージェントへ

ここで、私たちが実際に作っているものをご紹介させてください。「分岐ではなくガードレールを設計する」という考え方に何度も立ち返るのは、それがeeselの実際の動き方だからです。

すべての会話分岐を手作業で配線する代わりに、eeselは既存のナレッジベースと過去のチケットからサポートフローを学習し、Zendesk、Freshdesk、Gorgiasなど、すでに使っているヘルプデスクの中で動作します。ガードレール、つまりどのトピックを扱うか、いつエスカレーションするか、何には絶対に触らないかは、これまで通りあなたのフローチャートから設定します。ただし、400個ものノードを持つ決定木をメンテナンスする必要はありません。

私が最も誇りに思っている部分は、先ほどのステップ5がそのまま組み込まれていることです。eeselが実際の顧客に1件でも返信する前に、何千件もの過去のチケットに対してシミュレーションを行い、実際にどう回答していたか、何を解決していたかを正確に確認できます。これは、フローチャートがうまく機能することを願うのと、実際にそうなると分かっているのとの違いです。ある企業、Gridwiseは、導入から最初の1か月でティア1リクエストの73%を解決しました。シミュレーションによって、本番稼働前におおよそのその数字を把握できていたのです。

あなたのサポートフローにeeselを試してみる

会話フローチャートをすでに描いていて、それを実際に動くボットにする作業を前に足踏みしているなら、そのギャップこそeeselが埋めるために作られたものです。あなたが設計したガードレール、つまりどのインテントを担当するか、いつ人に引き継ぐかはそのまま保ちながら、eeselはその下にある自然言語の雑多さを処理し、過去のチケットから学習することで初日からあなたのチームらしい受け答えをします。本番稼働前に、自分たちの過去データに対してシミュレーションすることもでき、試すのは無料です。