ロット・バッチのトレーサビリティでリコールに備える基幹システム

月曜の午前9時42分。大阪の病院薬局から品質デスクに電話が入ります。ロット2403-B-117のバイアル1本で反応が起きたという連絡です。1時間以内に、そのロットを載せて倉庫を出たすべての出荷を知りたいと求められます。どこへ行き、いくつ出荷し、いつ出荷したか。

もし担当者がスプレッドシートを開いてスクロールを始めていたら、その時点で負けは確定しています。保健行政は完全な引き渡しの連鎖を、しかも速やかに求めます。顧客は安心を求めます。経営陣はコストの封じ込めを求めます。制御された事象と公の危機の差は、あなたの記録が一つの問いに即座に答えられるかどうかにかかっています。どのロットが、どの場所に、どの注文に紐づいているのか。

基幹システムがその存在意義を証明するのは、この瞬間です。デモのなかでも、パンフレットのなかでもありません。月曜の朝、何かが起きたその時にこそです。

トレーサビリティがいま日本の経営課題である理由

日本の製造業は、複数の方向から同時にトレーサビリティの圧力を受けています。2025年のレガシーシステムの崖が、ベンダーがサポートを終了したシステムからの移行を迫り、その後継はかつての旧システム以上のことを求められています。適格請求書書方式と、より広いデジタルトランスフォーメーションの潮流は、財務、在庫、営業が一つの信頼できる元帳を共有することを意味します。そして消費者の信頼、得るのは難しく失うのはやすく、製品がどこから来てどこへ行ったかを証明できるかどうかにかかっています。

リコールの計算は容赦ありません。マーシュによれば、単一の製品リコールによる平均的な損害額は約150万米ドル（約2億2,000万円）を超え、しばしばはるかに高額に達する一方で、一般賠償責任保険の補償上限はリコール費用に届かないことが少なくありません。リコールがかかる費用と、保険が補填する額との差は、往々にして貸借対照表にのります。その差を縮めるのがスピードです。正しいロットだけに絞り込み、数時間で解決したリコールは、何日にもわたり無関係な在庫まで巻き込んで長引くリコールのごく一部の費用で済みます。

日本の規制当局も期待を引き上げています。農林水産省は食品トレーサビリティシステム導入のための公式の手引きを公表しており、食品衛生法の下では食品製造業者に対するHACCPが義務化されています。もはや求められるのは「よい記録を残すこと」ではありません。「ロットごとに、証拠とともに、求められた時にすぐ提示すること」です。ロットをネイティブに扱う基幹システムは、その要求を現場のパニックから、ただの照会へと変えます。

システム内でロットトレーサビリティが実際に意味すること

トレーサビリティは、貼るラベルではありません。データ構造です。正しく構えられたERPでは、ロット管理対象の製品の数量は、すべて、独自の識別子とライフサイクルと日付を持つロット記録に紐づいています。構築されている内容に基づいて、その記録が何を保持するかを具体的に見ていきましょう。

それぞれのロットは、会社内で一意のロット番号、賞味期限と製造日または受入日、そしてライフサイクルステータスを持ちます。ステータスは飾りではありません。ピック可否を制御します。ACTIVEなロットはピックも出荷も可能です。QUARANTINEDなロットは品質保持中です。BLOCKEDなロットは動かせません。EXPIREDなロットは期限を過ぎて凍結されています。倉庫担当者が在庫をピックする時、システムは先に切れるものから先に出すFEFO（First-Expired-First-Out）で動かせます。それだけで、棚で息絶える在庫による黙示録的なマージン低下と廃棄ロスを減らせます。

ロット番号は誰かが書式を覚えていることに依存しません。担当者が空欄のままにすると、システムは製品コード、日付、連番からなる読みやすいパターンに従い、製品ごとに任意の接頭辞を付けてロット番号を自動採番します。その番号は社内で一意でなければならず、システムは重複を拒否します。これは響き以上に重要です。重複した、あるいはいい加減なロット番号は、どの物理的なバッチを指しているのか誰にも分からなくなり、リコールが本来の範囲を超えて広がる最も一般的な原因です。

それぞれのロットは自由入力のメモ欄も持ちます。品質所見、仕入先参照、検査担当者のイニシャル、不適合チケット番号。監査人がロット117をなぜ出荷可としたか問うた時、その答えは誰かの受信箱ではなく、ロットそのものにあります。

ソフトウェアで再現するリコールのシナリオ

東大阪にある精密部品と試薬のメーカーを思い浮かべてください。従業員約70名、関西から東京にかけての医療機器の組立メーカー向けに部品と検査キットを供給しています。約1,800品目の有効SKUのうち、賞味期限を伴うか規制対象の原料を扱うため約600品目がロット管理対象です。

