第36回 国連 CEFACT フォーラム（Virtual）会議報告
2021年4月26日～5月7日
オンライン会議

報告者：国連 CEFACT 日本委員会
一般社団法人サプライチェーン情報基盤研究会
菅又 久直
第36回国連CEFACTフォーラムは、2021年4月26日から5月7日の2週間、3つのオンライン会議室を使って、分野領域（ドメイン）ごとのセッションが並行的に行われました。
国連CEFACTフォーラムでは大まかに4つの分野（貿易円滑化分野、電子ビジネス分野、電子政府分野、技術分野）に分かれてセッションが持たれます。


貿易円滑化分野では、シングルウィンドウや貿易情報ポータルについての課題、および貿易円滑化関連の勧告について審議されています。

電子ビジネス分野では、国際サプライチェーン、運輸・物流及びその他のビジネス電子化に関わる課題が審議されています。


国際サプライチェーン関係では自動車製造工程プロジェクトや日本から提案中の電子交渉プロジェクトなどが議題になりました。



運輸・物流関係では、複合一貫輸送及び商流・物流を連携したトレーサビリティが中心の話題となっています。



その他の電子ビジネス分野では、金融、会計、保険、医療、旅行観光などの電子ビジネスモデルが検討されています。



電子政府分野では、ブロックチェーンやIoTなどの新技術によるデータ管理を検討しています。更に、農業／漁業／環境分野も電子政府関係領域に含まれています。



技術分野では、EDIのAPI化に向けた標準の整備について審議が行われました。

本報告では、小生（菅又）が電子ビジネス分野（国際サプライチェーン関係）と技術分野を中心に参加した以下のセッションにつき報告します。
オープニングセッション（日本時間：4月26日 20:30 – 22:30）

APIガイドライン活用セッション（日本時間：4月26日 17:00 – 19:30）



トレーサビリティに関する意見交換（日本時間：4月28日 17:00 – 19:30）

1

サプライチェーン・ドメイン会議（日本時間：4月29日―4月30日）



技術仕様ドメイン会議（日本時間：5月5日 17:00 – 19:30）



コードリスト管理（日本時間：5月6日 17:00 – 19:30）

クロージングセッション（日本時間：5月7日 20:30 – 22:00）

１．オープニングセッション（Opening Session）
オープニングセッションには75名が参加。日本からは菅又久直（SIPS）、鈴木耀夫（JTREC）、清友大造（JASTPRO）、島野繁弘（Legoliss）、遠城秀和（NTTD）の5名が参加した。
開催にあたって、Ms. Elisabeth Tuerk（UNECE 経済協力・貿易担当理事）及びMs.
Sue Probert（UN/CEFACT議長）の挨拶があり、事務局（Lance Thompson）より次の紹介があった。
2021-2022 Programme of Work（UN/CEFACT活動計画）の総会承認



電子ビジネスMoU会議における国連CEFACT標準（CCL）使用の呼びかけSustainable Mobility（持続的交通手段）とSmart Connectivity（接続容易性）におけるUNECE Nexus（Water-Food-Energy-Ecosystemsに関わるタスクフォース）の活動
プログラム開発エリア（PDA: Programee Development Area）ごとに担当副議長及びドメイン・コーディネータより、各プロジェクトの進捗状況と今フォーラムでの審議予定につき説明が行われた。
ITP (国際貿易手続) PDA:

貿易手続簡易化ドメイン


民間企業のNTFB (政府貿易簡易化組織)参加促進プロジェクト

シングルウィンドウ・ドメイン


貿易情報ポータルBRS（業務要件仕様）プロジェクト

コロナ禍におけるシングルウィンドウWEBセミナ

コードリスト・フォーカルポイント
コードリスト・メインテナンス要求

ISC (国際サプライチェーン) PDA:


サプライチェーン管理&購買ドメイン


トレーサビリティ合同会議



自動車製造プロジェクト



MLETR（電子交換文書模範法）に準拠した権利書（電子B/Lなど）転送
プロジェクト2

電子交渉プロジェクト

輸送／物流ドメイン


危険物輸送メッセージ（IFTDGN）



国際海事機関（IMO）国際海運簡便化条約（FAL）に準拠した電子情報マッピング・プロジェクト

ファイナンス／ペイメント・ドメイン


貿易手続のためのオープンファイナンス・プロジェクト

