本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント等と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。 なお本記事の数値・スキーマは、特記のない限り 2026年8月20日時点で取得した PACT Technical Specifications v3.0.3 の実測です。

数値データを組織の外に渡すとき、値そのものと同じくらい「その値がどうやって得られたか」が問題になります。実測なのか、推定なのか、上流から受け取ったものをそのまま流しているのか。

この問題に正面から取り組んでいる産業標準のひとつが、製品カーボンフットプリント（PCF。製品1単位あたりの温室効果ガス排出量）の交換仕様です。WBCSD の PACT が策定しており（WBCSD は持続可能な発展のための世界経済人会議、PACT はその下で炭素の透明性を扱う枠組み）、データ品質を等級（1から5）として構造化フィールドに載せる設計になっています。

私の関心は、そこから一段ずれたところにあります。この種の仕様は「第三者に検証されたか否か」を書けます。では「そもそも検証する観測点が存在しない」ことは書けるのか。値が悪いことと、値が無いことと、値を得る手段が無いことは、受け取る側から見て区別がつくのか。

OpenAPI（Web API の仕様を機械可読に書く記法。ここでは交換するデータの型が定義されている）の実体を取ってきて、JSON Schema として実際に検証をかけながら確かめた記録です。

PACT とは何か

PACT は Partnership for Carbon Transparency の略です。公式サイト https://www.carbon-transparency.org のタイトルにこの展開形が出ています。

仕様書本文（§1.4 About PACT and the PACT Network）の記述はこうです。

The PACT (previously Pathfinder) Network is a concept developed by PACT and powered by the World Business Council for Sustainable Development (WBCSD).

（PACT（旧称 Pathfinder）ネットワークは、PACT が開発し、持続可能な開発のための世界経済人会議（WBCSD）が推進するコンセプトである。）

仕様リポジトリの index.md 冒頭にはこうあります。

PACT, Partnership for Carbon Transparency, is a project hosted by WBCSD (World Business Council for Sustainable Development), which co-chairs the GHG Protocol.

GHG Protocol は温室効果ガスの排出量算定で最も広く使われている国際的な基準です。PACT はその策定側に連なる立場から、企業間で PCF をやりとりするための API を定めています。

Pathfinder は旧称です。 成果物は次の2本立てになっています。

名称旧称内容
PACT MethodologyPathfinder FrameworkPCF をどう算定するかの方法論
PACT Technical Specifications for PCF Data Exchange—データモデルと交換 API

仕様書の Abstract がこの関係を一文で書いています。

This document specifies a data model for GHG emission data at product level based on the PACT Methodology (previously Pathfinder Framework) Version 3, and a protocol for interoperable exchange of GHG emission data at product level.

リポジトリの RELEASE-PLAN.md にある版の履歴です。方法論と技術仕様は別々に版が進み、大版だけが揃います。

方法論公開
Version 1（Pathfinder Framework）2022-06
Version 22023-01-26
Version 32025-04-30
技術仕様公開
v1.0.02022-06-16
v2.0.02023-02-21
v2.3.02024-10-24
v3.0.02025-04-30

技術仕様の現行版は 3.0.3 です。GitHub のリリースタグは v3.0.3（2025-12-09 付）、公開された仕様書の This version: は https://wbcsd.github.io/tr/2025/data-exchange-protocol-20251118/ を指しています。リポジトリの index.md も「3.0.3 (latest stable)」と表示しています。

技術仕様は次の場所にあります。

なお別リポジトリ wbcsd/pact-openapi にも OpenAPI 定義がありますが、その README は次のように述べています。

IMPORTANT This repository is now OBSOLETE, as the OpenAPI definitions for PACT are now integral part of the PACT Technical Specification

以下、参照するのは data-exchange-protocol リポジトリの spec/v3/openapi.yaml です。

データモデルの構造

仕様書 §4 のデータ型は次のようになっています。

ProductFootprint          交換される文書そのもの
 └ pcf : CarbonFootprint  排出量と算定条件の本体
    ├ dqi : DataQualityIndicators   データ品質指標
    ├ verification : Verification   第三者検証の情報
    ├ primaryDataShare              一次データの割合
    ├ secondaryEmissionFactorSources : [EmissionFactorSource]
    └ productOrSectorSpecificRules  : [ProductOrSectorSpecificRule]
 └ extensions : [DataModelExtension]

