第 6 章 プロジェクトの実施と結果のフィードバック
6.2. データ連携システム同士の連携実証
82
て、クラウドサービスと共通EDIプロバイダー機能を併設する形態（以下、
便宜上「一体型」という。）に用いられることを想定している。
・ API方式
API により連携する方式である。主に、それぞれ異なるベンダーが運営す るクラウドサービスと共通EDIプロバイダーが連携する形態（以下、便宜上
「分離型」という。）に用いることを想定している。
「分離型」の連携における API は、都度個別の協議にて仕様を決める手間お よび接続先ごとに開発するコストの発生を回避するために、仕様の共通化が求 められる。
実証検証仕様の策定に際し、モデルプロジェクトに提案を求めたが、実証プ ロジェクトは「一体型」が大半を占め、この形態においては独自方式が有効で ある。他方、「分離型」の実証プロジェクトは2件であり、1件は独自APIで接 続し、他の1件はJX手順で接続したため、共通APIについての実証検証は各 モデルプロジェクト単位では実施していない。
(ウ) 共通EDIプロバイダー間連携仕様
共通 EDI プロバイダー間の連携については、「7.2. データ連携システム同士 の連携実証」にて示す。
既存のEDIとの連携仕様
共通EDIプロバイダー間の連携についても、同様に「7.2. データ連携システ ム同士の連携実証」にて示す。
83 れた。
表 10 データ連携システム同士の連携実証の検証パターン
6.2.1. データ連携サービスプロバイダー同士での連携実証
本事業にて策定した中小企業共通EDIに対応するデータ連携サービスプロバイダ ー同士は、「1.4.1. 業種の垣根を越えたデータ連携システムの基本的な考え方」に示 したように、それぞれが国連CEFACTに準拠した仕様であることから、大きな負荷 なく互いを経由し、それぞれのデータ連携サービスプロバイダーを利用するユーザ ー企業同士のデータ連携を狙っている。
本調査実証では、中小企業共通EDIに対応するデータ連携サービスプロバイダー 同士について、5パターンのテストケースにて検証を行った。この連携方式について は、仕様化に至っていないことから、モデルプロジェクトの参加ベンダー企業から の提案を元に調査実証の連携方式を定めた。
(1) エージェント方式
データ連携サービスプロバイダー同士での5パターンでの連携実証のうち、3つ のパターンは「エージェント方式」として、ファイルの転送による連携を行った。
これは、データ連携システムと業務アプリケーション間の連携に多く用いられて いる手段の応用であり、データ連携サービスプロバイダーにとっての開発負荷が 小さい連携方式である。「エージェント方式」は、データ連携サービスプロバイダ ーの違いによる障害が発生しないことを確認するため、同様の連携方式で、異な るデータ連携サービスプロバイダーのパターンを3種類検証した（表10 # 1-3）。 (ア) 小島プレス社とグローバルワイズ社の両プロバイダー間
(イ) スマイルワークス社とグローバルワイズ社の両プロバイダー間
5 アプリケーションエクス社 プロバイダーエクス社 未来EDI グローバルワイズ社プロバイダー アプストウェブ社アプリケーション プロトコル
2 アプリケーション小島プレス社 小島プレス社プロバイダー エージェント方式 グローバルワイズ社プロバイダー グローバルワイズ社アプリケーション
3 スマイルワークス社アプリケーション スマイルワークス社プロバイダー グローバルワイズ社プロバイダー アプストウェブ社アプリケーション 1 イークラフトマン社アプリケーション イークラフトマン社プロバイダー グローバルワイズ社プロバイダー アプストウェブ社アプリケーション
4 アプリケーション武州工業社 プロバイダー武州工業社 ベース独自方式SOAP-RPC グローバルワイズ社プロバイダー アプストウェブ社アプリケーション
6 アプリケーション日本情報通信社
日本情報通信社 プロバイダー
（流通BMS対応）
データ連携ITツール
（本事業開発ツール）
データ連携ITツール
（本事業開発ツール） JX手順
業務アプリ発注者側プロバイダー 連携方式 プロバイダー受注者側業務アプリ
データ連携サービスプロバイダー と他EDIシステムとの連携実証 データ連携サービスプロバイダー
同士での連携実証
# 目的
84
(ウ) イークラフトマン社とグローバルワイズ社の両プロバイダー間
調査実証の結果、「エージェント方式」を用いた（ア）（イ）（ウ）それぞれのパ ターンで企業間のデータ連携を確認できた。開発負荷も小さいことから、当面有 効な連携方式であると考えられるが、今後、データ連携サービスプロバイダーを 多段に跨ぐ際の仕様策定やその検証が必要である。
(2) SOAP-RPCベース独自方式
本パターンは、SOAP-RPCをベースとした独自の連携方式によるパターンであ る。クラウドサービスであるデータ連携サービスプロバイダー同士が連携する上 で、「エージェント方式」以外の有効な方式として提案があった。同連携方式は、
「エージェント方式」と比較し、開発負荷が大きくなるが、即時性を含め、より データ連携サービスプロバイダー同士の連携を志向した連携方式である（表10 # 4）。
調査実証の結果、「SOAP-RPCベース独自方式」を連携方式とした場合において も、企業間のデータ連携を確認できた。「エージェント方式」同様、当面有効な連 携方式であると考えられるが、今後、データ連携サービスプロバイダーを多段に 跨ぐ際の仕様策定やその検証が必要である。
(3) 未来EDIプロトコル
本パターンは、「未来EDIプロトコル」と命名した、将来的に中小企業共通EDI にて広く用いられることを見越したパターンである。本調査では、あるデータ連 携サービスプロバイダー同士の連携を確認するが、今後中小企業共通EDIが普及 をしていく中では、データ連携サービスプロバイダーが多段に跨り連携を行うこ とが想定される。その際には、ユーザー企業のアドレスをいかにデータ連携サー ビスプロバイダー間で共有・特定し連携を行うかなど、更なる技術的な検討が必 要となる。「未来EDIプロトコル」は、将来的な問題を見据えて検討を行っている 新方式である（表10 # 5）。
「未来EDIプロトコル」においても、本調査実証でのデータ連携が確認できた。
「未来EDIプロトコル」は将来性に重き検討が進む一方、まさに検討中途の仕様 ではあることから、今後も継続して検討・検証を行い、実用化を目指す必要があ る。
6.2.2. データ連携サービスプロバイダーと他EDIシステムとの連携実証
また、「1.4 課題解決の方向性」（11 ページ）図 7「課題解決の基本的な考え方」
に示したように、業界標準EDI等、中小企業共通EDI標準の仕様と異なる個別の受 発注システムに対しても、ゲートウェイを介し変換を行うことで、個別の受発注シ ステムを用いるユーザー企業に対してもデータ連携を実現することを見込んでおり、
今回は1パターンの調査実証を行った（表10 # 6）。 (1) 流通BMS
我が国の既存のEDIの仕組みとして、最も普及が進んでいる仕組みのひとつは 流通BMSであり、卸・メーカーの導入企業数は2017年12月1日現在で11,400 社
85
以上と推測され、この半年間で 600社ほど増加している16。
中小企業共通EDIが、既存の業界標準EDIなど他の受発注システムに対しても 連携を実現するために、既に普及をしている流通BMSとの連携実現性を確認する 必要があることから、本調査では有効なサンプルとして、1パターンにて検証を行 った。
結果、本項で示すデータ連携の定義としては、その実現が確認できた。
一方、次のような課題が明らかになった。
本調査では注文プロセスを対象としたが、注文メッセージにおける中小企業共 通EDI標準仕様書で定めた必須情報項目が13項目であるのに対し、流通BMSの 必須情報項目は 36 項目存在する。今回の調査では、発注側が中小企業共通 EDI であったため、企業間データ連携を行う必須情報項目が不足しており、また中小 企業共通EDI標準仕様書で定めた注文プロセス全135項目を用いたとしても、流 通BMSの必須情報項目36項目に対して対応項目が不足していた。流通BMS側 のシステムが、36 項目に満たないデータ連携はエラー処理となることから、本調 査のマッピングの際には、中小企業共通EDIの「注釈項目」を汎用的に用いるこ とで企業間データ連携を実現している。
これは、発注側が流通BMS、受注側が中小企業共通EDIであった場合も同様に 課題となり、いかに情報項目をマッピングしスムーズな情報連携を実現するか、
これら課題解決に向けては慎重な協議・調整が必要である。