会計／監査ドメイン


複合一貫輸送プロジェクト

会計／監査参照データモデル・プロジェクト

保険／医療ドメイン


医療費償還請求



自動車賠償責任保険、保険証書

旅行／観光ドメイン


持続的観光ビジネス標準化プロジェクト

体験プログラム技術成果物プロジェクト

REG (規制／電子政府) PDA:

漁業／農作物ドメイン
電子証明書プロジェクト

電子品質証明書プロジェクト

環境ドメイン

廃棄物管理と分析

電子データ管理ドメイン
ブロックチェーンによる特恵原産地証明書交換プロジェクト



貿易手続のためのデジタルIDプロジェクト



貿易手続のためのIoTプロジェクト



国連CEFACTチェイン・プロジェクト

越境管理ドメイン

越境管理参照データモデル

M+T (手法／技術) PDA:


技術仕様ドメイン

RDM2API（参照データモデルAPI化）プロジェクト

API Town Plan（API標準／実装フレームワーク構築）プロジェクト



技術仕様メインテナンス（NDR（XML設計規則）, CCBDA（業務文書構築仕様）, XHE（交換ヘッダー仕様）



共通辞書管理／評価フォーカルポイント

3




共通辞書2021年A版は既に完成し公開済

シンタックス・フォーカルポイント


国連EDIFACT DMRs（辞書変更要求）

２．APIガイドライン活用セッション（API Guideline Sandbox for use withUN/CEFACT）
APIガイドライン活用セッションには43名が参加。日本からは菅又久直（SIPS）、鈴木耀夫（JTREC）、遠城秀和（NTTD）の3名が参加した。
APIプロジェクト進捗状況
APIプロジェクトリーダーのSteve Chapell氏が、RDM2API（参照データモデルのAPI化プロジェクト）の進捗状況（下図）の説明と、国連CEFACT Web上に作られたJSON-LDライブラリを使ってUMLツール（StarUML）によるAPI実装のデモを行った。
JSON-LDライブラリ：
https://service.unece.org/trade/uncefact/vocabulary/uncefact/

RDM2API進捗状況

RDMs (ReferenceData Models)
BSP : Buy Ship PayProperties
fobAmountroleCode
Etc..
Code Values
rec20:millipascal
rec21:carton
Etc..

done

done

Open API 3.x

Any others..

Classesconsignment
party
Etc..

UML Profile

Naming & Design Rules

Code Lists
UN Recs : UoM,
package type, etc
UNCL: EDIFACT
code lists

JSON-LDAny others..

doneNaming & Design Rules

MMT : MultiModal Transport

JSON-LD
Vocabulary

Design Tools

done
UN API Resources(interfaces & events)

Transport Domain

Movements
BillsOfLading
Etc..
Trade Domain
TradeProducts
Invoices
Etc..
Regulatory Domain
Declarations
Certificates
Etc..

Conformance Rules Other Domains..

Test Tools

With techspecification

Startingsoon

インボイスAPI 導入例
Nis Jespersen氏（デンマーク）によるインボイスAPI導入事例のデモが行われた。



APIについての自動車業界の観点
Joerg Walther氏（ODETTE：欧州自動車業界）より、自動車業界のAPI化に向けての考え方を紹介し、課題についての意見表明が行われた。
APIソリューションの場合、膨大なAPIライブラリは使いにくい。 標準化されたビルディングブロック（セマンティックユニット）のツールボックスが4必要。
APIソリューションの場合、明示的な名前ではなく修飾属性（タイプコード、ロールコードなど）を使用する標準化されたデータ構造（ABIE）のライブラリが良いと思われる。



必要な標準データの柔軟な実装（可能な場合は集約（リンク）、ただし複合（コンポジット）も利用可能に）。



ビジネスプロセス、地域または業界固有のプロセスについては、ソリューシ
ョン開発者が同じデータ構造/アーティファクトを使用してさまざまなプロセスを実装/サポートできるようにするユニバーサルなツールボックスを提供および維持する必要がある。

eCMR （電子道路貨物国際運送契約）のAPI化についてRudy Hemeleers氏により、eCMR API化のユースケースに関してライブラリの持ち方についての提言が行われた。



ドメイン毎のAPI化への取組みについてAPI化に関心を持つドメイン代表者から意見が表明された。
Tahseen Khan（規制／電子政府PDA担当）

