AIは1つの文書で複数の言語を読める？
はい、その実力を解説

AIが複数言語を読み取る精度：スクリプトファミリー別の実力

多言語AI抽出を評価する際、最もよくある誤解は「100以上の言語に対応」という数字を単一の精度として捉えることです。実際はそうではありません。精度は明確なスクリプトファミリーの階層に従います。あなたの文書がその階層のどこに位置するかを理解することが、ワークフローが機能するかどうかの分かれ目です。

ラテン文字系の言語（英語、フランス語、ドイツ語、スペイン語、ポルトガル語、イタリア語、オランダ語など多数）は、26文字のアルファベット、左から右への読み方向、共通のタイポグラフィの伝統を共有しています。単一のOCRパイプラインで全てを処理できます。最新のビジョンモデルは、きれいな印刷物のラテン文字文書に対して、言語に関係なく95%以上の精度を達成します。フランス語かドイツ語かをモデルが認識する必要はありません。視覚的なパターンが十分に類似しているからです。

キリル文字（ロシア語、ウクライナ語、ブルガリア語、セルビア語）は第二の文字セットを追加しますが、読み方向とテキストレイアウトの規則はラテン文字と共通です。精度の低下はわずかで、きれいな文書で約90～93%です。構造的な類似性により、トレーニングデータがうまく転用できるためです。多言語コーパスでトレーニングされたほとんどのビジョンモデルは、キリル文字でもラテン文字に近いレベルを達成します。

そして、本当の課題が始まります。アラビア文字とCJK（中国語、日本語、韓国語）のスクリプトは、単なる異なる文字参照テーブルではなく、根本的に異なる認識モデルを必要とします。それぞれが難しい理由は以下の通りです。

これらは特殊なケースではありません。一枚の請求書に、英語の会社ヘッダー、日本語の住所ブロック、韓国語の商品説明、アラビア数字が含まれることがあります。一つのスクリプトファミリーしか処理できないモデルは、それ以外の全てで失敗します。CC-OCRベンチマーク（arXiv 2412.02210）は、日本語、韓国語、アラビア語、および6つのラテン文字言語を含む10言語でモデルをテストし、最高の汎用モデルであるGemini-1.5-Proでも多言語OCRの総合スコアは78.97であり、日本語はテストセットに縦書きテキストが多く含まれていたため、全ての汎用モデルの中で最も低いパフォーマンスの言語でした。

実用的な意味合い：文書がラテン文字系の言語のみを使用している場合、どの有能なAI抽出ツールでも実用レベルの精度が期待できます。アラビア文字やCJKが含まれる場合は、ベンダーのデモではなく実際の文書でテストし、検証のための時間を確保する必要があります。

多言語AI抽出の強み

多言語文書におけるAIと従来のOCRの差は、単なる性能差ではなく構造的なものだ。従来のOCRは「1文書＝1言語」を前提に設計されている。Tesseractに英語、日本語、アラビア語を設定し、文書を読み込ませて結果を待つ。複数言語が混在するページは想定外だ。

視覚言語モデルにはこの制限がない。文字を個別に切り出して言語別の辞書と照合するのではなく、ページ全体（レイアウト、テキスト、文脈）を読み取り、多言語を扱える人間と同じように、言語に関係なく内容を理解する。これにより、以下のシナリオで信頼性の高い処理が可能になっている。

ラテン文字のみの多言語文書。ドイツ語・フランス語・イタリア語が混在するスイスの請求書、英語とフランス語のカナダの納品書、スペイン語のベンダー情報とポルトガル語の配送指示が混在する汎ヨーロッパの注文書。これらの言語は文字セットと読み方向が共通しているため、AIは1回の処理で精度を落とさずに処理でき、単一言語のラテン文字抽出と同等の95%以上の精度を維持する。

読み方向が同じ一般的な2言語の組み合わせ。英語/韓国語、英語/日本語、英語/中国語の文書で、非ラテン文字部分が補足的な場合——英語の会社名の横に韓国語の住所、英語のSKUの下に日本語の商品説明。AIは得意とするラテン文字を基点に、CJKやアラビア文字を追加の認識対象として処理する。フィールドラベルが意味的な手がかりとなる構造化フォーム（列ヘッダー「Description」があれば、その下の内容が言語に関係なく商品説明だとわかる）では、非ラテン文字部分の精度は80～90%程度になる。

