⑥高額だったコールセンターシステムを個人開発で作った話｜Amazon ConnectのAI自動架電に、督促の作法を教え込む苦行

2026年11月3日 10:26

督促の電話をかけたのに、名乗らないAI。そんなものを、うっかり作ってしまいました。

コールセンター開発記の第6話です。今回は、華やかな新機能の話ではありません。AIに「督促の台本」と「判断の基準」をひたすら覚え込ませる、地味な作業の話と、その先に待っているUAT(ユーザー受け入れテスト、本番と同じ使い方で最後に確かめるテスト)の話です。結論から言うと、苦行の真っ最中です。疲れ半分、笑い半分で書きます。

なぜ、いきなり督促を選んだのか

人間のオペレーターに近づけるのは、本当に難しいです。第4話でも思い知りましたが、今回また思い知りました。

ふと思ったのは、「いきなり督促業務のオペレーターを選んだからではないか」ということです。督促は、電話に出たくない相手に出てもらい、本人かどうかを確認し、そのうえでお金の話をします。しかも、本人ではない人が出ることもあります。言い方がほんの少し違うだけで、相手は怒りますし、切られます。問い合わせの受付より、はるかに難易度の高い電話です。

それでも督促を選んだ理由は、2つあります。

1つ目は、オペレーターの定着率の悪さです。コールセンターのオペレーターは、とにかく長続きしません。なかでも督促は、相手に嫌がられ、ときには怒られる、ストレスの大きい仕事です。みんな、やりたがりません。通信キャリアにいた頃に、コールセンターの運営にも関わっていたので、この現実は、身にしみて知っています。人がやりたがらない仕事を、AIが引き受けられないか。このAI自動架電システムは、そこから作り始めました。

2つ目は、いちばんよく知っている業務だったからです。通信キャリアでは、料金や督促の仕組みの設計に関わっていました。「よく知っている業務なら、AIにも教えられるはずだ」と考えました。

結果は、冒頭のとおりです。自分がよく知っていることと、AIに教え込めることは、まったく別の話でした。

今回の目玉は、AIが自動で電話をかける「AI自動架電」

ここまで読んで、「で、結局、何を作っているの？」と思われた方のために、目玉を整理します。それが、AIが督促の電話を自動でかける、AI自動架電システムです。電話をかける相手の一覧(対象リスト)をインポートしておくだけで、あとはシステムが勝手に、次々と電話をかけていきます。人が電話の前に張りついている必要はありません。

流れは、こうです。まず、発信先のリストを取り込みます。決めた時間帯になると、システムが順番に、自動で電話をかけます。留守番電話なら、それを検知して切り、時間をおいてかけ直します。人が出たら、AIが名乗り、本人かどうかを確認し、支払いの状況をたずねます。振込用紙が手元にない方には、再送の手配をします。担当者につなぐべき相手なら、人間のオペレーターに転送します。通話が終わると、結果が12種類の状態として記録され、必要なものはSlackに通知が飛びます。

この自動発信の土台には、Amazon Connect(AWSのクラウド型コールセンター)のアウトバウンドキャンペーン機能を使っています。発信と留守番電話の検知は、AWSが用意してくれている機能にお任せして、その上に、督促の会話、結果の管理、転送、通知を、自分で作り込んでいます。

安全弁も、ひととおり入れています。かけてはいけない番号(発信拒否リスト)には発信しない。発信回数には上限を設ける。電話をかけてよい時間帯を、設定で管理する。督促という業務の性格上、「かけすぎない」「かけてはいけない相手にかけない」仕組みは、欠かせません。

「AIが電話をかける」サービス自体は、企業向けに、すでにいくつもあります。ただ、個人が、AWSの部品を使って組み上げ、督促の会話から、状態の管理、転送、通知まで、一続きにつないでいる例は、少なくとも探した範囲では、すぐには見つかりませんでした。なかなか世の中にないものを作っている、と、ひそかに自負しています。