Edmund Gray（サプライチェーン管理／購買ドメイン担当）

David Roff（運輸／物流ドメイン担当）



Ian Watt（国際サプライチェーンPDA担当）

３．トレーサビリティに関する意見交換（Traceability Discussion）
トレーサビリティ・セッションには61名が参加。日本からは菅又久直（SIPS）、清友大造（JASTPRO）、祁答院包則（JASTPRO）、遠城秀和（NTTD）の4名が参加した。
Ian Watt氏（国際サプライチェーンPDA担当副議長）がトレーサビリティに関する意
見交換セッションの紹介を行い、以下のプレゼンテーションを基に質疑応答が行われた。
トレーサビリティ・プロジェクト（Supply Chain Cross Industry Track &Trace）（by Hanane Becha：運輸／物流担当副議長）


運輸ロジスティックス領域では、トレーサビリティに関してスマート・コンテナー及び複合一貫輸送追跡の２つのプロジェクトを進めている。その中で、透明性のある複合一貫輸送相互運用性コラボレーション標準を進めている。

課題は複合一貫輸送に関して、商流と物流で共通に認識できるIDの欠如である。

5

Sales OrderOrder ID

1

Trade Items

TradeB2B Data
World

1

1..*

1..*

0..*

1..*

0..*

Trade Item Identifier
Product Identifier

0..*

1..*

1..*

Trade Packaging
Trade Packaging ID

Shipment (Trade Delivery)

0..*

1..*

1..*

1

1Shipment ID

* * *
1..*

Transport
B2B Data
WorldID Gaps

1

1

Consignment Items

1..*

Consignment Item ID

1..*

0..*

Transport Packaging

Transport Packaging ID

1..30..*

1..*
1..*

1

Transport Contract

1

Consignment ID

0..*

0..*

1..*

1

1..*
Transport Movement

Transport Equipment
Transport Equipment ID

0..*

1

Transport Movement ID

11..*
Transport Means
Transport Means ID

透明性のあるトレーサビリティのためのデータパイプライン及び運輸ドメインの成果物（Data Pipelines, and Transport Domain Deliverables for Traceability
and Transparency in the Supply Chain）（by David Roff：運輸／物流ドメイン・コーディネータ）データパイプラインとは、


サプライチェーンから蓄積された商品とその動きに関するデータの電子記録であり、データは、さまざまな経路上のポイントでSnippet（情報の断片）として提供できる。



情報提供は情報が真実であることを知っている人が提供しなければならない。



情報が必要な人には、それらのデータにアクセスできる基盤を提供。

データパイプラインについては次の白書が公開されている。
https://unece.org/fileadmin/DAM/cefact/GuidanceMaterials/WhitePaperDat
aPipeline_Eng.pdf


繊維／革製品分野の透明性・持続性のあるトレーサビリティ（Traceability, Transparency and Sustainability for Textile & Leathersector）（by Maria Teresa Pisani：UNECE）

持続的な繊維／革製品分野のトレーサビレィティについての関心は高まっている。


消費者：特に先進国において、労働者の権利、環境を尊重し、安全で持続可能な製品に対する需要の高まりがある。

6



市民社会：トレーサビリティ、透明性、持続可能性を要求するNGO、標準化団体、業界プラットフォームの数と強さが増加している。



規制当局：安全性やラベリング基準など、透明性と消費者保護を必要とする規制を設定する必要がある。

ビジネス：
「持続可能（サステイナビリティ）ブランド」に対する消費者の需要に対応する必要。



競争力を維持するには、コストと効率を抑える必要。



複数の法域にわたる法的およびコンプライアンスの義務を果たす必要

BSP (Buy-Ship-Pay)参照モデル領域にSDCE（Sustainable Development & Circular
Economy View）を追加する。
４．サプライチェーン管理／購買ドメイン会議（Supply Chain Management &Procurement Domain）
ドメイン・コーディネータ Edmund Grayの司会により、サプライチェーン関連の次のプロジェクトに関して審議及び意見交換が行われた。
電子交渉プロジェクト（eNegotiation）



欧州における電子インボイス（eInvoicing）

トレーサビリティ・プロジェクト（Track & Trace）



自動車製造プロジェクト（Automotive）



新規プロジェクト提案

