AI 音声カスタマーサポートのPoC（概念実証）の目的は、スムーズなデモを録音することではなく、以下の3つの点について、限定された範囲で検証することです。 1. 実際に電話がかかってきた場合に、指定されたタスクを完了できるか 2. 失敗した場合に、システムがそれを検知し、対応できるか 3. 全体的なコストに見合うかどうか 重要なのは、音声が自然で、回答がスムーズであることだけを証明するのではなく、システムが正確にタスクを割り当て、ステータスを照会し、重要なデータを保護できることを証明することです。
POC（Proof of Concept）を選択する際には、以下の条件を満たすタスクが適しています。; 明確なルール; 通話量を予測可能; 結果をバックエンドで確認可能; 誤った場合に修正可能 例えば、「修理に関する情報を収集し、それに基づいて工数を生成する」というタスクは、「すべての顧客からの問い合わせに対応する」よりも、検証に適しています。 POCを開始する前に、以下の情報を明確に定義する必要があります。; 通話の開始方法; 必要な項目; 実行可能な操作; 禁止する操作; 人手による対応条件; 企業APIとテスト環境の提供元 範囲を明確に定義できない場合、検証は主観的な試聴に終わってしまいます。
基準がないと、POC（プロセス最適化）が改善されているかどうかを判断できません。少なくとも、現在のタスクを誰が担当しているか、成功の定義、一般的なエラー、ピーク時の待ち時間、再入力が必要なデータ、および人がどのように修正するかを記録しておく必要があります。基準は必ずしも美しいKPIである必要はありません。確認された実際の事例をいくつか集めるだけでも、サプライヤーの自己判断よりも信頼性が高くなります。正式な比較を行う際には、同じタスク、類似の状況、および一貫した成功定義を使用する必要があります。
まず、業務、カスタマーサポート、およびシステム担当者が、入力項目、予想される質問、必要な項目、許可される動作、および最終状態を共同で作成し、その後システムにテストを依頼します。ただし、すべてのケースを完全に同じスクリプトで読み上げるのではなく、ユーザーの発言、データの欠落、同音の単語、背景音、沈黙、会話、APIのタイムアウト、および人間の指示など、さまざまな状況を考慮したテストを行う必要があります。特に、氏名、住所、金額、または身分に関する項目については、AIが単にスクリプトと一致するかどうかを確認するだけでなく、確認のプロセスをシミュレートできるかどうかをテストする必要があります。
| 状況 | 観察すべき点は何か | 確認できた結果 |
|---|---|---|
| 正常に完了 | 必要な項目、質問の順序、およびツールへのアクセス | CRMシステム、工務依頼、および割り当て状況が、通話記録と一致していること。 |
| 資料が不明瞭である、または内容を意図的に変更している | 以前の値を確認し、上書きする操作を実行しますか？ | 最終確認書類のみを保存し、重複した注文を作成しない。 |
| 音声に関する誤解 | 低い自信、詳細な質問、および人的資源の活用 | エラーが正式システムに直接書き込まれないようにする。 |
| API のタイムアウトまたは拒否 | 返信、再試、処理、および冪等性 | 成功をあらかじめ公表せず、後で最終的な状態を確認できるようにする。 |
| 人間による実施、またはリスクの高い作業 | コンテキストに応じたルーティング | 確認済みの項目と未解決の問題をシステム上で把握 |
音声認識の精度が任務の成功を保証するものではありません。逐語テキストに誤りがあったとしても、必ずしも結果に影響を与えるわけではありません。 評価においては、任務の完了、必要な項目への正確性、ツールの呼び出し成功、誤解や代替案、計画的な移行、異常な状況への対応、ユーザーによる放棄、応答の遅延、および人工修正の量など、複数の要素を総合的に評価する必要があります。 それぞれの項目について、明確な基準とデータソースを設定することが重要です。例えば、「範囲内のテスト通話」を基準とし、電話記録、モデルイベント、APIログ、および企業システムの最終状態をクロスチェックすることで、正確性を検証します。
| 指標 | 定義の方法 | 誤った判断を避ける |
|---|---|---|
| 任務完了率 | 範囲内で、最終的な状態が正確である通話の割合 | 単に会話が完了したことを、仕事の完了としてカウントすることはできません。 |
| 必要な項目における正確性の確保 | 確認欄：回答と実際の回答との一致度 | 平均値は、住所、金額などの重要な項目を隠蔽するものではありません。 |
| ツールが正常に実行されました | API の実行が成功し、重複やエラーによる副作用は発生していない。 | オンラインでの取引における遅延は、自動的に「失敗」または「成功」と判断されません。 |
| 誤解と代替 | システムが、特定の質問や問題に対する繰り返し質問や回答を理解または処理することができない場合。 | 合理な質問と、無意味な繰り返しを区別することが重要です。 |
| 人工オペレーターによる対応 | 計画による接続、異常な急増、およびユーザーからの直接的な要求 | 人工転換が必ずしも失敗するわけではありません。原因によって分類する必要があります。 |
すべてのAI電話に適用される基準線はありません。営業時間に関する問い合わせや支払い情報の修正に関するエラーのコストは、全く異なります。例えば、住所を1つ間違えるだけでも、不自然な表現よりも深刻な問題を引き起こす可能性があります。そのため、まずエラーを「自動で再試行可能」「手動での確認が必要」「自動実行不可」の3つのカテゴリーに分類し、それぞれのカテゴリーごとに基準と責任者を設定します。サンプル数が不足している場合は、「POC（Proof of Concept）では特定の課題が見つかっていない」としか言えず、正式な環境で必ず基準を満たすとは断定できません。
正式サービスにおいて、回線断絶、モデルの遅延、企業APIの異常、人工座席の満杯、およびサプライヤーのメンテナンスといった問題が発生する可能性があります。POC（Proof of Concept）担当者は、それぞれの問題が発生した場合、どのような状況になるのか、データの状態、誰に通知が送られるのか、そして復旧後に安全に再試行できるのかを確認する必要があります。また、フロントエンドと運用後台には、問題の内容を明確かつ理解しやすい形で表示し、例外処理によって問題が隠蔽されて、顧客サポート担当者が状況を誤認識しないようにする必要があります。
GoGoCha が公開している事例から、Falcon が AI による電話受付、共同配車システム、待ち行列、リアルタイム通知、およびウェブサイト、LINE、アプリとの連携、バックエンドシステム構築を行ったことが確認できます。しかし、これらの事例には、認識率、平均遅延、接続率、人件費削減、または正式な通話 SLA などの具体的な数値データが公開されていません。そのため、これらの数値は他の企業にとって基準として使用することはできません。新しい PoC (概念実証) でも、対象企業の電話環境、顧客の言語、および業務データに基づいて、改めて検証を行う必要があります。
少なくとも、以下の項目を固定されたバージョンで残しておくテストケース、結果の詳細、未解決のリスク、システム構成、データフロー、権限、監視、手動での対応と復旧手順を記録しておく必要があります。正式版では、ピーク時の同時接続数、実際のPBX/SIP、バックアップ、録音ポリシー、および運用権限についても確認する必要があります。POC（概念実証）は、継続的に構築する価値があることを示すものであり、正式版のトラフィックをそのまま受け入れることを意味するものではありません。
検証可能な事例と証拠
GoGoCha AI 電話および即時配車技術の事例現在の通話方法、通話後のシステム動作、および例外処理について議論を開始します。要件を提示した後、デモ時間、展示範囲、およびPoC（概念実証）の必要性を確認します。
