バッチ抽出でファイルの半分が
欠落する原因と対策

ステージ1：ファイルがアップロードを通過しなかった

これはファイル欠落の最も一般的な原因であり、アップロードの進行状況バーがスムーズに動くため見落とされがちです。問題のあるファイルがキューに入る前にカウントが止まります。ツールはこれらのファイルを「アップロード済み」ではなく「試行済み」として記録し、ファイルごとのエラーログがないため、ギャップは静かに見過ごされます。

サポートされていないファイル形式

すべての画像や文書形式が同じように扱われるわけではありません。ほとんどのAI抽出ツール（ImageToTable.aiを含む）は、PDF、JPG、PNG、WebP、AVIFをサポートしています。しかし、バッチにTIFFファイル、iPhoneのHEIC写真、古いシステムのBMPスクリーンショットが含まれている場合、アップロードハンドラーが単にスキップすることがあります。特にTIFFはよくある原因です。多くのスキャナーはデフォルトでマルチページTIFFを出力しますが、TIFFは有効な画像コンテナであるものの、ほとんどの抽出ツールの入力リストには含まれていません。ファイルはアップロードされているように見えます（ブラウザが送信します）が、処理パイプラインがそれを拾うことはありません。

確認方法： アップロード前にソースフォルダをファイル拡張子で並べ替えてください。.tiff、.heic、.bmp、.svgがある場合は、事前にJPGまたはPNGに変換してください。ほとんどのOSはエクスプローラーやFinderで一括変換できます。30秒の変換作業で、後で何時間も頭を悩ませる手間を省けます。

破損または不完全なファイル

あなたのマシンでは問題なく開けるファイルでも、アップロードの整合性チェックに失敗することがあります。クラウドダウンロードが中断されたPDFは最終ページが切り詰められている可能性があります。カメラの書き込みに失敗した画像はEXIFヘッダーが破損している可能性があります。OSがキャッシュされたサムネイルを表示するためプレビューでは「正常に見える」ファイルでも、抽出ツールがバイトを読み取ろうとすると失敗することがあります。

これは特にメールの添付ファイルやクラウドストレージのリンクからダウンロードしたファイルでよく発生します。ファイルは開き、内容は正しく見えますが、バイナリは完全ではありません。プレビューを読む人間とは異なり、抽出ツールはバイトを読み取ります。壊れたバイトは空の結果を生み出します。

確認方法： 疑わしい各ファイルを開いて保存し直してみてください。Adobe Acrobatでは、「ファイル → 別名で保存 → 最適化されたPDF」を使用して潜在的な破損を取り除きます。画像の場合は、任意のフォトエディターで簡単に保存し直すと、通常はヘッダーの問題が解決します。

ファイルサイズ制限

ほとんどの抽出ツールには個別ファイルのサイズ上限があります。ImageToTable.aiでは、標準的なアップロード制限は一般的なオフィス文書に対応していますが、200ページのスキャンPDFや48メガピクセルで撮影した高解像度の請求書写真はこれを超える可能性があります。このツールは必ずしもアップロードを明示的に拒否するわけではなく、ファイルのメタデータを受け入れても、サイズしきい値を超えたと判断すると実際のコンテンツをスキップすることがあります。

確認方法: アップロード前にファイルを確認してください。1つのファイルが30～50MBを超える場合は、PDF分割ツールを使って複数ページのPDFを小さな文書に分割するか、アップロード前に画像解像度を下げることを検討してください。PDFsamやAdobe Acrobatの「文書を分割」機能を使えば、数秒で処理できます。

ファイル名の特殊文字

見落とされがちな障害モードです。INV-2026-03-15_återbetalning.pdfや收据-001.jpg、Invoice (final - DO NOT EDIT).pdfのように、非ASCII文字、特殊記号、または非常に長いパス名を含むファイルは、サーバー側の書き込み処理で失敗する可能性があります。アップロードリクエストは成功し、サーバーはファイルストリームを受け入れますが、元のファイル名で一時ストレージに書き込もうとすると、ファイルシステムが文字エンコーディングを拒否します。HTTPレイヤーではファイルは「受信済み」とカウントされますが、処理のためにディスクに保存されることはありません。

