製品リコールの対象製品リスト管理｜ブロックチェーンに記録するもの・社内に残すもの

ある製造会社で、部品ロットC-42に欠陥が見つかりました。品質の責任者がまずしなければならないのは、この部品を組み付けた製品を割り出し、販売店や修理事業者に知らせることです。

責任者は、製造の記録からC-42を組み付けた製品を探し、出荷の記録と突き合わせて最初のリストを作ります。ところが、記録は一度にそろいません。出荷の記録が遅れて届けば、そこで対象が増えます。販売店や修理の記録を見ていくと、すでに部品を交換した製品や、返品・廃棄された製品、行き先の分からない製品も出てきます。調べが進むたびに、リストは書き換わっていきます。

書き換わるたびに、販売店に渡したリストは古くなります。リコールは経済産業省へ報告し、その後も進み具合を定期的に報告します。ところが上書きを重ねたリストでは、ある時点でなぜこの製品を対象から外していたのかが、あとから分からなくなります。

こうした混乱を防ぐ鍵は、対象製品のリストを「版」として残すことです。どの記録から、どんな条件で対象を決め、誰が承認したか。これをリストと一緒に、変更のたびに新しい版として記録します。

ブロックチェーンを使うなら、役割は限られます。関係する各社が一緒に確かめる必要のある証跡（「同じ版のリストを見ている」と確かめるための要約値と承認など）だけを、記録する候補にします。購入者の連絡先や通知、返送・修理の証憑は、社内の業務システムで管理します。そして、チェーンが止まっても、通知と回収は止めません。

以下では、この会社がC-42のリコールを進める流れに沿って、対象の決め方からチェーンの役割、状態の管理、障害時の動き方までを見ていきます。製造・流通の担当者に加え、デジタル製品パスポート（DPP）を本番システムに入れる担当者も想定しています。トレーサビリティにブロックチェーンを使う理由の基礎はトレーサビリティにブロックチェーンを使う理由で解説しています。

この記事でわかること

• リコールの対象製品リストを、根拠と承認者つきの版として残す方法
• チェーンに載せるデータと、社内システムに残すデータの見分け方
• 公表から処置の完了までの管理と、チェーンが止まったときの動き方

最初に決めるのは、対象製品リストの版とその根拠

リコールの対象を「対象か、対象でないか」の印だけで管理すると、困ったことになります。調査の途中で対象を増やしたり外したりした理由が、あとから分からなくなるのです。

そこで、リコールごとに番号を付け、対象の条件と対象製品のリストを版で管理します。対象の条件には、製品コードだけでなく、危険との因果関係を絞り込む軸を入れます。

• ロット、製造期間、工場
• 部品ロット、出荷先
• ソフトウェアの版

承認の記録も欠かせません。消費者庁の事故情報報告・公表制度の事業者向け資料は、製造・輸入事業者がリコールを実施する場合に経済産業省へ報告するよう求めています。進捗状況も定期的に報告します（製品安全4法の対象製品はもれなく報告）。

だから版ごとに、次の4つをまとめて残します。

1. 対象の条件
2. 対象製品のリスト
3. 根拠にしたデータ（抽出したときのスナップショット）
4. 誰が、いつ承認したか

データの形は、後半の「実装する人向けの詳細」にまとめています。

部品ロットC-42から、対象製品をどう割り出すか

C-42の例では、3つのシステムからイベントを集めます。

• MES（製造実行システム）から、組付けのイベント
• WMS（倉庫管理システム）から、出荷のイベント
• 販売・修理システムから、引渡しと部品交換のイベント

抽出は次の順で進めます。

1. 各システムから抽出した時点とデータ形式の版を記録し、入力のスナップショットを固定する。
2. C-42を組み付けた製品を1台ずつ割り出す。すでに交換済みの製品も、処置の状態を付けてリストに残す。
3. 返品、廃棄、再販売、所在不明を区別する。購入者の連絡先は、製品の識別子とは別に管理する。
4. 対象製品を決まった順に並べて要約値（Merkle root）を計算する。件数・条件・承認とともに版を確定する。
5. 販売店や修理事業者は、手元の製品がリストに含まれていることを証明で確かめる。処置の結果は、チェーンの外のシステムへ登録する。
6. 日ごとの集計のスナップショットのハッシュを記録する。対象を広げるときは、旧版を参照する新版を作る。

大事なのは、リストを計算した入力・条件・結果を、同じ版にまとめることです。遅れて届いたイベントで対象が増えても、旧版は上書きしません。差分と理由を持つ新版として承認します。こうしておけば、通知した時点の対象と今の対象を取り違えずに再現できます。

販売店や修理会社に、同じリストだとどう確かめてもらうか

ここで要約値が役に立ちます。個々のシリアル番号を公開チェーンに並べる必要はありません。問い合わせがあったとき、その製品の識別子と、リストに含まれていることの証明（Merkle proof）を渡します。受け取った側は、承認済みのリストにその製品が含まれていることを確かめられます。

