⑤高額だったコールセンターシステムを個人開発で作った話｜AIコールセンターが黙り込んだ7秒間に、本気で腹が立った

前回までは、督促業務(入金が滞っているお客様に電話で入金を促す業務)の中でも「本人確認」と「支払確認」という、1対1のやり取りに絞って作り込んできました。今回はこの範囲を広げ、決まった業務の外にある「自由な会話」そのものをAIに任せるチャンネルと、電話を「受ける」だけでなく「かける」側までAIに任せる仕組みに手を付けました。

結果から先に言うと、どちらもなんとか動くところまでは持っていけました。ただし「うまくいきました」と胸を張れるほど綺麗な話ではなく、そこに至るまでは相変わらず地味な試行錯誤の連続で、中には「電話越しにAI相手に本気で腹を立てる」という、我ながらどうかと思う出来事もありました。今回はその泥臭い部分を、疲れも込みでそのまま書きます。

「このコールセンター、どういう仕組みなんですか」に答えるAI

今回作ったチャンネルの1つが、このコールセンターシステム自体の機能や操作方法を、音声の自由会話で説明してくれる案内AIです。管理者やオペレーター、導入を検討している担当者から「これってどういう仕組みなんですか」「この機能は何ができるんですか」と聞かれたときに、電話口でそのまま答えてくれます。

これが個人的にはかなり気に入っています。何が良いかというと、操作マニュアルを別途書かなくていいことです。仕組みとしては、ダッシュボード(管理画面)やオペレーター画面のソースコードそのものをAIに読み込ませ、そこにある機能を1つずつ洗い出して構造化した上で、説明文としてまとめ直す、という2段階の作り方をしています。できあがった説明文はテキストファイルとしてクラウドストレージに置いておき、案内AIが答えるたびにその場で読み込んで会話に反映する仕組みです。つまり、機能を追加したり画面を変えたりしたときは、この説明文を作り直すだけで、案内AIの回答は常に今のシステムの状態に追随します。操作マニュアルの「あの機能、まだ古い説明のままだった」問題が起きない設計です。

もともとマンチーは、操作マニュアルは時間をかけてでも「見れば絶対わかる」ところまで作り込むべきだ、というのが持論です。その自分の基準に照らしても、AIが自動で書き起こしたこの説明文はかなり高いレベルで仕上がったと感じていて、正直満足しています。

実際に使ってみて地味に「効くな」と思ったのが、単なる機能紹介だけでなく、オペレーターから「この機能の画面って、どこのボタンをONにすればいいんですか」というような、かなり具体的な操作レベルの質問にもちゃんと答えられたことです。最初は「そこまで答えられるとは思っていなかった」というのが正直な感想でした。ただ、よくよく考えれば当たり前の話で、画面そのもののhtmlやcssをこのAIに読み込ませていますし、プロンプト側にも「画面の説明が含まれている」と伝えてあります。つまりAIからすれば、ボタンの配置や見た目まで含めて把握した上で答えているわけで、狙って作ったというより、あとから「あ、これもできるのか」と気づいた副産物でした。

もちろん、何でも喋っていいわけではありません。「誰が作ったんですか」「いくらかかったんですか」「どこの会社ですか」といった、開発者・費用・契約条件に関わる質問には、はぐらかす受け答えをあらかじめ用意しています。加えて、専門用語をそのまま使わないようにも指示していて、たとえば「DynamoDB(AWSのデータベースサービス)」は「顧客情報データベース」と言い換えて説明するようにしています。相手は必ずしもエンジニアではないので、これは地味に大事な配慮です。

答えが尻切れトンボになるバグ

ただ、ここまで持ってくるのに、素直に動いてくれない期間がありました。案内AIの回答が、途中で急に切れてしまうのです。

もともとAIの音声回答には、長く喋りすぎて間延びしないよう、一定の文字数を超えたところで区切って返す仕組みを入れていました。最初はこの上限に引っかかって、説明の途中でぶつ切りになっているのだろうと当たりをつけ、この案内チャンネルだけ上限を緩めました。ところが直してもまだ同じように切れる。おかしいと思って調べてみると、原因はもう一段手前にありました。AIが答えるとき、本題に入る前に「そのご質問についてですが、」のような前置きの一文を挟む癖があり、上限の文字数に達した時点で、まだその前置きの途中だった、というオチです。文字数を緩めても、前置きが長くなればまた同じことが起きるだけでした。

