Skip to content
Published on

文書 AI / OCR 2026 — Mistral OCR / Marker / Surya / LlamaParse / Docling / OlmoOCR 徹底ガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — 2026 年でも OCR が難しい理由

2026 年でも我々は PDF に苦しんでいる。請求書、契約書、保険約款、医療記録、学術論文、政府文書 — 人類が作成したビジネス文書の大半は依然として PDF だ。そのうちかなりの割合がスキャン画像 PDF か、テキストはあっても表・画像・数式・複数段組レイアウトが混ざっていて「ただテキストを抜く」ができない。

LLM が十分賢くなったので文書解析は解けた問題なのか。違う。2025 年だけで Mistral OCR、OlmoOCR、Reducto、LlamaParse の新版、Docling 1.0、Marker 1.0、Surya 0.6 が立て続けに出たという事実そのものが「まだ正解がない」という証拠だ。誰も一発で解いていない。

この記事は 2026 年 5 月時点の文書 AI エコシステムを 13 候補で地図化する。それぞれがどこに強く、どこで崩れるか、そして自分のチームが請求書・契約書・論文・RAG ingestion のどれをやるなら何を選ぶべきか、まで。

1. 2026 年の文書 AI 地図 — 4 段階パイプラインで整理する

文書 AI を一塊として見るとツール選びが効かない。段階に割って考える。我々は 4 段階モデルを使う。

段階やること入力出力
1. OCRピクセル → テキスト画像 / PDF文字 + 座標
2. レイアウトテキスト + 座標 → 構造OCR 結果ブロック・表・見出し・読み順
3. 抽出構造 → 意味フィールドレイアウト結果JSON (invoice_number, total, ...)
4. RAG ingestion意味 → 検索インデックス抽出結果チャンク化マークダウン + メタデータ

各段階は別ツールで解くこともあるし、1 つのツールが複数段階を吸収することもある。2026 年のトレンドは明確 — 段階が融合する方向。

  • Mistral OCR、OlmoOCR、Marker、Docling — OCR + レイアウトを一発で
  • LlamaParse、Unstract、Reducto — そこに抽出まで
  • マルチモーダル LLM(Pixtral、Florence-2、Claude、GPT-4o) — 4 段階を丸ごと吸収しようと試みる

融合がいいことばかりではない。1 段階が壊れたとき、どこが壊れたのかが見えにくい。なので我々は 段階ごとにツールを選んで組むパイプライン と end-to-end LLM 呼び出し の両方を使う。どちらが優位かはドメインが決める。

核心の洞察 — 2026 年でも単一モデルが OCR のすべてを解くわけではない。 請求書で良いものは学術論文で崩れ、韓国語で良いものは日本語で崩れる。ドメイン別ベストが別々にある。

2. Mistral OCR(2025 年 3 月) — 新しい標準 API

2025 年 3 月、Mistral が「OCR API」という名で独立した製品をリリースしたとき業界は驚いた。LLM 会社がなぜ独立した OCR API を出すのか。答えは「Mistral 7B のような自社モデルで RAG をやるには良い PDF パーサが必須なのに、市場に満足できるものがなかった」だ。

Mistral OCR が起こした変化は 3 つ。

  • 速度優先 — バッチで約 2,000 ページ/分。Marker のようなオープンソースに対して 1 桁速い。
  • レイアウト + 数式 + 表 + 画像位置のすべてを Markdown で返す — テキストだけでなく構造を返す。
  • ページ単位課金 — 1,000 ページあたり約 1 ドル。クラウド OCR(Document AI、Textract)の半額〜1/3。

API はシンプルだ。

from mistralai import Mistral

client = Mistral(api_key="...")
response = client.ocr.process(
    model="mistral-ocr-latest",
    document={"type": "document_url", "document_url": "https://example.com/contract.pdf"},
    include_image_base64=True,
)
for page in response.pages:
    print(page.markdown)

