最先端モデルは高性能だが、文書解析はそれ以上に難しい

最新世代のフロンティアモデルは、1年前には不可能だったことを実現しています。複雑な推論に関するベンチマークでは、人間の専門家レベル、またはそれに近いスコアを記録しています。100万トークン規模のコンテキストウィンドウを扱います。
コードを書き、財務モデルを分析し、ドキュメントを処理し、実際の専門家による精査にも耐えうるアウトプットを生成します。進歩は本物であり、ベンチマークもそれを反映しています。

請求書、財務報告書、契約書、技術マニュアルといった実際の企業文書を処理するパイプラインを構築している方であれば、これらのモデルを見て、「優れたモデルならどこまでできるのだろうか」と考えたことがあるかもしれません。

ベンチマークの結果は良好で、その性能には期待が持てるように見えます。
では、シンプルな抽出プロンプトを使って、大量の実際のドキュメントにそれらのモデルの一つを向け、作業を行うよう依頼すると、実際には何が起こるのでしょうか。

まさにそれが、私たちが知りたかったことです。

テストの実施方法

私たちは、ドキュメント解析のための公開ベンチマークである SCORE-Bench を使用しました。SCORE-Benchは、企業環境で実際に扱われる文書を反映した224件の実世界のドキュメントで構成されています。
文字が傾いてスキャンされた請求書、階層が深い表を含む財務報告書、医療関連フォーム、法的契約書、複雑な複数カラムレイアウトを持つ技術文書などです。完全なデータセットは、Hugging Face上で一般公開されています。
私たちは、Claude Opus 4.6、GPT-5.2、Claude Sonnet 4、GPT-5-mini、Gemini 2.5 Proをテストしました。いずれのモデルにも、シンプルな抽出プロンプトのみを与え、追加の設定は行っていません。比較対象となるベースラインには、私たちのVLM Partitionerパイプラインを使用しました。このパイプラインでは、Claude Opus 4.5に加えて、最適化された抽出プロンプト、後処理、そして出力構造を強制する仕組みを組み込んでいます。

この2つの条件の差が、今回の結果が測定しているものです。

結果

5つすべてのモデルにおいて、総合指標で見た全体的な精度は、私たちのパイプラインを4～16ポイント下回りました。全体像は以下のとおりです。

その差は、すべての指標で一様に現れているわけではありません。いくつかの指標、特にハルシネーションの抑制においては、一部のモデルが私たちのパイプラインに驚くほど近い結果を示しています。一方で、表抽出やドキュメント構造の把握といった指標では、その差はかなり大きくなっています。より興味深い発見があるのは、まさにその部分です。

差が開くポイント

ハルシネーション率

これは、私たちが最も驚いた発見でした。
ハルシネーション率は、モデルが生成したトークンのうち、元の文書には存在しないトークンがどれだけ含まれているかを測る指標です。
この指標において、Opus 4.6は際立っていました。Opus 4.6の値は0.044で、私たちのパイプラインは0.043でした。実用上は、ほぼ同等と言えます。

GPT-5.2は0.167で、私たちのパイプラインのおよそ4倍の値でした。
GPT-5-miniは0.161、Gemini 2.5 Proは0.257でした。

これが皆さんのパイプラインにとって何を意味するのか。
ハルシネーションされたコンテンツは、自分から「これはハルシネーションです」とは知らせてくれません。見た目は、普通に抽出されたテキストと同じです。
そのままベクトルストアに流れ込み、検索対象となり、まるで実在する情報であるかのようにLLMへの入力として使われます。
その結果、後段では、発見しづらい形で「自信満々に間違った回答」が生成される可能性があります。
Opus 4.6のこの点における基礎能力は本物です。文書を読み取り、そこに存在しない内容を勝手に作り出すことはありません。
一方で、Opus 4.6が弱いのは構造面です。これはまったく別の問題です。

ハルシネーションの裏返しにあるのが、カバレッジ(網羅率)です。
つまり、元文書の内容がどれだけ実際に出力に含まれているか、という指標です。
この点で、Opus 4.6は0.737となっており、今回テストしたすべてのモデルの中で最も低い結果でした。
つまり、Opus 4.6はほとんどハルシネーションを起こさない一方で、元文書の内容のおよそ4分の1を取りこぼしている、ということです。

このトレードオフは理解しておく価値があります。
より多くのコンテンツを見つけるモデルは、その分、存在しない内容を作り出してしまう傾向もあります。
GPT-5.2とGPT-5-miniは、カバレッジではより高いスコアを出していますが、その一方でハルシネーション率も高くなっています。
Geminiは多くの情報を見つけますが、今回のグループの中で最も高いハルシネーション率を示しています。
高い再現率、つまり必要な情報を多く拾えることと、低いハルシネーション率、つまり存在しない情報を作らないこと。
この両方を同時に達成できているかどうかが、グラフ上部の数値に反映されています。

皆さんのパイプラインにとって、コンテンツの取りこぼしは、検索時のギャップを意味します。
LLMが質問を受けたとき、本来必要な関連箇所がそもそも抽出されていなければ、回答は不完全になったり、誤ったものになったりします。
これはハルシネーションよりも目立ちにくい失敗パターンですが、後段に与える影響としては同じように現実的な問題です。

表の抽出