ただし、要約値が示すのは「登録したリストと一致している」ことだけです。工場や販売店が入力した内容が事実だったことまでは示しません。

どのデータをチェーンに記録し、どれを社内に残すか

チェーンに記録する候補は、関係各社が一緒に確かめる必要のある要約値・ハッシュ・承認・状態に限ります。購入者の情報や、製品1台ずつの一覧は記録しません。

この見極めは、「改ざんされたくないか」だけでは決まりません。次のことを一緒に考えます。

• 訂正・削除ができるか、どこまで公開されるか
• 検索のしやすさ、更新の頻度、容量
• チェーンが止まったときに業務を続けられるか

Ethereumの公式資料も、保存のしかたによって違いがあると説明しています。ストレージ、calldata、イベント（ログ）、チェーンの外への保存では、誰が参照できるか、チェーン上の処理から使えるか、費用が異なります（ブロックチェーンのデータストレージ戦略）。

データごとに整理すると、次のようになります。

それぞれの理由は次のとおりです。

• 対象リストの版：複数の組織が同じ版を確かめるため。製品1台ずつの一覧は公開しない。
• 製造・入出荷・販売のイベント：検索・訂正・大量の取り込みは、チェーンの外で行う。
• 購入者の情報：個人情報の訂正・削除・利用目的の管理と、公開された台帳は両立しにくい。
• 通知・返送・修理・返金の証憑：本文や画像は公開しない。監査のときに原本と一致するかを確かめる。
• 事案の状態：決められた順番を飛ばす更新を、コントラクトで拒否できる。
• 消費者向けの告知：本文には訂正、アクセシビリティ、多言語への対応が要る。

全イベントをブロックチェーンに写すより先に、することがあります。各社が同じ識別子、時刻、業務の工程、訂正の規則を使えるようにすることです。

その土台になるのがGS1の標準です。Global Traceability Standard公式アーカイブから参照できるバージョン2.0は、製品・場所・主体を識別する考え方を示しています。記録するのは、Critical Tracking Events（追跡上重要なイベント）と、Key Data Elements（各イベントで持つべき主要な項目）です。実装の形式にはEPCIS 2.0.1を使えます。何が、いつ、どこで、なぜ、どのように動いたかを、イベントとして交換できます。

EPCISイベントの設計と訂正（errorDeclaration）の扱いはEPCIS 2.0とブロックチェーンで詳しく扱います。企業間で正本と訂正の責任を決める方法は企業間トレーサビリティのデータガバナンスで扱います。

リコールは、どこまで進んだら「終わり」か

「公表した」で終わりではありません。管理する状態は、処置が終わるまでを表します。C-42のリコールなら、次の順に進みます。

• 検知 → 評価中 → 対象を承認 → 通知中 → 回収中 → 処置中 → 経過観察 → 終了
• 評価の結果、リコールしないと決めた場合は、評価中からそのまま終了へ
• 対象を承認した後で対象が変わった場合は、対象の改訂を経て通知中へ

名前は業務に合わせて変えて構いません。大切なのは、決められた順番でしか進めないことと、主な移り変わりごとに誰が承認するかを決めておくことです。

表の「冪等性キー」は、同じ要求を何度送っても1回分しか処理されないようにする識別子です。各移り変わりに必要な入力は、後半にまとめています。

終了の判断は、制度とも結び付きます。EUの一般製品安全規則は、関係する事業者への安全情報の共有、影響を受ける消費者への通知、是正措置を求めています。そして、当局が進捗の報告や是正措置の完了時点を判断できるとしています（Regulation (EU) 2023/988, Articles 9, 18, 20 and 35–37）。システム上の「終了」は、トランザクションが成立した時点ではありません。業務上・制度上の終了の判断と結び付けます。

チェーンが止まっても、通知と回収を止めないには

ブロックチェーンを使っても、リコールの通知や回収の受付を、チェーンが動いているかどうかに頼ってはいけません。処置はチェーンの外で続け、復旧後に順序と重複を確かめてからチェーンに記録します。

起こりうる障害ごとの動き方は次のとおりです。

• チェーンの停止・混雑：状態の変更は、署名済みの送信待ちの場所（outbox）に保留する。通知・回収は続ける。復旧後は、事案ID・版・冪等性キーで一度だけ反映する。
• ブロックの再編成：トランザクションの送信と確定を、別の状態として管理する。所定のfinality（覆らないと扱う確定の条件）を満たすまで、外部へ完了を知らせない。
• 対象の版がぶつかる：コントラクトは、今の版を前提にした更新だけを受け付ける（楽観的ロック）。古い版からの更新は拒否し、人が差分を確かめ直して新版を承認する。
• 署名鍵の漏えい：緊急停止、役割の失効、鍵の入れ替え（ローテーション）、侵害された時点以降の移り変わりの再確認を、手順にしておく。NISTのSP 800-57 Part 1 Rev. 5が示す鍵のライフサイクル管理を、スマートコントラクトの権限設計にも活かす。
• 元データの誤り：過去の要約値は消さず、訂正の理由と差分を持つ新版を出す。誤った登録を「ブロックチェーンだから正しい」と扱わない。
• チェーンの外の正本がなくなる：要約値だけでは原本を元に戻せない。地理的に離れた場所へのバックアップ、復元の訓練、データ形式と署名の確かめ方の保管が要る。

