16-E001

平成 16 年度 企業間情報化に関する調査研究

中小企業にも適用可能な
インターネット EDI 設計・導入ガイド

平成 17 年 3 月

財団法人日本情報処理開発協会

電子商取引推進センター
協力:電子商取引推進協議会

この報告書は，（財）日本情報処理開発協会電子商取引推進センターが競輪の補助金を受けて，電子商取引推進協議会（ECOM）の協力を得て実施した事業の成果を取りまとめたものです。

はじめに企業の経営効率化を実現するためには，
企業活動のあらゆる局面でコンピュータ等を利活用した業務の効率化が不可欠であります。商取引に係わる業務では，従来，電話，郵送，FAX の人手を介した取引が行われていましたが，業務の効率化の観点から，企業間でコンピュータネットワークを構築し電子的に商取引を実現することで大幅な業務改善が図られることになります。
このような取組みは EDI と呼ばれ，既に 1980 年代から取組みが始まりました。当初は，このような取組みは特定 2 社間で始まり，EDI 実現のためにはシステム要件として専用線やサーバーを必要とするなど多大なコストを必要とするものであり，大企業を中心に活用されました。その後，取引企業の拡大を目指し，業界単位での標準構築，適用業務の拡大に向けた取組みが進められています。
しかしながら，中小企業における EDI の導入・活用は低い実態があります。2003 年度に電子商取引推進協議会（ECOM）で実施した「中小企業における EC 実態調査」によると，中小企業の視点
からは，伝票やデータフォーマットが業界・企業毎に異なっている，EDI の導入費・運用費が高い等の問題点から，EDI 実施率（利用率）は非常に低い状況です。
ECOM では，中小企業を含めて EDI の導入・活用を促進する観点から 2003 年度より次世代の EDI
システムを調査研究し，昨年度，今後の EDI 促進策として「インターネット EDI 促進調査研究報告書―インターネット EDI の実態と今後の EDI 促進策の提言―」を纏めました。
2004 年度は，引き続き「中小企業 EC/EDI 普及 SWG」において，標準化と実用化の観点から中小企業でも導入可能な EDI システムを調査研究し，「中小企業にも適用可能なインターネット EDI 設計・
導入ガイド」として纏めました。インターネット EDI システムの導入を検討している各企業，業界の皆様に参照され，産業界における EDI の進展に寄与できれば幸いです。
本設計・導入ガイドの作成に当たっては，EDI システムを導入している企業・業界の方々及びソフトウェア製品を提供している IT ベンダーの方々のご協力を得て作成しました。（社）電子情
報技術産業協会（JEITA），（社）首都圏産業活性化協会（TAMA 協会），（社）日本工作機械工業会，及び（社）日本建設機械工業会の方々から各種情報をご提供頂きました。
関係者各位のご理解・ご協力に対して厚く御礼申し上げます。

本設計・導入ガイドの読者としては，業界・企業の情報システム部門，調達企画部門，販売企
画部門の方々，IT ベンダー・サービスプロバイダーのシステムアナリスト（SA）・システムエン
ジニア（SE），及び IT/EC 関係のコンサルタントの方々を想定しています。
本設計・導入ガイドの内容と想定している読者を以下に示します。
読者
本設計・導入ガイドの内容
1章

中小企業 EDI の状況，システム構成概念・導入効果，要約調達・販売企画・業

SA，SE，IT/EC 関係

務部門

コンサルタント○○

2章

システム構成○○3章

EDI 標準メッセージ

○

○

4章

EDI 受発注アプリケーション画面

○

○

5章

認証方式と企業識別

○

○

6章

EDI メッセージ送受信・蓄積交換機能○

7章

EDI 簡易アプリケーションの機能と構造○

8章

中小製造業 EDI メッセージモデルの応用・実装検討○

付録 1 中小企業に関する IT/EC 関係活動○○

付録 2 認証技術応用と PKI 認証局サービスの動向○○

付録 3 人材育成○○

付録 4 EDI 標準メッセージ○○

付録 5 中小製造業 EDI メッセージモデル／UBL マッピング○

なお，本設計・導入ガイドに関係のある以下の報告書がありますので，必要に応じてご参照ください。
・ インターネット EDI 促進調査研究報告書―インターネット EDI の実態と今後の EDI 促進策の提言―（平成 16 年 3 月，（財）日本情報処理開発協会電子商取引推進センター，電子商取引推進協議会）・ 標準ビジネスプロトコル変換方法調査研究報告書（平成 16 年 3 月，（財）日本情報処理開発
協会電子商取引推進センター，電子商取引推進協議会）
平成 17 年 3 月
財団法人日本情報処理開発協会
電 子 商 取 引 推 進 センター
電子商取引推進協議会

中小企業 EC/EDI 普及 SWG 委員名簿
（主査）
斉藤 幸則

富士電機情報サービス（株） 情報 SI 事業部事業企画部 ゼネラルマネージャー

（委員）
錦織 聡一

（株）帝国データバンク 企画部マーケティング課

常石 禎一

日本電気（株） 市場開発推進本部 エキスパート

桐原 重喜（株）日立製作所 ソフトウェア事業部 主任技師

矢野 理恵子

三菱商事（株） CIO オフィス根本 忠昭

鉄道情報システム（株） ［（社）日本物流団体連合会／物流 EDI センター］

鈴木 耀夫

旅行電子商取引促進機構 主幹事

中根 敏男（財）住宅産業情報サービス 事業推進部

高山 茂

横河電機（株） 業務システム部 課長 ［（社）日本電気計測器工業会］

上野 圭輔(株)エムシー・ヒューマンリソース 社長付部長 ［石油化学工業協会］

佐藤 徹

富士通（株） 購買本部調達戦略室 e-Procurement 推進部 部長

川内 晟宏

プロセス経営研究所 代表

細田 直正

NEC ソフト（株） 製造ソリューション事業部 E ビジネスグループ グループマネージ
ャー

柳澤 政夫

マイクロソフト（株） 製造ソリューション本部製造ソリューション部 ソリューションデベ
ロップメントマネージャー

井口 光夫（株）シナジー・インキュベート リサーチ＆ディベロップメントマネージャー

桑山 義明（株）シーガル 代表取締役， （NPO）OCP 総合研究所 理事長

吉田 稔（株）日本ユニテック 開発部システム開発課 課長（オブザーバ）
伊原 智人

経済産業省 商務情報政策局情報経済課 課長補佐

小林 秀司

経済産業省 商務情報政策局情報経済課 企画１係長

菅又 久直

電子商取引推進協議会 主席研究員

竹内 一正

電子商取引推進協議会 主席研究員

（事務局）
若泉 和彦

（財）日本情報処理開発協会 電子商取引推進センター

目次
1

中小企業の EDI の状況，システム構成概念・導入効果，要約....................................................... 1
1.1

EDI の概要 ........................................................................................................................... 1

1.2

中小企業のインターネット EDI の状況................................................................................... 3

1.3

中小企業のインターネット EDI の問題点・課題...................................................................... 4

1.4

インターネット EDI の問題点・課題の解決策の提言 .............................................................. 6

1.5

システム構成概念と導入効果................................................................................................. 7

1.5.1

システム構成概念........................................................................................................... 7

1.5.2

本設計・導入ガイド採用の導入効果 ............................................................................... 7

1.6
2

3

本設計・導入ガイドの要約...................................................................................................... 9システム構成................................................................................................................................12
2.1

システム構成概念 ................................................................................................................12

2.2

共通 XML/EDI フレームワーク ...........................................................................................13

2.3

中小企業にも適用可能な EDI-ASP の機能 ........................................................................14

2.4

Pull 型 XML/EDI クライアントのシステム構成モデルと機能 ...............................................16

2.5

Push 型 XML/EDI の機能 .................................................................................................18

EDI 標準メッセージ.....................................................................................................................19
3.1

中小企業にも適用可能な EDI 標準メッセージの策定方針..................................................19

3.1.1

方針 .............................................................................................................................19

3.1.2

主流となる EDI 標準メッセージの選定.........................................................................193.1.3

EDI 標準メッセージの策定..........................................................................................20

3.2

EDI 標準メッセージ利用のユースケース .............................................................................21

3.2.1

今後の EDI 標準メッセージ利用のユースケース .........................................................21

3.2.2

現状の EDI 取引 .........................................................................................................23

3.3

中小企業 EDI メッセージモデルの標準構造.......................................................................26

3.3.1

各業界の EDI 標準メッセージのデータ項目と ECALGA の比較................................26

3.3.2

中小企業 EDI メッセージモデルの標準構造 ...............................................................27

3.3.3

CII 標準と EIAJ 標準採用の業界団体........................................................................28

3.3.4（社）日本機械工業連合会の団体会員 .........................................................................29

3.4

中小企業 EDI メッセージモデル（注文情報）の策定............................................................29

3.4.1

電機・電子業界の Web-EDI 画面から ECALGA へマッピングの結果 ........................29

3.4.2

機械業界の EDI 標準メッセージの概要と ECALGA へのマッピングの結果 ...............30

3.4.3

中小製造業の Web-EDI 画面から ECALGA へマッピングの結果..............................31

3.4.4

中小企業 EDI メッセージモデルの策定.......................................................................32

3.5

中小製造業 EDI メッセージモデルの使われ方 ...................................................................33

3.5.1

電機・電子業界，機械業界内の商取引.........................................................................33

3.5.2

業界間の商取引...........................................................................................................34
−i−

3.6
4

5

EDI 受発注アプリケーション画面 ................................................................................................36
4.1

画面設計方針 ......................................................................................................................36

4.2

注文情報，納期確認／回答のビジネスプロセス ...................................................................36

4.3

画面設計..............................................................................................................................37

4.3.1

メインメニュー ...............................................................................................................37

4.3.2

注文情報一覧（受注者用）............................................................................................37

4.3.3

注文情報明細（受注者用）............................................................................................374.3.4

納期確認情報一覧（受注者用） ....................................................................................384.3.5

納期確認情報（発注者用）／回答情報（受注者用）.......................................................39

4.3.6

納期回答情報（受注者用）............................................................................................39

4.4

印刷.....................................................................................................................................39

4.5

画面デザイン .......................................................................................................................39

認証方式と企業識別....................................................................................................................44
5.1

前提条件と検討テーマ.........................................................................................................445.2

認証方式と企業識別方式の動向..........................................................................................44

5.2.1

政府関係......................................................................................................................45

5.2.2

企業間取引（B2B）.......................................................................................................49

5.2.3

e 文書法，電子署名，タイムスタンプの動向..................................................................50

5.3

企業間電子商取引（B2B）の企業認証方式..........................................................................52

5.3.1

EDI 利用の二つのタイプ−固定的継続取引とオープン取引− ...................................53

5.3.2

インターネット EDI-ASP サービスでの企業認証..........................................................53

5.3.3

企業間電子商取引（B2B）における企業認証の方式と考察..........................................54

5.3.4

中小企業インターネット EC/EDI の認証方式に関する考察.........................................55

5.4

6

EDI 標準メッセージ種 .........................................................................................................35

中小企業に適した企業識別（企業コード）の考察..................................................................60

5.4.1

企業識別方式の現状 ...................................................................................................60

5.4.2

企業識別方式の課題 ...................................................................................................60

5.4.3

中小企業の企業識別導入に対する現状と課題 ............................................................615.4.4

企業識別に求められる要件..........................................................................................61

5.4.5

企業識別方式の考察 ...................................................................................................62

EDI メッセージ送受信・蓄積交換機能.........................................................................................66
6.1

システム構成........................................................................................................................66

6.1.1

システム構成モデル.....................................................................................................66

6.1.2

システム機能構成要素 .................................................................................................67

6.2

EDI クライアント送受信インタフェース .................................................................................686.2.1

送達確認（Acknowledgement）機能 ...........................................................................68

6.2.2

ビジネスプロセス制御...................................................................................................70

6.2.3

ビジネスドキュメント制御...............................................................................................71

6.2.4

クライアントインタフェース.............................................................................................72
−ii−

6.3

EDI クライアント送受信・EDI サーバー間交換インタフェース..............................................73

6.3.1
6.4

7

EDI メッセージ送受信・蓄積交換機能の Web サービス化の検討........................................76

6.4.1

個別実装方式 ..............................................................................................................76

6.4.2

Web サービス方式.......................................................................................................77

6.4.3

MS Office 2003 を活用した Web サービス方式..........................................................796.4.4

各方式の比較 ..............................................................................................................80

6.4.5

補足説明......................................................................................................................81

EDI 簡易アプリケーションの機能と構造 ......................................................................................837.1

全体機能構成 ......................................................................................................................83

7.2

簡易 EDI システムのデータファイル構造.............................................................................84

7.3

EDI メッセージ受信機能 .....................................................................................................84

7.3.1

表示・印刷機能 ............................................................................................................85

7.3.2

設定機能......................................................................................................................867.3.3

指定納品伝票印刷機能................................................................................................86

7.3.4

受信メッセージバックエンド連携機能............................................................................88

7.4

EDI メッセージ送信機能 .....................................................................................................89

7.4.1

入力機能......................................................................................................................89

7.4.2

送信メッセージバックエンド連携機能............................................................................907.5
8ebMS V3.0 実装方法 ..................................................................................................73

各種標準文書の管理 ...........................................................................................................91

中小製造業 EDI メッセージモデルの応用・実装検討..................................................................938.1

中小製造業 EDI メッセージモデル/UBL マッピング ...........................................................93

8.1.1

マッピングの背景・目的 ................................................................................................93

8.1.2

マッピングの方法 .........................................................................................................93

8.1.3

マッピング不可能項目の解説.......................................................................................94

8.1.4

マッピング結果 .............................................................................................................94

8.1.5

評価 .............................................................................................................................95

8.1.6

UBL TC へのコメント（マッピングのデータ項目の説明以外） .......................................97

8.2

ebXML CC 仕様に基づいた中小製造業 EDI メッセージモデル実装の検討....................103

8.2.1

ebXML CC 仕様に基づいた中小製造業 EDI メッセージモデル実装の背景・目的...1038.2.2

コア構成要素を使う利点.............................................................................................103

8.2.3

中小製造業 EDI メッセージモデルの情報項目の再整理...........................................103

8.2.4

集約コア構成要素の選択と集約ビジネス情報項目の決定..........................................104

8.2.5

関連ビジネス情報項目及び基本ビジネス情報項目の決定 .........................................105

8.2.6

メッセージ構造表の説明 ............................................................................................1088.2.7

コア構成要素に基づくメッセージ作成の評価 .............................................................111

付録 1

中小企業に関する IT/EC 活動動向 ..............................................................................117

付録 1.1

政府・団体..................................................................................................................117

付録 1.2

企業 ...........................................................................................................................117
−iii−

付録 2

認証技術応用と PKI 認証局サービスの動向.................................................................123

付録 2.1

認証技術応用の動向 .................................................................................................123

付録 2.2

認証局サービスの動向...............................................................................................123

付録 3

人材育成........................................................................................................................127

付録 3.1「ITSSP」と「IT 経営応援隊」......................................................................................127

付録 3.2

日本商工会議所の「日商 EC 実践研修」と「日商 EC 実践能力検定試験」 .................128

付録 4

EDI 標準メッセージ

付録 5

中小製造業 EDI メッセージモデル／UBL マッピング−iv−

1 中小企業の EDI の状況，システム構成概念・導入効果，要約
本章では，本設計・導入ガイドの序章として，EDI の概要，中小企業 EDI の概要，シス
テム構成概念・導入効果，及び本設計・導入ガイドの要約を説明する。中小企業 EDI の状
況としては，2003 年度の ECOM 活動成果から，中小企業のインターネット EDI の状況，
問題点・課題，及び問題点・課題の解決策の提言の要約を説明する。

1.1

EDI の概要(1) EDI の概念
EDI（Electronic Data Interchange，電子データ交換）とは，企業間の電子データ交換を意味し，B2B 電子商取引などを含む。EDI は，各社の情報システムのインタフ
ェース部分を標準化することによってインタフェースギャップを埋め，企業間に係わる業務を効率的に支援する情報システムを容易に実現しようとする考え方である。
備考(1)：EDI の定義［通産省「電子計算機相互運用環境整備委員会（1989 年度）」，
日本情報処理開発協会の「国内外の EDI 実態調査」］「異なる組織間で，取引のためのメッセージを，通信回線を介して標準的な規約（可能な限り広く合意された各種規約）を用いて，コンピュータ（端末を含む）間で交換すること。」
備考(2)：EDI の定義［JIS X 7011-1「行政，商業及び輸送のための電子データ交換(EDIFACT)」］「トランザクション又はメッセージデータを構成することを目的に合意された規格を用いた，商業上又は行政上のトランザクションの電子計算機適用業務から電子計算機適用業務への電子的な転送。」
備考(3)：図 1.1 に EDI と電子商取引（EC）の関係を示す。
電子商取引（EC）

・ 標準化していない電子商取引（例：e-mail 本文
での非標準の受発注）
・ B2C の EC

図 1.1
z

EDI

・ B2B の EC
・ B2G の EC

・ 設計データ連携
・ 生産工程管理
・ 電子カルテ交換処理（医療）・他

EDI と電子商取引（EC）の関係

EDI は，EC 以外に設計データ連携，生産工程管理，医療・福祉・教育分野でのデータ交換などが含まれる。
―1―z

EC は，物品・サービスの売買など商取引の範囲であり，設計データ連携，生産工程管理などを含まない。

z

一般に B2C の EC は EDI に含まない。

(2) EDI のビジネスプロセス
一般的に，EDI のビジネスプロセスは，商品企画・設計・開発を主体にしたエンジ
ニアリングプロセスと生産計画・受発注・支払・出荷を主体にしたサプライチェーン
プロセスで構成される。図 1.2 EDI のビジネスプロセスと EDI 機能に，エンジニアリ
ングプロセス，サプライチェーンプロセスと EDI 機能の関係を示す。

サプライチェーンプロセス

エンジニアリングプロセス

所要計画

見積

発注

受入

支払

生産

出荷

受注

生産計画

発注

受入

生産

出荷

請求

注文先
支払

見積

生産計画

需要予測

仕様決定

納期検討

原価検討

開発

詳細設計

性能設計

基本設計

商品企画

ビジネスプロセス計画生産型プロセス（セットバイヤー）

受注生産型プロセス（バイヤー，サプライヤ）
電子カタログ
基本 EDI（需要予測〜支払）
I
D
E

機能

納入仕様書交換
開発購買（購入仕様書，新製品見積）

図 1.2

z

倉庫事業者預託，コンサイメント

EDI のビジネスプロセスと EDI 機能

サプライチェーンプロセスは，計画生産型プロセス（セットバイヤーのプロセス）と受注生産型プロセス（セットバイヤーから受注して，下位のサプライヤに発注するプロセス）があり，相互に連携して業務が実施される。

z

基本 EDI（需要予測〜支払）機能は，サプライチェーンプロセスの受発注プロ
セス（発注，受注）を中核とした電子データ交換機能である。従来 EDI 及び今後の EDI を含めて，EDI の中核機能である。

z

近年では，エンジニアリングプロセスにおける電子カタログの活用，納入仕様
書交換，開発購買（購入仕様書，新製品見積）などで EDI 化が進展している。

z

サプライチェーンプロセスの生産・出荷プロセスでの倉庫事業者預託・コンサ―2―

イメント機能の EDI 化が推進されている。

1.2

中小企業のインターネット EDI の状況

EDI は，専用線又は VAN 回線を利用した EDI システムとして 1980 年代から導入が始まった。1990 年代前半に登場したインターネット基盤・技術を，この EDI システムに活用した取組みが始まり，1996 年からインターネット網・技術を活用したインターネット EDIの商用提供及び企業への導入が開始された。
EDI 普及の評価尺度として，EDI の導入率*と実施率（利用率）**がある。EDI の普及
促進は，その尺度として，導入率の向上のみならず実施率の向上が重要である。
EDI 導入率*：1 社とでも EDI を実施している企業を EDI 導入済みと定義し，EDI 導入
済み企業の割合。
EDI 実施率（利用率）**：データ交換業務の内，電子データ交換（EDI）で取引を実施
している業務の実施割合。
中小企業に取ってのインターネット EDI の導入率と実施率に関する調査結果として以下がある。以下の調査結果は電子商取引の調査であるが，調査の実態は B2B 電子商取引であり，EDI の主体である。（出典：ニュースリリース「電子商取引の一層の拡大に向けて，中小企業の電子商取引の実態を日本で初めて調査・発表」，2004 年 1 月 14 日，ECOM）(1) 導入率2003 年度 10 月に ECOM が実施した日本の中小企業（約 5,000 社）を対象にした電子商取引（EC）に関するアンケート調査によると，電子商取引（EC）の導入率は購入 EC で 35%，販売 EC で 70%でかなり高い。但し，この調査における調査母体は IT・
EC を指向していると想定できる中小企業であり，EC 導入率は高かった。総務省が実施した平成 13 年事業所・企業統計調査では EC 導入率は 10%であり，中小企業全体ではその EC 導入率は低い。図 1.3

電子商取引（EC）の導入率参照。

電子商取引（EC）の導入率
全体母数
837社

購入EC

837社

販売EC

35%（291社）
70%（584社）

160万社 中小企業のEC導入率の全国平均

10%（16万社）

備考：・中小企業のEC導入率の全国平均は平成13年事業所・企業統計調査による（総務省統計局）
・EC導入率：1社とでもECを実施している企業をEC導入済みと定義し，EC導入済みの企業の全回答企業に対する割合。

図 1.3 電子商取引（EC）の導入率(2) 実施率(利用率)
電子商取引（EC）を導入していても，商取引全体に占める電子商取引（EC）の実―3―

施率（利用率）は非常に低い。件数レベルの実施率では，10%以下の実施率としている企業が 52%（購入 EC），48%（販売 EC）とほぼ半数を占めている。相手社数レベ
ルの実施率では，4.3%（購入 EC），4.6%（販売 EC）と非常に低い。電子商取引の実施から得られる効果を充分に享受できるまでに至っていないと思われる。図 1.4
電子商取引（EC）実施率参照。

電子商取引（EC）の実施率（件数，商流業務）
購入ECの回答企業の割合
52%

販売ECの回答企業の割合
10%以下

14%

48%
14%

20%以下
7%

母数：220社

3%

30%以下

8%

40%以下

6%

母数：470社

備考：・EC実施率（件数）：商取引業務の内，ECで商取引を実施している業務の実施割合（件数）。
・母数は，商取引業務のEC導入企業数。

電子商取引（EC）の実施率（取引先数）
購入EC
4.3%

販売EC

電子商取引先社
数（平均）：12.6社

4.6%

電子商取引先社
数（平均）：24.4社

取引先社数
全体平均：536社

取引先社数
全体平均：294社

母数：584社

母数：291社

備考：・EC実施率（取引先数）：ECを実施している商取引先数の全商取引社数に対する割合。
・母数は，EC導入企業数。

図 1.4

1.3

電子商取引（EC）実施率

中小企業のインターネット EDI の問題点・課題

1．2 節で述べたように，中小企業にとってのインターネット EDI 普及に関する大きな問
題点として，EC 導入率が低いこと，及び EC 導入済みの企業でもその実質的な実施率（利用率）が著しく低いことがある。原因として，以下の複数の問題点・課題がある。
(1) 中小企業の EC 実態アンケート調査
2003 年 10 月に ECOM が実施した中小企業の EC 実態アンケート調査によると，第一の問題点が「伝票やデータフォーマットが業界・企業により異なり困る。」であり，半数以上（58%）の企業が指摘している。次に続く問題点は，「電子商取引の導入費，運用費が高い。」「電子商取引を行う人的環境が整っていない。」，「システム構築，―4―

システム接続に専門知識を要する。」，「セキュリティ対策が十分に構築できない。」
である。表 1.1 電子商取引に関する問題点・課題を参照。

表 1.1

電子商取引に関する問題点・課題

No.

問題点・課題

1
2
3
4
5
6
7
8
9
10

伝票やデータフォーマットが業界・企業により異なり困る。
電子商取引の導入費，運用費が高い。
電子商取引を行う人的環境が整っていない。
システム構築，システム接続に専門知識を要する。
セキュリティ対策が十分に構築できない。
電子商取引に関する法律・ガイドラインが整ってない。
電子商取引を行うシステム的環境が整っていない。
コード（商品・製品コード）が整備されていない。
コード（企業コードなどの参照系コード）が整っていない。
どのような伝票やデータフォーマットを採用したら良いか解ら
ない。
その他
回答企業数

11
12

回答数
割合
（社数） （％）
420
58.1
257
35.5
231
32.0
225
31.1
221
30.6
124
17.2
66
9.1
63
8.7
51
7.1
40
5.5
56
723

7.7
100.0

(2) インターネット EDI に関する問題点・課題の纏め
上記に述べた中小企業の EC 実態アンケート調査，及び複数の中小企業対象の個別ヒアリングから，インターネット EDI に関する問題点・課題を纏めると以下に整理できる。
① 標準化の問題
z

伝票やデータフォーマットが業界・企業により異なり困る。

② ユーザー体制・能力の問題z

電子商取引を行う人的環境が整っていない。

zシステム構築に専門知識を要するので，システム構築できない。

z

セキュリティ対策が十分に構築できない。

③ 利便性の問題
z

Web-EDI が多いが，社内システムと連携していない。手入力している。自動又は半自動で社内システムと連携したい。

z

中小企業の商取引は FAX を用いた取引が多い。EC，EDI に移行するにはそれなりのメリット・効果がないと意味がない。

④ 費用の問題z

電子商取引の導入費，運用費が高い。

z

インターネット EDI の ASP サービスの利用と個別企業の EDI を実施している。ASP 一業者（又は個別企業）あたり約 1 万円／月の運用費がかかる。取引相手の ASP 及び個別企業が数社になると数万円／月となり費用負担が困
―5―

難。

1.4

インターネット EDI の問題点・課題の解決策の提言

電子商取引推進協議会（ECOM）は，2003 年度の活動「インターネット EDI 促進 SWG」
で，インターネット EDI の問題点・課題の解決策を提言した。
提言の主な骨子は以下である。

(1) EDI システムの基本技術は，XML*1 技術を採用したインターネット EDI とする。
z

21 世紀初頭のインターネット技術革新の一つの XML（拡張可能マークアップ言語）を採用する。

z

安全・安心を確保するためのセキュリティ・高信頼性メッセージ搬送機能を実装する。国際標準で実装が進んでいる，SSL 標準，PKI 標準，及び ebXML MS
標準*２を適用する。

(2) XML スタイルシート*３を活用する。
z

現状のインターネット EDI で主流になっている Web-EDI の問題点である，データ項目と Web 表示フォーマットの非統一の問題をクライアントパソコン側の処理で解決する。

(3) 中小企業でも導入可能なパソコンレベルの標準簡易電子商取引システムと安価な運用管理サービスを開発・提供する。
z

ユーザー側の電子商取引システムは，パソコンレベルで動作可能なシステムとし，電子商取引の標準メッセージ送受信機能と標準メッセージ処理機能（画面表示機能，帳票印刷機能，社内バックエンドシステムとの連携機能）を持たせる。

z

標準メッセージ送受信機能としては，ebXML MS 仕様*２準拠の HTTP 方式電子
商取引クライアントシステムとする。

z

標準メッセージ処理機能には，XML 技術にフル対応し，かつコスト的・技術的に中小企業でも利用可能な MS Office System 2003 の利用が可能である。

z

複数の商取引先と単一のシステムで，安価に電子商取引を実施するための運用
管理サービスとして，共通電子商取引の ASP サービスを開発・提供する。

z

中小企業が利用できるように費用負担は FAX 導入レベルとする。具体的には，一次導入費用：10 万円〜20 万円，月額維持費用：3,500 円〜5,000 円である。
開発・提供方法にもよるが，このレベルは中小企業にとって受け入れ易いレベ
ルであり，実現性が高い。

(4) 業界間の標準メッセージ*⁴変換システムを開発・提供する。
z

多くの業界で，業際取引の標準メッセージ変換に悩んでいる。主要の標準メッセージとの変換システムを開発して，複数の業界で活用する。

z

主要の標準メッセージは，XML ベースの e ビジネス国際標準 ebXML に準拠した UBL（Universal Business Language）*⁵と ECALGA *6（JEITA）標準メッ
セージが第一候補である。

―6―

*1〜*6：章末に用語解説を示す。

1.5 システム構成概念と導入効果
1.5.1 システム構成概念
中小企業でも導入可能な標準簡易電子商取引システムを実現するため，本設計・導入ガ
イドで提案しているシステム構成概念を図 1.5 システム構成概念に示す。
z

現状の EDI ネットワークは，バイヤー企業・EDI-ASP サービス毎に接続するシス
テム形態となっており，バイヤー企業及びサプライヤ企業は複数のネットワーク方式でそれぞれ EDI 接続しなければならない。提案 EDI システムでは，バイヤー企業及びサプライヤ企業に取って 1 本のネットワーク方式で EDI 接続を可能にする。

z

現状の EDI では，EDI 標準メッセージを採用していたとしても，EDI 画面・帳票がバイヤー企業または EDI-ASP サービス毎に異なっている。
提案 EDI システムでは，
原則として統一された EDI 画面・帳票を採用する。

z

現状の EDI では，サプライヤ側は受注 EDI が主体であり，同一方式で発注が出来ない。提案 EDI システムでは，受注と発注を可能にする。

ﾊﾞｲﾔｰ A 社

ﾊﾞｲﾔｰ B 社

ﾊﾞｲﾔｰ B 社

ﾊﾞｲﾔｰ A 社

ﾊﾞｲﾔｰ C 社

ﾊﾞｲﾔｰ C 社

相互接続

ｻﾌﾟﾗｲﾔ X 社

EDI-ASP (S)EDI-ASP (T)ｻﾌﾟﾗｲﾔ Y 社

ｻﾌﾟﾗｲﾔ Z 社

EDI-ASP (S)ｻﾌﾟﾗｲﾔ X 社

・複数のネットワークで接続。
・バイヤー企業・ASP 毎の複数の EDI 画面，帳票。
・サプライヤは受注のみ。

現状の EDI

EDI-ASP (T)ｻﾌﾟﾗｲﾔ Y 社

ｻﾌﾟﾗｲﾔ Z 社

・1 本のネットワークで接続。
・統一された EDI 画面，帳票。
・サプライヤは受注と発注が可能。

提案 EDI システム
図 1.5

システム構成概念

1.5.2 本設計・導入ガイド採用の導入効果
本設計ガイド「中小企業にも適用可能なインターネット EDI 設計・導入ガイド」，及び本設計・導入ガイドに基づいた EDI システムは以下の導入効果がある。

1.5.2.1 EDI ユーザー（中小企業）の導入効果(1) 統一 EDI インタフェースの実現
従来の複数の不統一の EDI システムが，統一された共通のインタフェース（EDI 通―7―

信機能と EDI 画面・伝票フォーマット）となり，以下の多くのメリットがある。第 1のインターネット EDI に関する問題点・課題である「標準化の問題」を解決できる。
z

1 種類の EDI インタフェースで多くの取引先と EDI が可能になる。

z

EDI 取引先毎に掛かっていた EDI 取引費用が 1 種類に削減される。

z

EDI 取引毎に必要だった複数の EDI オペレーション・画面・伝票が 1 種類になり，オペレータの削減・学習の削減など合理化できる。

(2) 受発注の実現
z

中小企業にとっては，主として受注の機能だけが EDI 処理できていた。本ガイドのシステム導入により，受注だけでなく，同一インタフェースで発注も可能になる。

(3) 社内バックエンドシステムとのデータ連携z

必要に応じて，社内バックエンドシステム（受注システム，購買システム，会計システムなど）とデータ連携できる。従来必要だった人手による再入力が不要になり合理化できる。インターネット EDI に関する問題点・課題である「利便性の問題」を解決できる。

1.5.2.2 EDI ユーザー（大企業）の導入効果(1) 中小企業との EDI の促進z

EDI-ASP サービスとして共通インターネット EDI サービス，及び EDI 標準メ
ッセージとして中小企業 EDI メッセージモデルを採用することにより，従来からなかなか進まなかった中小企業との EDI 化を促進できる。

(2) コストパフォーマンスの高い EDI システム構築・運用z

共通インターネット EDI サービス，及び EDI 標準メッセージとして中小企業
EDI メッセージモデルの採用は，自社独自の EDI システム構築より安価となり，コストパフォーマンスの高い EDI システム構築・運用が可能になる。

1.5.2.3 ASP プロバイダーの導入効果(1) EDI ユーザーの加入拡大z

従来，インターネット EDI-ASP サービスとして共通インタフェースがなく，個々の ASP プロバイダーが独自のインターネット EDI-ASP サービスを開発・提供してきた。独自の仕様のため，なかなかユーザーの利用加入が進まなかった。共通 EDI インタフェースを採用することにより，ユーザーの利用加入が拡大する。

(2) マーケティング・仕様開発の合理化
z

EDI システム開発のマーケティング・仕様開発の参考になる。従来多くのマンパワー・時間をかけたマーケティング・仕様開発が合理化される。

1.5.2.4 IT ベンダーの導入効果(1) EDI 関連の新しいビジネスチャンス―8―z

共通 EDI システムの導入をきっかけとして，大企業や中小企業の EDI システム
導入の見直しが始まり，新しい IT ビジネスチャンスが生まれる。

1.6

本設計・導入ガイドの要約

本設計・導入ガイドの要約を以下に示す。
(1) システム構成
複数の取引先と単一のインタフェースで安価に EDI を実施するには，共通 EDI-ASP
サービスの提供・利用が最適である。また，複数の EDI-ASP サービスの相互接続が必要である。共通 EDI-ASP サービスを利用したシステム構成モデルと，ここに接続する
XML/EDI クライアントのシステム構成モデルを策定した。（第 2 章）
(2) EDI 標準メッセージ
従来から多くの業界で取組み推進してきたように，EDI 標準メッセージの策定は重要である。中小企業でも広く利用できる EDI 標準メッセージを策定した。（第 3 章）
(3) EDI 受発注アプリケーション画面
現状の EDI の世界では，EDI 標準メッセーが策定・採用されているが，EDI 運用のための画面（例：Web-EDI の画面）は標準化されていなく，EDI ユーザー企業に取っての個別対応が多く合理化の障害になっている。広い範囲の EDI 相互運用性を確保し，
EDI ユーザー企業に取っての合理化を推進するには，EDI 運用画面の標準化も必要である。中小製造業 EDI メッセージモデルを EDI 画面として設計した。（第 4 章）
(4) 認証方式と企業識別
インターネット EDI として適切なセキュリティ機能が必要である。クライアント認証機能として，大きく ID・パスワードの方式と電子証明書の方式があり，これらの利用方針を検討した。（第 5 章，5.3 節）
EDI 取引で企業を特定する必要があり，各種の企業識別コードサービスが提供されている。企業識別方式として，企業識別コードを利用する方式とその他の管理番号（例：法人登記番号，EDI-ASP のアカウント番号）を利用する方法を検討した。（第5 章，5.4 節）(5) EDI 送受信・蓄積交換機能
本設計・導入ガイドの第 2 章で策定した共通 EDI-ASP サービスモデルを実現する
EDI 送受信・蓄積交換機能を設計した。この中の EDI 送受信機能は，全世界的に利用が進展している ebXML MS（Message Service）標準を適用した機能設計としている。
（第 6 章の 6.1 節〜6.3 節）
21 世紀初頭のインターネット技術として Web サービスが，その標準化と導入推進が進んでいる。本来の Web サービスは，疎結合の分散アプリケーションを実現する技術であり，今後の EDI の世界でも適用が考えられる。本設計・導入ガイドの共通
EDI-ASP サービスモデルを Web サービス化することを検討した。（6.4 節）(6) EDI 簡易アプリケーションの機能と構造
EDI ユーザー各社に実装される標準的な簡易 EDI 機能と構造を設計した。適用技術
としては，XML のファミリー標準である XSLT，XSL-FO の適用を検討・評価した。
―9―

また，XML 技術にフル対応した MS Office 2003（InfoPath，Excel）の適用も検討・評価した。（第 7 章）
(7) EDI 標準メッセージの応用・実装検討
EDI 標準メッセージの応用・実装研究として以下の 2 点を実施した。
① 中小製造業 EDI メッセージモデルの UBL マッピング
第 3 章で策定した中小製造業 EDI メッセージモデルを UBL にマッピングして，
東南アジアなどでの国際取引 EDI で利用の可能性を考慮しつつ，中小製造業 UBL
サブセットを策定した。（8.1 節）② ebXML CC 仕様に基づいた中小製造業メッセージモデルの策定
ebXML 標準の中にコア構成要素仕様（CCTS，Core Component Technical
Specification）があり，この仕様に準拠したコア構成要素（CC，Core Component）
が開発されつつある。第 3 章で策定した中小製造業メッセージモデルを，コア構成
要素仕様とコア構成要素に準拠して，ebXML CC 仕様に基づく EDI メッセージモデ
ルを策定した。（8.2 節）(8) 中小企業に関する IT/EC 関係動向
2004 年の約 1 年間の中小企業に関する IT/EC 関係動向を整理した。（付録 1）(9) 認証技術応用と PKI 認証局サービスの動向（付録 2）
2004 年の約 1 年間の認証技術応用と PKI 認証局サービス動向を整理した。
(10) 人材育成
インターネット EDI 促進に関する大きな課題の一つとして人材育成がある。IT 関連のスキルの習得・認定の取組みを紹介した。（付録 3）＜用語解説＞
1. XML*1：eXtensible Markup Language，拡張可能なマークアップ言語，インターネ
ット電子商取引（B2B，B2C）は勿論，多くの分野［ナレッジマネジメント（知識管理），文書処理，印刷処理，音声処理，CAD など］で利用が拡大している。
2. ebXML*2：e-business XML の略称。XML ベースの e ビジネスの国際標準フレームワークである。1999 年 11 月に，XML ベースのｅビジネス標準基盤を提供することを目的に，UN/CEFACT と OASIS は共同で「ebXML Initiative」を設立した。18 ヵ月の活動を経て，2001 年 5 月に ebXML 仕様 V1.0 を策定・公開した。2004 年現在，
UN/CEFACT 及び OASIS が引き継いで ebXML 仕様の二次開発を推進している。一部の標準仕様は V2.0 が策定・公開されている。ebXML MS（Message Service）仕様
は，ebXML 仕様群の一つで，EDI メッセージの高信頼性メッセージ搬送仕様である。
産業界で実装が進んでおり，サポートソフトウェア製品の相互接続テストが全世界的に推進している。
3. OASIS(Organization

for

the

Advancementof

Structured

Information

Standards)：米国主体の XML 実装標準化を推進しているコンピュータ企業と業界団体の幅広いコンソーシアム。
―10―

4. UN/CEFACT (United Nations Center for Trade Facilitation and Electronic
Business)：国際標準メッセージの EDIFACT の標準化・保守を進めている国連の組織。
5. XML スタイルシート*3：XML 文書の表示フォーマットを記述した文書。W3C（World
Wide Web Consortium）が XSLT（XSL Transformations）標準として標準化している。
6. 標準メッセージ*⁴：電子商取引の発注・受注で使用される紙の伝票の内容を，ネットワーク上で送受信するための情報項目を決めた標準仕様。標準化組織と業界などで標準化している。代表的な標準メッセージは，日本では CII 標準，EIAJ 標準，欧米では
EDIFACT がある。
7. UBL*⁵：Universal Business Language の略称。従来の標準メッセージ仕様は，流通業界，電機・電子業界等の業界単位に標準化されてきた。UBL は，特定の業界にディペンドしなく国際的に汎用的に利用されることを目的に開発されている国際標準メッセージ仕様である。UBL は，OASIS が標準化を推進しており，最新仕様 V1.0 が，2004
年 11 月に OASIS 標準として制定された。UBL は，ebXML CC (Core Component)
仕様に準拠している。
8. ECALGA*6：JEITA（電子情報技術産業協会）で標準化を進めている次世代の標準メ
ッセージ仕様。2003 年 12 月に，Ver2003A-Rev01 として公開された。

―11―

2 システム構成
本章では，中小企業にもメリットのある EDI システムのシステム構成を説明する。シス
テム構成概念，及びシステム構成概念を具体化する共通 XML/EDI フレームワークを説明する。共通 XML/EDI フレームワークの機能として，EDI-ASP の機能，及び EDI-ASP に接続する EDI ユーザー側のサーバー機能とクライアント機能を説明する。

2.1

システム構成概念

図 2.1 中小企業にもメリットのある EDI システム構成概念に，中小企業に取ってもメ
リットのある EDI システム構成を示す。
複数の取引先と単一のインタフェースで安価に EDI を実施するには，現状の技術・サービスの提供実態から判断すると，共通 EDI-ASP サービスを利用した EDI システムが最適である。EDI のインタフェースとは，EDI 送受信機能（通信プロトコル，セキュリティ，他），EDI 標準メッセージ，及び画面・帳票レイアウトなどが該当し，これらが単一の仕様になることが望ましい。
共通 EDI-ASP サービスに関した要求仕様と利用形態として以下がある。
z

複数の EDI-ASP サービスが相互接続し，どれかの一つの EDI-ASP サービスに加入
すれば，他の EDI-ASP サービス配下の取引先とも EC を実施できるようになる必要がある。

z

一般に大手企業は，サーバーで調達システム及び販売システムを構築し，共通
EDI-ASP サービスに接続する。

z

一般に中小企業は，汎用パソコンを使用して EDI システムを構築出来るようにする。
汎用パソコンを使用した EDI システムで受注できるようになる。また，発注もできるようになる。

―12―

サーバー（A 社）

大手企業

ｲﾝﾀｰﾈｯﾄ
サーバー（B 社）
共通 EDI-ASP サービス（S）

ｲﾝﾀｰﾈｯﾄ

EDI ﾒｯｾｰｼﾞ蓄積・交換機能
標準ﾒｯｾｰｼﾞ変換機能
相互接続

EDI ﾒｯｾｰｼﾞ送受信機能

共通 EDI-ASP サービス（T）
EDI ﾒｯｾｰｼﾞ蓄積・交換機能
標準ﾒｯｾｰｼﾞ変換機能
EDI ﾒｯｾｰｼﾞ送受信機能

ｲﾝﾀｰﾈｯﾄ
ｸﾗｲｱﾝﾄ PC（A-1）

ｸﾗｲｱﾝﾄ PC（A-2）

中小企業

ｸﾗｲｱﾝﾄ PC（B-1）

図 2.1

2.2

ｲﾝﾀｰﾈｯﾄ
ｸﾗｲｱﾝﾄ PC（B-2）

PC ｻｰﾊﾞｰ（B-3）

中小企業にもメリットのある EDI システム構成概念

共通 XML/EDI フレームワーク

共通 EDI-ASP サービスを実現する「共通 XML/EDI フレームワーク」を図 2.2 共通
XML/EDI フレームワークに示す。共通 XML/EDI フレームワークは，Push 型 XML/EDI と
Pull 型 XML/EDI クライアントを EDI-ASP サービス事業者が提供する HUB サーバーを介して接続することにより実現する。
z

大手企業と中規模中小企業は Push 型 XML/EDI で，小規模中小企業は Pull 型
XML/EDI クライアントで，EDI-ASP サービスの HUB サーバーと接続する。

z

EDI 標準メッセージは，共通の EDI 標準メッセージとして中小企業 EDI メッセー
ジモデルを利用する。業界固有の EDI 標準メッセージがある場合は，EDI-ASP サービスで EDI 標準メッセージ変換を実施する。海外取引では，UBL サブセットなどを利用する。EDI 標準メッセージの利用に関しては，3 章「EDI 標準メッセージ」
を参照。

［備考］
z

Push 型 EDI：受信者の所有（又は使用）するコンピュータに，送信者から EDI データを送り付ける方式。インターネットの固定 IP アドレスが必要になる。一般的にはサーバーが必要になる。

z

Pull 型 EDI：受信者が，送信者の所有（又は使用）するコンピュータ（又は蓄積交換のサーバー等に）に EDI データを取りに行く方式。インターネットの固定 IP ア
ドレスが不要である。一般的には，受信側システムはクライアントパソコンで構築―13―

可能である。

＜大手発注企業＞
VAN
通信端末＜大手企業＞＜大手企業＞
Push型
XML/EDI

他のXML-EDIサーバーへ

Push型
XML/EDI＜A業界EDI標準又は中小企業EDIﾒｯｾｰｼﾞﾓﾃﾞﾙ＞＜専用線＞＜B業界EDI標準又は中小企業EDIﾒｯｾｰｼﾞﾓﾃﾞﾙ＞

インターネット •＜中小企業EDIﾒｯｾｰｼﾞﾓﾃﾞﾙ＞

VAN
サーバー

EDI-ASP
HUBサーバー

EDI-ASP
HUBサーバー＜中小企業EDIﾒｯｾｰｼﾞﾓﾃﾞﾙ＞
他のHUBへ
海外へ＜UBLサブセット＞＜中小企業EDIﾒｯｾｰｼﾞﾓﾃﾞﾙ＞

Push型
XML/EDI

Push型
XML/EDI＜中規模中小企業＞ ＜中規模中小企業＞
Pull型
XML/EDI
クライアント

Pull型
XML/EDI
クライアント＜小規模中小企業＞＜小規模中小企業＞

図 2.2

2.3

共通 XML/EDI フレームワーク

中小企業にも適用可能な EDI-ASP の機能

中小企業における EDI 普及のために想定する ASP（Application Service Provider）は，その加入者である企業（受注者，発注者）間の取引に関わる情報のやり取りに際して通信を媒介する。
共通 EDI-ASP サービスが提供するする基本的機能は以下がある。
(1) EDI メッセージ蓄積・交換機能① Pull 型加入者中継機能
サーバーを保有せずパソコン（PC）を利用して，クライアント／サーバー接続プ
ロトコルで通信を行う自らの加入者（Pull 型加入者と呼ぶ）の EDI 情報を中継する
Pull 型加入者中継機能。
z

自らの Pull 型加入者宛てに送信された EDI 情報を，当該加入者に代行して受信したうえで当該加入者の In-Box（EDI 受信メッセージ格納箱）に一次的に蓄積し，当該加入者からの要求によって（Pull 型の運用形態で）引き渡す機能。

z

自らの Pull 型加入者（送信側）から送信する EDI 情報を，当該加入者のOut-Box（EDI 送信メッセージ格納箱）に一時的に蓄積し，受信者に対して―14―

送出する機能。
② Push 型加入者中継機能
サーバーを保有しサーバー／サーバー接続プロトコルで通信を行う自らの加入者（Push 型加入者と呼ぶ）の EDI 情報を中継する Push 型加入者中継機能。
z

自らの Push 型加入者宛てに送信された EDI 情報を，当該加入者に代行して受信し，当該加入者へ送出する機能。

z

自らの Push 型加入者から送信する EDI 情報を中継受信して，受信者に対して送出する機能。

(2) EDI 標準メッセージ変換機能
加入者から送信された EDI 標準メッセージのビジネスプロトコルを変換する機能。
ビジネスプロトコルとして，シンタックスルール（構文規則，例：CII のレングス・タ
グ方式，EDIFACT のデリミタ方式，XML）とデータ項目（例：発注者企業名，発注者品名コード，単価，注文数量）がある。
一般的には，ASP 経由の受信者が認識できる標準メッセージに変換する。
例：中小企業 EDI 標準メッセージモデル→UBL サブセット
必要に応じて，EDI 標準メッセージ種類毎に，ASP 機能として実装しサービス提供
される。
(3) EDI メッセージ送受信機能
EDI-ASP サーバーとクライアント間で EDI 標準メッセージを送信及び受信する機能。
送受信機能としては，送達確認（Acknowledge）制御，高信頼性通信機能などがある。
(4) ASP 間相互接続機能
異なる ASP から送信された EDI 情報を受信して自らの加入者に配信し，また，自らの加入者が送信する EDI 情報のあて先が異なる ASP の加入者である場合，該当する ASP に対して情報を送信する機能。
以上の基本機能以外に，EDI-ASP サービスの安全で利便性を向上するための以下の機能がある。
セキュリティ機能(1)

セキュアな通信を確保する機能。
z

加入者でないものが ASP に接続しないことを保証する機能（ID，Password 又はクライアント認証による）。

z

加入者が，他の加入者の In-Box および Out-Box にアクセス（読み出し，書き込み）しないことを保証する機能（なりすまし防止，改竄防止）。

z

加入者が予め ASP に対して申告した相手以外からの情報の受信を拒否（又は警告）する機能（パートナーチェック）。

z

加入者が予め ASP に対して申告した相手以外への情報の送信を拒否（又は警告）する機能（パートナーチェック）。
―15―

z

ASP が媒介した通信に対して，送信者，受信者，日時，メセージの固有 ID など
必要な情報を通信のログとして記録する機能（事後否認防止）。
運用支援機能(2)

EDI の円滑な運用を支援する機能。
z

通信上の異常を検知し，記録し，加入者に通知する機能。

z

In-Box に情報を配信した際に，クライアント／サーバー接続プロトコルで通信を行う加入者に対して，情報の引取りを促すための通知をする機能。

z

加入者が予め定めた期間以上，In-Box の内容を引き取らない場合に加入者に警告する機能。

z

加入者が引き取った後も，In-Box の内容を一定期間保持し，加入者側のトラブルによって再送の必要が生じた場合に備える機能。

z

送信が完了した後も，Out-Box の内容を一定期間保持し，受信者側のトラブルによって再送の必要が生じた場合に備える機能。

2.4

Pull 型 XML/EDI クライアントのシステム構成モデルと機能

Pull 型 XML/EDI クライアントは，図 2.3 Pull 型 XML/EDI クライアントのシステム構
成モデルに示すシステム構成モデルがある。A タイプ，B タイプ，C タイプ，及び D タイ
プの 4 タイプが考えられる。これらは，企業規模，事業性格などにより選択して実装することになる。

EDI ﾒｯｾｰｼﾞ蓄積・交換機能
標準ﾒｯｾｰｼﾞ変換機能

共通 EDI-ASP サービス

EDI ﾒｯｾｰｼﾞ送受信機能

インターネット
XML

XML

XML

HTML

EDI ﾒｯｾｰｼﾞ
送受信機能

EDI ﾒｯｾｰｼﾞ
送受信機能

EDI ﾒｯｾｰｼﾞ
送受信機能

表示・帳票

EDI 簡易アプリ
ケーション

個別接続アプリケーション

各種アプリケーション機能
汎用パッケージ

表示・帳票
B ﾀｲﾌﾟ
A ﾀｲﾌﾟ
社内バックエンド
システム

図 2.3

C ﾀｲﾌﾟ

D ﾀｲﾌﾟ

Pull 型 XML/EDI クライアント
社内バックエンドシステム

Pull 型 XML/EDI クライアントのシステム構成モデル―16―

(1) A タイプz

汎用的に開発された EDI メッセージ送受信機能と EDI 簡易アプリケーション機
能を実装する。

z

共通 XML/EDI-ASP サービスとの EDI 送受信フォーマットは XML とし，クライアント側で機能を動作させるリッチクライアント*を実現する。

z

EDI 簡易アプリケーション機能で，EDI 画面表示・帳票印刷を実施する。必要に応じて社内バックエンドシステムとデータ連携する。

z

この A タイプは，一般的な中小企業の利用を想定する。

リッチクライアント*：最近の主流の Web アプリケーション構築方法であり，クライアント側に高機能・高性能システムが実装でき，かつクライアントソフトウェア
管理が比較的易しいなどの特長がある。
(2) B タイプz

汎用的に開発された EDI メッセージ送受信機能を実装する。

z

社内バックエンドシステムとは，個別に接続インタフェースソフトウェアを開発して接続する。

z

メリットとして，EDI 画面表示・帳票印刷，及び社内バックエンドシステムとの連携が自由にできる。

z

デメリットとして個別開発費用が掛かる。

z

この B タイプは，IT 技術力を備えた中堅企業の利用を想定する。

(3) C タイプz

汎用的に開発された EDI メッセージ送受信機能を実装する。
又は共通 XML/EDI
フレームワークに準拠した EDI メッセージ送受信機能を開発・実装する。各種
業務アプリケーションと組み合わせて，クライアント EDI 統合ソリューション
となる。

z

汎用パッケージベンダーが，各種のアプリケーションソフトウェアと一体にして提供されることを想定する。

(4) D タイプz

現状のインターネット EDI で多く利用されている Web-EDI のシステムモデル
である。共通 XML/EDI-ASP サービスとは HTML フォーマットで送受信接続する。

zメリットとして，クライアント側は Web ブラウザのみで動作可能である。クラ
イアント側としては，一番簡易にシステム構築可能である。

z

デメリットとして，クライアント側で EDI データの電子的再利用，加工などが
できない。
―17―

z

2.5

小規模中小企業の利用を想定する。

Push 型 XML/EDI の機能

一般的にはサーバーで EDI システムを構築して EDI-ASP サービスに接続する方式であり，大手企業及び中規模中小企業がシステム構築する方式である。
Push 型 XML/EDI においても，EDI メッセージ送受信機能と EDI アプリケーション機
能が必要であり，そのシステム構築には本設計・導入ガイドが参考になる。

―18―

EDI 標準メッセージ3

本設計・導入ガイドでは，EDI システムとして重要な構成要素の EDI 標準メッセージとして，中小企業での利用を考慮した中小企業 EDI メッセージモデルを策定した。本章では，
EDI 標準メッセージの策定方針，EDI 標準メッセージ利用のユースケース，中小企業 EDI
メッセージモデルの標準構造，中小企業 EDI メッセージモデルの策定，及び中小製造業 EDI
メッセージモデルの使われ方を説明する。

3.1 中小企業にも適用可能な EDI 標準メッセージの策定方針
3.1.1 方針
以下の方針に従って検討し，中小企業にも適用可能な EDI 標準メッセージを策定した。
z

今後，主流になると思われる EDI 標準メッセージを選定する。

z

新規に EDI 標準メッセージを開発しない。理由：広い範囲で EDI の相互運用性を確保するには共通な EDI 標準メッセージの採用が必要であり，主流の EDI 標準メ
ッセージを採用することが近道である。不具合・改善提案がある場合は，その管理機関へ改善依頼する。

z

広い範囲の中小企業でも適用可能な EDI 標準メッセージは，主流の EDI メッセー
ジをサブセット化した方が相互運用性が高まると想定でき，主流の EDI 標準メッセージのサブセット化を検討する。

3.1.2 主流となる EDI 標準メッセージの選定
3.1.2.1 EDI 標準メッセージの選定
現状での第一の候補として以下の EDI 標準メッセージを選定した。
(1) JEITA の ECALGA 標準① 利用目的z

電機・電子業界の EDI 標準メッセージz

電機・電子業界と業態の近い製造業の EDI 標準メッセージ② 選定理由z

JEITA の EDI 標準メッセージの EIAJ は日本国内で利用実績が高い。EIAJ
標準メッセージは CII シンタックスルールを採用しており，日本国内の各業
界 EDI 標準と親和性が高い。

z

JEITA の ECALGA 標準メッセージは，EIAJ 標準メッセージの後継標準メッ
セージであり XML 技術を採用している。

z

ECALGA 標準は，2003 年 12 月に第 1 バージョン（Ver2003A-Rev01）が公開されて，2004 年度から ASP サービスの提供と各企業の EDI システムへの採用が開始される。

(2) OASIS の UBL（Universal Business Language）標準① 利用目的―19―

z

標準メッセージを持たない業界・業種の EDI 標準メッセージz

業界間取引の EDI 標準メッセージz

海外取引の EDI 標準メッセージ② 選定理由z

XML 関係の国際標準機関の OASIS（Organization for the Advancement ofStructured Information Standards）が推進している。

z

UN/CEFACT（UN/EDIFACT を開発・保守している国連の組織）の運営委員会においては，UBL をベースにした唯一の文書標準の開発意向を表明している。

z

UBL は，ebXML の CC（Core Component）標準に準拠している。

z2004 年 5 月に OASIS UBL TC は V1.0 を策定・公開した。公開レビューの後，2004 年 11 月に OASIS 標準として認定された。

z

UBL 適用推進の地域サブ委員会（Localization Sub-Committee）が，日本，
韓国，中国，及びスペインで立ち上がっている。東南アジアでの国際 EDI 標
準メッセージとして利用の可能性が高い。

③ 制限事項などz

現状での UBL 標準メッセージは，Order（注文情報）から Invoice（請求）までの受発注プロセスの EDI 標準メッセージしかない。需要予測などの SCM
機能はまだない。

(3) その他の EDI 標準メッセージ
上記以外の EDI 標準メッセージは，標準化動向を見て順次検討が必要である。

3.1.3 EDI 標準メッセージの策定選定した EDI 標準メッセージのサブセット化を検討して，中小企業にも適用可能な EDI
標準メッセージとして「中小企業 EDI メッセージモデル」を策定した。中小企業 EDI メッ
セージモデルの策定方法は以下とした。
z

主要企業の現状運用されている Web-EDI の注文情報のデータ項目の調査，
ECALGA 注文情報データ項目とのマッピングz

中小企業 EDI メッセージモデル（注文情報）の策定

z

中小企業 EDI メッセージモデル（注文情報）の UBL Order とのマッピングz

UBL Order サブセットの策定

z

各企業・業界の現状運用されている EDI 標準メッセージ種の調査

z

注文情報以外の EDI 標準メッセージの検討（中小企業 EDI メッセージモデル，UBL
サブセット，今後）

備考：EDI 標準メッセージの基本は注文情報であり，最初の EDI 標準メッセージの調査・分析対象とした。注文情報を分析することにより，その他の標準メッセージの検討・分析
に役立つ。

―20―

具体的な策定方法と策定結果は，3.4 節中小企業 EDI メッセージモデル（注文情報）の策
定に示す。

3.2

EDI 標準メッセージ利用のユースケース

EDI 標準メッセージがどのような場面（バイヤー・サプライヤーとの関連，対象の業界，
国際取引，EDI-ASP の利用有無，他）で利用されるかは，EDI 標準メッセージ策定に関して重要な課題である。3.2.1 項に今後の EDI 標準メッセージ利用のユースケースを示す。
3.2.2 項に現状の EDI 取引の現状を示す。

3.2.1 今後の EDI 標準メッセージ利用のユースケース
本項では，今後の EDI 標準メッセージ利用のユースケースを検討した。同時に，中小企業 EDI メッセージモデルの利用の観点での位置付けを示した。

3.2.1.1 電機・電子業界及び業態の近い製造業（国内取引）主として，大企業〜中小企業，及び中小企業同士の EDI は，中小企業 EDI メッセージモ
デルを利用する。業態の近い製造業としては，機械業界が想定される。

バイヤー
サプライヤ

大企業

大企業
中小企業 EDI メッセージモデル

ECALGA フルセット

ASP（共通 XML/EDI ﾌﾚｰﾑﾜｰｸ対応）
中小企業 EDI メッセージモデル

ECALGA のフルセット

バイヤー
サプライヤ

図 3.1

大企業

中小企業

中小企業

電機・電子業界及び業態の近い製造業（国内取引）のユースケース（補足説明）
z

大企業間の接続は，ECALGA 標準（フルセット）を利用する。

z

大企業〜中小企業，及び中小企業同士の EDI は，中小企業 EDI メッセージモデルを利用する。

z

ASP は，企業間接続のハブ機能を持ち，共通のインタフェース仕様で接続する。共通インタフェース仕様なので，バイヤー／サプライヤ共に企業毎の個別対応の開発が不要になる。

z

各企業及び ASP サービスでの標準メッセージ変換はない。

3.2.1.2 電機・電子業界及び業態の近い製造業（国際取引）
国際取引には UBL サブセットを利用する。中小企業 EDI メッセージモデル⇔UBL 変換
は，共通 XML/EDI フレームワーク対応の ASP サービスが実施する。

―21―

バイヤー
サプライヤ

大企業

中小企業
中小企業 EDI メッセージモデル

中小企業 EDI メッセージモデル

標準メッセージ変換（中小企業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ⇔UBL）
UBL サブセット

バイヤー
サプライヤ

図 3.2

ASP
（共通 XML/EDI ﾌﾚｰﾑﾜｰｸ対応）

海外企業

電機・電子業界及び業態の近い製造業（国際取引）のユースケース（補足説明）
z

国内企業と ASP 間の接続は，中小企業 EDI メッセージモデルを利用する。

z

海外企業とは，国際標準メッセージである UBL を利用する。

z

ASP は，国内企業と海外企業間のハブ機能を持ち，標準メッセージの変換機能を持つ。

z

国内企業は，海外標準メッセージである UBL を意識せずに海外企業と接続ができる。

z

共通のインタフェース仕様なので，バイヤー／サプライヤ共に企業毎の個別対応の開発が不要になる。

3.2.1.3 業界間取引（直接取引）
受注側企業で標準メッセージ変換を実施する。
変換後の標準メッセージとして中小企業 EDI メッセージモデル又は UBL サブセット＋αが考えられる。
鉄鋼業界

バイヤー

石油化学業界

個別標準

個別標準

自動車業界
自動車個別仕様

・標準メッセージ変換（⇒中小企業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ＋α）（⇒UBL サブセット＋α）
・自社システム連携

サプライヤ

図 3.3

業界間取引（直接取引）のユースケース（補足説明）z

個別の EDI 標準を持つ業界間の取引では，サプライヤ（受注側）で標準メッセージ
変換機能を使い，自社の社内システム内に組み込み，直接取引を行う。

z

大企業のサプライヤが利用するユースケースである。

z

個別対応システムになるため，広い範囲で相互運用性を確保できるシステムモデル
でなく，効率的でない。
―22―

3.2.1.4 業界間取引（サプライヤが電機・電子・機械業界，ASP 利用）z

国内取引は，中小企業 EDI メッセージモデルを利用する。国際取引には UBL サブ
セットを利用する。

z

電機・電子・機械業界の製品の購入なので，中小企業 EDI メッセージモデルの利用が望ましい。若しくは，各業界用の中小企業 EDI メッセージモデルが考えられる。
例：鉄鋼用中小企業 EDI メッセージモデル，自動車用中小企業 EDI メッセージモ
デル，石油化学用中小企業 EDI メッセージモデル。

鉄鋼業界

バイヤー

石油化学業界

自動車業界

中小企業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ

中小企業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ

ASP
標準メッセージ変換（中小企業ﾒｯｾｰｼﾞﾓﾃﾞﾙ⇒UBL ｻﾌﾞｾｯﾄ） （共通 XML/EDI ﾌﾚｰﾑﾜｰｸ対応）
中小企業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ

サプライヤ

図 3.4

製造業

UBL サブセット

電機・電子
・機械業界

海外企業

業界間取引（サプライヤが電機・電子・機械業界，ASP 利用）のユースケース

3.2.1.5 業界間取引（一般，ASP 利用）z

ASP サービスが，各業界 EDI 標準メッセージから UBL（サブセット）を通して，各業界 EDI 標準メッセージへの変換を実施する。

z

EDI 標準メッセージ変換の ASP サービスニーズを元に ASP サービス化を行う。

z

バイヤー・サプライヤ毎の取引内容と標準メッセージなど具体的なユースケースの調査・検討が必要である。それぞれの業界などで検討が必要である。
鉄鋼業界

バイヤー

鉄鋼標準

石油化学業界
JPCA 標準

自動車業界

流通業界

自動車個別仕様JEDICOS 標準

標準メッセージ変換（各標準⇒UBL）（UBL⇒各標準）
鉄鋼標準

サプライヤ

図 3.5

鉄鋼業界

JPCA 標準JEDICOS 標準

石油化学業界

流通業界

ASP（共通 XML/EDI ﾌﾚｰﾑﾜｰｸ対応）

サービス業界

業界間取引（一般，ASP 利用）のユースケース

3.2.2 現状の EDI 取引
現状の EDI 取引における，業界 EDI 標準メッセージの利用方法の実際は以下となってい
―23―

る。
(1) 業界内取引z

各業界が策定している EDI 標準は，各業界の製品を業界内部で電子商取引するための標準である。

鉄鋼業界

石油化学業界

自動車業界

需要家

商社

自動車ﾒｰｶｰ

バイヤー

JISI 鉄鋼標準
JAMA
自動車標準
（EDIFACT）

JPCA
石油化学標準商社
JISI 鉄鋼標準

サプライヤ

鉄鋼ﾒｰｶｰ

石油化学ﾒｰｶｰ

図 3.6

自動車部品ﾒｰｶｰ

業界内取引の現状(2) 業界間取引（サプライヤが電機・電子業界）z

電機・電子業界が他業界から受注する場合は，明確な EDI 標準がなく，個別対応が多い。

石油化学業界

バイヤー

FAX

鉄鋼業界

電機・電子業界

自動車業界

個別標準

個別標準

通信業界

EIAJ

FAX

EIAJ

EDI ｼｽﾃﾑ 1

EDI ｼｽﾃﾑ 2

EDI ｼｽﾃﾑ 3

サプライヤ
受注ｼｽﾃﾑ

図 3.7

業界間取引（サプライヤが電機・電子業界）の現状(3) 業界内外の取引
z

業界内部の取引は，各業界 EDI 標準を利用している。

z

電機・電子業界は EIAJ を利用している。今後 ECALGA に移行する。

z

機械業界は EIAJ を利用している企業がある。ECALGA に移行可能と思われる。

z

電機・電子・機械部品取引は，現状でも EIAJ の利用が多い。ECALGA の利用が可能と思われる。
―24―

バイヤー

電機・電子業界

機械業界

鉄鋼業界

石油化学業界

自動車業界

ｾｯﾄﾒｰｶｰ

機械ﾒｰｶｰ

需要家・商社

商社

自動車ﾒｰｶｰ

EIAJ
サプライヤ

部品ﾒｰｶｰ

機械標準
EIAJ

JPCA

JISI

部品ﾒｰｶｰ

鉄鋼ﾒｰｶｰ

石油化学ﾒｰｶｰ

電機・電子・機械部品取引（EIAJ）

大手企業，中小企業

図 3.8

業界内外の取引の現状―25―

EDIFACT
部品ﾒｰｶｰ

3.3

中小企業 EDI メッセージモデルの標準構造

JEITA の ECALGA 標準をベースとした中小企業 EDI メッセージモデルを考察する。

3.3.1 各業界の EDI 標準メッセージのデータ項目と ECALGA の比較(1) 各業界の EDI 標準メッセージのデータ項目と ECALGA データ項目の比較
図 3.9 に，各業界の EDI 標準メッセージ（注文情報）のデータ項目と ECALGA データ項目の比較を示す。

ECALGA フルセット［注文情報，160 項目（ヘッダー＋本体）］

90%〜100%

電機・電子業界（30〜70 項目）

中小製造業（20〜40 項目）

80%〜100%

住宅産業標準（52 項目）

73%

50%〜6０%

機械業界（約 50 項目）

鉄鋼標準（54〜138 項目）

46%

石油化学標準（67 項目）

43%

自動車標準（135 項目）

中小製造業 EDI メッセージモデル（86 項目）

図 3.9

z

20%

100%

各業界の EDI 標準メッセージのデータ項目と ECALGA データ項目の比較

電機・電子業界の EDI 標準メッセージは，ECALGA フルセットのデータ項目に
ほぼ 100%含まれる。現状の電機・電子業界は，EDI 標準メッセージとして EIAJ
標準の利用が多いが，EIAJ 標準のデータ項目に企業個別のデータ項目を追加し―26―

て運用しているケースがあり，この追加項目は，ECALGA フルセットにも含まれていない。
z

中小製造業の EDI 標準メッセージのデータ項目は，20〜40 項目と少なく，
ECALGA フルセットのデータ項目に 80%〜100%含まれる。

z

機械業界の EDI 標準メッセージのデータ項目は，ECALGA フルセットのデータ
項目に 50%〜60%含まれる。

z

鉄鋼標準，石油化学標準，及び自動車標準は，各業界内での業界取扱い製品の
EDI 取引のための標準メッセージである。ECALGA フルセット（注文情報）にマッピングすると半数以下のデータ項目しかマッピング出来ない。

z

今回策定した中小製造業 EDI メッセージモデルは，86 項目（ヘッダー：3 項目，
本体：83 項目）であり，ECALGA フルセットに 100%含まれる。

参照データ：付表 4.1 業界標準メッセージと ECALGA の比較(2) 評価z

電機・電子業界は，中小製造業 EDI メッセージモデルの利用が可能である。企業特有の個別データ項目は極力追加しない方が EDI 相互運用性の高い広い範囲の EDI が可能となる。

z

中小製造業は，中小製造業 EDI メッセージモデルの利用が可能である。

z

機械業界は，中小製造業 EDI メッセージモデルの利用が可能である。必要に応じて，中小製造業 EDI メッセージモデルをベースにして，機械業界用の EDI
標準メッセージにカスタマイズできる。

z

住宅産業標準，鉄鋼標準，石油化学標準，及び自動車標準は，それぞれの業界内で有効な EDI 標準メッセージである。電機・電子・機械部品の調達には，中小製造業 EDI メッセージモデルの利用が可能である。

3.3.2 中小企業 EDI メッセージモデルの標準構造(1) 標準仕様
基本となる標準仕様は以下の 2 種とする。
z

標準メッセージのデータ項目表（スプレッドシート）z

XML Schema*

XML Schema*：XML スキーマ言語は，各データ項目の属性（必須／任意の区別，
値の型，出現回数など）を定義する言語である。XML のスキーマ言語として，DTD，
XML Schema，RelaxNG があるが，現状では XML Schema が主流となっており，多くの標準化団体及び業界で採用されている。
(2) 標準構造の策定方針
z

主として電機・電子業界と機械業界を対象とした標準として，「中小製造業 EDI
メッセージモデル」とする。
―27―

（理由）
z

電子業界と機械業界の双方を対象にすることで，EDI メッセージデータが多少冗長になるが，コンピュータ・インターネットの高性能化のトレンドを考慮す
ると大きな問題とならない。仕様を一本化したメリットを重視する。

z

鉄鋼標準，石油化学標準，自動車標準は，それぞれの業界内の EDI 標準であり，取引内容はそれぞれの業界の製品である。このため，データ項目を重ね合わせることは困難である。無理して統一化しない方が実際的である。

3.3.3 CII 標準と EIAJ 標準採用の業界団体
CII 標準と CII 標準に準拠した EIAJ 標準は，多くの業界で採用されている。EIAJ 後継の ECALGA 標準は，多くの業界で採用されると推定できる。

表 3.1

CII 標準と EIAJ 標準採用の業界団体

名称

略称（財）建設業振興基金（社）鋼材倶楽部（社）住宅産業情報サービス
石油化学工業協会
石油連盟
中小企業総合事業団
電気事業連合会（社）日本アルミニウム協会（社）日本ガス協会（社）日本広告業協会（社）日本電気計測器工業会（社）日本電機工業会（社）日本電気制御機器工業会（社）電子情報技術産業協会（社）日本電線工業会

CI-NET（社）日本パーソナルコンピュータソフトウェア
協会（社）日本配電盤工業会（社）日本半導体製造装置協会（社）日本物流団体連合会物流 EDI センタ
ー（社）日本貿易会

JPSA

JPCA
PAJ
JASMEC
FEPC
JGA
JAAA
JEMIMA
JEMA
NECA
JEITA
JCMA

標準の種
類
CII
CII
CII
CII
CII
CII
CII
CII
CII
CII

標準の名称
（BPID）
CINT
JISI
HIIS
JPCA
PAJE
TIRA
FEPC
JALF
JGAS
WAVE

CII

JEMA

CII
CII

EIAJ
JCMA

隣接業界の標
準

EIAJ
EIAJ
EIAJ
EIAJ,FEPC ，
CPSD
HWSW
EIAJ，FEPC
EIAJ

CII

TRPT，JTRN
JISI ， JPCA ，
EIAJ，JALF

CII
CII/XML
CII
CII
CII
CII
CII
CII

（社）日本ロジスティクスシステム協会（社）日本航空宇宙工業会
食品業界企業間情報システム研究会（社）日本ドウ・イット・ユアセルフ協会（社）日本新聞協会広告委員会
通信資材 EDI 推進部会
小型コンピュータ業界 EDI 取引委員会（社）電信電話工事協会

―28―

JTRN
SJAC
VMDI
JDIY
NEWS
CPSD
HWSW
TFCA

出典：JEDIC 会員及び EDI 推進団体の状況（2001-04-27）

3.3.4 （社）日本機械工業連合会の団体会員
機械業界は，（社）日本機械工業連合会の団体会員の工業会である。（社）日本機械工業連合会には多くの工業会が含まれる。JEITA［（社）電子情報技術産業協会］が日本機
械工業連合会の会員であり，JEITA の EIAJ 標準，ECALGA 標準の利用の可能性が高い。

表 3.2（社）日本機械工業連合会の団体会員

有限責任中間法人カメラ映像機器工業会

情報通信ネットワーク産業協会(社) 水門鉄管協会

全国作業工具工業組合(社) 全国木工機械工業会

ダイヤモンド工業協会

超硬工具協会(社)電子情報技術産業協会(社)日本鋳物工業会(社)日本印刷産業機械工業会(社)日本エレベータ協会(社) 日本計量機器工業連合会

日本機械鋸・刃物工業会(社)日本航空宇宙工業会(社) 日本建設機械工業会(社) 日本工作機械工業会

日本工具工業会(社)日本産業機械工業会(社)日本産業車両協会(社)日本工作機器工業会

日本試験機工業会(社) 日本自動車部品工業会(社)日本自動車工業会(社) 日本精密測定機器工業会(社)日本食品機械工業会(社) 日本造船工業会(社)日本繊維機械協会

日本チエーン工業会(社) 日本鍛圧機械工業会(社)日本電気計測器工業会(社) 日本鉄道車輌工業会(社) 日本電気制御機器工業会(社)日本電機工業会(社)日本時計協会(社)日本ねじ工業協会(社) 日本農業機械工業会(社)日本バルブ工業会(社) 日本ばね工業会(社) 日本歯車工業会(社)日本舶用工業会(社)日本フルードパワ−工業会(社)日本分析機器工業会(社) 日本ベアリング工業会(社)日本防衛装備工業会(社)日本縫製機械工業会(社)日本ロボット工業会(社)日本包装機械工業会(社) 日本冷凍空調工業会(社)日本陸用内燃機関協会(社)ビジネス機械・情報システム産業協会

3.4 中小企業 EDI メッセージモデル（注文情報）の策定
3.4.1 電機・電子業界の Web-EDI 画面から ECALGA へマッピングの結果
1. 大手の電機・電子メーカー企業（11 社）の Web-EDI 画面のデータ項目数は，30 個〜70 個である。ECALGA 注文情報のビジネスドキュメント本体（ビジネスドキュメ
ントヘッダを除く）の 135 項目の 22%〜52%である。大手の電機・電子メーカー企業―29―

（11 社）の Web-EDI 画面は，殆どが EIAJ 標準準拠であり，ECALGA の注文情報のデータ項目にマッピングできる。
2. 大手の電機・電子メーカー企業（11 社）の Web-EDI 画面のデータ項目は共通化・層別できる。
◎［共通項目となっている情報項目（8 社以上が利用）］：16 項目○［準共通項目となっている情報項目（5 社以上が利用）］：25 項目△ ［共通でない情報項目（1 社以上が利用）］：37 項目
合計：78 項目
3. ECALGA の注文情報の仕様として必須項目になっておりながら，以下のデータ項目
は使用実績がない。EIAJ になく，ECALGA で追加されたデータ項目である。
z

発注者コード管理組織z

受注者コード管理組織

4. EIAJ のデータ項目「情報区分コード」が，ECALGA のデータ項目にない。
z

EIAJ の「情報区分コード」（項目 No.：00002）は，注文に関して，内示注文，確定注文，変更注文，注文取消し，注文打切を識別する情報である。

z

ECALGA では，ビジネスプロセスを実現する仕組みとして，ビジネスコラボレ
イションの概念を導入し，それを実現する仕組みを組み込んだ。

z

内示注文，確定注文，変更注文，注文取消し，注文打切の各ビジネスプロセス
は，ビジネストランザクションとビジネスアクションがそれぞれ異なる。

z

それぞれのビジネストランザクションとビジネスアクションについては，ユニ
ークな ID を設定している。

z

ECALGA のビジネスドキュメント（標準メッセージ）では，これらの情報を，「ビジネスドキュメントヘッダ」の「ビジネストランザクション ID」と「ビジネスアクション ID」に持たせている。EDI の標準メッセージ処理アプリケーシ
ョンは，この ID を参照することにより，内示注文，確定注文，変更注文，注文
取消し，注文打切を識別できる。

z

EIAJ の「情報区分コード」に対応する ECALGA のデータ項目は，「ビジネスドキュメントヘッダ」にある「ビジネスアクション ID」と理解した方が良い。

z

なお，意味が似ているデータ項目として「訂正コード」があるが，これはデー
タ内容そのものが間違っている場合に，ビジネスドキュメントを再送するときに使用するデータ項目である。

5. 自由使用欄［X(100)］は，各社で自由に定義して使用している。便利なデータ項目ではあるが，別の観点では相互運用性を損なうデータ項目である。今後の課題と思われる。

3.4.2 機械業界の EDI 標準メッセージの概要と ECALGA へのマッピングの結果
3.4.2.1 日本工作機械工業会
z

工業会 A 社の調達 Web-EDI は，EIAJ 準拠である。

z

B 社の EDI 取組み：国内メーカーとの受発注業務は国内標準 EDI の CII 標準（EIAJ）―30―

で，また同社の海外生産拠点等，社内でのデータのやり取りは国際標準 EDI のEDIFACT で行っている。
z

資料：平成 14 年度工作機械分野の電子商取引のモデル化に関する調査研究報告書（平成 15 年 3 月，日本工作機械工業会発行）

3.4.2.2 ビジネス機械・情報システム産業協会z

複数の企業の調達 Web-EDI は，EIAJ 準拠を利用している。

3.4.2.3 その他の工業会(1) 以下の工業会は EIAJ 標準を利用している。
z（社）電子情報技術産業協会（JEITA）

z（社）日本電機工業会（JEMA）

z（社）日本電気計測器工業会（JEMIMA）

z（社）日本電気制御機器工業会（NECA）(2) 以下の工業会は，独自の業界標準を利用している。
z（社）日本航空宇宙工業会（SJAC）

資料：JEDIC 会員及び EDI 推進団体の状況（2001-04-27，電子商取引推進センター）
備考：本項での機械業界の定義は，（社）日本機械工業連合会の団体会員となっている工業会である。

3.4.2.4 機械業界企業の Web-EDI 画面から ECALGA へマッピングの結果
z

注文情報のデータ項目数は，約 50 項目である。

z

EIAJ 準拠でも，生産管理に関する機械業界特有のデータ項目を追加している。例：
組立工程，ステーション No.，出庫先，組付外注コード，管理区分，ロット No.，日程，工程符号，他

z

大手の機械業界企業（2 社）の Web-EDI 画面のデータ項目は共通化・層別できる。
◎［共通項目となっている情報項目（2 社以上が利用）］：13 項目○［準共通項目となっている情報項目（1 社以上が利用）］：27 項目
合計：40 項目

3.4.3 中小製造業の Web-EDI 画面から ECALGA へマッピングの結果
TAMA 協会の中小製造業の Web-EDI 画面のデータ項目を調査し，ECALGA 注文情報へマッピングした。
z

データ項目数は，20〜40 項目と少ない。

z

データ項目は，ほぼ ECALGA のデータ項目に包含される。

z

中小製造業（5 社）の Web-EDI 画面のデータ項目は共通化・層別できる。
◎［共通項目となっている情報項目（3 社以上が利用）］：15 項目―31―

○［準共通項目となっている情報項目（2 社以上が利用）］：14 項目△［共通でない情報項目（1 社以上が利用）］：23 項目
合計：52 項目

3.4.4 中小企業 EDI メッセージモデルの策定(1) 策定方法
・ 電機・電子業界，機械業界，及び中小製造業で現状運用されている Web-EDI のデータ項目を調査して，「中小製造業 EDI メッセージモデル」を策定する。
・ 複数企業の Web-EDI のデータ項目から，必須項目，準必須項目，及び任意項目を策定する。
(2) 中小製造業 EDI メッセージモデルの検討
電機・電子業界，機械業界，及び中小製造業で現状運用されている Web-EDI のデータ項目の共通データ項目の OR（論理和）を取って，中小製造業 EDI メッセージモ
デルのデータ項目とした。中小製造業 EDI メッセージモデルを，付表 4.2 に示す。
中小製造業 EDI メッセージモデルのデータ項目は以下となった。
◎［共通項目となっている情報項目］：15 項目○［準共通項目となっている情報項目］：27 項目△［共通でない情報項目］：41 項目
合計：83 項目
これらのデータ項目の性格を以下とした。
◎：必須：必ず使用する。
○：準必須：使用することが望ましい。
△：任意：必要に応じて使用する。
(3) 中小製造業 EDI メッセージモデルの策定オプション
以下の 2 種のオプションがある。
① 必須項目（15 個），準必須項目（27 個），及び任意項目（41 個）の合計 83 項目
を中小企業 EDI メッセージモデルとする。
z

この標準メッセージは，大手電機・電子会社，機械業界，及び中小製造業の調達 Web-EDI のデータ項目を全て包含している。

z

任意項目（41 個）は，1 社又は 2 社が利用している程度であり，冗長となる。

② 必須項目（15 個），準必須項目（27 個）だけの合計 42 項目を中小製造業 EDI メ
ッセージモデルとする。
z

任意項目（41 個）は今回の調査結果で，1 社又は 2 社程度であり，簡易版の中小企業 EDI メッセージモデルに含めない方が実際的と思われる。

(4) 中小製造業 EDI メッセージモデルの策定z

上記のオプション①を採用した。
―32―

z

但し，標準画面の設計では，必須項目（15 個），準必須項目（27 個）の範囲で設計する。必要に応じて，個別の業界・会社でカスタマイズが可能である。

z

中小製造業 EDI メッセージモデルのデータ項目表を「付表 4.2 中小製造業 EDI
メッセージモデル（注文情報）」に示す。

3.5 中小製造業 EDI メッセージモデルの使われ方
3.5.1 電機・電子業界，機械業界内の商取引(1) 現状の商取引z

大企業から中小企業への発注は，EIAJ 準拠であるが，利用しているデータ項目
は個別対応である。Web 画面も統一性がない。取引頻度が少ない取引相手とはFAX で商取引している。

z

中小企業同士，及び中小企業から大企業への発注は FAX が主体である。

大企業

バイヤー
EIAJ 準拠
一部 FAX
サプライヤ

大企業（部品の調達）

中小企業

サプライヤ

FAX 主体 （原材料，部品の調達）

中小企業

バイヤー

バイヤー
FAX 主体（原材料，部品の調達）
一部個別 EDI
サプライヤ

図 3.10

中小企業

現状の電機・電子業界，機械業界内の商取引(2) 今後の商取引z

大企業の発注は，序々に ECALGA に移行すると思われる。

z

大企業の発注でも，中小製造業 EDI メッセージモデルの利用は可能である。理由：中小製造業 EDI メッセージモデルの策定は，大手の電機・電子メーカー10
社以上の調達 Weｂ-EDI のデータ項目を集約している。

z

中小企業同士，及び中小企業から大企業への発注は中小製造業 EDI メッセージ
モデルの利用が相応しい。

―33―

バイヤー

大企業

大企業

ECALGA 準拠（部品の調達）
中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
サプライヤ

サプライヤ

中小製造業
（原材料，部品の調達）
EDI 標準ﾒｯｾｰｼﾞﾓﾃﾞﾙ

中小企業

中小企業

バイヤー

バイヤー
中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ （原材料，部品の調達）

サプライヤ

図 3.11

中小企業

今後の電機・電子業界，機械業界内の商取引

3.5.2 業界間の商取引
z

電機・電子業界以外の業界（例：機械，鉄鋼，自動車）でも，電機・電子部品の調達は，現在でもかなりの割合で EIAJ 標準準拠の個別 EDI で取引されている。

z

今後，適切に ECALGA 及び中小製造業 EDI メッセージモデルを PR・指導することにより，電機・電子・機械部品の調達の際は，ECALGA 又は中小製造業 EDI メ
ッセージモデルへ移行することが可能である。

バイヤー

電機・電子業界

機械業界

鉄鋼業界

石油化学業界

自動車業界

ｾｯﾄﾒｰｶｰ

機械ﾒｰｶｰ

需要家・商社

商社

自動車ﾒｰｶｰ

EIAJ 準拠ECALGA 準拠
中小製造業
EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
サプライヤ

部品ﾒｰｶｰ

機械標準
EIAJ 準拠
中小製造業
EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
部品ﾒｰｶｰ

JPCA

JISI

鉄鋼ﾒｰｶｰ

石油化学ﾒｰｶｰ

EIAJ 準拠ECALGA 準拠
中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
（電機・電子・機械部品の調達）大手企業，中小企業

図 3.12

業界間の商取引―34―

EDIFACT

部品ﾒｰｶｰ

3.6

EDI 標準メッセージ種

以下の EDI 標準メッセージの利用実績が高い。
z

所要計画情報z

見積依頼情報z

見積回答情報z

予約注文情報z

確定注文情報z

注文請け情報z

納期確認情報z

納期回答情報z

納入指示情報

z

出荷情報

z

入荷情報

z

検査情報

z

検収情報

z

買掛明細情報資料：付表 4.3

Web-EDI で利用されている EDI 標準メッセージ種

本章で述べたように，中小製造業 EDI メッセージモデルとして，「注文情報」の EDI
標準メッセージのみを策定した。実際の EDI 取引では，上記の EDI 標準メッセージが多く利用されており，これらの中小製造業 EDI メッセージモデルの策定が必要である。但し，
EDI 標準メッセージの基本は注文情報であり，中小製造業 EDI メッセージモデル（注文情報）は，注文情報以外の中小製造業 EDI メッセージモデルの策定に役立つ。

―35―

4 EDI 受発注アプリケーション画面
本設計・導入ガイドでは，EDI 用の画面として EDI 受発注プロセスのアプリケーション
画面を設計した。本章では，EDI 受発注アプリケーション画面に関して，設計方針と具体的な画面仕様を説明する。EDI 受発注アプリケーション画面のベースとなる EDI 標準メッセージは，3 章で策定した中小製造業 EDI メッセージモデル（注文情報）である。

4.1

画面設計方針(1) 画面上のデータ項目に関する方針z

画面に表示するデータ項目は，中小製造業 EDI 標準メッセージ（注文情報）の必須項目と準必須項目とする。

z

任意項目の表示が必要の場合は，必要度に応じてカスタマイズする。

(2) 画面表示に関した方針z

Web ブラウザのような表示とする。

z

基本的には 1 画面に収まる設計とする。

z

コード類は，極力コードの意味に変換して表示する。

z

画面上の各データ項目配置のデザインは，現状運用されているの複数のWeb-EDI 画面を参考にして設計する。左側を合わせたデザインとした。

(3) 項目選択，データ入力に関した方針
z

メニュー：メニューリストを表示し，所望の項目をクリックすることにより選
択する。

4.2

z

項目選択：プルダウンリストにより選択する。

z

日付入力：「YYYYMMDD」又は「YYYY/MM/DD」とする。

z

起動：釦をクリックすることにより行う。

注文情報，納期確認／回答のビジネスプロセス
発注者

ビジネスドキュメント

受注者

発注

注文情報

注文情報の受信注文請け情報回答処理
納期回答情報

納期確認

図 4.1

納期確認情報

納期確認情報の受信

納期回答情報

納期回答

注文情報，納期確認／回答のビジネスプロセス
―36―

z

受注者が注文情報を受信した後処理として，注文請け情報を返信しても，納期回答
情報を返信しても良い。

z

発注者は，必要に応じて納期確認情報を発信できる。

4.3 画面設計
4.3.1 メインメニューz

情報種類毎の画面を表示するためのメニュー画面である。

z

着信件数：全体の件数。（照会済み件数＋新着件数）

z

新着件数：照会していない件数。

z

回答済件数：回答を発行した件数。

4.3.2 注文情報一覧（受注者用）
z

現状の複数の Web-EDI 画面を調査して，多くの事例で使われているデータ項目を
設定した。

z

簡単な検索機能を準備した。検索条件：照会状況，注文日，納期。

z

注文請け回答の操作簡略化のために一括回答機能を準備した。複数案件を選択して受諾の請け回答を発行できる。

4.3.3 注文情報明細（受注者用）(1) 注文情報明細画面① この画面は，注文情報一覧の「No.」釦をクリックすることで表示する。
② Web 画面の 1 ページでの表示の設計とした。
③ データ項目をグループ化して，タイトルを表示した。
④ データ項目は，中小製造業 EDI メッセージモデル（注文情報）の必須項目と準必須
項目としている。
（例外）
z

通貨コード（任意）を表示項目に入れた。理由：海外（特にアジア，中国，
韓国，台湾）のサプライヤとの取引で必要と思われる。

⑤ データ項目の桁数は，基本的に ECALGA 仕様に準拠の方針で，実態を考慮したデザインとしている。
⑥ ECALGA 仕様では，納入条件・納期を複数件（1〜31 件）指定できる仕様である。
実態を考慮して 5 件分のデザインとしている。6 件以上ある場合は，「全件」
釦をクリックすることにより全件表示する。
⑦ コード類は，画面表示時に理解し易い文字に変換して表示する。
z

情報区分：ビジネスドキュメントヘッダのビジネスアクション ID から変換して表示する。例：確定注文，変更注文，注文取消z

訂正コード：新規，変更，取消z

決済条件：基本契約通り，別途協議による，交付書面によるz

通貨：日本円の場合はブランク。米国ドルの場合は「USD」と表示。
―37―

⑧ 納期回答z

この画面の「納期回答」釦をクリックすることにより，納期回答情報画面に移行できる。

⑨ 添付ファイルz

ECALGA の注文情報仕様ではファイルを添付しない仕様になっている。

z

他の EC 調達サイトの事例（例：アリバの電子購買ネットワーク），及びファイル（図面など）添付のニーズが多いことから，ファイル添付の機能を組み込んだ。

z

ECALGA の技術仕様としては，添付ファイルの技術仕様を決めている。ebMSの ebXML ペイロードドキュメントに，ビジネスドキュメント本体とは別に添付ドキュメントを格納する。添付ドキュメントのアーカイブ形式として，
PDF 形式と ZIP 形式を推奨している。

(2) 注文情報回答のサブ画面z「注文請け情報」を発行するための画面である。

z「条件付き受諾」と「拒否」を選択した場合は，本注文情報の契約は成立しない。別途，電話などでネゴし，修正した注文情報が発行される。

z「条件付き受諾」の受諾の対象項目としては，単位，単価，注文数量，納期，
通貨コード，単価（外貨）などがある。「条件付受諾」での条件は，注文情報
回答では条件提示しない。オフラインの電話などでネゴする。

(3) 添付ファイルのサブ画面
ファイル添付方式は，以下の 2 種を選択可能とした。
z

ファイル所在 URL：ファイル所在の URL を指定する。必要な時点で受注者がダウンロードする。図面ファイルなど大容量の場合は，この方式を選択する。
一般的には，発注者のホームページなどを利用する。

z

添付ファイル：注文情報に添付する方式。E-mail の添付ファイルと同じ操作方法とする。

(4) ダウンロードのサブ画面z

ダウンロードは，注文情報明細でも注文情報一覧画面のどちらからでも操作可能とした。理由：現状の Web-EDI の多くはこの方式となっている。

z

ダウンロードで，データ形式を「XML」と「CSV」を指定できるようにした。

4.3.4 納期確認情報一覧（受注者用）
z

現状の複数の Web-EDI 画面を調査して，多くの事例で使われているデータ項目を
設定した。

z

簡単な検索機能を準備した。検索条件：照会状況，注文日，納期。

―38―

4.3.5 納期確認情報（発注者用）／回答情報（受注者用）(1) 納期確認情報（発注者用）
z

発注者が納期確認情報を発信する画面である。

z

分納毎に，発注者の希望する納期と数量を「確認納期（回答納期）」欄と「確認数量（回答納期）」欄に記入する。

z

他の基本情報を入力して「発行」釦をクリックする。

(2) 回答情報（受注者用）
z

この画面を元に，受注者が納期回答を発信することが出来る。

z

受注者の納入可能な納期と数量を「確認納期（回答納期）」欄と「確認数量（回答納期）」欄に記入する。

z

確認マークとして，「希望通り」又は「希望通りでない」を選択設定する。

z

最後に「回答」釦をクリックする。

4.3.6 納期回答情報（受注者用）
z

受注者は独自に納期回答を発行できる。

z

この画面は，注文情報明細画面の「納期回答」釦をクリックすることにより表示する。

z

注文情報から得られているデータ項目（基本情報，取引方法，取引物品，納期）は，注文情報から自動的に転記される。この画面で入力すべき項目は，回答納期，回答
数量，及び確認マークの 3 種のみである。

z4.4

所定の内容を記入し，「回答」釦をクリックして発行する。

印刷

z

画面の印刷は Web ブラウザの印刷機能を利用して印刷する。

z

特定の帳票印刷（例：指定納品伝票）は，別の機能を起動して印刷する。

4.5

画面デザイン

次ページから画面デザインを示す。

―39―

メインメニュー（受注者用）
情報種類

着信件数

新着件数

回答済件数

注文情報

20

7

10

納期確認

5

2

1

閉じる

戻る

・情報種類：クリックすると所定の一覧画面を表示する。

1

注文情報一覧（受注者用）
照会状況

全件

注文日

2004/10/20 〜 2004/10/20

No.

選 情報
択 区分

1
確定
2 レ 確定3 レ 変更
4
確定
5
確定
6
確定
7
確定
8
取消
9
確定
10
確定
一括回答

（全件，未照会，照会済）
納期

2004/10/20 〜 2004/11/20

状況
注文
注文金額 照 請け 納期
数量会 回答 回答
2004/08/20 2004/08/30 123456
123-123456789 S60EDT7H
1,200
12,000 済 済 済
2004/08/21 2004/09/10 256000 123999 ABC-123-245 ABC12345-1234
5 500,000 済 済
XQW12345-AWS
2004/08/22 2004/09/20 123456
123-AWS
1,250
12,500 済
XQW12345-AWS1
2004/09/10 2004/10/20 123456
123-AWS1700
6,000
2004/09/15 2004/10/20 256000 256999 ABC-123-789 ABC12345-1234
12 1,326,000
2004/09/20 2004/10/20 123456
133-SWED2XQW12345-SWED2 5,000
56,0002004/10/03 2004/10/20 123456
123-FRTG
XQW12345-FRTG
2,000
26,0002004/10/04 2004/11/20 123456
123-FRTF12
XQW12345-FRTF12 1,200
15,0002004/10/07 2004/11/20 123456
123-JUIJ
XQW12345-JUIJ
2,500
30,0002004/10/20 2004/11/20 123456
123-FRDF
XQW12345-FRDF
120
500
注文日

納期

ダウンロード

発注者コード 発注者品名ｺｰﾄﾞ

一括ダウンロード

戻る・No.：クリックすると注文情報明細画面を表示する。
・選択：ダウンロードしたい案件を指定する。
・状況：照会，受け回答，納期回答の状況を表示する。
・取込：ダウンロード状況を表示。
・添付：添付ファイルの有無を表示。

品名（品名仕様）

閉じる

2

―40―

添 取
付 込

?

?

済
未
未
未
未
未
未
未
未
未

注文情報明細（受注者用）
基本情報

123

訂正コード

新規

変更注文区分

123

情報区分

確定

2004/10/20

注文番号99,999,999,999

発注者

発注者コード113032 222222

発注者

発注者企業名 中小製造業㈱取引方法 コック区分

取引物品

発注者品名コード

HHIN_CODE_0001

製造番号

品名（品名仕様）

HINMEI SIYOU (30)

版数

123

検査区分

注文数量

200,000,000

受渡場所

DELIVERY

納入条件

発注者ﾊﾞｰｺｰﾄﾞ情報

金額条件

注文金額

注文日

データ処理No.

データ作成日2004/10/20

発注部門コード

仕様書有無

11234560単価区分 1 単価
場所名

BASYOMEI

111122223333444455556666

555,555,555

消費税額

22,222,222

購買担当

支給区分

1

直納区分

単位 PC

受渡場所（工場，棟，入口）

発注者備考

AAABBBCCCDDDEEE

577,777,777

決済条件

基本

課税

1

自由使用欄 AAAAABBBBBCCCCCDDDDDEEEEEFFFFFGGGGGIIIII (100)
備考

AAAAABBBBBCCCCCDDDDDEEEEEFFFFFGGGGGIIIII (30)納入条件，納期

No.
納期
1
2004/11/15
2

納入指示数量200,000,000

納品キー番号
111112222233333 (23)

3
4
5

全件

3
注文請け回答

納期回答

添付ファイル

ダウンロード戻る

閉じる

注文請け回答のサブ画面

注文情報回答受諾

拒否

条件付き受諾

閉じる

添付ファイルのサブ画面

ファイル所在URL

http://www.abc.co.jp/File/

添付ファイル■製品仕様１■製品仕様２添付ファイルの保存

4

―41―

1

7W5423

消費税区分 不含 通貨

123,456

合計額

1

SEIZOU BANGOU 11112222

材料・規格・寸法漢字

KOBAITANTOU

ダウンロードのサブ画面

ダウンロードのデータ形式選択
XML

CSV
閉じる

OK

名前を付けて保存
保存する場所

Down Load Folder

ファイル名

AAA.CSV

ファイルの種類

全てのファイル（＊，＊）

保存
キャンセル

5

納期確認情報一覧（受注者用）

照会状況

全件

注文日

2004/10/20 〜 2004/10/20

No.

注文日

（全件，未照会，照会済）

納期

発注者コード

納期
注文番号

2004/10/20 〜 2004/11/20
発注者品名ｺｰﾄﾞ

品名（品名仕様）

1 2004/08/20 2004/08/30 123456
99,999,999,999 123-123456789 S60EDT7H
2 2004/08/21 2004/09/10 256000 123999 11,222,333,444 ABC-123-245 ABC12345-1234
3
4
5
6
7
8
9
10
戻る

注文
状況
数量
1,200 回答済
5 未回答

閉じる

・No.：クリックすると納期確認情報画面を表示する。

6

―42―

納期確認情報（発注者用）／回答情報（受注者用）
基本情報

注文日

2004/10/20

注文確認情報

納期確認日

2004/11/20

取引方法

コック区分

1

取引物品

発注者品名コード

HHIN_CODE_0001

品名（品名仕様）

HINMEI SIYOU (30)

版数99,999,999,999

納期回答要求日

支給区分

1

材料・規格・寸法

123

注文数量

注文番号

直納区分

2004/11/30

1
製造番号

SEIZOU BANGOU 11112222

7W5423単位

200,000,000

PC

備考

AAAAABBBBBCCCCCDDDDDEEEEEFFFFFGGGGGIIIII (30)

納入実績・
累計数量

合計納入数量
No.
1
2
3
4
5

納期
2004/12/15
2004/12/15

発行／回答

戻る

納入条件，納期

納入累計数量200,000,000

199,994,000

確認納期（回答納期）
2004/11/30
2004/12/15

未納入数量

確認数量（回答数量）
1,000
5,000

6,000

確認マーク
■
■

閉じる

7

納期回答情報（受注者用）
基本情報

注文日

2004/10/20

取引方法

コック区分

1

取引物品

発注者品名コード

HHIN_CODE_0001

品名（品名仕様）

HINMEI SIYOU (30)

版数

123

注文数量
備考

注文番号

支給区分

1

材料・規格・寸法200,000,000

99,999,999,999

直納区分

1
製造番号

SEIZOU BANGOU 11112222

7W5423単位

PC

AAAAABBBBBCCCCCDDDDDEEEEEFFFFFGGGGGIIIII (30)納入条件，納期

No.
1
2
3
4
5

回答

納期
2004/11/15
2004/11/15

戻る

回答納期
2004/11/15
2004/12/15

回答数量1,000,000
199,000,000

確認マーク
■希望通り
■希望通りでない

閉じる

8

―43―

5 認証方式と企業識別
今後の企業間取引にインターネットが全面的に利用される方向が明確となってきたが，企業間取引に要求されるセキュリティと信頼性をインターネット上で確保するためには特別の考慮が必要になる。すでに大企業相互間のインターネット EDI に関しては国際標準規格類も整備され，実利用が可能なサービスも提供され始めており，実用化のレベルに到達している。
しかしながらこれらのサービスは大企業の利用を想定しているために，中小企業がイン
ターネット EDI を利用するためにはいくつかの課題が残されている。本章はセキュリティの基本になる認証方式と企業識別方式について，コスト面や取扱い容易さ等を踏まえて中小企業向けインターネット EDI として利用可能な方式の設計ガイドを示す。

5.1 前提条件と検討テーマ
インターネット EDI は現在多方面に利用され始めており，その利用形態に応じて利用されるセキュリティ方式は異なる。現在インターネット利用におけるセキュリティは普及の途についたところであり，各種のセキュリティ方式が混在して利用されている状況にある。
従って本設計ガイドにおいては将来における理想像を示すと共に，今後のインターネット
EDI 普及の中間過程におけるセキュリティ方式の選択肢についても提示する方針とした。
インターネット EDI は今後次の区分で利用が広がってゆくと予想されている。
z

政府調達，電子申請（G2B）z

行政個人サービス（G2C）z

個人相互間取引（C2C）z

企業間取引（B2B）z

企業対個人間取引（B2C）

本章は企業間電子商取引（B2B）に焦点を絞った認証方式と企業識別方式についての調査検討と設計ガイドである。
認証方式と企業識別に関する主な検討テーマとして以下がある。
(1) 認証方式に関係する検討テーマ
・ 企業認証方式（ID・パスワードと電子証明書）
・ 電子署名(2) 企業識別に関する検討テーマ
・ 商用の企業識別コード
・ その他の企業識別方式

5.2 認証方式と企業識別方式の動向
認証方式と企業識別方式に関して，その動向を概観する。
本設計・導入ガイドは，インターネット EDI の設計・導入ガイドであり，主体として B2B
電子商取引が含まれる。インターネット EDI の技術動向は，B2B 電子商取引に加えて G2B
及び G2C の電子商取引の動向も密接に関係するので，両者の動向を調査した。
―44―

5.2.1 政府関係
5.2.1.1 政府の認定認証業務
政府（総務省）は，特定認証業務を認定している。
「電子証明及び認証業務に関する法律」が 2001 年 4 月 1 日に施行された。また，認証業
務の内一定の水準を充たすものは，政府の認定を受けることができる制度が導入されている。
認証業務（電子署名が本人のものであることを証明する業務）の内，法律で定める一定の基準（本人確認方法等）を満たす業務を主務大臣（総務大臣，法務大臣，経済産業大臣）が認定できることとし，認定を受けた業務についてその旨の表示ができるほか，認定の要件，認定を受けた者の義務等を定めている。
主務大臣（総務大臣，法務大臣，経済産業大臣）の指定を受けて，主務大臣に代わって
当該調査の業務を行う機関を「指定調査機関」と言う。指定調査機関として，「（財）日本品質保証機構」が指定されている。
出典：電子署名及び認証業務に関する法律の施行について
http://www.soumu.go.jp/joho_tsusin/top/ninshou-law/law-index.html
総務省が認定している認証業務を，表 5.1

電子署名及び認証業務に関する法律に基づく認定認証業務一覧に示す。この認証業務サービスは，総務省・経済産業省関係の電子申請業務に利用することはできるが，法務省関係の登記業務では利用できない。
出典：http://www.soumu.go.jp/joho_tsusin/top/ninshou-law/d-nintei.html

表 5.1

電子署名及び認証業務に関する法律に基づく認定認証業務一覧（総務省 HP，2004-12-14 現在）
特定認証業務の名称

業務を行う者の名称

1
2
3

AccreditedSign パブリックサービス２
株式会社日本電子公証機構認証サービス iPROVE

日本認証サービス株式会社
株式会社日本電子公証機構

ＣＥＣＳＩＧＮ認証サービス

株式会社コンストラクション・イーシー・ドットコム

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

セコムパスポート for Ｇ−ＩＤ
ＡＯＳｉｇｎサービス
e-Probatio PS サービス
ＴＯｉＮＸ電子入札対応認証サービス
CWJ 電子入札対応認証サービス
ＴＤＢ電子認証サービス TypeA
ビジネス認証サービスタイプ１
電子入札コアシステム用電子認証サービス
信金中央金庫 電子認証サービス
全国社会保険労務士会連合会認証サービス
CTI 電子入札・申請届出対応 電子認証サービス
よんでん電子入札対応認証サービス
AccreditedSign パブリックサービス１
ＭＪＳ電子証明書発行サービス
税理士証明書発行サービス

セコムトラストネット株式会社
日本電子認証株式会社
エヌ・ティ・ティ・メディアサプライ株式会社
東北インフォメーション・システムズ株式会社
株式会社サイバーウェイブジャパン
株式会社帝国データバンク
日本商工会議所
ジャパンネット株式会社
信金中央金庫全国社会保険労務士会連合会
株式会社中電シーティーアイ
四国電力株式会社
日本認証サービス株式会社
株式会社ミロク情報サービス
日本税理士会連合会―45―

19 Secure Contract Support Service
20 BLADE クライアント証明書発行サービスタイプＧ１
21 日本司法書士会連合会認証サービス

リコーリース株式会社
エヌ・ティ・ティ・コミュニケーションズ株式会社
日本司法書士会連合会

5.2.1.2 総務省（G2C，G2B）
総務省の汎用受付システムにおいて，重要な申請（例：国民年金加入・喪失届，国民健康保険加入・脱退届など）は，電子証明書を必須とする指針を出している。
汎用受付システムにおける受付時の本人確認手段としての指針を，表 5.2 汎用受付シス
テムにおける本人確認手段の指針に示す。
2002 年 3 月 27 日から，10 の行政手続（例：ファクシミリやテレックスなどの非標準機能提供者コードの指定の申請，ITU-T 勧告に準拠する国内標準の作成及び発行を行う機関の承認申請）について電子申請の受付を開始した。

表 5.2 汎用受付システムにおける本人確認手段の指針
項
番

手続ごとの本人確認要件

1

住民・企業等が不利益を被る可能性のある手続実印の押印又は写真付身分証明書の提示を求める手続
認印の押印又は署名を求める手続
記名のみで良い手続

2
3
4

各方式による電子化の可能性

該当手続例

電子証明
書（PKI）
必須

ID／パス
ワード
不可

記名のみ
不可

国民年金加入・喪失届

必須

不可

不可

国民健康保険加入・脱退届

選択可
選択可

選択可
選択可

不可
選択可

児童手当認定請求施設の利用申込み

出典，背景，補足説明：z

平成 14 年度電子自治体推進パイロット事業報告書（2003 年 3 月，総務省），総務
省

電

子

申

請

・

届

出

シ

ス

テ

ム

等

の

運

用

開

始

（http://www.soumu.go.jp/s-news/2002/020327_3.html），経済産業省電子申請のご案内（http://www.meti.go.jp/application/index.htm）
z「e-Japan 重点計画」において複数の行政手続を扱える汎用的な受付等システムを整備するために，府省庁間のシステムの整合性を確保するための基本的な仕様を策定することが決定された。これを受けて，総務省が事務局となり，各府省庁の意見を反映させた「汎用受付等システムの基本的な仕様」が 2001 年 8 月に策定された。

ze-Japan 戦略に基づいて，電子自治体を実現するために，平成 14 年度電子自治体推
進パイロット事業を推進した。この報告書に基づいて，日本全国の電子自治体で開発・推進されている。

z

上表における PKI は，住民基本台帳カード（住基カード）で実施する。住基カード
は，電子証明書を搭載している。

z

住基カードの発行サービスは，2003 年 8 月 25 日から開始された。市町村が発行する。500 円／1 枚。10 年間有効。

z

電子証明書の発行サービス（住基カードに電子証明書を書き込むサービス）は，2004―46―

年 1 月 29 日から開始された。都道府県知事が発行する。500 円／1 枚。3 年間有効。
更新手続は未定（e-mail など）。

5.2.1.3 経済産業省の電子申請（G2B）
経済産業省は，2004 年 3 月 29 日から経済産業省所管法令に係わる全ての行政手続（約5,400 手続）について，24 時間・365 日，オンラインによる電子申請受け付けを開始した。
(1)

電子申請の基盤技術
電子申請システムを信頼して利用するための，相手を確認するための政府認証基盤（GPKI，Government Public Key Infrastructure）と汎用受付等システムを利用する。
政府認証基盤（GPKI）は，公開鍵方式の暗号技術を応用して，申請書の名義人の同一性，文書内容の秘匿，内容改ざんの有無の検出などを可能にする。GPKI では，総務省のブリッジ認証局が中核となって，府省認証局，法務省商業登記認証局，公的個
人認証局，民間認証局などとの相互認証を結ぶことによって，信頼できる第三者機関による認証サービスを相互に利用できる仕組みとしている。
経済産業省の電子申請システムは，総務省が策定した「汎用受付等システムの基本的な仕様」に準拠している。
(2)

電子申請の方法
電子申請書にはデジタル署名が必要になる。デジタル署名には，総務省のブリッジ

認証局と相互認証を実施した認証局（法務省商業登記認証局，特定認証局など）が発行した電子証明書が必要になる。電子申請は，経済産業省の汎用電子申請システムにおいて，デジタル署名に付けられた申請者の電子証明書を GPKI を通じて検証される。
出典：経済産業省電子申請のご案内（http://www.meti.go.jp/application/index.htm）

5.2.1.4 国土交通省（G2B）
国土交通省では，2003 年 4 月 21 日より，国土交通省地方整備局等が発注する建設工事
及び建設コンサルタント業務等の全てを対象に電子入札を開始している。入札参加者は，電子証明書を準備しなければならない。
電子証明書の取得方法は，（財）日本建設情報総合センター（JACIC）ホームページに掲載されている認証局に問合せる方法としている。
以 下 ， 国 土 交 通 省 ホ ー ム ペ ー ジ の 電 子 入 札 の 実 施 内 容（http://www.mlit.go.jp/kisha/kisha03/13/130410_.html）より抜粋。
【入札参加者が準備する内容】＜電子証明書（IC カードに格納）＞
電子入札に参加するには，複数の認証局から一つ又は複数を選び，そこから発行された電子証明書（有料）が必要となります。 さらに，国土交通省の電子入札では，代表者（競争参加資格認定通知書に記載されている者）又は代表者から入札・見積権限及び契約権限について年間委任状により委任を受けた者（支店長など）の電子証明書のみにより電子入札が可能となりますのでご注意ください。電子証明書の取得方法につきましては補足資料-1―47―

をご参照ください。
＜電子入札に必要な機器＞
電子入札は，インターネットを利用して参加して頂くため，ハードウェア，ソフトウェ
ア，ネットワーク環境を準備して頂く必要があります（平成 13，14 年度に電子入札を行われた方も再度仕様の確認をお願いします）。入札専用のソフトについては，各認証局から提供されますので詳細につきましては各認証局にお問い合わせ下さい。なお，各機器の構成及びスペックについては補足資料-2,3,4 をご参照ください。

5.2.1.5 地方自治体による電子調達（G2B）
各地方自治体は電子入札方式の導入を進めており，多くの地方自治体では入札に際し電子証明書の利用を義務付けようとしている。（2005 年 4 月からは多くの地方自治体で電子入札が本格スタートする。）
例えば東京都では，従来までの ID・パスワード方式から平成 17，18 年度の建設・土木等電子業者登録ではフロッピーディスクによる電子証明書を利用しての登録が義務づけられ，中小・零細企業といえども今後 PKI 方式による電子署名や電子入札あるいは電子納品などに対応していくことが求められている。

5.2.1.6 政府（国土交通省）推奨の B2B 電子商取引
建設業界の電子商取引導入作業の一環として，以下を実施している。
(1)

電子証明書
z

電子商取引では，書類の印鑑の代わりに「電子署名」を，また，印鑑の正しさ（押印された印影が本人のものであること）を証明する印鑑証明書の代わりに「電子証明書」を利用する。

z

PKI に基づいた電子証明書は，利用者が個別に取得しなければならない。（財）
建設業振興基金等で発行している。（財）建設業振興基金発行の電子証明書は3 年間の有効期限があり，一度取得すればその間は自由に利用できる。

(2)

企業識別コードz

ネットワーク上で取引を行うためには，コンピュータが通信してきた相手先企業の識別が出来なければならない。

z

企業コードは全産業統一的に管理される上 6 桁と，各社が自由に利用できる下 6桁で構成されている。

z

企業コードの発行は，（財）建設業振興基金が行っており，有効期限は 3 年間
である。

(3)

出典と背景
z

出典：建設業の生産高度化に向けた先進的業務モデル導入マニュアル（2004 年
9 月 1 日，（財）建設業振興基金）

z

国土交通省では，2003 年度に「建設業の生産高度化のための実証実験」事業を実施し，（財）建設業振興基金が推進する業界の電子商取引基盤「CI-NET」，「C-CADEC」のデータ交換規約等を活用しながら，中小・中堅建設業者でも簡―48―

易に導入できる効率的な業務モデル・効果的なシステムについて，効果検証等を行っている。この導入マニュアルは，実証した業務モデルやシステムの理解と普及促進を目的に，実証実験の概要，効果，各種成果の導入方法等を平易に解説したもので，特に，中小・中堅建設業者の企業経営に携わる方々に広く参照頂くことを目的にしている。

5.2.2 企業間取引（B2B）
5.2.2.1 （社）電子情報技術産業協会（JEITA）
JEITA は，電機・電子業界で長年利用されてきた専用線 EDI である EIAJ 標準の後継標準として，2003 年 12 月にインターネット EDI である ECALGA 標準を策定・公開した。
ECALGA 標準では認証方式については取引当事者間の個別の取り決めに任されている。
ECALGA 標準での企業コードの扱いは以下となっている。
z

従来通り，企業コードは標準企業コード（ECALS については DUNS も可），納入
仕様書交換の部品分類コードは ECALS 部品分類コードを使用する。

z

電子商取引における企業識別コードとして，従来通り標準企業コードの取得が必要になる。

出典：ECALGA についての Q&A（2004 年 11 月，（社）電子情報技術産業協会 EC センター）

5.2.2.2 流通業界のインターネット電子商取引（B2B）
流通業界におけるインターネット EDI は，財団法人流通システム開発センターにおいて検討が進められてきた。経済産業省からの委託事業として平成 14 年度には「流通業界における XML-EDI 標準化調査研究」が実施され，平成 15 年度には「流通サプライチェーン全体最適化情報基盤整備事業」が実施された。
これらの事業においてレガシー流通標準 EDI メッセージ“JEDICOS”の中からインタ
ー ネ ッ ト EDI 化 す る こ と に よ り 効 果 が 期 待 で き る EDI メ ッ セ ー ジ が 選 択 さ れ ，
JEDICOS-XML が開発された。JEDICOS-XML は国際標準 ebXML に準拠し，通信手順は
ebMS（ebXML Message Service）を採用している。平成 16 年度には経済産業省の委託事業による JEDICOS-XML の実証実験が実施されている。
流通業界の企業認証コードとして財団法人流通システム開発センターは「JAN メーカー
コード」および「共通取引先コード」の 2 つの利用方式を定めていた。しかし「共通取引先コード」では国際化のニーズに対応できないと判断し，1999 年 5 月に国際 EAN 協会が制定した Global Location Number（GLN）の採用を決定し附番を開始した。GLN は国内
および国際間取引で相互に企業や事業所等を唯一に識別できるコードとして位置づけられている。
「共通取引先コード」は GLN 利用を目的とする事業者への附番を 2004 年 9 月に停止した。すでに附番された「JAN メーカーコード」は GLN として利用することができる。流
通業界の企業認証コードは今後 GLN に統一されることになる。
―49―

出典：
z

流通業における電子化取引標準化調査研究報告書（流通業における XML-EDI
標準化調査研究）（平成 15 年 2 月

独立行政法人経済産業研究所，委託先財団

法人流通システム開発センター）z

流通サプライチェーン全体最適化情報基盤整備事業報告書（平成 15 年度経済産業省委託事業）（平成 16 年 3 月

財団法人流通システム開発センター流通コー

ドセンター）z

GLN（Global Location Number）利用の手引き 2004 年度版（2004 年 10 月

財団法人流通システム開発センター）

5.2.2.3 法人向けインターネットバンキング（B2B）
2002 年より東京三菱銀行が法人向けに行っている「Biz STATION」サービスでは，振込・振替や残高・明細照会といったインターネットバンキング機能に加え，企業からの借り入れ相談や申込みの受付を行っている。金融情報や顧客企業の信用情報といった重要情報がインターネット上でやり取りされるため，東京三菱銀行は顧客企業に対して専用の電子証明書を発行することで，安全な情報の送受信のための顧客企業認証と通信内容の機密性確保を実現している。
出典：東京三菱銀行 HP

http://www.btm.co.jp/BizSTATION/service/index.htm

5.2.3 e 文書法，電子署名，タイムスタンプの動向
上記の G2B，G2C，及び B2B に関連する以下の動向がある。

5.2.3.1 e 文書法z

民間に保存が義務付けられている文書の電子保存を原則全て認める統一的な法律である。2005 年 4 月 1 日から施行される予定で法令化が推進されている。

z

従来会計処理をパソコン（PC）などで行っていれば電子帳簿保存法により会計デー
タの電子的保存は認められていたが，領収書や契約書まで含めて容認されていなかった。この法律の実施より，領収書や契約書まで含めて電子的保存が容認される。

z

税務関係書類の 50%から 90％近くを電子保存できると試算されており，保有コストの大幅な軽減が見込まれる。

z

紙代や印刷コストさらには輸送コストなどを考えれば，大幅なコストダウンが可能なことが予想される。さらに，ビジネスの流れが一挙にネット取引に移行することが起こる。紙の発注書や領収書あるいは契約書を郵送や FAX していた方法から，インターネット EDI や電子伝票交換が一層推進すると考えられる。

z

文書によっては「真実性・可視性を確保するための要件（改ざん防止措置等）」が必要になる。電子データの利点に，簡単に修正や改変ができるところにあるのだが，そのために逆に保存されている電子書類が改ざんされていないことを証明する必要がある文書もある。その際は，時刻認証と改ざんされていないことを証明するため―50―

のサービスであるデジタルタイムスタンプなどの付加も必要になる。
z

デジタルタイムスタンプは，インターネット等で取引や手続きが行われた時刻や電子文書が作成された時刻を証明するサービス（時刻認証サービス）で，日付が改ざんされたり，文書内容がスタンプ以後改ざんされていないことを証明する技術である。

5.2.3.2 電子署名
(1)

電子署名
z

電子署名とは，電子文書に対して行われる処理であり，電子署名が付された電子文書が，電子署名を行った者によって作成されたことを示すと同時に，電子文書の改ざんが行われなかったかどうかを確認できる。

z

電子署名において現在，最も信頼されて使用されているものが，「公開鍵暗号方式」を用いた電子署名である。

(2)

公開鍵暗号方式z

異なる対になった鍵（公開鍵と秘密鍵）を使う。公開鍵もしくは秘密鍵で暗号化し，復号するときは，暗号化に使用した鍵とは別の鍵を使う。

z

通常の暗号処理においては，公開鍵で暗号化し対になる秘密鍵で復号するが，秘密鍵は，名前の如く所有者によって秘密に管理される鍵であり，公開鍵は他の人と交換することによって利用される鍵という性格を持っている。

z

秘密鍵を管理する方法としては，IC カード，USB トークン等に格納してネット
ワークより切り離した環境で管理することが望ましいと言える。

z(3)

関連事項：SSL

SSLz

SSL：Secure Sockets Layer の略

zWeb ブラウザと Web サーバーの間でデータを暗号化してやり取りするためのプロトコル。米国ネットスケープ・コミュニケーションズが開発した。米国マイクロソフトは Web ブラウザで採用している。

z

SSL は，インターネット上でオンライン・ショッピングを利用するユーザーがクレジットカード決済をする際，不正利用を防ぐためのプロトコルとして用いられている。個人情報入力などサーバーとクライアント間で盗聴や改ざん防止のために使用されている。また，企業間電子商取引のセキュリティ機能としても多く利用されている。

z

SSL には認証と暗号化の機能がある。認証は Web ブラウザと Web サーバーの間で互いの Web サーバーの身元を確認するための機能。暗号化は通信中のデー
タを第三者により盗聴・盗み見されないようにするための機能である。

5.2.3.3 デジタルタイムスタンプz

電子化されたネットワーク社会の中で必要とされるのは，「いつ・誰が・何を」を改ざんされないようなデータとして運用することである。
―51―

z

「誰が・何を」は，電子署名を使って解決することができる。電子署名を行う際に参照される時計が各個人のコンピュータである以上，「いつ」を証明するこは困難である。

z

この「いつ」を解決する手段として「デジタルタイムスタンプ」技術がある。デジタルタイムスタンプ技術で出来ることは「存在証明」と「完全性証明」である。
存在証明：タイムスタンプによって示される時刻にデータが存在していたことを第三者に証明する。
完全性証明：タイムスタンプが付与された時刻以降，そのデータが改ざんされていないことを第三者に証明する。

z

デジタルタイムスタンプ機能サービスが提供されている。

5.2.3.4 中小企業 EDI における電子署名とデジタルタイムスタンプに関する考
察
(1)

電子署名
z

EDI で送受信される EDI 標準メッセージは，既に多くの業界・企業の EDI シス
テムで，電子認証基盤技術の採用等により電子署名されている。

z(2)

中小企業 EDI システムでも，EDI 標準メッセージの電子署名は必要である。

デジタルタイムスタンプze 文書法の施行に伴い今後はデジタルタイムスタンプが必要になると思われる。

z

デジタルタイムスタンプの提供サービスの状況とコスト・便宜性を考慮して，必要に応じて利用を選択する。

5.3 企業間電子商取引（B2B）の企業認証方式
企業間取引（B2B）における EDI は業態毎に様々な形で利用されているが，現時点では，
主として大企業による購買企業と中小企業が中心である供給企業間の取引であり，購買企
業にとっては調達 EDI，供給企業にとっては販売 EDI として利用することになる。
これは，大手購買企業がイニシアティブを取ることで普及をした取引体系であり，レガ
シーEDI と呼ばれている。レガシーEDI は購買企業と供給企業が１：１の関係で接続されており，通信先の認証については当事者の取り決めに任されてきた。
一方供給企業の中心を占める中小企業は取引額が少なく，EDI の導入による投資メリットが得られないので FAX による取引が継続してきた。近年，インターネットの普及により，多くの中小企業で e-mail や Web 閲覧などができる環境が整うことで，購買企業や VAN（EDI-ASP）事業者による Web-EDI が導入され始めた。Web-EDI 方式は購買企業と供給企業が１：Ｎの関係で接続されており，接続先企業認証方式は購買企業や VAN（EDI-ASP）
事業者の判断に任されている。
Web-EDI は供給企業にとってはデメリットが多いため，中小企業が現在の環境を生かして本格的な EDI の実現を可能とする新しいインターネット EDI（共通 EDI-ASP サービス）が提案されている。（「図 2.1 中小企業にもメリットのある EDI システム構成概念」参照）
この新しく提案された共通 EDI-ASP サービス方式では EDI-ASP を介して購買企業と供―52―

給企業がＮ：Ｎの関係で接続されることになるため何らかの統一した企業認証方式の導入が不可欠の条件となる。
本節においてはレガシーEDI または Web-EDI から新しい共通 EDI-ASP サービス方式への転換に焦点を当て，検討を行った。

5.3.1 EDI 利用の二つのタイプ−固定的継続取引とオープン取引−
これまでの製造業における調達方式は系列型の取引が中心であり，特定の企業間における取引が長期間に亘って固定されてきた。しかし近年のグローバル化の動きと共に取引先を固定する系列型取引は急速に崩壊し始めており，オープン調達方式が利用され始めるよ
うになっている。流通業においても大手流通企業を中心に固定的な企業間取引の EDI 利用が進展したが，近年製造業と同様の取引先のオープン化・拡大のニーズが強くなっている。
固定的取引とオープン取引では利用される目的が異なり，要求されるセキュリティ方式も大きく異なる。
固定的継続取引の場合には EDI を開始する以前に取引相手の信用度確認などは完了した上で取引を開始することになるので，EDI 運用時には通信相手の確認が確実に出来さえす
れば EDI 利用上の問題は起こりにくい。このケースは，上記で述べているレガシーEDI に当てはまる。
これに対しオープン取引は不特定の新しい取引先との取引となるケースが多く，まず相手企業の確認が不可欠の条件となる。この要求をインターネット EDI で満たすためには認証システムなどのハイレベルのセキュリティ機能の導入が必要となる。このケースが上記で述べているインターネット EDI に当てはまり，今後レガシーEDI からの転換が期待されている。これは，今までの大手購買企業の発注側と中小企業が中心となる受注側の調達 EDI
は発注１社に対する受注 N 社の取引体系であるが，今後は受注 N 社の中で受注のみではな
く発注もできるなど一つの EDI-ASP 内でより多くの取引が実現できる場が望ましい。
ただし，現状のオープン取引では新規取引先を開拓し，企業の信用度などを確認し取引基本契約を締結したうえで継続的な取引に移行するのが一般的に行われている取引上の運用形態である。

5.3.2 インターネット EDI-ASP サービスでの企業認証
中小企業における EDI 普及のために想定する ASP は，その加入者である企業（受注者，発注者）間の取引に関わる情報のやり取りに際して，通信を媒介する事業者によりサービスが提供されている。
EDI-ASP はセキュアな通信を確保するために，次のようなセキュリティ機能を提供している。
z

加入者でないものが ASP に接続しないことを保証する機能（ID・パスワード又は電子証明書による）。

z

加入者が，他の加入者の In-Box および Out-Box にアクセス（読み出し，書き込み）
しないことを保証する機能（なりすまし防止，改ざん防止）。

z

加入者が予め ASP に対して申告した相手以外からの情報の受信を拒否（又は警告）―53―

する機能（パートナーチェック）。
z

加入者が予め ASP に対して申告した相手以外への情報の送信を拒否（又は警告）する機能（パートナーチェック）。

z

ASP が媒介した通信に対して，送信者，受信者，日時，メセージの固有 ID など必要な情報を通信のログとして記録する機能（事後否認防止）。

現状ではインターネット EDI-ASP サービスは Web-EDI 方式が多く提供されている。
その加入者認証方式には ID とパスワード方式と電子証明書方式の 2 つがあり，EDI-ASP
サービス事業者はいずれかの方式を採用して運用を行っている。
加入者認証を ID とパスワードで実施し，電子証明書を利用していない EDI-ASP 事業者
はその理由として以下をあげている。
z

電子証明書はコストがかかる。

z

加入者認証のための電子証明書の発行・更新手続が EDI ユーザーの負担になる。

z

利用企業毎に ASP 加入契約を実施し，セキュリティ機能として SSL（Secure Sockets
Layer）を実装しており，加入者認証に関する事故は少ない。

当面は EDI-ASP サービスの利用企業がコスト負担とセキュリティを勘案してどちらの加入者認証方式の ASP サービスを利用するかを選択することになる。

5.3.3 企業間電子商取引（B2B）における企業認証の方式と考察
企業間電子商取引（B2B）における認証の方式として，大きく分類すると，①電子証明書，②IDとパスワードの 2 方式がある。概要・特質を表 5.3 企業間電子商取引における企業認証方式に
示す。

表 5.3

企業間電子商取引における企業認証方式
電子証明書

認証方式の概要

・

・

メリット

・

デメリット

・
・

セキュリティーレベル
ユーザビリティー評価

取引企業毎が，当事者を証明す
る電子証明書を添付して，電子商取引を実施する。
電子証明書は，認証機関又はASP サービス業者が発行する電子証明書を利用する。
成りすましと事後否認の脅威が防げる。
電子証明書発行のコストが掛かる。
電子証明書運用の手間がかかる。電子証明書の有効期間は，1年〜3 年であり，更新の手間がか
かる。

高
やや難
優

ID とパスワード
・・取引企業，担当者毎に ID・パス
ワードを発行する。
ID・パスワードを指定してログインする。

・

コストがかからない。

・

成りすましと事後否認の脅威がある。
不正利用の際に，ユーザー側が原因であるか，システム側が原因であるか，特定し難い。

・

不安が残る
容易
良

―54―

レガシーEDI からインターネット EDI への転換が前提条件であれば，今までの固定的取引よりもオープン取引の増加が見込まれ，相応のセキュリティレベルが必要となる。
また，「5.2 認証方式と企業識別方式の動向」で述べたように，G2B 及び G2C では電子証明書を積極的に利用して行く方向になっており，多くの B2B 電子商取引でも，電子証明書を利用した認証が用いられている。
表 5.3

企業間電子商取引における企業認証方式の比較，及び以下の理由から電子証明書を用いた企業認証が望ましいと考えられる。
z

G2B，G2C など，市場が電子証明書を利用する方向となっている。

z

社会的な環境として，電子証明書を用いる社会的基盤が整い機会が増えることで，中小企業を含めた多くの企業にとって電子認証を用いることの抵抗感が軽減され，電子証明書の取扱いについてのリテラシー向上が進んでいる。また，利用が進むにつれセキュリティ対策費用の低減も進む。

z

商取引上深刻なトラブルの要因となるセキュリティ上の脅威は，なりすましと事後否認である。情報を電子メールや Web サイトでやり取りする場合には，当事者間の責任において，これらの脅威に対処するため取引当事者の相互確認を行う電子証明書の利用が安全性が高い。

z

ブラウザ格納型の電子証明書にて，更新用 e-mail のリンクをクリックするだけで更新手続きが可能，e トークンや IC カードでもソフトウェアにより更新手続が可能になるなど，ユーザーの使い勝手の良い電子証明書サービスが提供されつつある。

電子認証サービス事例を表 5.4 電子認証サービス事例に示す。

5.3.4 中小企業インターネット EC/EDI の認証方式に関する考察
多くの中小企業が EDI-ASP を利用する上で，商取引上深刻なトラブルの要因となるセキ
ュリティ上の脅威は，なりすましと事後否認である。情報を電子メールや Web サイトでやり取りする場合には，当事者間の責任において，これらの脅威に対処するため取引当事者の相互確認を行う電子証明書を用いた認証方式を利用することが望ましい。
しかし，中小企業にとって電子証明書のコスト負担が，EDI-ASP 普及にとっての障害となりうる可能性も考慮しなくてはならない。
以下では，EDI-ASP を利用する際のセキュリティの必要性を考察した上で，認証方式の今後を示す。

(1)

EDI-ASP を利用した中小企業 EDI におけるセキュリティの必要性に関する考察
運用が簡単でコストが非常に安い認証サービスが市場に十分普及するまでの期間，

企業側のコスト負担とセキュリティを勘案し，企業側コスト軽減のために ID とパスワードを用いた認証方式が適用することは，現時点で有効な方法とも考えられる。
特に，インターネット EDI-ASP サービスの利用において，EDI 取引当事者（発注者と受注者）双方が取引基本契約を締結したクローズ（固定的取引）の商取引を，個々のインターネット EDI-ASP サービス規約に基づいて実施する場合は，電子証明書を使用しない運用も可能と思われる。ASP を利用した中小企業 EDI におけるセキュリティ―55―

の必要性に関する考察を，表 5.5 ASP を利用した中小企業 EDI におけるセキュリティの必要性に関する考察に示す。

(2)

認証方式の今後の考察「5.3.3 企業間電子商取引（B2B）における企業認証の方式と考察」の考察の通り，

将来における理想像としては電子証明書を用いた認証方式が標準化することが望ましい。
インターネット EDI-ASP サービスの普及に際しては，事故のない高信頼性の EDI取引の実現が基本的な条件となる。EDI-ASP サービスから電子証明書の利用機能が提供され，発注企業と受注企業の双方が電子証明書を利用して商取引を実施することにより，特になりすましと事後否認の観点でより一層安全性の高い EDI 商取引が実現できる。1990 年代後半からのオープンネットワーク（インターネット）基盤拡大により
EDI 商取引においても利用価格の低価格化と簡便性など多くのメリットをもたらした。
このメリットを享受・拡大するには，安全と安心のインターネット電子商取引を実現するための新しいセキュリティコスト（電子証明書）がかかることを理解する必要がある。
今後は，G2B，G2C，B2B の多くの分野で電子証明書の利用が進むと考えられる。
B2B 電子商取引の分野では，インターネット EDI-ASP サービス相互接続サービスの実現など B2B 電子商取引利用のトータルコストダウンと利用簡便性が必要になる。
B2B 電子商取引の認証機能の観点では，G2B，G2C 分野で GPKI として実施されているように，B2B 電子商取引の認証機能に適した電子証明書の相互運用・ブリッジ認証
局機能が必要である。

―56―

表 5.4

電子認証サービス事例

認証種別

主な用途

格納形式

有効期間

価格

参考
（年間費用）BLADE クライアント証明書

クライアント認証

B2B

ブラウザ格納形式
IC カード

1年
3年

2,000 円
5,000 円

2,000 円
1,666 円株式会社帝国データバンク

COSMOSNET/EC

クライアント認証

江戸川区入札
B2B

ブラウザ格納形式

1年

6,000 円

6,000 円3

日本認証サービス
株式会社

AccreditedSign
パブリックサービス 1

クライアント認証

B2B/B2C

ブラウザ格納形式

2年
3年

18,000 円
24,000 円

9,000 円
8,000 円4

日本電子公証機構

iPROVE

クライアント認証

B2B/B2C

ブラウザ格納形式

-

-

-

5

セコムトラストネット株式会社

セコムパスポート for Member

クライアント認証

B2B/B2C

IC カード-初期：300,000 円
月額：90,000 円

1,380,000 円

6

セコムトラストネット株式会社

セコムパスポート for Web

サーバー認証

B2B/B2C

シール

1年

68,250 円

68,250 円

7

日本ベリサイン株式会社

ベリサイン SSL サーバ証明書
サーバ ID

サーバー認証

B2B/B2C

シール

1年
2年

81,000 円
153,000 円

81,000 円
75,000 円

8

ビートラステッド･ジャパン
株式会社

sure server 証明書

サーバー認証

B2B/B2C

シール

1年
2年
3年

75,000 円
138,000 円
198,000 円

75,000 円
69,000 円
66,000 円

9

地方公共団体

個人認証サービス

クライアント認証

個人認証（属性認証なし）

住基カード

3 年間

500 円

166 円

10

株式会社帝国データバンク

TDB 電子認証サービス SG

クライアント認証

東京都
東京都内区町村FD

2 年 1 ヶ月

16,000 円

8,000 円

11

法務局

商業登記に基礎を置く電子認証制
度に基づく認証サービス

クライアント認証法人の代表者認証

ブラウザ格納形式

3 ヶ月単位
3〜27 ヶ月2,500 円〜
16,900 円

約 8,500 円

12

株式会社ミロク情報サービス

MJS 電子証明書発行サービス

クライアント認証

e-Tax 用IC カード

1年
3年

9,000 円
23,000 円

9,000 円
7,666 円13

株式会社中電シーティーアイ

CTI 電子入札･申請届出対応
電子認証サービス

クライアント認証

国土交通省入札
地方公共団体CD-R

2 年 1 ヵ月3 年 1 ヵ月18,000 円
24,000 円

9,000 円
8,000 円14

日本電子認証株式会社

KeySign サービス

クライアント認証

東京都
東京都内区町村

FD

1年
2年
3年

9,000 円
16,000 円
21,000 円

9,000 円
8,000 円
7,000 円No.

サービス事業者

1

NTT コミュニケーションズ
株式会社

2

サービス名

―57―

15

ジャパンネット株式会社

電子入札コアシステム用
電子認証サービス

クライアント認証

国土交通省入札
国・地方公共団体

IC カード

1年
2年
3年

10,000 円
20,000 円
30,000 円

10,000 円

16

四国電力株式会社

よんでん電子入札対応
認証サービスクライアント認証

国土交通省入札
国・地方公共団体

IC カード

2年

21,000 円

10,500 円

17

株式会社帝国データバンク

TDB 電子認証サービス TypeA

クライアント認証

国土交通省入札

IC カード2 年 1 ヶ月

28,000 円

14,000 円

18

株式会社中電シーティーアイ

CTI 電子入札･申請届出対応
電子認証サービス

クライアント認証

国土交通省入札
国・地方公共団体

IC カード2 年 1 ヵ月3 年 1 ヵ月

28,000 円
38,000 円

14,000 円
12.666 円

19

NTT メディアサプライ
株式会社

e-ProbatioPS

クライアント認証

国土交通省入札
国・地方公共団体

IC カード1 年 1 ヶ月2 年 1 ヶ月

15,000 円
23,800 円

15,000 円
11,900 円

20

東北インフォメーション・
システムズ株式会社

TOiNX 電子入札対応
認証サービスクライアント認証

国土交通省入札
国・地方公共団体

IC カード

2年

23,000 円

11,500 円

21

日本商工会議所

ビジネス認証サービス
タイプ①−A

クライアント認証

国土交通省入札
国・地方公共団体

IC カード1 年 30 日
2 年 30 日

15,000 円
28,000 円

15,000 円
14,000 円

22

日本電子認証株式会社

AOSign サービス

クライアント認証

国土交通省入札
国・地方公共団体

IC カード1 年 30 日
2 年 30 日
3 年 30 日

15,000 円
28,000 円
39,000 円

15,000 円
14,000 円
13,000 円

23

東京三菱銀行

東京三菱 BizSTATION

クライアント認証

インターネット
バンキング

ブラウザ格納形式

-

-

-

24

株式会社帝国データバンク

サーバ証明書サーバー認証

各サーバー

シール

1年

81,000 円
75,000 円

81,000 円
75,000 円

備考：(1)ブラウザ格納形式は，ユーザー側で媒体格納が可能。
(2)上記の多くは，日本ベリサイン社やビートラステッド・ジャパン社の技術に基づき，電子認証サービスを提供している｡―58―

表 5.5
脅威

脅威の例

ASP を利用した中小企業 EDI におけるセキュリティの必要性に関する考察
B2B取引での可能性

ｾｷｭﾘﾃｨ技術による対処

EDIデータ内の取引の内 １． 通信回線をワイヤタッピン 暗号化
グされると盗聴の可能性が
容（価格など）をライバルある。
会社に見られてしまう。
２． ASPのメールボックス（サーバー）では盗聴の可能性が
少ない。
電子署名
改ざん
EDIデータの内容が誰か １． 通信上，蓄積されるのはに書き換えられてしまう。
ASPのメールボックス（サーバー）であり，改ざんされる
恐れが少ない。
なりすまし 第三者が，取引先を装っ １． ASPの加入者が，他の加入 電子署名者になりすまして不正行為 電子証明書て注文を出す。
を働く可能性は低い。
第三者が，取引先を装っ
２． 第三者が他の加入者になりて注文を請ける。
すまして不正行為を働く可能性がありうる。

ASPの機能による代替対処1.

盗聴

事後否認 注文を出しておきながら， １． 取引基本契約を取り交わし 電子署名てEDIを実施する企業間で， 電子証明書「そのような発注はした覚
事後否認が発生する可能えがない。」ととぼける。
性は低い。

運用による対処考察

ASPサーバーに格納 運用上の対処に加え，ワイヤタッ
されている情報そのも ピングされる恐れがあり，取引当事者間で，必要と認めた場合にのを暗号化する。
は，双方の責任でメッセージを暗号化して送受信する。

１． ASPサーバーへの不正侵入，不正アクセスの防止。

ASPのセキュリティが充分である
ならば，取引当事者が電子署名を添付しない運用も可能である。

１． 予め届け出のあった企業 １． 注文請け情報の送信 ASPのセキュリティ対策に加えて，運用上の対処を行えば，電を徹底する。
間の通信のみを媒介する。（ﾊﾟｰﾄﾅｰﾁｪｯｸ，CUG） ２． メッセージに連番のID 子証明書を使用しない運用も可を付けておかしな注文 能である。
２． ASPｻｰﾊﾞｰへの不正侵を排除する。
入，不正アクセスの防３． ASPの加入契約に，止。
他の加入者に損害を
３． ASPが通信のﾛｸﾞを取る。
及ぼす行為の禁止を
４． ASPの加入者以外の通明示。
信は媒介しない。（悪意の第三者を排除）
１．ASPが通信のログを取る。 １． 注文請け情報の送信 ASPのセキュリティ対策に加えて，運用上の対処を行えば，電を徹底する。
２． メッセージに連番のID 子証明書を使用しない運用も可をつけておかしな注文 能である。
を排除する。
３． 企業間で取引基本契約を締結。EDI実施の覚書，運用ﾏﾆｭｱﾙを作成して取り交わす。

―59―

5.4 中小企業に適した企業識別（企業コード）の考察
EDI 取引の企業を特定するため，企業識別が必要である。本節では，企業識別に関する
課題，要件，考察を述べる。

5.4.1 企業識別方式の現状
企業識別には複数の方式が存在する。EDI は取引にかかわる企業間の合意によって実行されるものであるため，企業識別として何を採用するかも，取引先との合意によって決定されなければならない。
どんな企業と取引する場合にも同一の企業識別が使用できることが理想ではあるが，現実には，取引先から使用する企業識別を指定された場合には，それに従わなければならない。複数存在する企業識別の体系を混在させてもユニーク性を確保するための規格（ISO，
UN/EDIFACT）があるが，現実には取引先の要請で，それぞれ指定のコード管理機関から企業識別を取得しているのが実情である。逆に，特定のコード管理機関が管理している企
業識別を取得しても，取引先がその企業識別を採用することに同意しなければ，EDI に使用することは出来ない。
当事者間の合意を簡易にするため，EDI 標準の中に使用する企業識別を規定している場
合も多い（JEITA：統一企業コード，RosettaNet：D-U-N-S ナンバー，EANCOM：GLN）。
JEITA-ECALGA 標準では，JEITA/EC センターが発番する統一企業コード（CII 標準企
業コードと同じもの）の採用を業界として決定しており，業界標準の一部として制定している。また，流通業においては（財）流通システム開発センター・流通コードセンターが発番する GLN および JAN メーカーコードが広く使われている。
これらの企業識別コード利用には，以下のメリットがある。
z

永続的機関がコードの登録管理を行っており，余計な手間がかからない。

z

EDI のための企業識別として，大手取引先企業に認知されており，取引先の合意を
得やすい。

z

異なる ASP 間で通信を中継する際にも，ASP に依存せず企業識別のユニーク性が保証される。

5.4.2 企業識別方式の課題
企業識別には複数の体系が存在するので，様々な企業識別コードが採用された場合各社での運用上の効率が悪化し，コストアップにつながることが懸念される。
本設計ガイドの「2 章システム構成」で示されている EDI-ASP 間の接続が実現できたケースを想定し，EDI-ASP に関わる３者の視点からの課題抽出が必要である。
発注者側からすると，複数の ASP を通じて複数の受注者が登録され，この受注者の管理を行わなくてはならないケースが考えられる。この際，企業識別コードが複数存在することで，管理コストは増大する。また，ID（企業識別コード）毎にシステム上で取引先確認をしなくてはならないといった方法であった場合には，取引先管理コストが増大するため，ID（企業識別コード）が公開されている必要がある。

―60―

次に，受注者側からすると，できる限りコストが安く導入できることが第一条件となる。
最後に，EDI-ASP 提供者側からすると，同一企業に対しては，同一コードが用いられていないと，すべての EDI-ASP 間で企業識別コードのマッチングが必要となる。これは，
EDI-ASP 提供者の管理コストが高くなることが容易に予想される。
これからの拡大が期待されているインターネット EDI で，ばらばらの企業識別方式が採用された場合の社会的損失は非常に高いことが予想され，上記の課題抽出を踏まて，中小企業にとって望ましい形を考察する必要がある。

5.4.3 中小企業の企業識別導入に対する現状と課題受注者である中小企業は既存の EDI 用企業識別コードをまだほとんど導入しておらず，
今後中小企業へ EDI を普及して行くためには何らかの企業識別方式を導入しなければならない。
既存の EDI 企業識別コード管理機関の発行するコードサービスは，大企業の EDI 利用を前提として価格設定されており，既存の企業コードサービスの利用を強制することが中小企業にとっては負担となり，EDI 普及の妨げとなる恐れが大きいと考えられる。
そこで，既存の企業識別コードに替わる低コスト案の検討も必要である。

5.4.4 企業識別に求められる要件
インターネット EDI-ASP サービスに関わる発注者・受注者・EDI-ASP 提供者の３者の視点から，企業識別コードの求められる要件は以下である。
(1)

企業識別コード利用料金が低コストである。
受注者の多くは中小企業であり，EDI 普及の妨げとならぬよう低コストで利用できる必要がある。できれば，利用料金は無料が望ましい。
(2)

網羅率が高い。
既存の企業識別を用いた場合，現時点で既登録分が相当数ないと登録に手間がかかる。
(3)

全国全業種・規模を問わない。
EDI-ASP 利用者は広く利用されることが期待されているため，業界や地域に偏りがないことが必要である。
(4)

公開されており常に照会が可能である。
EDI-ASP 提供者・発注者は，企業識別コードをキーに管理しなくてはならず，コードが非公開である場合には一件ごとに照会しなくてならないため，非常に手間がかかる。特に，EDI-ASP 提供者の場合，他の EDI-ASP を経由した注文等を管理する際には，コードが非公開であると他の ASP に企業情報を照会しなくてはならないため，コ
スト増が懸念される。
また，基礎情報の照会は無料が望ましい。
(5)

常にメンテナンスを行っている。
EDI-ASP 提供者・発注者にとって，合併・被合併，倒産などが管理されていること―61―

で，取引の安全性が高まる。

5.4.5 企業識別方式の考察
中小企業が利用しやすく，インターネット EDI-ASP サービスに関わる発注者・受注者・
EDI-ASP 提供者のいずれにとっても利便性が高いものでなくては，EDI の普及の障害となる恐れが高い。上記の要件を踏まえ，次の通りの考察を行った。

(1)
①

②

③

案 1： 公開されており無償で利用可能な企業識別コードを利用する。
メリットz

永続的機関がコードの登録管理を行っており手間がかからない。

z

網羅率が高い。

z

利用には費用がかからない。

z

企業識別コードが公開されており常に照会可能である。

z

ASP に依存せず企業識別のユニーク性が保障される。

z

業種・規模を問わない。

z

定期的にメンテナンスされている。

デメリット
z

企業コードの登録に費用が掛かる。

z

個人事業者がカバーされない可能性がある。

備考
z

④

(2)

各コードにより，網羅率や提供形態が異なるため確認が必要。

評価：優案 2： 法人登記番号，商工会議所の会員番号など，企業が既に持っている企業識別の中から，EDI で使えそうなものを探して採用する。

①

メリット
z

②

③

(3)

費用がかからない。（コード管理機関に費用を支払う必要がない）

デメリット
z

個人事業者がカバーされない可能性がある。

z

コードが非公開である可能性が高い。

z

問い合わせ対応などが受けられない可能性が高い。

評価：良案３： 中小企業における EDI の実施が，ASP への加入を前提にするならば，ASPのアカウント（ユーザ ID・メールアドレス・電話番号）を企業識別の代わり
にする。

①

メリット
z

取り決めが容易である。

―62―

z
②

企業識別コードのための費用がかからない。

デメリット
z

ASP のアカウントやメールアドレス・電話番号は非公開情報である。メール
アドレスや電話番号は個人情報であり，その利用については，個人情報保護法及び不正アクセス行為禁止法で厳しく制限されている。

z

電話会社やインターネット接続事業者との契約変更時，ID が変更されることがあるのでその対処が必要になる。

z

大企業側は ASP 非加入の企業との EDI では個別の企業識別を使い，ASP 経由の取引先とは ASP のアカウントを使うという「使い分け」が必要になるた
め合意しない可能性がある。合意しない場合には，取引先と協議の上，適当な企業識別コードを取得する必要がある。

z

異なる ASP 間で通信を中継する場合には，発信者または受信者が他の ASPの加入者であることを ASP の処理系が認識できなければならない。そのため，加入している（企業識別を発番した）ASP の識別と企業識別を合わせて企業を識別する必要がある。この方式を実現するためには EDI サービスを連携して提供する ASP 事業者が相互にこのアカウント利用方法を承認し，標準化をすることが必要になる。

③

(4)

評価：可
案４：中小企業が属するコミュニティ（取引関係のある企業の集まり）の中で，各社にコードを付番する仕組みを自前で構築し，企業識別を管理する。

①

メリット
z

費用がかからない（コード管理機関に費用を支払う必要がない）。個人事業者でも登録できる。

②

デメリット
z

自前で登録管理をする手間とコストを誰かが永続的に負担しなければならな
い。

③

(5)

評価：可
案５：取引先企業（主に大企業）が個別に付番したコード（取引先コード）を利用
する。

①

②

メリット
z

費用がかからない。

z

取引先の合意を得やすい。

デメリット
z

ASP 事業者が企業を識別する目的（メッセージの振分処理など）には使用できない。A 社との取引では当社は「XXXX 番」と名乗り，B 社との取引では
当社は「YYYYYY 番」と名乗るというように，自社のコード値は一定しない―63―

ので，社内で取引先別にコンピュータ等で管理しておき，間違えないように運用することが必要。大企業側が自らコードの付番を行っておらず，コード
管理機関の発番する企業識別を採用している場合，コード取得の費用がかか
る。
③

評価：可

上記５案の中では，案 1 が最も EDI-ASP 関係者のメリットが高く，社会全体としての管理コストを低減できる可能性がある。但し，案１のデメリットとして企業コードの登録・維持に費用が掛かる。中小企業に適用する場合の条件として低コストの要件があり，今後
は企業識別コードの登録・維持コストの低価格化が期待される。

―64―

表 5.6
サービス事業
者

サービス名

電子商取引推
進センター
標準企業コ
1
(JIPDEC/ECPC ード)
ダン アンド ブ
ラッドストリート D-U-N-S
2
ジャパン株式会 Number
社

3㈱帝国データバ TDB 企業コ
ンクード㈱東京商工リ
4
サーチ

TSR 企業コード

保有件 公開企業コードの利
数
用料金

企業識別コードサービス一覧

登録料金

登録条件 期限5,250 円〜42,000 円
Web から無料で（資本金額によるほか，登録 法人およ約2万
コードリストのダウン 申請を受け付ける業界団体 び個人事社
ロード可能。
毎に会員割引等の制度あり） 業者（3 年間分の料金）
Web から有料で検索
8,400 万 可能。(国内企業
基本的に3,150 円社
法人のみ
\525/件,海外企業\2,625/件)
信用調査やその他調査活動を通じて登録される。ただし，
WEB から無料で検 企業コードを特別に新規登録 基本的に174 万社索可能。
する際は，手続内容により， 法人のみ
1,300 円から 2,800 円にて登録可能。

不明

非公開であり，提供
商品に付加されるも不明
ので，特に使用料金は発生しない。

基本的に
法人のみ

日本国
（財）流通システ GLN（グロー10,500 円〜241,500 円
内だけ
Web から無料で検索
ム開発センター バル・ロケー
5で（業種，年商による）（3 年間／流通コードセ ション・ナン
可能。
約 11 万
分の料金）
ンター
バー）
社
（財）流通システ
共通取引先
約 6 万 公開（無料で問い合ム開発センター6
5，250 円（3 年間）
コード企業コ／流通コードセ
社
わせ対応）
ード
ンター
（財）日本貿易
7 関係手続簡易化協会

日本輸出入標準コ 新規登録：6,600 円
日本輸出入 約 9 万 3
ード表 CD-ROM 版： 変更登録：1,350 円
者標準コード 千社
6,800 円（税別）
更新登録：3,150 円（3 年毎）

―65―

企業また
は団体

基本的に
法人のみ
輸出入を
行う法人
及び個人
事業者

メンテナンス特徴

備考

・コード：6 桁＋6
企業からの申請に応じ
ISO/IEC15459，ISO6523，
桁て，登録・変更・削除の
UN/CEFACT ディレクトリ等主 http://www.ecom.
3 年間
メンテナンスを日々行っ
要な国際標準に登録済み。 jp/jedic/kcode/kcている。
ode.htm
なし

調査活動を通じ，日々 ISO/IEC15459，ISO6523，
http://www.dnb.c
登録・削除などのメンテ UN/CEFACT ディレクトリ等主 o.jp/duns̲number
ナンスされている。
要な国際標準に登録済み。 /なし

・公開されている企業コードで・コード：9 桁
調査活動を通じ，日々 は網羅率が非常に高い。
http://www.tdb.co
登録・削除などのメンテ ・無料で利用できる。
.jp/tdbcode/tdbco
ナンスされている。
・リアルタイムでメンテナンスを
de.html
行っている。

なし

調査活動を通じ，日々
リアルタイムでメンテナンスを http://www.tsr-n
登録・削除などのメンテ行っている。
et.co.jp/
ナンスされている。

ISO/IEC15459，ISO6523，
企業からの申請に応じ
UN/CEFACT ディレクトリ等主 http://www.dsri-dて，登録・変更・削除の3 年間
要な国際標準に登録済み。 cc.jp/company/gl
メンテナンスを日々行っ
JAN メーカコードを GLN 企業コ n/top.htmている。
ードとして使用可能。
企業からの申請に応じ2004 年 9 月末をもって GLN 利 http://www.dsri-dて，登録・変更・削除の3 年間用を目的とする事業者への附 cc.jp/company/01
メンテナンスを日々行っ
番を停止した。
/kyoutsu̲c.htmている。
企業からの申請に応じ
an5 桁ｺｰﾄﾞ（1 社,1輸出入申告手続を初めとして，登録・変更・削除等
事業所１ｺｰﾄﾞ）
3 年間て，貿易関係手続，海運業界の業務，3 年毎の更新
http://www.jastpr
で広く使用されている。
作業を行っている。
o.org/code/6 EDI メッセージ送受信・蓄積交換機能
本章では，EDI メッセージ送受信・蓄積交換機能を概観し，その中で EDI クライアン
ト送受信インタフェースを検討・考察する。

6.1

システム構成EDI メッセージ送受信・蓄積交換機能は，EDI クライアント又は EDI サーバーと，
EDI-ASP サーバーとの間で，EDI メッセージを交換するためのものである。本機能は，Pull 型 XML/EDI クライアントの場合に，A タイプ，B タイプ，及び C タイプで必須となる機能である。（2.4 節

Pull 型 XML/EDI クライアントのシステム構成モデルと機能を参照）
ebXML による実装においては，ebXML 仕様が EDI サーバー間の規格が中心であるた
め，EDI クライアントに関しては，本機能が重要になる。

6.1.1 システム構成モデル
EDI メッセージ送受信・蓄積交換機能におけるシステム構成モデルを，図 6.1 システ
ム構成モデルに示す。
EDI メッセージ送受信・蓄積交換機能は，EDI クライントと EDI サーバーにより構成されるため，構成モデルとしては，クライアント・サーバー構成が基本となる。さらに，
ebXML の利用を想定すると，EDI サーバー間接続が前提になるため，EDI クライアントに EDI サーバー間構成が加わり，クライアント・サーバー・サーバー構成になる。ebXML
規格が EDI サーバー間仕様が中心となっているのに対して，EDI クライントを含むのがEDI 送受信機能の特徴である。
また，EDI サーバ間接続が前提にならなければ，クライアント・サーバー・クライアン
ト構成が想定できるが，クライアント・サーバー・サーバー構成の変形モデルと捕らえることで，同様に扱うことができる。

―66―

サーバー･サーバー型

EDI
サーバー

EDI
サーバー

クライアント・サーバー･サーバー型
クライアント・サーバー型
インタ

EDIクラ
イアント

EDI
サーバー

EDIクラ
イアント

EDI
サーバー

ーネッ
ト

クライアント・サーバー･サーバー・クライアント型

EDIクラ
イアント
クライアント・サーバー･クライアント型

図 6.1

システム構成モデル

システム構成モデルの特徴と機能構成要素を，表 6.1 に示す。
クライアント・サーバー構成において，EDI サーバーは固定 IP アドレスとサーバー用
基本ソフトウェアを必要とするが， EDI クライアントは，固定 IP アドレスとサーバー基
本ソフトウェアのいずれも必須としないのが特徴である。サーバー・サーバー構成の EDI
サーバーは，送受信・蓄積・変換機能を必須としない。サーバー・サーバー構成の場合，送受信・蓄積・変換機能はアプリケーションサーバーに実装する場合が多い。

表 6.1

システム構成モデルの特徴と機能構成要素○：必須，△：任意，−：関係なし

システム構成モデル
ク ラ イ ア ン
ト・サーバー構成
サーバー・サーバー構成

システム構成要素
EDI クライアント
ASP または
EDI サーバー
EDI サーバー

固定 IP ｱﾄﾞﾚｽ△○

ｻｰﾊﾞｰ基本
ｿﾌﾄｳｪｱ
△
○

送受信

交換

蓄積

変換

○
○

−
○

−
○

△
△

○

○

△

○

−

−

6.1.2 システム機能構成要素
EDI 送受信機能は，EDI クライアントと EDI サーバーとで，EDI メッセージを送受信する機能である。この EDI クライアントと EDI サーバーは，図 6.2 EDI クライアントと EDI サーバーの機能構成のように構成される。

―67―

EDI
クライアント

EDI
サーバー

ASP
またはEDIサーバー

交換

交換

蓄積

変換

送受信

送受信

変換

ＡＰ

ファイル

バッファ

図 6.2

EDI クライアントと EDI サーバーの機能構成

EDI サーバーと EDI サーバー間は，EDI メッセージをサーバー・サーバーの交換規約に基づき交換する「交換」が中核構成要素であり，いずれの EDI サーバーにも，サーバー型の交換機能が実装される。さらに，EDI サーバーには，EDI サーバー間の「交換」に，
EDI クライアントとのタイミング吸収役としての，EDI メッセージの蓄積機能を有する「蓄積」機能を有する。
EDI サーバーと EDI クライアントには，EDI サーバーの蓄積機能と EDI クライントと
EDI メッセージのやり取りをする「送受信」機能が実装される。さらに，EDI クライアン
トには，業務アプリケーション「AP」との間の EDI データ格納機能として，「ファイルやバッファ」や，EDI 標準メッセージと EDI ローカルデータの変換を行う「変換」機能を有する。なお，「変換」は，業務アプリケーションが，EDI 標準メッセージを直接扱えないなどのときに利用される。

6.2

EDI クライアント送受信インタフェース

本節では，Pull 型 XML/EDI クライアントの EDI 送受信機能の設計，特に，ebXML 実
装において明確になっていない，送受信インタフェースを中心に検討・考察する。

6.2.1 送達確認（Acknowledgement）機能
EDI において，EDI メッセージの送達確認は重要な機能である。その送達確認にも，送達先の深度により適切な確認処理が必要である。これらの送達の確認レベルは，業務適用に応じて利用方法を判断することになる。
① メッセージ受信確認
MSH（メッセージサービスハンドラ）の受信確認で，EDI サーバーまたは
EDI-ASP サーバーがメッセージ受信したときことの確認になる。
② メッセージ受取確認
ビジネスサービスインタフェース（BSI）ソフトウェアの読取可否確認で，EDI
サーバーまたは EDI-ASP サーバーがメッセージ構文や XML として妥当性チェッ―68―

ク（スキーマチェック）し，メッセージが読取可能であることの確認になる。
実装上は，蓄積機能に相当するメールボックス（MBX）に格納したことや EDI
クライアントによる送受信確認が考えられるが，EDI-ASP サービスの利用も想定
すると，MBX への格納にすることが多い。
③ アプリケーション受付確認
アプリケーションによる処理受付確認で，EDI サーバーまたは EDI-ASP サーバ
ーが，ビジネスドキュメント又はドキュメントエンベロープの内容を，ビジネスルールとして妥当性チェックし，ＡＰが処理受付されたことの確認になる。
実装上は，業務アプリケーションからの確認を受け付けしてもらうのが一番望ま
しいが，実際上は，既存の業務アプリケーションでは実装できないため，業務アプ
リケーションに近い変換アプリケーション，更には EDI クライアントの送受信機能で対応することが多い。
送達確認機能と ebXML 仕様の対応関係を，表 6.2 送達確認機能と ebXML 仕様との関係にまとめた。
表 6.2

送達確認機能と ebXML 仕様との関係

確認レベル
メッセージ受信確認

ebXML
ebMS
Acknowledgement

メッセージ受取確認

BPSS Receipt
Acknowledgement

アプリケーション受
付確認

BPSS AcceptanceAcknowledgement

摘要・ MSH（メッセージサービスハンドラ）の受信確認処理。
・ EDI サーバーまたは EDI-ASP サーバーがメッセージ受信したときに発信。
・ メッセージサービスインタフェースソ
フトウェアの読取可否確認処理。
・ EDI サーバーまたは EDI-ASP サーバーがメッセージ構文やスキーマチェック
し，メッセージが読取可能であることを確認したときに発信。
・ ＡＰには見えない。
○案１：BSI＝MBX
メールボックス（MBX）に格納したときに発信。
×案２：BSI＝送受信クライアント
送受信クライントがデータを送受信完了したときに発信。
・ アプリケーションによる受付確認処理。
・ EDI サーバーまたは EDI-ASP サーバー
が，ビジネスドキュメント又はドキュメ
ントエンベロープの内容を，ビジネスルールとして妥当性チェックし，ＡＰが処理受付されたことを確認したときに発信。
・ AP が意識するか否かは任意。
○案１：AP＝送受信クライント○案２：AP＝変換または業務 AP―69―

従来 EDI
ファイル転
送の転送完
了
EDI ト ラ ン
スレータに
よりメッセ
ージ変換後
の受信確認
メッセージ

同上

ebXML 仕様に準拠した送達確認制御を，図 6.3 送達確認（Acknowledgement）制御に示す。

EDIクライアント

ASPまたはEDIサーバー

交換

ドキュメント交換

ドキュメントebMS Acknowledgement

ドキュメント

バッファ

蓄積

変換

送受信

送受信

変換

ＡＰ

ファイル

EDI
サーバー

ドキュメントReceipt Acknowledgement

ドキュメントAcceptance Acknowledgement

図 6.3

送達確認（Acknowledgement）制御

6.2.2 ビジネスプロセス制御
ビジネスプロセス制御は， EDI メッセージの交換とビジネスコラボレーション制御による，パートナーとのビジネスコラボレーションを実現するための支援機能である。このビジネスプロセス制御のためには，EDI メッセージの交換を通して，ビジネスコラボレー
ション制御のための情報を取得し，制御することになる。ビジネスプロセス制御のための情報と制御方法は次のような適用が想定できる。
これらのビジネスプロセス制御方法は，業務適用に応じて利用方法を判断することにな
る。
① ebXML メッセージヘッダ
ebXML メッセージヘッダの，送受信者情報や，ビジネスドキュメント情報，ビ
ジネスコラボレーション情報（例えば，カンバゼーション ID やビジネスアクショ
ン等）によりビジネスコラボレーションを制御する。
ebXML の規格に即した，ebXML メッセージヘッダ上の情報を利用することになるため，汎用性が高いが，参照できる情報が限定されるため，細かなビジネスプロ
セス制御ができないことがあることや，利用者が情報を設定できる範囲が限定されることもあることが難点になる。
② ビジネスドキュメントヘッダ
ビジネスドキュメントヘッダの送受信者情報や，ビジネスドキュメント情報，ビ
ジネスコラボレーション情報（たとえば，カンバゼーション ID やビジネスアクシ
ョン等），ステータス情報によりビジネスコラボレーションを制御する。
ビジネスドキュメントヘッダは，EDI-ASP や利用者側で参照・設定できるため，―70―きめ細かなビジネスプロセス制御が期待できる。しかし，ビジネスドキュメントヘ
ッダの内容が業界等で独自になるため汎用性に欠ける難点がある。しかし，ビジネ
スドキュメントヘッダの標準化は，ebXML においても検討が進展するものと考えられる。

6.2.3 ビジネスドキュメント制御
ebXML 実装において，ビジネスプロセス制御や送達確認（Acknowledgement）制御を実装する必要がある。このための情報は，利用者の利便性を考慮すると，ビジネスドキュ
メントによる制御を期待する。こうしたドキュメント制御のためには，ビジネスドキュメ
ントと ebXML との関係づけを整理しておく必要がある。

ｅｂＸＭＬ
ｅｂXMLメッセージヘッダ
ｶﾝﾊﾞｾﾞｰｼｮﾝID

メッセージID
タイムスタンプ

ビジネスドキュメント
ビジネスドキュメントヘッダ
サービス

アクション

発信者

受信者

ドキュメントステータス

ドキュメント本体
発注者

受注者

注文番号

メッセージ

タイムスタンプ

図 6.4

ビジネスドキュメント制御―71―

① メッセージ ID，カンバゼーション ID
メッセージ ID，カンバゼーション ID は，ビジネスドキュメントの交換毎，ビジ
ネスプロセス毎にユニークに付与される。
たとえば，「注文情報」標準メッセージの場合，注文番号に相当するものがカン
バゼーション ID に相当し，確定注文や注文変更，注文キャンセル等が発行される毎にメッセージ ID が付与される。そこで，業務上での理解しやすさを考慮すると，カンバゼーション ID を最初に付与する場合には，ビジネスドキュメント上の注文
番号から付与されることを期待する可能性がある。

6.2.4 クライアントインタフェース
クライアントインタフェースは，アプリケーションから EDI クライアントの送受信機能を利用するときのインタフェースである。クライアントインタフェースの種類と実現方法
を表 6.3 クライアントインタフェースの種類と実現方法に示す。
(1) コマンドコマンドとしては，送受信に対応して，「PutDocumnet」と「GetDocument」が基本となる。その他，電子メールと同様にドキュメント一覧を取得するための「QueryDocument」，Acknowledge 等のシグナルドキュメントを交換するための「ConfirmDocument」が想定できる。
これらから，交換するドキュメントの種別としては，「要求/応答ドキュメント」や「シグナルドキュメント」がある。
(2) 送受信先
送受信先は，送受信する URL や企業コードになるが，これらの情報は，ebXML
では CPA に格納されており，CPA 内の情報を参照することがある。そこで，送受信先を選択するため，CPA-ID やドキュメント内の情報を設定することになる。
(3) ビジネスアクション
ビジネスアクションは，例えば，「注文情報」標準メッセージなどの場合は，注文や注文変更，注文請けに相当し，どのビジネスプロセスのどのビジネスアクションなのかを示すため，カンバゼーション ID とビジネスアクション ID を指定することになる。また，ビジネスドキュメントから生成する場合には，注文番号やドキュメント
ID から生成することが想定できる。
(4) 格納場所
格納場所やトリガは，アプリケーション側からの利用形態により異なるが，ファイ
ルやフォルダ指定，シングルやバッチ指定が想定できる。また，ドキュメントとしては，ドキュメント本体以外に添付ファイルもあるため，格納方法も考慮する必要があ
る。

―72―

表 6.3

クライアントインタフェースの種類と実現方法

クライアントインタフェース
コマンド
ドキュメント種別
データ種別
トリガ
CPA
送信先企業コードビジネスアクション
ビジネスコラボレーション
格納方法
格納場所

6.3

実現方法
受信系
GET/QUERY
ドキュメント／シグナル指定なし／指定
シングル／バッチ
CPA-ID
送信先企業コードビジネスアクション ID
カンバゼーション ID
ファイル／ディレクトリ
ファイル名，フォルダ名

送信系
PUT/CONFIRM
ドキュメント／シグナル指定なし／指定
シングル／バッチ
CPA-ID
送信先企業コードビジネスアクション ID
カンバゼーション ID
ファイル／ディレクトリ
ファイル名，フォルダ名

EDI クライアント送受信・EDI サーバー間交換インタフェース

EDI クライアント送受信・EDI サーバー交換インタフェースは，EDI クライアント・
EDI サーバー間送受信インタフェースと，EDI サーバー間交換インタフェースの通したイ
ンタフェースである。

6.3.1 ebMS V3.0 実装方法
ebMS V3.0 では，従来のサーバー間インタフェース以外に，クライアント・サーバー間
インタフェースも OASIS で標準化を推進している。
クライアント・サーバー間インタフェースを標準化されると，サーバー間交換インタフ
ェースだけでなく，クラインアント・サーバー間送受信インタフェースも，同じ規格，例
えば，ebMS V3.0 で扱うことができる。そこで，具体的にはどのように実装できるのか，ebMS V3.0 による実装方法を以下に示す。
(1) サーバー間交換インタフェース
サーバー間のドキュメントの交換インタフェースは，Push 型のメッセージ交換にな る た め ， ド キ ュ メ ン ト の 送 信 ま た は 受 信 と も に ， 「 RequestMessage 」 と「AcknowledgementMessage」により実装できる。
(2) クライアント・サーバー間送受信インタフェース
クライアント・サーバー間の送受信インタフェースは，クライアントからサーバー
へのドキュメント送信は，サーバー間交換インタフェースと同じく，Push 型のメッセージ送信になるため，「RequestMessage」と「AcknowledgementMessage」により実装できる。また，サーバーからクライアントへのドキュメント受信は，クライア
ントからの Pull 型のメッセージ受信になるため，クライアントからのドキュメント
要求は「PullRequestMessage」，これに対するサーバーからのドキュメント送信は「PullResponseMessage」，その送達確認は「PullAcknowledgementMessage」に―73―

より実装する。
(3) BPSS Acknowlegement
BPSS レベルの「ReceiptAcknowledgemet」，「AcceptanceAcknowledgement」
は，「SignalDocument」として，通常の「Requset/ResponceDocument」と同様にして扱う。
図 6.5 ebMS V3.0 の実装方法に，ebMS V3.0 仕様に準拠した EDI メッセージ交換制御
を示す。

―74―

EDI クライアント

ＡＰ

MSH

ASP または EDI サーバー

ＭBX

MSH

ASP または EDI サーバー

ＭSＨ

ＭSＨ

ＭBX

EDI クライアント

ＭSＨ

MSH ＡＰPut Document(Request Document）
Request Ｍｅｓｓａｇｅ備考）ＡＰ:アプリケーションまたはアプリケーションプロキシ，ＭSＨ：メッセージサービ
スハンドラ，MBX：蓄積メールボックス（ Request Document）

Acknowledgment Message

Document(Request Data Document)
Request Ｍｅｓｓａｇｅ
Get Document（Request Document）
Acknowledgment

Pull Request Message

Document
Request Message(Receipt Acknowledgment Signal)
Get Document

Acknowledgment Message(Request Document)
Pull Response Message
Pull Acknowledgment Message

Pull Request Message(Acceptance Acknowledgment Signal)
Confirm Document(Acceptance Acknowledgment Signal)(Acceptance Acknowledgment Signal)(Acceptance Acknowledgment Signal)
Request Message
Acknowledgment Message
Request Message(Acceptance Acknowledgment Signal)
Acknowledgment Message

Pull Response Message
Pull Acknowledgment Message

図 6.5

ebMS V3.0 の実装方法

―75―

6.4

EDI メッセージ送受信・蓄積交換機能の Web サービス化の検討

本節では，共通 XML/EDI フレームワークの Web サービス利用を考察する。EDI メッセージ送受信・蓄積交換機能に関して，Web サービス*1 を利用したシステムモデルを検討・考察した。2.4 節の Pull 型 XML/EDI クライアントのシステム構成モデルの A タイプについて，Web サービス利用を検討した。
Web サービス*1：Web サービスとは，XML 技術を利用して疎結合の分散アプリケーシ
ョンを実現する技術及び提供サービスである。中核技術標準として，SOAP*2，WSDL*3，
及び UDDI*⁴がある。2000 年に V1.0 が制定・公開された。Web サービス利用システムの実証実験及び実ビジネス導入が始まっている。
SOAP（Simple Object Access Protocol）*2：ビジネス文書（EDI 標準メッセージ）の搬送のための封筒情報（ヘーダー，ボディ）の標準規約。
WSDL（Web Service Description Language）*3：Web サービス利用の情報（サービス
内容，インタフェース情報）を記述する言語。
UDDI（Universal Description, Discovery, and Integration）*⁴：Web サービスの探索・
統合サービスの規約。

6.4.1 個別実装方式
EDI サーバー

Push 型 XML/EDI
ebMS
インターネット

共通 EDI-ASP サービス
ebMS
EDI 蓄積，交換，変換，送受信

インターネット
ebMS, SOAP-RPC

EDI クライアント

EDI メッセージ送受信機能

XML/EDI ﾃﾞｰﾀ
EDI 簡易ｱﾌﾟﾘｹｰｼｮﾝ

ﾊﾞｯｸｴﾝﾄﾞｼｽﾃﾑ

図 6.6

EDI メッセージ送受信・蓄積交換機能の個別実装方式(1) 本方式の狙いz

現在主流のクライアント・サーバーシステムを実現したシステムモデルである。
―76―

(2) EDI サーバーのシステム機能z

Push 型 XML/EDI でシステム構築し，EDI 発注機能と受注機能を持つ。

z

EDI の送受信を実施する。共通 XML/EDI-ASP サービスとは ebMS［ebXML MS(Message Service)仕様］で接続する。

(3) EDI クライアントのシステム機能z

Pull 型 XML/EDI クライアント機能を実装する。Pull 型 XML/EDI クライアン
トは，共通 XML/EDI-ASP と ebMS 又は SOAP-RPC で接続する。Pull 型 EDI
クライアント機能を動作させて，結果として，所望の XML/EDI データを受信する。

zXML/EDI データを入力として，EDI 簡易アプリケーション機能を動作させる。

z

EDI 簡易アプリケーション機能は，XML/EDI データを基にして，画面表示，帳票印刷，バックエンドシステムとの接続を実施する。

z

画面表示，帳票印刷は MS Office 2003 (InfoPath, Excel)と XSLT，XSL-FO を
利用する。

z

バックエンドシステムとの接続は，XML データ又は CSV とする。CSV の時は，
XML-CSV トランスレータを実装する。

6.4.2 Web サービス方式
Push 型 XML/EDI

EDI サーバー

ebMS
インターネット

EDI 蓄積，交換，変換，送受信

共通 EDI-ASP
サービス

Pull 型 EDI
Web ｻｰﾋﾞｽ
WSDL

インターネット
SOAP, WSDLEDI クライアント
Pull 型 EDI
呼出しﾊﾟﾗﾒｰﾀ

Pull 型 EDI
Web ｻｰﾋﾞｽ呼出し

標準ﾒｯｾｰｼﾞ（XML ﾃﾞｰﾀ）
EDI 簡易ｱﾌﾟﾘｹｰｼｮﾝ

ﾊﾞｯｸｴﾝﾄﾞｼｽﾃﾑ

図 6.7

EDI メッセージ送受信・蓄積交換機能の Web サービス方式―77―

(1) 本方式の狙いz

本来の Web サービスのコンセプト（疎結合の分散アプリケーションを実現）を実現したシステムモデルである。

z

EDI クライアントとして，EDI 送受信機能は自身で実装しない。これらの機能
は，別途 Web サービスで提供される機能を利用する。

z

EDI 簡易アプリケーション機能は，EDI 標準メッセージ（XML データ）の表示・印刷機能が主体であり，この機能は共通 XML/EDI-ASP で Web サービス化しない。理由：XML データの表示・印刷機能は，オフライン処理の実現性，起動時の高速性およびコストパフォーマンスから個別に実装した方が良いと考えられる。

z

分散アプリケーションを実現するために，Web サービスの基本機能の SOAP とWSDL を実装する。

(2) 共通 XML/EDI-ASP のシステム機能z

Pull 型 EDI-Web サービス機能を構築して提供する。

z

クライアントと接続のための WSDL 文書を用意する。

(3) EDI クライアントのシステム機能z

Web サービス基本機能（SOAP，WSDL）を実装する。

z

取引先 ID，EDI 標準メッセージ種別などのパラメータを与えて Pull 型 EDI-Web
サービスを呼出す。結果として所望の EDI 情報（XML/EDI 標準メッセージ）を受信する。

z

受信した EDI 情報をパラメータとして，EDI 簡易アプリケーション機能を動作する。EDI 簡易アプリケーション機能は，EDI 情報（XML/EDI 標準メッセー
ジ）の画面表示とバックエンド接続を実施する。

z

クライアント PC 側の機能の Pull 型 EDI Web サービス呼出しと EDI 簡易アプ
リケーション機能は，JAVA 言語，VB 言語などを利用してシステム構築する。

―78―

6.4.3 MS Office 2003 を活用した Web サービス方式
Push 型 XML/EDI

EDI サーバー

ebMS
インターネット

EDI 変換，蓄積，交換，送受信

共通 EDI-ASP
サービス

Pull 型 EDI
Web ｻｰﾋﾞｽ
WSDL

インターネット
SOAP, WSDLEDI クライアント

Pull 型 EDI
呼出しﾊﾟﾗﾒｰﾀ

Pull 型 EDI
Web ｻｰﾋﾞｽ呼出し

InfoPath

標準ﾒｯｾｰｼﾞ（XML ﾃﾞｰﾀ）
XML Schema

画面表示・印刷XML Schema

XML⇒CSV 変換

Excel

ﾊﾞｯｸｴﾝﾄﾞｼｽﾃﾑ

図 6.8

EDI メッセージ送受信・蓄積交換機能の MS Office 2003 を活用した Web サービス方式

(1) 本方式の背景・狙いz

MS Office 2003（InfoPath，Excel，Word）には，Web サービス対応機能がある。この機能を有効活用することにより，EDI 送受信機能と MMI（Man
Machine Interface）機能（画面表示，帳票印刷）を実現する。

z

画面表示・印刷機能として InfoPath 2003 を利用する。画面表示フォーマット
が表計算形式でも良い場合は Excel 2003 の利用でも良い。但し，Excel 2003の場合は Web サービス呼出しのためのマクロが必要になる。（InfoPath 2003の場合はマクロが不要。）

z

InfoPath フォームに，画面フォーマット，XML Schema，Web サービス呼出し
パラメータが含まれる。

(2) 共通 XML/EDI-ASP のシステム機能z

Pull 型 EDI-Web サービス機能を構築して提供する。
―79―クライアントと接続のための WSDL 文書を用意する。

z(3) EDI クライアントのシステム機能
Web サービスの利用に必要な基本機能を実装する。Micrsoft Office Systemz

2003 には，Web サービスを利用するための基本機能が実装されている。
InfoPath のフォーム作成機能を利用して画面設計・開発および Web サービスz

連携を実現する。この時，XML Schema を参照して，XML/EDI 情報のデータ
属性チェックなどを実現できる。作成したフォームテンプレートは，インターネット等から配布する。
InfoPath 2003 の機能を利用して，取引先 ID，EDI 標準メッセージ種別などのz

パラメータを与えて Pull 型 EDI-Web サービスを呼出す。結果として所望の EDI
情報（XML/EDI 標準メッセージ）を受信する。
受信した XML/EDI 情報を InfoPath で作成されたフォームテンプレートを利用z

して画面表示・印刷する。
Excel 2003 は，XML データを読み込み CSV データで保存することも出来る。

z

この機能を活用して，バックエンドシステム接続用 CSV データを生成（ファイル形式）する。
その後，バックエンドシステムへ CSV データを送付する。

z

6.4.4 各方式の比較
以上の 3 方式のメリット・デメリットを整理して，表 6.4

EDI メッセージ送受信・蓄積

交換機能の Web サービス方式のメリット・デメリットに示す。それぞれの方式のシステム
機能，メリット，デメリット，他の条件などを具体的に評価して選定することになる。

表 6.4

EDI メッセージ送受信・蓄積交換機能の Web サービス方式のメリット・デメリット

方式

１．個別実装方式

EDI-ASP とEDI クライア
ント間の通
信方式
ebMS
SOAP-RPC

２．Web サービ
ス方式

WSDL
SOAP

３．MS Office

WSDL

メリット

・

従来からの実装方式で実現可能。
・ リッチクライアントとしての実装も可能。
・ 本来の Web サービスモデル。
・ クライアントアプリケーションシステ
ムが簡略化される。
・ EDI 送受信機能は ASP 機能となるため，改善・変更が統一して容易に実現できる。
・ マイクロソフトのソフトに縛られない方式。
・ クライアントアプリケーションシステ

―80―

デメリット

・

従来と同様に，クライアントシ
ステムアプリケーションの実装が必要。

・ JAVA，VB 言語を利用しての開発に専門技術が必要。

・

マイクロソフトのソフトに依存2003 利用 Web
サービス方式SOAP

ムを MS Office 2003 ベースで簡素化する。
・ 開発が易しく，カスタマイズ，メン
テが容易。
・ XML-CSV ト ラ ン ス レ ー タ が 不
要。

する方式。

6.4.5 補足説明
6.4.5.1 MS Office System 2003 と Web サービス基本機能(1) InfoPath 2003 機能z

InfoPath は，GUI インタフェースで画面設計・作成できる。

z

Web サービスを呼出せる。（SOAP，WSDL が動作する。）

z

各データ項目を XML Schema と対応付けて，各データの妥当性チェックなどが可能である。

z

画面表示のための XSLT スタイルシートを吐き出すことが出来る。吐き出した
XSLT スタイルシートを Word や Web ブラウザなどで利用可能。

(2) Excel 2003 機能z

Excel の各セルに XML Schema を対応付けて，XML データの読み書きができる。

zExcel に XML データを読み込み，CSV 形式で保存することもできる。XML→CSV のマッピングは Excel の機能を使って行う。CSV データとしての保存機能
は，InfoPath にはない。

(3) クライアント PC への Web サービス基本機能の実装
z

Windows 2000（Service Pack 3 以上）及び Windows XP は，.NET Framework
をインストールすることで Web サービスを利用するために必要な基本機能が実装される。.NET Framework はマイクロソフトの Web サイトからダウンロ
ードしてインストールできる。

z.NET Framework により，SOAP や WSDL を利用できるようになる。

z

Microsoft Office は，Microsoft Office 2003 Web Services Toolkit をインストー
ルすることで，Web サービスを利用するために必要な機能が実装される。
Toolkit はマイクロソフトの Web サイトからダウンロードしてインストールできる。

6.4.5.2 Web アプリケーションの構築方法(1) クライアント方式
Web アプリケーションの開発方式として，ファットクライアント，シンクライアン
ト，及びリッチクライアントの 3 方式がある。

―81―

表 6.5
クライアント方式
ファットクライアント

シンクライアント

リッチクライアント

クライアント方式

方式の説明

メリット

・ 従来からの C/S システムのク
ライアント。
・ クライアントソフトを事前に配布・実装する。
・ 全ての機能をサーバー側に実装する。
・ クライアントソフトは Web ブ
ラウザだけで動作する。
・ クライアント側で機能を動作させる。
・ クライアントソフトの機能の一部をサーバー側で管理する。
・ Web サービス技術などを活
用。

デメリット

クライアント側に高機能が
実現可能。

・

クライアントソフトの配布は必要ない。
・ 機能改善はサーバー側だけの変更で可能。

・

・

・

・

クライアント側に高機能が実現可能。
・ クライアントソフトの管理が，ファットクライアントよりは楽。
・ 表示系のような高速性を問われるものだけをクライ
アント側におくため，アプ
リケーションが軽くなる

クライアントソフトの配布，管理が難しい。

クライアントで動作させる機能が制限される。
・ サーバーに負荷がかかる。
・ ある程度のクライア
ントソフト管理が必要。例：パッチの適用，版数管理。

(2) クライアントソフトウェアの配布管理z

クライアントソフトウェアの配布管理方法として，一般的には，クライアント
システム構築時に，クライアント PC へダウンロード・インストールする方式と，プログラム実行時にクライアント PC 側へダウンロード・実行される方式がある。

z

クライアントシステム実行時に，クライアント PC へダウンロード・インストールする方式が，管理の簡略化とクライアントシステムの性能向上にメリットがある。

z

クライアントシステムに必要な機能によりコストパフォーマンスの良い方法の選択が必要である。

(3) プログラミング言語
クライアントソフトウェアや Web アプリケーションを開発するには，以下のような開発言語の選択肢がある。
z

JAVA

z

VB.NET

z

C#

―82―

7 EDI 簡易アプリケーションの機能と構造
本章では，汎用パソコンを利用して動作可能な EDI 簡易アプリケーションの設計ガイドを示す。2.4 節の Pull 型 XML/EDI クライアントのシステム構成モデルの A タイプを，具体的な機能構成に展開したものである。但し，他のシステム構成モデル（B タイプ，C タイプ，及び D タイプ）でも参考になる。

7.1

全体機能構成EDI 簡易アプリケーションの機能構成を図 7.1

EDI 簡易アプリケーションの機能構成に示す。図 7.1 の「簡易 EDI システム」の範囲が，EDI 簡易アプリケーションの機能範囲である。
EDI サーバー（ASP，他）
XML データ

インターネット
ルータ（HTTP，HTTPS）

ﾌｧｲｱｳｫｰﾙEDI ﾒｯｾｰｼﾞ
送受信機能
EDI ﾒｯｾｰｼﾞ
受信機能

EDI ﾒｯｾｰｼﾞ
送信機能

標準ﾒｯｾｰｼﾞ(表示)XML Schema
表示・印刷
機能

表示・印刷

指定納品伝票

簡易 EDI ｼｽﾃﾑ
（ｸﾗｲｱﾝﾄ PC）

設定
機能

標準ﾒｯｾｰｼﾞ（XML ﾃﾞｰﾀ）

標準ﾒｯｾｰｼﾞ(設定)XML Schema

管理ﾃﾞｰﾀ

入力
機能
標準ﾒｯｾｰｼﾞ(設定)XML Schema
送信メッセージ
B/E 連携機能

指定納品伝票印
刷機能
受信メッセージ
B/E 連携機能

社内バックエンド
システム
基幹 DB

図 7.1

EDI 簡易アプリケーションの機能構成

―83―

入力・印刷

7.2

簡易 EDI システムのデータファイル構造(1) 標準メッセージファイル（XML データ）
EDI メッセージ送受信機能から取り出した XML/EDI 標準メッセージを格納するファイルであり，2 種の方式がある。
表 7.1

標準メッセージファイルの方式

方式

ファイル構造EDI メッセージ送受
信機能

XML フ ァ
イル

・

・

DB
（ RDB 又は
XML-DB）

・

送受信結果の 1 個のトランザクションを格納する。
・ 各標準メッセージと注文一覧データなどがある。

複数のトランザクションを格納する。
・ 検索，並び替えなどが可能。

1 回の要求により，
1 個のトランザクショ
ンを処理する。
・ EDI メッセージ送受信機能としては，パラメータとして N 個のトランザクションを処理できるようにした方が良いかもしれない。
・ 1 回の要求により N個（又は 1 個）のトラ
ンザクションを送受信する。

アプリケーション
機能（表示，印刷，
バックエンド連携）
・ 1 個のトランザク
ション処理だけとなる。
・ 複数の EDI 取引
トランザクション処
理は，人間系で
実施。

評価

・

△
・ AP 構造の自由度が高いが複雑になる。
・ インターネット通信障
害時は，ASP 側の EDI
送受信処理の終了処理が未処理になる可能性がある。
・ DB 実 装 費 用 が 掛 かる。

複数のトランザ
クションを処理可能になる。

○
・ 簡易 AP 構造の方が良い。現状の Web-EDIの処理形態である。
・ インターネット通信障害 時 で も ， ASP 側 のEDI 送受信処理の終了処理が確実。

(2) 管理データファイル
管理データファイルとして，アプリケーション処理状況ファイルと社内バックエンド連携ファイル（B/E 連携ファイル）がある。
① アプリケーション処理状況ファイル
簡易アプリケーションの機能レベルによるが，アプリケーション処理状況を保存する機能が必要になる場合がある。例：注文情報処理機能で，処理状況（例：注文情報照会状況，注文請け回答状況，納期回答状況）の保存機能。この機能の実現方
法として，簡易 2 次元ファイル（例：MS Excell, Access）の利用が考えられる。
② 社内バックエンド連携ファイル（B/E 連携ファイル）
ダウンロード・アップロードのデータを一次格納するファイルである。

7.3

EDI メッセージ受信機能

EDI メッセージ受信機能は，主として電子商取引の受注者が必要になる機能であり，見積依頼情報，注文情報，納期確認情報，納入指示情報，買掛明細情報などの EDI 標準メッ
セージの受信処理機能である。また，発注者として，受注者からの応答情報（例：見積回答情報）の受信もある。
―84―

EDI メッセージ受信機能として，EDI 標準メッセージの表示・印刷機能，必要に応じて設定が必要な設定機能，指定納品伝票印刷機能，及び受信メッセージバックエンド連携機
能がある。

7.3.1 表示・印刷機能
表示・印刷機能は，EDI メッセージ送受信機能から得られた標準メッセージデータ（XMLデータ）を画面表示する。また画面の印刷をする。
表示・印刷機能の中で，必要に応じてデータダウンロードする。管理データファイルへ格納する。
(1) XSLT の利用
XSLT ｽﾀｲﾙｼｰﾄ（電機・電子）XSLT ｽﾀｲﾙｼｰﾄ（機械）
XSLT ｽﾀｲﾙｼｰﾄ（ｶｽﾀﾏｲｽﾞ）XSLT ﾌﾟﾛｾｯｻ
（変換）

標準ﾒｯｾｰｼﾞ（XML ﾃﾞｰﾀ）

図 7.2

HTML

表示・印刷

XSLT 利用による表示・印刷方式

z画面表示・印刷は HTML で表示・印刷する。HTML 変換は，XSLT を利用する。

z

XSLT スタイルシートは，業界グループ毎に作成する。業界グループ（例：共通
XML/EDI 実用化推進協議会）が提供する。

z

XSLT スタイルシートは，必要に応じて EDI クライアント側でカスタマイズできる。

z

IE（Internet Explorer）の基本機能で表示可能。

(2) MS InfoPath 2003 の利用
InfoPath ﾌｫｰﾑ
（電機・電子）InfoPath ﾌｫｰﾑ
（機械）
InfoPath ﾌｫｰﾑ
（ｶｽﾀﾏｲｽﾞ）
標準ﾒｯｾｰｼﾞ（XML ﾃﾞｰﾀ）

InfoPath

表示・印刷

XML Schema（中小企業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ）

図 7.3

MS InfoPath 2003 利用による表示・印刷方式
―85―

z

画面表示・印刷は，MS Office InfoPath 2003 を利用する。

z

InfoPath フォームは，業界グループ毎に作成する。業界グループ（例：共通
XML/EDI 実用化推進協議会）が提供する。

z

InfoPath フォームは，必要に応じて EDI クライアント側でカスタマイズできる。

(3) 各方式の比較
表 7.2

XSLT 利用

InfoPath2003 利用

Excel
利用

2003

表示・印刷方式の比較

メリット・ W3C が制定した国際標準。
・ MS Internet Explorer に組み込まれている。（無料）・ 使い易く，見栄えの良い画面設計が可能。
・ InfoPath の操作が易しい。
・ EDI ユーザーがカスタマイズ容易。
・ XML Schema を有効活用。
・ Excel の操作が易しい。
・ EDI ユーザーがカスタマイズ容易。
・ XML Schema を有効活用。

デメリット
・ XSLT が難しい。
・ EDI ユーザーによるカスタマイズが困難。
・ 購 入 が 必 要 。 25,000円。

評価○（使い分け）

・△（使い分け）

・

画面設計の自由度が少ない。
購入が必要。

○（使い分け）

7.3.2 設定機能
クライアント PC 側の機能として，受注者としての注文請書の設定，納期確認情報メッセージにおける回答情報の設定など，設定機能が必要になる。
設定機能の実現方法は，従来からのアプリケーション作成方法としての VB，JAVA など
でのプログラム開発と InfoPath を利用する方法がある。これらの方法の比較を表 7.3 に示
す。
表 7.3

VB，JAVA などでの開発
InfoPath 2003 利
用・

設定方式の比較メリット
自由に設計・開発可能。

GUI 方式で画面設計・開発が可能。
・ InfoPath の操作が易しい。
・ EDI ユーザーがカスタマイズ容易。
・ XML Schema を有効活用。
・デメリット
・ プログラミングによる開発で，工数がかかる。
・ 購 入 が 必 要 。 25,000
円。

評価
△
○

7.3.3 指定納品伝票印刷機能
発注側企業は，企業毎又はその工場毎の指定納品伝票を要求することが多い。通常，バーコードが利用されている。JEITA の ECALGA 仕様では，標準納品書として標準化している。
z

フォーマットの雛型は，業界グループ毎に作成する。業界グループ（例：共通―86―

XML/EDI 実用化推進協議会）が提供する。
z

各企業又は各工場毎にカスタマイズが必要になる。

(1) XSLT の利用z

XSLT スタイルシートで帳票フォーマットを定義する。

(2) XSL-FO の利用
帳票印刷用の標準仕様として，W3C が XSL-FO（Formatting Object）を標準化している。

FO ｽﾀｲﾙｼｰﾄ（電機・電子）FO ｽﾀｲﾙｼｰﾄ（機械）
FO ｽﾀｲﾙｼｰﾄ（ｶｽﾀﾏｲｽﾞ）XSLT ﾌﾟﾛｾｯｻ
（変換）

標準ﾒｯｾｰｼﾞ（XML ﾃﾞｰﾀ）

図 7.4

XSL-FOXSL-FO
ﾌﾟﾛｾｯｻ印刷

XSL-FO 利用による指定納品伝票印刷方式z

XSL-FO スタイルシートで帳票フォーマットを定義する。

z

XSL-FO プロセッサを利用して帳票印刷する。XSL-FO プロセッサは，アンテ
ナハウスの XSL Formatter などがある。

(3) MS Word 2003，MS Excel 2003 の利用
Word, Excel ﾌｫｰﾑ
（電機・電子）Word, Excel ﾌｫｰﾑ（機械）
Word, Excel ﾌｫｰﾑ
（ｶｽﾀﾏｲｽﾞ）

標準ﾒｯｾｰｼﾞ（XML ﾃﾞｰﾀ）

Word 2003
Excel 2003

表示・印刷

XML Schema（中小企業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ）

図 7.5
z

MS Word 2003，MS Excel 2003 利用による指定納品伝票印刷方式

XML 対応した MS Word 2003，又は MS Excel 2003 を利用して帳票フォーマットを定義する。
―87―

XML Schema を利用した帳票機能になる。

z(4) 各方式の比較
表 7.4

指定納品伝票印刷の各方式の比較
メリット

デメリット

・

・

MS Internet Explorer に組み込まれている。
XSLT は国際標準。

XSL-FO 利用

・・

細かい印刷フォーマットが可能。
XSL-FO は国際標準。

・
・

Word 2003 利用

・
・
・
・
・
・

操作が簡単。
XML Schema を有効活用。
操作が簡単。
XML Schema を有効活用。
表計算機能がある。
何でも出来る。

・XSLT 利用

・

Excel 2003 利用

個別アプリケーシ
ョンで作成

・

・

・

細かい印刷フォーマットが不可能。
EDI ユーザーによるカスタマイズが困難。
購入・入手が必要。（注２）
EDI ユーザーによるカスタマイズが困難。
細かい印刷フォーマットが不可
能。
細かい印刷フォーマットが不可能。
標準でなく，流通・再利用が困
難。

評価
（注
１）
△

○

△
○

△

注１：指定納品伝票の種類によって使い分けが可能である。
注２：XSL-FO ツールとして，アンテナハウスの XSL Formatter とフリーソフト「Apache FOP」がある。
① アンテナハウスの XSL Formatterz

W3C 勧告 XSL-FO V1.0 に準拠

z

スタンドアロンライセンス：126,000 円／CPU，サーバーライセンス：525,000
円／CPU② フリーソフト「Apache FOP」
z

フ リ ー の XSL-FO フ ォ ー マ ッ タ と し て オ ー プ ン ソ ー ス 団 体 の Apache
Software Foundation が提供している Apache FOP がある。

z

FOP を使って XSL-FO から PDF 形式に変換してから印刷・出力することができる。ただし，FOP には，ⓐデフォルト設定では，日本語フォントが使えないため，インストール後の設定変更が必要，ⓑ開発途上であるため（最新バージョンは，0.20.5 版），未サポートの XSL-FO 機能が少なからず残っている，などの問題がある。ⓑの問題については，帳票出力にどのくらいの書式設定機能が求められるのか不明だが，凝った帳票でなければ FOP で事足りる可能性がある。

7.3.4 受信メッセージバックエンド連携機能
z

EDI クライアント企業が受注側の場合，バックエンドシステム（B/E システム）は受注システム，販売管理システムなどになる。
―88―

z

受注システムは，各企業が開発した固有のシステム，ERP パッケージ，汎用ソフト（例：OBC 商奉行）などが考えられる。

z

B/E システムとのデータインタフェースは，XML と CSV が考えられる。

z

B/E 連携機能は，表示・印刷機能で得られたダウンロードデータを必要に応じてフォーマット変換をして，B/E システムに格納する。
管理データ

B/E 連携機能XML
B/E システム

固有
ｼｽﾃﾑ

図 7.6

表 7.5

XML

CSV

7.4

XML
ﾄﾗﾝｽﾚｰﾀ
CSV
ERP
ﾊﾟｯｹｰｼﾞ汎用
ﾊﾟｯｹｰｼﾞ

受信メッセージバックエンド連携機能の方式

受信メッセージバックエンド連携機能の方式の比較

メリット・ XML の特色の拡張性・柔軟性が活かせる。
・ XML はインターネット世界の今後のデータ標準。
・ トランスレータが不要。
・ 従来のシステムは CSV が多い。

デメリット

・
・

拡張性・柔軟性がない。
トランスレータが必要に
なる。

評価
○

△

EDI メッセージ送信機能

EDI メッセージ送信機能は，主として電子商取引の発注者が必要になる機能であり，見積依頼情報，注文情報，納期確認情報，買掛明細情報の EDI 標準メッセージの発信処理機能である。また，受注者として，発注者への応答情報（例：見積回答情報）の送信もある。
EDI メッセージ送信機能として，EDI 標準メッセージの入力機能がある。社内バックエ
ンドシステムのデータを連携して入力する必要がある場合は，送信メッセージバックエンド連携機能を実装する。

7.4.1 入力機能
入力処理の実現方法は，従来からのアプリケーション作成方法としての VB，JAVA など
での開発と MS InfoPath，MS Excel を利用する方法がある。これらの方法の比較を表 7.6
―89―

に示す。
表 7.6

VB，JAVA など
での開発
InfoPath 2003
利用

Excel 2003 利用

入力機能方式の比較

・メリット
自由に設計・開発可能。

・
・
・
・
・
・
・

GUI 方式で画面設計・開発が可能。
InfoPath の操作が易しい。
EDI ユーザーがカスタマイズ容易。
XML Schema を有効活用。
Excel の操作が易しい。
EDI ユーザーがカスタマイズ容易。
XML Schema を有効活用。

・
・

・
・

デメリット
プログラミングによる開発
で，工数がかかる。
購入が必要。25,000 円。

画面設計の自由度が少ない。
購入が必要。

評価
△
○

△（使い分
け）

必要に応じて，社内バックエンドシステムからのデータを連携して入力する。アップロード機能で実現する。

7.4.2 送信メッセージバックエンド連携機能
z

EDI クライアント企業が発注側の場合，バックエンドシステム（B/E システム）は
購買システムなどになる。

z

購買システムなどは，各企業が開発した固有のシステム，ERP パッケージ，汎用ソ
フト（例：OBC 商奉行）などが考えられる。

z

B/E システムとのデータインタフェースは，XML と CSV が考えられる。

z

B/E 連携機能は，社内バックエンドシステムにある該当データを，必要に応じてフォーマット変換して入力機能へ渡す。

管理データ

B/E 連携機能XML
B/E システム

図 7.7

固有
ｼｽﾃﾑ

XML
ﾄﾗﾝｽﾚｰﾀ
CSV
ERP
ﾊﾟｯｹｰｼﾞ汎用
ﾊﾟｯｹｰｼﾞ

送信メッセージバックエンド連携機能の方式―90―表 7.7

送信メッセージバックエンド連携機能の方式の比較

メリット・ XML の特色の拡張性・柔軟性が活かせる。
・ XML はインターネット世界の今後のデータ標準。
・ トランスレータが不要。
・ 従来のシステムは CSV が多い。

XML

CSV

・
・

7.5

デメリット

評価
○

拡張性・柔軟性がない。
トランスレータが必要になる。

△

各種標準文書の管理(1) 共通管理z

共通に利用される各種標準文書は，共通のデータベースとして提供されることが望ましい。例：共通 XML/EDI 実用化推進協議会のホームページで提供。

z

各種標準文書の内容は，
図 7.8 共通 XML/EDI 標準データベースの内容に示す。

共通 XML/EDI
標準データ
ベース

中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
ｽﾌﾟﾚｯﾄﾞｼｰﾄ

中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
XML Schema

中小製造業 UBL ｻﾌﾞｾｯﾄ
ｽﾌﾟﾚｯﾄﾞｼｰﾄ

中小製造業 UBL ｻﾌﾞｾｯﾄ
XML Schema

中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
XSLT ｽﾀｲﾙｼｰﾄ（電機・電子）

中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
XSLT ｽﾀｲﾙｼｰﾄ（機械）中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
InfoPath ﾌｫｰﾑ（電機・電子）

中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
InfoPath ﾌｫｰﾑ（機械）中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
納品伝票
XSLT ｽﾀｲﾙｼｰﾄ（電機・電子）

中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
納品伝票
XSLT ｽﾀｲﾙｼｰﾄ（機械）中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
納品伝票
XSL-FO（電機・電子）

中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
納品伝票
XSL-FO（機械）中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
納品伝票
Excel（電機・電子）

中小製造業 EDI ﾒｯｾｰｼﾞﾓﾃﾞﾙ
納品伝票
Excel（機械）図 7.8

共通 XML/EDI 標準データベースの内容―91―

(2) 共通 XML/EDI 標準データベースのフレームワーク
共通 XML/EDI 標準データベースのフレームワークとして，ホームページの文書ページと ebXML R&R 標準準拠の二種類が考えられる。
表 7.8

共通 XML/EDI 標準データベースのフレームワークの比較

ホームページの
文書ページ

・

ebXML R&R 準拠

・

メリット
簡単に構築可能。

デメリット

登録・検索の各種機能
がある。

・
・

―92―

複雑。
ebXML R&R ソフトウ
ェアが必要。

評価○（単純なデータベース。各業界標準の提供は本方式。）△

8 中小製造業 EDI メッセージモデルの応用・実装検討
本章では，3 章で策定した中小製造業 EDI メッセージモデルに関する応用・実装検討として以下の 2 種を実施した。
z

中小製造業 EDI メッセージモデルを，国際標準 EDI メッセージの UBL にマッピングし，UBL サブセットを策定した。この試行を通して UBL を評価した。

z

中小製造業 EDI メッセージモデルのデータ項目を，ebXML CC 仕様に展開し，ebXML
CC 仕様をベースとした EDI 標準メッセージの作成の容易性について考察した。

8.1 中小製造業 EDI メッセージモデル/UBL マッピング
8.1.1 マッピングの背景・目的z

UBL の利用ユースケースを具体的に検討・評価する。

z

UBL 利用の最大の可能性として国際取引がある。特に東アジア圏（日本，中国，香港，韓国）では UBL 地域普及活動（UBL Localization Sub Committee）に積極的に参加しており，東アジア圏における国際取引での UBL 利用の可能性が高い。

z

日本で利用実績の高い EIAJ 標準の後継の XML/EDI 標準メッセージの ECALGA
を UBL へマッピングすることにより，ECALGA ベースの UBL サブセットの策定
可能性と問題点・課題を検証する。

8.1.2 マッピングの方法(1) マッピング方法z

ECOM の中小企業 EC/EDI 普及 SWG が策定した「中小製造業 EDI メッセージモデル（注文情報）」をキーにして，UBL V1.0 にマッピングした。UBL V1.0
は，2004 年 11 月に OASIS 標準として承認・公開されたものである。UBL の
データ項目表は，UBL Name と UBL Definition が日本語翻訳されたデータ項
目一覧表（UBL 注文日本語 V1.0，UBL 再利用日本語 V1.0）を利用した。UBL
注文日本語 V1.0
（UBL Order V1.0 Japanese）と UBL 再利用日本語 V1.0
（UBL
Reusable V1.0 Japanese） は，UBL JPLSC（Japanese Localization Sub
Committee）が作成した UBL データ項目表である。

z

中小製造業 EDI メッセージモデル項目（必須，準必須，及び任意）のみを UBLにマッピングした。その他のデータ項目は無視している。その他のデータ項目の中でも UBL へマッピングできる項目はある。

z

該当する UBL のビジネスドキュメントは，UBL 注文（UBL Order）と UBL
再利用（UBL Reusable）である。

(2) マッピング表「中小製造業 EDI メッセージモデルの UBL マッピング表（注文情報）」z

中小製造業 EDI メッセージモデル（注文情報）の各データ項目に対して，該当する UBL のデータ項目（UBL 注文と UBL 再利用）をマッピングした。UBLのデータ項目は，UBL Name（BIE 又は CCT），Dictionary Entry Name，Representation Term，Cardinality，Component Type，及び日本語（UBL―93―

JPLSC）とした。
z

UBL マッピング表の左列に，「BIE」として，マッピング該当する UBL デー
タ項目の ABIE 名，ASBIE 名，BBIE 名を示した。この BIE 名は，UBL においてデータ項目を一意に定義できるデータ項目名称となる。

z

中小製造業 EDI メッセージモデルの UBL マッピング表（注文情報）を付表 5.1に示す。

8.1.3 マッピング不可能項目の解説
中小製造業 EDI メッセージモデル（注文情報）のデータ項目に関し，UBL に直接当ては
まる BIE がないデータ項目がある。表 8.4

中小製造業 EDI メッセージモデル／UBL マッ

ピングでのデータ項目の説明を参照。

8.1.4 マッピング結果(1) UBL マッピング可否の合計
表 8.1

中小製造業 EDI メッセージモデル（注文情報）の UBL マッピング可否の結果

必須項目
準必須項目
任意項目
合計

中小製造業 EDI
メッセージモデルのデータ
項目数合計
15 個
27 個―2 個
41 個
83 個―2 個

マッピング可能

マッピング代用可能

マッピング不可能

マッピング可能
＋代用可能

14 個
15 個
13 個
42 個

0個
5個
10 個
15 個

1個
5個
18 個
24 個

14 個
20 個
23 個
57 個

93%
60%
32%
52%

0%
20%
24%
19%

7%
20%
44%
30%

93%
80%
56%
70%

「―2 個」：別のビジネスドキュメントとなり，マッピング対象外。
(2) マッピング結果の評価
z

中小製造業 EDI メッセージモデルの必須項目は殆ど UBL にマッピングできる（マッピング可能率：93%）。必須項目の内，単価区分（確定，変更，未定）
のみが UBL にマッピングできない。単価区分は常に確定とする。

z

準必須項目は，代用可能を含めると 80%のマッピング可能率である。

z

任意項目は，代用可能を含めると 56%のマッピング可能率である。

z

必須，準必須，及び任意項目を全て合わせた全体では，UBL マッピング可能率（代用可能を含む）は 70%であり，マッピング可能率が高い。

z

マッピング不可能率が 30%あるが，この内殆どは運用で逃げられ，運用レベルで大きな障害にならない。例：消費税区分は常に税抜きにする。単価区分は単
価未定発注などに使用されるが，単価未定発注は下請法で禁止されており，中小企業取引では常に確定の取引とする。運用レベルでの対策は，表 8.4

中小製造業 EDI メッセージモデル／UBL マッピングでのデータ項目の説明を参照ください。
z

総合的には中小製造業 EDI メッセージモデルをほぼ UBL にマッピング出来，―94―

運用レベルを含めて対応することにより，中小製造業 EDI メッセージモデルのデータ項目の範囲で UBL サブセットと相互運用性のある EDI 取引が可能である。但し，実際の EDI 取引の場合は，UBL サブセットを導入する業界又は国際で再評価・設計が必要である。

8.1.5 評価
8.1.5.1 ビジネスドキュメントの相違(1) データ項目名称の構造z

UBL Name は，１つの BIE を取り出して全てが解る名称となっていない。EDI
電文の XML インスタンスでは，構造化タグがあるので判断できる。

z

一方，中小製造業 EDI メッセージモデル（ECALGA ベース）のデータ項目名称
は，１つのデータ項目名称のみで解るデータ項目名称となっている。

(2) ビジネスドキュメントの構造
表 8.2

ビジネスドキュメントの構造

中小製造業 EDI メッセージモデル（ECALGA ベース）
１品１葉分割納入可能

UBL

評価

N 品１葉
分割納入可能１品１葉で運用する。
問題なし。

(3) データ項目の構造
表 8.3
中小製造業 EDI メッセージモデル（ECALGA ベース）
中小製造業 EDI メッセージモデル（ECALGA ベース）のデータ項目順
（例）
・ 発注者
・ 受注者
・ 注文 BD 情報
・ 取引方法・ 取引物品・ 納入条件・ 金額計算条件
・ リユーザブルの構造がない。
・ 同一のデータ項目が併記されている。

データ項目の構造

UBL

評価

UBL クラス順（例）・ Order 基本情報
・ Reusable の 各
BIE

・
・

・

・

・

リユーザブルの構造化している。
同 一 の BIE は
Reusable として 1個の定義である。

8.1.5.2 データ項目の内容（XML インスタンス）(1) 各コードの内容は取引時に決定する必要がある。
例：検査区分，X(3)
―95―

・

・

基本的には整合していない。
実質的なデータ項目ではマッピン
グできるように割り切る。
UBL サブセットの場合は，UBL ク
ラス順の XML インスタンスにする。
別途，UBL サブセット表が必要。

それぞれのメリット・デメリットがある。
割り切って理解する。

(2) XML インスタンスの内容は，国際取引に適切な表現にする必要がある。
z

英語表示，ローマ字表示が必要。
例：住所，購買担当(名称)の内容
東京都品川区大崎 1-11-2 富士太郎（日本語）
11-2, Osaki 1-chome, Shinagawa-ku, Tokyo Tarou Fuji（英語）z

中小製造業 EDI メッセージモデル（ECALGA ベース）には漢字のデータ項目が数個ある。UBL の BBIE「Name」の Attribute で，Language.Identifier を指定することにより漢字を使用できる。

8.1.5.3 中小製造業 EDI メッセージモデル（ECALGA ベース）から UBL サブセットへの変換(1) データ項目内容（XML インスタンス）の変換
z

必要に応じて，データ項目内容（XML インスタンス）の変換が必要である。

(2) データ項目構造の変換z

中小製造業 EDI メッセージモデル（ECALGA ベース）の複数のデータ項目が，UBL サブセットの 1 つの BIE に対応する場合があり，適切に変換が必要である。

z

例：納期，納入時刻の 2 項目（ECALGA）→RequestedDeliveryDateTime の 1
個の BIE（UBL）

8.1.5.4 中小製造業 EDI メッセージモデルと UBL の相互運用性(1) 東アジア圏での UBL サブセットの相互運用性z

中小製造業 EDI メッセージモデル/UBL サブセットは，中小製造業 EDI メッセージモデルを UBL にマッピングしたものであり。ECALGA がベースになっている。

z

中小製造業 EDI メッセージモデルは，ほぼ UBL にマッピングできる。マッピ
ング出来ないデータ項目もあるが，運用上差し支えない状況である。参照：表
8.4 中小製造業 EDI メッセージモデル／UBL マッピングでのデータ項目の説明の UBL 運用の対策。

z

東アジア（韓国，中国など）で独自の UBL サブセットを作成したら，彼らのUBL サブセットと整合しない可能性がある。

z

取引先双方で，UBL サブセットの BIE（Business Information Entity，ビジネ
ス情報項目）のチェックが必要である。

(2) UBL の相互運用性z

UBL Order には，配下の Reusable を含めると 300 以上の BIE がある。

z

UBL Order のそのままでは，基本的に相互運用性の確保は不可能である。実際の EDI 取引の場合，300 以上の BIE を全て使用することはあり得なく，選択した BIE は取引先毎に異なるのが自然である。
―96―

z

UBL の実際的応用は，業種・業界毎に適切な UBL サブセットを策定して活用すべきである。

8.1.6 UBL TC へのコメント（マッピングのデータ項目の説明以外）
z

AllowanceCharge の中に CurrencyCode がある。BasePrice の中にも CurrencyCodeが必要と思われる。

―97―

表 8.4 中小製造業 EDI メッセージモデル／UBL マッピングでのデータ項目の説明
運用対策：A：代用可能の BIE を利用，B：UBL では使用しない，C：別のビジネスドキュメント
No.

中小製造業 EDI メッセージモデルのデータ項目

直接マッピング対象の UBL の BIE

代用の BIE，CCT など

共
通
部3
6

データ作成日（準必須）

UBL にない。

なし。

UBL ではビジネスドキュメントがそれぞれ異なる。

―

16

訂正コード（準必須）（ビジネスドキュメントは注
文情報で共通）・ １：新規・ ２：変更・ ３：取消購買担当(漢字)（任意）UBL にない。

26

営業担当(漢字)（任意）UBL にない。

明
細部5

発注形態区分（任意）・ 発注形態を示すコード。
・ 個別発注，グループ発注，総量注文等。
・ X(2)
変更注文区分（準必須）
・ どこのデータ項目が変更したかの区分。
・ ECALGA では，新規注文と変更区分で，同一の注文情報を使用する。
・ １△：数量変更
・ ２△：単価変更
・ ３△：納期変更
・ 他
親注文番号（任意）・ グループ発注時，発注者が採番した親の注文番号。
予約番号（任意）
注文請け返信期限（任意）UBL にない。

UBL の BBIE「Name」の Attribute で， A
Language.Identfier を指定することにより漢字を書ける。*1。
UBL の BBIE「Name」の Attribute で， A
Language.Identfier を指定することにより漢字を書ける。*1。
なし。
B

・

―

C

UBL にない。

なし。

B

UBL にない。
UBL では以下の BIE がある。
・ 注文有効期間開始日
・ 注文取消可能期限
・ 有効期間（日数）

なし。
なし。

B
B

6

7
10
11

・

UBL では別のビジネスドキュメントの「Order
Change」がある。
DocumentStatusCode（文書状態コード）が対応
する。

―98―

UBL 運用の対策
運 用 運用方法コメント
対策
B
運用上，発注日（IssueDate）で代用できる。
C
ビジネスドキュメン
トが別になる。

Order Change を使用
する。

21

22

23
25

27
34

・

コック区分（準必須）
１：通常品
２：コック品・ コック品とは，発注者の倉庫に取引品を補充する取引方式のこと。コンサイメント取引の意。
ビジネスモデルは，コラボレイティブ EDI のコ
ンサイメントモデルだが，EDI 標準メッセージ
としては，「注文情報」を使用する。
・ 支給区分（準必須）
１：支給なし２：有償支給３：無償支給４：混在
・ 本データ項目は，支給品の有無を指定するデー
タ項目である。支給品の内容は本 EDI メッセー
ジで指定しなく，別途連絡する。
・ 直納区分（準必須）
１：通常品
２：直納品（納入指定場所あり）
契約条件区分（任意）

納入指示有無区分（任意）・ １：納入指示なし
・ ２：納入指示あり
品名（品名仕様）（必須）・品名（品名仕様）は一般的な製品名称。

35

品名（品名仕様）（漢字）（任意）36

版数（準必須）・ 図面・仕様書等の作成・変更回数を表す。
・ 品名・品名コードと共に製品の内容を特定する。
戦略物資区分（任意）
発注品仕様（任意）

39
44

・
・

・
・

UBL にない。
UBL TC に提案する。「SCM のコンサイメント取引機能でコンサイメント取引区分が必要である。Item 配下又は適切な場所に個別の BIE（コンサイメント取引区分）を追加するか，Special
Description などの BIE を追加して欲しい。」

・・・
UBL にない。
UBL TC に提案する。「支給区分が必要である。
Item 配下又は適切な場所に個別の BIE（支給区 ・分）を追加するか，Special Description などの BIE を追加して欲しい。」

UBL で は ， DeliveryTerm の ， 納 入 条 件 ID とSpecialTerms（Text，納入条件特記事項）にマッピング可能。
・ SalesConditions ID にマッピングした。
・ Reusable の Contract.Contract Type.Code の方が適していると思われる。但し，Order の BIEに含まれていない。UBL TC に提案する。
UBL にない。
・ UBL の Item の Description が該当する。
・ ECALGA では，「品名（品名仕様）」と「発注品仕様」の 2 種のデータ項目がある。これに相当する UBL の BIE は，Item の Description しかな
い。品名と発注品仕様（品名説明）の両方の BIEがあった方が良く，UBL TC に提案する。
UBL にない。
UBL にない。

UBL にない。
・ UBL にない。
・ ECALGA では，「品名（品名仕様）」と「発注品―99―

Item の Description で代用可 A 又はB能。
DeliveryTerm（納入条件）の，納入条件 ID と SpecialTerms（Text，納入条件特記事項）は納入条件であり，代用不可能。

B の場合は通常品の範囲の取引とする。

Item の Description で代用可 A 又能。
はBDeliveryTerm（納入条件）の，納入条件 ID と SpecialTerms（Text，納入条件特記事項）は納入条件であり，代用不可能。

B の場合は支給なしの範囲の取引とする。

――

DeliveryTerm の，納入条件 ID とSpecialTerms（Text，納入条件特記事項）で代用可能。

A 又
はB
―

UBL の BBIE「Name」の Attribute で， A
Language.Identfier を指定することにより漢字を書ける。*1。
Item
の
中
の A 又
AdditionalItemIdentification（そ は Bの他商品識別）で代用可能。
なし。
Item の Description で代用する。

B
A 又
はB

B の場合は納入指示なしと割り切る。

仕様」の 2 種のデータ項目がある。これに相当する UBL の BIE は，Item の Description しかな
い。品名と発注品仕様（品名説明）の両方の BIEがあった方が良く，UBL TC に提案する。
UBL にない。

45

発注品仕様（漢字）（任意）52

検査区分（準必須）
・ 検査方法を示すコード。
・ X(3)
仕様書有無（準必須）
・ １：なし・ ２：あり図面・仕様書枚数（任意）
図面・仕様書番号（任意）
要求書部数（任意）
試験成績書要否区分（任意）・ １：要・ ２：不要指定メーカ名（任意）・ 商社経由の取引において，元発注者が商社に指定した製品を製造するメーカ名。
エンドユーザ名（漢字）（任意）・・UBL にない。
UBL TC に提案する。

・・UBL にない。
UBL TC に提案する。

エンドユーザ注文番号（任意）・ 商社経由の取引において，商社に対する元発注者が注文情報に付与した管理番号。
・ 商社と受注者間で必要になった場合に使用する。
・ 単価区分（必須）
１：確定
２：変更
３：未定
４：別途定められたさん低方法による単価
・ 器具部品，レアメタルなど原料の価格が市場の相場で変動するため，発注時に単価が決められない部品購入の場合に「単価未定」を使う。

56
57
58
61
64
68
72
76

78

UBL の BBIE「Name」の Attribute で， A
Language.Identfier を指定することにより漢字を書ける。*1。

UBL にない。
UBL にない。
UBL にない。
UBL にない。

なし。
なし。
なし。
なし。

B
B
B
B

UBL にない。

なし。

B

UBL にない。
UBL にない。

UBL の BBIE「Name」の Attribute で， A
Language.Identfier を指定することにより漢字を書ける。*1。
なし。
B

UBL にない。

なし。

―100―

B

・ 常に確定相当にする。
・ 単価未定の発注は注文金額（単価×数量）も未定になる。注文金額なしの発注は，下請法で禁止されている。下請法で守られる中小企業取引
では，単価未定発
注はないものとする。
84

UBL にない。

102

主材料ベース（任意）・契約時の主材料のベース単価を表す。
単位（必須）
X(3)（例）・ PC△：個・ KPC：千個・ BT△：本（Bottle）
・ ST△：式・ M△△：メートル・ KM△：キロメートル
・ G△△：グラム・ KG△：キログラム
条長（任意）
・ 注文数をある単位の量に切り分け納入する場
合の切り分け数量を示す。
・ 電線業界における取引において必要なデータ項目である。例：納入数量は巻きロール数での納入の場合，長さは条長で数量（長さ）を指定する。
条長個数（任意）・ 同上数量に対する個数を示す。
受渡場所名（準必須）
・ 受渡場所と納入先の違いは以下の事例を参照。
・ 納入先住所：日野市豊田 1-1-2
・ 受渡場所：東 2 号館東側入口
受渡場所名（漢字）（準必須）105

納入先住所（漢字）（任意）UBL にない。

106

納入先宛先名（任意）・ 納入先名称及び宛先。
・ 法人名，所属，氏名の順とし，間にスペース 1
桁以上を空ける。
・ X(100)

・
・

107
109

納入先宛先名（漢字）（任意）納入時連絡先（任意）・ 製品を納入する際の連絡先電話番号など。

88

95

96
101

・

なし。

CCT の QuantityUnitCode に該当する。*2。

B―

UBL にない。

なし。

B

UBL にない。

なし。

B

UBL にある。

―

UBL にない。

UBL の BBIE「Name」の Attribute で， A
Language.Identfier を指定することにより漢字を書ける。*1。
UBL の BBIE「Name」の Attribute で， A
Language.Identfier を指定することにより漢字を書ける。*1。
なし。
B

UBL にない。
Address の BIE の並びが整理されていない。整理すべき。
・ Contact（法人名，所属，氏名など）がない。
追加すべき。
・ 上記を UBL TC に申し入れる。
UBL にない。
UBL にない。

―101―

なし。
なし。

B
B

121

・ X(18)
発注者バーコード情報（準必須）・ 納入条件の中にある。
発注者用備考（準必須）・ UBL にない。
・ UBL TC に提案する。
UBL にない。

122

発注者用備考（漢字）（任意）UBL にない。

123

納品書価格表示区分（任意）UBL にない。
・ 標準納品書使用時において，帳票上の単価・金額等の表示パターンを示すコード。
消費税区分（準必須）
UBL にない。
・ １：税込み
・ UBL の基本的考え方は，単価等には税金が含ま
・ ２：税抜きない。
・ 単価と注文金額（単価×注文数量）に該当する。 ・ 合計金額として，課税対象額と合計税額がある。
注文金額
UBL にある。
・単価×注文数量
合計額（準必須）
UBL にない。
・消費税区分が税込みの場合は金額。税抜きの時は，金額＋消費税額。

120

125

134
138

144

備考（漢字）（任意）Note で代用可能。

UBL にない。

A 又
はB
UBL の BBIE「Name」の Attribute で， A
Language.Identfier を指定することにより漢字を書ける。*1。
なし。
B
なし。

B

・常に税抜きとする。

なし。

B

・
・

計算で可能。
LineExtensionT
otalAmount （課税対象額）＋
TaxTotalAmount（合計税額）UBL の BBIE「Name」の Attribute で， A
Language.Identfier を指定することにより漢字を書ける。*1。

*1：漢字の記述：①UBL の BBIE「Name」の Attribute で，Language.Identfier を指定することにより漢字を書ける。Language.Identfier は，CCT「Text.Type」の CCT Components
として標準化定義されている。XML Instance 例：<Name Language.Identfier =”ja”>日本企業</Name>②郵送などの場合，住所などは現地語が必要になる。英語（ローマ字）と現地語の両方の表記が必要になる。これを実現するには，UBL の BBIE「Name」を複数記述できるようにすれば良い。現仕様の UBL の BBIE「Name」の Cardinality は，「0..1」となっているので，これを「0..*」にすると良い。UBL TC に提案する。
*2：単位の記述：CCT の QuantityUnitCode で記述できる。XML Instance 例：<Quantity QuantityUnitCode=”kg” >10</ Quantity >

―102―

8.2

ebXML CC 仕様に基づいた中小製造業 EDI メッセージモデル実装の検討

8.2.1 ebXML CC 仕様に基づいた中小製造業 EDI メッセージモデル実装の背景・目的
現在 EDI が普及している業界は，EDI に熱心な業界団体やリーダシップを持って標準メッセー
ジの開発をリードする企業が存在するケースがほとんどである。今後，中小企業への EDI 普及を考えるとき，
このような恵まれた環境にない業種に属する中小企業がどのようにして自分たちの業務に合った EDI メッセージを手に入れるかが重要な課題となる。
中小企業に限らず，EDI のメッセージはなるべく既存の標準メッセージを使用することが望ましいことは論を待たない。したがって，利用可能な他業界の標準メッセージがある場合には，進んでこれを採用するべきである。しかしながら，EDI のメッセージに含まれる情報項目は，取引対象となる製品やサービスの特性，取引当事者双方の社内プロセス，当事者間の取引のプロセス，および商慣習などを反映するため，業務に適合する既存の標準メッセージが存在しないケースもありうる。そのような場合には，実際に取引のある企業グループの中で，自前の EDI メッセージを作成する必要がある。
従来の EDI では，シンタックスルールの難しさなどから，標準メッセージの開発に多大な努力を要する傾向があった。一方 XML は，理解が容易で，手軽に情報の設計が可能であるがゆえに，
結果として各社個別のメッセージを設計してしまいがちであるという欠点がある。
また，標準メッセージは，多くの企業の要求を取り入れれば取り入れるほどメッセージが肥大化し冗長になってしまう。そのため，標準メッセージの中から実際に使用する情報項目を選び出す
作業が，メッセージを作成する作業に匹敵するほどの作業負荷を生じる場合もある。
この節では，3 章で策定した「中小製造業 EDI メッセージモデル」を，UN/CEFACT で検討されているコア構成要素を用いて表現することで，シンプルな EDI メッセージの作成を試行し，メッセージ作成の容易性について考察する。
なお，試行にあたっては，2004 年 12 月末時点で，UN/CEFACT Forum/TBG17 が公表あるいは検討しているコア構成要素仕様「Core Components Technical Specification – Part 8 of theebXML Framework V2.01」の原案に準拠した。

8.2.2 コア構成要素を使う利点
ebXML コア構成要素は，業種横断的に共通な基本的な情報だけを汎用の部品として標準化したものである。この部品の組合せで，実業務に必要な EDI メッセージを比較的簡単に作成することが可能になる。コア構成要素に含まれる情報項目は，UN/EDIFACT など従来の EDI のノウハウを取り入れて取捨選択されたものであるため，必要な情報項目の洗い出しの作業が省略できる点が大きなメリットである。
さらに，将来多くの産業における標準メッセージがコア構成要素を採用して構築されるようになると，メッセージの構成要素の構造がほぼ同じになるため，比較検討が容易になり，異なる業界
間，或いは国際間の取引メッセージを検討する際の作業も大幅に簡素化できる可能性がある。

8.2.3 中小製造業 EDI メッセージモデルの情報項目の再整理
3 章で策定した中小製造業 EDI メッセージモデルの情報項目を，当事者，（商品），取引上の―103―

事象と言う観点から再整理すると表 8.5 中小製造業 EDI メッセージモデルの情報項目のように分類することができる。

表 8.5 中小製造業 EDI メッセージモデルの情報項目
大分類
当事者

取引明細

中分類

小分類

情報項目

発注者

−

受注者
納入先

−
−

最終ユーザ

−

発注者コード，発注者企業名，発注部門コード，発注部門名
購買担当，購買担当（漢字）受注者コード，受注者企業名，受注部門コード，営業担当（漢字）
納入先宛先名，納入先宛先名（漢字），納入時連絡先，納入先住所，納入先住所（漢字）エンドユーザ名，エンドユーザ名(漢字）

取引物品

−
税
支払条件
納入条件
分納条件
受渡場所
製品

メッセージ
取引行為

注文メッ セー
ジ
注文

−

予約注文
注文変更
最終ユーザ注文−−−−

発注者用備考，発注者用備考（漢字），注文金額，注文数量（単位），
条長個数，消費税額，（通貨コード），合計額，納品書価格表示区分
課税区分，消費税区分
決済条件区分荷姿（包装単位）納入 No.，納品キー番号，納期，納入時刻，納入指示数量
受渡場所，受渡場所名，受渡場所名（漢字）
発注者品名コード，受注者品名コード，品名（品名仕様），品名（品名仕様）（漢字），発注品仕様，発注品仕様（漢字），製造番号，機種コード，発注者バーコード情報，戦略物資区分，単価，（通貨コード），単価
区分，原産地コード，主材料ベース，指定メーカ名，材料・規格・寸法，条長，仕様書有無，検査区分，試験成績書要否区分，図面・仕様
書番号，版数，要求書部数，図面・仕様書枚数
データ処理 No.，データ作成日
注文番号，親注文番号，注文日，直納区分，コック区分，支給区分，納入指示有無区分，発注形態区分，契約条件区分，訂正コード，注文請
け返信期限，備考，備考（漢字），自由使用欄
予約番号
変更注文区分
エンドユーザ注文番号

8.2.4 集約コア構成要素の選択と集約ビジネス情報項目の決定
この試行では，表 8.5 中小製造業 EDI メッセージモデルの情報項目中の大分類に対応する集約コア構成要素（以下 ACC）を表 8.6 中小製造業 EDI メッセージモデルで使用する ACC に示すように対応付けることができた。

表 8.6 中小製造業 EDI メッセージモデルで使用する ACC
中小製造業 EDI メッセージモデル

ACC
Party

当事者
（発注者・受注者など）
取引明細（取引物品，数量，金額，など）
メッセージ（当該注文メッセージに関する事項）

LineItem
Document―104―

Event

取引行為（当該注文に関する事項，予約注文等に関する事項）

さらに，これら 4 種類の集約コア構成要素に修飾詞を付加することにより，表 8.5 中小製造業 EDI メッセージモデルの情報項目の中分類に対応する集約ビジネス情報項目（以下 ABIE）を表
8.7 中小製造業 EDI メッセージモデルで使用する ABIE に示すように派生させることができた。

表 8.7 中小製造業 EDI メッセージモデルで使用する ABIE
中小製造業 EDI メッセージモ
デル

ABIE

発注者

Buyer_Party

受注者

Seller_Party

納入先

Recipient_Party

最終ユーザ

EndUser_Party

取引物品

Order_LineItem

注文メッセージ

Order_Document

注文

Order_Event

予約注文

ReservationOrder_Event

最終ユーザ注文EndUserOrder_Event

注文変更

OrderChange_Event

なお，これらの決定には，中小製造業 EDI メッセージモデルの基になった ECALGA のメッセージ仕様のオブジェクトクラスを参考とした。

8.2.5 関連ビジネス情報項目及び基本ビジネス情報項目の決定
ABIE の構造中には，関連ビジネス情報項目(以下 ASBIE)と基本ビジネス情報項目(以下 BBIE)が含まれる。これらをコア構成要素の構造に照らして決定した。ここでは，Buyer_Party を例としてその過程を述べる。
コア構成要素 Party の構造の概略を，図 8.1 Party の構造に示す。なお，下線を引いた基本コ
ア構成要素（以下 BCC）及び関連コア構成要素（以下 ASCC）が中小製造業 EDI メッセージモデ
ルで使用する部分である。

―105―

Party. Details (ACC) ： 当事者
Party. Identification.Identifier (BCC) ：識別子
Party. Name.Text (BCC) ： 名称
Party. Type.Code (BCC) ： タイプコード
Party. Access.Code (BCC) ： アクセスコード
Party. Classification.Code (BCC) ： 分類コード
Party. Description.Text (BCC) ： 説明文
Party. Role.Code (BCC) ： 役割コード
Party. Language.Code (BCC) ： 言語コード
Party. Organization (ASCC) ： 組織（企業など）
Party. Person (ASCC) ： 個人
Party. Event (ASCC) ： 事象

図 8.1 Party の構造
Organization は ASCC である。Organization は図 8.2 Organization の構造のような構造を持っている。
Organization. Details (ASCC)
Organization. Count. Quantity (BCC) ： 計数
Organization. Business Type. Code (BCC) ： 業種コード
Organization. Legal Classification. Code (BCC) ： 法人種別コード
Organization. Registration. Identifier (BCC) ： 法人登記番号
Organization. Name. Text
(BCC) ： 組織名
Organization. Identification. Identifier (BCC) ： 組織の識別子
Organization. Description. Text (BCC) ： 説明文
Organization. Code (BCC) ： 汎用のコード
Organization. Registration. Code
(BCC) ： 登記関係のコード
Organization. Short Name. Text
(BCC) ： 略称
Organization. Establishment. Date Time (BCC) ： 創立年月日
Organization. Doing Business As Name. Text (BCC) ： 商号
Organization. Tax Bracket Percentage. Numeric(BCC) ：課税等級
Organization. Date Time (BCC) ： 汎用の日付
Organization. Indication. Indicator (BCC) ： 汎用の標識
Organization. Registration (ASCC) ： 法人登記
Organization. Tax Fee (ASCC) ： 税・料金
Organization. Contact (ASCC) ： 連絡先
Organization. Organization (ASCC) ： 組織
Organization. Address (ASCC) ： 住所
Organization. Account (ASCC) ： 口座
Organization. Location (ASCC) ： 場所・位置
Organization. Period (ASCC) ： 期間

図 8.2 Organization の構造

さらに Organization の中には連絡先 Contact が含まれ，Contact の中には担当者 Person が含
まれるそれぞれの構造を図 8.3 Contact の構造および図 8.4 Person の構造に示す。

―106―

Contact. Details (ACC) ： 連絡先
Contact. Identification. Identifier (BCC) ： 連絡先の識別子
Contact. Job Title. Text (BCC) ： 連絡先の肩書き
Contact. Responsibility. Text (BCC) ： 連絡先の責任範囲
Contact. Department Name. Text (BCC) ： 連絡先の部署名
Contact. Primary Contact. Indicator (BCC) ： 最初の連絡先かの標識
Contact. Type. Text (BCC) ： 連絡先のタイプ
Contact. Name. Text (BCC) ： 連絡先の名称
Contact. Person (ASCC) ： 担当者
Contact. Organization (ASCC) ： 組織
Contact. Communication (ASCC) ： 通信（電話番号など）
Contact. Preference (ASCC) ： 優先権
Contact. Address (ASCC) ： 住所

図 8.3 Contact の構造

Person. Details (ACC) ： 個人
Person. Identification. Identifier (BCC) ： 人の識別子
Person. Name. Text (BCC) ： 氏名
Person. Given Name. Text (BCC) ： 名（下の名前）
Person. Nickname. Text (BCC) ： 愛称
Person. Middle Name. Text (BCC) ： ミドルネーム
Person. Family Name. Text (BCC) ： 姓
Person. Title. Text (BCC) ： 称号，役職
Person. Salutation. Text (BCC) ： 敬称
Person. Family Name Prefix. Text (BCC) ： 姓の接頭語
Person. Name Suffix. Text (BCC) ： 名の接尾語
Person. Marital. Code (BCC) ： 婚姻コード
Person. Gender. Code (BCC) ： 性別コード
Person. Birth. Date Time (BCC) ： 生年月日
Person. Age. Measure (BCC) ： 年齢
Person. Death. Date Time
(BCC) ： 死去年月日
Person. Language. Identifier (BCC) ： 言語
Person. Description. Text (BCC) ： 説明文
Person. Maiden Name. Text (BCC) ： 旧姓Person. Preferred Name. Text (BCC) ： 呼称（本人が呼ばれたい名前）
Person. Nationality. Identifier (BCC) ： 国籍識別子
Person. Address (ASCC) ： 住所
Person. Nationality. Country (ASCC) ： 国籍
Person. Communication (ASCC) ： 通信（電話番号など）

図 8.4 Person の構造

以上，太字の BCC 及び ASCC に必要に応じて修飾詞をつけ，BBIE，ASBIE を派生させた結果，図 8.5 中小製造業 EDI メッセージモデルにおける Buyer̲Party の構造のような BBIE が得
られる。

―107―

Buyer_Party (ABIE) ： 発注者
Identification.Identifier (BBIE) ： 発注者コード
Name.Text (BBIE) ： 発注者企業名
ResponsibleBranch_Organization (ASBIE) ： 発注部門
Identification.Identifier (BBIE) ： 発注部門コード
Name.text (BBIE) ： 発注部門名

Contact(ASBIE) ： 連絡先

Responsible_Person (ASBIE) ： 担当者
Name.Text (BBIE) ： 購買担当

図 8.5 中小製造業 EDI メッセージモデルにおける Buyer̲Party の構造

ABIE は，ACC または ASCC の名称に，業務上の意味を表す修飾詞を必ず付け加え，アンダー
バーで区切って表記した。例えば発注者は，ACC の名称である”Party”に修飾詞”Buyer_”を付け加えて，”Buyer_Party”となる。
BBIE および ASBIE は，特に必要な場合のみ修飾詞を付け加えた。例えば Buyer_Party の直下の Name.Text は発注者企業名であることが自明なので，修飾詞はつけていないが，
Organization は 当 該 発 注 に か か わ る 担 当 部 門 で あ る こ と が 分 か る よ う に ， 修 飾詞”ResponsibleBranch_”を付け加えて”ResponsibleBranch_ Organization”とした。
他の ABIE についても同様の作業を行い，得られたメッセージ構造を表 8.8 ebXML コア構成要素に基づく EDI メッセージモデル（注文情報）に掲載した。
この構造を UN/CEFACT の制定するメッセージ規則（NDR）に従って忠実に XML Schema
化することで，所望の EDI メッセージの XML Schema を作成することが出来る。

8.2.6 メッセージ構造表の説明(1) 項目の説明
表 8.8 ebXML コア構成要素に基づく EDI メッセージモデル（注文情報）は，3 章で策定した「中小製造業 EDI メッセージモデル」の情報項目を 8.2.5 項「関連ビジネス情報項目及び基本ビジネス情報項目の決定」で決定した ABIE，ASBIE および BBIE の形式で整理したものである。
UID(仮)の欄は，ABIE，ASBIE，BBIE に対して，それぞれの種別ごとに便宜的に振った整理番号である。AB-で始まるものが ABIE，AS-で始まるものが ASBIE，BB-で始まるもの
が BBIE である。UID は本来国際的かつ業種横断的にユニークになるように付与するものであるが，現在 UID の付与規則が明確化されていないため，当該メッセージ内でユニークとなるように付与してある。
ビジネスターム(項目名)の欄は，「中小製造業 EDI メッセージモデル」の項目名を記載し―108―ている，「中小製造業 EDI メッセージモデル」は JEITA/EC センターが開発した ECALGAのメッセージを参考にしているため，項目名称はこれに準拠している。但し，ebXML では，
使用言語は XML タグの attribute として規定するため，購買担当と購買担当(漢字)のような同じ意味でありながら使用言語(文字)の違う情報項目は 1 つにまとめてある。
辞書登録名(Dictionary Entry Name)の欄は，8.2.5 項「関連ビジネス情報項目及び基本ビ
ジネス情報項目の決定」で説明した手順でコア構成要素からビジネス情報項目を派生した際に決定した情報項目の正式な名称であり，ebXML の規格であるコア構成要素技術仕様書で規定されたルールに従って命名したものである。なお，ASBIE および BBIE は「字下げ」によって包含関係を明らかにしてある。
BBIE の名称はその BBIE が属する ABIE または ASBIE の名称（パス）をつけて，フル
パスで表記するのが正式である。しかし，フルパス表記は表が非常に見にくくなる欠点がある。
フルパスによる辞書登録名称を使用した場合の”Buyer_Party”の表記を図 8.6 フルパス
による辞書登録名の表記例に示す。

Buyer̲Party
Buyer̲Party.Identification.Identifier
Buyer̲Party.Name.Text
Buyer̲Party.ResponsibleBranch̲Organization
Buyer̲Party.ResponsibleBranch̲Organization.Identification.Identifier
Buyer̲Party.ResponsibleBranch̲Organization.Name.text
Buyer̲Party.ResponsibleBranch̲Organization.Contact
Buyer̲Party.ResponsibleBranch̲Organization.Contact.Responsible̲Pers
Buyer̲Party.ResponsibleBranch̲Organization.Contact.Responsible̲P
図 8.6 フルパスによる辞書登録名の表記例

一方，表 8.8 ebXML コア構成要素に基づく EDI メッセージモデル（注文情報）においては，表の構造から，各 BBIE が属する ABIE または ASBIE が容易に分かるので，表を見やすくするため，便宜的に ABIE または ASBIE の名称は省略してプロパティ名称，リプリゼ
ンテーション名称のみ記載してある。このパスを省略した表記法による”Buyer_Party”の表記を図 8.7 パスを省略した表記による辞書登録名の表記例に示す。

―109―

Buyer̲Party
Identification.IdentifierName.Text
ResponsibleBranch̲Organization
Identification.IdentifierName.text
Contact
Responsible̲Person
Name.Text
図 8.7 パスを省略した表記による辞書登録名の表記例

なお，XML のインスタンスでは，図 8.8 XML インスタンスの例に示すように，パスを省略した名称が，XML のタグになる。そのため，パスを省略した表記の方が XML タグとの対応を理解しやすい。なお，図 8.8 XML インスタンスの例は簡単にするため，attribute は省
略して XML タグのみを記載している。
<Buyer̲party><IdentificationIdentifier> 506022</IdentificationIdentifier><NameText>○×産業（株）</NameText><ResponsibleBranch̲Organization><IdentificationIdentifier> 000001</IdentificationIdentifier><NameText>資材部</NameText><Contact><Responsible̲Person><NameText>○山 ×夫</NameText></Responsible̲Person></Contact></ResponsibleBranch̲Organization></Buyer̲party>

図 8.8 XML インスタンスの例

種別の欄は，この BIE が ABIE，ASBIE，BBIE のいずれであるかを記載してある。また，
ABIE と ASBIE の行は背景を着色してある。
定義の欄はビジネスタームの欄と同様に JEITA/EC センターが開発した ECALGA の項目
定義を参考に一部字句を補って作成した。
使用の欄は，「中小製造業 EDI メッセージモデル」において当該情報項目が「必須」であるか，「準必須」であるか，「任意使用」であるかを記載した。なお，ECALGA 標準では定義されているが「中小製造業 EDI メッセージモデル」には採用されなかった情報項目には「不使用」と記載してある。
繰り返しの欄は，「中小製造業 EDI メッセージモデル」において当該情報項目が何回繰り返して使用されるかを ebXML の表記法に従って記載した。0..1 は省略可で繰り返しなし（0―110―

回以上 1 回以下の繰り返し）を表し，1..1 は，「省略不可で繰り返し無し」を表している。
購買担当と購買担当(漢字)のように表記の言語(文字)が異なる項目を 1 つにまとめた BBIE では，漢字表記とフリガナ表記を併用するニーズがあることに配慮して繰り返しを 1..2(省略不可で繰り返し 2 回まで)または 0..2「省略可能で繰り返し 2 回まで」としてある。
(2) 情報項目の順序
表 8.8 ebXML コア構成要素に基づく EDI メッセージモデル（注文情報）の表における情報項目の順序（出現順序）は，ebXML コア構成要素の集約コア構成要素（ACC）の分類の順序にしている。中小製造業 EDI メッセージモデル（ベースは ECALGA）の情報項目の順
序とは異なっている。

8.2.7 コア構成要素に基づくメッセージ作成の評価
中小製造業 EDI メッセージモデルは ECALGA メッセージを参考として製造業向けの情報項目を集めたため，製品仕様に関する項目が多数含まれている。一方，この試行で採用したコア構成要
素 の ド ラ フ ト に 規 定 さ れ て い る コ ア 構 成 要 素 Product に は ， 製 品 の 詳 細 仕 様 を 表 すProductSpecification が関連コア構成要素として含まれていない。今後，UN/CEFACT のコア構
成要素調整グループが，この点の改善を行うことを前提に，Product は ProductSpecification を含
むものとして，作業を行った。
また，中小製造業 EDI メッセージモデルでは，直納品か否か，支給品があるか否かなど Indicator
型の BBIE で表されるべき項目が存在するが，本試行を実施した時点のコア構成要素では，
Indicator 型の BCC が定義されていないため，代替として Code 型の BCC を使用している。
その結果，この部分を除いて，中小製造業 EDI メッセージモデルをコア構成要素から作成することが出来た。なお，不足の項目については，UN/CEFACT に追加の提案を行うこととする。
(1) コア構成要素から EDI メッセージを作成するメリット
コア構成要素からメッセージを作成するメリットとしては次の点を挙げることが出来る。
① 必要な項目が容易に定義できる。
UBL など既存のメッセージで必要な項目をマッピングする場合には，対応しない項目が存在する場合があるが，コア構成要素を基にビジネス情報項目を派生させる場合には，適切な修飾詞をつけることで目的とするビジネス情報項目を定義することが出来るため，対応しないケースは少ない。
② オブジェクト指向設計が容易に出来る。
ECALGA のように，EDI メッセージを設計する際に，オブジェクト指向の設計手法により含まれる情報項目の相互の関係が整理されていると，コア構成要素構成要素のオブジェクトクラスと完全に一致していない場合であっても，対応付けが容易である。
オブジェクト指向の設計手法に精通していなくても，「誰が」，「何を」，「どうする」ということを明確に規定することで，比較的容易に対応するコア構成要素を見つけ出すことが出来る。結果として，オブジェクト指向によるメッセージ開発と同じ効果が，コア構成要素を利用することで得られる。
―111―

③ 国際標準である ebXML に準拠した構造となるため，体系的に整理され，理解が容易になる。
他業界の標準を参考にする場合や，業界標準間の調整を行う場合にも，相互の理解が容易となる。
(2) コア構成要素から EDI メッセージを作成するデメリット
一方でコア構成要素を使用する際には以下のデメリットも存在する。
① コア構成要素の理解が必要。
コア構成要素は，単純な基本コア構成要素以外に構造を内包した関連コア構成要素を含んでおり，その包含関係が複雑である。Organization の下にさらに Organization が含まれる（再帰的）な構造や，Address の下に Location が含まれ，Location の下に Addressが含まれるような双方向の包含構造があるため，これらの関係を予め理解している必要がある。
② 修飾詞の選択によって開発者の個性が出てしまう。
コア構成要素を利用すると，メッセージの設計者によって情報の構造がまちまちになることは防げるが，修飾詞にどのような言葉を選ぶかは設計者に任されているため，同じ意
味のビジネス情報項目が異なる名称（修飾詞）で定義される可能性がある。
③ 情報項目の名称（辞書登録名）が長くなる。
(3) コア構成要素を利用したメッセージ設計の課題
コア構成要素を利用したメッセージ設計の手法が普及し，中小企業でも適用可能になるためには以下のような取組みが必要であると考えられる。
① コア構成要素の早期の完成
コア構成要素は現在開発の途上であるが，早期に初版がリリースされ，使えるようになる必要がある。
② コア構成要素リストの日本語化（定義部分）
中小企業だけでなく，わが国の産業界がコア構成要素を使用するためには，定義を説明した文章は速やかに日本語化して公開される必要がある。
③ コア構成要素の構造と使い方の解説の整備
コア構成要素は汎用性を高めるために，ASBIE の包含関係が複雑で，どのような目的の時にどのような使い方をするのかが分かり難い。これを解決するためには，ABIE および
ASBIE に対してその構造と使用方法を具体的に解説した資料が整備されなければならない。
④ ノウハウの蓄積と共有
コア構成要素を使用する上で，先行するユーザがどのような修飾詞を付けどのような使い方をしたかを参考に出来るよう，開発事例が公開されるよう当事者に働きかけるとともに，これらの情報を共有する仕組みの整備が必要である。

―112―

⑤ 再利用可能（Reuseable）なビジネス情報項目の蓄積と共有
参考資料として利用する③のケースに加えて，先行する他の業界が作成したビジネス情報項目がそのまま流用可能（再利用可能）なケースもありうる。このようなビジネス情報
項目を収集して効率よく EDI メッセージを作成できる仕組みが必要である。
⑥ コア構成要素の保守ルールの確立
コア構成要素の利用が進むと，ユーザから基本コア構成要素や関連コア構成要素の追加などメンテナンスの要望が提案されることが予想される。これらの提案を受け付け，速やかに処理するためのルールや体制が整備される必要がある。

表 8.8 ebXML コア構成要素に基づく EDI メッセージモデル（注文情報）

UID(仮)

ビジネスターム(項目名)

AB-0001 発注者
BB-0001 発注者コード(管理組織含む）
BB-0002 発注者企業名
BB-0003 発注者企業の国コード
AS-0001 担当部署
BB-0004 発注部門コード
BB-0005 発注部門名
AS-0002 連絡先
AS-0003 担当者
BB-0006 購買担当
購買担当（漢字）
AB-0002 受注者
BB-0007 受注者コード（管理組織含む）
BB-0008 受注者企業名
BB-0009 受注者企業の国コード
AS-0004 担当部署
BB-0010 受注部門コード
BB-0011 受注部門名
受注部門名(漢字）
AS-0005 連絡先
AS-0006 担当者
BB-0012 営業担当
営業担当（漢字）
AB-0003 納入先
BB-0013 納入先宛先名
納入先宛先名（漢字）AS-0007 担当部署
AS-0008 連絡先
BB-0014 納入時連絡先
AS-0009 納入先住所
BB-0015 納入先住所
納入先住所（漢字）
BB-0016 市町村コード
BB-0017 納入先郵便番号
AB-0004 エンドユーザ
BB-0018 エンドユーザ名
エンドユーザ名(漢字）AB-0005 取引明細
BB-0019 明細行番号（不使用）
BB-0020 合計額

辞書登録名

種別

Buyer̲Party
Identification.IdentifierName.Text
Country̲Code(追加要求）
ResponsibleBranch̲Organization
Identification.IdentifierName.text
Contact
Responsible̲Person
Name.Text
Seller̲Party
Identification.IdentifierName.Text
Country̲Code(追加要求）
ResponsibleBranchOrganization
Identification.IdentifierName.text
Contact
ResponsiblePerson
Name.Text
Recipient̲Party
Name.Text
ResponsibleBranchOrganization
Contact
Name.Text
Address
Address.LineOne.Text

―113―

使用 繰返

発注企業の詳細
必須 1..1
発注企業の識別子（企業コード・管理組 必須 1..1
織）
BBIE 発注企業の名称
準必須 0..1
BBIE 発注企業の国籍
不使用 0..0
ASBIE 発注部門の詳細
準必須 0..1
BBIE 発注部門の識別子（部門コード）
準必須 0..1
BBIE 発注部門の名称
任意 0..1
ASBIE 発注企業連絡窓口の詳細
必須 0..1
ASBIE 発注企業連絡窓口担当者の詳細
必須 0..1
BBIE 発注企業の担当者の氏名
必須 0..2
ABIE
BBIE

受注企業の詳細
必須 1..1
受注企業の識別子（企業コード・管理組 必須 1..1
織）
BBIE 受注企業の名称
準必須 0..1
BBIE 受注企業の国籍
不使用 0..0
ASBIE 受注部門の詳細
任意 0..1
BBIE 受注部門の識別子（部門コード）
任意 0..1
BBIE 受注部門の名称
不使用 0..0
ASBIE 発注企業連絡窓口の詳細
ASBIE 発注企業連絡窓口担当者の詳細
BBIE 受注企業の担当者の氏名

不使用 0..0
不使用 0..0
不使用 0..0

ABIE
BBIE

納入先企業の詳細
納入先企業の名称

任意
任意

0..1
0..2

ASBIE
ASBIE
BBIE
ASBIE
BBIE

受注部門の詳細
納品先企業連絡窓口の詳細
納品先企業連絡窓口の名称
納品先企業住所の詳細
納品先企業の住所

任意
任意
任意
任意
任意

0..1
0..1
0..1
0..1
0..2

納品先の市町村コード

不使用 0..0

納品先の郵便番号
最終需要家の詳細
最終需要家の名称

不使用 0..0
任意 0..1
任意 0..2

Local̲SelfGgoverningBody̲Identificati BBIE
on.Identifier
Postｃode.Code
BBIE
EndUser̲Party
ABIE
Name.Text
BBIE
Order̲LineItem
Identification.Identifier
Total̲Amount

定義

ABIE
BBIE

ABIE
BBIE
BBIE

商品・取引品の詳細

必須 1..1
不使用 0..0
税額を含む合計金額（通貨コードを含 準必須 0..1

BB-0021 消費税額，（通貨コード）

Tax̲Amount

BBIE

BB-0022 注文金額(通貨コード）

Net̲Amount

BBIE

BB-0023 注文数量，（単位）BB-0024 条長個数
BB-0025 発注者用備考
発注者用備考（漢字）BB-0026 納品書価格表示区分

Order̲Quantity
CuttingPeace̲Quantiry
BuyerPurposeAdditionalInfomation̲Text

BBIE
BBIE
BBIE

InvoicePriceStatement̲Code

BBIE

AS-0010 税

Tax

ASBIE

BB-0027 課税区分
BB-0028 消費税区分
AS-0011 支払方法
BB-0029 決済条件区分
BB-0030 数量契約区分

TaxExemption̲CodeBBIE

TaxIntension̲Code
PaymentMeans

BBIE

Code
QuantityBasis̲Code

BBIE
BBIE

AS-0012 納入条件
BB-0031 一括納入番号

DeliveryTerm
KitDelively̲Identification.Identifier

BB-0032
AS-0013BB-0033
BB-0034
AS-0014BB-0035
BB-0036

RequiredDelivery̲DateTime
BBIE
Package
ASBIE
PackageDescription̲Text
BBIE
PackageInculusion̲Quantity
BBIE
Divided̲DeliveryTerm
ASBIE
Delidery̲Identification.Identifier
BBIE
DividedDelivery̲Identification.Identifie BBIEr
Delivery̲DateTime
BBIE 指定納入日・時刻(分納の場合繰返し) 必須

納入指定日
納品梱包
荷姿（包装単位）
包装単位数量納入条件（分納）
納入Ｎｏ．
納品キー番号

BB-0037 納期，
納入時刻
BB-0038 納入指示数量
AS-0015 受渡場所
BB-0039 受渡場所
BB-0040 受渡場所名
受渡場所名（漢字）
AS-0016 取引物品
BB-0041 品名（品名仕様）
品名（品名仕様）（漢字）
BB-0042 発注品仕様
発注品仕様（漢字）
BB-0043 発注者品名コード

ASBIE
BBIE

む）
この商品にかかる税額（通貨コードを含 準必須 0..1
む）
税を含まない注文金額（通貨コードを含 必須 1..1
む）
注文数量(単位を含む）
必須 1..1
電線取引における条数
任意 0..1
発注者側が使用する付加的な情報（備 準必須 0..2
考)
納品書に単価を記載するか否かを表す 任意 0..1
コード
当該注文にかかる租税に関する情報 準必須 0..1の詳細
この商品が課税か非課税かを示すコー 準必須 0..1
ド
内税か外税かを示すコード
準必須 0..1
当該注文での支払い方法の情報の詳 準必須 0..1
細支払の方法を表すコード
準必須 0..1
最終決済を計算上の数量で行うか，実 不使用 0..0
際数量で行うかを表すコード。
納入先時の諸条件の詳細
任意 0..0
キット納品等，複数製品をセットにして 不使用 0..0
一括納品する場合の納品管理番号
納入指定日
不使用 0..0
納品梱包に関する条件の情報
任意 0..1
出荷時の容器，梱包等を説明する文章 任意 0..1
１包装単位内の数量
不使用 0..0
分割納入に関する情報
準必須 0..31
当該注文に対する納入の識別子
任意 0..31
分納の場合の納品の識別子
準必須 0..31

納入数量(分納の場合繰返し)
受渡場所の詳細
受渡場所の識別子
受渡場所の名称

0..31

Delivery̲Quantity
Delivery̲Location
Identification.IdentifierName.Text

BBIE
ASBIE
BBIE
BBIE

必須 0..31
必須 1..1
必須 1..1
準必須 0..2

Product
Name.Text

ASBIE 当該注文で売買される商品・製品の情 必須
報
BBIE 商品名又は仕様
任意

0..2

Description̲text

BBIE

1..1

この商品の詳細仕様

任意

0..2

BuyerAssigned̲Identification.IdentifierBBIE

発注者側の商品識別子

必須

1..1

BB-0044 受注者品名コード

SellerAssigned̲Identification.Identifier BBIE

受注者側の商品識別子

任意

0..1

BB-0045 製造番号
BB-0046 機種コード

Production̲Identification.Identifier
Model̲Identification.Identifier

BBIE
BBIE

製造番号，製造ロット番号
準必須 0..1
当該注文で発注した製品を組み込んで 任意 0..1
製造される製品の型番，型式の識別子

BB-0047 機種名（漢字）BB-0048 発注者バーコード情報

Model̲Name.Text
BarCode̲Identification.Identifier

BBIE
BBIE

BB-0049 戦略物資区分

StrategicGoods̲Code

BB-0050
BB-0051
AS-0017BB-0052
BB-0053

最低発注数量
主材料コード
単価
単価，（通貨コード）
単価区分

MinimumOrderUnit̲Quantity
MainMaterial̲CodeBase̲priceAmountType̲Code

AS-0018 原産国
BB-0054 原産地コード
AS-0019 主材料ベース単価

Origin̲Country
Identification.Identifier
MainMaterial̲BasePrice

BB-0055 主材料ベース

Amount―114―

製品の機種に付けられた名称
不使用 0..0
バーコードに記載する商品識別子（JAN準必須 0..1
等)
BBIE この商品が戦略物資であるか否かを表 任意 0..1
すコード
BBIE 最小発注量
不使用 0..0BBIE 契約時の主材料を表すコード
不使用 0..0
ASBIE 単価に関する情報
必須 1..1
BBIE この商品の単価
必須 1..1
BBIE 確定単価，単価未定，変更単価のいず 必須 1..1
れであるかを示すコード
ASBIE 原産地・原産国の詳細
任意 0..5
BBIE 原産国の識別子
任意 0..5
ASBIE 電線取引における主材料のベース単価任意 0..1の情報
BBIE 電線取引における主材料のベース単価任意 0..1

主材料ベース(外貨）（通貨単位を含む）

BB-0056 主材料単位

Unit̲Quantity

AS-0020 メーカ名
BB-0057 指定メーカ名

Manufacturer̲Organization
Name.Text

AS-0021 取引物品．説明．仕様詳
細BB-0058 材料・規格・寸法
材料・規格・寸法(漢字)
BB-0059 条長

ProductSpecification

BBIE

電線取引における主材料のベース単価不使用 0..0に対応する数量単位
ASBIE 製造メーカーの詳細
任意 0..1
BBIE 製造メーカを指定する場合の製品の製 任意 0..1
造メーカ名称ASBIE 製品仕様の詳細
準必須 0..1

Physicalcharacteristics̲text

BBIE

材質・規格・寸法など

CuttingLength̲Measure

BBIE

BB-0060 仕様書有無

Attatchment̲code

BBIE

BB-0061 検査区分

QualityInspectionMethod̲Code BBIE

電線取引における条長（条長単位を含 任意 0..1
む）
仕様書が添付されるか否かを表すコー 準必須 0..1
ド
検査方法をあらわすコード
準必須 0..1

BB-0062 試験成績書要否区分

AS-0022 図面・仕様書
BB-0065 図面・仕様書番号
BB-0066 版数

QualityInspectionEvidence̲Cod BBIEe
QualityInspectionEvidenceItem̲ BBIE
Code
QualityInspectionEvidencePres BBIE
entationMeans̲CodeTechnical̲Documet
ASBIE
Identification.Identifier
BBIE
Version̲Identification.Identifier BBIE

BB-0067 設計変更番号
BB-0068 要求書部数
BB-0069 要求書種類

DesignChange̲Identifier
Copy̲Quantity
Type̲code

BB-0070 要求書言語

Language̲code

BB-0063 試験成績書検査区分
BB-0064 試験成績書提出方法

BB-0080 図面・仕様書枚数
AS-0023 工事発注

Totalpages.Quantity
Order̲Project

BB-0081 工事件名
工事件名(漢字）Construction̲Name.Text

AB-0006 データ順序と属性

Order̲Document

準必須 0..2

検査成績書が必要か否かを表すコード 任意

0..1

検査成績書の記載項目などを表すコー 不使用 0..0
ド
検査成績書の提出方法を表すコード 不使用 0..0
図面仕様書の詳細
図面仕様書の識別子
図面仕様書のバージョンの識別子

準必須 0..1
任意 0..1
準必須 0..1

BBIE
BBIE
BBIE

設計変更に付与された識別子
不使用 0..0
納品時に必要とする書類の部数
任意 0..1
納品時に必要とする書類の種類を表す 不使用 0..0
コード
BBIE 納品時に必要とする書類を記述する言 不使用 0..0
語を表すコード
BBIE 図面仕様書のページ数
任意 0..1
ASBIE 当該発注品が工事である場合または， 不使用 0..0
納品時に据付工事を伴う場合のみ使用
する
BBIE 当該発注品が工事である場合または， 不使用 0..0
納品時に据付工事を伴う場合，その工事件名ABIE 注文メッセージの詳細
準必須 1..1

BB-0082 データ処理No.
Identification.Identifier
IssueDate.DateTime
BB-0083 データ作成日・データ作
成時刻（タイムゾーン含む）
AB-0007 注文ＢＤ情報．詳細
Order̲Event
BB-0084 注文番号
Identification.Identifier
BB-0085 親注文番号
ParentOrder̲Identification.Identifier
BB-0086 注文日
DateTime
BB-0087 直納区分
DirectDeliveriy̲Code

BBIE
BBIE

この注文メッセージの識別子
準必須 1..1
この注文メセージを生成した日付・時刻 準必須 1..1
（タイムゾーン，UTCオフセットを含む）

ABIE
BBIE
BBIE
BBIE
BBIE

BB-0088 コック区分

ConsignmentStock̲Code

BBIE

BB-0089 支給区分

BuyerProvideParts̲Code

BBIE

BB-0090 納入指示有無区分

DeliveryInstraction̲Code

BBIE

BB-0091 発注形態区分

OrderPatternCode

BBIE

BB-0092 取扱形態区分
BB-0093 契約条件区分

TransactionType̲code
OrderType̲Code

BBIE
BBIE

BB-0094 訂正コード

Revise̲Code

BBIE

BB-0095 注文請け返信期限

OrderResponceLimit̲DateTime

BBIE

BB-0096 備考

AdditionalInfomationText

BBIE

当該注文の詳細
必須 1..1
当該注文の識別子（注文番号）
必須 1..1
当該注文の親注文の識別子
任意 0..1
当該注文を行った日付・時刻
必須 1..1
当該注文が直納品であるか否かを表す準必須 0..1
コード
当該注文がコック品の注文であるか否 任意 0..1
かを表すコード
当該注文に関して支給品があるか否か 準必須 0..1を表すコード
当該注文において，納入指示を行うか 任意 0..1
否かを表すコード
当該注文が個別発注，グループ発注， 任意 0..1
総量発注かなどを表すコード
発注者側での取引形態を表すコード 不使用 0..0
当該注文が継続注文か都度注文かな 任意 0..1
どを表すコード
当該注文が新規注文か変更注文かを 準必須 1..1
表すコード
受注企業が注文回答を送信する期限 任意 0..1
日付・時刻
当該注文に関する付加的な情報(備考） 準必須 0..1―115―

備考（漢字）
BB-0097
AB-0008
BB-0098
BB-0099

自由使用欄
FreePurposeText
エンドユーザ注文情報 EndUserOrder̲Event
エンドユーザ注文番号
Identification.Identifier
エンドユーザ品名
Product̲Name.Text
エンドユーザ品名(漢字)
BB-0100 エンドユーザ品名コード
Product̲Identification.Identifier
AB-0009 代品納入
SubstituteItemOrder̲Event

BBIE
ABIE
BBIE
BBIE

BB-0101 返品代納区分

SubstituteItemOrder̲Code

BBIE

BB-0102 旧納品キー番号

SubstituteItemDividedDelivery̲Identificatio BBIE
n.Identifier

BB-0103 代納理由区分

SubstituteItemOrderReason̲Code

AB-0010 注文変更

OrderChange̲Event

ABIE

BBIE
ABIE

BB-0104 注文変更番号
BB-0105 変更注文区分

Identification.Identifier
OrderChandeCode

BBIE
BBIE

BB-0106 変更前注文数量
BB-0107 変更前単価
変更前単価（外貨）BB-0108 変更前納期
BB-0109 変更前納入指示数量
AB-0011 予約注文
BB-0110 予約番号

OriginalOrder̲Quantity
OriginalUnitPrice.Amount

BBIE
BBIE

OriginalDelivery̲DateTime
OriginalDelivery̲Quantity
ReservationOrder̲Event
Identification.Identifier

BBIE
BBIE
ABIE
BBIE

ReservationOrder̲AmountBBIE

BB-0111 予約金額
予約金額（外貨）
AB-0012 見積
BB-0112 見積番号
BB-0113 見積金額
見積金額(外貨）
AB-0013 見積依頼
BB-0114 見積依頼時発注者品名
コードBB-0115 見積依頼番号

自由使用欄
最終需要家からの注文書の詳細
最終需要家からの注文書の識別子
最終需要家による品名

準必須 0..1
任意 0..1
任意 0..1
不使用 0..0

最終需要家による品名コード
不使用 0..0
当該注文が注文変更である場合の詳 不使用 0..0
細
当該注文が代品納入注文であるか否 不使用 0..0かを表すコード
当該注文が代品納入注文である場合 不使用 0..0に代品納入支持の元になった納品キー
番号
代品納入注文を行う理由を表すコード 不使用 0..0
当該注文が注文変更である場合の詳 準必須 0..1
細注文変更の識別子
不使用 0..0
当該注文が変更注文である場合，変更 準必須 0..3
された項目を表すコード
変更される前の注文数量
不使用 0..0
変更される前の単価
不使用 0..0

Quotation̲Event
Identification.Identifier
SellerEstimated̲Amount

ABIE
BBIE
BBIE

変更される前の納期変更される前の納入数量
当該注文に対応する予約注文の詳細
当該注文に対応する予約注文の識別子
当該注文に対応する予約注文の注文
金額(通貨単位を含む）
当該注文に対応する見積の詳細
当該注文に対応する見積の識別子
当該注文に対応する見積の金額

QuotRequest̲Event

ABIE

当該注文に対応する見積依頼の詳細 不使用 0..0

BuyerAssignedGoodsItem̲Identification.Ide BBIE
ntifier
Identification.Identifier
BBIE

見積依頼時に発注者が指定した商品 不使用 0..0の識別子
当該注文に対応する見積依頼の識別 不使用 0..0子

備考：「不使用」は，ECALGA では定義されているが，中小製造業 EDI メッセージモデルでは使用しない項目。

―116―

不使用 0..0
不使用 0..0
準必須 0..1
準必須 0..1
不使用 0..0
不使用 0..0
不使用 0..0
不使用 0..0

付録1 中小企業に関する IT/EC 活動動向
中小企業の IT/EC に関する 2004 年度の新聞記事，各種ホームページなどの情報を，付表 1 中
小企業に関する IT/EC 関係活動（政府，団体）と付表 2 中小企業に関する IT/EC 関係活動（企業）に示す。

付録1.1 政府・団体(1) 中小企業に関係する政府活動，団体活動は多く存在する。
(2) IT 推進活動は経済産業省主体に推進している。
z1999 年度からの戦略情報化投資活性化事業（ITSSP）。

z

2004 年度からの IT 経営応援隊。

z2004 年度からの IT 経営百選。

付録1.2 企業
(1) 中小企業の IT 市場は拡大状況である。この 2〜3 年は中小企業の IT 関係事業を推進する好機と思われる。
z

ERP 市場全体は 2003 年に減速した。中小企業向け ERP 市場は年率約 8%で拡大している。中小企業向け ERP システムが販売されている。（SAP）

z

2004 年 4 月〜6 月の PC サーバー出荷台数は，年率約 10%で拡大中。PC サーバーの低価格化が進んでいる。

z2004 年上期の国内パソコン出荷台数は，中小企業の需要に支えられて前年同期比 11%増。

zIT ベンダー各社は中小企業向けのソリューション事業を強化している。

z

SMB（Small and Medium Business，中小企業相手のビジネス）が注目されている。

z

中小企業は雇用を拡大している。

z

中小企業の設備投資意欲が強い。

(2) 中小企業相手の教育が盛んに行われている。中小企業の EC/EDI 促進策としても教育が重要
である。

―117―

付表 1 中小企業に関する IT/EC 関係活動（政府，団体）
時期
政府・団体
1999年度〜 経済産業省
1
2001 年度 商務情報政策局
経済産業省
2 2002年度〜
商務情報政策局

活動テーマ
活動内容
参考資料
備考
戦略的情報化投資活性化事
2001 年度に IT コーディネータ制度の立ち上げ。
○
業（ITSSP）第 1 期
戦略的情報化投資活性化事 IT コーディネータ制度の啓蒙と IT コーディネータを活用した中小企業の情報化○業（ITSSP）第 2 期
支援活動を推進。
・産学連携を推進するために関東経済産業局の支援の下に設立された。
「中小製造業受発注業務の・1999 年〜2004 年に ITSSP 事業の実施団体となり，企業訪問等で中小企業のＥＤＩ化による中小製造業サ
情報通信技術活用型取引シ IT 化支援活動を行っている。
プライチェーン・マネージメン
・2001 年度に中小企業庁の補助金を受け「中小製造業受発注業務のＥＤＩ化にステム開発事業
ト・ネットワーク調査研究」報（社）首都圏産業活性3 2001年度〜
よる中小製造業サプライチェーン・マネージメント・ネットワーク調査研究」を実
告書化協会（TAMA 協会）
即効型地域新生コンソーシ 施した。
「中小製造業 SCM を実現す・2002 年度に，「中小製造業 SCM を実現するシンプル XML/EDI システム開発」
アム研究開発事業
るシンプル XML/EDI システを関東経済産業局より受託し，ebXML MS 仕様を採用した実証実験を実施しムを開発」報告書
た。
・「平成 15 年度末において中小企業のおおむね半数程度がインターネットを活ECOM のインタ用した電子商取引を実施できること」という基盤整備も目標は達成された。
ーネット EDI 促
・この現状認識は，2003 年 12 月に三菱総合研究所から報告された，「中小企業http://www.meti.go.jp/feedb 進 SWG から意における IT 利活用に関する実態調査報告書」をベースにしている。
経済産業省
4 2004 年 3 月
中小企業 IT 化推進計画Ⅱ見を提出したack/data/i40317aj.html
・内容は以下。
中小企業庁
が，考慮されな-基本理念
かった。
-中小企業おける IT 利活用の方向性-中小企業の IT 化推進の支援方策
電子商取引はhttp://www.meti.go.jp/feedb 広い概念。電子2003 年 12中小企業における IT 利活用
5㈱三菱総合研究所
・電子商取引について，実施済みは 73%。
ack/downloadfiles/i40220bj2. メールを利用し
月に関する実態調査
pdf
た発注・受注処理などを含む。
・電子商取引の導入率は，購入 EC で 35%，販売 EC で 70%と高い。
電子商取引推進協議 中小企業における IT／EC に ・しかしながら，商取引全体に占める電子商取引の実施率（利用率）は非常に低 中小企業における IT／EC
6 2004 年 3 月
会（ECOM）
関する実態調査
い。件数レベルの実施率では，10%以下の実施率としている企業が約 50%。相手 に関する実態調査報告書
社数レベルの実施率では，約 4%と非常に低い。
・インターネット XML/EDI 技術の適用
・インターネットEDI 促進調査
・XML スタイルシートの活用
研究報告書
電子商取引推進協議 中小企業で も 導入可能な
7 2004 年 3 月
・簡単で安価な標準 EDI クライアントシステムの設計・開発
・標準ビジネスプロトコル変会（ECOM）
EDI システムの提言
・共通 EDI-ASP サービスの開発
換方法調査研究報告書
・標準メッセージ変換システムの開発
テキストと実習・大企業，中堅企業，中小企業の EC/EDI ユーザーの EC 実践能力向上を推進プログラムの開する。
EC 実践能力検定試験 3 級
2003年度〜
8
日本商工会議所
EC 実践能力検定試験制度 ・この推進を図るため，IT 関連の知識と実践的なスキルを習得してもらうことを発は㈱シーガ公式テキスト2004 年度
ルが開発してい
目的に，EC 実践能力検定試験制度を創設した。
る。
・公式テキストと実習プログラムを開発している。

―118―

9 1998年度〜（財）全国中小企業情
中小企業情報化実態調査
報化促進センター

・中小企業情報化実態調査
中小企業の情報化推進事業を実施している。
報告書（1998 年度，2001 年
・IT 導入事例を調査している。
度，2002 年度）
・2002 年度には，中小企業の電子商取引の導入支援に関するマニュアルを作・中小企業の電子商取引に成・公開した。
関するマニュアル

10

中小企業総合事業団

繊維ファッション業界の各種調査などを実施。

11

経済産業省
2004 年 6 月
商務情報政策局〜
中小企業庁

IT 経営応援隊

・中小企業の IT 化を啓蒙するための啓蒙用教科書の作成。
・全国的な啓蒙普及活動の展開。

http://www.meti.go.jp/policy/it̲policy/press/0005293/0/ ○040608itkeieiouentai.pdf

経営不振の中小企業の再生を支援する「事業再生アドバイザー」が，中小企業を主な融資先とする地方銀行や信用金庫ので人気の資格になりつつある。
事業再生アドバイザーは，民間資格で，特定非営利活動法人（NPO 法人）の金融検定協会が資格を認定する。2004 年 5 月に第 1 回目の資格試験を実施，約400 名が合格している。
中小企業の IT 投資が渋っている。原因は，中小企業に戦略的なシステムを提案できる専門家の絶対的不足がある。
また，大きな課題として，企業を進化させていくために中・長期的視点で継続的
IT 経営百選に IT 投資が必要である。
IT 活用して経営を成功に導いている優れた中小企業を全国から選抜し「IT 経営百選」として認定する。
中小企業は雇用を拡大
中小企業金融公庫は，バブル経済崩壊後の10年間（1991年〜2001年）の企業
規模別でみた雇用者数の変化に関する調査を纏めた。
大企業が人員削減を進めた一方で，中小企業が雇用を拡大したことが分かった。
製造業だけを取り出して労働生産性（従業者1人当りの付加価値額）の10年間の変化を見たところ，大規模製造事業者は1.5%増にとどまったのに対し，中小企業は10.7%増に達した。人件費の安い中国企業に対抗するため，高付加価値の事業に特化した中小製造業が多いことを示している。
流通向けネット受発注規格 経済産業省は，小売店と卸売業者を結ぶ受発注システムの新規格を作成しまずイオン採用へた。インターネットに対応したデータ送信方法などの規格で，採用するとデータをやり取りする速度が現在の数百倍になり，効率の良い物流体制を組める。
まずイオンが採用する方針。経済産業省は，他の流通大手にも採用を働きかけ，流通システムの改善を促す。
新規格は，XML（拡張可能なマーク付け言語）技術を採用している。

2004 年 10
金融検定協会（NPO
事業再生アドバイザー
12 月 （ 日 経 産
法人）
業新聞）

2004 年 10
13 月 （ 日 経 産 経済産業省
業新聞）
2004年10月 中小企業金融公庫
（日経産業
新聞）
14

2004年11月 経済産業省（日経新聞）
15○○

付表 2 中小企業に関する IT/EC 関係活動（企業）
時期
1

企業

活動テーマ

2004年1月（日経 NEC，富士通，日中小企業向けPCサーバー
産業新聞）
本HP，デル

活動内容

備考

米国マイクロソフトが「Windows Small Business Server 2003」を発売したのを機に各メーカーが売り出す。

○

―119―

2004年1月（日経 富士通中部システ 中 小 企 業 受 発 注 シ ス テ ム ・卸・小売業や外食産業向けに小規模な取引相手との間でも電子商取引を行い，伝票を不要にするサービス。
産業新聞）
ムズ「Chain Flow」
・基本料金は，発注する小売店が月額23万円から。取引相手側は，1企業3,500円から。
・中堅，中小企業が部材受発注情報を自動的に収集するためのシステムを開発する。
・開発するのはEDI受発注業務改善のための情報システム。インターネット経由で取引先のWebを自動的に巡回
早稲田大学，日本
EDI受発注業務改善の情報シ し，部品などの発注データを収集。自社のサーバーで扱えるようにデータ形式を変換，受注データベースに取り込
2004年1月
3
コンピュータ・ダイ
ステム
む。
（日本経済新聞）
ナミクス
・早大がシステムを設計，日本コンピュータ・ダイナミクス（NCD）が構築する。新会社「W&N社」（仮称）を2004年6月に設立予定。
ライセンスオンライ
2004年4月（日経・全国で200人の技術者が中小企業のソフト導入（設定・運用）を支援する。
4ン，ピーエスシー 中小企業のソフト導入支援
産業新聞）
・当初はマイクロソフトとシマンテックの25製品が対象。
（PSC）
2004年5月（日経
中堅・中小向けパソコン「Jシ5
NEC・中堅・中小企業向けのパソコンとして，最大28%値下げして販売攻勢をかける。
産業新聞）
リーズ」
中小企業用電子商取引シス ・中小メーカーや商店がECサイトを簡単に制作・運営できるシステム。
2004年5月（日経6グローバルデータ テム「グローバルコマースシ ・オービックビジネスコンサルタント（OBC）の基幹業務用ソフト「奉行」シリーズと連動する。
産業新聞）
ステム for OBC」
・システム価格は480万円から。
・富士通は，ソフト会社11社と共同で中堅企業向け市場を開拓強化する。
2004年6月（日経
中堅企業向けの最適ソフト提 ・富士通製のサーバーやネットワーク機器とソフト会社の業務用パッケージソフトの最適な組み合わせをあらかじ○
7
富士通め構築し，ユーザー向けシステムの開発期間を短縮する。
産業新聞）
案
・参加するソフト会社：オービックビジネスコンサルタント，サイボウズなど。
2004年6月（日経
中 小 企 業 向 け ERP 「 SAP ・社員200人以下の中小企業を対象にしたERPで，財務，在庫管理，人事などの基本機能を備える。
8
SAP
○
産業新聞）
Business One」
・最小構成価格は70万円。
・中小企業向けに，貿易，決済書類のインターネットASPサービスを提供する。
・英国ボレロ・インターナショナルの電子証明書付きネットワークを活用する。
中小企業向けの貿易，決済 ・利用料金：45，000円／月，事業所。
2004年6月（日経9
日本通運
書類のインターネットASPサ ・ボレロは，ネット上で，送り状や包装明細書などほぼ全ての貿易書類を作成できる標準化した82種類の標準メッ
産業新聞）
セージがある。
ービスを提供・ボレロの日本法人は，1999年に三井物産などが出資して設立，新日本製鉄，東洋インキ製造，東京エレクトロンなどが加入している。
・システム開発のトランスコスモスは，オフィスコンピュータを中核とした旧型システムを，オープンシステムに移行する事業を本格化する。8月にオープンシステムの安定性などを検証するための技術センターをマイクロソフト，日2004年7月（日経
中堅・中小企業向けにオープ
10
トランスコスモス
本ユニシスの協力で設立する。
産業新聞）
ンシステム化の移行支援
・東京渋谷の本社内に「.NETマイグレーションセンター」を設立する。
・移行の対象は，IBM製オフィスコンピュータ「AS/400」を導入している中堅・中小企業。
・ガートナージャパンは，日本国内のPCサーバー出荷動向を纏めた。1月〜3月はデルが初めて首位となったが，2004年7月（日経
国内PCサーバー出荷台数で 4月〜6月は再びNECが首位に返り咲いた。中小企業を中心に出荷台数が伸びた。
11
NEC
○
産業新聞）
NECが首位奪還
・4月〜6月のPCサーバー出荷台数は，前年同期比12.4%増の92,107台。
・ガートナーは，7月〜9月お11%程度で出荷が増えると予測している。
・東京都大田区の中小製造業の業況判断は3年半ぶりにプラスに転じた。景気回復がようやく中小企業に波及した
2004年8月（日経とも言えるが，不況期に経営体質強化や業態転換まで試みるなど自助努力の成果も見逃せない。
12
中小企業，好況の波
産業新聞）
・昔は，区内に1万社以上あった事業所も今は6千前後。バブル後に淘汰が進み，残った企業は技術力が高いので仕事が集まり易い。
2―120―

・統合基幹業務（ERP）システムが企業のIT化と共に伸びてきたが，2003年ついに止まった。
・大企業向けが前年度比5.7%の減少が最大の理由。中小企業向けは8.3%増加した。
・ERP大手のSAPジャパンは，6月に中小企業向けの新製品「SAP Business One」を発売した。
2004年8月（日経13IT各社，中小市場を攻める
・日本オラクルは，中小企業向けのソフトのオンライン営業拠点「オラクル・ダイレクト」に人員強化した。統合業務 ○産業新聞）
ソフト「E-ビジネス・スイート」の販売強化する。
・マイクロソフトのサーバー部門の売上は前年度比20%増。牽引力は中小企業向け。
・OBCは，「中堅・中小向けITシステム市場が本格化するのは今年」と推測している。
・ミロク情報サービスと日立ソフトウェアエンジニアリングは，中小企業向けのソフト販売，サービス事業で提携す2004年8月（日経 ミロク情報，日立ソると発表した。
14
中小企業向け事業を連携
○
産業新聞）
フト
・ミロクの会計ソフトと日立ソフトのセキュリティ用ソフトを組み合わせて，両社の顧客に売り込む。
・中小企業向け新サービスとして，インターネットを使う無担保融資サービスを共同開発する。
最近のコンピュータ業界で，新しい3文字キーワードが注目されている。「SMB（Small and Medium Business）」であ
本当に中堅・中小企業のニー る。「SMB市場に本格的に取り組む。」などを言われる。
ズを考えていますか。”SME 最近はSMBのキーワードで大手コンピュータ会社が積極的に乗り出している。既に市場の飽和感さえある大手ユ
2004年9月（日経○15ブーム”は安易な姿勢で乗る ーザーだけでなく，中堅・中小ユーザーまで固める戦略である。
IT Pro）
SMB市場の開拓は容易ではない。多くの難題がある。中堅・中小ユーザーには，大手ユーザーのような一般的なと失敗する。
IT経営の考え方が通用しない。標準化できない部分を対応することを競争力としている中小企業もある。
・インターネット検索関連サービスのアウンコンサルティングは，中小企業を対象に検索エンジンを使った販売促
2004年9月（日経
検索エンジン最適化を中小企
16
アウンコンサル
進手法の技術講座を始める。
産業新聞）
業向けに講座・検索結果で企業名などを上位表示できる「検索エンジン最適化（SEO）」と呼ぶ手法を伝授する。
・システム開発のコアシステムズは，携帯電話のインターネット画面を使った通販システムの販売に乗り出す。
2004年9月（日経
携帯向け通販システムを中17
コアシステムズ・システム名は，「e買い物」。不特定多数を対象とする従来のパソコン通販システムと異なり，常連客からの注文を
産業新聞）
小企業向けに開発
増やしたい中小店舗を主なターゲットにする。
・金融機関向けの人材研修の銀行研修社は，中小企業の最高財務責任者（CFO）の養成講座を通信教育方式で2004年9月（日経
中小企業向けのCFO養成講
18
銀行研修社
10月に始める。
産業新聞）
座
・来年5月から全国130箇所で試験を行い，合格者に「CFO認定書」を与える。
2004年上期の国内パソコンの総出荷台数は，前年同期比7%増の702万台。
2004年9月（日経上期の国内パソコン出荷
19
IDCジャパン調査
法人需要が上半期としては最高を記録した。法人向けが，中小企業の需要に支えられ11%増の426万台と拡大し ○産業新聞）
702万台，7%増た。個人向けは1.4%増の276万台と下げ止った。
中小企業向け経営支援サイト運営のジェービービーは，ソフト開発のネオジャパンと共同で，営業支援ソフトの期間貸し（ASP方式）方式での提供を始める。
2004年10月（日経20
ジェービービー
低価格営業支援ソフト
営業担当者１人当たりの利用料は，１ヵ月2,100円。ジェービービーの営業支援システム利用料として同3,150円が産業新聞）
別途必要だが，同様の他のサービスに比べ2〜3割程度の利用料に設定した。20〜30人程度の中小企業を中心に
年間1,000社の契約獲得を目指す。
日本IBMは，中小企業向けにあらかじめソフトを組み込んだ低価格のPCサーバーを発売した。
ソフト組込み低価格サーバー 価格は89,250円。
導入や設定に関する質問を24時間ホームページで受け付けるサービスを2005年5月まで無償で提供する。

21

2004年10月（日経
日本IBM
産業新聞）

22

2004年10月（日経 石川コンピュータ・
中小向けの販管ソフト
産業新聞）
センター

23

サイボウズは，11月から顧客管理ソフトの中小企業向け販売でNTTビズリンクと連携する。自前でサーバーを持2004年11月（日経 サイボウズとNTT 顧客管理ソフトとホスティング
たない企業に同ソフトとNTTビズリンクのホスティング（サーバーの能力貸し）サービスを組み合わせて売り込む。
産業新聞）
ビズリンク
のセットで中小企業開拓
サイボウズの顧客管理ソフト「メールワイズ」は，顧客から届く大量のメールを複数の担当者で処理するのに使う。

コンピュータ機器販売の石川コンピュータ・センター（金沢市）は，見積から売上，在庫まで一括管理できる中小企
業向けの販売管理ソフト「CESS（チェス）販売管理システム」を開発した。
システム導入費用は525,000円からで，保守契約料金は年間52,500円。

―121―

○

PCサーバーの低価格化が進んでいる。NECと米デルのシェア争いが加速しており，富士通など各社が追随してい2004年11月（日経 NEC，米デル，富 PCサーバー，個人も手が届くるためである。
○
産業新聞）
士通
範囲に
4万円台のPCサーバーが登場する一方で，各社では高付加価値モデルも発売，品揃えが充実してきている。
韓国のECサイト構築サービスのコリアセンタードットコムは，日本法人を設立，ECサイトの構築支援・管理サービ
2004年11月（日経 コリアセンタードッ 韓国VB，日本進出スを始めた。日本法人はメイクショップ。
25
月額使用料が5,000円からと低価格のサービスをソフトの期間貸し（ASP）方式で提供する。同社は，韓国で約
産業新聞）
トコム
ECサイトの構築支援
50,000件のECサイト構築・管理の実績があり，日本でも中小小売店・メーカーを中心に需要を開拓する。
ライブドアは11月9日，会計ソフト大手の弥生を買収すると発表した。買収金額は約230億円。
弥生の持つ全国の中小企業の顧客網を生かし，ライブドア自体のソフトウェアや金融商品の販売事業を拡大す
2004年11月（日経26
ライブドア
会計ソフトの弥生買収る。
産業新聞）
弥生の主力事業はパッケージソフト販売で，ホームページ開設などのIT化を支援するサービスも展開している。
2004年7月期の売上高は66億円，営業利益は25億円。
米デルの日本法人は，ERP大手独SAPの日本法人，SAPジャパンと提携して，中小企業向けに販売価格を従来の1/10以下に抑えたERPシステムを発売した。
2004年11月（日経
中小企業向けERPシステム
27
デル，SAP
デルの高性能サーバー「パワーエッジ」と，SAPの財務や在庫管理などの業務をこなすERP「SAPビジネス・ワ ○新聞）
価格１／１０以下にン」，システム導入にかかわるコンサルタントサービスを一体化。価格は1,575万円からで，従来システムの1/10以下という。
マイクロソフトと英通信大手のBritish Telecommunications (BT)は，BTのマイクロソフト技術を使って中小企業向け
2004 年 11 月 （ IT
中小企業向けWebサービスで にインターネットを使った各種の新サービスを立ち上げる。
28
BT，MSMedia News）
提携
BTは，マイクロソフトの.NET技術を採用し，電子メールや予定表・住所録共有，その他のアプリケーションを低料金で中小企業に提供する。
2004年7月〜9月の法人企業統計によると，資本金1億円未満の中小企業の設備投資は2兆8,515億円で，前年同2004年12月（日経
中小企業，以外に強い投資 期を19%上回った。
29
財務省
○
新聞）
意欲
中小企業の設備投資が前年同期を上回ったのは4期連続。景気回復の恩恵に加え，金融機関が中小企業向け融資に積極的になっていることが背景にある。
システム開発の日本コンピュータ・システム（NCS）は，NECと連携して首都圏での営業体制を強化する。
2004年12月（日経
中小企業向けシステム
NECとその関連会社を通じて中小企業向け業務パッケージを販売，首都圏での顧客数を3年後に現在の2倍の150
30
日本コンピュータ
新聞）
NECと連携，首都圏営業強化 社程度にまで拡大する。
NECの営業部門が，首都圏でNCSの工場向け生産管理システムとなる業務用パッケージを販売する。
システム開発のニュートラル（札幌市）とイー・カムトウルー（札幌市）は，ASP方式を使った商品受発注システムを共同開発した。
2004年12月（日経
中小スーパー向け受発注シ
31
ニュートラルなど
利用料を安価に抑えることで，これまで電話やFAXに受発注を頼っていた中小スーパーや小売チェーンへの導入
新聞）
ステムをASPで提供を目指す。
月額料金は売上に比例する従量制を採用。売上高100億円のスーパーの場合，月額利用料は約63万円となる。
24

―122―

付録2 認証技術応用と PKI 認証局サービスの動向
認証技術と PKI 認証局に関する 2004 年度の新聞記事，各種ホームページなどの情報を付表 3
認証技術応用関係活動と付表 4 PKI 認証局関係活動に示す。

付録2.1 認証技術応用の動向
z

種々な場面に個人認証を取り入れるケースが増えてくる。例：社内ネットワーク接続に個
人認証，複合機（プリンター，コピー，ファックス）の使用に個人認証，パソコンの使用に個人認証，キャッシュカード・クレジットカードの使用に個人認証。

z

認証技術としては，ID・パスワード，認証ソフト，IC カード，USB 端末，手のひら静脈認証，顔認証などが採用されている。セキュリティを実現する多くの技術が登場している。

z

中小企業向けに低価格の暗号化装置が登場。

付録2.2 認証局サービスの動向z

電子証明書市場が急拡大している。理由としては，大企業だけでなく中小企業にも利用が広がっているため。

z

サーバーの電子証明書の発行サービスの市場価格は，65,000 円〜80，000 円／1 枚，1 年間。

z

日本での PKI 認証局の大手は，日本ベリサイン（約 8 割の国内シェア），ビートラステッ
ド・ジャパン（旧日本ボルティモア），セコムトラストネット。

z

国税の電子申告用に，有期限の無償サービスが登場した。

―123―

付表 3 認証技術応用関係活動
時期

企業

活動内容
備考
・システム構築のテレマトリックスは，米アベンテイルが開発・販売するインターネット向け暗号化通信装置
を7月末までに発売する。
中小企業向けに低価格
2004年7月（日経1テレマトリックス・販売する機器は，「アベンテイル・EX-750」。暗号化通信技術のSSLを採用，専用の暗号通信ソフトがなく
産業新聞）の暗号化装置の発売ても通信内容を暗号化できる。
・利用者25人の場合，118万円であり，従来品より35%割安である。
・生体認証，暗号化などの要素技術やシステム設計の他，廃棄パソコンのハードディスクの情報を消去す
る情報漏洩防止策まで一貫サービスを提供する。
2004年9月（日経
情報セキュリティ事業を ・「情報セキュリティ・アライアンス」の名称で，ソリューション会社のアイティフロンティア，電子認証局を構
2
三菱商事
築・運営する日本サイバースペース，システム監視サービスのインフォセック，パソコンのハードディスク
産業新聞）
一貫サービスの完全データ消去サービスを手がけるデジタルリユースの4社が連携する。
・共同の営業体制を作ることで，官公庁や電力会社，銀行などに一括サービスの採用を働きかける。
暗号ソフトのRSAセキュリティは，マイクロソフトの基本ソフト（OS）「Windows」の安全性を強化するシステ
ムを10月28日に発売する。
使い捨てパスワード装置と認証ソフトを組み合わせ，社外に持ち出したノートパソコンに保存されたデータ ・パソコン（Windows）利用のを紛失や盗難による漏えいから守る。3年後をメドに3千社への販売を見込む。
2004年10月（日経ウインドウズの安全性を
3
RSAセキュリティ
販売する「RSAセキュアIDフォーマイクロソフトウインドウズ」は，RSAの使い捨てパスワード装置「セキュ 本人認証。
産業新聞）
強化
アID」を使ってウインドウズの利用を制限する。6桁の乱数を60秒に1回自動生成するセキュアIDを使い， ・パスワードと認証
ソフトによる。
従来のパスワードの代わりに使う。
価格は，サーバーソフトが利用者25人の場合971,000円（年間保守費用別）。セキュアIDは，49人が2年間利用する場合1個9,000円。
リコーは，ICカードで本人認証できる複合機（多機能複写機）のシステムを開発した。
読み取り装置にICカードをかざし，本人と確認することでプリンター，コピー，ファックスなどの各機能が使える。不正利用を防ぐとともに，個人ごとの出力枚数管理なども可能。2005年5月の個人情報保護法全面○施行を控え，製品の情報セキュリティ機能を強化する。
・複合機（コピー機
2004年10月（日経
本人認証，複合機の全機
4
リコー
非接触型ICチップの「フェリカ」を内臓した社員証や携帯電話などで本人認証できる。
産業新聞）
能に採用
など）の本人認証。
複写機業界では，富士ゼロックスがフェリカによる本人認証で複合機のプリンター機能を使えるようにする
・ICカードによる。
システムを開発，今年末に商品化する予定。
事務所の入退室管理などでICカードを使った本人認証を採り入れる企業が増えていることから，リコーは複合機でも本人認証機能の需要が高まると判断した。
○
預金者の個人認証技術として「手のひら静脈認証」技術を応用した「スーパーICカード」の運用を10月12日
・キャッシュカード，から始める。
クレジットカードの2004年10月（日経
手のひら静脈認証を採用
5
東京三菱銀行
スーパーICカードは，キャッシュカード，クレジットカード，及び電子マネーの3つの機能を1枚にまとめてい本人認証。
産業新聞，広告）したスーパーICカードる。スーパーICカードの利用時に，専用ATMに手をかざすと，あらかじめ登録された静脈パターンと照合
・手のひら静脈認証
して個人認証する。
とICカードによる。
2004年10月（日経
6
シャチハタ
産業新聞）

活動テーマ

「社外秘」の電子印鑑

シャチハタは，パソコン画面上で「社外秘印鑑」を押印すると関係者以外は閲覧や印刷ができない機能など安全（セキュリティ）機能を高めた電子印鑑の新システムを開発した。
新製品「セキュリティ電子印鑑パック」（6，800円）は，社外秘，印刷禁止，極秘などの5つの機能を持つ。別にパソコン1台毎に専用ソフトの「UCV Viewer 2.0」（9，800円）が必要。

―124―

業務用ソフトのアクシスソフトは，企業の基幹業務システムの端末ソフトとして使う業務用閲覧ソフト「リッチクライアント」の安全対策機能を強化する。
業務用閲覧ソフトの安全 リッチクライアントソフトは，パソコンから基幹業務システムに情報を入力するためのソフトで，財務管理シ
2004年10月（日経7
アクシスソフト対策
ステムの数値入力や帳票の作成など様々な業務に活用されている。
産業新聞）
暗号化や個人認証
新製品「Biz/Browser V4.1」は，サーバーとの通信を全て暗号化した他，パソコン内の情報も暗号化して保存。保存データは改ざんされないように変更を検知する機能も加え，更にパソコン固有の番号とデータに記録された番号が一致しなければ読み取れないようにした。
三菱電機は，個人情報保護ソフトを予め組み込んだ中小規模向けサーバーを発売した。
導入後直ぐに利用できるのが特徴。
2004年10月（日経
中小規模システム向け
8三菱電機
発売するのは，「CRY PROFILE SERVER」。サーバー内の機密情報を自動的に暗号化して不正なアクセス
産業新聞）
暗号化サーバーから守る機能を搭載した。機密情報の取扱履歴を管理できるため漏洩時の経路追跡も可能。
中小規模システムに利用した場合，同社の従来製品の1/10の費用で導入できると言う。価格は98万円。
キャノン販売は，社員証などのICカードで利用者を認証する複合機（多機能複写機）システムの本格販売
本人認証の複合機システ を開始した。
2004年10月（日経ム
9
キャノン販売このシステムは，プリンターやFAX，コピーなどの機能を利用する際に，読み取り装置にICカードをかざ○
産業新聞）
法人向け開拓し，本人かどうかを確認する。
価格は30万円程度。
アルテックの全額出資子会社でセキュリティ事業などを手がけるアルテックエーディーエス（アルテック
ADS）は，米ビサージと顔認証システム事業で提携する。
2004年11月（日経
顔認証システム
顔認証システムを構築するために必要なビサージのソフトをシステム開発会社向けに販売する。パスポ○
10
アルテックADS
産業新聞）
ソフト技術販売
ートや運転免許証の認証など公的機関向け，預金者の本人認証など金融機関のシステム向けなどへの販売を見込む。
ビサージの技術は米国のパスポート認証や運転免許証認証などで利用されており信頼性も高い。
パソコン周辺機器のバッファローは，中小企業向けに社内ネットワーク接続認証システムを2005年2月に発売する。
2004年11月（日経パソコン認証システム
社員がネットワークにパソコンを接続する時，管理サーバーでパソコンを認証し接続の許可をする。
11
バッファロー○
産業新聞）
中小企業向け発売「セキュア・ロック・ステーション」の名称で始める。各社員はパソコンのUSB端子に差し込む認証カギとパスワードを使ってネットワークに接続できる。
価格は，登録者30人につき，認証カギ5本付きで98，000円。
NTTPCコミュニケーションズは，ユーザー側でもIDを確認する双方向の認証サービスの販売を開始した。
ユーザー側でも認証認証に必要なIDが利用するたびに変わる「ワンタイム」方式を採用。サーバーだけではなく，ユーザー側
2004年11月（日経12
NTTPC
双方確認サービス「なり でも認証することでセキュリティを高めた。
産業新聞）
すまし」防ぐ新サービスの名称は，「MyKey BOSS」。認証技術には，九州大学大学院の研究室が設計し，セキュアー
ド・コミュニケーションズが製品化した「Qシグナル」方式を採用した。ASPサービスとして提供する。
情報セキュリティのRSAセキュリティは，電子商取引の本人確認などに使う電子証明書が有効期限切れかどうかをリアルタイムで確認できる検証用ソフトを発売した。システムに負荷をかけず，比較的低価格で導電子証明書の効力，リア 入できるのが特徴。ネット顧客の認証などに電子証明書を使う金融機関から中小企業まで幅広く販売す2004年12月（日経13
RSAセキュリティ ルタイムで確認る。
産業新聞）
価格は，100人が利用する場合，利用者1人当り3，234円。
企業向け安価なソフト同様の検証用サーバーは専門の電子認証機関などでは採用されているが，新ソフトは中小企業などでも低価格で導入でき，需要は大きいと見ている。

―125―

付表 4 PKI 認証局関係活動
時期

企業

活動テーマ

活動内容
・6月1日から全国で始まる国税の電子申告「e-TAX」に必要な電子証明書を無償提供する。
・期間は5月1日から6月末まで。NTTコムのインターネット接続サービスの利用者が対象。
ミロク情報サービス
国税の電子申告「e-TAX」
・無償の電子証明書の有効期間は1年間。
2004年4月（日経○
1（MJS），NTTコミュニケ に必要な電子証明書を無・通常は9，000円以上の価格で販売しており，ICカード読み取り装置も市販で4，600円程度する。
産業新聞）
ーションズ
償提供
・国税庁は，「e-TAX」に使える電子証明書の発行機関として官民の7機関・事業者を指定しており，
MJSもその1つ。
・電子証明書の発行サービスの市場が急拡大している。大企業だけでなく中小企業にも利用が広
日本べりサイン，日本
がっている。現時点では電子証明書を取得しているサーバーは国内全体の1割程度とみられ，本
2004年4月（日経 ボルティモアテクノロジ 電子証明書，発行が急拡
2
格的な市場の拡大はこれから。
○
産業新聞）
ーズ，セコムトラストネ 大・日本べりサイン（約8割の国内シェア），日本ボルティモアテクノロジーズ，セコムトラストネットット
・サーバーの電子証明書発行サービス料金：65，000円〜80，000円／1枚，1年間・システム構築のテレマトリックスは，米アベンテイルが開発・販売するインターネット向け暗号化通信装置を7月末までに発売する。
2004年7月（日経
中小企業向けに低価格の
3
テレマトリックス・販売する機器は，「アベンテイル・EX-750」。暗号化通信技術のSSLを採用，専用の暗号通信ソフ
産業新聞）
暗号化装置の発売
トがなくても通信内容を暗号化できる。
・利用者25人の場合，118万円であり，従来品より35%割安である。
・電子認証システム大手の米ビートラステッドは，同業の日本ボルティモアテクノロジーの発行済み株式の約28%を購入し，同社の経営権を取得した。
・英ボルティモア社は，昨年9月，電子認証事業などを米ビートラステッドへ売却することで合意し2004年7月（日経日本ボルティモアの経営
4
米ビートラステッド
た。
○
産業新聞）
権を取得
・日本ボルティモア社は，NTTコミュニケーションズや日本テレコムに電子証明書ソフトや認証ソフトを販売している。
・日本ボルティモア社の社名は，7月29日付けで「ビートラステッド・ジャパン」に変更する。
・電子認証サービスの日本べりサインは，国内でICタグ関連事業に進出する。
・ICタグの情報管理サービスや企業が製品情報を蓄積したサーバーへの電子証明書発行を手がける。
2004年9月（日経
情報管理や証明書発行で5
日本べりサイン・今後，実証実験に参加し，2005年度以降の事業化を目指す。
産業新聞）
ICタグ事業に参入
・タグに記載された「電子製品番号（EPC）」と，各企業のサーバーに蓄積された製品情報を結びつけるためのデータベースの運営・管理を始める。
・情報の安全性を確保するため，企業のサーバーや利用者への電子証明書の発行事業も始める。
大塚商会とマイクロソフト日本法人は，エヌシーネットワーク（NCネット）が運営する中小製造業向
2004年10月（日経
中小製造業向けサイト
け電子商取引サイトの会員企業を対象に無料の情報セキュリティ診断サービスを開始した。
大塚商会など産業新聞）
セキュリティを診断
NCネットの製造業向け受発注サイトは約13,000社の会員企業を持つ。

―126―

備考

付録3 人材育成「1.3 中小企業のインターネット EDI の問題点・課題」で述べたように，中小企業のインター
ネット EDI に関する問題点・課題として，以下のようなユーザー体制・能力の問題がある。
z

電子商取引を行う人的環境が整っていない。

zシステム構築に専門知識を要するので，システム構築できない。

z

セキュリティ対策が十分に構築できない。

ネット社会においては，企業はその大小にかかわらず，インターネットを通じて外部（顧客，取引先等）と時間，距離に関係なく繋がっている状況になっている。つまり，EDI，電子商取引，
電子入札，電子申請，電子の納税，電子決済，電子会議，電子メール等において，全てがデジタルデータでネットワークを通じて 24 時間 365 日休みなく情報交換している。
デジタルデータでネットワークを通じてデータ交換しても，社内の情報システムが整備されていなければこれを有効に活用できない。
多くの中小企業は社内情報システムが十分に整備されておらず，社内情報システムの整備も重要である。
企業内の IT 化を推進するとともに，実社会とネット社会を結びつける人材が必要とされ，パソコンの操作技能やハード，ソフトの知識のみならず，ネット社会における企業活動で必要となる，
EDI，電子商取引，電子コミュニケーション，業務ネットワーク，運用・管理，電子認証，情報セ
キュリティ，ネット関連法律等に関する知識，スキルを持つ EC 実践担当者というべき人材が求められている。特に，人的資源に限りがある中小企業においては，こうした人材の確保・育成が急務である。
またこのような背景から，2005 年４月より経済産業省関係税制改正において，人材育成に積極的に取り組む企業について，教育訓練費の一定割合を法人税額から控除する制度「人材投資促進減税」が，創設・実施されることになった。人材投資促進減税は，企業の人材育成のための投資に関して，我が国の産業競争力の基盤である産業人材を育成・強化する観点から，人材投資の減少傾向
を拡大に転じさせるとともに，企業における戦略的な人材育成への取組を強力に後押しするために創設するものである。

付録3.1 「ITSSP」と「IT 経営応援隊」
経済産業省は，1999 年より 6 年間にわたり「戦略的情報化投資活性化事業（ITSSP 事業）」を実施し，中堅・中小企業の情報化の支援を行ってきた。中小企業の立場に立って経営に活かす IT
化を支援する人材として「IT コーディネータ」制度を発足させた。
2004 年度には ITSSP 事業の成果を広く普及させるために「中小企業の経営改革を IT の活用で応援する委員会（IT 経営応援隊）」事業を 3 ヵ年事業として発足させた。中小企業の IT 化がなかなか進まないのは，IT 化を妨げる 3 つの壁があり，この壁を越えるための支援を行うことを目的
として IT 経営応援隊事業が発足した。3 つの壁とは①IT 導入の壁，②経営の壁，③企業の壁である。IT 経営応援隊は ITSSP 事業の成果を引き継ぎ，これまでの成果を集大成した「IT 経営教科書」の作成を行っている。IT 経営教科書のベータ版は，2005 年 3 月に完成予定である。企業の壁を超えるためには中小企業でも容易に導入できる EDI システムを提供することが必要である。今後のIT 経営応援隊活動の重要テーマである。
―127―

IT 経営応援隊事業では，IT 経営の重要性の啓蒙活動を推進しており，IT を経営に活用する手順を学ぶための経営者 IT 経営研修コースや IT 導入成果発表セミナーなどを実施している。

付録3.2 日本商工会議所の「日商 EC 実践研修」と「日商 EC 実践能力検定試験」
IT 関連の知識と実践的なスキルを習得してもらうことを目的に，日本商工会議所は，「日商 EC
実践研修」と「日商 EC 実践能力検定試験」を創設した。
「日商 EC 実践研修」は，単なるパソコンの操作レベルではなく，ネット社会での電子コミュ
ニケーションを行うために知っておきたい知識や適切な態度を習得させる。特に，デジタルコミュ
ニケーションの特徴やビジネスにおける電子メール，ホームページの活用，及び電子認証，電子商取引の基礎知識などを教育する。
これからネット取引を行う企業にいる人材全てが学ぶべき知識とスキルが体系的に網羅されている。
単なる知識としてではなく，「実践できるスキル」の習得を目指している。従来，このようなネット社会における知識やスキルを体系的に学ぶための教材や教育の仕組みがなく，
情報セキュリティやプライバシーマークあるいはネットワーク管理者などの専門特化したベンダー向けの教育・資格ばかりであった。本研修と本検定試験は，企業実務で必要とされる幅広い EC/IT 関係の知識と実践的なスキルを習得・認定するものである。
付図 1

EC 実践能力検定制度の体系に EC 実践能力検定制度の体系を示す。

本検定試験は，（財）日本情報処理協会及び電子商取引推進協議会（ECOM）が後援している。
なお，「日商 EC 実践研修」と「日商 EC 実践能力検定試験」は，本設計・導入ガイドの内容を研修・試験するものではない。

［検定制度］
2005 年時期未定
EC ﾏｽﾀｰ［実践研修］
体験を通じて実践的スキルを習得

幅広い知識を習得

合格
2005 年時期未定

応用コース（2005 年 4 月予定）
E ラーニング（2004 年8 月）

1 級公式テキスト(2005 年 3 月予定)

1級
受講
修了

合格
2004 年 10 月
2級

基礎コース
（2004 年7 月）［テキスト学習］2 級公式テキスト(発刊済)受講2004 年 4 月
3級

付図 1

EC 実践能力検定制度の体系―128―

3 級公式テキスト(発刊済)(1) 日商 EC 実践能力検定の内容
日本商工会議所の「日商 EC 実践能力検定」は，企業においてネット社会への対応を推進する人材として必要とされる以下の能力（知識，スキル）を問う内容となっている。
① 外部調整能力（ベンダー等とハード，ソフトについて自社の業務に照らして，意見交換ができる能力。ネットワーク関連の基礎知識）② 内部調整能力（企業内の情報化について，運用方針を定め各部門との連絡調整ができる能力）③ セキュリティ管理能力（セキュリティ対策に関する知識，スキル）④ 危機管理能力（ネットワーク社会におけるトラブルを未然に防止するとともに，トラブルが起きた際の的確な対処）⑤ 法律知識に関する能力（個人情報保護，著作権，ネット取引等に関する法律知識）⑥ 電子認証に関する能力（入札や EC で必要となる電子認証に関する知識やスキル）⑦ 情報通信機器に関する知識（サーバー，パソコン，モバイル端末，IP 電話，等）⑧ Web マスターとしての能力（ホームページ運用と効果的な PR，広報，ニュースリリース等）⑨ 情報・データ管理能力（企業情報の蓄積・保存・バックアップ・管理）
また，日商 EC 実践能力検定には以下のレベル設定がある。
① EC マスター
ネット社会における幅広い意味での EC に精通し，他社をも指導できる能力を有して活躍できる人材。
② 日商 EC 実践能力 1 級
自社の各種ポリシーを策定・実践する能力を持ち，ネット社会における幅広い意味でのEC という観点から，自社の他メンバーを指導できる人材。
③ 日商 EC 実践能力 2 級
ネット社会における幅広い意味での EC という観点から，自社内の各種オペレーションを実践面でリードできる人材。
④ 日商 EC 実践能力 3 級
ネット社会における幅広い意味での EC に関する知識と実践スキルを持つ人材。
特に，企業においては，
まず 3 級及び 2 級の人材育成を重点的に行う必要がある。
既に 2004
年 4 月からインターネットを通じての EC 実践能力検定をネット試験で全国各地でスタートしている。ネット試験とは，インターネットを通じて全国のネット試験会場でいつでも検定試験が受験できる試験である。
日 商 EC 実 践 能 力 検 定 試 験 の 詳 細 は ， 日 本 商 工 会 議 所 の 検 定 ホ ー ム ペ ー ジ（http://www.kentei.ne.jp/）を参照。

―129―

付録4 EDI標準メッセージ
付表4.1 業界標準メッセージとECALGAの比較
石油化学業界JPCA標準ﾋﾞｼﾞﾈｽﾌﾟﾛﾄｺﾙ（XML版）
注文

ECALGA注文情報（BDS0210 Ver2003A-Rev01）（社）電子情報技術産業協会（JEITA）開発＃＃

No.
C00001
18040
18041
18042
C00002
18014
18015
18016
18017
C0000318018
18019

ビジネスドキュメントヘッダ

18020
18021
C00004
18035
18001
18009
C00005
18002
18003
18005
18007
18010
C00006
18008
18036
18037
18038
18039
C0000718004
1 C00008
2

18011

3

18012

4

18013

5

00001

6

00009

7 C00009

ビジネスドキュメント本体共通部

8

00004

9

18022

10

18023

11

18024

12

00006

13

00184

14

00279

15

00018

16

00260

17 C00010
18

00005

19

18027

20

18028

21

18029

22

18031

23

18033

24

18034

25

00092

26

00264

L1L2 L3 L4L5L6 L7 L8 L9 L10L11 L12
BDデータ作成日時
BDデータタイムゾーン
BDデータ作成日
BDデータ作成時刻
送信者
送信者コード
送信者コード管理組織
送信者所属プロバイダコード
送信者センタコード
受信者
受信者コード受信者コード管理組織
受信者所属プロバイダコード
受信者センタコード
ビジネスドキュメントの識別
ビジネスドキュメントの標準
ビジネスドキュメントのバージョン
ビジネスドキュメントID
ビジネスサービス条件
コンプレックスビジネスコラボレーションID
ビジネスコラボレーションID
ビジネストランザクションID
ビジネスアクションID
TPA番号
ビジネスコラボレイション制御
カンバセイションID
BC回答期限日
BC回答期限時刻
BC制御意味コード
BC制御理由コード
運用モード
テスト本番区分
データ順序と属性
タイムゾーン
データ作成日データ作成時刻
データ処理No.
訂正コード
発注者
発注者コード
発注者コード管理組織
発注者企業名発注者企業の国コード
発注部門コード
発注部門名
発注部門名（漢字）購買担当
購買担当（漢字）
受注者
受注者コード受注者コード管理組織
受注者企業名受注者企業の国コード
受注部門コード
受注部門名
受注部門名（漢字）
営業担当
営業担当（漢字）

必須

値の型

●
●

X(10)
X(8)
X(6)

●
●

X(20)
X(10)
X(20)
X(20)

●
●

X(20)
X(10)
X(20)
X(20)

●
●
●

X(5)
X(14)
X(7)

●
●
●
●
●

X(8)
X(7)
X(7)
X(8)
X(34)
X(64)
X(8)
X(6)
X(1)
X(1)
X(1)

●
●
●
●
●
●

●
●

X(10)
X(8)
X(6)
X(5)
X(1)
X(20)
X(10)
K(40)
X(10)
X(8)
X(20)
K(40)
X(7)
K(14)
X(20)
X(10)
K(40)
X(10)
X(8)
X(20)
K(40)
X(7)
K(14)

出現回数
1
0/1
1
1
1
1
1
0/1
0/1
1
1
1
0/1
0/1
1
1
1
1
1
1
1
1
1
1
1
0/1
0/1
0/1
0/1
0/1
1
1
1
0/1
1
1
1
1
1
1
1
0/1
0/1
0/1
0/1
0/1
0/1
0/1
1
1
1
0/1
0/1
0/1
0/1
0/1
0/1
0/1

(1)マッピング可能項目
必須・
項目名称
任意・
補完

データ種別

必須

鉄鋼業界

自動車業界

電機・電子業界

住宅産業

鉄鋼EDI標準

JAMA・JAPIA-EDIJEITAベース

JEITAベース

確定注文情報注文確定情報

注文情報

注文確定情報

項目名称

項目名称

項目名称

ｷｰ・
必須・
任意

情報発信者企業コード
情報発信者名○☆

情報受信者企業コード
情報受信者名

☆
☆

情報区分

○

ｷｰ・
必須・
任意

項目名称

ｷｰ・
必須・
任意

中小企業（TAMA協会）

機械業界の事例

画面，発注明細書，他

注文確定情報

項目名称

ｷｰ・
必須・
任意

配信日

任意

項目名称

ｷｰ・
必須・
任意

情報区分コード

適用業務区分
処理区分

必須

処理年月日
処理時刻

必須
必須

赤黒区分
発注者企業コード

内示／確定区分

情報区分コード

必須

情報区分コード

必須

情報区分コード（確定注文)
TPA番号

必須
任意

情報区分コード

必須

○
○
○
○

処理日／時刻ﾃﾞｰﾀ作成日

準必須

作成日付

必須

発行日

準必須

データ作成日必須

任意

データ作成年月日
データ作成時分秒
データ処理No.
訂正区分

変更区分

ﾃﾞｰﾀ処理No.
訂正ｺｰﾄﾞ

準必須
準必須

データ処理№
訂正コード

必須
必須

発行番号
訂正コード

準必須
任意

データ処理No.
訂正コード

必須
必須

必須

発注者コード◎

発注者

発注者ｺｰﾄﾞ必須

発注者コード必須

発注者コード

任意

発注者コード

必須

発注者

必須

部門
担当

準必須
任意

工場コード
部門名

任意
任意

発注者名称
発注者部門コード必須

発注者担当課コード☆

発注部門コード
発注部門名

準必須
任意

発注会社担当部署名

任意

発注者担当者コード

☆

購買担当

購買担当
購買担当（漢字）

必須
任意

発注会社担当者名

任意

購買担当
購買担当(漢字)

必須
準必須

購買担当
発注者名

任意
任意

受注者コード◎

受注者

受注者コード

必須

注文先

必須

取引先コード必須

受注者コード

必須

取引先名/

必須

受注担当（漢字）

任意

受注者名

任意

受注者名称
受注者担当課コード☆

受注部門コード

任意
受注会社担当部署名

任意

受注会社担当者名

任意

1 C00108

注文ＢＤ情報2 00007

注文番号

●

X(23)

1

注文番号

必須

注文番号

☆

注文番号

発注番号

必須

注文番号

必須

注文番号

必須

3 18103

注文日

●

X(8)

1

発注者・注文日

任意

発注年月日

☆

発注日

注文年月日

必須

注文日

必須

注文年月日

必須

発注形態

準必須

1

4 C00109

注文ＢＤ情報．詳細

5 00167

発注形態区分X(2)0/1

発注形態区分

任意

6 00170

変更注文区分X(2)0-3

変更注文区分

準必須

7 00168

親注文番号

X(23)

0/1

親注文番号

任意

8 00180

一括納入番号

X(10)

0/1

00072

見積依頼番号X(23)0/1

10 00068

予約番号

X(23)

0/1

11 18151

注文請け返信期限

X(8)

0/1

9

注文番号

必須

0/1

変更注文区分（繰り返し指定あり 任意

見積依頼番号

注文請け発行日

1 / 5 ページ

任意

任意
予約番号

任意

請け返信期限任意

12 00430
13 C00110

返品代納区分X(1)0/1

9(9)V(3)0/1

注文ＢＤ情報．変更前．数量単価

0/1

14 00424

変更前注文数量

15 00425

変更前単価

9(10)V

0/1

16 00426

変更前単価（外貨）9(11)V(5)0/1

17 C00111

注文BD情報．変更前．納入

18 18091

変更前納期

19 00428

変更前納入指示数量

20 C00138

取引方法．ビジネスモデル

0-31
X(8)

0/1

9(9)V(3)0/1
0/1

21 00010

コック区分

X(1)

0/1

22 00017

支給区分

X(1)

0/1

23 00027

直納区分

X(1)

0/1

24 C00139
25 00166
26 C00140
27 00030
28 C00141
29 00281
30 C00142

取引方法．契約条件

任意

コック区分

準必須

コック区分

任意

支給区分

準必須

材支

任意

直納区分

準必須

契約条件区分

任意

納入指示有無区分

任意

通貨コード

任意

直納区分

任意

契約条件区分

X(1)

0/1

オーダ区分

任意

納入指示有無区分X(1)

取引方法．通貨

0/1

■

X(3)

取引物品

0/1

通貨

任意

発注者品名コード

必須

品番

任意

製造番号

準必須

細品番

任意

品目コード

任意

1

発注者品名コード

X(25)

1

製造番号

X(19)

0/1

33 00023

受注者品名コード

X(25)

0/1

34 00022

品名（品名仕様）

X(30)

0/1

35 00262

品名（品名仕様）（漢字）

K(60)

0/1

36 00021

版数

X(3)

0/1

版数

準必須

版数

任意

版数

任意

37 00019

材料・規格・寸法

X(20)

0/1

材質・規格・寸法

準必須

材質・規格・寸法

任意

規格

準必須

38 00261

材料・規格・寸法（漢字）

X(40)

0/1

39 00177

戦略物資区分X(1)0/1

戦略物資区分

任意

40 00178

原産地コードX(3)0-5

原産地コード任意

原産地コード任意

41 00346

取扱形態区分X(1)0/1

見積依頼時発注者品名コード

X(25)

0/1

●

取引物品．説明．仕様詳細

部品番号

品名

必須

必須
準必須

発注者側品名コード

任意

受注者部品番号

受注者品名コード

任意

受注者側品名コード

部品名称

品名（品名仕様）

必須

品名（カナ）

任意

品名(品名仕様)

必須

品名

任意

品名漢字

任意

品名（漢字）

任意

品名(品名仕様)(漢字)任意

品名（仕様）

任意

単価区分

必須

任意

0/1

発注品仕様

X(120)

0/1

発注品仕様

任意

仕様書No.

任意

45 00278

発注品仕様（漢字）K(240)

0/1

表示形名

任意

購買発注テキスト任意

46 C00145

取引物品．説明．適用先

機種コード

任意

機種名

準必須

検査区分

準必須

検査区分

準必須

図番・規格

任意

検査成績書要否

任意

/単価区分

任意

0/1

47 00171

機種コード

X(20)

0/1

48 00277

機種名（漢字）

K(40)

0/1

49 00188

工事件名

X(40)

0/1

50 00280

工事件名（漢字）

K(80)

0/1

X(3)

0/1

52 00029
53 C00148
54 00172
55 C00149

取引物品．説明．検査区分

0/1

検査区分
取引物品．説明．設計変更区分

0/1

設計変更番号X(12)0/1

取引物品．説明．仕様書

0/1

56 00020

仕様書有無

X(1)

0/1

仕様書有無

準必須

57 00025

図面・仕様書枚数

9(2)

0/1

図面・仕様書枚数

任意

図面・仕様書番号

X(30)

0/1

図面番号

任意

要求書部数

任意

成績表要不要任意指定ﾒｰｶ名任意

エンドユーザー名

任意

需要先企業名任意

58 00173
59 C00150

ビジネスドキュメント本体明細部（注文情報）

品名コード
製造番号

44 00183

51 C00147

取引物品．説明．要求書類
要求書種類

X(1)

0/1

61 00175

要求書部数

9(2)

0/1

62 00176

要求書言語

X(1)

0/1

63 C00151

取引物品．説明．試験成績書

64 00192

試験成績書要否区分

X(1)

0/1

65 00193

試験成績書検査区分

X(1)

0/1

66 00194

試験成績書提出方法

X(1)

0/1

67 C00152

取引物品．説明．指定メーカ

0/1

指定メーカ名X(20)0/1

69 00273

指定メーカ名（漢字）

K(40)

0/1

取引物品．説明．エンドユーザ
エンドユーザ名

X(20)

0/1

72 00269

エンドユーザ名（漢字）

K(40)

0/1

73 00155

エンドユーザ品名

X(30)

0/1

74 00156

エンドユーザ品名コード

X(25)

0/1

75 00272

エンドユーザ品名（漢字）

K(60)

0/1

76 00157

エンドユーザ注文番号

X(23)

0/1

取引物品．契約単価．取決め状況
単価区分

メーカー名

任意

0/1

71 00151

78 00014

任意

0/1

68 00158

77 C00155

仕様書有無

0-4

60 00174

70 C00153

任意0/1

32 00008

43 C00144

任意

直納区分

0/1

31 00024

42 00351

支給区分

0/1

取引方法．納入指示有無

通貨コード

取引区分

需要家名称

任意

需要家注文番号

任意

エンドユーザ注文番号

任意

単価区分

任意

単価区分

必須

1
●

X(1)

1

2 / 5 ページ

79 C00158

取引物品．契約単価（注文）180 00013

単価●

9(10)V(3)

1

販売単価

必須

81 00282

単価（外貨）■

9(11)V(5)

0/1

単価単位

任意

82 C00159

取引物品．契約単価．主材料ベース
主材料コードX(2)0/1

84 00190

主材料ベース9(10)V(3)0/1

85 00191

主材料単価

X(3)

0/1

9(11)V(5)

0/1

X(3)

1

主材料単価（外貨）87 C00160

取引物品．取扱い単位

☆

単価

単価

必須

単価（外貨）

任意

主材料ﾍﾞｰｽ

任意

材料識別コード

数量単位

単位

必須

89 00026

荷姿（包装単位）

X(7)

0/1

荷姿

補完

荷姿コード

荷姿（包装単位）任意

90 00348

包装単位数量9(9)V(3)

0/1

容量

任意

収容数

91 00093

最低発注数量9(9)V(3)0/1

9(9)V(3)

1

注文数量

必須

注文数量

必須

94 C00165

条長

96 00186

条長個数98 00187
99 C00167

員数単位

注文数

条長

任意

0/1

条長個数

任意

X(3)

0/1

X(8)

1

受渡場所

必須

受渡場所名

準必須

納入場所

準必須

受渡場所名

X(20)

0/1

102 00274

受渡場所名（漢字）

K(40)

0/1

103 00152

納入先郵便番号

X(8)

0/1

郵便番号

任意

104 00153

納入先住所

X(100)

0/1

受渡場所住所任意

105 00270

納入先住所（漢字）K(100)

0/1

106 00154

納入先宛先名X(100)

0/1

107 00271

納入先宛先名（漢字）K(100)

0/1

108 00195

市町村コードX(7)0/1

109 00196

納入時連絡先

X(18)

0/1

●

納入条件．納期（注文）納入場所名称

納入先名称

地区コード

納入場所

必須

納入先住所

任意

納入先住所1

任意受け渡し場所 電話番号

任意

納入№

任意

0

114 00032

納入指示数量9(9)V(3)0/1

115 00179

納入時刻

X(4)

0/1

116 00159

納品キー番号X(23)0/1

117 00435

旧納品キー番号X(23)0

118 00436

代納理由区分X(1)●納入条件．発注者納品書情報

120 00161

発注者バーコード情報

X(23)

0/1

121 00162

発注者用備考X(50)0/1

122 00275

発注者用備考（漢字）K(100)

0/1

123 00257

納品書価格表示区分

X(1)

0/1

124 C00180

金額計算条件．諸条件
X(1)

0/1

126 00059

課税区分

X(1)

0/1

127 00169

数量契約区分

X(1)

0/1

X(1)

0/1

注文金額

135 00283

注文金額（外貨）136 00060

消費税額

137 00287

消費税額（外貨）138 00061

合計額

139 00288

合計額（外貨）140 C00207

汎用．自由使用欄

141 00055

自由使用欄

発注納期

☆

希望納入時刻任意

納入指定時分

☆

納入指示日／時刻

納入指定日

任意

納入指示数

任意

シーケンスＮｏ．

任意

必須

納期

必須

任意

納入指示合計数

納入指示数量

必須

納入指示数

必須

納入指示数

納入指示日／時刻

納入時刻

任意

納入時刻

準必須

納入時刻

任意

納品ｷｰ番号

準必須

納品キー番号

準必須

納品キー番号

任意

発注コメント カナ

発注者用バーコード情報

準必須

発注者バーコード情報

任意

発注者バーコード情報

任意

発注者用備考準必須
発注者用備考（漢字）任意

納品書価格表示区分

任意

消費税区分

準必須

消費税区分

任意

消費税区分

任意

課税区分

準必須

課税区分

任意

課税区分

任意

決済条件区分

準必須

支払条件区分

任意

決済条件区分

任意

注文金額

必須

注文金額

任意

注文金額

任意

消費税額

準必須

消費税額

任意

消費税額

任意

合計額

準必須

合計額

任意

合計額

任意

自由欄

準必須

自由使用欄１

任意

自由使用欄

準必須

備考

準必須

備考１

任意

備考

必須

備考

任意

備考（漢字）

任意

任意

0/1

消費税区分

134 00016

必須

任意

納期

0/1

125 00057

予約金額（外貨）希望納入年月日

納入No.

0119 C00178

予約金額

任意

任意

X(8)

133 00289

受け渡し場所 郵便番号

納入先FAX番号

納入指定日

132 00071

準必須

1-31

必須

見積金額(外貨）

納入先

任意

任意

見積金額

任意

任意

納期

131 18090

任意受け渡し場所 住所

任意

納入No

130 18089

納入場所（漢字）

必須

納入先宛先名1

決済条件区分

必須

注文数量

納入先企業名0/1

金額計算条件．金額

注文数量

任意

納入先

X(8)

129 C00181

必須

準必須
任意

注文数（受注数）

納入先名称

X(8)

128 00082

単位

数量単位
荷姿

1

101 00160

113 18108

☆

0/1

受渡場所

納期

必須

0/1

条長単位

納入Ｎｏ．

発注員数

9(4)

納入条件．納入場所

112 18104☆

9(9)V(3)

取引物品．契約数量．条長単位

111 00034

単価

0-10

100 00028

110 C00173

任意

必須

1
●

取引物品．契約数量．条長

95 00185

97 C0166●

取引物品．契約数量（注文）
注文数量

単位

単価

1

単位

93 00015

任意☆

88 00012

92 C00164

単価

0/1

83 00189

86 00301

契約単価

▲

課税区分

任意

決済条件

☆

1
9(10)

0

9(12)V(3)

0

9(10)

0

9(12)V(3)

0

9(10)

1

9(12)V(3)

0/1

9(10)

0/1

9(12)V(3)

0/1

9(10)

0/1

9(12)V(3)0/1

X(100)

0/1

消費税金額

☆

注文金額

必須

0/1

142 C00208

汎用．備考

143 00056

備考

X(30)

0/1

144 00263

備考（漢字）

K(60)

0/1

自由使用欄

☆

0/1
予備欄

任意

注） No. Cnnnnn:クラスNo.，nnnnn:項目No.

3 / 5 ページ

必須：(2)マッピング不可能項目
ｷｰ・必
項目名称
須・任
意
支払者企業コード
必須■：任意項目。但し国内での外貨取引の場合に限り必須項目。

支払者部門コード

必須▲：任意項目。但し下請取引では必須項目。

契約番号9：0から9までの数字だけで構成される数値項目。

鉄鋼メーカーコード

ｷｰ・
必須・
任意
☆

発行日／時刻

注文年月日

状態

号ロ、号機

商社コード

☆

対象基準日

合計納入数量

次区

工場区分

必須

需要家コード☆

確定注文対象期間

見積回答番号変更情報（旧情報番号）

登録年月日

発注者・注文時刻

任意

需要家3/最終需要家☆

オリジナルデータ作成日／時刻

明細番号

部品番号（変番)

品番

X：英数字，カナ，特殊文字等で構成される文字列項目。

連絡要否区分

任意

部品メーカーコード☆

中継地到着日／時刻

発注者側メーカーコード

工順

組立工程

K：漢字等全角文字で構成される文字列項目。

0-N：出現しないか，最大N回まで。

数量指定区分
品名グループ
ロット番号指定区分
ロット番号

任意
任意
任意
任意

受渡場所コード
鋼材加工業者コード
受入部署コード
発注者管理番号☆
☆
☆
☆

中継地出発日／時刻
先行時間
オフライン日／時刻
検査完了期日

受注者側メーカーコード
受け渡し方法受け渡し場所 FAX
自由使用欄２

指定メーカー名
国産輸入区分
単価単位数量品目グループ

工場コード（納入先工場）
集計区分
ステーションＮｏ．
ユニットＮｏ．

1-N：1回から，最大N回まで。

需要家企業コード補完

鋼材加工業者受付番号 ☆

設計変更切替日

明細備考

リビジョンNo.

Ｉ−ＡＳＳＹ

0：出現しない。実際の取引上のメッセージでは使用しない項目。

需要家部門コード補完

鋼材加工業者管理番号 ☆

打切日

受け渡し時刻

C/D

一貫番号●：ビジネスドキュメントにおける必須のデータ項目であることを示す。
但し国内での外貨取引の場合は任意項目。

値の型：

出現回数： 1：1回出現する。必須。
0/1：出現しないか，1回か。

BIE合計項目数

・ドキュメント本体共通部

23個

・ドキュメント本体明細部（注文情報）

112個

項目名称

項目名称

項目名称

ｷｰ・
必須・
任意

項目名称

ｷｰ・
必須・
任意

項目名称

ｷｰ・
必須・
任意

項目名称

2次店企業コード任意

プロジェクト番号☆

得意先納入日／時刻

明細合計

T/R

単材料費

2次店部門コード

任意

ライン番号

☆

納入指示対象期間内指示単位

調整金額

TSQS-No.

単加工費

調整後合計金額

2次店名称

任意

納入指示番号☆

納入指示対象期間

円外貨区分

出庫先

3次店企業コード

任意納入指示番号行番☆

納入指示対象期間範囲

工程

単価契約区分

3次店部門コード

任意

契約規格・鋼種☆

支払条件設定日

作業テキスト

ＣＤ

3次店名称

任意

ミリメートル寸法・厚1△

単価適用日付

組付外注発注品番

数量確定区分

任意

ミリメートル寸法・厚2△

生産日コード組付外注コード

口銭区分

任意

ミリメートル寸法・幅1△

納入日コード

合計時間

口銭単価

任意

ミリメートル寸法・幅2

△

仕入先

管理区分

2次店口銭区分

任意

ミリメートル寸法・長1

△

仕入先名称

外貨区分

2次店口銭単価

任意

ミリメートル寸法・長2△

出荷元

納品書発行区分

納入先企業コード

必須

質量単位

☆

出荷元名称

倉庫区分

納入先部門コード

必須

発注量（質量）☆

親発注者

形態（漢字）

受渡条件

任意

単価単位

☆

親発注者名称

工程順序１

納入先電話番号

任意

加工区分

☆

下請法対象メーカー識別

工程符号１

納入先FAX電話番号 任意

受渡条件コード☆

トラックヤード

工程順序２

希望納入コメント

任意

直納区分

☆

中継地

工程符号２

納入要件

任意

費用項目区分

☆

中継地名称

受注者確認

注文・販売個数補完

出荷場所

ダウンロード日時

注文数量単位任意

検査場所

ダウンロードＩＤ

割増割引区分任意

先行時間基準工程

ロットNo.

割増割引理由任意

得意先部品番号

日程

輸送手段

任意

部品色

数量

輸送車種

任意

設計変更情報

発注者情報

任意

発注者品名識別

受注者情報

必須

受注者部品名称

国内輸出区分

任意重点管理部品重要保安部品コード
背番号
差替情報
部品加工状態区分
防錆区分
現用／旧型区分
部品識別
材料手配区分
国内輸出区分
内外区分
初物区分
打切区分
検査区分
有償／無償識別
梱包／包装レベル
梱包／包装作業分類
梱包／包装資材コード
梱包／包装関連情報
梱包／包装資材使用数
梱包／包装単位個数
梱包／包装指示区分
梱包／包装資材手配区分
手配担当
進捗担当
情報システム担当
検査担当
会計担当

4 / 5 ページ

ｷｰ・
必須・
任意

前回注文数
打切残数
かんばん枚数
納入指示発生件数
受信確認用件数
端数区分
納入ロット括り区分
生産変動予測数反映区分
支給品質上単価
単価状態区分
単価契約区分
処理番号
注文明細番号
前回発行番号
親注文番号
工事番号
輸出番号
輸送手段
輸送業者
便番号
輸送識別
通常／緊急／不定期区分
通常／緊急区分
緊急追走区分
内示発行区分確定期間指示区分
注文発生理由新規計画区分
納入方式
納入指示サイクル
納入サイクル
変更情報提供識別
変更個所
費用番号
予算番号
現品票サイズ
現品票仕様
文字反転フラグ
凡例（キー・必須・任意）

現品票カーメーカーエリア◎：キー

納品票カーメーカーエリア○：必須

かんばんカーメーカーエリア△：条件付必須

帳票発行指示区分☆：任意支払方法等文言

マッピング可能数

29個

25個

27個

77個

38個

52個

40個

マッピング不可能数

38個

29個

108個

0個

14個

16個

34個

マッピング総数

67個

54個

135個

77個

52個

68個

74個

マッピング可能数比率

43%

46%

20%

100%

73%

76%

54%

備考：
１．JPCA標準(1) 出典JPCA標準ビジネスプロトコル（XML版）（http://www.jpca.or.jp/7business/web.htm）（2004年11月）(2) データ項目の考察

・項目名称はECALGAに似ている。石油化学業界の購買部門がECALGAに馴染み易いと思われる。

３．JAMA・JAPIA-EDI(1) 出典JAMA・JAPIA取引情報標準書 V1.04 （2004年3月）（http://www.jama.or.jp/cgi-bin/download.cgi）(2) データ項目の考察

・項目名称は，ECALGAと相当異なる。

・企業コードを種々の登場者で使用している。

・日付・時刻，関与者，場所品名などデータ項目が細かく多い。

・マッピング不可能項目でも重要な項目がある。

・自動車部品専門用語，自動車部品売買ビジネスプロセス用語が多い。
・必須，任意などの識別がない。全ての項目が必須なのかも知れない。

２．鉄鋼EDI標準(1) 出典物・商流情報解説（要旨）（http://www.jisf.or.jp/steeledi/edistand/butsumsg.htm）（2004年11月）(2) EDI情報種と用途・確定注文情報 需要家⇔商社

54項目

・注文情報A

商社⇔鉄鋼メーカー

138項目

・注文情報B

需要家⇔商社

85項目(3) データ項目の考察

４．住宅産業標準

・項目名称は，ECALGAと相当異なる。
・コードが多い。
・鋼材取引用語が多い。

5 / 5 ページ

(1) 出典

住宅情報産業情報システムネットワーク 標準ビジネスプロトコル VER1.0 （1992年，財団法人住宅産業情報サービス）

付表4.2 中小製造業EDIメッセージモデル（注文情報）

ECALGA注文情報（BDS0210 Ver2003A-Rev01）（社）電子情報技術産業協会（JEITA）開発＃＃

No.
C00001

L1L2 L3L4L5L6 L7 L8 L9 L10L11 L12

必須

値の型

出現回数

機械業界の
共通データ項目

中小製造業の共通データ項目

中小製造業EDI
メッセージモデル

項目名称（画面）

項目名称

項目名称

標準メッセージ項目

1

BDデータ作成日時

18040

BDデータタイムゾーン

X(10)

0/1

18041

BDデータ作成日

●

X(8)

1

18042

BDデータ作成時刻

●

X(6)

1

C00002

電機・電子業界の共通デー
タ項目

送信者

△

◎

必須

◎

必須

1

18014

送信者コード

●

X(20)

1

◎

必須

18015

送信者コード管理組織

●

X(10)

1

◎

必須

18016

送信者所属プロバイダコード

X(20)

0/1

送信者センタコード

X(20)

0/1

18017
C00003

受信者

1

ビジネスドキュメントヘッダ

18018

受信者コード

●

X(20)

1

◎

必須

18019

受信者コード管理組織

●

X(10)

1

◎

必須

18020

受信者所属プロバイダコード

X(20)

0/1

18021

受信者センタコード

X(20)

0/1

C00004

ビジネスドキュメントの識別

1

18035

ビジネスドキュメントの標準

●

X(5)

1

◎

必須

18001

ビジネスドキュメントのバージョン

●

X(14)

1

◎

必須

18009

ビジネスドキュメントID

●

X(7)

1

◎

必須

C00005

ビジネスサービス条件

1

18002

コンプレックスビジネスコラボレーションID

●

X(8)

1

◎

必須

18003

ビジネスコラボレーションID

●

X(7)

1

◎

必須

18005

ビジネストランザクションID

●

X(7)

1

18007

ビジネスアクションID

●

X(8)

1

TPA番号

●

X(34)

18010
C00006

ビジネスコラボレイション制御

1

カンバセイションID

X(64)

0/1

18036

BC回答期限日

X(8)

0/1

18037

BC回答期限時刻

X(6)

0/1

18038

BC制御意味コード

X(1)

0/1

18039

BC制御理由コード

X(1)

0/1

X(1)

1

X(10)

0/1

運用モード

18004

テスト本番区分1 C00008

データ順序と属性

◎

必須

◎

◎

必須

△

◎

必須

1
1

2

18011

タイムゾーン3

18012

データ作成日

●

X(8)

1

4

18013

データ作成時刻

●

X(6)

1

5

00001

データ処理No.

●

X(5)

6

00009

訂正コード

●

X(1)

7 C00009

◎

1

18008

C00007◎

発注者

ビジネスドキュメント本体共通部

○

◎

○

○

準必須

1

○

◎

○

○

準必須

1

○

◎

△

○

準必須

◎

◎

△

◎

必須

◎

○

準必須

1

8

00004

発注者コード

●

X(20)

1

9

18022

発注者コード管理組織

●

X(10)

1

10

18023

発注者企業名

K(40)

0/1

11

18024

発注者企業の国コード

X(10)

0/1

12

00006

発注部門コード

X(8)

0/1

○

○

○

○

準必須

13

00184

発注部門名

X(20)

0/1

△

○

△

△

任意

14

00279

発注部門名（漢字）

K(40)

0/1

15

00018

購買担当

X(7)

0/1

◎

○

◎

◎

必須

16

00260

購買担当（漢字）

K(14)

0/1

△

○

○

△

任意

◎

◎

◎

◎

必須

◎

○

準必須

△

任意

17 C00010

受注者

1

18

00005

受注者コード

●

X(20)

1

19

18027

受注者コード管理組織

●

X(10)

1

20

18028

受注者企業名

K(40)

0/1

21

18029

受注者企業の国コード

X(10)

0/1

22

18031

受注部門コード

X(8)

0/1

23

18033

受注部門名

X(20)

0/1

24

18034

受注部門名（漢字）

K(40)

0/1

25

00092

営業担当

X(7)

0/1

△

1 / 4 ページ

26

00264

営業担当（漢字）

K(14)

0/1

1 C00108

注文ＢＤ情報2 00007

注文番号

●

X(23)

1

3 18103

注文日

●

X(8)

1

○

△

△

任意

◎

◎

◎

◎

必須

◎

◎

◎

◎

必須

○

△

任意

1

4 C00109

注文ＢＤ情報．詳細

5 00167

発注形態区分

X(2)

0/1

△

6 00170

変更注文区分

X(2)

0-3

○

7 00168

親注文番号

X(23)

0/1

△

8 00180

一括納入番号

X(10)

0/1

00072

見積依頼番号X(23)0/1

10 00068

予約番号

X(23)

0/1

11 18151

注文請け返信期限

X(8)

0/1

12 00430

返品代納区分X(1)0/1

9(9)V(3)0/1

9

13 C00110

0/1

注文ＢＤ情報．変更前．数量単価
変更前注文数量

15 00425

変更前単価

9(10)V

0/1

16 00426

変更前単価（外貨）9(11)V(5)0/1

注文BD情報．変更前．納入

18 18091

変更前納期

19 00428

変更前納入指示数量

20 C00138

取引方法．ビジネスモデル

○

準必須

△

任意

△

△

任意

△

△

任意

△

○

準必須

△

○

準必須

○

準必須

△

△

任意

△

△

任意

△

△

任意
必須

△

0/1

14 00424

17 C00111

○

0-31
X(8)

0/1

9(9)V(3)0/1
0/1

21 00010

コック区分

X(1)

0/1

○

22 00017

支給区分

X(1)

0/1

○

○

23 00027

直納区分

X(1)

0/1

○

○

24 C00139
25 00166
26 C00140
27 00030
28 C00141
29 00281
30 C00142

取引方法．契約条件

0/1

契約条件区分X(1)

取引方法．納入指示有無

0/1

納入指示有無区分X(1)

取引方法．通貨
通貨コード

0/1
0/1
0/1

■

X(3)

取引物品

△

0/1
1

31 00024

発注者品名コード

X(25)

1

◎

○

◎

◎

32 00008

製造番号

X(19)

0/1

○

○

○

○

準必須

33 00023

受注者品名コード

X(25)

0/1

△

△

△

任意

34 00022

品名（品名仕様）

X(30)

0/1

◎

○

◎

◎

必須

35 00262

品名（品名仕様）（漢字）

K(60)

0/1

△

○

△

△

任意

36 00021

版数

X(3)

0/1

○

△

○

準必須

37 00019

材料・規格・寸法

X(20)

0/1

○

○

○

準必須

38 00261

材料・規格・寸法（漢字）

X(40)

0/1

39 00177

戦略物資区分

X(1)

0/1

△

△

任意

40 00178

原産地コード

X(3)

0-5

△

△

任意

41 00346

取扱形態区分X(1)0/1

見積依頼時発注者品名コード

X(25)

0/1

42 00351
43 C00144●

取引物品．説明．仕様詳細△

0/1

44 00183

発注品仕様

X(120)

0/1

△

△

△

任意

45 00278

発注品仕様（漢字）K(240)

0/1

△

△

△

任意

46 C00145

取引物品．説明．適用先

△

○

△

任意

○

○

○

準必須

0/1

47 00171

機種コード

X(20)

0/1

48 00277

機種名（漢字）

K(40)

0/1

49 00188

工事件名

X(40)

0/1

50 00280

工事件名（漢字）

K(80)

0/1

X(3)

0/1

51 C00147
52 00029
53 C00148
54 00172
55 C00149

取引物品．説明．検査区分
検査区分

0/1

取引物品．説明．設計変更区分
設計変更番号

0/1
X(12)

0/1

取引物品．説明．仕様書

0/1

56 00020

仕様書有無

X(1)

0/1

○

○

準必須

57 00025

図面・仕様書枚数

9(2)

0/1

△

△

任意

図面・仕様書番号

X(30)

0/1

△

△

任意

△

任意

△

任意

58 00173
59 C00150

取引物品．説明．要求書類

60 00174

要求書種類

X(1)

0/1

61 00175

要求書部数

9(2)

0/1

62 00176

要求書言語

X(1)

0/1

X(1)

0/1

63 C00151

取引物品．説明．試験成績書

64 00192

試験成績書要否区分

△

0-4
△

0/1
△

2 / 4 ページ△

ビジネスドキュメント本体明細部（注文情報）

65 00193

試験成績書検査区分

X(1)

0/1

66 00194

試験成績書提出方法

X(1)

0/1

67 C00152

取引物品．説明．指定メーカ

0/1

68 00158

指定メーカ名X(20)0/1

69 00273

指定メーカ名（漢字）

K(40)

0/1

70 C00153

取引物品．説明．エンドユーザ

△

△

任意

0/1

71 00151

エンドユーザ名

X(20)

0/1

△

△

任意

72 00269

エンドユーザ名（漢字）

K(40)

0/1

△

△

任意

73 00155

エンドユーザ品名

X(30)

0/1

74 00156

エンドユーザ品名コード

X(25)

0/1

75 00272

エンドユーザ品名（漢字）

K(60)

0/1

76 00157

エンドユーザ注文番号

X(23)

0/1

△

△

任意

◎

必須

77 C00155
78 00014
79 C00158

取引物品．契約単価．取決め状況
単価区分

1
●

X(1)

取引物品．契約単価（注文）

1

◎

◎

△

◎

◎

1

80 00013

単価●

9(10)V(3)

1

◎

◎

必須

81 00282

単価（外貨）■

9(11)V(5)

0/1

△

△

任意

△

△

任意

○

◎

必須

△

△

任意

◎

◎

必須

82 C00159

取引物品．契約単価．主材料ベース

0/1

83 00189

主材料コードX(2)0/1

84 00190

主材料ベース9(10)V(3)0/1

85 00191

主材料単価

X(3)

0/1

9(11)V(5)

0/1

X(3)

1

◎
△

86 00301

主材料単価（外貨）87 C00160

取引物品．取扱い単位

188 00012

単位

89 00026

荷姿（包装単位）

X(7)

0/1

90 00348

包装単位数量9(9)V(3)0/1

最低発注数量9(9)V(3)0/1

9(9)V(3)1

91 00093
92 C00164
93 00015
94 C00165

取引物品．契約数量（注文）注文数量
条長

96 00186

条長個数98 00187
99 C00167◎

1●

取引物品．契約数量．条長

95 00185

97 C0166

●

◎

◎

0-10
9(9)V(3)

0/1

△

△

任意

9(4)

0/1

△

△

任意

取引物品．契約数量．条長単位

0/1

条長単位

X(3)

0/1

X(8)

1

◎

納入条件．納入場所

1

100 00028

受渡場所

101 00160

受渡場所名

X(20)

0/1

○

102 00274

受渡場所名（漢字）

K(40)

0/1

○

103 00152

納入先郵便番号X(8)0/1

104 00153

納入先住所

X(100)

0/1

△

△

任意

105 00270

納入先住所（漢字）K(100)

0/1

△

△

任意

106 00154

納入先宛先名X(100)

0/1

△

△

任意

107 00271

納入先宛先名（漢字）K(100)

0/1

△

△

任意

108 00195

市町村コードX(7)0/1

109 00196

納入時連絡先

X(18)

0/1

△

△

任意

110 C00173●

納入条件．納期（注文）111 00034

納入Ｎｏ．

112 18104

納期

113 18108

○
○

◎

必須

○

準必須

○

準必須

1-31
X(8)

0/1

△

○

△

△

任意

X(8)

1

◎

◎

◎

◎

必須

納入指定日

X(8)

0

114 00032

納入指示数量9(9)V(3)

0/1

◎

○

◎

◎

必須

115 00179

納入時刻

X(4)

0/1

△

○

○

△

任意

116 00159

納品キー番号

X(23)

0/1

○

○

○

○

準必須

117 00435

旧納品キー番号X(23)0

118 00436

代納理由区分

X(1)

○

△

●

0

119 C00178

納入条件．発注者納品書情報

120 00161

発注者バーコード情報

X(23)

0/1

○

121 00162

発注者用備考

X(50)

0/1

○

122 00275

発注者用備考（漢字）K(100)

0/1

123 00257

納品書価格表示区分

X(1)

0/1

124 C00180

金額計算条件．諸条件

0/1

○
△

○

準必須

○

準必須

△

任意

△

任意

0/1

125 00057

消費税区分

X(1)

0/1

○

○

○

準必須

126 00059

課税区分

X(1)

0/1

○

○

○

準必須

127 00169

数量契約区分

X(1)

0/1

X(1)

0/1

○

○

○

準必須

128 00082

決済条件区分

129 C00181

金額計算条件．金額▲

1

3 / 4 ページ

130 18089

見積金額

131 18090

見積金額(外貨）132 00071

予約金額

133 00289

予約金額（外貨）134 00016

注文金額

135 00283

注文金額（外貨）136 00060

消費税額

137 00287

消費税額（外貨）138 00061

合計額

139 00288

合計額（外貨）140 C00207

汎用．自由使用欄

141 00055

自由使用欄

9(10)

0

9(12)V(3)

0

9(10)

0

9(12)V(3)

0

9(10)

1

9(12)V(3)

0/1

9(10)

0/1

9(12)V(3)

0/1

9(10)

0/1

9(12)V(3)0/1

X(100)

0/1

◎

○

○
○

◎

◎

必須

○

○

準必須

○

○

準必須

○

○

準必須

◎

○

準必須

△

任意

0/1

142 C00208

汎用．備考

143 00056

備考

X(30)

0/1

144 00263

備考（漢字）

K(60)

0/1

○

0/1
○

○
○

注） No. Cnnnnn:クラスNo.，nnnnn:項目No.

データ項目数

◎

16個

13個

15個

14個

必須

・ドキュメントヘッダ

25個

○

25個

27個

14個

15個

必須

・ドキュメント本体共通部

23個

△

37個

0個

23個

27個

準必須

・ドキュメント本体明細部（注文情報）

112個

合計

78個

40個

52個

41個

任意

・ドキュメント本体合計

135個

・データ項目数合計

160個

4 / 4 ページ

14個
42個
41個

14個

ﾋﾞｼﾞﾈｽﾄﾞｷｭﾒ
ﾝﾄﾍｯﾀﾞ

83個

ﾋﾞｼﾞﾈｽﾄﾞｷｭﾒ
ﾝﾄ本体

付表4.3 Web-EDIで利用されているEDI標準メッセージ種電機・電子業界
機械業界
中小製造業
情報区
JEITA調査
ECOM調査分コー
業務単位 情報種（EIAJ標準）実績
実績（2003年3月）（2004年7月〜10月） 実績
A社 B社
A社 B社
ド
豊富
豊富
A B C D E F G H I J K P Q R S T U 豊富社 社 社 社 社 社 社 社 社 社 社 社 社 社 社 社 社
購入仕様情報
0101○
仕様提示
納入仕様情報
0102○
所要計画情報0201○ ○ ○○ ○ ○ ○
○ ○○ ○ ○ ○ ○○ ○計画
コック引当計画情報0202○
見積依頼情報
0301
○ ○ ○
○
○ ○
○ ○ ○ ○ ○
○
○ ○
○
見積
見積回答情報
0302
○ ○ ○
○
○ ○
○ ○ ○ ○ ○○○ ○○見積採否通知情報
0303
○ ○
○
○
支給予定情報0401○○
支給実績情報0402○○○
支給品受領情報0403○
支給品検収情報0404○
支給品在庫通知情報0405○
支給品請求情報0406○
支給支給品返品情報0407○
支給品返品検収情報
0408○○
支給品在庫補充依頼情報0409
支給先在庫通知情報0410○
支給品売掛明細情報0412○
支給品照合確認情報
0413○
予約注文情報
0203
○ ○
○
○
○
○ ○
予約注文請け情報
0204○
内示注文情報0501○○○
確定注文情報0502○ ○ ○ ○ ○ ○ ○ ○○ ○ ○ ○ ○○ ○ ○○ ○ ○ ○ ○ ○注文
変更注文情報0503○ ○○ ○ ○ ○ ○○○○注文取消情報
0504
○ ○
○ ○
○
○
○
○
○
注文打切情報
0505
○ ○
○ ○
○
○
○
注文請け情報
0506
○
○
○
○ ○ ○
○
○
予約注文残高確認情報 0603○
契約状況
注文残高確認情報
0601
○
○
○
確認
単価確認情報0602○○
納期確認情報
0701
○
○ ○
○ ○ ○
○ ○ ○ ○ ○納期回答情報0702○ ○ ○ ○ ○ ○ ○ ○○ ○○ ○ ○ ○ ○○○納入
納入指示情報
0703
○
○ ○
○
○
○ ○ ○
出荷情報
0704
○ ○ ○ ○ ○○ ○○ ○ ○○ ○ ○ ○
入荷情報
0705
○
○ ○
○ ○ ○ ○ ○ ○ ○
○ ○
検査情報
0801
○
○
○
○ ○
○ ○
○ ○
検査
検収情報
0901
○ ○
○ ○ ○ ○○ ○ ○○ ○ ○ ○ ○○ ○ ○検収前返品情報
1002○
検収後返品情報
1001○○
返品
返品受領情報1003○○
返品受諾情報1004○
代納指示情報1005○
買掛明細情報1101○ ○○○○ ○ ○ ○ ○ ○ ○ ○○売掛明細情報1102○○
照合確認情報
1103
○
請求情報
1104
○
支払
相殺内容通知情報1105○○
検収支払情報1106○○○
請求支払情報1107○
合計支払情報1108○ ○○手形・小切手等明細情報 1109○
搬入推進情報
取入指示書
バルク注文書 単価決定通知情
その他
購買品単価申込 資材支払情報
資材支払情報付録５ 中小製造業EDIメッセージモデル／UBLマッピング
付表5.1 中小製造業EDIメッセージモデルのUBLマッピング表（注文情報）
ECALGA注文情報（BDS0210 Ver2003A-Rev01）（社）電子情報技術産業協会（JEITA）開発＃＃

No.
C00001

L1L2 L3L4L5L6 L7 L8 L9 L10L11 L12

必須

値の型

出現回数

X(10)

0/1

サブセット項目

BDデータタイムゾーン

18041

BDデータ作成日

●

X(8)

1

◎

必須

18042

BDデータ作成時刻

●

X(6)

1

◎

必須

送信者
送信者コード

●

X(20)

1

◎

必須

18015

送信者コード管理組織

●

X(10)

1

◎

必須

18016

送信者所属プロバイダコード

X(20)

0/1

18017

送信者センタコード

X(20)

0/1

受信者

ビジネスドキュメントヘッダ

受信者コード

●

X(20)

1

◎

必須

18019

受信者コード管理組織

●

X(10)

1

◎

必須

18020

受信者所属プロバイダコード

X(20)

0/1

18021

受信者センタコード

X(20)

0/1

C00004

ビジネスドキュメントの識別
ビジネスドキュメントの標準

●

X(5)

1

◎

必須

18001

ビジネスドキュメントのバージョン

●

X(14)

1

◎

必須

ビジネスドキュメントID

●

X(7)

1

◎

必須

ビジネスサービス条件
コンプレックスビジネスコラボレーションID

●

X(8)

1

◎

必須

18003

ビジネスコラボレーションID

●

X(7)

1

◎

必須

18005

ビジネストランザクションID

●

X(7)

1

◎

必須

18007

ビジネスアクションID

●

X(8)

1

◎

必須

18010

TPA番号

●

X(34)

1

◎

必須

○

準必須

ビジネスコラボレイション制御
カンバセイションID

X(64)

0/1

18036

BC回答期限日

X(8)

0/1

18037

BC回答期限時刻

X(6)

0/1

18038

BC制御意味コード

X(1)

0/1

18039

BC制御理由コード

X(1)

0/1

X(1)

1

X(10)

0/1

運用モード

18004

テスト本番区分1 C00008

データ順序と属性

Order. Globally Unique_
Identifier
Identifier. Identifier

1

18008

C00007

GUID

1

18002

C00006

GUID

1

18035

18009

Dictionary Entry Name

1

18018

C00005

UBL Name（BIE又はCCT）

1

18014

C00003Compo
Represent Cardi
日本語（UBL
nent
ation Term nality
JPLSC）
Type

BIE

1

BDデータ作成日時

18040

C00002

UBLマッピング表

中小製造業EDI
メッセージモデル

1
1

2

18011

タイムゾーン3

18012

データ作成日

●

X(8)

1

4

18013

データ作成時刻

●

X(6)

1

5

00001

データ処理No.

●

X(5)

1

○

準必須

6

00009

訂正コード

●

X(1)

1

○

準必須

◎

必須

Buyer Party，Party，PartyIdentification, ID

ID

Party Identification.
Identifier

Identifier○

準必須

Buyer Party，Party，PartyName, Name

Name

Party Name. Name

Name

○

準必須

Buyer Party，Party，Contact,
ID
ID

Contact. Identifier△

任意Buyer Party，Party，Address,
Department
Department

◎

必須

△

任意

◎

必須

Seller Party，Party，PartyIdentification, ID○

準必須

Seller Party，Party，PartyName, Name

7 C00009

発注者

ビジネスドキュメント本体共通部

00004

発注者コード

●

X(20)

1

9

18022

発注者コード管理組織

●

X(10)

1

10

18023

発注者企業名

K(40)

0/1

11

18024

発注者企業の国コード

X(10)

0/1

12

00006

発注部門コード

X(8)

0/1

13

00184

発注部門名

X(20)

0/1

14

00279

発注部門名（漢字）

K(40)

0/1

15

00018

購買担当

X(7)

0/1

00260

17 C00010

BBIE

メッセージID

1 BBIE

取引当事者ID

1..n

BBIE

取引当事者名Identifier

0..1

BBIE

担当者ID

Address. Department.
Text

Text

0..1

BBIE

部署

Buyer Party，Party，Contact,
Name
Name

Contact. Name

Name

0..1

BBIE

担当者名

Buyer Party，Party，Contact,
Name
※
Name

Contact. Name

Name

0..1

BBIE

担当者名

ID

Party Identification.
Identifier

Identifier

NameParty Name. Name

Name

0..1

※

1

8

16

※

購買担当（漢字）

K(14)

受注者

0/1
1

18

00005

受注者コード

●

X(20)

1

19

18027

受注者コード管理組織

●

X(10)

1

20

18028

受注者企業名K(40)0/1

1 / 4 ページ

1..n

1 BBIE

取引当事者ID

BBIE

取引当事者名21

18029

受注者企業の国コード

X(10)

0/1

22

18031

受注部門コード

X(8)

0/1

23

18033

受注部門名

X(20)

0/1

24

18034

受注部門名（漢字）

K(40)

0/1

25

00092

営業担当

X(7)

0/1

26

00264

営業担当（漢字）

K(14)

0/1

△

任意

△

任意

※

Seller Party，Party，Contact,
ID
ID

Contact. Identifier

Identifier

0..1

BBIE

担当者ID

Seller Party，Party，Contact,
Name
Name

Contact. Name

Name

0..1

BBIE

担当者名

Identifier

0..1

BBIE

発注番号

1 BBIE

発注日

1 C00108

注文ＢＤ情報2 00007

注文番号

●

X(23)

1

◎

必須

BuyersID

BuyersID

Order. Buyers_
Identifier. Identifier

3 18103

注文日

●

X(8)

1

◎

必須

IssueDate

IssueDate

Order. Issue Date. Date Date1

4 C00109

注文ＢＤ情報．詳細

5 00167

発注形態区分

X(2)

0/1

△

任意

6 00170

変更注文区分

X(2)

0-3

○

準必須

※

7 00168

親注文番号

X(23)

0/1

△

任意

※

8 00180

一括納入番号

X(10)

0/1

00072

見積依頼番号X(23)0/1

10 00068

予約番号

X(23)

0/1

△

任意

※

11 18151

注文請け返信期限

X(8)

0/1

△

任意

※

12 00430

返品代納区分X(1)0/1

9(9)V(3)0/1

9

13 C00110

0/1

注文ＢＤ情報．変更前．数量単価

0/1

14 00424

変更前注文数量

15 00425

変更前単価

9(10)V

0/1

16 00426

変更前単価（外貨）9(11)V(5)0/1

17 C00111

注文BD情報．変更前．納入

18 18091

変更前納期

19 00428

変更前納入指示数量

20 C00138

取引方法．ビジネスモデル

※

0-31
X(8)

0/1

9(9)V(3)0/1
0/1

21 00010

コック区分

X(1)

0/1

○

準必須

※

22 00017

支給区分

X(1)

0/1

○

準必須

※

23 00027

直納区分

X(1)

0/1

○

準必須

※ DeliveryTerms, SpecialTerms SpecialTerms

Delivery Terms.
Special_ Terms. Text

Text

0..1

BBIE

納入条件特記
事項

X(1)

0/1

△

任意

※ SalesConditions, ID

Sales Conditions.
Identifier

Identifier

0..1

BBIE

販売条件ID

X(1)

0/1

△

任意

※

△

任意

PricingCurrencyCode

PricingCurrencyC Order. Pricing Currency.
Code
ode
Code

0..1

BBIE

通貨コード（価格表示用）

ID

24 C00139

取引方法．契約条件

25 00166

契約条件区分

26 C00140

取引方法．納入指示有無

27 00030

納入指示有無区分

28 C00141

取引方法．通貨

29 00281

通貨コード

30 C00142

0/1

0/1
0/1
■

X(3)

取引物品

0/1
1

X(25)

1

◎

必須

OrderLIne，LineItem，Item，
BuyerItemIdentification，
ItemIdentification, ID

製造番号

X(19)

0/1

○

準必須

33 00023

受注者品名コード

X(25)

0/1

△

任意

34 00022

品名（品名仕様）

X(30)

0/1

◎

必須

35 00262

品名（品名仕様）（漢字）

K(60)

0/1

△

36 00021

版数

X(3)

0/1

○

37 00019

材料・規格・寸法

X(20)

0/1

31 00024

発注者品名コード

32 00008●○

Item Identification.
Identifier

Identifier

OrderLIne，LineItem，Item,
LotNumberID
LotIdentification, LotNumberID

Lot Identification. Lot
Number. Identifier

Identifier

OrderLIne，LineItem，Item，
SellerItemIdentification，
ItemIdentification, ID

ID

Item Identification.
Identifier

Identifier※

OrderLIne，LineItem，Item,
Descripyion

Description

Item. Description. Text

Text

0..1

BBIE

商品説明（仕様）

任意※

OrderLIne，LineItem，Item,
Descripyion

Description

Item. Description. Text

Text

0..1

BBIE

商品説明（仕様）

準必須※
OrderLIne，LineItem，Item，
BuyerItemIdentification，
ItemIdentification,
PhisicalAttribute

PhysicalAttribute

Physical
Attribute

0..n

ASBIE 物理属性

準必須

OrderLIne，LineItem，Item，
BuyerItemIdentification，
ItemIdentification,
MeasurementDimension
38 00261

材料・規格・寸法（漢字）

X(40)

0/1

39 00177

戦略物資区分

X(1)

0/1

△

任意

40 00178

原産地コード

X(3)

0-5

△

任意

41 00346

取扱形態区分X(1)0/1

42 00351

見積依頼時発注者品名コード

X(25)

0/1

X(120)

0/1△

任意

43 C00144
44 00183

取引物品．説明．仕様詳細
発注品仕様

ID

Item Identification.
MeasurementDim Measurement_
Dimensionension0..1BBIE

1 BBIE

商品ID

ロット番号ID

商品ID

Dimension 0..nASBIE 計測量の次元

Code

BBIE

※
OrderLIne，LineItem，Item，
OriginCountry,
IdentificationCode

0/1

2 / 4 ページ

Item Identification.
Physical Attribute

1 BBIE※

IdentificationCode

Country. Identification.
Code

0..1

国コード

45 00278

発注品仕様（漢字）46 C00145

取引物品．説明．適用先K(240)

0/1

47 00171

機種コード

X(20)

0/1

48 00277

機種名（漢字）

K(40)

0/1

49 00188

工事件名

X(40)

0/1

50 00280

工事件名（漢字）

K(80)

0/1

X(3)

0/1

51 C00147
52 00029
53 C00148
54 00172
55 C00149

△

任意

△

任意

○

準必須

※

0/1

取引物品．説明．検査区分

OrderLIne，LineItem，Item，
ManufacturersItemIdentificatio ID
n，ItemIdentification, ID

取引物品．説明．設計変更区分
設計変更番号X(12)0/1

取引物品．説明．仕様書

0/1
0/1

○

準必須

※

57 00025

図面・仕様書枚数

9(2)

0/1

△

任意

※

図面・仕様書番号

X(30)

0/1

△

任意

※

△

任意

※

△

任意

※

△

任意

※

△

任意

取引物品．説明．要求書類

0-4

60 00174

要求書種類

X(1)

0/1

61 00175

要求書部数

9(2)

0/1

62 00176

要求書言語

X(1)

0/1

63 C00151

取引物品．説明．試験成績書

64 00192

試験成績書要否区分

X(1)

0/1

65 00193

試験成績書検査区分

X(1)

0/1

66 00194

試験成績書提出方法

X(1)

0/1

67 C00152

取引物品．説明．指定メーカ

0/1

0/1

ビジネスドキュメント本体明細部（注文情報）

68 00158

指定メーカ名X(20)0/1

69 00273

指定メーカ名（漢字）

K(40)

0/1

71 00151

取引物品．説明．エンドユーザ

0/1

エンドユーザ名

X(20)

0/1

72 00269

エンドユーザ名（漢字）

K(40)

0/1

73 00155

エンドユーザ品名

X(30)

0/1

74 00156

エンドユーザ品名コード

X(25)

0/1

75 00272

エンドユーザ品名（漢字）

K(60)

0/1

76 00157

エンドユーザ注文番号

X(23)

0/1

77 C00155
78 00014
79 C00158

取引物品．契約単価．取決め状況
単価区分

商品ID

※

X(1)

70 C00153

1 BBIE0/1

仕様書有無

59 C00150

Identifier

0/1

検査区分

56 00020

58 00173

Item Identification.
Identifier

OriginatorParty，Party,
PartyName

△

任意

※

△

任意

※

◎

必須

※

PartyName

OriginatorParty，Party
PartyName

PartyName

Party. Party Name

Party
Name

0..1

ASBIE 取引当事者名

Party. Party Name

Party
Name

0..1

ASBIE 取引当事者名

1
●

X(1)

取引物品．契約単価（注文）1
180 00013

単価●

9(10)V(3)

1

◎

必須

OrderLIne，LineItem，Item，
BasePrice, PriceAmountPriceAmountBase Price. Price
Amount. AmountAmount

1 BBIE

単価金額

81 00282

単価（外貨）■

9(11)V(5)

0/1

△

任意

OrderLIne，LineItem，Item，
BasePrice, PriceAmountPriceAmountBase Price. Price
Amount. AmountAmount

1 BBIE

単価金額

△

任意

82 C00159

取引物品．契約単価．主材料ベース

0/1

83 00189

主材料コードX(2)0/1

84 00190

主材料ベース9(10)V(3)0/1

85 00191

主材料単価

X(3)

0/1

9(11)V(5)0/1

86 00301

主材料単価（外貨）87 C00160

取引物品．取扱い単位

※

1
X(3)

1

◎

必須

(CCT)
QuantityUnitCode

QuantityUnitCode

Quantity Unit. Code

Code

0..1

Supplementary

荷姿（包装単位）

X(7)

0/1

△

任意

OrderLIne，LineItem，Item，
CommodityClassification,
CargoTypeCode

CargoTypeCode

Commodity
Classification. Cargo
Type. Code

Code

0..1

BBIE

荷姿コード

90 00348

包装単位数量9(9)V(3)0/1

91 00093

最低発注数量9(9)V(3)0/1

9(9)V(3)1◎必須

OrderLIne，LineItem, Quantity Quantity

Line Item. Quantity

Quantity

0..1

BBIE

商品数量

Delivery，Delivery Address, ID ID

Address. Identifier

Identifier

0..1

BBIE

所在地ID

Delivery，Delivery Address,
BuildingName

BuildingName

Address. Building
Name. Name

Name

0..1

BBIE

ビル名称

Delivery，Delivery Address,
BuildingNumber

BuildingNumber

Address. Building
Number. Text

Text

0..1

BBIE

棟番号

88 00012

単位

89 00026

92 C00164
93 00015
94 C00165

取引物品．契約数量（注文）注文数量
条長

96 00186

条長個数98 00187
99 C00167

1●

取引物品．契約数量．条長

95 00185

97 C0166●

0-10
9(9)V(3)

0/1

△

任意

※

9(4)

0/1

△

任意

※

取引物品．契約数量．条長単位

0/1

条長単位

X(3)

納入条件．納入場所

100 00028

受渡場所

101 00160

受渡場所名

0/1
1

●

X(8)

1

◎

必須

X(20)

0/1

○

準必須

3 / 4 ページ※

102 00274

受渡場所名（漢字）

K(40)

○

0/1

準必須

※

103 00152

納入先郵便番号X(8)0/1

104 00153

納入先住所

X(100)

0/1△

任意

105 00270

納入先住所（漢字）K(100)

0/1△

任意

106 00154

納入先宛先名X(100)

0/1

△

任意

※

107 00271

納入先宛先名（漢字）K(100)

0/1

△

任意

※

108 00195

市町村コードX(7)0/1

109 00196

納入時連絡先

X(18)

0/1

△

任意

※

△

任意

110 C00173
111 00034

納入条件．納期（注文）BuildingName

Address. Building
Name. Name

Name

0..1

BBIE

ビル名称

Delivery，Delivery Address,
BuildingNumber

BuildingNumber

Address. Building
Number. Text

Text

0..1

BBIE

棟番号

Delivery，Delivery Address，
AddressLine, LineLine

Address Line. Line. Text Text

1..7

BBIE

所在地

Delivery，Delivery Address，
AddressLine, LineLine

Address Line. Line. Text Text

1..7

BBIE

所在地

Delivery, ID

ID

Delivery. Identifier

0..1

BBIE

配送ID

Date Time 0..1

BBIE

納入希望日

Quantity

0..1

BBIE

配送数量（納
品数量）

1-31

納入Ｎｏ．

X(8)

0/1

Identifier◎

必須Delivery,RequestedDeliveryDateTime

Delivery. Requested_
RequestedDeliver
Delivery Date Time.
yDateTime
Date Time

0/1

◎

必須

Delivery, Quantity

Quantity

X(4)

0/1

△

任意

Delivery,RequestedDeliveryDateTime

Delivery. Requested_
RequestedDeliver
Delivery Date Time.
yDateTime
Date Time

Date Time 0..1

BBIE

納入希望日

納品キー番号

X(23)

0/1

○

準必須

Delivery, ID

ID

Delivery. Identifier

Identifier

0..1

BBIE

配送ID

旧納品キー番号X(23)0

代納理由区分X(1)112 18104

納期

113 18108

●

X(8)

1

納入指定日

X(8)

0

114 00032

納入指示数量9(9)V(3)

115 00179

納入時刻

116 00159
117 00435
118 00436※

Delivery，Delivery Address,
BuildingName

Delivery. Quantity

0

119 C00178

納入条件．発注者納品書情報

120 00161

発注者バーコード情報

X(23)

0/1

○

準必須

121 00162

発注者用備考

X(50)

0/1

○

準必須

※ NoteNote

Order. Note. Text

Text

0..1

BBIE

備考

122 00275

発注者用備考（漢字）K(100)

0/1△

任意※ NoteNote

Order. Note. Text

Text

0..1

BBIE

備考

123 00257

納品書価格表示区分

X(1)

0/1

△

任意

※

124 C00180

金額計算条件．諸条件※
Tax Scheme. Tax Type.
Code
Code

0..1

BBIE

税タイプコード

1 BBIE

支払方法コー
ド

0..1

BBIE

課税対象額

0/1
※

0/1

125 00057

消費税区分

X(1)

0/1

○

準必須

126 00059

課税区分

X(1)

0/1

○

準必須

OrderLIne，LineItem，Item，
TaxCategory，TaxScheme,
TaxTypeCode

TaxTypeCode

127 00169

数量契約区分X(1)0/1

128 00082

決済条件区分

X(1)

0/1

○

準必須

AllowanceCharge，
PaymentMeans,
PaymentMeansCode

PaymentMeansCo Payment Means.
dePayment Means. Code

129 C00181

金額計算条件．金額
9(10)0

9(12)V(3)

0

◎

必須

○

準必須

○

準必須

○

準必須

130 18089

見積金額

131 18090

見積金額(外貨）132 00071

予約金額

133 00289

予約金額（外貨）134 00016

注文金額

135 00283

注文金額（外貨）136 00060

消費税額

137 00287

消費税額（外貨）138 00061

合計額

139 00288

合計額（外貨）140 C00207

汎用．自由使用欄

141 00055

自由使用欄

▲

Code

1

9(10)

0

9(12)V(3)

0

9(10)

1

9(12)V(3)

0/1

9(10)

0/1

9(12)V(3)

0/1

9(10)

0/1

9(12)V(3)0/1

X(100)

0/1※ LineExtensionTotalAmountLineExtensionTota Order. Line_ Extension
AmountlAmount
Total. Amount

TaxTotalAmount

TaxTotalAmount

Order. Tax Total.
AmountAmount

0..1

BBIE

合計税額

Note

Note

Order. Note. Text

Text

0..1

BBIE

備考

※

0/1

142 C00208

汎用．備考

143 00056

備考

X(30)

0/1

○

準必須

Note

Note

Order. Note. Text

Text

0..1

BBIE

備考

144 00263

備考（漢字）

K(60)

0/1

△

任意

※ NoteNote

Order. Note. Text

Text

0..1

BBIE

備考

0/1

注） No. Cnnnnn:クラスNo.，nnnnn:項目No.
BIE合計項目数

・ドキュメント本体共通部

23個

・ドキュメント本体明細部（注文情報）

112個

・合計

135個

※：表8.4 「中小製造業EDIメッセージモデル／UBLマッピングでのデータ項目の説明」に解説を示す。

ECALGAサブセット電機・電子（注文情報）のデータ項目数
ﾋﾞｼﾞﾈｽﾄﾞｷｭﾒﾝﾄﾍｯﾀﾞ
ﾋﾞｼﾞﾈｽﾄﾞｷｭﾒﾝﾄ本体

14個

必須

15個

必須

27個

準必須

41個

任意

14個
42個

14個
83個

41個

4 / 4 ページ禁 無 断 転 載
中小企業にも適用可能なインターネット EDI 設計・導入ガイド
平成 17 年 3 月 発行
発行所

財団法人 日本情報処理開発協会
電子商取引推進センター
東京都港区芝公園 3 丁目 5 番 8 号
機械振興会館 3 階
TEL：03-3436-7500

印刷所

新高速印刷株式会社
東京都港区新橋 5-8-4
柴田ビル 6 階TEL：03-3437-6365（本報告書は再生紙を使用しています。）

16-E001

ISBN4-89078-623-6 C2055