EPCIS 2.0とブロックチェーンの違い｜両方要るかを6つの質問で判断

製造・物流・小売の会社をまたいで、商品の動きを追えるようにしたい。そう考えたとき、最初に何から決めるかには、2つのやり方があります。

一つは、ブロックチェーンの製品から選ぶやり方です。ただ、台帳を先に決めても、「出荷」が何を指すかが会社ごとに違ったままなら、各社の記録の意味はそろいません。

もう一つは、まずイベントの意味をそろえるやり方です。そのための共通の決まりがEPCIS 2.0です。「出荷」「入荷」といった出来事を、会社どうしで同じ意味で伝えるための国際標準です。

EPCISは出来事の意味をそろえる決まり。ブロックチェーンは、記録が書き換えられていないことを複数の会社で確かめる道具です。役割が違うので、EPCIS 2.0とブロックチェーンは、どちらかを選ぶものではありません。別々に考えます。

では、ブロックチェーンは本当に要るのか。それを決める手がかりは、方式の名前ではありません。データの正本（正しいとする元データ）はどこか。誰が責任を持つか。間違いをどう直すか。誰に何を見せるか。止まったときにどう続けるか。この順に考えると、採用する範囲が見えてきます。最後に、採用を決める6つの質問にまとめています。

トレーサビリティにブロックチェーンを使う理由と仕組みの基礎はトレーサビリティにブロックチェーンを使う理由、サプライチェーン全体での活用領域はサプライチェーンにブロックチェーンが必要な理由で解説しています。ここでは、その先の実装設計として、ブロックチェーンを採用するかどうかの判断を詳しく扱います。

EPCISとブロックチェーンは、それぞれ何を引き受けるか

GS1 EPCIS 2.0.1は、企業の内外のアプリケーションが、モノの動きを表すイベントを作って共有するための仕組みです。データの形と、やり取りの窓口（インターフェース）を定めています。

EPCISのイベントは、対象・時刻・場所・業務上の意味を結び付けます。一方、サービスやデータベースの中身の作り方は定めていません。REST API、JSON/JSON-LD、センサーデータ、認証情報への参照を扱えます。そのため、既存のERP（統合基幹業務システム）、WMS（倉庫管理システム）、IoT基盤の上に、会社どうしをつなぐ層として載せられます。

ブロックチェーンは、参加者が検証のルールと記録の順番に合意し、複数のノードが同じ台帳を持つ仕組みです。NISTは、ブロックチェーンを「変更できない」とは言い切っていません。改ざんを見つけやすく、改ざんに強い台帳だと説明しています（NISTIR 8202）。

役割の違いは次のとおりです。

どちらも引き受けないものもあります。これは別に用意します。

• 意味：自社・業界に固有の業務ルール
• 交換：認証、認可、接続先の探索、再送の制御
• 保存：検索用DB、原本、画像、証明書、個人情報
• 信頼：現物、入力した人、測定器、組織の権限が正しいかの確認

つまり、現物が正しいかどうかは、EPCISもブロックチェーンも保証しません。

最初に、各社のイベントの意味と正本をそろえる

冒頭で見たとおり、最初にそろえるのは、台帳の製品ではなくイベントの意味です。EPCIS and CBV Implementation Guidelineは、イベントを5つの観点で表します。What（何を）、When（いつ）、Where（どこで）、Why（どの業務工程・状態で）、How（どのような条件で）です。

Core Business Vocabulary（CBV）2.0は、業務の言葉をそろえるための標準語彙です。これを使えば、たとえばshipping（出荷）やreceiving（入荷）を、会社ごとの独自コードから切り離せます。

一方で、業務データの正本は、すでに各システムにあります。注文数量はERP、梱包と在庫はWMS、測定の原本はIoT・品質基盤です。これらは正本のまま残し、EPCISに出すのは、会社をまたいで追跡するのに必要なイベントと参照だけにします。EPCISの保存先を、すべての業務データの正本にはしません。複数企業のあいだで正本・責任者・訂正の権限をどう決めて合意するかは企業間トレーサビリティのデータガバナンスで詳しく扱います。

出荷から受領までなら、場面ごとに正本と受け入れる条件を次のように決めます。

それぞれに対応するEPCISのイベント型は、後半の「実装する人向けの詳細」にまとめています。

