Claude Media
Claude VisionでOCRした日本語PDFの精度をどう見極めるか
Anthropic解説

Claude VisionでOCRした日本語PDFの精度をどう見極めるか

Claude Visionは日本語PDFを画像とテキストの両方で処理します。精度を左右する要因と、請求書・領収書など自社の帳票で精度を検証する手順をまとめました。

読了目安 約12分

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

Claude VisionはPDFの各ページを画像に変換し、そのページから抽出したテキストと画像の両方をモデルに渡します。専用のOCR(光学文字認識)エンジンを介さず、ページ画像をそのまま読み取って回答するしくみです。日本語の請求書や領収書のように、罫線・印影・手書き文字が混在する帳票では、この「画像として読む」という前提が精度を大きく左右します。

処理は3段階で進みます。各ページを画像に変換しテキストを抽出、テキストと画像の両方を分析、画像内の図表・レイアウトも踏まえて応答する、という順です。日本語に特化した精度の数値は公開されていません。「何%読み取れるか」を断定できる一次ソースは存在せず、自分の帳票で検証する以外に確かめる方法がないのが実情です。

精度を左右する3つの技術的な制約

ドキュメントが明示する制約を押さえると、検証すべきポイントが絞れます。

解像度の上限: 画像は長辺2576px(Claude Opus 5などの高解像度対応モデル)または1568px(それ以外のモデル)を超えると縮小されます。日本語の請求書は罫線の中に小さな文字が密集していることが多く、縮小されると文字が潰れて誤読の原因になります。スキャン時点の解像度だけでなく、モデル側の縮小後にどこまで文字が判読できるかを確認する必要があります。

低品質・小さい画像でのハルシネーション: 「200px未満の非常に小さい画像、回転した画像、低品質な画像を解釈するときにハルシネーションや誤りが起きうる」とドキュメントには明記されています。スキャナーの設定が粗い、あるいはスマートフォンで斜めに撮影した領収書は、この条件に該当しやすくなります。

ページ単位のトークン消費: 1ページあたりのテキストトークンはページの情報密度で1,500〜3,000程度、画像トークンは解像度に応じて別途加算されます。文字が密集した帳票を大量にまとめて送ると、ページ数の上限(600ページ、コンテキストウィンドウが100万トークン未満のモデルでは100ページ)に達する前に処理が失敗することもあります。

帳票の種類ごとにリスクの出方が違う

すべての帳票が同じように誤読しやすいわけではありません。罫線・印影・手書きの有無で、想定されるリスクの質が変わります。

帳票の特徴想定される誤読リスク検証で重点を置く項目
罫線あり・活字のみ想定される誤読リスク低い(構造が整理されている)検証で重点を置く項目桁数の多い金額欄
印影が金額・氏名に重なる想定される誤読リスク中〜高(文字の一部が隠れる)検証で重点を置く項目印影周辺の文字欠落
手書きの但し書き・訂正印想定される誤読リスク高い(活字より判読が難しい)検証で重点を置く項目手書き部分の抽出可否
スマートフォン撮影・斜め想定される誤読リスク高い(回転・低品質に該当)検証で重点を置く項目補正前後での差分

罫線だけの活字帳票であれば比較的安定した読み取りが期待できますが、印影の重なりや手書きが加わるほど検証の優先度を上げる必要があります。1種類の帳票だけを検証して「使える/使えない」を判断すると、他の帳票タイプで想定外の誤読に遭遇するリスクが残ります。

Amazon Bedrock経由だと結果が変わることがある

Amazon BedrockのConverse APIを使っている場合、精度検証の前に確認すべき分岐があります。Converse APIにはPDFの処理モードが2つあり、citations(引用)機能を有効にしていないと「Converse Document Chat」というテキスト抽出のみのモードが自動的に使われます。このモードは3ページのPDFで約1,000トークンしか消費せず、画像内のレイアウトや表を認識できません。

citationsを有効にすると「Claude PDF Chat」に切り替わり、各ページをテキストと画像の両方として処理する完全な視覚理解モードになります。同じく3ページのPDFで約7,000トークンを消費し、罫線・印影・レイアウトを含めた読み取りが可能になります。Bedrock経由でOCR精度が低いと感じた場合、まずcitationsが有効になっているかを確認する価値があります。これはモデルの読み取り能力そのものの問題ではなく、テキスト抽出のみのモードにフォールバックしていることが原因である可能性が高いためです。InvokeModel APIではこの制約がなく、citationsなしでも視覚理解モードを使えます。公式ドキュメントではこの挙動はOpus 4.6以前のBedrock経路の説明として記載されています。

自社の帳票で検証する具体的な手順

