企業間トレーサビリティで先に決めるルール｜誤登録の訂正・遅延・離脱への備え

ある原材料メーカーと加工会社、それに最終製品を組み立てるメーカーの3社が、部品の履歴を共有する仕組みを作ろうとしています。原材料のロットが加工され、物流を経て組み立てられ、最終製品になる。その流れを3社が同じデータで追えるようにする計画です。

準備を進めるうちに、組立メーカーの品質責任者が気づきました。原材料メーカーが誤ったロット番号を登録したら、どうなるのか。下流の2社はそれを信じて加工し、出荷してしまいます。いざリコールとなったとき、止めるべき製品を取り違えかねません。

ほかにも心配はあります。データが遅れて届く。同じ出荷が二重に送られる。途中で1社が抜ける。どれも、正しく動いているときの画面を見ているだけでは気づけません。

では、何を先に取り決めればよいのか。製品番号の付け方だけでは足りません。「出荷」が何を指すか。どの会社のどのシステムの値を正しいとするか。間違いを誰がどう直すか。ここまで先に合意しておけば、誤登録や遅れ、途中で抜ける会社が出ても、追跡結果の根拠を説明できます。

以下では、この3社の例を使い、正常な流れだけでなく、誤登録・遅延・重複・訂正・離脱まで順に見ていきます。

トレーサビリティにブロックチェーンを使う理由の基礎はトレーサビリティにブロックチェーンを使う理由、サプライチェーン全体の可視化の考え方はサプライチェーン可視化とはで解説しています。ここでは、複数企業でデータを共有するときに、正本・責任・訂正をどう取り決めるかを扱います。

まず、何を追えれば出荷を止められるかを決める

3社の場合、主な目的はリコールです。リコールで要るのは、対象ロットから、投入した原料と出荷先の両方向を検索できること。そして、疑いのある出荷を一定時間内に止められることです。これが受け入れの条件になります。目的を決めずに「全データを共有する」ことを目指すと、この条件に関係のない各社の負担と機密情報だけが増えます。

目的が変われば、必要な証拠とデータの新しさも変わります。カーボンフットプリントやデジタル製品パスポート（DPP）に対応するなら、さらに項目が増えます。計算の範囲、根拠データ、検証者、それにモデル・ロット・個体のどの粒度で扱うかです。

目的ごとの問いと、合格の目安は次のとおりです。

目的ごとに最低限共有するデータは、後半の「実装する人向けの詳細」にまとめています。リコールで影響範囲を求める手順は製品リコールのデータ設計で詳しく扱います。

目的、合格の目安、止める権限。この3つを合意しないまま共有の仕組みを作っても、本番で事故が起きたときに処理できません。この段階ではまだ技術の方式を選ばず、3つの役割ごとに次のことを決めます。

• 業務責任者：誤りに気づいたとき、誰が何を止めるかを決める
• 各社のデータ責任者：出せるデータの細かさ・新しさ・保存期間を示す
• システム担当者：それを実現する方式を考える

3社のデータを、どうつなげば意味がそろうか

製品・ロット・出荷の記録は、3社がそれぞれ自分のシステムで持っています。企業間トレーサビリティでは、この正本を各社が持ち続けたまま、共通の識別子と、イベントを表す共通の言葉を使って、関係だけをやり取りします。製品のテーブルを1つ作って3社で共同利用する仕組みとは違います。

IPAの「データ連携の仕組みに関するガイドラインの手引き サプライチェーン共通編 1.0版beta」も同じ考え方です。トレース識別子を製品の索引として割り当てます。そして、製品と仕入品の構成関係、事業者間の取引関係を結び付けます（IPA 手引き サプライチェーン共通編）。

GS1 EPCIS 2.0は、「何が、いつ、どこで、なぜ、どのように」起きたかを共通言語で伝えるイベント標準です。企業内でも企業間でも使えます。イベントの設計と、ブロックチェーンとの役割分担はEPCIS 2.0とブロックチェーンで詳しく扱います。

