この連載では、CEFACT標準の中核的存在である「コアコンポーネントライブラリ（CCL）」と「コアコンポーネント技術仕様（CCTS）」について、理想と現実や、前提知識が求められている観点からの難しさをこれまで解説してきました。残念なことに、実はもうひとつ、とっつきにくさの元凶とも言える「抽象的である」という性質があります。今回は、そのあたりの事情を掘り下げていきたいと思います。やや長文な記事ですが、どうぞ最後までお付き合いください。
1．なぜ抽象的なのか
CEFACT標準の中核となるコアコンポーネント技術仕様（CCTS）は、国や業界をまたいで再利用可能なデータモデルを作るために極めて抽象化されたデータ構造を採用しています。標準の目的は「共通の土台づくり」であり、特定の国の制度や企業の商慣行に寄せ過ぎるわけにはいきません。そこでCCTSでは業務文書そのものではなく、文書を構成する情報要素の「構造」を定義する方法が取られています。
また、CCTSは特定のデータ形式（XML、JSON）やコンピュータ言語、さらにはモデリング言語（UML）にも依存せず1、あらゆる実装技術から独立したデータモデルとして設計されています（技術中立性または技術に対する非依存性）。これは将来の技術進化・変化にも耐えられる基盤を提供することを狙ったものと考えられます。
2．キーワードは「分解」
さて、CCTSバージョン3.0では情報を構成する単位として「Core Component（CC）」と、それをもとに業務で使える形へと発展させた 「Business Information Entity（BIE）」が導入されています。しかし、これらの概念は日常の業務とはかけ離れたものであり、実務家には馴染みがありません。
例えば実務では「住所」「企業名」「金額」といった具体的な項目を扱いますが、CCTSではこうした項目をそのまま「住所」として固定的に定義するのではなく、まずその項目を成り立たる部品に「分解」して考えるという方法を取ります。
具体的には、CCTSでは情報を次の3つの視点に分けて整理します。
- 集約構造（Aggregate）：複数の情報をひとつにまとめた「まとまり」
- 基本データ型の要素（Basic）：文字列や数値といった「最小の意味単位」
- 文脈の与え方（Contextual）：利用目的に応じた「意味づけ（配送先住所／請求先住所など）」
ここでいう「分解」とは、高度な理論というよりも「住所という1つの情報を、どんな部品でできているのか順番に見ていく」という考え方です。
3．実践：住所を分解してみる
ステップ１
まず、住所全体を国名・地域名・市区町村・番地といった複数の情報をひとまとまりとして扱うAggregate（集約構造）と捉え、この住所という情報の入れ物がどのように構成されているか整理します。いったん、表記方法や利用場面については考えません。
ステップ2
次に、その中身「国名」「市区町村名」「通り名」など個々の要素は、文字列といったBasic（基本データ型の要素）として扱います。Basicは、特定の制度に左右されないSemantics（意味）に基づく最小単位の情報という位置づけです。これらの情報が実際のビジネス文書の中で使われる際には、Contextual（文脈）を付与することで、どのような住所として使うのかが決まります。たとえば、配送先として利用する場合は Party.ShipToAddress、請求に利用する場合は Party.BillToAddress のように、同じ住所でも用途によって「文脈」が異なります。
ここまでのステップで分解したものを図示化すると、以下のようになります
Core Component（CC） │ ├─ Basic Core Component（BCC） │ ├─ 国名（CountryName） │ │ └─ Basic Business Information Entity（BBIE） │ │ └─ 例：Address.CountryName │ ├─ 市区町村名（CityName） │ │ └─ BBIE │ │ └─ 例：Address.CityName │ ├─ 通り名（StreetName） │ │ └─ BBIE │ │ └─ 例：Address.StreetName │ └─ 郵便番号（Postcode） │ └─ BBIE │ └─ 例：Address.Postcode │ └─ Aggregate Core Component（ACC） │ ├─ 住所（Address） ← ACC（複数の BCC/BBIE を束ねた構造） │ └─ Aggregate Business Information Entity（ABIE） │ ├─ Address.CountryName（BBIE） │ ├─ Address.CityName（BBIE） │ ├─ Address.StreetName（BBIE） │ └─ Address.Postcode（BBIE） │ └─ Associated Business Information Entity（ASBIE） ├─ Party.ShipToAddress → Address（配送先住所） ├─ Party.BillToAddress → Address（請求先住所） ├─ Shipment.DeliveryAddress → Address（出荷の配送先住所）
このように、CCTSでは実務で一項目として扱う情報をSemantics（意味）→Aggregate（構造）→Contextual（文脈）という順に分けて理解します。「なぜこんなに回りくどいのか」とも思いますが、このように分けて考える仕組みにすることで「国や制度が異なっても再利用できる情報モデル」を作るための土台としているわけです。
4．抽象化が必要な本当の理由
そして、CCTSが敢えて抽象的である本当の理由は、大きく二つあります。
一つ目は、「国際的な相互運用性」を確保するためです。貿易手続は、国・地域・制度が異なる複数の主体の間で行われます。国ごとの帳票項目をそのまま標準化ししたとして、たとえ使われている言語が同じでも「同じ言葉で違う意味」「違う言葉で同じ意味」となる項目が必ず出てきます。それを考慮して標準化を試みたとしても、互換性が確保しきれないか、あるいは冗長になります。そこでCCTSでは「共通して意味が変わらない最小限の情報構造」のみを中立的に定義しているというわけです。
二つ目は、「業務の変化に耐えうる柔軟性」を得るためです。国際貿易のプロセスは変化していきます。紙から電子、単純な電子ファイルから第三者検証可能な貿易文書（例えばUNVTD2） へと進化する中で標準が使えなくなると困ります。長期間、変化に耐えながら標準が使われるようにするための戦略として抽象化という手法を用いているのです。
5．実装段階で「難しい」と感じる理由
こういった理由からCCL/CCTSは非常に抽象的なのですが、現実的な問題として情報システム開発や貿易実務の現場においては以下のような理由から大変とっつきにくいものであると考えられます。
（1）モデルが「抽象→具体」の順で設計されている
CCTSは、最初に「意味（Semantics）」をもつ最小単位（Basic/BCC）を定義し、それらを組み合わせて構造（Aggregate/ACC）を作り、最後に用途に応じた文脈（Context）を付与する、といういわばトップダウン構造です。
一方、実際の情報システム開発は、実務が最初にあります。そこから「項目」→「データモデリング」→「DB設計」のように具体的な要素から徐々に抽象化するというボトムアップ型で構築されています。そのため、CCTSのトップダウン構造は直感と大きく異なり、「何から読めばよいのか」「何がどの実務と対応しているのか」が把握しにくくなります。
（2）具体的な項目名をCCL構造にマッピングするための知識ギャップ
貿易実務で実際に使われる帳票やデータ項目は、
- 自社固有の名称や業界的な慣例に沿った呼称
- 自社や部署ごとのルール、プロセス
- 過去システムからの継承
などに基づいています。
一方、CCTSは国際的に意味（Semantics）が共通である最小単位を定義するため、企業システムで実際に使われるフィールド名と一致しない場合が多く、「自社の配送先郵便番号はCCTSのどのBBIEに当たるのか？」といった項目の読替え（マッピング）が必要になります。
この作業には、
- CCTSの概念を理解していること
- 自社業務のモデル化能力
- 属性の意味の読み解き
といった複合的な知識が求められるため、そのようなスキルを有した人材が必要となりますが、そういった人材は決して多くないものと考えられます。
（3）標準に合わせるメリットが（短期的に）見えづらい
さらに、もしCCTSを導入しても、すぐにコスト削減や業務効率化につながるわけではありません。
むしろ初期段階では、
- 抽象モデルの読解
- 既存形式とのマッピング作業
- 設計ルールの理解
といった追加の負担が発生します。
CCTSの真価は、将来的な
- 国際的な相互運用性
- データ交換の再利用性
- 仕様変更への強さ
といった長期的メリットにありますが、個社単位では短期的に目に見えにくいため、現場では「難しい」「手間が増えただけ」と感じられがちです。
6．では、抽象性をどう乗り越えるのか
(1)まず「文書」ではなく「情報構造」として理解する
CCTSは帳票テンプレートを定義する仕様ではなく、情報要素の構造化を定めるものです。したがってBasic・Aggregate・Contextualの概念を理解し、文書の部品化を目的とした「設計思想」として捉えることが第一歩です。
(2)国内・業界ガイドラインとのセットで読む
CCTSは国際的な相互運用性のために抽象化されており、そのまま実装する仕様ではありません。具体的な制度や商習慣への適用は各国が行う必要があります。国連CEFACTのガイドでは、各国の貿易円滑化組織（National Trade Facilitation Body：NTFB）が「国際標準を国内レベルに向けて翻訳・適用してきた」と記されています3。
これは、国際標準が抽象モデルの提供に留まり、実務に適した具体化は各国で行う必要があるという国連CEFACT自身の立場を示しています。
これはつまり、本来はNTFBが実装ガイドラインのような文書を用意し、抽象的な仕様を現場で使える形に具体化する作業が必須であることを示しています。この点、日本において取組みが不足していたことは否めず、日本のNTFBであるJASTPROとしても大いに反省すべきところです
7．まとめと次のステップ
これまで3回にわたってCCL/CCTSが「難しい」と言われる背景や、それを乗り越えるためにすべきこと、その難しさを乗り越えるための思考整理を紹介し、また、その過程でJASTPROの力不足からこれまで充分にCCL/CCTS活用の支援に取り組めていなかった点にも触れてきました。
しかし、反省だけで終わらせるわけにはいきません。今後、JASTPROではCEFACT標準、特に「CCL/CCTSを日本においてどのように活用していくのか」に照準を合わせた取組みを展開していく予定です。
tradigi.jpにおいても、この取り組みについて随時報告していく予定です。特に貿易DXに携わる皆様におかれましては、続報をお待ちいただければと思います。
【脚注】
- “The CCTS is described using the Unified Modeling Language (UML). It does not require UML in its implementation.” CCTS-Version3.pdf P.2
- 第44回国連CEFACTフォーラム報告 その１ | tradigi portal
- “NTFBs … have translated global, regional and sectoral standards at the national level” Guide for National Trade Facilitation Bodies on How to Use UN/CEFACT Standards and Tools、P.5