Green x Digital コンソーシアム

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

2024年7月29日

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.

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

2.3.3.

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

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

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

3.2.

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

3.2.1.

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

3.2.2.

Pathfinder Network API ............................................................................ 33

3.2.3.

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

3.3.

リファレンス....................................................................................................... 49

1

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

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

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

表 1 データフォーマット・連携検討 SWG の構成企業

リーダー

富士通

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

SWG メンバー

IHI、アスエネ、アマゾンウェブサービスジャパン、SBI R3 Japan

（五十音順）NTT データグループ、Sustech、ゼロボード、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 データを交換する際の共通データフォーマットやデータプラットフォームの在り方等を検討し、「データ連携のための技術仕様」
Version 1.0 を作成し 2023 年 8 月に公開した。
本文書は、2022 年度後半～2023 年度前半にかけて実施された「CO2 可視化フレームワーク
Edition1.0」と「データ連携のための技術仕様 Version 1.0」に基づき、多様な業界の企業が共通的な方法で算定した排出量データを、異なるソリューション間でデータ連携し、サプライチェーン CO2 排出量を正確かつ効率的

3

に把握できることを確認する実証実験1や、「CO2 可視化フレームワーク」の Edition2 への改版にともない改版作
成したものである。（実証実験は二段階にわたり、データ連携の技術的な検証を行う「フェーズ 1」、ユーザー企業も交えての CO2 算定も含めた実務的な検証を行う「フェーズ 2」と位置づけている。）

1.3. 本文書の目的
本文書は、“バージョン 2“であり、今後本文書内で参照している枠組みの仕様変更などが生じた際にも、本文書も適宜更新する予定である。

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 可視化フレームワーク」を参照いただきたい。

1

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

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 技術仕様 v2.0.13を 2023 年 9 月 27 日に、
v2.1.0 を 2023 年 12 月 7 日に公表しており、その中でデータ共有のための共通データ項目を定めている。このような状況を踏まえ、本ガイドラインは、共通データ項目について、以下の視点から設定する。


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



サプライチェーンは、グローバルに広がっているため国際的な活動に則したものとする。具体的には、PACT
Technical Specifications for PCF Data Exchange との連携を考慮する。

3

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

2023 年 1 月 25 日に公表された Pathfinder Framework v2 に合わせて、同年 2 月 21 日に v2.0.0 が公表された。さらに、2023 年 9 月 27 日に Version 2.0.1、同年 12 月 7 日に Version 2.1.0 が公開された。
(Version 2.0.0) https://wbcsd.github.io/tr/2023/data-exchange-protocol-20230221/(Version 2.0.1) https://wbcsd.github.io/tr/2023/data-exchange-protocol-20230927/(Version 2.1.0) https://wbcsd.github.io/tr/2023/data-exchange-protocol-20231207/

5

2.3. 共通データフォーマットの詳細
2.3.1. グローバル共通項目と独自項目の整理
共通データフォーマットは「グローバル共通項目」と「Green x Digital コンソーシム独自項目」にわけて整理する。
グローバル共通項目は、原則として「Pathfinder Network Technical Specifications for PCF Data
Exchange version 2.1.0（2023 年 12 月 7 日発行）」に定義されているデータモデル（以下 Pathfinder
Network データモデル）に準拠するが、一部、Green x Digital コンソーシアムの独自仕様を含む（詳細は細目を参照）。
Green x Digital コンソーシアム独自項目は、「CO2 可視化フレームワーク」においてデータ活用等を考慮して独自に追加した項目であり、実証実験フェーズ２において、「Pathfinder Network Technicalspecifications version 1.0.0（2022 年 6 月 16 日発行）」に基づいてその有用性等の検証を実施した。
※前述の実証実験プレスリリースを参照
なお、以下は、次項以降の項目詳細の記載に関する留意点である。


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



開示必須の項目に対応できていない場合でも、それを明示することでデータ交換を行うことは認められている。
対応が困難である場合は、上流サプライヤーからのデータ提供があるまでは、未対応でデータ交換を行う、というアプローチもあり得る。



Optional*は現状任意であるが 2025 年以降は定義必須となる項目である。（DQI 等）



データは HTTP ペイロードとして表現されるときは JSON 形式となるため、JSON のデータ型をそれぞれ記載している。（Object 型の場合は詳細のリンクを脚注に記載）



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



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

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

2.3.2. グローバル共通項目
Pathfinder Network データモデルの細目は以下のとおりである。仕様の詳細は、「Pathfinder Network
Technical Specifications for PCF Data Exchange version 2.1.0（2023 年 12 月 7 日発行）」4を参照すること。

4

PCF Data Exchange version 2.1.0

https://wbcsd.github.io/tr/2023/data-exchange-protocol-20231207/

6

2.3.2.1.
項目名id：データ ID

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

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

要求レベル：Mandatory
JSON データ型：String
PACT で管理されるデータモデル仕様のバージョン。Version 2.1.0 では「2.1.0」で表現される文字列。
2.3.2.3.
項目名precedingPfIds：上流 ProductFootprint の識別子セット

要求レベル：Optional
JSON データ型：Array<String>
メジャーアップデート等に伴い Deprecated になった ProductFootprint 識別子を要素に持つ配列。
定義されている場合、空でなく重複がない状態でなければならない（MUST）。
2.3.2.4.
項目名version：データバージョン（更新回数）

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

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

要求レベル：Optional
JSON データ型：String
プラットフォームでデータが更新された日時。ISO8601 に準拠した文字列（タイムゾーンは UTC）でなければならない（MUST）。
ProductFootprint を更新した場合に更新日時をプロパティへ含める必要がある (SHOULD) 。
更新が一度も実行されていない場合、ProductFootprint にこのプロパティを含めてはいけない (MUST NOT)
2.3.2.7.
項目名status：ステータス

要求レベル：Mandatory
JSON データ型：String
各 ProductFootprint の利用可否を表す文字列。
Active または Deprecated を設定しなければならない（MUST）。
Active：デフォルトの値。Active の場合は、データ受信者による製品カーボンフットプリントの計算に使用されうる（CAN）。
Deprecated：廃止された製品カーボンフットプリント。データ受信者による製品フットプリントの計算に使用すべきではない（SHOULD NOT）。
2.3.2.8.
項目名statusComment：ステータスコメント

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

8現在のステータスの理由を説明するコメント。
2.3.2.9.
項目名validityPeriodStart：ProductFootprint の有効期間の開始日

