PDFをMarkdownに変換するとAIの読解力は上がるか？Claude vs Gemini 実験レポート
結論から言う
「PDFをMarkdownに変換すればAIの読解精度が上がる」という仮説は、半分正しく半分間違いだった。
正確には、モデルごとに最適な入力形式が異なり、変換効果はモデルの読解戦略に依存する。ClaudeはPDFでもMarkdownでもほぼ同等の精度を出すが、Geminiにとってはフォーマットより「どう読むかの指示」の方がはるかに重要だった。そしてもっと面白い発見がある。Claudeが「賢い」のは、モデルが賢いからではなく、自律的に文書を分割して複数回読んでいるからだ。
実験の設計
補助金の公募要領や交付要綱は、研究者が日常的に読まされるタイプの"読解地獄"文書だ。細則が多く、重要な数値が条文の中に埋もれており、読み落としが致命的なミスにつながる。こういった文書をAIに正確に処理させられるかどうかは、実務上の重大な問題になりつつある。
今回は2文書を用意した。先端研究基盤刷新事業（EPOCH）の令和8年度公募要領（PDF 1.9MB・68ページ）と、地域産学官連携の補助金交付要綱（PDF 390KB・20ページ）だ。それぞれをPDF形式とMarkdown形式（Markitdownで変換）の2種類に変換し、独立したAIエージェントに読ませた。
質問は3問に統一した。200字での要約、重要数値の完全列挙、そして注意すべき重要ポイント3つの提示だ。テストしたモデルはClaude Sonnet 4.6、Gemini Flash、Gemini 2.5 Pro（標準指示）、Gemini 2.5 Pro（網羅指示）の4条件。採点はClaudeとGemini双方に独立して行わせた。
発見1：ClaudeはどちらのフォーマットでもPDFを「分割読み」していた
最初に気づいたのはトークン消費の非対称性だ。
EPOCH公募要領（68ページ）を読ませたとき、Claude SonnetはPDF版で77,855トークン、Markdown版で77,036トークンを消費した。ほぼ変わらない。しかし把握した文字数は全く異なる。PDF版が約65,000字であるのに対し、Markdown版は約140,000字——2倍以上だ。
これはなぜか。Claudeのエージェント動作を観察すると、ReadツールをPDF・Markdownのいずれでも複数回に分けて呼び出していた。自律的に文書を分割し、順番に全文を処理する戦略を取っていたのだ。
一方、Gemini FlashはRead callを1回で完了させる。大きなファイルを一気に読もうとするため、長い文書では情報が高圧縮され、細則が脱落する。Markdown版のEPOCH要領を読ませたGemini Flashは、処理時間が306秒（PDFの5倍）に膨れ上がり、それでも把握した文字数は約95,000字にとどまった。
「Claudeが賢い」という評価は正確ではない。Claudeが採用している読解アーキテクチャが、長い文書に対して自然に機能しているだけだ。これはモデルの能力差というより、エージェントとしての設計の差に近い。
発見2：Geminiは指示次第でClaude同等の網羅性を1/5のトークンで達成できる
読解スコアの比較で最も印象的だったのは、Gemini 2.5 Proへの「網羅指示」の効果だ。
標準的な指示でEPOCH要領を読ませたとき、Gemini Pro（標準）は19項目の正解セットのうち10項目しか拾えず、スコアは11.0点（15点満点）だった。Claude Sonnet（PDF版）が19/19項目を抽出して13.75点を出したのと比べると、大きな差がある。
ここに網羅指示を加えた。「文書を複数ブロックに分けて読め（PDFは20ページ×3回、MDは1000行×4回）」「抽出すべきカテゴリを明示する（スケジュール・予算・経費閾値・研究者処遇・不正制裁年数・手続き期限・容量制限）」という2点だけの変更だ。
結果は劇的に変化した。PDF版で19/19項目を完全抽出、推定スコアは14.5点。Claude Sonnetとほぼ同等の網羅性を、消費トークン14,781で達成した。Claudeは77,855トークンを使っていたので、同等の成果を81%少ないトークンで実現した計算になる。
これはGeminiの「能力の問題」ではなく「読解戦略の問題」だと結論づけてよい。モデルに適切な読解プロトコルを渡せば、コストと性能を両立できる。
発見3：フォーマット差はGeminiで非対称、Claudeでほぼ中立
PDFとMarkdownの読解精度を比較すると、モデルごとに異なる傾向が見えた。
Claudeにとってフォーマット差は小さい。Doc-B（交付要綱）ではMarkdown版の方がスコアがやや高かった（MD: 14.75点、PDF: 12.5点）が、Doc-A（EPOCH要領）ではPDF版がわずかに上だった。一貫した優劣はなく、どちらを使っても大きくは外れない。
Geminiにとっては状況が異なる。Gemini Pro（標準）はDoc-BのMarkdown版で11/14項目を抽出（PDF版は10/14）と、Markdownの方がやや安定していた。一方でGemini Flashにとってのマークダウン化は逆効果になった。ファイルサイズが大きくなった分、処理時間が急増し、かえって非効率だ。
つまりMarkdown変換が有効なのは「中程度の文書を、適切な読解指示を持つモデルで読む」場合に限られる。大きなMarkdownをFlashのような高速・軽量モデルに渡すのは得策ではない。
発見4：採点者バイアスは対称的に存在する
採点の公平性を検証するため、Claude採点官とGemini採点官を独立して走らせた。結果は予想通りだが、興味深い形で現れた。
両採点官とも、自モデルの回答に対して約1点甘く採点する傾向があった。ClaudeはClaudeの回答を、GeminiはGeminiの回答を、それぞれ高めに評価する。バイアスは対称的に存在しており、相殺はされない。
ただし最上位・最下位の順位は両採点官で一致していた。全体的な序列の評価は共有されており、細かいスコアの差にのみバイアスが現れる形だ。
AIを採点に使う実験では、採点者の独立性と多様性が設計上の必須条件になる。自己採点に依存した評価は信頼性が低い。
発見5：Gemini Flashの構造誤読は深刻だった
Gemini Flashに補助金交付要綱（Doc-B）をPDFで読ませたとき、重大な誤記が発生した。
「軽微な変更と認められる面積変更の閾値」について、正解は「2%以内の増、1%以内の減」なのに対し、Flashの回答は「2%以上の増、1%以上の減」と方向が逆になっていた。これは数値の欠落ではなく、意味が反転するエラーだ。補助金の申請実務でこの誤読が起きれば、計画変更の要不要の判断が狂う。
Gemini Pro（標準・網羅どちらも）では同じエラーは起きなかった。FlashのPDF処理における構造解釈の脆弱性を示す事例として記録に値する。軽量・高速モデルを細則の多い法令文書の読解に使う場合は、特に注意が必要だ。
今後の展望
今回の実験で見えた課題は、次の問いに発展する。
まず対象文書の拡張だ。今回は補助金関連の2文書に限定したが、学術論文・契約書・技術仕様書など、文書の種類によって最適なフォーマットと読解戦略がどう変わるかは未検証だ。特にグラフや図表を含む文書では、Markdownへの変換ロスが大きくなる可能性がある。
次にモデルの追加だ。GPT-4o、Mistral、Commandなど他のモデルで同じ実験を行えば、「分割読み戦略」がモデル固有のものかアーキテクチャ的な設計選択なのかが明確になる。
さらに大規模化も重要な変数だ。今回の最大文書は68ページだが、数百ページに及ぶ年次報告書や法令全集ではどうなるか。コンテキストウィンドウの上限に近づいたとき、各モデルの読解戦略はどう変化するか。
最後に変換ツールの比較だ。今回はMarkitdownを使ったが、他のPDF-Markdown変換ツール（Docling、LLMSherpa、Unstructuredなど）との比較も、変換品質が読解精度に与える影響を明らかにする上で意味がある。
まとめ
実験から導かれる実務的な指針を整理する。
Claude Sonnet 4.6を使う場合、PDFとMarkdownの差は小さく、どちらでも高精度の読解が期待できる。ただし68ページ級の文書では約78,000トークンを消費するコストは考慮が必要だ。
Gemini 2.5 Proを使う場合、網羅指示（分割読み指示＋カテゴリ明示）を必ず付けることが前提条件になる。指示なしでは大幅に性能が落ちるが、指示を適切に設計すればClaudeと同等の精度を大幅に低いコストで実現できる。
Gemini Flashは細則が多い法令・要綱の処理には適さない。構造誤読のリスクがあり、大きなMarkdownファイルでは処理時間も膨れる。要約や概要把握など、精度より速度を優先する用途に限定すべきだ。
そして採点・評価を自動化する際には、必ず複数の異なるモデルを採点官として使い、バイアスを相殺する設計にすること。自己評価は定量的には有意でない。
実験は2026年4月時点の各モデルの挙動に基づく。モデルのアップデートにより結果が変わる可能性がある。