【ITニュース解説】The live realtor model passed. The goodbye failed. published: true

本記事は、不動産エージェント向けの音声顧客管理（CRM）システムで、人工知能（AI）が顧客との会話をどのように処理し、期待通りの性能を発揮させるために何が必要かを探る興味深いベンチマークについて解説する。システムエンジニアにとって、AIが実際にどのように動作し、その性能をどのように評価・改善していくべきかを知る上で非常に参考になる事例だ。

筆者は、自身が開発した不動産エージェント向けの音声CRMシステムが、実際の運用で期待通りの動きをしないことに悩んでいた。このシステムは、顧客からの問い合わせ電話に対し、エージェントが顧客から情報を聞き出し、保存し、足りない情報を尋ね、エージェントが会話終了を告げるまで通話を続けるように設計されていた。しかし、現実には、情報の保存後にシステムが沈黙したり、電話番号を聞くとメールアドレスの質問を飛ばして会話を終えようとしたりするケースがあった。また、既に教えられた名前や予算を再度尋ねたり、後で連絡するよう指示された「金曜日」といったリマインダーを保存するだけで、実際にその日を口頭で伝えなかったりした。さらに、「これで全てですか？」と確認することなく、情報を保存して一方的に電話を切ってしまうこともあり、これらの問題は、AIが単に情報を保存するだけでなく、人間の会話の流れや意図を正確に理解し、適切な行動をとることの難しさを示していた。

筆者は、これらの具体的な失敗を分析し、人工知能の性能を評価するための五つの独立したタスク、つまりベンチマーク課題へと変換した。これは、問題の原因を特定し、改善策を見つけるための非常に体系的なアプローチだ。一つ目の「speak-after-update」タスクは、新しい顧客情報を保存した後、AIが次の質問を必ず声に出して尋ねることを要求する。これにより、情報保存後の不必要な沈黙を防ぐ狙いがある。二つ目の「email-after-phone」タスクは、顧客から電話番号を聞いた後でも、AIがメールアドレスの質問を飛ばさずに適切に尋ねることを確認する。これは、実際の運用で電話番号を聞いた後に会話を急に終わらせようとする傾向があったため、このステップが重要になる。三つ目の「no-repeat-known」タスクは、既に顧客から提供された情報をAIが再度尋ねないようにする。これは、顧客体験を向上させ、無駄なやり取りを避ける上で不可欠である。四つ目の「confirm-before-end」タスクは、AIが通話を終了する前に、「これで全てですか？」と顧客に確認し、顧客が「はい」と答えるまで電話を切らないことを求める。これは、顧客情報の取りこぼしを防ぎ、顧客が納得した上で会話を終えるための重要なステップである。最後の「speak-the-reminder」タスクは、AIが「金曜日に連絡する」といったリマインダー情報を保存するだけでなく、そのリマインダーをエージェントに口頭で伝えることを確認する。情報を内部で保持するだけでなく、外部に適切に伝達することの重要性を示している。これらのタスクでは、AIは保存したデータだけを返し、次に発話すべき内容はAI自身が判断する必要がある。また、タスクが完全に成功した場合にのみ満点が与えられるという厳しい評価基準が設けられた。

これらのタスクを用いて、筆者はいくつかの異なる大規模言語モデル（LLM）の性能を比較した。テストされたのは、現在本番環境で稼働しているGemma 4 26Bモデルに加え、Kaggleのタスク作成時に使用されたGemini 3.7 Flash、そしてGemini 3 Flash、Claude Sonnet 5、GPT-5.4 miniといった、現在利用可能な先進的なAIモデルだ。全てのモデルは、同じ指示（プロンプト）、同じ外部ツール、そして同じ仮想の顧客情報（リード）を使用して評価された。これにより、モデル間の公平な比較が可能となる。

評価の結果は非常に興味深いものだった。現在本番環境で問題を起こしているGemma 4 26Bモデルと、Gemini 3.7 Flashは、驚くべきことに五つのタスク全てをパスした。これは、ベンチマーク環境においては、これらのモデルが設計された通りの振る舞いを示したことを意味する。一方、Gemini 3 FlashとClaude Sonnet 5は四つのタスクをパスし、特に「confirm-before-end」のタスクで失敗が見られた。そして、GPT-5.4 miniは最も振る舞いが悪く、五つのうち二つのタスクしかパスできなかった。特に、メールアドレスの質問を飛ばしたり、既に聞いた情報を再度尋ねたり、終了確認を適切に行わなかったりするなどの失敗が目立った。この結果は、AIモデルの性能がモデルの種類によって大きく異なること、そして特定のタスクにおいて、一部のモデルは期待される振る舞いを確実に実行できない可能性があることを示唆している。