戻り値はページ単位の Markdown。表は GFM テーブル、数式は LaTeX、画像は base64 として埋め込まれる。一回呼ぶと Markdown + 埋め込み画像 + ページメタが一発で揃う。

弱点もある。韓国語/日本語などの非ラテン文字は英語/フランス語ほど安定しない(2025 年末に韓国語追加学習が入ったが、まだネイバー CLOVA OCR にはわずかに劣るとの報告が多い)。そしてクローズド API だ — 自己ホスト不可。

いつ選ぶか — 英語中心の PDF を素早く Markdown 化したく、API 費用を払える時。 特に RAG ingestion パイプラインを 1 週間で作る必要があれば、ほぼ常に最初の試行になる。

3. Marker(Vik Paruchuri) — PDF → Markdown オープンソースの王者

Marker は Datalab を作った Vik Paruchuri のオープンソースプロジェクト。「PDF を Markdown 化する」最も有名な OSS で、GitHub スター 3 万を超える(2026 年 5 月時点)。Mistral OCR が出るまでは「OSS で PDF を Markdown 化するほぼ唯一の答え」だった。

Marker の構成。

  • Surya — 同じ作者によるマルチリンガル OCR + レイアウトモデル(次章)
  • レイアウトモデル — DocLayoutYOLO 系のブロック分類
  • Markdown 変換器 — 表・数式・コードブロックを認識して GFM/LaTeX に変換
  • オプションの LLM リファイン — 曖昧領域を LLM に再質問して仕上げ

使用は 1 行。

pip install marker-pdf
marker_single contract.pdf output/ --output_format markdown

バッチ処理、ワーカー数、GPU/CPU 切り替え、LLM リファイン有効化はすべて CLI オプションで効く。

Marker の強みは 数式と表。LaTeX 数式だらけの学術論文では Mistral OCR よりきれいな結果を出すことが多い。そして自己ホスト可能 — GPU 1 枚のマシンで 30〜100 ページ/分が出る。データを外部に出せない企業に向く。

弱点は速度。CPU のみだと 1 ページ 5〜30 秒。GPU でも Mistral OCR より遅い。

いつ選ぶか — PDF を外部に出したくない(セキュリティ)、数式・表が重要な学術 / 金融文書が多い、または GPU リソースが潤沢な時。

4. Surya — マルチリンガル OCR + レイアウト + 読み順

Surya は Marker 内部で OCR を担当するモジュールだが、単体でも強力。同じ作者(Vik Paruchuri)で、「OSS で最もマルチリンガルに強い OCR」のポジションにある。

Surya が一発で解く 4 つのこと。

  • テキスト検出 — ページ上の文字領域を見つける
  • テキスト認識(OCR) — 90 言語、日本語・韓国語・中国語含む
  • レイアウト解析 — 見出し・本文・表・画像・キャプションを分類
  • 読み順 — 複数段組・図キャプション・脚注を人間の読み順に並べ替え

特に最後の「読み順」が重要。新聞や学術論文は段組が複数あり、サイドバー・脚注・キャプションが本文に絡む。単純な左上→右下スキャンではテキストが絡まる。Surya はトランスフォーマで人間の読む順を予測する。

from surya.recognition import RecognitionPredictor
from surya.detection import DetectionPredictor
from PIL import Image

image = Image.open("page.png")
det = DetectionPredictor()
rec = RecognitionPredictor()
predictions = rec([image], det_predictor=det)
for line in predictions[0].text_lines:
    print(line.bbox, line.text)

Surya の日本語/韓国語品質は 2026 年時点で OSS では最上位。ネイバー CLOVA OCR や Google Document AI の日本語/韓国語モデルにはわずかに劣るが、自己ホスト可能な OSS という点が決定的だ。

いつ選ぶか — マルチリンガル(特に CJK)の PDF を自己ホストで処理する必要がある時。 Marker の中に組み込まれているので単体呼び出しの機会は少ないが、OCR だけ切り出したい時は Surya を直接叩く。

