しかし現場では、「本文はよく読めるのに、表の数字やグラフを取り違える」「金額の桁や単位を落とす」「日本語の資料だと思ったほど精度が出ない」といった問題がよく起きています。業務文書では、たった1つの数字の読み違いが大きな判断ミスにつながります。

この記事では、各社の公式ドキュメントでAIがPDFや画像をどう受け取り、どこでつまずくかを整理し、「どこで間違え、どう測り、どう防ぐか」を扱った論文4本を紹介します。結論を先に言うと、AIの読み取りは「平均点」ではなく「数字・単位・グラフ・対話」といった弱点ごとに確かめ、間違えると困る項目には元の資料との突き合わせを残すのが基本です！

画像やPDFを読めるAIの仕組み

PDFは「ページの画像」と「抜き出した文字」の両方で渡される

主要なAIのAPIは、PDFを受け取ると2種類の情報に分けてモデルに渡します。Anthropic の説明では、Claude の API はPDFの各ページを画像に変換し、各ページから抜き出した文字と一緒に渡します（一部の利用経路では文字の抽出だけになる場合があります）。だからこそ、文字だけでなくグラフや図についても質問できます（Anthropic「PDF support」）。OpenAI も、画像を扱えるモデルではPDFから文字とページ画像の両方を取り出して渡すと説明しています（OpenAI「File inputs」）。

注意したいのは、PDF以外の形式では、この「見た目」の情報が落ちることです。OpenAI は、Word や PowerPoint などPDF以外の文書からは文字だけを取り出し、埋め込まれた画像やグラフは渡さないため、グラフを読ませたいときはPDFに変換してから送るよう勧めています。Google の Gemini API の説明でも、見た目まで理解できるのはPDFで、テキストや HTML などほかの形式は単なる文字として扱われ、グラフや書式は失われるとされています（Google「Document understanding」）。

画像は縮小・拡大されてから読まれる

もう1つ知っておきたいのが解像度です。ページ画像はそのままの大きさでモデルに届くとは限りません。Anthropic の説明では、長辺の上限（標準で1,568ピクセル、Claude 4.7 以降のモデルで2,576ピクセル）があり、それを超える画像は縮小されてから処理されます（Anthropic「Vision」）。Gemini API では、大きなページは最大3,072×3,072ピクセルに縮小され、小さなページは768×768ピクセルに拡大されます。OpenAI は、細かいグラフや小さな文字にはPDFの処理の細かさを高く設定するよう案内しています。

細かい文字が詰まったページや小さな注記つきの表は、縮小の段階で読みにくくなることがあります。

文書理解でつまずきやすい点と、対策の全体像

各社は、画像の読み取りの限界を公式ドキュメントで明示しています。OpenAI は、日本語や韓国語のようなラテン文字以外の文字を含む画像では性能が十分に出ないことがある、小さな文字や回転した文字を読み違えることがある、色や線の種類（実線・破線・点線）で区別するグラフの理解に苦労することがある、と書いています（OpenAI「Images and vision」）。Anthropic も、画質が低い・回転している・極端に小さい画像では誤ることがあり、物の数は概数になることがあるとしたうえで、完璧な正確さが必要な作業では人の確認なしに使わないよう求めています。Google は、ページの向きを正しくし、ぼやけたページを避けることを勧めています。

これらを、文書を読ませる場面に当てはめて整理すると次のようになります。

対策は大きく、入力を整える（向き・解像度・PDF化）、仕組みを選ぶ（専用のOCRや段階的な処理か、1つのモデルにまとめるか）、弱点ごとに評価する、人の確認を残す、の4つに分けられます。読み取った文書をAIに検索させて答えさせる仕組みを作る場合は、RAG（検索拡張生成）の記事も参考にしてください。ここからは、こうした弱点をどう測り、どう防ぐかを扱った論文を見ていきます。

研究で見る「どこで読み違えるか」

📄 論文: 日本の白書の図表で測ると、オープンな小型モデルは6割に届かない

HakushoBench: A Japanese Chart and Table VQA Benchmark from Governmental White Papers（Issa Sugiura ほか、2026年5月、arXiv:2606.01132）は、査読前の論文（プレプリント）です。

対象と条件: 日本の省庁が公開している33冊の白書のHTML版から集めたグラフ・表の画像2,053枚に、人が1問ずつ質問と答えを付けたデータで、オープンウェイトのモデル6つ（3B〜9Bパラメータ）を NVIDIA A100 で、商用モデル3つを各社のAPI経由で測っています。実際の業務文書ではなく、公開された白書の図表で測った結果です。

図表を読むAIの性能は英語のベンチマークで測られることがほとんどでした。この論文の質問は、図全体の情報をまとめる、複数の値から比を計算する、数を数えるといった手間のかかるものに絞られ、正誤はAI（GPT-5.1）が判定して3回の平均を取っています。

