Trying to improve my OCR-LLM document extraction: LLMアプリ実装で見る設計論点

description: OCRとLLMを組み合わせたドキュメント抽出パイプラインの改善を議論したStack Overflowの投稿を起点に、LangGraphを使った実装設計、プロンプト設計、評価・運用上の論点を整理します。

meta description: OCR×LLMによるドキュメント抽出の精度改善手法を、LangGraph・RAG・プロンプトエンジニアリングの観点から解説。実装時の注意点とPoC判断材料をまとめます。

---

何が出たのか

2026年6月10日時点でStack Overflowに投稿された「Trying to improve my OCR-LLM document extraction method. Any recommendations?」は、OCR（光学文字認識）とLLMを組み合わせたドキュメント抽出パイプラインの精度改善を求めるスレッドです。タグには artificial-intelligence、ocr、large-language-model、langgraph が付いており、LangGraph（LLMの処理フローをグラフ構造で定義するフレームワーク）を使った実装が前提になっています。

投稿のスコアは0、回答数は1、閲覧数は105と、まだ議論が始まったばかりの段階ですが、「OCRの出力をそのままLLMに渡しても精度が上がらない」という課題感は、同時期のHacker NewsやRedditのLLM関連スレッドでも繰り返し登場しているテーマです。具体的には、スキャンPDFや手書き帳票を扱うシステムで「OCRのノイズをLLMがどこまで吸収できるか」「構造化出力の安定性をどう担保するか」という問いが共通して挙がっています。

この記事では、その投稿を起点に、OCR×LLMパイプラインの設計論点を整理します。LangGraphを使った実装パターン、プロンプト設計の工夫、評価・運用上の注意点を順に見ていきます。

---

技術的に面白い点

OCRとLLMの役割分担を明示的に設計する

OCR×LLMパイプラインで最初につまずくのは、「OCRの出力品質のばらつきをLLMに丸投げしてしまう」設計です。OCRエンジン（Tesseract、AWS Textract、Google Document AIなど）が返すテキストには、文字認識ミス、改行の崩れ、表構造の消失といったノイズが含まれます。LLMはある程度のノイズを補正できますが、補正の範囲を超えると幻覚（hallucination）が発生しやすくなります。

LangGraphを使う利点は、この「OCR後処理 → LLM抽出 → 検証 → 再試行」という一連のステップをノードとエッジで明示的に定義できる点です。処理フローをコードで可視化することで、どのステップで精度が落ちているかをトレースしやすくなります。

```

[OCR実行] → [テキスト前処理] → [LLM抽出] → [スキーマ検証] → [OK / 再試行]

```

このフローをLangGraphのStateGraphとして実装すると、各ノードの入出力を型付きの状態オブジェクトとして管理でき、デバッグ時に中間状態を確認しやすくなります。

プロンプト設計：「何を抽出するか」を構造で伝える

LLMへの指示は自然言語で書けますが、抽出対象のフィールドが多い場合や、フィールド間に依存関係がある場合は、JSONスキーマやPydanticモデルを使って出力形式を明示する方が安定します。OpenAIのFunction CallingやStructured Outputs、AnthropicのTool Useはいずれも「期待する出力スキーマをAPIに渡す」仕組みを提供しており、2026年6月時点では主要モデルで利用可能です。

プロンプト設計で特に効果が出やすいのは以下の2点です。

• フィールド定義の明示「会社名を抽出してください」より「company_nameフィールドに、請求書ヘッダーに記載された発行元企業名を入れてください」のように、フィールド名と取得元を同時に伝える書き方が精度を上げやすいです。
• 不確かさの扱いOCRノイズで読み取れなかった箇所をnullで返すか、最も近い候補を返すかをプロンプトで明示しておくと、後段の検証ロジックを単純化できます。

LangGraphのConditional Edgeで再試行ロジックを組む

