従来型OCRと文書解析VLMの比較
Receipt Benchmark Results (2026)

文字誤り率（CER）は、個々の文字のうち誤って読み取られた割合を測定します。削除、挿入、置換を正解文字数で割った値です。これは古典的なOCRの評価指標であり、英語のレシートにおいて「VLM優位」という主張が崩れるポイントでもあります。

SROIE 2019では、最良の2つのテキスト認識エンジンはVLMと従来型エンジンがそれぞれ1つずつで、その差はわずか0.006ポイントです。Surya2が0.191、docTRが0.197で、PaddleOCRが0.204で3位となっています。残りの3つのVLM（PaddleOCR-VL 0.337、Docling 0.591、Unlimited-OCR 0.655）は、EasyOCR（0.283）やTesseract（0.335）といった従来型エンジンと同等かそれ以下の性能です。

SROIE（英語レシート）におけるモデル別文字精度

出典：summary_metrics.csv — cer列、sroie_2019行（8行）。Surya2 0.1915、docTR 0.1971、PaddleOCR 0.2045、EasyOCR 0.2833、Tesseract 0.3347、PaddleOCR-VL 0.3370、Docling 0.5909、Unlimited-OCR 0.6552。低いほど良い。TesseractはCPUのみ対応。

表: summary_metrics.csv — cer および wer 列、sroie_2019 行、各361サンプル（全8モデルで error_rate 0.0）。CER = 文字誤り率、WER = 単語誤り率。低いほど良好。正確な値: Surya2 cer 0.19147 / wer 0.27352; docTR cer 0.19707 / wer 0.31990。

単語誤り率（WER）は、粒度を変えて同じ結果を示しています。文字単位ではなく単語単位の誤りを評価します。Surya2 が WER 0.274 でトップ、docTR が 0.320 で続きます。最下位の外れ値に注目してください。Unlimited-OCR は CER が最悪（0.655）ですが、WER は中位（0.478）です。その出力は大文字・小文字や形式が大幅に正規化されており（方法論セクションで説明する出力規約）、単語がほぼ無傷でも文字レベルの編集回数が増加します。

Doclingは比較表に登場する前に分類上の注意が必要です。Doclingは純粋な従来型OCRエンジンでもVLMでもありません。Doclingはパイプラインパーサーです。レイアウト解析、テーブル検出、読み順の再構築をOCRコアの周りで実行する段階的なツールチェーンです。普通のレシートでは、このパイプラインのオーバーヘッドはほとんど価値を生みません。そのため、SROIEでの生のCER（0.591）が単一パスエンジンに劣る理由の一部となっています。

コストとレイテンシ：従来型エンジンの優位性

文字精度が両ファミリーの間で何も決めないのであれば、コストとレイテンシがほぼすべてを決めます。同一のテスト分割において、docTRは449ページ/分、ページあたり108.7 ms p50、1,000ページあたり$0.048を維持します。Surya2は12ページ/分、2,668 ms p50、1,000ページあたり$1.061を維持します。おおよそ37倍のスループット、24.5倍のページあたりレイテンシ、22倍の1,000ページあたりコストです。

コストは、ウォールクロック実行時間×RunPod RTX 4090レート（$0.76/時間、実行マニフェストに価格のタイムスタンプあり）として計算されます。これは、モデルの初期化を含め、GPU時間に対して実際に支払う価格です。Tesseractは特別なケースです。CPUのみで、GPUコストは一切かからず、それでもSROIEで78.6ページ/分を処理します。そのコストセルがCSVで空なのは意図的であり、無料だからではなく、課金対象のGPU時間を消費しないためです。

出典：summary_metrics.csv — latency_p50_ms列、sroie_2019行。docTR 108.7、PaddleOCR 297.0、EasyOCR 413.6、Tesseract 670.9（CPU）、PaddleOCR-VL 694.3、Docling 732.0、Unlimited-OCR 1600.7、Surya2 2668.0。定常状態のレイテンシ、ウォームアップ後のスコアリング測定モード（モデルの読み込みは除外）。

