【活用事例 - TradeLens】なぜ貿易プラットフォームにブロックチェーンが必要か？

こんにちは！ハラヒデ(@harahidey)です。

パーミッション型のブロックチェーン（もしくはブロックチェーンライクな分散型台帳）で最もポピュラーな3つ「Corda, Hyperledger Fabric, Quorum」に焦点を当て、解説していくシリース、引き続きやっていきます。

以前実施したセミナーでは、事例の紹介をサクッとやったものの、もっと深く内容を知りたいという要望もチラホラ。

今回は、一つの事例を深く見ていくのもアリかと思い「TradeLens」のみを取り上げることにしました。

前提知識：Hyperledger Fabricとは

今回取り上げるTradeLendsはHyperledger Fabricを利用しています。前提知識として概要を記します。

「Hyperledger」はエンタープライズ向けのブロックチェーン基盤や関連ツールを開発する世界有数のコミュニティです。非営利団体「Linux Foundation」のもと、ブロックチェーン開発がオープンソース・ソフトウェア（OSS）で行われています。

Hyperledger Fabricはその中のプロジェクトで最も多く採択されているプロジェクトで、IBMなどが率先して普及を進めています。

Fabricでは、JavaやGo、Node.jsなどの汎用プログラミング言語でスマートコントラクトを記述できるため、イーサリアムのように独自言語を学ぶ必要はありません。一方で、決定性の無い記述も行えてしまうため、注意して開発する必要があります。

また、モジュール化されたアーキテクチャを備えており、ユーザーIDの発行や認証、スマートコントラクトの開発・実行などの機能が提供されています。

下記の記事でもう少し詳しく記述していますので、もしご興味あれば！

「Hyperledger Fabric」もっとも利用される企業向けブロックチェーンフレームワークの概要

Hyperledger Fabric 2.0　新機能まとめ

※1年ほど前の記事なので、現在はもっとアップデートされています。現在のバージョンはv2.3。詳細はドキュメント見るのが良いです。

A Blockchain Platform for the Enterprise — hyperledger-fabricdocs master documentation

TradeLens概要

TradeLensご存知の方も多いと思いますが、一言で言えば、国際貿易に関わる事務を楽にするためのプラットフォームです。
既に実稼働している企業向けブロックチェーンの事例として、TradeLendsが真っ先に事例としてあがるくらい有名です。※2018年12月から実稼働

このTradeLensはIBMと海運最大手のマースクが主導しており、それぞれ自社の営業チャネルでTradeLensの販売、契約を行っています。

マースクが主導しているからと言って、マースクの関連会社は他の参加者と同じ条件で参加しており、特別待遇は無く、競合他社のデータにもアクセス出来ないようになっています。

基盤としては、Hyperledger FabricベースのブロックチェーンをIBM Cloud上で稼働させる「IBM Blockchain Platform」というBaaS (Blockchain as a Service - PaaSのようなもの)で稼働しています。

2021年3月時点で、稼働開始から約1800万の書類と3800万のコンテナ、20億のイベントが処理され、現在も一日あたり200万以上のトランザクションがさばかれています。

消費者が毎日利用する物資の80%は船社に運ばれていますので、コンテナ数ベースでグローバル輸送市場の半分以上をTradelensが占めているので、もはや無くてはならないプロダクトと言っていいでしょう。

引用：https://www.tradelens.com/platform

国際貿易の課題

実際に国際貿易は情報のバケツリレーともいわれるくらいプレイヤーが多く、書類の数も膨大です。

これらは、紙ベースでやり取りされ、煩雑かつ面倒な１：１のやり取りの繰り返しで行われます。ITシステムを利用した場合でも、各プレイヤー内に情報がサイロ化され、分断が起きています。

国際貿易の主要な課題として４つ挙げられますが、これらに対するソリューションとして機能しています。

 - データのサイロ化
 - 紙ベースの処理
 - 通関手続きに時間がかかる
 - 高コストかつ低レベルな顧客サービス

ちなみに、アボカドをアフリカのケニアから、オランダのロッテルダムに海上輸送する場合、30組織にまたがる100人の関係者の中で、延べ200回もの紙ベースのやり取りが発生するらしいです。
また、多くの手続きが紙の書類に基づいていることから、IBMによれば事務処理コストの負担は輸送コストの20%にも及んでいるそうです。

これらが解決されるのであれば、相当インパクトは大きいですよね。

TradeLensの全体像　概要

引用：https://docs.tradelens.com/learn/solution_architecture/

TradeLensは全部で3つのレイヤーに分かれています。

