1．はじめに

ブロックチェーン技術を用いた社会課題解決のための実証実験が，世界的に進められている．ブロックチェーン技術の用途について，さまざまな機関から提示されている[1],[2]．その1つに，貿易実務が挙げられる．

貿易実務は，書面管理にもとづく煩雑さ，一元的な情報トレースの難しさ，紙に依存した権限管理といった問題を抱えている．これらの問題を，ブロックチェーンが有するトレーサビリティや改ざん耐性といった特性を用いることで，解決できる可能性がある．世界貿易機構（WTO）は，ブロックチェーンによる障壁の撤廃により，2030年までに累計1兆ドル規模以上の貿易が新たに生まれる可能性があると指摘している[3],[4]．金融機関においても，貿易実務に関する実証実験が行われている．

筆者らは，ブロックチェーンを用いたシステムがこれらの課題をどの程度解決し得るかを検証するため，国内で貿易業務に携わる企業3社と共同で実証実験を行った[5]．具体的には，ブロックチェーンを用いた実験システムを構築し，実際の貿易業務にて試用した．

2．実験目的

2.1　実験目的

2.1.1　貿易取引における問題の所在

貿易取引では，輸出入業者，船会社，銀行，保険会社など，多数の企業の間で代金支払いを確約する信用状，船会社が貨物を引き受けたことを証明する船荷証券，貨物破損に備えた保険証券など，多くの書類をやりとりする必要がある．このうち，1）取引参加者が多く，2）正本性の高い書類を扱うといった2つの特徴には，それぞれ以下に挙げる課題がある．

第1に，取引参加者が多い点について．貿易取引には，輸出入業者のほかにも，フォワーダー^☆1，保険会社，船会社，銀行など，多数の関係者が参画する．このため，ひとたび書類の偽造や不着といった事故が発生すると，その回復には多大な時間や費用を要する．

第2に，正本性が高い書類を扱う点について．たとえば，船荷証券（B/L，Bill of Lending）^☆2は，その証書自体が貨物引渡請求権を示していて，貨物と1対1に対応する．すなわち，B/L自体が有価証券であり，正本性が求められる．B/Lが改ざんされた場合，正当でない関係者に貨物の所有権が渡るリスクがある．

さらに，取引が複数国にわたることから，国ごとに貿易ルールが異なる問題もある．電子文書が認められる国や，紙の原本が必要となる国がある．また，国によって，銀行が求める文書の種類や形式が異なる．このため，貿易手続において電子化されていない事務処理が残っている．

これらの問題を解決するため，これまでも，電子船荷証券（eB/L）[6]やTSU/BPO ^☆3といった，貿易業務の電子化の取り組みが行われてきた．しかし，現状，これらのソリューションも幅広く利用されているとはいえない．たとえば，eB/Lは，不正や遅延の防止などには効果があるが，導入費が高額である．また，TSU/BPOは，決済期間を短縮できるが，原本を授受するプロセスが残る．さらに，貨物の状態管理については，個社ごとにシステム化されているものの，業界標準のシステムはまだ存在していない．このように，貿易実務の課題を網羅的に解決できていない．

これらを踏まえ，貿易取引に携わるすべての関係者を包括的に巻き込み，かつ，安価で容易に導入可能なスキームが求められている．

2.1.2　貿易業務とブロックチェーンとの親和性

ブロックチェーンは，データを格納したブロックが，暗号技術を用いて前後のブロックとチェーンのように連結する構造を持つデータ構造である．ブロックチェーンは，その参加者全員が同一のデータを共有し，参加者によって合意された情報だけが有効と認識される，分散型台帳の構造をとる．このため，ブロックチェーンの改ざんは，実質的に困難である．また，データの連続性が保証されるため，トレーサビリティが確保できる．

以上のようなブロックチェーンが持つ特性を活かして，貿易業務にブロックチェーン技術を適用する試みは，2016年から複数の事例が見られる．公開されている最初期の事例として，英バークレイズ銀行は2016年7月に，乳製品の取引をブロックチェーンを用いて行った[7]．また，豪コモンウェルス銀行と米ウェルズ・ファーゴは2016年10月に，綿花の取引をブロックチェーンを用いて行った[8]．これらを始めとして，国内外にて多数の事例が進められ公表されている．

