DPPのデータはどこに持つか｜デジタル製品パスポートにブロックチェーンは要るか

EUのデジタル製品パスポート（DPP）は、2027年2月18日から始まります。最初は一部の大型電池の電池パスポートです。対象は、LMT用電池、容量2 kWh超の充電式産業用電池、EV用電池です（Regulation (EU) 2023/1542, Article 77）。その後、ほかの製品群にも広がっていきます。

準備を任された製造業のDX・IT責任者が、まず社内で聞かれるのが「DPPはブロックチェーンでやるのか」です。EUのルールを読むと、求められているのは、製品ごとの識別子、機械で読めるデータの形式、見る人ごとのアクセス制御などです。特定のブロックチェーンは指定されていません。ですから、先に決めるのはブロックチェーンではなく、次の3つです。

• 製品を、どの単位で見分けるか（モデルか、ロットか、1個ずつか）
• どの情報を、誰が作り、誰が直すか
• 誰に、何を見せるか

電子署名と、追記しかできない監査ログを持つ通常のデータベースでも、ルールの多くは満たせます。ブロックチェーンを使うかどうかは、複数の企業で一緒に確かめる必要がある記録に限って判断します。それ以外の情報は、今の業務システムに残します。

以下では、どの情報を今のシステムに残し、どれをブロックチェーンに記録しうるかを、作る順に見ていきます。DPPの制度の概要、対象製品、時期はデジタル製品パスポート（DPP）とは、先に始まる電池の制度はバッテリーパスポートとはで解説しています。

この記事でわかること

• DPPのデータを、どのシステムに持たせ、誰に責任を持たせるか
• 製品の見分け方と、公開・取引先・当局・個人の見せ分け方
• ブロックチェーンを使うべきかを決める3つの問いと、試験導入の進め方

DPPは1枚の製品ページではない。識別子から、いくつもの正本へたどる仕組み

EUのESPR（持続可能な製品のためのエコデザイン規則）第9〜11条は、DPPについて次のことを求めています（Regulation (EU) 2024/1781, Articles 9–11）。

• ずっと使える一意の製品識別子と、データキャリアにつなぐこと
• データを、オープンな標準に沿った、機械で読めて・構造化され・検索でき・移せる形にすること
• アクセスを製品群ごとの権利に沿って制御し、顧客の個人データは明示の同意なしにDPPへ保存しないこと

2026年7月に動き始めた欧州委員会のDPPレジストリも、製品データを中央に集める作りではありません。事業者が登録するのは、一意の製品識別子と関連するメタデータです。製品データそのものは、分散して保管します（European Commission: The Digital Product Passport Registry is now live）。

ですから、QRコードの飛び先に全部の項目を埋め込む作りにはしません。識別子を入口にして、見る人と権限に合った情報源へ案内するリゾルバー／APIが要ります。

DPPを形作る記録と、その正本の候補は次のとおりです。

それぞれをDPPでどんな形で見せるかは、後半の「実装する人向けの詳細」にまとめました。

項目を並べる前に、誰が作り、確かめ、直すかを決める

DPPの項目の一覧を作るだけでは、値が正しいと言える理由も、いつまでに更新するかも決まりません。そこで1つひとつの値に、次の情報を付けます。

• 何についての値か、誰が作ったか、根拠は何か
• いつからいつまで有効か
• どの形式の版で書かれ、どの古い値を置き換えたか

値を入れるサプライヤーと、その値を承認する製造者は、別の役割にします。自己申告の値と、第三者が確かめた値は、画面でもAPIでも見分けられるようにします。

たとえば材料の構成は、部品サプライヤーが出します。それを対象モデルに使うと決めるのは完成品メーカーです。試験結果の一部は、認証機関が発行することもあります。「全員が同じ台帳に書く」だけでは、責任の分け方になりません。更新の権限、承認の条件、記録、訂正の手順を、項目ごと、あるいは主張データごとに決めます。複数の企業で正本と訂正の責任を合意する進め方は企業間トレーサビリティのデータガバナンスで詳しく扱います。

