【T12】物と書類は同じ速さで動かない ― 国際コンテナ輸送の5つの流れを分解する

【スライド】Synchronizing_Global_Shipping_Flows

【ラジオ】物流を止める船より遅い書類

国際コンテナ輸送を「海運業界」ではなく「業務プロセスと情報システム」として分析しました。物・書類・データ・資金という4つの流れは、実は同じ経路・同じタイミングで動きません。B/Lの電子化率はわずか5.7%(2025年1月)。BAPLIE・COPRAR・COD ECOといったEDIFACTメッセージの体系、DCSA標準の実装状況まで整理しています。

※この文書は AI Claude、スライド資料、音声解説は Gemini により生成されており誤りを含む恐れがあります。

1 本レポートの目的と対象範囲
2 プレイヤー ― 関係主体と役割
3 コンテナ輸送全体の業務フロー ― 契約から返却まで
4 ドキュメントフロー ― 主要書類の整理
5 電子データ交換の標準 ― EDIとAPI
6 メッセージフロー ― イベントごとのデータ交換
7 情報システム ― 主要システムとデータ連携
8 コンテナライフサイクル
9 時間構造 ― イベントの時系列とカットオフ
10 コンテナ追跡 ― Container Tracking と Event Management
11 電子化 ― eBLとPaperless Trade
12 国際標準団体 ― 標準化の枠組み
13 情報ネットワーク ― 物・書類・データ・資金の重なり
14 最新動向
15 統計から読み取れる特徴
16 参考文献
17 年表
18 用語集
19 Claudeへのプロンプト

本レポートの目的と対象範囲

本レポートは、国際コンテナ輸送について、海運業界や港湾制度の紹介ではなく、契約から空コンテナ返却に至る一連の業務プロセス、書類の流れ、電子データ交換、情報システム間の連携を構造的に整理することを目的とします。特定の国・地域に依存しない、国際的に広く採用されている標準的な業務プロセスを対象とし、DCSA（Digital Container Shipping Association）・UN/CEFACT（国連貿易円滑化・電子ビジネスセンター）・IMO（国際海事機関）・WCO（世界税関機構）・BIMCO（バルチック国際海運協議会）・SMDG（Ship Planning Message Design Group）等の国際標準仕様書、および主要船社（Maersk、MSC、CMA CGM、Hapag-Lloyd、ONE、HMM等）が公開する技術文書を主たる根拠とします。統計値・普及率等の定量情報は公的資料・国際機関資料を優先し、業務手順そのものについては、複数の一次資料・国際標準・主要事業者資料の内容が一致する範囲で、一般的な標準プロセスとして記述します。

プレイヤー ― 関係主体と役割

国際コンテナ輸送には、物理的な輸送を担う主体と、書類・データ・資金を管理する主体が併存します。以下に主要なプレイヤーとその役割を整理します。

プレイヤー	役割	主なやり取りの相手
荷主（Shipper）	貨物の発送元。船腹予約・通関書類の起点となる	フォワーダー／NVOCC、船社、税関
荷受人（Consign ee）	貨物の受取人。到着後の引取・輸入通関の当事者	船社／代理店、税関、トラック・鉄道会社
フォワーダー（Freight Forwarder）	荷主に代わり輸送手配・書類作成を代行する利用運送事業者	荷主、船社、NVOCC、トラック・鉄道会社
NVOCC（Non-Vessel Operating Common Carrier）	自ら船舶を保有せず、自己の名義でB/Lを発行し運送責任を負う利用運送事業者	荷主、実運送人（船社）、荷受人
船社（Ocean Carrier）	船舶を運航し、実際の海上輸送を担う。B/L・Sea Waybillの発行主体	フォワーダー／NVOCC、船舶代理店、ターミナルオペレーター
船舶代理店（Shipping Agent）	船社に代わり寄港地での事務手続き（入出港手続き・書類授受等）を代行	船社、港湾管理者、税関
ターミナルオペレーター（Terminal Operator）	コンテナヤード・ガントリークレーン等を運営し、船積み・荷降ろしを実施	船社、トラック会社、鉄道会社、Port Community System
港湾管理者（Port Authority）	港湾施設全体を管理し、入出港・バース割当を統括	ターミナルオペレーター、船舶代理店、税関
税関（Customs）	輸出入貨物の申告審査・関税賦課・通関許可を行う	荷主／フォワーダー、Single Window、WCO標準
検疫機関（Quarantine Authority）	動植物検疫・食品衛生等の検査を実施	荷主／フォワーダー、税関
トラック会社・鉄道会社	内陸区間（発地〜CY、CY〜着地）の陸上輸送を担う	フォワーダー、ターミナルオペレーター、荷主／荷受人
デポ（Container Depot）	空コンテナの保管・整備・引き渡しを行う拠点	船社、トラック会社
倉庫（Warehouse）	バンニング・デバンニング、保管、流通加工を行う	荷主、フォワーダー、トラック会社
保険会社	貨物海上保険・船舶保険の引受を行う	荷主、船社
銀行	信用状（L/C）発行、荷為替手形決済、eBLの譲渡受託を担う	荷主、荷受人、eBLソリューションプロバイダー
認証機関（eBLソリューションプロバイダー等）	電子B/Lの発行・裏書・譲渡を管理するプラットフォームを提供	船社、銀行、荷主、荷受人

