AIにPDFを渡しても読めないとき──「文字のPDF」か「画像のPDF」かを自分で見分ける

結論から書く。AIにPDFを渡して「内容が読み取れません」「白紙のようです」と返るとき、疑うべきはAIの性能ではなくそのPDFに文字データが入っているかどうかだ。見た目が同じ書類でも、文字が文字として入っている「文字のPDF」と、紙をスキャンした写真が貼ってあるだけの「画像のPDF」がある。渡す前に見分ける手順を置き、判定結果ごとに次の一手を分ける。

3行まとめ

1. 判定はPDFビューアで本文をドラッグする10秒のテスト1つ。文字を選択できれば文字のPDF、絵のように四角く反転するだけなら画像のPDF
2. 確定させるなら poppler の pdffonts と pdftotext。当サイトの実測では、文字のPDFがフォント34行・1ページ目2,899バイト、同じページを画像化したPDFはフォント0行・1バイトだった
3. AI側の上限にも公式の明記がある。OpenAIのFile inputsは1ファイル50MB未満、Anthropicは1リクエスト32MB・最大600ページ

なぜPDFが「読めません」と返ってくるのか

PDFという拡張子は中身の作り方を1つに縛らない。文字のPDFはWordやGoogleドキュメント、ブラウザの「PDFとして保存」から作られたもので、文字が文字コードとして格納されている。画像のPDFは複合機のスキャン、書類をスマホで撮った写真のPDF化、FAXの電子化などで、中身はページ全面を覆う1枚の画像だ。人間の目には文字が見えるが、データとしては文字が1つも入っていない。

AI側の処理は公式ドキュメントにある。OpenAIの「File inputs」によれば、PDFはvision対応モデル（gpt-4o以降）に対して抽出したテキストとページ画像の両方が送られる。Anthropicの「PDF support」も、各ページを画像に変換したうえで各ページから抽出したテキストを画像と並べて渡すと明記している。

つまり画像のPDFでもページ画像としては届くので、読み取りが完全に不可能なわけではない。ただし届くのは空の文字データと画像だけで、小さな文字・薄い印字・傾いたスキャンでは精度が落ちる。

10秒で判定する──本文をドラッグしてみる

道具の追加は要らない。手元のPDFビューア（macOSのプレビュー、Adobe Acrobat Reader、ChromeにPDFをドラッグしても可）で開き、本文の一行をマウスでなぞる。

• 文字が1文字ずつハイライトされ、コピーして貼り付けられる → 文字のPDF
• 文字に反応せず四角い範囲が反転するだけ／コピーしても何も貼り付かない → 画像のPDF

一段確実にするなら、ビューアの検索（Cmd+F / Ctrl+F）でそのページに実際に見えている単語を打ち込む。ヒットすれば文字が入っている。ドラッグより誤判定が少ない。

コマンドで確定させる──pdffontsとpdftotext

大量のPDFをさばくときやページ別に調べたいときはコマンドが早い。PDFレンダリングライブラリ Poppler に同梱される pdffonts（使用フォントの列挙）と pdftotext（プレーンテキストへの変換）を使う。いずれも公式のman pageがあるが、WindowsやmacOSには標準で入っておらず別途インストールが要る。

実際に測った。素材は文字のPDF（arXivで公開されている論文PDF「Attention Is All You Need」、2,215,244バイト、PDF 1.5）と、その1ページ目を150dpiでPNG化して再度PDFに変換した画像のPDFの2つ。

画像のPDFで pdftotext が返した1バイトは改ページ文字だけで、本文は1文字も取れていない。pdffonts は見出し行だけを出力してフォントを1件も列挙しない。

ページ別に調べるなら1ページずつバイト数を出す。文字のPDFで1〜6ページ目を測ると 2,899 / 4,269 / 1,831 / 2,545 / 3,233 / 3,512 バイトと並び、極端に少ないページがない。ここに数バイトのページが混ざっていれば、そのページだけスキャン画像である可能性が高い。