筆者らは，ブロックチェーンが備える，高い改ざん耐性と，スマートコントラクトによる自動執行の2点に着目した．高い改ざん耐性は，原本書類の改ざんを防ぐ点や，取引先や金額といった業務秘密を守る点で有用である．また，ブロックチェーンのスマートコントラクト機能を用いることで，複雑な業務を自動処理できる可能性がある．

併せて，分散台帳の仕組みにより，すべての参加者がリアルタイムで情報を共有できることで，情報伝達に要する時間の短縮や手間の削減につながる（ただし，この点はブロックチェーンを用いない従来型システムでも実現できる）．

2.1.3　実験内容

本実験では，ブロックチェーンを用いて貿易取引ワークフローシステムを構築し，以下3点を検証した．

• （1）ブロックチェーンのスマートコントラクト機能を用いて，貿易処理を自動化できるか．
• （2）ブロックチェーンを用いたシステムは，他システムと接続できるか．特に，銀行APIを用いて振込指図を自動化できるか．
• （3）ブロックチェーンを用いたシステムは，貿易取引の手続時間を短縮できるか．

それぞれについて，以下の要領で実験した．

• （1）コンテナに装着したIoTセンサが取得した位置情報をトリガーとして，実験システム上で自動処理を行った．
• （2）銀行APIを用い，実験システムから銀行のインターネットバンキングシステム宛に振込指図を行った．
• （3）実際の貿易取引をもとに，現在各社で用いている商用システムと同時に実験システムを操作し（この手法をシャドーイングと呼ぶ），所要時間を比較した．

なお，実験システムは，商用システムとは接続せず，別に準備したテスト環境で行った．ブロックチェーンが高い改ざん耐性を備えることは，すでにさまざまな実験で認められていることから，本実験の検証範囲外とした．

2.2　実験システムの要件定義

2.2.1　対象とする貿易業務

ブロックチェーンの効果を発揮できると見込まれる貿易業務の1つに，船荷証券（B/L）の権利移転がある．この処理を実験システムに実装した．そのほか，個々の貿易商材によらず，貿易取引に共通する手続きを挙げ，実験システムの要件を定義した．

他の実証実験は，L/C（Letter of Credit, 信用状）を対象としている[9][10]．筆者らは，オープンアカウント方式（L/Cを用いない送金ベースの取引）を対象とした．その理由は，近年，L/Cを含むドキュメンタリーベースの貿易取引に代わり，オープンアカウント方式の取引が増加しているためである．

2.2.2　業務フロー

まず，業務フローを設計した．本実験では，契約，船積，保険関連のドキュメントについて，幅広く対象とした．

実験システムは，図1に示すように，P/O（Purchase Order，発注書）やS/C（Service Contract）など，20種類以上の貿易関連書類を対象とした．請求書を受け取った輸出者が船賃を送金するといった資金決済には，三井住友銀行が提供する銀行APIを用いた．

それぞれの書類のワークフローを制御するため，スマートコントラクトを用いた．図2は，スマートコントラクトを用いた業務フローである．処理の大きな柱は，主契約（Contract）と船積（Shipping）である．主契約機能から船積機能に移り，その中の船積予約処理から，保険機能や決済機能に処理が分岐する．たとえば，輸出者が輸出手続き依頼（S/I，Shipping Instruction）を作成すると，その後続手続きである保険申込みが可能となる．その後，決済機能に情報を引き継いで請求書が発行され，支払方法によって前払（Prepaid）と回収（Collect）のいずれかに分岐する．

実験システムから資金決済を行う際は，まずユーザは，実験システムのWeb画面から送金指示を行う．それを受け，実験システムは銀行APIを発行する．なお，初回利用時にはこの時点で，銀行のインターネットバンキングシステムのユーザ認証が行われる．認証が完了すると，更新APIを送信して送金処理が行われ，その完了記録が実験システムに送信される．

なお，ワークフローは正常系の実装を主とし，ワークフローの差戻し機能や，ドキュメントを修正する機能，修正内容を後続ドキュメントへ自動反映する機能は，本実験では対象外とした．

2.2.3　関係者

