複数の船会社の船荷証券を一括処理し
1つのスプレッドシートに集約

1件のBOL vs. 500件：単一書類のチュートリアルではカバーされない効率格差

AIによる抽出で、1件の船荷証券をExcelに変換するのに要する時間は5～10秒。手動入力の約18倍の速さです。これは書類レベルでの自動化の標準的なベンチマークであり、BOLをExcelに抽出する作業を1件ずつ行えば、確実にこの速度を達成できます。

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

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

マルチキャリアのBOLがテンプレートベース抽出を破綻させる理由

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

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

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

テンプレートベースの抽出ツールは、この多様性に対応するため、キャリアごとに個別のテンプレートを必要とします。15社のキャリアと取引がある場合、15個のテンプレートを作成することになります。キャリアがBOLのデザインを更新するたびに（リブランディング、規制順守、システム移行など、理由は様々です）、テンプレートは静かに機能しなくなります。手入力を排除するはずのツールが、新たなメンテナンス負荷、すなわち「テンプレート管理」を生み出してしまったのです。この問題はキャリア数に比例して拡大し、テンプレート更新のきっかけは、常に誰かが「データが流れなくなった」ことに気づいた時です。

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

全キャリア対応の単一列リスト：セマンティック抽出がBOLフォーマット間で機能する仕組み

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

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

以下は、一般的なフォワーダー向けBOL抽出ワークフローに必要なフィールド一覧で、どの運送会社でも修正不要で機能します：

これらの列名は一度定義するだけで完了します。ドキュメントごとに設定する必要はなく、一度設定すれば出力スプレッドシートのヘッダーとして機能します。すべての運送会社のすべてのBOLを処理すると、ソースドキュメントのレイアウト、ラベル、ページ数に関係なく、同じ列が同じ順序で並んだ行が生成されます。12社の運送会社から50件のBOLをバッチ処理すれば、手動で結合が必要な12個のテーブルではなく、1つのテーブルが生成されます。

このアプローチは、まったく異なる形式のBOLタイプにも対応します。運送会社がフォワーダーに発行する海上マスタービル・オブ・レーディング（MBL）、フォワーダーが荷主に発行する海上ハウスビル・オブ・レーディング（HBL）、そして航空貨物運送状（AWB）——これら3つのドキュメントは、視覚的なレイアウト、フィールド名、データモデルがすべて異なりますが、同一の列構造を持つ行を生成します。AIは位置情報ではなく意味情報を読み取るため、ドキュメントタイプに自動的に適応します。

バッチワークフロー：運送会社の受信箱から管理スプレッドシートへ

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

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

1枚のBOLページの処理時間は5〜10秒の範囲です。50枚の単一ページBOLのバッチは数分で完了します。制限要因はフォーマットの多様性ではなく、総ページ数です。キャリア#16をワークフローに追加しても、セットアップ時間はゼロです。なぜなら、セマンティック抽出は扱うキャリアの数に関係なく機能するからです。

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

問題発生時の対応：スケールでの例外処理

単一ドキュメント抽出では、例外は不便なものに過ぎません。修正して次に進みます。しかし、15のキャリアにわたるバッチ処理では、例外を効率的に解決することが、勤務日が午後3時に終わるか午後7時に終わるかを左右します。このスケールでの例外処理の実践は、正常系の処理よりも重要です。

マルチキャリアBOLバッチ処理における最も一般的な3つの障害モード：

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

スキャン品質のばらつき。マースクのシステムから届く鮮明なPDFのBOLと、倉庫の蛍光灯下で撮影され現地代理店が転送したBOLでは、入力品質が異なります。ぼやけたコンテナ番号、汚れた重量欄、傾いたページの向きは、抽出精度を低下させます。AIはこれらを確認対象としてフラグ付けします。オペレーターは、正しく抽出されたデータを一行ずつ確認する必要なく、どの項目に注意が必要かを把握できます。BOLへの重要な手書き修正（重量調整、シール番号の手書き追加）については、劣化したスキャンからの完全自動抽出を期待するのではなく、短時間の確認工程を計画してください。

欠落および曖昧な項目。すべてのキャリアがすべてのBOLに全項目を記載するわけではありません。地域のキャリアはHSコードを省略する場合があります。LCL混載BOLではシール番号が空白のままの場合があります。テンプレートベースのツールは、欠落項目を抽出失敗とみなすことがよくあります。セマンティック抽出は異なる方法で処理します。該当項目は単に空で返され、オペレーターは別の書類（パッキングリスト、商業送り状）から不足データを入手するか、そのまま進めるかを判断します。パッキングリストとBOLを同じバッチで処理し、書類間で重複する項目を扱うことは、このワークフローの自然な拡張です。

実際の成果：カラム名抽出で処理された50件のBOLバッチの場合、確認工程はフラグが付いた約2～5件の書類に集中し、50件すべてを一行ごとに検証する必要はありません。

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

フォワーダーの書類フローは、その性質上、地理的に分散しています。上海の積出港で原本BOLを扱う担当者と、ロッテルダムやシカゴの本社で管理用スプレッドシートを管理する担当者は異なります。データ入力担当者の元に届ける必要がある物理書類は、メール転送、ポータルダウンロード、WhatsApp写真など、一つひとつが追加の引き継ぎとなり、それぞれが遅延や誤送の原因となります。

コレクションリンクは、この分散問題を直接解決します。コレクションリンクとは、発行元で書類を扱う担当者（倉庫スタッフ、船会社代理店、パートナーフォワーダー、集荷ドライバーなど）に配布する、共有可能な専用アップロードページ（/c/xxxxのようなURL）です。受取人はリンクを開き、短い確認コードを入力して、BOLを直接アップロードします。アカウント作成、ログイン、トレーニングは一切不要です。書類は処理キューに届き、ダッシュボードから確認・エクスポートできます。

これにより、中間ステップが完全に削減されます。「発地代理店がBOLのPDFを業務デスクにメール → 業務担当が添付ファイルをダウンロード → フォルダに保存 → 抽出ツールにアップロード」という流れが、「発地代理店がコレクションリンクを開く → BOLをアップロード → 書類が確認・エクスポート用のキューに表示される」に変わります。3つの引き継ぎがなくなり、書類は発行から数分以内に処理可能になります。場合によっては、船舶が積出港を出港する前にも処理できます。

複数の貿易レーンとタイムゾーンにわたり、世界中から24時間体制で書類が届くBOLを管理するフォワーダーにとって、コレクションリンクは、メール依存の連鎖的な引き継ぎを、並行的な直接アップロードパイプラインに変えます。すべての港のすべての代理店が、同じ宛先にアップロードします。

よくある質問

物流ドキュメントのワークフローを広く扱うチーム向けに、梱包明細書と納品書の一括抽出やサプライヤー別の注文書一括処理のガイドもご覧ください。手動データ入力を続けるコストを検討中なら、手動データ入力の隠れたコストについてお読みください。

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