構造化された多言語フォーム。最も高い性能を発揮するのは、ラベル付きフィールド、一貫したレイアウト、区切られたテキスト領域を持つ明確な構造の文書だ。フィールドごとに言語ブロックが分かれたEUの税関申告書、仕入先名・金額・税額が空間的に分離された韓国の電子税計算書（전자세금계산서）。AIは各フィールドを独立して読み取り、フィールドラベルを意味的な手がかりとして値を特定する。これは単一言語の文書でも機能するカスタム列抽出の仕組みと同じで、抽出したい列（例：「仕入先名」「合計金額」「税率」）を定義すれば、AIは画面上の位置ではなく意味を理解して各値を特定する。

大語彙の視覚モデル。GPT-4oは新しいトークナイザーを導入し、非英語言語の処理を大幅に改善した。従来モデルと比較して、グジャラート語で4.4倍、テルグ語で3.5倍、タミル語で3.3倍少ないトークンで処理できる。英語の2～8倍のトークンを消費するCJK言語では、この差は極めて重要だ。トークンが少なければ、より多くの文書をモデルのコンテキストウィンドウに収められ、情報損失が減る。Google Document AIは200以上の言語（うち50言語は手書き対応）、Azure AI Document Intelligenceは100以上の言語（CJK、アラビア語、デーヴァナーガリー文字を明示的にサポート）をカバーしている。

多言語AI抽出が依然として苦手とする領域

正直な答えは、マーケティング用の答えよりも重要です。多言語対応を過剰に約束することは、誰かが初めて韓国語/英語の請求書をアップロードし、ハングルの半分が誤読されているのを見た瞬間に信頼を失う最短の道だからです。

同一ページ内での右横書きと左横書きの混在。英語の条項参照を含むアラビア語の法的契約書。フランス語の配送条件が記載されたヘブライ語の梱包明細書。AIは文字体系の境界を検出し、各セグメントに正しい読み方向を適用し、それらを単一の出力に統合する必要があります。LTRテキスト用に構築された標準的なOCRパイプラインは、意味的に破綻した出力を生成します。アラビア語のテキストが逆方向にレンダリングされ、改行位置が誤り、両方の文字体系の文字が混ざり合って無意味になります。Visionモデルは、方向をテキストストリームのプロパティではなくレイアウトプロパティとして扱うことで、この問題をより適切に処理しますが、真に方向が混在するドキュメントの精度は依然として65～80%に低下します。

縦書きCJKテキスト。日本語の文書では、横書きと縦書きが頻繁に混在します。本文は上から下へ流れ、英語の注釈や数字は左から右へ流れます。中国語や韓国語は現代のビジネス文書では縦書きの使用は一般的ではありませんが、伝統的な形式、証明書、正式な書簡では残っています。CC-OCRベンチマークは、縦書き日本語テキストが、すべての汎用モデルにおいて最大の精度低下要因であると特定しました。横書き日本語で90%近い精度を達成するモデルでも、同じテキストが縦書きになると60～70%に低下します。これは、モデルのレイアウト理解が主に横書き文書で訓練されているためです。

稀な言語の組み合わせ。英語/スペイン語や英語/日本語は、訓練データに頻繁に出現するため、十分にカバーされています。同一ページ内のタイ語/アラビア語は？スワヒリ語/キリル文字は？ベトナム語/ヘブライ語は？これらの組み合わせは、訓練コーパスにおいて著しく過小評価されています。モデルは個々の文字体系を認識できても、それらの相互作用を解析するのに苦労する場合があります。特に、異なる書き方向を使用する場合や、一方の文字体系に他方の文字と視覚的に類似した文字が含まれている場合です。

手書きと印刷が混在した多言語文書。英語の手書き注釈が入った印刷された日本語のフォーム。ハングルと英語が混在した手書き修正が入った韓国語の請求書。手書きだけでも、印刷テキストと比較してAIの精度は15～30%低下します（AI手書き文字認識の精度に関するガイドを参照）。その上に第二言語が加わると、特に手書き部分が文字体系間で切り替わる場合、エラーが複合します。モデルは手書きの曖昧さと文字体系の境界を同時に解決する必要がありますが、現在のアーキテクチャはこれらを逐次的に処理し、統合的には処理しません。