扱うデータは、役割によって4種類に分かれます。

• 業務の正本：事実を確定する元のシステム。製造実績ならMES、在庫・出荷ならERP/WMS、認証状態なら認証機関。
• 共通形式のイベント：各社固有のコードを共通の識別子と言葉に変えたもの。起きた時刻と記録した時刻を別々に送る。
• 証憑：検査票や証明書の原本。アクセスを制限した保存先に置き、イベントからは版とダイジェスト（内容から計算した短い値）で指す。
• 検索用の投影：追跡の図や現在の状態。イベントから作り直せる派生データなので、正本とは呼ばない。

役割が違うので、EPCISを採用する場合も、その項目をそのままデータベースの設計に写さず、この4種類に分けて持ちます。

もう一つ、粒度をそろえます。モデル、ロット、個体、物流の単位を混ぜないことです。分割・混合・組立・再梱包のときは、入ってきたIDと出ていくIDの関係をイベントで残します。

番号のぶつかりにも注意が要ります。会社Aの「ロット001」と会社Bの「001」が衝突しない仕組みが要ります。次の3点をデータ契約に書いておきます。

• 会社ごとに番号がぶつからない名前の付け方（名前空間）
• 統合・分割の後も過去へたどれるリンク
• 識別子を使い回さないこと

データの約束ごとには、誰が責任を持つかまで書く

冒頭の誤登録のような事故で問われるのは、誰が出したデータか、誰がどう直すかです。JSON SchemaやAPI仕様は項目の形を決めるもので、こうした責任までは決めません。そこでデータ契約には、項目の意味と一緒に、責任と品質の約束も書きます。たとえば次のものです。

• 誰が出すか（提供主体と正本）
• どのくらい遅れてよいか（更新頻度と許容遅延）
• 間違えたら誰がどう直すか（訂正方法と、品質違反時の連絡先）

このほか、単位、必須条件、利用目的、保持期間も書きます。スキーマは版を管理し、古い版を使える期間と移行期限を決めておきます。

1つの中央運営者がイベントの中身の真偽まで保証しようとすると、現場を持たない会社に責任が集中してしまいます。そこで、責任の分け方は次を基本にします。事実の正しさは、その事実を起こした会社が負います。

連携の仕組みが確かめるのは、送り手の本人性、権限、形式、重複までです。第三者の認証が要る主張は、認証機関が署名した証明と、その有効状態を別に確かめます。処理ごとの分担は次のとおりです。

処理ごとに残す記録（検証証跡）は、後半にまとめています。

間違いが見つかったら、どう直すか

冒頭の例で、原材料メーカーのロット番号の誤りが見つかったとします。誤ったイベントを消してしまうと、すでにそれを見た加工会社や組立メーカーの手元の値と食い違います。かといって、誤りをずっと有効のまま残す必要もありません。

そこで、イベントは消さずに追記していきます。受け取った、確定した、異議が出た、訂正された、という状態の移り変わりとして管理します。元のイベントと訂正のイベントは関連付けておきます。

異議が出ている間の扱いも問題になります。調べている間は、その情報を使った出荷を保留するのか、警告を出すだけにするのか。これは用途ごとに決めておきます。状態の一覧と、各イベントに持たせる項目は後半にまとめています。

どの会社に、どこまで見せるか

「参加企業なら全件見られる」にすると、見せなくてよい情報まで出てしまいます。取引価格、配合、サブサプライヤー（取引先のさらに先の仕入先）、個人情報などです。

NIST SP 800-207は、ゼロトラストの考え方を示しています。ネットワーク上の場所や資産の持ち主だけで信頼しない。主体と資源ごとに認証・認可する、という考え方です。

企業間の連携では、見せるかどうかを会社単位では判断しません。データの中身、目的、時点を組み合わせて判断します。具体的には次の項目です。