ProductFootprint の必須プロパティは OpenAPI 定義の required に10個あります。

id, specVersion, created, status, companyName, companyIds,
productDescription, productIds, productNameCompany, pcf

CarbonFootprint の必須は12個です。

declaredUnitOfMeasurement, declaredUnitAmount, productMassPerDeclaredUnit,
referencePeriodStart, referencePeriodEnd,
pcfExcludingBiogenicUptake, pcfIncludingBiogenicUptake,
fossilGhgEmissions, fossilCarbonContent,
ipccCharacterizationFactors, crossSectoralStandards, exemptedEmissionsPercent

dqi、primaryDataShare、verification はいずれも required に入っていません。 これは後で効いてきます。

実際の ProductFootprint

仕様に適合する ProductFootprint を1件作りました。二次アルミ地金（ADC12）1トンの PCF という想定です。

{
  "id": "3f2504e0-4f89-41d3-9a0c-0305e82c3301",
  "specVersion": "3.0.3",
  "version": 0,
  "created": "2026-04-01T00:00:00Z",
  "status": "Active",
  "validityPeriodStart": "2026-01-01T00:00:00Z",
  "validityPeriodEnd": "2028-12-31T00:00:00Z",
  "companyName": "Example Aluminium Co., Ltd.",
  "companyIds": ["urn:pact:example-aluminium.co.jp:supplier-id:SUP-000123"],
  "productDescription": "Secondary aluminium ingot, ADC12, ingot form, no packaging",
  "productIds": ["urn:pact:example-aluminium.co.jp:product-id:ADC12-INGOT"],
  "productClassifications": ["urn:unspsc:11101704"],
  "productNameCompany": "ADC12 secondary ingot",
  "pcf": {
    "declaredUnitOfMeasurement": "kilogram",
    "declaredUnitAmount": "1000",
    "productMassPerDeclaredUnit": "1000",
    "referencePeriodStart": "2025-04-01T00:00:00Z",
    "referencePeriodEnd": "2026-03-31T00:00:00Z",
    "geographyCountry": "JP",
    "boundaryProcessesDescription": "Cradle-to-gate: scrap collection and sorting, melting in reverberatory furnace, alloying, casting.",
    "pcfExcludingBiogenicUptake": "620",
    "pcfIncludingBiogenicUptake": "620",
    "fossilGhgEmissions": "618",
    "fossilCarbonContent": "0",
    "biogenicCarbonContent": "0",
    "recycledCarbonContent": "0",
    "packagingEmissionsIncluded": false,
    "ipccCharacterizationFactors": ["AR6"],
    "crossSectoralStandards": ["ISO14067", "PACT-3.0"],
    "exemptedEmissionsPercent": "1.8",
    "exemptedEmissionsDescription": "Lubricants and refractory consumables below the exemption threshold.",
    "allocationRulesDescription": "Mass allocation between ingot and dross.",
    "secondaryEmissionFactorSources": [
      { "name": "IDEA", "version": "3.4" }
    ],
    "primaryDataShare": "41.2",
    "dqi": {
      "technologicalDQR": "2.1",
      "geographicalDQR": "1.8",
      "temporalDQR": "3.4"
    },
    "verification": {
      "coverage": "PCF calculation model",
      "providerName": "Example Assurance K.K.",
      "completedAt": "2026-03-20T09:00:00Z",
      "standardName": "ISO 14064-3"
    }
  }
}

この JSON は、spec/v3/openapi.yaml の components.schemas.ProductFootprint を JSON Schema 2020-12 として解決し、jsonschema 4.25.1 で検証してエラー0件を確認したものです（$ref のプレフィックスを #/components/schemas/ から #/$defs/ に置換して自己完結させています）。

読みどころは末尾の3ブロックです。

  • primaryDataShare: "41.2" — この PCF の 41.2% が一次データ由来
  • dqi — 技術・地理・時間の3軸の品質等級。数字が小さいほど良い
  • verification — 第三者検証を受けた事実と、その範囲・実施者・完了日

