EPCIS 2.0 導入：企業間共有のRFP・PoC・受入

EPCIS 2.0 導入を成功させる鍵は、API製品を先に選ぶことではありません。工場、倉庫、物流会社、顧客の間で「どのモノに、いつ、どこで、何が起きたか」を同じ意味で交換できるよう、イベント契約、開示範囲、RFP、受入証拠を先に決めることです。本稿はタイ・ASEANの製造業が90日で実装可否を判断するための実務手順を示します。

結論：EPCIS 2.0 導入で最初に買うのは「共有可能なイベント契約」

EPCISは、異なるアプリケーションが企業内・企業間で可視化イベントを作成・共有するためのGS1標準です。ERPを置き換える製品名でも、データを自動的に正しくする魔法でも、公開範囲を決める法的契約でもありません。したがって調達の対象は「EPCISサーバー一式」ではなく、次の5つが組になった運用能力です。

1. 対象品、梱包単位、物流単位、拠点、取引先を一意に識別する能力。
2. 現場の出来事を、合意したイベント型・語彙・必須項目で記録する能力。
3. MES、WMS、ERP、検査装置、センサーのデータをイベントへ変換する能力。
4. 取引先ごとの権限、保持期間、訂正手順を守って共有する能力。
5. 取り込み、照会、例外、再送、監査を契約可能な受入試験で証明する能力。

GS1の公式カレンダーでは、GS1 Industry & Standards Event 2026が2026年9月21〜24日にオンライン開催されます。本稿執筆時点でイベントでのEPCIS更新発表を示す一次情報はなく、ここでは開催直前という時機性だけをフックにします。現在の規格事実として確認できるのは、EPCIS 2.0.1が2025年7月1日に公開され、GS1のアーカイブで最新として掲示されていることです。

既存のDPP記事が製品パスポートの制度要件と製品向けデータ提供を扱うのに対し、本稿はその上流にあるイベント契約、capture/query、取引先別の開示境界と受入証拠に限定します。EPCISはDPP専用基盤ではなく、回収、品質、物流、顧客説明など複数用途へ同じ追跡事実を渡すための選択肢です。

この順序なら、ベンダーのデモがきれいでも実データでは意味が合わない、HTTP 202が返ったのにイベントが保存されていない、別顧客のイベントが検索できる、といった典型的な失敗を調達前に発見できます。

GS1 EPCIS 2.0とは何を標準化するのか

GS1のトレーサビリティ体系は、Identify（識別）、Capture（取得）、Share（共有）を土台にします。Global Traceability Standardは、実際の受入、梱包、出荷、加工などをCritical Tracking Event（CTE）、その出来事を説明する情報をKey Data Element（KDE）として整理します。EPCISは、その「出来事を共通言語で表して交換する」層を担います。

what・when・where・why・howでイベントを読む

EPCISイベントを設計するとき、フィールド名の一覧から始めるより、次の問いでレビューする方が実務的です。

「誰が」はソース・宛先や取引先、拠点、アクセス主体の設計と合わせて扱います。全イベントに全項目を詰めるのではなく、各CTEに必要なKDEを定義し、欠けた場合に拒否するのか、隔離するのか、補正待ちにするのかを決めます。

5つのイベント型を業務事実から選ぶ

EPCIS 2.0の規格・スキーマには、ObjectEvent、AggregationEvent、TransactionEvent、TransformationEvent、AssociationEventがあります。名称が似ていても目的が違います。

FIG2ではこの5種類を、順序を持たない独立した5パネルで比較します。「4つのイベント型」として説明する古い資料だけをRFPの根拠にすると、AssociationEventを落とす恐れがあります。

CBVと独自拡張の境界

Core Business Vocabulary（CBV）は、business step、dispositionなどに共通の値を提供します。企業ごとのコードを全部禁止する必要はありません。しかし、「shipping」をA社は出荷確定、B社は積込開始、C社はゲート通過の意味で使うなら、同じ文字列でも追跡結果は一致しません。RFPでは、標準CBV値、業界プロファイル、独自語彙、変換責任、廃止ルールを別表にします。

独自拡張は名前空間、データ型、単位、必須条件、所有者、バージョンを登録し、受信側が未知の拡張を受けたときの動作も決めます。黙って無視すると事故原因を見落とし、全面拒否するとパートナー追加のたびに止まります。許可リスト、隔離、警告付き受入のどれを使うかはデータ重要度ごとに分けます。

