DPP登録簿API:バッテリーパスポートをEUに登録する手順を順を追って解説

TL;DR

• 2026年10月30日、欧州委員会はDPP登録簿APIの技術仕様を公表しました。統合ガイド、OpenAPIファイル、サービスアカウントと自社ホスト型の認証ガイド、そしてバッテリーのセマンティックデータモデルです。
• 登録は非同期で、全件成功か全件不成立かのどちらかです。1回の提出で最大100件のパスポートを送り、登録簿が各パスポートをそのウェブアドレスから取得して検証します。1件でも不合格なら、1件も登録されません。
• これまでに定義されている製品グループはバッテリーだけです。EV用、LMT用、および2 kWhを超える産業用バッテリーは2027年2月18日から登録済みのパスポートが必要であり、APIを呼び出す前に、自社の組織が適格電子シールによって検証されていなければなりません。

DPP登録簿APIは、製造者、輸入者、またはそれらのために働くプラットフォームが、ウェブフォームで製品を1件ずつクリックしていくことなく、デジタルプロダクトパスポートをEUに登録するための手段です。登録簿そのものは2026年7月20日から稼働しています。10月30日に届いたのは、開発者がそれに対して実装するために必要な詳細です。エンドポイント、認証、エラーコード、ポーリングのルール、そして登録簿がパスポートを検証する際の基準となるデータモデルです。

本ガイドは、2月までにバッテリーパスポートを登録簿に載せなければならない担当者のためのものです。文書を実際に出会う順に追い、決まっていることとまだ未確定のことを分けて説明します。登録簿とは何か、なぜ存在するのかについては、当社のEUのDPP登録簿の解説を参照してください。以下の内容はすべて2026年11月時点のものです。

欧州委員会は10月30日に何を公表したのか

六つの技術文書が、告知のニュース記事もないまま、欧州委員会のDPPリソースページに掲載されました。これらは2026年9月の経済事業者向けユーザーガイドと並んで置かれています。

10月19日には、欧州委員会はバッテリーパスポートのガイダンスのバージョン3.2も公表しており、バッテリーのカテゴリー別にデータポイントを列挙しています。これについては後述します。

拘束力を持つのは、2026年7月16日付の欧州委員会実施規則(EU)2026/1778です。第3条(b)は登録のためのAPIを定め、第8条第6項はユーザーインターフェースまたはAPIを通じた登録を認め、第8条第7項はセマンティクスと粒度の自動チェックを求めています。今回の仕様は、欧州委員会がこれらの条文を実装する方法です。

登録簿はパスポートをどう扱うのか

登録簿はインデックスであって、保管庫ではありません。パスポートごとに固有製品識別子(UPI)を送りますが、APIはそのUPIがHTTPSのURLであることを求めます。提出時に、登録簿はそのURLにアクセスしてパスポートを取得し、製品グループのデータモデルに照らして検証します。統合ガイドの言葉を借りれば、登録簿は「取得したDPPペイロードの内容を保持しない」(原文:"does not persist the fetched DPP payload content")のです。

この一つの設計上の選択が、エンジニアリング作業の大半を左右します。パスポートは、後からではなく、提出する時点でオンラインにあり、完全で、有効でなければなりません。登録簿がそこに到達できなければ、その項目はUPI_NOT_RESOLVABLEで不合格になります。内容がスキーマに合致しなければ、ITEM_NON_COMPLIANTとして不合格になります。先に登録して後からパスポートを公開するワークフローは機能しません。

登録が成功すると、実施規則の第9条により、欧州委員会の適格電子シールが付された登録証明が得られ、90日間利用できます。ダウンロードして保管してください。それが、パスポートが登録されたこととその日時を示す証拠になります。

最初のAPI呼び出しの前に何を整えておく必要があるのか

多くのチームが予想するより多く、しかもそのほとんどはコードではありません。

検証済みの組織。 ユーザーはEU Loginでログインしますが、APIは検証されていない組織からのリクエストを403で拒否します。実施規則の第4条により、法人は適格電子シール(または属性の電子証明)によって自らの身元と所在地を証明します。個人事業主は、適格電子署名、またはeIDAS保証レベル「高」のeIDを利用できます。実務上は、登録簿が欧州委員会のシール付きの宣言を発行し、それに署名またはシールを付します。検証済みのステータスは、識別手段の有効期限が切れるまで、かつ最長3年間有効であり、その後は再度検証を受けなければなりません。

