ベンチマークレポート: Ur-AI Parser API vs. Azure・LlamaParse・IBM Docling — 日本語の企業・財務文書での比較評価

要旨

本レポートでは、エンタープライズAIシステムやLLMアプリケーション向けに設計された次世代ドキュメント変換モデル（Doc2Md）の性能を評価しています。事業計画書やプレゼン資料のような非構造化の財務データに対して、AIが論理的に推論することは、現在のAIアーキテクチャにおける中核的な課題の一つです。

従来の静的な評価手法は、CERやAST/TEDSのような見た目や表層的な整形精度を重視してきました。しかし、こうした指標だけでは、下流のLLMが実際の推論タスクでどこまで機能するかを、十分な信頼性をもって測ることはできません[3][4]。

そこで本レポートでは、LLM-as-a-Judge[5]の考え方を取り入れ、抽出されたテキストを用いて、下流のLLMが実際に課題を解けるかどうかを直接検証する評価フレームワークを提案しています。検証対象は、日本語の企業・財務文書25件、QAタスク165問、100個のチャートにまたがる推論タスク198問です。その結果、Ur-AI Parser APIは、実運用に不可欠な意味復元力、すなわち推論の頑健性において、主要なエンタープライズ向け基盤モデルと同等水準の性能を示しました。本レポートは、文書処理における新たな基準として「AI対応力（AI-readiness）」を提示し、AIアプリケーションに適した文書変換アーキテクチャを明らかにするものです。

1. 従来のOCR指標がAIアプリケーションで通用しない理由

これまでOCRやパーサーの評価には、文字列一致を測るCERや、表構造の一致度を測るTEDSが広く用いられてきました。しかし、こうした指標だけでシステムの信頼性を判断することは、本番運用では大きなリスクになり得ます。

1.1 見た目の正確さと、タスクを解けるかどうかは別問題です

文書を入力として使うAIで本当に問題になるのは、LLMが解釈できない形でデータが表現されてしまうことです。意味のつながりが失われたり、VLMがグラフを読み違えたりすると（視覚的ハルシネーション[6]）、出力は容易に誤ります。見た目が整ったMarkdownや高いTEDSスコアが得られても、下流のLLMが元のデータ構造を論理的に読み解けなければ、実用上の価値は限定的です。

また、距離ベースの指標は、意味的には同じMarkdownであっても、細かな書式差を厳しく減点します[3]。近年の研究[5][4]でも、表面的な文字列一致と、LLMが実際に正しく回答できるかの間には強い相関がないことが示されています。つまり、従来の帳票中心の評価指標だけでは、文書起点のAIアプリケーションで求められる性能を見誤る可能性があります。

2. Ur-AIが最適化しているもの: AI対応力

企業データ活用のボトルネックは、もはやAIモデルそのものの不足ではなく、そこに投入される非構造化データの品質にあります。私たちが取り組んでいるのは、従来型OCRでも、単純なパーサーでも、RAGの一部機能でもありません。

Ur-AI Parserは、業務文書を下流の推論に適した構造化表現へ変換するAI対応文書変換システムです。Markdown、構造化テキスト、意味表現などへ変換し、実運用上は文書とAIシステムのあいだにある変換レイヤーとして機能します。

2.1 AI-Readinessの定義と構成要素

AI-Readinessとは、文書のデータ表現がLLMベースのシステムにどれだけ正しく解釈され、問い合わせ可能な状態になっているかを示す概念です。これを実現するためには、少なくとも次の要素が必要です。

• テキストの明瞭さ — OCRノイズや壊れたトークンがないこと
• 構造の保全 — 表、階層、セクションが保たれていること
• 数値の忠実性 — 財務用途では必須
• 意味の連続性 — 情報が不自然に分断されていないこと
• 区切り記号と書式の健全性

2.2 制御された正規化

一般的なOCRシステムは、見た目の再現性を厳密に追います。一方で、Ur-AI Parserは、LLMにとっての読みやすさを主眼に設計されています。

そのために用いているのが、意味を変えずに機械可読性を高める制御された正規化です。具体的には、表の列同士が混ざらないよう適切な区切りを入れたり、過剰な空白を整えたりします。こうした正規化によって、元の業務データや数値構造を損なうことなく、AIが扱いやすい形へ変換できます。

3. ベンチマーク設計

この能力を厳密に評価するため、本ベンチマークでは表層的な一致率ではなく、タスクベースの評価を中心に据えました。問いはシンプルです。下流のLLMアプリケーションは、パースされたテキストを安定して読み取り、複雑な論理推論を実行できるのか。この点を検証しています。

3.1 意味推論タスクの4段階（L1–L4）

推論の頑健性は、次の4段階で整理しました。

• L1 — 単独の数値や事実を抜き出すタスク
• L2 — 利益率差分の計算のような、表構造を踏まえた計算・構造推論[1][2]
• L3 — 大きな構造と細部の両方を参照する、階層・文脈推論
• L4 — チャートなど、視覚的な論理フローを含むスキーム推論

4. データセットと方法論

本検証では、できる限り透明性が高く、厳密な評価設計を採用しました（詳細な方法論は付録をご参照ください）。

データセット構成

• 件数: 25文書
• 対象領域: 日本語の金融・ビジネス文書（有価証券報告書、中期経営計画、説明会スライド）
• タスク: L1のテキスト抽出、L2の表構造理解・計算、L3のセクション横断推論を含むテキストQA 165問と、100チャートに対するL4マルチモーダル推論 198問

評価プロセス