４．１ 電子交渉プロジェクト（eNegotiation）
電子交渉プロジェクトには29名が参加。日本からは菅又久直（SIPS）、中台慎二（NEC）、高橋一裕（NEC）、藤森英明（NEC）、柳紀夫（NEC）、安達辰巳（NEC）、田部尚志（NEC）、佐藤友昭（NES）、藤田延介（SEC）の9名が参加した。
電子交渉プロジェクト（eNegotiation）は日本からの提案プロジェクトであり、プロジェクトリーダーは菅又久直、リード・エディターは中台慎二が担当しており、2人からBRS（Business Requirement Specification：業務要件仕様）及びImplementation Guide（導入ガイド）のドラフトにつき内容紹介が行われた。


当プロジェクトは、電子交渉に関連するビジネスプロセスと関連するデータ交換要件を定義することを目的としている。これは、内部の人またはAI等による意思決定プロセスではなく、交渉におけるプロトコルとデータ形式を対象にしている。人間の交渉者、AI交渉者、またはAI /ロボットサポートによって支援された人間の交渉者は、同じ基本セマンティックプロトコルを使用することを目指して

7

いる。
電子交渉の範囲は、図4.1-1に示す「交渉フェーズ」における電子情報交換

（EDI）を対象としている。

Five fundamental activities of abusiness transaction(ISO/IEC 15944-1)

Our scopeplanning
identification

Standardized protocols
Human-basednegotiation
actualization
post-actualization

AI-supportedRPAAI“May 5th, 10 items, $10”
“May 4th, 20 items, $18”

Company A

OKCompany BEDI

図4.1-1 交渉フェーズ

交渉人（AIを含む）間のプロトコルは図4.1-2に示すゲーム理論で引用される
AOP（Alternative Offer Protocol）を基本としている。

図４．１－２ AOPプロトコル


AOPでやりとりされる交渉情報は図4.1-3に示す交渉データ・コアモデルで定義される。

8

図４．１－３ 交渉データ・コアモデル


電子交渉プロジェクト紹介に関して次のコメントがあった。


将来的には交渉プロトコルをデータパイプライン基盤の中に位置づけるのが望ましい。

電子交渉プロトコルは、国連CEFACTで標準化されているビジネスプロセス（貨物予約プロセス、製造スケジューリングプロセス等）と整合化させる必要がある。

電子交渉プロジェクトの今後の予定は次の通り。


公開評価用BRSドラフトの準備：6月末



導入ガイドの策定：7月末



関連CC/BIEの共通辞書追加要求：7月末

BRS公開評価：8月～9月

４．２ 欧州における電子インボイス（eInvoicing）
欧州における電子インボイスの検討には26名が参加。日本からは菅又久直（SIPS）、高橋一裕（NEC）の2名が参加した。


欧州で公式に認められる標準は欧州標準化委員会（CEN）で発行されたものである。欧州の電子インボイス標準（EN16931）もCENの標準であり、実装方式（Syntax Binding）として国連CEFACTのCII（Cross Industry Invoice）と9

OASISのUBL（Universal Business Language）が定義されている。


今後、国連CEFACTでは CIIの参照モデルに基づくAPI（JSON-LD）の策定を進める。自動車業界もAPIライブラリのサブセットを作って行きたい意向がある。

欧州各国からは、自国の制度／環境に対応すべく電子インボイス標準仕様に対する追加変更要求が少なからず提出されて、CENの関係部会（CEN/TC434）で検討されている。CEN/TC434では、UBL支持委員が多く国連CEFACTの意見は通りにくくなっている。

４．３ トレーサビリティ・プロジェクト（Track & Trace）
トレーサビリティ・プロジェクトには31名が参加。日本からは菅又久直（SIPS）、高橋一裕（NEC）、遠城秀和（NTTD）の3名が参加した。
Hanane Becha（運輸／物流担当副議長）より、トレーサビィリティにおける商流・物流を通じた貨物（商品）の識別スキームにつき提案がなされた。

Cargo Reports
Transit Declarations

MUCR
Master level

HUCR
House level

Import, ExportDeclarations

ID Gaps

TUCR
Trade level

Todd Frazier（航空貨物担当）より、IFT（International Forwarding andTransport）メッセージのユースケースによる説明が行われた。

