AI電話のPoCで使う検証項目と本番開始の判断例

AI電話の導入検証では、自然な音声で会話できるかを試すだけでは不十分です。本番で使えるかを判断するには、対象業務を限定します。そのうえで現在の業務と比べる指標を決め、通常時と例外時を同じ条件で試します。

PoCは導入を前提にした儀式ではありません。導入するのか、範囲を狭めて再検証するのか、見送るのかを判断する期間です。

PoCの対象を一つの通話フローに絞る

最初に、開始条件から通話後の処理までを一つの流れとして定義します。対象は件数が把握でき、会話の目的と終了条件を決められる業務が適しています。

たとえば、資料請求後に発信して検討時期を聞き、関心がある相手を営業へ転送するまでを対象にします。受電なら、代表電話で会社名と用件を聞き、担当部署へ通知するまでが一つの単位です。複数の部署や言語、複雑な契約変更まで同時に試すと、失敗の原因を特定できません。

計画書には対象件数と実施期間、対応時間を記載します。誰に電話するか、誰を対象外にするかも必要です。利用する電話番号と連携先まで一枚にまとめます。PoC中だけ手作業で補う工程がある場合は、本番で誰が担うかを別に記録します。

例えば、代表電話の折り返し受付を次のように限定します。これは実績ではなく、計画の記入例です。

最初の12ケースは障害を意図的に起こす受入試験です。通常の電話でどれだけ役立つかは、その後の限定運用で測ります。例外を多く含む試験の成功率を、そのまま本番の自動化率として使わないようにします。

現状値と判断指標を先に決める

導入効果は、AIの通話件数だけでは測れません。現在の業務を同じ指標で測り、PoC後に比較できる状態にします。

目標値は「AI化率80%」のような手段ではなく、「定型受付を完了し、例外を10分以内に担当者へ渡す」のように業務結果で置きます。10分は設定例であり、業界標準ではありません。担当者が実際に対応できる時間と用件の影響から決めます。

費用も先に上限を置きます。仮に試験費用50,000円、社内設定8時間、通話確認5時間、修正3時間を使い、社内工数を1時間3,000円で換算すると、合計は98,000円です。設定費だけを試験費用とせず、確認と修正も含めた架空の計算です。実契約の最低期間や従量費が別なら加算します。

正常系と例外系のテストケースを作る

PoCでは成功しやすい会話だけを試してはいけません。会話を止める場面や聞き返す場面、人へ渡す場面も再現します。最低限、次のケースを用意します。

• 想定した回答で正常に完了する
• 言い直し、聞き返し、沈黙、雑音がある
• 登録されていない質問を受ける
• 個人情報や契約条件に関する質問を受ける
• 人との会話を希望される
• 転送先が応答しない、営業時間外である
• 発信停止やデータ削除の希望を受ける
• システム連携が失敗する

各ケースについて、AIが答えてよい範囲と会話を終了する条件を決めます。失敗したときの通知先と復旧方法も必要です。テストケースは、想定するリスクと対策が対応する形で残します。

同じ三つの台本で候補を比べる

候補ごとに違うデモを見て採点すると、製品ではなく準備した台本の違いを比べることになります。同じ業務を担う候補へ、次の入力と期待結果を渡してください。名前は架空、番号は利用許可のある試験用番号にします。

無言と理解できない返答も別に試します。どちらも聞き返すとしても、回数と最終的な出口を決めます。会社名を訂正した後、話題が変わっても古い名前に戻らないか見てください。会話の印象だけでなく、最終記録を合否の根拠にします。

候補間では転送先の人数と在席状態、通知先、録音条件もそろえます。各社が設定にかけた時間と、自社で直せる部分は別に記録します。録音・文字起こし・要約は完成までの時間が異なることもあるため、それぞれの処理状態を確認します。

一件のIDで発信から復旧まで追う

発信では受付、発信要求、呼び出し、応答、終了の時刻を分けます。受電では着信から転送・終了までを同じ通話IDで追い、通知とCRMの記録も結び付けます。「電話した」の一状態だけでは、どこで待たされたか分かりません。

Amazon Connectのテスト実行資料でも、期待したイベントを検証できない試験は失敗になります。また、模擬通話が実担当者へ接続される可能性があるため、専用の試験キュー等を使うよう案内しています。試験で実顧客や公的な緊急番号へ発信しないでください。

データ管理と委託条件を検証範囲に含める

PoCで実データを使う前に、顧客情報がどこから入り、通話結果がどこへ渡るかを図にします。録音や文字起こし、要約も同じ図へ含めます。

次に、保存場所と保存期間を確認します。誰が閲覧できるか、どのように削除するかも決めます。操作ログと障害時の連絡、AI学習への利用有無まで確認できれば、本番との差を把握できます。

個人情報保護委員会の通話内容録音に関するFAQでは、特定の個人を識別できる通話内容は個人情報に該当すると示されています。個人情報保護法ガイドライン通則編も参照します。安全管理措置を決めるだけでなく、従業者と委託先をどのように監督するかPoC契約と運用へ反映します。

