コールセンター向けLLMはどう選ぶのか ー レイテンシ・日本語・コスト・ガバナンスの評価軸
音声AIの応答が800ミリ秒を超えると、通話の放棄率が目に見えて上がる。Prodinitがまとめた実運用のレンジでは、800ミリ秒を超える遅延はコンタクトセンターで放棄率を40%押し上げるとされている。一方で通話後の要約やナレッジ検索は、数秒待たされても誰も困らない。
同じセンターの中で、これだけ要求が違う。それなのに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ドルが2026年8月31日まで適用され、その後は入力3ドル・出力15ドルへ移行する。同じシリーズの中ですら、上位と下位で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：規制業種の応対＝ガバナンス起点で先に絞る 金融・医療・公共では、まず出せるデータの範囲を決め、その制約を満たすモデル群の中から性能を比べる。順番が逆になると、選定をやり直すことになる。
ここからは私の見立てとして
4軸で分けろ、と書いてきたが、これには当然コストがある。モデルを4種類使い分けるということは、監視も、プロンプト管理も、障害時の切り分けも4系統になるということだ。運用チームが2〜3人のセンターで、この複雑さを背負うのが正解とは限らない。単一モデルで全部を賄い、運用をシンプルに保つほうが総コストで勝つケースは普通にある。私の見立ては「分けたほうがいい」だが、それは分けた分を運用できる体制がある場合に限られる、という留保付きだ。
そのうえで、次の3条件が揃うなら使い分けに踏み込む価値があると考えている。第一に、月間の処理件数が数千件を超えていて単価差が金額として見える規模であること。第二に、リアルタイム業務とバッチ業務の両方を抱えていること。第三に、モデルの差し替えを前提としたアーキテクチャ（プロンプトとモデル指定を業務単位で外出しする構成）を最初から取れること。3つ目が一番見落とされやすい。
逆に言えば、この3つが揃わないうちは、ガバナンス要件だけ先に固めて、あとは1つのモデルで走り始めたほうが早い。
まとめ
第一に、コールセンターのLLM選定は単一の勝者を選ぶ作業ではなく、レイテンシ・日本語・コスト・ガバナンスの4軸で業務ごとに割り当てる設計作業になった。第二に、この1年で日本語性能の実用ラインを超えたモデルが一気に増え、性能差より価格差のほうが大きい局面に入っている。第三に、4軸のうちガバナンスだけは後から差し替えるコストが極端に高く、最初に決めるべき制約として扱う必要がある。
そのうえで、残る問いはこうだ。自社のセンターの業務を書き出したとき、本当に「一番賢いモデル」でなければ成立しない業務は、いくつあるだろうか。
よくある質問
リアルタイム応対と通話後処理で、LLM選定の考え方は具体的にどう変えるべきでしょうか？
リアルタイム応対では、人間が会話として自然に感じる300〜800ミリ秒程度の応答時間が重要で、モデル単体の賢さよりレイテンシが優先されます。一方、通話要約やナレッジ検索のような通話後処理は数秒の待ち時間が許容されるため、速度の制約は小さく、要約品質やトークン単価など別の軸でモデルを選ぶ余地が大きくなります。
日本語性能が上がった今、どの程度の業務から上位モデルを使う意味があるのでしょうか？
日本語の実用水準を超えたモデルが多数存在し、性能差より価格差の方が大きい局面に入っています。そのため、住所変更受付のような定型的な業務や要約・ナレッジ検索では中位以下のモデルでも足りる場面が多く、クレームの一次分析など推論の難度が高い業務から上位モデルを検討する、という切り分けが現実的とされています。
モデルを業務ごとに使い分ける場合、運用面でどのような負荷増を想定しておくべきですか？
モデルを4種類使い分けると、監視・プロンプト管理・障害時の切り分けがそれぞれ別系統になり、運用の複雑さが増します。運用チームが少人数のセンターでは、この複雑さが総コストを押し上げる可能性があり、単一モデルで統一した方が結果的に有利なケースもあるとされています。体制とトレードオフを見たうえで判断する必要があります。
ガバナンス要件を踏まえたうえで、どのような順番でLLM候補を絞り込むのが現実的でしょうか？
通話音声には個人情報が含まれるため、まずデータの取り扱い方針を決め、国内リージョン完結・オンプレミスやVPC内での国産モデル運用・個人情報マスキングといった構成方針から候補を絞る必要があります。そのうえで、制約を満たすモデル群の中からレイテンシや日本語性能、コストを比較する順序が望ましく、順番を逆にすると選定のやり直しコストが大きくなるとされています。
自社センターで複数モデルの使い分けに踏み込むかどうかは、どんな条件で判断すべきでしょうか？
踏み込む価値がある条件として、月間処理件数が数千件を超え単価差が金額として効いてくること、リアルタイム業務とバッチ業務の両方を抱えていること、プロンプトとモデル指定を業務単位で外出しできるアーキテクチャを最初から取れることの3点が挙げられています。これらが揃わない場合は、まずガバナンス要件を固めたうえで単一モデルで走り始める方が現実的とされています。
注記: 本稿は2026年8月6日時点で確認できた公開情報にもとづく。API料金・モデルのラインナップは変更が頻繁なため、導入検討時は各社公式の最新情報を確認いただきたい。他社モデルの料金に関する記述には第三者アグリゲータの集計が含まれ、一次情報での裏取りは別途必要になる。ベンチマークスコアは評価手法により結果が変わるため、自社データでの検証を推奨する。後半の見立ては筆者（相原ことは）の個人的見解であり、特定製品の推奨を意図するものではない。
出典
Telnyx「Voice AI Agents Compared on Latency (2026 Benchmarks)」
DestiLabs「2026 AI Voice Agent Benchmark: Latency & Cost per Minute」
AI API Pricing「Compare GPT, Claude, Gemini Token Costs (2026)」
金融庁「AIディスカッションペーパー（第1.1版）ー 金融分野におけるAIの健全な利活用の促進に向けた初期的な論点整理」
この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。
