系譜は「親子リンク」ではなく「消費イベント」で持つ
系譜（ジェネアロジー）を「完成品ロットに、使った材料ロットをぶら下げる」という親子関係の表として設計すると、実装の途中で必ず破綻します。破綻するのは、次のような現場が普通に存在するからです。
- 材料ロットAを流している途中で、切れたのでロットBを継ぎ足した
- 1バッチの投入で、同じ品目を2つの仕入先ロットから半分ずつ使った
- 前工程の仕掛を戻して再投入した（リワーク）
- 使い切らなかった材料を、次のロットに持ち越した
親子リンクは「AはBから作られた」という結果しか表現できません。上の4つはいずれも「いつ・どれだけ・どの作業指図に対して使ったか」という過程の情報を必要とします。
したがって、系譜の中核テーブルは関係表ではなく消費イベント表（材料投入トランザクション）です。1回の投入＝1レコードとして、次の項目を持ちます。
作業指図ID｜工程ID｜投入日時｜投入品目｜投入ロット／シリアル｜数量｜単位｜投入者｜設備ID｜取消フラグ
このモデルにすると、上の4つはすべて「レコードが複数ある」あるいは「数量が部分的である」だけの話になり、例外処理が不要になります。逆順の追跡（この材料ロットはどの完成品に入ったか）も、同じ表を投入ロットで検索するだけで成立します。
4つのテーブルで系譜は成立する
系譜のために必要な実体は、実装上たった4つです。多くの製品が持つ「トレーサビリティ画面」は、この4つを検索するUIにすぎません。
重要なのは、産出イベントが生んだ在庫単位が、次工程では①として消費イベントの入力になるという再帰構造です。この再帰が成り立っていれば、工程が5つでも20でも同じロジックで追跡できます。逆に、工程ごとに専用の系譜テーブルを作ってしまうと、工程追加のたびに追跡ロジックの改修が発生します。
設計で決める4項目
系譜の設計判断は、製品選定より前に自社で決められます。決めずにベンダーへ渡すと、標準機能の初期値がそのまま採用され、稼働後に変えられなくなります。
| 決める項目 | 選択肢 | 判断の軸 | 後から変えられるか |
|---|---|---|---|
| 粒度 | ロット／サブロット／シリアル | リコール時に絞り込みたい最小単位 | 実質不可（過去データと連続しない） |
| 分岐点 | どの工程でロットを切り直すか | 品質特性が変わる操作（熱処理・混合・分割）の直後 | 難しい。工程マスタと在庫の両方に影響 |
| 保持期間と保持場所 | オンライン／アーカイブ／段階移行 | 応答時間の要求。24時間以内ならアーカイブでも可、30分以内ならオンライン必須 | 可能。ただし移行設計が必要 |
| 照会経路 | MES画面／BI／API公開 | 誰が照会するか。顧客・当局・社内で経路が違う | 可能 |
粒度と分岐点の2つは、ロット管理とシリアル管理の選択およびトレーサビリティ要件の3軸と一体で決めます。ここを個別に決めると、粒度は細かいのに分岐点が粗く、結局同一日製造分がまとめて対象になる、という状態が起こります。
よくある実装の失敗3つ
失敗1：取消・訂正を物理削除で実装する。 投入ミスの訂正を、消費イベントのレコード削除で実装している実装は少なくありません。これをやると監査証跡が成立せず、規制産業では即座に指摘対象になります。訂正は必ず「取消フラグを立てた元レコード＋訂正レコード」の2行で表現します。監査証跡の設計と同じ原則です。
失敗2：ERPの在庫キーとMESのロットキーを別体系にする。 MES側で LOT-20260825-001、ERP側で 0000123456 という別のキーを持ち、変換テーブルで橋渡しする設計は、変換テーブルが壊れた瞬間に系譜が切れます。どちらかを正とし、もう一方は参照キーとして保持する形にします。
失敗3：照会性能を稼働後に確認する。 系譜の照会は木構造の探索なので、階層が深いと応答が急激に遅くなります。1完成品あたり部品100点、3階層なら探索対象は理論上100万件規模になります。要件定義の段階で「最悪ケースの構成で何秒か」を実データ量で測る必要があります。PoCで測るべき項目の代表格です。
製品による実装差はどこに出るか
系譜機能は「ある／ない」ではほぼ差がつきません。差が出るのは次の3点です。
- バルク／連続工程の扱い：ディスクリート系のMESは、タンクや連続ラインの系譜を標準機能で持たないことがあります。プロセス産業向け製品（ISA-88のレシピモデルを前提とするもの）は、チャージ単位の系譜を標準で持ちます。
- 照会UIの分岐表示：1つの完成品から複数の材料ロットへ分岐する木を、画面で追えるか。テキストのリストしか出ない製品もあります。
- 外部提出フォーマット：顧客や当局へ提出する形式（CSV、PDF、あるいはデジタルプロダクトパスポート向けのデータ）を標準で出せるか。ここは近年、DPPの出力要件として重みが増しています。
選定時は、自社の最も複雑な製品1つを持ち込み、その系譜をデモ環境で実際に組んでもらうのが最も確実です。カタログの機能一覧では、上の3点は判別できません。
よくある質問
系譜と「トレーサビリティ」は同じ意味ですか？
重なりますが、同じではありません。トレーサビリティは「追える状態」という要求、系譜（ジェネアロジー）はその要求を満たすためのデータ構造を指します。実務では、トレーサビリティ要件を粒度・範囲・応答時間で定義したうえで、それを満たす系譜モデルを設計する、という順序になります。要件のほうから決めないと、記録量だけが増えて必要な絞り込みができない状態になります。
既存のExcel記録から系譜を移行できますか？
過去分の完全な移行は、多くの場合できません。Excelの記録は「投入した」という事実は残っていても、投入時刻・数量・投入者のいずれかが欠けていることが大半で、消費イベントの形に正規化できないためです。現実的な進め方は、移行時点を境に新規分は完全な系譜を取り、過去分は参照専用のアーカイブとして別に保持することです。この二層構成であることを、社内の品質部門と事前に合意しておく必要があります。合意なく進めると、稼働後に「過去分も追えるはずだった」という認識違いが表面化します。
系譜のデータはどれくらいの量になりますか？
消費イベントは「1工程あたり投入品目数×ロット分割回数」で増えます。部品50点の組立を1日1,000台流す工程なら、消費イベントだけで1日5万行、年間で1,800万行程度が目安です（推測ではなく単純な積算値です）。これ自体は現代のRDBで問題になる規模ではありませんが、5年・10年の保持要求と、そこに測定値や画像が付随すると容量は桁で変わります。容量を押し上げるのはイベントの行数ではなく付随データなので、保持期間はイベントと付随データで分けて設計します。