排出量の数値と、その数値の資格が、同じ文書に入っています。（DQR は data quality rating、データ品質等級のことです。primaryDataShare は一次データの割合を表します。いずれも後で詳しく見ます。）

なお MUST や SHALL は、仕様書で要求の強さを表す慣用語です（RFC 2119 由来で、MUST は絶対的な要求、SHALL も同義に使われます）。この語が構造の制約と食い違う箇所がひとつあります。productOrSectorSpecificRules の記述は「If no product or sector specific rules were followed, this set MUST be empty.」（該当する規則がなければ空集合にしなければならない）ですが、スキーマ側は minItems: 1 です。空配列 [] を入れると検証エラーになります。上の例では該当なしのためプロパティごと省略しました。

dataQualityIndicators の実際

依頼のあった確認事項のひとつが、dataQualityIndicators（DQI）というフィールドの有無と、そのサブフィールド名・値域でした。

フィールドは存在します。 ただし名前は dataQualityIndicators ではありません。CarbonFootprint 上のプロパティ名は dqi で、その型名が DataQualityIndicators です。

spec/v3/openapi.yaml の該当箇所です。

    DataQualityIndicators:
      title: DataQualityIndicators
      description: |
        Data type DataQualityIndicators contains the quantitative data quality indicators.
      type: object
      x-methodology: 4.2.3
      required:
      - technologicalDQR
      - geographicalDQR
      - temporalDQR
      properties:
        technologicalDQR:
          description: |
            Quantitative data quality rating (DQR) based on the data quality matrix,
            scoring the technological representativeness of the sources used for
            the final absolute PCF excluding biogenic CO2 uptake calculation based
            on weighted average of all inputs.

            The value MUST be between `1` and `5` inclusive.
          x-term: Technological representativeness
          x-rule: SHALL
          $ref: '#/components/schemas/Decimal'

サブフィールドは3つだけで、すべて必須です。

サブフィールド意味型値域
technologicalDQR技術代表性Decimal（decimal 形式の文字列）1以上5以下（記述文のみ）
geographicalDQR地理代表性同上同上
temporalDQR時間代表性同上同上

pedigree matrix 由来か

LCA（ライフサイクル評価。製品の資源採取から廃棄までの環境負荷を積み上げて計算する手法）の pedigree matrix（ペディグリー行列。データの素性を複数の指標で採点し、その採点を不確実性に変換する仕組み）には通例、technological / temporal / geographical / completeness / reliability の5軸があります。v3.0.3 の DQI にあるのは、このうち3軸です。

由来については、PACT Methodology v3.0 の用語定義が答えています。

Data quality: Characteristics of data (completeness, reliability and technological, temporal and geographical representativeness) that relate to their ability to satisfy stated requirements (the most common frameworks are the Pedigree Matrix (Ecoinvent) and the Data Quality Matrix/Requirements (Product Category Rules)).

定義文では5軸すべてを挙げ、Ecoinvent の Pedigree Matrix を代表的な枠組みとして名指ししています。 しかし交換されるフィールドは3軸です。

v2 系との比較で差がはっきりします。pact-openapi リポジトリに残る v2.3.0 の定義では、DQI は6項目すべて必須でした。

    DataQualityIndicators:
      required:
      - coveragePercent
      - technologicalDQR
      - temporalDQR
      - geographicalDQR
      - completenessDQR
      - reliabilityDQR

しかも値域が違います。v2 の各 DQR は FloatBetween1And3（type: number, minimum: 1, maximum: 3）でした。

v2.3.0v3.0.3
軸の数5（+ coveragePercent）3
completenessDQR / reliabilityDQRありなし
coveragePercent（品質評価の対象範囲）あり（必須）なし
値域1–31–5
型number（min/max で機械的に制約）string の decimal 形式（制約は記述文のみ）

方法論 v3.0 §4.2.3 が3軸であることと値域を明記しています（原文は2段組で、3つの指標は箇条書きで両段に分かれています）。

