自炊代行のOCRと国会図書館のOCR、どちらが正確か｜同じ本で再OCRして比較した

はじめに

自炊代行サービスに本を電子化してもらうと、OCR処理済みの「検索可能PDF」が納品されます。
このOCR、自分でかけ直したらもっと良くなるのか、気になったことはありませんか。

前回、納品PDFのOCR精度を実際に確かめる記事を書きました。
その最後に「納品PDFに自分で再OCRをかけ直す経路があるが、効果までは検証していない」と書いて終わっていたので、今回はその宿題を回収します。
納品PDFと同じページに、国立国会図書館のOCRエンジン「NDLOCR-Lite」で再OCRをかけて、精度を正面から比較しました。

プログラミング自炊代行の納品PDFは検索に使えるか｜OCR精度を実際に確かめた自炊代行サービスから納品された検索可能PDFのOCR精度を、手元の2冊（横書きの技術書と縦書きの読み物）で実測した記録です。テキスト層がどのページに入っているか、本文にある20語が検索でヒットするか、どんな誤認識が起きるかを調べ、読む・探す・コピペ・AI利用・コードの再利用という用途別に整理しました。

結論を先に書くと、文字の正確さは全体でほぼ互角でした（納品97.2%、再OCR97.6%）。
ただし間違い方が正反対で、納品OCRは文字が「化ける」、NDLは文字が「消える」という違いがあります。
そして日本語の文章だけならNDLはほぼ完璧、前回問題だったスペース混入も日本語の本文では起きませんでした。
用途がAIやテキスト再利用なら、再OCRをかける価値は十分あるというのが私の結論です。

比較した2つのOCR

比較したのは次の2つです。

自炊代行の納品OCR：スキャンピーのバリューパック（フルカラー＋OCR処理込み）で納品されたPDFのテキスト層。どのOCRエンジンなのかは、PDFの中身を見てもスキャナーがCanon製ということしか分かりませんでした
NDLOCR-Lite：国立国会図書館が開発してGitHubで公開している、書籍・印刷物向けの軽量OCRエンジン。レイアウト解析機能があり、GPUなしのCPUだけで動きます

NDLOCR-Liteは、私が作ったキャプチャ・OCRアプリ「kindle_shot」に組み込んでいるエンジンです。
kindle_shotには外部PDFを読み込む機能があるので、「納品PDFを画像に展開 → 余白をトリミング → NDLOCR-LiteでOCR」という流れがコマンド3つで再現できます。
つまり今回の比較は「業者に付いてきたテキスト層」対「自分の手元で無料でかけ直したOCR」の勝負です。

【コピペ卒業】Kindle・電子書籍をPDF化＆OCRするアプリを作りました

ちなみに「検索可能PDF」がそもそもどういう仕組みのファイルなのかは、別の記事で詳しく書いています。

プログラミング「検索可能PDF」とは何か｜画像PDF・テキストPDFとの違いと「テキストレイヤー」の仕組み自炊やスキャンの話で出てくる「検索可能PDF」の仕組みを整理した記事です。画像PDF・テキストPDF・検索可能PDFの3タイプの違い、透明なテキストレイヤーを重ねた二層構造、OCRが何をしているか、ファイルサイズが軽くならない理由、用途別の使い分けまでをまとめました。

検証の方法

素材は前回と同じ、性格の違う2冊です。

『リーダブルコード』（オライリー・ジャパン）：横書きの技術書。本文にプログラムのコードが大量に出てくる
『アイデアのつくり方』（CCCメディアハウス）：縦書きの読み物。日本の書籍で多い縦書き組版の代表として

この2冊から、本文がしっかり詰まったページを9ページ選びました（リーダブルコード5ページ、アイデアのつくり方4ページ）。
横書きの地の文、箇条書き、コードブロック、白抜きの見出し、縦書きの地の文が混ざるようにしています。

再OCR側の手順は、kindle_shotのCLIでこの3コマンドです。

