
はじめに
ボイスボットはユーザーと音声で対話するAIシステムであり、カスタマーサポート分野を中心に幅広く活用されているソリューションのひとつです。特に24時間365日稼働する電話対応サービスでは、サービスの可用性と品質が非常に重要です。
RightTouchでも、RightVoicebot by KARTE(β版) を提供しており、顧客体験の向上に貢献する音声チャネルの自動化に取り組んでいます。
しかし、音声インターフェースはWebなどの文字ベースのUIと比較して外部からの動作検証が難しく、特に電話においては以下のような音声固有の課題があります。
- 入力の不確実性: ネットワーク品質が音声品質に影響を及ぼすため、常に同様の入力をボイスボットに与えることが困難です。
- 音声認識の不確実性: 音声認識エンジンは、分析された音声スペクトグラムから特徴量を抽出しそれを確率モデルを用いて判定を行うため出力が不安定になります。この問題は、ボイスボット本体とその音声を検証するテストランナーの両方に存在します。
さらにボイスボットは、内部的には「正常に動作している」ように見えても、実際の通話においては音声が再生されない、認識がうまくいかないといった問題が発生していて検知できないケースがあります。
このように、ユーザーとの電話を通じた音声体験はブラックボックスに埋もれやすく、内部メトリクスだけではその品質を保証しきれません。
そこで私たちは実際の通話経路を通じてボイスボットの応答を確認する外形監視を構築し、ユーザー視点での品質の担保を行なっています。
本記事では、その外形監視システムの概要と、運用における工夫や課題への対応について紹介します。
システム概要
私たちが実装したボイスボット外形監視システムは定期的にプログラムから電話発信を行い、その応答を自動的に評価しています。
発信
実際の発信は、テレフォニーAPIを用いて行います。
テレフォニーAPIとは、プログラムから電話の発信・着信などの電話機能を制御できるようにするクラウド上のインターフェースのことで、代表的なものにTwilioが存在します。

※図では省略していますが、実際にはボイスボットサーバーもテレフォニーAPIを用いて電話を受けています。
入力の不確実性に対するアプローチ
通話の品質やラグなどにより、テストプログラムが送出した音声が正しくボイスボットに伝わらないケースがしばしばあります。
この「入力の不確実性」に対応するため、テストは複数回リトライする設計にしています。具体的には、初回の失敗後に数回再試行し、連続して失敗した場合のみ「テスト失敗」とみなします。
応答の評価
応答評価は以下のステップで行われます:
- 音声認識:ボイスボットからの音声を音声認識エンジンにかけて文字起こし
- 編集距離の計算:認識結果と期待する結果との編集距離を求める
- 類似度の算出:編集距離を正規化し、一定の類似度以上なら成功と判定
- リトライ評価:失敗した場合もリトライを実施し、連続失敗時に最終失敗と判断
ここで使用している編集距離の算出方法は以下のようなコードになります。
// getEditDistanceは2つの文字列間の編集距離(挿入・削除・置換の最小操作回数)を計算する関数
const editDistance = getEditDistance(recognized, expected);
// 編集距離を最大文字列長で割ることで正規化し、1に近いほど期待通りの応答だったと判断できる
const similarity = 1 - editDistance / Math.max(recognized.length, expected.length);
この手法を用いることで、たとえ数文字の誤認識があっても過剰なな失敗判定を避けられます。
テストケース
テストケースとしては、以下のような主要なシナリオをカバーしています。
- ユーザーの発話をボイスボットがオウム返しする
- ダイヤルパッド入力への応答を確認する
- 入力が無いまま一定時間経過する(タイムアウト)
外形監視失敗時のオペレーション
テスト結果は Datadog に集約され、ダッシュボード上で可視化されます。
サービスの性質、障害の影響範囲は大きく、即時の検知が必要なので各チャネルに通知を行なっています。Slackをはじめとして、即時で気づくことが難しいためPagerDutyを用いて電話、SMSでも通知される形になっています。

おわりに
RightTouchではカスタマーサポート市場の改革に挑むプロダクトエンジニアを採用中です。
もし興味があれば、ぜひお話ししましょう!