小規模メーカー向けバッチトレーサビリティアプリ入門

製造現場でバッチ記録が途切れる理由

バッチ記録は、ミキサーの横に置いた紙、受け入れ時の納品書、オフィスのスプレッドシートから始まることがよくあります。個別に見れば、どの記録にも意味があります。ところが、まとめて見ると抜けが生まれます。

ある作業員はロット番号を手書きし、別の作業員はクリップボードで温度検査を記録します。購買担当は仕入先の情報をメールのスレッドに残し、出荷担当は顧客の注文を別のシステムに記録します。その間を口頭の引き継ぎが埋めますが、引き継ぎを受けた人が休んだり、内容を別の形で覚えていたりすると、情報が途切れてしまいます。

手書きのメモには別の問題もあります。にじんだ数字によって、ロット「L24071」が「L24017」に見えるかもしれません。スプレッドシートの行が誤ったタブに入ることもあります。こうした身近なミスがあると、急いで答えを探すときに製造ロットの追跡に時間がかかります。

顧客から問題が報告されたら、スタッフは製品を前後両方向に追跡する必要があります。どの完成品バッチがいつ顧客に出荷されたのか、そのバッチにどの原材料や部材が使われたのか、製造と品質検査を誰が担当したのか、同じバッチの在庫が倉庫に残っているのか、ほかの顧客に出荷されたのかを確認しなければなりません。

情報が複数の場所にあると、単純なクレーム対応が調査作業になります。誰かが出荷書類を確認し、製造責任者に電話し、古いスプレッドシートを開き、日付と仕入先からの納品を照合します。数時間かかることもあり、最も忙しいタイミングでスタッフを製造から離すことになります。

在庫を出荷した後は、コストがさらに増えます。仕入先と出荷の情報が明確に追跡できなければ、影響を受けたロットを絞り込めず、似た製品を購入したすべての顧客に連絡したり、在庫を保留したりすることになります。これは廃棄、売上の損失、気まずい顧客対応につながります。影響を受けたバッチの在庫を見落とすと、さらに深刻です。

バッチトレーサビリティアプリは、1つのバッチIDを中心に記録をまとめます。現場のスタッフは作業中にそのIDをスキャンまたは入力し、検査結果を追加し、材料の使用を記録し、次の引き継ぎを確認できます。問題が起きた後に記録を再構成するのではなく、その日の実際の作業を反映した記録になります。

バッチ記録に含めるべき情報

バッチ、つまりロットとは、同じ条件で一緒に受け入れたり製造したりした製品のまとまりです。仕入先から届いた小麦粉1パレット、午前中に充填した500本のボトル、1回の機械シフトで製造した部品のまとまりなどが該当します。定義はスプレッドシートの都合ではなく、工場の作業方法に合わせてください。

各バッチには固有のIDが必要です。受け入れ記録、製造画面、検査票、ラベル、出荷記録のすべてで、そのIDを確認できるようにします。バッチトレーサビリティアプリは、1つのIDを検索するだけで複数のファイルを開かずに全体の履歴を見られるときに力を発揮します。

記録には、仕入先からの納品、材料ロット、製造工程、品質検査、顧客への出荷をつなげます。仕入先名、発注番号、到着日、受け入れ数量を記録します。材料ロットには、仕入先ロット番号、必要に応じた使用期限、保管場所も紐づけます。製造工程には、完成品ロット番号、レシピや工程、ラインまたは機械、製造数量を含めます。品質記録には、検査や試験の内容、結果、必要な測定値、不合格後の対応を残します。出荷記録には、顧客、出荷日、出荷数量、工場から出た完成品ロットを記録します。

長いメモより、記録同士のつながりが重要です。顧客から1箱の問題が報告されたら、スタッフはその出荷を特定し、完成品ロットを確認し、その工程で使われたすべての材料ロットを調べられる必要があります。同じ完成品ロットがほかにどこへ出荷されたかも確認できなければなりません。

すべての入力には、日付と時刻、入力したスタッフ、現在のステータスという3つの基本情報が必要です。日付があれば、出来事を正しい順序に並べられます。担当者名があれば、測定値が不自然なときに管理者が確認できます。ステータスによって、バッチが「受け入れ済み」「検査待ち」「承認済み」「保留」「製造使用済み」「出荷済み」「完了」のどの状態かを全員が把握できます。