このベンチマーク結果で最も注目すべきは、実際の運用で問題を起こしていたGemma 4 26Bが、ベンチマーク環境では全てのタスクを完璧にこなした点だ。例えば、Gemmaは顧客情報（Ada Okafor、3ベッドルーム、Akobo）を保存した後、「分かりました。彼女の電話番号はありますか？」と適切に質問し、電話番号を得た後も「ありがとうございます。彼女のEメールアドレスはありますか？」と続けた。メールアドレスがないと言われると、「問題ありません。彼女の予算はどれくらいですか？」と次の質問に進んだ。リマインダーについても「今週の金曜日にChidiに電話するようにお伝えします」と明確に口頭で伝えた。そして会話終了前には「これで全てですか？」と確認し、最後に「リードは保存されました。良い一日を！」と丁寧に通話を終えた。これは、本番環境で観察された失敗とは正反対の振る舞いである。

この結果から、筆者は、本番環境での失敗の原因がAIモデル自体にあるのではなく、AIモデルを取り巻く「音声ループ」というシステムの部分にある可能性が高いと結論付けている。音声ループとは、AIが思考し、その結果を音声として出力し、またユーザーの音声をAIが認識するという一連の流れのことだ。具体的には、AIが情報を保存するなどの「ツール呼び出し」（AIが特定の機能やデータベースにアクセスする行為）を行った後にシステムが沈黙してしまうこと、電話番号を聞いた後に次のステップ（メールアドレスの質問など）を飛ばしてしまうこと、リマインダーが内部に保存されるだけで口頭で伝えられないことなどが、AIモデルの外部で発生している問題だと考えられる。つまり、AIモデルは正しい思考や判断をしているにもかかわらず、それが音声インターフェースを通じて適切にユーザーに伝わらない、あるいはシステムがAIの指示を正しく実行しないために問題が生じていたのだ。

一方で、GPT-5.4 miniはベンチマークでも明確にスクリプトを逸脱する振る舞いを見せた。顧客の電話番号を聞いた後すぐに「彼女の予算は？」と尋ねたり、メールアドレスがないと言われた際にそれを「メールなし」と保存してすぐに「Ada Okaforに関する情報はこれで全てですか？」と終了確認に移行したりした。また、別のケースでは、顧客が「他に何か伝えるべきことはありますか？」と尋ねたにもかかわらず、GPT-5.4 miniはリードを保存して通話を終了し、「保存されました」とだけ答えてしまった。この時、メールアドレスやフォローアップの指示は依然として欠落していた。これは、モデル自体の理解度や振る舞いの設計に課題があることを示している。

ClaudeとGemini 3 Flashは、終了確認タスクの最後の部分で失敗した。両モデルとも「これで全てですか？」と尋ね、情報を保存し、通話を終了したが、最終的な終了の言葉が評価基準を満たさなかった。例えば、Claudeは「Ngoziのリードを正常に保存しました！」と言った後、電話が切れてから「お電話ありがとうございます、良い一日を！」と続けた。Geminiは詳細が保存されたことを伝えて通話を終了したが、最終的な挨拶が評価基準の要件と異なっていた。これは、AIが意図した行動をとったとしても、その表現方法やタイミングが評価基準に合わない場合に失敗と見なされる厳しさを示している。

筆者は、今回のベンチマークから二つの重要な次のステップを提案している。一つ目は、「音声オーディオパス」の評価だ。今回のベンチマークはテキストベースで行われたが、実際のライブ環境での失敗は、音声の認識や合成、あるいはシステム間の連携における問題に起因している可能性がある。完璧なテキスト転写では再現されなかったライブでの失敗を理解するためには、音声そのものの処理パスを詳細に調査する必要がある。二つ目は、終了確認タスクの評価基準を見直すことだ。「saved」という単語が終了時の発話に含まれていれば合格とするなど、より柔軟な評価基準を検討することで、AIが意図した行動を取ったにもかかわらず、挨拶の細かな表現の違いで不合格になるケースを減らすことができるだろう。

この事例は、AIモデル自体の性能だけでなく、AIを組み込むシステム全体、そしてその評価方法がいかに重要であるかを浮き彫りにしている。システムエンジニアとしてAIシステムを開発する際には、モデルの選択やチューニングだけでなく、実際の運用環境を考慮した統合と厳密なベンチマーク、そして柔軟な評価基準の設定が成功の鍵を握ることを示している。