なぜ最先端のLLMは日本語ドキュメントの読み取りに失敗するのか（日本語の何が特殊なのか）

最先端の大規模言語モデル（LLM）が日本語ドキュメントの読み取りに失敗するのは、他のどの主要言語も一度には併せ持たない特徴を、日本語が同時に積み重ねているからです。1つの文の中に3種類の文字 — 漢字・ひらがな・カタカナ — がラテン文字やアラビア数字とともに混在し、単語間にスペースがなく、しばしば上から下への縦書き（たてがき）で書かれます。縦書きの日本語では、GPT-4.1やGPT-5のようなモデルの文字誤り率が、同じテキストを横書きにした場合と比べて約10倍に跳ね上がります。さらに、入れ子の表、ビジネスチャート（グラフ）、赤いハンコ、文字の脇に小さく振られた読み仮名といったビジネス文書の現実が加わると、精度はいっそう低下します。

日本語の有価証券報告書、不動産登記簿、あるいはスキャンした契約書を最先端のチャットボットに貼り付け、自信たっぷりに返ってきたテキストが微妙に — あるいは大きく — 間違っているのを目にしたことがあれば、この問題を肌で知っているはずです。これらのモデルは、学習データに近い見た目 — きれいで、横書きで、現代的 — の日本語なら流暢に読みます。しかし実際のドキュメントは、めったにそうは振る舞ってくれません。

日本語ドキュメントの何が特殊なのか

日本語は、現役で使われている書字体系の中でも最も正書法が複雑なものの一つです。1つの文が、しばしば3種類の文字を同時に混在させます。漢字（中国語から借用した表語文字。常用漢字2,136字を学校で学び、全体では数万字に及びます）に加えて、それぞれ46字の音節文字 — 固有語と文法を担うひらがな、外来語や強調に使うカタカナ — があります。さらにラテン文字（ローマ字）とアラビア数字が、これらと自由に並んで現れます。

• 3種類の文字が混在 — 漢字・ひらがな・カタカナが、しばしば1語の中で、視覚的な区切りなしに混ざります。
• 単語間にスペースがない。日本語は単語の境界に関係なく行を折り返し、読み手がどこで語が切れるかを推測します。
• 2つの書字方向。現代の文書は横書き（よこがき、左から右）を使いますが、契約書・新聞・小説・多くの公的書式は縦書き（たてがき） — 列を上から下へ、列は右から左へ — を使います。
• 見た目のよく似た文字が数千。密な漢字は一画の違いしかないこともあり、部品も共有するため、文字単位の正確さは少しの誤りも許しません。

日本語は「別のアルファベットで書いた英語」ではない。3種類の文字、2つの読み方向、そしてスペースの不在 — 欧文を前提にOCRモデルが置く仮定のほぼすべてが、ここでは成り立たない。

なぜ縦書きが最先端のLLMを破綻させるのか

その差が数値として表れるのが縦書きです。縦書き日本語に対するマルチモーダルLLMを評価した2025年11月の研究では、テストされたすべての最先端モデルが、同じ内容を横書きにした場合よりも、縦書き（たてがき）で著しく性能が落ちることが分かりました。理由は構造的です。これらのモデルは圧倒的に横書き・左から右のテキストで学習されているため、文字が上から下へ、列が右から左へ並ぶと、誤った順序で読んでしまったり、横書きとして走査し直して意味の通らない出力を生んだりするのです。

文字誤り率（CER）は、誤って挿入・削除・置換された文字の割合を測る指標で、低いほど良いものです。横書きでは最先端モデルはほぼ完璧で、誤り率はおよそ2%未満です。ところが同じテキストを縦の列に回転させると、GPT-4.1は18.2%、GPT-5は21.3%へと跳ね上がります — およそ5文字に1文字が誤りです。契約条項の5分の1が崩れているかもしれず、しかもどの5分の1かを容易に見分けられないとき、その条項は信頼できません。