要求レベル：Optional
JSON データ型：String
データ受信者による ProductFootprint の使用に対して有効であると宣言される期間の開始日（ISO8601 に準拠した文字列）。
有効期間が指定されていない場合、ProductFootprint は 3 年間有効となる。
有効期間を指定する場合は、validityPeriodStart の日付は referencePeriodEnd の日付よりも後、もしくは等しい日付に設定する必要がある（MUST）。
また、validityPeriodEnd の日付を validityPeriodStart の日付より後、かつ referencePeriodEnd+3 年以内に設定する必要がある（MUST）。
※validityPeriodStart の日付は有効期間に含む、後述の validityPeriodEnd の日付は有効期間の対象に含まない。
2.3.2.10.
項目名validityPeriodEnd：ProductFootprint の有効期間の終了日

要求レベル：Optional
JSON データ型：String
データ受信者による ProductFootprint の使用に対して有効であると宣言される期間の終了日（ISO8601 に準拠した文字列）。
2.3.2.11.
項目名companyName：企業名

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

9

2.3.2.12.
項目名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 で拡張仕様を策定中。
2.3.2.13.
項目名productDescription：製品説明

要求レベル：Mandatory
JSON データ型：String
対象製品の生産技術やパッケージングなどに関する情報を自由形式で記述することができる。
空文字可。
2.3.2.14.
項目名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.15.
項目名productCategoryCpc：製品分類（CPC コード）10

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

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

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

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

2.3.2.18.
項目名extensions：データ拡張情報

要求レベル：Optional
JSON データ型：Array<String>
フォーマットの詳細は下記を参照。
https://wbcsd.github.io/data-model-extensions/spec /11

2.3.2.19.
項目名

pcf

：製品カーボンフットプリント

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

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

liter：ℓ・kilogram：㎏

・

cubic meter：㎥

・kilowatt hour：kWh・

megajoule：MJ・

ton kilometer：t・km

・square meter：㎡

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

yen:円

単位の定義は下記を参照。
Bureau International des Poids et Mesures5［補足］

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

5

Bureau International des Poids et Mesures (Table 8. Non-SI units accepted for use with

the SI units)
https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-EN.pdf/2d2b50bff2b4-9661-f402-5f9d66e4b507
12

からは「個」を追加したいとの要望もあり、引き続き PACT と協議していく方針。
2.3.2.19.2.
項目名unitaryProductAmount：製品量（宣言単位に対する量）要求レベル：Mandatory
JSON データ型：String
declaredUnit に対する量。ゼロ以上の数値（少数含む）でなければならない（MUST）。
2.3.2.19.3.
項目名

pCfExcludingBiogenic：総排出量（生物由来の排出と除去を含まない）

要求レベル：Mandatory
JSON データ型：String
生物由来の CO2 排出を除いた、製品の二酸化炭素排出量。
declaredUnit で定めた単位毎に、CO2 排出量が計算され（単位：kg-CO2eq / declaredUnit）、ゼロ以上の数値（小数含む）でなければならない（MUST）。
2.3.2.19.4.
項目名

pCfIncludingBiogenic：総排出量（生物由来の排出と除去を含む）

要求レベル：Optional*
JSON データ型：String
すべての生物起源の排出物 (CO2 等)を含む製品の二酸化炭素排出量が計算され（単位：kg-CO2eq /declaredUnit）、正負含む数値（小数含む）でなければならない（MUST）。
2.3.2.19.5.
項目名fossilGhgEmissions：化石燃料由来の排出量

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

要求レベル：Mandatory
JSON データ型：String
化石炭素含有量（単位：kg-C / declaredUnit）。declaredUnit で定めた単位毎に炭素含有量が計算され（単位：kgC / declaredUnit）、ゼロ以上の数値（小数含む）でなければならない（MUST）。
2.3.2.19.7.
項目名biogenicCarbonContent：生物由来炭素含有量

要求レベル：Mandatory
JSON データ型：String
生物由来炭素の質量（kg-C / declaredUnit）。declaredUnit で定めた単位毎に炭素含有量が計算され（単位：kgC / declaredUnit）、ゼロ以下の数値（少数含む）でなければならない（MUST）。
2.3.2.19.8.
項目名dLucGhgEmissions：直接的な土地利用変化による排出量

要求レベル：Optional*
JSON データ型：String
対象の土地領域での利用変化における炭素ストック損失に起因した排出量（例：森林破壊によるもの）。
このプロパティの値には、直接的土地利用変化(dLUC) （単位：kg-CO2eq / declaredUnit）を含める必要がある（MUST）。declaredUnit で定めた単位毎に CO2 排出量が計算され（単位：kg-CO2eq /declaredUnit）、ゼロ以上の数値（小数含む）でなければならない（MUST）。
それ以外の場合は、統計的土地利用変化 (sLUC) を使用可能。
2.3.2.19.9.
項目名landManagementGhgEmissions：土地管理による排出量または除去量

要求レベル：Optional*
14

JSON データ型：String
非 CO2 発生源を含む、土地管理関連の変更に関連する GHG 排出量と除去量（単位：kg-CO2eq /declaredUnit）。declaredUnit で定めた単位毎に CO2 排出量が計算さ れ（ 単位：kg-CO2eq /declaredUnit）、正負含む数値（小数含む）でなければならない（MUST）。
2.3.2.19.10.
項目名otherBiogenicGhgEmissions：その他の生物由来炭素排出量

要求レベル：Optional*
JSON データ型：StringdLUC、iLUC および土地管理 ( landManagementGhgEmissions) には含まれない製品の製造および輸送に関連するその他すべての生物起源の GHG 排出量。
declaredUnit で定めた単位毎に CO2 排出量が計算され（単位：kg-CO2eq / declaredUnit）、ゼロ以上の数値（小数含む）でなければならない（MUST）。
2.3.2.19.11.
項目名

iLucGhgEmissions：間接的な土地利用変化による排出量

要求レベル：Optional
JSON データ型：String
企業またはそのサプライチェーンが所有または管理していない土地の土地転用による最近（過去 20 年間）の炭
素ストック損失に起因する排出量。
declaredUnit で定めた単位毎に CO2 排出量が計算され（単位：kg-CO2eq / declaredUnit）、ゼロ以上の数値（小数含む）でなければならない（MUST）。
2.3.2.19.12.
項目名biogenicCarbonWithdrawal：生物由来の除去量

要求レベル：Optional*
JSON データ型：String
製品に含まれる生物起源炭素を kg-CO2eq に換算した値。
declaredUnit で定めた単位毎に CO2 排出量が計算され（単位：kg-CO2eq / declaredUnit）、ゼロ以下の数値（少数含む）なければならない（MUST）。
15

2.3.2.19.13.
項目名aircraftGhgEmissions：航空機エンジン由来の排出量

要求レベル：Optional
JSON データ型：String
製品の輸送のための航空機エンジンの使用に起因する GHG 排出量。
declaredUnit で定めた単位毎に CO2 排出量が計算され（単位：kg-CO2eq / declaredUnit）、ゼロ以上の数値（小数含む）でなければならない（MUST）。
2.3.2.19.14.
項目名characterizationFactors：GWP 特性評価係数の IPCC バージョン

