文字起こしにおけるコードスイッチング誤りの修正

混合言語音声が壊れる理由

ほとんどのコードスイッチング失敗の解決策は、ネイティブの多言語モデルを備えたエンジンを選び、単一の言語に固定しないよう指示することです。AssemblyAIを使っている場合は speech_model: "universal" を渡し、2つの言語コードを設定します。Deepgramの場合は、Nova-3またはFluxで language=multi を設定します。Whisperの場合は language=None を設定して、セグメントごとの検出を許可します。この投稿の残りでは、これらの選択がなぜ重要なのか、そしてそれでも失敗する場合にどうすればよいのかを説明します。

ほとんどの文字起こしエンジンは、単一言語の前提で作られています。 音声を受け取り、主要言語を選び、すべての音素をその言語の語彙にマッピングします。話者が文の途中で言語を切り替えると、モデルは3つの悪い選択肢に直面します。第2言語を第1言語の音声近似として出力する（「para crear」が「para crayer」になる）、新しい言語に固定されてしまい、話者が元の言語に戻ってもそこにとどまる、あるいは一致しないセグメントを完全に落とす。いずれも壊れた文字起こしになります。

より深い問題は、特に言語境界にあります。多言語音声モデルに関する研究では、スイッチポイントWER（各言語遷移の前後2〜3語のウィンドウで測定されるエラー率）は、全体のブレンドWERより30〜50ポイント高くなりうることが示されています。全体で10%のWERを記録するモデルでも、すべてのコードスイッチを台無しにしうるのです。ブレンドされた精度の数字は、これを隠してしまいます。

3つの失敗モード

どの失敗モードに直面しているかを理解すれば、どの修正を適用すべきかがわかります。

音声置換：エンジンが主要言語にとどまり、第2言語の単語を近似の同音異義語として出力します。最も一般的な失敗で、最も見つけやすいものです。「Finalizando」が「finally sando」になります。修正策：多言語エンジンに切り替える。

言語ロック：エンジンが切り替えを検出して新しい言語に固定し、その後元に戻せなくなります。文字起こしの残りが間違った言語になります。修正策：ジョブ単位ではなく、セグメント単位の検出を使う。

境界ハルシネーション：モデルが遷移点で文脈を見失い、実際には発話されていないもっともらしいテキストを生成します。出力はきれいに見えるのに間違っているため、最も気づきにくい失敗です。沈黙やノイズが言語境界に重なる短い音声セグメントでは、特にWhisperでよく起こります。修正策：VAD（音声アクティビティ検出）による前処理で、無音セグメントをモデルに届く前に除去する。また、スイッチの多いコンテンツでは、汎用の多言語モデルよりも専用のコードスイッチエンジンを優先する。

修正策1：専用のコードスイッチエンジンを使う

2024年以降のこの分野で最も明確な進歩は、いくつかの主要APIが「多言語対応」だけでなく、専用のコードスイッチモードを提供するようになったことです。

language=multi を指定したDeepgram Nova-3は、英語、スペイン語、フランス語、ドイツ語、ヒンディー語、ロシア語、ポルトガル語、日本語、イタリア語、オランダ語の10言語にわたるコードスイッチングをサポートします。/listen を呼び出す際に、クエリ文字列で language=multi を設定します。ストリーミングでは、コードスイッチされた音声に対して、Deepgramは endpointing=100（100ミリ秒のエンドポイント検出）を推奨しています。Nova-3 Multilingualは2026年3月のアップデートで、バッチWERを約34%相対的に削減し、最大の改善はコードスイッチ境界で得られました。

**Deepgram Flux Multilingual（flux-general-multi）**は、2026年4月に一般提供されました。同じ10言語をサポートし、コードスイッチングが単一言語モデルの上に検出レイヤーとして載せられているのではなく、モデルアーキテクチャにネイティブに組み込まれています。どの言語が含まれているかわかっている場合は、オプションの language_hint パラメータを渡して検出を補助できます。

