どの音声AIベンダーにも言語ページがあります。そこには30、50、時には90以上の言語が、整然と並んだ国旗のグリッドとともに並んでいます。ところがサンパウロで導入してみると、「ポルトガル語対応」のはずのエージェントは meia(口語の「6」)を言い間違え、文の途中でポルトガル語と英語を行き来する顧客につまずき、さらにLGPD担当の法務が問題視したばかりの米国リージョンを通じて通話録音をルーティングします。
言語数は虚栄の指標です。グリッド上の国旗が示すのは、モデルがそのロケールでトークンを出力できるということだけです。ノイズの多い携帯回線での単語誤り率も、合成音声が人質が台本を読んでいるように聞こえないかどうかも、エージェントがコードスイッチングに耐えられるかどうかも、音声が物理的にどこに保存されるかも、そこからは何もわかりません。
これは、多言語音声AIが本番環境で機能するかどうかを実際に左右する3つの問題についての、構築者向けのガイドです。あわせて、国旗のグリッドの代わりに購買担当者に手渡せる、深さで評価した2026年の対応状況マトリクスも示します。
「50言語対応」という嘘 — なぜ数はカバレッジと等しくないのか
「50言語に対応しています」という言い方は、それぞれ独立して破綻する3つのエンジニアリング上の問題を一緒くたにしています。
- 言語カバレッジ — STT(認識)とTTS(合成)の品質は、言語単位ではなくロケール単位です。
es-MXとes-ARは別々の問題です。 - 会話中の挙動 — ライブの全二重通話の最中における自動言語検出、コードスイッチング、アクセントへの頑健性。
- 地域ごとのコンプライアンス — データレジデンシー、同意、録音に関する法律は、国境を越えた瞬間に変わります。
ベンダーはカバレッジで満点を取りながら、挙動で失敗することがあります。ほとんどがそうです。優れた hi-IN のTTS音声を学習させておきながら、顧客が「mera payment fail ho gaya, can you check the status」と言った瞬間にモデルが崩壊します。これは6億人以上の話者にとってまったく普通の、一文のヒングリッシュです。国旗のグリッドは✅ヒンディー語と示していました。本番環境の答えはノーでした。
数ではなく深さで評価してください。以下、それぞれの観点が実際にどう破綻するかを見ていきます。
3つの観点:STTのWER、TTSの自然さ、会話中の挙動
STT — 単語誤り率(WER)。 認識器が誤る単語の割合です。クリーンな米国英語であれば、最良のエンジンはWER 5〜8%に達します。ジッターのある携帯接続越しのアクセントのある英語では、同じエンジンが15〜25%まで悪化することがあります。WERはすべての上流にかかる税金です。誤認識された単語の一つひとつが、下流でのLLMのハルシネーションの予備軍になります。WERがおよそ12%を下回ると、会話はネイティブに感じられます。20%を超えると、エージェントは耳が聞こえていないように感じられます。ベンチマークは自社の音声で行ってください。スタジオ録音のWAVではなく、アクセントがあり、圧縮された、実際の電話系コーデック(8kHz μ-law)の音声です。
TTS — 平均オピニオン評点(MOS)。 自然さを1〜5で人間が評価したものです。4.0を超えれば人間らしく聞こえ、3.5を下回ると、最初の一文で信頼を損なう2010年代初頭のカーナビ音声のように聞こえます。MOSは同じベンダー内でもロケールによって大きく変動します。学習データが乏しかったために、en-US が4.3である一方で ar-EG が3.2ということもあり得ます。
会話中の挙動。 これはどの言語ページも測定していない観点であり、通話の成否を決める観点です。3つのサブスキルがあります。
- 自動言語検出 — 「スペイン語は2を押してください」というIVRなしに、発信者の言語に切り替えること。
- コードスイッチング — 発信者が一つの発話の中で言語を混ぜても、一貫性を保つこと。
- アクセントと方言への頑健性 —
en-IN、es-419、地域ごとのアラビア語を、WERを崩壊させずに扱うこと。
優れたSTTとTTSを買っても、失敗する多言語エージェントを出荷してしまうことはあります。挙動はモデルのチェックボックスではなく、オーケストレーションの問題だからです。
コードスイッチング:スパングリッシュ、ヒングリッシュ、アラビア語‑フランス語 — 2026年に実際に機能するもの
コードスイッチングは典型的な失敗モードであり、エッジケースではありません。バイリンガル人口にとってはこれが標準です。
- スパングリッシュ(米国ラテン系市場):「Necesito cancelar mi appointment para el lunes.」
- ヒングリッシュ(インド、話者約6億人):「Bhai, mera recharge nahi hua, can you refund?」
- アラビア語‑フランス語(マグリブ — モロッコ、アルジェリア、チュニジア):「Je veux activer le forfait, bghit nchanger l'offre.」
何が破綻するか:通話の開始時に一つの言語を検出し、STTをそれに固定してしまうパイプラインは、外国語の区間を意味不明な文字列として書き起こします。2026年の解決策は、発話内での切り替えに対応した多言語音響モデル — ターン全体を通して単一の言語IDに固定しない認識 — と、どちらの言語も受け付けつつ発信者の優勢な言語で応答するようプロンプトされたLLMとの組み合わせです。
本番環境で通用する実践的なルール:
- 応答言語を一つに強制しないこと。発信者の優勢な言語に合わせ、副次的な言語は黙って受け入れます。
- 固有名詞と製品名は翻訳しないままにすること。スペイン語の文の中で「Premium Plan」を英語のまま言うのは正しい挙動であり、バグではありません。
- 切り替えの一文 — 発信者が言語を切り替える発話 — をテストしてください。ターンごとに再検出するパイプラインが話の筋を落とすのは、まさにそこだからです。インドのケースについては、Scaling AI in Customer Service: Overcoming India's Network Jitter でさらに詳しく扱っています。そこではコードスイッチングとパケットロスが重なり合います。
アクセントと方言のコスト
言語はロケールではありません。es-ES で学習した「スペイン語」をメキシコシティに展開すると、WER が上昇し、理解精度が静かに低下します。語彙、語調、リズムが異なるためです。特に問題となるのは次のとおりです。
- インド英語(
en-IN) — 音韻とリズムが独特で、汎用のenSTT では WER が 8〜12 ポイント悪化することがあります。ここは非常に大きな市場であり、失敗が許されません。 - 中南米スペイン語(
es-419) —es-MX、es-AR、es-COは相互に十分な差異があり、ある地域の音声は他の地域では外国語のように聞こえます。 - 地域別アラビア語 — モデルが学習しているのは現代標準アラビア語(MSA)ですが、サポート通話で MSA を話す人はいません。エジプト方言、レバント方言、湾岸方言は事実上それぞれ別の認識対象です。
このコストは実際の金額として現れます。アクセントに起因する WER の 1 ポイントごとに、再プロンプトが増え、「申し訳ありません、聞き取れませんでした」が増え、離脱が増え、人間へのハンドオフcoストが増えます。言語単位ではなく、ロケール単位の評価を予算に組み込んでください。
地域別コンプライアンスの重ね合わせ:音声データはどこに着地するのか
多言語展開は本質的に国境をまたぐものであり、音声が国境を越えた瞬間に法的な検討範囲が変わります。音声は生体情報に準じるものであり、録音は個人データです。エンタープライズ商談を左右する4つの規制は次のとおりです。
- GDPR(EU) — EU 域内でのデータ所在と適法な根拠を求めます。多くの購入企業は契約上、域内での処理を必須としています。
- インド DPDP 法 — 同意優先で、アウトバウンド発信については TRAI/DLT の通信規則 と組み合わせて適用されます。通信レイヤーの落とし穴については レガシーなインドのコンタクトセンターをクラウドへ移行する を参照してください。
- ブラジル LGPD — GDPR に近い構成ですが、同意とデータ主体の権利行使については独自の仕組みを持ちます。
- 中国 PIPL — データのローカライゼーションと越境移転の承認が厳格で、国内インフラなしに満たすのは4つの中で最も困難です。
アーキテクチャ上の要件は具体的です。リージョン別の処理エンドポイント + 設定可能な録音保持期間 + リージョン別の同意取得です。すべての通話を us-east-1 で処理するベンダーは、フランス語 TTS がどれほど優れていても、GDPR の適用を受ける EU のエンタープライズには正当に販売できません。データ所在は足切り要件であり、あれば望ましい程度のものではありません。品質が評価される前に商談を潰します。
2026年 多言語音声 AI 対応状況マトリクス
国旗単位ではなく、対応の深さで評価しています。評価基準: アクセントのある電話音声での STT WER、TTS MOS(1〜5)、コードスイッチング(✅ ネイティブ対応 / ⚠️ 部分対応 / ❌)、データ所在(域内オプションの有無)。区分は 2026 年時点の最良水準のエンジンの一般的な値を反映しています。導入を決める前に、自社の音声で必ずベンチマークしてください。
| ロケール | STT WER | TTS MOS | コードスイッチング | データ所在 |
|---|---|---|---|---|
| en-US | 5–8% | 4.4 | ✅ | US/EU |
| en-GB | 6–9% | 4.3 | ✅ | EU |
| en-IN | 10–15% | 4.0 | ✅(ヒングリッシュ) | インド |
| es-MX | 7–10% | 4.2 | ✅(スパングリッシュ) | US |
| es-ES | 7–10% | 4.2 | ⚠️ | EU |
| es-AR | 9–13% | 3.9 | ⚠️ | US |
| pt-BR | 8–11% | 4.1 | ⚠️ | ブラジル |
| fr-FR | 7–10% | 4.2 | ⚠️ (FR-AR) | EU |
| de-DE | 7–10% | 4.2 | ⚠️ | EU |
| it-IT | 8–11% | 4.0 | ⚠️ | EU |
| hi-IN | 11–16% | 3.9 | ✅(ヒングリッシュ) | インド |
| ar-EG | 14–20% | 3.4 | ⚠️ (FR/EN) | ⚠️ 限定的 |
| ar-SA | 13–19% | 3.5 | ⚠️ | ⚠️ 限定的 |
| zh-CN | 9–13% | 4.0 | ⚠️ | 中国(PIPL) |
| ja-JP | 9–12% | 4.1 | ⚠️ | APAC |
| ko-KR | 9–12% | 4.0 | ⚠️ | APAC |
| nl-NL | 8–11% | 4.0 | ⚠️ | EU |
| pl-PL | 9–13% | 3.9 | ❌ | EU |
| ru-RU | 9–13% | 4.0 | ❌ | ⚠️ 限定的 |
| tr-TR | 10–14% | 3.9 | ❌ | EU |
| id-ID | 11–15% | 3.8 | ⚠️ | APAC |
| vi-VN | 12–16% | 3.7 | ❌ | APAC |
| th-TH | 12–17% | 3.7 | ❌ | APAC |
| tl-PH | 12–16% | 3.8 | ✅（Taglish） | APAC |
| sw-KE | 16–22% | 3.3 | ⚠️ | ⚠️ 限定的 |
これはティア（段階）として読んでください。ティア1（WER 10未満、MOS 4.0以上、ネイティブなコードスイッチ対応）は現時点ですでに本番運用可能です — en-US/GB/IN、es-MX、pt-BR。ティア2は人へのハンドオフのしきい値を調整すればパイロット運用が可能です。ティア3（アラビア語の各方言、スワヒリ語、いくつかの東南アジア言語）には人によるセーフティネットと厳密なフォールバックが必要です。ベンダーが宣伝する言語数は、深さで評価した途端に一気に縮むことに注意してください。
展開のプレイブック：パイロット、フォールバック、地域別のハンドオフ
- パイロット対象のロケールは、旗の数ではなく「案件価値 × 対応成熟度ティア」で選ぶ。 ティア1のロケールを1つネイティブにやり切るほうが、ティア3のロケールを5つ中途半端にやるより優れています。
- ロケールごとにWERのフォールバックしきい値を設定する。 実運用中の信頼度がそれを下回ったら人にエスカレーションします。しきい値はロケールごとに調整してください。
en-USでのWER 12%とar-EGでのWER 12%は意味が違うからです。 - 人へのハンドオフを地域対応にする。 EUの発信者はEU域内のキューにルーティングしてください。録音を国境を越えて米国のエージェントに送り、せっかく回避する設計にしたコンプライアンス問題を自ら作り出さないように。
- 実際の電話音声でベンチマークする — 8kHzのコーデック、アクセント、背景ノイズ — 契約する前に。スタジオ環境のベンチマークは当てになりません。レイテンシがこの問題をさらに悪化させます。「Slashing SIP Latency Under 180ms for AI Call Center Agents」を参照してください。
- データレジデンシーは契約で確認する — 地域ごとに、書面で。営業の場での「EUにも対応できます」はDPAの条項ではありません。
FAQ
多言語対応のvoice AIと翻訳は何が違うのですか？ 翻訳は、事後的に2つの言語間で変換するものです。多言語対応のvoice AIは、それぞれの言語の中でネイティブにリアルタイムで認識し、推論し、応答します — 発信者が文の途中で言語を切り替えても対応します。翻訳はレイテンシを増やし、ニュアンスを失います。ネイティブな多言語会話はそうではありません。
Hinglish（ヒングリッシュ）やSpanglish（スパングリッシュ）のようなコードスイッチはどう処理されるのですか？ 1ターンごとに1つの言語IDに固定されない多言語音響モデルと、発信者の主要言語で応答しつつ従属的な言語も受け付けるようプロンプト設計されたLLMを組み合わせます。通話開始時に一度だけ言語を判定するパイプラインはここで失敗します — 2つ目の言語をノイズとして文字起こししてしまうのです。
多言語対応のvoice AIはGDPRやデータレジデンシーの要件を満たしますか？ ベンダーが地域内での処理エンドポイント、設定可能な録音保持期間、地域ごとの同意取得を提供している場合に限ります。データレジデンシーは、GDPR、LGPD、PIPL関連の案件では前提条件となります。営業資料ではなく、地域ごとに契約で確認してください。
2026年に実際に本番運用可能な言語はいくつありますか？ ベンダーが宣伝する数よりはるかに少数です。深さ（WER 10%未満、MOS 4.0以上、ネイティブなコードスイッチ対応）で評価すると、現時点で本当に本番運用可能なのはおよそ5〜8ロケールです。残りは、調整済みの人によるハンドオフというセーフティネットがあればパイロット運用が可能です。数ではなく深さで評価してください。
開発者向けメモ： リッチリザルトの対象となるよう、このFAQブロックからFAQPageのJSON-LDを出力してください。
2文目でも破綻しない多言語対応を提供する
Finnは旗の数ではなくロケールを起点に構築されています。ロケールごとのSTT/TTSチューニング、発話内のコードスイッチ処理、地域対応のデータレジデンシー、そして言語ごとに設定できる信頼度ベースの人へのハンドオフ。いちばん難しい通話を持ち込んでください — Hinglishでの返金対応、Spanglishでの解約、マグレブ方言での料金プラン変更。多言語パイロットを予約する し、ご自身の地域で、ご自身の音声を使ってFinnをベンチマークしてください。
