Green x Digital コンソーシアム

データ連携のための技術仕様
Version 1.0

2023年8月4日

Green x Digitalコンソーシアム 見える化WG
データフォーマット・連携検討SWG

目次
1.

2.

3.

はじめに ................................................................................................................. 2
1.1.

本文書の位置づけ ................................................................................................ 2

1.2.

本文書の背景 .................................................................................................... 3

1.3.

本文書の目的 .................................................................................................... 4

1.4.

本文書の対象 .................................................................................................... 4

共通データフォーマット .................................................................................................. 5
2.1.

データフォーマットの共通化の目的................................................................................ 52.2.

共通データフォーマットの方針 ..................................................................................... 5

2.3.

共通データフォーマットの詳細 ..................................................................................... 6

2.3.1.

グローバル共通項目と独自項目の整理.................................................................... 6

2.3.2.

グローバル共通項目......................................................................................... 7

2.3.3.

Green x Digital コンソーシム独自項目................................................................ 17

データ連携プラットフォーム ............................................................................................ 20
3.1.

データ連携プラットフォームの考え方 ............................................................................ 20

3.2.

データ連携仕様 ................................................................................................. 21

3.2.1.

想定されるデータ連携のパターン.......................................................................... 22

3.2.2.

Pathfinder Network API ............................................................................. 24

3.2.3.

Green x Digital コンソーシム独自 API ................................................................ 24

1

1. はじめに1.1. 本文書の位置づけ
本文書は、サプライチェーン全体でデジタル技術を活用して共有すべき CO2 データの共通データフォーマットやデータプラットフォームの在り方を示す文書である。
作成者は、Green x Digital コンソーシアムの「見える化 WG（ワーキンググループ）」の下部組織として設置された「データフォーマット・連携検討 SWG（サブワーキンググループ）」である。
「見える化 WG」は、デジタル技術を活用し、サプライチェーン全体の CO2 データの見える化を進め、削減努力
がデータとして適切に反映される仕組みの構築を目指す作業部会であり、図 1 で示すように、下部組織として、サ
プライチェーン全体でデジタル技術を活用して共有される CO2 データの算定方法やデータ共有時の開示項目等の検討を担当する「ルール化検討 SWG」と、それらの CO2 データをデジタル技術を活用して交換する際の共通デー
タフォーマットやデータプラットフォームの在り方等の検討を担当する「データフォーマット・連携検討 SWG」を設置している。

図 1 データフォーマット・連携検討 SWG と本文書の位置づけ

本文書は、「データフォーマット・連携検討 SWG」の検討結果を踏まえ、リーダーおよびサブリーダーが主たる執筆者となり、SWG メンバーからの協力を得て、以下に関してそれぞれ取りまとめたものである。
（ア）「共通データフォーマット」の考え方と詳細仕様（イ）「データ連携プラットフォーム」の考え方

2

「データフォーマット・連携検討 SWG」のメンバーは表 1 のとおりである。
表 1 データフォーマット・連携検討 SWG の構成企業

リーダー

富士通

サブリーダーNTT データ、野村総合研究所

SWG メンバー

IHI、アスエネ、アマゾンウェブサービスジャパン、SBI R3 Japan、（五十音順）NTT データ、カコムス、ゼロボード、chaintope、デロイトトーマツ、
東芝、長瀬産業、日東電工、日本電気、野村総合研究所、
パナソニック ホールディングス、日立製作所、PwC コンサルティング、
富士通、三井物産、リコー

1.2. 本文書の背景
2050 年のカーボンニュートラル実現に向けてあらゆる産業においてサプライチェーン全体の脱炭素化が強く求められており、その達成には自社排出（スコープ 1、2）だけではなく、サプライチェーンの上流・下流からの排出（スコープ 3）を含むサプライチェーン CO2 排出量の正確な把握と削減努力が不可欠となる。
特に、スコープ 3 の中でも「調達品の CO2 排出量（カテゴリー1）」は、調達金額や調達量に業界平均値等の CO2 排出原単位を乗じる算定方法が一般的に採用されているが、この方法ではサプライヤーの削減努力を反映できないため、昨今、サプライヤーから CO2 排出量データを取得する働きかけが増えている。しかしここには大きく
2 点の課題がある。
一つ目は、サプライヤーからデータを提供することを前提とした共通的な CO2 排出量算定の方法論がなく、デー
タの品質にばらつきが生じることである。
二つ目は、「CO2 見える化」のソリューションが数多く開発されるなか、異なるソリューション間でデータ連携を行う
ための共通的なデータフォーマットや接続方式等がなく、サプライチェーンの中で異なるソリューションを使用している場合には、一気通貫での CO2 排出量把握が難しくなることである。
そこで、Green x Digital コンソーシアムの見える化 WG では、前述のとおり、下部組織として「ルール化検討
SWG」と「データフォーマット・連携検討 SWG」を設置し、「ルール化検討 SWG」では、サプライチェーン全体でデジタル技術を活用して共有される CO2 データの算定方法やデータ共有時の開示項目等を示す「CO2 可視化フレームワーク」を作成した。また、「データフォーマット・連携検討 SWG」では、デジタル技術を活用して CO2 データを交換する際の共通データフォーマットやデータプラットフォームの在り方等を検討し、本文書を作成した。
さらに、「CO2 可視化フレームワーク」と本文書に基づき、多様な業界の企業が共通的な方法で算定した排出量データを、異なるソリューション間でデータ連携し、サプライチェーン CO2 排出量を正確かつ効率的に把握できることを確認する実証実験1を 2022 年度後半～2023 年度前半にかけて実施することを計画している。（実証実1