5. LlamaParse(LlamaIndex) — RAG 用に最適化されたパーサ

LlamaParse は LlamaIndex チームの PDF パーサ。出発点が違う — 「RAG に使う良い入力を作る」が目標。なので Markdown 出力が LlamaIndex のチャンク分割器と相性よく設計されている。

LlamaParse の特徴。

  • 3 つのモード — fast(安い)、balanced(既定)、premium(LLM リファイン、表精度最強)
  • GFM 表として高精度 — premium モードの表認識が最強との評価が多い
  • 画像位置を保持 — Markdown 内に画像プレースホルダ
  • ページ単位課金 — fast の最初の 1,000 ページ無料、premium は 1,000 ページあたり約 3 ドル

API はシンプルだ。

from llama_parse import LlamaParse

parser = LlamaParse(
    api_key="...",
    result_type="markdown",
    parsing_mode="premium",
)
docs = parser.load_data("contract.pdf")
for doc in docs:
    print(doc.text)

特徴的な機能が parsing instructions — 「この文書は保険約款だから条項番号を見出しにして」のような自然言語ヒントを渡せる。内部で LLM がそのヒントを受けて解析を調整する。

弱点はコストとクローズド API。premium モードで 1,000 ページあたり 3 ドルは Mistral OCR の 3 倍。そして自己ホスト不可。

いつ選ぶか — すでに LlamaIndex ベースの RAG を運用しており、文書が表中心の時。 LlamaParse → SemanticSplitterNodeParser → ベクトルインデックスの流れがスムーズ。

6. Docling(IBM、オープンソース) — 企業向け総合パーサ

Docling は IBM Research が 2024 年末に公開したオープンソース文書パーサ。IBM 内部で「watsonx Discovery」という RAG 製品を作りながら蓄積したパース知見を切り出して公開したもの。

Docling が持ち込んだ差別化 3 点。

  • 豊富な出力フォーマット — Markdown だけでなく独自 JSON フォーマット(「DoclingDocument」)で座標・ブロック ID・段落・表セルまで保持
  • TableFormer — IBM が別途学習させた表構造認識モデル。ICDAR ベンチで SOTA
  • ローカル + GPU オプション — 自己ホスト可能、CPU でも動く

Docling のコード。

from docling.document_converter import DocumentConverter

converter = DocumentConverter()
result = converter.convert("contract.pdf")
print(result.document.export_to_markdown())
# または JSON 構造で
import json
print(json.dumps(result.document.export_to_dict(), indent=2))

DoclingDocument JSON はツリー構造。body の下に sections、sections の下に paragraphs / tables / figures が入り、各ノードがページ番号と bbox を持つ。これが重要 — 単純な Markdown では「この文が PDF のどこから来たのか」が逆引きできないが、Docling JSON ならページ・座標まで遡れる。RAG の出典表示(citation)にそのまま使える。

弱点は速度。Marker よりわずかに遅く、GPU がないと 1 ページ 10 秒を超えることもある。日本語/韓国語は英語ほど成熟していない。

いつ選ぶか — 自己ホストが必要で、RAG で「この答えの根拠が PDF のどこか」を正確に示す必要がある時。 企業のコンプライアンス環境にぴったり合う。

7. DocLayoutYOLO — レイアウト検出専門、速い

DocLayoutYOLO は OCR ではない。レイアウトだけ やる。PDF のページ画像を受け取って「ここはタイトル、ここは本文、ここは表、ここは図」のようなバウンディングボックスを返す。

なぜ別のモデルが要るのか。他の全ツールがレイアウトを内蔵しているのに。答えは 速度と組み合わせ自由度。DocLayoutYOLO は YOLOv10 ベースで GPU で 1 ページ約 10 ミリ秒で処理する。Marker や Docling 内蔵のレイアウトモデルより 1 桁速い。

