Claude × 名刺OCR 汎用LLMでの画像認識について

【Amazon Bedrock】Claudeで名刺OCRの精度を検証してみた

はじめに

今回は Amazon Bedrock 上の Claude（Haiku / Sonnet / Opus）に名刺画像を読ませて、構造化データ抽出の精度・コスト・速度を定量比較してみました。
100枚の検証画像を使って、モデルごとに性能を計測しています。
※ 本記事の検証はデータ数100枚と限られているため、結果は傾向の把握としてご参考ください。実運用への適用にあたっては、より大規模なデータセットでの検証が必要になります。

背景

Webアプリのバックエンド開発の中で、画像認識で文字データを抽出する開発項目を担当する可能性があり、その検証としてClaudeモデルを使った現状の認識精度を測る必要がありました。
既存のAIを使った専用サービス等はありますが、Webアプリへの組み込みやカスタマイズ、そしてコストには制約があります。
Bedrock上のClaudeならAPIで呼び出すことができるため、それなりの精度が出るのであればWebアプリに組み込む検討を行うことができます。

そこで、「汎用LLMの画像認識能力で、専用OCRにどこまで迫れるのか？」を具体的な数字で確かめてみることにしました。
今回はある程度記載するフォーマットが決まっている名刺を題材に、検証を行いました。

検証設計

データセット

60種類の架空名刺を、6つの条件で撮影・加工しました。

60種のうち10枚はチューニング用とし、残り50種 + 50種をベースに加工したいずれかの条件で合計 100枚 を評価対象としています。

画像は以下のように用意しました。

1. Claude Codeで指示し、架空の名刺デザインをHTMLで作成してもらいました。
   (デザイン作成にあたり、Anthropic公式のSkillを読み込ませて作成しました。)
2. 作成したHTMLをplaywrightでキャプチャし、デザイン画像を作成しました。
   
3. 作成したデザインを印刷し、カメラで撮影。
   
4. 撮影した画像をもとに、Cursor の画像生成機能で各条件の加工画像を作成しました。
   
   

ステップ4について補足します。
加工画像の作成には AI コードエディタの Cursor を活用しました。
Cursor 上で正常撮影画像を読み込ませ、「この画像に光の反射効果を加えてください」「ピントがぼけたように加工してください」といったプロンプトを条件ごとに指示することで、5種類の加工画像を生成しています。
Cursorは内部でGeminiのAPI(Nano Banana)を呼んで画像生成してくれます。

プロンプトで加工条件を指示するだけで劣化画像を量産できるため、Photoshop等で1枚ずつ手作業で加工するよりも効率的でした。
ただし、生成された画像が意図した条件を正確に再現しているかは目視で確認し、不自然なものは再生成しています。

比較モデル

すべて Amazon Bedrock 経由で実行しています。
（料金は2026年4月時点)

抽出対象（11フィールド）

会社名 / 氏名 / 氏名読み / 役職 / 郵便番号 / 住所 / 電話番号 / FAX / 携帯電話 / メール / URL

評価指標

レコードEMRは「1フィールドでも間違えたらアウト」という厳しい指標で、業務上「そのままDBに入れられる名刺の割合」に相当します。

実装：Bedrock Converse API で名刺を読む

実装はシンプルです。Amazon BedrockのConverse API に画像を渡し、JSON 形式で返させます。今回の実装のポイントを紹介します。

プロンプト設計

SYSTEM_PROMPT = """あなたは画像に書かれた文字を完璧に読み取る専門家です。
細部まで注意深く観察し、画像の文字を一切変更せずに転記します。

名刺画像から以下のフィールドを抽出してください。
...（フィールド定義）...

## 重要なルール
1. 見えたままを忠実に転記する（推測や補正はしない）
2. 存在しないフィールドはnullにする
3. 090/080/070で始まる番号はmobileに分類

## 出力形式
<thinking>タグ内で画像に見えるテキストを観察した後、
<answer>タグ内にJSON形式で出力してください。"""