実証実験プレスリリース https://www.gxdc.jp/pdf/press_release221209.pdf（2022 年 12 月 9 日）
https://www.gxdc.jp/pdf/press_release230215.pdf（2023 年 2 月 15 日）

3験は二段階を想定し、データ連携の技術的な検証を行う「フェーズ 1」、ユーザー企業も交えての CO2 算定も含めた実務的な検証を行う「フェーズ 2」と位置づけている。）

1.3. 本文書の目的
本文書は、“バージョン 1“であり、実証実験フェーズ２において異なるソリューション間でのデータ連携を行う際の共通的な技術仕様として、ソリューション提供企業が参照することを目的としている。
なお、実証実験終了後、その成果を踏まえて本文書を更新することを予定している。また、本文書内で参照している枠組みの仕様変更などが生じた際にも、本文書も適宜更新する予定である。

1.4. 本文書の対象
本文書は、Green x Digital コンソーシアムが「サプライチェーン全体でデジタル技術を活用して共有すべき」と結論付けた CO2 データを対象とする。
「ルール化検討 SWG」では、Scope3 スタンダードと同様、近年注目を集めるサプライチェーン CO2 データ交換の国際的なプラットフォーム／フレームワークである WBCSD Partnership for Carbon Transparency（PACT）2の「Pathfinder Framework」においても適用を推奨している「製品データに基づく算定」を前提としながら、実務において広く実施されている「組織データに基づく算定」も認め、「製品データに基づく算定」・「組織データに基づく算定」のいずれについても、Green x Digital コンソーシアムとしての算定方法を提示する（ルール化検討 SWG 作成「CO2 可視化フレームワーク」より）と結論付けている。
したがって、本文書の対象は、適用を推奨する「製品データに基づく算定データ」を主としつつ、「組織データに基づく算定」に対しても対応可能な属性を Green x Digital コンソーシム独自に追加したものとする。
なお、サプライチェーン全体でデジタル技術を活用して共有される CO2 データの算定方法やデータ共有時の開示項目等の検討は「ルール化検討 SWG」が担当することになっており、本文書では対象としない。別途、同 SWGが発行する「CO2 可視化フレームワーク」を参照いただきたい。

2

WBCSD Partnership for Carbon Transparency（PACT）について
WBCSD（持続可能な開発のための世界経済人会議）は、持続可能な開発を目指す企業約 200 社の CEO 連合体。GHG プロトコルの主催団体。Partnership for Carbon Transparency (PACT) は、WBCSD の下、バリューチェーンにおける排出量の透明性を高めて脱炭素化を加速することを目的として活動。排出量データ交換に必要な方法論的・技術的基礎を定義し、Pathfinder Framework ならびに Pathfinder Network として公表中。
Green x Digital コンソーシアムは、PACT のエコシステムにコラボレーターとして参画。
Web サイト：https://www.carbon-transparency.com/

42. 共通データフォーマット
2.1. データフォーマットの共通化の目的
グローバルでのサプライチェーン全体の脱炭素化を目指すためには、サプライチェーン全体の CO2 排出量（特にscope3）の正確な把握が必要となる。特に、サプライヤーの削減努力が反映されるよう、scope3 の算出に、サプライヤー企業から提供される一次データを利用していくことが必要となるものの、それらサプライヤー企業から提供されるデータは、受領側企業の活用事例や、提供側・受領側それぞれの企業が社内で利用していている CO2 可視化ソリューション（以降、「見える化ソリューション」と呼ぶ。）によって多種多様に存在しているのが現状である。
一方で、サプライチェーン CO2 データ交換に関する枠組みは、海外では WBCSD PACT の「Pathfinder
Framework」と「Pathfinder Network」が先行して取り組んでおり、グローバルに広がったサプライチェーン全体
での活動とするためには、国際的かつ異種システム間で相互運用の可能性を考慮する必要がある。
そのため、本 SWG では、サプライチェーン内に位置する中小企業等が対応でき、国際的なデータ交換・連携が可能となるような、CO2 データの情報伝達に資する共通データフォーマットを本文書にて示すこととした。

2.2. 共通データフォーマットの方針
共通データフォーマットを考えるうえで、既存の見える化ソリューションのデータ項目を分析し、最小公倍数として項目を設定する方法が考えられる。一方で、ルール化 SWG の検討成果物である「CO2 可視化フレームワーク」の内容を実現するような共通データフォーマットを作成することも考えられる。また、見える化 WG ではデータ活用について検討されており、データ活用を実現するような共通データ項目を用意するという考え方もありうる。さらに、世界に目を向けると WBCSD PACT が Pathfinder Network 技術仕様 v1.0.03を 2022 年 6 月 16 日に公表しており、その中でデータ共有のための共通データ項目を定めている。このような状況を踏まえ、本ガイドラインは、
共通データ項目について、以下の視点から設定する。


ルール化検討 SWG の成果物である「CO2 可視化フレームワーク」の内容に基づくデータ項目とする。



サプライチェーンは、グローバルに広がっているため国際的な活動に則したものとする。具体的には、
Pathfinder Network および関連文書（Use Case 001 等）との連携を考慮する。

3

ソリューションユーザーによるデータ活用への対応も考慮する。

https://www.carbon-transparency.com/media/1qcdbdyn/pathfinder-network_technical-

specifications-for-use-case-001.pdf
V1.0.0 に続き、2023 年 1 月 25 日に公表された Pathfinder Framework v2 に合わせて、同年 2 月 21 日に
v2.0.0 が公表された。https://wbcsd.github.io/tr/2023/data-exchange-protocol-20230221/

