鉄鋼 DPP 対応｜最終規則前に作るデータ契約とPoC

鉄鋼 DPP 対応は、最終ルールが出てからソフトを選ぶ仕事ではありません。タイ・ASEANの製鉄、加工、サービスセンター、商社、部品メーカーが今始めるべきなのは、EU向け製品について「誰が、どの識別単位で、どの根拠から、いつ有効なデータを渡すか」を決め、例外を含む実データで検証することです。鉄鋼向け委任法令と最終データ一覧はまだ採択されていません。本稿は欧州委員会、ESPR、2026年のJRC作業提案を区別し、データソース、識別子・版、Registry境界、RFP、受入テストへ落とします。

2026年に変わったこと、まだ決まっていないこと

欧州委員会の現行DPPロードマップは鉄鋼を2026年に置き、鉄鋼向け委任法令の採択を2026年第4四半期の目安としています。これは変更され得る予定です。採択後にも少なくとも18カ月の移行期間が示されていますが、採択日、対象製品、最終項目、粒度、アクセス権は製品別委任法令で確定します。

採択済みのESPR（Regulation (EU) 2024/1781）第9～11条と附属書IIIは、永続的一意製品識別子、オープンで相互運用可能な機械可読構造などの枠組みを定めます。一方、データ、キャリア、配置、model/batch/item粒度は製品別ルールに委ねます。「必ずcoil単位」「JRC資料の項目が必須」とは断定できません。

欧州委員会の鉄鋼ページは、製品識別・分類、技術・材料、循環性・再生材、サステナビリティ、適合・トレーサビリティ文書を候補情報群として説明します。JRC/Product Bureauの2026年3～4月資料も、中間鉄鋼製品について既存義務や業界文書から組んだ作業提案であり、採択済みの法定リストではありません。DPP全体像はEUデジタル製品パスポート対応ガイドを参照し、本稿は鉄鋼固有の実装準備へ進みます。

商流ごとの責任を先に決める

EU市場へ上市する経済事業者がDPPの主要責任を負います。しかし一社が製鋼、圧延、スリット、表面処理、輸出をすべて行うとは限りません。タイの供給者がRegistryへ直接登録しない場合でも、信頼できる原データと証拠を契約に従って渡す必要があります。

役割	主な仕事	提供候補	契約上の論点
製鉄・圧延	溶解、鋳造、圧延、検査	heat/cast、成分、工程、試験	最終項目は未確定
加工・サービスセンター	切断、スリット、処理	入出力ID、分割・統合、加工、検査	親子関係を保持
商社・輸入者	契約、輸出入、EU上市	製品ID、供給者証拠、登録情報	EU責任主体を明記
下流顧客	部品化、品質承認	受入単位、用途、要求証拠	アクセス範囲を定義

「DPP対応品を納入」だけでは足りません。EU経済事業者、DPPホスト、Registry登録者、原データ承認者、訂正通知者をRACIで分けます。供給者は一次証拠を提供し、EU側責任者が最終法令に照らして公開・登録内容を決める境界を契約化します。

四つのデータ層を分離する

工場系譜・イベント層：MES、WMS、トレーサビリティDBが受入、製造、分割、統合、再加工、検査、出荷を、時刻、設備、数量、単位、親子ID付きで保持します。
材料・試験証明層：ミルシート、inspection certificate、LIMS/QMSの成分、寸法、機械特性を扱い、証明書番号、版、訂正、承認者、対象IDを構造化します。
サステナビリティ・循環性証拠層：再生材、環境情報、算定境界、係数、対象期間、検証主体を保持します。候補は準備できますが、開示義務は最終規則待ちです。
外部DPP・Registry層：データキャリア、解決先、アクセス、API、Registryへ渡す識別子・登録情報・高レベルメタデータを扱います。

詳細データ本体を一つの中央DBに複製する必要はありません。層を分ければ、工場イベントの訂正時に過去証明を上書きせず、DPPサービスを変更しても原データを保持できます。企業間イベントはタイ製造業のチェーントレーサビリティとEPCISと接続して検討できます。

暫定データソース表：候補であって法的必須ではない

