このAIは文の途中で言語を切り替えます。

英語でスマートスピーカーに質問をすると、その文の途中でスペイン語に切り替えると、多くのシステムがフリーズしたり、誤って書き写したり、または別の言語で奇妙な応答を返したりします。今日の主流の音声ボットは、単一言語ロックステップで効果的に動作しています：1つの言語が1セッションごとに使われ、設定メニューで選択されるか、開発者によってハードコーディングされています。

人間は逆のことをします。バイリンガルの話者は常に「コードスイッチ」を行います—「明日のla citaを予約してくれますか？」—どのモデルがどの地域をサポートしているか考えることなく。ロンドン、ニューヨーク、またはメキシコシティのような都市では、単一の会話が10秒以内で英語、ポーランド語、フランス語の間を行き来することがあり、誰もまずその言語を宣言するためにフォームに記入することはありません。

音声AIは主にヒューゴ・ポッドが呼ぶTier 1に存在しています：複数の言語に対応できますが、どの言語を期待するかを事前に伝えなければなりません。これは厳格なコールフローやIVRには対応できますが、発信者が英語で「スペイン語を話せますか？」と尋ね、その後実際にスペイン語に切り替えると問題が発生します。エージェントは英語で返答を続けるか、さらに悪いことに、文字起こしが混乱してLLMが機能しなくなります。

Tier 2はアップグレードです。自動的に言語を検出し、文の途中で切り替えるマルチリンガルエージェントで、手動での切り替えや「スペイン語は2を押す」などの操作、再起動も必要ありません。ユーザーは英語で始め、ポーランド語に切り替え、さらにフランス語のフレーズを加えることができ、システムはすべてをリアルタイムで追跡します。このような流動性は、ボイスボットを設定パネルから会話へと変えます。

Tier 2エージェントの構築には、緊密に連携する3つの要素が必要です： - リアルタイムオーディオとエージェントロジックを調整するためのスマートフレームワーク（LiveKitなど） - 多くの言語で自然に応答できる強力な脳（LLM） - 低遅延で高精度なコードスイッチングを実施する、超敏感な耳（STT）

ほとんどのLLM（大規模言語モデル）や音声合成エンジンは、すでに複数の言語を合理的に扱うことができます。本当のボトルネックは、音声認識で、「スペイン語を話せますか？」という問いを聞き取り、文の残りがスペイン語で到着した時にシームレスに続けられることです。再設定やハードリセットなしで、継続的な多言語理解が求められています。

Tier 1の多言語エージェントは、紙面上では柔軟に見えます：1つのシステムで多くの言語。実際には、誰かが言葉を発する前にあらかじめ言語を宣言しない限り、うまく機能しません。「スペイン語」、「ポーランド語」、または「フランス語」をセッションパラメータとして設定すると、その選択に固定されたまま会話が進みます。

そのデザインは、IVRフォンツリーからカスタマーサポートボットまで、至る所に現れます。ドロップダウンから選択したり、「2でスペイン語」を押したり、旗のアイコンをタップすると、その時点で初めて音声認識パイプラインが適切な音響モデルと言語モデルを読み込みます。通話中に気が変わったり、別の言語を混ぜたりすると、システムはあなたの言うことを聞き取れなくなったり、その変更を無視したりします。

ロジスティクスの観点から、Tier 1は不格好に感じます。フォームには追加の「希望言語」フィールドが必要で、コールフローにはメニューが必要で、キオスクには開始するためのUIの配慮が必要です。追加される手順が増えるほど、摩擦と放棄が増加します。多くの消費者向けアプリは、オンボーディングに10〜20秒以上かかるとユーザーが離れてしまいます。

ティア2のマルチリンガルエージェントは異なる働き方をします。彼らはまず聞き取り、事前の宣言なしに、あなたが使用している言語、または言語をその場で判断します。会話は英語から始まり、質問のためにスペイン語に移り、その後ポーランド語に切り替わることができ、エージェントはその移行をリアルタイムで追跡します。

そのシフトは、多言語機能をチェックボックスから実際の会話の流暢さへと変えます。Tier 2システムは自然な「コードスイッチング」をサポートし、ユーザーが「請求書を私の仕事のメールに送ってくれますか？」や「あなたはスペイン語も話しますか？」のように、1つの文の中で言語を混ぜ合わせることができます。エージェントは、すべてのスイッチで適切に文字起こしを行い、判断し、応答する必要があります。