出典：summary_metrics.csv — cost_per_1000_pages列、sroie_2019行。docTR 0.0479、EasyOCR 0.1098、PaddleOCR-VL 0.2048、PaddleOCR 0.2214、Unlimited-OCR 0.3879、Docling 0.3978、Surya2 1.0609。TesseractはCPUのみ：CSVではセルが空（GPUコストなし）。コストにはモデルの初期化が含まれ、純粋な定常状態のスループットではありません。

表: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages、sroie_2019 行。GPUはRTX 4090で実行（$0.76/hr、価格はマニフェストにタイムスタンプあり）。TesseractはCPUのみで実行（コストセルは空、ゼロではない）。スループットはモデル初期化を含むウォールクロック時間でのページ/分。

テールレイテンシ列は、中央値だけでなく最悪ケースの挙動を重視する場合に重要です。PaddleOCRのp95（3,331 ms）とDoclingのp95（3,240 ms）は、それぞれのp50値から大きく乖離しています — 初回ページ効果とプリフィルスパイクがGPUエンジンのテールを支配します — 一方、docTRのp95（281 ms）は安定しています。インタラクティブなワークロード（1ページを待つユーザー）では、このp95の差が0.3秒の待ち時間と3秒以上の待ち時間の違いになります。

CORD（インドネシア語レシート）：言語ミスマッチと正解データの膨張

CORD v2は、ネストされたフィールド（menu、sub_total、total）を持つインドネシア語のレシートデータセットです。8つのエンジンのいずれもインドネシア語レシートを主に学習していないため、CORDは言語横断的なストレステストとして機能し、全エンジンのCERは0.90〜1.08に低下します。これらの数値は、CORDの正解テキストに注釈構造が埋め込まれており、全エンジンの生のCERを膨張させているという点を踏まえて解釈する必要があります。CORDの結果はSROIEランキングとは厳密に分離されており、単一のリーダーボードに統合することはできません。

CORDのCERを1.0に押し上げる要因は2つあり、そのうち言語自体は1つにすぎません。第一に言語：英語で学習されたエンジンはインドネシア語の単語を実際に誤読します。インドネシア語の人名、住所、通貨形式（Rp）は、それらの学習分布の外にあります。第二に正解データ：CORDの公開注釈には、純粋な可視テキストではなく注釈構造（座標付きのフィールドラベル）が埋め込まれているため、生のCERは構造的に拡張された文字列との編集距離を測定します。最もクリーンなVLMの例が最も厳しくペナルティを受けます。CER 1.080のPaddleOCR-VLは、そのメカニズムによる極端な産物であり、テキスト品質の読み取りではありません。

CORDにおける公平なファミリー間比較は、したがってCERではなくフィールド指標です（次のセクションを参照）。CER列が依然として有用に示すのは、言語ミスマッチがアーキテクチャ全体で現実的かつ普遍的であることです。従来型とVLMの両方を含むすべてのファミリーが、同じ0.90〜1.08の帯域に位置し、どちらにも構造的優位性はありません。

表: summary_metrics.csv — cer列、cord_v2行、各100サンプル。 これらの数値をSROIEと組み合わせたランキングで比較しないでください： CORD CERは、実際の言語不一致と、正解データにおけるアノテーション構造の膨張（方法論は下記参照）を組み合わせたものです。CERが1.0を超える場合（PaddleOCR-VL 1.0805）は、その膨張した正解データによる編集距離のアーティファクトです。

フィールドF1：LLM後処理がフィールドを収束させる

文字精度はエンジンをランク付けしますが、フィールド抽出こそが本番ユーザーが実際に支払う価値です。ベンチマークは、各エンジンのOCRテキストから4つのレシートフィールド（会社名、日付、住所、合計）を、2つの後処理方法 — 固定のregexパターン（従来のOCR＋ルールベースKIEアプローチ）と、構造化プロンプトを使用したLLM（deepseek-v4-flash）— で抽出します。その結果、LLMはSROIEにおけるエンジン間のギャップをほぼ解消し、8エンジンのうち6つを0.57–0.62のフィールドF1帯域に引き寄せました — 一方、regexの結果は0.26ポイントの範囲に分散していました。

フィールド値F1は、抽出されたフィールド値の適合率と再現率の調和平均であり、正解データと照合してスコアリングされます — 1.0はすべてのフィールド値が完全に抽出されたことを意味し、0は何も復元されなかったことを意味します。regex列はデータセットごとに1つの固定パターンセットを使用し、LLM列は決定論的な出力のために温度0のdeepseek-v4-flashを使用します（比較CSVのllm_model列）。2つの指標は異なるパイプラインを測定しており、決して混合されません。

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