候補データ	所有者	ソース	識別・粒度例	版・有効時点	証拠
製品ID・grade	品質/営業	ERP、仕様マスタ	product/batch/coil候補	受注・製造時版	仕様承認
heat/cast	製鋼	MES、鋳造記録	heat、cast、slab/billet	発生・確定時刻	製造記録
化学成分	ラボ	LIMS、証明書	sample/heat/batch	分析・再分析版	ラボ承認
機械特性	品質	LIMS/QMS	coil/plate/batch候補	試験・承認時	試験成績
寸法・質量	生産/物流	MES、WMS、計量	coil/plate/bundle	計量・訂正時	校正記録
分割・統合	加工拠点	MES/WMS	parent→children等	イベント時刻	作業実績
再生材候補	調達/環境	仕入証拠、台帳	site/period/product候補	期間・方法版	供給者証拠
環境候補	環境	EMS、検証報告	site/route/product候補	報告期間・訂正版	方法・検証
適合証明	品質/法務	DMS/QMS	certificate→対象ID	発行・訂正版	電子承認
登録情報	EU経済事業者	DPP/Registry	persistent ID	登録・更新時	API応答・ログ

この表は最終フィールド名を先取りするものではありません。各候補に、責任者、正本、識別粒度、有効時点、承認証拠が揃うかを問います。「ERPにある」ではなく、どのレコードのどの版が正本で、訂正時に誰が承認し、旧版をどう残すかまで決めます。

heat、coil、plateをつなぐIDと版

鉄鋼には一対一だけでなく、一heatから複数slab、一coilから複数slit coilやsheet、複数材料の統合、再加工があります。唯一の普遍階層を宣言せず、自社の変換系譜を定義します。例はheat → slab → hot-rolled coil → slit coil → shipment batch、またはbillet → bar batch → bundleです。

各単位に永続IDを与え、分割は親、子、投入量、産出量、単位、歩留り、時刻、工程を記録します。統合は全親と出力、証拠を継承する比率・規則を残します。kg/tonne、mm/m等は換算規則、丸め、原単位、規則版を固定します。拠点ローカルIDとグローバルIDの対応には有効期間を持たせ、IDを再利用しません。

訂正は上書きと分けます。証明書が訂正されたら旧版ID、新版ID、理由、承認者、有効時刻、影響製品を保持します。閲覧者には現行版を示しつつ、監査時には当時提示した版を再現できなければなりません。

DPP Registryの境界を誤解しない

欧州委員会はRegistryを、識別子、登録情報、高レベルメタデータのインデックスと説明します。詳細DPPデータは経済事業者またはサービスプロバイダー側に分散保持されます。ミルシートや全工程イベントをEUの一中央DBへ単純にアップロードする構造ではありません。

テスト環境、UI、APIは準備に利用できますが、鉄鋼で最終的に登録する内容は製品別ルールで決まります。PoCでは仮ID、登録メタデータ、応答、更新、取消、再試行、監査ログを試し、API変更を吸収できる接続層を設けます。公開、取引先限定、当局向けアクセスを分け、登録要求、応答、時刻、実行者、API版、失敗理由を証拠として保持します。

RFPに入れる条項

条項	要求内容
範囲・役割	製品、拠点、商流、EU責任者、承認、ホスト、登録
データ契約	項目候補、型、単位、品質、最終規則変更への設定対応
ID・粒度	永続ID、粒度候補、heat/coil/plate系譜、非再利用
出所	原システム、文書、供給者、取得時刻、承認者
版・有効時点	transaction/effective time、理由、旧版、再公開
更新・訂正	遅延、証明書差替え、影響、通知、再登録
アクセス・保存	ロール、失効、証拠、イベント、APIログ、版履歴
API・出力	Registry、ERP/MES/QMS/LIMS、可搬CSV/JSON
セキュリティ	認証、権限、暗号、鍵、監査、事故対応
供給者参加	テンプレート、検証、エラー、教育、SLA
終了・移行	全データ、証拠、ID対応、ログ、削除証明

正常なデモより、証明書訂正、遅着、分割・統合、API停止を評価します。最終法令で項目や粒度が変わった際、設定変更で済む範囲と追加開発範囲を、価格・責任とともに回答させます。

供給者データ契約を「値の受け渡し」で終わらせない

鉄鋼の証拠は一社だけで完結しません。原料供給者、製鉄所、加工会社、試験機関、物流会社から異なる時刻と形式で届きます。データ契約では、フィールド名とファイル形式だけでなく、正確性を表明する主体、提出期限、欠落時の状態、訂正通知、根拠文書の利用権、監査時の再提出まで定義します。

