1

全銀 TCP/IP手順［拡張仕様］

（拡張 Z手順）による

EDI と社内ファイル転送の統合

〔前編〕

ビジネスコミュニケーション掲載記事 1998年No.10号

藤野裕司

企業における社内ネットワークは、この数年大きな変革の中にあると言っていいだろう。

LAN の普及に始まり、インターネット技術の導入、それに伴う通信プロトコルの TCP/IP化

と、情報システム部門は矢継ぎ早に手を打ってきた。一方、企業間ネットワークはというと、

1980年 JCA手順、1983年全銀手順の発表以来ずっとこの手順を使っている。つまり、社

内は国際標準ともいえるTCP/IPへの統一が進むなか、企業間は旧来からのBSC（2進同

期通信）をベースとした全銀/JCA手順に頼り続けてきたことになる。

しかし、今この流れが変わろうとしている。1997 年 3 月全銀 TCP/IP 手順が制定され、

同 5 月その拡張仕様（拡張 Z 手順）が発表された。この意味するところは非常に大きい。

企業内・企業間を問わず、通信プロトコルは TCP/IPに統一可能になったということだ。

蝶理情報システムは、1983 年全銀/JCA 手順を搭載した多目的データ交換システム

DEX-Ⅱを発売以来、EDI（Electronic Data Interchange）の普及に努めてきた。しかし、本

来の目的はそれのみではない。1985 年以降 DEX-Ⅱには、3270FTP，3740，3770，3780，

LU0 と社内ファイル転送用のプロトコルを次々と搭載し、マルチプロトコルによる企業間デ

ータ交換と社内ファイル転送の統合を目指している。そして今、DEX-Ⅱへの全銀ＴＣＰ手

順（拡張 Z 手順準拠）搭載、およびＰＣ・ＰＣサーバ・UNIX 対応の全銀ＴＣＰ通信プログラ

ム（拡張 Z 手順準拠）発売と、企業間ネットワークと社内ネットワークの統合に向けて必要

な要素をすべてそろえることが可能となった。メインフレームからＰＣまで、すべてのプラッ

トフォームでネットワーク統合のソリューションを提供できるのは、中立的なサードベンダー

では当社だけである。これら製品群とＥＣ/EDI で培った多様なノウハウで、企業のネットワ

ークに対する最適なソリューションを提案していきたい。

本編は、前後２回に分けて次のような構成になっている。

【前編】

・ネットワーク統合の流れと全銀 TCP/IP手順［拡張仕様］の登場。

・当社製品 DEX-Ⅱ、全銀ＴＣＰ通信プログラムの機能と特長

【後編】

・具体的な導入のポイントと適用事例

2

通信プロトコルを TCP/IPに統一

コンピュータが世に現れオンラインが始まって以来、企業は様々なネットワークを持つように

なってきた。その種類は通信プロトコルによって大きくは 3つに分けられる。

① xNA のメインフレーマ系のオンラインネットワーク

xNA とは、SNA，FNA，HNA，DINA で代表される、リアルタイム系オンラインネットワークであ

る。

② TCP/IP による社内 LAN/WAN ネットワーク

これは、インターネットの普及とともに通信プロトコルの国際標準となってきている。

③ 全銀/JCA手順による企業間データ交換ネットワーク

国内 EDIの標準通信プロトコルとして長い歴史を持ち、アプリケーションもほぼこの手順をもと

に作られている。

これらのネットワークは、互いに資源を共有できない。しかも運用はすべて異なる。回線費

用、ハードウェアコストなどはネットワークごとに必要で、しかも、おのおの管理方法が異なり、

技術習得が難しい。また、相互に接続が不可能となっており、TCP/IP以外はいわゆるオープ

ンなネットワークにならない。

インターネットの普及とともに、「TCP/IP が通信プロトコルの標準」ということは、誰もが認め

ることとなった。そこで、企業は前述①のオンラインネットワークをゲートウェイ（通信プロトコル

変換装置）を経由して、②TCP/IPのLAN/WANネットワークに統合しようとしている。現に多く

の企業でこの動きは進んでおり、大手企業においてはほぼ統合化は終わったとみることがで