グローバル製品において、ティア2は金の標準です。1人のエージェントが、別々の電話番号やボット、複雑な言語ルーティングルールなしで、数十の市場にわたってユーザーにサービスを提供できます。企業は英語、フランス語、ポーランド語のために並行フローを維持することを避け、代わりにユーザーが話す言語に適応する単一のロジックレイヤーを展開します。

Hugo Podの「LiveKitとGladiaを使って多言語音声エージェントを構築する方法」は、このTier 2モデルを明示的に対象としています。低遅延のコードスイッチングにGladiaを、リアルタイム音声にはLiveKitを使用し、彼のスタックはより高い基準を目指しています：フォームのようではなく、人間のように振る舞うエージェントを目指しています。

コードスイッチングは、バイリンガルの人々が考えもせず文の途中で言語を切り替える様子を指します。「ねえ、そのレポート送った？」や「Ça marche, 後で連絡するね。」という風に。心理言語学者たちはそれを欠陥ではなく特徴と見なしており、研究によればバイリンガルはトピック、感情、または話している相手に基づいて言語を切り替え、しばしば1分間に数回行うことが示されています。

AI音声エージェントにとって、その動作は聖杯です。スペイン語を話す顧客がIVRメニューを英語で始め、請求の問題を説明するためにスペイン語に移行し、カード番号のために再び英語に戻るかもしれません。最初の言語で固まってしまうシステムは、信頼、時間、そしてしばしばユーザーを失います。

現実のリスクは高まっています。メキシコシティ、マニラ、ワルシャワのグローバルサポートセンターでは、同じラインで英語と2〜4の現地語を巧みにやり取りしています。フィンテック、旅行、SaaSの国際営業の電話では、英語、ヒンディー語、地域方言の間を行き来しています。ニューヨークやロンドンのような都市の公共サービスは、医療、住宅、教育にわたる混合言語の会話を処理しなければなりません。

技術的には、これは厳しい問題です。生の音声は言語的文脈なしでは曖昧です。2秒のクリップは、異なる意味を持つ英語、ポーランド語、ポルトガル語のいずれかの言葉に対応する可能性があります。バックグラウンドノイズ、アクセント、専門用語が混乱を増幅させるため、初心者のモデルは「誤った言語にロックイン」され、二度と回復できなくなります。

すべての3つの柱—STT（音声認識からテキストへの変換）、LLM、TTS—は、言語の選択において完璧に同期する必要があります。LLMはすでに多言語のプロンプトにうまく対応でき、11 Labsなどの現代的なTTSエンジンは、クリーンなテキストを得れば説得力のあるポーランド語やスペイン語を話せます。音声認識が本当に難しい部分です。

マルチリンガルSTTは、リアルタイムで言語の境界を検出する必要があります。時には単語単位で、自然な通話のためには遅延を約300ミリ秒以下に保たなければなりません。「これは英語の‘no’なのか、ポルトガル語の‘não’なのか？」を即座に判断し、モデルやボキャブラリーを瞬時に切り替える必要があります。Gladiaのコードスイッチングモデルや、Voice AIクイックスタート | LiveKitドキュメントに記載されたフレームワークのようなツールが登場していますが、完璧なコードスイッチングは依然として未解決の課題です。

現代のコードスイッチング音声AIは、リアルタイムルーティング、音声認識、言語推論、合成音声の4つの柱の上に成り立っています。そのうちの1つを弱いコンポーネントに置き換えると、流暢でバイリンガルな会話の全体的な幻想が瞬時に崩れます。

中心には、エージェントの神経系のように機能するリアルタイム通信フレームワークであるLiveKitがあります。これは、低遅延の音声ストリーム、セッションの状態、バックプレッシャーを管理し、音声パケット、トランスクリプト、応答が数秒ではなく数百ミリ秒以内に到着することを保証します。

LiveKitは、スタックの異なる部分をそれぞれ所有する3つの専門サービスを結びつけています： - Gladia：音声認識 - OpenAI GPT-4.1：言語理解 - 11Labs：テキスト読み上げ

Gladiaはエージェントの耳として機能し、ユーザーが話している間に生の音声をテキストに連続して書き起こします。SEA SALARIA 1バリアントなどの多言語モデルは、数十の言語にわたるコードスイッチングをサポートし、文が英語からスペイン語、さらにポーランド語に飛ぶ際にもセッションをリセットすることなく検出します。

そのコードスイッチング能力は重要です。なぜなら、音声認識はこの連鎖の中で最も脆弱な部分だからです。もしGladiaがスペイン語をアクセントのある英語として誤認識すると、GPT-4.1は正しい言葉を一度も見ることができず、全体の「多言語」体験が意味不明なものや awkwardな確認質問に崩れてしまいます。