適格シールは適格トラストサービスプロバイダーから取得するもので、そのプロバイダー独自の本人確認があります。自社がシールを保有していないなら、ここから始めてください。

管理者とサービスアカウント。 組織の管理者が、登録簿のインターフェースでサービスアカウントを作成します。サービスアカウントは検証済みの組織に紐づく人間以外のアイデンティティであり、DPPの登録を許可するロールが必要です。組織はアクセストークンから特定されるため、リクエストで組織IDを渡すことはありません。

製品分類。 各提出では製品グループとサブグループを指定します。これらはハードコードせず、GET /api/v1/dpp/product-groupsから取得します。現在、この呼び出しが返すグループはBATTERIESの一つだけで、EV、LMT、産業用のサブグループがあります。

サービスアカウントはどう認証するのか

登録簿は、private_key_jwtを用いたOAuth 2.0のクライアントクレデンシャルを使います。ガイドの表現は率直です。「共有クライアントシークレットはサポートされていない」(原文:"Shared client secrets are not supported.")。自社のシステムが秘密鍵を保持し、有効期間の短いアサーションに署名し、それをアクセストークンと交換します。

つまずきやすい点は次のとおりです。

• 楕円曲線鍵のみ(ES256、ES384またはES512)。RSA鍵は受け付けられません。公開鍵はJWKまたはPEMとしてアップロードし、ガイドは秘密鍵をハードウェアセキュリティモジュールに保管することを推奨しています。
• 短いアサーション。 クライアントアサーションの有効期限は60秒から120秒とし、決して5分を超えないようにし、毎回新しいjtiを使う必要があります。
• リソースインジケーター。 トークンリクエストでは、環境ごとに公表されている値を使って、登録簿をリソースとして指定しなければなりません。
• 短いトークン。 アクセストークンの有効期間は最長15分なので、長時間のバッチ処理の途中でクライアントがトークンを更新しなければなりません。
• 上限。 サービスアカウントは組織あたり最大5つ、アカウントあたり有効なクレデンシャルは2つまでで、これによりダウンタイムなしの鍵ローテーションが可能になります。クレデンシャルの有効期間は1年が推奨され、最長2年です。

プラットフォームが代わりにパスポートを登録する場合、バージョン1.0の文書が説明しているモデルは、自社の検証済み組織の中に置かれたサービスアカウントです。現在の統合はそのように機能しますが、それが法律の認める唯一の経路ではありません。実施規則は、事業者に代わって行動する検証済みの第三者についても定めています。第6条第1項は、EU法が定める場合に、検証済みの事業者がアクセス権を第三者に委任することを認め、第8条第2項はその場合に検証済みの第三者が登録行為を行うことを認め、第19条第4項は事業者から権限を与えられた第三者が自ら検証を受けることを求めています。登録簿は検証済みのDPPサービスプロバイダーのリストも保持します(第3条(f))。その委任が技術的にどう機能するかは、統合ガイドにはまだ記載されていません。いずれの経路を使う場合でも、コンプライアンスについては経済事業者が引き続き全面的に責任を負います。

登録の提出はどう機能するのか

流れは四つの呼び出しで構成されます。製品グループを取得し、提出し、その後、欧州委員会がActivity Dashboard APIと呼ぶものを通じてタスクを追跡します。

POST /api/v1/dpp/submission
Authorization: Bearer <access token>
Idempotency-Key: 7f3c9a2e-batch-2027-02-01-001
Content-Type: application/json

{
  "productGroup": "BATTERIES",
  "productSubGroup": "EV",
  "submissionItems": [
    {
      "uniqueProductIdentifier": "https://example.com/dpp/battery/0001",
      "granularity": "item",
      "batchIdentifier": "xxx-000",
      "modelIdentifier": "yyy-111"
    }
  ]
}

このボディは公式の例に沿ったものです。uniqueProductIdentifierとgranularity(item、batchまたはmodel)はすべての項目で必須であり、バッチ識別子とモデル識別子は任意です。

登録簿はtaskIdを付けて202 Acceptedを返します。202は、リクエストが処理のために受け付けられたことしか意味しません。その後GET /api/v1/tasks/{taskId}をポーリングし、どの項目が合格したかを知る必要があるときはGET /api/v1/tasks/{taskId}/itemsを呼び出します。これはJSONまたはCSVを返します。