kindle_shot.bat pdf --in 納品.pdf --out 納品_pages --dpi 300
kindle_shot.bat trim --in 納品_pages --out 納品_trimmed --auto
kindle_shot.bat convert --in 納品_trimmed --out C:\books --format markdown --name 納品

PDFを300dpiで画像に展開し、余白を自動トリミングして、OCR結果をMarkdownで受け取っています。
OCR前処理（拡大・コントラスト強調）と置換辞書はkindle_shotの既定のままONです。
なので正確には「素のエンジン同士」ではなく「納品のテキスト層」対「kindle_shotのいつもの設定」の比較になります。

精度の測り方は次の通りです。

9ページ分の紙面を目視で文字起こしして「正解テキスト」を作る（計4,159字）
正解と各OCR結果を1文字ずつ突き合わせ、置換・脱落・余計な挿入が何文字分あるかを数える（編集距離と呼ばれる数え方です）
一致した割合を「文字一致率」とする

なお、前回わかった「文字間にスペースが大量に混入する」問題は、今回の文字一致率には含めていません（空白を全部取り除いてから比較しています）。
全角半角やダッシュの字形ゆれも誤りには数えていません。
また、ページ上下の柱・ページ番号と、読み取り順序が媒体でずれたコラム1か所は、比較対象から外しています。
つまり今回の数字は「文字そのものをどれだけ正しく読めたか」だけを見た、両者に公平な条件です。
ちなみにこの検証の実作業（ページの転記や突き合わせ）は、Claude Codeに任せました。

結果1：文字の正確さは、ほぼ互角

まず全体の文字一致率です。

OCR	全体の文字一致率
自炊代行の納品OCR	97.2%
再OCR（NDLOCR-Lite）	97.6%

正直、この数字を見たときは拍子抜けしました。
「再OCRをかければ圧勝」を少し期待していたのですが、トータルではほぼ互角です。
納品OCRは前回「文字は正確」と評価した通り、文字単位ではかなり優秀でした。

ただ、注目してほしいのが縦書きの『アイデアのつくり方』です。
NDLは4ページ中4ページが誤りゼロ、つまり縦書きの本文は1文字も間違えませんでした。
横書きの技術書でも、コードのない地の文だけのページは99.7%でした。
NDLが点を落としたのは、ほぼすべてコードと記号がらみの箇所でした。

結果2：納品OCRは「化ける」、NDLは「消える」

数字がほぼ同じでも、間違い方はきれいに正反対でした。
ここが今回いちばん面白かったところです。

納品OCRの間違い方：文字が別の文字に化ける

納品OCRの誤りは、ほぼすべて「置換」です。
つまり、何かしらの文字は出力されるけれど、別の文字に化けています。

「空白」→「空自」、「クリエイティブ」→「クリエイテイブ」、「したがって」→「したがつて」
// → ノノ、list → tist、Python → Iyhon、6.6 → 6口6
白抜きデザインの「第I部」→「鰊颯蒻鰈」（もはや暗号です）
縦書きページの漢数字「一八八〇―一九三〇」→「一八ハ〇―二九二〇」、「進化論」→「造化論」

パターンとしては、似た形の字への誤変換（O→0、l→I、九→え）と、記号の日本語化（// → ノノ）が中心です。
化けた文字は目で見ればすぐ「おかしい」と分かるので、発見はしやすいです。

NDLの間違い方：あったはずの文字が消える

一方のNDLは、置換よりも「脱落」が目立ちました。
出力された文章は自然に読めるのに、原文にあった要素がこっそり抜けています。

箇条書きの「ServerCanStart() よりも CanListenOnPort() のほうが明確だ」から、CanListenOnPort() だけが丸ごと消える
URL例の /biz/ac-joes-tire-smog-inc が丸ごと消える
変数名のアンダースコアがほぼ全滅（_ms → ms、url_path_name → url path name）
箇条書きの区切りに使われるダッシュ「——」が消える、「第I部」の「I」が消える

こちらは文字単位の置換も少しあります（retval → rehial、Python → Pvthon）。
ただ怖いのは脱落のほうで、出力だけ読むと欠けていることに気づけません。
「コード」のように見た目が壊れる納品OCRと、きれいな顔をして中身が欠けるNDL。
どちらの誤りが困るかは、このあとの用途の話につながります。