確認方法: ファイル名に標準的な英数字、ハイフン、アンダースコア以外の文字が含まれていないか確認してください。元の名前の代わりにINV-2026-03-15-refund.pdfのように一括で名前を変更すれば、この問題を完全に排除できます。

ステージ2: アップロードされたが処理中に暗黙的にドロップされる

このステージは、アップロードが成功したことが確認されているため、診断がより困難です。ツールには30ファイルがアップロードされ、30個の緑色のインジケーターが表示されます。しかし、AIが各文書を実際に読み取りデータを抽出する処理フェーズでは、エラー状態をトリガーせずにファイルがコンベアベルトから落ちることがあります。コアエンジンが処理を完了したため、処理UIは「完了」と表示しますが、アップロードされた文書よりも少ない数しか処理されていません。

同時実行制限とキュー制限

AI抽出は計算コストが高く、各ドキュメントにビジョンモデルの推論が必要で、GPUメモリとAPIスループットを消費します。安定性を維持するため、抽出ツールは同時実行制限を設けています。通常、ユーザーあたり4～8の同時処理スロットです。50ファイルをアップロードするとキューに入り、ツールは4つずつ波のように処理します。

問題はキューに上限がある場合に発生します。一部のシステムは、キュー深度を超えたファイルを静かに破棄します。プランで1バッチあたり50ファイル、同時スロット4つが許可され、最初の4ファイルの1つで永続的なエラー（例：破損したPDFがリーダーをハングさせる）が発生すると、その波全体が停止し、残りのファイルがタイムアウトで破棄される可能性があります。UIには「50アップロード済み、46処理済み」と表示されますが、欠落した4つは実際には試行されていません。

確認方法: アップロードを10～15ファイルの小バッチに分割し、順次処理します。特定のバッチで一貫してファイルが失われ、小バッチでは失われない場合、同時実行制限が原因です。この動作は、Google Document AIからセルフホスト型OCRパイプラインまで、多くのバッチ処理システムで文書化されており、「アップロード済み」と「処理済み」のカウント差はほぼ常にキューイングのアーティファクトです。

大規模・複雑PDFのサイレントタイムアウト

100ページ以上または複雑な埋め込みグラフィックを含むPDFは、抽出エンジンのドキュメントあたりの処理タイムアウトを超える可能性があります。明示的なタイムアウトエラー（ファイル失敗を通知）とは異なり、一部のシステムはファイルを静かにスキップして次に進みます。タイムアウトハンドラがスレッドを正常に閉じたため、処理ジョブはファイルを「完了」として記録しますが、抽出結果は生成されません。

これは、実質的に100個の個別JPEG画像を1ファイルにまとめたスキャンPDFで特に一般的です。各ページに完全なOCRパスが必要で、累積時間が70ページ目でタイムアウトしきい値を超え、プロセッサは蓄積された作業を破棄して次に進みます。

確認方法: 問題のファイルを個別にアップロードします。単独では成功するがバッチモードでスキップされる場合、バッチキュー中のタイムアウトが原因です。30ページを超えるマルチページPDFは、バッチアップロード前に小ドキュメントに分割することを検討してください。

混在ファイルタイプによる動作の違い

すべてのファイルタイプが同じ速度で処理されるわけではありません。1ページのJPGスクリーンショットと50ページのスキャンPDFが混在するバッチでは、処理のリズムにばらつきが生じます。軽量なJPGはすぐに完了しますが、重量級のPDFは不釣り合いな処理時間を消費します。全ファイルの合計処理時間に基づいてバッチタイムアウトが計算されている場合、低速なPDFが原因で、後からキューに到着したJPGが破棄される可能性があります。JPG単体では問題なく処理できるにもかかわらずです。

これは特定の製品の癖ではなく、あらゆるバッチ抽出ツールに影響するシステムレベルの問題です。根本的な原因は、処理パイプラインが通常ファイルを不均一にバッチ処理する一方で、タイムアウトを均一に測定していることにあります。

確認方法: アップロード前にファイルをタイプとサイズでグループ化します。すべての小さなJPGファイルを1つのバッチで処理し、その後で大きなPDFを個別に処理します。これにより、低速ファイルと高速ファイルが分離され、タイムアウトロジックにおける相互汚染が排除されます。