きるだろう。しかし、③の全銀/JCA 手順による企業間データ交換ネットワークは、古い手順の

まま残り続けている。つまり、TCP/IPへの統合から取り残された状況となっているのだ。

全銀／ＪＣＡ手順の企業間ネットワーク

メインフレーム

ＴＣＰ／ＩＰのＬＡＮ／ＷＡＮネットワーク

ｲｰｻﾈｯﾄ

公衆電話網ＩＳＤＮ網

アプリケーションサーバ ＯＡサーバ

通信制御装置

IBM 3X74

ｲｰｻﾈｯﾄ

ＯＡサーバ

ｘＮＡのオンラインネットワーク

専用線

図１ 企業が持つ３種類のネットワーク

3

ネットワークを統合する新 EDI通信プロトコルの登場

全銀手順は、1983年に制定されてから 15年間、流通業界で広く使われている JCA手

順と並び、企業間データ交換手順の日本標準として長く使われ続けてきた。しかし、

TCP/IP が通信プロトコルの標準として定着しているため、これら企業間のネットワークも

TCP/IPに吸収しようと新しい EDI通信プロトコルが開発された。それが、1997年 3月に全

銀協（全国銀行協会連合会）が傘下銀行の企業・銀行相互間のオンラインデータ交換に

おいて使用するために制定した「全銀協標準通信プロトコル－TCP/IP手順（Ver．1）通称

「全銀 TCP/IP手順」である。

ところが、全銀手順を使うのは金融業界ばかりではない。そこで、(財)日本情報処理開

発協会(JIPDEC)産業情報化推進センター(CII)が中心となって、金融業界のみならず全

産業で利用可能なように拡張し、1997年 5月に全銀 TCP/IP手順［拡張仕様］（拡張 Z手

順）として発表されるに至った。これにより、企業が持つネットワークは、すべて TCP/IP に

統一することができ、企業内・企業間の商取引のプロセスを一元的にコントロールすること

ができるようになったのである。

全銀 TCP/IP手順［拡張仕様］（拡張 Z手順）の特徴

この手順には次の 5点の特徴がある。

① 企業間ネットワークと社内 LAN/WAN ネットワークを統合

これが最大の特徴で、前述の通り企業のネットワークを TCP/IP に集約し、イントラネット/

エクストラネットの基盤を作ることができる。

② アプリケーションインターフェイスは、現行全銀ベーシック手順と完全互換。

これにより、通信システムを入れ替えるだけで既存のアプリケーションに全く影響を与える

ことなく、新システムに移行することができる。

③ 安価な非同期式全二重モデムを使用し、高速データ交換を実現

全銀ベーシック手順は、BSC であるため同期式半二重モデムが必要であった。このモデ

ムは高価な上に 2400bps という非常に低い速度でしか通信できない。一方、非同期式全

二重モデムは、安価で最大 56kbps という高速通信が実現できる。さらにインターネットや

パソコン通信とも共用が可能となり、一石 3鳥のメリットがでる。

④ プログラムモジュールや 2Kバイトを超える（最大 32,687 バイト）レコードの伝送

も可能。

これは［拡張仕様］の機能で、従来扱うことができなかった長大なレコードやプログラムモ

ジュール・CAD/CAMデータ・マルチメディアファイルなどのデータ交換が可能となる。

⑤ 目的限定の非常にシンプルなプロトコル

データ交換という限定された用途であるため、非常にシンプルなプロトコルとなっている。

よって、設定を必要とするパラメータも少なく、導入レベルでの障害も非常に少ない。また、

運用時の障害発生要因も少ない。

EDIは拡張 Z手順に順次移行

全銀TCP/IP手順というと、どうも金融関係中心と思われがちだが、これは大きな誤解で

ある。確かに全銀ベーシック手順（全銀手順）と同様、全銀協が制定したプロトコルだ。し

4

かし、全銀手順は、実際ほぼすべての業界で使われており、この全銀 TCP/IP手順とて金

融業界に限る制約など一切ない。まして、［拡張仕様］は全産業を対象としており、業界に