最終的な直し方は、この案内チャンネルに限っては文字数で区切る仕組み自体を使わないことにし、代わりに「前置きなしで、いきなり結論から答えること」という指示をAIに追加しました。地味な話ですが、文字数を調整するという対症療法ではなく、そもそも前置きを喋らせないという根本のほうを直したことで、ようやく答えが最後まで届くようになりました。とはいえ、ここに至るまで同じ質問を何度も投げては録音を聞き返す作業を繰り返していて、正直もう何回目だったか覚えていません。

もう一つ、地味に効いているのが「できません、とはっきり言わせる」というルールです。対応していない機能を聞かれたときに、AIがそれっぽく取り繕って答えてしまうと、あとで「説明と実際が違う」という食い違いを生みます。分からない・対応していないことは、ぼかさずに「できません」とはっきり答えさせる。愛想の良さより正直さを優先する、という判断をここでもしました。

自由に喋らせたら、電話が「かける」側にも化けた話

もう1つ手を入れたのが、特定の業務に縛られない汎用の自由会話チャンネルです。名前・要件・折り返し先の電話番号といった情報を、決まった台本ではなく自然な会話の中から聞き取って記録する、という設計にしています。

このチャンネルを作っていて実感したのは、自由に会話させることの本当の価値は、聞き取りの自然さそのものより、会話の中身をAIが理解した上で「状態」に変換できることでした。人間のオペレーターなら、通話の中身を聞きながら頭の中で「これは折り返し案件だな」「これは不在で終わったな」と自然に整理しています。AIにこの整理を代わりにやらせるには、会話から読み取った内容を、システムが扱える決まった状態(以下、フラグと呼びます)に変換させる必要があります。

このフラグ化の仕組みは、督促業務向けに電話を「かける」側の機能を作ったときに本領を発揮しました。督促のお客様に対してAIが自動で電話をかけ、名前を確認したうえで未払い金額と依頼元を伝え、支払いの意思を確認する、という一連の会話をAIに任せる機能です。相手の返答は「払った」「今度払う予定」「振込用紙がない」「本人じゃない」「払えないので相談したい」など、実際にはかなりバラつきます。これを1つずつ、システムが扱える状態として書き出したのが以下のフラグです。せっかくなので全部書きます。

• 未発信：まだ一度も電話をかけていない状態。一括発信の対象になります。

• リトライ待ち：電話をかけたがつながらず、再発信までの間隔待ちをしている状態。

• 不在・未応答：発信したものの相手が出ず、つながらなかった状態。リトライの対象になります。

• 発信済：通話が成立した状態。この先の細かい結果は、会話の中身によって以下のフラグに枝分かれします。

• 支払済み申告：お客様が「もう払った」と申告した状態。担当者側で入金の事実確認が必要です。

• 支払い予定あり：「いつ払う」という具体的な予定日をお客様が約束した状態。期日をめどに入金確認をします。

• 振込用紙送付依頼：お客様の手元に振込用紙がなく、登録住所宛てに再送してほしいという依頼があった状態。

• 担当者転送：AIが自分の対応範囲を超えると判断し、有人オペレーターへの引き継ぎを選んだ状態。

• 本人以外申告(要確認)：電話に出たのが本人ではない、または番号自体が違うと申告された状態。人の目での確認が必要です。

• 拒否・切電：お客様から強い拒絶があり通話が終了した状態。以後の発信対象から外すかどうかの検討対象になります。

• 上限達成：あらかじめ決めた最大発信回数に到達した状態。これ以上は自動発信しません。

• DNC除外：Do Not Call(発信拒否)リストに登録済みで、以後は永久に発信対象から除外される状態。

こうして書き出してみると、単純な「発信した/しなかった」の2択ではなく、人間のオペレーターが電話の後に頭の中でやっている振り分けを、そのまま言葉にしただけだと分かります。逆に言えば、この振り分けを最初から言語化できていなければ、AIに自由に喋らせることはできても、そのあとの業務(誰にいつ振込用紙を送るか、誰を担当者に回すか)にはまったくつながりませんでした。自由会話とフラグ管理は、セットで初めて意味を持つのだと今回よく分かりました。

なお、振込用紙がない場合の対応は特に気を配った部分です。口座番号を電話口でAIにそのまま読み上げさせることはせず、振込用紙を登録住所宛てに再送する、という形に寄せています。督促のような業務では、電話口で口座情報を伝えるやり取り自体がトラブルの元になりかねないため、あえて遠回りに見える手段を選びました。

着信して7秒、AIが黙り込んで本気でキレた話