グラディアがテキストを発信すると、OpenAI GPT-4.1が頭脳として登場します。このLLMは会話の履歴、ユーザーの意図、言語の変化を追跡し、何を言うべきかだけでなく、どの言語で言うべきかも決定します。プロンプトによってGPT-4.1はユーザーの言語を自動的に反映するように促したり、明示的に求められた場合には切り替えたりすることができます（「¿Puedes hablar polaco?」）。

11Labsは声としてループを閉じます。ポーランド語、フランス語、または英語のトークンを入力すると、その言語で自然な音声を返し、同じ合成音声を使用するため、エージェントは異なるシステムの寄せ集めではなく、一貫したペルソナのように感じられます。

LiveKit、Gladia、GPT-4.1、そして11Labsが一体となって、リアルタイムの緊密な回路を形成します。音声が流れ込み、言語に配慮したテキストが通過し、正確にローカライズされた音声が出力されます—コードスイッチングがまるでカジュアルに行えるかのように、アプリを切り替える感覚ではなく、スムーズに行われるのです。

音声認識は、多言語音声エージェントが正常に機能するか、崩壊するかを静かに決定します。英語からスペイン語、ポーランド語に単一の文でコールを追跡する必要があるTier 2システムにとって、STTはスタックの中で最も難しい部分です。LLMsやTTSはクリーンなテキストから数十の言語を同時に処理できますが、STTはリアルタイムでノイズのある、重なり合った、強いアクセントのある音声からそれを行わなければなりません。

Gladiaのsea-salaria-v1モデルは、その重要な地点に位置しています。40以上の言語に対応しており、ネイティブのコードスイッチングをサポートするため、「Can you call mi mamá en Madrid?」のようなフレーズを一つの混乱した言語に変えてしまうことはありません。代わりに、実際の波形に現れるように英語とスペイン語をクリーンに分割し、転写します。

地域ルーティングは、sea-salaria-v1がデモだけでなくライブ製品にも適用できるようになることを意味します。Gladiaを利用すると、EU Westなど特定の地域に処理を固定できるため、ユーザーがロンドンやパリにいる場合、トランスアトランティックの往復で発生する100〜200msの遅延を回避できます。音声エージェントにとって、その遅延を短縮することは、前後の応答を約300msの閾値内に保ち、「AIの間」が明らかになるのを防ぎます。

言語の変更を音声から直接検出できるSTTエンジンがなければ、パイプライン内の他の何も賢くなる可能性はありません。LLMは受け取ったテキストの転写しか見ることができず、もしSTTがポーランド語を英語と誤認識して無意味なトークンを出力すれば、たとえどんなに優れたモデルでも間違った言語で自信を持って応答します。そしてTTSはその間違いをユーザーに喜んで話し返し、失敗を固定してしまいます。

STTレイヤーでのコードスイッチングサポートは、もろい事前ルーティングハックを防ぎます。電話番号やメニューの選択、最初の文から呼び出し者の言語を推測する必要はもうありません。Sea-salaria-v1は、秒数ゼロから聞き取りを開始し、ユーザーが英語の指示から急速なフランス語に切り替えたことを認識し、即座に文字セットや言語モデルを調整することができます。

Deepgramや他のSTTプロバイダーは、多言語対応やコードスイッチング機能を宣伝していますが、これらは多くのユースケースにおいて機能します。しかし、特定のTier 2エージェントにおいては、Gladiaが混在言語オーディオにおける生の文字起こし精度で勝ちました。特に、速い切り替えや英語-ポーランド語のようなあまり一般的でない組み合わせにおいては顕著です。全体の体験がそのようなエッジケースを完璧に処理することに依存している場合、その精度のギャップは決定的です。

LiveKitはもはや単なるWebRTCルーターとして機能するのではなく、コールループ全体を管理するエージェントランタイムとして振る舞います。STT、LLM、TTSを手動で接続するのではなく、オーディオフレーム、メッセージ、タイムアウトといったイベントに反応するエージェントを定義し、LiveKitがリアルタイムでその他を調整します。

中心にあるのは LiveKitエージェントフレームワーク で、これはメディアパイプラインに近い場所であなたのPython（またはNode）ロジックを実行します。この近接性は重要です。メディア、推論、ビジネスロジックの間のホップが少ないほど、エンドツーエンドのレイテンシが低くなり、コードスイッチング音声エージェントにとっては重要な要素となります。