• 誰か：事業者ID、担当者またはサービスID、役割
• 何を：対象製品、データの機密区分
• どんな関係で：取引関係、利用目的、契約期間

運用では、次の点に気をつけます。

• データを5段階に分類する。公開情報、直接の取引先だけ、サプライチェーンの関係者だけ、当局・監査だけ、提供企業の中だけ。
• 見せるかどうかの判断と、データの配信は別の仕組みにする。拒否・許可・一部を隠す判定の理由と、ポリシーの版を監査ログに残す。
• ダウンロードされた後の使い道は、技術だけでは完全に縛れない。契約、監査、透かし、集計や秘匿化を組み合わせる。
• 権限を変えたら、これからのアクセスだけでなく、発行済みのAPIトークン、キャッシュ、エクスポート、分析環境への影響も片付ける。

取引先ごとに見せる項目を絞る暗号化や、失効の方式は機密サプライチェーンデータの共有設計で扱います。

EUのESPR（Regulation (EU) 2024/1781）も、DPPについて同じ方向を示しています。データを見られる主体、作成・更新できる主体、モデル・ロット・個体の粒度を製品群ごとに定めます。そのうえで、役割別のアクセス権と相互運用性を求めています。詳しい要件は製品群ごとの委任法令で決まります。それでも、アクセス権を後付けにしない点は、一般のトレーサビリティ設計にも当てはまります。

相手のシステムが止まったら、どうするか

複数の会社がつながると、止まるのは珍しいことではありません。相手システムの停止、処理待ちの滞留、署名鍵の失効、スキーマの不一致、ネットワークの分断。どれも、最初から起きるものとして考えておきます。

3社の例で、原材料メーカーからの送信が止まったとします。このとき、リスクの高い出荷は保留し、低いものは期限付きで続ける、という分け方ができます。このように、止まったときに処理を続けるか（fail-open）、止めるか（fail-closed）は、全部を一律にせず、データの用途ごとに決めます。障害ごとの対応は後半の表にまとめています。

監視では、業務日ごとに届くはずの件数と実際の件数、遅れの分布、訂正が終わらない時間などを測ります。APIが正常に応答したか（HTTP 200）を見るだけでは、これらは分からないからです。

ブロックチェーンは要るか

ブロックチェーンを使っても、入力された中身が正しいかは分かりません。共有すべきデータの定義も、自動では決まりません。

候補になるのは、独立した複数の会社が同じ確定履歴を確かめる必要があり、しかも1社が運営する通常のデータベースと署名付きの監査ログでは合意できない場合だけです。その場合も、チェーン上に載せるのは次のものに絞ります。

• 機密でない参照とハッシュ
• 署名者とスキーマの版
• 状態が確定したこと

先に合意しておくべきなのは、誰が担うかです。ノードの運営、鍵の管理、スマートコントラクトの変更、そして障害時に最終判断を下す人です。採否の判断基準と構成ごとの比較はEPCIS 2.0とブロックチェーンで扱います。製品情報の識別子とアクセスの観点はデジタル製品パスポート（DPP）のデータ設計で詳しく扱います。

最初のPoCでは、3社・1製品群・5つの異常を試す

PoC（本番前の小さな試験運用）の目的は、画面を見せることではありません。責任の分担が回るか、壊れても元に戻せるかを確かめることです。冒頭の3社のように、原材料・加工・最終製品の3社と1製品群に絞ります。受領・変換・出荷の正常なイベントに加えて、次の5つの異常を起こします。

1. 同じ出荷イベントを再送し、二重に数えられないことを確かめる。
2. 原材料の受領が加工イベントより遅れて届いても、あとから正しくつながることを確かめる。
3. 数量またはロットの対応を訂正し、古い情報を使った全社に反映されることを確かめる。
4. 提供企業のAPIを止め、用途別の保留・期限付き継続と、復旧後の差分の再送を確かめる。
5. 参加企業の資格か署名鍵を失効させ、新しい登録を拒み、過去のデータは引き続き確かめられることを確認する。

