FSMA 204 トレーサビリティ計画

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

2026年1月更新 • FSMA 204食品トレーサビリティ規則、トレーサビリティ計画の構造、FTLの範囲、CTE/KDEの記録管理、TLCガバナンス、受領/変換/出荷ワークフロー、24時間データセット応答、模擬リコール、EPCISの調整 • 主に食品サプライチェーンのトレーサビリティ（製造業者、共同包装業者、販売業者、FTL食品を扱う3PL）

FSMA 204トレーサビリティプランは、食品トレーサビリティリスト（FTL）に掲載されている食品に必要なトレーサビリティデータを組織がどのように取得、維持、取得するかを説明する、文書化された運用設計図です。これは「方針声明」ではありません。実際の業務から実際のデータへの道筋を示すものであり、重要な追跡イベント（CTE）がどこで発生するか、各イベントでどの主要データ要素（KDE）が取得されるか、トレーサビリティロットコード（TLC）がどのように割り当てられ、保存されるか、例外がどのように処理されるか、そしてプレッシャーの下で一貫性のあるデータセットを迅速に作成する方法を示しています。

この計画のビジネス価値は明白です。「トレーサビリティの行き詰まり」を防ぐことで、リコールの範囲と対応時間を短縮できます。コンプライアンス上の価値も同様に明白です。トレーサビリティを、文書やインタビューから再構成しなければならないストーリーではなく、実証可能なシステム特性に変えることができます。優れたトレーサビリティ計画があれば、データセットの要求前に計画が定義されるため、24時間以内のデータセット対応が現実的になります。

ありのままに言ってみましょう。ほとんどの企業がFSMA 204に不合格になるのは、ERPやWMSを導入していないからではありません。計画が曖昧で、ワークフローがゲート化されておらず、データが連携されていないことが不合格の原因です。受入部門ではサプライヤーのロットを一貫性なく取得し、出荷部門ではロットの識別なしに注文を確認し、変換部門では入力と出力が連携されていません。これらのギャップを埋めるのは計画です。つまり、CTEポイントと取得すべきデータフィールドを正確に指定し、その取得なしに作業が「完了」しないようにするための管理策を定義するのです。

「トレーサビリティ計画は、遵守を義務付ける書類ではありません。ドックが混雑し、ラインが動いているときにギャップが生じないようにするためのプレイブックです。」

1) FSMA 204トレーサビリティ計画とは何か（そして何ではないのか）

トレーサビリティ計画は、管理された運用モデル文書です。検査レベルの以下の4つの質問に、簡潔に答える必要があります。

• 対象範囲は何ですか? （どの製品とどの役割）
• CTE はどこにありますか? （受領、変換、出荷、集約ポイント）
• どのようなデータがキャプチャされますか? （KDE辞書とTLCルール）
• どうすれば早く証明できるのでしょうか? （エクスポートパッケージとドリル）

これは「トレーサビリティを実施しています」という文章ではなく、他の施設からコピーした汎用テンプレートでもありません。ドックドア、ライン、WIPフロー、出荷方法にマッピングされていない場合、実際のトレース要求には対応できません。

2) 範囲: FTLマッピングとロールマッピング

計画は、まずスコープを明確にすることから始まります。取り扱うFTLカテゴリーをリストアップし、それぞれの役割（受領のみ、変換、発送、保管、再梱包、配布）を明確にする必要があります。これは単なる雑用ではありません。担当するイベントや関連するKDEフィールドは、担当する役割によって決まります。

実践範囲の内容：

• 処理されるFTLカテゴリ（内部製品ファミリがマッピングされている）
• 含まれるサイトと場所、
• 役割マップ（製造業者、共同包装業者、販売業者、3PLなど）
• 関連するシステム (WMS/MES/ERP/LIMS) と各データ タイプに対する権限。

