バッチデータ抽出: フォルダ1つで、確認用スプレッドシート1つ

文書レイアウトごとにテンプレートが必要なため、ベンダーごとにテンプレートが必要になります。 テンプレートベースのツールはレイアウトごとにパーサーが必要です。そのため、ベンダーごとに請求書のレイアウトが異なる場合、それぞれに個別の設定を構築・保守する必要があります。NanonetsやRossumのようなAI搭載ツールでも、バッチを処理する前に文書タイプごとのトレーニングやフィールドマッピングが必要です。Redditのユーザーは、この状況を率直に述べています：「毎週PDFからExcelに手動でデータをコピーしていて、時間がかかりすぎています。」テンプレートソリューションは作業をなくすのではなく、コピーから設定へと移すだけです。

実際のフォルダはフォーマットごとに整理されていません。 ネイティブPDF、スキャン画像、スマホの写真は、従来のOCRツールではそれぞれ異なる処理パイプラインが必要です。そのため、フォーマットごとにバッチを分けて実行し、出力を手動で結合することになります。Redditのある開発者はこう断言しています：「PDFは人間が読むための出力フォーマットです。コンピューターが読むための入力フォーマットではありません。」そのため、フォルダに複数のフォーマットが混在すると、フォーマット固有のパイプラインはすぐに機能しなくなります。

バッチサイズと進捗状況の可視性は後回しにされています。 多くのツールは、単一のプログレスバーの背後でファイルを1つずつ処理します。1つの文書が失敗しても、どれが失敗したのか、なぜ失敗したのかを把握する方法がないため、バッチ全体を手動で再確認する必要があります。実際のボトルネックはAIの速度ではなく、文書ごとのステータス表示がないことです。

定義するのは出力であって、入力ルールではありません。レイアウトごとにパーサーを構築する代わりに、必要なカラム名を入力するだけです（例：Document Date, Vendor, Total Amount, Tax, Due Date）。AIは意味を理解して、すべての文書からその値を探し出します。あるベンダーのPDFにある「Invoice Date」も、別のスキャン済み領収書にある「Transaction Date」も、すべて「Document Date」カラムに解決されます。カラム名自体が唯一の設定であり、ベンダー、形式、レイアウトに関係なく、バッチ内のすべての文書に適用されます。これがカスタム列抽出です。AIは位置的なルールではなく、意味を読み取ります。

すべての形式が1つのパイプラインを共有するため、事前の仕分けは不要です。PDFの請求書、スキャンしたJPGの領収書、モバイルで撮影したPNG写真、そして時折混ざるWordやテキストファイルを、同じアップロード先にドロップするだけです。視覚言語モデルはすべてのファイルを同じ方法で読み取ります。ピクセルを確認し、指定したカラムを抽出します。「PDF用パイプライン」と「画像用パイプライン」の区別はなく、1つのバッチ、1つのカラム定義、1つの出力スプレッドシートだけがあります。

文書ごとの進捗状況と独立した処理により、1つの不良ファイルがバッチ全体を台無しにすることはありません。各文書は独立して処理され、それぞれのステータスがリアルタイムで追跡されます。バッチビューには、完了した文書、処理中の文書、問題が発生した文書が正確に表示されるため、個々の失敗を隠すような単一の進捗バーはありません。処理は1ページあたり5〜10秒かかります（手動入力は1ページあたり約3分）。出力は、定義したカラムで構成された1つのXLSXまたはCSVファイルです。