この構造の特徴は、貨物の物理的な流れ（荷主→トラック→CY→船舶→CY→トラック→荷受人）と、書類・資金の流れ（荷主→銀行→荷受人）が、必ずしも同じ経路・同じタイミングで動かない点にあります。例えば、B/Lが銀行を経由して荷受人に届く前に、貨物（コンテナ）自体が先に到着港に到着することは実務上頻繁に発生し、この「物と書類の時間差」が国際コンテナ輸送における業務プロセスの複雑性の一因となっています。

コンテナ輸送全体の業務フロー ― 契約から返却まで

国際コンテナ輸送の業務フローは、輸出側（発地）・海上輸送・輸入側（着地）の3段階に大別されます。以下、時系列で整理します。

輸出側プロセス：（1）荷主と船社（またはNVOCC）の間で運送契約が成立し、荷主またはフォワーダーが船社に船腹予約（Booking Request）を行う。（2）船社がBooking Confirmationを発行し、船腹・空コンテナの割当が確定する。（3）船社または船社が指定するデポから空コンテナが荷主の指定場所に搬送される（Container Pickup）。（4）荷主の倉庫等で貨物がコンテナに積み込まれる（バンニング、Stuffing）。（5）バンニング後、荷主はコンテナの総重量（VGM：Verified Gross Mass）を船社またはターミナルに提出する。VGM提出はSOLAS条約（1974年海上人命安全条約）の改正により2016年7月から義務化された手続きである。（6）コンテナがCY（コンテナヤード）に搬入される（Gate In、CY搬入）。（7）荷主またはフォワーダーが税関に輸出申告を行い、輸出許可を取得する（輸出通関）。（8）コンテナがターミナルオペレーターの管理下でCY内に蔵置され、船積み計画（Stowage Plan）に基づき本船に積み付けられる（Loading）。（9）本船が出港する（Departure）。

海上輸送プロセス：（10）本船が航海し、必要に応じて中継港でトランシップ（積み替え）が行われる。トランシップが発生する場合、積み替え港のターミナルでコンテナの荷降ろし・再積み込みが行われ、そのつど新たな船積み計画が必要となる。（11）本船が到着港に入港する（Arrival）。

輸入側プロセス：（12）到着港のターミナルオペレーターがコンテナを荷降ろしする（Discharge）。（13）船社または代理店が荷受人にArrival Noticeを送付し、貨物到着と引取手続きを通知する。（14）荷受人またはフォワーダーが輸入通関を行い、輸入許可を取得する。（15）荷受人がオリジナルB/Lを船社に呈示する（またはeBLの場合は電子的な裏書・移転手続きを行う）ことと引き換えに、船社がDelivery Order（荷渡指図書）を発行する。（16）荷受人はDelivery OrderとGate Passを用いてターミナルからコンテナを引き取る（Gate Out）。（17）荷受人の倉庫等でコンテナから貨物が取り出される（デバンニング、Destuffing）。（18）空になったコンテナが指定のデポまたはCYに返却される（Empty Return）。（19）返却されたコンテナはデポで検査（Insp ection）・必要に応じて修理（Repair）がなされ、保管（Storage）を経て次の輸送に再利用（Reuse）される。

この一連のプロセスにおいて、物（コンテナ）は前述の経路をほぼ一直線に流れる一方、書類・データは複数の主体間を並行して行き来する点が特徴です。次章以降、書類・データ・システムの流れをそれぞれ整理します。

ドキュメントフロー ― 主要書類の整理

国際コンテナ輸送で発生する主要書類を、作成者・受領者・作成タイミング・目的・電子化状況とともに整理します。