４．４ 自動車製造プロジェクト（Automotive）
自動車製造プロジェクトには29名が参加。日本からは菅又久直（SIPS）、高橋一裕（NEC）、遠城秀和（NTTD）の3名が参加した。
自動車製造プロジェクトリーダーのRob Exellより、プロジェクトの目的とスコープにつき説明と意見交換が行われた。


自動車製造プロセス関連メッセージ（現在はEDIFACT）をAPI化するため

10

に、EDIFACTメッセージをSCRDM（サプライチェーン参照データモデル）にマッピングする。


対象とするプロセスはスケジューリング（Delivery ForecastとSupplyInstruction）及び納入・受領（Dispatch AdviceとReceiving Advice）である。



SCRDMへのマッピングにおいて、メッセージ構造上の違いがあり、現在のスケジューリング（特にDemand Forecast）メッセージの変更が必要となる。

Demand Forecastのメッセージ構造変更について、欧州航空宇宙業界（BoostAero）のSamy Schemama氏より反対が表明された。

４．５ 新規プロジェクト提案
サプライチェーン・ドメイン会議総括には21名が参加。日本からは菅又久直（SIPS）、高橋一裕（NEC）、藤森英明（NEC）、柳紀夫（NEC）、安達辰巳（NEC）、田部尚志（NEC）、佐藤友昭（NES）、藤田延介（SEC）、工藤裕子（中央大学）の9名が参加した。
サプライチェーン・ドメイン会議総括において、次の新規提案についてドメイン内で検討を進めることが合意された。
JSON-LDサブセット構築を目指すためにAPI Town Planプロジェクトを加速化する。



自動車業界の要件に従ってRDM2APIガイダンスをテストすることを提案。

CEN/TC440 Orderのビジネス用語にマッピングした業界横断注文メッセージ（CI Order）の実装サブセット（Syntax Binding）開発プロジェクトを提案する。

CEN/TC434とCEN/TC440とのリエゾン関係を構築するよう事務局に要求する。

５．技術仕様ドメイン会議（Specification Domain）
技術仕様ドメイン会議には16名が参加。日本からは菅又久直（SIPS）、遠城秀和（NTTD）の2名が参加した。
技術仕様ドメイン会議では、技術仕様メインテナンスとAPIプロジェクトをテーマに次の審議が行われた。
（１） 技術仕様メインテナンス
日本からの提案による「メッセージ構築ガイド」プロジェクト（2020年8月完了）で指摘した、NDR（XMLメッセージ設計規則）とCCBDA（ビジネス文書構築仕様）の不備及び不明瞭箇所の修正についての技術仕様メインテナンス要求につき審議を行った。

11

修正指摘箇所は次の通り。
NDR


XMLスキーマ定義における「必須」の備考（Annotation）を「任意」にする。

XMLスキーマモジュールにあるコードリスト・モジュールを任意に入れ替えることができるようにする。

CCBDA

ヘッダー／エンベロープ（XHE）の使用を「任意」にする。

定義規則の内、編集上の間違えを正す。

定義規則の内、不明瞭な個所を明快な文書に書き換える。

当該メインテナンス要求は、国連CEFACTオープン開発手順（ODP: OpenDevelopment Process）で規定する本質的でない変更（Non-substantiverevisions）に該当するとの判断から、それぞれの改訂版を策定する変更要求プロジェクトを提案することとした。
XHE（ヘッダー／エンベロープ）
XHEプロジェクトは2020年6月に完了し技術仕様は公開済であるが、XHEのデータモデルの情報項目が国連CEFACT共通辞書（CCL）に登録がないため、必要なCC/BIEを追加申請することとした。
なお、XHEはebXML環境（SOAPベース）を想定した仕様であり、EDIFACT（UNBセグメント）やAPI環境（HTTP）への適用は想定されていない。それらの環境におけるヘッダー／エンベロープ機能（ラウティング等）要求にどう応えるか検討が必要となっている。

（２） APIプロジェクト
RDM2API（参照データモデルのAPI化）プロジェクト
RDM2APIプロジェクトでは次の３つのドラフト仕様が提案されている。
Open API Design Rules：
JSON-LDで定義された情報項目（Class, Property, Code Values）
から国連APIリソースを構築する設計規則を規定。

RDM2API JASON Guide：
参照データモデルからJSON-LDの情報項目を定義する設計規則。

