バッチトレーサビリティシステムの構築方法：コード体系・工程紐付け・リコール範囲の確定

バッチトレーサビリティと帳票をめくる運用の違い

「トレーサビリティはある」と答える工場の多くは、紙の移動票と表計算の台帳を保管し、必要になったときに数人で探す運用をとっています。

この運用が問われるのは三つの場面です。顧客からのクレームで説明を求められたとき、監督当局の監査を受けたとき、異常を検知して流れを確定しなければならないとき。いずれも時間の余裕がなく、散在する記録を人が組み直す余裕はありません。

バッチトレーサビリティシステムの違いは三点に集約されます。

• 記録は事後に補うのではなく取得される：バッチ番号は投入・移送・検査の時点で書き込まれ、引き継ぎ後の入力に依存しない
• 関連は人がつなぐのではなくシステムが作る：原料バッチから工程バッチ、完成品バッチへの親子関係が規則により自動生成される
• 照会は双方向：完成品から原料へさかのぼる追跡と、原料からどの完成品に入ったかを引く追跡の両方ができる

実務的な判断基準は一つです。任意の完成品バッチ番号を抜き出し、数分以内に使用した原料バッチの一覧を出せれば、そのトレーサビリティは成立しています。

コード体系の決め方：バッチ・バーコード・容器の三層

トレーサビリティの土台はコード体系です。ここが定まらないと、後段の関連付けはすべてずれます。

一般的な進め方は、コードを三層に分け、各層に一つの役割を持たせる方法です。

コード体系は立ち上げ段階で文書として確定させます。量産開始後に規則を変更すると、履歴データに二つの基準が併存してしまいます。

業界で参照されることの多い体系は二種類あります。ひとつは GS1 体系（GTIN や SSCC などの識別方式を含む）で、小売・物流の工程と接続する場面に向きます。もうひとつは企業独自のコードで、柔軟である一方、社内規格の整備がより重要になります。どちらが適切かは下流の流れによって決まり、共通の答えはありません。

工程の紐付けで残すべき項目

バッチが照会できても、トレーサビリティチェーンが成り立つとは限りません。監査や顧客が見るのは、その連鎖にどの項目が載っているかです。

受け入れられる記録には、一般に次の六種類の情報が含まれます。

• タイムスタンプ：投入・移送・検査・梱包の各時点の正確な時刻
• バッチ関連：当該記録で使用した原料バッチ、産出した半製品または完成品バッチ
• 設備と工程位置：どの設備・どの工程位置で完了したか、設備番号まで追えること
• 作業者：実施者と確認者、権限アカウントとの紐付け
• 工程パラメータ：主要工程の温度・圧力・速度・時間などのプロセス値
• 検査結果：検査項目、判定結論、抜取割合と判定基準

この六種類が、一般に「人・機械・材料・方法・環境」と呼ぶ証拠の基礎になります。どれかが欠けると、対応する問いに答えられません。作業者が欠ければ責任の切り分けが止まり、工程パラメータが欠ければバッチ間の差を問われたときに説明できません。

項目数は監査側と顧客の要求に沿って決めます。多いほどよいわけではなく、項目が増えると現場の取得作業が重くなり、入力漏れによる連鎖の切断を招きます。

トレーサビリティチェーンの完全性をどう検証するか

連鎖で最も困るのは、データが無いことではなく、データがつながっていないことです。

切断が起きやすいのは三か所です。手入力で補う工程、通信機能を持たない旧設備、そしてシフト交代の時間帯です。いずれも監査で抽出されやすい位置でもあります。

完全性の検証は、一般に二つの方法で行います。

• 正逆の突き合わせ：任意の完成品バッチで追跡照会を行い、結果集合が手作業の台帳と一致するか確認する
• 切断の抽出点検：複数のバッチを無作為に抽出し、各段階のタイムスタンプに空きがないか確認する

通信機能を持たない旧設備については、記録用のインタフェースを先に用意し、バッチ情報を人手確認とタイムスタンプ付きでシステムに書き込む方法が一般的です。設備本体を改造するより粒度は粗くなりますが、連鎖は途切れません。監査が求めるのは各段階の自動化ではなく、連鎖が切れないことです。

