ボイスボットのシナリオの作り方　コールセンターの通話ログから組む5つの手順

ボイスボットのシナリオは、分岐図から描き始めると失敗します。先に書くのは「この通話は、何が揃えば終えてよいか」という完了条件で、会話の流れはそこから逆算して組み立てます。手順は5つです。用件を1つ選んで完了条件を書く、通話ログから顧客の実際の言い方を集める、会話の骨組みと台詞を書く、外れたときの出口を付ける、テストして本番のログで直す。本稿では、通販のコールセンターの「配送日の変更」を例に、シナリオ表の実物まで示します。

聞き返し・無言・人への転送の細かな設計は個別の記事に任せ、ここでは1本のシナリオを最初から最後まで組む流れに集中します。

1. 用件を1つ選び、完了条件を書く

最初の1本は、件数が多く、手続きが決まっている用件を1つだけ選びます。複数の用件を同時に作ると、どの用件の設計が原因で通話が落ちたのか分からなくなるからです。

選んだら、完了条件を書きます。完了条件とは「この情報が揃い、この確認が取れ、この処理が終われば、通話を終えてよい」という定義です。AWSの対話ボット基盤Amazon Lex V2の開発者ガイドも、インテント（用件）の構成を、用件の達成に必要なパラメータ（スロット）、実行前の確認、実行、締めの応答という部品で説明しています。製品が違っても、シナリオの中身はこの部品の組み合わせです。

配送日の変更なら、完了条件は次のようになります。

項目	配送日の変更（例）
必要な情報	注文番号、本人確認用の電話番号下4桁、希望の配送日、希望の時間帯
確認	「○月○日の午前に変更します。よろしいですか」に顧客が「はい」
処理	受注システムの配送日を更新し、成功の応答が返る
締め	変更後の日時を伝え、確認のSMSを送ると案内して終話
完了にしない状態	発送済みで変更できない、本人確認が一致しない、希望日が受付期間外

大事なのは最後の行。完了にしない状態を先に書いておくと、手順4の出口がそのまま決まります。

2. 通話ログから顧客の言い方を集める

完了条件が決まったら、その用件の通話を実際に聞くか、文字起こしを読みます。集めるのは、顧客が用件を最初にどう言うかです。

「配送日を変えたい」と言う人ばかりではありません。「明日受け取れないんですけど」「届く日をずらせますか」「不在票が入っていて」。最後の例は、配送日の変更なのか再配達の依頼なのか、聞き分けが要ります。こうした言い方を少なくとも数十件集め、どの言い方がどの用件に当たるかを表にします。Amazon Lex V2のガイドは、1つの用件につき10個以上の発話例を用意するよう勧めています。これは製品の最低限の目安で、現場の言い方の幅を拾うにはログからの収集が欠かせません。

この工程を飛ばすと、ボットは設計者が想定した言い方にしか反応しません。BIZTELを提供するリンクが公表した2024年の意識調査によると、無人音声サービスに不満を持った人の51.7%が「自分の用件と合致する選択肢がなかった」を理由に挙げました。顧客の言葉と設計側の言葉がずれると、こう感じられます。

3. 会話の骨組みと台詞を書く

骨組みは、どの用件でもほぼ同じ6段階で組めます。名乗りと用件の聞き取り、用件の確定、必要な情報の取得、確認、処理、締めです。各段階に、ボットの台詞と、期待する顧客の返答と、次の段階を書きます。

段階	ボットの台詞（例）	期待する返答	次へ進む条件
名乗り・聞き取り	「○○通販の自動音声です。ご用件をお話しください」	「配送日を変えたい」など	用件を判別できた
用件の確定	「お届け日の変更ですね」	「はい」	肯定の返答
情報の取得	「ご注文番号を、数字のボタンで入力してください」	10桁の数字	照合が一致
情報の取得	「ご注文時の電話番号の下4桁を、数字のボタンで入力してください」	4桁の数字	注文情報と一致
情報の取得	「ご希望のお届け日をお話しください」	「11月10日」など	受付期間内の日付
情報の取得	「ご希望の時間帯を、午前、午後、夜間からお選びください」	「午前」など	3つのいずれか
確認	「11月10日火曜日の午前に変更します。よろしいですか」	「はい」	肯定の返答
処理・締め	「変更しました。確認のメッセージをお送りします」	なし	更新の成功

台詞は、紙で読んで分かる文ではなく、耳で一度聞いて分かる文にします。1つの台詞で聞くことは1つ。日付は曜日を添えて読み上げる。注文番号のように音声で崩れやすい項目は、最初から数字ボタンで受ける設計もあります。音声とボタンの切り替えはプッシュ入力へ切り替える設計で詳しく書きました。

用件の確定の段階は省きたくなります。それでも残すのが無難です。ここで聞き違いを止めておけば、情報を全部取った後で「そうではなく再配達の話です」と戻る事態を防げます。

4. 外れたときの出口を付ける

骨組みの各段階には、期待どおりの返答が来なかったときの行き先を付けます。外れ方はおおむね3種類です。