ある顧客が不具合品を指摘します。品質責任者が基幹システムでロット記録を開き、ロット番号を入力すると、数秒で製造日、賞味期限、ステータス、メモが表示されます。彼はステータスを一つ変更し、そのロットを隔離します。その瞬間から、倉庫はそのロットの1個たりとも出荷できません。人の確認によるミスが起きうる余地はほぼゼロに縮みます。

続いてより難しい問いです。それはどこへ行ったのか。在庫残高がロットを参照しているため、チームはどの倉庫の棚にまだ在庫があるか、どの出荷がそのロットを載せて倉庫を出ていったかを追跡できます。影響を受ける売上注文を引き出し、該当する顧客に連絡し、返品を手配します。ロット118はリコールしません。製品ライン全体もリコールしません。厳密に117に紐づく個数だけをリコールします。

これが絞り込んだリコールと、無差別なリコールの差です。無差別なリコールは正常な在庫を棚から引き抜き、何も悪くしていない顧客を激怒させ、もともと危険になかった売上を破壊します。ロットレベルの記録によって可能になる絞り込んだリコールは、費用のごく一部で済み、何年もかけて築いた関係を守ります。

保健所から電話が来た時、チームはロット番号、製品、日付、ステータスを日付範囲やステータスで絞り込んでロットデータをCSVに出力し、整った完全な記録を送付します。再入力も、突合作業も要りません。監査証跡は、システムそのものです。

スプレッドシートより組み込みの統制が勝る理由

スプレッドシートは、まさにトレーサビリティが重要になる条件下で破綻します。基幹システムが、スプレッドシートにはできないことを実行するのは次の点です。

入力時に不正データをブロックします。製品がロット管理必須と設定されていれば、ロットなしでは在庫を作れません。製品が賞味期限管理を必須としていれば、賞味期限は必須項目となり、システムは製造日より前の期限や過去の期限を拒否します。これらは助言ではありません。明確な停止です。スプレッドシートは何でも入力できます。システムは誤ったものを拒絶します。

気づかれない上書きを防ぎます。すべてのロット記録はバージョン番号を持ち、更新は楽観的ロックで照合されます。二人が同じロットを編集した場合、二番目の保存は明確な競合として拒否されます。どの変更が勝ち、それがいつだったかを常に把握できます。記録の完全性が訴訟の帰趨を決めかねないリコール調査では、それが意味を持ちます。

破壊的なクリーンアップを止めます。手持ち在庫が残っているロットは削除できません。システムはまず残高を確認し、拒否します。現場に残っている在庫の証跡を、誤って消し去ることはできません。

会社ごとのデータ分離を保ちます。共通の基盤で動く複数会社のグループであっても、ある会社のロットが別の会社に漏れ出すことは決してありません。あなたが照会するトレーサビリティは、あくまで自社の事業のためのトレーサビリティであり、それ以外の何物でもありません。

会社のタイムゾーンで語ります。製造日も賞味期限も、サーバーの既定値ではなく、日本の会社のタイムゾーンで解決されます。監査人がロット117をいつ製造したか問うた時、答えはスタッフが実際に過ごした現地の日付であり、世界標準時の不都合な産物ではありません。

正直な限界と、それでもなお有利である理由

信頼できるシステムは、まだできないことを正直に伝えます。正直さは売れ、そして精査に耐える唯一のものでもあります。

ロット記録は、まだ不変の監査ログテーブルではありません。代わりに用意されているのは、承認ワークフローの履歴と、バージョン管理されたロット記録であり、この二つが組み合わさって誰が何をいつ変更したかを捉えます。ほとんどのリコールや品質管理の目的にはそれで十分であり、紙の記録よりはるかに優れています。もし業界が専用の追記専用監査ログを求めるのであれば、選定の過程で確認すべきギャップとして扱ってください。

ロットデータは、まだ会計元帳に自動転記されません。在庫評価には、今も手動の仕訳が必要です。今日、仕訳を自動生成するのは売上請求書、仕入請求書、経費精算の三つだけです。したがって、ロットが廃棄や評価損で切り下げられた時、在庫側はシステム上で追跡されますが、元帳側は人間が意図的に確認した仕訳となります。これにより、償却の判断に人間が介在し続け、ワンクリックではないものの、保守的で弁明可能な運用が保たれます。

能力計画と工程スケジューリングは構築されていません。システムは製造実行システムを介さず、在庫を通じてロットを追跡します。もしリコールのリスクが完成品在庫ではなく現場（工場）にあり、その補完として製造実行レイヤーの追加が必要になります。

これらの限界は、核心を変えません。月曜の朝に電話が鳴った時、問われるのは決して「製造実行システムがあるか」ではありません。「ロットはどこにあるか」です。基幹システムは今日、スプレッドシートなしで、それに答えます。