CJKにおける文字密度。日本語の一文には、3つの文字体系（漢字、ひらがな、カタカナ）に加え、英語の外来語のためのラテン文字や金額のためのアラビア数字が、すべて一行に含まれることがあります。これらのいずれかに設定された従来のOCRエンジンは、他のものを黙って見落とします。Visionモデルは、日本語の複数文字体系の性質を構造的特性として正しく処理しますが、情報密度がトークン化のオーバーヘッドを生み出します。同じ意味内容を日本語で表現すると、英語の約2倍のトークンを消費するため、長い文書ではモデルがより早くコンテキストウィンドウの制限に達します。

多言語AI抽出で最高の結果を得る方法

最も重要な変数は、AIにデータを抽出させる方法です。これは多言語ドキュメントにおいて、他のどのドキュメントタイプよりも重要です。生のOCR全文文字起こしではなく、セマンティック抽出を使うことが、使える多言語データと多言語の混乱を分ける決定的な違いです。

1. 全ページOCRではなく、カスタム列抽出を使う。 AIに「このページのすべてを読み取って」と依頼しないでください。抽出したいフィールドを正確に指定しましょう — 「仕入先名」「請求書日付」「合計金額」「税ID」。出力列を定義すると、AIはそれらの特定の値を意味的に理解して探すことに集中するため、言語に関係なく抽出できます。ハングルで書かれた韓国の仕入先名（例：「한국전자」）も英語のものと同様に見つけられます — AIは「仕入先名」フィールドが企業名を含むことを認識します。一方、生のOCRはエンジンが設定された言語のテキストストリームを出力し、それ以外はすべて落とします。この列ベースのアプローチがドキュメントタイプ全体でどのように機能するかの詳細は、AIドキュメント抽出とは何か、その仕組みをご覧ください。

2. 写真の品質を高く保つ。 多言語ドキュメントは、画像品質の問題をすべて増幅します。インクと用紙のコントラストが低い、斜めからの撮影、低解像度は、英語よりも非ラテン文字で精度をより深刻に低下させます。なぜなら、CJK文字は細かいストロークの区別（例：中国語の「已」vs「己」vs「巳」、日本語カタカナの「ツ」vs「シ」）に依存しており、画質の悪い画像では認識できない形にぼやけてしまうからです。真正面から撮影し、均一な照明を使用し、少なくとも200 DPIを維持してください。すべての文字に理想的なのは、白い紙に濃いインクです。

3. 可能であれば、ドキュメントを主要言語ごとに分ける。 50枚の請求書（英語30枚、韓国語20枚）のバッチがある場合、一緒に処理することもできますが、言語グループごとに別々のバッチで処理することで、言語グループごとに精度を検証できます。これはAIのパフォーマンスを直接向上させるわけではありませんが、検証ワークフローを管理しやすくします。英語のバッチは10%を素早くスポットチェックし、エラーが発生しやすい韓国語のバッチにレビュー時間を集中できます。

4. 複数スクリプトが混在する重要なフィールドには、フィールドレベルの検証を使用する。 通貨金額、税ID、日付は、抽出エラーが金銭的な影響を与えるフィールドです。多言語ドキュメントでは、これらのフィールドは周囲の言語に関係なくアラビア数字で表示されることが多く、これは役立ちますが、それでもクロスチェックが最も安価な保険です。ドキュメントごとに最も重要な5つのフィールドを30秒レビューする方が、間違った税IDに支払いを送ってしまう修正よりもはるかに速いです。

5. ドキュメントの構造をアンカーとして活用する。 ラベル付きフィールドを持つ構造化フォームは、多言語AI抽出に最も適したケースです。多言語ドキュメントのほとんどがフォーム（請求書、税関申告書、税務書類）である場合、フィールドラベルはセマンティックアンカーを提供し、言語間の精度を劇的に向上させます。AIは韓国の税務請求書にある「Total (합계)」を読み取り、フィールドラベルが韓国語で、値に英語の通貨コードが含まれている場合でも、金額値を抽出することを認識します。ドキュメントの構造が多ければ多いほど、言語の重要性は低くなります。

AIが複数言語を読み取る実際の文書例

これらは仮説ではありません。実際の現場で言語の壁を越える文書であり、AIはそれぞれに異なる方法で対応します。