LangGraphのConditional Edge（条件分岐エッジ）を使うと、スキーマ検証の結果に応じて「再試行ノードに戻る」「エラーとして記録して終了する」「人間によるレビューキューに送る」といった分岐を宣言的に書けます。再試行回数の上限をStateに持たせることで、無限ループを防ぐfallbackも自然に実装できます。

Hugging Face上のLangGraph関連リポジトリでも、2026年6月前後にドキュメント処理系のサンプルが複数公開されており、再試行ロジックとロギングを組み合わせたパターンが増えています。

---

既存の流れとの違い

従来のOCR後処理との比較

従来のアプローチは、OCRの出力に対して正規表現やルールベースのパーサーを当てて構造化するものでした。この方法はフォーマットが固定された帳票には有効ですが、フォーマットが多様なドキュメント（取引先ごとに異なる請求書など）には対応しきれません。

LLMを組み合わせることで、フォーマットの多様性への対応力は大きく上がります。ただし、「ルールベースは決定論的で監査しやすい」という特性は失われます。LLMの出力は確率的であるため、同じ入力でも結果が変わる可能性があり、監査ログや出力の再現性を別途担保する設計が必要です。

RAGとの関係

RAG（Retrieval-Augmented Generation：検索結果をLLMの入力に組み込む手法）は、ドキュメント抽出パイプラインとは目的が異なります。RAGは「大量のドキュメントから関連情報を検索してLLMに渡す」用途に向いており、今回のような「1枚のスキャン帳票から特定フィールドを抽出する」用途とは設計の前提が違います。

ただし、「過去の類似帳票のサンプルをfew-shotとしてプロンプトに埋め込む」という使い方では、RAGの検索コンポーネントが役立つ場面があります。抽出精度が低いフォーマットに対して、類似フォーマットの正解例を動的に取得してプロンプトに追加する、というパターンです。

マルチモーダルモデルの選択肢

2026年6月時点では、GPT-4oやGemini 1.5 Pro、Claude 3.5 SonnetといったマルチモーダルモデルがPDF画像やスキャン画像を直接入力として受け付けます。「OCRを別途実行してテキストを渡す」パイプラインと、「画像をそのままLLMに渡す」パイプラインの2つの選択肢があり、それぞれトレードオフが異なります。

• OCR経由テキスト抽出の中間結果を確認・修正できる。OCRエンジンの選択でコストとレイテンシを調整しやすい。
• 画像直接入力パイプラインがシンプルになる。ただし、入力トークン数が増えるためコストとレイテンシが上がりやすく、画像品質への依存度が高い。

どちらが優れているかはドキュメントの種類と要件次第で、ベンチマークを自社データで取ることが判断の前提になります。

---

実装・運用で気になる点

評価基準の設計

OCR×LLMパイプラインの精度を測るには、「正解データ（グラウンドトゥルース）」が必要です。フィールドごとの抽出精度（完全一致率、部分一致率）を指標にするのが一般的ですが、金額や日付など型が決まっているフィールドは型変換後の一致で評価する方が実用的です。

評価データセットを用意せずにプロンプトを改善しようとすると、「感覚的には良くなった気がする」という状態に陥りやすいです。最低でも50〜100件の正解付きサンプルを用意してから改善ループを回すことを推奨します。

レイテンシとコストのトレードオフ

LLMのAPI呼び出しはレイテンシとコストの両方に影響します。1ドキュメントあたりの処理時間が許容範囲内かを早期に計測しておく必要があります。再試行ロジックを組む場合、最悪ケースのレイテンシ（最大再試行回数×1回あたりの処理時間）を見積もっておかないと、SLAを設定できません。

バッチ処理が許容される用途では、非同期処理とキューイング（例：Celery + Redis、AWS SQS）を組み合わせることでスループットを上げつつコストを抑えられます。

ログと監査