トレーサビリティ データ共有のスコープを1枚にする

PoC開始前に「追跡したい問い」を5〜10個へ絞ります。たとえば「原料ロットXを使った完成品はどれか」「顧客へ出荷したパレットYに含まれる箱は何か」「温度逸脱時間帯に影響を受けたロットは何か」です。これらから逆算してCTE、KDE、識別粒度を決めます。

対象と対象外を明記する

スコープ表には、品目群、工場、ライン、倉庫、取引先、期間、粒度、システム、例外を記載します。「タイ工場のトレーサビリティ」だけでは範囲が曖昧です。「工場Aのライン2で製造する製品群P、原料受入から顧客倉庫の受領まで、ロット＋物流単位、MES/WMS/TMSの3系統、サプライヤー1社と物流会社1社」のように境界を切ります。

既存の全体設計から整理したい場合は、タイ製造業のトレーサビリティシステム設計も参照してください。データキャリア選定が未確定なら、バーコード・QR・RFIDの選び方を先に確認すると、読取条件とイベント粒度の手戻りを減らせます。

内部データと共有データを分ける

GS1 Global Traceability Standardは、組織内データと、条件を満たせば外部共有できるデータの感度差を扱っています。生産レシピ、原価、詳細な人員情報、全検査波形を共有する必要は通常ありません。一方、品目・ロット、出荷・受領、影響判定に必要な品質状態などは、目的に応じて外部共有候補になります。

この分類がないと、技術チームは「取れるから送る」、法務・顧客担当は「怖いから送らない」となり、PoCがデモ用ダミーデータで終わります。

EPCIS REST APIを中心にした参照アーキテクチャ

構成は、現場ソース、正規化・検証、EPCISリポジトリ、共有ゲートウェイ、利用アプリの5層に分けると責任が明確になります。

1. 現場ソース：PLC直結を前提にせず、MES、WMS、ERP、スキャナー、RFIDリーダー、検査・温度システムから業務確定済みデータを受ける。
2. イベント生成：ローカルIDをGS1識別子へ対応付け、時刻・単位・CBV・イベント型を正規化する。
3. 検証と隔離：JSON Schema、業務ルール、重複、参照整合、許可語彙を検査し、不正イベントを隔離する。
4. EPCISリポジトリ：capture、query、events、discovery等を提供し、保持・訂正・監査を管理する。
5. 共有ゲートウェイ：取引先・用途・品目・期間に基づく認可、レート制限、マスキング、監査を行う。

JSON/JSON-LDとRESTを「開発しやすい」で終わらせない

GS1の公式概要は、EPCIS/CBV 2.0がJSON/JSON-LD構文、RESTによるcapture/query、センサーデータ、製品・組織・場所の認証詳細、GS1 Digital Link URI構文をサポートすると説明しています。公式artefactsにはOpenAPI、JSON Schema、SHACL、XML用XSD、オントロジーがあります。RFPでは「JSON対応」だけでなく、どの版のartefactで検証したか、contextの扱い、content type、ページング、タイムゾーン、単位、拡張の許可方法を答えさせます。

Digital LinkはGS1識別キーをWeb URIで一貫して表現するための標準であり、EPCISリポジトリそのものではありません。識別子の表現、解決先、イベント保管、アクセス権限を別コンポーネントとして設計すると、QRコードを読めば社内イベントが無制限に見える、といった誤設計を防げます。

HTTP 202は保存完了ではない

公式OpenAPIでは、/captureは複数イベントを非同期で受け付け、成功した受付はHTTP 202とcapture jobのLocationを返します。同じ説明には、受付成功がイベント保存を保証せず、capture IDでジョブ結果を確認するとあります。よって受入試験は次の流れを必要とします。

1. 正常なEPCISDocumentをPOSTする。
2. 202とLocationを検証する。
3. capture jobを完了までポーリングする。
4. success、errors、rollback/proceedの結果を検証する。
5. queryで保存結果と件数を照合する。
6. 元システムの送信台帳とリポジトリを突合する。

APIの応答だけでは不十分です。受信、検証、永続化、検索可能化、相手への可視化という各段階の状態を分けて測ります。

