ヒンディー語文字起こしとヒングリッシュの壁（2026年最新）

実際の問題：ヒンディー語音声の多くは実質「ヒングリッシュ」

現代のヒンディー語音声のほとんどは純粋なヒンディー語ではありません。 ビジネス系ポッドキャストの一節には、次のようなものがあります。「Aaj meeting mein hum decide kiya ki next quarter mein hum launch karenge, but pricing strategy abhi finalize nahi hui hai.」これは1つの文の中に、ヒンディー語が7単語、英語が7単語混ざり合い、息継ぎなしで発音されています。AIエンジンは、単語ごとにデーヴァナーガリー文字とラテン文字のどちらを出力すべきかを判断しなければなりません。

ヒングリッシュ音声：ヒンディー語を設定しコードスイッチ部分を確認

これこそが2026年におけるヒンディー語文字起こしの最大の難所です。言語の切り替えだけでなく、表記文字（スクリプト）の切り替えという二重の問題が絡んでいます。適切に処理できるエンジンは自然で読みやすいテキストを出力しますが、そうでないエンジンは（英単語を無理やり音写した）全編デーヴァナーガリー文字になるか、ヒンディー語を完全に無視してすべて英語として扱ってしまいます。

本ガイドでは、ラボ内のベンチマークではなく、公式ドキュメントや開発者の実際のレポートに基づいて、主要エンジンがこの課題にどう対処しているかを解説します。

デーヴァナーガリー文字：表記上の要求仕様

ヒンディー語は、47の基本文字（14の母音と33の子音）を持つアブギダであるデーヴァナーガリー文字で書かれます。文字は左から右へ書かれます。最大の特徴は「シローレーカー（shirorekha）」と呼ばれる文字上部の水平線で、文字同士を視覚的につなげて単語を形成します。

文字起こしにおいて重要な表記構造がいくつかあります。

マートラー（母音記号）： 母音は独立した文字としてではなく、先行する子音に付加されるダイアクリティカルマークとして書かれることがよくあります。子音を正しく認識できても、マートラーの位置を誤るモデルは判読不能なデーヴァナーガリーを出力してしまいます。

結合子音（サンユクタ・ビャンジャン）： 2つの子音が母音を挟まずに連続する場合、1つの合字に統合されます。たとえば「ज्ञान」（知識）は結合子音です。これらを誤るのは、モデルのデーヴァナーガリーの学習データが不足している証拠です。

ヌクター（下点）： 子音の下に打たれる点は、サンスクリット由来のヒンディー語にはない外来音を示します。「ज़」（za）、「क़」（qa）、「फ़」（fa）などはすべてヌクターを使用しており、ウルドゥー語の影響を受けたヒンディー語や、音写された英語の借用語に頻出します。

シュワー削除（随伴母音脱落）： 話し言葉のヒンディー語では、音節末尾の短い「a」の母音（シュワー）が脱落することが多々あります。「राम」は「ラーマ」ではなく「ラーム」と発音されます。シュワー削除をモデル化できていない文字起こしエンジンは、音韻的に不正確な出力を生成します。

正確なヒンディー語文字起こしには、これらすべてを正確に捉える必要があります。ツールが「मैं आपका शुक्रिया अदा करता हूँ」ではなくローマ字表記の「main aapka shukriya ada karta hoon」を返す場合、そのツールは実質的にヒンディー語を処理できていません。

ヒングリッシュの規模とコードスイッチングの構造

New York Timesの報道によると、インドの都市部では3億5,000万人以上が日常的にヒングリッシュを使っています。インド工科大学（IIT）デリー校の研究では、ヒングリッシュの使用頻度は2022年から2024年の間に前年比2%増で拡大していることが示されました。ヒンディー語話者の約83%が、発話中にある程度英語の単語を混ぜています。

ヒングリッシュにおけるコードスイッチング（言語の切り替え）は無秩序ではありません。明確なパターンが存在します。