5なお、ルール化検討 SWG の成果物である「CO2 可視化フレームワーク」では、データ交換の単位について、「組織レベル算定」では「製品単位（kg-CO2e/kg, kg-CO2e/L 等）」と「取引金額/取引量単位（kg-CO2e/〇〇万円、kg-CO2e/〇〇kg 等）」のいずれを用いてもよいとされているが、Green x Digital コンソーシムでは「製品レベル算定」を推奨しているため、「組織レベル算定」においてもデータ交換される単位は「製品単位」が望ましいと考え、本文書においてデータフォーマットとして共通化する対象は「製品レベル算定」と「組織レベル算定の製品単位宣言」のみとする。

2.3. 共通データフォーマットの詳細
2.3.1. グローバル共通項目と独自項目の整理
共通データフォーマットは「グローバル共通項目」と「Green x Digital コンソーシム独自項目」にわけて整理する。
グローバル共通項目は、原則として「Pathfinder Network Technical specifications for Use Case
001 version 1.0.0（2022 年 6 月 16 日発行）」に定義されているデータモデル（以下 Pathfinder
Network データモデル）に準拠するが、一部、Green x Digital コンソーシアムの独自仕様を含む（詳細は細目を参照）。
Green x Digital コンソーシアム独自項目は、「CO2 可視化フレームワーク」においてデータ活用等を考慮して独自に追加した項目であり、実証実験フェーズ２において、その有用性等の検証を行う予定である。独自項目については、今後、「Pathfinder Network: Guidance and criteria catalog for data model
extensions（2022 年 11 月 3 日発行）4」と照らし合わせデータモデル拡張項目とすることを想定しており、PoC から得られたフィードバックの共有しつつ PACT と協力を進めている。
なお、以下は、事項以降の項目詳細の記載に関する留意点である。


要求レベルは Mandatory（必須）、Optional（任意）、Recommendation（推奨）のいずれかであり、Mandatory であるものは、必ずデータに含まれていなければならない。



データは HTTP ペイロードとして表現されるときは JSON 形式となるため、JSON のデータ型をそれぞれ記載している。



小数を許可する項目（fossilGhgEmissions など）については、暫定的に、有効数字を 16 桁に定めた。



PACT へ問合せを行った結果などに基づいて一部詳細化を行った内容、また、今後の検討課題については、「補足」として四角枠で囲って記載した。

4

Guidance and Criteria Catalog for Pathfinder Data Model Extensions:
https://wbcsd.github.io/data-model-extensions/guidance/
Technical Specification for Data Model Extensions: https://wbcsd.github.io/data-model-

extensions/spec/
これらの文書は以下 URL にリストアップされている。
https://www.carbon-transparency.com/our-approach/pathfinder-network6

グローバル共通項目に一部含まれる Green x Digital コンソーシアム独自仕様については、下線を引いて記載している。

2.3.2. グローバル共通項目
Pathfinder Network データモデルの細目は以下のとおりである。仕様の詳細は、「Pathfinder Network
Technical specifications for Use Case 001 version 1.0.0（2022 年 6 月 16 日発行）」を参照する
こと。
2.3.2.1.
項目名id：データ ID

要求レベル：Mandatory
JSON データ型：String
ProductFootprint の識別子。プラットフォーム間で連携される個々のデータの識別に用いる。RFC4122 で規定される UUID (Universally Unique Identifier) version 4 でなければならない。
2.3.2.2.
項目名

specVersion：データモデル仕様バージョン

要求レベル：Mandatory
JSON データ型：String
PACT で管理されるデータモデル仕様のバージョン。正規表現\d+\.\d+\.\d+で表現される文字列。
2.3.2.3.
項目名version：データバージョン

要求レベル：Mandatory
JSON データ型：Number
ProductFootprint のバージョン。データ生成直後は 0 で、更新されるたびにインクリメントされる。
2.3.2.4.
項目名created：生成日時
7

要求レベル：Mandatory
JSON データ型：String
プラットフォームでデータが生成された日時。ISO8601 に準拠した文字列でなければならない（タイムゾーンはUTC でなければならない）。
2.3.2.5.
項目名updated：更新日時

要求レベル：Optional
JSON データ型：String
プラットフォームでデータが更新された日時。ISO8601 に準拠した文字列でなければならない（タイムゾーンはUTC でなければならない）。
2.3.2.6.
項目名companyName：企業名

要求レベル：Mandatory
JSON データ型：String
データの所有者の名前を表す文字列。後述の companyIds による所有者の識別を補完する目的で用いられる。
長さ 1 以上の文字列でなければならない。
2.3.2.7.
項目名companyIds：企業 ID

要求レベル：Mandatory
JSON データ型：Array<String>
データの所有者を一意に識別する URN（Uniform Resource Name）を要素に持つ空でない配列。
［補足］
DUNS Number/ISIN/Ticker コード等の一意に特定できる企業 ID。
URN はグローバルで一意に企業を識別できるような GLN（Global Location Number）や OID（Object
Identifier）など、IANA に登録されている名前空間であれば利用可能。
IANA に登録されていないような、業界固有の識別子などの対応については PACT で拡張仕様を策定中。

8

2.3.2.8.
項目名productDescription：製品説明

要求レベル：Mandatory
JSON データ型：String
対象製品の生産技術やパッケージングなどに関する情報を自由形式で記述できる。空文字可。
2.3.2.9.
項目名productIds：製品 ID

要求レベル：Mandatory
JSON データ型：Array<String>
対象製品を一意に識別する URN（Uniform Resource Name）を要素に持つ空でない配列。
［補足］
URN はグローバルで一意に製品を識別できるような GTIN（Global Trade Item Number）や OID（Object Identifier）など、IANA に登録されている名前空間であれば利用可能。IANA に登録されていない
ような、業界固有の識別子や企業固有のコード体系などの対応については PACT で拡張仕様を策定中。
2.3.2.10.
項目名productCategoryCpc：製品分類（CPC コード）