EPCIS RFPに入れるべき12の要求群

RFPは機能チェックリストではなく、回答を比較できる契約の骨格にします。

ベンダーロックインを見抜く質問

「EPCIS対応」という回答の後に、標準形式で一括exportできるか、標準OpenAPIへ外部クライアントから接続できるか、独自イベント型を使わずに主要ユースケースを表現できるか、contextや拡張語彙を顧客が所有できるかを質問します。さらに、契約終了時にイベント、マスターデータ、語彙、監査ログ、添付証明をどの形式・期間・費用で受け取れるかを明記します。

セキュリティは「ログインあり」では足りない

最低限、取引先、役割、品目、拠点、イベント型、期間、目的に応じた認可を試験します。A社がB社のロットIDを推測して検索しても、存在の有無を含めて漏れないことが重要です。管理者操作、query条件、export、権限変更、失敗した認証を監査ログへ残し、時刻同期とログ保持を決めます。

センサーデータやcertification detailsを扱えることと、それを全員へ見せてよいことは別問題です。生データは社内保管し、閾値逸脱と証明参照だけを共有するなど、最小開示をイベント契約へ組み込みます。

90日PoC：MAP・BUILD・TEST・ACCEPT

以下はGS1が定めた期間ではなく、TOMAS TECHの実装計画例です。対象取引先を2〜3社、製品群を1つ、追跡質問を5〜10個に絞れば、90日で本番投資の判断材料を作れます。

1〜15日：MAP

• スポンサー、データ所有者、現場責任者、取引先窓口を決める。
• 追跡質問、CTE、KDE、対象識別子、境界、成功指標を確定する。
• 現行MES/WMS/ERPの時刻、ID、状態コード、訂正方法を棚卸しする。
• 内部限定・条件付き・共有必須へデータ分類する。
• サンプル20〜50件を人手でイベントへマッピングし、意味のずれをレビューする。

この段階の出口はPowerPointではなく、署名可能なイベント契約、データ辞書、責任分担、テスト対象ロット一覧です。

16〜45日：BUILD

• 1つのcapture経路と1つのquery経路を実装する。
• JSON Schemaに加え、識別子、CBV、時刻、単位、親子関係の業務検証を作る。
• 再送キュー、dead-letter、重複判定、capture job照合を実装する。
• 取引先ごとの認可と監査ログを有効にする。
• 規格準拠サンプル、境界値、意図的な不正payloadをテスト資産にする。

すべての工場設備を直結しません。まず業務確定点を持つMES/WMSなどからイベントを生成し、必要な場合だけエッジ機器を追加します。

46〜75日：TEST

• 正常系：受入、変換、梱包、出荷、受領を端から端まで追う。
• 異常系：必須項目欠落、無効ID、未知語彙、未来時刻、単位不一致を投入する。
• 運用系：ネットワーク断、重複送信、順不同、部分失敗、再起動を試す。
• 権限系：別取引先、期限切れtoken、過剰な期間検索、一括exportを試す。
• 性能系：合意したデータ量・同時数・query条件でp50/p95と失敗率を測る。
• 突合系：ソース件数、capture完了件数、検索件数、取引先受信件数を照合する。

76〜90日：ACCEPT

• すべての受入ケースにID、実行者、日時、入力、期待値、実績、証拠リンクを付ける。
• 未達を重大度、暫定回避、修正期限、再試験条件で分類する。
• 本番化対象、次期対象、対象外を再確認する。
• 運用Runbook、権限承認、障害連絡、語彙変更、partner onboardingを引き渡す。
• Go、条件付きGo、No-Goをスポンサーが記録する。

受入試験：測れる合格条件へ変える

下記の数値は規格要求ではなく、RFPで調整する例示値です。重要なのは、分母、期間、データ量、測定場所を固定することです。

テストケースの書き方

「検索できること」では弱すぎます。「取引先Aのユーザーが、製品P、期間D1〜D2、bizStep=shippingで検索したとき、自社へ共有許可された15イベントだけが返り、取引先Bの5イベントは件数にも示されず、query監査ログに主体・条件・時刻・件数が記録されること」と書けば、合否が一意になります。

異常系も期待動作まで書きます。未知単位を拒否するのか隔離するのか、同じeventIDの再送を冪等に扱うのか競合として警告するのか、過去イベントの訂正を置換・追加・エラーのどれにするのかを明確にします。