DocLayoutYOLO + 好きな OCR(Tesseract、Surya、PaddleOCR)を組み合わせると自分専用のパイプラインができる。

from doclayout_yolo import YOLOv10

model = YOLOv10("doclayout_yolo_docstructbench_imgsz1024.pt")
results = model.predict("page.png", imgsz=1024, conf=0.2)
for box in results[0].boxes:
    print(box.cls, box.xyxy)

いつ選ぶか — レイアウト検出だけ要るか、OCR は別モデルで回しつつレイアウトを別建てで速くやりたい時。 大量文書を処理しつつ各段階の GPU 活用を最大化したいパイプラインに合う。

8. Nougat(Meta) — 学術論文専用

Nougat は Meta が 2023 年に公開した学術論文専用 OCR モデル。名前が意外だが「Neural Optical Understanding for Academic Texts」の略。arXiv 論文 800 万本で学習され、数式・表が多い学術 PDF では圧倒的だ。

Nougat の出力は Markdown + LaTeX 数式。他の OCR が数式領域を画像のまま残したり崩れたテキストに変換するところを、Nougat は LaTeX コードで正確に復元する。行列・積分・総和 全部できる。

pip install nougat-ocr
nougat path/to/paper.pdf -o out --model 0.1.0-base

弱点 — 学術論文以外ではしばしば崩れる。 請求書、契約書、一般 PDF では使い物にならない結果が頻繁に出る。学習データドメインが学術だから。

そして幻覚(hallucination)がある。Nougat はエンコーダ・デコーダのトランスフォーマなので「もっともらしい LaTeX」を生成する。原文にない数式を作ったり、数式を書き間違えるケースが報告されている。学術ドメインでも検証は必要。

いつ選ぶか — arXiv のような学術 PDF を大量に Markdown / LaTeX 化する時。 それ以外のドメインなら他のツールがほぼ常に勝る。

9. OlmoOCR(Allen AI、2025 年 2 月) — オープン重み、クラウド水準

OlmoOCR は Allen Institute for AI(AI2)が 2025 年 2 月に公開したオープン重み OCR モデル。名前が OlmoOCR なのは AI2 のオープン LLM 系列「Olmo」に OCR 能力を学習させたから。

OlmoOCR が起こした衝撃 — オープン重みなのに GPT-4o 水準の OCR 品質を見せる。 AI2 の自社ベンチ(olmOCR-Bench)で GPT-4o、Mistral OCR と同等か一部ドメインで上回る結果が出ている。

特徴は学習方式。AI2 は 7B のビジョン・言語モデル Qwen2-VL-7B をベースに、「PDF から抽出した正解テキスト」25 万ページで SFT した。正解は GPT-4o で生成して人が検証したデータセット。

import torch
from transformers import AutoProcessor, Qwen2VLForConditionalGeneration

model = Qwen2VLForConditionalGeneration.from_pretrained(
    "allenai/olmOCR-7B-0225-preview", torch_dtype=torch.bfloat16
)
processor = AutoProcessor.from_pretrained("allenai/olmOCR-7B-0225-preview")
# ... 画像 + プロンプトで推論

推論は 7B モデルなので GPU 1 枚に乗る。1 ページ約 1 秒(A100 基準)。推論コードを vLLM か SGLang でバッチ化すると速い。

弱点 — 7B なので VRAM 12GB は要る。OCR 専用ではなく VLM なので「指示を聞いて要約しようとする傾向」がたまに出る。システムプロンプトのチューニングが必要。

いつ選ぶか — クラウド API 費用を払えないがクラウド水準の品質が必要で、GPU がある時。 オープン重みで自己ホストが自由、ライセンス負担もない。

10. Tesseract 5 / LayoutLMv3 / Donut — クラシックと事前学習モデル

新ツールばかり見てはいけない。クラシックも生きている。

Tesseract 5