要求レベル：Mandatory
JSON データ型：String
対象製品を分類するための UN CPC コード（Central Product Classification Code）version 2.1 の値。
空文字可。
2.3.2.11.
項目名productNameCompany：製品名

要求レベル：Mandatory
JSON データ型：String
対象製品の取引名称。前述の productIds による製品の識別を補完する目的で用いられる（例えば製品のカスタマイズに関する情報など）。長さ 1 以上の文字列でなければならない。
9

2.3.2.12.
項目名comment：コメント

要求レベル：Mandatory
JSON データ型：String
カーボンフットプリントの計算に関する情報や指示、またはデータの解釈、監査、検証の可能性に関する情報に使用することができる。空文字可。
［補足］

監査・検証の方法を定義するのであれば、システムとして解釈しやすいよう、自由形式ではなく別途プロパティを定義するべきかについては、今後の検討課題である。

2.3.2.13.
項目名pcf：製品カーボンフットプリント

要求レベル：Mandatory
JSON データ型：Object
前述のプロパティによって識別される製品のカーボンフットプリントとその関連データ。以下の各プロパティを含む。
2.3.2.13.1.
項目名declaredUnit：提供する CO2 データの宣言単位

要求レベル：Mandatory
JSON データ型：String
以下のいずれかの値を設定できる。
・

liter：ℓ・kilogram：㎏

・

cubic meter：㎥

・kilowatt hour：kWh・

megajoule：MJ・

ton kilometer：t・km

・square meter：㎡

10

［補足］


単位に「個」を含めることについて、PACT に確認した結果、「個」には主観が入る懸念があり、比較可能性を維持することを考慮し除外しているとの回答があった。一方、Green x Digital コンソーシアムのメンバー企業
からは「個」を追加したいとの要望もあり、引き続き PACT と協議していく方針。

2.3.2.13.2.
項目名unitaryProductAmount：宣言単位に対する量要求レベル：Mandatory
JSON データ型：String
declaredUnit に対する量。ゼロでない正の数値（少数含む）。
2.3.2.13.3.
項目名fossilGhgEmissions：燃料由来炭素排出量

要求レベル：Mandatory
JSON データ型：String
化石資源の燃焼による排出量。declaredUnit で定めた単位毎に、1kg あたりの CO2 換算量により計算されなければならない（kg-CO2eq / declaredUnit）。ゼロ以上の数値（少数含む）。
計算方法については CO2 可視化フレームワークまたは Pathfinder Framework を参照。
2.3.2.13.4.
項目名biogenicEmissions：生物由来炭素排出量

要求レベル：Optional
JSON データ型：Object
生物由来による排出量（GHG Protocol FLAGStandard を参照）。設定する場合、以下に定義する 3 プロ
パティのうち、最低限 1 つが設定されている必要がある。
・

landUseEmissions・

landUseChangeEmissions

・otherEmissions

112.3.2.13.4.1. landUseEmissions
項目名：土地利用排出量

要求レベル：Optional
JSON データ型：String
土地利用による排出量（例：文化的慣習）。ゼロ以上または以下の数値（小数含む）。
2.3.2.13.4.2. landUseChangeEmissions
項目名：土地利用変化排出量

要求レベル：Optional
JSON データ型：String
土地利用変化による排出量（例：森林破壊によるもの）。ゼロ以上または以下の数値（小数含む）。
利用可能な場合は直接土地利用変化量（dLUC）を含まなければならない。そうでない場合は統計的土地利用変化量（dLUC）を使用することができる。また、間接的土地利用変化（iLUC）の利用は任意とする。
2.3.2.13.4.3. otherEmissions
項目名：その他排出量

要求レベル：Optional
JSON データ型：String
その他の排出量（例：生物起源廃棄物処理) 。ゼロ以上または以下の数値（小数含む）。
2.3.2.13.5.
項目名biogenicCarbonContent：生物由来炭素含有量

要求レベル：Mandatory
JSON データ型：String
生物由来炭素の質量（kgC / declaredUnit）。ゼロ以上の数値（少数含む）。
2.3.2.13.6.
項目名reportingPeriodStart：データ収集期間（開始）12要求レベル：Mandatory
JSON データ型：String
報告開始日時。ISO8601 に準拠した文字列でなければならない（タイムゾーンは UTC でなければならない）。
詳細は CO2 可視化フレームワークまたは Pathfinder Framework を参照。
2.3.2.13.7.
項目名reportingPeriodEnd：データ収集期間（終了）

要求レベル：Mandatory
JSON データ型：String
報告終了日時。ISO8601 に準拠した文字列でなければならない（タイムゾーンは UTC でなければならない）。
詳細は CO2 可視化フレームワークまたは Pathfinder Framework を参照。
2.3.2.13.8.
項目名geographyCountrySubdivision：データ収集を行った地理的範囲（区画）

要求レベル：Optional
JSON データ型：String
地理的粒度が行政区画（例えば東京都）の場合はこのプロパティを定義しなければならない（その場合geographyCountry や geographyRegionOrSubregion を含めてはならない）。ISO 3166-2 のいずれかの文字列を設定可能。
［補足］
東京の場合全国地方公共団体コードは JP-13。
2.3.2.13.9.
項目名geographyCountry：データ収集を行った地理的範囲（国）要求レベル：Optional
JSON データ型：String
地理的粒度が国（例えば日本国）の場合はこのプロパティを定義しなければならない（その場合geographyCountrySubdivision や geographyRegionOrSubregion を 含 め て は な ら な い ） 。 ISO
3166-1 alpha-2 のいずれかの文字列を設定可能（例えば JP）。

13

2.3.2.13.10.
項目名geographyRegionOrSubregion：データ収集を行った地理的範囲（準地域）

