主要データ要素 (KDE)

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

2026年1月更新 • トレーサビリティKDE、イベントベースのデータキャプチャ、ロットID、取引先リンク、数量とUOM、タイムスタンプ/ロケーションスタンプ、CTEマッピング、FSMA 204対応、EPCISアライメント、24時間データセットレスポンス • 主に食品サプライチェーントレーサビリティ（FTL食品、リコール対応、監査対応）

主要データ要素（KDE）とは、トレーサビリティイベント中に何が起こったかを記述する、必須のデータフィールドです。具体的には、誰が関与したか、どの製品が移動または変更されたか、どのロットが関与したか、どれだけの量が関与したか、そしてイベントがいつどこで発生したかなどが含まれます。KDEが重要なのは、トレーサビリティが失敗する原因は書類の不足ではなく、コアとなる識別子が欠落している、一貫性がない、取得が遅れている、またはイベント間でリンクされていないためです。KDEを徹底することで、「再構築によるトレーサビリティ」を防ぐことができます。再構築によるトレーサビリティは時間がかかり、エラーが発生しやすく、検査やリコールで弁護するのが困難です。

現代の食品トレーサビリティにおいて、KDE（キーデータ要素）は、FSMA 204（FDAのトレーサビリティ規則）の文脈で最も一般的に議論されています。しかし、KDEは、小売業者のトレーサビリティプログラム、GFSI（世界食品安全イニシアチブ）のトレーサビリティ監査、社内リコール準備プログラムなど、より広範なシステムの実際的な基盤でもあります。名称は様々ですが、運用上の要件は同じです。つまり、一貫性のあるロットリンクされたデータセットを迅速に作成できなければなりません。そのため、KDEは、上位/下位追跡、エンドツーエンドのロット系譜、そして「24時間以内の対応」といった要件と自然に結びつくのです。

ありのままを伝えましょう。KDE準拠とは、スプレッドシートにフィールドを追加することではありません。実際に重要な少数のフィールドがイベント発生時に確実にキャプチャされ、コンテキストに基づいて検証され、変換によって保持され、オンデマンドでエクスポート可能であることです。もしKDEがトラックが出発した後に記憶から入力されるのであれば、トレーサビリティデータセットは架空のものです。もしKDEがスキャン駆動型でゲート制御型であれば、トレーサビリティはシステムプロパティとなり、業務が多忙な時でも信頼性を確保できます。

「トレーサビリティのために 5 つの項目だけを記録する場合は、イベントが発生した瞬間に、誰が、何を、どのロットで、どれだけの量を、いつ、どこで記録するかを記録します。」

1) KDEとは何か、そしてなぜ重要なのか

KDEは、トレーサビリティを迅速かつ確実に実現する標準化されたフィールドです。トレーサビリティは対応能力であるため、KDEは重要です。原料ロットが関与していることが判明した場合、顧客が病気を報告した場合、あるいはFDAがデータセットの提出を要求した場合、推測ではなく事実に基づいて対応する必要があります。KDEは、各イベントレコードにチェーンを繋ぐために必要な最小限の情報が含まれていることを保証することで、これらの事実を提供します。

システムの観点から見ると、KDEは散在する運用データをトレースデータセットに変換するものです。適切なKDEがあれば、クリーンなイベントチェーンをエクスポートできます。そうでない場合は、書類を読んだり、関係者にインタビューしたりして再構築せざるを得なくなります。再構築はうまくいく場合もありますが、時間がかかり、不安定で、時間的な制約があるとうまくいきません。

2) KDE vs ドキュメント: 「PO + BOL」だけでは不十分な理由

多くの組織は、トレーサビリティとは「入荷用の発注書と出荷用のBOLがある」ことだと考えています。これは文書トレーサビリティであり、ロットレベルの精度が必要な瞬間に機能しなくなるのが一般的です。文書は商業的なコンテキストを提供し、KDEはロットにリンクされたイベントの真実を提供します。

一般的なドキュメントのみのギャップ:

• 発注書明細にはサプライヤーロットIDは含まれません。
• BOLには数量と製品は記載されますが、ロットコードは記載されません。
• ASNは存在するが、実際にロードされたものとはリンクされていない。
• 文書には変換（入力→出力）は全く存在しない。
• 混合パレットと再梱包は、文書のみの想定を破ります。

KDE プログラムはドキュメントを置き換えるのではなく、ロット ID とイベント時間によってドキュメントをイベント レコードにリンクします。

3) KDE カテゴリ: 誰が/何を/どれが/いくら/いつ/どこで

KDE を運用化する最も簡単な方法は、追跡可能なすべてのイベントに存在する必要があるカテゴリ グループとして KDE を扱うことです。

これらのカテゴリに基づいて記録管理を標準化すると、最小限の作業でほとんどの規制および顧客プログラムに適応できます。

