④高額だったコールセンターシステムを個人開発で作った話｜AIコールセンターを人間のオペレーターに近づける難しさを思い知った

企業がコールセンターの運営や外部委託を検討するとき、必ずと言っていいほどぶつかる壁があります。それが「本人確認」です。

電話をかけてきた相手が本当に本人なのか。これは単なる応対品質の話ではなく、個人情報保護法(個人情報の適切な取り扱いを事業者に義務づける法律)に基づく安全管理措置の一環でもあります。日本の個人情報保護委員会も、コールセンター業務における個人データの取り扱いについて、安全管理措置や従業員・委託先の監督に関する注意喚起をわざわざ出しているほどです。本人であることを確認しないまま、電話口で支払い状況のような個人情報を答えてしまえば、それ自体が第三者への不適切な情報開示になりかねません。

その上で、この本人確認は人間のオペレーターが担当する業務の中でも最も歩留まりが悪い部分だとよく言われます。名前・電話番号・住所を1つずつ聞き取って照合する地味な工程で、聞き取りミス、聞き直しによる通話時間の増加、お客様のストレスが積み重なり、法令遵守とコスト・品質を同時に圧迫します。

前回、Agentic Voice(AIが自然な間合いで音声対話するAIエージェント機能)を導入して自由会話ができるようになったので、今回はこの「本人確認」と、その先にある「支払確認」(督促業務の核となる入金確認のやり取り)を、AIにどこまで任せられるか、という挑戦をしました。結果から言うと、仕組みとしてはかなり形になりました。ただし、そこに至るまでは地味なチューニングの連続でした。今回はその泥臭い部分を正直に書きます。

📌 AI時事ネタ：AWSは「ノーコードで作れ」と言ってきた

2026年9月2日、Amazon Connect(AWSのクラウド型コンタクトセンター基盤)は「agentic CX designer」というノーコードツールの一般提供を開始しました。東京リージョンを含む9つのリージョンが対象です。これはAWSが買収した対話AIスタートアップNLXの技術がベースになっており、コールセンターの会話フロー(お客様への質問順序や分岐)、ビジネスロジック、ガードレール(AIの逸脱を防ぐ制約)、外部システムとの連携までを、コードを書かずに画面上で設計できるというものです。厳密な手順を守らせたい部分と、自然な会話に任せたい部分を、担当者が使い分けて設計できる——というのが売りです。

正直に言うと、これを見て真っ先に思ったのは「マンチーがこの数日やってきた細かい調整は、これを使えば要らなかったのか」ということでした。結論から言うと、答えは半分イエスで半分ノーです。

会話の分岐や条件分けといった業務ロジックの組み立てそのものは、たしかにノーコードの画面で完結できたはずです。ここは今回、マンチーがLambda(サーバーレス関数実行サービス)のコードの中で1つずつ書いていた部分と重なります。ただ、これからお伝えするマンチーのカスタマイズは、そうした業務ロジックの話ではなく、AIモデルや音声認識そのものの「精度」の話です。ノーコードツールの発表内容を見る限り、こうした音声認識・読み上げレベルの微調整まで肩代わりしてくれるとは書かれていません。フロー設計の手間は減らせても、今回いちばん苦しんだ泥臭い部分はノーコード化の対象外だった、というのが正直な感想です。

個人開発は今のところ、地道な手作業の積み重ねで進んでいます。

本人確認の実装、素晴らしいがひと悶着あった話

自分で言うのも何ですが、本人確認の仕組みは今回かなりきちんと作れたと思っています。お名前→登録電話番号→ご住所の3項目を1つずつ照合し、途中で不一致があれば聞き直し、それでも確認が取れなければ担当者に引き継ぐ——という段階的な設計です。人間のオペレーターが頭の中で無意識にやっている「1つずつ確認して、ダメなら聞き直して、それでもダメなら上に回す」という手順を、そのままAIの手順として言語化した形です。

ただ、ここに至るまでは一発では決まりませんでした。最初のうち、名前の照合ロジックは、お客様の漢字の名前から読みを導き出し、それと電話口での発音を突き合わせるという作り方になっていました。ところが日本人の名前は同じ漢字でも読み方がバラバラで、漢字から機械的に導いた読みなど当てになりません。当然、一致しないエラーが量産されました。

直したのは、比較の基準を変えたことです。漢字から読みを推測させるのではなく、データベースに最初から登録してあるカタカナ欄をそのまま正解データとして使い、電話口の発音をそれと突き合わせるように指示し直しました。考えてみれば当たり前のことですが、「読みを合わせにいく」という発想そのものが遠回りだったわけです。住所の照合も同じ扱いに直し、漢字住所ではなくカタカナ欄を基準にするよう統一しました。

これで大枠は解決しましたが、そこから先は「どこまで一致していればOKとするか」という閾値の微調整が何度も続きました。人間なら「まあ、だいたい合ってるな」で流せる程度のズレも、AIには「何文字までのズレを許容するか」を数値で教えてやる必要があります。厳しくしすぎると本物のお客様まで弾いてしまい、緩くしすぎると別人でも通ってしまう——このさじ加減を、名前の文字数に応じて許容できるズレの数を変えるところまで含めて、何度も調整することになりました。