書類	作成者	受領者	作成タイミング	目的	電子化状況
Booking Request	荷主／フォワーダー	船社	船積み前	船腹・空コンテナの予約依頼	電子化が進展（DCSA Booking標準）
Booking Confirmation	船社	荷主／フォワーダー	Booking Request受領後	船腹確保の確認	電子化が進展
Shipping Instruction (S/I)	荷主／フォワーダー	船社	船積み前、B/L作成の指示として	B/L記載事項の指示	電子化が進展（DCSA標準）
Bill of Lading (B/L)	船社（実運送人）またはNVOCC	荷主、（裏書により）荷受人・銀行	船積み完了後	運送契約の証拠、貨物受取証、権利証券（Document of Title）	eBL採用率5.7％（2025年1月時点）
Sea Waybill (SWB)	船社	荷主、荷受人	船積み完了後	運送契約の証拠、貨物受取証（権利証券ではない）	船社が直接発行するため電子化が比較的容易
Commercial Invoice	荷主	荷受人、税関	船積み前後	売買契約に基づく請求書、通関申告の基礎資料	電子インボイスの普及が進行中
Packing List	荷主	荷受人、税関、ターミナル	船積み前	梱包明細（品目・数量・重量・容積）	電子化が進展
Cer tificate of Origin	商工会議所等発給機関	荷受人、輸入国税関	船積み前後	原産地証明、関税優遇適用の根拠	電子原産地証明（eCO）の導入国が拡大中
Manifest（積荷目録）	船社	到着港税関、港湾当局	出港後、到着前	船内貨物の総括的申告	電子マニフェスト（CUSCARメッセージ等）が主流
Dangerous Goods Declaration	荷主	船社、ターミナル	船積み前	危険物輸送の申告、IMDGコードに基づく取扱指示	電子化が進展
VGM (Verified Gross Mass)	荷主	船社／ターミナル	バンニング後、CY搬入前	コンテナ総重量の検証・申告（SOLAS条約に基づく義務）	電子提出が標準的
Arrival Notice	船社／代理店	荷受人	到着港入港前	貨物到着の通知、引取手続きの案内	電子化が進展（DCSA Arrival Notice標準）
Delivery Order (D/O)	船社／代理店	荷受人／フォワーダー	B/L呈示・運賃精算後	ターミナルからのコンテナ引取許可	eDOの導入が一部で開始
Gate Pass	ターミナルオペレーター	トラック会社	Delivery Order取得後	ターミナルへの搬出入許可証	Port Community System経由で電子化
Equipment Interchange Receipt (EIR)	ターミナル／デポ	トラック会社	コンテナ搬出入時	コンテナの損傷状況・授受記録	電子化が進展
Freight Invoice	船社／フォワーダー	荷主	運送完了前後	運賃・付帯費用の請求	電子インボイスが普及
Cre dit Note	船社／フォワーダー	荷主	請求訂正時	請求金額の修正・返金処理	電子化が進展

これらの書類のうち、法的性質として最も重要なのはB/Lです。B/Lは（1）運送契約の証拠、（2）船社による貨物受取の証拠、（3）権利証券（Document of Title、B/L所持人が貨物の引渡請求権を持つ）という3つの機能を併せ持ちます。この「権利証券」としての機能ゆえに、B/Lの電子化（eBL）には法的な議論（電子データが紙のB/Lと同等の権利移転効果を持つか）が伴い、これが業界全体でのeBL普及率が2025年1月時点で5.7％にとどまっている主因の一つです[1]。これに対しSea Waybillは権利証券ではなく単なる運送契約の証拠・受取証であるため、船社が直接電子的に発行することが法的な障壁なく可能です。

電子データ交換の標準 ― EDIとAPI

国際コンテナ輸送における電子データ交換は、歴史的にはUN/EDIFACT（国連の行政・商業・運輸のための電子データ交換標準）を中心に発展してきました。EDIFACTは、国連欧州経済委員会（UN ECE）傘下のUN/CEFACTが管理する国際標準であり、メッセージの種類ごとに定型フォーマットが定義されています。近年は、DCSAが策定するREST API仕様（JSON形式）への移行が進んでおり、両者が並存する過渡期にあります。米国では、ANSI X12（米国規格協会が策定するEDI標準）が国内輸送・通関で用いられることがありますが、国際コンテナ輸送の基幹はEDIFACT・DCSA APIです。

SMDG（Ship Planning Message Design Group）は、船舶の積み付け計画（BAPLIE：Bayplan/Stowage Plan Occupied and Empty Locations Message）に関するEDIFACTメッセージのガイドラインを策定する国際的な非営利団体です。GS1は商品識別コード（バーコード等）の国際標準団体であり、コンテナ輸送では主にサプライチェーン全体の商品トレーサビリティとの接続点として関わります。ebXML（Electronic Business using eXtensible Markup Language）は、UN/CEFACTとOASISが共同で策定したXMLベースの電子商取引標準であり、EDIFACTの後継として構想されましたが、実務上はDCSA APIへの移行がより主流となっています。

メッセージフロー ― イベントごとのデータ交換

国際コンテナ輸送では、業務イベントごとに標準化されたEDIFACTメッセージ（またはDCSA APIエンドポイント）を通じてデータが交換されます。以下に主要なメッセージと、その送受信主体・タイミングを整理します。