Tesseract は 1985 年に HP で始まり、Google が買収して後にオープンソース化された OCR エンジン。5.x(2021 年以降)は LSTM ベースに書き直され精度が大きく上がった。100 言語以上、CPU で速く、無料。

tesseract scan.png output -l kor+eng --psm 6

弱点は明確 — レイアウトを見ない。テキストだけ吐く。表を表として、見出しを見出しとして認識できない。なので 2026 年では「Tesseract + 別レイアウトモデル」の組み合わせで使う。または「すでにきれいな 1 段組テキスト PDF だけを処理するバックアップパイプライン」として。

いつ — オフライン・超低コスト・単一段組文書。

LayoutLMv3(Microsoft)

LayoutLMv3 は Microsoft Research が 2022 年に公開した事前学習済みドキュメント理解モデル。テキスト + 座標 + 画像パッチを 1 つのトランスフォーマに同時に入れて学習された。なので「ここはヘッダー、ここは合計フィールド」のような分類・抽出タスクに強い。

OCR は直接やらない。OCR 結果(テキスト + 座標)を入力として受け取り分類・抽出だけする。なので「Tesseract / Azure OCR + LayoutLMv3 ファインチューン」の組み合わせがよく使われる。FUNSD・CORD・SROIE のような IE(情報抽出)ベンチで強い。

いつ — 請求書・領収書・申込書のようにフィールドが決まった文書を大量に処理し、自社データでファインチューンできる時。

Donut(NAVER CLOVA AI)

Donut は NAVER CLOVA AI が 2022 年に公開した「OCR-free」ドキュメント理解モデル。名前は「Document Understanding Transformer」の短縮。他のモデルと違って OCR ステージをスキップする。画像をそのままトランスフォーマに入れて即座に JSON / Markdown を吐く。

これがなぜ重要なのか。伝統的なパイプラインは OCR → レイアウト → 抽出の 3 段階で、各段階のエラーが累積する。Donut は 1 モデルで終わらせる。特に CORD(レシート)、DocVQA、TICKET のようなドメインで強い。

弱点はドメインファインチューンが必要なこと。素のままの Donut を任意の PDF に投げると使い物にならない。自分のドメインデータ数千枚でファインチューンして真価が出る。

いつ — 同じ種類の文書(例: 韓国式レシート、米国 W-2)を数十万枚処理する必要があり、学習データを集められる時。

11. マルチモーダル LLM — Pixtral 12B / Florence-2 / KOSMOS-2.5

2025〜2026 年の新しい流れは マルチモーダル LLM に PDF ページをそのまま投げる 方式。別途 OCR も、別途レイアウトも、別途抽出器もなし。VLM が全部やる。

Pixtral 12B(Mistral、2024 年 9 月)

Pixtral 12B は Mistral の最初のマルチモーダルモデル。画像を受け取ってテキストで返す。PDF ページ画像を投げて「このページを Markdown にして」と言えば Markdown が出る。Mistral OCR が出る前は Pixtral で OCR をするユーザが多かった。

Florence-2(Microsoft、2024 年 6 月)

Florence-2 は 0.23B / 0.77B の小さいビジョンモデル。OCR、キャプション、物体検出、領域抽出を 1 モデルでやる。「small but strong」コンセプト — エッジ・オンデバイス向きに良い。

KOSMOS-2.5(Microsoft、2023 年 9 月)

KOSMOS-2.5 はテキスト豊富画像専用マルチモーダルモデル。スクリーンショット、文書画像を受けて Markdown に変換する。学術的影響は大きいが、実プロダクションでは OlmoOCR に席を譲りつつある。

Claude / GPT-4o / Gemini 1.5/2.0

商用マルチモーダル LLM も PDF 解析によく使われる。ページ画像を投げて「Markdown にして」で終わり。品質は良いがトークン費用が大きく(1 ページに数千トークン)、ページ数が増えると疲れる構造。

1 行結論 — マルチモーダル LLM はページ数少なめ・複雑なレイアウト・構造化抽出(JSON)で有利。大量 OCR ならコストと速度で Mistral OCR / OlmoOCR / Marker が前。