実際のビジネス文書は、テスト文よりさらに難しい

これらのベンチマーク値は、比較的きれいなテキストから得られたものです。実際の日本語ビジネス文書には、問題を複合させる層がさらに加わります。

• 密で入れ子の表。日本語の財務諸表や登記簿は、セルを結合した多層ヘッダーの表を詰め込みます。汎用モデルは行と列の対応を見失い、値が誤ったセルに入り込みます。
• ビジネスチャート・グラフ。差が最も大きいのがチャートの視覚的な読み取りです。既存のOCRやドキュメントAIは、軸・凡例・数値を読み違え、チャート理解の正解率は40%台前半にとどまります。
• ハンコ（印鑑）。赤い朱肉の印影が契約書や稟議書の印刷文字に重なり、法的に重要な文字そのものを覆い隠します。
• ふりがな・ルビ。漢字の脇や上に読みの補助として小さく振られたかなが、本文の流れに紛れ込み、結果を壊します。
• 1ページ内での方向の混在 — 縦書きの本文に、横書きの表キャプション・ページ番号・印影が同居します。
• 手書きや古い書式 — 現代の学習データから大きく外れる、古い届出や手書きの注記。

目に見える誤りよりも厄介なのは、見えない誤りです。最先端のLLMは確率的であり、温度ゼロでも同じ文書から実行のたびに微妙に異なる出力が返ることがあります。さらに、追い詰められたモデルは、文書には存在しなかったもっともらしい値を捏造することがあります。気軽な利用なら煩わしいだけですが、財務の締め・コンプライアンス報告・契約レビューといった高リスクの業務では、自信ありげに作り出された数字は重大なリスクになります。

きれいな横書きの段落では、最先端モデルは見事に見える。しかし、印影が重なり、縦書きで、複数の表を含む日本語契約書では、見事に見えて、間違っている — そのほうが厄介だ。

なぜこれがあらゆる高リスクのAIワークフローで重要なのか

建設（けんせつ）、物流、小売、製造、金融サービスに至るまで、日本のビジネスの多くは、まさに最先端モデルが最も苦手とする文書 — 縦書きの契約書、ハンコの押された稟議書、密な財務表、検査表、登記事項証明書 — の上で動いています。RAGアシスタントに読み込ませるにせよ、請求書を突き合わせるにせよ、意思決定のために数値を抽出するにせよ、縦書きのページで80%正しい汎用チャットボットは時短にはなりません。隠れたリスクです。誤読した20%は、日本語を読めない人にとって、正しく読めた80%と見分けがつかないからです。高リスクの業務では、見えない正確さは信頼できない正確さです。

実際に機能するもの：日本語のために作られたドキュメントインテリジェンス

解決策は、より大きな汎用モデルではなく、実際の日本語ビジネス文書に合わせて設計されたドキュメントの層です。それこそが、当社のドキュメントインテリジェンスエンジン Nebula が注力していることです。汎用モデルが静かに破綻する領域 — 複雑な表、ビジネスチャート、ハンコ、密で方向の混在したレイアウト — を、レイアウトを保ったMarkdownと構造化JSONに変換し、すべての値がページ上の位置までさかのぼれる形にします。Nebulaはすでに、日本語のビジネス文書、そして日本語全般において高い性能を示しています。完全な縦書き（たてがき）のようなより難しいケースは、私たちが現在取り組みを進めている領域であり、この分野の誰にとってもまだ解決済みではありません。その結果として Nebula は、RAGアシスタント、分析、エージェント、レビュー業務といったあらゆる下流のAIシステムの、信頼でき監査可能な入力層となります — 建設・物流・小売・金融など、業界を問わず。その原則は、私たちが作るすべての根底にあるものと同じです — 制御できるAI、信頼できるインサイト、そして100%の監査可能性。鵜呑みにするほかないブラックボックスではありません。