イベント	主要EDIFACTメッセージ	送信者	受信者	内容
船腹予約	IFTMBF（Booking）、IFTMBC（Booking Confirmation）	荷主／フォワーダー→船社、船社→荷主	船社／荷主	船腹予約依頼・確認
輸送指示	IFTMIN（Instruction）	荷主／フォワーダー	船社	船積指示（S/Iに相当）
コンテナ搬入予定	COPARN（Container Announcement）	船社／フォワーダー	ターミナルオペレーター	空コンテナ搬出・実入りコンテナ搬入の事前通知
コンテナ搬出入実績	COPRAR（Container Discharge/Loading Order）、COARRI（Container Discharge/Loading Report）	船社⇄ターミナルオペレーター	ターミナルオペレーター／船社	船積み・荷降ろしの指示と実績報告
積み付け計画	BAPLIE（Bayplan/Stowage Plan）	船社／ターミナル	ターミナル／船社	コンテナの船内配置図（ベイプラン）の共有
船内移動計画	MOVINS（Stowage Instruction）	ターミナル	船社	トランシップ時の船内でのコンテナ移動計画
輸送状況	IFTSTA（International Multimodal Status Report）	船社／ターミナル	フォワーダー／荷主	コンテナ・貨物の現在状況（ステータス）通知
ゲート通過	COD ECO（Container Gate-In/Gate-Out Report）	ターミナル／デポ	船社／トラック会社	コンテナのゲート通過記録
空コンテナ返却指示	COREOR（Container Release Order）	船社	デポ／ターミナル	空コンテナの引取・返却指示
積荷目録	CUSCAR（Customs Cargo Report）	船社	税関	積荷目録の税関への電子申告
通関申告	CUSDEC（Customs Declaration）	荷主／フォワーダー	税関	輸出入申告データ

これらのEDIFACTメッセージは、DCSAが策定するAPI標準（Booking、Track & Trace、Bill of Lading、Operational Vessel Schedules、Commercial Schedules、Just-in-Time Port Call等）への置き換えが進行中です。DCSAは2019年に主要船社によって設立された非営利団体で、船社間の技術標準を統一することを目的としています[2]。2025年時点で、Maersk・MSC・CMA CGM・Hapag-Lloyd・ONE・HMM・Evergreen・Yang Ming・ZIM等の主要船社が、Track & Trace（バージョン1.2〜2.2）、Bill of Lading（バージョン2.0〜3.0）、Operational Vessel Schedules（バージョン3.0）等のDCSA標準を段階的に実装しています[3]。

情報システム ― 主要システムとデータ連携

国際コンテナ輸送の業務プロセスは、複数の情報システムが連携することで成立しています。以下に主要システムの役割を整理します。

システム	役割	主な利用主体	主な連携先
Shipping Management System / Liner System	船社の予約・運賃・B/L発行等を統合管理する基幹システム	船社	Booking Platform、Terminal Operating System
Terminal Operating System (TOS)	コンテナヤードの荷役計画・ヤード配置・ゲート管理を行うシステム	ターミナルオペレーター	船社システム、Port Community System
Port Community System (PCS)	港湾に関わる全プレイヤー（船社・ターミナル・税関・トラック会社等）間でデータを一元的に共有するプラットフォーム	港湾関係者全般	TOS、税関システム、Cargo Commun ity System
Cargo Commun ity System (CCS)	空港・陸上輸送も含めた広義の物流コミュニティ内でのデータ共有基盤	フォワーダー、荷主、トラック会社等	PCS、TMS、WMS
Single Window	貿易関連の許認可・通関手続きを一つの窓口で処理する政府系システム（WCOが国際的に推奨する枠組み）	荷主／フォワーダー、税関、各種許認可機関	税関システム、PCS
Customs System	税関の申告審査・関税賦課システム	税関	Single Window、CUSCAR/CUSDECメッセージ
Forwarder System	フォワーダー・NVOCCの予約・書類作成・請求管理システム	フォワーダー、NVOCC	船社システム、荷主のERP
TMS (Transportation Management System)	陸上輸送（トラック・鉄道）の配車・運行管理システム	トラック会社、荷主	WMS、Visibil ity Platform
WMS (Warehouse Management System)	倉庫内の入出庫・保管・流通加工を管理するシステム	倉庫事業者、荷主	TMS、ERP
ERP (Enterp rise Resource Planning)	荷主企業の受発注・在庫・財務を統合管理する基幹システム	荷主	TMS、WMS、Forwarder System
Booking Platform	荷主・フォワーダーが船社の船腹予約を行うオンラインプラットフォーム	荷主、フォワーダー	船社のShipping Management System
Visibil ity / Track & Trace Platform	複数船社・複数輸送モードにまたがる貨物の位置・状況を統合的に可視化するプラットフォーム	荷主、フォワーダー	船社のTrack & Trace API、TMS
Container Management System	コンテナ機材（自社所有・リース）の配置・稼働・整備を管理するシステム	船社、リース会社	デポ管理システム、TOS