イベントを受け取ったことと、中身を業務上受け入れたことも別に扱います。形式のチェックに通っても、送り手がその拠点の出荷権限を持つとは限らないからです。

ブロックチェーンには何を載せるか

ブロックチェーンを検討するのは、独立した複数の組織が同じ記録を確かめる必要があり、1社が運営する監査ログでは合意できない場合です。

参加する会社が決まっていて、中立の運営者と契約できるなら、ブロックチェーンがなくても、次のもので要件を満たせます。

• 署名済みのEPCISイベント
• 追記しかできないログ
• WORM（Write Once Read Many：追記後の変更を制限する）ストレージ

台帳を使う場合も、載せるのはイベントの本文ではありません。共同で確かめる最低限の記録だけです。イベントのハッシュ、イベントID、発行者、スキーマの版、記録時刻、失効・訂正先などです。

Hyperledger FabricのPrivate Data Collectionsも同じ形です。限られた参加者だけが元データを持ち、全参加者の台帳にはハッシュを残します。

ただし、ハッシュで分かるのは、その内容が存在したことまでです。入力された内容が現物と一致することまでは保証しません。記録する項目の例は後半に載せています。

間違ったイベントは、どう直すか

現場では、誤スキャン、二重送信、通信の遅れ、ロットの誤った紐付けが起きます。EPCIS 2.0.1には、過去のイベントの主張が誤りだったと示す「誤り宣言」（errorDeclaration）があります。

元のイベントは消しません。消すと履歴が途切れるからです。誤りの宣言と訂正版を関連付けて残します。イベントIDは、どの実装から見ても一意になるように作ります。同じイベントが再送されたら、何度届いても結果が同じになるように処理します（冪等処理）。

ブロックチェーン上のハッシュも、消そうとはしません。訂正イベントのハッシュと、元のイベントへの参照を追加します。検索画面には、いま有効な状態を返します。監査画面では、元のイベント、訂正理由、承認者、再計算の結果までたどれるようにします。

取引情報の漏れと、止まったときの備えをどうするか

全参加者へ同じ台帳を複製すると、取引情報が漏れるおそれがあります。取引数量、仕入先、拠点、時刻の組み合わせから、営業情報を推し量れる場合があるからです。

チャネル（参加者を限った台帳）やプライベートデータコレクションを使っても、残る責任があります。参加者の追加、組織の退出、鍵の失効、バックアップ、ログ閲覧です。

次のものは、権限を管理したストレージに置き、EPCISのイベントから参照します。

• 個人情報、営業秘密
• 証明書の原本、画像
• 連続したセンサーデータ

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

止まりにくさ（可用性）にも注意が要ります。台帳のノードが複数あっても、EPCIS Capture API、認証基盤、ネットワークの合意処理、検索インデックスのどこかは止まります。ですから、「ノードが複数あるから止まりにくい」とは限りません。

出荷を止めないためには、現場のゲートウェイに署名付きイベントを一時保存します。復旧後に、同じイベントIDで再送します。Query APIが止まっても受領の判断を続けられるよう、キャッシュの範囲と、古い状態を使ってよい時間を業務ごとに決めておきます。

どの構成を選べばよいか

ここでは4つの構成を、合う条件と合わない条件で比べます。

構成ごとに誰が何の責任を負うかは、後半にまとめています。

PoCでは、再送・訂正・離脱を先に試す

PoC（概念実証）は、1つの製品群、3組織、梱包・出荷・受領など少ないイベントから始めます。正常な流れの画面だけでは、方式の差は出ません。わざと次のような障害を起こします。

• イベントの順序の逆転、同一イベントの100回再送
• 誤った親子関係の訂正、署名鍵の失効、参加組織の離脱
• EPCIS Queryの停止、台帳ノードの停止

確かめるのは次の5点です。

1. 相互運用: 3社の実装が同じEPCISイベントを同じ意味で取り込み、CBV語彙と独自拡張を区別できる。
2. 整合性: 再送で重複せず、遅れて届いたイベントや訂正の後も、現在の状態を組み立て直せる。
3. 責任の分担: 発行者、承認者、データの正本、障害復旧の担当が、イベントの種類ごとに決まっている。
4. 機密性: 権限のない参加者、ノード管理者、ログ基盤から取引内容を推し量れない。
5. 撤退できるか: 台帳を止めてもEPCISデータと署名を出力し、別の基盤で検証を続けられる。