ほかにも細かい保険をいくつか仕込んでいます。電話口の発音をそのままカタカナ化したものだけでなく、平仮名・カタカナ部分だけを抜き出したもの、万一音声認識が漢字のまま出力してきた場合に備えた漢字同士の比較、さらに、音声認識が苗字を英語として誤認識するケースに備えて、認識された文字列の末尾だけを取り出してDB側の名前の末尾と突き合わせるパターンまで用意しました。1つのロジックに頼らず、何通りかの照合方法を並行して試し、どれか1つでも一致すればOKとする——これも、実際にエラーが起きるたびに1つずつ積み増した結果です。

もう一つ、地味だけれど効いているのが、確認が取れたあとの受け答えです。「名前が確認できました、次は電話番号をお願いします」というような、次に何を聞くかが決まりきっている場面では、AIに考えさせずに固定の言い回しをそのまま返すようにしています。AIに毎回答えを考えさせると数秒待たされることがありますが、決まりきった受け答えなら考える必要がないので、瞬時に返せます。お客様を無駄に待たせないための、地味だけれど効果の大きい工夫です。

本人確認の先に用意した、もう一つの目玉「支払確認」

今回のもう一つの目玉が、督促業務(入金が滞っているお客様に電話で入金を促す業務)の核となる「支払確認」の会話を、本人確認の直後からそのままAIに任せたことです。

流れはこうです。本人確認が完了すると、AIはそのお客様について現在まで入金が確認できていない月と未入金額を読み上げ、「入金はお済みでしょうか」とお尋ねします。ここで「まだです」ということであれば、その旨を記録して通話を締めくくりますが、お客様の中には「いや、払っているはずだけど」と答える方もいます。この場合AIは「いつ、どちらから入金されましたか」と聞き返し、お客様が具体的な入金日と入金元を答えたら、それを「確認します」の一言で受け止めて通話を終えます。

実はこの「未入金額の読み上げ」だけでも、一筋縄ではいきませんでした。「◯月分◯◯円」とそのまま読み上げさせると、何度指示を出し直しても不自然な区切りで読んでしまう現象が続きました。原因を探ってみると、「◯月分」と金額がひと続きの文節として扱われてしまっていることが分かり、「◯月分」と金額をそれぞれ独立した文節として分けて読み上げさせるように直したところ、ようやく自然に聞こえるようになりました。あわせて、金額はそのままの数字で渡すと不自然な読み方になってしまうため、AI側でいったん人が読み上げるときの自然な言い方(和数字表記)に変換してから音声化するようにしています。

ここで終わらせないのが、今回こだわった部分です。お客様が答えた入金日・入金元の情報は、その場でSlack(チームで使うチャットツール)へテキストとして自動通知されるようにしました。担当スタッフは通知を見るだけでなく、必要であればSlackからそのまま該当の通話録音を聞き返すこともできます。さらに、このやり取り一式は管理者用のダッシュボード(管理画面)の履歴にも自動的に残るようにしてあります。誰かが個別にメモを取らなくても、あとから「いつ・誰が・どんな入金申告をしたか」を追える状態にしました。

念のため補足すると、ここでSlackに流している入金日・入金元のテキストは、Contact Lens(Amazon Connectの通話分析機能)の文字起こしとは別物です。Contact Lensは通話が終わったあとにまとめて記録を生成する仕組みなので、会話の最中にその場で拾って通知するような使い方には向きません。実際にはAIが会話中にリアルタイムで認識した音声認識の結果をそのまま使っているだけの、地味な作りです。ただ、この地味な仕組みが思いのほかよく効いていて、聞き取った内容をほぼそのままの精度でSlackに流せています。

正直、自分で作っておいて「至れり尽くせりだな」と思う設計です。ただ、本人確認と同じで、この便利さは一朝一夕にできたわけではありません。ここから先も、細かいチューニングの積み重ねがありました。

とんでもなく細かいチューニングの日々

本人確認の精度を上げるためには、その手前にある音声認識そのもののチューニングが避けて通れませんでした。

支払い確認の本人確認フローで、マンチー自身の名前がなぜか1回目に必ず認識に失敗するという現象が起きました。調べてみると、音声認識ボットに日本語(ja-JP)だけでなく英語(en-US)の設定が残っていて、日本語の名前を英語として聞き取ろうとしていたことが判明しました。英語設定を削除しただけで解決しましたが、「英字が混ざっていたら、まずコードで吸収しようとする前に認識設定そのものを疑う」という教訓が残りました。本人確認は1回目の聞き取りに失敗するだけで、お客様の心証もオペレーターへの引き継ぎ判断も変わってしまう工程なので、この手の初歩的な設定ミスが一番怖いのです。

苗字の認識精度についても、想定される読みのカスタム辞書を100件強、会話サンプルを100件強、それぞれ個別に積み上げています。前回書いた「自由会話ができる」という基本仕様の上に、こうした地道な辞書の積み増しがないと、本人確認で名前を聞き間違えるリスクは実際の着信では消えません。