重要なステータスフィールドは二つあり、意味が異なります。タスクのstatusはPENDING、PROCESSINGを経てCOMPLETEDまたはERRORになります。完了すると、outcomeResultがSUCCEEDEDまたはFAILEDを示します。タスクはCOMPLETEDでありながら結果がFAILEDになることがあります。処理は機能したが、データが合格しなかったということです。ERRORは登録簿側の技術的な障害です。

webhookはありません。ガイドは1、1、2、3、5、8、13、21、34、55秒の間隔でポーリングし、その後は最短でも60秒ごととすることを推奨しており、Retry-Afterヘッダーは常に自社のスケジュールより優先されます。

バッチ設計を左右すべきルールはアトミック性です。1回の提出には同じ製品グループとサブグループのパスポートを1件から100件まで含められますが、そのうち1件でも不適合なら、合格したものも含めて1件も登録されません。100件のバッチに不良レコードが1件あれば、良好な99件が足止めされます。当社であれば、提出前にすべてのパスポートを公表されたスキーマに照らしてローカルで検証し、データがまだ固まっていない間はバッチを小さく保ち、不合格の後は問題のない項目を速やかに再提出します。

Idempotency-Keyヘッダーは必須で、最大128文字です。同じキーで再試行すると、重複を作成するのではなく元のタスクが返されます。これはタイムアウトや500の後に望ましい動作です。内容を変更した提出には新しいキーが必要であり、異なる内容に同じキーを再利用すると409が返されます。

エラーコードは一般的なもの(400、403、409、413、422、429、500)で、ガイドはそれぞれについて、同じキーで再試行すべきか新しいキーを使うべきかを示しています。403は通常、組織が検証されていないか、サービスアカウントに登録ロールがないことを意味します。

パスポートを自社でホストする場合は何が変わるのか

バッテリーパスポートには公開データと制限付きデータがあり、登録簿は検証時にその両方を読み取ります。パスポートが自社のサーバー上にある場合、そのサーバーは登録簿を識別し、一般に見せる以上のものを登録簿に見せなければなりません。

パスポートのホストは、OAuth 2.0のリソースサーバーとして機能します。登録簿はまずクレデンシャルなしでUPIをリクエストし、公開パスポートを期待します。次に、欧州委員会の認証サービスが発行したベアラートークンを付けて同じURLをリクエストし、公開データと制限付きデータの両方を期待します。トークンは短命で(ES384、最長120秒)、スコープdpp:registry:readを持ち、自社ホストのHTTPSオリジン宛てに発行されます。トークンの検証は欧州委員会が公表するJWKSの鍵のみに照らして行い、トークン内部から参照される鍵を使ってはなりません。

レスポンスのルールは厳格です。トークンなし:公開パスポートを返す。有効なトークンで、権限のあるリクエスト元:公開データと制限付きデータを返す。トークンはあるが無効:401を返し、公開ビューへのフォールバックはしない。有効なトークンだがスコープまたはリクエスト元が誤っている:403。キャッシュが二つのバージョンを区別できるようVary: Authorizationを送り、TLS 1.2以降を使ってください。基本のレスポンス形式はJSONで、JSON-LDとXMLも受け付けられます。

ガイドが説明している呼び出し元は一つだけ、登録簿自身です。当局、リサイクル業者、その他の正当な利益を持つ当事者がどう認証するかは扱っていないため、それらには別の答えが必要になります。誰が何にアクセスする権利を持つかは、当社のデジタルプロダクトパスポートのアクセス権に関するガイドで解説しています。固有の事業者識別子もまだ処理されていません。ガイドはそれを将来のバージョンで予定しています。

GS1 Digital Linkの位置づけ

登録簿はリダイレクトをたどりますが、解決全体で最大3回までであり、UPIとすべてのリダイレクトをクレデンシャルなしで解決するため、各ステップは公開で到達可能でなければなりません。これはリゾルバーと両立します。https://id.yourbrand.com/01/09520123456788/21/SN0001のような自社ドメイン上のGS1 Digital Link URIは、各バッテリーに、そのパスポートにつながり、製品上のQRコードとしても機能する永続的なHTTPS識別子を与える一つの方法です。これは必須ではありません。安定したHTTPSのURLであれば、どれでもAPIの形式ルールを満たします。リゾルバーを使う場合は、ホップ数を数えてください。QRのドメインからリゾルバー、ホスティングプロバイダー、最終URLへと至るチェーンは、それだけで3回すべてを使い切ります。ガイドは認証後のリダイレクトを避けることも勧めているため、権限付きのリクエストは直接パスポートに到達するようにしてください。

