第58号ｅｂＸＭＬとＷｅｂサービスによる次世代ＥＤＩ(サマリー)～商流情報と物流情報のリアルタイム連携～(2004年6月25日発行)
| 執筆者 | 藤野 裕司 蝶理情報システム株式会社 EC事業推進部 スペシャリスト |
|---|
目次
はじめに
１９８０年に「ＪＣＡ手順」という日本初のＥＤＩプロトコルが生まれて以来、日本のＥＤＩは世界とは異なる発展を続け、独特の体系を作り上げてきた。それは世界に誇るべき機能を持ちながらも、世界とは相容れない方法として今もなお広く使われ続けている。
しかし、２０年以上前に作られたこの規格は、インターネット時代においてふさわしい規格とは言えなくなってきた。ここは最新の世界標準に目を向けるべきであろう。ただし、新しければいいのかというと決してそうではない。これまでの膨大な歴史的ＥＤＩ資産を簡単に捨てることはできないからだ。
そこで本稿では、ＥＤＩに関わる最新技術を従来の日本型ＥＤＩに照らし合わせ、より柔軟な次世代ＥＤＩを実現する方法を提案してみたい。ただ、紙面の関係上多くを語ることができないため、ここは「サマリー」ということにして、詳細は別途発表するようにしたい。そこには、本稿で書ききれなかった、
・現行技術と次世代技術の違い
・XMLのビジネスレベルから見たメリット
・リアルタイム連携が必要なわけ
・ＥＤＩを取引のトレーサビリティという視点で見ると
・システム構築上の考慮点
・実施・運用・普及時の検討事項
・次世代への移行の段階
・想定できる利用例
等を含めたいと思う。
よって、ここではあるべき姿を中心に、これまでなかなか実現できなかった「商流情報と物流情報のリアルタイム連携」という視点から次世代ＥＤＩをかいまみてみたい。
１.次世代ＥＤＩとは
■ これまでのEDIは「企業間対向１対１のデータ交換」 ■
現在のEDIは、企業もしくは事業所に１つ設置されたEDIサーバに対外的なデータを集め、そこから他企業のEDIサーバに向けて1対1の企業間データ交換を行なっている。ここでいうEDIサーバとは、メインフレームやオープン系フロントエンドサーバに搭載されたデータ交換システムをいう。昔のように、アプリケーションがメインフレーム集中ならこの方式で問題はなかった。 ［図１］
図１ メインフレーム集中型業務システム
しかし、今はオープン系サーバを含めてアプリケーションが分散している。複数のサーバに業務がまたがり処理することも少なくない。また、求める情報が異なるサーバに分散して存在することもよくある話。［図２］
図２ オープン系分散型業務システム
そうなると、企業間で交換するデータを作るのに、複数のサーバに存在するアプリケーションが連携する必要が出てくる。つまり、EDIを行なうためには異なるサーバの業務を連携させてデータを管理する必要があるのだ。
■次世代ＥＤＩでは「企業間を含めた複数サーバ間リアルタイム連携」が必要■
このように、現行ＥＤＩであっても複数サーバのデータを連携させる必要が出てきている。そこで、次世代ＥＤＩがどのような形で発展していくかを考えてみたい。先進的な企業や業界でこの動きはすでに始まっており、 「現行技術で実現する企業間のリアルタイムＥＤＩ」がその走りである。従来のＥＤＩはバッチ型ファイル転送であったが、この部分がリアルタイムにつながることになる。
では、次世代ＥＤＩでいう「リアルタイム連携」とはどのようなものか。ここで、その定義を「共通・安価なネットワークインフラとなったインターネットならびに標準的な手法を用いて、任意の企業に自在にデータ授受の連絡および照会ができるリアルタイム処理も可能なＥＤＩ」としてみたい。あえて「リアルタイム処理も可能な」としたのは、リアルタイムだけがよいのではなく、リアルタイム処理の必要がない場合や大量データ・大量処理のように従来型のファイル転送処理の方が都合がよい場合もあるからだ。また、すべての企業が一斉にリアルタイム処理に切り替えられるわけでもなく、柔軟な方式を維持することが次世代への有効な移行手段と考えるからである。
■ キーワードは「インターネット」と「標準化された手法」 ■
ここで最も重要なのは「インターネットならびに標準化された手法を用いる」点であることを強調しておきたい。その結論として筆者が提案する次世代ＥＤＩの条件は、
・散在するサーバのアプリケーションが、リアルタイムかつシームレス
に連携できること。
・セキュリティが十分確保できること。
・国際標準に準拠し、システム開発を容易にするツール群が豊富である
こと。
等が挙げられる。
しかし、今始まりつつあるリアルタイム型ＥＤＩは、個別企業の独自方式もしくはＶＡＮセンター経由のクローズなシステムである。これではシームレスにも国際標準準拠にもならない。そこでその条件に見合った形態を考えると、「ｅｂＸＭＬとＷｅｂサービスによる商流情報と物流情報のリアルタイム連携」に行き着くのだ。
２.リアルタイム連携を実現するインフラ
～ｅｂＸＭＬとＷｅｂサービス～
■ 企業間はｅｂＸＭＬ、社内はＷｅｂサービスで連携 ■
では、そのｅｂＸＭＬとＷｅｂサービスをもう少し深く探ってみたい。インターネットが高速かつ安価に利用できるようになった今、これを支える技術も普及し安定しつつある。
その流れの中、ｅｂＸＭＬはＷｅｂサービスの拡張機能という位置づけのもとに、国際的なＥＤＩ標準として策定が進んでいる。ＥＤＩに注目した取り決めを細かく規定しており、企業間接続では国内外を問わず標準化された利用が進むと思われる。アジア地域ではインプリメントが進んでおり、相互接続試験も頻繁に実施されている。また貿易分野では本番業務も始まっており国際ＥＤＩとして注目されている。国内では電子機器業界（JEITA）がｅｂＸＭＬをベースとした『企業間コラボレーションを実現する新ＥＣ標準（ＥＣＡＬＧＡ）』を発表した。従来型ＥＤＩ（EIAJ-EDI）の後継として注目されている。
一方、Ｗｅｂサービスはインターネット上のアプリケーションを自在に連携できるような機能を提供している。マイクロソフトとＩＢＭが中心となって提唱した標準規格で、現在米国を中心に企業内アプリケーションの連携を目的とした導入が始まっている。
つまり、異なる企業間の接続は標準化されたｅｂＸＭＬで、社内のアプリケーションは自由度の高いＷｅｂサービスで連携するのが好ましい接続形態と考えられる。また、技術的に見てもＸＭＬがベースであるため、互いに非常に相性がよくなっている。[図３][図４]
図３ 企業間（国内・海外）はｅｂＸＭＬ 社内はＷｅｂサービスで連携
図４ ｅｂＸＭＬとＷｅｂサービスの技術的共通性
■ 次世代ＥＤＩの核となる技術 ■
ここで参考のため、少し技術的説明を加えておきたい。とはいえ、本稿は技術解説が目的ではないため、ＷｅｂサービスとｅｂＸＭＬの概要程度にとどめておく。
◎Ｗｅｂサービスとは
ネットワーク(Web)上に存在する複数のサーバを相互に接続し、個々のアプリケーションが自在に連携した統合的なサービスを利用者に提供する機能。
サーバ間のシステムやアプリケーションを連携するため、情報をやり取りする方式やメッセージ、フォーマットなどが決められている。（ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩなど）
| ＊ |
ＳＯＡＰ（Simple Object Access Protocol） ・ ＸＭＬデータをシステム間でやり取りするための通信プロトコル。 ・ 電子的な封筒で構成され、「送付先情報」「送り主が本人であることを証明す る署名」などが含まれている。 ・ ＸＭＬデータ（ＳＯＡＰボディ）に送付先等の情報（ＳＯＡＰヘッダー）を付 けて、電子封筒（ＳＯＡＰエンベロープ）に入れて送る。 |
| ＊ | ＷＳＤＬ（Web Service Description Language） ・ Webサービスを記述するための、XMLをベースとした言語仕様。 ・ それぞれのWebサービスがどのような機能を持つのか、それを利用するためには どのような要求をすればいいのか、などを記述する方法が定義されている。 |
| ＊ | ＵＤＤＩ（Universal Description, Discovery and Integration） ・ インターネット上に存在するWebサービスの検索・照会システム。 ・ 企業各社がインターネット上で提供しているWeb技術を応用したサービスに関す る情報を集積し、業種や名称、機能、対象、詳細な技術仕様などで検索可能にす る仕組み。 |
◎ebXML
XML技術の標準化団体であるOASISとＥＤＩの国際標準を策定するUN/CEFACTが共同で設立した団体とそこで定める電子商取引に関わる標準仕様。XMLベースのオープンなインフラストラクチャで、参加者すべてに相互運用性があり、セキュリティが保たれ、矛盾のない一貫した方法での電子ビジネスを目指す。データの構造は、ＳＯＡＰをベースとしている。
■ メインフレームとはエミュレータを介して接続 ■
ここまではオープン系システムであることを前提に話を進めてきた。しかし、メインフレームを忘れることはできない。一般にオープン系とメインフレームをネットワークで接続するのは難しい。というのは、オープン系のシステムは常にシステム間を対等につなぐことができるが、メインフレームは自分が親になり相手を子供としてしつなぐしか方法がないのだ。これを解消し接続する機能をエミュレータという。ここでも、メインフレーム系の通信プロトコルとWebサービスを仲介するエミュレータが必要となる。これを通すことにより、すべてのWebサービスは相手を意識することなく全く同じ条件で接続することができるようになる。［図５］
図５ エミュレータを経由したメインフレームとの連携
このＷｅｂサービスは、各アプリケーションから受け取ったメッセージをＷｅｂサービス共通のメッセ－ジに置き換え相手に送り出す、もしくはその反対の流れを実現する機能である。
３.商流と物流をリアルタイムでつなぐ連携事例
■ ２次卸→１次卸→メーカへのリアルタイム発注 ■
ではここで、ｅｂＸＭＬとＷｅｂサービスを使った商流情報と物流情報のリアルタイム連携を実現する業務を想定してみたい。あくまで仮想ではあるが、ツール類さえ整えば実現可能なシステムである。この例は、現在 ある大手１次卸が現行技術で実現している受発注のネットワークを、ｅｂＸＭＬとＷｅｂサービスを用いて物流情報と連携することを仮定して考えてみた。
ここでは、以下のような業務の流れを考えてみたい。
２次卸が取引のある１次卸に資材を発注する。１次卸に在庫があればその場で注文し、なければそこからメーカに発注をかける。あわせてそのサイトから運送状況や請求状況を確認する。［図６］
図６ 商流情報と物流情報のリアルタイム連携 想定事例１
■ ２次卸から見た処理の流れ ■
| ① | ２次卸が、１次卸に発注 ・ １次卸の発注サイトにログインする。 ・ １次卸の在庫を検索。 （発注サーバから在庫サーバに在庫状況をWebサービスで検索） ・ 商品がそろっていればその場で注文。 （Webサービスで、在庫を引き落とし物流サーバに出荷指示） |
| ② | メーカの在庫を検索 ・ １次卸に在庫がなかった場合、メーカの在庫を検索。 （発注サーバからメーカ在庫サーバにebXMLで検索） ・ その在庫を確認しその場で注文。 （１次卸がメーカに対する発注と同時に２次卸が１次卸に対する発注も 成立する） |
| ③ | 運送状況確認 ・ 発注履歴から物流サーバを見に行き運送状況を確認。 （Webサービスで出荷状況を確認した上、ebXMLで運送会社の追跡状況を検索、 結果をWebサービスで発注サーバに反映） |
| ④ | 請求・支払状況を確認 ・ 発注履歴から請求サーバを見に行き請求情報と支払情報を確認。 （Webサービスで当月の購入状況、過去の支払状況を確認） |
これらはあくまで一例だが、ebXML、Webサービス機能があれば比較的簡単にこれらのシステムを構築することができるようになるだろう。
４.実現のための課題
このように、理屈ではバラ色の世界を夢見ることができるが、実際にはまだまだ多くの課題が残っている。それらにも、自社の努力で解決できるものと社会の動きに左右されるものがある。
| ＊ | インターネット関連技術の標準化促進 ・ebXMLもWebサービスもまだまだ完成された標準ではない。発展途上であるため、 そのバージョンが替われば互換性もなくシステムの連続的な発展性がなくなる こともあり得る。 ・似たような標準もいろいろ出てくるため、デファクトが決まらない。 |
| ＊ | インフラの整備 ・ネットワーク環境は、この数年飛躍的向上を遂げている。しかし、ビジネスで 利用するためには、より安定・安心・安価なサービスが求められる。 |
| ＊ | セキュリティに対する認識とサービスの均質化 ・セキュリティポリシーが企業ごとに異なり、複数の企業が関わる場合、同じレベ ルでの合意が取りにくい。 ・異なる認証局から取得した証明書の場合、互いに確認することができないことが ある。このあたりの実運用レベルでの取り決めとサービスの提供を急ぐ必要が ある。 |
| ＊ | パッケージ群の整備 ・まだパッケージが十分出揃っていない。パッケージベンダーも世の中の様子を見 ているレベルなので、十分機能が吟味された製品が出ていない。 |
| ＊ | ベンダーサービスの多様化 ・パッケージベンダーは製品を提供するとサービスを終えるところが多く、実際の ビジネスに即したインプリメントをサポートできない場合が多い。このあたりは ＳＩベンダーの役割に期待されるところが大きい。 ・また、普及拡大に力を尽くすベンダーもまだ少なく、システムができあがっても 十分利用されない場合もある。ここはユーザ企業の意識改革も必要ではないか。 |
| ＊ | 個々の企業の積極的取り組み ・技術の変遷が早く、なかなか自社の業務にうまく取り込むことができていない。 ・システムベンダーとの信頼関係のもと、最新技術の有効な利用方法について積極 的研究を積み重ねていく必要がある。 |
今気づく大きな点だけを述べてみたが、今後も新たな問題や課題が出てくるに違いない。それらを含めて、時代の流れとスピードに流されないよう、かつ負けないよう対応を進めていかなくてはならない。「拙速は危険」という判断もあるが、最近の動きを見ると「あまりに早い社会の変化についていけない企業が取り残されている」という現実を強く感じる。あたかも「ＰＣがどんどん新しくなるので、買い控えをしているうちにＰＣ文化に対応できなくなった」に等しいような気もする。ここは「拙速も重要な判断基準」といえるのではないだろうか。
おわりに
ＸＭＬ関連技術は近年めざましい発展を遂げ、ようやく実運用レベルの話題として取り上げられるようになってきた。一方、旧来のＥＤＩはシステム老朽化と環境変化が相まって非常に使いづらい状況になってきたと思われる。つまり、そろそろ次世代ＥＤＩを視野に入れないと国内・海外との円滑なる電子商取引が実現できなくなると言えなくもない。それを逆手に取ると、他社を出し抜くチャンスともいえるのではないか。本稿が、自社のＥＤＩシステムを見直し、次の一手を考えるきっかけとなれば嬉しい限りである。
以上
【参考文献】
［１］ 菅又久直・森田勝弘『ｅｂＸＭＬ技術解説』
ソフト・リサーチ・センター、２００１年
［２］ ＸＭＬ Consortium『Ｗｅｂサービス委員会議術解説書』
URL：http://www.xmlconsortium.org/websv/kaisetsu/
［３］ 日本アイ・ビー・エム（株）ｊＳｔａｒチーム
『最新Ｗｅｂサービスがわかる』 技術評論社、２００２年
(C)2004 Hiroshi Fujino & Sakata Warehouse, Inc.