ありのままを伝えましょう。スコープが明確でないと、トレースプログラムは中途半端になってしまいます。スコープを宣言しないと、間違ったイベントのKDEをキャプチャしてしまい、重要なイベントのKDEを見逃してしまいます。

3) CTEマップ: ワークフロー内でイベントが発生する場所

CTEマップは計画の中核です。これは、各CTEが業務のどの段階で発生するかを示すワークフロー図（またはステップリスト）です。ほとんどの施設では、少なくとも以下の項目が必要です。

• 受信CTE: 製品がドックで保管されるとき。
• 変換CTE: 入力ロットが出力ロットになるとき（製造、再梱包、再ラベル、混合、分割）。
• 配送CTE: 製品が保管場所を離れたとき（出荷確認）。
• 集約/混合: アイデンティティ関係がグループ化または混合されている場合（ケース→パレット SSCC、混合パレット、故障/再構築）。

計画では、レコードを作成するための正確な運用トリガーを指定する必要があります。例えば、「サプライヤーロットがスキャンされ、社内ロットラベルが印刷された時点で受領が完了する」、または「SSCCスキャンが完了した後にのみ出荷が確認される」などです。トリガーが曖昧だと、バックフィルが発生します。

4) KDE辞書: 適用するフィールドセット

KDE辞書は、各イベントで必須となるフィールドの管理リストです。プランでは以下を定義する必要があります。

• 誰： 発送元、発送先、運送業者の識別子（フリーテキスト名だけではありません）。
• 内容： アイテムの ID (SKU/GTIN) と説明。
• どれ： ロット ID (TLC)、および使用される場合は SSCC/ケース ID。
• いくら： 数量とUOM、不一致の処理。
• いつ/どこで: イベントの時間と場所（施設 + オプションのドック/ライン/部屋）。

トレースギャップの多くは「特別なフィールドが欠けている」ということではありません。上記の5つのカテゴリ、特に「どのロット」と「いくら」が欠けているのです。だからこそ、辞書は厳格かつ最小限に抑えるべきなのです。

5) TLCガバナンス：ロットコードルールとマッピング戦略

この計画では、TLCのガバナンスを明確に定義し、「区画識別情報」がチームによって異なる解釈をされないようにする必要があります。以下を含めてください。

• TLCフォーマットルール（一意性、文字ルール、長さ）
• サプライヤーロットの保存（サプライヤーIDを上書きしない）
• 内部ロットマッピングルール（サプライヤーロット → 内部ロット → TLC）
• TLCが割り当てられている場合（受領 vs 梱包 vs 変換）、
• TLCがラベルにどのように表示されるか（人間が読める形式＋バーコード）、
• 出荷確認時に TLC を取得する方法 (ロット/SSCC 取得ルール)。

TLCガバナンスが弱ければ、あなたの計画はプレッシャーのかかる翻訳プロジェクトとなってしまいます。まさにそれを避けたいはずです。

6) 受領セクション: ドッキングワークフローと処分ゲート

受信セクションでは、「1ステップバック」キャプチャパスを定義します。以下の内容を指定する必要があります。

• サプライヤーロットの取得方法（スキャンファースト）
• 内部区画の割り当てとラベル付けの方法
• 数量がどのように記録され、文書と照合されるか
• 処分の適用方法（検疫/保持/解放),
• CoAと受入検査がどのようにリンクされているか（該当する場合）、
• 例外がどのように処理されるか (ドキュメントの欠落、読み取り不可能なラベル、混合パレット)。

KDEキャプチャの受領は、トレーサビリティ負債の発生または防止につながる重要なプロセスです。サプライヤーロットの識別情報がなければ受領を完了できないこと、また、隔離されたロットがリリースゾーンに漏れ出さないことを計画に明確に規定する必要があります。

7) 変換セクション：入力→出力の連携と質量バランス

変換セクションでは、内部系図の作成方法を定義します。以下の項目を定義する必要があります。

