7,000ページのPDFに対するOCR処理：
1つの巨大ファイルが作業単位として不適切な理由

7,000ページのファイルの正体

数千ページのファイルをバックアップアーカイブとして扱うと、アプローチ全体が変わります。ドキュメントには読者がたどる構造があります。章、節、目次などです。アーカイブはコンテナであり、そこに問いかけられる有益な質問は、特定のページやフィールドがどこにあるかだけです。冒頭で「1000ページ以上のPDFファイルにテキストと表データが入っているが、誰かが画像として書き出してしまった」と述べているr/DataHoarderのスレッドは、まさにこの種のオブジェクトを説明しています。

OCRの前に、2分間のテストを実行してください。PDFを開き、カーソルでテキストを選択してみてください。テキストがハイライトされれば、ファイルにはすでにテキストレイヤーが含まれており、多くの場合、そのテキストからほぼ完璧な精度で必要なフィールドを直接抽出できます。カーソルが空のボックスを描き、何もハイライトされなければ、ページは画像であり、OCRが本当に必要です。このテストは2つのまったく異なる作業を区別するものであり、ほとんどのガイドが省略しているステップです。すでにテキストレイヤーがあるファイルにOCRを実行することは、不要な作業に1日分の計算リソースを費やす最も一般的な方法です。ページが本当に画像である場合の対処については、AIがスキャンしたPDFからデータを抽出する方法を参照してください。

巨大な1つのファイルがすべての段階で失敗する理由

巨大なPDFの失敗は構造的なものです。より優れたアプリでも、ページツリーや1ページに必要なメモリは変わりません。

ファイル内では、ページは読み取り順に保存されていません。ページはページツリーからぶら下がっています。これは、リーダーがドキュメントを組み立てるためにたどる分岐構造であり、ユーザーが操作する人間が読める目次はアウトラインツリーで、PDF仕様ではブックマークと呼ばれます（ISO 32000-1:2008、セクション7.7.3および12.3.3）。7,000ページのファイルは非常に大きなツリーを持ち、ドキュメント全体に触れるすべての操作はそのツリーを走査する必要があります。

PDF 1.5で追加された2つの機能により、実際の使用では状況が悪化します。ページ辞書、注釈、ブックマークなどの小さなオブジェクトは、圧縮されたオブジェクトストリームにパックでき、ドキュメントのクロスリファレンステーブルはクロスリファレンスストリームに置き換えることができます。どちらも標準の正当な部分であり（ISO 32000-1、セクション7.5.7および7.5.8）、どちらもリーダーがバイトオフセットでオブジェクト番号5,000にジャンプできないことを意味します。何かを見つけるには、ブロック全体を解凍する必要があります。そのため、600 MBのファイルは開くのが遅く、検索も遅く、ツールが内部をジャンプしようとするとハングします。

次にラスタライズがあります。これは、ツールが1ページを画像にレンダリングして読み取れるようにするステップです。ページあたりのメモリコストは過小評価されがちです。300 DPIでレンダリングされたA4ページは、約2,480×3,508ピクセル、生のカラーで約26 MBを占有します。600 DPIでは、1ページあたり約104 MBにまで上昇します。複数のページを同時に保持するデスクトップアプリケーションや、ドキュメント全体の1つのモデルを構築しようとするアプリケーションは、ロジックではなくメモリを使い果たします。

600 DPIの1ページは、認識が行われる前に約104 MBのメモリを占有する可能性があります。この数値が、巨大なファイルがデスクトップタスクなのかパイプラインタスクなのかを決定します。

Acrobatサポートフォーラムは、この問題の行き着く先を示す最も明確な公の記録です。あるユーザーは「約1500ページを超えるとクラッシュする」と報告しています。別のユーザーは「毎年、10,000ページを超えるPDFをいくつかOCRする必要がある」と述べ、Acrobatは「ファイルのOCRを試みるときも、分割しようとするとクラッシュする」と報告しています。3人目のユーザーは24,595ページのドキュメントについて質問しています。コミュニティの専門家は「Acrobatは低ボリュームのOCR向けのツールです」と要約しています（Adobeコミュニティスレッド）。このアプリは設計どおりに動作しますが、600MBの単一ファイルのジョブ用に設計されたことはありません。同じ境界線は、AcrobatのOCRとビジョンモデルの比較に関する、そのサイズを超えるドキュメントの説明にも現れます。

7,000ページのスループット計算

7,000ページの場合、有用な質問は、そのジョブに何時間と何ドルかかるかです。