結果は、評価したオープンウェイトのモデルで最も良い Qwen3-VL 8B でも、段階的に考えさせる指示を付けて正解率58.6%でした。最も良い商用モデル（Gemini 3 Pro）は93.5%で、両者の差は34.9ポイントです。ただし商用モデルの中でも差は大きく、GPT-4o は54.1%と、最良のオープンモデルより低い結果でした。

運営者にとっての意味は、「図表も読める」という評判は、自社の日本語の資料で確かめるまで当てにならないということです。

📄 論文: 表は読めても、グラフと「やり取り」で崩れる

When Tables Go Crazy: Evaluating Multimodal Models on French Financial Documents（Virginie Mouilleron ほか、2026年2月投稿・6月改訂、arXiv:2602.10384）は、査読前の論文（プレプリント）です。

対象と条件: 運用会社が公開しているフランス語の投資目論見書や重要情報文書から作った1,204問（評価用データ「Scribe Finance」）で、オープンウェイトのモデル6つ（8B〜124Bパラメータ）を測っています。文章の問題は画像ではなく文字に変換した本文で与え、表とグラフの問題は画像で与えています。正誤は3つのオープンなAIの多数決で判定しました。

論文の表によると、文章からの抜き出しは6モデルとも88〜90%と高い正解率でした。一方、表の画像の読み取りは52〜86%とモデルによる差が大きく、グラフの解釈は34〜62%にとどまりました。

目立ったのは、やり取りしながら計算する場面です。正しい前の答えを与えた場合は63〜86%だったのに、モデル自身の前の答えを引き継がせると、46〜59%の狭い範囲にまとまりました。最初の誤りが後の質問に持ち越され、大きなモデルでも防げなかったということです。

運営者にとっての意味は、「表が読めたからグラフも大丈夫」「1問目が合っていたから続けて聞いても大丈夫」とは限らないということです。

「どう測り、どう防ぐか」

📄 論文: 文字は合っていても事実が違う、OCRの品質は「事実単位」で測る

FinCriticalED: A Visual Benchmark for Financial Fact-Level OCR（Yueru He ほか、2025年11月投稿・2026年4月改訂、arXiv:2511.14998）は、査読前の論文（プレプリント）です。

対象と条件: 米国の証券当局の開示書類や非営利団体の税務書類など、主に米国の英語の金融文書859ページを、300dpiのページ画像にしたものが対象です。スキャンした紙ではなく、電子文書を画像にしたものです。専門家が付けた9,481個の事実（数値・日付・通貨単位・報告主体・金融用語）が、読み取り結果に正しく残っているかを、規則とAI（GPT-4o）を組み合わせた判定で確かめました。対象はOCRの専用システムから商用のAIまで13種類で、商用はAPI経由、一部は自前のGPUで動かしています。

OCRの品質は文字列の一致度で評価されることが多いですが、「(1,200)」を「1,200」と読めば、括弧で表したマイナスが消えて意味が逆になります。実際、OCR システムの MinerU2.5 は、文字列の重なりを見る指標（ROUGE-1）で95.71%だった一方、通貨単位の事実の正解率は54.05%でした。全体では、事実の正解率は65.68%から97.23%まで大きくばらつき、数値と通貨単位が最も壊れやすい種類でした。重大な誤りは、文章と表が混在した複雑なページに集中していました。

運営者にとっての意味は、読み取りの仕組みを「文字の一致率」だけで選ばないことです。金額・単位・日付など、間違えると困る項目ごとに正解率を測ります。

📄 論文: レイアウトを先に考える小型の統合モデル

Qianfan-OCR: A Unified End-to-End Model for Document Intelligence（Daxiang Dong ほか、2026年3月、arXiv:2603.13398）は、査読前の論文（プレプリント）です。

対象と条件: 開発元が作った4Bパラメータのモデルを、公開の文書解析ベンチマーク（OmniDocBench v1.5、OlmOCR Bench など）で測った結果で、比べた他のモデルの値の一部は各ベンチマークの公開値を使っています。処理速度は NVIDIA A100 1枚で測っています。

文書処理は「レイアウト解析→文字認識→内容理解」と段階を分けるのが一般的ですが、段階が増えるほど管理が複雑になります。一方、1つのモデルにまとめると、どこに何が書いてあるかというレイアウトの情報が失われがちでした。この論文は、文書の解析・レイアウト解析・内容の理解を1つのモデルにまとめ、さらに「Layout-as-Thought」という任意の思考の段階で、要素の位置・種類・読む順番を先に書き出してから答えられるようにしました。

結果は、統合型のモデルの中で OmniDocBench v1.5 で93.12 と首位でした（段階を分ける方式の最上位は94.50）。ただしこの93.12は思考の段階を使わない通常の設定の値で、思考の段階を使うと全体では92.64とわずかに下がりました。著者らは、文章・表・数式・図が混在する複雑なページでは思考の段階が効く一方、単純なページでは逆効果になることがあり、思考の段階の効果を確かめたのは OmniDocBench v1.5 だけだと述べています。