ステージ3: 処理されたがマージで消失

最も稀ですが、最も紛らわしい障害モードです。30ファイルすべてが正常にアップロードされ、30ファイルすべてがAIによって処理され、30ファイルすべてが抽出結果を返しました。しかし、最終的なマージ出力、つまりダウンロードした単一のスプレッドシートには、22行しか含まれていません。残りの8ファイルは個別のドキュメントとして処理されましたが、統合エクスポートには組み込まれませんでした。

異なるファイル構造による行のずれ

一連のドキュメントに対してバッチ抽出を実行すると、ツールのバッチ処理エンジンは、結果を一貫した列ヘッダーを持つ単一のテーブルにマージしようとします。これは、すべてのファイルが同じタイプ（例：30件の請求書）の場合、シームレスに機能します。しかし、バッチに25件の請求書と5件のクレジットノートが含まれている場合、クレジットノートには異なるフィールド（「請求書番号」ではなく「クレジットノート番号」など）が存在する可能性があり、マージアルゴリズムが重複した列を作成したり、実装によっては、構造が多数派のスキーマと一致しない行をスキップしたりする原因となります。

これは厳密な意味でのデータ損失ではありません。抽出自体は成功しています。しかし、エクスポートロジックは、これらの8ファイルを構造上の外れ値とみなし、列の一貫性を保つために統合テーブルから除外しました。ツールの視点からは、可能な限りクリーンなマージを提供したため、ユーザーにその旨が通知されることはありません。

確認方法: ソースファイル間の違いを探します。一部のファイルでページの向き、言語、またはドキュメントタイプが根本的に異なる場合は、それらのファイルを別のバッチとして処理します。「バッチ」の定義が重要です。ワークフローはフォルダの都合ではなく、構造的な類似性によってファイルをグループ化する必要があります。

この問題は、類似しているが同一ではないドキュメントをバッチ処理する場合に特に一般的です。例えば、結合セルやネスト構造を含むドキュメントからテーブルを抽出する場合など、ドキュメントごとの行数が予測不能に変動するケースが該当します。

アップロード前チェックリスト — 1バッチ30秒

上記の失敗モードのほとんどは、アップロード前にソースフォルダをざっと見れば発見できるという共通点があります。このチェックリストを「処理準備完了」と「バッチ開始」の間のゲートとして扱ってください。後で8つのファイルが見つからないトラブルシューティングをするより時間がかかりません。

1. ファイル形式の確認 — すべてのファイルがJPG、PNG、PDFであることを確認します。TIFF、HEIC、BMP、WebPファイルは変換してください。エクスプローラで拡張子で並べ替えると、異常なファイルがすぐにわかります。
2. ファイルサイズの確認 — 30MBを超えるファイルがないか確認します。あれば分割または圧縮してください。
3. ファイル名の無害化 — 特殊文字（&、%、#、括弧）や非ASCII文字（é、ü、å、中）を含むファイル名は変更します。使用できるのはA-Z、0-9、ハイフン、アンダースコアのみです。
4. 種類の均一性チェック — すべてのファイルが同じ文書タイプですか？請求書とクレジットノート、注文書と納品書が混在している場合は、専用のバッチに分けてください。
5. 大きなファイルのテスト — 最大のPDFを個別にアップロードし、正しく処理されるか確認します。単独でタイムアウトするなら、バッチでは確実に失敗します。
6. バッチサイズの調整 — 30ファイルを超える場合は、10～15ファイルの小さいバッチに分割します。小さいバッチは問題を特定しやすく、全体の処理も速く完了します。

エスカレーションのタイミング — このツールはあなたのファイルに適していますか？

ツールの限界を正直に認識することで、繰り返しのフラストレーションを防げます。複数のバッチで一貫してファイルが失われ、アップロード前チェックリストでも原因がわからない場合、あなたの文書セットが、ほとんどの抽出ツールの設計前提から外れた特性を持っている可能性を考慮してください。

バッチ抽出ツール — ImageToTable.aiを含む — は、標準的なオフィス文書、きれいなスキャン、読み取り可能なコンテンツを含む写真といった一般的なケース向けに作られています。以下の用途には設計されていません：

