多言語抽出の精度が低下する理由とは？
3つのシナリオと具体的な対策

パターンはいつも同じだ。英語の文書でテストすると魔法のような結果が得られ、実際の文書——3カ国のサプライヤーからの請求書、2種類の文字が混在する住所の配送ラベル、途中で言語が切り替わる契約書——に切り替えると、精度が落ちる。壊滅的ではないが、このツールは本当に機能しているのかと疑い始めるには十分な低下だ。

機能している。問題は、何をさせようとしているかだ。英語の請求書1枚は均一な入力だ。1言語、1文字体系、1つの読み方向。フランス語の明細項目とスペイン語の支払条件が混ざったドイツ語の請求書は、同じ種類の問題ではない——そして精度はそれを反映する。 直面している3つの異なるシナリオのうちどれかを理解することが、何を修正すべきかを知ることと、間違ったものを責めることの違いを生む。

このガイドでは、精度低下が起こる最も一般的な3つのシナリオ、自分の文書でどれが起きているかを見分ける方法、そしてそれぞれへの対処法を解説する。アーキテクチャレベルでビジョンAIが複数言語を処理する方法の概要については、AIは1つの文書内の複数言語を読み取れるかを参照のこと——本稿はその背景を前提とし、トラブルシューティング面に焦点を当てる。

シナリオ1：1文書内の複数言語

これが精度低下の最も一般的な原因であり、ユーザーが通常、自分が直面していることに気づかないパターンだ。 文書は「ドイツ語」だが——ヘッダーは英語（会社名と住所）、明細項目はドイツ語の製品説明とフランス語の原材料名が混在し、フッターには法務チームが前四半期に選んだ言語の法的定型文が記載されている。

ほとんどのAIビジョンモデルは、ページ全体を単一の視覚的コンテキストとして処理する。従来のOCRのように「言語を切り替える」のではなく、すべてを一度に読み取り、同じ推論パスの中で各文字の書記体系を判別する。これは、事前に選択された言語パックを必要とするOCRエンジンに対する利点だが、微妙な問題を生み出す。異なる言語のテキストが同じ視野内に現れると、モデルは文字境界、特殊文字（é, ü, ñ, ß）、および文脈に依存する字形を同時に解決する必要があるため、文字の信頼度が低下する。

実際の複数言語の請求書1枚で何が起きるかは以下の通りだ：

• 英語のヘッダー（会社名、住所）——精度96%。モデルが最も強い領域。
• ドイツ語の本文（ウムラウト付きの品目説明、"€"通貨記号、ドイツ語の日付形式）——精度88～91%。ウムラウト（ä, ö, ü）が欠落または置換される。「14.03.2026」が英語の「03/14/2026」と混同される。
• フランス語の明細項目（アクセント付き文字：é, è, ê, œ）——精度85～88%。混合グリフ行のアクセントで誤差が蓄積。「générique」が「generique」や「g6n6rique」になる。
• スペイン語の支払条件（ñと逆感嘆符）——精度82～87%。フッターに到達するまでに、モデルはドイツ語とフランス語のセクションで文字解像度の予算を使い果たしている。

これらは最悪のケースの数値ではない。同じアルファベットを共有しながらも、特殊文字、日付形式、通貨表記が異なる3つのラテン文字言語間で切り替わる文書では、これが典型的な数値だ。

診断： 同じ文書内でフィールドごとの精度が異なる場合——日付がベンダー名より信頼できる、数字は正確だがアクセント付き文字が壊れている——おそらくシナリオ1に該当する。

解決策: 全ページOCRではなくカスタム列抽出を使用します。「仕入先名」「請求日」「合計金額」などの出力列を具体的に定義すると、AIはページ上のすべての文字を均等に処理しようとするのではなく、意味に基づいてそれらの値を探すことに集中します。「合計金額 (EUR)」という列があれば、周囲のテキストがドイツ語、フランス語、スペイン語のいずれであっても、通貨記号の近くにある数値を探すようにモデルに指示できます。文書タイプを問わない列ベースの抽出の詳細については、AI文書抽出の仕組みと列定義の重要性をご覧ください。

シナリオ2: 文字体系の違い — ラテン文字 vs. CJK vs. アラビア文字

ここで精度の低下は「厄介」から「ワークフローを破壊する」レベルに変わります。 英語の請求書は96%で抽出されるのに、日本語の請求書は82%でしか抽出されません。これは日本語の文書の品質が低いからではなく、文字体系の違いがビジョンモデルにとって根本的に異なる課題となるからです。

ラテン文字（英語、フランス語、ドイツ語、スペイン語、ポルトガル語、イタリア語、オランダ語）は、26文字のアルファベット、左から右への読み方向、豊富なトレーニングデータを共有しています。これらは現代のビジョンAIにとって解決済みの問題であり、清潔な印刷ラテン文字の精度は一貫して95～99%に達します。

