Claude Vision OCRの精度は日本語PDFで足りるか — 測り方と誤読の切り分け

Claude Vision OCRの精度は、日本語PDFで何%と言えるのか

結論から言うと、日本語PDFの読み取り精度を示す公式の数値はありません。PDF対応ページにもVisionページにも、言語別の正解率は載っていないためです。使えるかどうかは、自分の帳票で項目別に測って決めます。

ClaudeでPDFを読ませるときは、PDFをそのままdocumentブロックで渡します。Claude APIならbase64かURL、Files APIの file_id で渡せます。1リクエストあたりのページ上限は600ページ(コンテキストウィンドウが100万トークン未満なら100ページ)です。

Claude VisionのPDF処理は日本語専用のOCRエンジンではない

Claude VisionはPDFの各ページを画像に変換し、そのページから抽出したテキストを画像に添えてモデルに渡します。専用のOCR(光学文字認識)エンジンの出力を返すのではなく、ページ画像とテキストを合わせて読んで回答するしくみです。

調達書類で項目別に測った例は不使用証明書の回収漏れ確認にあります。

この記事では、誤読が出たときに原因を切り分ける表、画像の縮小とトークン消費の数字、項目別の正解率を測る手順の順に扱います。

誤読の症状から原因を切り分ける

読み取り結果がおかしいとき、プロンプトを直す前に疑う順番があります。公式の2つのページを突き合わせると、原因は「経路」「画像の条件」「リクエストの規模」に分けられます。

表の上2行は、モデルの読み取り能力ではなく入力の側に原因があるケースです。モデルを替える前に、入力の条件を先に確かめる価値があります。

精度を左右する画像の縮小とトークン消費

PDFの各ページは画像として扱われるため、画像の縮小ルールがそのまま日本語の読みやすさに響きます。

画像は28×28ピクセルのパッチ単位で数えられ、トークン数は ⌈幅/28⌉ × ⌈高さ/28⌉ です。長辺の上限は、Claude 4.7以降のモデルが2576px、それ以外のモデルが1568pxです。上限を超える画像は縦横比を保ったまま縮小されます。

縮小の条件は、長辺だけではありません。視覚トークンの上限(標準は1,568、高解像度は4,784)を超えても縮められます。たとえば2000x1500pxのスキャンは、長辺が2000pxでも標準ティアでは1269x952pxになります。高解像度ティアなら縮小されず、3,888トークンです。

1枚あたりの上限は、寸法が8000x8000pxです。容量はClaude API直なら10MB、BedrockとGoogle Cloudでは5MBで、どちらもbase64換算です。

単価との組み合わせで見ると、1000x1000pxの画像は1,296トークンです。Visionページの換算例では、標準ティアのClaude Haiku 4.5($1/百万トークン)なら1,000枚あたり約$1.30、高解像度ティアのClaude Opus 5($5/百万トークン)なら約$6.48です。これは例として挙がっている組み合わせで、実際に使うモデルの単価は料金ページで確かめ、トークン数×単価÷100万で置き換えます。縮小の強さと単価の両方が、モデル選びの材料になります。

細かい活字が密集した帳票では、この縮小で文字が潰れるかどうかが分かれ目になります。高解像度ティアは同じ画像でも最大で約3倍の視覚トークンを使うため、精細さが要らない用途では事前に縮小してコストを抑える、とVisionページは述べています。

1回のリクエストに画像が20件を超えると、すべての画像により厳しい寸法上限がかかります。これはプラットフォームを問わない仕様です。数えられるのは、前のターンから再送した画像も含めた全件です。BedrockとGoogle Cloudでは、PDFなどのdocumentブロックもこの件数に入ります。上限を超えた画像は、メッセージに「many-image requests」を含む invalid_request_error で拒否されます。回避するには、各画像を縦横とも2000px以下に縮めるか、画像とdocumentブロックを20件以内に抑えます。複数の帳票を1回の会話にまとめて再送し続ける運用は、この数え方に当たります。

PDF対応ページの見積もりでは、1ページあたり1,500〜3,000トークンのテキストに、画像分のトークンが加算されます。密度の高い帳票が多いと、600ページ(コンテキストウィンドウが100万トークン未満なら100ページ)の上限より前に失敗することがあり、その場合は分割が勧められています。

画像の圧縮も見落としやすい要因です。JPEGやWebPの強い圧縮はアーティファクト(ノイズ状の劣化)を生み、文字が読みにくくなることがあります。とくに圧縮を重ねるほど影響が大きくなるため、実際にAPIへ送る画像を目で確かめるよう、Visionページは求めています。スキャン後に何度もJPEGで保存し直す運用は、ここで見直せます。

帳票の種類ごとに検証の優先度を変える

帳票の特徴によって、誤読が出たときの確認箇所が変わります。ドキュメントに帳票別の精度は書かれていないので、次の表は「どこを重点的に見るか」の整理であり、精度の予測ではありません。

1種類の帳票だけで「使える/使えない」を決めると、別の種類で想定外の誤読に出会います。

Amazon Bedrock経由ではモードの確認が先になる

Bedrockを使う場合は、精度検証の前に確認する分岐があります。Opus 4.6以前のBedrock経路でConverse APIを使うと、PDFの処理モードが2つに分かれます。

citationsを有効にしないとConverse Document Chatが自動で使われます。Bedrock経由で罫線や印影まわりの読み取りが弱いと感じたら、まずcitationsの設定を確かめてください。InvokeModel APIにはこの制約がなく、citationsなしでも視覚理解のモードを使えます。

自社の帳票で検証する手順

1件ずつ処理するときは、Files APIでPDFをアップロードして file_id で参照すると、リクエストを小さく保てます。

