重要な追跡イベント（CTE）

この用語集の用語は、 SG Systems Global 規制および運用ガイド ライブラリ。

2026年1月更新 • FSMA 204トレーサビリティ規則、重要追跡イベント（CTE）、イベントベースのトレーサビリティ、KDEキャプチャ、受領/変換/出荷/集約、ロットIDスパイン、24時間データセット応答、EPCISアライメント、リコール準備 • 主に食品サプライチェーントレーサビリティ（FTL食品、コンプライアンス対応トレーサビリティシステム）

重要追跡イベント（CTE）とは、サプライチェーンにおいて製品の所有権が移転したり、重要な場所が移転したり、加工によって製品の識別情報が変わったりする、明確に定義された重要な瞬間を指します。これらのイベントでは、構造化されたロットリンクデータを取得しない限り、トレーサビリティが途切れてしまうことがよくあります。FSMA 204の用語では、CTEは食品トレーサビリティリスト（FTL）に掲載されている食品について「追跡しなければならないイベント」です。関連するキーデータ要素（KDE）は、これらのイベントについて「記録しなければならないデータ」です。

CTEが重要なのは、トレーサビリティが基本的にイベントベースであるためです。製品は「継続的に自分自身をトレースする」わけではありません。受領、加工、集積／混合、出荷といった特定の境界で何が起こったかを記録することで、トレーサビリティが確保されます。CTEを見落とすと、行き止まりが生じます。行き止まりは、サプライヤーのロットと完成品ロット、あるいは完成品ロットと顧客の出荷を確実に結び付けることができないため、リコールの範囲が広く、時間がかかる原因となります。

ありのままを言えば、ほとんどのトレーサビリティプログラムが失敗するのは、ロット（Lot）とは何かを理解していないからではなく、CTE（継続的テスティング）のキャプチャを制御されたワークフローとして扱っていないからです。そうしたプログラムは、ドキュメントや記憶、そして「後で考えればいい」という考え方に頼っています。FSMA 204は、企業がエクスポート可能なKDEデータセットを使用してCTEイベントを迅速にキャプチャすることを義務付けることで、こうした行動を排除するように設計されています。多くの場合、これは「24時間以内の対応」という期待に沿ったものです。

「CTE は、トレーサビリティが証明可能になるか、行き詰まるかのどちらかになる場所です。」

1) イベントベースのトレーサビリティにおけるCTEとは何か

CTEとは、トレースチェーンを定義するイベントです。施設内の「あらゆる動き」を指すのではなく、トレースのストーリーを有意義な形で変化させる瞬間を指します。

• 商品を保管する（受領）、
• 製品のアイデンティティを変える（変換）
• 商品の保管（配送）を解放します。
• アイデンティティ関係を集約、混合、または再構成します (集約/混合)。

実際には、CTE とは、記録しなかった場合に「このロットはどこから来たのか？」または「このロットはどこへ行ったのか？」を迅速かつ正確に答えることができないイベントのことです。

2) CTE vs KDE: イベント vs 必須フィールド

CTEは「動詞」です。KDEは「データ」です。各CTEごとに、最低限のKDEセットをキャプチャする必要があります。

• 誰： 関係する取引先（発送元/発送先）、該当する場合は運送業者。
• 内容： 製品 ID (商品 / SKU / GTIN)。
• どれ： ロット ID (TLC/ロット コード)、および使用される場合は SSCC/ケース ID。
• いくら： 数量とUOM。
• いつどこで： イベントの時間と場所。

イベントをキャプチャしてもKDEを見逃した場合、証拠のないイベントになってしまいます。KDEをキャプチャしても、それがどのイベントに属するかがわからなければ、コンテキストのないデータになってしまいます。両方が必要です。

3) CTEが存在する理由：トレーサビリティの行き詰まりを防ぐ