貿易には，荷主・荷受人・船会社（およびその代理店）・フォワーダー・保険会社に加え，保険会社の代理店・税関・ターミナルオペレーター・日本商工会議所といった関係者が関与する．そのうち本実験では，対象を貿易の基本機能に絞る観点から，関係者を荷主・荷受人・船会社・フォワーダー・保険会社に限定し，その他の関係者は，実験のスコープ外とした．

2.2.4　対象とする貿易取引

貨物輸送の手段は，専用船とコンテナ船の2つに大別される．専用船は，鉄鉱石のバラ積みや乗用車の輸出のように，船に積載される貨物が決まっていて，その結果，貿易に関する手続きが個別最適化され，標準的な貿易取引手順の一部が省略されていることがある．一方，コンテナ船は，さまざまな種類の荷物をコンテナ単位に格納し，大量に混載して輸送している．本実験では，ブロックチェーンの貿易実務における汎用性を検証するため，対象とする貿易取引としてコンテナ貨物の輸入および輸出を選定した．なお，コンテナの中身は，本実験における貿易手続きには影響しない．

3．実験方法

3.1　実験システムの構築

3.1.1　Fabricの採用

実験システムの構築にあたり，ブロックチェーンには，2017年7月に公開されたHyperledger Fabric 1.0[11]を採用した．Fabricは，Hyperledgerプロジェクトの1つであり，さまざまな業務システムを構築・運用するためのソフトウェア基盤をオープンソースで提供している．

Fabricは，分散台帳（ブロックチェーン）とその合意形成（コンセンサス）機能，スマートコントラクトの開発・実行機能，ユーザIDの発行・認証機能等を有している．Fabricで構築したブロックチェーンは，その参加に許可制を採用している．これは，特定企業間でプラットフォームを構築するのに向き，取引情報を第三者に秘匿したいという業務ニーズにも適合する．

Fabricの台帳は，ブロックチェーンとステートDBの2種類がある．スマートコントラクト（Fabricではチェーンコードと呼ばれる）の実行履歴をブロックチェーンに書き込み，トランザクションを実行した結果の最新状態を，ステートDBに書き込む．

Fabric 1.0が具備する合意形成アルゴリズム[12]は，ファイナリティ（記録の確定性）を有する．Fabric 1.0は，エンドースメントポリシーとチャネル機能によって，台帳の合意形成ルールや情報の秘匿性を柔軟に設定できる．エンドースメントポリシーとは，トランザクションの承認に必要なノード数と実行ノードを決めるルールである．本実験では，過半数（6ノード中4ノード）で承認するルールを採用した．

実験システムの構成を，図3に示す．実験システムは，IBMのクラウドサービスIBM Cloud[13]上のサーバ1台の中に，仮想マシンを8個構築した．

3.1.2　電子船荷証券の実装

貿易業務をシステム化するにあたり，できるだけ多くの取引国や取引種類に対応することが，システム普及の鍵となる．そこで筆者らは，eB/LをCMI ^☆4規則に準拠するように設計した．

CMI規則は，その時代背景もあり，基本的にはEDI（Electronic Data Interchange）を前提とした条文が規定されている．具体的には，電文に添付される個人キーによって，当事者が伝送の真正性と完全性を確保することが求められている．一方，Fabricは，すべてのトランザクションにその発行者の署名が付与される．この機能により，CMI規則を充足できる．

3.1.3　コンテナセンサの実装

コンテナの位置情報を実験システムの入力情報として用いるため，コンテナにContguard社のセンサ兼発信装置CMU-R[14]を設置した．CMU-Rは，設置されたコンテナの位置，温度，湿度，照度，衝撃，コンテナのドア開閉の各情報を取得し，一定間隔でContguard社のサーバに携帯電話網経由で送信する． 本実験では，CMU-Rが取得した位置情報を，Contguard社のWebサイトからCSV形式で自動取得し，実験システムのサーバに転送した．

3.2　実験１：シャドーイング

3.2.1　ロールプレイ

シャドーイングの前に，実験システムの習熟を目的に，過去の貿易取引の情報を用いて実験システムを操作した（以降，この操作をロールプレイと呼ぶ）．図4に，実験システムのWeb画面を示す．