FILE_ID=$(curl -sS -X POST https://api.anthropic.com/v1/files \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -F "file=@invoice_sample01.pdf" | jq -r '.id')
 
curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d "{
    \"model\": \"claude-opus-5-5\",
    \"max_tokens\": 1024,
    \"messages\": [{
      \"role\": \"user\",
      \"content\": [
        {\"type\": \"document\", \"source\": {\"type\": \"file\", \"file_id\": \"$FILE_ID\"}},
        {\"type\": \"text\", \"text\": \"この請求書から取引先名・請求金額・発行日・品目をJSON形式で抽出してください。\"}
      ]
    }]
  }"

アップロードの詳細はFiles APIでPDFを処理する方法にあります。

検証サンプルをFiles APIに置くときの制約

Files APIはClaude APIとClaude Platform on AWSで使えますが、Amazon BedrockとGoogle Cloudでは提供されていません。Bedrockで検証する場合、上の手順はそのままでは使えません。

Files APIの制約のうち、検証の運用に響くのは次の点です。

• Files APIはゼロデータ保持(ZDR)の対象外です。請求書や領収書のような機微な帳票を置くときは、この点を先に確かめます
• アップロード時に expires_in_seconds を付けると、ファイルを自動で失効させられます。値は3,600〜7,776,000秒(1時間〜90日)の整数で、削除したファイルは復元できません
• 1ファイルの上限は500MB、組織全体の保存容量は1TBです。上限を超えると413、コンテキストウィンドウに収まらないファイルを使うと400で失敗します
• リクエスト全体は32MBが基準で、密度の高いPDFはFiles APIを使っても、ページ数の上限より前に失敗することがあります
• アップロードしたファイルはダウンロードできません。元のスキャンは手元に残します

大きなPDFで検証が止まったら、ページの分割から試します。どのファイルIDがどの帳票かは自分で控えておくと、誤読したサンプルの再現に戻りやすくなります。

抽出結果を正解値と突き合わせる

手順4の集計は、正解JSONと抽出JSONを項目ごとに比べるだけで足ります。ここで効くのが正規化です。全角数字・カンマ・円記号の違いを先に揃えないと、読み取りは合っているのに不一致と数えてしまいます。

import json, sys, unicodedata
 
def norm(v):
    return unicodedata.normalize("NFKC", str(v)).replace(",", "").replace("¥", "").replace("円", "").strip()
 
expected = json.load(open(sys.argv[1]))
extracted = json.load(open(sys.argv[2]))
for f in ["取引先名", "請求金額", "発行日"]:
    ok = sum(norm(e[f]) == norm(x.get(f, "")) for e, x in zip(expected, extracted))
    print(f"{f}: {ok}/{len(expected)}")

ダミーの3件(請求金額の1件だけ 9,800 を 9,600 と誤読した想定、もう1件は ¥128,000円 と記号付きで返った想定)で実行すると、次のように出ます。

取引先名: 3/3
請求金額: 2/3
発行日: 3/3

記号付きの ¥128,000円 は正規化で一致扱いになり、数字そのものが違う1件だけが誤りとして残ります。これはモデルを呼ばない集計スクリプトの動作確認で、Claudeの精度を示す数字ではありません。

画質を整える工夫と、精度の限界は別の話

PDF対応ページは、標準的なフォントを使う、文字が明瞭であること、ページを正しい向きに揃える、PDFを本文より前に置く、といった点を挙げています。スキャン設定を変えられない帳票なら、次が現実的です。

• 向きを揃えてから渡す: スキャナーやアプリで回転を解消してから送る。回転画像は制限事項に挙がっている
• プロンプトでページを指定する: 複数ページのPDFでは、PDFビューアー上のページ番号で範囲を指定する
• 大きなPDFは分割する: 密度の高いPDFは上限前に失敗することがある
• キャッシュで再質問を安くする: 同じ帳票に項目を変えて何度も聞くなら、cache_control でPDFをキャッシュできる

どれも入力の画質を整える話で、モデルの日本語読み取り能力を変える設定ではありません。画質を直しても精度が上がらないときは、読み取りの限界か、帳票の特徴に合った検証ができていないかのどちらかです。

見落としやすい落とし穴

印影と文字の重なり: 角印・丸印が金額や取引先名に重なる帳票は、検証項目に必ず含めてください。印影を想定した記述はドキュメントにないので、重なった部分の扱いは自分のサンプルで見るしかありません。

抽出後の正規化: 全角と半角の数字が混在する帳票では、JSONの値をそのまま計算に使うと不一致の原因になります。前節のスクリプトのように、比較や集計の前に正規化を挟みます。

元がテキストならPDFにしない: 会計システムのCSVやテキストの明細をPDFに変換して渡すと、画像として再処理される分だけ余計な経路が増えます。.txt・.csv・.mdは、Files APIにMIMEタイプ text/plain でアップロードし、file_id で参照すればそのまま扱えます。.xlsxや.docxはdocumentブロックでは使えず、テキストかPDFへの変換が要ります。検証の対象は、画像・スキャンでしか手に入らない帳票に絞れます。

同じ質問の結果は1回で決めない: 同じPDFへの同じ質問で結果が毎回一致する保証は、ドキュメントに書かれていません。境界線上のサンプルは複数回試し、ブレの有無を記録しておくと、導入後の想定外を減らせます。

まとめ

日本語の帳票の精度は公式にも数値がなく、項目別の正解率を自分で測るしかありません。誤読が出たら、プロンプトの前にBedrockのモード、画像の縮小、画質の3点を順に確かめるのが近道です。

PDF読み込みの基礎はClaudeのPDF読み込み・画像解析の使い方、添付時のエラーはClaude Code PDFエラー一覧で扱っています。