たとえば、出荷時点で供給者の環境候補値が届かない場合、ゼロや前回値で自動補完してはいけません。「未受領」「暫定」「承認済み」を別状態にし、DPPの公開可否を決める責任者を置きます。後日値が届いたら、受信時刻、対象期間、供給者版、承認結果を記録し、どのDPP版が更新されたかを追跡します。

証拠PDFと構造化値の矛盾も想定します。LIMSから取得した成分値と訂正版ミルシートが異なる場合、最後に届いた値を無条件で採用せず、ソース優先順位と不一致ワークフローへ送ります。自動検証は範囲、単位、桁数、gradeとの整合、重複証明書番号、対象IDの存在を確認し、人の承認は例外理由と影響製品を確認します。

供給者が小規模でAPIを提供できない場合も、直ちに排除する必要はありません。管理されたCSVテンプレートやポータル入力を用意し、入力者、アップロード時刻、原本、検証結果を記録します。ただし、手入力を「システム連携済み」と見せず、誤入力率、再作業、承認負荷をPoCで測り、将来の接続優先順位へ反映します。

訂正、取消、遅延を状態遷移として設計する

DPPを一枚の静的ページと考えると、現実の訂正に耐えません。製品データには、作成中、証拠待ち、検証中、承認済み、登録済み、訂正中、失効・取消、アーカイブなどの状態が必要です。どの状態で誰が外部閲覧できるか、出荷できるか、Registry更新が必要かを表にします。

証明書訂正では、原データ修正、影響範囲計算、承認、DPP新版生成、外部通知、必要に応じたRegistry更新を一つのケースとして検証します。途中でAPIが停止しても、内部承認と外部反映を混同せず、再開時に同じ更新を重複送信しない冪等キーを使います。取消時も詳細データを消去するのではなく、アクセス制御と保存規則に従い、取消理由と時刻を監査できるようにします。

有効時点と処理時点は分けます。分析結果が9月1日に有効だったがシステムへ9月3日に登録された場合、effective timeとtransaction timeの両方が必要です。これにより9月2日に顧客が見たDPPを再現しつつ、後日届いた正しい証拠を現在版へ反映できます。

セキュリティと可搬性を受入対象にする

DPPは外部公開を含むため、公開範囲と工場機密を分けます。MESの設備条件、配合、顧客名などを、規制候補データと同じ権限で外へ出してはいけません。最小権限、ロール、期限付きアクセス、サービスアカウント、鍵のローテーション、監査ログ、異常検知、インシデント時の停止・復旧をRFPに入れます。

データキャリアから到達する画面だけをテストせず、APIの認証失敗、期限切れトークン、権限変更、退職者アカウント、委託先終了も試します。顧客が変わったときに旧顧客の限定情報が見え続けないこと、当局アクセスが正しく記録されること、サービス障害時に工場ネットワークへ危険な逆方向接続を作らないことを確認します。

ベンダー終了時の可搬性も重要です。全製品ID、親子系譜、全版、証拠ファイル、アクセス設定、Registry応答、監査ログを、仕様が公開された形式でエクスポートできるかを実演させます。出力ファイルがあっても、証拠へのリンクが切れ、ID対応表がなく、版順序を再構成できなければ移行可能とは言えません。別環境へ一部を読み込み、同じ製品の現行版と過去版を再現するところまでを受入試験にします。

最終委任法令が出たときの差分評価

準備プロジェクトの成果は、暫定項目の件数ではなく、変更を安全に受け入れる能力です。最終法令が公開されたら、対象製品、粒度、必須項目、データキャリア、アクセス、Registry登録、保存期間を暫定契約と比較します。各差分を「既存ソースで取得可能」「供給者契約変更」「マスタ/系譜変更」「新規証拠」「システム設定」「追加開発」「法務判断」に分類します。

次に、欠落件数、対象製品、供給者、過去データへの遡及、試験再実行を評価し、適用日から逆算した計画へ更新します。JRC候補にあった項目が最終法令にない場合も、事業上必要かを判断して保持または廃止します。反対に新項目が追加されても、原本・所有者・版・承認という共通データ契約があれば、単なる列追加ではなく統制された変更として扱えます。

TOMAS TECH提案の90日準備評価

これはEU期限でも導入期間の保証でもなく、最終規則前に判断材料を作る計画フレームです。対象、拠点、既存品質、関係会社数に応じて調整します。