表: field_method_comparison.csv — regex_field_value_f1 / llm_field_value_f1、sroie_2019行。LLM = deepseek-v4-flash後処理（llm_model列）。docTRのregex 0.0766 → LLM 0.6171（8.1×向上）。遅延エンジン6種以外は0.5685–0.6171の範囲。

この表には直感に反する結果が2つある。第一に、docTRはSROIEでregexフィールドF1が最低（0.077）でありながら、LLMフィールドF1が最高（0.617）であること。同じクリーンなOCRテキストからregexが7.7%のフィールドしか抽出できなかったものが、LLMでは61.7%を達成した。ボトルネックはOCRではなく後処理にあった。第二に、0.57–0.62の帯域から外れる2つのエンジンは、まさにOCR基盤が劣化している2つであること。EasyOCR（0.372、SROIE CER 0.283）とTesseractである。TesseractのCORD結果（LLMフィールドF1 0.163）は、LLMが根本的に読み取れないテキストからフィールドを抽出できないことを示している（CORD CER 0.9523）。あらゆる後処理の上限は、その下にあるOCR基盤の品質によって決まる。

CORDでは、LLMも言語ショックの一部を吸収します。健全なエンジン（PaddleOCR 0.553、docTR 0.550、PaddleOCR-VL 0.520、Surya2 0.520）では、LLMのフィールドF1が0.47–0.55を維持する一方、regexはほぼゼロにまで低下します（docTR 0.0、EasyOCR 0.7%）。パターンは英語形式用に書かれており、「もう一つの言語」のペナルティは、LLMではなく、ほぼすべてルール側が負担することになります（field_method_comparison.csv、llm_field_value_f1 / regex_field_value_f1、cord_v2行）。

CERが文書解析VLMを過小評価する理由

CERはVLMの出力と正解を文字単位で比較するため、VLMは認識エラーではない2つの正当な動作、すなわちケース折りたたみとラベル/値のマージに対してペナルティを受けます。ベンチマークのSROIEにおけるCER分解では、VLMのCERの約18%がケース形式の差異（例：TAN CHAY YEE → tan chay yee）に、約10%が行のマージまたは区切り行の欠落に起因するとされています（フィールド値自体（会社名、合計、日付）は実際には正しい）。このCER分解分析は、ベンチマークのプロトコルノート（SROIE実行）に記録されています。

この設計上の緊張は現実的かつ構造的なものです。従来型OCRエンジンはケースを保持した生テキストを出力するため、CERスコアリングに最適化されるように設計されています。一方、文書解析VLMは「理解された」テキスト（正規化されたケース、マージされたラベルと値のペア、並べ替えられた行）を出力します。これは下流システムが求めるものに近い一方で、完全な文字一致からは遠くなります。このため、このページの見出しでは、類似した出力間の公平な比較にのみCERを使用し、ファミリー間の公平な比較はフィールドメトリクスに委ねています。また、CORDのCER（さらに注釈構造のインフレーションを伴う）は、専用セクションに隔離されています。より広いポイントは次の通りです。ファミリー間のCERギャップは、自動的に精度ギャップを意味するわけではありません。モデルをファミリー間で比較する際は、結論を下す前に、CERが何を測定しているかを確認する必要があります。

選び方：ワークロードにとって重要な軸はどれか

「優れている」という評価は、ワークロードなしでは意味を持ちません。このベンチマークの正直な結論は、2つのファミリーが異なる軸で勝負しているということです。そしてレシート処理は、従来型エンジンが勝つ軸と、後処理（エンジンファミリーではなく）がフィールド品質を左右する軸を具体的に測定しています。

選択ガイダンスは、引用されたCSV行から直接導出されています。これはデータ駆動型の読者支援であり、ベンダーの推奨ではありません。実際の結果は、ハードウェア、文書構成、モデルバージョンによって異なります。

よくある質問

文書解析VLMは、レシートにおいて従来型OCRよりも精度が高いのでしょうか？