音声の音質チューニングでは、思わぬところから助けが入りました。マンチーは趣味でベースを弾いており、DTM(パソコンで音楽制作をすること)もかじっています。録音の音質を調整していたときに「なんか音がこもってる」で終わらせず、どの周波数がどう問題なのかをその場で指摘したところ、エキサイター(高域を持ち上げて音を鮮明にする処理)とハイパスフィルタ(低い周波数をカットするフィルタ)を、具体的な数値を決めて実装することになりました。AWSのLambda(サーバーレス関数実行サービス)にDAW(音楽制作ソフト)は積めませんが、信号処理のロジックだけなら書けます。コールセンターの録音品質をベーシスト目線で調整する人間が、世界に何人いるのかはわかりません。

人間とAIの会話には、どうしても「間」が生まれます。AIが聞き取った内容を分析して答えを組み立てるまでのわずかな時間が、電話越しだと不自然な沈黙として顧客に伝わってしまうのです。この間を詰めるために、AI側の読み返し・分析処理そのものを削れる場面はばっさり削り、代わりにAmazon Connect(またはLex)側がもともと持っている定型フレーズで済ませるようにしました。たとえば、取り次ぎ中に流れていた英語の案内アナウンスや、キュー名を読み上げていた箇所は、AIに何か言わせるのをやめて無音や保留音楽に置き換えています。AIに全部を喋らせようとするより、黙らせるべきところは潔く黙らせるほうが、結果として人間同士の会話に近い間になる——これも今回の発見でした。

この数日だけで、設定変更前のバックアップファイルが10個近く増えました。1つずつは地味な修正ですが、積み重ねると「あの頃より確実に自然になった」と感じられる分量になっています。

同時に喋り出したときのAIの振る舞い

本人確認は「聞く→答える→聞く→答える」のキャッチボールが何回も続く工程なので、発話がかぶる場面にも人一倍向き合うことになりました。

お客様が「あ」「いや」「えっと」のような短い言葉を挟んできたとき、AIがそれを律儀に拾って長々と反応してしまうと、かえって不自然になります。そこで、こうした短い相槌や言い淀みを検知したときは、AIに長く喋らせず「どうぞ、どうぞ、失礼しました。」とだけ短く返し、すぐにお客様の次の発言を待つように設計しました。

技術的なポイントは、この判定をAI(Claude)に毎回問い合わせるのではなく、その手前の処理で完結させていることです。発話がフィラー語(「あの」「えっと」など、それ自体に意味のない場つなぎの言葉)のような短いものかどうかはパターンで即座に判定できるので、AI呼び出しをまるごとスキップして返答を返します。AI応答を待つより体感で速く、人間同士の「かぶった、どうぞどうぞ」に近いテンポになります。会話の全部をAIに委ねるのではなく、「間」の取り方だけは決め打ちのロジックで先回りする——このバランスが自然さの正体なのだと気づかされました。

面白いのは、この「どうぞ、どうぞ」という振る舞いが、すべてのシーンで正解とは限らないことです。本人確認の会話のように、聞き取りの正確さが最優先される場面では、逆にこの相槌を使わない設計にしています。同じAIでも、シーンによって「引く」べきか「引かない」べきかが変わる——これも、人間のオペレーターが無意識にやっている使い分けを、AIには一つひとつ明示的に教えないといけない、という話です。

試行錯誤の中で見えてきた、本当のコストの正体

正直に書いておきたいのが、今回いちばんのコストは、AWSの利用料そのものではなく、地道なテストの手間だったということです。会話型の音声AIは画面上の検証だけでは足りず、結局は自分の携帯から何度も実際に電話をかけて確かめるしかありません。かけては結果をメモし、それをAIに伝えて直してもらい、また電話をかけ直す——この繰り返しが、体感でいちばん時間と気力を削られる部分でした。

「人間のオペレーターに近づける」の本当の意味

ここまで書いてきて、あらためて思うことがあります。企業がコールセンターを検討するとき最初にぶつかる「本人確認の歩留まりの悪さ」を、AIでどこまで埋められるか——それが今回のテーマでした。Agentic Voiceという基盤があれば自由会話はできます。しかし本人確認を人間のオペレーター並みに、あるいはそれ以上に安定させ、その先の支払確認までを自然な会話として成立させるための仕事は、そこから先にしかありませんでした。

英語設定が1つ紛れ込んでいるだけで名前を聞き間違える。発話がかぶったときの「どうぞ、どうぞ」の間合い。読みの照合を漢字頼みからカタカナ頼みに直し、閾値を何度も微調整する地道さ。どれも、人間のオペレーターなら意識すらせずにやっていることです。AIをそこに近づけるというのは、そうした無意識の振る舞いを一つひとつ言語化して、明示的に教え込んでいく作業なのだと、この数日で思い知らされました。こういう細かいことに気を配らないと、お客様に「なんとなく感じの悪いAIだな」という不快感を与えてしまいます。

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

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

＜おすすめ記事②＞
AIが電話口で黙り込んだ7秒間に、本気で腹が立った話はこちら。

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