要求レベル：Optional
JSON データ型：長さ 1 以上の String
地理的粒度が準地域的（例えばアジア全域）の場合はこのプロパティを定義しなければならない（その場合geographyCountrySubdivision や geographyCountry を含めてはならない）。Pathfinder Network
Technical specification for Use Case 0015の 17～18 ページに記載のいずれかの文字列を設定可能（例えば Asia）。
2.3.2.13.11.
項目名primaryDataShare：一次データ比率

要求レベル：Mandatory
JSON データ型：Number
一次データの割合（パーセンテージ）。ゼロから 100 までの数値（少数化）。
Green x Digital コンソーシアムの独自仕様：
組織レベル算定の際は"0"を設定する。
2.3.2.13.12.
項目名emissionFactorSources：二次データ排出係数

要求レベル：Optional
JSON データ型：Array<Objects>
設定する場合、以下のプロパティを含むオブジェクトを要素として持つ長さ 1 以上の配列を設定する。
2.3.2.13.12.1. name
項目名

：排出係数データベース名

要求レベル：(emissionFactorSources がある場合は)Mandatory
JSON データ型：String

5

https://wbcsd.github.io/data-exchange-protocol/#enumdef-regionorsubregion14排出係数のデータベース名を設定する。長さ 1 以上の文字列。
2.3.2.13.12.2. version
項目名：排出係数バージョン

要求レベル：(emissionFactorSources がある場合は)Mandatory
JSON データ型：String
排出係数データベースのバージョンを設定する。長さ 1 以上の文字列。
2.3.2.13.13.
項目名boundaryProcessesDescription：対象プロセス説明

要求レベル：Optional
JSON データ型：String
空文字可。例：生産段階でのインプットとして含まれる電力消費量
2.3.2.13.14.
項目名crossSectoralStandardsUsed：参照スタンダード（分野横断）

要求レベル：Mandatory
JSON データ型：Array<String>
排出量の計算や配分のために用いられた業界横断的なスタンダード。以下の文字列のすべてまたは一部を設定できる（空の配列は不可）。
・

GHG Protocol Product standard

・ISO Standard 14067

・

ISO Standard 14044

Green x Digital コンソーシアムの独自仕様：
・Green x Digital Product framework

・

GHG Protocol scope3 standard ※組織レベル算定用

・Green x Digital scope3 framework※組織レベル算定用

15

2.3.2.13.15.
項目名productOrSectorSpecificRules：参照スタンダード（製品または分野固有）

要求レベル：Mandatory
JSON データ型：Array<Object>
排出量の計算や配分に使用される規則（PCR など）。以下のプロパティをもつ Object を要素とする配列。規則に従っていなければ空の配列とする。
Green x Digital コンソーシアムの独自仕様：
組織レベル算定の際は空配列。
［補足］

日本国内の PCR を適用する場合に、otherOperatorName や ruleNames に何を設定するかを定義するべきかについては、今後の検討課題である。

2.3.2.13.15.1. operator
項目名：PCR 事業者

要求レベル：Mandatory
JSON データ型：String
以下のいずれかの文字列が指定できる。
・

PEF：EU Product Environmental Footprint

・

EPD International：EPD International・

Other：上記事業者が発行していない PCR の場合

2.3.2.13.15.2. ruleNames
項目名：PCR ルール名称

要求レベル：Mandatory
JSON データ型：Array<String>
長さ 1 以上の配列で、要素は長さ 1 以上の文字列。

16

2.3.2.13.15.3. otherOperatorName
項目名：PCR 事業者（その他）要求レベル：Optional
JSON データ型：String
operator で Other を設定した場合 PCR 事業者の名称を設定しなければならない。
2.3.2.13.16.
項目名allocationRulesDescription：割り当て規則

要求レベル：Optional
JSON データ型：String

適用される割り当て規則の説明。

2.3.3. Green x Digital コンソーシム独自項目
2.3.3.1.

項目名

gateToGate：Gate-to-Gate 用カラム

要求レベル：Recommendation
JSON データ型：Object
Cradle-to-Gate に加えて Gate-to-Gate の排出量が提供可能な場合に設定。
2.3.3.1.1.
項目名fossilGhgEmissions：Gate-to-Gate の燃料由来炭素排出量（提供する CO2 データの宣言単位あたり）

要求レベル：Recommendation
JSON データ型：String
Gate-to-Gate の、化石資源の燃焼による排出量。
「2.3.2.13.3. fossilGhgEmissions」の数値の内数として、自社よりも上流部分を除いた自社分のみを設定。
17

2.3.3.1.2.
項目名biogenicCarbonContent：Gate-to-Gate の生物由来炭素含有量（提供する CO2 データの宣言単位あたり）

要求レベル：Recommendation
JSON データ型：String
Gate-to-Gate の、生物由来炭素の質量（kgC / declaredUnit）。
「2.3.2.13.5. biogenicCarbonContent」の数値の内数として、自社よりも上流部分を除いた自社分のみを設定。
2.3.3.1.3.
項目名upstreamEmissions：サプライチェーン上流の排出量

要求レベル：Recommendation
JSON データ型：Array<Object>
直接取引のあるサプライチェーン上流企業から取得した gateToGate を配列で保持。
サプライチェーン最上流の際は空配列。
2.3.3.2.
項目名creditAmount 【Green x Digital コンソーシアム独自項目】：クレジット使用量

要求レベル：Optional
JSON データ型：String
宣言単位当たりのクレジット使用量（kg-CO2eq / declaredUnit）。
「クレジット使用量」「証書使用量」ともにデータ開示者が自ら調達し調整を行った使用量の報告を追加。
2.3.3.3.
項目名certificateAmount 【Green x Digital コンソーシアム独自項目】：証書使用量

