今から四半世紀前、「IT革命」というワードが流行語大賞になり、IT基本法が成立して内閣にIT戦略本部が設置されるなど、国を挙げてIT化の推進体制が整ったころのお話。日本の貿易業界では「TEDI（Trade EDI）」と呼ばれる貿易取引を電子化するための仕組みが構築され、商用化に向かっていました。この記事では、TEDI関係者の記憶をたどり、その貴重な経験から得られた教訓や、現代のデジタル変革に生かせるかもしれない提言をいただきます。前編は、TEDIの背景やコンセプトの解説と、いくつかの問題点について。
元テディ・アドバンスト・ネットワーク（TEDIANET）社長 渡邊浩吉氏（談）
（編集部注）本記事タイトル、記事内見出しはtradigi.jp編集部にて作成。
現在、有価証券性を持つB/Ｌ（船荷証券）について世界各国でeB/L法制化の検討が進むなど、貿易DXに向けた環境が整備されつつあります。技術面でもブロックチェーンが普及したことで電子情報の信頼性を担保する仕組みがいっそう充実し、記憶装置・処理装置や通信環境の飛躍的な性能向上によってツール活用の選択肢も大きく広がった印象です。そして何より、こういったデジタル技術を活用するための知識に習熟された人が多くなっていると感じます。しかし、貿易業界はプロセス面や文書面などを始めとしてバリエーションが大変多い世界で、その点においてデジタルで事を運ぶのが容易ではない部分もあります。経済産業省を中心として、貿易手続デジタル化を実現するための効果的な手段として「貿易プラットフォーム（貿易PF）」の普及・活用に向けた取り組みが進んでいますが、以下は貿易PFという言葉も使われていなかった時代の話です。
今から四半世紀も前、西暦2000年ごろに日本でTEDI (Trade EDI、日本語原名「貿易金融EDI」) という仕組みが開発されたものの、スタートから5年ほどで首尾を全うできずに終了しました。筆者はそのTEDIを運営するテディ・アドバンスト・ネットワーク（TEDIANET）社の社長を務めておりました。
あれから長い年月の経った今日、TEDIの事を話しても何か役に立つのかどうか見当もつきませんが、当時どのような問題があり、どのように対処しようとしていたのかをお伝えし、そこに現在にも通じるものがあるとすれば何かの参考にしていただけるかもしれず、それにより、全うできなかったTEDI が別の形でお役に立つことになれば望外の喜びです。
なお、本稿は正式な記録や見解に基づくものではありません。当時の関係者とお打ち合わせをしたものでもなく、インターネット上に残る断片的な情報をかき集め、個人の記憶と突き合せて文字化したものです。従って、記憶違い、理解違いもあるかと思いますが、そこは何卒ご寛恕ください。また、事実に対するコメントについては、筆者の私見とご理解願います。
TEDIの概要
TEDIはどんな背景から生まれたのか
西暦2000年頃は「IT革命」というワードが流行し、コンピュータの利用ケースにおいてインターネットが急激に重用されるようになった頃でした。貿易文書の交換にも、当然インターネットや電子データ交換を活用すべきであるとの考えが多くの貿易関係者にも広がっていました。この流れの中で、通商産業省（現・経済産業省）から貿易システム開発のお話があり、TEDIプロジェクトが始まりました。
当時、貿易文書の電子データ交換は既に一部で実施されていましたが、業種や個別の業務委託関係などをベースにした、独自の方法・仕様・ルールによるものでした。これでは国として全体を包括するシステムにはなりません。そこで、ebXML（Electronic Business using eXtensible Markup Language：タグで囲んで意味や構造を記述するXMLをベースとした、企業間電子商取引を円滑に行うための仕様）で作成した標準フォーマットを提供し、作業効率を高めるために同じデータは複数の文書に二重入力無しに転用できるようにするなど、当時の技術をできる限り盛り込んだ汎用性のあるシステムとして構築されたのがTEDIです。
TEDIはどんな構成になっていたのか
【図 TEDIの概念図（筆者作成）】
TEDIは、インターネットを介して利用者間のデータ交換を可能にし、そのやり取りの信頼性とデータの真正性を確保するため、図に示した通り二重構造になっていました。まず、データ交換されるメッセージの真正性を保証する基盤としての機能を実現するのが Repository Service Provider (RSP)である 日本電子貿易サービス（JETS）社です。後述するeB/Lに係る権利移転を、裏書の代替として電子的に実現するための記録保全機能 (Repository Service) を提供する他、メッセージに付ける電子署名に必要な認証局（個人や企業にインターネット上で電子証明書を発行し、電子署名等での信頼性を保証する機関）としての機能も持っていました。
次に、TEDIをアプリケーションとして利用者に課金ベースで提供するのが、Application Service Provider (ASP) であるテディ・アドバンスト・ネットワーク（TEDIANET）社です。利用者が必要とするRSPの機能を、利用者が直接RSPにアクセスすることなく、一元的に提供するインターフェースの役割を果たす他、主要な貿易文書については標準フォーマットを提供するなど、利用者の貿易実務に添った広範なサービスを提供していました。
そして、TEDIの普及推進を担うのがTEDI Clubという組織で、メーカー、商社、物流、運送、銀行、保険等の貿易関連企業によって2000年に立ち上げられ、その後もTEDI利用者に加入してもらうことで、TEDIの組織を形成していました。
現在であれば、デジタル化するということは単に紙の作業を電子作業に置き換えることではなく、業務のやり方自体を見直し、デジタル化によるメリットを最大限に引き出せるようにすることだという理解も広まっていると思います。しかしながら、当時はまだ紙の作業が当たり前のように多用されておりましたので、それらを実務上もれなく電子作業に置き換えられるかどうかがひとつの評価基準にならざるを得ませんでした。とにかく利用者に納得してもらわなければ話が進みませんから、実情に沿ったフォローを最優先にして対応する状況でした。
TEDIの、各側面における問題点の整理
Boleroに負けるな？
世界的なITブームの中、欧州で開発された貿易システム「Bolero」が1998年にスタートしたことを受け、これに後れを取らないようにとの意識もあって、匹敵する機能を持ったシステムとしてTEDIが開発され、2001年から稼働しました。
その意味では、貿易関係業界の要請を受けてというよりも、当時としては新しいコンセプトだから、先ずシステムを構築した上でそのメリットを広く情宣し、貿易関係業界からのフィードバックを受けながら改善することで利用者に納得してもらえるシステムに作り上げ、出来る限り早く活用する気運を高めていくことが必要だとの啓発的な意味合いが強かったようです。
当時はEコマース（電子商取引）が好調なスタートを切った頃ですから、貿易電子化の仕組みについても完成さえすれば自ずとニーズが湧き出てきてくれるのではないか、と期待していたところもあったと思います。しかしながら、実際にはその後多くの企業に個別に働きかけてニーズの掘り起こしに努めることになりました。
集中管理型のBolero、各国対等をめざしたTEDI
TEDIの基本的なコンセプトは、貿易相手国の貿易電子システムとの連携によりデータ交換を成立させることです。そこで、TEDI Clubは当時アジア8ヵ国の貿易電子システム事業者で構成されていたPan Asian e-Commerce Alliance (PAA) 1に加盟し、まずはPAA各国と連携することが念頭に置かれていました。
【図 TEDIの目指したコンセプト（筆者作成）】
PAAには、約款、貿易関連文書の標準フォーマット、電子署名用の認証局が実装されており、国境を越えた取引に対応できる体制になっていました。従ってTEDIは、PAA各国とはシステムを連携させた上で、PAAの約款とフォーマットに基づき、利用者に文書データ交換のサービスを提供することになります。すなわち、PAAの各貿易電子システム事業者とTEDIは、仕組みや機能はそれぞれ違っても、立場は対等な関係となります。一方Boleroは、貿易関係者を個社ベースにそれぞれ利用登録させ、Boleroが提示する規約(Bolero Rule Book)で公平に拘束し、電子メッセージ交換用のプラットフォーム(Core Messaging Platform)と権利登録システム(Title Registry)を利用させるという、 シンプルで分かり易いグローバルな集中管理型の構造を採用していました。Boleroの構成メンバーは国際金融通信の標準組織SWIFT、各国の船会社等が加盟し国際船主賠償責任保険(P&I)に関連するTTClub等であるということからも、汎用性や世界レベルでの展開には確信が持たれていたかと推測されます。
集中管理型が採用されたBoleroに対し、TEDI はいわば分散型で、各国の貿易電子システムと共存することに重点を置いた方針がとられたということになります。
メッセージ変換からワークフローづくりまでサポートしたものの・・・
TEDIの基本は、前述の通りTEDIANET社（ASP）を使って、貿易関連書類の標準フォーマット（ebXML）や書類作成の仕組みを参加メンバーで共用し、関連業種間、国内外の関係企業間の電子データ交換（EDI）を実現することです。これにより、データの汎用性を高めて貿易業務の効率化を図ることを目指していました。当初想定した使われ方は、利用者がTEDIの提供する標準フォーマットに基づいて文書を作成してASPに送信するという流れになります。
ところが、利用者はワープロソフトや表計算ソフト、または社内システムの独自フォーマットで文書を作成しており、その場合は送信前にTEDIの標準フォーマットに変換する必要が生じます。この辺りで利用者は煩わしさを感じて興味を失い始めますので、さらに踏み込んだ提案が必要になりました。例えば、社内の文書フォーマットを解析して変換モジュールを開発する作業をTEDIでサポートする提案、あるいは利用者の委託により利用者独自フォーマットのままASPに送信してもらい、受信側で（いくつかの合意等が必要ですが）変換するオプションを用意するといったことです。
これとは別に、TEDIにシステム連携するのではなく、利用者のPC画面からTEDIの標準フォーマットに直接入力するWebサイトも提供しました。これは利用件数がそれほど多くない場合には効果を発揮するものでしたが、それでも既存の仕組みとは異なる入力作法を覚える必要があるなど、一定レベルの手間はかかります。他に、利用者がメッセージを送信する前に必要な社内承認プロセスをを電子的なワークフローに落とし込むための設計も支援していました。これに加え、当時の貿易手続行政システムであるCuPES（税関手続申請システム）やJETRAS（貿易管理オープンネットワークシステム）とも連携されていました。
こういったアプローチを通じて「個社毎に独自に貿易電子化システムを立ち上げることに比べれば、標準・共通の仕組みとしてTEDIを導入する方が合理的である」ことは理解されたとしても、そもそもそれが必要か否かという話になると、例えば同じ社内でもシステム部門と貿易実務部門ではニーズも考えも異なるというケースは起こり得ることで、利用者の開拓にはかなりの工数がかかることになりました。
TEDIのスタート当初は、このような貿易の電子化自体が黎明期だったため、サービスの提供側、利用側が双方とも手探り状態であったことが否めませんでした。最新技術の導入を目指しつつ、発見された不具合には可能な範囲で手を打ちましたが、中には大規模なシステム改修が必要と思われるケースもあったようです。更に、前述のように利用者からの要望に事細かに対応することが欠かせず、その結果コストが嵩むことになりました。結局、TEDIは事業として許容される期間内では採算ラインに乗せられる見通しが立てられず、志半ばで終了することになります。【前編終了、後編に続く】