判定結果ごとに次の一手が変わる

画像のPDFだった場合はOCR（画像から文字を起こす処理）が要る。手近な選択肢のGoogleドライブは推奨条件としてファイル2MB以下、文字の高さ10ピクセル以上、正しい向き、Arial や Times New Roman などの一般的なフォント、コントラストのはっきりしたシャープな画像を挙げており、対応言語に日本語も含まれる。量が多い場合や帳票の項目単位で抜きたい場合は専用ツールの領域なので、AI OCR 文字認識ツールの比較記事を参照してほしい。社外秘を含む書類を外部サービスへ上げる前には生成AIに個人情報を入力して大丈夫かも確認したい。

公式ドキュメントに書かれている上限

文字のPDFなのに読めない場合は、サイズやページ数の上限に当たっている可能性がある。2026年8月27日時点で各社の開発者向けドキュメントにある値は次の通り。

Anthropicはトークン消費の目安を1ページあたり1,500〜3,000トークンとし、密度の高いPDFはページ数上限に達する前にコンテキストを埋め切ることがあると注意している。精度を上げる推奨として、標準的なフォントを使う・文字を明瞭にする・ページを正しい向きに回転させる、も挙がっている。

もう1点、PDF以外を渡すときの注意もある。.docx や .pptx、.txt などPDF以外の書類ファイルはテキストのみが抽出され、埋め込まれた画像やグラフはモデルのコンテキストに入らない。図を読ませたいならいったんPDFに変換してから渡すよう明記されている。資料の渡し方自体を見直すならAIに資料を頼むなら「HTMLで」と言う、長文の要約用途ならAI要約ツールの比較がある。

判定を誤らせる3つのケース

この手順が見ているのは「文字が入っているか」であって「文字が正しいか」ではない。

正直に書く──この手順で分からないこと

①文字が入っていても、AIが正しく構造を読むとは限らない。 多段組・複雑な表・脚注は、文字として取り出せても読み順が崩れる。pdftotext に読み順を制御する -layout や -raw があること自体、抽出順が一意に決まらないことの裏返しだ。Googleドライブのヘルプも「リスト、表、列、脚注、巻末の注などは、検出されない可能性があります」と書いている。

②本記事の数値は開発者向けAPIドキュメントの記載であり、ChatGPTやClaudeのアプリ画面から上げたときの上限とは別物の可能性がある。 消費者向けヘルプセンター（help.openai.com）は今回の取材でHTTP 403が返り取得できなかったため、アプリ側の上限は書いていない。また掲載した上限値は2026年8月27日時点の記載で、モデル更新に伴って変わる。

③実測した2件は当サイトが用意した検証用のPDF2ファイルにすぎない。 あらゆるPDFで同じ差が出ることを保証するものではなく、判定の当たり外れの割合を測ったものでもない。手順の出力がどう見えるかの実例として読んでほしい。

各社の仕様書と、poppler-utilsによる自社実測

• OpenAI「File inputs」（開発者向けドキュメント）: https://developers.openai.com/api/docs/guides/file-inputs
• Anthropic「PDF support」（Claude Docs）: https://docs.claude.com/en/docs/build-with-claude/pdf-support
• Google ドライブ ヘルプ「PDF や写真のファイルをテキストに変換する」: https://support.google.com/drive/answer/176692?hl=ja
• pdffonts man page（poppler-utils）: https://www.mankier.com/1/pdffonts
• pdftotext man page（poppler-utils）: https://www.mankier.com/1/pdftotext
• Poppler 公式サイト: https://poppler.freedesktop.org/

各社ドキュメントの記載内容は2026年8月27日に確認したもので、仕様・上限値は予告なく変更される。記事中の実測値は当サイトが同日に pdffonts / pdftotext / pdfimages（poppler-utils 26.06.0、pdftotext -vで確認）で取得した。特定のPDFやサービスでの読み取り成功を保証するものではない。