データ量と費用を独自試算する方法

PoC前の概算は、取引数ではなくイベント数とpayload量で作ります。以下は仮定値による独自試算です。

3ライン、2シフト、各ライン・各シフト当たり月600ロット、1ロット当たり8イベントと仮定すると、月間イベント数は 3 × 2 × 600 × 8 = 28,800件 です。これに梱包階層イベント、再送、センサーデータ、保持年数、query頻度を足します。センサーを1秒ごとにイベント化すると急増するため、EPCISへは業務上意味のある観測・逸脱・集約値を記録し、高頻度波形は時系列基盤に保持して参照だけ結ぶ設計も比較します。

費用は次の箱で比較します。

• 初期：業務設計、ID整理、イベントマッピング、connector、権限、テスト。
• 継続：イベント保管、API利用、監視、サポート、証明書、バックアップ。
• 変更：取引先追加、品目・拠点追加、語彙変更、規格版更新、再試験。
• 退出：標準export、監査ログ搬出、データ消去証明、移行支援。
• 社内：データオーナー、運用者、現場教育、例外処理、partner support。

単価だけでなく、「1取引先を追加するのに何日・何役割・何テストが必要か」を比較すると、長期の総コストが見えます。

タイ・ASEAN展開で追加する設計条件

多言語ではコードを翻訳しない

画面ラベルはタイ語、英語、日本語、ベトナム語へ翻訳しても、event type、CBV URI、識別子、単位コードは機械可読の正規値を維持します。説明文とコード値を分離し、翻訳によってshippingが「出庫準備」と「出荷完了」に分裂しないようにします。

時刻と拠点を曖昧にしない

タイはUTC+7ですが、取引先やクラウドは別タイムゾーンです。eventTimeにはオフセットを持たせ、recordTimeとの差を監視します。読取場所と業務場所を混同せず、ゲートのリーダー位置、倉庫、法人拠点を別に管理します。ネットワーク断で後送する場合も、発生時刻と記録時刻を保持します。

サプライヤー成熟度の差を吸収する

全社へ同じAPI実装を要求すると参加が進みません。大手にはREST、別の取引先には管理画面・SFTP変換・ラベル読取など入口を複数用意しても、内部では同じイベント契約と検証を通します。入口の多様性と共有イベントの意味の一貫性を分けて考えます。

食品用途なら、タイ食品工場のトレーサビリティシステムのロット・原料・回収設計も合わせて確認すると、TransformationEventのPoCシナリオを具体化できます。

よくある失敗と回避策

失敗1：標準対応という製品表示だけで選ぶ

対応版、イベント型、REST endpoint、query、拡張、exportの範囲は製品ごとに違います。公式artefactを使ったサンプル交換と否定テストを契約前に実行します。

失敗2：マスターデータ不整合をAPIで隠す

同じ工場が3つのコード、同じロットが複数形式、タイムゾーンなしの時刻を持つ状態では、変換後も意味は一致しません。ID所有者と対応表の変更責任を決めます。

失敗3：最初から全イベント・全取引先を対象にする

境界が広いほど会議は増え、証拠は薄くなります。追跡質問、製品群、取引先、工程を絞り、拡張判断の条件を置きます。

失敗4：正常デモを受入試験と呼ぶ

本番では欠測、重複、順不同、権限ミス、ネットワーク断が起きます。異常系、復旧、漏えい否定試験を受入に含めます。

失敗5：センサーデータを全部EPCISへ入れる

規格がsensor dataを扱えることは、すべての高頻度波形を保存すべきという意味ではありません。追跡判断に必要な観測、集約、逸脱と原データ参照を分けます。

失敗6：運用変更を契約に入れない

品目、拠点、CBV、取引先、証明、アクセス条件は変わります。変更申請、互換期間、回帰試験、通知、廃止をRFPへ含めます。

EPCIS 2.0 導入の社内Go/No-Goチェック

次の12問に「はい」と証拠で答えられれば、本番RFPへ進めます。