生の文字精度に関してはそうとは言えません。最良のVLMと最良の従来型エンジンは、SROIE 2019において統計的に同等です（Surya2 CER 0.191 対 docTR 0.197、summary_metrics.csvのsroie_2019行）。PaddleOCR（0.204）は3番目です。フィールド抽出が目的の場合、VLMであるかどうかに関わらず、LLMによる後処理が決定的な要因となります（0.57〜0.62の収束帯、field_method_comparison.csv）。

従来型OCRが文書解析VLMよりも適しているのはどのような場合ですか？

処理量が多く、コストが従量制である場合、または対話的なレイテンシが求められる場合です。SROIEでは、docTRは毎分449ページを処理し、1,000ページあたり$0.048、p50は108.7 msでした。一方、Surya2は毎分12ページを処理し、1,000ページあたり$1.061、p50は2,668 msでした（summary_metrics.csvのdoctrおよびsurya2のsroie_2019行）。1ページあたりの対話的な待ち時間では、0.1秒と2.7秒の差になります。

文書解析VLMが、低コストのOCRよりもCERで悪いスコアになることがあるのはなぜですか？

CERは正確な文字一致を評価するため、VLMは、誤読ではなく出力規則である大文字小文字の変換やラベルと値の結合に対してペナルティを受けるからです。SROIEにおけるベンチマークのCER分解では、VLMのCERの約18%が大文字小文字の形式の違いに、約10%が行の結合や区切り文字の欠落に起因するとされています（フィールド値自体は多くの場合正しいものです。方法論を参照）。CORDのCERはさらに、その正解データ内のアノテーション構造によって水増しされているため、このページではCORDのCERをランキングから除外し、ファミリー間の比較にはフィールドメトリクスを使用しています。

RTX 4090でレシートOCRの1ページあたりのコストはいくらですか？

RTX 4090、$0.76/時間、2026年8月時点の価格で、1,000ページあたり$0.048（docTR）から$1.061（Surya2）の範囲です（実行マニフェストのsummary_metrics.csv cost_per_1000_pages、sroie_2019行に記載）。TesseractはCPUのみでGPU時間を消費しません。コストにはモデル初期化が含まれるため、バッチサイズが大きくなるほど1ページあたりのコストは下がります。

CORDレシートで全モデルがCER 0.90超えなのはなぜですか？

2つの複合的な原因があります：真の言語ミスマッチ（各エンジンのトレーニング対象外のインドネシア語レシート）と、CORDの正解テキスト内のアノテーション構造によるインフレーションです。どちらのモデル群も回避できず、全8モデルが0.90〜1.08の帯域に収まります（summary_metrics.csv cer、cord_v2行）。CORDは言語・レイアウト堅牢性のストレステストであり、SROIEランキングとは別に扱われます。

LLMでOCR出力の品質は改善できますか？

ベースとなるテキストの品質までしか改善できません。SROIEではLLMにより6つのエンジンがエンジンに関係なく0.57〜0.62のフィールドF1帯域に引き上げられました（field_method_comparison.csv）が、TesseractのCORDケースが下限を示しています：CER 0.9523の場合、LLMのフィールドF1は0.163です。LLMは読めないテキストからフィールドを抽出することはできません。

レシートに最速のOCRはどれですか？

このベンチマークではdocTRです：SROIE 2019で1ページあたり108.7 msのp50、毎分449ページ（summary_metrics.csv doctr/sroie_2019: latency_p50_ms、pages_per_minute）。テスト中最も遅かったSurya2は、p50で24.5倍遅く（2,668 ms）、スループットでは37倍遅い（毎分12ページ）結果でした。

このページの数値はどこから来ていますか？

すべての数値は、ファーストパーティのベンチマークで公開されているCSVの行です — results/summary_metrics.csv（8モデル×2データセット：CER/WER、フィールドF1、レイテンシ、コスト、スループット）と results/field_method_comparison.csv（regex vs LLM後処理）— は ImageToTableai/benchmark-ocr でホストされており、各実行に環境フィンガープリント用の編集済み manifest.json が1つ付属しています。データセットの定義は、以下に引用するSROIE 2019およびCORDの論文に基づいています。

方法論と情報源

プロトコル