ロールプレイは，輸出取引と輸入取引の2パターンについて計3回実施した．1，2回目は参加各社が1拠点に集合して実施し，3回目は実運用に近い状況となるよう参加各社の拠点に分かれて実施した．

3.2.2　シャドーイング

シャドーイングは，実際の貿易取引を，現在商用利用しているシステムと同時並行で実験システムにも入力する手法を指す．以下に示す輸出取引2件を対象に行った．

• 1）日本2017年12月5日発，英国12月19日着
• 2）日本2017年12月12日発，豪州12月19日着

シャドーイングは，以下の点で，既存業務と異なる条件で行った．実験システムで測定できなかった部分は，過去の貿易取引における標準処理時間を用いた．

• 現行の貿易システムとは接続を行わなかった．
• 通常行われる書類のダブルチェック等は，実験システムでは割愛した．
• 取扱文書を限定した．具体的には，B/L，インボイス（C/I），パッキングリスト（P/L），保険証券（I/P）等を対象とし，C/O（原産地証明書），領事査証，各種証明書，B/L以外の船積書類（Shipping Documents）等は対象外とした．
• 関係者を限定した．具体的には，日本側フォワーダーや仕向地側カスタムブローカー等との情報連携については割愛した．

3.3　実験2：コンテナセンサとの連携

本実験では，CMU-Rが取得したコンテナの位置情報をもとに，実験システムが貨物到着案内（A/N，Arrival Notice）を自動発行する処理を実装した．コンテナの位置が所定の港の近隣海域に入ったとき，A/Nを送信するスマートコントラクトを実行した．図5は，コンテナにセンサを取り付けた様子である．

実験2は，以下に示す貿易取引2件を対象に行った；

• 1）日本2018年2月14日発，英国3月18日着
• 2）日本2018年2月27日発，香港3月5日着

4．実験結果

4.1　実験システムの評価

実験システムの設計・実装・試用を通じて，以下の結果を得た．

4.1.1　貿易取引ワークフローシステムの構築

貿易取引ワークフローシステムには，ステータスの制御機能やプロセスの自動実行機能，登録済データを変更する機能などが必要となる．本実験では，これらの機能をFabric 1.0を用いて実装できた．その過程で，たとえば，契約→船荷→｛支払，保険｝のように，条件によって副処理が発生し，複数のフロー間を同期する処理の設計や実装は，比較的難解であった．

また，法制度や業界ルールの変更により，業務フローを変更する場合がある．そこで，実験システムのリリース後にチェーンコードの更新を試みた結果，実験システムの他機能に影響を及ぼすことなくチェーンコードを更新できた．

一方，実験システムに登録したデータを変更するには，専用のチェーンコードを準備する必要があることが分かった．ブロックチェーンを直接変更することは改ざんにあたり，Fabric 1.0のブロックチェーンに記録されたデータは，チェーンコードを介してのみ変更できるためである．

4.1.2　ユーザ認証機能

貿易取引システムは，そのユーザ（貿易関係者の各スタッフ）ごとにIDを設定し，IDごとに取引単位・ドキュメント単位・ドキュメントの項目単位で情報の参照・更新権限を制御する必要がある．本実験では，これらの機能を実装し，各ユーザがWeb画面からログインしてシステムを利用できた．また，設定した権限に従い制御できていることを確認した．このことから，貿易システムで必要とされる最低限のユーザ認証・認可の機能をFabric 1.0で実装できることが確認できた．

実装の過程で，Fabric 1.0はアクセス制御機能の共通ライブラリが準備されていないことが分かった．システム開発生産性向上の観点からは，共通ライブラリが提供されることが望まれる．本実験では，部分的に独自ライブラリを作成し，開発生産性向上を試みた．

また，Fabricへの接続に用いるIDとパスワード（FabricではそれぞれEnrollment IDとsecretと呼ばれる）は，Fabricの外で管理するため，そのセキュリティ強度は従来と変わらない．よって試用の過程で，IDとパスワードは従来と同等水準で管理する必要があることが分かった．

4.1.3　他システム連携