4) ロットID: すべてが依存するKDE

ロット識別情報は、イベントをリンクする主要なキーです。FSMA 204では、この概念はトレーサビリティロットコード（TLC）として表現されることがよくあります。一般的なトレーサビリティでは、社内ロット番号またはバッチ番号が使用される場合があります。命名は重要ではなく、その特性が重要です。

• ユニーク： 保存期間および調査期間にわたって繰り返されることはありません。
• イベント時に撮影: 受領、変換、出荷中に記録されます。後から記録されるものではありません。
• 変換を通じて保存: 入力ロットは出力ロットにリンクします (行き止まりはありません)。
• 送信レコードに表示されます: 出荷中の KDE に表示されるため、前方トレースが可能です。
• 混合操作に耐えます: 混合パレット、部分的、再梱包では、ケース/SSCC リンクによりロット ID が保持されます。

ロットの識別が弱いと、他のKDEではそれを補うことができません。誰がいつ出荷したかは分かりますが、どのロットが関係していたかは分かりません。これではトレーサビリティとは言えません。

5) FSMA 204のKDE: CTEがキャプチャ内容をどのように制御するか

FSMA 204は、KDEキャプチャをイベントタイプ（CTE）別に体系化しています。これは、イベントの種類によってKDEセットが若干異なるため重要です。受入では出荷元とサプライヤーロットのキャプチャが重視され、出荷では出荷先と出荷IDが重視され、変換では入力と出力の連携と数量調整が重視されます。

運用上のポイントはシンプルです。KDEはイベントが発生した時点で捕捉する必要があります。「CTEマップ」はワークフローマップです。工場内のどこでCTEが発生するかがわからなければ、KDEを確実に捕捉することはできません。

そのため、多くの企業は、受信、変換、出荷という3つのコアテンプレートと、制御された例外処理パスを構築することで、KDEプログラムを実装しています。

6) KDEの受信：一歩後退して正しく開始する

KDE を受け取ることは、あなたの「一歩後退」の証拠となります。受け取り時に確認すべき重要な項目は以下のとおりです。

• 発送元/サプライヤーのIDと所在地、
• サプライヤーロットID（および内部ロットマッピング）
• 製品ID（商品/SKU）
• 受領数量およびUOM、
• 受領時間/場所、
• 処分（隔離/保留/解放）および受入証拠リンク（必要な場合は CoA/検査）。

KDEのギャップのほとんどは、サプライヤーロットの型指定、CoAの欠落、混合パレットを1つのロットとして記録すること、そして「処分前の保管」といった点から始まります。受入キャプチャ規律を修正すれば、下流の系統図は劇的に整理されます。

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

変換KDEは、トレーサビリティが内部系図となる場所です。変換レコードは以下をリンクする必要があります。

• 入力ロットリスト（消費されたロット）、
• 出力ロットリスト（作成されたロット）、
• 消費量と生産量（スクラップ/手直し/損失を含む）
• イベントの時間/場所と実行/バッチのコンテキスト。

トレース調査において、変換は最も一般的な行き詰まりの原因となります。多くの工場では「バッチXを製造しました」という記録はあっても、「バッチXはこれらの特定のロットを消費しました」という記録はないためです。サプライヤーロットが関与している場合、どの完成ロットにそれが含まれているのかという疑問が生じます。この答えは、変換KDEが完全である場合にのみ得られます。

変換記録では、質量バランスによって数量を照合する必要があります。照合できない場合、監査人はそれを「製品がどこかへ移動した」というトレースデータの欠落と解釈します。

8) KDE の出荷: 一歩前進の証明と出荷確認の真実

出荷KDEは「一歩前進」の証明です。出荷確認時に、以下の情報を取得する必要があります。

• 出荷先取引先のID、
• 出荷識別子（注文ID、BOL、ASN（使用されている場合））
• 出荷ロット識別（TLC/ロットコード）
• ロット/品目別の出荷数量、
• 出荷時間/場所および引き渡しの証拠（該当する場合はマニフェスト/シール/署名）。

出荷は、ドックの負担が大きいため、トレーサビリティが最も無視される領域です。そのため、「出荷確認はロットにリンクされている必要がある」という設定は、ほとんどのKDEプログラムで最も影響力のある制御となっています。ロットを識別せずに出荷すると、フォワードトレースは遅くなり、範囲も広くなります。

9) 集約と混合パレット:ドックを遅らせることなくアイデンティティを維持する

実際の倉庫では、混合パレットや分割ケースが使用されています。アイデンティティの保持には戦略が必要です。

• ケースレベルの ID: つかいます GS1-128 混合パレットが頻繁に使用されるケースをスキャンします。
• パレットレベルのID: つかいます SSCC パレットの内容リストを維持し、SSCC でスキャンします (すべてのケースではありません)。
• コントロールを再構築します: パレットの内容が変更された場合は、制御下で SSCC コンテンツ リストを再構築します (「サイレント変更」なし)。