ステータスはわかりやすく、数を絞ってください。「確認待ち」「確認中」「承認待ち」のように、同じ意味の選択肢をいくつも用意すると、現場が迷います。明確な「保留」ステータスがあれば、問題が解決する前に材料が移動するのを防げます。

記録の証拠になる場合だけ添付ファイルを追加します。破損した納品ラベルの写真、仕入先の証明書、署名済みの検査票などは、バッチに添付できます。メールの受信トレイに埋もれさせず、ロットに直接紐づけてください。

たとえば、ソースメーカーが仕入先ロットT-184のトマトを受け入れたとします。チームは納品を記録し、T-184を完成品バッチS-0624に使用し、加熱温度を記録し、S-0624を2社の顧客に出荷します。この一連の記録があれば、仕入先や顧客から電話を受けたときに、メーカーはすぐ答えられます。

受け入れから製造までロット番号を設定する

ロット番号は、スタッフが作業を止めずに読めて、口頭で伝えられ、入力できて初めて役に立ちます。短く一貫した形式にしてください。受け入れ材料なら、YYMMDD-MAT-###の形式が実用的です。たとえば250614-FLR-002なら、中央のコードが小麦粉を示し、最後の番号で同じ日の複数の納品を区別できます。

スタッフが複数のルールを調べないと使えないコードは避けます。番号は、1つの物理的な納品または定義済みの製造工程を識別できれば十分です。その他の情報は、バッチトレーサビリティアプリがそのシンプルなラベルの裏側に保存できます。

受け入れ時には、材料を保管場所や現場へ移す前に材料ロットの記録を作成します。社内の材料ロット番号、仕入先ロット番号、仕入先名、納品日、発注情報、材料名、受け入れ数量、単位、必要に応じた使用期限、受け入れ結果として「受け入れ」「保留」「拒否」を記録します。

たとえば、パン工場が6月14日に小麦粉を2回受け入れたとします。2つの納品が同じ仕入先から届いても、それぞれに社内ロット番号を付けます。後で一方の仕入先ロットがクレームの原因になった場合、そのロットを使ったすべての製造バッチを見つけられます。

混ぜる、切る、加熱する、包装する、組み立てるといった作業を始める前に、製造バッチを作成します。250614-COOKIE-01のように、その工程専用の番号を付けます。記録には、製品名、計画数量、製造日、シフト、作業を開始した担当者を表示します。

次に、使用した材料ロットを製造バッチに追加します。新しい説明を手入力するのではなく、受け入れ済み在庫の一覧からロットを選択してください。これにより、「小麦粉25kg」と「25 kg flour」のような表記の違いで履歴が別々の記録に分かれるのを防げます。

1つの製造バッチで複数の材料ロットを使うこともあります。小麦粉の袋を使い切って別の袋を開けたら、両方のロットと、それぞれの使用量を記録します。回収が必要になったとき、その日の生産物全体を疑うのではなく、影響を受けた完成品だけを絞り込めます。

受け入れ画面と製造画面は、現場のタブレットで簡単に使えるようにします。Koder.aiなら、チャットベースのワークフローでスタッフを案内しながら、ロットの関係を1つの検索可能な記録にまとめられます。

日々の作業を中心にワークフローを作る

バッチトレーサビリティアプリは、スタッフに作業を事務用語へ置き換えさせるのではなく、普段の順序に沿って動くときに定着します。納品が届き、材料が製造へ移り、検査が行われ、完成品が包装され、製品が出荷される流れを確認してください。アプリはその引き継ぎを中心に設計します。

一般的なワークフローでは、まず受け入れ担当者が仕入先、納品日、仕入先ロット番号、数量、保管場所を記録します。製造担当者は使用する材料ロットを選び、製造バッチを開始します。責任者は必要な検査を記録し、バッチを次へ進めてよいか判断します。包装担当者は完成品バッチ、包装日、包装数量を確認します。出荷担当者はバッチを顧客注文と出荷番号に紐づけます。

引き継ぎごとに記録と固定項目を用意します。作業員は一覧から仕入先を選び、ロット番号をスキャンまたは入力し、検査結果を選び、数量を追加できるようにします。破損したパレットや温度異常など、通常と異なる出来事には自由記述が役立ちます。ただし、後で検索したい情報を自由記述だけに入れないでください。

画面は短くします。ラインや包装台の横にいる人が、現在の作業、数個の必須項目、明確な保存操作だけを見られるようにします。作業が複数の時間帯に分かれるなら、長いフォームを小さなステップに分けます。朝に製造を開始し、検査後に品質担当者が結果を追加し、午後に出荷担当者が出荷記録を完了できます。