登録簿はどのデータモデルに照らして検証するのか

Semantic Data ArtifactsのZIPには、登録簿がチェックに使うモデルが含まれています。現時点で存在するのは二つだけで、coreモデルとbatteriesモデル(いずれも1.0.0)であり、EV、LMT、産業用バッテリーのサブグループ別スキーマがあります。それぞれがJSON Schema(draft 2020-12)、JSON-LDコンテキスト、SHACLシェイプ、SKOS語彙として提供され、さらにDCAT-APカタログが付いています。ガイドはXSDについても説明していますが、今回のリリースには含まれていません。

スキーマはアクセスレベル別に分かれています。公開ビュー(pub)と三つの制限付きビュー(res1、res2、res3)です。パスポートは適切なリクエスト元に適切なフィールドを示さなければならず、どのフィールドがどこに属するかはスキーマが教えてくれます。ZIPには各スキーマに適合するサンプルインスタンスも含まれており、最初のテストフィクスチャとして役立ちます。

四つのシリアル化形式(JSON、JSON-LD、XML、RDF)が説明されていますが、EN 18216:2026に沿って、登録に必須なのはJSONだけです。ガイドは相互運用性に関してEN 18223:2026も引用しています。両規格についてはCENのDPP規格に関するガイドで、構造化データがなぜ重要かについては機械可読なデジタルプロダクトパスポートに関するガイドで解説しています。実施規則の第12条は、セマンティックリポジトリが無料で利用でき、公開APIを備えることも定めています。

バッテリーガイダンスv3.2は何を加えるのか

2026年10月19日付のバージョン3.2であるGuidance Document: Digital Batteries Passport, data points by categoryは、EV用、LMT用、産業用バッテリーについて71のデータポイントを列挙しています。これはガイダンスであり、自ら法的拘束力はないと述べています。義務はバッテリー規則(EU)2023/1542に由来します。

各データポイントとバッテリーカテゴリーについて、ガイダンスはステータスを示しています。必須、任意(データがあれば記入)、該当する場合、特定のバッテリー種類のみ、そして2027年2月時点では記入も表示もしない、のいずれかです。計画に役立つのは最後のステータスです。たとえばカーボンフットプリントの宣言とラベルは、その形式がまだ実施法を待っているため2027年2月には記入しないとされており、使用説明書はOmnibusを待って保留となっています。各データポイントにはアクセスレベルもあります。公開、正当な利益を持つ者・認証機関・加盟国当局・欧州委員会に限定、またはより狭い制限レベルです。スキーマのpubビューとresビューが実装しているのは、これらのレベルです。

法的要件は当社のバッテリーパスポートのガイドで扱っています。統合作業では、v3.2を自社の製品データとスキーマのフィールドを対応づけるマッピングシートとして使ってください。

何が決まっていて、何がまだ未確定なのか

決まっていること:エンドポイント、認証モデル、アトミックなバッチのルール、ポーリング、batteriesデータモデル、そして提出時にパスポートが稼働していなければならないという要件です。適格シールによる検証は、実施規則そのものに定められています。

2026年11月時点でまだ未確定のこと:事業者に代わる検証済み第三者による登録が技術的にどう機能するか、バッテリー以外のデータモデル、カーボンフットプリントの形式、他の当事者が自社ホスト型パスポートに対してどう認証するか、そして固有の事業者識別子です。実施規則は建設製品、玩具、洗剤も対象としていますが、これらにはまだデータモデルがありません。バッテリー以外の製品については、義務は各委任法から少なくとも18か月後に始まります。加盟国は2027年2月18日までに各国の登録簿管理者を指名しなければなりません(第7条)。

バージョン1.0の文書の粗い点

最初のリリースには必ず不整合があり、コードを書く前に知っておく価値があるのは次の点です。

• Service Accountガイドは、APIのベースをreg.product-passport.ec.europa.euとしていますが、OpenAPIファイルはregistry.product-passport.ec.europa.eu(受け入れ環境にはregistry.acc.product-passport.ec.europa.eu)を使っています。本番環境を設定する前に、登録簿で現在の値を確認してください。
• 100件の上限はガイドには記載されていますが、OpenAPIスキーマでは強制されていないため、スキーマから生成したクライアントは101件のリクエストを平然と組み立ててしまいます。
• 統合ガイドはエラー時に識別子をtraceIdとして返すとしていますが、OpenAPIのエラースキーマではそれをcorrelationIdと呼んでいます。両方をログに記録してください。
• APIはサブグループコードEVを使いますが、セマンティック成果物のパスではevbが使われています。明示的に対応づけてください。