トレーサビリティの行き詰まりは、1つのイベントが欠落しているときに発生します。例えば、出荷ロットは確認できますが、それらを作成した内部処理にリンクできません。また、受入ロットは確認できますが、それらを使用した完成ロットにリンクできません。

CTEは、身元や保管場所が変更された時点でチェーンを強制的に捕捉することで、こうした行き詰まりを防ぐために存在します。運用上のメリットは計り知れません。リコール対象範囲を絞り込み、対応を迅速化し、顧客への影響を軽減できます。

4) コアCTEセット：受領、変換、出荷、集約

トレーサビリティ重視の製品を扱うほとんどの食品メーカーや販売業者にとって、コアとなる CTE セットには以下が含まれます。

• 受信CTE: 入庫保管イベント（サプライヤー/発送元 → あなた）。
• 変換CTE: 新しいロット関係（入力 → 出力）を作成する処理イベント。
• 配送CTE: 出荷保管イベント（あなた → 顧客/発送先）。
• 凝集/混合CTE: ID のグループ化または混合 (ケース → パレット SSCC、混合荷物、再梱包)。

一部の操作には追加の関連する CTE（収穫、冷却、初期梱包など）がありますが、上記のコアセットは「受領、変換、出荷」ビジネスの最小限のチェーンです。

5) CTEの受信：何を捕捉すべきか、そしてなぜそれが失敗するのか

受信側のCTEはワンステップバックの開始点です。キャプチャは即時かつロットリンクで実行する必要があります。

• 発送元ID、
• サプライヤーロットと内部ロットマッピング（該当する場合はTLC）
• 受領数量、
• 受領時間と施設の所在地、
• 処分（隔離/保留/解放）および受入れ証拠のリンク。

サプライヤーのロットがタイプ入力されていたり、混合パレットが1つのロットとして記録されていたり、材料が処分前に保管されていたりすると、受入に失敗することがあります。こうしたミスは「謎の入力」を生み出し、下流の系統図を汚染します。

6) 変換CTE：入力→出力の連携と質量バランス

変換CTEは内部系図ジェネレータです。以下のものをリンクする必要があります。

• 入力ロット（どのロットが消費されたか）、
• 出力ロット（作成されたロット）、
• 消費量と生産量（スクラップ/手直し/損失を含む）
• イベントの時間と場所、およびバッチ/実行識別子。

入力ロットの識別情報が欠落している場合、代替品が記録されていない場合、仕掛品タンクが非公式に管理されている場合、または識別情報なしで再加工品が追加された場合、変換は失敗します。これらの失敗は、双方向で行き詰まりを引き起こします（「どのロットにこの入力が含まれているのか？」と「どの入力がこの出力に供給されたのか？」という質問に答えることができません）。

7) 海運CTE: 船積み確認の真実と一歩前進の証明

出荷CTEは、一歩前進の証明を作成する場所です。以下の点を把握する必要があります。

• 発送先ID、
• 出荷識別子（注文/BOL/ASN）
• 出荷されたロット（またはロットにリンクされたSSCC/ケースID）、
• 出荷数量、
• 発送時間と場所/引き渡しの証拠。

「出荷確認」にロット識別が不要な場合、出荷は失敗します。これは、適切な顧客に迅速に通知できるかどうかに直接影響するため、修正が最も重要となる失敗です。

8) 凝集/混合CTE：混合パレット、SSCC、およびアイデンティティ保存

集約CTEは、IDがグループ化されている（ケースからパレットへ）か、混在している（混合パレット/積荷）場所です。SSCCを使用する場合は、ここでリンクします。

• SSCCパレットID → 含まれるケースID/ロットコード、
• パレットが壊れて再構築されたときの再構築イベント、
• 混合パレットの構成と制約。

混合パレットが「1ロット」として記録された場合、またはパレットの変更時にSSCCコンテンツリストが維持されていない場合、集計は失敗します。これにより、前方トレースの曖昧性と広範なリコール範囲が生じます。

