本文へスキップ
Ztract

OCR とドキュメント抽出 — 文字はデータではない理由

OCR はスキャンしたページを文字に変えます。ドキュメント抽出はそれを、使えるフィールド——invoice_number、total、line_items——に変え、しかもそれぞれが元の出どころに紐づきます。OCR をかけたのに結局すべてを表計算ソフトに打ち直すはめになった経験があるなら、この違いこそが肝心です。あなたのワークフローに実際どちらが必要なのかも含めて解説します。

Ztract チーム 8 min read
  • comparison
  • ocr
プリント基板のクローズアップ。ページから文字を読み取ることと、機械が処理できる構造化データに変えることのあいだの隔たり。

請求書を山ほどスキャンして OCR ツールにかけ、それでも結局、数字を表計算ソフトに手で打ち込んでいた——そんな経験があるなら、あなたはこの記事のテーマである「隔たり」をすでに肌で感じています。OCR は自分の仕事を果たしました——ページの画像を文字に変えたのです。けれど、文字はデータではありません。1,250.00 という文字がページのどこかに現れていると分かったところで、それが小計でも税額でも先月の残高でもなく、支払合計額だということまでは教えてくれません。

その最後のひと区間——「ページに並ぶ単語はこれです」から「合計、取引先、そしてすべての明細行が、ラベル付きですぐ使える状態でここにあります」まで——を埋めるのが、ドキュメント抽出です。この記事では、その違いをわかりやすい言葉で説明し、それぞれがどんな場面に合うのかを示し、あなたのワークフローに実際どちらが必要なのかを見極める手助けをします。

OCR が実際にやっていること

OCR——光学文字認識——には1つだけ仕事があります。文字の画像を見て、その文字を出力することです。スキャンしたレシートを与えれば、文字起こしを返してくれます——店名、明細行、合計、日付——を、だいたい読む順番に並んだ、ひと続きの文字として。

これは、用途によっては確かに役立ちます。

  • スキャンした PDF を検索可能にする。 撮影した文書を Ctrl-F で探せるようにするのが、OCR の働きです。
  • アクセシビリティ。 スクリーンリーダーには、OCR が生み出すテキスト層が必要です。
  • 全文アーカイブ。 あとから文書を中身で探すだけでよいなら、OCR で十分です。

OCR がしないのは、文書を理解することです。どの数字が合計でどれが税額かは分かりません。真ん中の3行が明細で、いちばん下の行が合計だということも分かりません。「Acme Corp」が取引先で「Jane Smith」が担当者だということも分かりません。文字を渡すだけで、その意味はあなたに委ねられます。

ドキュメント抽出が加えるもの

ドキュメント抽出は、OCR が終わるところから始まります。ページの内容を受け取り、名前と型を持ったフィールド——表計算ソフトにも、データベースにも、別のシステムにもそのまま流し込める構造化オブジェクト——を返します。

{
  "invoice_number": "INV-2026-0412",
  "issue_date": "2026-05-30",
  "vendor": "Acme Corp",
  "total_due": 1250.00,
  "currency": "USD",
  "line_items": [
    { "description": "Design work", "quantity": 10, "unit_price": 100.00 },
    { "description": "Hosting", "quantity": 1, "unit_price": 250.00 }
  ]
}

OCR の文字起こしとこれとのあいだで、変わったことが3つあります。

  1. 値にラベルが付いている。 total_due は合計であって、たまたまページにある数字ではありません。どれがどれかを突き止める必要はありません——抽出がやってくれています。
  2. 構造が保たれている。 明細行は、平らに潰れた塊ではなく、行のリストとして返ってきます。1つしかないもの(請求書番号)と、複数あるもの(明細行)が分かれています。
  3. 型が正規化されている。 1250.00 は数値であって、文字列の "$1,250.00" ではありません。2026-05-30 は、文書がどんな書式で印字していようと、並べ替え可能な日付です。先に何かを整えなくても、計算や絞り込みができます。

違いはひと言にまとめられます。OCR は文字を、抽出はデータを渡してくれるのです。

並べて比べてみる

OCRドキュメント抽出
出力ひと続きのテキスト名前と型を持ったフィールド(JSON / CSV / Excel)
文書を理解する?いいえ——文字起こしするだけはい——合計・小計・税額を区別する
構造平らなテキスト、読む順番リスト・表・入れ子を保つ
すべて文字列数値・日付・真偽値を正規化
新しいレイアウト機能する(ただ読むだけ)取引先ごとのテンプレートなしで機能する
得意なこと検索・アーカイブ・アクセシビリティツールやワークフローへのデータ投入
打ち直しがまだ必要?たいてい必要不要