From 2027 onwards, once the GHG calculations for the PCF excluding biogenic CO2 uptake have been completed, companies shall calculate a data quality rating (DQR) of direct emissions and emission factors data for the following three indicators:

  • Technological representativeness: The degree to which the data reflects the actual technology / technologies used in the process
  • Geographical representativeness: The degree to which the data reflects the actual geographic location of the processes within the inventory boundary (e.g., country or region)
  • Temporal / Time representativeness: The degree to which the data reflects the actual time (e.g., year) or age of the process

Each indicator of the data quality assessment matrix (Table 12) shall be assessed from 1 (best score) to 5 (worst score).

1から5は機械検査されない

v3 では technologicalDQR の型が $ref: '#/components/schemas/Decimal' になっています。その Decimal の定義はこうです。

    Decimal:
      type: string
      format: decimal
      pattern: ^[+-]?\d+(\.\d+)?$

minimum / maximum がありません。「1以上5以下」は description の散文にあるだけです。実際に検証してみました。

入力結果
{"technologicalDQR":"5.0","geographicalDQR":"2.0","temporalDQR":"3.0"}VALID
{"technologicalDQR":"9.9","geographicalDQR":"-3","temporalDQR":"1000.5"}VALID
{"technologicalDQR":"unknown", ...}INVALID（^[+-]?\d+(\.\d+)?$ に不一致）
temporalDQR を省略INVALID（required）
temporalDQR に nullINVALID（type: string）

PACT の公式適合性検査サービス wbcsd/pact-conformance-service が同梱する v3 スキーマ（packages/test/src/schemas/openapi_v3_0.yaml）では、DQR の型は type: string / format: decimal のみで、pattern すら落ちています。

つまり「9.9」は仕様違反ですが、私が確認した範囲では、その違反を機械的に止める仕組みは仕様側にも公式検査側にもありません。

primaryDataShare

一次データの割合を表すフィールドは CarbonFootprint/primaryDataShare です。定義はこうです。

        primaryDataShare:
          description: |
            Share of primary data in the final absolute PCF value excluding biogenic
            CO2 uptake (pcfExcludingBiogenicUptake).
          x-rule: SHALL
          x-term: Primary Data Share
          x-methodology: 4.2.2
          $ref: '#/components/schemas/Decimal'

方法論 §4.2.2 は、これ（PDS。primary data share の略で、報告値のうち実測などの一次データに由来する割合）を、各構成要素の一次データ率を排出寄与で加重平均したものと定義しています。

                       Σ (|PCF_i| × PDS_i)
PDS(PCF product) = ─────────────────────────
                            Σ |PCF_i|

  i       : PCF の範囲・境界に含まれる任意の構成要素（投入または産出）
  |PCF_i| : 生物由来 CO2 吸収を除いた PCF の絶対値

なお dataQualityRating という名前のフィールドは、私が v3.0.3 の OpenAPI 定義を全文検索した範囲では存在しません。品質の等級を担うのは dqi 配下の3つの ...DQR プロパティです。

適用時期は x-rule と方法論 §4.2 で分かれています。

  • primaryDataShare: SHALL（報告必須）。方法論は「Companies shall calculate and report PDS as part of the PCF data exchange.」とする
  • dqi: SHALL-2027。方法論 §4.2 は「From 2027 onwards, companies shall assess the data quality ratings (DQR)」とし、脚注で「it is only required by end of 2027 (i.e., 31.12.2027)」と補っている

つまり一次データの割合はいま必須、品質等級は2027年末から必須という段階適用です。

verification — assurance からの改名と、真偽値の削除

第三者検証を表すオブジェクトは、v3 で assurance から verification に改名されました。 仕様書の変更履歴に「CarbonFootprint/assurance renamed to CarbonFootprint/verification」とあります。

v3.0.3 の定義は次のとおりです。

    Verification:
      title: Verification
      description: |
        Contains the verification in conformance with the PACT Methodology.
      note: Renamed from `Assurance` in 3.0
      type: object
      properties:
        coverage:
          type: string
          enum:
            - PCF calculation model
            - PCF program
            - product level
        providerName:
          description: |
            The non-empty name of the independent third party engaged to undertake the verification.
          type: string
        completedAt:
          type: string
          format: date-time
        standardName:
          type: string
        comments:
          type: string