LiveKit Inferenceは、このループに管理されたLLMおよびTTSレイヤーとして直接組み込まれます。あなたのエージェントはモデル（OpenAI、ローカル、またはベンダーがホストするもの）を指し示し、LiveKitは3つの異なるSDKを扱うことなく、トークンをストリーミングして音声を返す処理を行います。

LiveKit Inferenceを使用することで、多くの運用上の頭痛の種を回避できます。LLMやTTSの呼び出しにおけるベンダーごとのレート制限を避け、利用を一つの請求書にまとめ、さらにLiveKitが公共のAPIゲートウェイではなく、エンタープライズレベルのリンクを介してプロバイダーと通信するため、低遅延を実現することができます。

請求の統合は単なる便利さではなく、アーキテクチャの変革をもたらします。各プロバイダーに対してカスタムのスロットリングやフォールバックロジックを構築する代わりに、推論を予測可能なクォータとモニタリングを持つ単一のリソースプールとして扱います。

LiveKitの構造は、コンポーネントの交換をほぼ機械的にします。Hugo Podのagent.pyでは、GladiaがSTTプロバイダーとしてシンプルな設定ブロックを介してプラグインします：モデル名（sea salaria 1）、地域（EU West）、およびサポートされている言語のリスト。

そのデザインは、思い切った実験を行うことができることを意味します。2つのTTS音声や2つのLLMプロンプトをA/Bテストしたいですか？エージェント定義の数行を変更するだけで、LiveKitはセッション状態、メディアルーティング、および再接続ロジックを引き続き処理します。

生のWebRTCやDIY gRPCサービスから来たチームにとって、これは異なる抽象レベルです。ソケットやコーデックについて考えるのをやめ、“エージェントセッション”や水平方向にスケール可能な“ジョブ”について考え始めます。

LiveKitのドキュメントはこのモデルに沿っています。音声エージェントの構築 | LiveKit ドキュメント では、バックグラウンドジョブ、マルチエージェントルーティング、そして多言語プロジェクトで再利用できるカスタムツールなどのパターンを紹介しています。

現代のLLMは、言語を切り替えるよう求められてもほとんど汗をかきません。GPT-4クラスのモデルは、多言語のウェブ、書籍、フォーラム、コードリポジトリから集めた数兆のトークンで訓練されており、英語やスペイン語からポーランド語、さらにはニッチな方言に至るまで幅広くカバーしています。「フランス語で答えてから英語で要約して」と指示すると、彼らはトークンごとにそれを実行します。

その多言語の挙動は追加機能ではなく、これらのモデルが学習する方法から自然に生まれるものです。訓練中、彼らは異なる言語で表現された並行する概念を目にし、巨大な共有埋め込み空間を最適化します。したがって、ユーザーが文の途中で「Can you book a flight?」から「para mañana a Madrid」に切り替えても、モデルは単に最も可能性の高い次のトークンを予測し続け、今度はスペイン語で行います。

プロンプトにより、正確なコントロールが可能になります。「必ず呼びかける人の言語で応答してください」や「英語で話すが、引用された外国語のフレーズは反映してください」とLLMに指示できます。単一のシステムメッセージで、同じGPT-4インスタンスがドイツ語でのカスタマーサポート、ポルトガル語での技術オンボーディング、英語でのフォローアップ質問などを、すべて一貫したセッション内で処理できます。

出力面では、11LabsのようなTTSシステムはさらに簡単です。彼らはあなたが意図した言語を推測する必要がなく、テキストが既に使用している言語をそのまま合成します。ポーランド語のテキストを与えればポーランド語の音声が生成され、フランス語に切り替えればフランス語が得られ、言語間で一貫した声のトーンを保つことがよくあります。

多言語TTSは主に二つの要素に依存します：言語のカバレッジと音声の品質です。もしあるプロバイダーが28言語とクロスリンガル音声をサポートしている場合、あなたのアプリは英語からスペイン語、さらにはポーランド語へリアルタイムで移行しながら、同じ「エージェントペルソナ」を維持できます。再構成は不要で、言語ごとに異なる音声も必要ありません。

そのエレガンスは、LLMに入る言葉が間違っている場合、崩れ落ちます。本当の魔法、そして本当のリスクはSTTにあります。そこで、Gladiaのようなモデルが言語の変化を検知し、正確にセグメント化し、LLMにクリーンでコード切替されたトランスクリプトを提供しなければなりません。