UML Profile Guideline：
UMLツール（例：StarUML）を使ったOpen API Designの実装法。

これらドラフト版を正式な国連CEFACT技術仕様として公開する必要がある。
API Town Planプロジェクト
API Town Planプロジェクトでは、APIリソース管理のためのドメイン・

12

マップを定義し、APIリソースの公開及び変更に関わる手順を規定しようとしている。

APIプロジェクトに対するリクアイアメント
Joerg Wather氏（自動車業界）より、ABIEクラス間のアソシエーション（ASBIE）を変数化する手法の必要性、およびAPIエクステンションにつきリクアイアメントが提言された。
（ASBIE変数化：Qualified Association）
クラスA

クラスB

変数ASBIE(ex. Role)

Buyer
SellerAgent

なお、ASBIE変数化については、API仕様にとどまらず、CCTS（コアコンポーネント技術仕様）、CCBDA（ビジネス文書構築法）及びNDR（XMLメッセージ設計規則）についても合わせて検討する必要があろう。
６．コードリスト管理（Code List Management）
コードリスト管理についての議論には17名が参加。日本からは菅又久直（SIPS）、遠城秀和（NTTD）、鈴木耀夫（JTREC）の3名が参加した。
国連CEFACTで定義しているコードリストには、次の種類がある。
UN/EDIFACTデータ要素関連のUNCL（国連CEFACTコードリスト）



国連CEFACT勧告（Recommendation）で定義されたコードリスト



外部国際標準化機関（ISOなど）が提供するコードリスト

議論はGerhard Heemskerk氏（SCM参照データモデル・プロジェクト編集リーダ）

13

による次の課題提起を中心に、手法・技術PDA担当副議長Marek Laskowski氏の司会により進められた。
EDIFACTに無いデータ要素のコードリスト
新たに国際標準として使いたいコードリストがあっても、対応するUN/EDIFACTデータ要素が定義されていないとUNCLに追加することができな
い。特に、UN/EDIFACTがカバーしていない新しい分野（農業、漁業、繊維など）のコードリストは特定ドメインの管理機関が独自に管理するものとなり、コードリストが国連CEFACTの公開WEBサイトから検索できない。
小生からは、それらは新たな国連CEFACT勧告として登録することが可能との意
見を表明した。

コンピュータでアクセス出来ないコードリストフォーマット
国連CEFACTメッセージ（EDIFACT、XML、JSON-LD）のコードリストへのアクセスは、UNCLか国連CEFACT勧告かISOかによりバラバラである。



UNCL：テキスト形式

XMLメッセージ用：XMLスキーマ

APIメッセージ：JSON-LDモジュール

国連CEFACT勧告：勧告文書内のテキストまたは添付EXCEL

ISOコード：ISO公開文書内のテキスト修飾データ型に固定的に定義されているコードリスト
国連CEFACT共通辞書（CCL）に、特定のデータ要素（BBIE）に結びつけられている修飾データ型で使用するコードリストが固定化されているものがある。
XMLメッセージ設計技術仕様（NDR）で、コードリスト・モジュールの自由選
択（Decoupling）が認められるようになったが、当該修飾データ型の扱いについては決められていない。



コード値の定義文の欠如
コードリストの発行形式（UNCL、XMLスキーマ、JSON-LD、国連CEFACT勧告、ISOコード）によりコード値の定義（Annotation）記述がことなる。また曖
昧な定義記述があり、実装時に混乱を来たす。

以上の議論が行われたうえで、コードリスト設定・公開・管理全般を規定する枠組みガイド（Town Plan）が必要であることが合意された。近々、コードリストTown
Planプロジェクトが開始されることが期待される。
７．クロージングセッション（Closing Session）
クロージングセッションには60名が参加。日本からは菅又久直（SIPS）、鈴木耀夫（JTREC）、清友大造（JASTPRO）、島野繁弘（Legoliss）、遠城秀和（NTTD）、石原直、中込昌治、鬼頭吉雄の8名が参加した。

14

当セッションでは、各PDA担当副議長より、それぞれのPDA及びドメインの活動概要報告がなされた。
事務局より今オンライン・フォーラムには世界中から約50か国、約400名（下図参照）の参加があった報告がなされた。
なお、次回フォーラムの時期・形式・場所については6月～7月ごろに決定するとの通知があった。

参加者の世界分布
以上15