3行でいうと

  • ClaudeとOpenAIは、PDFを「各ページの画像」と「取り出した文字」の両方でモデルに渡す。Geminiも画像として読む。
  • 上限は会社ごとに違う。Claudeは32MB・最大600ページ、OpenAIは1ファイル50MB未満、Geminiは50MBか1,000ページ。
  • 専用サービスは、単語や項目ごとの信頼度スコアと位置情報を返す。AIの直読みは、JSONの形は守らせられるが、値の正しさは保証されない。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書を読んでまとめたものです。価格の話は、この記事では扱っていません（料金は別の記事を見てください）。数字は2026年10月22日に確認したもので、変わることがあります。

先に結論

見立てです。帳票の抽出は、次の三つの道具の組み合わせで考えると整理しやすいと思います。

  1. OCR（Optical Character Recognition、画像の中の文字を文字データに変える技術）。文字を読むだけで、意味は理解しません。
  2. レイアウト解析。ページのどこが見出しで、どこが表で、どこがチェック欄かという「構造」を取り出します。
  3. AIの直読み。PDFを大規模言語モデル（LLM、文章を読み書きするAI）に渡して、「請求番号と合計金額を取り出して」と頼みます。

公式文書を読むかぎり、1と2は専用サービスが得意な領域として説明され、3は「構造化出力」という機能とあわせて、抽出の例が載っています。どれか一つを選ぶというより、対象の帳票が「決まった様式か、毎回違うか」「間違いをどれだけ許せるか」で組み合わせが変わると思います。

前提：何を取り出したいのか

「PDFから情報を取り出す」は、実際には次のように分かれます。

道具によって得意な段階が違います。以下、この順に読んでいきます。

AIにPDFを直接渡す方式

Claude（Anthropic）

公式文書によると、Claudeは次の流れでPDFを処理します。

  1. 各ページを画像に変換する。
  2. 各ページから文字を取り出し、そのページの画像と一緒に渡す。
  3. 文字と画像の両方をもとに、グラフや図も含めて理解する。

つまり、文字だけでなく、ページの見た目も読む方式です。上限は次のとおりです。

項目 上限
1リクエストの大きさ 32MB（プラットフォームで変わる）
1リクエストのページ数 600ページ（文脈窓が100万トークン未満のときは100ページ）
形式 標準のPDF（パスワードや暗号化なし）

「文脈窓」は、モデルが一度に扱える文章量の上限です。「トークン」は、AIが文章を数える単位です。公式文書は、1ページあたり通常1,500〜3,000トークンと書いています。ページ数が少なくても、文字が小さく表や図が多いPDFは、上限に達する前に文脈窓がいっぱいになることがある、と注意されています。対策として、文書を分割すること、埋め込み画像を小さくすることが挙がっています。

PDFの渡し方は3通りです。URL、base64（バイナリを文字列にした形式）、Files API（ファイルを先に預けて、IDで参照する窓口）です。同じPDFを何度も使うときはFiles APIが向く、とされています。PDF専用の追加料金はなく、標準のAPI料金が適用されると書かれています。

OpenAI

公式文書によると、画像を読めるモデルでは、PDFから文字とページ画像の両方を取り出してモデルに渡します。上限は、1ファイル50MB未満、1リクエストの合計も50MB以下です。

PDFの画像の読み込みの細かさは、detailという設定（auto、low、high）で選べます。公式文書の説明では、lowにすると入力トークンが減り、highは細かいグラフ・小さい文字・図に向くとされています。文字は常に渡されるため、この設定は画像の部分にだけ効きます。なお、Chat Completionsという別の呼び出し方式では、この設定は使えません。既定はautoで、GPT-5.6以降のモデルではautoがhighとして、それより前のモデルではlowとして扱われる、と書かれています。

注意として、PDF以外のDocxやPPTXは文字だけが処理され、埋め込まれた画像やグラフは取り出されません。グラフを残したいなら、先にPDFに変換するよう勧められています。表計算ファイルは、1シートの最初の1,000行までです。

Gemini（Google）

公式文書によると、GeminiはPDFを「ネイティブなビジョン」で読み、文字・画像・図・グラフ・表を文書全体にわたって扱います。上限は50MBか1,000ページです。1ページは258トークン相当とされ、PDFに埋め込まれた文字から取り出した分のトークンには課金されない、とも書かれています。Files APIは無料で、預けたファイルは48時間保存されます。

