デジタル製品パスポート要件をETIMフィールドにマッピングする

デジタル製品パスポートの規制は、求めるものの「形」については異例なほど明確で、その「中身」については異例なほど沈黙している。製品情報は機械可読で、構造化され、相互運用可能でなければならず、国際的に認知されたオープンな標準に立脚していなければならない。ただし、どの標準かは書かれていない。それは製品グループごとの委任法令に委ねられており、その大半はまだ存在していない。

電気設備、空調（HVAC）、配管、建材の製品を手がけるメーカーにとって、これは奇妙な状況を生む。要件が来ることは分かっている。何を求められるかも、おおよそは分かっている。しかし正確な項目名は、まだ知りようがない。そして手元のPIMには、自社製品の技術特性の大半をすでに一義的に記述している分類標準が眠っている。

であれば、取るべき手は決まっている。いま手元にあるものを、合理的に予測できるものへ対応づけ、レコードを先に構築し、規制まわりの配管工事は自社製品を対象とする法令が公表されるまで後回しにすることだ。本稿はその対応づけであり——重要なことに——対応づけが破綻する箇所も含めて示す。

ETIMが実際に与えてくれるもの

ETIMは辞書であって、ファイル形式ではない。その役割は、ドイツのメーカー、オランダの卸売業者、ポーランドの施工業者の三者が、事前に独自のスキーマを取り決めることなく、一つの技術特性を同じ意味で受け取れるようにすることにある。

その意味を担うのは、三種類のコードである。

ETIM 8.0には、5,145のクラスにまたがる18,766の特性が収録されている。各特性は、数値型、数値範囲型、英数字型、論理型という四つのデータ型のいずれかを持つ。

コンプライアンスの観点で効いてくる制約は、見落とされやすい。英数字型の特性は、フリーテキストを受け付けない。 それぞれが許容値のリストに紐づけられており、その値のひとつひとつが固有のEVコードを持つ。保護等級の項目に「IP66程度」と書き込むことはできない。値を選ぶか、そもそも埋めないか、そのどちらかである。

このたった一つの制限が、機械が読めるデータと、機械が評価できるデータとを分けている。適合性を確認する規制当局も、しきい値で絞り込むディストリビューターの調達システムも、「この中で屋外使用に対応しているのはどれか」に答えるAIアシスタントも、まったく同じやり方でその項目を問い合わせる。「相互運用可能」という言葉を「共有されている」の同義語として扱うのをやめたとき、それが実際に意味しているのはこれである。

DPPの要件は、この構造のどこに落ちるのか

要件は四つのグループに分かれ、そのうちETIMの守備範囲なのは二つだけである。

識別——ほとんどETIMの外側

パスポートには、一意の製品識別子と、その発行スキーム、そして事業者識別子が必要になる。ETIMが分類するのは製品が何であるかであって、識別子を発行するわけではない。ここはGS1、あるいは同等のスキームの領分であり、ほかのすべてがこれを鍵として紐づくため、真っ先に決めておくべき事項である。

技術特性——まさにETIMの本領

ここはETIMがそもそもそのために作られた領域であり、対応づけはほぼ一対一になる。寸法、材質、性能定格、電気的特性、保護等級、温度範囲——これらは、単位と許容値が定義されたEF特性として、すでに自社のクラス上に存在している。製品の分類が済んでいるなら、この部分はほぼ完了しており、単にそれをコンプライアンス用のデータだと考えてこなかっただけである。

環境とサーキュラリティ——ETIM xChange 2.0

大半の人がまだ把握していない動きが、ここにある。2025年11月にリリースされたETIM xChange 2.0では、ライフサイクルアセスメントおよび環境製品宣言のデータを扱う拡張環境項目が追加された。ETIM Internationalの環境データワーキンググループとともに開発されたものである。あわせて、包装および包装廃棄物規則を見据えた包装材要素も追加された。

それらの項目が、ある委任法令と一対一で整合するかどうかは、その法令が公表されるまで知りようがない。しかし構造はすでに存在し、バージョン管理され、メーカーによる登録も始まっている。「カーボンフットプリント」と見出しだけが付いた空の列を抱えている状態より、実質的にはるかに良い立ち位置である。

キャリア、レジストリ、アクセス——ここはETIMの外

物理的な製品に付されるデータキャリア、2026年7月に稼働したEUレジストリへの登録、そして段階的なアクセス制御——一部の項目は公開、一部は規制当局やリサイクル事業者だけに可視——は、いずれも分類標準の外側にある。ETIMが教えてくれるのは、あるプロパティが何を意味するかである。それを誰が読んでよいかについては、何も語らない。

コンプライアンスに耐える形のレコードとは

ETIM xChangeは、公開されたJSON Schemaを備えたJSONであり、汎用の製品データと、それを担う取引単位（trade item）とを分離する。以下に示す形はその分離であり、題材には配線用遮断器を使う。

一つ、意図的な省略があるので説明しておく。ETIMのモデルはODC-BYでライセンスされており、本稿はそれを再掲しない。 EC000001とEF000007が登場するのは、ETIM Internationalおよび各国組織が、自らのドキュメントのなかで説明用の例としてこれらを公開しているからである。以下に出てくるそのほかのコードは、すべてプレースホルダーとして示している。実際のコードは、自社が利用しているETIMリリースから取得してほしい——それがライセンスされ、出所が明示され、常に最新である情報源であり、自社の所有物ではない辞書を再配布することは、コンプライアンス用レコードの土台としては心もとない。