訂正のたびに過去の値を上書きすると、リコールや監査のときに「その時点で、誰がどの値を示していたか」を再現できなくなります。そこで、新しい主張データが古い版を参照する形で追加します。こうすれば過去を再現でき、誤りをずっと固定してしまうこともありません。データの例は後半に載せました。

製品の見分け方は、モデル・ロット・1個ずつのどれにするか

ESPRでは、どの細かさでDPPを作るかを、製品群ごとの委任法令で決める作りになっています。同じ説明書や材料の仕様ならモデル単位。製造ロットの試験結果ならロット単位。修理の履歴や本物かどうかは、1個ずつです。

全部を1個ずつにすると、件数と運用の費用がふくらみます。モデル単位だけでは、1個ごとの回収や修理を表せません。業務で起きる出来事に合わせて、細かさを選びます。

• モデル：設計の仕様、修理の手順、一般的な材料・性能など、多くの製品で共通する情報
• ロット：製造期間、工場、材料のロット、品質試験など、同じ生産のまとまりで共有する情報
• 個体：個体番号、所有権の移転、修理、再使用、個体ごとの状態など、1点ごとに変わる情報

包装に印刷したコードは、出荷した後では直せません。そこで識別子は、画面のURLとは切り離しておきます。GS1 Digital Linkは、GS1の識別子をWebのURIで表す標準です。GTIN（国際取引商品番号）、GLN（企業・事業所識別コード）、SSCC（物流単位識別コード）などが対象で、バーコードからオンラインの情報へつなげます。リゾルバーを使えば、包装の2次元コードはそのままで、DPP、取扱説明、修理情報など複数のリンク先を差し替えられます（GS1 Digital Link）。

ラベルの貼り替えへの強さは、別の問題です。ブロックチェーンに識別子を書いても、QRラベルを複製されたら本物だとは保証できません。偽物が出回ると困る製品では、次のものを組み合わせます。

• 開けたり改ざんしたりすると跡が残る封印
• NFC（近距離無線通信）などを使うチャレンジレスポンス認証（読み取り機が出した問いに、製品のチップが鍵で答える方式）
• 製造時の安全な鍵の設定

データキャリアを交換するときや、無効にするときの手順も用意しておきます。

公開・取引先・当局・個人データを分けて見せる

公開のJSONは、誰でも読めます。そこに消費者向けの情報と一緒に、サプライヤーの配合や価格、当局向けの適合資料まで入れれば、取引先の秘密まで公開されてしまいます。欧州委員会のDPP FAQも、アクセス権の管理、情報セキュリティ、データ保護を技術の要素として挙げています（European Commission: Digital Product Passport FAQs）。

見せる相手は、次の4つに分けます。

区分ごとの実装（認証の強さ、キャッシュの可否など）は後半にまとめました。個人の区分は、DPP本体と切り離して持ちます。

見せてよいかの判断には、見る人の役割だけでなく、対象の製品、使う目的、契約、地域、期限も使います。URLは転送されれば誰にでも届くので、URLを知っていることを権限にはしません。返す項目を権限のルールで絞り、断った記録・見た記録・書き出した記録も監査の対象にします。

公開ブロックチェーンに、暗号化した個人データを置くやり方も、原則として避けます。鍵を捨てても、データを消したことになるとは限らないからです。取引先ごとに見せる項目を絞る暗号化や、失効のやり方は機密サプライチェーンデータの共有設計で扱います。

修理や回収の記録は、今の値を書き換えず、出来事として受け取る

修理、部品交換、再販売、回収、再資源化では、複数の組織から同じ出来事が送り直されることがあります。後から訂正されることもあります。

そこで、DPPの今の値を直接書き換えるAPIにはしません。届いた出来事をそのまま保存し、確かめてから、参照用の今の状態を更新します。同じ出来事が何度届いても、反映は1回だけにします。誤った出来事は消さず、取り消しの出来事を追加して直します。

記録では、出来事が起きた時刻と、記録した時刻を分けます。こうすると、通信のない現場での作業や、遅れて届いた報告も扱えます。今の修理状態は、出来事の並びから組み立て直せます。処理の段階と保存する項目は、後半にまとめました。