これらのプロンプトを設計するにあたって、Anthropicが公式に出しているClaude Cookbooksを参考にしました。
Cookbooksは公式サンプル集で、さまざまなシチュエーションに沿ったプロンプトの具体例を紹介してくれています。
今回はその中でも画像認識に関わる部分、multimodalセクションを参考に以下のテクニックを採用しました。

• Role assignment（専門家の役割をシステムプロンプトに明記）
• thinkingタグに観察・推論結果を一度出し、それを元に answerタグに最終結果を出力させる
• 出力形式をJSONで明確に指定する
• 推測を禁止するように明示的に指示

＋αでFew-shotという手法を取り入れているパターンと、取り入れていないパターンの2つでデータを取得しています。
Few-shotの詳細は後述します。

検証結果

まずは 100枚（Few-shot なし）の結果から見ていきます。
※ コストは実測値ですが、2026年4月に検証実施した際の料金になっています。

注目すべきポイント:

• Sonnet vs Opus は精度差わずか1.7pt なのにコストは約6割で済む。多くのケースで Sonnet で十分な結果となりました。
• HaikuはフィールドEMR約70%と心許ない結果でした。速度・コストでは優位ですが精度面で実用は厳しいです。
• Opus 4.7 は 4.6 とほぼ同精度ですが、レイテンシが約半分（10.9s → 5.2s）に改善しています。

個人的には Opus 4.7 は 4.6 よりも精度があまり変わらなかったことが意外でした。

撮影条件の影響：「斜め」と「ぼけ」に注意

フィールドEMR を撮影条件別に見ると、条件によって大きく精度が変わります。

普通に撮れば Sonnet で95%超。反射や影は意外と影響が小さく、むしろ問題になるのは 斜め撮影とぼけ です。

• Haiku は斜め撮影で 51.1% まで落ちる（半分近く間違える）
• Sonnet でもぼけ画像は 70.2% と大幅低下
• Opus だけが斜め・ぼけでも80%以上を維持

やはり人間の目でも認識しづらい斜めからのアングルの画像や、ぼけている画像は精度が落ちます。
逆に言えば正面から普通に撮影した画像ならかなりの精度が出ているので、入力品質のガードレールを整備することも実運用では必要になってきそうです。

フィールド別：何が読みにくいか

フィールドEMR をフィールド単位で見ると、項目によって難易度が大きく異なります。

簡単な項目: 氏名（Sonnet/Opus 100%）、会社名、メール、URL
難しい項目: 住所（Haiku 26%）、役職（Sonnet 76%）

住所は文字数が多く、漢字+数字の複合表現。役職は「営業本部 関東支店 法人営業部 課長」のような複合表現の境界が曖昧で、モデルが区切り方を迷います。

Few-shot を試してみた

Few-shotとは、プロンプトに具体的な例示と、それに対応した回答を組み込むことで、AIの推論の判断基準として役立てる手法です。
チューニング用データセットから1枚の名刺画像とその正解JSONを assistant ロールに埋め込み、続けて評価対象画像を投げる形式です。

# Few-shot: 例示カードの画像+正解JSONを先に渡す
messages = [
    {"role": "user", "content": [
        {"image": {"format": fmt, "source": {"bytes": example_bytes}}},
        {"text": "この名刺画像から情報を抽出してください。"},
    ]},
    {"role": "assistant", "content": [
        {"text": json.dumps(example_ground_truth, ensure_ascii=False)},
    ]},
    # 本番画像
    {"role": "user", "content": [
        {"image": {"format": fmt, "source": {"bytes": target_bytes}}},
        {"text": "この名刺画像から情報を抽出してください。"},
    ]},
]

response = client.converse(
    modelId=model_id,
    messages=messages,
    system=[{"text": SYSTEM_PROMPT_FEWSHOT}],
    inferenceConfig={"maxTokens": 2048, "temperature": 0},
)

精度の変化