• 名詞や専門用語から英語に切り替わる： 「Budget」「deadline」「meeting」「strategy」などは、極めてヒンディー語優位な発話であっても英語のまま使われます。
• 動詞はヒンディー語にとどまりやすい： ただし英語の動詞がヒンディー語化されます。「launch karna」「finalize karna」「decide kiya」などがその例です。
• 文単位の切り替え： 改まった場面では、文の前半をヒンディー語で始め、後半を英語で締めくくるといった切り替えが一般的です。
• 単語レベルの混在： カジュアルな会話、SNS、ボリウッド映画のセリフでは、単語単位での混在が主流です。

その結果、単一の言語コードでは話者の発話を正しく定義できません。language=hiに設定するとデーヴァナーガリー文字で出力されますが、英語部分が適切に処理されない可能性があります。language=enに設定するとヒンディー語部分が完全に抜け落ちます。対応エンジンでlanguage=multiを設定するのが正解ですが、その挙動はエンジンごとに異なります。

技術的な詳細については、コードスイッチングが文字起こしパイプラインに与える影響をご覧ください。

主要エンジン別のヒングリッシュ処理状況

OpenAI Whisper (large-v3)

Whisper large-v3は最も著名な多言語モデルであり、明示的にlanguage=hiを設定すれば純粋なヒンディー語を良好に処理します。しかしヒングリッシュの場合、挙動は一貫しているものの多くのユースケースにとって理想的ではありません。英語の借用語やコードスイッチされた英語フレーズまでデーヴァナーガリー文字で音写してしまうためです。 たとえば「next quarter mein launch karenge」は、「next quarter」をラテン文字に残さず「नेक्स्ट क्वार्टर में लॉन्च करेंगे」と出力される可能性があります。

Whisperには、文字が混在したヒングリッシュ出力を指定する公式フラグがありません。コミュニティの回避策として、Trelis Researchによるファインチューニングモデル「Whisper-Hinglish」があり、|mixedcode|トークンでデーヴァナーガリーとラテン文字の混在を指示できますが、公式APIには実装されていません。

さらにもう1つの落とし穴として、自動言語検出を使用すると、Whisperベースモデルはヒンディー語をウルドゥー語と誤認することがあります（両言語は言語学的に非常に近く、口語表現を共有しているため）。ウルドゥー語はナスタアリーク体で表記されるため、ヒンディー語読者には読めなくなってしまいます。Whisperを使用する際は、必ず明示的にlanguage=hiを指定してください。

Deepgram Nova-3

Nova-3はヒンディー語（hi）を標準でサポートしています。純粋なヒンディー語音声に対しては、Deepgramの中でも最も強力な選択肢です。

ヒングリッシュ向けとして、Nova-3は10言語間でヒンディー語・英語のコードスイッチングをサポートする多言語モード（language=multi）を備えています。このモードでは、Nova-3は話者が選んだ文字表記を自然に出力します。 つまり、ヒンディー語の単語はデーヴァナーガリー文字で、英単語はラテン文字で表記されます。合成データではなく実際のコードスイッチングデータで訓練されているため、アーキテクチャとして理にかなっています。

ただし開発者のレポートによると、Nova-3 multiはヒングリッシュの録音においてヒンディー語をスペイン語と誤認することがあり、文字起こしが著しく破綻するケースが報告されています。これは多言語モデルにおける言語検出の信頼性の問題であり、アーキテクチャの根本的な欠陥ではないと見られます。一部の開発者が講じている回避策は、言語コードhiを指定してNova-2やNova-1に戻し、すべてデーヴァナーガリー文字になる制限を受け入れることです。

Deepgramはまた、標準的なWER（単語誤り率）指標がインド系言語でなぜ機能しないかを分析したBRIDGEフレームワークも発表しています。モデルの構造についてはDeepgram Nova-3の解説記事を参照してください。

AssemblyAI Universal-3

AssemblyAIのUniversal-3モデルは99言語をサポートし、自動コードスイッチングと話者分離に対応しています。ヒンディー語も対応言語に含まれています。AssemblyAIはヒンディー語の話者分離を特別に拡張しており（中国語、日本語、韓国語、ベトナム語と並ぶ）、複数人によるヒンディー語およびヒングリッシュの音声を正しく識別可能です。