• 入力ロットが消費時にどのように捕捉されるか（分配/ステージ/使用時にスキャン）、
• 交代がどのように記録され承認されるか（サイレント交代は不可）
• 出力TLCの割り当てとラベル付けの方法
• 数量がどのように調整されるか マスバランス （スクラップ、手直し、損失）、
• WIPのアイデンティティがどのように維持されるか（タンク/トート/部分）
• リワークがオリジンリンクでロットとして扱われる方法
• 保留/逸脱が影響を受ける出力にどのようにリンクするか。

トレースの行き詰まりの最大の原因は、変換です。計画でこのセクションが詳細に定義されていない場合、文書では準拠しているように見えても、訓練では不合格になります。

8) 発送セクション: 発送確認の真実とKDEパッケージの発送

出荷セクションでは、出荷ロットIDの取得方法を定義する必要があります。以下の情報を含めてください。

• 出荷確認はスキャン駆動型（ロット/SSCC/ケース）です。
• ロットリンクなしでは出荷を完了できない（ハードゲート）
• 出荷保留/出荷停止の強制（不適格ロットは出荷不可）
• 取得した出荷識別子（注文ID、BOL/ASN（使用されている場合））
• 出荷数量は計画ではなく実績として記録され、
• 混合積荷規則（1回の出荷で複数のロットをどのように表すか）
• 引き渡しの証拠を取得します (マニフェスト、シール、署名/タイムスタンプ (使用された場合))。

正直に言うと、ロットリンクゲーティングによる出荷確認は、大幅な改善への最速の道です。これがないと、フォワードトレースは広くなり、遅くなります。

9) 集約/混合セクション：混合パレット、SSCC、ケース識別

パレットの組み立て、パレットの解体、または混合貨物の統合作業を行う場合は、計画書に識別情報の保存について記載する必要があります。実用的な内容：

• SSCCの使用ルール（パレットにSSCCが付与される場合）
• ケースレベルのIDルール（必要な場合はGS1-128）
• パレットコンテンツリストルール（コンテンツの維持方法）
• コントロールを再構築してラベルを変更する（「サイレント」コンテンツの変更は行わない）
• 混合パレットが出荷KDEでどのように表現されるか
• コンテンツ リストがスキャンと一致しない場合に例外を処理する方法。

集約を無視すると、生産ラインではなく倉庫で計画が失敗します。

10) 例外処理: スキャン失敗と置換のための制御されたチケット

すべてのトレースプログラムには安全弁が必要です。計画では、以下の項目について「例外チケット」の概念を定義する必要があります。

• スキャン失敗（検証後のみ手動入力可能）
• 代替品（計画ロットと実際のロットの記録、承認の取得）、
• 数量の不一致（予想と実際、理由コード、調査リンク）
• 不足している書類（解決されるまで自動的に隔離/保留）
• 混合パレットの曖昧さ（制御下で再構築するか、ケースレベルの ID を取得します）。

例外処理は、「後で解決する」という文化を防ぐためのものです。例外が構造化されていない場合、人々は口頭で解決することになり、データセットにギャップが生じてしまいます。

11) データの完全性: 監査証跡、編集、そして「再構築なし」の姿勢

データセットの信頼性を確保するために、計画では整合性ルールを定義する必要があります。

• 固有のユーザーID（共有ログインなし）
• 変更理由付きの編集の監査証跡、
• イベントタイムキャプチャとエントリタイムキャプチャ（および編集の処理方法）
• 日常的な慣行として遡及適用は行われない。
• 制御されたアクセスと保持保護。

トレースリクエストが発生した場合、最悪の動作は慌ただしいバックフィルです。計画では、欠落データの処理方法（例外処理と修正アクション）を明確に規定する必要があり、単にクリーンアップするだけにとどめるのは避けるべきです。

12) 保持とインデックス作成:データセットを検索可能にする

取得なしのキャプチャはコンプライアンスに適合していません。計画では、レコードのインデックス作成と取得方法を明記する必要があります。