このページは、独立した再現可能なベンチマーク実行（公式ティア）に基づく文書解析比較を報告するものであり、第三者による主張の調査ではありません。固定テスト分割のみを使用：SROIE 2019テスト（英語レシート361件、フラットフィールド：会社名/日付/住所/合計）およびCORD v2テスト（インドネシア語レシート100件、ネストフィールド：メニュー/小計/合計）。トレーニング分割は評価対象外です。各（モデル×データセット）ペアは、同じ画像、同じ正解データ、同じ測定プロトコル（warm_then_scored：スコア対象パスの前に固定ウォームアップパスを実行し、レイテンシは定常状態）を使用します。全16実行がerror_rate 0.0で完了しました（summary_metrics.csvのerror_rate列）。

実行環境

• ハードウェア：すべてのGPU実行はNVIDIA RTX 4090（24 GB）上で実施。GPUコストはRunPodのオンデマンド料金$0.76/時間で計算し、価格タイムスタンプは各実行の編集済みマニフェスト（2026年8月）に記録。TesseractはCPUのみで実行され、GPUコストは発生しません（CSVのコストセルは空）。
• エンジン：全モデルを追加調整なしで標準設定のまま実行。バージョンは実行マニフェストに固定。
• LLM後処理：deepseek-v4-flashをAPI経由で温度0に設定し、決定的な出力を生成（field_method_comparison.csvのllm_model列）。全LLMフィールド行で使用された唯一のモデルです。
• コスト基準：ウォールクロック実行時間×$0.76/時間（モデル初期化を含む）。バッチ処理によりページあたりのコストが低下します。
• フィールド後処理：SROIEフィールドメトリクスはpostprocessed_sroie_receipt_regex_* / LLMバリアントです。つまり、固定のregexセットまたはLLMによってOCR テキストから抽出されたフィールドを測定します。これらはOCRと下流の抽出を測定するものであり、モデルによるネイティブな構造化出力を測定するものではありません。

バージョンはベンチマークのモデルテーブル（README.md）および実行ごとの編集済みマニフェスト（results/manifests/、公開実行ごとに1つ、計16件）に記録されています。各マニフェストには、実行ID、モデルバージョン、ランナースクリプトのハッシュ、GPU/ドライバ、torch/CUDA/Pythonバージョン、pip-freezeハッシュ、価格タイムスタンプ付きのコストメタデータ、再現性のためのアーティファクトハッシュが記録されています。

指標の定義

• CER（文字誤り率）: OCRテキストと正解データ間の編集距離（挿入＋削除＋置換）を、正解データの文字数で割った値。低いほど良い。大文字小文字や表記規則に敏感。
• WER（単語誤り率）: 同じ編集距離の計算を単語単位で行ったもの。
• フィールド値F1（regex）: OCRテキスト上の固定regexパターンを用いて抽出したフィールド値に対する適合率・再現率の調和平均（従来型OCR＋ルールベースKIEパイプライン）。列名: regex_field_value_f1。
• フィールド値F1（LLM）: LLM後処理の出力（OCRテキスト → deepseek-v4-flash → フィールド）に対する同じ指標。列名: llm_field_value_f1。 2つのパイプラインは異なり、混在することはない。
• レイテンシp50/p95・pages/min: 定常状態での1ページあたりの推論時間（ウォームアップ後に計測、モデル読み込みは除外）と、モデル初期化を含む実時間スループット。
• 1,000ページあたりのコスト: 記録された$0.76/hrのレートでの1,000ページ分のGPU利用時間。CPUのみのTesseractでは空欄。

ソース一覧