実験システムと他システムとを接続でき，実用上問題なく利用できることを確認した．具体的には，実験システムは，コンテナの位置情報をContguard社のサーバ経由で受信できた．また，実験システムと銀行のインターネットバンキングシステムをAPI接続し，実験システムから銀行口座への振込指示を問題なく実行できた．

4.2　実験1の結果

シャドーイングに先だち実施したロールプレイの結果，実験システムの利用者は，実験システムを用いることで，現行の手続きフローよりも手続き時間が短縮できる可能性が体感できた．

表1は，標準所要時間とシャドーイングの所要時間（2回の試行）を，分単位で示したものである．シャドーイングの所要時間は，2回平均で60分であった．一方で，通常業務における標準所要時間は2,420分（1日24時間換算で約1.7日），郵送時間を除き225分である．実験システムを用いることで，実験シナリオにおける所要時間は，約40分の1（郵送時間を除くと約4分の1）に短縮した．

さらに，筆者らは実験参加者から以下の肯定的なコメントを得た；

• UX（ユーザエクスペリエンス）の観点では，実験参加者は「簡単で使いやすい」「プロセス全体を明確にとらえることができる」と評価した．
• 効率面では，システムへの入力数が減るため，作業量を削減できる．また，B/Lの権限委譲について，書類による現在の手続きでは，裏書手続きや原本の輸送が必要であるのに対し，システムのボタン1つで操作できる．

4.3　実験2の結果

第3.3節で示した2回の試行1），2）のうち2）の試行において，スマートコントラクトを実行できた．

1）の試行では，目的地の途中までコンテナの情報を取得したが，センサの電池が枯渇したため，チェーンコードが作動する計画タイミングよりも前に通信が途絶した．

2）の試行では，コンテナが香港入港前の特定海域に入った時点で，位置情報に基づき，チェーンコードが作動し，A/Nが自動で発行された（図6）．

また，コンテナ輸送の途中で，位置情報がリアルタイムに取得できない事象が発生した．具体的には，コンテナが船の下部に積載され，他のコンテナに囲まれたことが影響して，センサの通信状況が変化し，電波が途絶した．

5．考察

5.1　ビジネス上の効果

実験の結果，実験システムの商用化には，以下に挙げるような可能性が考えられる．

第1に，ブロックチェーン技術によらず，貿易書類が電子化されることで，書類の不備や内容不一致の発生リスクが下がると考えられる．これにより，L/Cの買取・確認時間の短縮が期待できる．また，書類の輸送料や船荷証券発行料，フォワーダーへの手数料等が不要となる可能性がある．

第2に，B/Lに伴う貨物引渡請求権の管理・移転が安全にブロックチェーン上で行われることにより，銀行だけでなく，多様な事業者が貿易債権の保証や債権の買取を行うことが可能となり，ファイナンスの裾野が広がる可能性がある．

第3に，コンテナ装着センサから取得した，積載貨物の温度や湿度といった情報を用いることで，貨物の管理水準の向上が見込まれる．また，センサから取得した位置情報を貨物の担保管理に活用することも考えられる．一方，導入にあたり，IoTセンサの利用料が追加で必要になる．

さらに，銀行システムといった他のシステムと接続され，ワンストップで手続きを行えるようになると，業務効率化につながり，実務面で有用である．一方，業務効率化のためには，システムの機能だけでなく，画面の使い勝手といったユーザインタフェースも利用者の意見を踏まえて決定する必要がある．

5.2　導入に向けての課題

本実験の過程で，実験関係者と商用化に向けた議論を行った結果，実験システムを商用化するには，本実験の検証項目だけでなく，多岐にわたる課題を解決する必要があることを再認識した．それらの課題について，以下に整理する．

5.2.1　ブロックチェーン技術に関する課題

第1に，各関係者がブロックチェーンの特性を理解し，それを活かした業務設計を行う必要がある．ブロックチェーンのコンセプトは，各参加者が対等な立場で，情報を統一ルールで分散管理する点にある．ところが現実には，参加者（企業）の規模や役割は均質ではなく，統一ルールの策定には多くの合意形成（コンセンサス）を要する．このため，ブロックチェーンを用いたプラットフォームの構築は，単一の企業が開発・提供する商用パッケージシステムと比べて難易度が高く，それゆえにビジネスリスクも大きい．よって，ブロックチェーンを用いたシステムの商用化には，各関係者がブロックチェーンの特性を理解した上で，それを活かした業務設計を行う必要がある．