要求レベル：Mandatory
JSON データ型：String
PCF の計算に使用される GWP 特性評価係数の IPCC バージョン。
下記のいずれかを指定指定しなければならない（MUST）。
・AR6：IPCC の第 6 次評価報告書
・AR5：IPCC の第 5 次評価報告書
2.3.2.19.15.
項目名crossSectoralStandardsUsed：参照したスタンダード（業種横断）

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

GHG Protocol Product standard

・ISO Standard 14067

・

ISO Standard 14044

Green x Digital コンソーシアムの独自仕様：
・ISO Standard 14040

・ISO Standard 14025
16

・ISO T/S 14027

・Green x Digital Product framework ※CO2 可視化フレームワーク「製品ベース算定」

・

GHG Protocol scope3 standard ※GHG プロトコル「Scope3 スタンダード」

・Green x Digital scope3 framework ※CO2 可視化フレームワーク「組織ベース算定」※当項目は上記のようなスタンダードを想定しているが、これ以外の値も入ってくる自由記述の形であるため、当項目の値によって、組織ベース算定/製品ベース算定等のシステム的なチェックは実施しない。
2.3.2.19.16.
項目名productOrSectorSpecificRules：参照したルール（製品または業種固有）

要求レベル：Optional
JSON データ型：Array<Object>
排出量の計算や配分に使用される規則（PCR など）。以下のプロパティをもつ Object を要素とする配列。
規則に従っていなければ空の配列としなければならない（MUST）。
Green x Digital コンソーシアムの独自仕様：
組織ベース算定の際は空配列。
［補足］
日本国内の PCR を適用する場合に、otherOperatorName や ruleNames に何を設定するかを定義するべ
きかについては、今後の検討課題である。
2.3.2.19.16.1. operator
項目名：PCR 運営者

要求レベル：Mandatory
JSON データ型：String
以下のいずれかの文字列を指定しなければならない（MUST）。
・

・

PEF
➢

EU / PEF 手法の Product Category Rule の場合➢

EU Product Environmental FootprintEPD International➢・

EPD International によって作成または発行された Product Category Rule の場合

Other
17

➢

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

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

要求レベル：Mandatory
JSON データ型：Array<String>
長さ 1 以上の配列で、要素は長さ 1 以上の文字列。
2.3.2.19.16.3. otherOperatorName
項目名：他 PCR 運営者

要求レベル： optional
JSON データ型： NonEmptyString
operator プロパティが Other の場合、このプロパティに PCR 事業者名を含む必要がある（MUST）。
この場合、ProductOrSectorSpecificRuleOperator に定義された事業者を含んではならない（MUSTNOT）。
もし operator プロパティが Other でなければ、このプロパティは定義してはならない（MUST）。
2.3.2.19.17.
項目名biogenicAccountingMethodology：生物由来炭素の算定の方法論

要求レベル：Optional*
JSON データ型：String
生物起源の排出と除去を考慮するための規格を下記から指定しなければならない（MUST）。


PEF：EU 製品環境フットプリントガイド

ISO：ISO 14067 規格

GHGP：温室効果ガスプロトコル (GHGP) の土地部門と除去ガイダンス

Quantis：Quantis Accounting for Natural Climate Solutions のガイダンス

2.3.2.19.18.
項目名boundaryProcessesDescription：対象プロセスの説明

要求レベル：Mandatory18

JSON データ型：String
ライフサイクルの各段階に起因するプロセスの説明を記述する。空文字可。
例：生産段階でのインプットとして含まれる電力消費量
2.3.2.19.19.
項目名referencePeriodStart：データ収集期間（開始）

要求レベル：Mandatory
JSON データ型：String
報告開始日時。ISO8601 に準拠した文字列（タイムゾーンは UTC）でなければならない（MUST）。
PCF の有効期間は、有効期間内に製造工程に大きな変更がないことを条件に、最長 3 年とする。
大きな変更とは、当初の PCF と比較して 10％以上の差異が生じた場合を指す。
詳細は CO2 可視化フレームワークまたは Pathfinder Framework の 6.1.2.1 章を参照6。
2.3.2.19.20.
項目名referencePeriodEnd：データ収集期間（終了）

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

要求レベル：Optional
JSON データ型：String
地理的粒度が行政区画（例えば東京都）の場合はこのプロパティを定義しなければならない（その場合geographyCountry や geographyRegionOrSubregion を含めてはならない）。ISO 3166-2 のいずれか

6

6.1.2.1 章

https://www.carbon-transparency.com/media/srhhloun/pathfinder-framework.pdf

19

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

要求レベル：Optional
JSON データ型：長さ 1 以上の String
地理的粒度が準地域的（例えばアジア全域）の場合はこのプロパティを定義しなければならない（MUST）。
その場合 geographyCountrySubdivision や geographyCountry を含めてはならない。
Pathfinder Network Technical specificationv2.0.1 の下記を参照。（例：Asia）
https://wbcsd.github.io/data-exchange-protocol/v2/#enumdef-regionorsubregion
2.3.2.19.24.
項目名secondaryEmissionFactorSources：二次データ排出係数

要求レベル：Optional
JSON データ型：Array<Objects>
設定する場合、以下のプロパティを含むオブジェクトを要素として持つ長さ 1 以上の配列を設定する。
設定がない場合は undefined の定義が必要（MUST）。
2.3.2.19.24.1. name

20

項目名

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

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

要求レベル：(emissionFactorSources がある場合は)Mandatory
JSON データ型：String
排出係数データベースのバージョンを設定する。長さ 1 以上の文字列。
2.3.2.19.25.
項目名exemptedEmissionsPercent：カットオフ:%

要求レベル：Mandatory
JSON データ型：Number
PCF から除外される排出量の割合。
カットオフレート（考慮しなくても良い排出量を除外）。
0.0 から 5 の数値（少数含む）。
2.3.2.19.26.
項目名exemptedEmissionsDescription：カットオフ：説明

要求レベル：Mandatory
JSON データ型：String
PCF 排出量除外の理由を記載。
排出量が除外されない場合は空の文字列とする。
2.3.2.19.27.
項目名packagingEmissionsIncluded：梱包に起因する排出量のフラグ

要求レベル：Mandatory
21

JSON データ型：Boolean
パッケージング排出量が pCfExcludingBiogenic、pCfIncludingBiogenic に含まれるかどうかを示すブールフラ
グ。（true または false）
2.3.2.19.28.
項目名packagingGhgEmissions：製品の梱包に起因する排出量