（x-term / x-methodology などの注釈行は省略しています。）

required が1件もありません。 型としては空オブジェクト {} も妥当です（後述）。

v2 からの変化を並べます。

プロパティv2.3.0v3.0.3
assurance（真偽値）必須削除
coveragecorporate level / product line / PCF system / product levelPCF calculation model / PCF program / product level
level（limited / reasonable）ありなし
boundary（Gate-to-Gate / Cradle-to-Gate）ありなし
providerName必須任意
completedAt / standardName / commentsありあり

level と boundary が消えた点は、方法論の側と対照すると位置づけが分かります。方法論 v3.0 の「検証ロードマップ」（Figure 21）は8つの次元を定義しています。

Assurance dimensions: Coverage (5.3.3) / Conformance (5.3.4) / Boundary (5.3.5) / Level of verification (5.3.6) / Provider (5.3.7) / Process cycle (5.3.8) / Requirements for SMEs (5.4) / Timing and reporting (5.5)

Figure 22 はこのうち Level について、短期（2025-2030）を limited assurance、長期（2030以降）を certification とし、Boundary は両期間とも cradle-to-gate としています。

方法論が8次元で語っている検証の属性のうち、交換フォーマットが構造化して運べるのは coverage・provider・完了日・標準名の4つです。 level と boundary は v3 で構造を失い、書くなら comments の自由記述になります。

真偽値はなぜ消えたか

assurance 真偽値の削除は、リポジトリの意思決定記録 decisions/log/0044-remove-assurance-flag.md（2024-12-11、2024-12-18 に consensus reached）に理由が残っています。

This is superfluous: the presence of the assurance subrecord already indicates the inclusion of the assurance-related information, no boolean flag is necessary.

Moreover: setting the assurance attribute to false can lead to a confusing situation of setting the other attributes to null or empty strings, or omitting them.

（これは冗長である。assurance サブレコードの存在それ自体が保証関連情報の包含を示しており、真偽値のフラグは不要である。さらに、assurance 属性を false に設定すると、他の属性を null や空文字列にするか省略するかという混乱した状況を招きうる。）

そして仕様書の verification プロパティの記述はこうなりました。

The presence of the Verification object indicates whether or not the CarbonFootprint has been verified in line with PACT Methodology requirements.

「検証されたか否か」は、オブジェクトの有無で表す。 これが v3 の設計です。

本題：観測点の不在は書けるか

ここからが私の関心です。

この仕様は「検証された／されていない」を表せます。では「そもそも検証する観測点が存在しない」ことは、「検証を受けなかった」ことと区別して書けるでしょうか。

1. 「未定義」は一種類しかない

仕様書 §4.5 Undefined Properties の定義がすべての起点です。

In a JSON object, a property is deemed undefined if it is either not present in the object or explicitly set to null.

（JSON オブジェクトにおいて、プロパティはオブジェクトに存在しないか、明示的に null に設定されているとき、未定義とみなされる。）

省略と null が同義と定義されています。 つまり「書かなかった」と「無いと明言した」を、仕様のレベルで意図的に同一視しています。理由のある不在（測っていない／該当しない／測ったが出せない）を分けて書く場所は、この定義の下では作れません。

2. verification の不在は一種類しかない

実際に検証をかけました。使ったのは前掲の ProductFootprint スキーマです。

入力結果
verification を省略VALID
"verification": {}VALID
"verification": nullINVALID（type: object）

つまり次の3つの状態が、すべて verification の不在という同一の表現に落ちます。

  1. 検証を依頼したが受けていない
  2. 検証を依頼する予定がない
  3. この製品カテゴリでは検証しうる観測点（検証機関・評価基準）がまだ存在しない

assurance: false があった v2 なら、少なくとも1と3の一部は「明示的に false」と「そもそもオブジェクトが無い」で書き分ける余地がありました。ADR（Architecture Decision Record。設計上の判断とその理由を1件1ファイルで残す記録。PACT はリポジトリの decisions/log/ に置いています）0044 はそれを「冗長かつ混乱を招く」として削っています。私が確認した範囲では、v3 でこの区別を回復する手段は構造化フィールドにはありません。