Agent.pyはこの多言語セットアップの配線図として機能し、ほとんどの魔法はカスタムアルゴリズムではなく設定から生まれます。Hugoは、GladiaSpeechToText、LiveKitの推論サービス、およびいくつかの会話コントロールを1つのリアルタイムループに結びつける単一の`Agent`を定義します。

音声認識は最も詳細なチューニングが行われます。`GladiaSpeechToText`ブロックは、`model="sea-salaria-1"`、`region="eu-west"`、および`languages`配列の3つの重要なパラメータを指定します。この`sea-salaria-1`モデルは、英語、スペイン語、ポーランド語などの間での文中切り替えを処理するために設計されたGladiaのコードスイッチング用の主要なモデルです。

地域の選択はレイテンシに影響します。ロンドンから `region="eu-west"` を設定することで、Hugoは音声が大西洋を越えてデフォルトの米国エンドポイントに飛ばされることなく、往復時間を短く保ちます。多くのSTTプロバイダーは地域ルーティングを隠していますが、Gladiaはそれを直接公開しており、これは珍しく、リアルタイム音声にとって非常に便利です。

`languages`パラメータは、ティア1からティア2に移行する部分です。Hugoはモデルに「このコールはフランス語です」と伝える代わりに、許可されたオプションのリストを渡します。例えば： - `"en"` - `"fr"` - `"es"` - `"pl"` それからGladiaは、どの言語が話されているかを自動的に検出し、転記ルールを即座に切り替えます。

LiveKitの側は比較するとほぼ退屈に見えますが、それがまさに目的です。LLM推論のために、Hugoは「gpt-4o-realtime-preview」のようなモデルを用いた`LiveKitInference`クライアントを接続し、「あなたは役立つ音声アシスタントです。」という短いシステムプロンプトを設定しています。追加の多言語フラグもなく、ルーティングロジックもなく、すでに数十の言語を理解しているモデルが1つあるだけです。

テキスト音声変換も同様のパターンを使用します。選択したボイスIDを持つモデル「eleven_multilingual_v2」を指す`LiveKitInference` TTSクライアントがあります。TTSエンジンが対象言語をサポートしている限り、ポーランド語やスペイン語のテキストを渡すだけで機能するため、コードはほぼ設定のみになります。

ターンテイキングは、小さな設定変更がユーザー体験に大きな影響を与えるところです。ヒューゴはLiveKitの`turn_detection`モデルを`"english"`から`"multilingual"`に切り替え、エージェントが非英語言語や混合言語の文において、正しくポーズや発話の終わりを検出できるようにします。

ついに、`preemptive_generation=False`を設定することでエージェントがユーザーの発言を遮る習慣を無効にします。多くのリアルタイムシステムは、ユーザーが発言を終えたと“判断”するとすぐに話し始めますが、これはユーザーが別の言語で句を追加する際にコードスイッチングを妨げます。エージェントに明確な発言の区切りを待たせることで、自然な会話が維持され、文の途中での中断を防ぎます。

デモのコードスイッチングの瞬間は、無邪気に始まります。ユーザーは英語でオープンし、エージェントと通常のTier 1システムのように会話します。すると、ほとんどの生産音声ボットを壊してしまうような pivot line が来ます。「ポーランド語を話せるか知りたかっただけです。」

英語で返事をしたり、フリーズしたりする代わりに、エージェントは即座に切り替わります。流暢で自然な響きのポーランド語で回答し、TTSスタックからの正しい音韻と韻律を伴っています。これは、LLM、プロンプト、音声設定がすべてリセットなしで言語の切り替えを受け入れたことを示しています。手動の言語切り替えも、再初期化も、「言語を切り替え中です、少々お待ちください」という遅延もありません。

重要なのは次に何が起こるかです。ユーザーはポーランド語で続け、完全な対話に入り、その言語だけで進めます。エージェントは後続のポーランド語のフレーズを理解し、文脈を保持し、一貫性のある関連したポーランド語の応答を返します。これは、多言語製品が約束するがめったに実現しないTier 2の行動そのものです。

そのパフォーマンスは、裏側でSTTに依存しています。Gladiaのモデルは、最初は英語で始まる音声を受け取り、会話の途中でポーランド語に移行しても、低遅延で正確なトランスクリプトを生成します。このトランスクリプション品質が、LLMが「英語モード」と「ポーランド語モード」のスレッドを生成するのではなく、単一の会話状態を維持することを可能にしています。

