バッテリーパスポート 対応ガイド｜71項目・RFP・90日PoC

バッテリーパスポート 対応は、QRコードを貼る作業ではありません。EU向けに完成電池を市場投入する企業が、対象判定、71データポイントの責任、BMS・MES・PLM・QMS・ERPの接続、公開範囲、更新、監査証拠までを一つの運用として設計する仕事です。本稿は、タイ・ASEANのEV電池、LMT電池、2 kWh超の産業用電池に絞り、RFPと受入試験へ落とす手順を解説します。

先に結論：2027年対応は「71項目を持つ」より責任と更新経路を決める

2027年2月18日から、EU市場に置かれる、またはEUで使用開始されるEV電池、LMT（軽輸送手段）電池、容量2 kWh超の産業用電池には電子記録であるバッテリーパスポートが必要です。中心となる責任は、部材メーカーやITベンダーではなく、完成電池を市場に置く経済事業者が、情報を正確・完全・最新に保つことです。業務を委託できても、責任が自動的に委託先へ移るわけではありません。

実装の成否は次の七点で決まります。

1. 対象電池、EU市場投入者、モデル、個体の境界を確定する。
2. 71データポイントを一覧で集めるだけでなく、owner、source、frequency、access class、validationへ割り当てる。
3. モデル共通情報と、個体ごとに増える状態・使用履歴を分ける。
4. 公開、legitimate interest、当局・欧州委員会向けのアクセスを分離する。
5. QR、unique ID、DPP Registry、詳細データストアの役割を混同しない。
6. repurpose／remanufacture時に新しいpassportを作り、元passportへ追跡可能にリンクする。
7. RFPで機能だけでなく、FAT/SATで提出する証拠、障害時の可用性、規則変更時の改修責任を契約する。

欧州委員会が2026年8月21日に公表したガイダンスは、71データポイントをmandatory、optional、conditional、2027年2月時点では入力・表示不要に整理しています。ただし同ガイダンス自身が、追加の法的要求を作るものでも、法令の権威ある解釈でもないと明記しています。個別案件の最終判断は、Regulation (EU) 2023/1542、適用時点の委任・実施行為、規格、契約上の役割、必要に応じた専門家確認に基づけます。本稿は法的助言ではなく、実装と調達の設計ガイドです。

バッテリーパスポート 対応の対象判定を最初に行う

「電池を扱う会社だから対象」と一括判定すると、過大対応と抜けの両方が起きます。まず製品、容量、用途、EUでの市場投入・使用開始、経済事業者の役割を製品型式ごとに確認します。

EV電池、LMT電池、2 kWh超産業用電池を混同しない

EV電池は電気自動車用、LMT電池はe-bike、e-moped、e-scooterなど軽輸送手段用として扱われます。産業用電池は広く、工場設備、通信、農業、電力の生成・配電、定置蓄電、他カテゴリに入らない一定の電池などが含まれ得ます。用途の俗称ではなく規則の定義で判断します。産業用電池のpassport閾値は「2 kWh以上」ではなく「2 kWhを超える」です。

タイの製造拠点が直接EUへ売らない場合も商流を追う

タイ工場がEU輸入者へ完成電池を出荷する場合、完成品ブランドへOEM供給する場合、電池を組み込んだ装置としてEUへ出す場合では、誰が何を市場に置くかが異なります。セル供給者は必要データを提供しても、必ずしも完成電池passportの責任主体ではありません。一方、完成電池の経済事業者が責任主体でも、上流から得られない材料組成、デューデリジェンス、再生材、炭素フットプリント等は自社だけでは作れません。商流図に「法的責任」「データ提供」「システム運用」「承認」の四種類の矢印を描きます。

対象判定の成果物

PoC前に、型式、カテゴリ、容量、用途、EU市場投入経路、責任候補、適用データポイント、判断根拠URL、確認者、確認日を持つ対象判定台帳を作ります。判断が変わったときに、どのpassport、ラベル、契約、テストへ影響するかを追えることが重要です。

EU電池規則 2027に向けた責任分担

Article 77(4)は、市場に電池を置く経済事業者に、passport情報の正確性、完全性、最新性を確保させます。他の事業者に書面で代理を認めることはできますが、「DPP SaaSを契約したから法令対応を移管できた」という理解は危険です。RACIはデータポイント群ごとに作ります。

