レシートのregex vs LLMフィールド抽出：ベンチマークデータ（2026）

最終確認: 2026-08-14 · 実行ティア: 公式 · ファーストパーティベンチマーク · 8モデル × 2レシートデータセット

以下のすべての数値は、ベンチマークの results/field_method_comparison.csv（regex vs LLMフィールド指標）と results/summary_metrics.csv（CER/WERコンテキスト）に基づいており、公開GitHubリポジトリにミラーリングされ、行ごとに引用されています。F1値はCSVでは0–1の小数で格納され、ここではパーセンテージで表示されています。2つのフィールドF1定義 — regexベースのアプローチとLLMベースのアプローチ — は、すべての図でラベル付けされ、混在することはありません。

OCRテキストから構造化フィールドを抽出するタスクでは、OCRエンジンの選択よりも後処理プログラムの選択が重要です。regexルールをLLM（deepseek-v4-flash）に置き換えると、英語レシートではフィールドF1が0.08–0.34から0.37–0.62へ、インドネシア語レシートでは0.00–0.34から0.16–0.55へ、ベンチマークのすべての行、全8エンジンで向上します。

覚えておくべき逆転現象: docTRは、8エンジン中で最悪のregexフィールドF1（SROIEで0.077）でありながら、最高のLLMフィールドF1（0.617）を記録しました。そのOCRテキストは問題ありませんでした — regexパターンが、実際のレシートのフォーマットのばらつき（日付、通貨、複数行の住所）に耐えられなかっただけです。regexで7.7%のフィールドしか抽出できなかった同じテキストが、LLMでは61.7%を抽出できました。上流のOCRは「十分に良い」だけでよく、後処理プログラムが、そのテキストのどれだけが利用可能なフィールドになるかを決定します。