そして、この目玉を、ちゃんと人間らしく動かすための仕込みが、これから書く苦行です。

苦行の正体は、台本と基準を「覚えさせる」こと

人間のオペレーターなら、研修を受けて、先輩の電話を横で聞いて、だんだん覚えていきます。AIには、それができません。台本と、判断の基準を、1つずつ書いて渡すしかありません。小さなロボットの机の上に、台本と分岐表が山積みになっている光景を、想像してみてください。

発信側の台本には、判断の分かれ目が8つあります。電話に出たか、本人か、支払う意思があるか、いつ払うか、一括か分割か、住所は変わっていないか、担当者につなぐか、無音が続いていないか。1つの分かれ目ごとに、AIが言うこと、お客様がこう答えたらこう動くこと、システムの状態をどう変えるか、担当者に通知するかを決めていきます。これを表にすると、60行ほどになりました。

分岐の全体像は、図にしてみました。こうして眺めると、人間のオペレーターが頭の中でやっていることを、全部外に出しているだけだと気づきます。

約束を取りつけたら、満足して帰ってしまうAI

最初に笑ったのは、これです。「3営業日以内にお支払いいただくことは可能でしょうか」と聞くと、お客様が「可能だよ」と答えます。するとAIは、「本日はご協力いただき、ありがとうございました」と言って、電話を切るのです。

まだ振込用紙の確認が残っているのに、です。AIは、「約束を取りつけた=今日の目的は達成」と考えて、満足して帰ってしまいました。
直すのに、ルールを足すだけでは足りませんでした。プロンプト(AIへの指示書)に「肯定の返事のあとは切らない」と書いたうえに、プログラム側でも、直前の質問に「可能でしょうか」が含まれていたら、「通話はまだ終わりません、次の確認に進みなさい」と、その場で耳打ちする仕組みを入れました。AIは、禁止するだけでは足りず、今どの場面かを、その都度教えてあげないといけない。そう実感しました。

督促なのに、名乗らない

もう1つは、名乗りです。AIの話す内容は、長くなりすぎないように、短く整える仕組みを入れていました。ところが、その仕組みが、名乗りの一文を「長いから」と削ってしまっていたのです。

つまり、督促の電話をかけておいて、名乗らない人になっていました。「もしもし、お支払いの件ですが」。怪しさ満点です。直したあと、念のため、「誰ですか」と聞かれたら必ず名乗る、というルールまで足しました。

日付が読めない問題

Amazon Pollyという音声合成の仕組みは、「10月21日にご入金」と読ませると、「に、じゅういちにち」と、変なところで区切ることがあります。助詞の「に」が、日付の数字にくっついてしまうのです。

対策は、日付を漢数字に変えてから読ませることでした。「十月二十一日」と書いておけば、迷わず読んでくれます。人間なら一瞬でわかることを、AIには1つずつ、教えるしかありません。

一言だけ直したら、つながりが全部消えた

いちばん肝が冷えたのは、これです。音声認識の仕組み(Lex)のバージョンを更新するとき、「日本語を有効にする」という一言だけを指定しました。すると、その指定が「差分の更新」ではなく「全体の置き換え」として扱われ、裏側のプログラムとのつながりが、ごっそり消えました。

その結果、電話は最初の挨拶のあと、強制的に切れるようになりました。原因を見つけるまで、「なぜ、挨拶だけ言って切れるのか」と首をかしげていました。今は、更新の前に現状を取得し、更新の後にも確認する手順を、「絶対ルール」として書き残してあります。

子供の頃のプラモデルと、まったく同じだった

ここまで書いて気づいたのですが、この作業は、子供の頃に好きだったプラモデル作りと、まったく同じ感覚です。