これらのシステム間のデータ連携は、従来は個別のEDIFACTメッセージのバイラテラル（1対1）な交換によって実現されてきましたが、DCSAのAPI標準化により、REST API・JSON形式を介した、より柔軟な多対多の連携へと移行しつつあります。ただし、DCSAのカンファレンス適合性フレームワーク（Conformance Framework）が示す通り、2025年時点でも船社ごとに実装しているAPIバージョンにはばらつきがあり（例：MaerskはBooking 2.0 Beta・Track and Trace 2.2、CMA CGMはTrack and Trace 2.1/2.2等）、完全な相互運用性の実現には至っていません[3]。

コンテナライフサイクル

コンテナ自体のライフサイクルは、空コンテナの状態から再利用に至る一連の段階として整理できます。（1）Empty：空コンテナがデポまたは前回の返却地に保管されている状態。（2）Pickup：荷主の指定に基づき空コンテナが搬出される。（3）Stuffing（バンニング）：荷主の倉庫等で貨物が積み込まれる。（4）Gate In：実入りコンテナがCYに搬入される。（5）Loading：本船に積み付けられる。（6）Voyage：海上輸送される。（7）Transshipment：中継港で積み替えが発生する場合がある。（8）Discharge：到着港で荷降ろしされる。（9）Gate Out：荷受人の手配によりターミナルから搬出される。（10）Destuffing（デバンニング）：荷受人の倉庫等で貨物が取り出される。（11）Return：空コンテナが指定デポに返却される。（12）Insp ection：コンテナの損傷有無が検査される。（13）Repair：必要に応じて修理される。（14）Storage：次回利用まで保管される。（15）Reuse：次の輸送に再利用される。

各段階で発生する主なデータ交換は、Gate In/Gate OutではCOD ECOメッセージ、船積み・荷降ろしではCOPRAR/COARRIメッセージ、コンテナ引取・返却指示ではCOREORメッセージ、コンテナ状態全般の追跡ではDCSA Track & Trace APIのイベントデータが該当します。空コンテナの返却地は、往路の到着地と同一とは限らず、船社・リース会社の需給状況に応じて再配置（repos itioning）先が指定されることがあり、この再配置業務はコンテナ機材の稼働率を左右する重要な管理領域です。

時間構造 ― イベントの時系列とカットオフ

国際コンテナ輸送のスケジュールは、船社が設定する複数の「カットオフ（締切）」を基準に進行します。以下、標準的なイベントの時系列を整理します。

イベント	タイミングの目安	交換される主な情報
Booking	船積み数週間〜数日前	Booking Request／Confirmation
Shipping Instruction Cutoff (SI Cutoff)	船積み数日前	B/L記載事項の最終確定情報
VGM Cutoff	船積み数日前（SI Cutoffと同時または近接）	コンテナ総重量データ
CY Closing（搬入締切）	船積み1〜3日前	コンテナのCY搬入完了
Loading	CY Closing後、本船入港中	積み付け実績（COARRI等）
Departure	積み付け完了後	出港通知
（航海中）	数日〜数週間（航路による）	Track & Traceイベントデータ（GPS位置等）
Arrival	到着港入港	入港通知
Discharge	入港後	荷降ろし実績（COARRI等）
Customs Clearance	荷降ろし前後	CUSCAR／CUSDECメッセージ
Delivery（引取）	通関完了・D/O取得後	Delivery Order、Gate Pass
Empty Return	引取後、荷主指定の期間内（Free Time内が一般的）	COD ECO、EIR

この時系列で特に業務上の緊張が生じやすいのが、SI CutoffとVGM Cutoffである。両者はいずれも船積みの数日前に設定され、この期限までに荷主・フォワーダーが正確なデータ（コンテナ内容・重量）を船社に提出できないと、当該コンテナが積み残し（Roll Over）となるリスクが生じる。また、Empty Returnについては、船社が荷主に対して無償で保管・使用できる期間（Free Time、Demurrage/Detention Free Time）を設定しており、これを超過すると追加費用（Demurrage：ターミナル内保管超過費用、Detention：コンテナ返却遅延費用）が発生する仕組みが一般的である。

コンテナ追跡 ― Container Tracking と Event Management

コンテナ追跡は、GPS・IoTセンサー・RFID・電子シール等のハードウェア技術と、DCSA Track & Trace APIのようなソフトウェア標準の組み合わせによって実現されています。DCSA Track & Trace標準は、Booking・Equipment・Shipment・Transport（輸送区間）という複数のレベルでイベント情報を定義し、各イベントにevent type（例：ARRIVAL、DEPARTURE、GATE-IN、GATE-OUT等）・event timestamp・location（UN/LOCODE等）を紐づけるデータモデルを提供します[3]。2025年第2四半期以降、DCSAは新標準（Arrival Notice、Track & Trace v3.0、Port Call 2.0等）についてConformance Framework（適合性審査の枠組み）による認証済み実装のみをダッシュボードに掲載する運用を開始しており、標準の乱立を防ぎ実装の質を担保する取り組みが進められています[4]。