他の業務とのつながり

ロットトレーサビリティは単独では立ちません。連動する一つの筋肉であり、他の筋肉とともに働くとき価値が複利的に高まります。

ロットトレーサビリティを伴う在庫管理は、最も自然な組み合わせです。移動、倉庫間移動、出荷、出荷バッチはすべてロットの文脈を保持するため、リコール時に必要な追跡は、倉庫が普段のピックや出荷に使ったものと同じになります。緊急用の並行記録を保守する必要はありません。業務の記録が、そのまま緊急時の記録です。

承認ワークフローがその上に重なります。ロットがACTIVEからQUARANTINEDへ移る時、そのステータス変更を自由な編集ではなく、依頼者と承認者とタイムスタンプを伴う統制された承認のなかで行えます。規制業界では、その鎖が、弁明可能な行為と説明不能な行為の境目になります。

受注から入金までの流れが、ロットを顧客に結びます。見積は受注に、受注は出荷を呼び、出荷はロットを載せ、請求書が続きます。だからロット117を順方向に追うと、倉庫の棚ではなく、顧客と請求書に行き着きます。それが原材料から回収された売上までの輪を閉じます。

そして一つの基幹システムだからこそ、ロット管理を駆動するのと同じ製品マスタが、購買、製造の部品表、営業を駆動します。製品のロット要件の変更は、どこであろうと正しく波及します。つき合わせるための第二のリストは存在しません。

よくある質問

これまでなくてもやってこられました。なぜいま変えるのですか？

これまで切り抜けられたのは、電話が稀だったことと、誰かの記憶が支えていたからです。2025年のレガシーシステムの崖は、その二つのクッションをともに取り除きます。旧システムは消えゆき、知識を頭に抱えてきた担当者は、後継者育成の波のなかで引退してきます。リスクは理論上のものではなく、人口動態と技術の、同時に迫る問題です。

移行は現在のロット記録を壊しませんか？

きれいな移行は、既存のロット番号を新しい記録にマッピングし、日付とステータスを保ったまま取り込みます。システムが一意性を担保し日付を検証するため、移行そのものがデータ品質の監査になります。不良や重複のロット番号は、リコール中には対応できないインポート時に、冷静に修正できる形で浮かび上がります。

従業員70名の会社でも手が届きますか？

これは正しい問いであり、答えは多くの経営者が想定するより有利です。Kikan System のようなクラウドの基幹システムは費用を予測可能なサブスクリプションとして平準化し、オンプレミスのハードウェアがもたらす資本的な衝撃を避け、いくつかのバラバラな道具を一つにまとめます。最大2ユーザーまで無料、クレジットカード不要で始められるため、1円をコミットする前に、自社のデータでロットの流れを証明できます。

自社の業界固有のルールにはどう対応しますか？

食品、医薬品、化学、電子部品、医療機器は、それぞれ独自のロットと賞味期限のルールを持ちます。柔軟なステータスモデル、メモ欄、製品ごとのロットと賞味期限の切り替えにより、ほとんどのルールをカスタム開発なしで表現できます。認定された保管基準や業界固有の法定保存が必要な場合は、その範囲を直接にご確認ください。完成品のロット追跡を超える部分は、ロードマップの対話として扱ってください。

重要なポイントは、リコールが試すのは勇気ではなくデータだ、ということです。低い費用で生き残るのは、電話が鳴る前から、すべてのロットがどこにあり、どこへ行き、誰が触れたかを基幹システムが把握している会社です。

トレーサビリティを非常時の手段ではなく、普段の姿に

最も安上がりなリコールは、実際に不良であるロットだけに厳密に限定されたものです。最速の対応は、記録を一から組み立てる必要がないものです。最も弁明できる監査は、システムが通常の業務のなかで生み出したものです。

これらは偶然には起きません。ロットトレーサビリティが基幹システムのネイティブな能力であり、在庫、承認、受注から入金の流れに織り込まれ、不正データが生まれる前に止める統制と、精査に耐える完全性を持つ時に初めて起きます。

Kikan System は、ロットとバッチのトレーサビリティを基幹のなかに組み込んでいます。自動採番される一意のロット番号、先に切れるものから出すFEFO、隔離とブロックのステータス、日付と一意性の検証、バージョン管理された記録、そして監査人や顧客に問われた瞬間のためのきれいなCSV出力。会社ごとのデータは完全に分離され、日付は現地のタイムゾーンで解決され、手持ち在庫のあるロットは削除できません。

まずは2ユーザーまで、カード不要の無料プランで、ご自身の在庫でロットの流れを証明してください。(/#get-started)(/#get-started)から始め、(/#pricing)(/#pricing)でプランをご確認ください。月曜の朝の電話が来た時、あなたはすでに答えを持っています。