韓国の電子税額計算書（전자세금계산서）。 韓国が2023年に電子税額計算書を義務化して以来、すべての取引で構造化されたデジタル文書が生成されますが、データは会計システムに移行する必要があります。一般的な韓国税額計算書には、韓国語の供給者名と住所（ハングル）、韓国語の購入者名（ハングル）、韓国語の品目説明と時折含まれる英語の製品コード、アラビア数字と韓国ウォン（₩）通貨表記の金額が含まれます。AIは名前と住所のハングルフィールド、品目説明の混合コンテンツ、金額の数値フィールドをすべて1回の抽出パスで読み取ります。韓国語未学習のモデルがつまずく主要フィールドは、事業者登録番号（사업자등록번호）です。これは特定の形式に従い、請求書上の固有の位置に印刷されることが多い10桁の識別子です。この文書タイプの詳細は、韓国税額計算書データのExcel抽出ガイドをご覧ください。

EUの多言語通関・コンプライアンスフォーム。 EUの輸入申告書には通常、同じデータが2～3言語で繰り返し記載されています。例えば、荷送人名はフランス語、荷受人名はドイツ語、商品説明は英語です。1ページでラテン文字系言語が4～5回切り替わることもあります。これはAIにとって最も簡単な多言語シナリオです。なぜなら、すべての言語が同じ文字体系を共有しているからです。AIはフランス語、ドイツ語、英語のセクションを同一に処理し、精度は95%以上を維持します。言語の切り替えはモデルにとって透過的です。毎日何百ものこれらのフォームを処理する国際物流チームは、言語で仕分けすることなく一括処理できます。AIが言語混合をネイティブに処理します。全体像については、市場をまたぐ国際請求書データ抽出をご覧ください。

日本語/英語の輸送書類。 日本の輸出パッキングリストには、製品名が日本語（漢字＋カタカナ）、数量と重量がアラビア数字、送付先住所が英語で記載されています。日本語テキストには、製品名の漢字（自動車部品）、英語由来の用語のカタカナ（ブラケット）、型番のラテン文字（ABC-1234）の3つの文字体系がすべて含まれます。AIは同じ行にある4つの文字体系すべてを読み取り、抽出した値を正しい列に配置します。最大のリスクはカタカナと英語の混同です。「テーブル」のようなカタカナで音訳された単語は、単純なOCRエンジンでは英語テキストと誤認される可能性がありますが、日本語の表記規則を理解するビジョンモデルは正しく区別します。

中国語/英語のバイリンガル契約書。 中国語圏と英語圏の事業者間の国際契約書では、各条項が両言語で提示されることがよくあります。中国語テキストは英語翻訳の上または下に配置されます。レイアウトは横並びの列または積み重ねられた段落の場合があります。データ抽出（例：契約日、当事者名、支払条件の取得）において、AIは冗長性の恩恵を受けます。どちらかの言語バージョンから同じデータを読み取ることができ、二重表現により、一方の言語で欠落または曖昧なデータを他方で相互参照できるため、実際に精度が向上します。実用的なワークフローとしては、英語版を一次情報源（高精度）として抽出し、重要な財務フィールドの検証に中国語版を使用します。

よくある質問

3言語以上が混在した文書からAIはデータを抽出できますか？

はい、ただし条件があります。すべての言語が同じ文字体系（例：フランス語・ドイツ語・英語＝すべてラテン文字）であれば、AIは精度を落とさず透過的に処理します。文字体系が異なる場合（例：英語＋韓国語＋アラビア語が1ページに混在）、精度は最も低い文字体系に依存します。英語80％・アラビア語20％の文書では、英語部分はラテン文字レベルの精度、アラビア語部分はアラビア文字レベルの精度（約75～85％）になります。AIは難しい部分があるからといって簡単な部分の精度を下げることはなく、各テキスト領域は独立して処理されます。

AIは事前に文書内の言語を知っておく必要がありますか？

いいえ。最新のビジョンモデルはページを読み取る過程で自動的に言語を検出します。「英語＋韓国語」を事前選択したり、言語モジュールを設定する必要はありません。これは従来のOCRに対するビジョン言語モデルの最大の利点の一つです。Tesseractでは処理前に言語を指定する必要があり（誤った指定で間違えることもある）ますが、VLMはページを読み取り、各テキスト領域がどの文字体系を使用しているかをその場で認識します。モデルの言語検出は視覚的理解に組み込まれており、別のステップとして後付けされているわけではありません。