CJK文字（中国語、日本語、韓国語）は、難易度が異なります。日本語の1つの文には、漢字（数千の中国起源の文字）、ひらがな（46の音節文字）、カタカナ（46の音節文字、外来語用）、英語用のラテン文字、アラビア数字がすべて1行に含まれる可能性があります。同じ意味内容の日本語は、英語の約2倍のトークンを消費するため、CJK文書ではモデルのコンテキストウィンドウがより早く満たされ、フィールドごとに利用可能な情報が少なくなります。この密度の問題の実例については、日本語のレシートデータをExcelに抽出するに関する記事をご覧ください。

アラビア語とヘブライ語は、右から左への方向という課題を追加します。モデルは読み方向が逆になることを検出し、テキストブロックごとに正しく適用し、アラビア語の4位置文字形式（単語の先頭、中間、末尾、独立のいずれに現れるかで文字の形が変わる）を処理する必要があります。印刷されたアラビア語文書の精度は75～85%の範囲です。これはモデルがアラビア文字自体に弱いからではなく、RTLの組版規則が左から右への文字とは異なる視覚的解析問題を生み出すためです。

診断: 英語の文書が95%以上で抽出され、非ラテン文字の文書が一貫して10～20%低い場合（特定の文書だけでなく、複数の文書にわたって）、シナリオ2に該当します。

修正方法：ここでは2つのアプローチが有効です。まず、処理対象のスクリプトに対するツールの言語サポートを確認することです。「100以上の言語に対応」と謳うツールでも、すべてのスクリプトが均等に学習されているとは限りません。一部のビジョンモデルはラテン文字データに偏って学習され、CJKやアラビア語は小規模な二次コーパスとして追加されているにすぎません。必要なスクリプトファミリーがモデルの学習データに含まれているか、具体的に問い合わせてください。次に、ツールのデモ画像ではなく、実際の書類の代表サンプルでテストすることです。ベンダーのデモ用日本語請求書は、デジタル生成でコントラストが完璧なクリーンな画像です。一方、2019年のスキャンした日本語請求書で、仕入先名の上に薄れた印鑑が重なっている場合、認識課題はまったく異なります。

シナリオ3：同一フィールド内の混在スクリプト

これが最も困難なケースであり、ほとんどのドキュメントが触れていない点です。書類上の単一フィールドに、複数のスクリプトの文字が含まれています。品番「ABC-1234-안전밸브」（英字、アラビア数字、韓国語ハングル）。仕入先名フィールド「株式会社Yamada (Osaka Branch)」。日付フィールド「2026年03月14日」— CJKテキストに埋め込まれたアラビア数字。

ビジョンモデルは、各文字クラスターを独立して認識し、それらを結合して一貫した文字列にすることで混在スクリプトフィールドを処理します。しかし、このプロセスでは混在スクリプトシナリオに固有のいくつかの障害モードが発生します。