LLMの出力は確率的であるため、「いつ、どの入力に対して、どのモデルが、何を返したか」をログに残す設計が運用上必須です。LangSmith（LangChainのトレーシングツール）やArize AI、独自のログストアなど、選択肢はいくつかありますが、個人情報や機密情報を含むドキュメントを扱う場合は、ログの保存先と保持期間のポリシーを先に決めておく必要があります。

セキュリティと権限

スキャン帳票には請求書、契約書、個人情報が含まれることが多く、外部APIへの送信に際してデータ処理契約（DPA）の締結が必要なケースがあります。OpenAI、Anthropic、Googleはいずれもエンタープライズ向けのデータ処理オプションを提供していますが、利用規約の確認と社内の情報セキュリティポリシーとの照合は実装前に済ませておくべき作業です。

---

Spectralの見解

1. 技術的な読み

OCR×LLMパイプラインは、「ルールベースでは対応しきれない多様なフォーマット」に対する現実的な解法として成熟しつつあります。LangGraphのようなオーケストレーションフレームワークを使うことで、再試行・分岐・ログといった運用上必要な機能を宣言的に実装できる点は、プロダクション投入を見据えた設計として有効です。一方、マルチモーダルモデルの直接入力という選択肢も現実的になっており、「OCRを挟むかどうか」自体がアーキテクチャ上の判断ポイントになっています。

2. PoCで確認すべき点

• 自社ドキュメントでの精度計測汎用ベンチマークの数値は参考程度に留め、実際に扱うドキュメントのサンプルで抽出精度を計測することが先決です。
• OCR経由 vs 画像直接入力の比較同一サンプルで両パターンを試し、精度・コスト・レイテンシの三軸で比較することで、アーキテクチャ選択の根拠を作れます。
• 再試行上限と失敗時の挙動再試行しても精度が出ないケースをどう扱うか（人間レビューへの転送、エラーとして記録など）をPoC段階で決めておくと、本番設計がスムーズになります。

3. 業務・プロダクト実装に移す時のリスク

• 評価データの整備コスト正解データの作成は地味ですが、改善ループを回すための基盤です。このコストを過小評価すると、精度改善が感覚頼りになります。
• 外部APIへのデータ送信機密性の高いドキュメントを扱う場合、APIプロバイダーとのデータ処理契約と社内ポリシーの確認が必要です。オンプレミスや閉域網でのモデル実行が要件になるケースもあります。
• 出力の非決定性LLMの出力は同一入力でも変わり得るため、監査が必要な業務（会計、法務など）では出力ログの保存と人間によるサンプルチェックの仕組みを組み込む必要があります。

---

まとめ

OCRとLLMを組み合わせたドキュメント抽出パイプラインは、フォーマットの多様性に対応できる実用的なアーキテクチャです。LangGraphを使うことで処理フローを明示的に管理でき、再試行・分岐・ロギングといった運用上の要件を構造的に実装できます。

ただし、精度改善を進めるには評価データの整備が前提であり、「何を正解とするか」を定義しないままプロンプトを調整しても効果を測定できません。また、OCR経由と画像直接入力のどちらが適切かは、ドキュメントの種類と要件によって異なるため、自社データでの比較計測が判断の起点になります。

セキュリティ・監査・コストといった運用上の論点は、実装後に後付けで対応しようとすると設計の手戻りが大きくなります。PoC段階からこれらを設計の一部として扱うことが、プロダクション投入をスムーズにする近道です。

---

*Spectralでは、OCR×LLMパイプラインを含むLLMアプリの技術調査・PoC設計・プロダクション移行の支援を行っています。実装上の論点整理や自社ドキュメントでの検証設計についてご相談があれば、お気軽にお問い合わせください。*

関連論点として How reliable are LLMs when it comes to playing: LLMアプリ実装で見る設計論点 もあわせて読むと、この技術動向の背景を追いやすくなります。

Spectralでは、技術調査からPoC設計、プロダクト実装まで支援しています。実現性の確認や事業活用の相談は サービス詳細 と お問い合わせ をご覧ください。