結果3：前回の弱点は再OCRで直るのか

前回の記事で挙げた納品OCRのクセが、再OCRでどうなったかを並べます。

文字間のスペース混入：前回は「コード」822件中810件が「コード」に割れていました。NDLの出力は、日本語の本文へのスペース混入がゼロです（コード行には多少残ります）。検索やコピペを邪魔していた最大のノイズが消えます
縦書きの句読点が「︒」「︑」になる：NDLは普通の「。」「、」で出力します。縦書き特有の字形問題は起きませんでした
柱・ページ番号のノイズ：納品テキスト層は毎ページ柱（ページ上下の書名・章名）が混入しますが、kindle_shot経由の出力では9ページ中7ページで柱が出てきませんでした
促音の「つ」「っ」：納品OCRで見つかった「したがつて」問題は、NDLの出力では起きませんでした
プログラムのコード：これはどちらもダメです。ただし壊れ方が違い、納品OCRは記号が化け、NDLは記号や識別子の一部が消えます。技術書のコードをテキスト層から拾うのは無理、という前回の結論は再OCRでも変わりません

日本語の文章として使う分には、前回の弱点がほぼ全部解消される、という結果でした。

所要時間：9ページで36秒

再OCRにかかった時間も測りました。
私のWindows機で、9ページの変換が2冊合計36秒ほどです（画像の前処理込み。NDLOCR-LiteはGPUなしのCPUだけで動きます）。
単純計算だと266ページの『リーダブルコード』1冊で18分前後になります。
画像への展開やトリミングの時間は別にかかりますが、どちらも放置でいい処理なので、寝る前に仕掛けておけば十分な速度かと思います。

で、どちらを使えばいいのか

用途別に整理するとこうなります。

読む・ビューアで検索する：納品PDFのままで大丈夫です。文字精度は十分高く、スペースを無視して検索してくれるビューアなら快適に使えます（このあたりの挙動は前回記事に書きました）。わざわざ再OCRする必要はありません
AIに読ませる・テキストとして再利用する：再OCRに分があります。スペース・柱・字形のノイズがないぶん、そのままMarkdownとしてNotebookLMなどに投入できます。納品テキスト層を使う場合は空白除去などの前処理が必要でした
正確さが命の引用・転記：どちらか一方を信じるのは危険です。特にNDLは「自然に読めるのに欠けている」タイプの誤りがあるので、最後は原本画像との突き合わせが要ります
コードの抽出：どちらも不可です。原本を見てください

私自身は「本をAIに読ませるためのテキスト化」が主目的なので、納品PDFであっても再OCRをかける運用に落ち着きそうです。
自炊代行のOCRオプション自体は「読む・探す」用途に十分な品質なので、前回の評価を下げるものではありません。
納品PDFはあくまで画像がきれいな原本として保管し、テキストは用途に応じて自分で作る、という役割分担です。

まとめ

いかがでしたか。
今回は自炊代行の納品OCRと、kindle_shot＋NDLOCR-Liteの再OCRを、同じ本の同じ9ページで実測比較しました。

文字一致率は納品97.2%、再OCR97.6%でほぼ互角（2冊9ページ・4,159字での実測です）
ただし納品OCRは「化ける」誤り、NDLは「消える」誤りと、性格が正反対
縦書きの本文はNDLが誤りゼロ。スペース混入・柱・縦書き字形のノイズも再OCRでほぼ解消
コードはどちらも壊れる。引用・転記の最終確認は原本で
再OCRは9ページ36秒（CPUのみ）。1冊単位でも現実的な速度

再OCRに使ったkindle_shotの紹介記事と、前回のOCR精度検証、関連記事はこちらです。

ちなみに検証に使った『リーダブルコード』は、コードの読みやすさを扱った定番の技術書です。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

※本記事にはAmazonアソシエイトのリンクを含みます。

この記事が誰かの役に立てばうれしいです。