なぜAIドキュメントリーダーは長いPDFの途中で詰まるのか

40ページのベンダー契約を想像してください。お気に入りのAIツールにアップロードし、解約条項の内容を尋ねます。その条項は22ページにあります。モデルは速やかに、かつ自信満々に回答します。しかし、その回答は誤りであり、実際には3ページの定型文から言語を抽出していたことが判明します。

これは仮定の特殊ケースではありません。新しい論文『SynthDocBench』によると、これはほぼ予測可能な失敗モードです。研究者が詳細にテストした6つのビジョン・ランゲージモデルのうち5つにとって、長文書の中間1/3が最も処理が難しく、文書内のどの部分を参照するかを尋ねる際、モデルの多くは深くなるにつれて性能が徐々に低下します。これらのモデルを基盤とした製品を構築している場合、あるいは実際のワークフローのためにOCRとドキュメントAIエンジンの選択を検討している場合、この問題は20分間の注意を払う価値があります。

単一の雑多な試験で採点することの問題点

DocVQA、ChartQA、MMLongBench-Doc などのドキュメント向けビジョン・ランゲージモデル（VLM）ベンチマークの多くは、「このモデルはドキュメントを読み取り、それに関する質問に回答できるか？」という問いに対しては妥当な評価を行なっています。しかし、モデルが失敗した理由を明らかにする点では、これらのベンチマークは不十分です。

実際のドキュメントは、複数の次元で同時に多様性を持っています。例えば、ドキュメントの長さ、レイアウトの複雑さ（単一カラムのテキスト、高密度な財務表、チェックボックス付きのフォームなど）、埋め込まれるコンテンツの種類（プレーンテキスト、表、グラフ、スキャン画像）、そして質問の難易度などが挙げられます。既存のベンチマークでモデルが誤答を出した場合、これら4つの要因がすべて絡み合っています。モデルが混乱したのは、ドキュメントが長かったからでしょうか？ 珍しいレイアウトだったからでしょうか？ それとも、単語の検索と置換ではなく表の計算が必要だったからでしょうか？ ベンチマークのドキュメントは現実世界から収集されたものであり、これらの要因を制御していないため、真の原因を特定することはできません。

SynthDocBench が埋めようとしているのは、まさにこのギャップです。著者らは、現実のドキュメントを収集して多様性が平均化されることを期待するのではなく、ドキュメントを一から生成し、各要因を独立して調整します。これは、野外で偶然見つかるものを観察するのではなく、実験室で制御された実験を設計するのと同じアプローチです。

ドキュメントをスクレイピングではなく科学実験のように構築する

仕組みを平易な言葉で説明すると、研究者たちはコンテンツ、構造、ビジュアルレイアウトをすべて一貫して生成するLLMパイプラインを構築しました。各ドキュメントには6つのレイアウトアーキタイプ（レポート風、フォーム風、表とテキストの混在など）のいずれかが割り当てられ、論文ではドキュメントの長さ、レイアウトの複雑さ、テキスト・表・チャート・画像の組み合わせ、そして質問の種類をそれぞれ独立して変化させます。ここで言う「組み合わせ設計」とは、すべてを混ぜ合わせる1つのつまみではなく、他の条件を固定したまま個別に調整できる複数のつまみがあることを意味します。

ここには巧妙な工夫があります。生成プロセスの40%のケースでは、意図的にドキュメントの「想定される」パターンを無効化します。例えば、レイアウトの慣例では通常配置されない場所にチャートを配置するといった具合です。これはモデルがテストを不正に突破するのを防ぐためです。実際の年次報告書のレイアウト傾向から「収益に関する答えは常に1ページ上部にある」と学習した場合、モデルはドキュメントを実際に読まずとも、ドキュメントの慣例に基づくパターンマッチングで高得点を得てしまいます。40%のランダムな上書きはこのショートカットを遮断し、モデルがドキュメントが「通常通り」レイアウトされていると仮定できなくします。