【エコシステム】
船会社や荷主、港・ターミナルや税関当局、フォワーダーなどのTradeLensネットワークの会員で構成されており、TradeLensプラットフォームに直接接続し、貿易に関わるデータを提供しています。ネットワーク会員以外の企業もデータを提供することができ、日本国内にある複数の港・ターミナルが情報を提供しています。

【TradeLensプラットフォーム】
オープンAPI経由でアクセス可能です。サイロ化を課題としていた国際貿易において、オープンで標準化されたAPIを提供し、業界の情報共有とコラボレーションを促進しています。
また、TradeLensはHyperledger Fabricベースのプラットフォームであるため、将来的に他のHyperledgerプロジェクトと連携し、名前空間などを含む相互運用性が担保される予定です。

【マーケットプレイス】
TradeLensとサードパーティの両方が目的ごとに様々なサービスを公開できます。

プレイヤーについて

TradeLens上のプレイヤーについて見ていきます。
プレイヤーは下記のようにカテゴライズされます。

引用：TRADELENS 概要 - IBM

BCO(Beneficial Cargo Owner) - NVOを通さずに船会社と直接契約するメーカーや大手流通業者と言った荷主のこと。Genuine Shipperともいう。
NVO (Non-Vessel Operating Common Carrier) - 自らは本船を運航しないが、集荷して輸送責任を負う利用運送事業者のこと
FFW(Freight Forwarder) - 乙仲。海運貨物業者のこと
CHB(Customs House Broke) - 税関ブローカーのこと
3PL(3rd party logistics) - 第3者が荷主企業に代わって、最も効率的な物流戦略や物流システムの構築などを提案し、荷主企業のロジスティクス全体を包括的に請け負う業態
内陸輸送
税関/行政当局
港/ターミナル
船社

▼プレイヤー一覧

▼各プレイヤーのロール一覧

引用：TradeLens データ共有仕様書:データ共有モデル

主要プレイヤーのメリット

▼荷主 / 実荷主のメリット
・在庫予測の精度が上がる
・なにか問題が発生した場合は早い段階で通知される
・料金や課徴金の確認が完全に透明になり、安全在庫を減らせる
・手作業の処理に関する遅れをなくせる

▼行政当局のメリット
・リスク評価活動をサポートするための豊富な情報が得られる
・情報共有の改善
・手作業によるドキュメント処理の自動化
・国のシングルウィンドウ・プラットフォームへの接続
・税関が管理のために必要になったとき、貿易業者の負荷を増やさずに追加ドキュメントにアクセスできる
・上記によって貿易の円滑化を促進し、輸出入処理を合理化できる

【2019年初頭時点で参加している当局】
・オーストラリア内務（Australia Home Affairs）
・バーレーン税関（Bahrain Customs）
・カナダ税関（Canada Customs）
・オランダ税関（Dutch Customs）
・ガーナ（Ghana / GCNET）
・サウジアラビア税関（Saudi Arabia Customs）
・ペルー税関（Peru Customs）
・シンガポール税関（Singapore Customs）
・トルコ税関（Turkey Customs）

▼港とターミナル・オペレーターのメリット
・港資産の利用率を改善
・海路全体をEndToEndに可視化
・港湾でのコラボレーションを向上し、ターミナル計画を改善
・予約の合計量と次の輸送手段をあらかじめ伝えることで、トラックや船舶のサービス時間を改善