要求レベル：Optional
JSON データ型：String
製品の梱包に起因する排出量。
declaredUnit で定めた単位毎に CO2 排出量が計算され（単位：kg-CO2eq / declaredUnit）、ゼロ以上の数値（小数含む）でなければならない（MUST）。
2.3.2.19.29.
項目名allocationRulesDescription：配分規則

要求レベル：Optional
JSON データ型：String
適用される配分規則の説明。
2.3.2.19.30.
項目名uncertaintyAssessmentDescription：不確実性評価の説明

要求レベル：Optional
JSON データ型：String
結果とその主要な要因、および不確実性評価の定性的な説明を記述。
1 次データが正確でない場合（データの信頼性がない、安定した値になっていない等）、２次データを使用した方が良いケースがあるためその注釈コメントとして記述する。
2.3.2.19.31.
項目名primaryDataShare：一次データ比率

要求レベル：Optional*
22

JSON データ型：Number
一次データの割合（パーセンテージ）。ゼロから 100 までの数値（少数化）。
Green x Digital コンソーシアムの独自仕様：
組織ベース算定の際は"0"を設定する。
2025 年の年初より前に終了する報告期間の場合は、少なくとも 1 つ primaryDataShare または dqi の各プ
ロパティを定義する必要がある。
2025 年の年初以降を含むレポート期間の場合、このプロパティを定義する必要がある。
2.3.2.19.32.
項目名

dqi

： データ品質評価指標（Data Quality Indicators）

要求レベル：Optional*
JSON データ型：Object
2025 年の年初より前に終了する報告期間の場合は、少なくとも 1 つ primaryDataShare または dqi の各プ
ロパティ7を定義する必要がある。
2025 年の年初以降を含むレポート期間の場合、このプロパティを定義する必要がある。
2.3.2.19.33.
項目名assurance： 保証情報要求レベル：Optional
JSON データ型：Object
Pathfinder Framework に準拠した保証情報8。

7

dqi の詳細（4.2.3 章：Data quality assessment）

https://www.carbon-transparency.com/media/srhhloun/pathfinder-framework.pdf
8

Tec spec 4.4. Data Type: Assurance

https://wbcsd.github.io/data-exchange-protocol/v2/#elementdef-assurance

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

項目名calcMethod 【Green x Digital コンソーシアム独自項目】：算定方法

要求レベル：Mandatory
JSON データ型：String※以下のいずれかを設定
製品ベース算定：0
組織ベース算定：1
2.3.3.2.

FWedition 【Green x Digital コンソーシアム独自項目】

項目名：フレームワーク Edition
要求レベル：Mandatory
JSON データ型:String
参照した CO2 可視化フレームワークの Edition。CO2 可視化フレームワーク Edition 2.0 を参照した場合は「2.0」

2.3.3.3.

項目名

gateToGate 【Green x Digital コンソーシアム独自項目】：Gate-to-Gate 用カラム

要求レベル：Recommendation
JSON データ型：Object
Cradle-to-Gate に加えて Gate-to-Gate の排出量が提供可能な場合に設定。
2.3.3.3.1.
項目名

gateToGateFossilGhgEmissions 【Green x Digital コンソーシアム独自項目】：Gate-to-Gate 排出量（生物由来の排出と除去を含まない）

要求レベル：Recommendation
JSON データ型：String24総排出量（生物由来の排出と除去を含まない）のうち、自社の Gate-to-Gate バウンダリからの排出量（kgCO2e）2.3.3.3.2.

gateToGateBiogenicCarbonContent 【Green x Digital コンソーシアム独自
項目】

項目名

：Gate-to-Gate 排出量（生物由来の排出と除去を含む）

要求レベル：Recommendation
JSON データ型：String
Gate-to-Gate の、生物由来炭素の質量（kgC / declaredUnit）。
「2.3.2.19.7. biogenicCarbonContent」の数値の内数として、自社よりも上流部分を除いた自社分のみを設定。
2.3.3.3.3.

unitaryProductAmountComment 【Green x Digital コンソーシアム独自項
目】

項目名：製品量 記述欄

要求レベル：Recommendation
JSON データ型：String「製品量」と「宣言単位」について説明を追加するための自由記述欄。
［補足］「組織ベース算定」で通貨単位（円、ドルなど）を宣言単位にするケースでは、製品単位の CO2 データか取引単位の CO2 データか区別が付きづらいため、本欄にて説明を行う。
2.3.3.4.
項目名certificateAmount 【Green x Digital コンソーシアム独自項目】：証書使用量（含む再エネ電力由来 J-クレジット）

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

25

2.3.3.5.
項目名certificateType 【Green x Digital コンソーシアム独自項目】：証書種類（含む再エネ電力由来 J-クレジット）

要求レベル：Recommendation
JSON データ型：String※記載例。
・renewable energy certificate：グリーン電力証書
・jcredit：J クレジット・nonfossil fuel certificate：非化石証書
2.3.3.6.
項目名scope3Category 【Green x Digital コンソーシアム独自項目】：算定対象カテゴリ

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

要求レベル：Mandatory
JSON データ型：String
2.3.3.8.
項目名scope2DistributionLevel 【Green x Digital コンソーシアム独自項目】：配分レベル Scope２

要求レベル：Mandatory
JSON データ型：String※【組織ベース算定用】Scope1~3 物理的な配分レベル/以下のいずれかを記載。
・organization：組織・site：拠点
・building：建屋・production line：生産ライン
26

2.3.3.9.
項目名scope1DistributionIndex 【Green x Digital コンソーシアム独自項目】：配分の指標 Scope1

要求レベル：Recommendation
JSON データ型：String
2.3.3.10.
項目名scope3DistributionLevel 【Green x Digital コンソーシアム独自項目】：配分レベル Scope３

要求レベル：Mandatory
JSON データ型：String※【組織ベース算定用】Scope1~3 物理的な配分レベル/以下のいずれかを記載。
※Scope3 は複数ある場合は支配的なレベルを記載
・organization：組織・site：拠点
・building：建屋・production line：生産ライン
2.3.3.11.
項目名distributionLevelComment 【Green x Digital コンソーシアム独自項目】：配分レベル 記述欄

要求レベル：Optional
JSON データ型：String「配分のレベル」をさらに詳細に記載するための自由記述欄
2.3.3.12.
項目名scope2DistributionIndex 【Green x Digital コンソーシアム独自項目】：配分の指標 Scope2

要求レベル：Recommendation
JSON データ型：String
2.3.3.13.
項目名scope3DistributionIndex 【Green x Digital コンソーシアム独自項目】：配分の指標 Scope3

要求レベル：Recommendation
27

JSON データ型：String※【組織ベース算定用】Scope1~3 物理的な配分の指標を記載/以下のいずれかを記載※Scope3 は複数ある場合は支配的な指標を記載
・volume：体積・unit：個数・JPY：生産高
2.3.3.14.
項目名distributionIndexComment 【Green x Digital コンソーシアム独自項目】：配分の指標 記述欄