ブロックチェーンを使うべきか、使わないべきか

チェーンへの記録が役に立つのは、独立した組織どうしで、同じ対象の版と処置の状態を確かめる必要がある場合です。メーカー、輸入者、物流、販売、修理などが関わり、1つの運営者の監査ログだけでは責任の分担が足りない場合がこれに当たります。

逆に、次のような段階では、通常のデータベースとマスターデータの整備を先にします。

• 1社が全システムと参加者を統制していて、改ざんに気づけるログや電子署名で監査の要件を満たせる
• 共通の識別子がなく、販売店からイベントを集められない

判断の基準と構成ごとの比較はEPCIS 2.0とブロックチェーンで詳しく扱います。

PoC（本番前の小さな試験運用）では、処理件数だけでなく、次のことを測ります。

• 対象の抽出を再現する時間、リストに含まれることの証明が成功する率、遅れたイベントを反映する時間
• 重複した処置の率、鍵を失効させるまでの時間
• チェーンが止まっている間の業務の継続、バックアップからの復元

DPPとつなぐ場合は、DPP全体の識別子、データの責任、アクセスの制限を、リコール事案の設計とは別に決めます。DPP側の設計はデジタル製品パスポート（DPP）のデータ設計、制度の基礎はデジタル製品パスポート（DPP）とはで解説しています。

実装の前に確かめる受け入れ条件

• 同じ入力のスナップショットと条件から、同じ対象製品のリストを作り直せる。
• 対象の追加・除外を、旧版、根拠、承認者とともに追える。
• 個人情報や営業秘密が、トランザクション、イベント、URI、ハッシュ化する前の平文に混ざらない。
• チェーンが止まっている間も通知、受付、回収、修理を続け、復旧後に重複なくそろえられる。
• 決められた順番に沿わない移り変わり、古い版からの更新、失効した鍵での更新を拒否できる。
• 権限を持つ監査者が、チェーン上の要約値から、チェーンの外の原本と対象に含まれることを確かめられる。
• 終了の判断が、到達率、処置率、未回収のリスク、必要な当局・責任者の判断と結び付いている。

実装する人向けの詳細

ここからは、さきほどの製造会社で、リコール管理のデータと状態を実際に組む担当者の話です。

対象リストの版のデータ構造

リコール事案はrecall_case_idで識別し、対象の条件と対象識別子のリストを版で管理します。

RecallScopeVersion {
  recall_case_id, version, product_class,
  lot_or_serial_predicate, effective_at,
  source_snapshot_hash, member_set_root,
  approved_by_role, approved_at,
  supersedes_version
}

• source_snapshot_hash：抽出に使った入力データのスナップショット
• member_set_root：対象識別子のリストのMerkle root（多数の値を1つのハッシュへ要約し、個別に含まれることを確かめられる値）

状態の定義と、移り変わりごとの必須入力

DETECTED → ASSESSING → SCOPE_APPROVED → NOTIFYING
          ↘ CLOSED_NO_RECALL
NOTIFYING → COLLECTING → REMEDIATING → MONITORING → CLOSED
SCOPE_APPROVED → SCOPE_REVISED → NOTIFYING

各移り変わりには、実行する役割、必要な承認、入力の版、冪等性キー、時刻を持たせます。処置が終わらないときはMONITORINGを保ちます。システム上のCLOSEDは、業務上・制度上の終了判断へ紐付けます。

XTELAができること

私たちは、MES・WMS・販売システムから入力スナップショットを凍結し、対象集合の版とMerkle rootを承認付きで確定する仕組みを、貴社の既存ERP・WMS・DPPとつないで実装します。チェーン停止中も通知と回収を止めずに後から一度だけ同期できるかを、PoCで障害を起こして確かめます。届出、通知内容、終了判断などの法的な判断は弁護士や製品安全の責任者と連携して進めます。構成の検討はお問い合わせからご相談ください。

参考資料

• 消費者庁「消費生活用製品安全法に基づく製品事故情報報告・公表制度の解説」（2026年9月24日確認）
• GS1 Global Traceability Standard Archive（2026年9月24日確認）
• GS1 EPCIS Standard 2.0.1（2026年9月24日確認）
• Regulation (EU) 2023/988 on general product safety（2026年9月24日確認）
• ethereum.org「ブロックチェーンのデータストレージ戦略」（2026年9月24日確認）
• NIST SP 800-57 Part 1 Rev. 5（2026年9月24日確認）

資料の確認日と注意

法令・標準・公式ガイダンスは2026年9月24日に確認しました。一般的な技術・業務設計の解説であり、法務、規制、製品安全、適合性その他の助言ではありません。届出、通知、保存期間等は法域・製品群で異なるため、対象製品に適用される最新の法令、規格、当局ガイダンスを専門家と確認してください。