9) ロット識別スパイン（TLC）：CTEがチェーン全体にわたってどのように接続されるか

CTEはロットIDを介して接続されます。FSMA 204では、トレーサビリティロットコード（TLC）がイベントレコードをリンクする標準的なロットIDです。ロットコードが受入、加工、出荷の各段階で不一致の場合、各イベントレコードが存在していても、チェーンは途切れてしまいます。

実用的なルール：すべてのCTEレコードは、チェーンを接続するために使用されるロットIDを参照する必要があります。そのために変換テーブルが必要な場合、システムは調査の時間的制約下では脆弱です。

10) イベントタイムキャプチャ：「後で入力する」がコンプライアンス違反になる理由

CTEはタイミングに敏感です。イベント時刻は記録の信頼性の一部です。イベント時刻を後から取得すると、記録が再構成されたように見えるため、監査リスクが生じます。イベント時刻の取得は可能な限り自動化（スキャナー/デバイスのタイムスタンプなど）し、編集内容は監査証跡と変更理由によって保護する必要があります。

イベント時間の記録も調査に役立ちます。リコールでは、時間枠に基づく範囲設定が一般的です（例：「10:00から14:00の間に製造された製品」）。イベント時間の記録が信頼できない場合、範囲は広くなります。

11) EPCISマッピング: CTEを標準化されたイベントとして表現する

EPCISは、CTEをKDEのようなフィールドを持つイベントとして表現する標準化された方法です。CTEイベントをKDEカテゴリでキャプチャすると、EPCISマッピングが自然になります。

• 受信と発送をオブジェクトイベントにマップします。
• 変換は変換イベントにマップされます。
• 集約は親子関係を持つ集約またはオブジェクトイベントにマップされます。
• ビジネス トランザクション (PO/BOL/ASN) は EPCIS businessTransactionList にマップされます。

EPCIS は CTE キャプチャを置き換えるものではなく、交換を運用化するものです。

12) 24時間データセット応答: CTEチェーンを迅速に組み立てる

CTE キャプチャの実際的なテストは、完全なチェーンを迅速に生成できるかどうかです。

• 関連する入力の受信データセット、
• 入力と出力をリンクする変換データセット、
• 顧客と出荷に出力をリンクする出荷データセット
• 混合パレットとSSCCコンテンツリストが適用される集約データセット
• 質量バランスの調整。

CTEが1つでも欠けていると、データセットは行き止まりになります。行き止まりは、保守的なスコープと遅延した応答を強制します。

13) 制御: 各CTEでのハードゲートと構造化された例外

制御なしのCTEキャプチャはオプションになります。影響の大きい制御：

• 受信ゲート: ロットの識別と処分がなければ受領を完了できません。
• 変換ゲート: 入力→出力ロットの連携がなければバッチを閉じることはできません。
• 船のゲート: ロット/SSCC ID を取得しないと出荷を確認できません。
• ホールドゲート: 不適格なロットは出荷も消費もできません。
• 例外チケット: スキャンの失敗、代替、および不一致には、承認を伴う構造化された記録が必要です。

これらの制御により、最も一般的なトレーサビリティのギャップ（ロットのタイプ、リンクの欠落、文書化されていない混合操作など）が防止されます。

14) CTE準備テスト：模擬リコールと行き止まりの訓練

CTE の準備は訓練を通じて証明されます:

• ランダムロット模擬リコール：受信→変換→発送のフルチェーンを生成する、
• サプライヤーロットトレース: 入力ロットの影響を受ける完成ロットを一覧表示します。
• フォワードトレース: 完了ロットの顧客/出荷をリストします。
• 質量バランス: イベント間の量を調整します。

行き止まりが目標です。行き止まりによって、どの CTE キャプチャが欠落しているか、または信頼できないかが正確に明らかになるからです。

15) KPI: CTEカバレッジとドリフトの測定

