船社別の船荷証券をバッチ処理して
1つのスプレッドシートにまとめる

B/L 1件と500件の差：単一書類のチュートリアルでは扱わない効率ギャップ

AI抽出による船荷証券1件のExcel変換は5〜10秒で完了し、手入力の約18倍の速さです。これは書類レベルの自動化の標準的なベンチマークであり、B/LのExcel変換を1件ずつ行う場合でも確実に達成できます。

しかし、運用規模で見た場合、単一書類の処理速度はボトルネックではありません。ボトルネックは書類と書類の間にあります。マースクのB/L、MSCのB/L、COSCOのテンプレート、ハパックロイドのフォーマット、ONEのレイアウト——それぞれフィールドの配置、命名規則、テーブル構造が異なり、それらを切り替えながら、B/L番号が全行で同じ意味を持つ統一されたスプレッドシートを作成するまでの累積的な摩擦が問題なのです。

フォワーダー業務に関するExpedockの分析によると、オペレーション担当者は輸送管理システムへのデータ入力と監査だけで1日2〜4時間を費やしています。月300件の貨物を処理するチームの場合、データ入力だけで150時間が消費され、運賃交渉、例外処理、カスタマーサービスに充てる時間がなくなります。コストは1件あたりの分数ではなく、船社ごとに月単位で積み重なる時間にあるのです。

複数船社のB/Lがテンプレートベースの抽出を破綻させる理由

海運業界はマースク、MSC、CMA CGM、COSCO、ハパックロイド、ONE、エバーグリーン、HMM、ヤンミン、ZIMといった少数の主要船社によって動いており、各社が独自のテンプレートで船荷証券を発行しています。その違いを見てみましょう：

• フィールド名。マースクが「Vessel / Voyage」と表記するものを、MSCはサイドバーパネルで「Vessel Name」と表記し、地域船社は本文中で「Carrier Vessel」と呼びます。3つの異なるラベル、同じ情報です。
• 配置。B/L番号はある船社のテンプレートでは右上隅、別の船社では左下に配置されることがあります。コンテナ番号はヘッダーテーブル、複数行のリスト、貨物説明とインラインのいずれかに表示される場合があります。
• データ形式。ある船社は日付をDD/MM/YYYY形式で、別の船社はMM-DD-YYYY形式で記載します。重量は貿易ルートと船社の慣習に応じて、キログラム、ポンド、メトリックトンのいずれかで表記されます。
• ページ構成。単一コンテナのB/Lは1ページです。同じ船社の複数コンテナのB/Lは5ページに及ぶことがあり、さらに別の船社は複数コンテナの貨物をまったく異なる形式で構成します。

全米通関ブローカー・フォワーダー協会（NCBFAA）は、国際貿易において1,500社以上の会員企業と110,000人の従業員を代表しており、その会員には、米国の輸入申告の97%以上を扱うフォワーダーが含まれています。これらのフォワーダーは、営業日の毎時間、船社ごとのフォーマットの多様性に対応しています。

テンプレートベースの抽出ツールは、船社ごとのレイアウトに個別のテンプレートを必要とすることで、この多様性に対応しています。15社の船社と取引する場合、15個のテンプレートを作成することになります。船社がBOLのデザインを更新すると（ブランド変更、規制順守、システム移行など、理由はさまざまですが、実際に更新は行われます）、テンプレートは静かに壊れます。手入力をなくすはずのツールが、新たなメンテナンス負担、つまりテンプレート管理を生み出してしまったのです。この問題は船社の数に比例して拡大し、テンプレートを更新するきっかけは、常に誰かがデータの流れが止まったことに気づいたときです。

国際フォワーダー連盟（FIATA）は、電子FBLデータ標準（UN/CEFACT複合一貫輸送参照データモデルにマッピングされた、交渉可能な複合一貫輸送船荷証券（FBL）のオープンソース版デジタル形式）により、フォーマット断片化の問題に標準レベルで取り組んでいます。しかし、eFBLの船社への普及は緩やかで、現在フォワーダーの受信箱に届く紙やPDFのBOLは、標準の収束を待ってはくれません。フォワーダーは、届いたものからデータを抽出する必要があるのです。

1つの列リストで全船社対応：セマンティック抽出がBOLフォーマットを横断して機能する仕組み