合格の目安には、次の数字を使います。

• 前方・後方へたどる所要時間、欠損に気づくまでの時間、訂正完了までの時間
• 誤検知率
• 各社の入力工数、問い合わせ件数

技術的に追跡できても、本番に使えない場合があります。入力の負担が大きく現場が抜け道を使う。訂正の責任者がいない。利用企業が「異議あり」の状態を無視する。こうした場合です。

実装する人向けの詳細

ここからは、3社の連携の仕組みを実際に作る担当者向けに、データの項目・状態・障害時の制御をまとめます。

目的ごとに最低限共有するデータ

処理ごとに残す検証証跡

• 事業者・拠点登録：法人確認、拠点ID、承認者、有効期間
• イベント生成：元伝票、送信者、イベントID、スキーマ版
• 受領・形式検証：署名、時刻、必須項目、拒否理由
• 内容の異議申立て：対象イベント、根拠、回答期限
• 訂正・取消：旧版との関係、理由、承認、通知先
• ルール・スキーマ変更：変更提案、影響評価、採決、適用日時

イベントの状態

イベントは5つの状態を持ちます。異議が出ている間の扱いが、用途ごとに変わる点に注意します。

イベントに持たせる項目と重複の扱い

すべてのイベントに、次の項目を持たせます。

• 一意なevent_id、作成企業、対象ID、イベント種別
• 発生時刻、記録時刻、スキーマ版、前提イベント
• 署名、または認証済みの送信者

同じevent_idの再送には同じ結果を返す、冪等処理（何度実行しても結果が同じになる処理）にします。同じ業務事実が別IDで二重に送られた場合に備え、それを見つける相関キーも用意します。時計のずれやオフライン入力が起こり得るので、発生時刻だけで順序を確定しません。

障害時の制御

障害は、検知の方法と、すぐ取る制御、復旧の条件をセットで決めておきます。

監視と再処理

監視では、次の値を測ります。

• 業務日ごとの期待イベント数、遅延の分布、隔離件数、訂正未完了の時間
• 追跡グラフの孤立ID、署名検証の失敗
• 権限拒否の急増

復旧後は、たまったキューを機械的に全部再送しません。対象期間とイベントIDを突き合わせ、反映されていないと確かめたものだけを再処理します。

XTELAができること

私たちは、参加企業ごとの正本を残したまま、データ契約、責任分担表、DISPUTEDを含む訂正の状態遷移を実装仕様に落とし、イベントの受領・検証・訂正通知を担う連携基盤を作ります。3社・1製品群のPoCで再送、到着順の逆転、訂正、API停止、鍵失効を実際に起こし、訂正完了までの時間や各社の入力工数を貴社と一緒に測ります。契約・競争法・個人情報などの法的な判断は弁護士と連携して進めます。技術構成の検討はお問い合わせからご相談ください。

主要参考資料

• IPA データ連携の仕組みに関するガイドラインの手引き サプライチェーン共通編 1.0版beta（2025年12月、2026年9月24日確認）
• IPA サプライチェーン強靭化におけるデータ連携の仕組みに関するガイドライン（車載半導体関連）0.1版（2026年6月16日公開、2026年9月24日確認）
• GS1 EPCIS Standard Release 2.0.1（2026年9月24日確認）
• Regulation (EU) 2024/1781（ESPR）, Articles 9–11（2026年9月24日確認）
• NIST SP 800-207: Zero Trust Architecture
• International Data Spaces: Usage Control（2026年8月13日確認）

資料の確認日と注意

制度や標準の記述は、2026年9月24日に一次資料で確認しました。一般的な技術・運用設計の解説であり、法務、規制、契約、個人情報保護その他の助言ではありません。標準・制度は更新されるため、実装時点の一次資料と専門家の判断を確認してください。