責任表には「誰が入力するか」だけでなく、誰が根拠資料を保有し、誰が変更を承認し、誰が期限切れを検知し、誰が公開停止できるかを記載します。海外本社がcompliance owner、タイ工場がdata owner、EU輸入者がregistration ownerという分担もあり得ます。会社名と担当部署を具体化し、退職・組織変更時にも運用が残るようロールで管理します。

71データポイントをowner/source/frequency/access/validationへ落とす

71という数だけをKPIにすると、「列は埋まったが正本も更新契機も分からない」状態になります。欧州委員会ガイダンスの各行に、実装管理用の五列を追加します。この「71 × 5マトリクス」は本稿の提案モデルであり、規則が指定する帳票ではありません。

71項目を一括で同じ扱いにしない

ガイダンス上のmandatory、optional、conditional、2027年2月時点で入力・表示不要という区分を保持し、電池カテゴリ別の適用性と法的根拠を紐付けます。「optionalだから捨てる」「71項目だから全部必須」のどちらも避けます。conditionalは条件判定式と証拠を持たせ、条件が変われば再評価します。

データ契約を先に決める

各データに、名称、意味、型、単位、許容値、欠測表現、列挙値、時刻基準、ID参照、版、機密区分を定義します。たとえばcapacityだけでは、ratedかremainingか、AhかkWhか、model値かunit測定値かが分かりません。temperatureも現在値、期間統計、イベント時値、保存時耐性範囲では意味が異なります。語義を固定してからAPIを作ります。

変更の頻度を三種類に分ける

1. モデル更新：BOM、chemistry、定格、保証、設計試験の改訂。
2. 個体イベント更新：製造、出荷、修理、事故、状態変更、repurpose。
3. 時系列更新：cycle、SOC、temperature、state of health等の一定頻度・イベント駆動更新。

すべてをリアルタイム同期にする必要はありません。逆に、年一回のバッチでは使用由来データの最新性を満たせない可能性があります。データごとに鮮度SLA、再送、欠測、遅延、訂正を定義します。

モデルデータと個体・使用時系列データを分ける

Annex XIIIは、battery modelに関する情報と、individual batteryに関する情報を分けています。実装でもmodel IDとunit unique IDを別キーにします。

時系列の全生データをpassport表示層へ複製する必要があるとは限りません。必要な粒度、保持、集約、アクセス、ダウンロード範囲を適用規則で確認し、BMS／IoT正本からpassportが参照・提供できる構造にします。センサー交換、時刻ずれ、通信断、unit IDの付け替えを放置すると、見栄えのよいdashboardでも個体証拠として使えません。

公開・legitimate interest・authorityのアクセス分離

バッテリーパスポート QRコードを誰でも読めるからといって、全データを公開してよいわけではありません。Regulationは情報を少なくとも三つのアクセス層へ分けます。

legitimate interestは共有リンクではない

申請者の組織、役割、目的、対象unit、要求データ、期間を確認し、最小限のアクセスを許可します。退職、契約終了、目的終了で失効させます。誰が何を閲覧・取得したかを記録し、機密情報の大量ダウンロード、URL転送、APIキー共有を防ぎます。具体的な対象者と再利用範囲は適用時点の実施行為を確認します。

フィールドと添付証拠の両方を守る

画面で項目を隠しても、PDFの添付、APIレスポンス、CSV export、ログ、検索indexから漏れる場合があります。アクセス制御はフィールド、文書、API、cache、backup、support toolまで一貫させます。公開画面の検索エンジンindexingやエラーメッセージにも機密値を出しません。

QR、unique ID、DPP Registry、DPP data storeの責任境界

四つを同じものとして設計しないことが重要です。

1. QR carrier：電池に付され、人や機械が読み取る入口。印刷品質、耐久、貼付位置、交換手順が必要です。
2. Unique identifier：電池を特定するキー。重複禁止、発番、廃止、再印刷、リンク管理が必要です。
3. DPP Registry：EUレベルのindex。欧州委員会の説明では、unique identifiers、registration data、high-level metadataを保持し、full DPP本文を中央保管する仕組みではありません。適用行為で追加情報が要求される場合は従います。
4. DPP data store / resolver：詳細情報を保持・解決する分散側。責任を持つ経済事業者自身または認めたproviderが運用し、アクセス区分に応じて提供します。

代表的な読取経路は「QR → unique ID / resolver → access decision → DPP data store」で、EU市場投入前には適用法に従いRegistryへ登録します。Registryの稼働だけを待って社内データ整理を延期してはいけません。一方、未確定のAPI仕様を推測で固定し、後から大規模改修することも避けます。Registry adapterを業務データ層から分離し、仕様変更を境界で吸収します。