依存していない。開発した産業情報化推進センターも、そこを配慮して「拡張 Z手順」と呼

んでいる。今後これが日本の EDI 用標準通信プロトコルとなるといっても間違いはないだ

ろう。

では、この手順を利用するためにはどのように移行すればよいか。基本的には、通信部

分のみの入れ替えであるが、接続先にも同手順が必要になる。先方の協力なくしては実

現できない。移行のメリットを十分説明し、理解を仰ぐところからすべてが始まる。

作業としては、システム導入とパラメータ類の設定変更が中心となる。全銀手順からの

移行の場合、アプリケーションのインターフェイスが同じであるため、それほど大きな変更

にはならないだろう。JCA 手順といえども、パラメータの対応付け変更（図 2）でこの全銀

TCP/IP手順に移行ができる。

ただし、ＰＣなどに見られるようなアプリケーション組込型通信ソフトの場合には、通信部

分が切り離せない場合があり、注意が必要である。

その他、拡張Z手順利用の手引き書として産業情報化推進センターより「拡張Z手順利

用ガイド」（平成 10年 3月）が発行されている。導入検討時にはきっと役に立つはずだ。

すでに、このメリットを知った企業から順次移行が始まった。日本の EDI が拡張 Z 手順

中心となるのも、そう遠い日ではないような気がする。

社内ファイル転送も拡張 Z手順で

ここまでの話で、拡張 Z 手順は EDI 専用のプロトコルと思われた方もいるだろう。

これも誤解である。このプロトコルは、社内ファイル転送にも大いに威力を発揮する。

これまでファイル転送というと、3270、6680、560 などのメインフレーム系エミュレータ、も

しくはＲＪＥ、ＦＴＰを使うのが主だった。これらの場合には、ファイルの送達確認やエラー状

況が確認しにくいうえ、データもファイル名そのもので管理しなくてはならない。しかも、そ

の管理システムについては、ユーザが自分で開発しなければならなかった。

拡張 Z 手順はプロトコルの中に詳細なエラー情報を持っているほか、二重交換防止機

通信システムのパラメータ設定変更にて移行は可能。

■■ JJCCAA手手順順 •• セセンンタターーココーードド（（６６桁桁））

•• スステテーーシショョンンココーードド（（８８桁桁））

•• 識識別別子子（（６６桁桁））

•• デデーータタ種種類類（（２２桁桁））

■■ 全全銀銀TTCCPP//IIPP手手順順

•• 相相手手セセンンタターー確確認認ココーードド

（（HHeexx７７桁桁＝＝数数字字１１４４桁桁））

•• 当当方方セセンンタターー確確認認ココーードド

（（HHeexx７７桁桁＝＝数数字字１１４４桁桁））

•• パパススワワーードド（（６６桁桁））

•• フファァイイルル名名（（１１２２桁桁））

•• フファァイイルルアアククセセススｷｷｰー（（６６桁桁））

■■ 移移行行方方法法 •• セセンンタターーココーードド、、スステテーーシショョンンココーードドはは、、通通常常ゾゾーーンン１１００進進がが使使用用さされれてていいるる。。ここのの場場合合はは、、単単純純にに

HHeexxにに直直しし、、セセンンタターー確確認認ココーードドににセセッットト。。数数字字以以外外をを使使用用のの場場合合、、再再度度取取りり決決めめがが必必要要。。

•• パパススワワーードドはは、、新新規規にに取取りり決決めめるる。。使使用用ししななくくててもも可可。。

•• 他他はは、、文文字字左左詰詰めめででセセッットト。。

図２ ＪＣＡ手順からの移行

5

能、相手先情報、データ種別情報等も持っている。つまり、これらの機能を駆使することの

できるデータ交換システムがあれば、社内ファイル転送といえども、EDIと同等の管理が可

能になるわけだ。

企業間・社内をシームレスに統合するデータ交換システム

DEX-Ⅱと全銀ＴＣＰ通信プログラム

今後、EDI はますますの普及を見せるだろう。同時に、社内のクライアント/サーバシス

テムも、どんどんアプリケーションが増え、メインフレームとサーバ間、サーバとサーバ間の