Tesseractは、CPUベースラインの基準です。クリーンな印刷テキストでは、最新のCPUで毎分約25ページを処理し、独立したベンチマークでは、PaddleOCR（RTX 3090で毎分約120ページ）やEasyOCR（CPUで毎分約8ページ）などのより重いエンジンと比較して、そのレベルに位置付けられています。7,000ページをシングルスレッドのTesseractに投入すると、約280分、5時間弱かかります。EasyOCRのCPUパスでは、同じジョブが14時間以上に延びます。

これらの数値を変えるレバーは並列処理です。OCRmyPDFは、Tesseractエンジンをコマンドラインツールでラップし、ジョブ数を指定できるため、8コアで5時間の実行を約40分に短縮できます。前のセクションの注意事項は引き続き適用されます。ワーカーを増やすと、ページごとの常駐メモリも増えるため、RAMが控えめなマシンでは、多数のページを並列処理するよりも、少数のページを処理する方が速く完了します。

クラウドOCRは、制御を犠牲にして並列処理を提供し、ページ単位で課金されます。Google Document AIとAWS Textractはどちらも1,000ページあたり約1ドルで、7,000ページのドキュメントはリトライ前で10ドル未満になります。より高品質またはより構造化されたサービスはより高額で、Reductoの公開レートは1,000ページあたり10ドルです。予算がここでの制約になることはめったにありません。制約となるのは、7,000ページすべてをOCRする必要がめったにないことと、1つの巨大なファイルを扱うツールがジョブを面倒にしていることです。

実用的な手順は、コミットする前にサンプリングすることです。アーカイブの範囲をカバーする5〜10ページ（クリーンなページ、色あせたページ、密度の高いテーブル、異なるフォームレイアウトのページ）を抽出し、候補パスで実行して、実際のページ/分と実際のエラー率を測定します。独自の測定サンプルから外挿することは、上記の数値を含むベンチマーク表を信頼するよりも優れています。

手作業ではなく構造で分割する

大きなPDFへの対処法は、既存のツールに収まる単位に、ドキュメントがすでに宣言している境界線に沿って切り分けることです。

最適な境界線はアウトラインツリーです。PDFにブックマークがある場合、それはそのPDF自身の目次であり、各トップレベルのブックマークが自然な単位（章、明細期間、ファイリング）を示します。これらの境界線で分割することで関連するページがまとまり、後段の抽出精度が向上し、各ファイルに後で意味を判断できる名前を付けることができます。

ローカルで実行すべき処理とサービスに送るべき処理

適切な分担としては、ローカルマシンが切断とインデックス作成を担当し、実際に読み取りが必要なページをサービスが担当します。

qpdfやpdftkによる分割は高速で、ファイルをアップロードせずに直接処理でき、コストもかかりません。TesseractやOCRmyPDFによるOCRもローカルで実行できます。これは、アーカイブに見知らぬウェブアップローダーに渡したくない記録が含まれている場合に重要です。トレードオフはスループットです。1台のマシン、1つのCPUプール、そして処理中のページごとに実際のメモリコストがかかります。デスクトップツールは、単一ドキュメントの抽出ステップには依然として適切な選択肢であり、そのカテゴリの強みと限界についてはデスクトップOCRソフトウェアの比較で説明しています。

クラウドOCRサービスはハードウェアの制限を排除し、ページ単位で課金されます。また、アップロード上限があり、600 MBのファイルはすぐにその上限に達するため、サービスはファイルが分割された後にのみ有用になります。ブラウザベースの分割ツールは数十メガバイトに制限される傾向があり、ソースファイル自体には使用できません。

アーカイブと切断はローカルに保持してください。読み取りを行うサービスには、定義されたサブセットのみを送信してください。1回のコールで600 MBをアップロードできる製品は存在せず、ワークフローにもその必要はありません。

分割後に抽出が果たす役割

巨大なファイルがチャンクに分割されると、残りの作業は数千ページからいくつかの名前付きフィールドを抽出して、1つのスプレッドシートにまとめることです。

ここで抽出はOCRとは異なります。OCRはページの画像をテキストの壁に変換します。抽出はより具体的な質問に答えます。このページのドキュメント日付、ケース番号、口座番号、金額は何か？ビジョンベースの抽出ツールは、後で解析する必要のあるテキストを生成する代わりに、その質問に直接答えます。この違いは精度が入力に依存する理由で説明されているものと同じです。

カスタム列抽出は、必要なものから始まります。ドキュメント日付、ケース番号、口座番号などの列名を入力すると、ツールはすべてのページとレイアウトにわたって意味に基づいて各値を特定します。ページ400とページ4,000の間でデザインが変わるフォームでも、新しいテンプレートは不要です。ドキュメントタイプごとにトレーニングや設定が行われないためです。出力を定義するのはあなたであり、アーカイブは何も定義しません。