【2019年初頭時点で参加しているターミナル - オペレーター】
・アルヘシラス、スペイン - アルヘシラス港
・アルヘシラス、スペイン  - APM Terminals
・アパパ、ナイジェリア APM Terminals
・オークランド、ニュージーランド PortConnect
・エイヴォンマウス、イギリス MCP
・バーレーン APM Terminals
・バルセロナ、スペイン バルセロナ港
・ビルバオ、スペイン ビルバオ港 
・ブリスベーン、オーストラリア Patrick Terminals 
・ブエノスアイレス、アルゼンチン APM Terminals 
・釜山、韓国 釜山港 
・カヤオ、ペルー APM Terminals 
・コトヌー、ベニン APM Terminals 
・エリザベス、ニュージャージー州、アメリカ合衆国 APM Terminals 
・フィーリックストウ、イギリス MCP 
・フリマントル、オーストラリア Patrick Terminals 
・イェーテボリ、スウェーデン APM Terminals 
・ハリファックス、カナダ Halterm Canada 
・香港 Modern Terminals 
・ヒューストン、テキサス州、アメリカ合衆国 ヒューストン港 
・イタジャイ、ブラジル APM Terminals 
・イズミル、トルコ APM Terminals 
・ラサロ、メキシコ APM Terminals 
・リヴァプール、イギリス MCP ⦿
・ロサンジェルス、カリフォルニア州、アメリカ合衆国 APM Terminals 
・マースヴラクテII、オランダ APM Terminals 
・マニラ、フィリピン ICTSI 
・メルボルン、オーストラリア Patrick Terminals 
・モントリオール、カナダ MGTP 
・モビール、アリゾナ州、アメリカ合衆国 APM Terminals 
・ネイピア、ニュージーランド Napier Port Authority 
・ニューキャッスル、イギリス MCP 
・オンネ、ナイジェリア APM Terminals 
・フィラデルフィア、ペンシルヴェニア州、アメリカ合衆国 PackerTerminals
・ピパバブ、インド APM Terminals 
・ペセム、ブラジル APM Terminals 
・ポティ、ジョージア APM Terminals 
・ロッテルダム、オランダ APM Terminals
・シドニー、オーストラリア Patrick Terminals 
・シンガポール、シンガポール PSA 
・タンジール、モロッコ APM Terminals 
・タウランガ、ニュージーランド PortConnect 
・ティーズポート、イギリス MCP 
・バレンシア、スペイン Port of Valencia 
・ヴィシャカパトナム、インド JM Baxi 

参加している海運会社

TradeLensは、もともとIBMとマースクが主導で立ち上がったこともあり、海運大手の多くが参加しています。ついでにTradelensの対抗馬であるGSBNも一緒に見てみるとこんな感じです。

1. APM-Maersk → TradeLens
2. MSC → TradeLens
3. COSCO → GSBN
4. CMA-CGM → TradeLens, GSBN
5. Hapag-Lloyd → TradeLens, GSBN
6. ONE → TradeLens
7. Evergreen Line → なし（GSBNから離脱？）
8. Yang Ming → なし（GSBNから離脱？）
9. Hyundai → なし
10. PIL → TradeLens
11. ZIM → TradeLens

日本からだと、海運大手3社（日本郵船・商船三井・川崎汽船）のコンテナ船事業部を統合した「ONE」（Ocean Network Express、世界シェア第6位）、井本商運もTradeLensに参加しています。

また、上記の「Evergreen Line」と「Yang Ming」は、2018年11月の覚書締結時には名を連ねていたものの、2019年7月のServices Agreements締結時にはメンバーから外れています。

正確さは微妙ですが、下記のようなデータもありました。
あくまで参考程度に見るのが良さそうです。

▼TradeLens参加者の業種別割合

7割が輸送会社で、2割がディストリビューター。

▼TradeLens参加者の国別の割合

シンガポール、アメリカ、オランダの順に参加組織が多い。

引用：List of IBM TradeLens Customers

出荷の流れ

大まかな流れは下記の図のようになります。

引用：TRADELENS 概要 - IBM

プラットフォームアーキテクチャ

引用：TRADELENS 概要 - IBM

情報の共有について

TradeLensは、UN-CEFACT(貿易簡易化と電子ビジネスのための国連センター)が定めた、「サプライチェーン参照データモデル基準」により定義された、相互に関係する 3 つの取引オブジェクト、出荷、送り荷、輸送設備に関連するデータの共有を管理します。

また、プラットフォーム上でやり取りされるデータは下記のようなカテゴリーに分類されます。

管理イベント ：例）送り荷追跡の開始、参照番号の追加
計画イベント：例）計画ゲートイン、船舶の到着予定、鉄道の出発予定
予想イベント：例）予想ゲートイン、船舶の到着予想、列車の出発予想
実際のイベント：例）実際のゲートイン、実際の船舶到着、実際の列車出発
その他のイベント：例）通関許可、VGM（総重量確定情報）受領
取引ドキュメント：例）船荷証券、危険物申告、輸入申告

国際貿易に必要な書類は例えば下記です。

仮送り状
商品送り状
パッキング・リスト
予約確認
シッピング・インストラクション
輸出申告書
船荷証券
海上運送状
到着通知
輸入申告書
衛生証明書
植物検疫証明書
検査証明書
燻蒸消毒証明書
検査証明書
分析証明書
原産地証明書
危険物申告書
etc...

TradeLens上でサポートされる取引ドキュメントの詳細は下記にあります。

Document Sharing - TradeLens Documentation

情報の共有範囲について

多くのプレイヤーがドキュメントを共有し、なおかつ一部を秘匿するにはどうしたら良いでしょうか。
基本的にはHyperledger Fabricのチャネルという機能を利用して、関わりのある組織同士のみで情報共有をする形になります。