いずれも統合を妨げるものではありませんが、文書の新しいバージョンが出るたびに再確認してください。

いま何をすべきか

1. 適格電子シールを取得してください。 自社がまだ保有していなければ適格トラストサービスプロバイダーから取得し、登録簿で組織の検証を受けてください。このリストの中で最もリードタイムが長い項目です。
2. 受け入れ環境に登録し、 サービスアカウントを作成できる管理者を指名してください。
3. パスポートをどこに置くかを決めてください。 自社のサーバーに置くなら、そのサーバーが自社ホスト型の認証ルールを実装しなければなりません。あるいは、すでにそれに対応しているプロバイダーに置きます。
4. UPIを確定してください。 バッテリーごとに安定したHTTPSのURLパターンを選び、item、batch、modelのいずれの粒度にするかを決め、チェーン内のリダイレクトを数えてください。
5. データをv3.2とbatteriesスキーマに対応づけてください。 フィールドごとに、公開ビューと制限付きビューも含めて行います。2027年2月に必須でないものには印を付け、誰もそれに時間を浪費しないようにしてください。
6. 提出前にローカルで検証してください。 同梱のJSON Schemaに照らして検証し、1件の不良レコードが残りを足止めしないようにバッチを設計してください。
7. クライアントをきちんと構築してください。 HSMに保管したEC鍵、トークンの更新、再現可能なべき等キー、フィボナッチ間隔のポーリング、そしてすべての登録証明の保管です。
8. 受け入れ環境で完全なテストを実施してください。 2027年2月18日より十分前に、不合格のバッチと鍵ローテーションも含めて行ってください。

Digital LinkはGS1ソリューションパートナーであり、当社のプラットフォームは、製品ごとの永続的なGS1 Digital Link識別子の上にバッテリーパスポートと製品パスポートを構築し、公開データと制限付きデータを同じレコードから提供します。当社は独自の登録簿統合を準備しています。これには三つの別個のステップがあります。当社の適格電子シールの取得、登録簿における当社の検証の完了、そしてAPI接続の構築とテストです。当社はまだ登録簿に接続していません。登録簿統合を計画したい場合や、自社のパスポートデータが検証に合格するかを確認したい場合は、お問い合わせください。当社のチームがお客様のケースを確認します。

よくある質問

DPP登録簿APIは必須ですか。

いいえ。実施規則(EU)2026/1778の第8条第6項は、ユーザーインターフェースまたはAPIを通じた登録を認めています。実務上は、ごく少数を超えるパスポートを登録する人なら誰でもAPIを使いたくなるでしょう。

登録簿は自社のパスポートデータを保存しますか。

いいえ。提出時に検証のためにURLからパスポートを取得しますが、統合ガイドは取得した内容を保持しないと明記しています。パスポートは自社がホストする場所に残ります。だからこそ、提出時に到達可能でなければならないのです。

サービスアカウントにRSA鍵やクライアントシークレットを使えますか。

いいえ。サービスアカウントは、楕円曲線鍵(ES256、ES384またはES512)を用いたprivate_key_jwtで認証します。共有クライアントシークレットとRSA鍵はサポートされていません。

バッチ内の1件のパスポートが検証で不合格になるとどうなりますか。

提出全体が不合格となり、そのパスポートは1件も登録されません。タスクは結果FAILEDで完了し、項目ごとの結果からどの項目が原因かがわかります。それらを修正し、新しいべき等キーで再提出してください。

パスポートを登録するのにGS1 Digital Linkは必要ですか。

いいえ。固有製品識別子は、パスポートに解決されるHTTPSのURLでなければなりません。自社ドメイン上のGS1 Digital Link URIはそれを満たす一つの方法で、製品のQRコードも兼ねますが、安定したHTTPSのURLであればどれでも受け付けられます。

バッテリーパスポートはいつまでに登録しなければなりませんか。

EV用バッテリー、LMT用バッテリー、および2 kWhを超える産業用バッテリーについては、規則(EU)2023/1542に基づくバッテリーパスポートの義務が2027年2月18日から適用されます。登録簿とその受け入れ環境はすでに開いているので、先にテストする時間があります。