逆方向にも隙間があります。"verification": {} は妥当です。仕様の言葉どおりに読めば、中身が空でも「検証された」と主張していることになります。 検証機関名も完了日も標準名も無しに。

3. DQI では「不明」が値に潰される

より効くのはこちらです。DQR フィールドに "unknown" は書けません（Decimal の pattern で弾かれる）。では不明なとき何を書くのか。方法論 v3.0 §4.2 の要求事項に、はっきり書かれています。

If upstream PDS and DQRs are unknown, companies shall apply the worst-case scenario (i.e., 0% PDS and 5 DQR)

（上流の PDS および DQR が不明な場合、企業は最悪ケースのシナリオ（すなわち PDS 0%、DQR 5）を適用しなければならない。）

§4.2.3 でも繰り返されます。

If upstream DQRs are unknown, companies shall apply the worst-case scenario (i.e., a score of 5 for each DQI).

そして品質評価行列（Table 12）のスコア5のセルの文言そのものに、「unknown」が組み込まれています。

指標スコア5の定義（原文）
Technological representativenessThe dataset has been created based on different or unknown technology vs technology actually employed
Geographical representativenessThe dataset has been created based on data with a geographical scope which is either unknown or pertaining a country, or region not including the site in which the product has been manufactured
Temporal / Time representativenessThe difference between "Reference Period End" of the dataset and "Reference Period End" of the PCF is >4 years or unknown

primaryDataShare も同じ扱いです。

If the PDS of a PCF component is unknown, companies shall apply a 0% PDS score to that specific component.

「測ったが悪い」と「測っていない／分からない」が、意図的に同じ数値へ写像されています。

これは設計の失敗ではありません。合算可能な指標を作るには、欠測を数値に落とさなければ加重平均が計算できない。方法論は「不明なら最悪値」と定めることで、不明であることを隠すのではなく、不利に振ることで開示のインセンティブを作っています。 上流に問い合わせて実測値を取れば数字は改善する。合理的な設計です。

しかし受け取る側から見れば、DQR 5 という数字は「実測して5だった」のか「何も分からないので5と書いた」のか判別できません。 値が悪いことと、値を得る観測点が無いこととの区別は、この仕様の交換単位には残りません。

4. 部分的な逃げ道

私が確認した範囲で、不在の理由を伝えられる場所は3つあります。いずれも構造化されていないか、目的が違います。

（a）exemptedEmissionsPercent

        exemptedEmissionsPercent:
          description: |
            The percentage of emissions excluded from the PCF.
          note: string<decimal> in 3.0, was Number in 2.x. Removed upper boundary of 5%.

必須フィールドで、PCF から除外された排出の割合を数値で運びます。「境界の外に置いた分がどれだけあるか」は書ける、ということです。ただし表すのは境界の設定であって、観測点の有無ではありません。理由は隣の exemptedEmissionsDescription（自由記述、v3 で任意化）に書きます。

（b）自由記述フィールド

boundaryProcessesDescription、exemptedEmissionsDescription、allocationRulesDescription、comment、Verification/comments。いずれも type: string で、機械的な照合はできません。ADR 0031 は自由記述フィールドを必須から任意に落とした理由をこう説明しています。

Free-form text field which is not populated in a standardized way and labor intensive to generate at scale.

（標準化された方法で埋められることがなく、大規模に生成するのが労力を要する自由形式のテキストフィールド。）

仕様自身が、自由記述は標準化された形では埋まらないと判断しています。

（c）DataModelExtension

ProductFootprint/extensions に独自のデータモデル拡張を載せる仕組みがあります（仕様書 §4.8、別リポジトリ wbcsd/data-model-extensions）。原理的にはここで「この項目は観測点が存在しないため未取得」と書けます。ただしそれは PACT の共通語彙ではなく、送り手と受け手の二者間の合意になります。

5. まとめ