ブロックチェーンが要るかを、3つの問いで決める

ESPRが求めているのは、オープンな標準、相互運用性、データの完全性、アクセス制御などです。特定のデータベースやブロックチェーンを指定してはいません。電子署名と、追記しかできない監査ログを持つ通常のデータベースでも、多くの要件を満たせます。

GS1 Digital Signaturesも、ブロックチェーンなしで確かめる方法を示しています。データキャリアの中か、Webから取った署名データを検証するオープンな標準です。これで、誰が発行したか、改ざんされていないかを確かめられます（GS1 Digital Signatures）。

ブロックチェーンを検討するのは、次の3つにすべて「はい」と答えられるときです。

1. 同じ記録を確かめる、独立した組織が複数あるか。
2. その組織どうしが、1つの運営者とその監査ログを信頼できない事情があるか。
3. 電子署名、WORM（追記した後は変えられない）ストレージ、第三者のタイムスタンプでは足りない理由を説明できるか。

使う場合でも、本文・証明書・画像は置きません。データの並べ方の手順と版を固定したうえで、ハッシュだけを記録します。通常のデータベース、許可型の台帳、公開ブロックチェーンへのハッシュ記録を条件ごとに比べた表は、後半にあります。判断の問いと構成ごとの比較はEPCIS 2.0とブロックチェーンで詳しく扱います。

おすすめの構成：今の業務システムを正本に残し、署名と必要なハッシュ記録を足す

今のPLM・ERP・QMSは、それぞれの業務データの正本として動いています。これを残したまま、その上にDPP連携の層を置き、識別子、データの形式、権限のルール、出来事、署名をまとめます。こう切り分けておけば、ブロックチェーンを試しても、使う・やめるを切り替えられます。最初の構成として安全なのは、この形です。

1. 業務データの正本：PLM、ERP、QMS、サプライヤーの基盤が、それぞれの業務データの正本を持ち続ける。
2. DPPの主張データの保管：誰が、何の根拠で、いつまで有効か、どの版かを付けた主張データと出来事を保存する。
3. 見せてよいかを判断する窓口：消費者、取引先、当局ごとに返す項目を選び、見た記録を監査する。
4. リゾルバー：ずっと使える製品識別子から、DPPのつなぎ先と関連サービスへ案内する。
5. 完全性を確かめる層：発行者の署名、鍵の失効、WORMの監査ログを基本にする。必要なスナップショットのハッシュだけを台帳に記録する。

ハッシュを記録した後に元のデータを直すときは、古いハッシュを消そうとしません。新しい版のハッシュと、失効・訂正の理由を追加します。確かめる側は、「ハッシュがある」だけで中身が本当だとは判断できません。署名した人の権限、根拠の文書、確認の状態、訂正の履歴をあわせて見ます。

試験導入は1つの製品群・3種類の出来事から始める

全サプライヤーと全項目を一度につなぐと、データの欠けや責任のあいまいさが、技術の問題に見えてしまいます。対象を1つの製品群に絞り、モデル／ロット／個体の細かさを決めます。出来事は、製造・修理・リサイクルなど、価値を確かめられる3種類ほどから始めます。

ブロックチェーンを使うかの判断も、段階ごとに進めます。

• 0. 棚卸し：まだ選ばない
• 1. 見分け方の設計：署名で足りるかを確かめる
• 2. 管理された試験導入：独立した組織どうしの食い違いを測る
• 3. 規模の拡大：必要な範囲だけ採用する

成果は、制度への対応と業務の価値に分けて測ります。

• 制度への対応：必須項目がそろっている率、更新期限を守れた率、アクセス権の正しさ、監査のときに記録を出すまでの時間
• 業務の価値：リコールの対象を絞り込む時間（求め方は製品リコールのデータ設計を参照）、サプライヤーをつなぐ手間、修理の判定時間、再資源化のときに材料の情報が取れた率など

「ブロックチェーンに書いた件数」は、成功の指標にしません。