3社のPDF直読みを並べた表
項目 Claude OpenAI Gemini
渡す内容 ページ画像＋取り出した文字 ページ画像＋取り出した文字 ページを画像として読む。埋め込み文字も取り出す
サイズの上限 32MB（リクエスト全体） 1ファイル50MB未満、合計50MB以下 50MB
ページの上限 600（文脈窓が100万未満なら100） 今回読んだページに記載なし 1,000
1ページのトークン 文字で通常1,500〜3,000。画像分は別 文字と画像の両方が文脈に入る。数字の記載は確認できていません 258
画像の細かさの設定 今回読んだページに記載なし detail（auto・low・high） media_resolution（low・medium・high）
ファイルを預ける窓口 Files API Files API（/v1/files） Files API（48時間保存）

この表は、各社の文書の記述を、僕らが並べ直したものです。数字の意味がそろっているとは限りません。たとえばClaudeの1,500〜3,000は「文字分」の目安で、Geminiの258は「1ページの相当量」です。単純な比較にはしないでください。

専用サービスの方式

Google Document AI

公式の一覧には、用途別の「プロセッサ」（処理の部品）が並んでいます。たとえば次のものです。

注目点は、Layout Parserの一部のバージョン（v1.5、v1.6、v3.1-lite。v1.5以降はPreviewと表示）が、PDFのレイアウト解析にGeminiモデルを使うと書かれていることです。専用サービスと生成AIの境目は、すでに溶けてきています。ただし、v1.6のようにデータの置き場所（データレジデンシー）の基準を満たさないものがある、とも注記されています。

Azure Document Intelligence（Microsoft）

文書の中身を取り出す、クラウドのOCR・文書処理サービスです。概要ページの現在の題は「Azure Document Intelligence in Foundry Tools」で、Azure Content Understanding の機能の一部として位置づけられ、注記では、LLMを使う解析も提供する Content Understanding との使い分けを案内するページへのリンクが付いています。公式文書では、次の型が並びます。

Layoutモデルについて、公式文書は次のように書いています。

Amazon Textract（AWS）

公式文書は、印刷と手書きの文字を取り出し、文書の中の項目と表も構造化して返すサービスと説明しています。主な機能は、文字の検出、フォーム・表の抽出、質問（Queries）で欲しい情報を指定する方法、請求書・レシート用のAnalyzeExpense、身分証用のAnalyzeID、住宅ローン書類を分類して振り分けるLending、です。1ページなら同期、複数ページなら非同期の処理になります。

今回読んだ概要ページには、信頼度スコアの記載は見つかりませんでした。詳細はAPI仕様書の確認が必要です。

構造化出力：直読みの出力を型に収める

AIの直読みで項目を取り出すときは、出力を「JSONスキーマ」（JSONの項目名と型を決めた設計図）で縛る機能が公式に用意されています。

ここで重要なのは、OpenAIの文書が示す区別です。この機能が保証するのは「形」であって、「値が正しいこと」ではありません。請求番号の桁を読み間違えても、形としては合格です。Claudeの文書でも、拒否や途中切れ（max_tokens）の場合は、スキーマに合わないことがあると書かれています。また、Claudeでは、引用機能（citations）と構造化出力は同時に使えず、APIがエラーを返します。

公式文書の例：構造化出力の呼び出し（Claude）

次は、Claudeの公式文書にある書き方の抜粋を、短く整えたものです。公式文書の例です。この記事では、実行していません。

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    messages=[...],
    output_config={"format": {
        "type": "json_schema",
        "schema": {
            "type": "object",
            "properties": {"name": {"type": "string"}},
            "required": ["name"],
            "additionalProperties": False,
        }}},
)

スキーマで使えない制約もあります。公式文書では、minimum、maximum、minLength、maxLengthなどは未対応と書かれています。SDKの補助機能は、これらを送るスキーマから取り除いて、項目の説明に移し、返ってきた値を後から検証する、とされています。

使い分けの見立て

見立てです。公式文書から読み取れる違いを、判断の軸にまとめます。

状況 向いていそうな方式 理由（文書から読めること）
様式がばらばらの書類を、少量、柔軟に読みたい AIの直読み＋構造化出力 画像と文字の両方を読み、質問に答えられる。形はスキーマで揃えられる
同じ様式を大量に、位置情報つきで処理したい 専用サービス（Document AI、Document Intelligence、Textract） 構造（表・項目）と位置を返す。単語などに信頼度が付く（Azureの文書で確認）
結果を人が確認する前提で、怪しい箇所だけ見たい 専用サービスの信頼度スコア 今回読んだAIの直読みの文書には、値ごとの信頼度スコアの説明は見つかりませんでした
検索や質問応答のため、文書を塊に分けたい Layout Parserのような、チャンク化機能 Document AIの文書にチャンク生成の説明がある

つまずきやすい点

気をつけること

出典

更新履歴