本番より緩い権限や長い保存期間でPoCを行うと、導入可否を正しく評価できません。可能な限り本番に近い権限と削除手順を使います。

運用責任者と変更手順を決める

AI電話は公開して終わりではありません。会話内容や対象リストを誰が変更するか決めます。除外条件と転送先、対応時間の変更には承認者も必要です。

業務責任者は成功条件と例外処理を確認します。システム担当は連携と障害対応を受け持ちます。個人情報保護や法務の担当者は利用目的とデータ管理、現場担当は引き継ぎ後の対応を確認します。

提供会社が会話設計や改善を担う場合は、変更依頼から反映までにかかる時間も試します。テスト環境と変更履歴、緊急停止の窓口が実際に機能するか確かめます。

Dialogflow CXの版と環境の説明は、本番で確認済みの版を使い、Webhookも環境別にする運用を推奨しています。利用製品が違っても、試験用の接続先を本番へ残さないことと、変更前の版へ戻せることは分けて確認した方がよいです。通話中の切替で影響が出る場合があるため、切替時刻も決めます。

週次レビューでは、完了率と失敗した通話を分けて確認します。誤回答や転送失敗だけでなく、停止希望や有人確認が必要だった通話も対象です。問題が起きたときに対象範囲を狭められることも、PoCの重要な確認事項です。

導入・修正・見送りの基準を決める

PoC終了前に、導入判断の会議体と必要な証拠を決めます。判断は「導入」「条件を修正して再検証」「見送り」の三つに分けると、課題を残したまま本番へ進むことを避けられます。

本導入へ進むには、必須条件を満たすだけでは足りません。重大な誤回答とデータ管理上の問題が解消している必要があります。有人対応を含む運用工数と費用が許容範囲に収まり、責任者と改善手順まで決まっていることを求めます。

例えば12ケースのうち11ケースが通り、通知の再送だけが失敗したとします。合格率91.7%でも、受け付けた用件を失うなら本番開始は延期です。修正後に失敗ケースを再実行し、正常と訂正の台本も再度通します。これが判断の記入例で、実際の製品評価ではありません。

逆に、正しく処理できても確認工数が減らない場合があります。自動受付が必要な理由が時間外の取りこぼし防止なら、その便益と費用を別に評価します。人件費削減が目的なら、確認作業を含む時間が改善するまで導入範囲を見直した方がよいです。

本番開始前は用途ごとの事故を通しで試す

PoCの成功と、本番番号で安全に動くことは別です。開始前に使用する番号・接続先・版を確定し、管理下の電話で次の確認を行います。全項目を一つの通話に詰めず、ケースごとに別の試験IDを付けます。

発信停止は、一つのキャンペーンだけか会社全体への希望かを記録します。曖昧なまま別リストから発信せず、担当者が範囲を確認するまで対象から外します。除外によって発信しなかった件は、通信障害の失敗件数と分けてください。発信可能な時間も利用者側の時刻で設定し、システムのタイムゾーンとのずれを試します。

即架電はフォームの利用目的と電話冒頭の説明を一致させます。個人情報保護委員会のFAQでは、入力画面で本人から個人情報を取得する際は原則として目的の明示が必要としています。問い合わせへの回答と、新しいサービスの勧誘を同じ目的と決めつけないようにします。

同じ受付IDの再送と、別の新しい問い合わせを区別してください。外部Webhookの署名が不正な場合は発信へ渡しません。Twilioの公式FAQではサーバー側SDKによる署名検証を説明しています。これはTwilioの方法で、別製品にはその製品の検証方式を使います。

受電では営業時間内の混雑と営業時間外を分け、祝日・臨時休業も試します。すべての用件で氏名や連絡先を必須にせず、折り返しに必要な情報だけを受け取ります。緊急性を示す発話は通常の質問から外し、事前に決めた人の窓口へ渡します。試験は社内の確認用接続先で行い、公的な緊急番号へつながないようにします。

停止と再開も開始条件に入れる

発信の停止は、新規投入と予約済みの再試行を分けて試します。停止しただけで対象を削除したり、人による一斉架電へ切り替えたりしません。再開前に未発信・応答済み・停止希望を照合します。

受電の停止は、AIを止めた後も有人受付や留守番電話へ着信するところまで確認します。代替経路で受けた用件にもIDを残し、復旧後に二重のタスクを作らないようにします。停止担当と再開承認者を決め、代理の担当者でも操作できるか試してください。

本番初日は対象用件と時間帯、件数上限を絞ります。開始直後・中間・終了時に誰が確認するかを決め、未処理を当日中に追える範囲から始めます。翌日に件数を増やすかは、前日の完了件数だけでなく誤回答と残作業を見て判断します。

最初に作るのは大きな要件書ではなく、一つの通話フローと三つの台本です。AI電話サービス検索で同じ業務を担う候補へ絞り、この条件を共通で渡すところから始めてください。