要求レベル：Recommendation
JSON データ型：String
宣言単位当たりの証書使用量(kwh / declaredUnit)。
「クレジット使用量」「証書使用量」ともにデータ開示者が自ら調達し調整を行った使用量の報告を追加。
18

2.3.3.4.
項目名scope3Category 【Green x Digital コンソーシアム独自項目】：算定対象カテゴリ

要求レベル：Recommendation
JSON データ型：Array<Number>【組織レベル算定用】scope1,2 に加えて、scope3 について算定対象カテゴリを配列で設定。
例：[1, 4, 5]
2.3.3.5.
項目名distributionLevel 【Green x Digital コンソーシアム独自項目】：配分レベル

要求レベル：Recommendation
JSON データ型：String【組織レベル算定用】物理的な配分レベル/以下のいずれかを記載。
・organization：組織・site：拠点
・building：建屋・production line：生産ライン
2.3.3.6.
項目名distributionIndex 【Green x Digital コンソーシアム独自項目】：配分の指標要求レベル：Recommendation
JSON データ型：String【組織レベル算定用】物理的な配分の指標を記載/以下のいずれかを記載。
・volume：体積・unit：個数・JPY：生産高

19

3. データ連携プラットフォーム
3.1. データ連携プラットフォームの考え方
本 SWG において、データ連携プラットフォームのあるべき姿について検討を重ねた結果、Green x Digital コンソーシムとして整備すべきプラットフォームに関する考え方を下記のように結論付けた。
データ連携プラットフォームとして最初に検討した形は、「サプライチェーン CO2 の“見える化”のための仕組み構築に向けた検討（Green x Digital コンソーシアム見える化 WG 一次レポート6）」に以下のイメージ図のように掲載されていた「中央集権データベースモデル」である。データベースおよびサーバをコンソーシアム参加企業で共有するモデルである。このモデルでは、データ構造を統一し、可視性や耐改ざん性をサーバで集中管理できるメリットがある反面、コンソーシアムによる保守メンテナンスにかかる費用負担や運用のスキームを考える必要がある。

図 2 一次レポートによるデータ共有基盤のイメージ図

次に、非中央集権型の管理モデルの採用について検討を行った。非中央集権型管理モデルとしては以下のようにさまざまなものが考えられるが、ユーザー企業がさまざまな見える化ソリューションを既に導入しており、それらのソリューションベンダーごとのビジネス方針があることや、見える化ソリューションとデータ連携ソリューションとの連携には、提供企業自身で多大なシステムエンハンスをする必要が生じることもあり、Green x Digital コンソーシアムとして整備すべきプラットフォームとしての「あるべき姿」を描くことができなかった。

6https://www.gxdc.jp/pdf/achievement_report.pdf

20図 3 非中央集権型の管理モデルのイメージ図

また、いずれの場合においても、サプライチェーン内に位置する中小企業においては費用面での課題が大きくな
り、サプライチェーン全体でのデータ連携が困難となると考えられるため、コンソーシアムとしてのあるべき姿を下記のように結論付けた。
・「共通データプラットフォーム」を整備することはせず、共通化するのは「データフォーマット」のみとする。

・

サプライチェーンを構成する企業のデータ収受方法は BtoB 間での決定に委ねる（Pathfinder Network
では API 連携を想定しており、本文書においても API 連携をする場合の仕様を次節で記載し、実証実験においても API 接続モデルを採用して検証するが、データ連携方法をこれらに限定することはしない）。

3.2. データ連携仕様
本節では、見える化ソリューション（製品カーボンフットプリント算定アプリ等）およびデータ連携ソリューション（データ連携の際にトレーサビリティや対改ざん性などを具備した基盤サービス等）のソリューション間でデータ連携をする際に想定されるパターンと API 連携を行う場合の仕様について記載する。
なお、異なるソリューション間の製品カーボンフットプリント情報の交換・共有については、既に PACT より
Pathfinder Network の一部として API が公表されている。今後のグローバルでの GHG 排出量の共有ニーズを踏まえ、API 連携を行う場合は、第一段階として、Pathfinder Network API を通じて行うとともに、 Green x
Digital コンソーシアムの追加項目については、Green x Digital コンソーシアムデータ独自 API を用いてデータ交換を行うことを想定している。
次の段階として、業界や地域を超えて関連するデータ要素については Pathfinder Network API を通じたデータ交換を想定している。Green x Digital コンソーシアム独自のデータ要素については、Pathfinder Network21

のデータモデル拡張を使用し、これらの要素を共有することを想定している。

3.2.1. 想定されるデータ連携のパターン
データ連携の組み合わせは、①見える化ソリューションが Peer-to-peer で直結する場合、②見える化ソリュー
ションが何らかのデータ連携ソリューションと連携する場合、③データ連携ソリューション間での連携する場合、の 3 パ
ターンが考えられる。また、連携の方法として API を介す場合と API を用いない場合が想定される。
3.2.1.1.

見える化ソリューションが Peer-to-peer で直結する場合

この形態は PACT の想定と合致するため、各ソリューションが Pathfinder Network API および Green x
Digital コンソーシム独自 API を実装することで、共通の仕様でデータ連携を実現することができる。しかしどの製品がどのプラットフォームで管理されているかという情報が同 API では提供されないため、ソリューション外部で（あるいは内部に共通化して）製品とソリューションのマッピングデータを管理しておく必要が生じる。

見える化ソリューション A

見える化ソリューション B
Pathfinder Network API

製品 S

製品 T

および
G x D コンソ独自 API

部品 S

製品 S の活動量

製品 T の活動量

の登録

の登録

ユーザー企業

ユーザー企業図 4 見える化ソリューションが Peer-to-peer で直結する場合