スタッフが実際に使う言葉をラベルに使います。「仕入先ロット」「自社バッチ」「確認者」「包装可」のような表示は、「参照」や「ステータス」のような曖昧な表示より混乱が少なくなります。現在の作業に必要な項目だけを表示してください。出荷画面を開くたびに、受け入れ情報まで表示する必要はありません。

アプリを使い始める前に、担当範囲を決めます。受け入れ担当者は納品記録を作成し、製造担当者は製造数量を追加し、品質担当者は検査を承認または拒否し、出荷担当者は出荷情報を紐づけます。管理者はミスを修正できるようにしますが、承認後の変更には理由を必須にして、なぜ記録が変わったのかを確認できるようにします。

Koder.aiなら、チャットを使ってこのような流れを小規模メーカー向けに作り、スタッフが使いながら画面を調整できます。まずは1つの製品ラインと1つのシフトから始めます。作業員が現場を離れずに1分以内で記録を更新できるなら、プロセスは定着しやすくなります。

バッチを手順に沿って記録する

スタッフに必要なのは、シフトの最後にまとめて入力するフォームではなく、作業に沿って更新できる記録です。各入力は1、2分で完了し、誰がいつ入力し、どのバッチに影響するのかを表示します。バッチトレーサビリティアプリは、ラインの横でタブレットやスマートフォンから使えると効果的です。

1. 材料が届いたら受け入れ記録を作成します。仕入先、納品日、仕入先ロット番号、社内ロット番号、数量、必要に応じて使用期限を記録します。破損した箱や証明書の不足など、簡単な受け入れ検査も記録します。検査に不合格なら、誰も使う前にロットを保留にします。

2. 作業開始時に製造バッチを開きます。担当者は製品、計画数量、ラインまたは作業場所、使用する材料ロットを選びます。アプリは、期限切れ、ブロック済み、在庫切れのロットを選べないようにします。これにより、何を製造したかはわかっても、どの原材料や部品を使ったかがわからないという、よくある追跡の抜けを防げます。

3. 作業の進行に合わせて品質結果を追加します。「合格」「不合格」「保留」のような簡単な選択肢を使い、測定値やメモは必要な場合だけ入力します。食品メーカーなら加熱温度や包装重量、部品メーカーなら寸法や外観検査の結果を記録します。不合格になったバッチは、責任者が判断を記録するまで次の工程へ進めないようにします。

4. バッチを完了し、出荷注文に紐づけます。完成数量、廃棄数量、最終承認結果、使用した包装ロットを記録します。倉庫担当者が注文をピッキングするときは、その出荷に含めた完成バッチを選択します。顧客注文、出荷日、配送会社の番号、届け先をバッチ履歴の横に表示します。

修正履歴は見える状態にします。ロット番号を間違えて入力した場合、元の値を上書きするのではなく、理由を付けて修正できるようにします。顧客クレームや回収の際、スタッフは紙の記録を探さなくても、出荷された製品から完成品バッチ、品質検査、仕入先ロットまで追跡できます。

Koder.aiなら、メーカー独自の帳票、承認ルール、画面に合わせてこのワークフローを作成できます。将来カスタム拡張が必要になった場合は、ソースコードをエクスポートできます。

1日の製造例

午前7時、パン工場がNorth Millから小麦粉20袋を受け入れます。受け入れ担当のMayaは納品書を確認し、袋数を数え、バッチトレーサビリティアプリに仕入先名、納品日、小麦粉ロットFM-240617を入力します。袋が密封されて乾燥しており、使用期限内だったため、受け入れ検査に合格したことも記録します。

8時15分、パン職人がFM-240617から10袋を開け、種入りパンの午前の製造を始めます。製造バッチSL-0617-Aを作成し、小麦粉ロットとほかの材料を追加します。混ぜる時間、オーブン温度、完成した箱の数48箱も記録します。

昼食後、チームは同じ小麦粉ロットからさらに10袋を使って同じ作業を繰り返します。今回はバッチSL-0617-Bを作成し、44箱を包装します。担当者が包装前に、両方のバッチのパンの重量とラベルの正確さを確認します。担当者は氏名と検査時刻とともに、各バッチに結果を記録します。

午後2時30分、出荷担当者がSL-0617-Aから24箱をGreen Street Shopへ、24箱をRiverside Grocerへ送ります。午後4時には、SL-0617-Bの44箱をRiverside Grocerへ送ります。各出荷記録には、顧客、箱数、出荷時刻、バッチ番号を含めます。