もう一つの注目すべき特徴は長さです。SynthDocBenchのドキュメントは、DocVQA、ChartQA、MMLongBench-Docで一般的に含まれるものよりも、大幅に長く、構造的な多様性を持っています。これは重要です。なぜなら、この論文で興味深い失敗の多くは、ドキュメントが長くなった場合にのみ現れ、短いベンチマークではそれらを完全に見逃してしまうからです。

ドキュメントが長くなると、モデルのパフォーマンスが明確に低下する

最初の発見は最も予想通りですが、それでも明確に述べる価値があります。ドキュメントが長くなるにつれて精度が低下します。これは文脈が長くなれば何でも難しくなるという点で驚くべきことではありませんが、重要なのは精度低下の「速度」と「急峻さ」です。SynthDocBenchはレイアウトやコンテンツの種類とは独立して長さを制御しているため、研究者は精度低下を「長いドキュメントほどレイアウトが乱雑になりやすい」という以前すべてのベンチマークが抱えていた交絡因子ではなく、長さに特化して帰属させることができます。

マルチページドキュメント（賃貸契約書、医療記録、財務諸表、技術マニュアルなど）を処理する製品を開発している人々にとって、これは2ページのサンプルでうまく動作するデモが、実際の顧客がアップロードする60ページのバージョンでどのように動作するかについてほとんど教えてくれないという点の再確認です。

ドキュメント中央部の盲点

これは本論文で最も興味深い結果です。研究者たちは各ドキュメントを3等分（前半、中央、後半）し、モデルがどこで誤答するかを調査しました。この方法でテストされた6つのモデルのうち5つにおいて、中央の1/3が質問に答える上で最も困難な部分でした。モデルが息切れすると予想される終わりではなく、中央です。

また、彼らは「前半から後半への傾向」と呼ばれる指標も測定しました。これは基本的には、テキストを進めていくにつれて、ドキュメント前半の質問に対する精度と後半の質問に対する精度がどのように変化するかを示すものです。6つのモデルのうち5つで負の傾向を示し、つまり後半の素材よりも前半の素材の方が成績が悪く、最も急激な低下は8.3ポイントに達しました。

このパターンが既視感を持つなら、それは当然です。長文脈のテキスト専用言語モデルを研究する研究者たちは、長年にわたり類似した現象を記録してきました。しばしば「中央で失われる（lost in the middle）」と呼ばれ、モデルは長い入力の最初と最後の情報を使うことには優れていますが、中心に埋もれた情報を使うことには劣ります。SynthDocBenchは、この同じ失敗が純粋なテキストだけでなく、視覚的なドキュメント理解でも現れることを示しています。これは意味のある拡張です。なぜなら、多くの人がマルチモーダルなドキュメントモデルはトークンストリームだけでなくレイアウトや画像を処理するため、異なる挙動を示すと想定していたからです。しかし、彼らは異なる挙動を示しません。弱点はアーキテクチャとともに移動します。

実用的には、これは30ページの保険契約書を読むモデルが、中央のページ（12〜20ページ）にあるものを、2ページ目や28ページ目にあるものよりも不均衡に高い確率で見逃すことを意味します。中央のページが客観的に読むのが難しいわけではない場合でもです。

チャートは、最も必要とされる時点で機能しなくなる

3つ目の失敗モードは、チャートの理解に特化したものです。棒グラフや折れ線グラフを読み取り、それに関する質問に答えることは、テキストを読むよりもすでに難しいタスクです。なぜなら、モデルは視覚的な要素（棒、軸、凡例）を数値的な意味にマッピングする必要があるからです。SynthDocBenchは、チャートが長いドキュメントに埋め込まれると、このスキルが著しく低下することを発見しました。これは、前述の一般的な長さに関連する低下から予測されるよりも悪い結果です。

チャートが実際に存在するドキュメントを考えてみましょう。四半期決算資料、科学論文、政府報告書、PDFにエクスポートされた販売ダッシュボードなど。これらは、15ページ目のチャートが誰かが抽出しようとしている数値を保持しているまさにそのドキュメントであり、SynthDocBenchがモデルが最も信頼できないことを示すまさにその設定です。