3.2.1.2.

見える化ソリューションが何らかのデータ連携ソリューションと連携する場合

前述のとおり、見える化ソリューション同士のデータ連携ではソリューション外部のマッピングデータが必要であった。
データ連携ソリューションはこの役割を担うことで、見える化ソリューションが連結用に別途データを管理するコストを低減することができる（データ連携ソリューションへの接続だけを考慮すればよい）。また、データ連携の規模が大きくなれば、ソリューション間のネットワークが複雑化しその管理コストが発散することが考えられるが、データ連携ソリューションが接続を一元管理できればこれも緩和できる。ただし、データ連携ソリューションに何らかの理由で通信障害が発生すると、ネットワーク全体が機能不全に陥る可能性があるため、データ連携ソリューションには非対称的なコストの増大が発生しかねない。
22

見える化ソリューション B

データ連携

見える化ソリューション A

ソリューション X
製品 S

製品 T

製品 T
Pathfinder Network API

Pathfinder Network API

および

部品 S

G x D コンソ独自 API

部品 S

および
G x D コンソ独自 API

製品 T の活動量

製品 S の活動量
データ連携ソリューションはどの製品が

の登録

の登録

どの見える化ソリューションにあるかというマッピング情報を保持している

ユーザー企業

ユーザー企業図 5 見える化ソリューションが何らかのデータ連携ソリューションと連携する場合

3.2.1.3.

データ連携ソリューション間での連携

前述のとおり、見える化ソリューションのデータ連携においてデータ連携ソリューションを活用すると、ネットワーク構造を単純化できるものの、データ連携ソリューションのコストが極端に増大してしまうという問題があった。これを解消するためにデータ連携ソリューションを複数用意し、それらを相互運用することで、耐障害性を向上し、負荷を分散することができる。ただし、実現のためには、データ連携ソリューション間で情報を同期する方法などの標準化などのさらなる検討が必要となる。

データ連携
見える化ソリューション A

製品 S

ソリューション X
Pathfinder Network API

見える化ソリューション B
製品 T

製品 T

および
G x D コンソ独自 API

部品 S

部品 S

製品 S の活動量の登録

定期的に情報を同期

製品 T の活動量

Pathfinder Network API

データ連携
ソリューション Yの登録および
G x D コンソ独自 API

製品 T

ユーザー企業A

部品 S

ユーザー企業B

図 6 データ連携ソリューション間での連携
23

3.2.2. Pathfinder Network API
グローバル共通項目について API 連携を行う場合は Pathfinder Network API を用いる。
Pathfinder Network API の仕様は、「Pathfinder Network Technical specifications for Use Case
001 version 1.0.0（2022 年 6 月 16 日発行）」の p.30 以降の Use Case 001 HTTP REST API
Version 1.0.0 を参照すること。
3.2.3. Green x Digital コンソーシム独自 API
以下の通り、Green x Digital コンソーシアム独自の API 仕様を設けた。
なお、仕様においては、Pathfinder Network API との将来的な互換性を考慮し、Green x Digital コンソーシア
ムによる独自データモデルの追加に留め、Pathfinder Network API の技術仕様を可能な限り参照している。
また、認証は Pathfinder Network API の”Action Authenticate”に準拠する。

3.2.3.1.

get_list

get_list は、Pathfinder Network API の”Action ListFootpirnts”を参照している。原文からの変更点は、Request syntax のパス変更と Response parameters への Green x Digital Consortium による独自データモデル追加の 2 点である。
「created」または「updated」によるオプションのフィルタを使用して、製品フットプリントの一覧を取得する。
ホストシステムは、アクセス管理システムを実装し、データ所有者が要求元のデータ受信者へのアクセスを許可した製品フットプリントのみを返すべきである。
3.2.3.1.1.

リクエスト構文GET Subpath/JEITA/0/footprints?Filter HTTP/1.1
Host: Hostname
authorization: Bearer BearerToken
3.2.3.1.2.

リクエストパラメータ

Subpath:
ホストシステムが相対サブパスを使用する場合、要求元のデータ受信者は、このサブパスを追加する。
Hostname:
要求元のデータ受信者はホストシステムのドメイン名を使用しなければならない。
BearerToken:
24データ受信者は、アクション Authenticate からのレスポンス本文のプロパティ access_token の値をBearerToken として使用しなければならない。
Filter:Filter はオプションの要求パラメータです。定義する場合は、ODatav4 仕様で定義されている$filter 構
文に準拠する必要がある。$filter は、プロパティ「created」またはプロパティ「updated」のみを参照しなければならない。フィルタは、フィルタ操作 ge を指定しなければならない。
3.2.3.1.3.

レスポンス構文

HTTP/1.1 HttpStatusCode OKcontent-type: application/jsoncontent-length: ContentLengthBody
3.2.3.1.4.

レスポンスパラメータ

HttpStatusCode:
ホストシステムがアクセストークンを受け入れる場合、HttpStatusCode は 200 でなければならない。ホストシステムがエラー応答で応答する場合、HttpStatusCode はそれぞれのエラー応答コードの HTTP ステータス
コードと一致しなければならない。ホストシステムが ProductFootprints のリストを返さない場合、エラーHTTP ス
テータスコード(4 xx、5 xx)を返さなければならない。
ContentLength:
Body の長さ。RFC2616 参照。
Body:
ホストシステムがアクセストークンを受け入れる場合、本文は ProductFootprints のリストの値を持つプ
ロパティデータを持つ JSON オブジェクトでなければならない。リストは JSON 配列としてエンコードされなければならない。リストが空の場合、ホストシステムは空の JSON 配列を返さなければならない。
さらに、a) リクエストパラメータ Filter がプロパティ「updated」に対して定義されている場合、プロパティ「updated」が定義され、フィルタによって与えられたタイムスタンプ以上の値を持つ ProductFootprints
のみが Body に含まれるべきであるb) フィルタがプロパティ「created」に対するものである場合、フィルタによって与えられたタイムスタンプ以25