{
  "product": {
    "manufacturerProductNumber": "MCB-C16-1P",
    "manufacturerGLN": "<GS1 Global Location Number>",
    "productIdentifier": {
      "scheme": "GS1",
      "value": "<GTIN>"
    },
    "classification": {
      "system": "ETIM",
      "release": "ETIM-8.0",
      "class": "EC000001",
      "features": [
        { "code": "EF000007", "type": "A", "value": "<EV code for colour>" },
        { "code": "EF<rated-current>", "type": "N", "value": 16, "unit": "A" },
        { "code": "EF<poles>", "type": "N", "value": 1 },
        { "code": "EF<tripping-characteristic>", "type": "A", "value": "<EV code for C>" },
        { "code": "EF<ip-rating>", "type": "A", "value": "<EV code>" }
      ]
    },
    "environmental": {
      "epd": {
        "declarationNumber": "<EPD registration>",
        "validUntil": "2029-11-30",
        "gwpTotal": { "value": 2.41, "unit": "kg CO2e" }
      },
      "recycledContent": { "value": 18, "unit": "%" }
    },
    "packaging": {
      "materials": [
        { "material": "corrugated board", "weight": { "value": 42, "unit": "g" }, "recycledContent": { "value": 82, "unit": "%" } }
      ]
    }
  },
  "tradeItems": [
    {
      "gtin": "<GTIN>",
      "packagingQuantity": 1,
      "orderUnit": "PCE"
    }
  ]
}

このレコードについて、取り出しておくべき点が三つある。

分類ブロックは、自らのリリースを持ち歩く。 "release": "ETIM-8.0"は飾りではない。特性はリリースをまたいで移動するため、どの辞書に対して書かれたのかを明示していないレコードは、次のバージョンが出た瞬間に曖昧になる。これは、実運用のETIMデータで最も多い欠陥である。

すべての特性は、自らの型を持ち歩く。 受け手の側は、遮断器について何も知らなくても、"type": "N"を数値として、"type": "A"を許容値リストに照らして検証できる。ファイルを、単にパースできるだけのものではなく、検査できるものにしているのはこの点である。

汎用データと取引単位は分かれている。 製品は一つ、荷姿は複数、技術的な事実は一組。これを平坦化してしまうこと——スプレッドシートベースの交換の大半がやっていることだ——が、10個入りパックが単体の重量を名乗り出す原因になる。

埋まらない穴を、率直に

完全にカバーできると謳うマッピング記事は、何かを売りつけようとしている。正直に挙げれば、穴は四つある。

1. 01大半の製品グループについて、委任法令はまだ存在しない。 確定している唯一の期日は、一部の産業用・EV用・小型モビリティ用電池を対象とする2027年2月18日であり、これはESPRではなく電池規則に基づくものである。DPPの期限を一つだけ挙げてくる相手は、話を単純化しすぎている。
2. 02ETIMの環境項目は新しい。 2025年11月のリリースであり、公表済みの委任法令に照らして検証されたことはまだない。照らす相手が存在しないからである。
3. 03アクセス制御は、フォーマットの側で解決されていない。 規則は段階的な可視性を想定している。ETIM xChangeはそれを表現しない。この責務は、パスポートを配信する側の仕組みが担うことになる。
4. 04分類のカバー範囲にはむらがある。 5,145クラスは確かに多いが、自社製品が特性の乏しいクラスに属している場合、辞書は差別化要因を運んでくれず、結局は添付ファイルとフリーテキストに逆戻りすることになる。

それでもこのレコードを作る価値がある理由

規制をすべて取り払ってみても、この同じファイルは、自社カタログのために構築しうるもののなかで、依然として最も価値の高いものである。

構造化され、型付けされ、辞書に裏打ちされた製品レコードがあるからこそ、ディストリビューターはマッピングのプロジェクトを立てずに自社の品揃えを取り込めるし、調達システムはキーワードではなくしきい値で絞り込めるし、AIアシスタントは自社製品の仕様に関する質問に、推測ではなく自社を出典として引きながら答えられる。この最後の点について当社が984の産業カタログを測定したところ、スコアの中央値は100点満点中50点だった——制約になっているのは、ほぼ常に製品そのものではなく、それを記述するデータがPDFとJavaScriptのなかに閉じ込められていることである。

コンプライアンスの期限は、それ自体で元が取れる作業を前へ進める強制力として働く。これは珍しく居心地のよい状況であり、そう認識しておく価値がある。

どこから始めるか

次の順序で進めるとよい。各ステップが、その次のステップを安くしてくれるからである。

1. 01現在利用しているETIMリリースに対して分類する。 そして、どのリリースなのかを記録する。すでに分類済みであれば、エクスポートにリリースが明示されているかを確認してほしい——明示されていないことが多い。
2. 02ETIM xChange 2.0にエクスポートし、公開されているJSON Schemaに照らして検証する。ここで出る検証エラーは、もともと抱えていながら見えていなかったデータ品質の問題である。
3. 03環境ブロックを埋める。 いま手元にあるEPDおよびLCAのデータを、たとえ部分的であっても入れておく。部分的でも構造化されたデータは、完全でも非構造のデータに勝る。
4. 04識別を確定させる。 GTINまたは同等の識別子と、その発行スキームを決める。パスポートはそれを鍵として紐づくからである。
5. 05データキャリアとレジストリは、自社の委任法令が公表されるまで後回しにする。 ドラフトに合わせて作り込むのは、同じ仕事を二度やることになる典型的な道筋である。

最初の三つのステップは、委任法令が最終的に何を言うかにかかわらず、出来上がったその日から役に立つ資産を生む。誰かがDPP対応の作業を提案してきたときに当てるべき基準は、これである。規制がなければ無価値な作業なら、それはおそらく時期尚早だ。