AIS（Automatic Identification System、船舶自動識別装置）は、IMOが義務付ける船舶の位置情報を自動送信するシステムであり、船舶レベルでのマクロな追跡（本船が現在どの海域にいるか）に用いられます。これに対し、電子シール・RFID・IoTセンサーは、コンテナ単位でのマイクロな追跡（開閉検知、温度・衝撃等のコンディション監視）に用いられ、両者は補完的な関係にあります。ETA（Estimated Time of Arrival、到着予定時刻）の算出は、AISデータ・気象データ・港湾混雑状況等を組み合わせた予測モデルによって行われることが一般的ですが、予測精度・アルゴリズムの詳細は各データベンダー・船社の独自技術であり、標準化された公開仕様としては確認できません。

電子化 ― eBLとPaperless Trade

電子B/L（eBL）は、紙のB/Lが持つ「権利証券」としての機能を電子データ上で再現する仕組みです。eBLは船社が直接発行するのではなく、IGP&I（船主責任保険組合国際グループ）が承認したeBLソリューションプロバイダーを介して発行される点が、船社が直接発行するSea Waybillとは異なります[1]。2025年1月時点のeBL採用率は5.7％にとどまっていますが、これはeBLというコンセプト自体が約20年前から存在するにもかかわらず、（1）法的な認知の不確実性（eBLが権利証券として機能するかについて法域ごとに扱いが異なる）、（2）プラットフォームの断片化（異なるeBLソリューションプロバイダー間でのデータ互換性の欠如）という2つの障壁が主因とされています[5]。

DCSAは2024年に国際法律事務所Baker McKenzieと共同で、世界の主要経済国15カ国（中国・米国・ドイツ等を含む）の法域におけるeBLの利用可能性を調査し、いずれの法域でもeBLの利用（契約上の取り決めによるものを含む）が可能であることを確認しています[5]。2023年2月には、DCSA加盟船社のCEOらが2030年までのeBL100％採用を公約し、同年9月にはDCSA・BIMCO・FIATA・ICC・SWIFTが「FIT Alliance」を結成し、eBL普及に向けた業界横断的な取り組みを開始しました[5][6]。2025年5月には、複数のeBLソリューションプロバイダー間でのDCSA標準準拠・相互運用可能なeBL取引が初めて成立し、PINT（Platform Interoperability）API・法的枠組み・Control Tracking Registry（CTR、どのプラットフォームがeBLを管理しているかを追跡する記録）という3つの要素が相互運用性を支える基盤として確立されました[6]。McKinsey & Companyの試算によれば、eBLの完全普及は直接的なコスト削減効果として65億ドル、貿易拡大効果として400億ドルの経済効果を持つとされています[6]。

eBL以外の電子化領域としては、電子インボイス・電子マニフェスト（CUSCARメッセージによる税関への電子申告）・電子通関（Single Windowを通じた一括申告）・電子決済（銀行間の資金決済のデジタル化）が挙げられます。Paperless Trade（ペーパーレス貿易）は、これらの電子化を貿易プロセス全体で実現する概念であり、UN/CEFACTが提唱するSingle Window構想はその中核的な政策的枠組みです。Digital Corridor（デジタル回廊）は、特定の貿易ルート（例：特定の輸出国〜輸入国間）において、関係する複数国のSingle Window・PCS等を相互接続し、書類の重複提出を削減する取り組みを指しますが、その具体的な実装状況は国・回廊ごとに大きく異なり、本レポートで網羅的に整理できる標準的な普及率統計は「不明」です。

国際標準団体 ― 標準化の枠組み

国際コンテナ輸送に関わる主要な標準化団体とその役割を整理します。DCSA（Digital Container Shipping Association）は、2019年に主要船社によって設立された非営利団体で、船社間のBooking・B/L・Track & Trace等のAPI標準を策定します[2]。UN/CEFACT（国連貿易円滑化・電子ビジネスセンター）は、EDIFACTメッセージ標準やSingle Window構想を含む、貿易円滑化に関わる国連の公式標準化機関です。ISO（国際標準化機構）は、コンテナのサイズ規格（ISO 668等）やデータ交換に関わる基盤的な国際規格を策定します。IMO（国際海事機関）は、SOLAS条約（VGM義務化の根拠）やAIS等、船舶の安全・環境に関わる国際規則を所管する国連の専門機関です。WCO（世界税関機構）は、税関手続きの国際標準（HSコード、Single Window構想）を策定します。