• スクリプト境界の誤検出：モデルが、あるスクリプトの終わりと別のスクリプトの始まりを誤って判断します。CJK表意文字に視覚的に類似した韓国語ハングル文字が誤ったスクリプトグループに分類され、後続の文字が間違った認識コンテキストで解析される可能性があります。
• 文字の置換：スクリプト間で似た文字が入れ替わります。ラテン文字の「A」、キリル文字の「А」、ギリシャ文字の「Α」は視覚的にほぼ同一ですが、異なるUnicode文字です。ラテン文字の「A」を含む製品コードがキリル文字の「А」として出力される可能性があります—視覚的に同一で、意味的には誤りであり、正しく見えるためスポットチェックでは検出できません。
• LTR/RTL混在フィールドでの方向性の混乱：アラビア語の会社名の後に括弧付きの英語の登録番号が続くと、モデルが正しく順序付けする必要がある双方向文字列が生成されます。「شركة (ABC-1234)」の代わりに「(ABC-1234 شركة」のような出力が一般的です—両方の文字は存在しますが、読み取り順序が逆になっています。

診断方法：抽出されたデータが視覚的にはもっともらしく見えるが、既知の参照と照合すると失敗する場合—適切な文字がすべて含まれているように見えるがERPと一致しない品番、または人間が見ると問題ないが検索に失敗する仕入先名—シナリオ3が原因である可能性が高いです。

修正方法：言語ヒントによる前処理により、混在スクリプトのエラーを大幅に削減できます。ほとんどのビジョンモデルは言語を自動検出しますが、抽出コンテキストを明示的に固定することで効果があります。対応しているツールでは、「このドキュメントの主要言語は韓国語で、英語の製品コードが埋め込まれている」といったヒントを渡すことで、モデルがスクリプト境界を認識エラーとして扱うのではなく、期待するようになります。税ID、品番、登録コードなど精度が重要なフィールドでは、言語別のスポットチェック検証が最も信頼性の高い防御策です。データを抽出した後、非ラテン文字部分とラテン文字部分を別々に検証します。参照データベース（ERP、CRM、仕入先リスト）がある場合は、抽出値をクロスリファレンスすることで、どんな目視検査でも見つけられない文字置換エラーを発見できます。

自分がどのシナリオに該当するか診断する方法

多言語ドキュメントで精度低下に気づいたら、何かを変更する前に、この3つの質問で診断してください。

1. 精度低下は、同じドキュメント内で言語を問わず一貫して発生していますか？ 英語のフィールドは常に正確で、同じドキュメント内のフランス語/ウムラウトフィールドだけが一貫して劣化している場合 → シナリオ1。セマンティックフィールド定義を用いた列ベースの抽出を試してください。
2. 精度低下は、言語ファミリーごとにドキュメント全体で一貫していますか？ 内容に関係なく、すべての日本語ドキュメントがすべての英語ドキュメントよりも抽出精度が低い場合 → シナリオ2。ツールのトレーニングデータが特定の文字体系をカバーしているか確認してください。
3. 精度低下は、混合スクリプトを含む特定のフィールドに限定されていますか？ 仕入先名は問題ないが、漢字やアラビア文字が埋め込まれた品番でエラーが多い場合 → シナリオ3。前処理で言語ヒントを追加し、フィールドごとの相互参照を実装してください。

これら3つのシナリオは重複することがよくあります。同じページ内に、複数の言語（シナリオ1）が異なる文字体系（シナリオ2）で存在し、混合スクリプトフィールド（シナリオ3）が含まれる可能性があります。診断質問は、どのレイヤーを最初に修正すべきかを示します。間違ったレイヤーを修正すると時間の無駄になるからです。 シナリオ2に該当する場合、列の改良（シナリオ1の対策）をいくら行っても精度ギャップは回復しません。より良いプロンプトではなく、モデルに異なるトレーニングデータのカバレッジが必要なのです。

予防：多言語精度低下を減らす3つの習慣

自分のシナリオを特定したら、以下の習慣を実践することで、新しいドキュメントタイプや言語で同じ問題が再発するのを防げます。

1. 可能な限り、ドキュメントをスクリプトファミリーごとに分ける。 毎日200件の請求書を処理していて、そのうち150件がラテン文字言語、50件がCJK（中国語・日本語・韓国語）だとします。これらを別々にバッチ処理すれば、2つの独立した精度ベースラインが得られます。ラテン文字の抽出精度は95%以上、CJKは82%とわかります。CJKバッチの精度が突然70%に低下したら、すぐに気づけます。しかし、1つのバッチに混在させていると、全体の平均が93%から90%に下がった程度で、誰も問題視しないでしょう。

2. 言語ごとの検証サンプルを維持する。 処理する言語ファミリーごとに、代表的なドキュメントを5～10件選びます。抽出ワークフローを更新したりツールを切り替えたりするたびに、この検証セットを実行し、言語ごとの精度を比較します。これにより、本番環境に影響が出る前に性能低下を発見できます。ラテン文字の精度を2%向上させたが、CJKの精度を8%低下させるツールは、多言語ワークフローにとっては純粋な改善とは言えません。

3. 言語によって異なるフィールドレベルの信頼度しきい値を使用する。 同じドキュメント内の英語フィールドとアラビア語フィールドに、同じ「信頼度が90%以上なら受け入れる」というルールを適用してはいけません。英語に90%のしきい値を設定すると厳しすぎる（すべてが通過する）一方で、同じしきい値をアラビア語に適用するとすべての抽出が拒否される可能性があります。検証サンプルの結果に基づいて、言語ごとのしきい値を設定してください（例：アラビア語75%、ラテン文字90%、CJK 80%）。しきい値を下回ったものは、黙って受け入れるのではなく、手動レビューに回すようにします。

エスカレーションの判断基準 — 手動対応が必要なケース

このセクションの内容は、本記事で最も正直に書かれています。Vision AIは多言語対応に優れていますが、プロンプト調整や前処理をいくら施しても、実運用レベルの精度に達しない境界条件が存在します。

• 異なる文字体系にわたる4言語以上の文書。英語（ラテン文字）、アラビア語（右横書き）、日本語（CJK縦書き＋横書き）、韓国語（CJK横書き）が同一ページに混在する文書は、現在のビジョンモデルの能力の限界に近いものです。単一言語のベースラインと比較して5～15％の精度低下が見込まれます。
• 同一文または表セル内での右横書き／左横書きの混在。契約条項などでアラビア語と英語が同一行に出現し、括弧で関係性が示される場合（例：「البند (Item) 4.2」）、双方向解析により構造エラーが発生し、前処理のヒントでは部分的にしか修正できません。
• 非ラテン文字による手書きコンテンツ。手書きのみで活字と比較して15～30％の精度低下が生じます。そこに第二言語が加わり、例えば日本語の手書きの中にアラビア数字の手書きが混在すると、その複合効果により、ほとんどの抽出結果が実用可能な閾値を下回ります。このような文書では、印刷部分のAI抽出は依然として有効ですが、手書きフィールドは例外ではなくデフォルトのワークフローとして手動入力に振り分けるべきです。
• 低リソース言語の組み合わせ。タイ語／アラビア語、スワヒリ語／キリル文字、ビルマ語／英語など、ビジョンモデルのトレーニングにおいて個々の言語が高リソースではない組み合わせです。これらの文書の精度下限は、英語／スペイン語や英語／中国語のようなカバレッジの高い組み合わせよりも低くなります。

実用的なワークフロー：AI抽出により多言語データの80～90％が自動処理されます。残りの10～20％ — 複数文字体系が混在する文書内の高リスクフィールド、右横書き／左横書き混在テキスト内の重要な数値フィールド、非ラテン文字の手書き入力 — は、完全な手動入力よりも迅速で、かつ最も困難なケースにおいてAIに依存するよりも信頼性の高い人間によるレビューステップに振り分けられます。

よくある質問

AI抽出ツールが英語の請求書では精度が高いのに、ドイツ語やフランス語では低下するのはなぜですか？

これは典型的なシナリオ1です。英語の文書は単一言語入力で、スクリプトの曖昧さがありません。一方、ドイツ語やフランス語の文書には特殊文字（ウムラウト、アクセント記号）が含まれることが多く、ビジョンモデルはこれらを標準ラテン文字のバリエーションとして扱います。これらのバリエーションは、アクセントのない文字に比べて学習データに出現する頻度が低いため、信頼度が低くなります。英語と他のラテン文字言語の間の精度差は通常5～8%で、顕著ではありますが、ページ全体のOCRではなく特定のフィールドにモデルを集中させる列ベースの抽出で修正可能です。

文書を事前に単一言語に変換することで、多言語抽出の精度を向上できますか？

信頼性は高くありません。抽出前の機械翻訳は、別のエラー層を導入します。翻訳されたテキストから抽出することになり、フィールドラベル、数値形式、文書構造が失われる可能性があります。元の文書には、作成者が意図したレイアウトとデータが含まれています。抽出は、翻訳版ではなく、オリジナルを読み取ることで最適に機能します。より良いアプローチは、セマンティックな列定義を使用して元の文書から抽出し、その後、ダウンストリームシステムで必要な言語に対して抽出データを検証することです。

AIは処理前に文書に含まれる言語を知る必要がありますか？

検出に関しては不要です。最新のビジョンモデルは、ページを読み取る過程でスクリプトと言語を自動的に検出します。ただし、コンテキストに関しては必要です。文書に珍しい言語の組み合わせや混在スクリプトのフィールドが含まれている場合、言語ヒント（例：「この文書には韓国語と英語が含まれ、アラビア数字が埋め込まれています」）を提供することで、モデルが認識リソースをより効率的に割り当てるため、二次言語部分の精度が3～7%向上します。

同じツールでラテン文字文書とCJK文書を処理した場合、精度にどの程度の差が出ますか？

同程度の品質の印刷文書であれば、同じツールでもCJKの精度はラテン文字より8～15％低くなると想定してください。これはツールの品質問題ではなく、文字数（26 vs 数千）、意味単位あたりのトークン消費量（2倍）、学習データ量の根本的な違いを反映したものです。英語で97％のスコアを出すツールが日本語で83％であれば、現在のビジョンAIの水準としては正常なパフォーマンスです。

言語ごとに異なるAI抽出ツールを使うべきですか？

文書が複数の文字体系ファミリーにまたがる場合（同じ文字体系内の複数言語ではなく）、特定の地域スクリプトに最適化されたツールを使うことで、言語ごとの精度を高められます。例えばPaddleOCRは、学習データがCJK中心であるため、汎用ビジョンモデルよりもCJK文書で優れた性能を発揮します。ただし、複数ツールの管理はワークフローの複雑さを招き、精度向上のメリットを上回る可能性があります。有効なアプローチの一つは、汎用ビジョンAIツールを全言語の一次抽出器として使い、一次ツールの信頼度が閾値を下回った場合のみ、特定スクリプトの文書を専門のフォールバックエンジンに振り分ける方法です。

単一ラテン文字文書と多言語文書の間の精度低下は、技術の失敗ではありません。それは予測可能で、診断可能で、大部分は修正可能なギャップです。診断の問いから始め、該当するシナリオに応じた修正を適用し、現在のビジョンモデルがまだ学習中のエッジケースには手動レビューを残してください。ご自身の多言語文書でテストし、どのシナリオが該当するか確認してください。