• ロット中心のインデックス（TLC/ロットコードによる検索）
• 時間ウィンドウのインデックス作成（疑わしいウィンドウを日付範囲で検索）
• 取引先インデックス（発送元/発送先）
• 文書のリンク（イベントに関連付けられたCoA/BOL/ASN）
• 電子記録および紙記録の保管場所
• バックアップと保持のガバナンス。

このセクションは、24 時間対応を単なる願望ではなく現実的なものにするものです。

13) 24時間データセット応答パッケージ: 要求に応じてエクスポートするもの

調査中に「標準データセットパッケージ」を勝手に作成しないよう、計画書に「標準データセットパッケージ」を定義しておく必要があります。最低限必要なパッケージは以下の通りです。

• 受信データセット: 発送元、サプライヤーロット/内部マッピング、数量、処分、リンクされたドキュメント。
• 変換データセット: 数量と質量バランスによる入力→出力のつながり。
• 配送データセット: 発送先、出荷 ID、出荷ロット、数量、イベント時間/場所。
• 集計データセット（該当する場合）: SSCC/ケース関係と履歴の再構築。
• 例外： スキャンの失敗、代替、承認との不一致。
• サマリーシート: 範囲ステートメントと調整スナップショット (在庫、出荷済み、廃棄/再加工されたもの)。

計画にこのパッケージが明確に定義されていれば、リハーサルして改善することができます。計画に明確に定義されていない場合は、慌てることになるでしょう。

14) EPCISの調整: 摩擦を軽減するオプションの標準化

取引先からの標準化されたイベント交換の要求があれば、オプションでイベントエクスポート用のEPCISマッピングをプランに定義できます。EPCISとの連携により、後続のカスタムマッピング作業が削減されますが、これは社内のキャプチャが適切に行われている場合に限られます。

実用的なアプローチ：EPCISをキャプチャメカニズムとしてではなく、エクスポート形式として扱います。まずワークフロー内でKDEをキャプチャし、必要に応じてEPCISとしてエクスポートします。

15) 訓練と能力：捕獲行動の一貫性の確保

トレーサビリティ計画は、1人だけが「トレースを機能させる」方法を知っている場合、失敗します。計画では以下の点を定義する必要があります。

• 受領、生産、出荷ユーザー向けのロールベースのトレーニング
• スキャンの失敗や例外を処理する方法
• ロットが保留中の場合の対処法（オーバーライドなし）
• データセットエクスポートパッケージの実行方法
• ギャップが発見された場合に是正措置を実施する責任者。

トレーニングは、計画の厳格なゲートに沿って行う必要があります。「出荷が最優先」と訓練されていれば、捕獲を回避してしまうでしょう。捕獲は出荷の一部であるというルールを徹底して訓練しましょう。

16) テスト: 模擬リコール、訓練、行き止まりの探索

計画では、現実的なテストの頻度と方法を定義する必要があります。

• 模擬リコール訓練: ランダムにロットを選択し、完全なデータセット パッケージを生成します。
• サプライヤーロットドリル: 入力ロットから開始し、影響を受けるすべての完了ロットをリストします。
• フォワードトレースドリル: 完成したロットから開始し、それを受け取ったすべての顧客/出荷をリストします。
• 質量バランスドリル: 生産、出荷、在庫、スクラップ、手直しを調整します。
• 例外訓練: スキャンの失敗をシミュレートし、例外チケット パスが使用されていることを確認します。

行き詰まりこそが重要です。行き詰まりを見つけたら、それは真のギャップを見つけたということです。計画には、ギャップが発生した場合に是正措置と再テストを実施することを明記する必要があります。

17) KPI: 計画がうまくいっているかどうか（あるいはうまくいっていないか）を証明する

指標のない計画は単なるお飾りに過ぎません。役立つKPI：