測るのはブロック数ではありません。次の数字です。

• 取引先の接続にかかる日数、受入エラー率、欠損イベント率
• 訂正完了までの時間、リコール対象を特定する時間
• 1イベント当たりの総運用費

ブロックチェーンなしの構成も同じテストにかけます。共同で合意できることの価値が、運用の負担を上回るかを比べるためです。

リコール対象を特定する時間を指標にする場合、対象の集め方は製品リコールのデータ設計で扱います。製品単位の情報を長く公開する場合の識別子とアクセスの設計はデジタル製品パスポート（DPP）のデータ設計で扱います。

採用は6つの質問で判断する

1. 共有する業務イベントをEPCISとCBVで表せるか。独自拡張の持ち主と版の管理は決まっているか。
2. 各イベントの原本、発行者、承認条件、保持期間、訂正方法は決まっているか。
3. 複数の組織が、1社の運営者を信頼できない具体的な場面があるか。
4. 電子署名、追記専用ログ、第三者時刻証明では足りない理由を説明できるか。
5. 台帳に載せる情報を、ハッシュなど機密でない最低限の記録に限れるか。
6. ノード停止、鍵の喪失、誤登録、組織の退出、方式の移行を共同で運用できるか。

1と2が決まっていないなら、EPCISのイベント設計へ戻ります。3と4に具体的な不足がなければ、集中管理DBと署名で始めます。5と6を満たせない場合も、ブロックチェーンは採用しません。

先にEPCISで会社どうしのつなぎ目を固めておけば、必要になった記録だけを後から台帳につなげられます。

実装する人向けの詳細

ここからは、EPCISの取り込みと台帳への記録を実際に作る担当者向けの内容です。

場面ごとのEPCISイベント型

JSON-LDの構文検証に通っても、送信者に対象拠点の出荷権限があるとは限りません。スキーマ、識別子、発行主体、業務ルールの順に検証し、結果を監査できる形で保存します。

台帳に記録する項目の例

{
  "eventID": "urn:uuid:3f3f4e86-...",
  "eventHash": "sha256:9d78...",
  "issuer": "did:web:manufacturer.example",
  "schema": "epcis-2.0.1+profile-1.3",
  "recordedAt": "2026-08-13T04:20:00Z",
  "supersedes": null
}

同じJSONでも、空白、キーの順番、数値の書き方、JSON-LDコンテキストの扱いが違うとハッシュは変わります。そこで、ハッシュの方式に加えて、正規化（同じ内容なら同じハッシュになるよう書式をそろえること）の手順と版を固定します。検証用のテストベクトル（入力と期待する出力の組）を参加組織へ配ります。

受信から訂正までの状態

構成ごとの主な責任

• EPCIS＋集中管理DB：運営者が可用性、証跡、アクセス制御を担う
• EPCIS＋署名＋第三者時刻証明：鍵管理、失効、長期検証を担う
• EPCIS＋許可型ブロックチェーン：参加資格、合意規則、ノード、更新を共同管理
• EPCIS＋公開チェーンへのハッシュ記録：手数料、確定待ち、鍵、チェーン移行を管理

XTELAができること

私たちは、既存のERP・WMS・IoT基盤を正本として残したまま、その上にEPCISイベントの取り込み・検証・訂正の層を実装します。3組織規模のPoCで再送、訂正、鍵失効、参加組織の離脱を実際に起こし、ブロックチェーンありとなしの構成を同じ指標で比べて、台帳を使う範囲を貴社と一緒に決めます。構成の検討はお問い合わせからご相談ください。

主要参考資料

• GS1 EPCIS Standard 2.0.1（2026年9月24日確認）
• GS1 Core Business Vocabulary Standard 2.0（2026年9月24日確認）
• GS1 EPCIS and CBV Implementation Guideline 2.0（2026年9月24日確認）
• GS1 Japan EPCIS技術講座 EPCIS 2.x編（2026年9月24日確認）
• NISTIR 8202: Blockchain Technology Overview（2026年9月24日確認）
• Hyperledger Fabric: Private data（2026年9月24日確認）

資料の確認日

EPCIS・CBVとブロックチェーン関連の仕様・資料は、2026年9月24日に確認しました。