1. summary_metrics.csv（GitHub raw）。16行＝8モデル×2データセット。列: model、compute_type、dataset、cer、wer、field_f1_regex、field_acc_regex、latency_p50_ms、latency_p95_ms、cost_per_1000_pages、pages_per_minute、error_rate。 このページのすべてのCER/WER、レイテンシ、コスト、スループットの数値は、ここの行に由来する。
2. field_method_comparison.csv（GitHub raw）。16行。列: model、dataset、llm_model（＝deepseek-v4-flash）、regex/LLMフィールド値の精度とF1、document-fields-exact、llm_median_latency_ms、トークン数。 すべてのregex/LLMフィールドF1の数値は、ここの行に由来する。
3. ImageToTableai/benchmark-ocrリポジトリ。結果CSV、匿名化された実行マニフェスト、固定プロトコル、再現用のデータセットサンプルリスト（固定テスト分割）を公開するパブリックリポジトリ。
4. results/manifests/（GitHub）。公開された各実行（16実行）につき1つの匿名化されたmanifest.json。環境フィンガープリント、モデルバージョン、コストメタデータ、成果物ハッシュを含む。
5. Huang et al.,「ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction」(2019)。SROIE 2019データセットの定義、タスク構造、ライセンス（CC-BY-4.0）。
6. Park et al.,「CORD: A Consolidated Receipt Dataset for Post-OCR Parsing」(2020)。CORD v2データセットの定義、ネストされたフィールドスキーマ、ライセンス（CC-BY-4.0）。

制限事項

• ドキュメントの範囲: レシートのみ（SROIE + CORD）。このベンチマークは、レイアウト・表・フォーム・長文ドキュメント、またはレシート以外のフィールドの処理については何も測定していません。文書解析VLMが最大の利点を主張するドキュメントタイプは、ここでは未測定のままです。このページを「従来型OCRはどこでも優れている」と結論付けるために使用しないでください。
• サンプルサイズ: 英語361件 + インドネシア語100件のレシート。フィールドF1とCERはコーパスに依存します。数百分の1の一桁の差はノイズとして扱い、工学的な真実とは見なさないでください。
• 単一GPUティア: すべてのGPU数値は、$0.76/時間の1台のRTX 4090からのものです。他のGPU、マルチGPUサーバー、またはバッチスケジューリングでは、レイテンシ、スループット、コストが変動します。
• CPU/GPUの非対称性: Tesseract（CPU）はGPUアクセラレーションエンジンと比較されています。そのレイテンシ/時間はCPUハードウェアを反映し、コスト優位性はGPU課金がゼロであることを反映しています。これは関連するすべての表に記載されていますが、非対称性は比較に内在するものです。
• LLM後処理は単一モデル: すべてのLLMフィールド行はdeepseek-v4-flashを使用しています。異なるLLMでは絶対的なF1が異なる可能性があり、収束の順序は限界的に変わる可能性があります。LLMレイテンシ（中央値約1.8〜2.4秒、field_method_comparison.csv llm_median_latency_ms）はAPIによるものであり、OCRエンジン自体のレイテンシには含まれません。
• コストのタイムスタンプ: $0.76/時間のGPU価格は、2026年8月の実行マニフェストに記録されたものです。GPUのスポット/オンデマンド価格は変動します。予算を立てる前に、現在のレートでコストを再計算してください。
• CORD CERは品質の指標ではありません: CORDのグラウンドトゥルースにはアノテーション構造が埋め込まれており、エンジンはインドネシア語でトレーニングされていません。CORD CER（全8モデルで0.90〜1.08）は、言語の不一致とグラウンドトゥルースのインフレを反映しており、モデルごとの読み取り品質ではありません。CORD行は意図的にSROIEランキングには統合されていません。
• Regexチューニング: regexパターンセットはデータセットごとに1回作成されました。ベンダーごとに高度にチューニングされたパターンライブラリは、独自のフォーマットでより高いスコアを獲得できる可能性がありますが、LLMが排除するメンテナンスコストがかかります。
• クラウド/APIモデルなし: AWS Textract、Google Document AI、Azure AI Document Intelligence、およびホスト型VLM API（例：クラウドOCRサービス）は含まれていません。これらのレイテンシと価格モデルは、ここで測定されたローカルエンジンとは根本的に異なります。
• バージョンの固定: 結果は上記の2026年8月のモデルバージョンに適用されます。新しいリリースでは結果が変わる可能性があり、大きなp95スパイクを持つ2つの測定（PaddleOCR、Docling）のp50レイテンシは、この実行のバッチパターンにおけるプリフィル/ファーストページ効果を反映しています。

関連リファレンス: フィールド抽出におけるregexの限界 · フィールドレベルと文字レベルの精度の比較 · レシートOCR精度 · ドキュメントタイプ別OCR精度データ

関連記事: AI OCRと従来型OCRの精度比較 · AIビジョン抽出がOCRと異なる画像の読み取り方法 · AIドキュメント抽出の価格（2026年）