12. 韓国 — ネイバー CLOVA OCR と韓国語ドメイン

韓国語文書はグローバルツールにとって弱点が多い。ハングル形態素、漢字混用、縦/横書き混在、韓国独自の表書式が原因。ネイバー CLOVA OCR が韓国語ドメインで最強との評価が定着しているのはそのせい。

ネイバー CLOVA OCR の特徴。

  • 韓国語精度 95 パーセント以上(ネイバー自社ベンチ、印刷体基準)
  • 身分証・パスポート・自動車登録証のドメイン特化テンプレ
  • 表認識が韓国式の表(セル結合、点線枠)パターンに合わせて調整されている
  • API 呼び出し単位課金(月 10,000 件まで無料枠)
import requests, json

headers = {"X-OCR-SECRET": "..."}
files = {"file": open("doc.pdf", "rb")}
payload = {
    "message": json.dumps({
        "version": "V2",
        "requestId": "uuid",
        "timestamp": 0,
        "images": [{"format": "pdf", "name": "doc"}],
    })
}
r = requests.post("https://...apigw.ntruss.com/custom/v1/.../general", headers=headers, files=files, data=payload)

代替 — 韓国語に強い OSS として PaddleOCR(中国語・韓国語に強い)と EasyOCR(80 言語)がよく使われる。Surya も韓国語がかなり改善した(2025 年 0.5 以降)。

いつ CLOVA を選ぶか — 国内ビジネス文書(税金計算書、事業者登録証、領収書、銀行取引履歴)を大量処理する時。 ドメインテンプレが直接ハマる。

13. 日本 — Yomi-toku、Google Cloud Document AI 日本語

日本語文書には韓国語と違う難しさがある。横書き/縦書きの混在、振り仮名(ルビ)、漢字 + ひらがな + カタカナの混用、そして手書きの比重が大きい。

Yomi-toku(読みトク)

Yomi-toku は日本語特化のオープンソース OCR。日本語印刷体・縦書き・振り仮名に強い。日本政府デジタル庁の一部プロジェクトで採用され知名度が上がった。

pip install yomitoku
yomitoku scan.pdf -o output.json

Google Cloud Document AI 日本語プロセッサ

Google Cloud の Document AI はグローバルクラウド OCR の中で日本語品質が最も安定している。日本の請求書・見積書・領収書専用プロセッサが別途提供される。日本の SaaS / フィンテック企業がよく採用する。

その他

  • Tegaki(手書き) — 手書き専用 OSS ライブラリ
  • NDL OCR — 国立国会図書館が学習させたモデル、古典日本語・縦書きに強い

いつ何を — 国内限定ビジネス文書なら CLOVA、日本限定なら Document AI 日本語プロセッサ、両方ハマらないなら Surya / OlmoOCR から始めてドメインファインチューン。

14. 誰が何を選ぶべきか — 4 シナリオ

ツール 13 個を暗記する必要はない。シナリオで圧縮する。

シナリオ A — 請求書・領収書大量処理(IE)

フィールド(取引先、金額、日付、明細)が決まった文書を大量に処理し JSON として吐く。

  • 推奨スタック — Mistral OCR / Docling で Markdown 抽出 → LLM(Claude 3.5 / GPT-4o)で JSON 抽出
  • 自己ホスト必要時 — Marker → vLLM ホストの LLM
  • 数十万枚以上の規模 — Donut を自社データでファインチューン

シナリオ B — 契約書解析

100〜300 ページの PDF から条項を探して比較する。

  • 推奨スタック — LlamaParse premium / Docling で構造保持抽出 → チャンク分割 → RAG
  • 出典表示が重要 — Docling JSON(ページ・座標)で citation を正確に

シナリオ C — 学術論文(arXiv、学会誌)