AssemblyAI Universal-3 Proは、録音済み音声のコードスイッチングを、英語、スペイン語、ポルトガル語、フランス語、ドイツ語、イタリア語で処理します。知っておくべき制約：1回の文字起こしリクエストで指定できるのは最大2つの言語コードで、そのうち1つは英語である必要があります。最良の結果を得るには、非英語の言語が音声中で優勢である必要があります。

リアルタイムストリーミングについては、AssemblyAIのUniversal-Streamingモデルが、手動での言語指定なしに6言語（英語、スペイン語、フランス語、ドイツ語、イタリア語、ポルトガル語）を1回のフォワードパスで処理します。

これらのセット外の言語ペアについては、Whisperベースのツールが依然として最も広く使えるフォールバックです。修正策2を参照してください。

関連記事：多言語モデルアーキテクチャを詳しく知りたい方は、Deepgram Nova-3の解説をご覧ください。

修正策2：未対応の言語ペアには自動検出付きのWhisperを使う

上記の専用エンジンがカバーしない言語ペア（ウォロフ語＋フランス語、広東語＋英語、タグリッシュ、シングリッシュ、ポルトゥニョールなど）には、学習データがより幅広い言語の組み合わせをカバーしているため、Whisper Large-v3が最も実用的な選択肢です。

重要な設定：単一の言語コードを強制するのではなく、セグメントごとの検出を許可するために language=None を設定します。

result = model.transcribe(
    audio_file,
    language=None,  # auto-detect per segment
    task="transcribe"
)

特定の言語コードを設定すると、モデルはすべての音声をその言語として解釈するよう強制されます。Noneに設定すると、Whisperは30秒ごとのウィンドウで言語を推定できます。

正直な注意点：Whisperのコードスイッチ精度は言語境界で低下し、その地点では専用エンジンよりもハルシネーションを起こしやすいです。ヒングリッシュに関しては、2026年時点で信頼性を持って対応できる商用文字起こしツールはありません。ヒンディー語−英語のコードスイッチングには、Whisperが現状最良の選択肢ですが、学習データが豊富なスパングリッシュやフランス語−英語のコンテンツよりも、多くの手動修正が必要になると想定してください。

修正策3：対応している場合は言語を明示的に指定する

単一のコードではなく言語リストをサポートするエンジンでは、音声に含まれる言語を明示的に指定することで、モデルが検出に集中しやすくなります。

# Google Cloud Speech-to-Text (Chirp 3, V2 API)
config = {
    "model": "chirp_3",
    "language_codes": ["es-US", "en-US"]  # up to 3 languages; fewer = more accurate
}

Googleのドキュメントでは、指定する言語を少なくするほど検出精度が上がるとされています。V2 APIはChirp 3で language_codes: ["auto"] による完全自動検出にも対応していますが、言語ペアがわかっている場合は、明示的なコードの方が自動検出より優れています。

Google Cloud STTの場合、この機能は global リージョンおよび us と eu のマルチリージョンでのみ利用可能です。

コードスイッチングのパターンとエンジンの選択

適切なエンジンは、どの言語が切り替わるかによって変わります。以下は、一般的なペア別の実用的な内訳です。

言語検出と併せて話者分離が必要な多言語会議の録音については、話者ダイアライゼーションの解説と多言語会議の文字起こしをご覧ください。

AWS Transcribe：多言語識別とコードスイッチングの違い

AWS Transcribeは、バッチジョブとストリーミングジョブの両方に多言語識別を追加しました。この機能はセグメントごとに優勢な言語を検出し、文字起こし出力にラベルを付けます。「米国英語とヒンディー語（Hindi-IN）のように言語を交互に使用するバイリンガル話者」を、各言語を個別に識別・文字起こしすることで認識できます。

重要な区別：これは言語識別とセグメントごとの文字起こしであり、文途中のコードスイッチングではありません。構造化された交互使用（話者Aが英語で答え、話者Bがスペイン語で返す）ではうまく機能します。文内混合（「I was finalizando the deal」のような場合）では、切り替えが単一の検出ウィンドウ内で発生するため、信頼性が低くなります。