• 極めて大きな単一文書 — 500ページ以上のPDFは、バッチ抽出キューではなく、専用の文書管理パイプラインに属します。
• 非常に多様なコレクション — 1つのフォルダに15種類の異なる文書タイプがあると、どんなマージエンジンでも限界に達します。分離してください。
• 暗号化または権利管理されたPDF — パスワード保護されたファイルは、事実上すべての抽出ツールでスキップされます。アップロード前に保護を解除してください。
• ピクセル単位の正確な位置が必要な文書 — すべてのフィールドの正確なX,Y座標を知る必要がある場合、セマンティック抽出エンジンよりもテンプレートベースのゾーンOCRツールの方が適しているかもしれません。

あなたのファイルがこれらのカテゴリのいずれかに該当する場合、解決策はより良いトラブルシューティングではなく、ツールの設計に合わせてワークフローを調整することです。それはツールやプロセスの失敗ではありません。あなたの特定の文書特性が、抽出パイプラインに別のアプローチを必要としているというシグナルです。

よくある質問

ファイルが失敗しても抽出ツールがエラーを表示しないのはなぜですか？

ほとんどの抽出ツールは、ファイル単位ではなくバッチ単位（「30ファイルをアップロードしました」）で報告します。アップロード中にファイルが失敗し、処理キューに登録されなかった場合、ツールはそのファイルが処理対象だったことを記録できません。あなたの認識上のカウントとツールのカウントの差は、責任があなたからシステムに移る境界で発生します。ファイル単位でステータスを追跡できるツールは例外であり、標準ではありません。

バッチ処理中にスキップされたファイルからデータを復旧できますか？

はい、ほとんどの場合可能です。アップロードや処理中に失敗したファイルは、通常ローカルマシン上でそのまま残っています。アップロード前のチェックリストに従って確認し、特定された問題（形式変換、名前変更、分割など）を修正した上で、個別またはより小さいバッチで処理してください。

アップロードダイアログでのファイルの順序は、スキップされるファイルに影響しますか？

ほとんどのシステムでは影響しませんが、そう見えることがあります。30ファイルをアップロードし、処理キューが受信順に処理する場合、キュー内で後ろに位置するファイルほど累積タイムアウトの影響を受けやすくなります。解決策は、ファイルの順序を並べ替えるのではなく、バッチサイズを減らすことです。

アップロード前にファイルが破損しているかどうかを確認するにはどうすればよいですか？

元のアプリケーションで開いてみてください。PDFの場合はAdobe Acrobat、画像の場合はフォトビューアーなどです。警告なしで開けば、おそらく問題はありません。バッチ検証には、pdfinfo（Linux）やAdobe Acrobatの「プリフライト」ツールなどで複数のPDFの構造的整合性をスキャンできます。疑わしいファイルを簡単に保存し直すだけで、潜在的な破損が解決することがよくあります。

1回のバッチに含めるファイルの最大数はいくつですか？

ほとんどのツールは1バッチあたり30～50ファイルをサポートしていますが、信頼性は10～15ファイルで最も高くなることが多いです。バッチサイズが小さいほど処理が速く完了し、問題のあるファイルを特定しやすくなり、同時実行制限や累積タイムアウトの影響も軽減されます。バッチサイズは機能の制限ではなく、信頼性とのトレードオフです。

推測しないで診断する

バッチ抽出でファイルが欠落する原因は、調べる場所がわかればほとんど謎ではありません。アップロード失敗が約60%を占めます — 未対応フォーマット、破損、ファイル名の問題。処理失敗 — 同時実行数の低下、タイムアウト、型の混在による競合 — がさらに約30%を占めます。最も気づかれにくいマージ漏れが残りの10%です。それぞれに修正方法があり、そのほとんどは1分もかかりません。

前回のバッチで失った8ファイルは、ほぼ間違いなくまだマシン上にあり、通過できなかった特定のゲートを特定すれば、そのまま処理可能です。「バッチ抽出でファイルが欠落する」と「バッチ抽出が確実に動作する」の違いは、どのゲートがなぜ失敗したかを知っているかどうかです。

次のバッチでチェックリストを実行してください。投入するファイルは30個のままですが、出力される行も30行になります。