データのやりとりが多くなってくる。当然ながら企業間取引のデータもその中に含まれる。

このように、これからのＥＣ/EDIでは、企業間・社内の区別がなくなり、情報はコンピュー

タ間を自在に行き来するようになる。もちろん、その間の通信手順は、拡張 Z手順だ。

そこで、企業にとって最も重要なことは、この広範なネットワークを統合するために、どの

ようなデータ交換システムを導入するかではないだろうか。その条件を考えてみる。

１．膨大なアプリケーションを自在に連携させることができ、かつすべての業務が完全自動

運転できる。

２．必要な機能はすべてパッケージ化されており、ユーザはデータを作るのみ。

３．導入・運用が容易で、特別な教育を必要としない。

４．既存のオンラインやデータベースに依存したり、影響を与えたりすることなく、完全独立

運用ができる。

５．メインフレームからＰＣまで、すべてのプラットフォームで、統一された運用ができる。

これらの条件を満たすことのできる製品群が、メインフレーム用の多目的データ交換シス

テム DEX-Ⅱと、UNIX・ＰＣサーバ・ＰＣ用の全銀ＴＣＰ通信プログラムである。以下、その

製品構成と機能について説明する。

【メインフレーム】

・製品名：多目的データ交換システム DEX-Ⅱ

・対応ＯＳ：ＩＢＭ/ＭＶＳ・ＯＳ390

富士通/ＭＳＰ

【ＵＮＩＸ】

・製品名：全銀ＴＣＰ通信プログラム ＵＮＩＸ版

・対応機種：ＳＵＮ、ＨＰ、ＩＢＭ、

ＮＥＣ、他ＵＮＩＸ機全般

【ＰＣサーバ】

・製品名：全銀ＴＣＰ通信プログラム サーバ版

・対応ＯＳ：Windows NT Server（Intel版）

【ＰＣ】

・製品名：全銀ＴＣＰ通信プログラム クライアント版

・対応ＯＳ：Windows95、98

Windows NT Workstation（Intel版）

6

製品共通の機能と特長

（１）データ交換機能

企業の内外を問わず、複数のシステム間でデータ交換を行うことができる。通信相手は、

同製品である必要はなく、全銀 TCP/IP 手順を搭載した他ベンダー製品でも接続が可能

（本製品は、財団法人日本情報処理開発協会 産業情報化推進センター発行の拡張 Z

手順相互運用性確認試験実施済み証明書を取得している）。

起動局・応答局両機能をサポート。クライアント版でも着信受付によるデータ交換の起

動ができる。

緻密な障害管理機能を持ち、エラー発生時には自動的にリトライ・リカバリーを行う。

クライアント版以外は、複数相手先との同時接続が可能で、ＶＡＮ相当の機能を持つ。

（２）集配信管理機能

相手先、データ種別、パスワードといったキーでデータをハンドリングできるため、集信

データを相手先別や業務別に振り分けて後続アプリケーションに渡したり、アプリケーショ

ンから受け取ったデータを相手先別・業務別にとりまとめ配信するなど、高度な集配信管

理機能を持つ。また、同じ相手先から同じデータを複数回受け取っても、個々のデータは

ユニークなものとして管理し、二重交換や重複使用、書き換えなどのミスを防止するような

配慮がなされている。

（３）スケジュール管理機能

年月日、曜日、時刻や、先行アプリケーションの終了、送受信の終了など、様々な条件

をきっかけとして、次の送受信や後続業務の起動を行うことができる。送受信をきっかけに

する場合、その通信結果が正常な場合と異常な場合で後続処理を分けることも可能。こ

れら条件の複合指定もでき、データ交換業務以外の一般業務を含めて完全自動運転が

可能となる。

（４）運用管理機能

メインフレーム

ＴＣＰ／ＩＰのＬＡＮ／ＷＡＮネットワーク

ｲｰｻﾈｯﾄ

アプリケーションザーバ

通信制御装置

IBM 3X74

ｲｰｻﾈｯﾄ

ＥＤＩサーバ

専用線

ＶＡＮ

ＬＡＮ制御装置 公衆電話網ＩＳＤＮ網