6システム連携の提案モデル

本稿では、PLM、MES、QMS、BMS、ERP、DPPの6システムを参照構成とします。これは法定のシステム数ではありません。PLMはモデルとBOM、MESはunit genealogy、QMSは検査・適合、BMSは使用状態、ERPは商流、DPPは解決・アクセス・公開を担当します。既存IoT基盤、MDM、data lake、document managementを別に持つ企業では増えますし、MESとQMSが統合されていれば減ります。

設計で必ず入れる非機能要件

• open、machine-readable、structured、searchable、interoperableな提供
• vendor lock-inを避けるdata exportと移行手順
• 経済事業者が消滅・EUで活動停止してもpassportを利用可能にする継続策
• data authentication、reliability、integrity、security、privacy
• 時刻同期、相関ID、監査ログ、署名・hash、版履歴
• 冗長化、バックアップ、復元試験、resolver障害時の案内
• supplier dataの期限切れ、単位不一致、版不整合を止めるquality gate

repurpose・remanufactureでは新passportと元passportをリンクする

電池の状態を既存recordの上書きだけで済ませると、originalの設計・使用・責任履歴が失われます。Article 77(7)では、preparation for re-use、preparation for repurposing、repurposing、remanufacturingを受けた電池に新しいpassportを作り、元の一つまたは複数のpassportへリンクします。責任は、その電池を改めて市場に置く、または使用開始する経済事業者へ移ります。

一対一とは限らない

複数の元packやmoduleから新しい定置用packを組む場合、新passportから複数の元passportへつながる可能性があります。逆に、一つのpackを分解して複数のsecond-life製品にすることもあります。親子関係を単一のprevious_idだけで実装すると表現できません。relation type、source passport、target passport、作業者、作業日時、投入・除外したcomponent、試験、承認を関係テーブルで持たせます。

状態遷移を制御する

original → repurposed → waste → recycledのような許容遷移を定義し、権限のない逆戻りや履歴削除を拒否します。再生後の定格、capacity、safety information、warrantyを元の値から無条件に継承しません。新しいresponsible operatorの承認と、新しいpassportの公開が完了するまで出荷をholdする仕組みが必要です。

90日PoCでバッテリーパスポートを発注可能な形にする

以下の90日はTOMAS TECHの提案モデルであり、法定期間、認証手続、2027年の猶予期間ではありません。対象製品、既存データ、サプライヤー数、実施行為の更新、顧客監査により延長します。目的は「画面を見せること」ではなく、責任・データ・アクセス・証拠の難所を小さな範囲で実証し、量産RFPへ移すことです。

0〜15日：scopeとresponsible operatorを確定

• 代表model 1件、unit 10〜50件程度をモデル前提として選ぶ。
• EV／LMT／産業用2 kWh超の対象根拠を確認する。
• EUの商流、importer、brand owner、manufacturer、service providerを図にする。
• EC 71-point guidanceの版と、適用する委任・実施行為を法務・complianceが確認する。
• 既存DPP総論はEUデジタルプロダクトパスポート対応で共通基盤を整理し、本PoCは電池固有のAnnex XIIIとBMSデータに絞る。

16〜30日：71 × 5マトリクスとgapを作る

• 71行をcategory別にmandatory／optional／conditional／not required as of Feb 2027で保持する。
• owner、source、frequency、access、validationを割り当てる。
• 現在値、根拠document、欠落、system改修、supplier依存を記載する。
• 同じDPPでも材料別要求は異なるため、鉄鋼DPP準備ガイドとのデータownerの違いを確認する。

31〜50日：IDと6システム連携を実装

• model ID、unit unique ID、lot、passport IDの対応を作る。
• PLM、MES、QMS、BMS、ERPから必要データだけを抽出する。
• DPP storeへ正規化し、source record IDとversionを残す。
• QR scanからresolverへ到達し、存在しないID、重複ID、廃止IDを正しく処理する。
• Registry connectionは現行の公式仕様・test environmentで確認し、mockだけを合格にしない。

51〜70日：アクセスとライフサイクルを試験

• public、legitimate interest、authorityの三roleで正・負の試験を行う。
• CSV/API/attachment/log/cacheからの越権取得を確認する。
• BMSのcycle、temperature、SOC、state of health、negative eventをunitへ紐付ける。
• repurposeでnew passportを作り、original passportへリンクする。
• supplier data遅延、通信断、時刻ずれ、重複event、訂正を注入する。