• 聞き取れなかった、または想定外の返答だった
• 無言が続いた
• 完了にしない状態に当たった（手順1の表の最終行）

1つめは、言い換えて聞き直し、決めた回数を超えたら別の手段に移します。Amazon Lex V2は、スロットの値や確認への返答を設定した回数内に認識できないと、フォールバック（想定外の受け皿）に移る仕組みです。そこで折り返し番号を受けるか、オペレーターにつなぐ。何回で諦めるかを、段階ごとに表へ書いておきます。

2つめの無言は、考え中なのか聞こえていないのかで対応が変わります。待ち時間と案内文の決め方は無入力時の案内を設計する記事に任せます。

3つめは、ボットの失敗ではなく業務上の分岐です。発送済みなら配送業者への連絡方法を案内する、本人確認が一致しなければ人につなぐ。人につなぐときに何を渡すかは、AIから人へ渡す設計を参照してください。

5. テストして、本番のログで直す

テストは2種類に分けます。1つは、手順2で集めた言い方を全部流して、正しい用件と段階に進むかを確かめる試験です。もう1つは、手順4の外れ方を意図的に起こす試験で、無言、言い直し、番号の打ち間違い、発送済みの注文を順に試します。

一度通ったテストは、保存して繰り返し流します。Googleの対話エージェント基盤Dialogflow CXは、保存した会話を流し直して期待どおりに応答するかを確かめるテスト機能を備え、目的を不具合の発見と回帰（直したつもりで別の箇所を壊すこと）の防止と説明しています。台詞を1か所直すたびに、前に通った会話が今も通るかを確かめる習慣が、シナリオの品質を保ちます。本番化の合格基準の置き方は、当ラボのPoC評価項目の記事にまとめました。

本番に出たら、通話を段階ごとに数えます。名乗りで切った、用件の確定で落ちた、情報の取得で人に回った、完了した。どの段階で抜けたかが分かれば、直す場所が台詞なのか、言い方の収集なのか、業務の分岐なのかを切り分けられます。完了率の合計だけを見ていると、この切り分けはできません。

生成AI型ならシナリオは要らないのか

要ります。書く中身が変わるだけです。

生成AI型のボイスボットは、分岐を1つずつ書く代わりに、目的と手順と会話例を自然文で与えます。Dialogflow CXのプレイブックも、目的（ゴール）、目的を達成するための手順、会話例という部品で組み、会話例はLLMへの少数の手本として使われると説明しています。

それでも、完了条件と完了にしない状態は人が決めて書くしかありません。生成AIは言い方の揺れには強くなりますが、「発送済みなら変更しない」「本人確認が一致しなければ人へ」という業務の決まりを自分で知ることはないからです。生成AI型に移ると、シナリオ作りの重心は分岐図から、手順1の完了条件の表と手順5のテストへ移ると見ています。

まとめ

• シナリオは分岐図からではなく、完了条件と「完了にしない状態」から書く
• 顧客の言い方は通話ログから集める。設計者の想定した言い方だけでは用件を聞き分けられない
• 骨組みは6段階で組み、台詞は耳で一度聞いて分かる文にする
• 各段階に、聞き取れない・無言・業務上の分岐の3つの出口を付ける
• テストは保存して繰り返し流し、本番では段階ごとに離脱を数える

最初の1本に選ぼうとしている用件の完了条件を、いま表の5行で書けるでしょうか。

よくある質問

ボイスボットのシナリオは誰が作るべきですか。

業務の決まりを知るSVや運用担当が完了条件と台詞を書き、ベンダーや情報システム担当が実装する分担が現実的です。完了条件を外部に丸投げすると、業務上の例外が抜けます。

最初のシナリオは何本作ればよいですか。

1本です。件数が多く手続きが決まった用件を1つ選び、本番のログで段階ごとの離脱を見て直してから、次の用件に広げます。

発話例はいくつ集めればよいですか。

Amazon Lex V2のガイドは1用件あたり10個以上を勧めています。実務では通話ログから数十件を集め、似た言い方をまとめて登録するほうが聞き分けの精度が上がります。

生成AI型なら分岐の設計は不要ですか。

言い方の揺れへの対応は楽になりますが、完了条件と例外の扱いは人が決めて書きます。テストの重要性はむしろ上がります。

---

注記: 確認日は2026年10月16日です。配送日の変更のシナリオ表と台詞は説明用の例であり、実在の企業の設計ではありません。製品の仕様は各社の公式ドキュメントの同日時点の記述によります。調査の数値はリンクの発表（20〜60代500名のインターネット調査）によるものです。本稿はAI著者によるデスクリサーチと編集部の設計案であり、特定の製品やベンダーを推奨するものではありません。

---

出典

• AWS「Adding intents - Amazon Lex」
• AWS「AMAZON.FallbackIntent - Amazon Lex」
• Google Cloud「Test cases（Dialogflow CX）」
• Google Cloud「Playbooks（Dialogflow CX）」
• リンク「AI時代における顧客コミュニケーションおよび窓口対応に関する意識調査」（2024年11月19日）

この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。