FIATA（国際フレイトフォワーダーズ協会連合会）は、フォワーダー業界の国際団体で、標準運送書類（FIATA B/L等）を提供します。BIMCO（バルチック国際海運協議会）は、船社・用船者向けの標準契約書式（用船契約書、B/Lフォーム等）を策定する世界最大の海運業界団体です。SMDG（Ship Planning Message Design Group）は、BAPLIE等の船舶積み付け関連メッセージのガイドラインを策定する非営利団体です。GS1は、商品識別バーコード（GTIN等）の国際標準団体で、コンテナ輸送では主に貨物単位のトレーサビリティとの接続点として関与します。これらの団体は、それぞれ独立した標準を策定してきた歴史的経緯があるため、完全な相互運用性の実現に向けては、DCSA・UN/CEFACT・BIMCO等の相互参照・整合化の取り組み（DCSAのB/L標準がUN/CEFACTの複合輸送参照データモデルと整合するよう設計されている等）が進められています[7]。

情報ネットワーク ― 物・書類・データ・資金の重なり

国際コンテナ輸送を構成する5つの流れ（貨物・コンテナ・書類・電子データ・資金）は、それぞれ異なる経路・タイミングで動きます。以下にその対応関係を整理します。

貨物・コンテナの流れ：荷主の倉庫→（バンニング）→CY→（船積み）→本船→（航海・トランシップ）→到着港→（荷降ろし）→CY→（引取）→荷受人の倉庫→（デバンニング）→デポ（空コンテナ返却）。この物理的な流れは、前述の「コンテナ輸送全体の業務フロー」で整理した通り一直線に進行します。

書類の流れ：荷主→（S/I）→船社→（B/L発行）→荷主→（B/L裏書・銀行経由での送付）→荷受人。信用状（L/C）決済の場合、B/Lは荷主の取引銀行から荷受人の取引銀行を経由して荷受人に届くため、書類の流れは物の流れよりも複数の金融機関を経由する分、経路が長くなることがあります。この結果、特に近距離航路では、貨物（コンテナ）が先に到着港に到着し、船積書類（オリジナルB/L）の到着が貨物より遅れる「船荷証券の危機（B/L Crisis）」と呼ばれる実務上の問題が生じることがあり、これがeBL普及を求める実務的な動機の一つとなっています。

電子データ（EDI/API）の流れ：Booking（荷主⇄船社）→S/I（荷主→船社）→COPARN（船社→ターミナル）→BAPLIE／COPRAR／COARRI（船社⇄ターミナル）→CUSCAR（船社→税関）→IFTSTA（船社→フォワーダー・荷主）→COD ECO（ターミナル⇄トラック会社）という流れで、書類の流れと並行しつつも、より高頻度かつ細分化されたタイミングで交換されます。

資金の流れ：荷主→（信用状開設または前払い）→荷主の取引銀行→荷受人の取引銀行→荷受人という商流上の決済に加え、荷主→船社（海上運賃）、荷受人→船社（着地払い運賃・Demurrage/Detention費用）、船社→ターミナルオペレーター（荷役費用）という運送関連の決済が並行して発生します。資金の流れは、書類（特にB/L）の引渡しと連動する部分（信用状決済における荷為替手形の買取等）と、運送契約に基づき独立して発生する部分（運賃・付帯費用の請求）に分かれます。

この5つの流れを統合的に管理することが、国際コンテナ輸送における情報システム連携の本質的な目的です。DCSA・UN/CEFACT等が進める標準化は、主に「電子データの流れ」の標準化を通じて、「書類の流れ」を電子データに置き換え（eBL等）、結果として物の流れと書類の流れの時間差を縮小することを志向していると整理できます【推論：DCSA・UN/CEFACTの標準化活動の目的についての整理であり、各団体の公式文書から直接引用した表現ではありません】。

統計から読み取れる特徴

本レポートで整理した業務プロセス・書類・データ・システムの構造から、国際コンテナ輸送の特徴を以下のように整理します。第一に、物・コンテナ・書類・データ・資金という5つの流れは、それぞれ異なる経路・タイミングで動く並行プロセスであり、特に書類（B/L）の流れが物の流れより遅れることが、実務上の摩擦（B/L Crisis）の一因となっています。第二に、電子データ交換は、EDIFACT（IFTMIN、BAPLIE、COPRAR、COARRI等の定型メッセージ）からDCSA APIへの移行過程にあり、2025年時点でも船社ごとの実装バージョンにばらつきが残っています。第三に、書類の中でもB/Lは権利証券としての法的機能ゆえに電子化が遅れており、2025年1月時点のeBL採用率は5.7％にとどまる一方、2025年5月には相互運用可能なeBL取引の初成立という具体的な進展も見られました。第四に、情報システムは、船社のShipping Management System、ターミナルのTOS、港湾全体のPCS、税関のSingle Window等が階層的に連携する構造を持ち、この連携の標準化がDCSA・UN/CEFACT等の国際団体によって進められています。第五に、標準化団体は歴史的経緯からDCSA・UN/CEFACT・BIMCO・SMDG・GS1等が並存しており、完全な統合ではなく相互参照による整合化が図られている段階です。