上の作成時刻を持つ ProductFootprints のみが Body に含まれるべきである
フィルタの例：$filter=updated ge 2020-03-01T00:00:00Z
ホストシステムがアクセストークンを受け入れない場合、Body は AccessDenied コードのエラー応答でなければならない。
もしホストシステムが期限切れのためにアクセストークンを受け入れないなら、Body はコード TokenExpired のエラー応答であるべきである。
他のすべての場合、例えばヘッダ認証の不正な値の場合、ボディはコード BadRequest のエラー応答であるべきである。
3.2.3.1.5.

例

リクエスト
GET example/0/footprints$filter=updated ge2022-12-14T06:00:00+09:00
HTTP/1.1
host: a.example.com
authorization: Bearer PIYOpiyoPIYOpiyoPIYOpiyo
レスポンス
HTTP/1.1 200 OK
content-type: application/jsoncontent-length: 300{"data":[{"id":"497f6eca-6276-4993-bfeb-53cbbbba6f08”"specVersion":"1.0.0","version":0,...,"pcf":{"declaredUnit":"kilogram","unitaryProductAmount":0.00204,"fossilGhgEmissions":"8.6",...,"gateTogate":{
...
26

},
...
}
}]}
3.2.3.2.

get_pcf

get_list は、Pathfinder Network API の”Action ListFootpirnts”を参照している。原文からの変更点
は、Request syntax のパス変更と Response parameters への Green x Digital Consortium による独
自データモデル追加の 2 点である。
製品フットプリントを取得する。
ホストシステムは、アクセス管理システムを実装し、データ所有者が要求元のデータ受信者へのアクセスを許可した製品フットプリントのみを返すべきである。
3.2.3.2.1.

リクエスト構文GET Subpath/JEITA/0/footprints?Filter HTTP/1.1
Host: Hostname
authorization: Bearer BearerToken
3.2.3.2.2.

リクエストパラメータ

Subpath:
ホストシステムが相対サブパスを使用する場合、要求元のデータ受信者は、このサブパスを追加する。
Hostname:
要求元のデータ受信者はホストシステムのドメイン名を使用しなければならない。
BearerToken:
データ受信者は、アクション Authenticate からのレスポンス本文のプロパティ access_token の値をBearerToken として使用しなければならない。
PfId:
要求元のデータ受信者は、取得しようとしている製品フットプリントの ID を PfId として使用しなければならない。
3.2.3.2.3.

レスポンス構文27

HTTP/1.1 HttpStatusCode OKcontent-type: application/jsoncontent-length: ContentLengthBody
3.2.3.2.4.

レスポンスパラメータ

HttpStatusCode:
ホストシステムがアクセストークンを受け入れる場合、HttpStatusCode は 200 でなければならない。ホストシステムがエラー応答で応答する場合、HttpStatusCode はそれぞれのエラー応答コードの HTTP ステータス
コードと一致しなければならない。ホストシステムが ProductFootprints のリストを返さない場合、エラーHTTP ス
テータスコード(4 xx、5 xx)を返さなければならない。
ContentLength:
Body の長さ。RFC2616 参照。
Body:
ホストシステムがアクセストークンを受け取り、要求元のデータ受信者に ProductFootprint へのアクセスを許可する場合、本文はプロパティデータを持つ JSON オブジェクトでなければならない。プロパティデータの値は、フットプリント識別子 PfId を持つ ProductFootprint でなければならない。識別子 PfId で ProductFootprint に変更があった場合、ホストシステムは識別子 PfId で識別される最新の ProductFootprint とプロパティバージョンの最大値を返す必要がある。
注意:ホストシステムにライフサイクルルールが実装されている場合、ProductFootprint の 「最新」 バージョンは、固定の PfId が与えられたバージョンの最大値を持つバージョンになります。
ホストシステムがアクセストークンを受け入れない場合、Body は AccessDenied コードのエラー応答でなければならない。
もしホストシステムが期限切れのためにアクセストークンを受け入れないなら、Body はコード TokenExpired のエラー応答であるべきである。
ホストシステムは、コード NoSuchFootprint でエラー応答を返してもよい。
他のすべての場合、例えばヘッダ認証の不正な値の場合、ボディはコード BadRequest のエラー応答であるべきである。

28

3.2.3.2.5.

例

リクエスト
GET example/0/footprints/497f6eca-6276-4993-bfeb-53cbbbba6f08 HTTP/1.1
host: a.example.com
authorization: Bearer PIYOpiyoPIYOpiyoPIYOpiyo
レスポンス
HTTP/1.1 200 OK
content-type: application/jsoncontent-length: 300{"data":{"id":“497f6eca-6276-4993-bfeb-53cbbbba6f08","specVersion":"1.0.0","version":0,...,"pcf":{"declaredUnit":"kilogram","unitaryProductAmount":0.00204,"fossilGhgEmissions":"8.6",...,"gateTogate":{
...
},
...
}
}}

29

本資料の著作権はGreen x Digitalコンソーシアムに帰属します。
本文書はWorld Business Council for Sustainable Development (WBCSD) の主催するPartnership for
Carbon Transparency (PACT)の「Pathfinder Network and Technical Specifications for PCF Data
Exchange」（version 1.0.1）に基づいて作成されたものです。本資料の使用に関連して生じたいかなるトラブル・損失・
損害・第三者からの請求などに対して、Green x Digitalコンソーシアムは一切の責任を負いません。

30