船社別テンプレートに代わる方法がカラム名抽出です。特定の船社のページ上のどこに値があるかを定義する代わりに、探している情報カテゴリを定義します。AIは文書をセマンティックに読み取り、各データの意味を理解し（座標ではなく）、値がどこに現れるかではなく、何であるかによって値を特定します。

具体的な例を示します。「B/L番号」という列を定義します。AIがヘッダーに「Bill of Lading No. MAEU123456789」とあるMaerskのBOLに遭遇すると、パターンを認識して「MAEU123456789」を抽出します。サイドバーのボックスに「MEDU987654321」とラベル付けされたB/L番号が異なるフォーマットで記載されたMSCのBOLに遭遇した場合も、「MEDU987654321」を抽出します。これは、AIが両方を船荷証券の識別子として理解するからであり、両方が同じピクセル座標にあるからではありません。定義した列名が対象となる概念です。AIは、どの船社のフォーマットでも対応する値を見つけ出します。

典型的なフォワーダーのBOL抽出ワークフローに必要なフィールドリストは以下のとおりで、修正なしで全船社に対応できます：

これらの列名は一度だけ定義すればよく、ドキュメントごとの作業は不要です。定義した列名は、出力されるスプレッドシートのヘッダーになります。処理するすべての船荷証券（BOL）は、送信元ドキュメントのレイアウト、ラベル、ページ数に関係なく、同じ列が同じ順序で並ぶ行として生成されます。12社の船社から届いた50件のBOLを一括処理すれば、手作業での結合が必要な12個のテーブルではなく、1つのテーブルが生成されます。

このアプローチは、外見がまったく異なるBOLタイプにも対応します。船社がフォワーダーに発行する海洋マスター船荷証券 (MBL)、フォワーダーが荷主に発行する海洋ハウス船荷証券 (HBL)、そして航空運送状 — 視覚的なレイアウト、フィールド名、データモデルが異なる3種類のドキュメントでも、同一の列構造を持つ行が生成されます。AIは位置情報ではなくセマンティックに読み取るため、ドキュメントタイプに自動的に適応します。

バッチワークフロー: 船社の受信トレイから管理スプレッドシートへ

フォワーダーの月曜日の朝は、通常、週末に出航した船社から届いたBOLのPDFから始まります。それらはメールの添付ファイル、船社のポータルからのダウンロード、または仕向地代理店からの転送ドキュメントとして届きます。優先事項は、1件のBOLを素早く抽出することではなく、顧客が配送状況の問い合わせを始める前に、すべてのBOLを追跡スプレッドシートに入力することです。そのような問い合わせは、通常、各BOLの追跡番号から船社の追跡スクリーンショットを取得することから始まります。

ここで、バッチ処理ワークフロー — 複数のファイルを一度にアップロードし、AIが同じ列定義を使用してすべてを処理し、1つの統合された出力を生成する方法 — が、その朝のルーティンをどのように変革するかを説明します:

B/L1ページあたりの処理時間は5〜10秒の範囲です。単一ページのB/L50件のバッチは数分で完了します。制限要因はフォーマットの多様性ではなく、総ページ数です。ワークフローに16社目の船社を追加しても追加のセットアップ時間はかかりません。セマンティック抽出は扱う船社の数に関係しないためです。

あらゆる船社フォーマットに対応した船荷証券データ抽出の詳細については、専用のコンバーターツールをご覧ください。

問題が発生した場合の対応：大規模な例外処理

単一ドキュメントの抽出では、例外は一時的な障害に過ぎません。修正して次に進むだけです。しかし、15社の船社を対象にしたバッチ処理では、例外を効率的に解決できるかどうかで、勤務時間が15:00に終わるか19:00までかかるかが決まります。この規模での例外処理の実践は、正常な処理経路よりも重要です。

複数船社のB/Lバッチ処理で最も一般的な3つの障害モード：

船社のテンプレート更新。MaerskがB/Lのレイアウトを再設計した際（特定のフィールドの移動、表の再構成、ページ構造の調整）、テンプレートベースの抽出ツールは、誰かがテンプレートを再構築するまで、これらのフィールドを追跡できなくなりました。カラム名抽出はこれとは異なる方法で対応します。AIがピクセル位置に依存していないため、情報の内容が同じであれば、レイアウトが変更されても抽出が中断されることはありません。B/L番号は、再設計されたページのどこに表示されても、B/L番号のままです。

