業務改善・運用
ボイスボット導入の進め方|要件整理・シナリオ設計・検証の手順
対象業務の選定から要件整理、会話とシステム連携の設計、試験、運用開始までを解説。導入チェックリストと例外を含む試験項目表を紹介します。
公開日: Daisybell Japan

ボイスボットを導入したいが、まず何を決めればよいのか。デモでは会話できても、自社の受付で使うために必要な準備が分からない。導入担当者が最初に整理したいのは、製品の機能一覧よりも、任せる仕事の始点と終点です。
ボイスボット導入は、対象業務の選定、要件整理、会話・連携の設計、試験、運用開始後の改善を一続きで考えます。 AIが答えたことだけでなく、正しい情報が記録され、必要な処理が終わったことを確認できるようにします。
この記事では、一部の用件から試行するための手順とチェックリストを紹介します。費用相場や製品ランキングではなく、担当者が関係部署と確認を進めるための実務ガイドです。
導入の流れを、作るものと判断することに分ける
| 段階 | 作るもの | 次へ進む前に確認すること |
|---|---|---|
| 対象を決める | 対象・対象外の用件一覧 | 業務の完了条件を説明できるか |
| 要件をそろえる | 要件表、担当者一覧 | 正しい情報と、判断できる人がいるか |
| 設計する | 会話分岐、連携・記録の仕様 | 通常と例外の動作がつながっているか |
| 試験する | 試験項目と結果の記録 | 実際の利用条件で、期待する結果が出るか |
| 限定運用する | 監視・切替・改善の手順 | 問題を見つけ、元の運用へ戻せるか |

図1:導入は六つの判断を積み重ねる。本文の関係や手順を整理した図。
ボイスボット自体の仕組みは、ボイスボットの基本記事で説明しています。導入では、その仕組みを自社の電話、情報、担当者の仕事につなぐことが必要です。
1. 最初に任せる用件と、完了する地点を選ぶ
候補の用件について、件数、対応にかかる時間、答えの変わりやすさ、例外の多さを調べます。件数だけで選ばず、試験で正誤を確認できるかも見ます。
たとえば「配送についての問い合わせ」では広すぎます。「本人確認後に、登録されている配送状況を案内する」「配送日時の変更希望を受け付けて担当者へ渡す」では、必要なシステム連携も終了条件も異なります。
最初の対象は、正しい回答の参照先、必要項目、人へ渡す条件を説明できる用件から選びます。緊急性や大きな影響を伴う用件は、担当部署の判断と専用の運用設計が必要です。
| 受付の範囲 | 完了条件の例 | 残る作業 |
|---|---|---|
| 定型案内 | 管理された情報に基づき案内できた | 個別相談は担当者へ |
| 希望の受付 | 必要情報を確認し、担当先へ記録が届いた | 担当者による判断・連絡 |
| データの照会 | 本人確認を行い、正しい対象の情報を案内した | 情報が見つからない場合の対応 |
| データの更新 | 確認した内容の登録成功を確かめ、結果を案内した | 失敗・結果不明時の照合と対応 |
「希望を聞けた」を「処理が終わった」と数えないよう、試験と効果測定でもこの区別を使います。
2. 電話・情報・運用の要件をそろえる
電話の接続と受付条件
今の番号をどう使うか、転送や接続の方式、対応時間、同時に受ける通話、発信者番号の扱いを確認します。実現できる構成は契約や設備によって変わります。
転送先が出ない場合、回線やシステムが停止した場合、AIの受付を一時停止する場合の案内も決めます。接続できることに加え、止まったときに誰がどの操作で切り替えるかまで確認します。
回答の情報源と更新責任者
FAQや手順書を集め、どれが正しい情報かをそろえます。料金や締切の古い版が残っている場合は、AIへ渡す前に整理します。
更新する担当者、承認する人、反映する時刻を決めます。「FAQを更新したのに、電話では古い回答をする」という状態を見つけられるよう、変更後の確認方法も用意します。
記録と個人情報の扱い
どの情報を記録し、誰が閲覧し、どこへ保存するかを確認します。個人を識別できる通話内容は個人情報に該当します。個人情報保護委員会のQ&A
録音・文字起こしの利用目的、保存期間、委託先、学習への利用有無などを、社内ルールと実際の契約・設定で照合します。取得できる情報をすべて集めるのではなく、業務上必要な項目を決めます。
3. 会話とシステム処理を一緒に設計する
会話では、最初に聞くこと、取得済みの情報、不足を聞き返す条件、終了時の案内を決めます。相手が先に答えた項目を何度も聞かないこと、訂正を反映すること、有人対応の希望を扱うことも必要です。
質問ごとの分岐を作る方法は、受電トークスクリプトの作り方を参照してください。
連携では、データを見る操作と、変更する操作を分けます。必要な権限、本人確認、入力内容の確認、処理結果の読み取りを定め、会話の流れに組み込みます。
特に注意したいのが、処理の結果が分からない場合です。たとえば、変更依頼を送った後に通信が途切れた場合、更新されていないとは限りません。結果を照合する前に同じ処理を繰り返すと、二重受付などにつながる可能性があります。
そのような場面は、連携システムの仕様に沿って状態を確認するか、担当者へ「結果未確認」として渡します。成功が確認できていないのに、会話だけを成功の案内へ進めないようにします。
4. 通常の用件と、例外の用件を分けて試す
試験では、質問に答えられたかだけでなく、保存された記録や連携先の状態まで確認します。説明が自然でも、別の顧客の情報を表示したり、訂正前の値で処理したりしていれば不合格です。

