コールセンター向けLLMはどう選ぶのか ー レイテンシ・日本語・コスト・ガバナンスの評価軸

音声AIの応答が800ミリ秒を超えると、通話の放棄率が目に見えて上がる。Prodinitがまとめた実運用のレンジでは、p95で800ミリ秒を下回ることが信頼性の下限とされ、これを超えると発信者が話をさえぎったり離脱したりするとされている。一方で通話後の要約やナレッジ検索は、数秒待たされても誰も困らない。

同じセンターの中で、これだけ要求が違う。それなのにLLMの選定は「どのモデルが一番賢いか」という一本の物差しで語られがちだ。本稿の立場ははっきりしていて、コールセンター向けのLLM選定は単一の勝者を決める作業ではなく、業務ごとに別のモデルを割り当てる設計作業だと考えている。その割り当てを決める軸を、レイテンシ・日本語・コスト・ガバナンスの4つに分解する。

軸1：レイテンシ ー 会話が成立する時間の壁

まず数字を押さえる。Telnyxの2026年ベンチマークによれば、人間が自然な会話と感じる音声AIの応答は300〜500ミリ秒のレンジに収まる。実務的な合格ラインはもう少し緩く、800ミリ秒を下回れば大半の発信者は違和感を持たない。1,200ミリ秒までは業務通話として許容範囲、1,500ミリ秒を超えると明確な間が生まれ、相手は機械と話していることに気づく。

比較のために、業界全体の現在地を見ておく。同じ調査群の中で、業界の中央値は1.4〜1.7秒とされている。理想値の3倍以上だ。ただしDestiLabsが10件超のプロジェクトを実測した2026年のベンチマークでは、中央値のプロジェクトで p50 680ミリ秒・p95 1,180ミリ秒に達している。つまり「業界平均は遅い」と「作り込めば速くできる」は同時に成立している。

ここで単純比較への留保を1つ。この数値はエンドツーエンド、つまり発信者が話し終えてから応答が返るまでの全経路だ。LLMの推論はその一部でしかなく、音声認識・ネットワーク・音声合成が残りを食う。LLMを速いモデルに替えるだけで800ミリ秒が達成できるわけではない。逆に言えば、要約やナレッジ検索のように音声のリアルタイム性が絡まない業務では、この壁そのものが存在しない。

軸2と3：日本語とコスト ー なぜ「一番賢いモデル」が答えにならないのか

日本語性能は、この1年で前提が変わった。LLM比較サイトの集計によると、日本語ベンチマークでスコア0.80を超えるモデルは2025年12月時点で4つだったが、2026年3月には11に増えている。3か月で3倍近い。国産勢も伸びていて、国立情報学研究所が2026年4月に公開した「LLM-jp-4」は日本語MT-Benchで7.82を記録し、GPT-4oの7.29を上回ったと報じられている。

コスト側も同時に動いている。Anthropicの公式の料金表では、Opusクラスが100万トークンあたり入力5ドル・出力25ドル、Haiku 4.5が入力1ドル・出力5ドル。Claude Sonnet 5は導入価格として入力2ドル・出力10ドルで、当初の導入価格がその後恒久化された。同じシリーズの中ですら、上位と下位で5倍の開きがある。他社を含めた横比較では、料金アグリゲータの集計が2025年から2026年にかけて業界全体で約80%の値下がりがあったとしている（第三者集計であり、各社公式の一次情報とは別に確認が必要）。

この2つの事実を並べると、選定の構図が見えてくる。日本語の実用水準を満たすモデルが1つではなく10以上あり、しかもその中で単価が数倍から数十倍違う。性能の差より価格の差のほうが大きい領域に入ったということだ。センターの業務を思い出せば、住所変更の受付とクレームの一次分析に同じ単価のモデルを使う理由はどこにもない。

料理の火加減に近い。強火が一番いいわけではなく、煮込みには弱火が要る。問題は、多くの導入案件が「一番強い火」を全部の鍋に使っていることだ。

軸4：ガバナンス ー ここだけは性能で選べない

4つ目の軸だけは性質が違う。データがどこへ出ていくかは、モデルの賢さと無関係に決まる。

金融分野では、金融庁がAIディスカッションペーパー（第1.1版）を2026年3月に公表し、AIの健全な利活用に向けた論点整理を進めている。同ペーパーを読み解いた解説では、生成AIと個人情報の関係、特に外部サービスへのデータ提供や越境移転の扱いが実務上のハードルとして整理されている。通話音声とその文字起こしは、氏名・住所・口座情報を含みうる典型的な個人データだ。コールセンターのLLM選定が、他の業務システム以上にこの論点に近い場所にある理由がここにある。

実装の答えは1つではない。国内リージョンで完結する構成を取る、国産モデルをオンプレミスやVPC内で動かす、あるいは海外モデルでも入力前に個人情報をマスキングする。いずれにせよこの軸は他の3軸と違って、後から差し替えるコストが極端に高い。契約と監査の話になるからだ。

参考になる実装として、NTTドコモビジネスが2025年12月に発表した金融機関向けソリューションがある。三菱UFJ銀行へ提供された「発話ベースルーティング」は、着信時に生成AIが発話内容をリアルタイム解析して最適なオペレーターへ接続する仕組みだ。注目したいのは適用範囲の狭さで、AIに任せているのは振り分けの判断であり、応対そのものではない。規制業種でまず動くのは、こういう「判断の範囲が限定された用途」からになる。

業務ごとの割り当て ー 4つの型

ここまでの4軸を、センターの代表的な業務に当てはめると、いくつかの再現可能な型が見えてくる。

型1：一次受け・振り分け＝速度優先の軽量モデル 発話から応答までが会話として成立しなければならず、扱う判断は「何の用件か」の分類にとどまる。難しい推論は要らないので、下位クラスの安価で速いモデルが素直に効く。振り分け先を間違えたときのリカバリ設計（有人への即時エスカレーション）をセットで持てば、精度要求もさらに下げられる。

型2：通話要約・ACW支援＝バッチ寄りの中位モデル 通話終了後に走るので、レイテンシの壁が消える。ここで効くのは日本語の要約品質とトークン単価の掛け算だ。1日数千件を回すなら単価差が月次コストに直撃するため、中位モデルで品質が足りるかを実データで検証する価値が最も大きい領域になる。

型3：ナレッジ検索・オペレーター支援＝日本語重視＋RAG前提 モデル単体の知識ではなく、社内ナレッジをどれだけ正確に引けるかで決まる。したがってモデル選定より検索側の設計が支配的で、モデルには「引いてきた文書を日本語で正確に要約する」能力があれば足りる。上位モデルを使う必然性は思ったより薄い。

型4：規制業種の応対＝ガバナンス起点で先に絞る 金融・医療・公共では、まず出せるデータの範囲を決め、その制約を満たすモデル群の中から性能を比べる。順番が逆になると、選定をやり直すことになる。