CTE プログラムは次のように測定する必要があります。

例外の増加と手動入力の増加は、キャプチャ ワークフローがずれていることを示す早期警告信号です。

16) 監査姿勢: 検査官がCTEイベントチェーンを圧力テストする方法

監査人は、ロットを抜き出し、チェーンの提示を求めることでプレッシャーテストを行います。彼らは以下の点を確認します。

• 完全なイベントチェーン（行き止まりなし）
• ロットリンクKDE（SKUのみの配送ではない）
• 量の調整（質量バランス）
• 整合性制御（監査証跡、サイレント編集なし）
• 速度（時間指定検索）。

クリーンなチェーンを迅速に作成できれば、監査の範囲は狭くなります。そうでない場合は、監査の範囲が拡大します。

17) 準備スコアカードをコピー＆ペーストする

これを使用して、CTE の準備状況を自己チェックします。

18) 失敗パターン: CTEキャプチャがどのように偽装されるか

• ドキュメントの置き換え。 ロットにリンクされたイベント レコードの代わりに PO/BOL が使用されます。
• ロット無しでの発送となります。 出荷確認では ID が取得されないため、前方追跡は推測になります。
• 変革の盲点。 入力→出力の連携はなく、内部系図が想定されます。
• 混合パレットのショートカット。 複数のロットが出荷され、1 つが記録されました。
• 事後エントリー。 後でキャプチャされたイベント。タイムスタンプは現実と一致しません。
• ゲートはありません。 キャプチャが完了していない状態でもユーザーは続行できるため、ギャップが保証されます。

CTE キャプチャは、ワークフロー レベルで強制される場合にのみ有効になります。

19) これをV5にマッピングする方法 SG Systems Global

V5では、スキャンファーストキャプチャ、ロットリンク、エクスポート可能なデータセットにより、受信/変換/出荷イベントをワークフローネイティブにすることで、CTEキャプチャをサポートします。

• サプライヤーロットマッピングと処分ゲーティングを備えたスキャン駆動型受入KDEキャプチャ、
• 入力ロットと出力ロットを数量調整で結び付ける変換イベント、
• スキャン駆動型の出荷KDEキャプチャは出荷、SSCC/ケースID、および文書にリンクされています。
• 不完全なキャプチャを防ぐためのハードゲートと例外ワークフロー
• パートナーと規制当局向けのエクスポート可能なデータセットと EPCIS 対応イベント。

20) 拡張FAQ

Q1. CTE はどの企業でも同じですか?
いいえ。CTEは役割や業務内容によって異なります。しかし、ほとんどのメーカーや流通業者にとって、受入、加工、出荷は中心的なイベントです。

Q2. 最も多くの故障を引き起こす CTE はどれですか?
変換。入力→出力の連携とマスバランスが必要ですが、多くの工場ではロットレベルの消費量を一貫して把握できていません。

Q3. 最も速く追加できる CTE 制御は何ですか?
ロットIDの取得なしには出荷確認を完了できません。この単一のゲートにより、フォワードトレースとリコールスコープの管理が劇的に改善されます。

Q4. EPCIS は必要ですか?
必ずしもそうではありません。EPCISは表現標準です。コンプライアンスは、CTEイベントとそのKDEを一貫してキャプチャし、データセットを迅速にエクスポートできることにかかっています。

Q5. CTE の準備状況をどのように証明しますか?
ランダムロットの模擬リコールを実行し、数量調整済みの受入→加工→出荷チェーンの完全なデータセットを迅速に作成します。行き止まり箇所を特定することで、どのCTEキャプチャが欠落しているか、または信頼性が低いかを正確に把握できます。

関連資料（実用的なもの）
CTE は、各イベントが完全な KDE キャプチャとペアになったときに動作可能になります。 受け入れ, , 運送すべて安定した TLC 迅速な輸出によって支えられ、 24時間以内の対応 期待。