図2:試験は三つの領域を横断する。本文の関係や手順を整理した図。
NISTのAIリスク管理フレームワークでは、導入前と運用中の試験、利用環境に近い条件での評価が示されています。電話業務に一律の合格率を定める資料ではありませんが、試験を継続する考え方の参考になります。NIST AI RMF Core
試験項目表のたたき台
| 試験する場面 | 期待する動作 | 確認する証拠 |
|---|---|---|
| 通常の用件を順に話す | 必要情報をそろえ、対象の処理を終える | 会話記録、保存項目、処理結果 |
| 最初に情報をまとめて話す | 取得済み項目を使い、不足だけ聞く | 質問の重複、最終記録 |
| 電話番号や日時を訂正する | 訂正後の値を確認して使う | 最終記録、連携先の値 |
| 対象データが見つからない | 別データで代用せず、確認・引継ぎへ進む | 検索結果、案内、引継ぎ記録 |
| 本人確認ができない | 許可されない情報を開示しない | 応答内容、操作履歴 |
| 無音・雑音・聞き取り不足がある | 再案内や別経路へ切り替える | 会話の回数、終了状態 |
| 人との会話を希望する | 対応可能な有人経路へ進める | 転送結果、渡した情報 |
| 連携先が停止する | 未完了を適切に伝え、代替対応へ進む | エラー記録、担当者への通知 |
| 更新依頼の結果が不明になる | 状態を照合し、安易に再実行しない | 操作・結果の対応、二重処理の有無 |
| 会話の途中で切れる | どこまで処理したかを追える | 受付状態、未完了の扱い |
同じ台詞の試験だけでなく、言い換え、話す速度、実際の電話回線の音質なども含めます。対象の利用者や業務に近いケースがそろっているかを、窓口の担当者と確認しましょう。
5. 合格・修正・見送りの条件を決める
試験を始める前に、対象用件ごとの判断基準を決めます。平均的な完了率だけでは、重要な失敗が埋もれる場合があります。
本人確認前の情報開示、確認していない変更の実行、失敗した処理の完了案内などは、業務への影響を踏まえて扱います。どの問題があれば開始を見送り、どの問題は対象を限定して改善できるかを、判断責任者と合意します。
修正した場合は、問題が起きたケースをもう一度試し、関連する通常のケースも崩れていないかを確かめます。台本や回答の情報、連携の設定が変わったら、試験結果と対応する版を記録します。
6. 限定運用から始め、戻せる状態を保つ
最初は対象の用件、窓口、時間帯を限定する方法があります。受け付けた件数だけでなく、用件の完了、聞き直し、誤案内、人に渡した後の作業、顧客の負担も確認します。
問い合わせが滞留したときに、誰が一覧を見て処理するかを決めます。責任者が休みの日にも状態を確認できるよう、代替担当を用意します。
運用を止める条件と、従来の受付へ戻す手順を事前に試します。停止しても、AIがすでに受けた依頼は残るため、未完了の受付を誰が引き受けるかまで決めておきます。
導入前チェックリスト
【ボイスボット導入の確認】
対象用件/対象外:
AIが担当する終点:
正しい情報の参照先/更新者:
電話番号・接続・営業時間:
必要情報/本人確認:
参照できるデータ/実行できる操作:
処理成功・失敗・結果不明の判定:
有人希望・例外時の引継ぎ先:
担当者不在時の代替対応:
録音・記録の管理方法:
通常・例外の試験と証拠:
開始・修正・停止を決める責任者:
運用を戻す手順/未完了依頼の担当者:
費用と保守に必要な作業:
開始後に確認する指標と見直し日:
空欄は、導入が不可能という意味ではありません。誰と何を確認すれば試行できるかを明らかにするための欄です。外部の支援を受ける場合も、窓口・情報・システム・運用の各担当を決めて進めます。
導入計画には、日付だけでなく判断材料を置く
AI電話対応の計画を作る際、契約日、設定完了日、利用開始日だけを並べると、その間に何を確かめるべきかが曖昧になります。各段階で必要な成果物と、次に進んでよいと判断する人を決めましょう。日程に合わせて確認を省くのではなく、確認結果を見て開始範囲を調整できる計画にします。
たとえば対象用件を決める段階では、用件一覧、対応できる範囲、対象外の案内方法が成果物になります。会話設計では、質問項目、確認文、分岐、記録の形式をそろえます。テスト段階では、実施したケース、実際の結果、残っている問題を確認できる状態にします。成果物は立派な資料である必要はなく、判断に使えることが大切です。
| 段階 | 残す成果物の例 | 主に確認する人 |
|---|---|---|
| 対象選定 | 用件と対応範囲の一覧 | 業務責任者・現場担当 |
| 要件整理 | 受付条件・連携項目・対象外の扱い | 業務担当・システム担当 |
| 会話設計 | 分岐と記録形式 | 現場担当・運用管理者 |
| テスト | ケース別の結果と未解決事項 | 業務担当・検証担当 |
| 開始判断 | 開始範囲・停止条件・連絡先 | 運用責任者 |
小さな組織では同じ人が複数の役割を持つこともあります。その場合も、どの立場で確認したかを区別すると、設定が動くことだけを確認して現場の引き継ぎが抜ける、といった偏りに気付きやすくなります。委託先が設定を行う場合も、受付条件や顧客への約束を最終的に決めるのは誰かを明確にしておきます。
要件は一つの電話を最後まで追って具体化する
要件の整理では、「問い合わせを自動化する」といった大きな表現を、一件の電話で起きる行動に分解します。ここでは、営業時間外の修理相談を受け付け、翌営業日に担当者が連絡するという仮の運用を例にします。修理の可否や訪問日時は、その場では確定しない前提です。
電話の入口では、現在は相談の受付を行う時間帯であることを案内します。次に、連絡先と相談内容を確認し、必要な情報を記録します。終了時は、相談を受け付けたことと、担当者による確認が残っていることを伝えます。翌営業日には担当者が記録を引き受け、確認後に連絡します。この流れに沿って考えると、会話の外側にも必要な作業があると分かります。
「できること」を受付・確認・確定に分ける
この例でAIが相談内容を聞き取れるとしても、修理を引き受けられるとは限りません。対象製品かどうか、契約条件に合うか、部品や担当者を手配できるかといった判断が別に必要なためです。受付、担当者による確認、結果の確定を分けると、会話中に案内できる内容を限定できます。
記録に必要な項目も、この区分から決めます。担当者が連絡するための情報、相談対象を確認する情報、顧客が希望していることを整理し、使い道が説明できない項目を安易に増やさないようにします。聞き取った値をどこに保存し、誰が参照できるかも、要件の段階で確認します。
通話後の担当者の作業まで試す
デモで電話受付が成功しても、翌日に担当者が記録を見つけられなければ業務は進みません。通知先が正しいか、担当者が必要な情報を読めるか、引き受け済みと分かるかを確認します。連絡先が不足している記録を受け取った場合、誰がどの方法で補うかも決めておきます。
実際の担当者に試験用の記録を渡してもらい、連絡の準備ができるかを確認すると、不足項目や不要な説明が見つかります。設定担当者にとって分かる略語でも、受け手には分からないことがあります。画面上に保存されたことと、担当者が作業を始められることは、別の確認項目です。
導入前の基準を残し、変化を読み取れるようにする
導入後に効果を評価するためには、開始前の状態を記録しておく必要があります。対象の用件がいつ多いか、どこで待ち時間や再連絡が生じるか、担当者がどの作業に時間を使うかを確認します。最初から精密な計測が難しい場合は、対象期間と方法を明記したサンプル調査から始めることもできます。
観察する項目は導入目的に合わせます。営業時間外の受付が目的なら、翌営業日に確認できた件数や連絡先の不足を見ます。後処理の軽減が目的なら、記録作成に加えて、内容の修正や転記にかかった作業も確認します。自動で処理した通話数だけでは、現場に残った仕事を把握できません。
比較時には、繁忙期、キャンペーン、営業時間、対象用件などの条件を添えます。条件が大きく違う期間を単純比較すると、AIの導入による変化と、それ以外の要因が混ざります。完全に同じ条件を作れなくても、違いを記録しておけば、数値の解釈を慎重に進められます。
テスト結果を「開始できる範囲」に結び付ける
テストで見つかった問題は、発生した事象と業務への影響を分けて記録します。「回答が不自然」だけでは、言い回しの調整で済むのか、誤った条件を案内したのかが分かりません。相手に何を伝え、どの状態で終了し、担当者に何が残ったかまで確認します。
| 結果の種類 | 判断時に確認すること | 対応の例 |
|---|---|---|
| 表現が分かりにくい | 意味や条件を誤解させていないか | 文を直して該当ケースを再確認する |
| 情報が欠けた | 後続の担当者が作業できるか | 質問と記録項目を見直す |
| 対象外を受け付けた | 顧客への案内と実際の範囲が一致するか | 分岐を修正して周辺条件も確認する |
| 処理結果が分からない | 二重処理や誤案内の可能性があるか | 結果確認と引き継ぎの手順を整える |
| 転送先につながらない | 代わりの受付方法が機能するか | 不在時の経路と記録を検証する |
一部の用件に未解決の問題がある場合、全用件を同時に開始する必要はありません。その用件を対象外にして案内や有人対応を用意できるなら、確認済みの範囲だけで開始する判断もあります。ただし、対象外にしたつもりでも会話の中で受け付けてしまわないか、境界のテストが必要です。
修正後の確認は、問題が出た一件だけでなく、同じ分岐を使う別の用件にも行います。たとえば終了時の案内を変更したなら、正常受付、対象外、連携エラーのそれぞれで終了状態に合うかを確かめます。共通部分の変更ほど、影響を受ける範囲を明示して確認しましょう。
開始当日は、監視・判断・切り戻しを担当に割り当てる
限定運用を始める日は、誰が記録を確認し、問題があれば誰に連絡するかを事前に決めます。「何かあれば対応する」という合意だけでは、設定変更の判断や顧客への連絡が遅れます。開始直後に確認する項目と、利用範囲を狭める条件を担当者同士で共有します。