要求レベル：Optional
JSON データ型：String「配分の指標」をさらに詳細に記載するための自由記述欄28

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

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

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

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

29図 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 Network30

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

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.

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

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

見える化ソリューション 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 データ連携ソリューション間での連携
32

3.2.2. Pathfinder Network API
グローバル共通項目について API 連携を行う場合は Pathfinder Network API を用いる。
Pathfinder Network API の仕様は、「Technical Specifications for PCF Data Exchange (Version
2.1.0)（2023 年 12 月 7 日発行）」の 6 章以降の HTTP REST API を参照すること。
3.2.3. Green x Digital コンソーシム独自 API
以下の通り、Green x Digital コンソーシアム独自の API 仕様を設けた。
なお、仕様においては、Pathfinder Network API との将来的な互換性を考慮し、Green x Digital コンソーシア
ムによる独自データモデルの追加に留め、Pathfinder Network API の技術仕様を可能な限り参照している。
ホストシステムは、以下のアクションを実装しなければならない。
・Action Authenticate
・Action ListFootprints
・Action GetFootprint
ホストシステムは、以下のアクションを実装するべきである。
・Action Events
ホストシステム は、https メソッドのみでアクションを提 供しなければならない。ホストシステム は、[OPENIDCONNECT]で指定された OpenId プロバイダ設定ドキュメントを提供するべきである。
ホストシステムは、トークンエンドポイント（アクション認証と OpenId プロバイダ設定ドキュメントから返されるエンドポイント）を除き、すべてのアクションを同じホスト名とサブパスで提供しなければならない。
ホ ス ト シ ス テ ム は 、 OpenId プ ロ バ イ ダ 設 定 ド キ ュ メ ン ト と ア ク シ ョ ン 認 証 を 、 ホ ス ト 名 と サ ブ パ ス と は 異 な る
AuthHostname と AuthSubpath で提供することができる。
ホストシステムが OpenId プロバイダ設定ドキュメントを提供しない場合、データ受信者は、アクション認証がAuthHostname/AuthSubpath/auth/token の下で提供されると想定しなければならない。
ホストシステムの DNS ドメイン名は example.org で、サブパスは/wbcsd である。一方、ID 管理システムはid.example.org ドメインを使用し、サブパスは空である。その場合、URI は以下のようになる：
OpenId プロバイダ設定ドキュメントの場合：https://id.example.org/.well-known/openidconfiguration
アクション認証の場合：https://id.example.org/auth/token
アクションリストフットプリントの場合：https://example.org/wbcsd/2/footprintsなど。

3.2.3.1.

Authenticate

クライアント認証情報を使用してアクセストークンをリクエストする。
ホストシステムは、このアクションを[rfc6749]セクション 4.4（OAuth2 クライアント認証情報）に準拠して実装しな
33

ければならない。ホストシステムは、専用の AuthHostname および AuthSubpath の下でこのアクションを提供してもよい。

3.2.3.1.1.

リクエスト構文

バージョン 2.0 の認証フローのみを実装するデータ受信者との下位互換性 のために、Host システムは、パス
AuthSubpath/auth/token とホスト名 AuthHostname の下でこのアクションを提供しなければならない。

POST AuthSubpath/auth/token HTTP/1.1
host: AuthHostname
accept: application/jsoncontent-type: application/x-www-form-urlencodedauthorization: Basic BasicAuth
content-length: ContentLength
AuthBody
また、ホストシステムが OpenId Connect をサポートしている場合、ホストシステムはこのアクションを第 2 の URL
で提供・実装し、この URL を OpenId プロバイダ設定ドキュメントの token_endpoint の値として設定することができます。
3.2.3.1.2.

リクエストパラメータ

AuthEndpoint：
認証フローを実行して値を検出した後、アクセストークンを要求するエンドポイント。
AuthSubpath：
ホストシステムがアクセストークンを作成する目的で専用の相対サブパスを使用している場合、リクエストするデータ受信者はこのサブパスを先頭に付加しなければならない。
AuthHostname：
リクエストするデータ受信者は、認証トークンを作成する目的でホストシステムが専用に使用しているドメイン名を使用しなければならない。
BasicAuth：
RFC6749 セクション 4.4.2 を参照。
ContentLength：
body の長さ。RFC9112 参照。

34

AuthBody：
RFC6749 セクション 4.4 参照。
クライアントは、以下のパラメータを追加してリクエストしなければならない。

grant_type：
必須。値は "client_credentials" に設定しなければならない。
scope：
任意。アクセス要求の範囲は、RFC6749 セクション 3.3 で説明されている。
3.2.3.1.3.

レスポンス構文

HTTP/1.1 AuthStatusCode OKcontent-type: application/jsoncontent-length: ContentLength
AuthResponseBody
3.2.3.1.4.

レスポンスパラメータ

AuthStatusCode：
RFC6749 セクション 4.4 およびセクション 5 に準拠した HTTP レスポンスコード。
AuthResponseBody：
認証が成功した場合は RFC 6749 セクション 4.4 (アクセス トークンを含む)、それ以外の場合は RFC 6749 セクション 5.2 に準拠する JSON オブジェクト。

3.2.3.1.5.

例

成功レスポンス{"access_token": "...","token_type": "bearer"}
エラーレスポンス
ユーザー名やパスワードが一致しなかったために生成される HTTP 呼び出しの例：
HTTP/1.1 401 Unauthorized
date: Mon, 23 Oct 2023 19:33:16 GMT
35

content-type: application/json{"error": "invalid_client","error_description": "Authentication failed"}
詳細について、例えばプロパティエラーの指定された値のリストについては、RFC6749 セクション 5.2 を参照。

3.2.3.2.

ListFootprints

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

フィルタリング

データ受信者は、適合するフィルタリングリクエストパラメータを設定することで、フィルタリングをリクエストできる。
注：フィルタリングステートメントの構文は、フィルタリングリクエストパラメータで説明されている。
ホストシステムによるフィルタリングのサポートはオプションであり、以下のようになる。
1. ホストシステムがフィルタリングを実装していない場合、フィルタリングが提供されていないかのようにリクエストを処理しなければならない。
2. ホストシステムがフィルタリングを実装している場合、フィルタリングステートメントをベストエフォートで処理できる。
1. フィルタリングステートメントやその一部を無視することができる。
2. また、フィルタリングステートメントやその一部をサポートしていない場合、特定のフィルタリングステートメントの処理を拒否することができる。この場合、NotImplemented というコードのエラーレスポンスを返さなければならない。
3.2.3.2.2.

ページネーション