ＤＥＸ－Ⅱ

全銀ＴＣＰ 通信プログラム 全銀ＴＣＰ

通信プログラム

全銀ＴＣＰ／ＩＰ手順による社内各種サーバとのデータ交換

全銀／ＪＣＡ、全銀ＴＣＰ／ＩＰ手順による企業対企業のＥＤＩ

既存の3270、RJE端末による、企業内拠点間のファイル転送

図３ システム構成

7

見やすい画面で、通信の実行記録・伝送状況・スケジュールの照会、処理の指示など、

システムの制御・稼働監視を行うことができる。

製品別の機能と特長

各項タイトルの下の［ ］内がその機能の該当するシステムである。全銀ＴＣＰ通信プログ

ラムについては、［全銀ＴＣＰ］と略す。

（１）マルチプロトコル対応

通信プロトコルは、拡張 Z 手順以外に、全銀/JCA 手順、3270FTP、3740、3770、3780

手順を持ち、多様な相手とのデータ交換を一元管理することができる。通信とデータ管理

に依存関係はなく、ファイルは任意のプロトコルで送受信が可能。

（２）完全独立・省資源設計

オンラインＤＣ/ＤＢシステムを前提とせず、他システムから完全に独立しているため、導

入にあたってのシステム変更を最小限に押さえることができ、運用や管理も容易。また、Ｖ

ＴＡＭ/ＢＴＡＭとの直接Ｉ/Ｏによる効率的な通信を実現しているため、非常に少ない資源

で安定的に稼働。

（３）高い親和性

Ａ－ＡＵＴＯ、ＣＡ7 などの市販のスケジュールソフトとの連携も可能で、より強力な自動

運転ができる。

（４）豊富な導入実績

国内 165社、198システム（1998年 8月現在）の導入実績を持ち、ほぼ全業種・業界を

カバーしている。また、大手ＶＡＮ会社の基幹エンジンとしても採用されており、高い信頼

を得ている。

（５）ＡＰＩを提供

ＡＰＩを利用して、運用形態に応じたアプリケーションの作成が可能。

（６）多彩なコード変換機能

「ＥＢＣＤＩＣ」「ＥＢＣＤＩＫ」「ＩＢＭ漢字コード」「ＪＥＦ漢字コード」「ＫＥＩＳ漢字コード」など

のコード変換機能をサポート。

（７）ファイル転送エージェント機能

その場で簡単にファイル転送を行うエージェント機能を持つ。画面からの即時処理に向

いている。プログラムから呼び出すことも可能で、ＡＰＩを使う複雑なコーディングも不要。

このように、拡張 Z手順の導入により、企業のネットワークは格段にシンプルかつ効率の

よいものとなることはご理解いただけただろう。次回は、具体的に導入する場合のアプリケ

ーション構造と適用事例について解説を進める。

8

全銀 TCP/IP手順［拡張仕様］

（拡張 Z手順）による

EDI と社内ファイル転送の統合

〔後編〕

ビジネスコミュニケーション掲載記事 1998年No.11号

藤野裕司

前編では、「ネットワーク統合の流れと拡張Ｚ手順のメリット」ならびに「当社製品

DEX-Ⅱ、全銀 TCP通信プログラムの機能と特長」について述べた。後編となる今回は、

「近次世代の EDIシステムとアプリケーションの構造」そして、当社製品を使って「

システムを構築するポイントと適用事例」について解説を進めたい。

近次世代の EDIはオープンネットワークで

従来の EDIシステムは、メインフレーム中心に作られてきた。クライアントサー

バシステムもかなり普及してきているが、スタンドアロン型システムが中心で、基

幹系アプリケーションがサーバで運用され、メインフレームと緊密な連携を持つシ

ステムは、そう多くは見られない。社内分散システムでもメインフレーム側とのデ

ータ授受は、限定された範囲でファイル転送が行われている。つまり、企業間の EDI

と社内ファイル転送は、完全に分離され運用されているのだ（図 1）。

しかし、企業間・社内のネットワークは、前編で述べたようにオープンに接続す

る準備はできた。図 2をご覧いただきたい。 図１ メインフレームによる集中処理