実行のログには興味深い問題点が浮かび上がる：「ターン検出器はポーランド語をサポートしていません。」ターン検出は、ユーザーが話し終えたと判断するためのものなので、この警告は副次的なコンポーネントが特定の言語のみをセグメント化できることを意味します。それにもかかわらず、システムは決して目に見える形でつまずくことはなく、コアのSTTパイプラインがポーランド語を信頼性高く認識・転記し続けています。

これは微妙ですが重要な建築的ポイントです。言語制限のあるターンディテクターのような非重要な部分が警告を出す一方で、メインの**Gladia** 転写エンジンは異なる言語で問題なく動作し続けることができます。実際の展開において、その懸念の分離は、実際に体験を支える多言語の脳にリスクを与えることなく、補助モジュールを反復して改善できることを意味します。

多言語対応エージェントは、高度なフレームワークのLiveKitを目的特化型のSTTエンジンGladiaに接続すると、単なる研究用のおもちゃではなくなります。LiveKitは、煩雑なリアルタイムの配線処理—WebRTC、セッション、エージェントのライフサイクル—を管理し、Gladiaの低遅延でコード切替可能なモデル（その一例がsea-salaria-1）が、一般的なモデルが未だに苦手とする一つの仕事をこなします。それは、同じ呼吸の中での複数言語の検出と文字起こしです。この組み合わせにより、シンプルなボイスボットが、システム設定を人間に追わせるのではなく、人間の会話を追跡するTier 2エージェントへと進化します。

これらの要素を組み合わせることで、実際にグローバルスケールで機能する製品が解放されます。単一のサポートラインは、メキシコシティ、ワルシャワ、パリの顧客を同じ多言語音声エージェントに接続し、製品名は英語、その他は母国語の間を行き来する際にもそれに伴います。IVRツリーは不要で、「スペイン語は3を押してください」といった指示もなく、リアルタイムで適応する一つのエンドポイントがあります。

会議も変わります。英語、ドイツ語、ポーランド語を行き来する参加者がいる10人の通話を聞き取るZoomやMeetの伴侶を想像してください。これにより、次のようなことが実現します： - 各参加者の希望する言語でのライブキャプション - 話者と言語でタグ付けされた検索可能なトランスクリプト - コードスイッチングが発生したタイミングと理由を保った要約

消費者アシスタントも同様に恩恵を受けます。バイリンガルの家族は、英語でホームデバイスと会話し、途中でフランス語に切り替えて祖父母に話しかけ、その後再び英語に戻ることができます。ウエイクワードのリセットやアプリ設定の変更なしに行えるのです。「デフォルト」言語の習熟度が限られているユーザーは、理解されるためにその言語に固執する必要がなくなり、アクセスibiltyが向上します。

かつて研究所での開発が必要だった障壁—高速ASR、堅牢なコードスイッチング、低遅延ストリーミング—は、今や週末のプロジェクトに収まるようになりました。LiveKitがリアルタイムスタックを抽象化し、Gladiaが多言語STTを担い、主流のLLMとTTSはすでに数十の言語を標準で話します。難しい部分は「これは構築できるのか？」ではなく、「このエージェントは実際に何をすべきか？」となりました。

自分で答えられますよ。「How to Build a Multilingual Voice Agent with LiveKit & Gladia」のGitHubリポジトリをチェックし、自分のプロンプトと声を組み込んで、ユーザーが既に互いに話すように話しかけるエージェントを作り始めてください。

AIコードスイッチングとは何ですか？

コードスイッチングは、AI音声エージェントが同じ会話の中で複数の言語を検出して切り替える能力であり、これはバイリンガルの人間と同様です。これには高度な音声認識技術が必要です。

なぜグラディアは多言語ボイスエージェントに推奨されるのか？

Gladiaの音声認識は、さまざまな言語における高い精度、低遅延、そしてこの種のエージェントにとって最も重要な機能であるコードスイッチングへの特化したサポートが評価されています。

このプロジェクトにおけるLiveKitの役割は何ですか？

LiveKitは音声エージェントの基盤となるフレームワークとして機能し、リアルタイム通信（WebRTC）を管理し、エージェント開発キットを提供します。また、その推論機能は、API呼び出しをプロキシすることで、GPT-4や11Labsのようなモデルの利用を簡素化します。

このLiveKitのセットアップで別のLLMやTTSを使用できますか？

はい。LiveKitのフレームワークは柔軟です。チュートリアルではOpenAIのGPT-4と11LabsをLiveKit Inference経由で使用していますが、あなたのニーズに合った他の言語モデルやテキスト音声化サービスを統合することも可能です。