AI電話のPoCは、自然に会話できるデモを確認する場ではありません。本番で起きる訂正、沈黙、聞き取りづらい固有名詞、転送不能、外部APIの遅延、再入電、同時着信を含め、業務が安全に続くかを確かめる検証です。最初から全用件を対象にせず、正本データと担当者が明確な一つの用件から、通話後の処理まで通します。
PoCを6つのGateに分ける
| Gate | 確認する対象 | 次へ進む条件 |
|---|---|---|
| 0: 対象選定 | 上位用件、対象外、担当、正本データ | 自動化しない判断と人の所有者が文書化されている |
| 1: 会話 | 通常会話、長い説明、訂正、沈黙、割込み | 必要項目を聞け、途中で安全に終えられる |
| 2: 業務連携 | 予約・CRM・通知・Case作成 | ReadとWriteの境界、冪等性、監査が確認できる |
| 3: 例外 | 認識不能、API失敗、転送不能、再入電 | 顧客と担当者に次の経路が示される |
| 4: 運用 | 台本更新、当番、SLA、監視、障害対応 | 誰がいつ直すか、記録と連絡経路がある |
| 5: 限定本番 | 実着信、指標、レビュー | 範囲を広げる根拠と停止条件が合意されている |
Gateの目的は承認を増やすことではなく、問題を本番利用者の前ではなく小さな範囲で見つけることです。
会話・連携・運用を横断する試験マトリクス
| 試験 | 見る失敗 | 期待する挙動 |
|---|---|---|
| 通常会話 | 必要項目の取り漏れ | 用件・連絡先・次の行動を確認してCase化 |
| 長い説明・訂正 | 古い情報のまま確定 | 要約を確認し、修正後の値だけを使う |
| 無音・Barge-in | 固定待ち時間での誤終話 | 再確認または人への切替、割込みを受ける |
| 訛り・騒音 | 推測した固有名詞で実行 | 確認を増やし、確信できなければ確定しない |
| 本人確認が必要な用件 | 電話番号だけで権限操作 | 追加認証または人への引継ぎ |
| API 429・5xx・Timeout | 再試行で二重作成 | 冪等キー、上限付き再試行、仮受付 |
| 転送不能 | 顧客を無音で切断 | 折返しCaseと明確な案内 |
| 再入電・重複 | 同一案件を複数作成 | Case照合、前回の文脈を引継ぎ |
| 同時着信 | 他人の情報混在・待ち行列崩壊 | 通話単位の隔離と容量上限の挙動 |
テスト結果は「成功／失敗」だけでなく、入力条件、実際の会話、作成された記録、担当者が取れた行動、再試験の要否を一件ずつ残します。
KPIは「会話率」だけで決めない
定型案内なら完了率、折返し受付なら期限内の担当完了率、予約なら正本側の確定率、有人転送なら転送後の文脈欠落率が重要になります。会話の完了率が高くても、誤ったCaseや約束できない回答を作れば本番の品質は下がります。指標を用途ごとに置き、導入前の基準値と一緒に比較します。
| 失敗の重大度 | 例 | 許容の考え方 |
|---|---|---|
| 重大 | 個人情報の誤開示、危険な誤案内、取消不能な二重操作 | 原則として本番拡大の停止条件。原因と再試験が必須 |
| 中 | 誤転送、期限漏れ、重要項目の欠落 | 発生率・検出性・回復手順を決め、限定範囲で改善 |
| 軽微 | 一回の聞き返し、表現の不自然さ | 用件別の上限を置き、UX改善の優先順位に使う |
一律の「90%」を合格基準にしないのは、失敗の重さが違うためです。重大失敗の予算は小さく、軽微な摩擦は利用目的に応じて評価します。
Go / Conditional Go / No-Goの決め方
Goは、対象用件・データ境界・人へのFallback・監視がそろい、重大失敗の再現試験も通った状態です。Conditional Goは、営業時間内だけ、予約変更を除く、有人監視付きなど制約を明示して限定本番へ進む状態です。No-Goは、正本データがない、担当者が決まっていない、障害時に顧客が取り残される、重大失敗が未解決といった状態です。No-Goは失敗ではなく、本番化の前に業務設計を直す判断です。
最後に、顧客が聞く案内、担当者が受け取る情報、運用者が見るアラートを同じシナリオで確認します。ここまで通って初めて、AIの会話ではなく受付業務全体のPoCになります。
以下は説明用Sample：予約変更を対象にしたPoC
期間を限定し、現状の電話100件を分析して上位Intentを抽出し、30ケースのテストを行う例を考えます。最初に予約変更だけを対象にし、社員Call Test、例外テスト、限定Production、Reviewへ進みます。数字は実案件の基準ではなく、対象を小さくして業務全体を検証する考え方を示すものです。
テストケースは会話と処理を一組で記録する
TC-01は正常な予約変更、TC-02は「15日ではなく17日」という訂正、TC-03は長い住所、TC-04は途中沈黙、TC-05はCRM Timeout、TC-06は人間転送失敗、TC-07は再入電です。各CaseについてInput、Expected、Actual、Severity、Retestを一行で残します。会話が自然でもCRMに誤った日付を書いたなら失敗であり、会話に聞き返しがあっても正しいCaseを作れているなら重大度は別です。
Go / Conditional Go / No-Goの判断例
会話完了率が高くても住所の誤登録が起きるならNo-Goです。聞き返しが多少あっても、最終確認とCase情報が正しく、営業時間内だけ有人監視できるならConditional Goの候補になります。Goは対象外、転送不能、API障害、再入電まで確認し、重大失敗の回復手順がある状態です。
PoCで起きやすい5つの誤り
静かな会議室の正常系だけを試す、会話できたことを成功にする、人への転送を試さない、API障害を試さない、Promptを変えた後に回帰試験をしない、という順で本番との差が広がります。PoC PASSは永久の安全ではありません。本番後もMonitoring、定期Regression、Prompt変更時の再試験、業務Rule変更時の承認を運用に組み込みます。
限定Productionで初めて見えること
社員テストを通っても、本番では発信者の早口、周囲の音、想定外の言い回し、ピーク時の同時着信が出ます。限定Productionでは対象時間・対象Intent・有人監視を明示し、逸脱した通話を安全に人へ渡します。そこで集めるのは会話ログだけでなく、Caseの正しさ、担当者が期限内に動けたか、顧客が再度説明したかです。
Promptや業務Ruleを変更したら、過去に通ったテストを再実行します。変更前後の差分、承認者、影響するIntentを残し、重大失敗が出た時は直近の安全な設定に戻せるようにします。PoCの成果物は台本ではなく、継続して回せる試験と監視の手順です。
PoCの試験を補う関連記事
失敗パターンを先に洗い出すにはAI電話受付の失敗例、会話の検証にはAI電話の会話UX、障害時の試験にはAI電話のBCPを使います。転送と負荷の受入条件は人間転送と同時着信設計を同じテスト計画に置くと漏れを減らせます。
よくある質問
PoCの合格率は90%にすべきですか？
一律の正解はありません。誤った転送や個人情報の誤処理のような重大な失敗は許容件数を極めて低くし、軽微な聞き返しは用途別に改善対象とします。
短いデモとPoCの違いは何ですか？
デモは会話の可能性を見るもの、PoCは実データ・実運用・例外・担当者の後処理まで含め、本番へ進める条件を検証するものです。