説明書(台本)はあります。でも、そのとおりに進めても、パーツがぴったり合わないことがあります。少し削って合わせる。色を塗り直す。仮組みして、違和感があれば外してやり直す。1点1点、丁寧に向き合う作業と、その場その場で合わせる臨機応変さの両方が必要です。

台本が、説明書です。AIの言葉づかいが、塗装です。電話の「間」の調整が、パーツの擦り合わせです。そして、電話をかけて確かめる作業は、仮組みです。大人になって、また似たようなことを、夢中でやっているわけです。

「穴は直しても戻る」を、自分のシステムでもやっていた

少し前に、情報漏洩やサーバーの脆弱性についての記事を書きました。その中で、「穴は直しても戻る」と書きました。

実は、自分のコールセンターでも、まったく同じことが起きていました。一度ふさいだはずの認証の穴が、いつの間にか開き直っていたのです。原因ははっきりしませんが、手元・バックアップ・本番の3か所にファイルがあり、どれが最新かわからなくなっていたことが、きっかけでした。手元のファイルは、本番より古かったのです。

記事を書いておいて、自分の家の鍵が開いていた。笑えない話ですが、書いておいてよかったとも思います。それ以来、本番の今の状態を先にバックアップして、本番から取り出したものを元に直し、直したあとに認証のテストを必ず通す、という手順を決めました。派手さはありませんが、こういう地味な作業を、コツコツ続けています。

UATは、てんこ盛りで、終わりは神のみぞ知る

台本と基準を覚えさせる作業は、そろそろ終わりそうな気配が出てきました。ところが、そのあとに、UATという大きな山が待っています。

UATのシナリオは、いつの間にか、73項目になりました。電話の着信、オペレーターへの転送、折り返し、発信キャンペーン、留守電の検知、そして今回の発信用の台本。それぞれに、手順と、期待する結果が書かれています。

とくに手ごわいのが、Lexの文字起こしの確認と、Slack通知の確認です。録音が完了したときの通知が2種類、支払いの申告があったときの通知、折り返しの依頼の通知。それぞれが、本当に正しい内容で、正しいタイミングに届くかを、1つずつ電話をかけて確かめます。

項目名も、なかなか味があります。「ガチャ切り着信が、未対話の着信として計上されるか」。自分でかけて、自分で出て、自分でガチャ切りして、自分で画面を確認する。1人で何役もこなしています。

そして、いつ終わるのかは、神のみぞ知る、です。1つ直すと、別の項目がおかしくなる。そんな追いかけっこが、まだ続いています。山頂には「UAT完了」の旗が立っているはずなのですが、霧が深くて、まだ見えません。

苦労ばかりでもない、うまくいったこと

とはいえ、苦労ばかりでもありません。うまくいったこともあります。

1つ目は、判断を言葉にして、図と表に残せたことです。AIにも自分にも、確認がしやすくなりました。社名を変数にしておいたので、依頼元が変わっても、台本を作り直さずに済みます。

2つ目は、ドキュメントがそのまま、AIの頭脳になっていることです。台本の表、プロンプトの設計、音声の一覧。これらを整えるほど、AIの受け答えが安定していきます。苦行ですが、積み上げた分は、ちゃんと返ってきます。

3つ目は、失敗するたびに、ルールが増えていくことです。「絶対ルール」の項目が、気づけば、ずいぶん増えました。失敗の数が、そのまま財産になっています。

最後に

人間のオペレーターに近づける道は、思っていた以上に長いです。それでも、プラモデルと同じで、1点1点、手を動かしていると、少しずつ、形になってきます。人がやりたがらない仕事を、AIが引き受けてくれる日のために、もう少し、手を動かします。

UATがいつ終わるかは、わかりません。ただ、終わったときには、また報告します。もし「うちのAIも、満足して帰っちゃうんですよ」といった経験がある方がいたら、ぜひ聞かせてください。

(この記事は、2026年11月時点の内容です。電話番号や設定値など、セキュリティに関わる情報は、記事に載せていません)