現在、多言語識別と併用しての編集（リダクション）機能やカスタム言語モデルはサポートされていません。

修正策4：予測可能な切り替えは音声を分割する

文レベルの混合ではなく、構造化された言語の交互使用がある録音では、言語セグメントごとに分割して各部分を個別に文字起こしすると、最もきれいな出力が得られます。

次のような場合には、追加の手順を踏む価値があります。コンテンツに予測可能な言語境界がある場合（質問は英語、回答は標準中国語というインタビューなど）、追加作業に見合うだけ重要度が高い場合、あるいは言語ペアが専用エンジンでサポートされていない場合。

ワークフロー：言語境界を特定し（手動または言語検出ツールで）、セグメントに分割し、各セグメントを対応する言語設定で文字起こしし、順番に結合します。構造が予測可能な定型的なコンテンツなら、スクリプト化できます。

コードスイッチされた文字起こしの手動クリーンアップ

最良のエンジンを選んでも、コードスイッチされた文字起こしは、焦点を絞ったレビューパスから恩恵を受けます。

まずスイッチポイントの単語を確認する。 各言語境界の直前と直後の単語に、ほとんどのエラーが集中します。全文を読む前に、まずその位置を確認しましょう。

音声置換を修正する。 モデルがある言語を、もう一方の言語の近似的な音声一致として出力した箇所は、両方の言語を知っていれば通常は間違いだとわかります。「para crear」が「Para crayer」、「I told my mom accha」が「I told my mom acha」となるようなケースです。

固有名詞を確認する。 言語境界をまたぐ人名、地名、ブランド名は、一貫性なく、あるいは音声的に出力されることがよくあります。重要度の高いコンテンツには、バイリンガルのネイティブスピーカーによるレビューが最も効率的なチェック方法です。

読みやすさを優先して正確性を犠牲にしない。 コードスイッチされた発話は、文字起こしの形ではぎこちなく読めることがありますが、文字起こしの役割は何が話されたかを記録することであり、滑らかに読めることではありません。ぎこちない箇所は黙って整えず、人によるレビュー用にフラグを立てましょう。

エンジン横断の精度ベンチマークについては、文字起こし精度の解説をご覧ください。

問題がコードスイッチングではない場合

一部の音声は、実際には別の問題なのに、コードスイッチングの問題と誤診されることがあります。

単一言語の訛りのある発話：強い地域訛りのある話者は、モデルの言語検出を誤作動させることがあります。これはコードスイッチングではなく、修正策も異なります。多言語コードスイッチモードではなく、訛りへの耐性が強いモデルを使いましょう。

外来語と借用語：「I ordered sushi at the izakaya」と言う話者は、コードスイッチしていません。それ以外は単一言語の文中に埋め込まれた単一の外来語は、最新のエンジンならどれでもうまく処理します。これが文字起こしの問題になるのは、外来語が珍しく、モデルが音声的に出力する場合だけです。

構造化されたバイリンガルコンテンツ：各発話がきれいに1つの言語である場合（話者Aは英語、話者Bはフランス語）、それはコードスイッチングではなくバイリンガルコンテンツです。コードスイッチモデルではなく、多言語識別（AWS Transcribe、Google Cloud STT）または話者ごとの言語割り当てを使いましょう。

経験則：切り替えが文の途中で起こる場合（1つの発話内で文法構造が混在する）、それはコードスイッチングです。切り替えが発話の境界で起こる場合は、バイリンガルコンテンツです。修正策は異なります。

録画された多言語会議については、音声から議事録を作成で、言語処理を含むエンドツーエンドのワークフローを解説しています。

私の見解：2025年の実用的な助言は「Whisperを使い、限界を受け入れる」でした。2026年半ばの現在、状況はより分化しています。Deepgramの language=multi がカバーする10言語と、AssemblyAIのU3-Proコードスイッチモードの6言語については、専用エンジンがスイッチ境界においてWhisperより測定可能なほど優れています。それらのエンジンがカバーしない言語ペアには依然としてWhisperが正しい選択ですが、もはやすべてに対するデフォルトの推奨ではありません。ワークフローではなく、言語ペアに合わせてエンジンを選びましょう。