その日の午後、SL-0617-Bの保存サンプル検査が不合格になります。パンの水分量が工場の基準を外れていたためです。責任者がそのバッチ記録を開くと、小麦粉ロット、検査結果、出荷履歴を確認できます。アプリには、Riverside Grocerが影響を受けたバッチから44箱すべてを受け取ったことが表示されます。

次に責任者が小麦粉ロットFM-240617を検索します。同じ納品を使ったため、SL-0617-Aも検索結果に表示されます。Green Street ShopとRiverside Grocerには、正確な箱数とバッチ番号を伝えて連絡できます。スタッフは残りの在庫を保留し、不合格の検査を記録し、シフトが終わる前に顧客への連絡内容を残せます。

全員が、作業が発生した時点で小さな操作を1つずつ記録しています。後から紙のメモや記憶、メッセージのやり取りを使って1日を再構成する必要はありません。

トレーサビリティ記録の信頼性を下げるミス

バッチトレーサビリティアプリは、忙しいシフト中でも記録を信頼できるときに役立ちます。ロット名のスペルミスや、承認前に出荷を記録するといった小さな抜けが、簡単な回収確認を何時間もの手作業に変えてしまいます。

自由入力は、こうした抜けの大きな原因です。作業員が実際のロットを選ばず「Blue cap mix」と入力すると、その作業を受け入れ記録、品質検査、顧客注文に確実につなげられません。画面には、存在し、その工程で使用できるロットだけを表示します。

入力時点で制御する

現場でスタッフが使うフォームにルールを組み込みます。長いロットコードを覚えてもらうより、明確な選択リストを使うほうが速く、名称の違いによって1つのバッチが複数の記録に分かれるのも防げます。

実用的な設定には、次のチェックが含まれます。

• スタッフは製品名を入力せず、受け入れまたは製造の一覧からロットを選択する。
• すでに存在する番号を新しいロット番号として登録できない。
• バッチが保留状態のときは出荷を確定できない。
• 数量、検査結果、仕入先情報を修正するときは理由を入力する。

保留は、スタッフが無視できる警告を表示するだけでは不十分です。出荷ワークフローそのものを止めなければなりません。たとえば、品質責任者が水分検査の不合格を受けてロットL-2047を保留にしたとします。倉庫チームが注文を準備するときにもその状態を確認でき、権限を持つ担当者が解除するまで出荷ボタンを使えないようにします。

スプレッドシートを分けて管理することも、よくある問題です。受け入れ担当者が1つのファイルでロット番号を付け、製造担当者が別のファイルで同じ番号を作ることがあります。共有ロット台帳があれば、この衝突を防げます。ロットを作成する場所をアプリ内の1か所にまとめ、受け入れ、製造、品質、出荷が同じ記録を使うようにします。

修正履歴を残す

入力ミスは誰にでも起こります。アプリは、履歴を消さずに誤りを直せるようにします。作業員が記録した重量を240kgから204kgへ変更した場合は、両方の値、修正理由、担当者名、変更時刻を保存します。

この記録は、スタッフと会社を守ります。管理者は、単なる入力ミスを直したのか、品質問題の後に結果を変更したのかを確認できます。権限はシンプルにします。現場では通常の修正を許可し、出荷済みロット、不合格の検査、完了済みの出荷を変更するときだけ承認を必要にします。

システムを信頼する前の簡単なチェック

スタッフが通常のシフト中に紙のメモを探したり何人もの人に確認したりせず、回収に関する質問へすぐ答えられるとき、トレーサビリティアプリは信頼を得ます。正式な記録の中心にする前に、実際の記録でテストしてください。

先週の完成品ロットを1つ選び、現場の担当者にロット番号で検索してもらいます。数秒で記録が開き、ステータス、製造日、材料または部品、検査、出荷履歴が表示されるはずです。特別なフィルターや正確なスペルが必要なら、まず検索機能を直します。

次に、同じロットをさかのぼって追跡します。責任者は、その工程で使ったすべての材料について、仕入先ロットを確認できる必要があります。仕入先から届いた1つのロットに問題があると報告されたとき、全製造品をあいまいに検索するのではなく、影響を受ける可能性のある完成品バッチを短い一覧にできなければなりません。

出荷と保留の手順をテストする