数式・表・参考文献が多い PDF を大量処理。

  • 推奨 — Marker(数式に強い)または Nougat(arXiv 限定)
  • 以降 — LaTeX 保存された Markdown で RAG / 検索インデックス

シナリオ D — RAG ingestion パイプライン(雑食)

多様な PDF が毎日数百件入って検索インデックスに入る。

  • 手軽で速い — Mistral OCR API + 自動チャンク
  • 自己ホスト — Docling + 自社チャンクポリシー
  • 品質優先・予算余裕 — LlamaParse premium

核心 — 1 つで終わるツールはない。 ドメインが雑食ならフォールバックチェーンを組む。まず Mistral OCR → 失敗したら Marker → それでも失敗したらマルチモーダル LLM。

15. チームの最初のパイプラインを作る — 具体レシピ

理論はもう十分。1 週間で PDF 1 万枚を Markdown 化するパイプラインを作るとしよう。手順は以下。

ステップ 1 — サンプル 100 枚でドメイン分布を把握する。 表が多いか、数式が多いか、非ラテン文字が多いか、手書きがあるか。ドメインが雑食なら 1 ツールで解けない事実を先に受け入れる。

ステップ 2 — 同じ 100 枚を 2〜3 ツールで処理する。 候補は Mistral OCR、Marker、Docling、LlamaParse からドメインに合わせて 2〜3 個。社内評価スクリプトで GFM 表精度・見出し抽出・数式保存を見る。

ステップ 3 — 勝者をメイン、次点をフォールバックに。 メインツールで処理し、メインがあるページで失敗(ブロック数 0、表崩れ、信頼度低い)したらフォールバックで自動再処理。

ステップ 4 — メタデータを一貫して保存する。 Markdown 本文 +(ページ番号、bbox、ツール名、バージョン、信頼度)メタデータ。後で「どのツールがどこで良かったか」を比較するのにこのメタが要る。

ステップ 5 — LLM 抽出は別ステップに。 OCR / 解析と IE(フィールド抽出)は分ける。抽出は Claude / GPT-4o / Gemini で Markdown を受けて JSON を吐く構造。モデル切り替えが容易になる。

図にすると。

[PDF 1 万枚]
   |
[サンプリング 100 枚]
   |
[Mistral OCR / Marker / Docling を並列処理]
   |
[社内評価スクリプトでツール選定]
   |
[メインツールで 9,900 枚処理 + 失敗時フォールバック]
   |
[Markdown + メタデータ保存]
   |
[必要なら LLM で JSON フィールド抽出]
   |
[ベクトルインデックス / DB]

この順を踏めば 1 週間で安定したパイプラインができる。

エピローグ — 2026 年の文書 AI はまだ道のりが長い

文書 AI はようやく「使える」のしきい値を越えた。2024 年には「PDF から表をきれいに抜く」がほぼ不可能だったが、2026 年には Mistral OCR / Marker / Docling のどれを使ってもまあまあできる。1 年で大きな変化だ。

それでも終わった問題ではない。

  • 長文書の文脈 — 100 ページの契約書をページごとに分けて Markdown 化した後でも、「第 5 条が第 12 条をどう改めるか」のような cross-page の意味は別問題。
  • 手書きと古い文書 — Yomi-toku、NDL OCR のような特化モデルがあっても一般手書きは依然難しい。
  • チャートと図面 — 棒グラフ、回路図、医療チャートは OCR ではなく別問題。Florence-2、GPT-4o が挑戦中だがまだ。
  • 検証と幻覚 — LLM / VLM ベースの OCR には幻覚がある。ミッションクリティカルドメイン(法・医・金融)では検証レイヤが必須。

ツール 13 個を全部暗記する必要はない。段階に割り、シナリオでまとめ、ドメインが決める答えを受け入れる。 Mistral OCR が請求書では圧倒的でも学術論文では Marker に負ける。それが普通だ。文書 AI には「一発」がない。

参考 / References

Discuss on Twitter • View on GitHub