上記の例だと、海運チャネル１に所属する団体は、TradeLensノード・海運1ノード、その他参加者のノードのみシェアされ、海運2,海運3のチャネルでやり取りされている情報にはアクセスできません。

ブロックチェーンでどのように改竄を防ぐか

<ドキュメント登録>
1.1 - 未承認ドキュメントが、TradeLensプラットフォームにアップロード
1.2 - セキュアなドキュメントストアに保存
1.3 - ハッシュ(トークン「A」)がブロックチェーン台帳に保存

＜ドキュメント検索＞
2.1 - ハッシュ「A」を取得
2.2 - ドキュメントストアのドキュメントから生成された新しいハッシュ(ト
ークン「B」)を取得
2.3 - AとBを突合し、ハッシュが一致したときのみ、ドキュメントが正しいと認められる

こうすることで、TradeLensはブロックチェーンを利用して、ドキュメ
ントの不変性とトレーサビリティを保証しています。

ドキュメントが編集/アップロードされるたびに、新バージョンのドキ
ュメントが作成されて、ソリューションに追加される仕組みになっています。

UIについて

具体的なUIはどのようになっているのか、いくつか見ていきます。

▼ダッシュボード
コンテナの最新の場所、ETA、積み替え場所での乗り継ぎ日、ネットワークメンバー全体の概要などが参照できるようです。

▼ETA(到着予定時刻)

▼予約の詳細

▼滞留時間

出発する港と荷積みをする港での、稼働日ごとの滞留時間とコンテナごとの請求可能日数が表示されている

料金体系

TradeLens Platform – Coreを利用するのに、従量課金orサブスクリプションでの料金がかかるようです。
このCoreには、国際コンテナー貨物の出荷状況の可視化、サプライ・チェーンを通じた積荷の物理的な移動、規制への対応、各種APIなどが含まれており、利用する上で必須のようです。

具体的な料金はIBMかマースクに問い合わせが必要ですが、サービス記述書を見る限りは、下記のような形になっていると予想します。

・クラウドサービスを利用するためのアクセス権（おそらくサブスクリプション）
・輸送のコンテナーの処理をクラウド上で処理する、管理するなどのアクションごとの課金（おそらく従量課金）

こちらはあくまで推察しただけですので、具体的な料金については問い合わせをしてください。

WHY BLOCKCHAIN??

ここまで見て、この貿易プラットフォームに「なぜブロックチェーンが必要とされているのか」考えていきます。

こちらのプラットフォームは、海運最大手のマースクとIBMによってスタートしています。もしこの２社のみが管理するプラットフォームを提供した場合、プラットフォーム利用では下記の懸念点が生まれます。

①競合であるマースクに対して、自社の情報が吸い上げられる可能性
②IBM・マースク側の事情によって、プラットフォームの稼働が停止する可能性
③導入後、IBM・マースク側に都合の良いようにアップデートされる可能性

上記の３点は、どれも中央管理されているが故に起こりうる弊害です。これらの条件をクリアせずに、果たして他の海運大手や国を巻き込むことができたのでしょうか。

ブロックチェーンの利用することによって、上記３つをこのように解決しています。

①競合であるマースクでも、実際に関係の無い他社情報にアクセス出来ない
②IBM・マースクが管理しているノードが落ちても、システムはダウンせずに稼働し続ける
③ノードを管理している参加者同士によってガバナンスを行う

最後の③に関しては詳細はわかりませんでしたが、一般的なブロックチェーンコンソーシアムの場合、機能の作り込みやアップデートに関してはノードを支えている組織にも発言権があるのが一般的です。

よくブロックチェーンの特性で言われている「耐かいざん性」に関しては、ブロックチェーン以外でも実現は可能ですので、それだけではブロックチェーンを採択する理由になりません。

ですが、競合同士を含む多くのプレイヤーが相互に参加するプラットフォームを作ろうとした場合、一社が集中的に権限を持たないからこそ、競合が参加しやすくなるというメリットが生まれます。

実際にTradeLensは多くのプレイヤーを巻き込んでいるので、コンソーシアムブロックチェーンとして成功している事例になります。

さいごに

もし、参考になった！という方がいれば「スキ」ボタンをポチってもらえると嬉しいです。

最近はあまりツイートできてないのですが、Twitterもやっております。https://twitter.com/harahidey

もしよければフォローお願いします！

それではまた！

参照

Tradelens
TradeLens Documentation
TradeLens データ共有仕様書:データ共有モデル
Top 10 International Container Shipping Companies
List of IBM TradeLens Customers
TRADELENS 概要 - IBM
サービス記述書
Service Description