運営者にとっての意味は、「レイアウトを考えさせる」機能は、自社の文書が複雑な混在型か単純な1段組みかで使い分けるべきだということです。

現場でやること

入力を整えてから渡す

• グラフや図を読ませたい資料は、Word や PowerPoint のままではなくPDFにしてから渡す
• ページの向きを直し、ぼやけたスキャンは取り直す
• 細かい表は、ページを分けるか処理の細かさの設定を上げる

自社の日本語の文書で、弱点ごとに評価する

実際に扱う帳票や報告書から30〜50ページほど選び、正解を人が用意して比べます。2本目の論文のとおり種類で大きく差が出るので、「文章」「表」「グラフ」に分けて数えます。

間違えると困る項目は「事実単位」で確かめる

金額・単位・日付・マイナスの表記・取引先名など、業務上重要な項目をチェックリストにし、項目ごとに正しく取れているかを確かめます。本番では、合計値の再計算や元データとの突き合わせなど、機械的に確かめられるところは仕組みで確かめ、残りに人の確認を残します。

グラフと対話の分析は「要注意」として設計する

グラフの数値は、元の数値表があればそちらを優先します。対話で分析させるときは、各段階で原文のどこから取った数字かを示させ、人が確かめられるようにします。

文書の中の「指示」には従わせない

外部から受け取った文書や画像に、AIの動きを変える指示が紛れ込んでいることがあります。OWASP は、ファイルなど外部の内容を信頼できない入力として区別し、AIの権限を必要最小限にし、重要な操作には人の承認を挟むよう勧めています（OWASP「LLM01:2025 Prompt Injection」）。詳しくはプロンプトインジェクションの記事で解説しています。

文書AIの導入の鍵は次の3点です

1. 評価は「自社の言語・自社の文書」で行う
   英語のベンチマークやモデルの評判をそのまま信じず、実際に扱う日本語の帳票や報告書で、文章・表・グラフに分けて比べます。
2. 数値・単位・日付は「事実単位」で検証する
   文字の一致率ではなく、業務上重要な項目が正しく取れているかを確かめ、金額や単位には元データとの突き合わせを残します。
3. グラフと複数ターンの分析は「要注意領域」として設計する
   AIには定型的な抜き出しから任せ、グラフの解釈や対話しながらの分析では、各段階で原文に立ち返れる流れにします。

まとめ：文書AIは「読めるか」から「どこで間違えるかを知って使う」へ！

マルチモーダルAIは、PDFをページの画像と文字の両方で受け取り、表やグラフについても答えられるようになりました。一方で、日本語の図表、グラフの解釈、対話での誤りの持ち越し、数字や単位の取り違えといった弱点もはっきりしています。

まずは自社の文書を数十ページ選び、「文章・表・グラフ」と「重要な項目」に分けて正解率を測ってみてください。どこまで任せられ、どこに人の確認が要るかが見えてきます！

参考文献

• Anthropic「PDF support」（https://platform.claude.com/docs/en/build-with-claude/pdf-support）2026-10-01 確認
• Anthropic「Vision」（https://platform.claude.com/docs/en/build-with-claude/vision）2026-10-01 確認
• OpenAI「File inputs」（https://developers.openai.com/api/docs/guides/file-inputs）2026-10-01 確認
• OpenAI「Images and vision」（https://developers.openai.com/api/docs/guides/images-vision）2026-10-01 確認
• Google「Document understanding」（https://ai.google.dev/gemini-api/docs/document-processing）2026-10-01 確認
• OWASP「LLM01:2025 Prompt Injection」（https://genai.owasp.org/llmrisk/llm01-prompt-injection/）2026-10-01 確認
• Issa Sugiura ほか「HakushoBench: A Japanese Chart and Table VQA Benchmark from Governmental White Papers」arXiv:2606.01132（https://arxiv.org/abs/2606.01132）2026-10-01 確認
• Virginie Mouilleron ほか「When Tables Go Crazy: Evaluating Multimodal Models on French Financial Documents」arXiv:2602.10384（https://arxiv.org/abs/2602.10384）2026-10-01 確認
• Yueru He ほか「FinCriticalED: A Visual Benchmark for Financial Fact-Level OCR」arXiv:2511.14998（https://arxiv.org/abs/2511.14998）2026-10-01 確認
• Daxiang Dong ほか「Qianfan-OCR: A Unified End-to-End Model for Document Intelligence」arXiv:2603.13398（https://arxiv.org/abs/2603.13398）2026-10-01 確認

2026-10-01 更新: 構成を見直し、論文へのリンクと参考文献を追加し、表の読み取りの正解率、白書の図表での商用モデルとの差、レイアウトを考える思考の段階の効果の記述の誤りを修正しました

The post 【2026年最新】マルチモーダルAIの文書理解×論文4選｜「PDFの表やグラフを読み違える」を解く first appeared on クエビコ.