トレースフォワードとは、指定した原料ロット、仕掛品、完成品、シリアル番号から、その後どの製品へ変換され、どの梱包に入り、どの倉庫・顧客へ移動したかを下流方向へ追うことです。反対方向のトレースバックと組み合わせれば、回収範囲や原因調査の根拠を作れます。しかし「データベースに履歴がある」だけでは追跡能力を証明できません。分割・混合・再包装・手直し・外部委託をまたいで探索し、欠損も隠さず、監督機関や顧客へ検証可能なファイルを制限時間内に出せることが必要です。
本稿は用語解説で終わらせず、製造業の買い手がRFP、デモ、FAT、SAT、模擬回収へ落とせる受入設計を示します。食品以外にも応用できますが、FDAの24時間要件やEU DPPの適用は製品・法域・役割によって異なります。法的適用は品質保証、法務、所管当局へ確認してください。
トレースフォワードとトレースバックは何を証明するのか
GS1 Global Traceability Standardは、trace backとtrack/trace forward、取引関係の一つ前・一つ後を把握する考え方、Who・What・Where・When・Whyに関係するデータを共通語彙で整理しています。ここからRFPで大切な区別が三つ生まれます。
第一に、方向です。トレースバックは指定品から投入原料、供給者、受入、製造条件へ上流探索します。トレースフォワードは指定原料や中間品がどの出力、梱包、出荷先へ流れたかを下流探索します。片方だけ速くても、原因と影響範囲を結べません。
第二に、組織境界です。one-up/one-downはサプライチェーン連携の重要な最低線ですが、工場内で混合槽へ何が入り、何に分割され、どのケースへ集約されたかまでは自動的に証明しません。取引先リンクと内部製造リンクを一つの探索グラフへ接続する必要があります。
第三に、説明可能性です。検索結果が返るだけでなく、どのIDを起点に、どの時点のマスタ、どのタイムゾーン、どの権限、どの除外条件で検索したかを再現できる必要があります。結果が後で変わるなら、提出時点のスナップショットとクエリ条件を保存します。
| 探索 | 起点の例 | 途中で辿る関係 | 出力の例 |
|---|---|---|---|
| トレースバック | 顧客苦情の完成品シリアル | 梱包解除、製造、投入、受入、供給者 | 原料ロット、設備、時刻、担当、検査 |
| トレースフォワード | 疑義のある原料ロット | 混合、分割、変換、包装、集約、出荷 | 完成品、ケース、パレット、倉庫、顧客 |
| 双方向 | 任意のロットまたはシリアル | upstreamとdownstreamを同じ基準時点で探索 | 原因候補、影響範囲、欠損、除外根拠 |
製造履歴の追跡は「イベントグラフ」で設計する
通常の帳票一覧は工程順に見えても、ロットの分割や合流を表せないことがあります。追跡能力は、モノのIDと出来事をノードとエッジで結ぶイベントグラフとして設計すると検証しやすくなります。
GS1 EPCIS 2.0.1はObjectEvent、AggregationEvent、TransactionEvent、TransformationEvent、AssociationEventを定義し、what・when・where・whyの文脈を交換するための標準です。TransformationEventは入力と出力、AggregationEventは親と子の関係を表せます。2.0 artefactsにはJSON/JSON-LDやREST API関連の成果物もあります。ただしEPCISを採用しただけで、欠損のないデータ、法令適合、検索性能が保証されるわけではありません。RFPは「標準名を使うか」より、「現場の意味を損なわず、探索と証跡を交換できるか」を問います。
最低限モデル化する製造イベント
| 現場の出来事 | 必要な関係 | 失敗すると起きること |
|---|---|---|
| 受入 | supplier lot → internal lot | 外部供給者へ戻れない |
| 変換・混合 | input lots → output lots | 原料から完成品の影響範囲が切れる |
| 分割 | parent quantity → child lots | 一部だけの出荷先を絞れない |
| 包装 | product serial/lot → case | 製品とケースの対応が曖昧になる |
| 集約 | case → pallet/container | 物流単位の追跡が切れる |
| 集約解除・再包装 | old parent → children → new parent | 古いラベルと新しい出荷の関係が消える |
| 手直し・再投入 | rejected output → rework input | 同じロットが循環し探索漏れが出る |
| 出荷・移動 | logistic unit → ship-to/location | 出荷先追跡が帳票依存になる |
| 返品・廃棄 | returned/disposed object → disposition | 市場残存量と工場在庫を誤認する |
入力ロットAとBを混合して出力Cを作り、CをC1とC2へ分割し、C1をケースKへ包装したとします。Aから下流検索した際にC、C1、C2の両方へ到達し、Kと出荷先まで見える必要があります。一方、Kから上流検索すればC1、C、A・Bへ戻ります。変換数量が完全には合わない場合、歩留まり、サンプル、廃棄、計量差を理由コードで説明します。「数量が合わないからリンクを消す」は不合格です。
時刻・場所・主体・理由をIDと同じ強さで扱う
同じロット番号でも、工場、ライン、日付、品目体系が違えば別物になり得ます。RFPではID一意性の範囲、時刻のタイムゾーン、設備時計の同期、物理場所と業務場所、実行者と承認者、工程理由コードを定義します。マスタ名称が後日変わっても提出時の意味を再現できるよう、IDとversionまたは有効期間を保存します。
イベントの受信時刻と発生時刻も分けます。オフライン端末が復旧して一日遅れで送信した場合、発生時刻だけを見れば正常に見えます。受信遅延、再送、重複排除の履歴がなければ、24時間回答の時点でデータが揃っていたか証明できません。
出荷先追跡を24時間回答へ変えるRFP要件
「トレース可能」「リアルタイム」「EPCIS対応」といった一文は受入できません。RFPは入力、処理、出力、時間、例外、証拠を同じ行に置きます。
1. 対象範囲と探索境界
対象製品、原料、工場、外部倉庫、委託工程、販売組織、保持期間を列挙します。ロット、バッチ、シリアル、ケース、パレットのどの粒度を保持するかを決めます。外部パートナーが詳細を返せない場合は、照会先、照会時刻、回答状態をイベントとして残します。
2. 双方向クエリの契約可能な表現
たとえば「権限を持つ品質担当者が任意の有効ロットを指定すると、システムは受入から出荷までの上流・下流関係を循環なく探索し、変換、分割、集約、再包装、返品を含む結果と未解決リンクを出力する」と書きます。最大件数、保存期間、性能は実データ量から決め、根拠のない固定値をコピーしません。
3. 24時間の時計をどこから始めるか
FDAのFood Traceability Rule current pageは、対象となる文脈で、FDAから要請された記録を原則24時間以内またはFDAが合意した合理的な時間内に提供する説明をしています。2026年のFDA tabletop exercisesでは、参加者がrecord requestを受け、24時間以内に電子的なsortable spreadsheetを提出する運用が試されました。
ここから受入要件へ翻訳する際は、24時間を単なるSQL実行時間にしません。Request受領、権限確認、対象確定、抽出、外部照会、欠損レビュー、品質承認、ファイル生成、提出までを時計に含めます。法的に同じ期限が適用されない製造業でも、顧客要求や危機対応の強い内部目標として採用できます。
FDAはCongressional directiveにより、2028年7月20日より前に当該ruleをenforceしない意向を示しています。これは本稿で「final compliance dateが確定した」と言い換えません。対象食品、役割、最新の公表内容は個別に確認してください。
4. 提出パッケージの定義
| 成果物 | 含める内容 | 検証方法 |
|---|---|---|
| Summary | request ID、対象、基準時刻、作成者、承認者 | requestと一致するか |
| Sortable data | ID、event type、event time、location、source/destination、quantity | 型、列、sort/filterを試す |
| Relationship file | input/output、parent/child、ship-from/ship-to | 双方向に同じ関係へ到達するか |
| Exception log | missing、invalid、late、duplicate、partner pending | 空欄で隠していないか |
| Query manifest | query、system、version、timezone、filters | 再実行可能か |
| Evidence index | 元記録、電子署名、添付、hashまたはversion | 変更・参照権限を確認 |
電子的であることと、機械的に検証できることは別です。画像PDFだけでは並べ替えや突合が難しくなります。人が読む要約と、ソート可能なデータ、関係ファイル、例外ログを分け、同じrequest IDで束ねます。
EPCIS 2.0をRFPでどう評価するか
EPCIS 2.0.1を候補要件に含めるなら、PowerPoint上の「対応」ではなく、サンプルイベントとquery/exportを提示させます。
- ObjectEventで対象IDの観測・状態を表せるか。
- TransformationEventで複数inputと複数outputを失わず表せるか。
- AggregationEventでcase/palletの親子を追加・削除できるか。
- 再包装後も旧親、新親、子の履歴を時系列で辿れるか。
- JSON/JSON-LDのschemaやREST interfaceをどのversionで実装するか。
- partner extensionや独自語彙を受信側が解釈できない場合、どう隔離・通知するか。
- event correctionを上書きするか、訂正履歴として残すか。
標準形式への変換層を設ける場合、原本と変換後データの対応表、丸め、単位変換、timezone変換、コードマッピングをversion管理します。APIが成功HTTPを返しても、単位やbusiness stepが誤っていれば追跡結果は誤ります。構文テストと意味テストを分けてください。
FAT/SATでトレースフォワード能力を壊して試す
FATのhappy pathだけでは、実際の回収時に壊れる箇所を見つけられません。試験データはproductionを模した関係性を持ち、意図的な異常を混ぜます。
基本シナリオ
- 一つの原料が複数製品へ分割される。
- 複数原料が一つの中間品へ混合される。
- ケースがパレットから外され、別パレットへ再集約される。
- ラベルが破損し、管理された手順で再発行される。
- 手直し品が別日に再投入される。
- 外部倉庫から複数顧客へ分納される。
- 返品の一部が廃棄され、一部が隔離される。
例外注入シナリオ
| 注入する異常 | 期待する挙動 | 不合格例 |
|---|---|---|
| event遅延 | lateと表示し、締切時点の完全性を区別 | 後着を最初から存在したように表示 |
| duplicate event | 識別し、数量を二重計上しない | 出荷数量が倍になる |
| device clockずれ | 補正ルールと原時刻を保持 | 勝手に上書きして証跡消失 |
| unknown lot | unresolvedとして隔離・通知 | 検索結果から黙って除外 |
| unit不一致 | 換算versionと元値を保持 | kgとpieceを足す |
| master削除 | historical versionで再現 | 現在名で過去を誤表示 |
| access遮断 | 代替承認とbreak-glassを記録 | 共用adminで回避し監査不能 |
| partner未回答 | pending範囲と照会証跡を出す | 「該当なし」と断定 |
FATとSATの役割を分ける
FATでは、固定したdatasetでイベント関係、API、query、export、性能、権限、訂正履歴を再現します。SATでは、実設備・実ネットワーク・実作業者・実ラベル・実シフトで同じ探索を行い、PLC/MES/WMS/ERP間の遅延、手作業、タイ語・英語の入力、オフライン復旧を確かめます。
仮定例として、買い手が500ロットを含むtest pack、うち10件の意図的欠損、4種類の時間異常を用意し、Requestからapproved exportまで8時間以内、欠損分類100%、関係誤り0件を目標にすることはできます。これは相場や普遍的KPIではありません。リスク、件数、法域、夜間体制に合わせて合意する試験値です。
受入判定を平均点だけにしない
GS1 Global Traceability Checklistは12 sections、73 control pointsを持ち、mandatory requirements（musts）には100%を求める評価方法です。この考え方を借り、必須gateと改善scoreを分けます。例えば、双方向探索、欠損表示、権限、提出再現性、バックアップ復旧のどれかが欠けたら、総合点が高くても受入保留にします。ただし自社採点をGS1認証と表現してはいけません。
模擬回収を「検索デモ」から業務訓練へ変える
模擬回収はIT担当者だけで実行せず、品質、製造、倉庫、購買、営業、法務、経営、外部パートナーを含む運用として試します。開始時には、参加者へ正解のロット関係を見せません。
- 権限者がrequest IDと時計を開始する。
- 品質担当が起点IDと対象範囲を確定する。
- システム担当がupstream/downstream exportを作る。
- 現場担当が物理在庫、隔離、出荷記録と突合する。
- 購買がsupplierへ、物流がwarehouseへ照会する。
- 例外ownerがmissing/late/invalidを分類する。
- 品質承認者が提出版を凍結する。
- 独立したreviewerが再現性と漏れを確認する。
測るべき時間は検索時間だけではありません。権限者が見つかるまで、外部倉庫が答えるまで、欠損を判断するまで、承認者が署名するまでを分けます。「24時間以内だった」で終わらず、critical pathと手作業依存を次の改善へ戻します。
欠損を隠さないデータ品質とガバナンス
追跡システムの危険な失敗はエラー表示ではなく、不完全な結果を完全に見せることです。空欄は少なくともunknown、not captured、failed validation、not applicable、partner pendingに分けます。ユーザーが結果から行を除外した場合はfilterとしてmanifestへ残します。
責任分界
| 責任 | Accountableの例 | 必要な証跡 |
|---|---|---|
| ID発行 | 品目/物流マスタowner | 発番規則、重複検査、廃止履歴 |
| event capture | 工程owner | 作業標準、device status、教育 |
| interface | IT/OT integration owner | mapping、retry、dead-letter queue |
| data quality | 品質保証 | rule、exception review、closure |
| external exchange | 購買/物流owner | partner SLA、acknowledgement |
| emergency export | recall coordinator | authority、runbook、approved template |
| retention/access | data owner | 保存、legal hold、access review |
ISO 22005:2007はfood/feed chainのtraceability system design and implementationのprinciples and basic requirementsを扱い、ISOページでは2022年に確認されcurrentと表示されています。製品・工程を問わず参考になるのは、技術より先に目的、範囲、責任、手順、記録を定める姿勢です。
EU DPPを見据えた将来互換は「全部入れる」ことではない
EUのESPR Regulation (EU) 2024/1781はDPPの枠組みを含みますが、実際の要求はproduct-specific delegated acts等で具体化されます。全製品が同じ日から同じ項目を即時義務化された、と表現してはいけません。
European CommissionのDPPページはindicative timelineとしてregistry operationalを2026年7月20日、remaining standardsを2026年9月、iron and steelを2026年第4四半期と示し、publication requirementsに左右される旨も記載しています。したがってRFPでは、未確定項目を大量に固定するのではなく、identifier、event、data owner、access policy、version、evidence linkを拡張可能にします。
トレースフォワード基盤とDPPは同じではありません。前者はイベント関係と影響範囲探索、後者は定められた製品情報へのアクセス・交換を含む枠組みです。ただし、信頼できるID、履歴、version、access、外部交換という基礎は共有します。
ベンダーデモで必ず聞く12の質問
- この原料ロットから全出力と全出荷先をどう列挙しますか。
- 完成品から複数のinput lotへどう戻りますか。
- split、merge、rework、repackをどのeventで表しますか。
- 欠損リンクを「該当なし」と区別できますか。
- 発生時刻、受信時刻、訂正時刻を保持しますか。
- 削除・変更されたmasterを過去時点で再現できますか。
- EPCIS 2.0のJSON/JSON-LDまたはREST artefactをどこまで実装しますか。
- 標準外extensionをどうvalidationしますか。
- 24時間回答のrunbookで誰が承認しますか。
- sortable data、relationship、exceptions、manifestを一つのrequest IDで出せますか。
- バックアップから復旧後、同じquery結果を再現できますか。
- FAT/SATで異常eventを買い手が注入できますか。
録画済みデモではなく、その場で買い手が指定したlotを使い、上流と下流の両方を辿らせます。結果件数だけでなく、一件を原記録までdrill-downし、別の担当者がexportから再計算できるか確認します。
FAQ：トレースフォワードのRFPと受入試験
トレースフォワードとは何ですか？
指定した原料、部品、ロット、シリアルから、その後に作られた製品、包装・物流単位、在庫場所、出荷先を下流方向へ追う能力です。単純な出荷検索ではなく、変換、分割、集約、再包装、返品を含む関係を辿ります。
トレースバックとの違いは何ですか？
トレースバックは完成品や苦情対象から原料、供給者、工程条件へ上流に戻ります。トレースフォワードは疑義のある原料等から影響を受ける出力と出荷先へ進みます。回収判断では両方向の結果を同じ基準時点で結ぶ必要があります。
製造履歴追跡はERPだけでできますか？
ERPにロットと出荷があっても、設備・MES・WMS・委託先にある変換、分割、包装解除の関係が欠ける場合があります。製品と工程によりERPで十分な範囲もあります。RFPでは製品名ではなく、必要eventと欠損時の扱いを実データで確認します。費用検討はタイのトレーサビリティシステム費用の整理も参照してください。
出荷先追跡は24時間以内なら十分ですか？
時間だけでは不十分です。対象範囲、完全性、欠損表示、承認、再現性、機械可読性も必要です。FDA文脈の24時間は重要な参照点ですが、適用対象を確認し、自社の顧客契約やリスクに合うgateを決めます。
EPCIS 2.0を導入すれば法令対応できますか？
いいえ。EPCIS 2.0は可視化eventを交換する強力な共通形式ですが、適用法の判断、データcapture、品質、保持、権限、運用体制を代替しません。標準形式と受入証拠を分けて評価します。
シリアル番号とロットはどう使い分けますか？
必要な回収粒度、工程能力、ラベル、読取負荷、顧客要求で決めます。個体識別が必要な工程はシリアル、混合・連続生産はロットが適することがあります。両者を包装・集約eventで接続する設計はシリアル番号トレーサビリティの実務で詳しく説明しています。
模擬回収はどのくらいの頻度で実施すべきですか？
一律の頻度は本稿では定めません。法令、顧客要求、製品リスク、工程変更、組織変更を基に品質保証が決めます。定期試験に加え、大きなinterface変更や倉庫切替後に再試験する設計が実務的です。回収対応トレーサビリティの設計も合わせて確認してください。
欠損が一件でもあればシステムは不合格ですか？
必ずしも同じ判定ではありません。欠損の重大度、影響範囲、代替証拠、是正期限を事前定義します。ただし欠損を検知できず「完全」と表示する挙動は重大な問題です。mandatory gateと改善項目を分けます。
まとめ：追跡能力は24時間の証拠パッケージで買う
トレースフォワード／バックの価値は、検索画面の速さではなく、指定IDから変換・分割・集約・再包装を双方向に辿り、Who・What・Where・When・Whyと欠損を説明し、検証可能な提出物を制限時間内に作れることです。RFPではevent graph、提出形式、例外、権限、再現性を契約可能な文で定義し、FAT/SATでは異常を注入します。模擬回収は検索デモでなく、外部照会と承認を含む業務訓練にしてください。
タイ工場で既存ERP・MES・WMSを活かしながら双方向追跡のRFPやFAT/SATを組み立てる段階でも、TOMAS TECHへ相談できます。対象ロット、工程境界、希望する提出形式を共有いただければ、現状データの棚卸しから受入シナリオまで整理します。
参考資料
- GS1 Global Traceability Standard: https://www.gs1.org/standards/gs1-global-traceability-standard/current-standard
- GS1 EPCIS 2.0.1: https://ref.gs1.org/standards/epcis/2.0.1/
- GS1 EPCIS artefacts: https://ref.gs1.org/standards/epcis/artefacts
- FDA Food Traceability Rule: https://www.fda.gov/food/food-safety-modernization-act-fsma/fsma-final-rule-requirements-additional-traceability-records-certain-foods
- FDA Traceability Readiness Tabletop Exercises report: https://www.fda.gov/media/192993/download
- FDA release (2026-06-10): https://www.fda.gov/food/hfp-constituent-updates/fda-releases-report-traceability-readiness-tabletop-exercises-and-updated-faqs
- GS1 Global Traceability Checklist: https://www.gs1.org/standards/global-trace-check-list/current-standard
- European Commission, Digital Product Passport: https://single-market-economy.ec.europa.eu/single-market/digital-product-passport_en
- Regulation (EU) 2024/1781: https://eur-lex.europa.eu/eli/reg/2024/1781/oj
- ISO 22005:2007: https://www.iso.org/standard/36297.html
*本稿は一般的なRFP・受入設計の情報であり、法的助言、適合認定、認証、特定製品の推奨ではありません。適用法、顧客契約、製品別要求、安全・品質判断は、所管部門と専門家へ確認してください。例示した時間、件数、KPI、採点は仮定です。*