★企業間取引 ・契約 ・物流 ・在庫 ・商談 ・請求 ・販促 ・受発注 ・支払い ★銀行企業間取引 ・振込入金通知 ・残高通知 ・入出金取引明細・総合振込 etc.

企業間データ交換と 社内ファイル転送が

完全分離

全銀／ＪＣＡ手順

★社内業務 ・人事システム ・営業システム ・販売管理システム

図 1 メインフレームによる集中処理

9

この例は、近次世代 EDIネットワークとして紹介するが、特別に新しいものでも

何でもない。今すぐにでもできそうなネットワークなのだ。

1)発注者は、メインフレームにある在庫情報をリアルタイムで照会し、

引き落としをかける。同時に、受注者に注文情報を送る。

2)受注者は在庫確認、出荷指図を行い、発注者に注文回答を送る。物流

サーバでは、荷揃えを終えた後、事前出荷通知を発注者側物流サーバ

に送る。

3)発注者側物流サーバでは、事前出荷通知を受け、入荷を待つ。入荷後、

発注サーバに入荷報告を送る。発注サーバは注文内容と照合し、経理

サーバに支払い依頼、受注サーバに入荷報告を送る。

4)受注サーバは、発注サーバからの入荷報告に従い、経理サーバに売上

情報を送る。経理サーバは売上処理とともに発注者側経理サーバに請

求情報を送る。

5)発注者は、受注者からの請求情報と発注サーバからの支払依頼を照合

の上、銀行に振込依頼を送る。

6)取引銀行間で振り込み処理が行われ、受注者には入金情報が送られる。

このように、基幹系業務もメインフレーム集中処理に限ることなく、必要に応じ

てメインフレームとサーバで処理を分散し、互いに緊密な連携を取るようになる。

企業間・社内がシームレスになった典型的なパターンといえよう。

なぜ、企業間・社内のネットワークが統合できなかったのだろう？

しかし、このようにごく当たり前のようなシステムを、どうして構築すること

メインフレーム （契約・商談）

メインフレーム （契約・商談・在庫）

発注サーバ （発注） 受注サーバ

（受注）

物流サーバ （入荷） 物流サーバ

（出荷）

経理サーバ （支払い） 経理サーバ

（請求）

取引銀行

発注者 受注者

取引銀行

企業間データ 交換

社内ファイル 転送

社内ファイル 転送

1)②

1)①

2)④

2)①

2)②

3)②

3)① 2)②

2)③ 3)③

4)①

4)②

5) 6)① 6)②

図 2 近似世代の EDI ネットワーク

10

ができなかったのだろうか。

大きな理由として、拡張Ｚ手順のような TCP/IP 環境で稼働する EDI 通信プロト

コルがなかったことがあげあられる。しかし、それ以上の理由として、異なるサイ

トでアプリケーションを緊密に連携し、自在にデータ交換を行うことのできるパッ

ケージシステムがなかったこと。つまり、このようなシステムを構築しようにも、

その手段がなかったことが最大の要因であろう。

DEX-Ⅱ・全銀 TCP通信プログラムによりネットワーク上のアプリケーションを緊密連携 !!

ここで、DEX-Ⅱ・全銀 TCP通信プログラムの機能を思い出していただきたい。

前編「機能と特長」で述べたとおり、これらの製品は共通にデータ交換機能・集

配信管理機能・スケジュール管理機能・運用管理機能を持つ。これらの各機能と製

品が稼働するプラットフォームの関係を図で表すと図 3のようになる。

運用管理機能

スケジュール管理機能

データ交換機能

集配信管理機能

ＴＣＰ／ＩＰ

ＯＳ（ＭＶＳ、ＭＳＰ）

ＤＥＸ－Ⅱ

運用管理機能

スケジュール管理機能 データ交換機能

集配信管理機能

ＴＣＰ／ＩＰ

ＯＳ（ＵＮＩＸ）

全銀ＴＣＰ通信プログラム

ＵＮＩＸ版

運用管理機能

スケジュール管理機能 データ交換機能

集配信管理機能

ＴＣＰ／ＩＰ

