4.1 社内システムとの連携
本節では，インターネットEDIシステムと社内システムを連携するための方法について述べる。
また，本節ではWeb-EDIを除いたファイル転送型インターネットEDI，e-mail型インターネッ
トEDI，及びコラボレーションXML/EDIを想定している。
4.1.1 社内システムおよびインターネット EDI システムの定義
連携の対象となる社内システムとは，各企業に固有の業務アプリケーションを意味するものと し，以下の2種に分類できる。
l ホストやサーバーなどで構成されるバックエンド系システム
l Excelやメールクライアントなどで構成されるフロントエンド系システム
また，インターネットEDIシステムとは，データを送受信するためのシステムを意味するもの とする。システム構成イメージは図 4.1 インターネットEDI システム構成イメージの通りである。
図 4.1 インターネットEDI システム構成イメージ
4.1.2 送信時と受信時における処理内容の違い
データ交換において，データを送信する場合と受信する場合では本質的に自動化の向き不向き といった特性が異なってくる。このため，送信処理と受信処理は非対称な処理形態となることが多 い。
(1) 送信の場合
データを送信する立場では，社内システムに存在するデータを変換して出力することにな り，一般に自動化は容易である。従って，バックエンド系システムとの連携が主体となりや すい。
(2) 受信の場合
データを受信する立場では，社内システムの保守ポリシーなどに影響があるため，受信し たデータを単純な変換などで社内システムに直接取り込むことは一般に困難である。従って フロントエンド系のシステムとの連携，もしくは人間を介在したバックエンド系システムと の連携が主体となりやすい。
4.1.3 技術要件
インターネットEDIシステムと社内システムとの連携にあたっては，いくつか技術的な要件が 社内システム インターネット
EDI システム パートナー
イン ター ネッ ト
ある。主に，何をきっかけとしてデータ交換処理を実行させるかといった分類と，具体的なデータ 転送方式の観点である。
(1) 送受信のトリガー分類
送受信処理を実行するきっかけとなるトリガーは，以下の二通りに分類される。
① イベント・ドリブン型
社内システム側で発生した業務イベントまたは社外からメッセージが届いたというイベ ントをリアルタイムにトリガーとする方法。
② ポーリング型
特定の対象をスケジュールで定期的に監視し，ある条件にマッチした場合にトリガーと する方法。
(2) データ連携の方式
トリガーを発生させてデータ連携を行う具体的な技術要素としては，主として下記のよう なものが考えられる。既存の社内システムとの連携に関わる部分であるため，すでに普及し ている従来型のインタフェースを採用することがほとんどである。具体的には，インターネ
ットEDIシステムと社内システムの両方で共通に利用できるインタフェースの中から選択す
ることになる。
l API呼び出し（イベント・ドリブン型）
l 特定のディレクトリへのファイル書き込み（ポーリング型）
l FTPによるファイルのアップロード（ポーリング型，イベント・ドリブン型）
l データベースへの書き込み（ポーリング型，イベント・ドリブン型）
l 非同期メッセージング・ミドルウェアへのデータ投入（イベント・ドリブン型）
4.1.4 連携の形態
社内システムとの連携にあたって，下記のような形態をとりうる。
(1) フロントエンド系システムとの連携
高度な社内システムを持たない企業がインターネットEDIを導入する場合，即ちそのデー タを必要とするのがごく少人数である場合には，受信したデータを担当者がそのまま Excel などで確認するという方式がよく採られる。また，高度な社内システムを持っている場合で あっても，単純な業務プロセスだけを扱う場合には，バックエンド系システムを介在せずに
Excelなどで直接処理してしまう方が簡単な場合がある。インターネットEDI導入の初期段
階ではこの方式が多い。
(2) 人間が媒介するバックエンド系システムとの連携
送受信するデータが複数の関連部署などで共有されるデータである場合，担当者はバック エンドからデータを抽出して送信処理を行ったり，受信したデータをバックエンドに入力し たりといった作業を求められる。連携にかかる設計・開発の工数はかからないが，転記作業 の増加に伴う負担増やヒューマンエラーの潜在性を考えると長期的にはコストパフォーマン スは悪い。
(3) バックエンド系システムとの自動連携
送受信するデータ量が多い，情報共有の要求が高いなどの場合には，必然的にバックエン
ド系システムとインターネットEDIサーバーをシステムレベルで連携させる方式が採られる。
連携にかかる設計・開発の工数はかかるが，取引量の増加による作業負担の増加を抑えるこ とができるため，長期的にはコストパフォーマンスが良い。
4.2 コードの標準化に関する考察
企業内の情報システムでは，取引する商品や取引先など多くのデータ項目がコード化されてお り，企業内，業界内，あるいは各標準化組織などで多様なコード体系（コードリスト）が定義され ている。異なるコード体系を使用する企業間でインターネット EDIを実施する際には，これらの コード体系の間で，相互の変換が必要となり，情報システムの大きな負担になっている。これらの コード体系が標準化（統一化）され，すべての企業で共有利用されれば，変換の処理を省くことが 出来る。
企業で使用されているコードを大別すると，国（言語）コード，企業コード，及び通貨コード のように「主として参照することを目的に使用されているコード」と，商品（製品）コードのよう に利用する「システムと密接に結合しているコード」がある。
コード体系の標準化はEDI普及促進の上で大変重要なテーマである。インターネットEDIのみ ならず，データの交換および共有に関わる共通の課題であり，標準化の推進と標準の採用が進展す ることが期待される。今後ともコードの標準化に焦点を合わせた取り組みが別途必要である。
以下に，参照系のコードと商品コードについての考察を述べる。
4.2.1 参照系コード
主として参照することを目的として使用されるコードの例としては，国（言語）コード，企業 コード，通貨コード，地名コード，数量単位コード，梱包（荷姿）種別コード，及び建値コード
（INCOTERMS）等がある。「主として参照することを目的に使用されているコード」の多くに ついては，ISO を始め標準化を推進する機関が推奨する標準コードを取り決めている。企業コー ドについてはISOのような国際標準コードは存在しないが，Dun & BradstreetのDUNSナンバ ーやEAN.UCCのGLN（Global Location Number）等は，欧米を中心に良く利用されているし，
日本にも税関の輸出入者コードやCIIの標準企業コードがある。GLN等は企業内の部門や支店等 もコード体系中に含まれている。また，これらの企業コードは ISO 6523 Structure for the identification of organizations and organization parts （UN/EDIFACTディレクトリにおいて はIdentification code qualifier）によって国際的に標準化された識別コードが付与されており，ど のコード体系を採用しても，一意性が保障される仕組みが確立している。
従って企業がEDIを実装する場合には，これらの標準コードを積極的に活用すべきであり，企 業内の情報システムが標準コードに対応（変換）することはそう難しいことではないと思われる。
現状における，企業間でのデータ交換では，異なるコード体系が存在することを前提に，混乱 なくデータをやり取りするために，コード値とコード体系の識別を併せて交換することが一般的で ある。以下に，異なるコード体系が複数存在する場合の対策方法として2つの例を紹介する。
(1) UN/EDIFACTでの対応例
EDIの国際標準であるUN/EDIFACTでは，異なるコード体系が複数存在することに対し て，コードを表すデータエレメントにはコード値だけでなく，そのコードの管理機関を表す
識別を付加することで，データを交換した際の混乱を防ぐ方策が採られている。
たとえば，国コードはISOで標準化されているが，各国内の地方自治体（サブエンティテ ィ）のコードはその国ごとにコード体系が決められている。そのためEDIFACTでは，
図 4.2 UN/EDIFACT におけるコード指 定例のように，単に地方自治体のコード値だけを交 換するのではなく，コードリストの識別，コードの管理機関の識別の付加を可能とすること で，データ交換に際しての混乱を防いでいる。
C819 COUNTRY SUB‑ENTITY DETAILS C 1
3229 Country sub‑entity name code C an..9 1131 Code list identification code C an..17 3055 Code list responsible agency code C an..3 3228 Country sub‑entity name C an..70
（上記の文字列の説明）
・ 本文字列は，UN/EDIFACT 仕様書の「複合データ要素」の仕様の一部である。
・ 「COUNTRY SUB-ENTITY DETAIL」は，複合データ要素（Composite Data Element，データ要素タグは「C」で始ま る）であり，次行からの 4 種のデータ要素（データ要素タグは数字で始まる）から構成される。EDI 電文インスタンス としては，これらの情報がセット（本例では 5 種のデータ要素）で指定される。
・ 「Country sub-entity name code」は，地方自治体のコード。
・ 「Code list identification code」は，上記の地方自治体コードを定義しているコードリストの識別コード。
・ 「Code list responsible agency code」は，上記の地方自治体コードリストの維持管理責任者コード。
・ 「Country sub-entity name」は，地方自治体の名称。
・ 各行の先頭の，「C819」〜「3228」は，EDIFACT のデータ要素タグ。
・ 右側の「C」は Conditional の略称であり条件付項目であること（必須項目ではないこと）を示す。
・ 「an..9」等は Alpha Numeric 9 桁を示す。
・
図 4.2 UN/EDIFACT におけるコード指 定例
(2) ebXMLでの対応例
一方，ebXML の「コア構成要素技術仕様」に定義された，コア構成要素タイプの中で，
コードを表すデータの型である「Code. Type」には，図 4.3 ebXML コア構成要素仕様におけ るコード指定例のような構成要素を含めることが出来るように規定されようとしている。