Universal-3 Proにおいて、ヒンディー語はAssemblyAIがWER 10〜25%と定義する「良好な精度（Good accuracy）」ティアに位置付けられています。最高峰とまでは言えないものの実用的なレベルです。AssemblyAIの話者分離は言語が切り替わっても話者の特定を維持できるため、1人のホストがヒンディー語を多く話し、もう1人が英語を多く話すポッドキャストでも正確にラベル付けされます。

Google Cloud STT (Chirp)

Google CloudのChirpモデルは125以上の言語に対応し、分単位の従量課金制を採用しています。ヒンディー語もサポートされています。コードスイッチングに対して、Googleは以前からlanguage_codesにhi-INとen-INの両方を含める設定を推奨しており、混合音声の処理が可能ですが、ヒングリッシュにおける出力の一貫性にはばらつきがあります。

APIを直接利用するユースケース（Deepgram、AssemblyAI）

パイプラインを自作する場合、DeepgramとAssemblyAIはどちらもヒンディー語対応のREST APIを提供しています。DeepgramのAPI料金やAssemblyAIの従量制モデルの比較詳細は、音声テキスト変換APIの料金比較ガイドをご覧ください。

エンジン比較一覧表

考察：読みやすい文字混在のヒングリッシュ出力を求める場合、言語検出が正しく機能していればDeepgram Nova-3 multiが構造上最も適しています。デーヴァナーガリー文字のみが必須である純粋なヒンディー語音声には、明示的にlanguage=hiを指定したWhisper large-v3が安定しています。言語の切り替えをまたぐ話者分離が最優先なら、AssemblyAIが優れた選択肢です。

インドの地域訛りと認識精度

インドには数十のヒンディー語の地域方言・訛りが存在し、それぞれAIエンジンの処理に影響を与える明確な音韻パターンを持っています。

デリー/NCRヒンディー語（都市部、英語の混在多め）：学習データで最も手厚くサポートされています。ベンチマークテストのデータセットに最も近い特徴を持ちます。

ムンバイヒンディー語（バンバイヤ）：マラーティー語の音韻がそり舌子音や母音の長さに影響を与えます。「Bhai」は独特の社会的な目印となる言葉です。精度はデリー方言より劣るものの、主要エンジンでも十分実用に耐えます。

ラクナウ/アワディー語の影響を受けたヒンディー語：より格調高い音韻を持ち、「l」と「r」の明確な使い分けや、格式高い語彙が特徴です。全般的に良好に処理されます。

ボージュプリー語の影響を受けたヒンディー語（ビハール州、ウッタル・プラデーシュ州東部）：音韻体系が標準語と大きく異なります。シュワーの保持パターンが標準ヒンディー語と異なるため、認識精度は顕著に低下します。

南インドのヒンディー語（タミル語、テルグ語、カンナダ語の強いアクセント）：ドラヴィダ諸語からの音韻的転移が顕著です。そり舌音と歯音の区別などに影響が出ます。どのエンジンを使っても、最も手作業での修正が必要になるカテゴリです。

なお、ボージュプリー語、マガヒ語、マイティリー語、マールワーリー語、アワディー語などは、訛りではなく独立した言語です。これらをヒンディー語モデルで文字起こしすると著しく品質が劣化し、どの主要エンジンでもサポート対象外となっています。

敬語レベルとテキストへの影響

ヒンディー語には動詞の活用、代名詞、語彙に影響を与える敬称レベルが存在します。

• Aap（आप）：フォーマルな二人称。目上の人や初対面の人に対して使用
• Tum（तुम）：中間の丁寧さ。同僚や親しい仲間に対して使用
• Tu（तू）：極めて親密な表現。親友や子どもに対して使用（見知らぬ人に対しては侮蔑表現になる）

これらの違いは動詞周辺の表現（करते हैं、करते हो、करता/करती हैなど）に影響し、異なる文字起こしテキストを生成します。これらの区別を単一の形式に勝手に正規化してしまう文字起こしエンジンは、話者の社会的な関係性のニュアンスを損なっています。