最近の顧客への出荷を開きます。出荷記録には、その顧客向けに積載したすべての完成品バッチと、必要に応じてバッチごとの数量を記載します。「50ケース出荷」のような出荷メモだけでは、対象を絞った回収に対応できません。

品質検査の不合格も練習します。たとえば、バッチPB-2406-18の封かん検査を不合格として記録します。アプリはそのバッチを保留にし、理由を表示し、権限を持つ担当者が出荷を解除または廃棄するまで、出荷に追加できないようにします。現場からロットを検索したときにも、保留が表示されるか確認してください。

次の短いリストを使って確認します。

• スタッフが助けを借りずにロット番号でバッチを検索できる。
• 各出荷に含まれるバッチが特定できる。
• 各完成品バッチから、使用した仕入先ロットへ戻れる。
• 品質検査が不合格になると、バッチのステータスが保留になる。
• 管理者が、誰が何をいつ編集したか確認できる。

画面だけでなく記録の履歴を確認する

2人のスタッフに、別々の端末から同じバッチを更新してもらいます。アプリが両方の変更を正しい順序で保持し、それぞれの編集についてユーザーと時刻を記録することを確認します。監査履歴は、以前の入力を黙って置き換えずに残す必要があります。

分割されたバッチ、数量の修正、返品された出荷、入力を間違えた仕入先ロットなど、日常的な例外も確認します。スタッフには、元の履歴を見える状態に保つ明確な修正方法が必要です。異常が起きたときにアプリを使わず別の方法で処理するなら、最も必要な場面で製造ロットの追跡が機能しなくなります。

小さなテストで、足りない項目やわかりにくい手順が見つかることがあります。材料を受け入れる人、製造を行う人、製品を検査する人、注文を出荷する人と一緒に問題を直してください。記録が信頼できる状態を保てるかどうかは、日常的に使う人たちにかかっています。

小さく実用的なバージョンから始める

受け入れから出荷までの流れが明確な1つの製品ラインから始めます。チームが頻繁に製造し、材料や部品の数が管理しやすい製品を選んでください。小規模なバッチトレーサビリティアプリは、すべての製品、倉庫の場所、例外を追加する前に、忙しいシフト中でもスタッフが記録を入力するかを確認するものです。

回収に関する質問へ答えるために必要な記録だけを作ります。食品メーカーなら、受け入れ時に小麦粉の仕入先ロットを記録し、混合作業の開始時に製造ロットを割り当て、焼成後に品質検査を記録し、そのロットを各顧客への出荷に紐づけます。この流れで、製造ロットの追跡を試すのに十分な最初の仕組みになります。

納品を受ける人、製造を行う人、バッチを検査する人、注文を包装する人に、通常の作業中にアプリを使ってもらいます。どこで手が止まり、紙に手を伸ばすかを観察します。誰も使わない項目は作業の負担になり、後で空欄の記録につながります。

最初のバージョンでは、次の4つの操作に集中します。

• 仕入先からの納品を受け入れ、ロット番号を記録する。
• 製造バッチを作成し、使用した材料を紐づける。
• 担当者と時刻を含めて、品質検査の合否を記録する。
• 各完成品ロットがどの顧客への出荷に含まれるかを確認する。

数日後、完了したバッチをチームと一緒に確認します。出荷番号から始め、完成品ロット、製造記録、仕入先からの納品へ逆向きに検索します。次に仕入先ロットから始め、影響を受けるすべてのバッチと出荷へ前向きに検索します。作業時間も測ってください。数分で完全な経路を見つけられないなら、アプリを拡張する前に記録項目やワークフローを直します。

重複した入力や、「確認済み」「問題なし」のようなあいまいな選択肢を削除します。品質検査記録には、明確な結果、日付と時刻、何を検査したのかを説明するのに十分な情報が必要です。項目を追加するのは、日々の作業や回収時にその答えをどう使うかを説明できる場合だけにします。

Koder.aiなら、チームがチャットで説明しながら、独自のWebアプリやモバイルのトレーサビリティアプリを作れます。計画モードで最初のワークフローを整理し、準備ができたらアプリをデプロイして、現場でテストできます。ソースコードをエクスポートすれば、ニーズが拡大したときにプラットフォーム外で開発を続けることもできます。

最初のリリースを狭い範囲にすると、正直にテストしやすくなります。1つの製品ラインで完全かつ検索可能な記録を作れるようになったら、プロセスを最初から作り直すのではなく、そのパターンを次のラインへ広げてください。