自炊代行の納品PDFは検索に使えるか｜OCR精度を実際に確かめた

はじめに

自炊代行サービスで本を電子化すると、OCR処理込みのプランでは「検索可能PDF」になって返ってきます。
ただ、この「検索できます」がどこまで本当なのか、気になったことはありませんか。

以前、「スキャンピー」という業者に本の電子化をお願いした体験談を書きました。

プログラミング 本の自炊代行を初めて使ってみた｜スキャンピーに持ち込んだ流れと納品PDFの仕上がり 紙の本の電子化を自炊代行サービス「スキャンピー」に依頼した体験談です。業者を選んだ基準、2025年10月時点の料金とプラン、店舗への持ち込み、Boxでの納品までの流れと、届いたPDFのスキャン品質、その後AI用途で使ってみた結果までまとめました。

今回はその続編として、納品されたPDFのOCR精度を実際に確かめてみます。

結論を先に書くと、私の納品分では、日本語の本文はかなり正確にテキスト化されていました。
一方で、文字と文字の間に細かいスペースが大量に入る、プログラムのコードはほぼ壊れる、縦書きの本は読み取るツールによって挙動が変わるという、知らないと戸惑うクセもありました。
「文字は正確、区切りが苦手」というのが一言でのまとめです。

検証したのは手元の2冊だけなので、「私の納品分では」という範囲の話として読んでください。

検証の素材と方法

素材は、納品されたPDFの中から性格の違う2冊を選びました。

• 『リーダブルコード』（オライリー・ジャパン）：横書きの技術書。PDFで266ページ。本文にプログラムのコードがたくさん出てくるので、「記号だらけの文章」をOCRがどう扱うかが見られます
• 『アイデアのつくり方』（CCCメディアハウス）：縦書きの読み物。PDFで110ページ。日本の書籍は縦書きが多いので、縦書きの扱いは実用上かなり重要です

どちらも体験談で紹介した「バリューパック」（フルカラー＋OCR処理＋ファイル名設定込みのプラン）での納品分です。
PDFの中身を調べると、スキャン画像は約300dpiのJPEGで、横書き本・縦書き本とも同じ仕様でした。

確かめたことは3つです。

• テキストがどのページに入っているか：OCRされたテキスト層をページごとに抽出して数えました
• 「確実に本文にある語」が検索でヒットするか：ページを画像で目視して確認した語を、1冊につき10個（見出しの語・本文の語・固有名詞を混ぜて）選び、抽出したテキストに検索をかけました
• 誤認識の傾向：ページを画像化して、同じページのOCRテキストと突き合わせ、どんな間違いが起きるかを採取しました

ちなみに「検索可能PDF」は、スキャン画像の裏に透明なテキストを重ねた二層構造のファイルです。
この仕組み自体は別の記事で詳しく書いたので、興味のある方はこちらをどうぞ。

このあと数字がいくつか出てきますが、要点はそのつど日本語でまとめるので、数字は眺めるだけで大丈夫です。

結果1：テキスト選択と検索

テキスト層はほぼ全ページに入っている

まず「そもそもテキストが入っているか」ですが、これは合格でした。

• 『リーダブルコード』：266ページ中245ページにテキストあり（約19.7万字）
• 『アイデアのつくり方』：110ページ中104ページにテキストあり（約5.2万字）

テキストが無いページをいくつか画像で開いて確認したところ、いずれも白紙ページでした。
つまり「本文があるのにOCRが丸ごと抜けたページ」は、確認した範囲では見当たりませんでした。

語句の検索テスト：文字は入っている。でも「区切り」に注意

次に検索テストです。
本文に確実に載っている語を1冊10個ずつ、合わせて20語選び、抽出したOCRテキストに対して検索をかけました。

結果はこうなりました。

• 抽出したテキストから空白を全部取り除いてから検索すると、20語すべてがヒットしました
• そのまま検索すると一部が外れ、外れた原因はすべて文字間へのスペース混入でした

面白いのは1つ目です。
空白さえ落とせば全部見つかるということは、文字そのものはちゃんと正しい順序で入っているということになります。

では、そのまま検索で外れた語はなぜ外れたのか。
このOCRは文字と文字の間に細かい空白を挟むクセがあり、たとえば『リーダブルコード』の中の「コード」という語を数えると、次のようになっていました。

822件のうち、正しく検索できるのはわずか12件だけということです。

要するに、「検索に使えるか」への答えは「文字は高い精度で入っているが、語がスペースで割れているため、検索する側のソフトがこの空白をどう扱うかに依存する」になります。
空白を無視して検索してくれるビューアなら快適に使え、素朴に文字列一致で探すツールだと取りこぼします。

縦書き本は「読み取るツール」で挙動が変わる

もうひとつ、縦書きの『アイデアのつくり方』で興味深いことがありました。

テキスト抽出に使うツールによって、同じPDFなのに結果がまったく違ったのです。
あるツール（Xpdf系のpdftotext）では、縦書きの列を横方向に読んでしまい、本文が完全に文字の羅列に崩壊しました。
別のツール（poppler系のpdftotext）では、正しい読み順で抽出できました。

つまりテキスト層そのものには正しい順序で文字が入っていて、崩れるかどうかは読み取る側の問題でした。
縦書きの自炊PDFをテキスト化して使いたい方は、「PDF側が悪い」と判断する前にツールを変えてみてください。

細かい話ですが、縦書き本では句読点が「︒」「︑」という縦書き用の字形で入っている点も、コピペして使うときに気づくポイントです（『アイデアのつくり方』だけで約1,300件ありました）。

結果2：誤認識の傾向

ページ画像とOCRテキストを突き合わせて見つかった間違いを、種類別に紹介します。

日本語の本文：かなり正確。ただし「つ」と「っ」