本番前に確認する10項目

1. 製品群ごとの適用法令、委任法令、必須データ、適用日を最新版で確認した。
2. モデル・ロット・個体の粒度と、識別子の発行・重複・失効・再利用ルールがある。
3. 各フィールドに作成者、承認者、根拠、更新期限、スキーマ版がある。
4. 消費者、取引先、当局、個人データのアクセス区分を分離した。
5. イベントの再送、順序逆転、オフライン登録、訂正、取消を冪等に（何度届いても1回分として）処理できる。
6. 署名鍵の発行、ローテーション（鍵更新）、失効、組織退出後の検証方法がある。
7. 運営者やサービス提供者が終了してもDPPを利用可能にするエクスポート・移行計画がある。
8. ブロックチェーンなしの代替案と比較し、採用理由を具体的な組織間の信頼不足で説明できる。
9. ブロックチェーン上に個人情報、営業秘密、原本、大容量データを書いていない。
10. 制度対応KPIと業務価値KPIを分け、試験導入の中止・拡大条件を決めた。

実装する人向けの詳細

ここからは、DPP連携層を実際に作る開発担当者向けに、前半で後回しにしたデータの形と処理の段階をまとめます。

記録ごとの、DPPで見せる形

主張データの項目と例

各データ要素に、subject（何についての値か）、issuer（誰が作成したか）、evidence（根拠）、valid_from、valid_until（有効期間）、schema_version（形式の版）、supersedes（置き換えた旧版）を持たせます。

{
  "subject_id": "urn:product:example:01:09506000151519:21:SN-1042",
  "claim_type": "recycled_material_ratio",
  "value": 0.42,
  "unit": "ratio",
  "issuer_id": "org:supplier-18",
  "evidence_id": "test-report:TR-8821",
  "valid_from": "2026-07-01T00:00:00Z",
  "schema_version": "material-claim/2.1",
  "status": "VERIFIED",
  "supersedes": null
}

訂正時は、新しい主張データが旧版をsupersedesで参照します。

アクセス区分ごとの実装

ライフサイクルイベントの処理段階

event_id、product_id、event_type、occurred_at、recorded_at、issuer、payload_hash、schema_versionを最低限保存します。試験導入の3種類のイベントは、たとえばmanufactured、repaired、recycledです。

構成ごとの比較表

ハッシュを記録するときは、正規化（データの並べ方をそろえる処理）の手順と版をhash_algorithm、canonicalization_version、schema_versionとして固定します。

XTELAができること

私たちは、既存のPLM・ERP・QMSを正本として残したまま、主張データストア、権限判定ゲートウェイ、リゾルバーからなるDPP連携層を実装します。1製品群・3種類のイベントに絞った試験導入で、公開・取引先・当局・個人のアクセス区分と訂正の流れを実データで確かめ、署名だけで足りるのか台帳が必要なのかを貴社と一緒に判断します。個別製品への法令適用は、弁護士や適合性の専門家と連携して進めます。構成の検討はお問い合わせからご相談ください。

主要参考資料

• Regulation (EU) 2024/1781（ESPR）, Chapter III（2026年9月24日確認）
• Regulation (EU) 2023/1542 concerning batteries and waste batteries, Article 77 and Annex XIII（2026年9月24日確認）
• European Commission: The Digital Product Passport Registry is now live（2026年7月20日公表、2026年9月24日確認）
• European Commission: Explore our Digital Product Passport FAQs（2026年9月24日確認）
• GS1 Digital Link（2026年8月12日確認）
• GS1 Digital Signatures（2026年8月12日確認）

資料の確認日と注意

EUの法令・欧州委員会の資料は2026年9月24日に、GS1の標準は2026年8月12日に確認しました。製品群ごとの必須項目や適用日は、今後の委任法令などで具体化されます。一般的な技術・業務設計の解説で、法務、規制、適合性、会計、税務その他の助言ではありません。製品群ごとの義務、標準、実施時期は更新されるため、個別製品への適用は実装時点の一次資料と専門家の判断で確かめてください。