ホストシステムは、以下のようにサーバーサイドでページネーションを実装しなければならない。
1.ホストシステムは、Limit リクエストパラメータを介して要求された ProductFootprints よりも少ない数を返してもよい。
2.追加の ProductFootprints が取得可能である場合、ホストシステムは Link ヘッダーを返さなければならない。
3.Link ヘッダーは[RFC8288]に準拠している。
36

4.rel パラメータの値は next と等しい。
5.Link ヘッダーのターゲット IRI（RFC8288、セクション 3.1）は必須である。
6.ターゲット IRI のホストの値は、元の ListFootprints HTTP リクエストのホストリクエストヘッダーの値と等しい。
ページネーションリンクヘッダーからのターゲット IRI は、ページネーションリンクと呼ばれる。
ホストシステムがページネーションリンクを返す場合、
1.データ受信者は、ページネーションリンクを複数回呼び出すことができる。
2.各呼び出しに対して、ホストシステムは1.成功した認証で同じセットの Product Footprints を返さなければならない。
2.データ受信者が Limit を定義した場合、要求されたよりも多くのプロダクトフットプリントを返してはいけない。
3.追加の ProductFootprints が利用可能である場合、前述の説明に準拠した Link ヘッダーを返さなければならない。
3.レスポンスに 2 つ目のページネーションリンクが含まれている場合、データ受信者が 2 つ目のページネーションリンクを呼び出すと、前のページネーションリンクが機能しなくなることがある。
つまり、データ受信者は、ページネーションプロセスを進めた後も、前のページネーションリンクが結果を返し続けることを前提としてはいけない。
4.ページネーションリンクは、作成後少なくとも 180 秒間有効であるなければならない。
5.サーバーがエラーを返した後、データ受信者はページネーションリンクを再度呼び出すべきである。
6.リトライ時には、ランダム化されたエクスポネンシャルバックオフを使用するべきである。
3.2.3.2.3.

リクエスト構文GET Subpath/JEITA/2/footprints?Filter&Limit HTTP/1.1
Host: Hostname
authorization: Bearer BearerToken
3.2.3.2.4.

リクエストパラメータ

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

BearerToken として使用しなければならない。
Filter:Filter はオプションの要求パラメータです。定義する場合は、ODatav4 仕様で定義されている$filter 構
文に準拠する必要がある。
また、$filter 文には、以下の演算子とプロパティのみを含める必要がある。
プロパティ「created, updated, productCategoryCpc, geographyCountry, referencePeriodStart,referencePeriodEnd」に対する論理演算子 eq, lt, le, gt, ge
論理演算子 and。
コレクション値プロパティ「companyIds, productIds」に対するラムダ演算子 any。演算子の式引数には、eq 演
算子のみを含める必要がある。
Limit:
Limit はオプションの要求パラメータです。定義する場合は、HTTP リクエストパラメータの名前は limit でなければならない。値は正の整数でなければならない。
3.2.3.2.5.

レスポンス構文

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

レスポンスパラメータ

HttpStatusCode:
ホストシステムがアクセストークンを受け入れる場合、HttpStatusCode は 200 または 202 でなければならない。
・HttpStatusCode 200 : 返されたリストが与えられたクエリの完全な結果であることを示す。
・HttpStatusCode 202 : 返されたリストが与えられたクエリの不完全な結果であることを示す。ホストシステ
ムは、将来的に残りのデータを取得できると主に判断した場合、この HttpStatusCode を返すことができる。リクエストパ
ラ メ ー タ Filter が 定 義 さ れ て い な い 場 合 、 こ の HttpStatusCode を 返 し て は い け な い 。 デ ー タ 受 信 者 は 、
HttpStatusCode 200 で示される完全な結果を受け取るまで、exponential-backoff で同じリクエストを送り続けることができる。

ホストシステムがエラー応答で応答する場合、HttpStatusCode はそれぞれのエラー応答コードの HTTP ステー
タスコードと一致しなければならない。ホストシステムが ProductFootprints のリストを返さない場合、エラーHTTP
ステータスコード(4 xx、5 xx)を返さなければならない。
38

ContentLength:
Body の長さ。RFC2616 参照。
Body:
ホストシステムがアクセストークンを受け入れる場合、本文は ProductFootprints のリストの値を持つプ
ロパティデータを持つ JSON オブジェクトでなければならない。リストは JSON 配列としてエンコードされなければならない。リストが空の場合、ホストシステムは空の JSON 配列を返さなければならない。
ホストシステムは、各フットプリントの最新バージョンを返さなければならず、前のバージョンを返すこともできる。同

一の ID 値を持つフットプリントの中で、最大のバージョン値を持つものが最新バージョンと呼ばれ、残りのものが前のバージョンと呼ばれる。リクエストパラメータ Filter が定義されている場合、指定された式は、OData v4 仕様に記載されているように、コレクション内の各 ProductFootprint に対して評価されるべきであり、式が真に評価される
ProductFootprints のみがレスポンスに含まれるべきである。式が偽に評価される ProductFootprints や、デー
タ受信者に利用できない ProductFootprints は、レスポンスで返されるリストから省略されるべきである。
ホストシステムがアクセストークンを受け入れない場合、Body は AccessDenied コードのエラー応答でなければならない。
もしホストシステムが期限切れのためにアクセストークンを受け入れないなら、Body はコード TokenExpired のエラー応答であるべきである。
他のすべての場合、例えばヘッダ認証の不正な値の場合、ボディはコード BadRequest のエラー応答であるべきである。
3.2.3.2.7.

例

リクエスト
GET example/2/footprints?$filter=updated ge 2022-12-14T06:00:00+09:00&limit=10 HTTP/1.1
host: a.example.com
authorization: Bearer PIYOpiyoPIYOpiyoPIYOpiyo
レスポンス
HTTP/1.1 200 OK
content-type: application/jsoncontent-length: 300
server: Pathfinder
39

link: <https:// a.example.com /2/footprints?$filter=updated ge2022-1214T06:00:00+09:00 &limit=10>; rel="next"{"data":[{"id":"497f6eca-6276-4993-bfeb-53cbbbba6f08”"specVersion":"1.0.0","version":0,...,"pcf":{"declaredUnit":"kilogram","unitaryProductAmount":0.00204,"fossilGhgEmissions":"8.6",...,"gateTogate":{
...
},
...
}
}]}
3.2.3.3.

GetFootprint

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

リクエスト構文GET Subpath/JEITA/2/footprints/PfId HTTP/1.1
Host: Hostname
authorization: Bearer BearerToken
3.2.3.3.2.

リクエストパラメータ

Subpath:40

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

レスポンス構文

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

レスポンスパラメータ