第2に，ブロックチェーンのノードの管理主体を定義する必要がある．プラットフォームの参加者ごとにノードを保有する場合，ノードの導入に要する初期コストが参入障壁となり得る．特に，貿易に携わる企業は大企業のみではないため，すべての参加者がノードを管理することは困難である．一方，管理者が特定少数に限定された場合，従来の集中管理型システムに近似し，ブロックチェーンを採用する意義が薄くなる可能性がある．これらを踏まえ，金融機関や中立的な業界団体といった，貿易参加者が信頼できる機関にノードの管理を委ねることが現実解となり得る．

第3に，クラウドサービスを利用するための社内ルールのや業界標準を整備する必要がある．ブロックチェーンは，情報を分散保管する点で，クラウドサービスとの親和性が高いと考えられる．一方，貿易に携わる企業においては，クラウドサービスの採用がまだ途上であり十分ではない．貿易システムのブロックチェーン化を契機に，クラウドサービスやAPIといったサービスを利用しやすくするための環境整備も，その広範な普及には必要である．

5.2.2　ビジネス面に関する課題

本節では，ブロックチェーン技術によらず，貿易実務において業界標準システムを商用化するにあたっての課題を示す．

第1に，プラットフォームの利用に際し利害関係がなく，皆が参加できることである．プラットフォームは，それが扱う情報の共有や透明性と，企業間競争の観点からの業務秘密保持とを両立させる必要がある．その点を踏まえ，プラットフォームの運用方法を決定する必要がある．さらに，貿易プラットフォームが乱立した場合，各参加企業にとっては，複数のプラットフォームの導入コストが課題となり，普及の妨げとなる．また，1つの貿易取引を複数のシステムに登録するといった重複作業は，回避されるべきである．

第2に，事業継続のための収益モデルを築けることである．プラットフォームは，参加者が増えることでネットワーク効果が働く．参加者を増やすには，料金をできるだけ廉価に設定するだけでなく，システムの拡張容易性も重要である．他システムと容易に接続できることで，利用者の拡大や一元管理できるデータの拡充につながる．

第3に，電子契約の法的効力を強化することである．今回のeB/Lは，第3.1.2項で述べたとおり，CMI規則に準拠した．これは欧州で標準となっているBolero（Bill of Lading Electronic Register Organization）[15]などと同様に，eB/Lの認定要件の一部を満たすように設計した．なお，CMI規則に準拠するだけでは十分ではなく，各国の法制度にも準拠する必要がある．さらにeB/Lは，現状，国際的な法体系が整備されていない．具体的には，eB/Lについて規定している国際条約であるロッテルダム・ルールズ（全部または一部が海上運送による国際物品運送契約に関する国連条約）が発効していない問題がある．このため，Boleroで行われているように，複数の当事者間で順守すべきルールブックを定め，その合意者のみが利用可能とする方法がある．しかし，ルールに漏れがある場合は，Boleroの外側で，当事者間で個別に定めた準拠法に依拠する考え方となり問題が生じる．商用化にあたっては，本実験で設計したeB/Lの法的位置づけを確認する必要がある．

6．おわりに

本稿では，ブロックチェーンを用いた貿易システムの試用と，実用化に向けての課題について述べた．

筆者らは，実際の貿易取引をFabric 1.0で実装した実験システムで管理した結果，問題なく稼動し，実務における業務効率化の可能性が示された．

ブロックチェーンを利用した貿易システムを商用利用するには，第5.2節に挙げた課題を解決していく必要がある．貿易業務の電子化はあくまでNice-to-haveであり，貿易に携わる企業は，プラットフォームに蓄積されたデータを用いた新たな価値の提供や，サプライチェーン全体の可視化などを求めている．実験システムが，さまざまな関係者にさまざまな事例で試用され，改善を続けることが必要である．貿易業務の効率化を通じて，貿易取引が質・量ともに一層豊かになることが望まれる．

謝辞　本実験の共同実験者である，日本アイ・ビー・エム，三井物産，商船三井，三井住友海上火災保険の関係者の皆様に深謝いたします．