実用面でも、改まった発話（ニュース、講義、演説）と砕けた発話（WhatsAppの音声メッセージ、カジュアルなポッドキャスト）では、ヒングリッシュの混入率が大きく異なります。前者は純粋なヒンディー語か完全な英文になりやすく、後者は最も濃厚なヒングリッシュになります。

ヒンディー語文字起こしの実用的なユースケース

インドのポッドキャストおよびYouTubeクリエイター： 最大の需要を占めています。インドのポッドキャスト市場は世界で最も急成長している分野の一つです。配信者はエピソード内、時には1つの文の中でヒンディー語と英語を行き来します。実際のリスナーが読む形式に合わせた、文字混在のヒングリッシュによる読みやすい概要欄やチャプターが必要です。

ヒンディー語ニュースルーム： 政治演説や討論番組を文字起こしし、ヒンディー語の記事にそのまま反映させるためデーヴァナーガリー文字の出力が求められます。討論番組には3〜6人の論者が参加するため、話者分離が不可欠です。

カスタマーサポートおよびコールセンター： ヒンディー語やヒングリッシュで行われる顧客対応を、CRMシステムに応じてラテン文字（またはデーヴァナーガリー）で記録し、担当者と顧客を区別するラベル付けを行います。コールセンター向けヒングリッシュに特化したモデルのファインチューニングなど、機械学習の活用が進んでいます。

法律および学術分野の文字起こし： 公的記録に残るため、マートラーや結合子音を正確に扱える高精度のデーヴァナーガリー文字出力が必須となります。

教育コンテンツ： 講義や研修動画では、教育機関や専門分野に応じて、純粋なヒンディー語からヒングリッシュまで幅広い音声が存在します。

独自パイプラインを構築せずに手軽に文字起こしを行いたい場合は、ConvertAudioToTextの音声テキスト変換ツールがヒンディー語のデーヴァナーガリー出力およびヒングリッシュの混在に対応しています。無料アカウントでは最初のファイルがプレミアムエンジン（最大1時間）で処理され、その後も毎日30ファイルまで、各ファイル30分まで無料で文字起こしでき、閲覧やコピーも無料なので、契約前に実際の音声を十分にテストできます。

ヒンディー語音声で本当に役立つ実践的なヒント

言語は必ず明示的に設定する。 ヒンディー語では自動検出に頼らないでください。音韻的にウルドゥー語と似ているため、一部の自動検出機能がウルドゥー語と誤認し、ヒンディー語読者には読めないナスタアリーク体で出力される危険性があります。

出力形式の用途に合わせてモードを選ぶ。 後続のシステムがデーヴァナーガリー文字のみを必要とする場合はlanguage=hiを使い、ヒングリッシュがすべてデーヴァナーガリーに音写される仕様を受け入れます。読みやすい混在出力を求める場合は多言語モードを選択してください。

インドの固有名詞にはカスタム語彙を活用する。 インドの人名には「Priya」と「Priyaa」、「Suresh」と「Suresh Kumar」など表記の揺れが多々あります。地名もローマ字表記と異なることが多いため、用語集の登録が精度向上に大きく貢献します。

背景ノイズは深刻な課題。 屋外市場、混雑したオフィス、街頭などで録音されたインドの音声はノイズが多くなりがちです。これはすべてのエンジンに共通する課題であり、エンジン選定以上に精度を左右する要因となります。

ボージュプリー語やマールワーリー語にヒンディー語モデルを使わない。 モデルは推測を試みますが失敗します。これらはまったく別の言語です。

ヒンディー語対応文字起こしツールの比較

Otterに関する注意点：月300分の無料プランは魅力的ですが、Otterはヒンディー語音声をラテン文字のみで文字起こしし、音声の言語にかかわらず要約を英語でしか生成しません。ヒンディー語圏の読者に向けてコンテンツを発信するインドのクリエイターにとっては、ワークフローの要求を満たせません。

基本料金以外の注意点（ユーザーごとのシート課金やエクスポート制限など）については、文字起こしサービスの隠れたコストで詳しく解説しています。

