チェーントレーサビリティは、自社工場内の履歴を検索できるだけでは完成しません。仕入先、製造拠点、物流会社、顧客が持つイベントを、同じ識別子・語彙・時刻規則・訂正規則で交換し、受信側が追跡結果を再現できて初めて機能します。本稿ではGS1 EPCIS 2.0を軸に、取引先オンボーディング、RFP、PoC、FAT/SAT、24時間演習までを実務の受入条件へ落とします。
結論：チェーントレーサビリティは「イベント交換の再現性」で発注する
最初に結論です。チェーントレーサビリティのRFPに「一元管理データベースを構築する」「ロットを検索できる」とだけ書いてはいけません。発注すべき成果は、企業をまたいで発生した出来事を、相手が機械的に受信し、構文と業務意味を検証し、トレースバックとトレースフォワードを同じ結果で再実行できることです。
中央DBを採るか、各社がデータを保持して必要時に照会するか、イベントブローカーを介すかは構成選択です。どの構成でも、次の六つが企業間で一致しなければ検索結果はつながりません。
| 問い | 企業間で合意する内容 | EPCISでの検討対象 |
|---|---|---|
| who | 誰が記録・保有・出荷・受領したか | source、destination、business transaction、party識別 |
| what | どの品目、ロット、シリアル、物流単位か | EPC、quantity、parent/child、入力・出力 |
| when | いつ現場で起き、いつ記録されたか | eventTime、timeZoneOffset、recordTime |
| where | どの事業所、工程、読取点か | readPoint、bizLocation、GLN等の場所識別 |
| why | 何の業務段階で、どの状態になったか | bizStep、disposition、action、CBV語彙 |
| how | どの方法・センサー・版で確かめたか | sensorElement、拡張項目、証跡参照、IF版 |
GS1 Global Traceability Standard 2.0が示す基本次元はwho、what、where、when、whyです。本稿のhowは、読み取り方法、センサー、手順、インターフェース版、証跡を区別する実装上の追加観点です。GS1の六番目の標準次元だと誤解してはいけません。
もう一つ重要なのは、受信できることと再現できることを分けることです。HTTP 200が返りJSON Schemaを通っても、出荷ロットと受領ロットの識別粒度が違う、時刻のタイムゾーンが欠ける、shippingの意味が会社ごとに違う、訂正が上書きで消えるなら、出荷先追跡は成立しません。RFPでは「送信成功率」だけでなく、相手のデータから対象範囲を再計算した結果、期待集合、差分理由、処理時間、証跡を受け入れます。
内部トレーサビリティとチェーントレーサビリティの境界
内部トレーサビリティは、一つの組織や管理境界の中で、入荷、保管、払出、投入、変換、検査、梱包、出荷を結ぶ仕組みです。チェーントレーサビリティは、その境界を越え、取引先どうしの「発送」と「受領」、「投入」と「生産」、「親物流単位」と「子物流単位」をつなぎます。
自社内では、品目コードA-100、場所WH1、状態OKの意味を担当者が補えます。しかし取引先には通じません。先方のA100-R2と同じ品目か、WH1が工場か倉庫か、OKが検査合格か出荷可かは、識別子とマスターの対応、語彙の定義、版の適用日がなければ判断できません。社内画面をそのまま外へ見せても、チェーンはつながらないのです。
GS1 Global Traceability Standard 2.0は、各組織が自らのトレーサビリティデータを管理し、エンドツーエンドでは複数組織のデータへのアクセスと結合が必要になると説明しています。また、対象物、関係者、場所を一意に識別し、データを捕捉・共有する相互運用の考え方を示しています。これは「全データを一か所へ集める」要求ではありません。データの所在が分散していても、問いに対して必要なイベントを発見し、権限を確認し、時間内に結合できればよいという設計が可能です。
内部の完成を待ってから外部へ広げるべきか
内部が無秩序なまま外部連携を始めるのは危険ですが、「社内を100%完成してから取引先へ」という順番も失敗しやすいものです。自社だけで決めたロット粒度や理由コードが取引先の発送単位と合わず、後から全面改修になるためです。
実務では、優先する一つの製品群と一つのサプライチェーンを選び、社内イベントと企業間イベントを同時に設計します。たとえば、仕入先の発送、自社の受領、製造投入、変換、梱包、出荷、物流会社への引渡し、顧客受領までです。最初から全SKU・全取引先を対象にせず、トレースバックとトレースフォワードの両方向が閉じる最小範囲を選びます。
社内の変更履歴を整えるには、4M変更管理システムの設計も参考になります。古い設備からイベントを取る方法は、老朽設備のIoTレトロフィットで、信号の意味、時刻、欠測をどう扱うかを確認してください。
GS1 EPCIS 2.0で企業間イベントを表す
EPCISは、サプライチェーン上の可視化イベントを表現し、捕捉し、照会するためのGS1標準です。EPCIS 2.0はXMLに加えてJSON/JSON-LDを支援し、RESTfulなcapture/query binding、センサー観測の関連付け、認証・認可を考慮したインターフェースを備えます。GS1が公開するEPCIS 2.0.1仕様と機械可読artefactには、OpenAPI、JSON Schema、SHACL、JSON-LD context、ontologyなどがあります。
これらはRFPとテストに使えます。ベンダー独自PDFを人が読むだけでなく、提供されたpayloadを公式JSON Schemaで検証し、APIのoperationとmedia typeをOpenAPIに照合できます。ただし、スキーマに合うことは業務意味が正しいことの証明ではありません。bizStepがshippingでも、物理的に出荷した時点なのか、出荷予定を確定した時点なのかを取引先が異なって解釈すれば、イベントはつながりません。
Object、Aggregation、Transformation、Transactionを使い分ける
企業間PoCでは、まず次のイベント型と用途を整理します。製品や工程により使わない型があっても構いません。大切なのは「すべてをObjectEventへ押し込む」ことを避け、親子、投入出力、取引との対応を明示することです。
| イベントの考え方 | 実務例 | 受入で確かめる関係 |
|---|---|---|
| ObjectEvent | ロットを出荷、物流単位を受領、状態を観測 | 対象、action、bizStep、場所、時刻 |
| AggregationEvent | ケースをパレットへ積付け、パレットから荷下ろし | parentとchild、ADD/DELETE、親の一意性 |
| TransformationEvent | 原材料ロットを投入して完成品ロットを生成 | inputとoutput、変換ID、数量・単位 |
| TransactionEvent | 対象物をPO、出荷指示、納品に関連付け | EPCとbusiness transactionの対応 |
| AssociationEvent | 対象を場所・設備などへ一時的／継続的に関連付け | parent、child、関連の開始・終了条件 |
たとえばパレットSSCCを受け取った顧客が、その配下のケースを照会できないなら、出荷先追跡の粒度が途切れます。製造ロットを追跡しても原材料投入とのTransformation関係がなければ、トレースバックで仕入先ロットへ到達できません。逆に、すべてをシリアル単位にすることも正解ではありません。GS1 GTS 2.0はclass、batch/lot、instanceという識別粒度を説明し、目的とリスク、コスト、取引先調整に応じて選ぶ考え方を示しています。
CBVは「コード一覧」ではなく共同の意味契約
Core Business Vocabulary（CBV）は、business step、dispositionなどの値をそろえるための語彙です。取引先オンボーディングでは、標準語彙を採用する項目、業界語彙や自社拡張が必要な項目、相手コードからのmapping、未知値を受けた場合の処理を決めます。
表示ラベルは日本語、タイ語、英語、ベトナム語に翻訳しても、送信コードは言語非依存にします。「出荷済」「จัดส่งแล้ว」「shipped」という画面表示が、同じcanonical valueへ対応する設計です。翻訳文を比較して意味を推測させるのではなく、コードと定義、発効日、廃止日、後継コードを共有します。
企業間EPCISイベント交換の最小アーキテクチャ
図の流れは、仕入先、製造会社、物流会社、顧客が、自社のイベントを保持しながら、許可された相手へ必要なイベントを交換する例です。中央DBを描いていないのは、中央化を否定するためではなく、トレーサビリティの成立条件が中央DBの有無ではないことを明確にするためです。
仕入先は発送する対象と物流単位、時刻、場所、取引を記録します。製造会社は受領イベントで同じ対象または対応する物流単位を参照し、受領差異を例外として残します。製造時には投入と出力を結び、完成品の梱包でケースとパレットを集約します。物流会社は引渡し、輸送、到着を記録し、顧客は受領を記録します。
トレースバックでは、疑義のある完成品ロットから製造変換、投入原材料、仕入先発送まで遡ります。トレースフォワードでは、原材料ロットから生成された完成品、パレット、出荷、顧客受領へ進みます。単に「前の会社」「次の会社」を一社ずつ示すだけでは不十分です。分割、統合、再梱包、返品、再出荷、外注加工があれば、関係は枝分かれします。
同じ識別子を交換する
GTIN、GLN、SSCCなどのGS1識別子は有力な選択肢です。GS1 Thailandのトレーサビリティ解説も、GTIN、GLN、SSCCによる識別、barcode/RFIDによるcapture、EPCIS/Digital Linkによるsharingを紹介しています。しかし「GS1コード欄がある」だけでは足りません。
RFPでは、チェックディジットを含む正規形、URI表現、先頭ゼロ、包装階層、再利用可否、supplier-assigned IDとのmapping、ラベル再発行、旧IDから新IDへの置換を定義します。PoCでは、Excelからコピーしたとき先頭ゼロが消える、SSCCを数値型で保持して桁が変わる、GTIN-13とGTIN-14の比較で誤る、といった現実的な不具合を入れます。
同じ時刻規則を交換する
eventTimeは現場で出来事が起きた時刻です。recordTimeやAPI受信時刻は、リポジトリへ記録された時刻であり、同じではありません。ネットワーク断の後にまとめて送信すれば差が開きます。イベント時刻にはタイムゾーンオフセットを含め、拠点の標準時、設備時計の同期元、許容clock skew、オフライン端末の補正、時刻不明時の扱いを合意します。
「受信順に並べる」実装では、遅延送信や再送で履歴が逆転します。検索と演習ではeventTimeとrecordTimeの両方を保ち、順序が矛盾するイベントを隔離して確認します。将来時刻、極端に古い時刻、offset欠落を単純に受理しないvalidationも必要です。
訂正を上書きで消さない
誤スキャンや誤ったロット関連は必ず起こります。企業間交換後に元レコードを静かに更新すると、送信側と受信側の履歴が分岐します。訂正は、元event IDを参照するerror declarationや、取消・逆転・再記録のルールで残します。誰が、いつ、なぜ、何を訂正し、相手がいつ受信したかを監査できることが必要です。
同じevent IDで内容の違うpayloadが届いた場合は、後勝ちで上書きせず競合として隔離します。同じ内容の再送は冪等に受理し、重複を増やしません。元イベントと訂正イベントの双方を含めて再生したとき、各社が同じ有効状態へ収束することをFATで確認します。
取引先オンボーディングは六つの検証ゲートで管理する
EPCIS repositoryを設置しても、取引先が接続できなければチェーンは完成しません。オンボーディングを「APIキーを発行してテスト送信」に縮めず、六つのゲートで管理します。各ゲートには入口条件、提出物、機械検査、業務確認、合格者、再試験条件を置きます。
Gate 1：識別子mapping
対象品目、ロット、シリアル、物流単位、場所、企業、取引を一覧にし、双方の識別体系を対応付けます。mapping不能なIDを無理に自由記述へ入れず、識別子発行責任と存続期間を決めます。テストデータには先頭ゼロ、最大桁、異なる包装階層、同じロット名を使う別品目、返却容器を含めます。
Gate 2：語彙と業務シナリオ
shipping、receiving、commissioning、packing、loadingなどのbusiness stepと、状態を示すdispositionを業務フローへ配置します。相手の独自コードはmapping表でcanonical valueへ変換し、変換不能ならrejectかquarantineかを決めます。語彙表には説明、例、非該当例、owner、version、effective dateを含めます。
Gate 3：時刻・順序・訂正規則
タイムゾーン、時刻精度、clock sync、遅延許容、未来時刻の拒否、recordTimeの付与主体を決めます。さらに、重複、順序逆転、取消、誤り訂正、遡及登録を試します。「エラーが起きないこと」ではなく、エラーが検出され、元イベントを失わず、再処理後に同じ結果へ収束することを合格条件にします。
Gate 4：構文・インターフェース検証
content type、JSON/JSON-LD、必須項目、列挙値、URI、数値単位、OpenAPI operation、pagination、query条件を機械検査します。認証、認可、certificateやtokenの更新、秘密情報の保管、rate limit、timeout、再送、監査ログもここで確認します。GS1のartefactは基準にできますが、製品固有拡張のschemaとnamespaceも版管理が必要です。
Gate 5：シナリオ試験
正常な一方向出荷だけでなく、部分出荷、過不足受領、パレット組替え、ロット分割、製造変換、外注加工、返品、再出荷、誤イベント訂正を端から端まで再生します。期待するtrace setを事前に固定し、実際のトレースバック／トレースフォワード結果と自動比較します。
Gate 6：本番移行と継続監視
合格したschema、語彙、mapping、certificate、endpointの版をbaseline化します。本番ではイベント件数だけでなく、拒否率、quarantine滞留、未知コード、時刻外れ、相手別遅延、訂正未受領、trace completenessを監視します。変更は予告、互換期間、sandbox再試験を経て導入します。
取引先を規模だけで一律評価してはいけません。EPCISを直接実装できない小規模取引先には、portal入力、CSV変換、managed gatewayなどを用意できます。ただし入口が違っても、最終的に同じ識別子・語彙・時刻・訂正規則でイベント化し、同じvalidationを通すことが重要です。
RFPに書くべき成果物と責任分界
チェーントレーサビリティの提案比較が難しい理由は、製品ライセンス、連携開発、データ整備、取引先支援、試験、運用が混ざるからです。RFPでは製品機能一覧より先に、誰が何を納品し、どの証跡で受け入れるかを書きます。
| RFP成果物 | 最低限含める内容 | 受入証跡 |
|---|---|---|
| Event catalogue | event型、trigger、owner、必須項目、例外 | 承認済み定義とpayload例 |
| Identifier policy | GTIN/GLN/SSCC/lot/serial、正規化、mapping | 境界値テスト、重複・桁検査 |
| Vocabulary profile | CBV採用値、拡張、定義、版、廃止 | machine-readable code list |
| Time policy | eventTime、offset、recordTime、clock skew | 遅延・逆転・future event試験 |
| Correction policy | event ID、error link、取消、再送 | 原本と訂正のreplay結果 |
| Security profile | 認証、認可、partner isolation、key rotation | 権限positive/negative test |
| Partner kit | sandbox、sample、schema、手順、support | 新規partnerの完了記録 |
| Trace service | trace-back/forward query、export、監査 | 期待集合との自動比較 |
| Operations runbook | 監視、障害、再処理、変更、退会 | drill記録、承認ログ |
責任分界では、ユーザー企業、solution provider、各取引先、GS1識別子管理、インフラ運用、情報セキュリティを分けます。特に「データ品質はユーザー責任」と一文で逃がさず、発生時点のcapture、gateway変換、repository validation、業務照合、訂正承認ごとにownerを置きます。
非機能要件を平均値だけにしない
通常日の平均event数ではなく、月末出荷、回収演習、ネットワーク復旧後のburstを想定します。query性能も「1件検索」だけでなく、一つの原材料ロットが多数の完成品・出荷先へ枝分かれするケースで測ります。保持期間、archive、再hydration、監査export、災害復旧後のevent順序も対象です。
可用性の数字を置くだけでは足りません。相手endpoint停止時にcaptureを失わないか、queueの順序と冪等性を保てるか、certificate期限切れを事前検知するか、再送が完了するまでどこに見えるかをシナリオで受け入れます。
PoCは「きれいなデモ」ではなく不一致を発見する
PoCの目的はEPCIS画面を見せることではなく、契約前に意味の不一致と運用負荷を発見することです。一つの製品ファミリー、二〜三社の取引先、現実の包装階層を選び、最低一回の変換と一回の分割を含めます。マスターデータは架空の一件だけでなく、桁、言語、単位、ロット命名のばらつきを含む匿名化実データを使います。
PoCの出口条件は、以下のように測定可能にします。
- 指定した開始ロットから期待する全投入ロットへトレースバックできる。
- 指定した原材料ロットから期待する全完成品・物流単位・出荷先へトレースフォワードできる。
- 重複送信でeventが増殖せず、内容違いの同一IDは隔離される。
- eventTimeとrecordTimeの差、offset欠落、未来時刻を検出できる。
- 未知語彙を黙ってdefaultへ変換せず、理由付きで保留できる。
- 訂正イベント受信後、元履歴を残したまま有効なtrace setが更新される。
- 取引先ごとの権限を越えたqueryが拒否され、監査ログが残る。
- partner担当者がrunbookだけで再送・訂正・照会を実施できる。
PoCで見つかった課題は「本番で対応」とまとめず、RFP要件、mapping、語彙、runbook、見積前提のどれに反映したかを追跡します。課題が多いこと自体は失敗ではありません。課題を見つけずに契約する方が危険です。
FAT/SATで企業間の受入を閉じる
FATは供給者の管理環境で、インターフェースとシナリオを再現可能に試す場です。SATは本番に近いネットワーク、認証、マスター、端末、取引先接続、運用者で、現場の成立を確かめる場です。チェーントレーサビリティでは、一社のシステムだけを「完成」としても受け入れは閉じません。
FATで固定するもの
- EPCIS/CBV profileと拡張namespaceのversion。
- positive/negative payloadのtest pack。
- JSON Schema/SHACLと業務validationの結果。
- trace-back/forwardの入力、期待集合、実出力。
- 重複、遅延、順序逆転、訂正、欠損、権限違反の挙動。
- performance testのデータ形状とburst条件。
- 未解決事項、暫定回避、SATへ持ち越す条件。
SATで確かめるもの
- 実際のbarcode/RFID/PLC/gatewayからeventTimeとIDが正しく届く。
- ERP/WMS/MESの取引とEPCIS eventが対応する。
- partnerごとのcertificate、token、firewall、DNS、時刻同期が機能する。
- offline復旧後の再送が冪等で、quarantineが担当者へ見える。
- 多言語画面でもcanonical codeが変わらない。
- 現場担当、品質、物流、ITがrunbookで調査・訂正・承認できる。
合否は「重大障害ゼロ」だけでなく、event completeness、意味不一致、未解決quarantine、trace結果差分、証跡の欠落で判定します。残課題を運用で吸収するなら、owner、期限、暫定統制、解除条件を承認記録へ残します。
EU DPPとFDAの動向から学ぶ事実境界
規制動向はチェーントレーサビリティの投資理由になりますが、標準と法的義務を混同してはいけません。EPCISは有力なイベント交換形式であって、すべての規制がEPCIS提出を義務付けるわけではありません。
EU Digital Product Passport Registry
欧州委員会は2026年7月20日、Digital Product Passport（DPP）Registryとtesting environmentの稼働開始を発表しました。公式発表によれば、事業者はsecure user interfaceまたはAPIで登録でき、Registryはunique product identifiersと関連metadataを登録する基盤です。製品データ自体はdecentralised mannerで保存されます。DPP公式ページも、製品別要件はdelegated actsや別のEU法令で定まり、移行時期が製品群で異なることを示しています。
したがって「EUは全製品データを中央Registryへ集約した」「全製品でDPPが義務化済み」「EPCIS 2.0がDPPの法定必須形式」とは書けません。実務上の示唆は、データが分散しても、一意な識別子、登録metadata、machine-readable model、API、access managementを使い、必要な主体が情報へ到達できる設計が求められることです。
FDA Food Traceability Ruleと24時間提出
FDAの現行ルール解説では、対象食品を扱う対象者に、harvesting、cooling、initial packing、shipping、receiving、transformationなどのCritical Tracking Events（CTE）に応じたKey Data Elements（KDE）の記録を求めています。要求を受けた後24時間以内、またはFDAが合意した合理的時間内に、必要記録と理解に必要な情報を提供し、該当する場合は電子的にsort可能なspreadsheetを提供する要件があります。
同ページは、2028年7月20日より前にFood Traceability Ruleを執行しないよう議会が指示し、FDAがそれに従う意向だとも説明しています。これはルールが撤回されたという意味ではなく、準備設計では最新の適用範囲と日程を法務・規制担当が確認すべきです。
FDAが2026年3月9日から4月1日に業界と行ったtraceability readiness tabletop exercisesの報告では、指定製品と短い期間の記録を探し、24時間以内にelectronically sortable spreadsheetを出せるかを試しました。FDAは、多くの企業が24時間以内に応答し、特定技術よりproactive supply-chain coordinationが強い結果を導いたとしています。まさに、中央DBの製品選択より取引先間の準備が重要だという実務的な示唆です。
出荷先追跡を24時間で再現する演習
ここでの24時間は、FDA対象企業では同ルールに沿う要件になり得ますが、すべてのタイ企業に共通する法定期限として示すものではありません。自社の契約、顧客要求、適用法令に合わせたreadiness targetとして使います。
演習は、曖昧な「ロットを追ってください」ではなく、要求時刻、対象識別子、対象期間、必要列、提出形式、承認者を固定して開始します。対象チームへ事前に正解を教えず、通常の連絡先とrunbookで対応させます。
- Request Received：要求と時計を記録し、incident ownerを決める。
- Scope Locked：品目、ロット、期間、拠点、除外条件を固定する。
- Trace Back：製造変換から投入原材料、仕入先発送・受領まで遡る。
- Trace Forward：完成品、包装階層、物流単位、出荷、顧客受領へ進む。
- Reconcile：EPCIS、ERP/WMS、partner responseの差分を説明する。
- Sortable File：要求列、型、code、timezoneをそろえて出力する。
- Approval：品質・規制・責任者が範囲と例外を承認する。
- Submit：期限内に安全な経路で提出し、受領証跡を残す。
演習KPIは「検索にかかった時間」だけではない
初回結果が速くても、出荷先が漏れていれば意味がありません。次の時間を分けて測ります。
- 要求受領からscope確定まで。
- 最初のtrace resultまで。
- 取引先から不足eventを回収するまで。
- 差分reconciliationが終わるまで。
- spreadsheet生成と品質承認まで。
- 最終提出と受領確認まで。
併せて、期待対象に対する完全性、重複、未知ID、時刻外れ、未解決差分、手作業補正件数、取引先別応答遅延を測ります。演習で手作業を使っても構いませんが、どの判断を誰が行い、次回までに何を自動化するかを残します。
トレースフォワードとトレースバックの落とし穴
トレースバックは完成品から原材料へ一方向に辿るだけではありません。再加工、混合、分割、代替投入があると複数の親へ枝分かれします。トレースフォワードも出荷伝票の顧客名だけでは足りず、どの物流単位がどの場所へ到着し、返品・転送・再梱包されたかを考慮します。
「出荷先 追跡」を顧客マスター検索へ縮めると、対象数量と残数量が合いません。変換収率、scrap、retain sample、在庫残、仕掛、返品をreconciliationし、input quantityとoutput/dispositionの差を説明します。単位換算や丸めがある場合は元単位と換算版も証跡に含めます。
運用開始後に壊れやすい五つの点
1. マスターと語彙の無通知変更
品目統合、場所移転、包装変更、reason code追加を相手へ伝えないと、schemaは通っても意味がずれます。変更申請、影響分析、partner通知、互換期間、sandbox test、production effective timeを標準手順にします。
2. 証明書・token・接続先の期限切れ
eventが発生してから接続不能に気づく運用は避けます。期限監視、更新責任、重複稼働期間、rollback、相手確認を決めます。送信queueが溜まった場合はeventTimeを維持し、復旧後のburstと重複を制御します。
3. quarantineが第二の倉庫になる
validation errorを隔離できても、担当者と期限がなければ未処理が蓄積します。理由別件数、最古滞留、partner別傾向、再処理成功率を可視化し、出荷・品質判断へ影響するものを優先します。
4. 取引先退会・合併・システム変更
endpointを止めるだけでなく、過去eventへの照会権、保持、監査export、identifier継承、legal holdを処理します。企業名の変更とparty identifierの変更を混同しないことも重要です。
5. 「一度合格したから大丈夫」という思い込み
四半期や大きな変更後に、代表ロットのtrace-back/forward、negative payload、訂正、権限、復旧を再試験します。取引先を追加するたびに同じonboarding gateを通し、例外承認を永久免除にしません。
FAQ：チェーントレーサビリティの実務疑問
チェーントレーサビリティとは何ですか？
複数の企業・組織が保有する追跡情報を、共通の識別子と意味でつなぎ、対象物の履歴・所在・関係をサプライチェーン全体で追える状態です。単一企業内の内部トレーサビリティと異なり、企業間のデータ契約、権限、オンボーディング、例外訂正が成否を左右します。
内部トレーサビリティがあれば十分ですか？
自社工程の品質調査には有効ですが、仕入先ロットまでのトレースバックや顧客・物流先へのトレースフォワードには企業間の接続が必要です。自社の出荷イベントと相手の受領イベントが同じ対象、時刻、場所、取引を参照できるかを確認してください。
EPCIS 2.0は必ず導入すべきですか？
すべての企業・規制で必須とは限りません。EPCIS 2.0はJSON/JSON-LD、REST、標準語彙、validation artefact、sensor関連などを利用でき、企業間のイベント相互運用を設計する有力な選択肢です。既存EDIやportalを残す場合も、共通event modelへ正規化できるかで評価します。
トレースフォワードとトレースバックの違いは？
トレースバックは対象製品から投入原料、工程、仕入先へ遡る探索です。トレースフォワードは指定原料や製品から、生成物、包装、出荷、受領先へ進む探索です。リコール準備では両方向を実行し、分割・統合・変換・返品を含む対象集合をreconciliationします。
出荷先追跡を24時間以内にするには何が必要ですか？
検索画面だけでなく、scope確定、partner連絡、EPCISとERP/WMSの照合、例外判断、sort可能な出力、品質承認、提出経路までを演習します。24時間という期限の法的適用は業界・製品・法域で異なるため、適用法令と顧客契約を確認してください。
取引先がEPCISに対応していない場合はどうしますか？
portal、CSV template、managed gateway、EDI変換などの入口を用意できます。ただし、入口ごとに意味を変えず、最終的には同じ識別子、語彙、時刻、訂正規則へ正規化し、共通validationとscenario testを通します。
PoCとFAT/SATはどう分けますか？
PoCは契約前に意味の不一致、技術実現性、取引先負荷を見つける活動です。FATは合意したprofileと異常系を供給者環境で再現可能に検証し、SATは実ネットワーク、端末、マスター、取引先、運用者を含めて本番成立を受け入れます。
まとめ：共有すべきものはデータベースではなく「検証可能な約束」
チェーントレーサビリティは、巨大な中央DBを導入すれば完成するプロジェクトではありません。who、what、when、where、whyと実装上のhowを、同じ識別子、語彙、時刻規則、訂正規則で交換し、受信側がtrace-back/forwardの結果を再現できることが本質です。
EPCIS 2.0とCBV 2.0は、その約束をJSON/JSON-LD、REST、語彙、sensor context、公開validation artefactで具体化する有力な基盤です。ただしschema合格と業務意味、標準採用と規制適合を混同してはいけません。取引先オンボーディングを検証ゲートで管理し、RFPに成果物と責任を明記し、PoCで不一致を発見し、FAT/SATと24時間演習で再現性を受け入れることが、実運用へつながる近道です。
TOMAS TECHでは、既存ERP/WMS/MESを前提にしたevent catalogue、EPCIS/CBV profile、取引先onboarding、RFP・PoC・FAT/SATの整理を支援しています。製品選定前の要件整理や、一つの製品群・取引先での小規模な検証段階でも、お問い合わせからご相談いただけます。
参照した一次情報
- GS1 Global Traceability Standard 2.0
- GS1 EPCIS overview
- GS1 EPCIS Standard 2.0.1
- GS1 EPCIS / CBV 2.0.1 artefacts
- GS1 Thailand: GS1 Traceability
- European Commission: The DPP Registry is now live
- European Commission: Digital Product Passport
- FDA: Food Traceability Rule
- FDA: Traceability Readiness Tabletop Exercises