HttpStatusCode:
ホストシステムがアクセストークンを受け入れる場合、HttpStatusCode は 200 でなければならない。ホストシステムがエラー応答で応答する場合、HttpStatusCode はそれぞれのエラー応答コードの HTTP ステータス
コードと一致しなければならない。ホストシステムが ProductFootprints のリストを返さない場合、エラーHTTP ス
テータスコード(4 xx、5 xx)を返さなければならない。
ContentLength:
Body の長さ。RFC2616 参照。
Body:
ホストシステムがアクセストークンを受け取り、要求元のデータ受信者に ProductFootprint へのアクセスを許可する場合、本文はプロパティデータを持つ JSON オブジェクトでなければならない。プロパティデータの値は、フットプリント識別子 PfId を持つ ProductFootprint でなければならない。識別子 PfId で ProductFootprint に変更があった場合、ホストシステムは識別子 PfId で識別される最新の ProductFootprint とプロパティバージョンの最大値を返す必要がある。
41

注意:ホストシステムにライフサイクルルールが実装されている場合、ProductFootprint の 「最新」 バージョンは、固定の PfId が与えられたバージョンの最大値を持つバージョンになります。
ホストシステムがアクセストークンを受け入れない場合、Body は AccessDenied コードのエラー応答でなければならない。
もしホストシステムが期限切れのためにアクセストークンを受け入れないなら、Body はコード TokenExpired のエラー応答であるべきである。
ホストシステムは、コード NoSuchFootprint でエラー応答を返してもよい。
他のすべての場合、例えばヘッダ認証の不正な値の場合、ボディはコード BadRequest のエラー応答であるべきである。

3.2.3.3.5.

例

リクエスト
GET example/2/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",...,
42

"gateTogate":{
...
},
...
}
}}
3.2.3.4.

ActionEvents

ActionEvents は、Pathfinder Network API の”Action Events”を参照している。原文からの変更点
は、Request syntax のパス変更と Response parameters への Green x Digital Consortium による独
自データモデル追加の 2 点である。
アクションイベントは、データ所有者とデータ受信者間でイベントデータを交換することを可能にする。
アクションイベントのエンドポイントは、以下のユースケースに指定されている。
1. 1 つ以上の製品フットプリントの更新に関するデータ所有者からデータ受信者への通知を可能にする（3.2.3.4.5. 製品フットプリントの更新に関するデータ受信者への通知を参照）
2. データ受信者がデータ所有者のアクションイベントエンドポイントにイベントを送信することで、データ所有者から製品フットプリントをリクエストすることを可能にする（3.2.3.4.6.製品フットプリントの非同期リクエストと取得を参照）。
ホストシステムは、認証後にのみイベントを受け入れるべきである。
アクションイベントのエンドポイントは、"Structured Content Mode"（[CE-Structured-Content-Mode]を参照）でエンコードされた CloudEvent イベント（[CE]を参照）を受け入れる。
アクションイベントのサポートはオプションである。
ホストシステムがアクションイベントのエンドポイントを実装していない場合、
1. 適合するエラーレスポンスと HTTP エラーレスポンスコードで応答するべきである。
2. 認証されたアクションイベントの呼び出しに対して、NotImplemented のコードを持つエラーレスポンスで応答すべきである。
3. エラーHTTP ステータスコード（4xx、5xx）で応答しなければならない。
3.2.3.4.1.

リクエスト構文POST Subpath/JEITA/2/events HTTP/1.1
Host: Hostname
43

authorization: Bearer BearerToken
content-type: application/cloudevents+json; charset=UTF-8
EventBody
3.2.3.4.2.

リクエストパラメータ

Subpath:
ホストシステムが相対サブパスを使用する場合、要求元のデータ受信者は、このサブパスを追加する。
Hostname:
要求元のデータ受信者はホストシステムのドメイン名を使用しなければならない。
BearerToken:
データ受信者は、アクション Authenticate からのレスポンス本文のプロパティ access_token の値をBearerToken として使用しなければならない。
EventBody:
EventBody は以下の条件を満たさなくてはならない。
1. CloudEvents イベントであること（[CE]を参照）
2. [CE-JSON]で定義された JSON オブジェクトとしてエンコードされていること
3. “Structured Content Mode”を使用していること（[CE-Structured-Content-Mode]を参照EventBody の構文とセマンティクスの詳細は、3.2.3.4.5. 製品フットプリントの更新に関するデータ受信者への通知および 3.2.3.4.6. 製品フットプリントの非同期リクエストと取得で説明されている。
3.2.3.4.3.

レスポンス構文

HTTP/1.1 HttpStatusCode OKcontent-length: 0
3.2.3.4.4.

レスポンスパラメータ

HttpStatusCode:
イベントを受け付けたホストシステムは、HTTP ステータスコード 200 で応答しなければならない。イベントを受け付けないホストシステムは、エラー応答で応答すべきである。

44

ContentLength:
Body の長さ。RFC2616 参照。
イベントを受け付けたホストシステムは、空の本体で応答しなければならない。
3.2.3.4.5.

製品フットプリントの更新に関するデータ受信者への通知

データ所有者は、PF 更新イベントをデータ受信者のアクションイベントエンドポイントに送信することで、1 つ以上の製品フットプリントの変更についてデータ受信者に通知することができる。
データ受信者は、PF 更新イベントを受信した後、アクション GetFootprint を通じて製品フットプリントを取得することができる。
そのため、イベントを送信するホストシステムのデータ所有者は、PF 更新イベントを通じて通知されたデータ受信者に対して、参照された製品フットプリントを利用可能にしなければならない。
PF 更新イベントは、以下の構文を持つ JSON エンコードされた CloudEvent イベントとして定義されている。
{"type": "org.wbcsd.pathfinder.ProductFootprint.Published.v1","specversion": "1.0","id": "EventId","source": "//EventHostname/EventSubpath","time": "2022-05-31T17:31:00Z","data": {"pfIds": PfIds}}
EventId:
イベントを送信するホストシステムによって設定されたイベントの一意の識別子。EventId は文字列でなければならない（[CE-JSON]を参照）。
PfIds:
更新された製品フットプリントのリスト。PfIds は、更新された製品フットプリントの id 値の空でないリストであり、JSON 配列としてエンコードされていなければならない。
EventHostname:
イベントを送信するホストシステムのホスト名。
EventSubpath:
イベントを送信するホストシステムのハンドラ。

45

3.2.3.4.6.

製品フットプリントの非同期リクエストと取得