よくある質問

Whisperはヒングリッシュを混在スクリプトで文字起こしできますか？

デフォルトではできません。language=hiに設定すると、Whisperは英語の単語や借用語を含め、すべてをデーヴァナーガリー文字で文字起こしします。たとえば「meeting」は「मीटिंग」と出力されます。これを変更する標準APIフラグはありません。コミュニティによるファインチューニングモデル（Trelis ResearchのWhisper-Hinglish）にはコードスイッチモードがありますが、公式Whisper APIには含まれていません。

文字起こしの観点でヒンディー語とヒングリッシュの違いは何ですか？

ヒンディー語はデーヴァナーガリー文字で表記され、公の場ではサンスクリット由来の語彙を使う標準言語です。一方ヒングリッシュは、文中に英語の単語やフレーズが混ざる話し言葉であり、エンジンは単語ごとに出力する文字（スクリプト）を判定する必要があります。表記ルールが統一されていないため、媒体によって「meeting」を「मीटिंग」と書くことも「meeting」と書くこともあります。この曖昧さが、エンジンごとの文字起こし結果の大きな差につながっています。

AIエンジンは南インド訛りのヒンディー語に対応できますか？

対応可能ですが、デリーやムンバイのヒンディー語と比べて精度は下がります。ドラヴィダ諸語（タミル語、テルグ語、カンナダ語、マラヤーラム語）からヒンディー語への音韻的影響により、そり舌子音や母音の長さが多くのヒンディー語モデルの学習データ分布と異なるためです。どのエンジンを使う場合でも、この種の音声にはより綿密な見直しが必要になります。

ヒンディー語の音声で話者分離（ダイアライゼーション）は利用できますか？

はい。Deepgram Nova-3、AssemblyAI Universal-3、Google Cloud STTで利用可能です。特にAssemblyAIは2025〜2026年にヒンディー語の話者分離機能を強化しました。なお、これはヒンディー語に限らず全言語に共通しますが、発話の重複が多い複数人のパネルディスカッションよりも、2人によるフォーマルなインタビュー形式の方が一般的に高い分離精度が得られます。

ボージュプリー語やマールワーリー語の音声はどうやって文字起こしすればよいですか？

ボージュプリー語、マールワーリー語、マガヒ語、マイティリー語の音声に対してヒンディー語モデルを流用して高精度な結果を得ることはできません。これらは独自の音韻体系を持つ独立した言語です。2026年半ば時点でボージュプリー語をサポート対象としている主要商用エンジンはありません。文字起こしが必要な場合は、専門家による人手での作業が確実な方法です。ヒンディー語モデルを使うと、不完全で誤りの多い出力にしかなりません。

参考資料

• Deepgram Models and Languages Overview: https://developers.deepgram.com/docs/models-languages-overview
• Deepgram Multilingual Code-Switching documentation: https://developers.deepgram.com/docs/multilingual-code-switching
• Deepgram Nova-3 Multilingual blog post: https://deepgram.com/learn/nova-3-multilingual-major-wer-improvements-across-languages
• Deepgram Nova-3 Hindi-English GitHub discussion: https://github.com/orgs/deepgram/discussions/1208
• AssemblyAI Supported Languages documentation: https://www.assemblyai.com/docs/supported-languages
• AssemblyAI Universal-3 Pro announcement: https://www.assemblyai.com/blog/introducing-universal-3-pro
• Otter.ai pricing: https://otter.ai/pricing
• Sonix pricing: https://sonix.ai/pricing
• ConvertAudioToText pricing: https://convertaudiototext.com/pricing
• Whisper Hindi script discussion: https://github.com/openai/whisper/discussions/1662
• Whisper Hinglish finetuned model: https://trelis.substack.com/p/whisper-hinglish
• Hinglish prevalence data: https://www.gan.studio/blog/posts/the-prevalence-of-hinglish-in-urban-india-a-data-driven-exploration
• OriserveAI Whisper-Hindi2Hinglish: https://github.com/OriserveAI/Whisper-Hindi2Hinglish