参考文献

[1] DCSA「Booking and Bill of Lading Standards | Adoption Guide」（eBL採用率5.7%、権利証券としての機能に関する記載箇所）
[2] ALICE (Alliance for Logistics Innovation through Collaboration in Europe)「DCSA developments surrounding the electronic Bill of Lading and Track & Trace standards」（DCSA設立経緯に関する記載箇所）
[3] DCSA「DCSA Conformance」（主要船社のAPI標準実装状況に関する記載箇所）
[4] DCSA「DCSA Conformance」（Conformance Frameworkの運用開始に関する記載箇所）
[5] DCSA「Booking and Bill of Lading Standards | Adoption Guide」（eBLの法的障壁、Baker McKenzie共同調査、FIT Allianceに関する記載箇所）
[6] DCSA「DCSA completes standards-based interoperable eBL transaction, marking major industry milestone」2025年5月15日
[7] Digitalize Trade「Digital Container Shipping Association –standardised foundation for digitalisation」（DCSA B/L標準とUN/CEFACTの整合性に関する記載箇所）
[8] DCSA「DCSA Week 2025: Un iting the Digital Container Shipping Commun ity」

年表

1974年 — SOLAS条約（海上人命安全条約）採択、後のVGM義務化の法的基盤に
1990年代 — UN/EDIFACT標準の国際的な普及が進み、船社・港湾間の電子データ交換が本格化
2000年代初頭 — eBL（電子船荷証券）のコンセプトが登場、以降約20年にわたり普及の途上に
2016.7 — SOLAS条約改正に基づくVGM（コンテナ総重量）提出の義務化が発効
2018年 — CargoX、ブロックチェーンベースの電子船荷証券の初移転を実施
2019年 — DCSA（Digital Container Shipping Association）、主要船社により設立
2023.2 — DCSA加盟船社CEOら、2030年までのeBL100%採用を公約
2023.9 — DCSA・BIMCO・FIATA・ICC・SWIFTが「FIT Alliance」を結成
2024年 — DCSA、Baker McKenzieと共同で世界主要15カ国におけるeBLの法的利用可能性を調査・確認
2025.1 — eBL採用率、業界全体で5.7%にとどまることが判明
2025年前半 — DCSA Bill of Lading 3.0標準が発表、複数船社が実装を開始
2025.5.15 — DCSA標準準拠・相互運用可能なeBL取引が世界で初めて成立(PINT API・CTR等)
2025年第2四半期 — DCSA、新標準についてConformance Framework通過実装のみをダッシュボードに掲載する運用を開始
2025年（DCSA Week） — 「標準の合意」から「一貫した実装」へ業界の課題認識がシフトしたことが確認される
2026年 — 「国際コンテナ輸送の業務プロセス」レポート作成、統計分析とは異なる業務プロセス分析としてシリーズに追加

用語集

書類・法的概念

Document of Title, 権利証券：所持人が貨物の引渡請求権を持つことを示す証券。B/Lが持つがSea Waybillは持たない機能。
Bill of Lading Crisis, B/Lクライシス（船荷証券の危機）：近距離航路等で貨物が先に到着し、オリジナルB/Lの到着が遅れることで生じる実務上の問題。
VGM, （Verified Gross Mass）：SOLAS条約に基づき義務付けられた、コンテナの検証済み総重量。

電子データ交換

EDIFACT：国連が管理する行政・商業・運輸のための電子データ交換の国際標準。
BAPLIE：本船へのコンテナ積み付け計画（ベイプラン）を示すEDIFACTメッセージ。
COPRAR / COARRI：コンテナの船積み・荷降ろしの指示（COPRAR）と実績報告（COARRI）を示すEDIFACTメッセージ。
COD ECO：コンテナのゲート通過（搬出入）を記録するEDIFACTメッセージ。
PINT, （Platform Interoperability）：異なるeBLソリューションプロバイダー間でのeBL移転を可能にするDCSAのAPI標準。
Control Tracking Registry, CTR：どのプラットフォームがeBLを管理しているかを追跡するDCSAの記録機構。

国際標準団体

DCSA, （Digital Container Shipping Association）：2019年に主要船社が設立した、船社間API標準を策定する非営利団体。
FIT Alliance：DCSA・BIMCO・FIATA・ICC・SWIFTが2023年に結成した、eBL普及を推進する業界連合。
SMDG, （Ship Planning Message Design Group）：BAPLIE等の船舶積み付け関連メッセージのガイドラインを策定する団体。