71〜90日：FAT/SATと量産RFPを完成

• requirementごとにtest ID、expected result、evidence、ownerを対応させる。
• FATでdata mapping、access、API、audit、backup/restore、移行性を確認する。
• SATで実機QR、工場network、BMS/MES実データ、運用者、出荷holdを確認する。
• 未解決gap、暫定manual process、規則変更リスク、量産cost driverを承認する。
• 量産展開のwave、supplier onboarding、support、change controlをRFPへ反映する。

バッテリーパスポート RFPに書くべき要求事項

「EU電池規則対応」「DPP対応可能」という一文では比較できません。supplierにYes/Noではなく、方法、制約、責任、証拠、標準機能かcustomか、version、費用発生条件を回答させます。

契約には、データ所有権、providerによる二次利用制限、subprocessor、データ所在、障害通知、脆弱性対応、保守終了、仕様変更、export、契約終了時の移行を含めます。根拠のない「業界標準費用」やROIを前提にせず、cost driverを、対象model数、unit数、BMS更新量、supplier数、接続system数、言語、可用性、保持、監査頻度に分解します。

FAT/SAT受入：画面ではなく追跡可能な証拠で判定する

FATはベンダー・検証環境でmapping、logic、security、interfaceを確認し、SATはタイ工場の実際のscanner、label、network、BMS/MES、operator、shift、出荷手順で確認します。テストデータだけでSATを終えず、承認された代表unitでend-to-endを通します。個別規制の適合性評価や法的確認は、IT受入試験とは別に必要です。

よくある失敗と回避策

QRコードを作って完了にする

QRは入口です。リンク先の識別、access、データ正本、更新、可用性、Registry登録、監査まで通らなければpassport運用になりません。QR読取テストに加え、unitの実体、model、Registry metadata、詳細storeが一致することを確認します。

71項目をExcelで埋めて止まる

初回の一覧はgap分析に有効ですが、設計変更、製造、BMS event、supplier証明更新をExcelへ手作業で追記すると、鮮度と監査性が落ちます。暫定manual processにはowner、二者確認、期限、移行計画を付けます。

全項目を公開する

透明性と機密保持は両立させます。public、legitimate interest、authorityの区分をdata model自体に持たせ、UIだけで隠しません。用途外利用、bulk export、support accessも制御します。

EU DPP Registryをfull DPP databaseと考える

Registryはindexとしての役割が中心です。詳細データを誰がどこで保持し、provider撤退後もどう残し、access requestをどう処理するかは別の設計課題です。

repurposeで元recordを上書きする

new passportとoriginal passportのlineageが失われ、責任者、状態、試験、材料履歴を説明できません。多対多の関係と不可逆なaudit trailを持たせます。

未確定仕様を固定値として契約する

委任・実施行為、標準、Registry仕様は適用時点の最新を確認します。契約ではbaseline date、変更監視、impact assessment、見積、test、releaseを一連のchange controlにします。

タイ・ASEAN拠点での導入ポイント

タイBOIが紹介するBEV・battery assembly投資のように、地域では電池・EVサプライチェーンの具体化が進んでいます。ただし投資案件の存在だけでpassport対象や責任主体は決まりません。EUへ流れる完成品ごとに商流を確認します。

多国籍サプライチェーンでは、日本語、英語、タイ語、ベトナム語の名称差より、共通IDとdata definitionの差が問題になります。現場表示はローカル言語でも、API field、unit、code、timestampは共通辞書へ寄せます。supplier onboardingでは、CSV templateだけでなくsample、validation rule、error return、correction、evidence expiryを配布します。

工場networkが不安定な場合はstore-and-forward、再送、sequence、重複排除を設計します。BMS cloudと工場MESの時刻源が違う場合、UTC正規化と原時刻・timezone保持を行います。データをEU域内へ置けば自動的に適法、域外なら自動的に不可、と単純化せず、個人情報、営業秘密、契約、data transferを専門家と確認します。

発注前チェックリスト