自動発信の機能を作るうえで、もう1つ外せない仕組みがAMD(留守番電話検知機能)です。これをオンにしておくと、電話がつながった相手が人間なのか留守番電話・FAXなのかをシステム側が自動で判定してくれます。督促の電話をAIが延々と留守番電話に喋りかけ続ける、という間抜けな事態を防ぐために、これは必須の設定でした。

ところが、これを組み込んで自分のスマホでテスト発信を繰り返していたところ、どうしても納得できない現象にぶつかりました。電話に出てから、AIが喋り出すまで、明らかに不自然な沈黙があるのです。体感で7秒近く、何も聞こえてこない。実際の相手からすれば、電話を取った瞬間に無言が続くわけで、「これは怪しい電話だ」とその場で切られてもおかしくありません。督促の電話でこれをやってしまったら本末転倒です。何度もかけ直しては同じ沈黙にぶつかり、さすがに腹が立ちました。

原因を切り分けてみると、2つの待ち時間が重なっていることが分かりました。1つは、AMDの判定そのものにかかる時間です。相手が出た直後の音声パターンを聞いて人間か留守番電話かを判断する仕組み上、判定にはどうしても数秒かかります。もう1つが、判定が終わったあと、会話エンジン(Lexボット、AIとの音声対話を実現する仕組み)へ通話をつなぎ直す処理の立ち上がりです。この2つの待ち時間がそのまま足し算されて、相手の耳には「つながったのに何も聞こえない数秒間」として届いていました。

直し方は、この2つの待ち時間そのものを削ることではなく、待っている間に何も聞かせないという状態そのものをなくすことでした。具体的には、AMDの判定が終わって人間だと分かった直後に、Amazon Connect(このシステムの土台になっているAWSのサービス)自身が持っている定型の音声合成で、決まった第一声だけを即座に流すようにしました。この第一声はAIが考えて喋っているわけではなく、あらかじめ用意した固定フレーズを流しているだけなので、判定が終わった瞬間にほぼ遅延なく再生できます。そのあとで、裏側では会話エンジンへの接続を静かに済ませ、相手が第一声を聞き終える頃には、その先の受け答えを本物のAIが引き継ぐ、という流れに組み替えました。

この構成に落ち着くまでに、通話フローの組み方を何度か作り直しています。判定の分岐をどこに置くか、固定の第一声をどのタイミングで挟むか、少しずつ配置を変えては実際に電話をかけて確認する、というのを繰り返しました。1つの通話フローファイルを直接書き換えるのではなく、バージョンを変えながら試したのは、電話をかけるたびに「今度はどうか」を確認する必要があったからです。

正直に書くと、これでゼロになったわけではありません。改修を重ねた今の時点でも、電話がつながってから声が聞こえるまで、体感でだいたい5秒はかかっています。7秒よりはだいぶマシになりましたが、まだ「一瞬の間」と呼べる長さではありません。AMDの判定そのものにかかる時間は仕組み上どうしても数秒必要になるため、ここから先をさらに詰められるかは正直微妙なところですが、引き続き努力目標として改善を検討していくつもりです。

人間らしさは、待たせないところに宿る

今回、着信対応の自由会話AIも、発信対応の自由会話AIも、なんとか動くところまでは持っていけました。「完成した」と言い切れるほどの手応えはまだなく、正直なところ疲労のほうが勝っています。ただ、実際に手を動かしてみて一番強く感じたのは、AIが「何を話すか」を作り込むのと同じくらい、あるいはそれ以上に、「何も話していない時間をどう扱うか」が人間らしさを左右する、ということです。

案内AIの答えが前置きの途中で切れるのも、着信直後に7秒間黙り込むのも、どちらも会話の中身自体は間違っていません。ただの間の悪さです。しかし電話の相手にとっては、その間の悪さこそが「なんだかおかしい電話だ」という違和感の正体になります。人間のオペレーターは、こうした間合いを意識すらせずにこなしていますが、AIに同じことをやらせるには、その間合いの1つひとつを見つけて、名前をつけて、直していくしかありませんでした。今回もまた、地味な調整の積み重ねでした。

【この記事が興味深かった方は、以下記事もおすすめです】

＜おすすめ記事①＞
本人確認と支払確認を、AIにどこまで任せられるかに挑んだ話はこちら。

＜おすすめ記事②＞
督促の作法をAIに教え込む、最新のUAT中の話はこちら。

＜おすすめ記事③＞
AmazonのAgentic Voiceで自由会話ができるようになるまでの6か月はこちら。