• 生成と検証: 初期のQAデータセット（Golden QA）は、OpenAI GPT-5.4 MiniやGoogle Gemini 3 Flash系の制約を踏まえ、複数アーキテクチャを横断して作成しました。これにより、特定モデルの書式バイアスを打ち消しています。最終的なGround Truthの数値や条件は、人手で原本ピクセルに照合して確定しました。
• LLM Judgeプロンプト: 各パーサーのMarkdown出力のみを文脈としてGoogle Gemini 2.5 Flashに与え、推論を実行しました。評価自体はGoogle Gemini 3 FlashをJudgeモデルとして用い、Golden QAに対する意味的な正確さに基づいて採点しています。厳密な文字列一致には依存していません。

評価対象モデル（2026年3月時点）

• Azure Document Intelligence（標準的なエンタープライズAPI）
• LlamaParse（標準的なサードパーティAPI）
• IBM Docling（高性能なローカルOSS）
• Ur-AI Parser API

5. 結果

タスク評価の結果を見ると、下流推論に最適化されたモデルどうしでは、とくにマルチモーダル課題で差が表れる一方、その差は従来の距離ベース指標にはほとんど現れないことが分かりました。

5.1 インフォグラフィックのマルチモーダル評価（L4）

複雑な視覚データを扱えることは、文書処理パイプラインにおいて重要な要件です。本評価では、100個のチャートに対して198件のL4クエリを実施しました。

Ur-AI Parserはこのカテゴリで71.2%の正答率を記録し、Azure Document Intelligenceの42.9%を大きく上回りました。専用の高コンテキストVLMであるGoogle Geminiは78.8%で最も高い結果でしたが、Ur-AI Parserが生成する構造化テキスト表現に置き換えることで、画像そのものを直接扱う際に生じやすい視覚的なチャートの誤読（ハルシネーション）[6]を抑えつつ、安定したデータ抽出が可能になります。

5.2 AIタスク評価の性能（L1–L3）

標準的なテキスト推論・構造推論タスク165問についても、正答率を評価しました。

Ur-AI Parserの総合正答率は70.3%で、Azure Document Intelligence（72.1%）とLlamaParse（70.3%）に並ぶ水準でした。とくにL2領域（表理解と計算）では77%から78%の精度帯を維持しており、Azure Document Intelligenceと同等です。これは、正規化によって構造や計算可能性が損なわれていないことを示しています。一方、L3のセクション横断タスクでは正答率が62%にとどまりました。深い階層構造の見出し表現をどこまで正確に抽出できるかは、今回検証した各モデルに共通する構造的な制約と考えられます。

5.3 従来指標（CER/TEDS）と実タスク性能のずれ

同じモデル群を従来の整列指標で評価すると、上記のタスクベース評価とは異なる見え方になります。

厳密なCERで見ると、Ur-AI Parserの制御された正規化は不利に働き、誤り率が高く算出されます。また、TEDSもGround Truth側のMarkdown記法に左右されやすい傾向があります[3]。しかし、これらの数値を5.1節と5.2節のL1–L4評価と見比べると、従来指標が下流LLMタスクの実力を一貫して予測していないことが分かります。AIアプリケーションを評価する際、見た目の再現度スコアだけに依存することには限界があります。

6. エラー分析

エラーを詳しく分類すると、システム全体の制約と、今後の設計改善で対処すべき要件が見えてきます。

たとえば、「△161,921」のマイナス記号を「4」と誤認するような一文字レベルの読み違いは、LLM推論の欠陥というより、基盤となる空間認識エンジン側の限界に属します。また、情報量の多い図表や複雑なインフォグラフィックでは、ピクセル領域から値を推定する処理に依存するため、一定の近似誤差は避けられません。

7. 限界

本ベンチマークにも限界があります。最大の制約は、165問というサンプル数ではモデル間の差について厳密な統計的有意性（p値）を主張しにくい点です。したがって、今回のデータセットが示しているのは、各モデルの絶対的な優劣というより、先行グループ内での「同等性能帯」に位置しているという傾向です。

8. これがAIアプリケーションにとって重要な理由

最終的に、文書変換は単なる前処理ではありません。AIアプリケーションの信頼性を左右する中核要素です。

投資デューデリジェンス、監査、財務コパイロット、エージェント型の業務フロー、ナレッジ抽出システムといったエンタープライズAIの用途は、いずれも非構造化文書を安定して取り込めることを前提としています。変換後テキストのAI対応力は、次の点に直接影響します。

• 回答モデル（LLM）の推論精度
• 情報起因のハルシネーション発生率
• 高密度データに対する論理・計算の安定性

Ur-AI Parser APIは、単に見た目を転記するのではなく、正規化された意味整合的なデータを下流の推論エンジンに渡すAI対応型の変換システムとして機能します。これにより、本番のAIワークフロー全体の信頼性向上を支えます。

Appendix: 詳細な方法論

1. Golden QAの作成

• 25件の対象文書に対し、多様なプロンプトと複数のLLMアーキテクチャを使って候補解答を生成しました。
• データアノテーター（領域専門家）が原本ページを確認し、数値・論理・文脈に関するGround Truthを確定しました。
• ブラインド・プロトコル: QAデータセットの作成時点では、各パーサーの出力を一切参照していません。設問は生のPDFや画像だけから作られており、特定のパーサーに有利な問いを選ぶ、いわゆる「ポチョムキン・バイアス」を構造的に防いでいます。これにより、ベンチマークの中立性を担保しています。

2. 評価プロンプトとLLM Judge設計

• Markdown出力をGoogle Geminiに入力するためのコンテキストプロンプトは厳密に標準化しました。
• メタプロンプトにより、外部知識を使わず文書内情報だけに基づいて回答するよう制約しました。
• Judgeの採点ロジックは、見た目の文字列差ではなく、実用上の意味的な誤りを重く見るよう設計しています。

参考文献