• [ ] 対象をEV、LMT、2 kWh超産業用で型式別に判定した
• [ ] EU市場に完成電池を置くresponsible economic operator候補を商流で確認した
• [ ] 71-point guidanceの参照版と適用法令の確認日を記録した
• [ ] mandatory/optional/conditional/not requiredの区分を保持した
• [ ] 71行すべてにowner/source/frequency/access/validationを割り当てた
• [ ] model ID、unit unique ID、lot、passport IDの関係を定義した
• [ ] PLM/MES/QMS/BMS/ERP/DPPの正本とinterfaceを決めた
• [ ] public/legitimate interest/authorityをUI、API、export、attachmentまで分離した
• [ ] QR、unique ID、Registry、detail storeを別componentとして設計した
• [ ] Registry仕様変更を吸収するadapterとchange controlを用意した
• [ ] repurpose/remanufactureでnew passportとoriginal linkを作れる
• [ ] negative event、temperature、SOC、cycle、state of healthの時刻・品質を管理できる
• [ ] operator/provider停止時の継続、export、restoreを試験した
• [ ] FAT/SATのnegative testと証拠形式をRFPに書いた
• [ ] 90日PoCを法定期間ではなく提案モデルとして合意した
• [ ] 最終法的判断を規則、現行acts、規格、専門家で確認するgateを置いた

まとめ：バッテリーパスポート 対応を出荷可能な運用へ変える

2027年対応の本質は、71項目の表やQR画像ではなく、完成電池の責任者が、modelとunitを識別し、複数システムとsupplierから正しいデータを集め、アクセスを分け、変化を更新し、元証拠まで説明できることです。対象判定、71 × 5マトリクス、6システム連携、Registryとの境界、lifecycle lineage、FAT/SATを一つのtraceability matrixへ結ぶと、RFPは「DPP対応できますか」から「この証拠で受け入れます」へ変わります。

対象電池やEU商流がまだ確定していない段階でも、71データポイントのgap分析、90日PoC、バッテリーパスポート RFP、FAT/SATの検討をご相談いただけます。TOMAS TECHへのお問い合わせから、対象カテゴリ、想定するEU市場投入者、現在のPLM/MES/QMS/BMS/ERPの範囲をお知らせください。

FAQ

バッテリーパスポートはいつから必要ですか？

Regulation (EU) 2023/1542 Article 77(1)では、2027年2月18日から、EU市場に置かれる、または使用開始される各EV電池、各LMT電池、容量2 kWhを超える各産業用電池にpassportが必要です。個別製品の該当性と経済事業者の役割は、適用時点の規則・actsと専門家で確認してください。

電池パスポート 71データ項目はすべて必須ですか？

いいえ。欧州委員会の2026年8月ガイダンスは71ポイントをmandatory、optional、conditional、2027年2月時点では入力・表示不要に整理し、カテゴリ別の適用性と法的根拠を示しています。ガイダンス自体は追加要求や権威ある法解釈ではないため、最新版と法令を併読します。

バッテリーパスポート QRコードに全データを入れますか？

QRはunique identifierにリンクし、passportへアクセスする入口です。全詳細をQR画像内へ格納するという意味ではありません。QRの耐久・読取、identifier、resolver、access、詳細store、Registry登録をend-to-endで設計します。

DPP Registry 接続だけで対応は完了しますか？

完了しません。欧州委員会はRegistryをunique identifiers、registration data、high-level metadataのindexと説明し、full DPP詳細は分散型でresponsible operator側に残るとしています。社内正本、更新、access、継続性、監査は別途必要です。

誰がデータの正確性に責任を持ちますか？

Article 77(4)では、電池を市場に置く経済事業者が正確・完全・最新性を確保します。他社を文書で代理にできますが、IT platformやsupplierへデータ入力を委託しただけで責任が自動移転するとは限りません。

repurposeした電池は元のpassportを更新すればよいですか？

規則は新しいpassportを作り、original batteryまたはbatteriesのpassportへリンクすることを求めます。新しい用途、責任者、状態、試験を新recordで管理し、元履歴は保持します。

90日PoCで法令適合を保証できますか？

90日は本稿の提案モデルで、法定期間でも適合保証でもありません。scope、data、access、lineage、FAT/SATの難所を代表範囲で確認し、量産RFPとgapを作る期間です。適合判断は別途、現行法令と専門家の確認が必要です。

バッテリーパスポート RFPで最重要の成果物は何ですか？

requirement–design–source data–test–evidenceをつなぐtraceability matrixです。加えて71 × 5 matrix、ID仕様、アクセス表、data-flow、lineage、negative test、export/restore、change controlを納入物にします。

参考情報

1. Regulation (EU) 2023/1542 — Articles 77–78 and Annex XIII
2. European Commission — Guidance to support preparations for the Digital Batteries Passport (21 August 2026)
3. European Commission — Digital Product Passport for Batteries
4. European Commission — Digital Product Passport overview
5. European Commission — The DPP Registry
6. Thailand BOI — Hyundai BEV and battery assembly project