AIにPDFを読ませるときの注意点｜表・画像・スキャンPDF

PDFをAIへ渡して「要約して」と頼むだけなら簡単です。

でも、契約書、論文、決算資料、マニュアルのように数字・表・グラフ・図解まで正確に読みたい場合は、PDFなら何でも同じように読めると考えない方が安全です。

同じPDF形式でも、中身が文字データなのか、画像なのか、スキャンなのかでAIが受け取れる情報が変わります。サービスによってはPDF内の画像を見る機能にも条件があります。

先に結論を言うと、PDFをAIに読ませるときは、まず

文字PDF / 表・図入りPDF / スキャンPDF

のどれかを確認します。

そのうえで、「本文だけ読めればいいのか」「図表まで必要か」を決めるのが一番分かりやすいです。

結論：PDFは「ファイル形式」より中身を見る

PDFは見た目が同じでも、内部構造がかなり違います。

表は横にスクロールできます

PDFのタイプ	中にある情報	注意点
テキストPDF	選択できる本文文字	比較的扱いやすいが、段組みや脚注で順序が崩れることがある
表・図入りPDF	本文＋表＋グラフ＋画像	テキスト抽出だけでは視覚情報が落ちる場合がある
スキャンPDF	ページ全体が画像	文字層がなければOCRまたは視覚処理が必要
複雑なレイアウト	複数段、注釈、欄外、吹き出しなど	読む順番や対応関係が崩れやすい

まずここを分けます。

「PDF対応」と書かれているだけでは、ページ内の文字を抽出するだけなのか、ページ全体を画像として理解するのかまでは分かりません。

1. 普通のテキストPDFは比較的読みやすい

WordやGoogle Docs、DTPソフトなどから書き出されたPDFでは、本文が文字データとして入っていることが多いです。

PDFビューアで文章をドラッグしてコピーできるなら、文字層を持っている可能性が高いです。

このタイプは、

• 要約

• キーワード抽出

• 条項の検索

• 複数ページをまたいだ質問

• 固有名詞や数字の抽出

などに使いやすいです。

ただし「文字が取れる＝構造も完全に分かる」ではありません。

2段組みの論文、ページをまたぐ表、脚注、欄外注記などでは、テキストを抽出した順番が人間の読む順番と一致しないことがあります。

重要資料では、答えだけでなく該当ページと根拠箇所も出させた方が確認しやすくなります。

2. 表は「文字が取れた」だけでは足りない

PDFの表は少し厄介です。

人間は、行・列・見出し・罫線・セル位置を同時に見て意味を理解します。

一方、PDFから単純に文字だけを抜き出すと、

「商品A 100 120 商品B 80 90」

のように並び、どの数字がどの列へ属するのか分かりにくくなることがあります。

特に注意したいのは、

• 横に長い表

• セル結合が多い表

• 複数ページに続く表

• 縦書き・回転文字

• 小さな注釈付きの表

です。

数字を使う仕事なら、「表を要約して」だけで終わらせず、

1. 表の見出しを列挙する

2. 指定した行だけ抜き出す

3. 数値と単位をセットで出す

4. ページ番号を付ける

5. 元PDFと照合する

という流れにした方が安全です。

表データを本格的に集計するなら、元のExcelやCSVがある場合はPDFよりそちらを使う方が扱いやすいこともあります。

3. グラフや図は「PDF内画像を見ているか」が重要

決算資料や調査レポートでは、結論がグラフにしか書かれていないことがあります。

本文には「下図の通り」としかなく、実際の増減率や系列の違いはグラフを見ないと分からないケースです。

ここでPDF処理がテキスト抽出だけだと、AIは本文を読めてもグラフそのものを見ていない可能性があります。

2026年10月7日に確認した公式仕様でも、主要サービスの扱いは異なります。

ChatGPT

OpenAIの公式FAQでは、PDF内の画像、グラフ、図などを読むVisual Retrievalは現在ChatGPT Enterprise向けです。

しかもEnterpriseでも、GPT KnowledgeやProject Filesとして置いたPDFはテキストのみの処理になり、会話中にアップロードしたPDFなどではVisual Retrievalが使われる、という条件があります。

つまり「ChatGPTにPDFを置いた」だけでは、常に図表まで見ているとは限りません。

Claude

Anthropicの公式ヘルプでは、100ページ以下のPDFについてテキストと画像・チャート・グラフィックスなどの視覚要素を分析すると説明されています。

101〜1000ページのPDFではテキストのみを処理します。

ここも重要です。

同じClaudeでも、90ページの資料と300ページの資料ではPDF内ビジュアルの扱いが変わります。

Gemini

Google AI for DevelopersのGemini API公式ドキュメントでは、PDFをネイティブな視覚入力として扱い、テキスト、画像、図、グラフ、表を理解できると説明されています。

APIではPDFは最大50MBまたは1000ページまでです。

一方、Gemini Apps側は動画以外の対応ファイルが1ファイル100MBまでなど別のアップロード条件があります。

アプリとAPIの上限を混ぜないようにします。

この比較は「どのAIが一番PDFに強い」という順位ではありません。

どの経路でPDFの視覚情報まで処理されるかの仕様差です。

4. スキャンPDFは「文字が入っていない」ことがある

紙の資料をスキャナーで取り込んだPDFは、ページ全体が画像になっていることがあります。

見た目は文章でも、内部には文字データがありません。

PDFビューアで文章をドラッグしても文字を選べないなら、このタイプの可能性があります。

この場合、テキスト抽出型の処理では本文をうまく取得できません。

必要なのは、

• OCRで画像から文字を起こす