表現したいことv3.0.3 で書けるか
第三者検証を受けた書ける（verification オブジェクトの存在＋ coverage / providerName / completedAt / standardName）
検証の水準（limited / reasonable）v2 では書けた。v3 では構造化フィールドが無い（comments の自由記述のみ）
検証を受けていない書ける。ただし不在としてのみ（省略＝null＝未定義）
検証を受けていない理由構造化フィールドは見当たらない
そもそも検証する観測点が無い「検証を受けていない」と同じ表現になる
データ品質が低い書ける（DQR 4–5）
データ品質が不明「低い」と同じ表現になる（方法論が DQR 5 / PDS 0% を指示）
PCF から除外した排出の割合書ける（exemptedEmissionsPercent、必須）

この仕様は「検証されたか否か」を表せます。「そもそも検証する観測点が存在しない」ことを、「検証されていない」と区別して表す構造化フィールドは、私が v3.0.3 の OpenAPI 定義および方法論 v3.0 を通読した範囲では見当たりませんでした。

そして DQI については、区別できないことが偶然ではなく方法論の明文の指示であることが確認できました。不明は最悪値に潰す、と書いてあります。

日本との接点

仕様の意思決定記録には、日本のイニシアチブが繰り返し登場します。decisions/log/ を検索すると、Green x Digital（Green x Digital コンソーシアム、https://www.gxdc.jp/）が TfS（化学業界）、Catena-X（自動車業界）と並んで少なくとも4件の ADR に現れます。

  • 0031-mandatory-to-optional-attributes.md: 「Initiatives (TfS, Catena-X, and Green x Digital) endorse changing all 5 attributes to optional」
  • 0033-piece-as-declaredunit.md: 「Three sector initiatives (Catena-X, TfS, and Green x Digital) raised feedback requesting the addition of piece as declaredUnit」
  • 0032-cross-sectoral-standards.md、0046-include-ccu.md でも同様

declaredUnitOfMeasurement の列挙値に piece が入っているのは、この3者からの要望が起点です。

検証の方法について

本記事の記述のうち、次は筆者が一次資料を直接取得して確認したものです。

  • wbcsd/data-exchange-protocol を clone し、spec/v3/openapi.yaml（OpenAPI 3.1.0、info.version: 3.0.3）を読んだ。DataQualityIndicators のサブフィールド3件と required、Verification の5プロパティと required 不在、CarbonFootprint / ProductFootprint の required 一覧、Decimal の pattern、x-rule の値（SHALL / SHALL-2027 / MAY）
  • 上記スキーマを JSON Schema 2020-12 に変換し、jsonschema 4.25.1 で本記事の ProductFootprint 例を検証（エラー0件）。および verification: {}、DQR "9.9"、"unknown"、null、必須欠落の各ケースの妥当性
  • wbcsd/pact-openapi の pact-openapi-2.3.0.yaml による v2 の DataQualityIndicators（6項目必須、FloatBetween1And3）と Assurance（assurance 真偽値必須、level、boundary）
  • wbcsd/pact-conformance-service の packages/test/src/schemas/openapi_v3_0.yaml で DQR に pattern が無いこと
  • decisions/log/0044-remove-assurance-flag.md、0031-mandatory-to-optional-attributes.md、0032、0033、0046 の本文
  • 公開された仕様書 HTML（https://wbcsd.github.io/data-exchange-protocol/v3/）の §1.4、§4.5、§4.7、§4.11、§4.12
  • PACT Methodology v3.0 の PDF を取得し pdftotext -layout でテキスト化。§4.2、§4.2.2、§4.2.3、Table 12、§5.2–5.3、用語定義（Data quality）
  • GitHub API によるリリースタグ（v3.0.3 が最新、2025-12-09 公開）

JSON の例は筆者がスキーマに照らして構成したものであり、PACT が公開する公式サンプルではありません。 数値は説明のための架空の値です。公式のサンプルは同リポジトリの spec/v3/examples/ にあります。

リポジトリ内の spec/v3/data-model.md は、私が取得した時点では verification ではなく旧称の assurance を記述しており、uncertaintyAssessmentDescription など公開版に無いプロパティも残っていました。ビルド定義 tasks.py は spec/v3/openapi.yaml から spec/v3/data-model.generated.md を生成する依存関係を宣言しており、公開 HTML のデータモデル節はこちらから作られます。本記事は openapi.yaml と公開 HTML を正とし、data-model.md は参照していません。

参照