例外発生率の上昇と手作業による入力の増加は、ドリフトの兆候です。監査で発見される前に、根本原因（ラベル、スキャン、ステージングの規律）を修正してください。

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

これを使用して、計画が実際に実行可能かどうかを評価します。

19) 失敗パターン：現実世界で計画を破綻させるもの

• 計画がワークフローと一致しません。 素晴らしい資料ですが、現実は間違っています。修正：CTEマップを実際の床面フローに合わせて更新してください。
• 発送確認はゲートされていません。 出荷時にロットIDが失われます。修正：ロット/SSCCキャプチャ時のハードゲート出荷。
• 変換が想定されます。 入力が出力にリンクされていません。修正: 入力→出力レコードと置換を強制します。
• 混合パレットは管理されていません。 複数ロットパレットに対して1つのロットが記録されていました。修正：SSCC/ケース識別ルールと制御の再構築。
• 例外は口頭です。 回避策はギャップを生み出します。修正：検証と承認を伴う例外チケット。
• ホールドは動きをブロックしません。 レコードが虚偽になります。修正: WMS/MES 全体で保留/解放を強制します。
• ドリルはスクリプト化されています。 簡単なロットを選んだため、行き止まりは見つかりませんでした。修正：ランダムロットの模擬リコールと時間指定エクスポート。

7つの失敗はすべて予測可能です。優れた計画は、訓練のスローガンではなく、設計によってそれらを防ぎます。

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

V5は、CTE/KDEキャプチャワークフローをネイティブにすることで、FSMA 204トレーサビリティプランをサポートします。

• スキャン駆動型 KDEキャプチャを受信 サプライヤーロットマッピングと処分ゲーティングにより、
• ロットリンク 変換イベントレコード 数量と質量バランスのサポートにより、
• スキャン駆動型 KDEキャプチャの出荷 出荷と取引相手に結びついており、
• ハードゲート 保持/解放 不適格ロットの出荷/消費を防ぐため、
• スキャンの失敗と承認による置換を記録する例外処理、
• エクスポート可能なデータセットパッケージは、 24時間以内の対応 期待と 模擬リコール訓練,
• イベント交換の調整 EPCIS エクステンション パートナーから要求された場合。

21) 拡張FAQ

Q1. トレーサビリティ計画は単なる規制上のチェックボックスですか?
いいえ。行き詰まりや広範囲にわたるリコールを防ぐのは運用モデルです。CTEポイント、KDEフィールド、TLCルール、そしてハードゲートを定義しなければ、運用モデルとは言えません。

Q2. FSMA 204 への対応において最も重要な管理策は何ですか?
ロットIDの取得なしでブロック出荷確認。このゲート一つでフォワードトレースの精度が飛躍的に向上し、顧客への影響を最小限に抑えます。

Q3. 計画が最も失敗するのはどこですか?
変換と混合パレット。入力→出力の連携が把握されていない場合、サプライヤーのロット調査は広範囲に及びます。混合パレットの識別が失われると、顧客への通知も広範囲に及びます。

Q4. 計画が機能することをどうやって証明するのでしょうか?
ランダムロットの模擬リコールを実施し、データセット全体のエクスポートを迅速に作成します。翻訳スプレッドシートを使わずに実行でき、数量が一致すれば、計画は現実的です。

Q5. 準拠するには EPCIS が必要ですか?
必ずしもそうではありません。EPCISは標準化された交換フォーマットです。コンプライアンスとは、必要なデータセットをキャプチャして生成することです。EPCISは、取引先が標準化されたイベント交換を要求するときに価値を発揮します。

関連資料（実用的なもの）
イベントキャプチャを中心に計画を立てます。 CTE + KDEs安定した TLC次に、追跡可能性が失われる 3 つの場所でキャプチャを強制します。 受け入れ, 変換, 運送証明するには 模擬リコール訓練 データセットのエクスポートは 24時間以内の対応 期待。