納品書から主要項目をExcelに抽出する方法
サプライヤーごとにフォーマットが異なっていても

なぜフォーマットの違いが従来の抽出を破綻させるのか — 代わりに機能する方法

サプライヤーごとに梱包明細書の印刷方法は異なります。Graingerは左側に品番、右側にカートン数を配置したマルチカラム表を使用します。Fastenalは項目を縦に並べ、出荷ドックで手書きの注釈を加えることがあります。Ulineのサーマル印刷には表構造がまったくなく、品目コードが段落内に埋め込まれたテキストが延々と続きます。MSC Industrialは、出荷フィールドと請求フィールドが同じページを共有する、結合された請求書兼梱包明細書ドキュメント内に梱包情報を入れ子にしています。ある物流コーディネーターは日常業務をこう表現しました。「どの注文でも、誰かが手作業で梱包明細書を読み、PO番号、重量、カートン数を抽出し、運送クラスを特定し、スプレッドシートに入力し、配送ラベルを適切なサイズにトリミングし、すべてを倉庫にメールで送信する必要がありました。それを1日に何度も。毎日です。」

従来のOCR抽出は位置に依存するため、ここで失敗します。テンプレートは「PO番号」が上端から2.3インチ、左端から1.1インチの位置にあることを記録しますが、それが移動すると抽出は破綻します。サプライヤーごとに1つのテンプレートが必要になります。さらに悪いことに、サプライヤーがレイアウトを変更した場合（通知なしに行われます）、テンプレートは静かに壊れ、数週間後に在庫差異が明らかになるまでエラーに気づきません。

代替となるのはセマンティック抽出です。これは人間が受信者として書類を読む方法です。ピクセル座標をスキャンするのではなく、「注文番号」を意味するテキストがどこにあっても探します。これがAIベースの抽出の仕組みです。位置を記憶するのではなく、フィールドの意味を理解します。ImageToTable.aiでは、抽出したい列名（「PO番号」、「SKU」、「受領数量」、「ロット番号」）を入力するだけで、AIがページ上のどこからでも各値を特定します。これは列名抽出と呼ばれます。入力したフィールド名が出力テーブルのヘッダーとなり、AIは各フィールドが何を表すかを理解することで、前回の位置を記憶するのではなく、値を列に一致させます。

受領に実際に重要なフィールド

梱包明細書には多くの情報が含まれていますが、そのほとんどはスプレッドシートに必要ありません。最善のアプローチは選択的であることです。受領ワークフローを推進するフィールドのみを抽出し、残りはPDFに残します。

すべての出荷にすべてのフィールドが必要なわけではありません。食品販売業者の場合、ロット番号は必須です — FDA 21 CFR Part 11では規制対象製品の電子記録のトレーサビリティが求められており、梱包明細書はその最初の書類となることが多いからです。一般商品倉庫であれば、PO番号、SKU、数量だけで十分かもしれません。重要なのは、ソフトウェアやサプライヤーのフォーマットではなく、あなた自身がカラムを定義できることです。

これは複数の梱包明細書を一括処理する際に使用するものと同じフィールドセットです — 違いは、大量処理に移行する前に、単一明細書の精度に焦点を当てている点です。

ステップバイステップ：梱包明細書のフィールドをExcelに抽出する

梱包明細書のPDFから構造化されたスプレッドシートに変換する最速の方法は、まずフィールドを定義し、AIにそれらを検出させることです — 位置のトレーニング、テンプレートの作成、サプライヤーごとの設定は一切不要です。このチュートリアルでは単一の梱包明細書を使用しますが、同じカラム定義は、あらゆるサプライヤーからのあらゆる数の書類に適用できます。

出力は、各行が梱包明細書（またはカラム構造に応じて明細項目）に対応し、各カラムがあなたが定義したフィールドとなるスプレッドシートです。データクリーニングは不要です — AIが自動的に日付形式を標準化し、品番から余分なスペースを除去し、数量値を数値形式に正規化します。

上記のフィールド（「PO番号」「SKU」「出荷数量」）を入力し、梱包明細書をアップロードしてみてください。AIが「位置」ではなく「意味」を読み取るため、同じ列でどのサプライヤーのフォーマットからもデータを抽出できます。

エッジケースへの対応：スキャン文書、手書き、感熱紙明細書

最新のERPで生成されたきれいなPDF梱包明細書は簡単なケースです。実際の入荷現場では、はるかに扱いにくい書類を処理する必要があります。抽出方法はそれらにも対応する必要があります。

スキャンされた納品書（特に150 DPIのデスクスキャナからメール添付で転送されるもの）は、小規模サプライヤーからよく送られてきます。文字がぼやけたり、傾いたり、一部が切れたりすることがあります。AIベースの抽出は、鮮明な文字の境界を必要とせず、人間が少し汚れた文書を読むのと同じように、視覚的な内容を全体的に解釈するため、こうした文書も処理できます。劣化の激しいスキャンについては、スキャンしたPDFをExcelに変換するガイドで説明されている方法と同じです。アップロード、列の定義、確認を行ってください。

手書きの注釈 — 倉庫作業員が印刷された数量50の横に「実際の数量：47」と走り書きするような情報は、受取人にとって必要な情報であり、無視すべきノイズではありません。ImageToTable.aiは手書き文字と印刷文字を一緒に読み取るため、現場での修正内容が、誰かのポケットの中のくしゃくしゃの紙ではなく、スプレッドシートに反映されます。

