実際のフォルダに耐えるバッチOCR：すべてのファイルをキューに入れ、追跡し、納品する
ほとんどのバッチOCRツールはフォルダを単一の一様なジョブとして扱うため、1つの不良ファイルで実行が停止します。ここでは各ファイルが1ページあたり5〜10秒で個別に処理され、独自のステータスを保持するため、200件中3件の失敗は3件のやり直しだけで済みます。
1ページあたり5〜10秒・PDF/JPG/PNG/WebPを1つのキューで・ファイルごとのステータス・印刷テキストで最大99%の精度
バッチOCR実行で各ファイルに得られる成果
バッチOCRとは、1つのドキュメントではなくフォルダ全体に1つのエンジンを向けることであり、重要なのは実行中に各ファイルで何が起こったかを把握できることです。共有スキャナから取り込んだPDFのバッチOCRと、スマートフォンで撮影した画像のバッチOCRを同じ実行で行えます。キューがすべての形式を同じように扱うためです。
ステータス、テキスト、メタデータはファイルごとに追跡されます。生の読み取り結果だけが必要な場合は、スプレッドシートの行にテキストとして、または各ファイルのレイアウトを保持した編集可能なWord文書として取得できます。後で全文ではなく列が必要になった場合は、必要な列名を入力すると、AIがページ上の各値を特定します。同じ実行で、再アップロードせずに構造化抽出にフィードできます。
バッチOCRは1つのジョブに見える。実際のフォルダは200の小さなジョブだ。
バッチOCRをオンラインで検索すると、2つのタイプのツールにたどり着く。バッチモードがウィザードの中に隠れているデスクトップスイートと、画像のスタックをキューに入れるオンラインコンバーターだ。どちらも開始を売りにしており、開始自体は簡単だ。文字の読み取りは、フォルダ規模のOCRで難しい部分では決してなかった。難しいのは運用面だ。開始をクリックしてから1時間の間に200のファイルに何が起こるか、どの3つが失敗したかをどうやって知るか、実行終了時にテキストがどこに出力されるか。以下のすべての比較は、その1つの違いにかかっている。
従来の実行があなたに委ねる3つの操作
同じ質問を200回繰り返す。 デスクトップツールは、ドキュメントごとに何かを尋ねて停止することがよくあります。Adobeコミュニティフォーラムのユーザーは、その手順を次のように説明しています：「このプロセスでは、各ドキュメントの品質設定を順番に確認し、OCR後に最適化された状態でファイルを保存することを確認する必要があり、これらはすべて依然として煩わしいものです。」200ファイルのフォルダは、回避策を見つけない限り、200回の確認になります。
失敗は見えないため、何をやり直すべきかわからない。 Kofax Power PDFヘルプページには、次のように明確に記載されています：「黄色または赤はOCRが失敗したことを意味します。ファイル名の横に黄色または赤の円が表示された場合は、再試行するか、ドキュメントをサポートチームに送信してください。」円が表示された後は、自己責任です。実行によって、不良ファックスが出力を汚染したかどうか、どのファイルが影響を受けたか、何をやり直すべきかが通知されることはありません。
1台のマシンがフォルダ全体を自らの時間で処理する。 従来のデスクトップバッチOCRソフトウェアは、ローカルハードウェア上で順次実行されます。システム管理者が約5000のPDFファイルのOCRについて尋ねたところ、現実的な見積もりは「約8〜11時間」であり、同じコメンテーターは「高速なOCRリーダーは品質を犠牲にしていることがわかった」と認めました。速度か精度か、机の上の時計がそれを決定します。
マネージド実行で手間が省けること
1つのキュー、事前仕分け不要。 共有スキャナの保存先からPDFのバッチOCRが仕事で、同僚が現場訪問の写真を追加する場合も、両方とも同じバッチに入ります。PDF、JPG、PNG、WebP、さらにはWordやテキストファイルも1つのパイプラインで処理され、「PDF設定」と「画像設定」を分ける手順も、後でマージするための別々の実行も不要です。
悪いファイルは1回のやり直しで済み、実行全体が台無しになることはありません。 ビジョンモデルは各ドキュメントを個別に読み取り、ファイルごとのステータス（待機中、処理中、完了、失敗）を報告します。傾いたスマホ写真で文字が薄く返ってきても、フォルダ全体が失敗することはありません。処理は完了し、フラグが付けられ、判断はあなたに委ねられます。200件中3件の不良ファイルなら、やり直しは3回だけです。ビジョンモデルは意味で読み取るため、きれいなスキャンと見づらいFAXで最初から品質設定を分ける必要はありません。
出力形式は明確：ファイルごとに1行。 処理は1ページあたり5〜10秒かかり、結果は1つのスプレッドシートになります。ファイルごとに1行、抽出されたテキストはセル内に、ファイル名とステータスはその隣に表示されます。散在する200個の.txtファイルを収集するスクリプト手順も、どの言葉がどのドキュメント由来か分からない匿名の塊もありません。1回の実行が終われば、何が得られたか、どの行を再確認すべきかが正確に分かります。
6つのカードに共通するテーマ：実行の開始が問題だったことは一度もない。フォルダ規模のOCRが機能するかどうかを決めるのは、各ファイルがキューに入った後にどう扱われるかだ。ファイルごとの問い合わせなし、失敗が自ら名乗り出る仕組み、そして確認できる場所にテキストが出力されること。次のセクションでは、アップロードからエクスポートまでの実際の実行を1つ追い、この3つが順番に機能する様子を確認する。
200ファイルの山を、ターミナルなしで整理できるテキストに
スキャンの滞留を解消するなら、バッチ実行が開始からエクスポートまで実際にどう進むかをご紹介します。
未整理のままフォルダを投入
滞留ファイルは200件：オフィスの複合機からのきれいなスキャン140件、紙のフォームのスマホ写真40件、デジタル生成のPDF 15件、暗号化された明細書5件。これらをまとめてドラッグします。PDF、JPG、PNG、WebPは同じキューに入り、パスワード付きPDFは指定したパスワードでロックが解除され、ファイルごとに設定確認を求められることはありません。
キューの進行を確認
1ページあたり5〜10秒なので、200ページのフォルダは約17〜33分で完了します。同じ内容を手入力すると1ページあたり約3分、合計で約10時間かかります。ファイルごとにステータスが更新されるため、FAXが薄く届いた場合も、その場でフラグが付くのが分かります。残りのファイルは処理を続け、スピナーがすべてを1本のプログレスバーの背後に隠すことはありません。
エクスポートは1回、再実行は3件
バッチを1つのXLSXとしてエクスポート：200行、1ファイルにつき1行、抽出されたテキストがセルに入り、ステータスが横に並びます。ステータスで並べ替えて3件の失敗を確認し、そのファイルだけを再アップロードして単独で再実行します。次のステップが全文ではなく構造化フィールドの場合は、同じフォルダをバッチデータ抽出やバッチドキュメントからExcelへ（列名付き）に渡せます。アップロードを2回行う必要はありません。
この実行が適している場面と、コマンドラインツールがより適している場面
ここでのバッチOCRは、フォルダを読み取ってテキストを提供することを意味します。何ができないかを知ることで、作業に合わないツールを選ぶことを防げます。
最適な用途
印刷物と手書きが混在するフォルダ。スキャン、写真、既にデジタル化されたPDFを1つのキューで処理し、印刷テキストは最大99%の精度で認識。手書きやチェックボックスも同じパスで読み取ります。
検索・仕分け・再利用のためのテキスト抽出。成果物はすぐに使えるテキストです。スプレッドシートにファイルごとの全文を出力するか、散文ではなく構造化したい場合は名前付きの列として出力します。
インストール不要でどのマシンからでも実行可能。ブラウザベースで、ライセンスサーバーもファイルごとの設定も不要。1回限りのバックログもラップトップ1台で半日で片付けられます。
注意が必要な用途
検索可能なPDFライターではありません。テキストはスプレッドシートのセルやドキュメントとして出力され、元のPDFファイル内に不可視のテキストレイヤーとして埋め込まれるわけではありません。数千ファイルにわたるアーカイブ級の検索可能PDF変換は別の作業であり、OCRmyPDF系のコマンドラインツールの方が適しています。
フォルダ監視はなく、バッチは手動で実行。1バッチで処理できるのは最大数百ファイルまで。数千ファイル規模のアーカイブは、自分で開始するアップロードの繰り返しになります。自動化ファーストの環境（ホットフォルダ、スケジュール実行）は別のカテゴリのツールです。
著しく劣化した原稿は依然として困難。ぼやけたFAX、200 DPI未満のスキャン、サーマルレシートは、どのエンジンでも精度のボトルネックになります。最悪のファイルにはレビュー時間を費やす前提で臨み、ゼロにすることは期待しないでください。また、既にテキスト選択が可能なファイルにOCRを再実行するのは無駄なので、それらはスキップして画像ベースのファイルのみをバッチ処理してください。
よくある質問
バッチOCRを実行する前に、フォルダ内のファイルを整理する必要がありますか？たとえば、PDFを1つのバッチに、スマホの写真を別のバッチにするなど？
整理の必要はありません。1つのバッチにPDF、JPG、PNG、WebPファイルをまとめて入れることができ、パスワード保護されたPDFも対応しています。ビジョンモデルはすべてのファイルを同じ方法で読み取ります。ピクセルを見て内容を読み取るため、ネイティブPDF、300 DPIのスキャン、傾いたスマホ写真も、フォーマット別のパイプラインやファイルごとの設定なしで1つのキューに入ります。ソース形式は出力の各行に記録されるので、後でフィルタリングしたい場合に便利です。
バッチOCR実行中に200ファイル中3ファイルが失敗した場合はどうなりますか？
残りの197ファイルは処理を続行し、何も停止しません。各ファイルは独立して処理され、そのステータスはバッチビューでファイルごとに追跡されます：待機中、処理中、完了、失敗。失敗した3ファイルはマークされたままになるため、それらのファイルだけを開いて、どのファイルが文字化けしたかを確認し、単独で修正または再アップロードし、フォルダ全体ではなくそれらのファイルだけを再実行できます。失敗のコストは1ファイルのやり直しだけで、バッチ全体のやり直しにはなりません。
各ファイルに個別の出力が作成されますか、それとも実行全体が1つのファイルに統合されますか？
1つのスプレッドシートに、ファイルごとに1行ずつ出力されます。バッチをエクスポートすると、単一のXLSXまたはCSVが作成され、各ドキュメントが1行になります：ファイル名、ページ数、ファイルごとのステータス、抽出されたテキストがセルに入ります。手動で統合する必要がある200個の散在する.txtファイルを受け取ることも、どの単語がどのドキュメントからのものか判別できない匿名のテキストブロックを受け取ることもありません。並べ替え、フィルタリング、アーカイブの判断はスプレッドシート上で行います。
バッチOCRで検索可能なPDFを作成できますか？
いいえ、その点は明確にしておく価値があります。このツールはドキュメントを読み取り、テキストをデータとして返します：スプレッドシートのセル、構造化された列、または編集可能なWordファイルとして。元のPDFファイルに不可視のテキストレイヤーを書き戻すことはありません。何千ものファイルにわたってアーカイブ品質の検索可能なPDFを作成することが目的なら、OCRmyPDFファミリーのコマンドラインツールが適しています。テキストを取り出して、他の場所で検索、並べ替え、編集することが目的なら、こちらがより軽量な方法です。
1回のバッチOCR実行にいくつのファイルを入れることができますか？また、何千ものファイルがあるフォルダの場合はどうなりますか？
バッチにはプランに応じて最大数百ファイルまで入れることができ、各ファイルは最大10 MBです。大きなフォルダは波のように処理されます：バッチをアップロードし、エクスポートし、次のバッチをアップロードし、各波が独自のスプレッドシートを生成します。監視フォルダの自動化はないため、5,000ファイルのアーカイブは、1回の無人ジョブではなく、意図的な実行の連続になります。つまり、9時間後に問題を発見するのではなく、波の合間に軌道修正ができるということでもあります。