• 追跡したいビジネス質問が5〜10個に定義されている。
• 対象製品、ロット、拠点、取引先、期間が限定されている。
• 各CTEとKDE、5イベント型の使い分けが合意されている。
• GTIN、GLN、SSCC、ロット、シリアルの所有・変換責任が明確である。
• CBVと独自拡張の台帳がある。
• 内部限定、条件付き共有、共有必須の分類がある。
• capture jobの最終状態まで突合する設計がある。
• query権限を取引先・品目・拠点・期間で否定試験できる。
• 訂正、重複、順不同、再送、隔離の動作が決まっている。
• 規格artefactを使った自動検証がある。
• 運用Runbookとpartner onboarding手順がある。
• 受入基準の分母・期間・データ量・証拠形式が固定されている。

FAQ：EPCIS 2.0 導入でよくある質問

EPCIS 2.0とはデータベース製品ですか？

いいえ。EPCISは可視化イベントのデータモデルとインターフェースを定めるGS1標準です。実装は商用製品、クラウドサービス、個別開発などがあり、保管、認証、監視、運用の品質は実装ごとに評価が必要です。

EPCIS 2.0.1とEPCIS 2.0の違いは何ですか？

GS1アーカイブでは2.0.0が2022年6月22日、2.0.1が2025年7月1日公開です。調達では「2.0対応」という表現だけでなく、対応する正確な版、CBV版、artefact、既知の制約を回答させてください。

GS1 EPCISを導入すればサプライチェーン全体が見えますか？

標準は共通言語を提供しますが、対象物の識別、各社のデータ品質、共有契約、アクセス権、partner onboardingがなければ全体可視化にはなりません。まず限定した追跡質問を端から端まで証明します。

EPCIS REST APIのPoCで最重要の試験は何ですか？

HTTP 202の確認だけで終わらず、capture jobの最終結果、query結果、元システム、相手受信を同じテストロットで突合する試験です。加えて、別取引先データが見えない否定試験を必須にします。

JSON-LDを必ず使う必要がありますか？

採用形式は参加システムとユースケースに合わせます。重要なのは、context、識別子、語彙、型、拡張の解釈を双方が同じにし、公式SchemaやSHACL等で検証できることです。単にJSONとしてparseできるだけでは意味の適合を保証しません。

センサーデータはどこまで共有すべきですか？

追跡判断に必要な範囲へ限定します。温度逸脱、測定期間、単位、センサー参照、校正参照などを共有し、高頻度原波形は社内の時系列基盤に残す案も比較してください。共有目的と保持期間が決定基準です。

EPCIS RFPで価格以外に比較すべき項目は？

対応版、イベント意味、標準export、partner onboarding工数、認可粒度、異常処理、監査、復旧、変更管理、退出条件、受入証拠を比較します。PoC価格が安くても、取引先追加が個別開発なら総費用が高くなります。

90日で本番導入できますか？

本稿の90日は全社展開ではなく、限定範囲で技術・業務・運用の実現性と投資判断を得るためのPoC例です。本番期間は拠点数、取引先数、マスター品質、接続方式、規制・契約要件で変わります。

まとめ：規格適合を、取引先と再現できる証拠へ変える

EPCIS 2.0 導入の価値は、イベントを保存できることではなく、企業の境界を越えて同じ出来事を同じ意味で照会し、回収、品質、物流、顧客説明に使えることです。what・when・where・why・how、5イベント型、CBV、JSON/JSON-LD、RESTは道具であり、成果を決めるのは追跡質問、開示境界、異常処理、受入証拠です。

TOMAS TECHでは、対象製品や取引先がまだ確定していない構想段階でも、イベント契約の作成、EPCIS RFP、90日PoC、受入試験表の整理をご相談いただけます。タイ工場と海外取引先の間で、どこまで共有し何を証明するかを小さく定義したい場合は、お問い合わせページからご連絡ください。

参考情報

• GS1 EPCIS Standard 2.0.1
• GS1 EPCIS Standard Archive
• GS1 EPCIS & CBV
• GS1 EPCIS/CBV 2.0.1 Artefacts
• GS1 EPCIS 2.0.1 OpenAPI
• GS1 Traceability
• GS1 Global Traceability Standard
• GS1 Digital Link standards
• GS1 Global Events Calendar

注：本文の90日構成、イベント量、性能・完全性の合格値、費用分類は、明記した仮定に基づくTOMAS TECHの計画例です。GS1の規格要求や市場平均ではありません。実際の契約値は対象業務、リスク、インフラ、取引先合意に合わせて設定してください。