棚卸し：EU向け一製品フローを選び、役割、原本、所有者、ID、版、欠落、手入力を確認します。
暫定データ契約：型、単位、粒度候補、親子、effective time、証拠、承認、アクセスを定義します。JRC提案を法的必須として固定しません。
一製品フローの証明：実heatまたは受入材から加工、出荷、証明書、外部DPPまでをつなぎ、利用可能な範囲でRegistry登録と応答を確認します。
例外試験：分割、統合、訂正、遅延、単位変換、アクセス変更、API停止、履歴再現を試します。
受入判断：不足、運用負荷、変更耐性、供給者、セキュリティ、可搬性から全面導入、対象追加、データ是正、RFP再設計、保留を判断します。

購入前PoCの受入テスト

テスト	操作	合格結果
ID重複	同一IDを別製品へ	拒否・隔離、理由記録
分割	coil→複数slit coil	親子、数量、証拠を再現
統合・混合	複数親→一出力	全親と配分規則を保持
代替材	承認済みgradeへ変更	承認と有効時点を記録
証明書訂正	新版を発行	旧版保持、現行版提示
供給者遅延	出荷後に値受信	暫定状態、期限、再公開
単位換算	kg/tonne等を混在	規則・丸めを再現
オフライン	接続を切断	重複なく安全に再送
履歴	過去値を訂正	当時版と訂正版を再現
権限変更	顧客ロール失効	即時反映、監査ログ
API障害	timeout/4xx/5xx	キュー、警告、再試行
証拠要求	税関・当局要求	権限内証拠と登録記録
移行	全データ出力	ID、版、証拠を再構成

業務、品質、IT/OT、サステナビリティ、EU側責任者が合否を共同判断します。技術的に動いても、訂正承認者がいない、供給者が期限内に出せない、証拠利用権が不明なら運用不合格です。

経営判断と段階的な次の行動

EU向け対象製品とEU上市経済事業者を特定したか。
最終委任法令未採択を前提に変更予算を持つか。
自社のheat、coil、plate、batch系譜と分割・統合を追えるか。
各候補に所有者、原本、版、有効時点、証拠、承認者がいるか。
供給者契約に品質、訂正、期限、証拠引渡しを入れたか。
Registryと分散データの境界を理解し、全件エクスポートできるか。
正常系だけでなく例外を受入条件にしたか。
最終規則発表後の差分評価責任者を決めたか。

次はソフト選定より先に、一製品フローの棚卸しと暫定データ契約を作ります。候補基盤で一つのDPPを再現し、例外試験の結果からRFPと投資範囲を決めます。

投資判断を三つのゲートに分ける

経営が一度に「全社DPP導入」を承認する必要はありません。第一ゲートはデータ準備、第二ゲートは一製品フローの検証、第三ゲートは展開投資です。各ゲートで成果物と撤退条件を明示すれば、最終法令が未確定でも過剰投資を避けながら前進できます。

第一ゲートでは、EU向け商流と責任主体が合意され、候補データの正本・所有者・版・有効時点が一覧化されていることを確認します。重大な欠落については、供給者契約で取得するのか、自社工程で新たに記録するのか、最終規則まで判断を保留するのかを分類します。この段階の合格は「全データが揃った」ことではなく、「欠落と取得責任が見える」ことです。

第二ゲートでは、一つの実製品を使い、heatまたは受入材から加工・出荷・証明書・外部表示・Registry登録証拠までを再現します。正常系だけでなく、分割、統合、訂正、遅延、権限変更、API障害を通します。不合格がデータ、運用、供給者、製品機能のどこにあるかを切り分け、追加設定、契約変更、開発、対象範囲縮小の費用を見積もります。

第三ゲートでは、対象製品・拠点・供給者を増やした際の運用量を評価します。月間登録件数だけでなく、証拠待ち件数、訂正率、手動承認時間、再試行、問い合わせ、アクセス申請、供給者教育を見積もります。データ品質が安定しないまま範囲だけを広げると、DPPの件数は増えても説明可能性が下がります。拡大条件には、例外処理のSLA、責任者の処理能力、監査サンプルの再現率を入れます。

ゲート	経営が見る成果	次へ進む条件	保留・戻し条件
データ準備	役割表、暫定契約、正本・欠落一覧	重要データの責任と取得方法が合意済み	EU責任主体や証拠利用権が未合意
一製品検証	系譜、DPP表示、登録証拠、例外結果	重大例外を履歴付きで処理可能	訂正で履歴消失、ID再利用、出力不能
展開投資	対象範囲、運用量、費用、変更計画	人員、SLA、移行・終了条件を承認	最終規則差分を吸収する予算・設計なし