スキャン品質のばらつき。Maerskのシステムから届いた鮮明なPDFのB/Lと、倉庫の蛍光灯の下で撮影され、元代理店から転送されたB/Lは、同等の入力ではありません。ぼやけたコンテナ番号、汚れた重量フィールド、傾いたページの向きは、抽出の信頼性を低下させます。AIはこれらを確認用にフラグ付けします。オペレーターは、正しく抽出されたデータの行を探し回ることなく、どのフィールドに注意が必要かを確認できます。B/Lの重要な手書き修正（重量の調整、ハンドによるシール番号の変更）については、完全自動抽出を期待するのではなく、迅速な確認パスを計画してください。

欠落および曖昧なフィールド。すべての船社がすべてのB/Lにすべてのフィールドを含めるわけではありません。地域の船社がHSコードを省略する場合があります。LCL混載B/Lでは、シール番号が空白のままの場合があります。テンプレートベースのツールは、欠落したフィールドを抽出失敗として扱うことがよくあります。セマンティック抽出はこれとは異なる方法で対応します。フィールドは単に空で返され、オペレーターは別のドキュメント（梱包明細書、商業送り状）から欠落データを調達するか、なしで進めるかを決定します。梱包明細書とB/Lを同じバッチで処理し、ドキュメントタイプ間で重複するフィールドを扱うことは、このワークフローの自然な拡張です。

実際の結果：カラム名抽出で処理された50件のB/Lのバッチでは、確認ステップは、フラグが付けられたフィールドを持つ約2〜5件のドキュメントに焦点を当てることになり、50件すべてのドキュメントを1行ずつ検証する必要はありません。抽出ツールを比較検討している場合、9つの物流ドキュメント抽出ツールの直接比較テストで、この種の複数船社のフォーマット差異を正確に取り上げています。

あらゆる港からB/Lが届く場合：コレクションリンク

フォワーダーの書類フローは、その定義上、地理的に分散しています。上海の積出港で物理的なB/Lを担当する人と、ロッテルダムやシカゴの本社で管理用スプレッドシートを管理する人は異なります。データ入力デスクに届ける必要がある物理書類はすべて、メール転送、ポータルダウンロード、WhatsApp写真といった受け渡しの回数が増えることを意味し、その受け渡しのたびに遅延や誤送のリスクが生じます。

Collection Linkは、この配布の問題を直接解決します。Collection Linkは、発行元で書類を扱う担当者（倉庫スタッフ、船会社代理店、提携フォワーダー、集荷ドライバー）に配布して共有できる、固有のアップロードページ（/c/xxxxのようなURL）です。受け取った担当者はリンクを開き、短い確認コードを入力して、B/Lを直接アップロードします。アカウント作成もログインもトレーニングも不要です。書類は処理キューに登録され、ダッシュボードから確認・エクスポートできます。

これにより、中間の手順が完全に省かれます。「発送元エージェントがB/LのPDFを業務デスクにメール送信 → 業務担当が添付ファイルをダウンロード → フォルダに保存 → 抽出ツールにアップロード」という流れではなく、「発送元エージェントがCollection Linkを開く → B/Lをアップロード → 書類が確認・エクスポート用のキューに表示される」という流れになります。3つの受け渡しがなくなり、書類は発行から数分以内に処理可能になります。船が積出港を出発する前の場合もあります。

複数の貿易ルートとタイムゾーンにまたがってB/Lを管理し、世界中から24時間体制で書類が届くフォワーダーにとって、Collection Linkは、順次的なメール依存の受け渡しチェーンを、並行的な直接アップロードのパイプラインに変えます。すべての港のすべてのエージェントが、同じ宛先にアップロードします。

よくある質問

より広範な物流ドキュメント処理ワークフローを扱うチーム向けに、パッキングリストと納品書のバッチ抽出およびサプライヤー間での発注書のバッチ処理に関するガイドをご覧ください。手動データ入力の継続コストを評価している場合は、手動データ入力の隠れたコストについてお読みください。

このワークフローの単一ドキュメント版（フィールドごとの抽出、キャリアフォーマットの処理、ステップバイステップのセットアップ）については、APIやIT設定なしで船荷証券データをExcelに抽出する方法をご覧ください。