OCRの構築・選定において重要である理由

OCRやドキュメントAIエンジンを、単なるデモ以上の実務用途で評価している場合、この論文から直接導き出される3つの実践的な教訓があります。

• 短いサンプルではなく、実際のドキュメントの長さでテストしてください。 5ページのテストPDFで高いスコアを出したモデルが、ユーザーが50ページの契約書をアップロードした際にも同じ性能を発揮するとは限りません。ベンダーに問いかけたり、オープンモデルを実行したりする際は、本番環境で実際に遭遇する長さのドキュメントを対象にしてください。
• 長文ドキュメントの中間部分に関する回答は、スポットチェックなしには信用しないでください。 ワークフローが長文ファイルの内部から情報を抽出することに依存している場合、それはまさにこの論文が最も信頼性に欠けると指摘している領域です。長文ドキュメントをチャンク（断片）に分割して個別にクエリを実行するか、モデルに読ませる前に検索機能で関連セクションを抽出し、全文を1つの長いコンテキストウィンドウに放り込むのではなく、適切に処理を検討してください。
• 図表が多い長文ドキュメントには特に注意が必要です。 埋め込まれた図や表を含むレポート（財務報告書、研究論文、分析エクスポートなど）を扱う場合、孤立した図表は適切に処理できても、レポートの20ページ目に埋もれた同じ図表も同様に処理できるとは限りません。図表の検証は、純粋なテキスト抽出とは別に、特に注意深く行ってください。

これらの指摘は、ドキュメント作業においてVLM（ビジョン言語モデル）を避けるべきだという主張ではありません。むしろ、SynthDocBenchがテストを行うように、ドキュメントAIを制御されたパーツに分解してテストし、数少ない例からの感覚だけで判断しないよう求めるものです。なお、日本語は漢字と仮名が混在し、縦書きというレイアウトが一般的であるため、英語のみを対象としたベンチマークや縦書きを無視したモデルでは、日本語読者にとって実務上重要な文字認識の課題がカバーされない点に留意が必要です。

このベンチマークが教えてくれないこと

正直なところ、いくつかの留意点は重要です。SynthDocBenchは完全に合成されたデータであり、実際のスキャン、提出書類、またはフォームから収集されたものではなく、LLMパイプラインによって生成されています。合成ドキュメントは、すべての変数を制御できるという点で有用ですが、その制御には代償が伴います。LLMで生成された「請求書」や「レポート」には、実際の請求書やレポートのレイアウトや表現とは異なる、独自の微妙な統計的な特徴（フィンガープリント）が含まれている可能性があります。論文自体が主張している「現在のモデルはベンチマークのアーティファクトに過学習している可能性がある」という点は、両刃の剣です。SynthDocBenchが測定しているものの一部が、より厳密に制御された新しい種類のアーティファクトそのものである可能性は十分に考えられます。

また、評価対象は7つの最先端VLM（ビジョン・ランゲージ・モデル）に限定されており、これは意味のあるサンプルですが、2026年半ば時点で利用可能なモデルのスナップショットに過ぎません。長文コンテキストタスクにおけるモデルの振る舞いは急速に進化しており、今後の一様な適用を前提とする前に、新しいリリースが「中間部分の欠落（lost in the middle）」という弱点を特にターゲットにしているかどうかを確認する価値があります。

それでも、これらの留意点にかかわらず、本研究の核心的な貢献は揺るぎません。長さ、レイアウト、モーダル性、質問タイプを独立して制御することで、研究者たちは、より雑多な実世界ベンチマークが構造的に表面化できなかった失敗モードを特定することに成功しました。特にドキュメント中央部の盲点は、既知の事実を再包装しただけではなく、真に新規かつ有用な発見です。長文ドキュメントの読み取りを業務とするシステムを構築している場合、その盲点を考慮して評価パイプラインや製品のチャンキング戦略を設計することは、非常に価値があります。