また、法令監視をプロジェクトの外に置かないことが重要です。欧州委員会、EUR-Lex、JRC/Product Bureauの更新を確認する担当、確認頻度、判断会議、変更台帳を決めます。Q4 2026や18カ月という目安を計画に使う場合は、取得日と「変更され得る指標」であることを明記し、確定日として生産・契約を拘束しないようにします。

最終的な適用判断は法務・規制専門家とEU側経済事業者が行います。IT/OTや品質チームの役割は、結論を代行することではなく、どの根拠でどの版のデータを提示したかを再現可能にし、判断変更が生じたときに影響製品と必要作業を短時間で示すことです。

投資稟議では、DPP画面の完成度だけを成果にしないことが重要です。第一段階の成果は、対象商流の責任表、暫定データ契約、原本と欠落の一覧、一製品の系譜、例外試験記録、最終規則差分を受ける変更台帳です。第二段階へのゲートには、重大なID不整合が解消したこと、証明書訂正を履歴付きで処理できたこと、主要供給者が期限と証拠条件に合意したこと、全件エクスポートから再構成できたことを置きます。

全面展開は、対象製品数ではなくデータ品質と運用責任を基準に段階化します。まず一拠点・一製品フローで承認を安定させ、次に加工拠点や供給者を追加し、最後にEU側の登録・アクセス運用を広げます。法令が未確定な段階で全製品を一括変換すると、後の差分修正が大きくなります。逆に、系譜と証拠の基礎を先に整えれば、最終項目の増減に対して再利用できます。

また、経営会議では「規制対応の有無」だけでなく、未決事項と前提を明示します。Q4 2026や18カ月という表現には必ず“indicative”と情報取得日を付け、誰が欧州委員会と最終委任法令を監視するかを決めます。規制・法務判断は専門家とEU側責任者が行い、IT/OTチームは判断に必要な証拠、履歴、テスト結果を提供します。

FAQ

鉄鋼 DPP 対応はタイ企業にも必要ですか？

所在地だけでは決まりません。対象製品がEU市場へ上市されるか、商流上の役割、今後の鉄鋼向け委任法令で判断します。EU側が主要責任を負っても、タイ供給者には信頼できる材料・工程・証明データが契約上求められ得ます。

鉄鋼デジタル製品パスポートの項目は確定済みですか？

いいえ。ESPRの枠組みは採択済みですが、鉄鋼向け委任法令と最終項目は未採択です。委員会の分類やJRC提案は準備材料で、法的必須一覧ではありません。

DPP Registry APIへ全データを送りますか？

いいえ。Registryは識別子、登録情報、高レベルメタデータのインデックスで、詳細は経済事業者またはサービス側へ分散保持されます。鉄鋼の最終登録内容は製品別ルールに従います。

model、batch、itemのどの単位ですか？

最終粒度は未確定です。coil等を決め打ちせず、heat/cast、slab/billet、coil/plate、加工・出荷単位を結び、複数粒度へ対応できる変換系譜を準備します。

中小企業は何から始めますか？

EU向け代表製品一つで、役割、ID、証明書、所有者、訂正を表にします。ERP、Excel、PDFの現状と欠落を確認し、取引先とのデータ契約から始められます。

ソフト購入前に何を試しますか？

ID重複、分割・統合、証明書訂正、遅延、単位変換、権限変更、API停止、履歴非上書き、全件出力を試し、最終規則変更を設定で吸収できる範囲を確認します。

まとめ：最終規則前に変更可能な証拠基盤を作る

鉄鋼 DPP 対応の現在地では、未確定項目を固定するのではなく、EU上市責任と供給者責任を分け、工場系譜、材料証明、サステナビリティ証拠、外部DPP/Registryを四層化します。heatから出荷までのIDと版をつなぎ、供給者契約、RFP、例外試験を整えれば、最終委任法令との差分を安全に反映できます。

準備状況は「画面があるか」ではなく、原本から提示データまでを説明でき、訂正後も過去の提示内容を再現できるかで評価します。この基準なら、特定製品やサービスに依存せず段階的に改善できます。

TOMAS TECHは、タイ・ASEANの鉄鋼メーカー、加工会社、商社、部品メーカー向けに、商流整理、データ棚卸し、RFP、DPP/Registry PoC、受入テスト設計を支援します。規制適合を保証するものではありませんが、検討段階から投資判断に必要な証拠と未決事項を整理できます。お問い合わせはこちら。