AP1

AP2運用管理機能

スケジュール管理機能

データ交換機能

集配信管理機能

ＴＣＰ／ＩＰ

AP1

AP2

全銀ＴＣＰ通信プログラム

サーバ版全銀ＴＣＰ通信プログラム

クライアント版

ＯＳ（Windows NT Sv） ＯＳ（Windows NT Ws,95,98 ）

メインフレーム ＵＮＩＸ ＰＣサーバ ＰＣ

AP1AP2 AP1

AP2

図3 異なるプラットフォーム間でのアプリケーション連携

この図でわかるように、ユーザが開発するのは、純粋にデータを作成するアプリ

ケーションプログラムだけである。その他のプログラム間連携、データの振分け・

とりまとめ、業務の自動化、障害時のデータ復元まで、すべてパッケージが行う。

ユーザは、開発の労力を本来の業務プログラム部分に集中することができるのだ。

これにより、開発工数を大幅に軽減できることは間違いない。

また、従来これらのプログラムやデータの連携は、各業務システム内で行ってい

た。その場合、当然ながら各プログラム間のデータがどのような状態にあるか、他

システムとやりとりするデータの送受信状況がどうなっているかなど、横の関係は

一切知ることができない。しかし、これらをパッケージが統括管理するので、詳細

なデータ交換状況、ひいてはシステム全体の稼働状況なども管理することが可能と

なる。

このように、メインフレームから UNIX，PCサーバ，PCまで一貫したシステム連

携が可能になり、拡張 Z手順という新 EDI標準通信プロトコルを搭載したパッケー

ジシステムは、他に類を見ない。これにより、システム部門の開発と運用の負荷は、

大いに軽減されるのではないだろうか。

11

適用事例

では、実際にこれらのパッケージを使った事例を紹介してみたい。具体的に導入

が進みつつある例もあるが、当社が考える新しい使い方についてもあわせて提案し

てみよう。

(1) 製造業における EDI関連業務の効率化とグループ内 EDI 化の促進（図 4）

大手セットアップメーカと部品メーカ間での企業グループ内受発注システム

製造業では、EDI 受発注における 1 回のデータ送受信量が多い。従来の 2400bps

全銀手順では、データ交換に長時間を要してしまう。これを拡張 Z手順にすること

により、通信速度を 64kbps にアップ。通信に要する時間を大幅に短縮することが

可能となった。その結果、一連のアプリケーション実行時間が短くなり、全体的な

業務の効率化を実現することができた。

また、通信ソフトが安価であり、かつ従来の専用同期通信ボードが不要であるた

め、全体のシステム価格を低く抑えることができた。それにより、これまで導入に

踏み切れなかった小規模な企業にも普及を促すことが可能となり、企業グループ全

体の EDI化を一段と押し進めることとなった。

(2)流通業におけるＪＣＡ手順からの移行

小売―卸間のデータ交換を拡張 Z手順により高速化

流通 EDIの中心となる小売－卸間は、従来ＪＣＡ手順が中心とされてきた。近年

Ｈ手順も利用されるようになったが、これに加え拡張 Z手順を採用することにより、

より安価に軽いシステムで高速化対応が可能となる。流通 EDIは、多頻度・短リー

ドタイムの受発注を可能にするシステムが前提となる。そのシステムを構築するの

大手セットアップ メーカ

大手部品メーカ

中小部品メーカ

大型部品の 受発注・納期回答 標準納品書

小型部品の 受発注・納期回答 標準納品書

図 4 製造業におけるEDI関連業務の効率化とグループ内EDIの促進

12

に、多額の出費は中小企業にとって大きな負担である。その点、当社製品群は、高

機能・低価格で実現できる有効なツールとなるだろう。

(3)製薬会社と病院間における臨床検査データの集配信（図 5）

病院から各種検査依頼を受け、検査結果をセンター起動で配信する

製薬会社では、病院から依頼される様々な検査を行っている。それにより、検査

依頼を病院から受け、その処理結果を病院に返すという業務が発生する。従来は、

これをＦＡＸで行っていたが、量・頻度ともに多く、作業が繁雑なため、自動化す