ベンチマークが存在しない以上、検証は自分でやるしかありません。以下は再現可能な手順です。

  1. サンプルを分類する: 請求書・領収書・見積書など帳票の種類ごとに、罫線あり/なし、印影の有無、手書き記入の有無で最低10件ずつ分ける
  2. 正解データを先に作る: OCR結果と突き合わせる正解値(取引先名・金額・日付・品目)を人手で先に確定しておく
  3. 同じプロンプトで一括処理する: 抽出したい項目をJSON形式で指定し、全サンプルに同一のプロンプトを使う(プロンプトを変えると精度差の原因が分からなくなる)
  4. 項目ごとに正解率を出す: 帳票全体の「合っている/間違っている」ではなく、金額・日付・取引先名など項目単位で正解率を集計する(全体が9割正しくても、金額だけ毎回ずれるなら実務では使えない)
  5. 誤読パターンを分類する: 数字の桁違い、全角/半角の混同、印影で隠れた文字の欠落など、誤りの型を分けて記録する
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\",
    \"max_tokens\": 1024,
    \"messages\": [{
      \"role\": \"user\",
      \"content\": [
        {\"type\": \"document\", \"source\": {\"type\": \"file\", \"file_id\": \"$FILE_ID\"}},
        {\"type\": \"text\", \"text\": \"この請求書から取引先名・請求金額・発行日・品目をJSON形式で抽出してください。\"}
      ]
    }]
  }"

大量の帳票を一括検証するなら、Files APIでPDFを処理する方法にアップロード手順をまとめてあるので、1件ずつ手作業でbase64化する代わりにこちらを使うと検証サイクルが速くなります。項目単位の正解率が出そろったら、桁違いや欠落が多い項目だけを抽出用プロンプトで補強する、といった改善サイクルを回せます。

精度を底上げする実務上の工夫

画質そのものに手を入れる方法として、標準的なフォントの使用・文字が明瞭であること・ページの向きを正しく揃えることが推奨されています。スキャン設定を変えられない帳票が相手のときは、次の工夫が現実的です。

  • 傾き補正を先にかける: スキャナーやスマートフォンのアプリで自動傾き補正を有効にし、モデルに渡す前に回転を解消する
  • 1ページに情報を詰め込みすぎない: 複数の帳票を1つのPDFにまとめず、1ファイル1帳票にすると個別の解像度低下を避けやすい
  • 論理ページ番号を明示する: 複数ページのPDFでは、プロンプト内でPDFビューアー上のページ番号を使って範囲を指定すると、目的のページの読み取り精度が上がりやすい
  • プロンプトキャッシュを使って同一帳票への再質問を効率化する: 同じ帳票に対して抽出項目を変えながら複数回問い合わせる場合、cache_control でPDFをキャッシュすると再送コストを抑えられる

これらはいずれも解像度や画質そのものを改善する話であり、モデル側の日本語読み取り能力を変える設定ではありません。画質を整える工夫と、読み取り精度そのものの限界は別の問題です。両方を混同すると、画質を改善したのに精度が上がらない原因を見誤ります。

見落としやすい落とし穴

ここまでの手順を踏んでも、検証項目のリストだけでは気づきにくい落とし穴がいくつか残ります。

印影と文字の重なり: 日本の請求書・領収書に特有の角印・丸印は、押印位置によっては金額や取引先名の一部と重なります。低品質画像に関する注記はこのケースを直接想定したものではありませんが、印影と文字が重なった部分は画像認識の観点で判読が難しい領域になりやすく、検証項目に必ず含めるべきポイントです。

全角・半角の混在: 日本語の帳票は全角数字と半角数字が混在することがあり、抽出したJSONの数値をそのまま計算に使うと桁がずれる場合があります。抽出後に正規化する処理を挟むことが安全です。

手書き文字の扱い: 手書きの但し書きや訂正印が入った領収書は、活字の帳票よりも誤読リスクが高くなります。手書き文字専用の言及はドキュメントになく、活字帳票と同じ「低品質・不明瞭な画像」の枠組みで扱われると考えるのが妥当です。

検証の運用面でも注意点があります。同じPDFに同じ質問を複数回投げても、抽出結果が毎回完全に一致するとは限りません。検証を1回だけで終わらせず、境界線上のサンプルは複数回試して結果のブレを確認しておくと、本番導入後の想定外を減らせます。また、会計システムから出力したCSVやテキストの明細をわざわざPDFに変換してから渡すと、画像として再処理される分だけ誤読のリスクを増やすことになります。プレーンテキストのファイル(.txt / .csv / .md)はFiles APIにMIMEタイプ text/plain でアップロードし file_id で参照すれば、画像変換を経ずにそのままテキストとして扱えます。読み取り精度を検証する対象は、あくまで元から画像・スキャンでしか手に入らない帳票に絞り込むのが合理的です。

まとめ

Claude VisionのPDF処理は日本語専用のOCRエンジンではなく、ページを画像として読み取る汎用の仕組みです。日本語の読み取り精度を数値化したベンチマークは存在しないため、「精度がどれくらいか」は自社の帳票で項目単位の正解率を測るしかありません。解像度の上限・低品質画像でのハルシネーション・ページ単位のトークン消費という3つの制約を踏まえたうえで、帳票の種類ごとにリスクの出方を分けて検証し、傾き補正や1ファイル1帳票の運用でスキャン品質を底上げすることが、実務で使える精度を見極める近道です。PDFの読み込み全般の基礎はClaudeのPDF読み込み・画像解析の使い方、添付時のエラーはClaude Code PDFエラー一覧で扱っています。

この記事を共有:XはてブLinkedIn

関連する記事

Anthropic をもっと見る →