データ受信者は、PF リクエストイベントをデータ所有者のアクションイベントエンドポイントに送信することで、データ所有者に製品フットプリントの送信をリクエストすることができる。
データ所有者は、PF リクエストイベントを受信した後、リクエストを以下のように処理することができる。
1.データ受信者のアクションイベントエンドポイントに PF レスポンスイベントを送信
2.リクエストが処理できないことをデータ受信者に通知するために、データ受信者のアクションイベントエンド
ポイントに PF レスポンスエラーイベントを送信
3.データ受信者のアクションイベントエンドポイントにイベントを送信しない。
データ所有者が PF リクエストイベントを受け入れた場合、ホストシステムは、PF リクエストイベントのソースで参照されるホストシステムにレスポンスを返さなければならない。データ所有者のホストシステムは、レスポンスを送信する
前に、ソースの値を検証しなければならない。元のリクエスト送信者（データ受信者）のホストシステムが利用できないか、HTTP 成功コード（2xx）でレスポンスを受け入れない場合、データ所有者のホストシステムは、エクスポ
ネンシャルバックオフを使用してレスポンスイベントの送信を再試行するべきである。ホストシステムは、3 日以上レス
ポンスイベントの送信を再試行しないようにするべきである。
3.2.3.4.6.1.

PF リクエストイベント構文

PF リクエストイベントは、データ受信者からデータ所有者に送信される CloudEvent イベントとして定義されている。このイベントには、製品フットプリントのフラグメントが含まれており、データ所有者にリクエストされた製品フットプリ
ントを説明する。
PF リクエストイベントは、以下の構文を持つ JSON エンコードされた CloudEvent イベントとして定義されている。
{"type": "org.wbcsd.pathfinder.ProductFootprintRequest.Created.v1","specversion": "1.0","id": "EventId","source": "//EventHostname/EventSubpath","time": "2022-05-31T17:31:00Z","data": {"pf": ProductFootprintFragment,"comment": PFRequestComment}}
EventId:
イベントを送信するホストシステムによって設定されたイベントの一意の識別子。EventId は文字列でなければならない（[CE-JSON]を参照）。
46

EventHostname:
イベントを送信するホストシステムのホスト名。
EventSubpath:
イベントを送信するホストシステムのハンドラ。
ProductFootprintFragment:
ProductFootprint のプロパティのサブセットを参照する JSON オブジェクトで、ネストされたプロパティも含まれる。
PFRequestComment:
データ受信者からデータ所有者へのリクエストに関するオプションのコメント。定義されている場合、
PFRequestComment は JSON 文字列としてエンコードされていなければならない。
PF リクエストイベントの data.comment プロパティはオプションである。
3.2.3.4.6.2.

PF レスポンスイベント構文

PF レスポンスイベントは、データ所有者からデータ受信者に送信される CloudEvent イベントとして定義されており、データ受信者から PF リクエストイベントを受信し、リクエストを正常に満たした後に送信される。
PF レスポンスイベントは、以下の構文を持つ JSON エンコードされた CloudEvent イベントとして定義されている。
{"type": "org.wbcsd.pathfinder.ProductFootprintRequest.Fulfilled.v1","specversion": "1.0","id": "EventId","source": "//EventHostname/EventSubpath","data": {"requestEventId": "ReqEventId","pfs": Pfs}}
ReqEventId:
PF レスポンスイベントが応答している PF リクエストイベントの EventId。ReqEventId は文字列でなければならない（[CE-JSON]を参照）。
Pfs:
PF リクエストイベントでリクエストされ、データ受信者がアクセスできる製品フットプリントのリストで、JSONの ProductFootprint の配列としてエンコードされている。
それ以外の場合、Pfs の値は空の JSON 配列でなければならない。

47

3.2.3.4.6.3.

PF レスポンスエラーイベント構文

PF レスポンスエラーイベントは、データ所有者からデータ受信者に送信される CloudEvent イベントとして定義されており、データ受信者から PF リクエストイベントを受信し、リクエストを正常に満たせなかった場合に送信される。
PF レスポンスイベントは、以下の構文を持つ JSON エンコードされた CloudEvent イベントとして定義される。
{"type": "org.wbcsd.pathfinder.ProductFootprintRequest.Rejected.v1","specversion": "1.0","id": "EventId","source": "...","data": {"requestEventId": "ReqEventId","error": ReqErrorResponse}}
ReqErrorResponse:
データ所有者がデータ受信者にリクエストが処理できないことを通知するために送信しているエラーレスポンス。
ReqErrorResponse の値は、エラーレスポンスでなければならない。
3.2.3.5.

エラーレスポンス

アクションゲットフットプリント、アクションリストフットプリント、アクションイベントは、一般的なエラーレスポンスの処理を指定する。
エラーレスポンスは詳細に指定されているため、データ受信者はエラーの原因を理解することができ、ホストシステ
ムがエラーを自動的に反応し解決することができる。
注：アクション認証は独自のエラーレスポンスを指定する（§ 6.5.2 レスポンス構文を参照）。
ホストシステムがエラーレスポンスを返す場合、以下のような HTTP レスポンスを送信しなければならない。
・HTTP ステータスコードは、それぞれのエラーレスポンスコードに定義された HTTP ステータスコードと同じであること（エラーコード一覧を参照）
・コンテンツタイプが application/json に設定されていること
・レスポンスボディがエラーレスポンスであること
エラーレスポンスは、以下のプロパティを持つ JSON オブジェクトである。
・code：文字列としてエンコードされたエラーレスポンスコード
・message：文字列としてエンコードされたエラーメッセージ
エラーレスポンスコードは、3.2.3.5.1.エラーコード一覧のエラーレスポンスコード列からの値である。
アクセス拒否エラーレスポンスの例：
48

{"message": "Access Denied","code": "AccessDenied"}
ホストシステムは、例えばデータ受信者に依存するローカライズされた値など、以下の一覧とは異なるエラーメッセージを返してもよい。

3.2.3.5.1.

エラーコード一覧

エラーメッセージは、人間に解読可能な説明である。例として、以下の表の Example Message 列に値がある。
ホストシステムは、データ受信者によって異なるローカライズされた値など、以下の表とは異なるエラーメッセージを返してもよい。
Error Response Code

Example Message

HTTP Status Code

AccessDenied

Access denied

403

BadRequest

Bad Request

400

NoSuchFootprint

The specified footprint does not exist.

404

The specified Action or header you
NotImplemented

provided implies functionality that is 400
not implemented

TokenExpired

The specified access token has expired
An internal or unexpected error has

InternalError

3.2.3.5.2.

occurred401500

データ受信者によるエラー処理

リクエストを行うデータ受信者は、code プロパティと場合によっては HTTP ステータスコードも使用して、異なるエラーを区別しなければならない。

3.3.

リファレンス[CE]
Cloud Events Specification. LS. URL: https://github.com/cloudevents/spec[CE-Structured-Content-Mode]
HTTP Protocol Binding for CloudEvents - Version 1.0.2. LS. URL:49

https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/bindings/http-protocolbinding.md#32-structured-content-mode[CE-JSON]
JSON Event Format for CloudEvents - Version 1.0.2. LS. URL:
https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/formats/json-format.md

50

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

51