Sonnet にはレコードEMR +7pt と明確に効く一方、Opus 4.6 には逆効果、Opus 4.7 に至っては精度が半減しました。

やるタスクやモデルの性能によって、プロンプト手法を採用するかどうかは検討が必要だということが分かりました。

また、捏造率に関しては面白い結果となりました。

Few-shot なしでは全モデル捏造率2%台で横並びだったのに、Few-shot ありで Haiku は4倍、Opus 4.6 は3倍に急増しています。

例示を与えるとそれによってバイアスがかかり、名刺に記載がないフィールドにも値を埋めてしまう傾向が見られました。

なぜ Opus 4.7 は大幅に劣化したのか

Opus 4.7 では、100枚中50枚で 例示に使った名刺の内容をそのまま本番結果として出力する 現象が発生しました。

原因は推測にはなってしまいますが、Anthropicが出しているOpus 4.7への移行ガイドを読み解くと見えてきます。
Opus 4.7からは以下のような変更がされています。

Claude Opus 4.7は、特に低い努力レベルでは、Claude Opus 4.6よりもプロンプトをより文字通りに明示的に解釈します。1つのアイテムから別のアイテムへの指示を静かに一般化することはなく、あなたが行わなかったリクエストを推測することもありません。

つまり、旧モデルでは「例示JSONは形式の参考」と汎化してくれたのが、Opus 4.7 では直前の assistant 応答をそのまま解釈し、再利用してしまうということです。

このように、モデルのバージョンアップで挙動が大幅に変わることがあり、モデルを新しいものに差し替えただけで性能が向上するとは限らないことが分かりました。
モデルを更新する際はプロンプト設計やパラメータなど変更も含めて検討する必要がありそうです。

コスト試算：SaaS と比べてどうか

Bedrock 上の Claude で名刺OCRを運用した場合の月間コスト試算です。

算定方法: 本検証100枚の実測コスト/枚（2026年4月実施）を、為替レート ¥160/$（2026年4月時点） で円換算しています。

特定の画像認識専用SaaSは具体的な単価が非公開のケースが多いですが、一般的に月額固定 + 従量課金の料金体系です。

自社の名刺処理量 × SaaS 単価が上記を超えるなら、自前実装の検討余地ありです。
ただし開発・運用コストは別途考慮が必要なので、「API費が安い ＝ トータルで安い」とは限りません。

まとめ

Claude 単体で名刺OCRは実用ラインに達している

• Sonnet 4.6 でフィールドEMR 91.5%、正常撮影なら 95%超
• Opus なら劣化画像でも 93% 以上を維持

撮影条件の管理が重要

ぼけ・斜めで精度が大幅低下します。バッチ処理でも入力品質のガードレールは必要です。

プロンプト手法はモデルごとに検証してから採用する

公式推奨の Few-shot でさえ、モデルによっては精度が劣化します。手法 × モデルの組み合わせ検証が不可欠です。

モデル更新はプロンプト再設計とセット

モデルバージョンの差し替えだけで済むとは限りません。
実際にバージョンによって精度がどう変わるかを評価しつつ、推論パラメータ、プロンプト構造、出力形式のすべてを再検証する工程を見込んでおくべきです。

おわりに

今回の検証で、フィールド単位で90%以上の一致率が許容できるユースケースであれば、Claudeの画像認識能力は実用的な選択肢になり得ることが確認できました。 一方で、求められる精度水準によっては追加の後処理や人手による確認フローが必要になるため、導入時には要件に応じた精度目標の設定が重要です。

また、モデルごとに得意・不得意があり、プロンプト手法との相性も異なるため、「とりあえず最新モデルを使っておけばOK」とはいかない点も明らかになりました。
名刺 OCR に限らず、LLM を業務パイプラインに組み込む際には モデル選定 × プロンプト設計 × 入力品質管理 の3つをセットで検討することが重要です。

Bedrock上での画像認識のAI活用を検討されている方の参考になれば幸いです。