混合パレットが非公式に取り扱われると、出荷 KDE で間違ったロット範囲が記録され、リコール時に通知不足または過剰通知のリスクが生じる可能性があります。

10) データ品質ルール: 検証、例外管理、監査証跡

KDEプログラムは、データの誤入力が起こりやすい場合、正常に動作しません。ワークフローにはデータ品質ルールを組み込む必要があります。

• 検証： ロット形式のチェック、予想されるコンテキストのチェック、UOM の正規化。
• 制御された例外: スキャンの失敗と置換では、検証を伴う構造化例外チケットを使用する必要があります。
• 監査証跡： 編集には変更理由が必要であり、元の値は保持されます（ 監査証跡).
• ステータスゲーティング: 保持/解放 不適格ロットの出荷と消費をブロックする必要があります。

原則はシンプルです。システムがKDEを完了せずに先に進めれば、ユーザーは先に進んでしまいます。完了を優先事項ではなく必須事項とすることで、ギャップを防ぐことができます。

11) 単位、数量、漁獲重量：「数学は調和しなければならない」というルール

数量はKDEです。「誰が受け取ったか」だけでは不十分だからです。リコールでは、影響を受ける数量を把握する必要があります。数量の把握は一貫して行う必要があります。

• 標準化された単位と変換を使用する（「時々ケース、時々ポンド」を避ける）、
• 注文数量ではなく実際の出荷数量を把握する。
• 矛盾点とその理由（ショートピック、損傷、交代）を記録する。
• 該当する場合は漁獲重量を記録し、変動重量をロットIDにリンクする。
• 変換と出荷全体の質量バランスを調整します。

数量が一致しない場合、データセットは不完全なものとみなされます。監査人はそれを記録の欠落と解釈し、調査範囲が拡大します。

12) EPCISの調整: KDEキャプチャを交換可能なイベントに変換する

EPCISは、イベントベースのトレーサビリティを表現するための一般的な標準規格です。KDEキャプチャはEPCISと自然に整合します。なぜなら、EPCISイベントは基本的に「標準化されたエンベロープ内のKDE」だからです。KDEキャプチャが適切に行われると、次のようになります。

• 受信はEPCISオブジェクトイベント（イベント時間、場所、識別子、ビジネストランザクション参照）になります。
• 配送はEPCISオブジェクトイベント（ビジネストランザクション、SSCC /ケースIDを介した配送先コンテキスト）になります。
• 変換は EPCIS 変換イベント (入力識別子 → 数量を含む出力識別子) になります。

EPCISは弱いキャプチャを修正するものではありません。強いキャプチャを交換可能かつ機械可読なものにします。

13) 24時間対応：KDEの設計が検索速度を決定する仕組み

KDE対応の実用性を判断する基準は、データ取得速度です。規制当局からデータセットの提出を求められた場合、迅速に（多くの場合、24時間以内の記録応答という期待値に合わせて）提供できなければなりません。データ取得速度は、以下の要素に依存します。

• ロットIDはイベント間で一貫している
• イベント記録はロット/時間/取引相手別にインデックス化され、
• 変換が明示的にリンクされている（行き止まりがない）
• 出荷記録がロットにリンクされている（SKUのみの出荷はない）
• エクスポートは手動でのステッチではなく、標準化 (CSV/EPCIS) されています。

イベントを接続するために翻訳スプレッドシートが必要な場合は、プレッシャーの下で作業が遅くなり、エラーが発生しやすくなります。

14) 実用的なテンプレート: 受信/変換/発送のための最小限の実行可能なフォーム

「最小限の実行可能な」KDE フォーム セットが必要な場合は、非常にシンプルにしてください。

これらのテンプレートは、「誰が/何を/どれが/いくら/いつ/どこ」のカテゴリに直接マッピングされ、イベント ベースのエクスポートと互換性があります。

15) ギャップを防ぐためのコントロール：ハードゲートとエスカレーションパス

テンプレートはギャップを防げません。ゲートが防ぎます。KDEで最も影響の大きいコントロールは次のとおりです。

• 受信ゲート: サプライヤーのロット識別と処分がなければ受領を完了できません。
• 変換ゲート: 入力ロットリストと出力ロットの割り当てがないとバッチを閉じることができません。
• 船のゲート: ロット/SSCC ID を取得しないと出荷を確認できません。
• ホールドゲート: 不適格なロットは出荷も消費もできません。
• 例外規律: 手動入力には検証と変更理由が必要であり、トレンド例外は KPI として扱われます。

「隙間なし」を実現したいなら、少なくともこれら 5 つのゲートが必要です。