アラビア語のような右横書き言語と英語が混在した文書は、AIはどのように処理しますか？

処理は可能ですが、これが最も難しい多言語シナリオです。AIは同一ページ上で文字体系A（左横書き、例：英語）と文字体系B（右横書き、例：アラビア語）を検出し、各セグメントに正しい読み方向を適用し、それらの意味的関係を維持する必要があります。真に混在した方向のページでは精度は65～80％に低下します。RTLコンテンツが空間的に分離されたブロック（例：英語の表の上にあるアラビア語のヘッダー）にある文書では精度は高くなります。RTLとLTRのテキストが同じ文や段落内で混在している場合（英語の製品説明にアラビア語の部品番号が散在するなど）は、結果を手動で確認する必要があります。

AIは手書きの日本語・中国語・韓国語を読めますか？

部分的に可能です。手書き認識の精度に関する枠組みはラテン文字とCJKスクリプトで共通ですが、CJK文字は筆順と正確な画の配置に依存するため、手書きのばらつきがラテン文字よりも深刻に影響します。例えば「口」という文字（3画の単純な四角形）は、書き手によって丸、楕円、または崩れた四角形に見えます。手書きの日本語は韓国語（ハングルはより体系的でユニークな形状が少ない）よりも難しく、両方とも手書きの英語より困難です。印刷されたCJKから手書きCJKへの精度は20～35%低下すると予想されます。手書き認識の課題の詳細については、AI手書き認識の完全ガイドをご覧ください。

言語ごとに異なるAIツールが必要ですか？

いいえ — ビジョン言語モデルベースの抽出ツールを使用している場合、同じモデルが英語の請求書も韓国の税務請求書もドイツの注文書も読み取ります。これがビジョン言語アプローチの実用的な利点の1つです。ドキュメントに含まれる言語の数に関係なく、1つのツール、1つのワークフロー、1つの出力形式で管理できます。ただし、検証作業には注意が必要です。非ラテン文字のドキュメントでは、英語のものよりも結果の確認に時間がかかります。しかし、別のツール、別のログイン、別のワークフローは必要ありません。

ビルマ語、アムハラ語、ラオ語など、デジタルリソースが非常に少ない言語はどうですか？

これらの低リソース言語では、精度が最も低下します。主要な世界言語とリソース不足のスクリプトとの間の性能差は、主要言語間の差よりも大きくなります。韓国語を85%の精度で処理できるモデルでも、ビルマ語では50～60%になる可能性があります。これはトレーニングデータの量が桁違いに少ないためです。GoogleのDocument AIは、希少言語のカバレッジ（200以上の言語）で最も強力な選択肢ですが、真に低リソースの言語については、ワークフローを確定する前に実際のドキュメントでテストすることをお勧めします。ベンダーの言語サポートに関する主張は、トップ50以外のスクリプトでは、実運用に耐える精度に結びつかないことがほとんどです。

AIは、文中で言語が切り替わる文書を処理できますか？

これはコードスイッチングと呼ばれ、多言語地域のビジネス文書では一般的です。例えば、香港の請求書に「Delivery to 中環辦公室 by 3pm.」と記載されている場合などです。最新のビジョンモデルは、ラテン文字系の言語内では問題なく、ラテン文字とCJK（中国語、日本語、韓国語）の混合でもある程度対応できます。モデルは文の途中で言語モジュールを切り替える必要はなく、文字列全体を連続した視覚入力として読み取り、各文字や単語をそれぞれの表記体系で認識します。文中のコードスイッチングの精度は、段落全体が混在するテキストよりも高いです。これは、コンテキストウィンドウが小さく、トークンレベルで文字の形状や文字セットの所属といったシグナルが明確だからです。

AI文書抽出の可能性と限界をより広く理解するには、AI文書抽出とは何か、その仕組みから始めてください。特に複数言語の手書き文字を扱う場合は、AI手書き文字認識の精度に関するガイドで、これら2つの難しい問題の接点を解説しています。また、テンプレートの設定やトレーニングなしでデータを抽出する必要がある場合（同じ形式が2つとない多言語文書では特に重要です）は、AIがテンプレートなしでデータを抽出できるかをご覧ください。