サーマル紙の納品書（Ulineなどのサプライヤーから）は、デジタル化以前に物理的な課題があります。それは、文字が薄れることです。解決策は、受け取ったらすぐに写真を撮るかスキャンすることです。スマートフォンの写真でも問題ありません。AIはサーマル印刷の写真もPDFと同じように処理します。Graingerの納品書用に定義したフィールド名は、設定を変更しなくてもUlineのサーマル印刷でも使用できます。

請求書兼納品書の統合ドキュメント — MSC IndustrialなどのB2Bサプライヤーは、請求書と納品書を兼ねた単一のドキュメントを発行することがよくあります。同じ列名抽出アプローチがここでも有効です。必要なフィールドだけを抽出すればよいからです。単価、税、合計などの財務フィールドは、数量、SKU、ロット番号などの物流フィールドと同じページにありますが、列は独立して定義します。後で同じドキュメントから請求書フィールドが必要になった場合は、請求書フィールドを抽出ワークフローが財務面を処理します。2つの抽出は重複なく相互補完します。

抽出から入庫ワークフローへ：スプレッドシートの次の行き先

抽出によりスプレッドシートが生成されます。そのスプレッドシートが入庫プロセスに供給されます。次に何をするかは、既存のシステムによって異なります。

WMS（倉庫管理システム）をお使いの場合 — Manhattan Active WMS、SAP EWM、Oracle WMS Cloud、Blue Yonder、またはLogiwaやFinale Inventoryなどの中堅市場向けシステム — 多くの場合、CSVアップロードまたはAPIを通じて入庫数量をインポートしています。抽出によるExcelファイルがインポート元になります。「PO番号」列をWMSの購買発注参照フィールドに、「出荷数量」を入庫数量に、「ロット番号」をロット追跡モジュールにマッピングしてインポートします。これにより、WMS端末への手動キー入力が不要になります。

ShipStationやFishbowlなど、より軽量な出荷プラットフォームをご利用の場合も、スプレッドシートは同じ目的を果たします。入庫数量をアップロードまたはコピー＆ペーストして、在庫を同期します。ShipStationの納品書テンプレートは出荷側をカバーしますが、入庫受入にはサプライヤードキュメントからのデータ入力が依然として必要です。抽出ステップがそのギャップを埋めます。

入荷処理をスプレッドシートで行っている場合 — 倉庫教育研究評議会（WERC）が依然として一般的な慣行として追跡しており、2023年時点で44%の倉庫が紙ベースのピッキングを使用している — 抽出されたExcelファイルがそのまま入荷記録となります。各行が出荷された荷物に対応します。「実数」「差異」「保管場所」の列を追加すれば、梱包明細書から手動でデータ入力することなく、完全な入荷記録が完成します。

単一明細書処理を超えて規模を拡大する準備ができたら、バッチ抽出アプローチを使用すると、1日分の梱包明細書を一度にアップロードし、統合された単一の入荷スプレッドシートを出力できます。同じ列定義が引き継がれるため、新しい設定を必要とせずにワークフローが拡張されます。比較として、同様のバッチロジックは異なる形式のベンダー見積もりにも適用され、同じサプライヤー多様性の問題が入荷ではなく購買で発生します。

よくある質問

手書きの納品書でも使えますか？

はい。AIは、数字、製品コード、荷受け場で書かれた注釈など、手書きの文字も認識します。手書きの精度は印字された文字より低くなります（読みやすさによりますが、約85～95%を想定）。受入記録を確定する前に、手書きで抽出した内容は必ず確認してください。

納品書の項目名が、自分が入力したものと異なる場合はどうなりますか？

これがセマンティック抽出の最大の利点です。列名として「PO番号」と入力し、納品書に「発注番号」や「注文参照」と記載されていても、AIはそれらが同じ意味だと理解し、正しい値を抽出します。仕入先ごとに用語を合わせて列名を変更する必要はありません。

納品書データをGoogleスプレッドシートに直接抽出できますか？

はい。Googleスプレッドシートアドオンを使用すると、スプレッドシートのサイドバーから納品書をアップロードして列名を指定できます。抽出されたデータはアクティブなシートに直接反映され、アプリケーションを切り替える必要はありません。

一度に何枚の納品書を処理できますか？

単票モードでは1枚ずつ処理します。これは、各出荷を即座に確認する必要があるリアルタイムの荷受けに最適です。営業終了時や一括処理には、バッチモードで複数の納品書を同時にアップロードでき（異なる仕入先の混在フォーマットも対応）、1つの統合Excelファイルを出力します。大量処理のワークフローについては、納品書一括処理ガイドをご覧ください。

AIは納品書の数量とPOが一致しないことを検出できますか？

ImageToTable.aiは納品書の内容を抽出しますが、発注書データにアクセスして自動照合することはできません。ただし、計算列を使用して抽出時にチェックを行うことが可能です。例えば、複数行の納品書の場合、計算列ですべての明細数量を合計し、印刷された合計と照合できます。発注書との差異チェックはエクスポート後のスプレッドシート作業となります。抽出した納品書データと発注書の明細をExcelに取り込み、VLOOKUPやINDEX/MATCHを使用して不一致を特定してください。

非英語の納品書はどうですか？

AIは50以上の言語の納品書を処理します。欧州サプライヤーからのドイツ語のLieferscheinも、Graingerからの英語の納品書と同じように抽出されます。列名を英語で入力すれば、ドキュメントの言語に関係なくAIが対応する値を特定します。