日本語の文章そのものは、正直かなり優秀でした。
数ページを丸ごと突き合わせても、文字単位の間違いは数えるほどです。
見つかった典型例は促音・拗音まわりで、

• 「したがって」→「したがつて」（小さい「っ」が大きい「つ」に）
• 「ユニットテスト」→「ユニ ツトテス ト」（小さい「ッ」が大きい「ツ」に。スペースは前述の混入で、原文ママです）

という、昔からOCRが苦手なパターンです。
頻度は高くないので、読む・探す分には実害は少ないと思います。

記号・レイアウト：数字や柱がノイズになる

本文以外の要素では、こんな間違いがありました。

• 見出しの「6.6」→「6口 6」（ピリオドが「口」に）
• ページ上部の柱の「|」→「1」
• ページ番号「76」→「f6」「/6」
• 縦書きページ内に横書きで入っている「解説」の文字が、「説」「解」と1文字ずつ逆順に分解

ページ番号や柱（ページ上下の書名・章名）は毎ページ混入するので、テキストとして再利用する場合はここがノイズになります。

ルビ：本文に割り込んでくる

縦書き本ではルビ（ふりがな）の割り込みが見つかりました。
原文の「架空小説」（「ロマンス」というルビ付き）が「架 グ コ小 説」になり、ルビ自体も「ロニ・」という断片として別の行に混入していました。
ルビの多い本ほどこの種のノイズは増えるはずです。

プログラムのコード：ほぼ壊れる

そして今回いちばん豪快だったのがコードです。
『リーダブルコード』のサンプルコードは、こうなっていました。

原文（ページ画像より）:

void DisplayProducts(list products) {
    products.sort(CompareProductByPrice);
    // listを逆順にイテレートする
    for (list::reverse_iterator it = products.rbegin(); it != products.rend();

OCRテキスト層:

void DisplayProducts(tist products) {
products, sort (CompareProductByPrice) ;
ノノlistを 逆順にイテレー トする
for(liStく PrOduCt〉 ::reVerSe̲iteratOr it=prOduCtS・ rbegin(),it l=prOduCtS・ rendO;

listがtist、//がカタカナのノノ、.が,や・、!=がl=、おまけに大文字小文字も混ざっています。
正直、ここまで壊れるかと笑ってしまいました。
日本語向けのOCRなので仕方ない面はありますが、技術書のコードをテキスト層から拾うのは無理、と割り切ったほうがいいです。

この精度で何ができて何ができないか

ここまでの実測を、用途別に整理するとこうなります。
あくまで手元の2冊（n=2）での判断です。

• 読む：問題ありません。テキスト層は表示に影響しないので、スキャン画質のまま普通に読めます（画質については体験談に書いたとおり、私は満足しています）
• 探す：文字は正確に入っているので期待できます。ただし前述のとおり語がスペースで割れているため、使うビューアの検索がどこまで賢いかに左右されます
• コピペで引用する：そのままだと「コー ド」のようなスペースや縦書き字形の句読点が混ざるので、整形前提なら実用的です
• AIに読ませる：テキスト層をそのまま抽出して渡すと、スペース・柱・ページ番号・ルビのノイズごと渡ることになります。文章中心の本なら空白を除去する軽い前処理でかなり使えますが、コードや図表の多い本は厳しいです。なお、そもそも自炊PDFをNotebookLMなどに読み込ませるときの制限は別記事にまとめています
• 技術書のコードを拾う：できません。コードは原本を見るか、コード向けの手段を使ってください

精度が足りないときの選択肢

「この用途では納品OCRだと足りない」となった場合、納品PDFに自分で再OCRをかけ直す経路があります。

私が作ったキャプチャ・OCRアプリ（kindle_shot）には外部PDFの読み込み機能があり、納品PDFを画像として展開（DPI200〜300目安）してから、国立国会図書館が開発したOCRエンジン「NDLOCR-Lite」でOCRをかけ直せます。
NDLOCR-Liteは書籍・印刷物向けで、レイアウト解析機能を持っています。

この再OCRの効果は、その後に同じ本で実測しました。
結果は続編にまとめてあるので、精度を上げたい方はあわせてどうぞ。

プログラミング 自炊代行のOCRと国会図書館のOCR、どちらが正確か｜同じ本で再OCRして比較した 自炊代行で納品された検索可能PDFのテキスト層と、国立国会図書館のOCRエンジン「NDLOCR-Lite」でかけ直した再OCRを、同じ本の同じ9ページで比較しました。文字一致率は納品97.2%・再OCR97.6%でほぼ互角ですが、納品は文字が化け、NDLは文字が消えるという違いがあります。検証の手順、誤りの実例、所要時間、用途別の使い分けまでまとめました。

まとめ

いかがでしたか。今回は自炊代行「スキャンピー」の納品PDFのOCR精度を、手元の2冊で実際に確かめました。

• テキスト層はほぼ全ページに入っていて、日本語本文の文字精度は高い（検証した20語すべてが、空白を除けばヒット）
• ただし文字間にスペースが大量に混入する（「コード」822件中810件が「コー ド」に割れていた）ため、検索の快適さは使うソフト側に依存する
• 縦書き本のテキスト層は正しい読み順で入っている。抽出結果が崩れたら、PDFではなくツールを疑う
• 促音（つ/っ）・記号・ルビ・ページ番号にノイズが出る。そしてコードはほぼ壊れる
• 「読む・探す」には十分、「コピペ・AI利用」は軽い整形前提、「コードの再利用」は不可——というのが私の納品分での結論です

自炊代行を検討していて「OCRオプションは付ける意味があるのか」と迷っている方の判断材料になればと思います。
少なくとも私の納品分では、付けた価値は十分にありました。

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