• PDFページ自体を視覚的に処理する

• 必要ページを画像として渡す

のどれかです。

OCRは、画像に写った文字をテキストへ変換する処理です。

ただしOCRを通せば必ず正確になるわけでもありません。

小さい文字、傾いた紙、かすれ、手書き、縦書き、特殊な表では読み間違いが起こります。

スキャンPDFでは、AIの回答だけでなくOCR結果そのものも検証対象です。

5. 「スキャンだけど読めた」は視覚処理かOCRかもしれない

AIがスキャンPDFへ答えられたとしても、その仕組みは1つとは限りません。

サービス側でOCRしている場合もあれば、マルチモーダルモデルがページ画像を直接見ている場合もあります。

ユーザー側から内部処理を完全に確認できないケースもあります。

そのため重要書類では、

「このPDFの3ページ目の見出しをそのまま抜き出して」

「7ページの表にある列名をすべて列挙して」

のように、まず取得確認をします。

正しく拾えてから要約や判断を頼む方が安全です。

6. 100ページ読めることと、100ページを正確に理解することは別

サービスのページ上限は、主に受け付けられる量の条件です。

1000ページまで対応しているからといって、1000ページの全項目を同じ精度で覚え、どんな質問にも完全に答えられることを保証する数字ではありません。

長いPDFでは、

• 重要箇所が埋もれる

• 同じ用語が複数の意味で使われる

• 前半と後半で条件が変わる

• 別冊・付録・脚注に例外がある

といったことがあります。

大きな資料ほど、

「全部読んで要約」

より、

「まず目次を整理 → 関係ページを特定 → その範囲を詳しく読む」

の方が確認しやすくなります。

7. ページ番号はPDFビューア基準で指定する

紙の資料では、表紙をページ数に含めなかったり、本文に「1」「2」と印刷されていてもPDF上では3ページ目だったりします。

Anthropicの公式ヘルプでも、特定ページを参照するときは、文書に印刷されたページ番号ではなくPDFビューアに表示されるPDFページ番号を使うよう案内しています。

これは他サービスで作業するときにも実用的です。

「資料の12ページ」ではなく、

「PDFビューア上の12ページ」

と指定すると、どのページを見ているのか合わせやすくなります。

8. 長いPDFは分割した方がよい場合がある

ページ上限以内でも、目的が一部分だけなら全部渡す必要はありません。

たとえば600ページのマニュアルから、決済APIの設定だけ確認したいなら、その章だけ切り出した方が質問の範囲を固定できます。

特に、

• スキャンPDF

• 図が多い資料

• 複数ページにまたがる表

• 同じ言葉が章ごとに違う意味で使われる資料

では、対象ページを絞るメリットがあります。

ただし分割すると前後の条件を落とすこともあるので、目次・定義・注意事項など必要な前提ページは一緒に残します。

9. PDF内の数字は必ず根拠ページまで戻る

AIへPDFを読ませる用途で一番注意したいのは、数字をそのまま転記する場面です。

たとえば、

• 売上高

• 利益率

• 契約期間

• 金額

• 人数

• 調査結果の割合

• 法令や規約の条件

です。

ここは要約の自然さより、元PDFとの一致が重要です。

AIには、

「結論、根拠となる原文、PDFページ番号をセットで出して」

と頼みます。

表なら行名・列名・単位も付けます。

そして最終的には元PDFを開いて確認します。

AIが自信ありげに答えたかどうかは、検証基準にはしません。

PDFを渡す前のチェックリスト

まずPDFを開きます。

文字を選択できるか。

重要情報は本文か、それとも図表か。

スキャン画像だけのページがあるか。

ページ数はいくつか。

そして使うAI側で、

• そのページ数を受け付けるか

• PDFの画像・図まで処理するか

• アプリとAPIで条件が違わないか

• ProjectsやKnowledgeに置いた場合も同じ処理か

を確認します。

アップロード後は、いきなり結論を聞かず、まず重要ページを正しく認識できているか小さく試します。

実務で使いやすい5ステップ

1. PDFの種類を確認する

   文字PDFか、スキャンか、図表中心かを見ます。

2. AIが視覚情報まで扱う経路か確認する

   「PDF対応」だけで判断しません。

3. 最初に取得テストをする

   見出し、固有名詞、ページ番号、表の列名などを抜き出させます。

4. 対象ページを絞って質問する

   長い資料ほど範囲を指定します。

5. 重要な数字・条件は元PDFへ戻る

   契約、料金、法律、決算などは特にここを省きません。

この順番にすると、PDFを「読ませたつもり」で進む事故を減らせます。

AIものさし編集部の判断

AIにPDFを読ませるとき、一番大事なのはPDFという拡張子ではなく、その中で情報がどう持たれているかです。

本文文字ならテキスト処理で足りることがあります。

表・グラフ・図解が重要なら視覚処理が必要です。

スキャンPDFならOCRまたはページ画像の理解が必要になります。

そして現在は、ChatGPT、Claude、GeminiでPDF内ビジュアルを扱う条件が同じではありません。

だからPDF比較では、

アップロード可否 → 文字取得 → 視覚処理 → ページ条件 → 根拠確認

の順に見ます。

「ファイルが送れた」ことを、読解完了の証拠にはしない。

これを押さえるだけで、PDFを使ったAI作業はかなり安定します。

自分の条件なら？

「決算資料のグラフを読みたい」「紙をスキャンした契約書を確認したい」「数百ページのマニュアルを扱いたい」など用途が決まっている場合は、AIものさしの比較ページでPDFの容量だけでなく、視覚処理・ページ上限・利用経路まで分けて確認できます。