APIを設定せずに多言語音声から素早く文字起こしが必要な場合は、ConvertAudioToTextが自動言語検出に対応しており、初回利用にはアカウント登録が不要です。

FAQ

2026年時点でヒングリッシュに最適な文字起こしエンジンは何ですか？

language=multi を指定したDeepgram Nova-3が最有力の選択肢です。ヒンディー語が10言語のコードスイッチングセットに含まれているためです。language=None を指定したWhisper Large-v3は妥当なフォールバックです。現在のところ、あらゆる地域の訛りにわたってヒングリッシュを高精度で処理できるエンジンは存在しません。スパングリッシュやフランス語−英語のコンテンツよりも、ヒングリッシュでは多くの手動修正が必要になると想定してください。ヒングリッシュで80〜90%の精度という主張は、独立したベンチマークでは検証できません。

AssemblyAIのコードスイッチングはDeepgramとどう違いますか？

録音済み音声の場合、AssemblyAI Universal-3 Proは1リクエストにつき2つの言語コードをサポートし、そのうち1つは英語である必要があり、非英語の言語が優勢な場合に最良の結果が得られます。language=multi を指定したDeepgram Nova-3は、英語を必須とせずに10言語をカバーし、2言語制限も課しません。リアルタイムストリーミングでは、両社とも専用の多言語ストリーミングモデルを提供しており（AssemblyAI Universal-Streamingは6言語、Deepgram Fluxは10言語）、差は縮まります。必要な言語ペアに基づいて選びましょう。

AWS Transcribeは文途中でのコードスイッチングに対応していますか？

AWS Transcribeの多言語識別は、各発話が1つの言語である構造化されたバイリンガルコンテンツにはうまく機能しますが、文内コードスイッチング（1つの文の中での混合）には信頼性が低くなります。この機能は音声セグメントごとに優勢な言語を検出し、各セグメントを個別に文字起こしします。文途中の切り替えには、言語ペアが重なるのであればDeepgram Nova-3またはAssemblyAI Universal-3 Proの方が良い選択です。

Whisperは言語境界でなぜハルシネーションを起こすのですか？

Whisperのデコーダーは、学習音声から習得したパターンに基づいてテキストを生成します。言語切り替え点で音声内容が曖昧な場合（特に無音や背景ノイズの近く）、モデルは実際の発話ではなく統計的にありそうな続きを出力し、もっともらしい捏造テキストを生成します。音声アクティビティ検出（VAD）による前処理で、ハルシネーションを引き起こしやすい無音セグメントを除去できます。スイッチの多いコンテンツでは、専用のコードスイッチモデルの方が境界ハルシネーションを起こしにくくなっています。そのアーキテクチャはパターンの継続ではなく、切り替えシグナルを明示的に処理するためです。

出典

• AssemblyAIコードスイッチングドキュメント： https://www.assemblyai.com/docs/pre-recorded-audio/code-switching
• AssemblyAI Universal-Streaming多言語ブログ： https://www.assemblyai.com/blog/real-time-transcription-code-switches-multilingual-speakers
• Deepgram多言語コードスイッチングドキュメント： https://developers.deepgram.com/docs/multilingual-code-switching
• Deepgram Flux Multilingual発表（2026年4月）： https://deepgram.com/learn/deepgram-launches-flux-multilingual-press-release
• Deepgram Nova-3 Multilingual WER更新（2026年3月）： https://deepgram.com/learn/nova-3-multilingual-major-wer-improvements-across-languages
• Google Cloud Speech-to-Text複数言語ドキュメント： https://docs.cloud.google.com/speech-to-text/docs/multiple-languages
• AWS Transcribe言語識別ドキュメント： https://docs.aws.amazon.com/transcribe/latest/dg/lang-id.html