業会 日本語タグを採用（国内での利用を前提）。業界の慣用的な用語に基づいて 業界団体が標準化。タグの文字数は 10 文字以内の目標値を設けて，タグの長 大化を防止する工夫をしている。タグを単独で見て意味がわかる。構造化に よる個々のタグの短縮は行っていない。
<発注者名>企業名</発注者名>
ApparelArc
日本語タグを採用（国内での利用を前提）。業界の慣用的な用語に基づいて 業界団体が標準化。タグを単独で見て意味がわかる。構造化による個々のタ グの短縮は行っていない。
7.1.2 XML タグ設計方式の分類と考察
表 7.2 XML タグ設計方式の分類と考察に，上記の現状を整理したXMLタグ設計方式の分類と 考察を示す。
表 7.2 XML タグ設計方式の分類と考察
言語 日本語 英語
名称付与規 則
業界の慣用的用語を業界 団体が標準化
業界の慣用的用語を業界団 体が標準化
ISO11179 の名称規則に 従ったジェネリックな項 目名称
主な例 （社）日本塗料工業会 ApparelArc
RosettaNet OTA
EAN.UCC
（社）日本航空宇宙工業会 UBL
メリット 日本人にとっては分かり やすい。
当該業界の人にはわかり やすい。
国際取引に利用しやすい。
同一業界内，関連業界間で あれば理解が容易。
国際標準(ebXML)と整合さ せやすい。
他業界でメッセージやデ ータエレメントが再利用 しやすい。
名称によりデータエレメ ントの同定が可能。
国際標準(ebXML)と整合。
デメリット 海外取引には使用し難い。
他業界でメッセージやデ ータエレメントが再利用 し難い。
他業界でメッセージやデー タエレメントが再利用し難 い。
抽象的で意味が理解し難 い言葉が多い。
記号や番号をタグにする方式はドイツ，韓国のEDIFACTtoXML及びCII/XMLで規定してい るが，実際の採用は少なく，今回調査した事例にも該当するものがない。技術的なトレンドとして は英語ないしは日本語のタグが採用される方向であると言うことが出来る。
7.1.1項の例を見ると，英単語（または漢字）が長く連なるタグは，（コンピュータのリソース
を多く消費するだけでなく）人間にとっても読み難いことが分かる。
タグの付与方法について一定の基準を設けて，その優劣を論じることは難しい。望ましいタグ の要件としては，以下の点が考えられる。
l 日本語，英語など自然言語のタグにする。日本語にするか英語にするかは国際標準との整合性，
EDI 取引の範囲（国内・国際）などを考慮して，業界ごとの事情により決定すべきものと考えられ る。
l 国際標準のネーミングルールに従った名称を原則とし，場合によって（セマンティクスは同一で）
業界で慣用的に使用されている用語（Business Team）のほうが適している場合はそれで代用 する。
l 構造化タグを利用して，1つ1つのタグはなるべく短く表現する。（7.3節で詳述）
7.2 CII/XML 対応のメリット・デメリット 7.2.1 CII/XML バージョン 1.1 の考察
CII/XMLバージョン1.1の仕様が公開されて2年以上が経過するが，仕様の一部を利用した例
は JEITAコラボレイティブ EDI実験フェーズ１（データエレメントタグを利用），航空宇宙業
界（繰り返し構造タグ利用）があり，全体を利用した例としてはパソコン流通業界の一部の企業で HWSW標準をXML化した事例がある。
CII/XMLは既存のCII標準メッセージを簡単な処理でXMLに変換する方法を規定したもので
あり，サポートするソフトウェアの開発が容易，メッセージの変更がないため，すでに CII 標準 のEDIを導入済みの企業がアプリケーションの変更を伴わずにXML/EDIに移行できるなどのメ リットを想定していた。CIIシンタックスルールはネットワークとしてVANを利用することを前 提とした構造が多く，これをXML化することでEDIのネットワークとしてXMLと親和性の高 いインターネットの利用が容易になると考えていたが，CII 標準のユーザーにはコストをかけて
CII/XMLに移行するメリットが見出し難いと言う問題がある。また，CII/XMLのデメリットとし
て，CIIシンタックスルールとの互換性を保つために，メッセージの構造化が出来ないこという技 術的な問題も指摘されている。
7.2.2 CII to ebXML リバースモデリング
CII/XMLバージョン1.1の反省に立って，ECOMではCII標準に準拠したEDI標準を利用し ているユーザーにとって，業界が開発したメッセージ及びデータエレメント等の資産を，ebXML と整合させて活用する方法を検討しており，CII to ebXMLリバースモデリングと称している。こ れは，CII 標準に準拠して開発された各業界の EDI 標準を，比較的簡単な分析作業によって，
ebXMLの仕様に準拠したXMLメッセージ（ビジネスドキュメント）に作り直す方法である。こ
の方法によれば，業界がCII標準策定に当たって蓄積したビジネスナレッジを継承して，CIIシン タックスルールとはまったく独立なXML/EDIメッセージを設計することが出来る。この詳細に
ついては2002年度XML/EDI標準化専門委員会の成果報告（ebXML技術ガイド）を参照された
い。
7.3 XML 化によってシステム負荷が重くなることに関しての考察と対策
実際に XML/EDI を運用する上でしばしば問題となるのが，マシンリソース（メモリ不足）及
びパフォーマンス（処理速度）である。XML化すると従来のEDI電文よりも2〜4倍の文書サイ ズになるといわれている。しかし，システム構築方法あるいは運用方法の工夫により実質的に問題 にならないように設計することが可能であり，また，コンピュータ及びネットワークの性能向上に
よりこのデメリットは吸収されると考えられる。
以下にXML化でシステム負荷が重くなることに対しての対策と考察を述べる。
7.3.1 データ要素値のアトリビュート化によるデータ量の低減
XML利用の初期段階では，タグの節約のために，データエレメント値を形式的にアトリビュー トにする方式が一部で提唱されたことがあった。
表 7.3 アトリビュート化によるデータ量の低減
通常の XML/EDI のデータエレメント アトリビュート化
<発注者>
<コード1>B00018000040</コード1>
<名>アパレル商事</名>
<部課コード>BAP02</部課コード>
<部課名>紳士服課</部課名>
<担当者名>織田信長</担当者名>
</発注者>
<発注者 コード1= 00018000040 名= ア パレル商事 部課コード= BAP02 部課 名= 紳士服課 担当者名= 織田信長 />
しかし，この方法はXML Schemaのデータタイプがアトリビュートには適応できないなど，デ メリットが多く，XML/EDIのデータとしては不適であると考えられる。事実7.1節で取り上げた 事例のいずれも採用していない。
7.3.2 構造化によるタグの短縮
構造化を利用することで，個々のタグを短縮する方法が有効である。
表 7.4 構造化タグによるデータ量の低減
構造化しない場合 構造化によって個々のタグを短縮した場合
<発注者コード>B00018000040</発注者コード>
<発注者名>アパレル商事</発注者名>
<発注部課コード>BAP02</発注部課コード>
<発注部課名>紳士服課</発注部課名>
<発注担当者名>織田信長</発注担当者名>
<発注者>
<コード1>B00018000040</コード1>
<名>アパレル商事</名>
<部課コード>BAP02</部課コード>
<部課名>紳士服課</部課名>
<担当者名>織田信長</担当者名>
</発注者>
この方法は，7.1.1項のUBLで採用されている。英語タグでも日本語タグでも適用可能であり，
発注者と受注者のように同一構造の別なデータエレメントが存在する場合は，XML Schema の
complexTypeを利用することで，スキーマを短くかつ保守性よく作成することが出来る。
7.3.3 専用のプログラムで処理する方式
XML/EDIでは，受信した電文をXMLのままで処理するのではなく，非XMLの社内システム
フォーマットで処理するケースも多いと考えられる。そのような場合，プログラムのパフォーマン スを向上させるために，汎用のツール（パーサーなど）を使用せず，専用のプログラムロジックで
XML/EDIメッセージを社内フォーマットに変換する方法をとった事例もある。
ただし，一般論としては，汎用のツールを利用したほうがソフトウェア開発の生産性が高まり，
開発コストの削減及びソフトウェアの保守性も向上する。また，使用するマシンやオペレーティン グシステムなどのプラットフォームに依存しないソフトウェアを開発するためにも，原則として汎 用のツールやミドルウェアを利用する事が望ましい。その場合，ツールやミドルウェアがW3Cや
ebXMLなどの標準に準拠しているものを採用することが望ましい。
7.4 XML 関係ツールの選定と XML バージョンアップ対応の対策
XMLのツールはITベンダーが提供する商用の製品のほかに，フリーウェア，シェアウェアな ども存在する。提供の形態も，独立した製品，開発のためのツールキット，他のソフトウェアにバ ンドルされたものなど多様である。しかし，XML/EDIのシステム構築に使用するには，高品質で あることや不具合のメンテナンスが責任を持ってなされることが必須であり，また知的所有権など のトラブルを防ぐためにも，IT ベンダーが保証・サポートしてくれる商用の製品を選択すること が望ましい。
また，XML関連の規格についてはW3Cにおいて開発途上のものや，バージョンアップ作業中 のものも多く，これらを「先取り」して実装した機能が最終的には，正式規格とは違う仕様になっ てしまう場合もあり，他のツールを利用する企業との間での相互運用性が保てなくなる恐れがある ので注意が必要である。一部のツールではドラフト規格の先取りとして独自の機能拡張を実装し，
次のバージョンでは互換性がなくなるというようなケースもある。したがって，先取りの機能や独 自の拡張機能は使用せず，W3Cの現行規格の範囲内で利用することがトラブルの防止になる。
また，ツールやミドルウェアを選定する際には，他社製品との接続試験（相互運用性試験）や 標準規格への適合性試験（コンフォーマンステスト）実施済みの製品を選定することが望ましい。