図3:限定運用の結果から、次を決める。本文の関係や手順を整理した図。
切り戻しは、電話の接続先を戻す操作だけではありません。AIがすでに受け付けた記録、未完了の手続き、担当者への引き継ぎ待ちを確認し、対応が途切れないようにする必要があります。通常の受付へ戻した後も、残っている案件を誰が確認するかまで手順に含めます。
連絡先の一覧には、業務判断の担当と技術的な復旧の担当を分けて記載します。システムが復旧しても、誤った案内を受けた顧客への確認が残る場合があります。それぞれの作業を完了扱いにする条件を決め、操作完了だけで対応全体を閉じないようにします。
用件を増やすときも、小さな導入として扱う
運用が安定した後に対象を広げる場合、新しい用件の受付条件、確認項目、引き継ぎ先を整理します。既存の仕組みを使える部分が多くても、新しい業務の判断まで確認済みとは限りません。変更した箇所と既存用件への影響を記録して、開始前に必要なテストを行います。
運用ルールには、案内内容の更新担当、更新が必要になる情報源、変更の確認方法を含めます。営業時間や担当窓口が変わるたびに誰かが気付いて直す仕組みでは、更新漏れを防ぎにくくなります。業務側の変更を会話と記録先へ反映する流れを定めることが、導入後の品質を維持する土台になります。
よくある質問
導入にはどれくらいの期間がかかりますか?
対象業務、既存設備、連携の有無、情報整備、試験範囲によって変わります。会話の設定期間だけでなく、社内確認と試験に必要な時間を見積もります。
システム連携がなくても始められますか?
定型案内や希望の受付など、連携なしで検討できる範囲はあります。その場合、記録をどこへ渡し、誰が後の処理を行うかを明確にします。
デモでうまく話せれば導入してよいですか?
デモだけでは、自社の情報、回線、利用者の言い方、例外時の処理を確認できません。対象業務に合う試験項目で、会話と処理結果の両方を確かめます。
導入後は、そのまま使い続けられますか?
受付ルールやFAQ、システムは変わります。更新担当と確認手順を決め、変更後の回答や処理、引継ぎが正しく動くかを継続して確認します。
まずは、試す用件と判定条件を一枚にまとめる
ボイスボット導入を具体化するには、対象用件、完了条件、必要情報、人に渡す条件、試験で確かめることをそろえるのが第一歩です。これらが見えると、どの機能が必要で、どの準備が残っているかを話し合いやすくなります。
Daisybellへのご相談では、対象にしたい電話業務と、現在の受付手順・連携先をお聞かせください。