ることとなった。

日々発生する検査依頼データをセンターで受信し、検査結果はセンター起動で病

院側に配信する。同社では、この大量多頻度処理を DEX-Ⅱ・全銀 TCP通信プログラ

ムを使い大きな成果を上げた。

ＩＳＤＮ

ＰＳＴＮ

Modem ＩＮＳネット １５００

研究所

センター

1.5 Ｍ 専用線

ＩＢＭ９６７２

全銀ＴＣＰ

通信プログラム

フレームリレー

支社

研究所

６４Ｋ

TA 64 K

病院

ＤＥＸ－Ⅱ

図５ 製薬会社と病院間における臨床検査データの集配信

13

(4)WebEDIによる電子商取引情報を基幹システムに反映（図 6）

今後爆発的に普及するＷｅｂEDIでも、既存システムとの連携は必須!!

ＷｅｂEDIにより、インターネットもしくはセキュア IPネットワーク経由で注文を

受けるシステムが注目を集めている。しかし、通常受発注システムは既にメインフ

レームで稼働している。よって、Ｗｅｂサーバに集まったデータを基幹システムに

つなぐ必要がある。また、端末側にアプリケーションを持つ場合には、サーバより

データを送る必要がある。このような場合などには、拡張 Z手順が最も有効である。

(5)ＰOS端末・バーコードスキャナへの応用（図 7）

ＰＯＳ端末・バーコードスキャナのデータをサーバに集め、メインフレーム・他サ

ーバのアプリケーションに連携させる。

ＴＣＰ／ＩＰの ＬＡＮ／ＷＡＮネットワーク

インターネット

ＷｅｂＥＤＩ 受発注サーバ

ファイア ウォール

商品カタログ 情報

メインフレーム

Ｗｅｂブラウザと 全銀ＴＣＰ

通信プログラム Ｗｅｂ参照

と入力 データ交換

顧客端末

図 6 WebEDI による電子商取引情報を基幹システムに反映

ＴＣＰ／ＩＰの ＬＡＮ／ＷＡＮネットワーク

ＰＯＳ端末

スキャナコントローラ

ＰＯＳコントローラ

バーコードスキャナ

店舗

倉庫

アプリケーションサーバ

メインフレーム 基幹システム

本部

図 7 POS 端末・バーコードスキャナへの応用

14

現在、ＰOS端末・バーコードスキャナは、ＬＡＮ上のコントローラとメーカ独自

の通信プロトコルもしくはＦＴＰでつながれている。この場合、他サーバのアプリ

ケーションとは連携を取ることができない。

しかし、POS 端末・バーコードスキャナとコントローラ、コントローラとアプリ

ケーションサーバ、アプリケーションサーバとメインフレーム、これらを拡張 Z手

順で接続すると、その間のすべてのアプリケーションが自在に連携を取ることが可

能となる。

(6)ハンディターミナル・FAX電話端末への応用（図 8）

WindowsＣＥ搭載のハンディターミナルやＦＡＸ電話端末を使い、安価な電子商取

引システムを構築。

�h �r �c �m

�e �̀�w �E �d �b�[ ���A �v ���P �[ �V �����T �[ �o

�n ���f �B �̂�[ �~ �i ��

�o �b���C ���t ���[ ���î �² �V �X �e ��

���o �C ���o �b

図８ ハンディターミナル・FAX電話端末への応用

現在独自 OSのハンディターミナルや FAX電話機も、今後は OSに WindowsCEが搭

載されるようになるだろう。そうなると軽いアプリケーションが実行できるため、

安価な EC/EDIシステムを端末側で動かすことができる。

それにより、パソコンが設置できないような小さな商店でも、電子商取引が可能

になる。たとえば、宅配便の取扱店までのトラッキングシステム。小さな町の小売

店、飲食店の商品・食材の発注等には威力を発揮するだろう。

このように、DEX-Ⅱ・全銀 TCP通信プログラムは、限りない可能性を秘めてい

る。当社としては、様々なユーザ様の声を聞きそれを製品機能に反映させるととも

に、幅広い業種・業態での利用形態を提案していきたい。