ほとんどのチームにとっていちばん大事なのは、最後の行です。数字で何かをしたい——照合する、合計する、会計システムに流し込む——のが目的なら、OCR は打ち直しの工程を目の前に残したままにします。抽出はそれを取り除きます。

「でも OCR はもうある——それで十分では?」

これがいちばんよくある質問で、正直に答えると、それはこの次に何をするか次第です。

文書を見つけて読むだけでよいなら、OCR で十分です——使わない複雑さを足す必要はありません。けれど、人間が OCR の出力を読んで値をどこか別のところに打ち込んでいるなら、その打ち込みの工程こそ、まさに抽出のためにあるものです。見分け方はかんたんです。あなたは画面から別の画面へ数字を写していませんか? もしそうなら、抽出が自動でやることを手作業でやっているのです。

これと近い落とし穴が、OCR の上に正規表現で自前の抽出を組むこと——「TOTAL で始まる行を見つけて、その後ろの数字を取る」というやり方です。最初の取引先ではうまくいき、2社目で壊れます。次の請求書は代わりに「Amount Due」と書いていたり、合計を別の場所に置いていたり、表が2ページにまたがっていたりするからです。新しいレイアウトのたびに、新しいルールが必要になります。このいたちごっここそ、テンプレート方式や regex 方式が、ほんのひと握りの書式を超えると拡張できなくなる理由です。

現代のドキュメント抽出はどこが違うのか

ひと世代前の抽出ツールには、レイアウトごとのテンプレートが必要でした——サンプル文書に枠を描いて「請求書番号はいつもここ、合計はいつもそこ」と指定するのです。これは、すべての文書が同じ見た目のときにしか機能しませんが、取引先・銀行・取引相手が1つを超えた時点で、それはまずありえません。

レイアウトを理解する抽出は、人が読むのと同じように文書を読みます——フィールドがページのどこにあるかではなく、それが何を意味するかを理解するのです。新しい請求書レイアウトは、テンプレートを用意しなくても一発で機能します。表が12ページにまたがって続く銀行明細も、きれいな1つのリストとして返ってきます。2つの言語が混じった通関書類も、各値を元の文字体系のまま保ちます。同じ考え方が領収書契約書本人確認書類履歴書検査報告書にも当てはまります——文書は違っても、考え方は同じ。ほしいものを説明すれば、エンジンがそれを見つけます。

「ほしいものを説明する」の実践編がほしい方には、まるごと1本の記事を用意しています。良い抽出スキーマの書き方です。

結果を検証するには?

生の OCR から構造化フィールドへ移ることについて、もっともな不安が1つあります。ツールが文字起こしするだけでなく文書を解釈するとき、その解釈が正しかったかどうかをどうやって確かめればよいのでしょうか。

その答えが、出どころ(プロヴェナンス)です。Ztract が抽出する値はすべて、元のページ上の正確な位置に紐づいています。出力の total_due をクリックすれば、元の文書で対応する箇所が光ります——だから数字の検証は、探し回ることではなく、ひと目で済みます。おかしく見えるフィールドをざっと探して、あればワンクリックで直し(修正は無料です——ページ数に数えられるのは抽出だけです)、それで完了です。自動化のスピードを手にしながら、自分で原本を読むのと同じ監査可能性も失いません。

では、あなたにはどちらが必要か

手早い判断ガイドです。

  • スキャンした文書を検索・アーカイブしたい → OCR で十分です。
  • 文書をスクリーンリーダーで読めるようにしたい → OCR で十分です。
  • 人が文書を読んで、値を表計算ソフト・ERP・データベースに打ち込んでいる → ドキュメント抽出が必要です。
  • OCR+regex を試したが、レイアウトが変わるたびに壊れる → 必要なのはルールを増やすことではなく、レイアウトを理解する抽出です。
  • 抽出したすべての値を、出どころまでたどって監査できる必要がある → 左右並びのビューアのような、出どころ付きの抽出が必要です。

Ztract にたどり着くチームのほとんどは、OCR から始め、打ち直しの壁にぶつかり、足りなかったのはより優れた文字認識ではなく——それらの文字をラベル付きのデータに変えることだった、と気づいた人たちです。

ご自身の文書でその違いを試してみる

この隔たりを体感するいちばんの近道は、ふだん実際に扱っている文書を抽出にかけて、文字の壁ではなく構造化された出力——ラベル付きのフィールド、本物の数値、行として並んだ明細——を見てみることです。新規アカウントには30 ページ無料の枠が付いていて、クレジットカードも不要です——いちばん厄介なレイアウトをいくつか試すには十分な量です。

そして、OCR と抽出のどちらが正しいツールか迷っているワークフローがあるなら、ぜひお聞かせください——間違ったものを売りつけるより、正しいやり方を選ぶお手伝いをしたいのです。

← Back to all posts