バッチファースト処理はボリュームを処理します。ファイルを1つずつではなく、ファイルのセットとしてチャンク全体をアップロードすると、結果はページごとに1行の単一のスプレッドシートにマージされます。スキャンされたドキュメントのバッチの場合、これはフォルダーに対するバッチOCRの実行と同じ考え方で、フォルダーからアーカイブにスケールアップされます。

パイプラインは、分割、バッチ、抽出の順になります。アーカイブを構造に基づいてチャプターサイズまたはページ数単位のチャンクに分割し、バッチごとに1つのチャンクをアップロードし、すべてのチャンクから同じ名前付き列を抽出します。出力はもはや7,000ページのドキュメントではありません。日付で並べ替え、ケース番号でフィルタリングし、空で返ってきたページをスキャンできるテーブルです。最後の部分は機能です。空白のセルは、そのページに読み取るものがなかったことを示し、数千行にわたってインデックスの正確性を維持します。

計画時に考慮すべき制限

どの製品も、600 MB・7,000ページのPDFを一度に取り込むことはできません。それを前提にした計画は初日から行き詰まります。重要な制限は公開されており、開始前に確認する価値があります。

したがって、7,000ページの作業は少なくとも7,000ファイルになります。Maxプランでは300件のバッチが約24回、Standardティアでは7,000クレジットになります。どちらの数字も、開始前にプランを確認すべき理由であり、どちらも作業ができない理由ではありません。

ページ数が多いと精度にも悪影響が出ます。文字起こしのエラーは量に応じて累積するため、120ページの処理中87ページ目のミスが、相互参照されるフィールドに波及する可能性があります。そのため、100ページを超えるあたりから、ほとんどのツールが論理的なセクションに分割することを推奨し始めます。これについては、マルチページPDF抽出で期待できることで詳しく説明しています。7,000ページの場合、分割の根拠は運用上のものであり、同時に精度に関わるものでもあります。

もう一つ、最も時間を節約できるルールがあります。すでにテキストレイヤーがあるものにはOCRを実行しないことです。サンプルページでテキスト選択テストが成功した場合は、テキストを直接抽出し、認識処理を完全にスキップしてください。

FAQ

7,000ページのPDFを一度にOCRできますか？

いいえ。600 MBの単一アップロードは、ファイルあたり10 MBの制限とサーバー側の50ページ制限を超え、デスクトップツールもその前にメモリが不足します。まずファイルを分割し、その後チャンクを処理してください。

手動で行わずにブックマークで大きなPDFを分割するにはどうすればよいですか？

Acrobatはトップレベルのブックマークで分割でき、Apryse PDF PageMaster、EverMap AutoSplit、DeftPDFなどのツールはより深いブックマークレベルをサポートしています。一般的なコマンドライン分割ツールであるqpdfはブックマークで分割できず、ページ範囲または固定ページ数で分割します。

600 MBのファイルでPDFリーダーがクラッシュするのはなぜですか？

単一ページを600 DPIでレンダリングするには約104 MBのメモリが必要で、複数ページを保持したりドキュメントのモデルを構築したりするリーダーは、デスクトップアプリの容量を超えてしまいます。圧縮されたオブジェクトストリームと高速Web表示レイアウトの欠如が、処理の遅延をさらに悪化させます。

数千ページのOCRにはどのくらい時間がかかりますか？

CPU上でTesseractを使用して毎分約25ページの場合、7,000ページはシングルスレッドで約4.7時間、8つの並列ワーカーで約40分かかります。クラウドサービスは多くのマシンで実行され、代わりにページごとに課金されます。

数フィールドだけが必要な場合、すべてのページをOCRする必要がありますか？

いいえ。必要なフィールドを指定し、それらを含むページに対して実行してください。日付、ケース番号、金額のインデックスが通常の成果物であり、アーカイブの完全な書き起こしではありません。

数千ページをOCRする最も安価な方法は何ですか？

ローカルのTesseractは実質的に無料で、CPUに制約されます。主要なクラウドOCR APIは1,000ページあたり約1ドルで、7,000ページのジョブは10ドル未満から始まります。より大きな節約は、すでにテキストレイヤーがあるページや不要なページでOCRをまったく実行しないことです。

ファイルのサイズは、その中のジョブの性質を示しています。7,000ページは、OCRの問題になるずっと前に検索の問題であり、構築する価値のある成果物は、最初から最後まで読むことのないアーカイブの忠実なコピーではなく、必要なページのインデックスです。ファイルをすでに分割されている場所で切り、関心のあるフィールドを指定し、バッチに残りを任せてください。

巨大なPDFから必要なフィールドを抽出する