以下は、ユーザー可視テキストのみを日本語に翻訳したHTMLフラグメントです。 ```html

SROIE 結果：英語レシート（361サンプル）

英語レシートでは、LLMは8つのエンジンすべてにおいてregexを上回りました。最小の改善は1.76倍（PaddleOCR-VL 0.337 → 0.592）、最大は8.1倍です。さらにLLMはモデル間の差をほぼ解消しました。Tesseract以外の7エンジンのうち6つが0.05ポイントの範囲（0.569–0.617）に収まり、regexの結果は0.26ポイント（0.077–0.338）に分散していました。

SROIE（Scanned Receipt OCR and Information Extraction、ICDAR 2019）は標準的な英語レシートのベンチマークです。361枚のテストレシートに、会社名、日付、住所、合計金額の4つの対象フィールドがあります（Huang et al., 2019）。各エンジンはまず共有のRTX 4090環境でOCRテキストを生成し、そのテキストを2つの並列後処理器に渡しました。1つは固定のregexパターン（従来のOCR＋ルールベースKIEアプローチ）、もう1つは構造化抽出プロンプトを使用したLLM deepseek-v4-flashです。両方とも同じ正解フィールドに対してスコアリングされました。チャートは、エンジンごとのregexフィールドF1（青）とLLMフィールドF1（緑）を示しています。

出典：field_method_comparison.csv — dataset=sroie_2019の行、列regex_field_value_f1 / llm_field_value_f1（0–1の小数で格納、%で表示）。LLM後処理器：deepseek-v4-flash（llm_model列）。エンジンあたり361サンプル（llm_ok_count）。

OCRエンジン	タイプ	regex F1	LLM F1	regex Acc	LLM Acc
Tesseract	従来型（CPU）	23.3%	43.9%	21.4%	43.4%
PaddleOCR	従来型	32.5%	58.1%	29.5%	58.1%
EasyOCR	従来型	14.8%	37.2%	12.7%	37.1%
docTR	従来型	7.7%	61.7%	6.2%	61.7%
Docling	パイプラインパーサー	22.4%	56.9%	20.4%	56.6%
Surya2	ドキュメントVLM	31.8%	61.4%	30.0%	61.4%
Unlimited-OCR	ドキュメントVLM	33.8%	60.5%	30.9%	60.5%
PaddleOCR-VL	ドキュメントVLM	33.7%	59.2%	31.0%	58.5%

出典：field_method_comparison.csv — sroie_2019の行：regex_field_value_f1 / llm_field_value_f1 / regex_field_value_accuracy / llm_field_value_accuracy（0–1の小数を%で表示）。docTR F1 0.0766 → 0.6171；Surya2 0.3183 → 0.6139；PaddleOCR 0.3254 → 0.5810。

CORDの結果：インドネシアのレシート（100サンプル、ストレステスト）

CORDでは、その差はさらに広がります。LLMが向上するからではなく（実際には向上しません）、regexが崩壊するからです。8つのエンジンのうち6つで、regexのフィールドF1は10.8%以下となり、2つ（docTR 0.0%、EasyOCR 0.7%）はほぼ何も復元できません。それでもLLMは、Tesseract以外のすべてのエンジンを33.8%以上に引き上げており、手書きのパターンでは対応できない言語やレイアウトにも、その抽出能力が汎用化されていることを証明しています。

CORD v2は、ネストされたフィールド（menu、sub_total、total）を持つインドネシア語のレシートデータセットであり（Park et al., 2019）、言語横断的なストレステストとして実行されました。8つのエンジンのいずれも、主にインドネシアのレシートでトレーニングされたわけではありません。この表を読む際には、2つの注意点があります。第一に、CORDのグランドトゥルーステキストには、アノテーション構造とVLM出力正規化の違いが含まれており、すべてのエンジンで生のCERが体系的に増加します。したがって、以下のフィールドメトリクス（CERではなく）が、モデル間の公平な比較となります。第二に、regexパターンはフラットな英語のSROIEスキーマ用に書かれています。CORDのネストされたスキーマとインドネシアのフォーマット（Rp通貨、日付規則）はそれらを無効にします。これこそが、この調査結果です。つまり、ある市場に合わせたルールは、他の市場には適用できないということです。

出典：field_method_comparison.csv — dataset=cord_v2の行、列regex_field_value_f1 / llm_field_value_f1（0〜1の小数を%で表示）。エンジンあたり100サンプル（llm_ok_count）。

OCRエンジン	タイプ	regex F1	LLM F1	regex Acc	LLM Acc
Tesseract	従来型（CPU）	7.5%	16.3%	5.6%	14.3%
PaddleOCR	従来型	1.5%	55.3%	1.1%	50.7%
EasyOCR	従来型	0.7%	33.8%	0.4%	30.5%
docTR	従来型	0.0%	55.0%	0.0%	51.8%
Docling	パイプラインパーサー	6.1%	46.9%	4.6%	44.3%
Surya2	ドキュメントVLM	24.6%	52.0%	18.9%	49.0%
Unlimited-OCR	ドキュメントVLM	10.8%	46.8%	8.4%	45.0%
PaddleOCR-VL	ドキュメントVLM	34.1%	52.0%	28.7%	49.3%

出典：field_method_comparison.csv — cord_v2の行（regex/llmのフィールド値F1と精度、0〜1の小数を%で表示）。PaddleOCR LLM F1 0.0154 → 0.5527；docTR 0.0 → 0.5500；tesseract 0.0752 → 0.1627。

LLMが差を平坦化する理由と、その上限

数字の中の3つのパターンが、表面下で起きていることを説明します。それぞれが検証可能な主張であり、正確なCSVセルは以下に示します。

(a) LLMは0.26ポイントのモデル差を0.05ポイントの帯域に変える

regexでは、どのエンジンを選ぶかが非常に重要でした。SROIEのフィールドF1は0.077（docTR）から0.338（Unlimited-OCR）まで広がり、0.26ポイントの差がありました。LLMでは、Tesseract以外の7エンジンのうち6つが0.569（Docling）から0.617（docTR）の間に収まり、0.05ポイントの帯域に収束します（field_method_comparison.csv、sroie_2019行、regex_field_value_f1とllm_field_value_f1の比較）。上流のOCRは読み取り可能なテキストを生成するだけでよく、LLMはそこからエンジンにほぼ依存せずにフィールドを抽出します。この帯域から外れる2つのエンジンは、EasyOCRの0.372（英語レシートでの最低LLM F1）とTesseractの0.439です。CORDでは、Tesseractが明確な最下位となり、その0.163はテーブル全体で最悪のLLM結果です。

(b) Tesseractの上限は後処理ではなくOCR自体で決まる

「ゴミを入れればゴミが出る」は、LLMの後処理にも当てはまります。インドネシアのレシートに対するTesseractの生のOCRテキストは、文字誤り率が0.9523（summary_metrics.csv、tesseract/cord_v2、cer）で、100文字中およそ95文字が誤っているか順序が乱れています。その結果、CORDでのLLMフィールドF1は0.1627（field_method_comparison.csv、tesseract/cord_v2、llm_field_value_f1）です。LLMは読めないテキストから会社名や合計を抽出することはできません。後処理の上限は、その下にあるOCRの基本品質によって決まり、プロンプトエンジニアリングで取り除ける制約ではありません。

(c) docTRが最大の受益者：regexの最低からLLMの最高へ

docTRの事例は、問題がOCRではなく後処理にあったことを最も明確に示しています。SROIEでのregexフィールドF1は8エンジン中最低の0.0766でした。そのクリーンで正確なテキスト（SROIE CER 0.1971、ベンチマークで最高、summary_metrics.csvのdoctr/sroie_2019行）は、桁区切りのある合計や複数行の住所に対するregexパターンに単純に一致しませんでした。LLMでは、同じテキストがベンチマーク最高のSROIE結果である0.6171を生み出し、8.1倍の向上でテーブル内で最大です（field_method_comparison.csv、doctr/sroie_2019、regex_field_value_f1 0.0766 → llm_field_value_f1 0.6171）。CORDでも同じ効果が再現されます：regexでは0.0、LLMでは0.5500です。

正規表現で十分な場合とLLMを使うべき場合

正直なトレードオフは「正規表現は壊れている」ではなく、「レシートの形式が変動する場合、正規表現は脆い」ということです。正規表現による後処理は決定的で、無料で、即時です。一方、LLM後処理はトークンと文書あたり中央値1.8〜2.4秒（field_method_comparison.csv、全16行のllm_median_latency_ms）を追加します。その代わり、LLMはSROIEで1.76〜8.1倍多くのフィールドを回復しました。また、CORDでは正規表現がほとんどのエンジンでほぼゼロに落ち込んだのに対し、LLMはルールベース抽出では到底到達できなかったフィールドの33.8〜55.3%を回復しました。

正規表現で十分な場合：文書が少数で安定したレイアウトセットから来ており、必要なフィールドがほぼ一定の形式（固定の請求書番号パターン、単一の日付形式、単一通貨）で現れる場合、正規表現は適切なツールです。コストはかからず、マイクロ秒で動作し、失敗も予測可能です。ベンチマークの下限ケースがこれを示しています。レシートに合わせた正規表現を持つエンジンは、SROIEでフィールドF1 0.34に達しました（Unlimited-OCR 0.3376、PaddleOCR-VL 0.3368）。

LLMを使うべき場合：形式のばらつきが入り込むとすぐに、複数通貨、地域別の日付形式、複数行の住所、さまざまなスタイルのベンダー名、または第二言語などが該当します。これらのそれぞれがパターンを壊します。LLMはそれらすべてを1つのプロンプトで吸収します。ベンチマークのCORD結果は、「もう1つの言語」がルールベースのパイプラインにどれだけのコストをもたらすかを定量化しています。正規表現のフィールドF1は0.08〜0.34（英語SROIE）から0.00〜0.34（インドネシア語CORD）に低下しましたが、LLMは0.16〜0.55を維持しました。これは、正規表現アプローチが100%負担し、LLMが部分的にしか負担しなかったペナルティです。ほとんどの本番フローの正しいアーキテクチャはハイブリッドです。変動フィールドにはLLM抽出、厳密な期待形式を持つフィールドには正規表現またはルールベースの検証を使用し、1.8〜2.4秒の文書あたりLLMコストは同期ユーザー待機ではなく、非同期バッチ処理で償却します。

よくある質問

LLMによるフィールド抽出はregex抽出よりも正確ですか？

はい、このベンチマークでは、すべての行で、LLM後処理（deepseek-v4-flash）が、両データセットの8つのOCRエンジンすべてにおいてregex後処理を上回りました（field_method_comparison.csv、全16行）。SROIE英語レシートでは、LLMのフィールドF1は0.37–0.62、regexは0.08–0.34でした。CORDインドネシア語レシートでは、0.16–0.55対0.00–0.34でした。

LLM後処理でレシートのフィールドを最も正確に抽出するOCRモデルはどれですか？

SROIEではdocTRが0.6171のフィールドF1でトップですが、LLMがループに入るとエンジン間の差はほとんどなくなります。Tesseract以外の7エンジンのうち6つは0.569から0.617の間に収まります（field_method_comparison.csv、sroie_2019行、llm_field_value_f1）。CORDではPaddleOCRが0.5527でトップ、docTRが0.5500で僅差の2位です。

LLMを使ってもTesseractが遅れを取るのはなぜですか？

OCRテキストが劣化しすぎて、どの後処理でもフィールドを復元できないためです。インドネシア語レシートでは文字誤り率が0.9523（summary_metrics.csv、tesseract/cord_v2）で、LLMのフィールドF1は0.1627に抑えられています。これはベンチマークで最悪のLLM結果です（field_method_comparison.csv、tesseract/cord_v2、llm_field_value_f1）。

LLMはregexと比べてフィールド抽出をどの程度改善しますか？

英語レシートではエンジンに応じて1.76倍から8.1倍で、docTRで最大の改善が見られました（0.077 → 0.617のフィールドF1、field_method_comparison.csvのsroie_2019行）。インドネシア語レシートでは改善はさらに大きく、PaddleOCRで36倍、docTRでは実質的に無限大（0.0 → 0.55）でした。regexがほとんど何も復元できなかったためです。

LLM後処理ですべてのフィールドを正確に取得できますか？

いいえ。そして読者もそれを期待すべきではありません。ベンチマークにおけるLLMフィールドF1の最高値は0.617（docTR、SROIE）で、約38%のフィールドが依然として見逃されたり誤ったりしており、文書全体の完全一致率の最高値は15.5%（Surya2、SROIE、llm_document_fields_exact）です。つまり、最大でも6件に1件の文書で4つのフィールドすべてが完全に正しかったことになります。LLM抽出はregexからの大きな改善ですが、万能薬ではありません。フィールドレベルの信頼度スコアリングと人的レビューは、本番環境では引き続き必要です。

LLM後処理の速度やコストはどの程度ですか？

このベンチマークでは、LLM呼び出しにより文書あたりの中央値レイテンシが1.8〜2.4秒追加され（field_method_comparison.csv、llm_median_latency_ms、全16行）、16グループ全体の実行で約133万プロンプト＋28万完了トークンを消費しました（llm_prompt_tokens / llm_completion_tokensの合計）。これはリアルタイムのフィールド抽出レイテンシではなく、インタラクティブな検索ではなく非同期バッチ処理に適しています。

LLM後処理は英語以外のレシートでも機能しますか？

regexよりは優れていますが、上限は低くなります。インドネシア語のCORDレシートでは、LLMはフィールドF1を0.16〜0.55に維持しましたが、regexは0.00〜0.34にまで落ち込みました（field_method_comparison.csv、cord_v2行）。しかし、CORDの最高結果（0.5527）は依然として英語の最高結果（0.6171）に及びません。これは、より難しい文字体系と劣化したOCRベースの両方を反映しています。英語のレシート用に書かれたルールは実質的に機能しなくなりましたが、LLMは代わりに緩やかに劣化しました。

方法論と出典

プロトコル

このページでは、ImageToTable.aiオープンソースOCRベンチマークのフィールド抽出比較を報告します。これは独立した再現可能な実験実行（公式ティア）であり、第三者による主張の調査ではありません。各（モデル×データセット）ペアのパイプライン：OCRエンジンがレシート画像からテキストを生成し、そのテキストを固定のregexパターンセットとLLMポストプロセッサの2回で抽出し、両方の出力を同じ正解フィールドに対してスコアリングします。LLMポストプロセッサはdeepseek-v4-flash（比較CSVのllm_model列）で、決定論的な出力のため温度0で実行されます。SROIE 361件とCORD 100件の全サンプルが正常に完了しました（llm_ok_count = 361 / 100）。

実行環境

ハードウェア：すべてのGPU実行はNVIDIA RTX 4090（24 GB）上で行われました。PyTorchベースのエンジン（docTR、EasyOCR、Docling）はPyTorch 2.8.0+cu128（CUDA 12.8）で実行されました。TesseractはCPUのみで実行（GPUコストなし）。vLLMで提供されるエンジン（Surya2、Unlimited-OCR、PaddleOCR-VL）はvLLMポッド上で実行されました。ドライバとPythonのバージョンは実行ごとに若干異なり、編集済みの実行マニフェストに正確に記録されています（下記のアーティファクトアクセスを参照）。
LLMポストプロセッサ：deepseek-v4-flashをAPI経由で、温度0で使用。
測定モード：warm_then_scored — スコアリング実行の前に固定のウォームアップ実行が行われるため、レイテンシ数値は安定状態です。
データセット：SROIE 2019テスト — 英語レシート361件、フラットフィールド（会社名、日付、住所、合計）、CC-BY-4.0。CORD v2テスト — インドネシア語レシート100件、ネストフィールド（メニュー、小計、合計）、CC-BY-4.0。
サンプル数：SROIE 361 / CORD 100、すべて固定テスト分割から（トレーニングデータの漏洩なし）。

両方のポストプロセッサが消費する上流のOCRテキストは、以下のエンジンバージョンから生成されました：

OCRエンジン	バージョン	バックエンド
Tesseract	5.3.4	CPU（GPUなし）
PaddleOCR	3.7.0	PaddlePaddle-GPU 3.3.1
EasyOCR	1.7.2	PyTorch
docTR	1.0.1	PyTorch
Docling	2.119.0	PyTorch
Surya2	0.22.1	vLLM
Unlimited-OCR	baidu/Unlimited-OCR	vLLM
PaddleOCR-VL	1.6	vLLM

実行ごとの完全な再現性フィンガープリントは、公開リポジトリのresults/manifests/にあるベンチマークの編集済み実行マニフェストに含まれています（公開された実行ごとに1つのmanifest.json、合計16件）。各マニフェストには以下が開示されています：実行ID、モデル+バージョン、ランナースクリプトのハッシュ（SHA-256）、GPUモデル/ドライバ/VRAM、torch/CUDA/torchvision/torchaudioバージョン、Pythonバージョン、pip-freezeハッシュ、コストメタデータ（GPU $/時間と価格タイムスタンプ）、測定モード、アーティファクトハッシュ（サンプルリスト、予測、メトリクス、パフォーマンス）。

指標の定義

フィールド値のF1（regexアプローチ）: 抽出されたフィールド値の適合率と再現率の調和平均で、regexによる後処理を使用します — 従来のOCR + ルールベースのKIEアプローチです。列: regex_field_value_f1。
フィールド値のF1（LLMアプローチ）: LLM後処理器の出力に対して計算された同じ指標 — OCR + LLM後処理アプローチです。列: llm_field_value_f1。 これら2つのアプローチは異なるパイプラインであり、混在することはありません。
フィールド値の精度: 抽出されたフィールド値が正解と完全に一致する割合（regex_field_value_accuracy / llm_field_value_accuracy）。
ドキュメント全フィールド完全一致: すべての対象フィールドが完全に一致したドキュメントの割合（regex_document_fields_exact / llm_document_fields_exact）。
CER/WER（コンテキストのみ）: 生のOCRテキストの文字/単語誤り率で、このページではTesseractのLLM上限を説明するためにのみ使用されます。

成果物へのアクセス

field_method_comparison.csv（GitHub raw）。16行 = 8モデル × 2データセット。列: model、dataset、llm_model（= deepseek-v4-flash）、regex/llmフィールドF1 + 精度、ドキュメント全フィールド完全一致、llm_median_latency_ms、llm_prompt_tokens、llm_completion_tokens。 このページのすべてのフィールドF1と精度の数値は、ここの行に由来します。
summary_metrics.csv（GitHub raw）。モデル × データセットごとのCER/WERで、Tesseractの上限の説明（tesseract/cord_v2 cer 0.9523）とdocTRのSROIE CER 0.1971に使用されます。
ImageToTableai/benchmark-ocr リポジトリ。結果CSV、実行マニフェスト、再現用のデータセットサンプルリストをホストする公開リポジトリです。
results/manifests/（GitHub）。公開された各実行（16回）につき1つの編集済みmanifest.jsonがあり、上記の実行ごとの環境フィンガープリントと成果物ハッシュが含まれています。
Huang et al.、「ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction」（2019年）。SROIEデータセットの定義とライセンス。
Park et al.、「CORD: A Consolidated Receipt Dataset for Post-OCR Parsing」（2019年）。CORD v2データセットの定義とライセンス。

制限事項

ドキュメントの範囲: レシートのみ（SROIE + CORD）。追加のテストなしでは、請求書、フォーム、長文ドキュメントには調査結果が一般化されません。
サンプルサイズ: 英語361件 + インドネシア語100件のレシート。フィールドF1はコーパスの構成に敏感で、数百分の1の単一ポイントの差はノイズとして扱ってください。
単一のLLMモデル: すべてのLLM行はdeepseek-v4-flashを使用しています。異なるLLM（サイズ、プロンプト、ベンダー）を使用すると絶対値が異なり、regexとLLMの順序が境界で変わる可能性があります。
CORDの正解データに関する注意: CORDのgt_textにはアノテーション構造とVLM正規化の違いが含まれるため、CORDの生のCERはすべてのエンジンで体系的に過大評価されます（例：PaddleOCR-VLのCER 1.08はアーティファクトであり、実際のテキスト品質を示すものではありません）。フィールドメトリクスが公平な比較であり、CERはTesseractの説明にのみ使用されています。
レイテンシはリアルタイムの抽出レイテンシではありません: llm_median_latency_ms（1.8〜2.4秒）は、OCRテキストからLLMフィールド抽出までの呼び出し全体をカバーしており、フィールドごとの検索ではなく、OCR時間自体は含まれません。
regexのチューニング: regexパターンは、データセットごとに一度だけ書かれた固定セットです（SROIE-flatスキーマ）。ベンダーごとに高度にチューニングされたregexライブラリは、独自のフォーマットでより高いスコアを獲得できる可能性がありますが、LLMが排除するメンテナンス負担がかかります。

関連資料: OCR精度の主張の読み方

レシートのRegex vs LLMフィールド抽出ファーストパーティベンチマーク結果（2026）