リコール範囲の確定：バッチから流れへ

リコールはトレーサビリティシステムが最も直接的に試される場面です。

対応は一般に四段階に分かれます。起動、範囲確定、実行追跡、記録の閉止です。

範囲確定の段階が最も力量を問われます。答えるべき問いは二つです。この材料が入った完成品はどれか、その完成品は現在どこにあるか。

これを現場の数え上げではなく短時間で成立させるには、システムに既にある二方向のデータを使います。完成品から原料への追跡と、完成品の原料構成を引く逆方向の照会です。両方向が引けて初めて、範囲を短時間で確定できます。

範囲確定の境界は稼働前に取り決めておきます。バッチ番号で囲むのか時間帯で囲むのか、記録に下流の顧客や物流の行き先を含めるのか、実施状況を誰が更新するのか。これらを方案に書いておかないと、いざというときに「システムは引けるが業務が追いつかない」という差が出ます。

試行段階で一度リコール演習を行うことを勧めます。実際のバッチを一つ選んで全工程を通し、各段階の所要時間と滞留点を記録する方が、機能一覧を眺めるより役に立ちます。

自主点検・監査とレポート出力

トレーサビリティシステムの成果物は照会画面だけではありません。決まった基準で出力するレポートも含まれます。

日常の自主点検では、一般に三点を見ます。バッチ記録の完全率、主要工程パラメータの保存状況、異常バッチの処理記録が閉じているか。これらを週次または月次で回すことで、切断を早めに見つけられます。

外部監査や顧客の工場監査では、決まった形式のデータ提出を求められることが多いため、システム側で次を支える必要があります。

• バッチ番号を指定した工程・検査記録の完全な出力
• 期間を指定したライン単位または設備単位のバッチ一覧の出力
• 出力した記録の項目、タイムスタンプ、作業者情報が可読かつ照合可能であること

レポートのひな形は納品段階で確定し、監査側の基準で一度照合しておきます。監査当日に形式を調整するのは、時間的にもリスク的にも割に合いません。

納品範囲と検収：導入前に取り決めること

トレーサビリティ案件の争点は二か所に集中します。項目を誰が保証するのか、範囲をどう確定するのか。検収前に境界を書面化しておくと、後段の説明が大幅に減ります。

検収項目には次を含めることを勧めます。

• コード体系の確認：三層のコード規則と例外処理（手直し、分割、容器替え）を書面で確定
• 追跡の実測：バッチを無作為抽出して正逆照会を行い、手作業の台帳と項目ごとに照合
• 切断の点検：タイムスタンプの空きを抽出し、補入力の仕組みと責任者を確認
• リコール演習：範囲確定の手順を一度通し、所要時間と滞留点を記録
• 権限と記録：アカウント階層、操作ログ、記録修正の履歴が追えること
• レポート出力：監査基準で一度完全なレポートを出力し、項目と形式が使えることを確認

上流・下流システム（MES の製造指図、ERP の受入など）との接続は、同じ範囲確認の回で扱うことを勧めます。インタフェース項目を一度確定した後の変更は、事前にもう一轮協議するより高くつきます。

納品状態は通常三区分です。既納品（現場で稼働済み）、納品可能（方案と事例がそろい、即時着手可能）、カスタム試行（現場条件に合わせて検証）です。複数ラインや複数拠点の場合は、まず一条のラインか一つの工程区画で立ち上げ、コード体系と取得経路を安定させてから他ラインへ展開することを勧めます。複製コストの中心は、プラットフォームではなくデータ取得点の追加にあります。

トレーサビリティの着地点：説明に要する時間を短くする

バッチトレーサビリティシステムが解くのは「記録を残すかどうか」ではなく、記録がどの形で存在し、どれだけ早く取り出せるかです。コード体系が連鎖を成立させ、工程項目が連鎖を支え、リコール範囲の確定が緊急時の反応速度を決めます。この三点が定まれば、トレーサビリティは台帳の電子化にとどまりません。