16) KDEの準備状況のテスト：模擬リコールと行き止まりの訓練

KDE の準備ができていることを証明するための唯一の正直な方法は、実際にテストすることです。以下を実行します。

• ランダムロット模擬想起: 完成したロットを選択し、受信/変換/出荷データセットを迅速に作成します。
• サプライヤーロット追跡: サプライヤー ロットから開始し、影響を受けるすべての完成ロットをリストします (変換証明)。
• フォワードトレースドリル: ロットを選択し、それを受け取ったすべての顧客/出荷を数量とともにリストします。
• 質量バランスドリル: 選択したスコープの生産/出荷/在庫/スクラップを調整します。

行き詰まりはKDEにギャップがあることを意味します。ワークフローを修正し、再テストしてください。これが真の成熟への道です。

17) KPI: KDEの完全性とドリフトの測定

ドリフトを早期に検出できるようにシステムを測定します。

例外率が上昇した場合、それはレポートの問題ではありません。プリンター、スキャナー、ステージングの規律、サプライヤーのラベル、トレーニングといったワークフローの問題です。

18) 失敗パターン: KDEプログラムが「存在する」のに動作しない理由

• 事後エントリー。 KDE は監査に合格するために「後から補填」しましたが、タイムラインは現実と一致しません。
• ドキュメントの置き換え。 ロットにリンクされたイベント データなしで提供される PO/BOL。
• 変革の盲点。 入力は出力にリンクされていません。内部の系譜は推測です。
• SKUにより発送します。 出荷確認時にロットが捕捉されず、前方トレースが広くなります。
• 手動入力が正規化されました。 タイピングがルーチン化され、エラー率が上昇します。
• 混合パレットのショートカット。 複数のロットが出荷されましたが、1 つのロットとして記録されました。
• 保留は強制されません。 不適格なロットは移動および出荷される可能性があり、記録が告白される可能性があります。

解決策は「書類作業の増加」ではありません。イベントタイムキャプチャ、スキャンファーストワークフロー、ハードゲート、そして監査証跡による例外管理です。

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

V5は、KDEを手動フォームではなくワークフローの出力として扱うことで、KDEの規律をサポートします。

• スキャン駆動型の受信はサプライヤーのロット、数量、処分ゲートを捕捉し、
• 変換記録は、入力ロットと出力ロットを数量調整でリンクします。
• スキャン駆動型出荷は、出荷先リンクと文書出力により、積荷時にロット/SSCC IDを取得します。
• 保留/解放ゲートは不適格ロットの出荷と消費を防止します。
• 例外ワークフローは、承認と監査証跡を使用してスキャンの失敗と置換をキャプチャします。
• エクスポートでは、必要に応じて迅速なデータセット応答と EPCIS 対応イベント データをサポートします。

実際には、V5 は KDE キャプチャを作業の「デフォルト パス」に変えるので、後でキャプチャすることを忘れないようにユーザーに依頼する必要がなくなります。

20) 拡張FAQ

Q1. KDE は FSMA 204 食品にのみ適用されますか?
KDEは一般的なトレーサビリティの概念ですが、FSMA 204ではCTEとFTL食品について明示的に規定されています。FSMA 204の適用範囲外であっても、KDEの規律はリコールへの対応と監査の防御力を向上させます。

Q2. 最も重要な KDE は何ですか?
ロットID（TLC/ロットコード）。ロットIDが欠落しているか矛盾している場合、他のフィールドがいくつあってもデータセットは壊れています。

Q3. 準拠するには EPCIS が必要ですか?
必ずしもそうではありません。EPCISは一般的な交換フォーマットですが、コンプライアンスは必要なKDEデータセットを迅速かつ一貫して取得・生成できるかどうかにかかっています。EPCISは、取引先が標準化された交換を必要とする場合に役立ちます。

Q4. ギャップを生じさせずにスキャンの失敗を処理するにはどうすればよいですか?
管理された例外事項を使用します。つまり、2人目の確認、理由コード、監査証跡を含む手動入力を行います。スキャンの失敗をKPIとして追跡し、根本原因（ラベルの印刷品質、スキャナーの衛生状態、サプライヤーのラベルなど）を修正します。

Q5. KDE の準備状況をどのように証明しますか?
ランダムロットの模擬リコールを実行し、数量調整済みの完全な受入・加工・出荷データセットを要求します。翻訳スプレッドシートを使わずに迅速にエクスポートできる場合、KDEプログラムは本物です。

関連資料（実用的なもの）
KDEの規律はスキャン駆動型ビルドで運用可能になります 受け入れ、ロットリンク 変換、スキャン駆動型 運送 ロットIDなしでイベントを閉じることを防ぐハードゲート。そして、それを継続的に証明する。 模擬リコール 高速データセットエクスポートは 24時間以内の対応 期待。