表には、企業にとって非常に価値の高い情報が多く含まれています。
財務数値、価格表、仕様一覧などがその例です。
これらを誤って抽出することは、単なる小さな精度の問題ではありません。
データの整合性に関わる問題です。
表抽出精度については、評価対象の5モデルはいずれも当社のパイプラインを下回り、最大で23ポイントの精度差が見られました。

ここで最も重要な指標は、単にモデルがセル内のテキストを正しく読めるかどうかではありません。
そのテキストが、どの行・どの列に属しているのかを理解できているかです。
たとえば、モデルが「4.2 million」という文字を完璧に読み取れたとしても、それを誤った列に配置してしまう可能性があります。
その時点で、数字そのものは正しくても、その数字が持つ意味は間違っていることになります。
後段の処理で直面する失敗パターンは、文字化けしたテキストではありません。
表面上は正しく見えるものの、構造的に誤った位置に配置されたデータです。

文書の構成

これは、今回のデータの中で最も大きな差が出た項目であり、同時に最も難しい問題でもあります。
要素の対応付けは、モデルが見出し、段落、表、図などを正しく識別し、それらを正しい順序で並べられているかを測る指標です。
評価したすべてのモデルにおいて、この指標は当社のパイプラインを下回り、その差は最大で16ポイントに達しました。

これが重大な問題である理由は、要素の対応付けの失敗は表面化しにくいからです。
テキスト自体は存在しています。文書も処理されています。
しかし、要素同士の構造的な関係性が間違っているのです。
段落が誤ったセクションに紐づけられたり、図がキャプションから切り離されたり、小見出しが本文の一部として扱われてしまったりします。
そうしたチャンクがRAGパイプラインに投入されると、そのチャンクが持つコンテキストは壊れた状態になります。
LLMは、正しい単語を使ってはいるものの、誤った順序や関係性の中で処理することになります。
そして、生成される回答にもその影響が反映されますが、何かが間違っていたことを示す明確なサインはありません。
ここは、単純なプロンプトが最も大きく遅れを取る領域であり、また、生のモデル呼び出しと最適化されたパイプラインとの差が最も顕著に表れる部分でもあります。

出力の一貫性

精度とは別に、本番運用上の懸念として挙げるべき点があります。
Gemini 2.5 Proは、224件の文書のうち12件、つまりデータセット全体のおよそ5%で、一貫性のない出力形式を返しました。
そのため、それらの出力は、そもそもスコアリングを行う前に後処理が必要でした。

その割合になると、単に一部の文書で精度が低いという問題では済みません。
パイプラインがそのまま取り込めない文書が発生している、という問題になります。
大規模に運用する場合、それは例外処理に対応するための追加のエンジニアリング作業を意味します。
また、フォールバック層を組み込まない限り、完全に自動化できないパイプラインになってしまいます。

ギャップの正体

今回テストしたモデルは、いずれも高い能力を持っています。
ハルシネーションに関する結果は、それを明確に示しています。Opus 4.6は、文書に存在しない内容を作り出すことなく、文書を読み取ることができています。
つまり、この差はモデルの能力そのものの問題ではありません。設定・構成の問題です。
単純な抽出プロンプトでは、結合された表ヘッダーをどう扱うべきか、文書要素をどの順序で並べるべきか、どれだけの内容を抽出すべきか、どのような出力形式にすべきかまでは、モデルに指示していません。
ただ「抽出して」と依頼し、残りはモデルがうまく判断してくれることを期待している状態です。
多くのタスクではそれでも問題ありません。
しかし、エンタープライズ規模で文書パースを行う場合、単純なプロンプトで指定されていない細部こそが、まさに処理が破綻するポイントになります。
生のモデル呼び出しと本番運用に耐えるパイプラインの間には、3つの層があります。
1つ目は、最適化されたプロンプトです。
これは、文書パースに求められる構造的な要件について、モデルに具体的な指示を与えます。たとえば、見出しをどう扱うか、不規則な表レイアウトをどう処理するか、文書要素をどう並べるか、カバレッジと正確性のバランスをどう取るか、といった点です。
2つ目は、後処理です。
後処理は出力を正規化し、適切にプロンプトを設計しても発生するエッジケースに対応します。
3つ目は、出力構造の強制です。
これは、モデルが回答を生成する前に、何をもって有効なレスポンスとするかを定義する仕組みです。
これらの各層は、今回の結果で見られた特定の失敗パターンに対応しています。
Element Alignmentの差は、プロンプト設計の問題です。
Opus 4.6に見られた再現率のトレードオフも、プロンプト設計の問題です。
Geminiで見られた出力形式の不一致は、出力構造の問題です。
これらの層のどれか一つでも欠けると、その影響は数値に表れます。
性能向上は、モデル単体から生まれるものではありません。
そのモデルの周囲に何を構築するかによって生まれるのです。

ご自身の文書でお試しください

今回テストしたモデルはいずれも強力であり、その結果にもそれは表れています。
同時に、これらの結果が示しているのは、汎用的なモデル性能と、文書パース性能は別物であるということです。
未加工のモデル呼び出しと、本番運用に耐えるパイプラインとの間には、確かな差があります。
そして、その差は埋めることができます。
ただし、それには単なるプロンプト以上のものが必要です。