製造業の現品票ラベル再発行管理システム導入｜誤貼付を防ぐ設計

現品票が破れた、印字が読めない、プリンタが詰まった。製造現場でラベルを再発行する理由は珍しくありません。しかし、印刷ボタンをもう一度押すだけでは、同じシリアルのラベルが二枚存在し、別のワークに貼られる余地が残ります。製造業で現品票ラベル再発行管理システムを導入するなら、印刷性能より先に「どの現物の識別を回復するのか」「旧ラベルをどう処理したか」「誰が何を確認して再発行したか」を定義する必要があります。本記事は紛失・破損ラベルの置き換えに対象を絞り、工程設計、MES・WMS連携、発注仕様、FAT/SATまで整理します。

現品票の再発行は「もう一枚印刷」ではない

通常発行では、新たに出来上がったワーク、箱、パレットなどへ、確定した品目・ロット・シリアルの表示を初めて与えます。再発行は、すでに識別が付与された現物に対して表示を回復する例外処理です。この違いを画面とデータで分けないと、初回発行の実績を上書きしたり、再発行を通常発行に見せたりできます。監査で「同じ番号のラベルが二枚出た理由」を説明できない設計になります。

GS1のGlobal Traceability Standardは、追跡粒度を品目、ロット、個体で区別し、個体識別ではシリアルを使うと説明しています。ラベルの再印刷は新たな製品個体の生成を意味しません。一方、現物の同一性が失われたときに古い番号を無条件に使い続けるのも危険です。ここを品質部門と工程責任者が判断できるよう、システムは状態・証拠・承認を結ぶべきです。GS1 Global Traceability Standard

一般的なラベル発行の位置付けや機器構成は工場向けラベル発行システムの解説を参照してください。本記事では印字速度やプリンタ選定より、例外時の識別統制を扱います。バーコードの運用基盤はバーコード管理システムの解説と合わせて読むと整理しやすくなります。

再発行を起こす事象を分類する

少なくとも「印字は完了したがラベルを紛失」「貼付済みラベルが破損」「発行途中で紙詰まり」「誤ったデータで印字」「正しいラベルを別ワークに貼った疑い」「箱の組み替えにより物流単位が変わった」を区別します。同じ『再印刷』というボタンにまとめると、シリアルを維持すべき場面と、新しいIDや品質判断を要する場面が混ざります。特に誤貼付の疑いは、表示を戻す前に対象現物と周辺の仕掛品を保留する扱いにします。単なる印字不良なら、元の現物とIDの対応が証明できる限り、同じIDでの代替ラベルを許容する設計が通常は自然です。

同じシリアルで再印刷するか、新しいシリアルを採番するか

判断軸はプリンタ故障の有無ではなく、識別対象の同一性です。製品一個に固有のシリアルを付けた工場で、現物の同一性が製造実績・刻印・治具位置・上流スキャンから確認でき、元のラベルを回収または使用不能にできるなら、原則として同じシリアルを表示し直す案を検討できます。再印刷イベントを別に作り、元の発行と紐付けます。シリアルそのものを増やすと、同じ製品が二個あるかのように下流システムへ見えるためです。

対照的に、外箱やパレットを作り直して物流単位そのものが変わる場合には、新しい物流単位IDが必要なことがあります。GS1のLogistic Label Guidelineでは、SSCCを物流単位の識別キーとして扱います。箱を単に貼り替えたのか、中身を組み替えて別の物流単位を作ったのかは違う判断です。製品シリアル、箱ID、パレットSSCCを一つの「ラベル番号」に統合しないことが重要です。GS1 Logistic Label Guideline

現物が特定できない、二つの候補ワークがある、旧ラベルが回収不能で他の現物への貼付可能性が残る場合は、自動再印刷を停止します。品質部門が現物確認と影響範囲の判断をした後、旧IDの無効化、新IDへの付け替え、仕掛品の再検査などの処置を選びます。これは業界共通の採番ルールではなく、工場の製品特性、客先仕様、規制要求に合わせてSOPとして決める事項です。

この表はシステムが機械的に確定する判定ではありません。現物の同一性が曖昧な場合ほど、承認前のスキャンと隔離を強くします。規制製品では当該制度と顧客固有要求を優先してください。

旧ラベルを「回収・無効・隔離」する動線を作る

再発行の実務で最も見落とされるのは、古いラベルが現場に残ることです。システム上で「無効」としても、紙のバーコードは物理的に読めます。余ったラベルを作業台に置いたまま新ラベルを発行すれば、二枚が別ワークに貼られる可能性を作ります。したがって、印刷前後のSOPには現物の保留、旧ラベルの回収、破棄または隔離、貼付後の照合を含めます。

破損ラベルが貼付済みなら、作業者は対象ワークを保留位置へ移し、剥がしたラベルを再発行票に添付するか、指定の回収容器へ入れます。感熱紙が剥がれない構造なら、旧表示が読めないよう処理し、現物写真と処置記録を残します。ただし、品質や製品安全上、ラベルを剥がすこと自体が許されない場合もあります。その場合は重ね貼りの可否を品質基準で決め、スキャナがどちらを読むか検証しなければなりません。ここを現場判断の暗黙知にしないことが導入の要点です。

紛失時は「旧ラベルなし」の理由を必須入力にし、捜索範囲、最後に確認した場所・時刻、プリンタ排出トレイ、廃棄容器、隣接ワークを点検します。回収不能なら、同じシリアルのラベルを物理的に二枚にできるリスクを受容するのか、別IDへの切り替えを含む品質判定に進むのか、権限者に判断させます。システム側は承認結果が出るまで再印刷キューを送信しません。

MicrosoftのDynamics 365 Supply Chain Managementでは、wave labelの再印刷と無効化を機能として扱い、履歴画面から確認できると説明しています。これは特定製品の実装例であり、すべてのMES/WMSが同じ機能を持つという意味ではありません。ただ、再印刷と無効化を状態として分ける設計の参考になります。Microsoft Learn: Reprint and void wave labels

無効化はデータと現物の二層で考える

データ上の無効化では、旧ラベルIDまたは旧印刷版を「使用不可」と記録し、読み取り時に警告・保留を返します。物理上の無効化では、ラベルを回収して廃棄する、読み取り不能化する、または隔離場所で管理します。片方だけでは不足です。旧紙片が流出すれば、データ側の検知がない端末や手書き工程で通ってしまいます。逆に紙片を回収しても、履歴が上書きされれば後で再発行の正当性を証明できません。

工場ラベル再印刷の承認は、理由と作業者を結び付ける

発行画面には「再印刷」だけを置かず、対象IDをスキャンしてから理由を選び、追加の自由記述を求めます。理由コードは「破損」「紛失」「紙詰まり」「印字不良」「包装変更」「品質処置」など、報告分析で使える粒度にします。全件を「その他」で通せる画面は形だけの管理です。自由記述だけでも入力負担と表記ゆれが大きくなります。

記録する主体は、作業者ID、申請者ID、承認者ID、作業端末、プリンタ、拠点、工程、対象ワーク、対象ラベルの元発行イベントです。時刻は端末の手入力ではなく、サーバーまたは同期された信頼できる時刻で記録し、タイムゾーンを保存・表示で明示します。代理承認を許す場合は代理元と代理実行者を分けます。共有アカウントで承認者だけが残る運用は、調査時に「誰が現物を見たか」を失わせます。

承認を全件に要求すると、軽微な紙詰まりでライン停止が増える場合があります。そこで影響度別に、未貼付が確実な印字不良は作業者＋班長確認、元ラベル紛失や誤貼付疑いは品質部門承認、物流単位変更は倉庫責任者も確認、といったマトリクスを設計します。これは例示であり、固定の法的要件ではありません。承認要否は対象物の識別粒度と出荷段階、客先要求で決めます。権限者が不在の夜勤では、代行権限、保留場所、期限、翌朝レビューをあらかじめ決めます。

再発行履歴に残す最小データ

最低限、イベントID、元ラベルID、対象物ID、再発行後の表示ID、初回発行との関連、理由コード、補足、申請・承認・印刷・貼付・検証の各時刻、作業者と承認者、使用テンプレート版、送信した印字データまたはハッシュ、プリンタ、印刷結果、旧ラベル処置、検証スキャン結果を持たせます。画像を保存する場合は保管期間、個人情報、端末容量を別に設計します。すべてを一つの監査ログ文字列に詰めるのではなく、検索可能な項目として持つ方が事故調査に役立ちます。

Microsoft Learnのwave label説明では、印刷・再印刷のたびにレイアウトから生成した印字文字列を履歴として保存し、以前の文字列で再印刷する場合と詳細を更新して新たに生成する場合を区別しています。この違いは、ラベル再発行でテンプレート版や品目マスタが更新されていたときに重要です。過去と同一表示を再現するのか、現行データで差し替えるのかを暗黙に決めず、品目・顧客・製品表示要件の変更規則と一緒に仕様化します。Microsoft Learn: Wave label printing

バーコードラベル再発行で誤貼付を防ぐスキャン照合

再印刷できたことと、正しい現物に貼れたことは別の完了条件です。新ラベルを印刷した直後に対象ワークとラベルを同一の作業ステーションで読み取り、MESまたはラベル管理サービスが、対象ID、品目、ロット、工程状態、出荷保留状態を突合します。必要に応じて、現物の刻印や上流に残るラベル、治具の位置IDを第二の識別子として使います。最初のラベルが失われているのに「失われたラベルをスキャンせよ」という手順にしないことも重要です。

スキャン成功だけで完了させず、作業者が貼付した後、貼付済みの新ラベルをもう一度読む設計にします。印刷物を机上で読めても、隣の箱に貼ったら意味がありません。連続した二つの箱に同じシリアルを貼ると、二回目の読み取りで重複使用として止めるべきです。バーコード検証機による印字品質確認と、業務データの一致確認は役割が違います。前者は読めるか、後者は正しい物に対応するかを扱います。

GS1 General SpecificationsはGS1バーコードと識別キーの使い方を規定する一次資料です。GS1方式を採用する場合は、GTIN、ロット、シリアルなどのApplication Identifierとデータ構文を対象品に合わせて確認します。独自バーコードなら、GS1準拠をうたわず、自社のID空間と重複防止、読取規則を定義します。GS1 General Specifications

失敗時の画面を先に設計する

スキャンが不一致なら、対象ID、期待値、実測値を表示し、通常の「続行」ボタンを出さず保留へ遷移させます。バーコードが読めない場合は、手入力を無制限に許すより、二人確認と画像または刻印照合の例外ルートを設けます。オフライン端末では、承認だけローカルに済ませてプリントしてしまうと重複発行を検知できません。通信断時の再発行を止めるか、厳密に限定した緊急手順を発動するか、製品リスクとライン停止影響で決めます。緊急手順の結果は復旧後に自動同期・重複検査し、衝突を品質保留にします。

ERP・MES・WMSの境界を決め、二重採番を止める

再発行システムはERP、MES、WMS、QMSのすべてを置き換える必要はありません。重要なのはデータごとの正本を一つにすることです。たとえばERPが品目・受注・顧客マスタ、MESが製造指図・工程進捗・製品シリアル、WMSが梱包単位・ロケーション・出荷、QMSが保留・逸脱処置と承認の正本になる構成があります。ラベル管理サービスはテンプレート版、印刷要求、再発行イベント、プリンタの応答、スキャン結果の正本になります。実際の境界は既存システムの機能と責任分担で確定します。

「採番」と「表示」は切り分けます。MESが製品シリアルを発番するなら、ラベルサービスが同じ領域の番号を再採番してはいけません。WMSがSSCCを持つなら、箱再構成の判断と発番はWMS側のトランザクションに従い、ラベルは確定したIDを表示します。ERPがマスタ更新をした途中で印刷する場合は、どの版の品目名・顧客名・数量を採用したかをイベントに残します。非同期連携では同じメッセージが再送されても二枚目を勝手に印刷しないよう、要求IDで冪等性を設けます。

GS1のEPCIS関連ガイドは、何の対象に、いつ、どこで、何が起きたかというイベントの捉え方を説明しています。すべての工場がEPCISを導入する必要はありませんが、再発行を履歴イベントとして扱い、対象物と工程・物流イベントに結びつける設計の参考になります。GS1 EPCIS and CBV Implementation Guideline

接続障害と再試行の契約を作る

インターフェース仕様には、要求ID、対象ID、版、状態、要求時刻、送信元、応答コード、再試行回数を含めます。印刷要求がタイムアウトしたとき「失敗」とみなしてすぐ再送すると、最初の印刷が実際には成功していて二枚出ることがあります。プリンタ応答だけでは排出・貼付の確定にならないため、印刷依頼済み、印字確認待ち、現物検証済みを別状態にします。再送前には印字ログと現場の排出物を照合し、二重要求を同じ要求IDで扱います。ジョブの取消も、「取消を送った」と「紙が出なかった」を同義にしません。

導入RFPに書くべき要件と、提案書で見抜くべき差

RFPの冒頭に、対象物の粒度を記します。ワーク一個、仕掛ロット、通い箱、出荷箱、パレットのどれに現品票を貼るのか、IDはどのシステムが発番するのか、旧ラベルを物理的に回収できるかを示します。次に、例外事象ごとの状態遷移表を付けます。状態は少なくとも「通常」「保留」「申請中」「承認済み」「印刷済み」「貼付確認済み」「旧表示無効」「却下」「取消」を扱い、状態間の権限と証拠条件を明示します。

機能要件には、再発行理由コード、同一シリアルと新シリアルの分岐、二人承認、旧表示の無効化、印刷枚数制限、スキャナ照合、テンプレート版管理、再送の冪等性、監査ログ検索・エクスポートを入れます。非機能要件には、工場のネットワーク断時の挙動、端末・プリンタ故障時の復旧、時刻同期、権限変更履歴、多言語画面、バックアップ復元、ログ保持期間を入れます。保持期間は法令や顧客契約で異なるため、汎用の年数をそのまま提案書へ写さないでください。

見積もりでは、ライセンス価格より境界条件を確認します。プリンタ一台の接続だけでなく、複数工程・倉庫での権限、ERP/MES/WMSとのインターフェース、旧ラベルを回収できない現場の運用、端末教育、夜勤の承認、帳票・証拠の保管が範囲に含まれるかです。ベンダーに「同じシリアルのラベルを二回印刷して、二枚を別箱に貼ったとき、どこで止まるか」を実演してもらうと、画面上の再印刷機能と実際の誤貼付防止能力の差が明確になります。

RFPの質問例

1. ラベル紛失で元の紙片を回収できないとき、誰がどの画面で判断し、何を証拠として残せるか。
2. 製品シリアルと箱・パレットIDの採番権限を別々に設定できるか。
3. テンプレート更新前の内容を正確に再現できるか。現行版で再出力する場合に差分を表示できるか。
4. ネットワーク断とプリンタタイムアウトの際、二重印刷を防ぐ要求IDと再試行手順は何か。
5. 旧ラベルをスキャンしたら、どの状態と理由を現場端末に表示するか。
6. 申請、承認、印刷、貼付、スキャン、無効化を一つの案件として検索・出力できるか。
7. 拠点のタイ語・日本語・英語の画面と理由コードは同じ意味を保てるか。

FAT・SATで再発行の例外を実際に通す

FATは受入前にベンダー環境で仕様通り動くかを確認し、SATは実機、現場ネットワーク、実際の工程動線で確認します。通常発行ときれいな再印刷だけを見ても不十分です。少なくとも破損、紛失、未貼付の紙詰まり、誤貼付疑い、箱再構成、通信断、プリンタ応答喪失、連続クリック、異なる作業者による同時申請を試験します。各ケースで期待するシステム状態、物理ラベル枚数、作業者画面、監査ログ、ERP/MES/WMSの更新結果を事前に書いておきます。

FATでは、同じ要求IDの再送が一つの処理に収束するか、承認前には印刷ジョブが出ないか、承認者が自分自身の申請を承認できない設定が働くかを試します。テンプレート版を切り替えた後の再発行、旧ラベルのスキャン拒否、履歴エクスポートの欠落も確認します。SATでは、実際の照明・距離・保護フィルム下でバーコードを読み、貼付後スキャンが動線上で実行できるかを観察します。操作に時間がかかるからといって、現場が照合を飛ばす迂回路を作っていないかも確認します。

合格基準は「画面が表示された」ではなく、現物と記録が一致し、不適切な再発行が止まり、許可された再発行が業務を完了できることです。合否を曖昧にしないため、試験票には初期状態、入力、期待イベント、期待するバーコード値、貼付先、旧紙片の扱い、判定者を記入します。トラブルが起きたケースは修正後に同じ条件で再試験します。

現場定着のための運用指標と教育

稼働後は再発行件数を単に減らす目標にしない方がよいでしょう。件数だけを評価すると、正当な再発行を記録しない誘因が生まれます。理由別の発生率、旧ラベルの回収可否、承認待ち時間、貼付後スキャン完了率、却下理由、同一IDの二重使用検知、プリンタ障害の再発を見ます。工程、シフト、機種別に偏りがあれば、ラベル素材や設置位置、紙の扱い方、保守を改善できます。数値目標は現場データの基準期間を取ってから決めます。

教育では「どのボタンを押すか」より、「なぜ同じシリアルを勝手にもう一枚出せないか」を説明します。作業者は紛失・破損・誤貼付疑いを見分け、保留位置へ現物を移し、元のラベルと新しいラベルを混ぜず、貼付後にスキャンする。班長は現物確認と承認の証拠を残す。品質担当は旧IDの扱いと影響範囲を判断する。IT担当はデータと印刷ジョブの状態を照合する。役割ごとの短い実技を夜勤を含めて繰り返す方が、長い操作マニュアル一冊より有効です。

再発行案件を一つの記録として追えるようにする

データベース設計では、初回発行の行に「再発行回数」を加えるだけで済ませない方がよいでしょう。再発行は申請から貼付確認まで複数の状態を通り、途中で却下、取消、通信断、再試行が起こります。初回発行イベントは変更不能の履歴として保持し、再発行案件には一意の案件IDを与えます。その下に申請、承認、印刷要求、プリンタ応答、現物照合、旧紙片処置を時系列イベントとしてぶら下げます。こうすれば、印刷はされたが貼付確認が無い案件と、承認されたが印刷されていない案件を区別できます。

同じ製品シリアルの代替表示を作った場合、対象物IDは変えず、ラベルの発行版または印刷イベントIDを変えます。逆に物流単位を組み替えて新しいIDにした場合は、旧単位と新単位の関係を別項目で保存します。「前ID」と「後ID」の二つだけでは、箱の中身がどの製品シリアルだったかという構成履歴を表せません。WMS側の梱包明細と連携し、再発行案件から対象の現物と構成を逆引きできるようにします。

操作ログは訂正可能な業務メモと分けます。作業者が理由の誤入力を訂正することは必要ですが、元の値を消すと後から事故の経緯を追えません。訂正時には変更前後、訂正者、訂正理由、時刻を残し、印刷済みのラベルがあれば再照合を求めます。こうした版管理は「ログを大量に保存するため」ではなく、表示内容が変わった時点を説明するためです。削除権限、退職者アカウント、バックアップからの復元時に履歴の整合性が維持できるかも、運用設計に含めます。

紙とデータの数量差を毎日閉じる

初期導入時には、発行枚数、プリンタ排出枚数、貼付確認枚数、回収・廃棄枚数を同じ集計単位で突き合わせます。プリンタが「成功」と返しても用紙を取り出せなかったり、二枚重なって排出されたりします。逆に、発行ジョブは失敗に見えて紙だけ出ている場合もあります。そこで未解決の差分を一覧化し、当日シフトの責任者が現物確認して閉じる手順を決めます。差分がある状態で、同じIDのラベルを翌日また印刷できる設計にはしません。

この照合は全工程に同じ厳しさを求めるという意味ではありません。たとえば梱包前のロット表示と、出荷箱の固有SSCCでは、流出したラベルが与える影響が違います。重要なのは、どの単位にどの統制を当てるかを明文化することです。人手の点検回数を増やす前に、プリンタ排出物の置き場、保留トレー、旧紙片回収箱、スキャン端末の配置を整えると、作業者が正しい順番を守りやすくなります。

導入対象を段階的に広げる

初回導入では、全製品・全プリンタを同時に変えるより、再発行頻度と誤貼付影響が把握できる一工程を選びます。そこで破損、紛失、紙詰まりの例外を実際に流し、承認待ち時間、旧紙片回収、スキャンの実行率を確認します。次に同じ工場の隣接工程へ広げる際、工程間でIDの意味が変わらないかを点検します。最後に倉庫・出荷へ広げるとき、製品シリアルと物流単位の境界を再確認します。試験範囲の拡大はソフトウェア設定の複製だけでは済みません。

移行前のラベルは再発行システムに初回発行履歴がありません。過去ラベルを再発行するときは「レガシーラベル」として扱い、元の製造・在庫記録を照合する特別な手順を用意します。履歴が無いのに、システム上では通常の再発行と同じ証拠が揃ったように表示してはいけません。段階導入中は新旧ラベルのテンプレートが混在するため、スキャナの判定ルールと現場掲示を揃えます。切り替え日、対象品目、対象工程、旧ラベルの有効期限を作業指示で明確にします。

事故訓練で仕様の穴を見つける

定期的に「破損したラベルを再発行し、旧紙片を誰かが別箱に貼ろうとした」という模擬訓練を行うと、机上の設計では見えない穴が分かります。旧ラベルのスキャンがどこで止まるか、出荷直前に二重シリアルを検知できるか、最初の申請から対象ワークと関係ロットを何分で特定できるかを計測します。訓練では現場を責めるための採点ではなく、画面、権限、置き場、データ連携の改善点を記録します。

別の訓練では、プリンタ応答が失われた直後に作業者がもう一度「印刷」を押す状況を作ります。システムが同じ要求IDを返すか、排出済みの紙を探す画面があるか、承認者には二回目の印刷と見えるかを観察します。出荷後に誤貼付の疑いが発覚した想定では、対象ラベル、製品、箱、出荷先をたどれるかを確認します。再発行を品質事故への入り口として扱えば、普段の印刷管理よりも実効性の高い検証になります。

ラベル設計変更と再発行の関係を明文化する

現品票のテンプレートが変わった後に、過去に発行したラベルを再発行することがあります。品名の表記だけを直した変更なら現行版での表示が妥当かもしれませんが、顧客指定の品番や注意表示が変わった場合は、旧版の忠実な再現が誤表示につながる可能性があります。逆に、現行版を無条件に使うと、過去の製造指図で承認された表示と異なるラベルが現物へ付くこともあります。変更の内容、対象ロット、発効日、顧客承認の有無で判断する規則を作り、再発行画面には選択した版と差分を示します。

版を選べる権限も制限します。作業者が都合のよい版を選ぶのではなく、製造指図や出荷指示に紐付く適用版をシステムが候補として提示し、例外は品質承認に回します。印字データの保存は再現に役立ちますが、保存した文字列を再送するだけで常に正しいとは限りません。旧版と新版のどちらで再発行したか、判断者と根拠を案件に残しておけば、後日の問い合わせで表示差異を説明できます。この設計はラベル改訂と製品識別を別々の変更管理として扱うための土台にもなります。

システム障害時の紙運用を無制限の抜け道にしない

ネットワークやプリンタが止まったとき、工場は完全停止を避けるために手書き票を使う場合があります。ただし、手書き票を使った現物に復旧後の正式ラベルを貼る際、紙票の番号とデータ上のIDが食い違うと、新しい誤貼付を作ります。緊急票には一意の管理番号、対象物、発行者、発行時刻、使用理由を記入し、保留区画から移動できる条件を制限します。復旧後は緊急票を案件IDに結び、元の識別情報と照合してから正式ラベルを発行します。緊急票も回収または使用不能にし、処置が終わるまで案件を閉じません。

紙運用の適用範囲は、製品の安全性、工程停止の影響、顧客要求に応じて事前に決めます。例えば出荷ラベルや個体追跡に不可欠な表示では、通信断中の手書き代替を許さず、対象物を隔離する判断もあり得ます。現場が障害のたびに独自の略号や連番を振ると、後で二重番号や読み違いを解消できません。訓練時には復旧作業だけでなく、緊急票を何枚作り、何枚を正式ラベルに置き換え、何枚を回収したかまで確認します。この照合を終えた時点を復旧完了と定義すれば、システム上は正常でも現場に未処理の紙が残る状態を防げます。

紙票の番号は、印刷された製品シリアルの代用品にしない方が安全です。紙票はあくまで「障害中の一時的な管理案件」を示す番号とし、製品の正式IDとは別欄に書きます。あらかじめ連番入りの緊急票を封緘して配布し、班長が使用開始番号と残枚数を管理すれば、現場が思いつきで重複する番号を書く事態を避けられます。未使用票も数え、紛失した票は使用済みと同じように調査します。紙票を貼った現物は専用の保留区画に置き、正式ラベル発行前に次工程や出荷へ流れない物理的な動線を作ります。障害中にどうしても工程を進める場合も、移動先、責任者、許可条件を事前に決め、移動履歴を紙票番号で追えるようにします。

復旧時は紙票の記載を単純に転記して終わらせません。製造指図、工程実績、現物の刻印、保留区画の実数を照合し、正式IDと紙票番号の対応表を確定します。誤記や二重使用の疑いがあれば品質部門の判断が出るまで正式ラベルを発行しない。照合した人と承認した人を記録し、正式ラベルの貼付後スキャンが成功したら紙票を回収します。票を回収できない場合は理由と影響範囲を記録し、案件を未解決のまま残します。障害終了時刻ではなく、現物、紙票、電子記録の三つが一致した時点を案件の完了条件にすることが重要です。

監査で一件を再現できるデータを残す

監査や客先照会では、「何枚再印刷したか」だけでなく、指定した製品または箱の一件を時系列で再現できることが求められます。元の発行時刻と内容、再発行申請、理由、保留、承認、印刷要求、プリンタ応答、旧紙片の処置、新ラベルの貼付、最終スキャンを一つの案件IDから辿れるようにします。途中で申請が却下された場合も削除せず、却下理由とその後の現物処置を残します。印刷要求が二回送られたが現物は一枚しか出なかった場合には、二回目が冪等処理で吸収されたことをログで説明できる設計にします。

保存される時刻は、工程端末、プリンタ、MES、WMSで数分ずれているだけでも順序が逆に見えます。各機器の時計を同期し、保存時刻と表示時刻のタイムゾーンを仕様書に明記します。時刻の修正やマスタの訂正が後から入った場合も、元データを消して帳尻を合わせず、訂正イベントを追加します。履歴の閲覧権限と訂正権限を分け、誰がどのデータをエクスポートしたかも必要に応じて残します。監査用画面で表示される内容と、実際の印字データ、現場の紙片が一致するかをサンプル案件で定期的に検証します。

紙とデータの突合では、発行要求件数とプリンタ成功件数を同じものとして扱わないことが大切です。プリンタ成功でも排出物が汚れて廃棄されることがあり、タイムアウトでも紙が出ていることがあります。そこで案件ごとに「要求した枚数」「機械が排出したと確認した枚数」「貼付した枚数」「隔離・廃棄した枚数」を別々に記録し、差が出れば理由が記録されるまで締めません。棚卸し担当が見るのは差分件数だけでなく、未貼付の紙片が今どこにあるかです。シフト終業時に未解決案件を引き継ぎ、次の担当者が同じIDを安易に再印刷しないよう、画面上でも保留表示を継続します。

変更管理と導入範囲を案件単位で追う

ラベルの改訂は、印字レイアウトだけでなく、読取ルール、品目マスタ、顧客指定、ERP/MES/WMSの受け渡し項目を変える場合があります。変更申請では、対象製品、対象工程、適用開始時刻、旧版ラベルが残る場所、既発行品を再発行するときの版選択を明記します。変更の影響を受ける再発行案件が進行中なら、印刷を一旦保留し、旧版で完了させるか新版でやり直すかを責任者が決めます。版だけを新しくして古い承認を流用することは避けます。表示内容が変わるなら、承認者が差分を確認した記録を残します。

段階導入では、対象外のラインや倉庫から来たラベルを新システムがどう扱うかも決めます。対象外で発行されたラベルを新端末が読めない場合、作業者が番号を手入力して通す抜け道が生まれます。移行表には製品、ライン、発行日、テンプレート版、読取可能な端末、再発行の責任システムを載せます。対象を広げる都度、旧版と新版のラベル、既存の箱在庫、仕掛品が混在する期間を見積もり、混在中の例外手順を掲示します。全ラインを同じ日に切り替える必要はありませんが、どの現物がどの統制下にあるかは曖昧にしません。

この変更管理を試すため、訓練には「前日に発行した旧版ラベルが今日破れた」「夜勤の通信断で紙票を使った」「箱を組み替えた直後に旧ラベルが見つかった」など、複数の例外が重なる場面を入れます。個別機能が動いても、複合事象で承認の責任が途切れることがあります。試験の結果は単に合格・不合格とせず、どの状態遷移で誰の判断が必要になったか、現物がどこに保留されたか、紙片を何枚回収したかまで記録します。改善した手順は次のFAT/SATの試験票と現場教育へ反映し、同じ穴を別ラインへ持ち込まないようにします。

タイの工場で決めておきたい実装事項

日本語の仕様をそのまま現場へ渡すと、理由コードの意味がタイ語画面で揺れることがあります。「紛失」と「未印字」、「破損」と「印字不良」は分け、コード自体は共通IDで管理し、表示文を言語別に定義します。班長と品質承認者の交代時刻、拠点間の時刻表示、ネットワークが途切れた場合の紙帳票による代替手順も確認します。日本本社とタイ工場で品目マスタや顧客ラベル指定が異なる場合は、どちらが表示内容の正本かをRFP前に決めます。

よくある質問

現品票の再発行履歴は、通常の印刷ログだけで足りますか？

足りない場合が多いです。印刷ログはプリンタへデータを送った事実を示しても、対象現物、理由、承認、旧ラベル処置、貼付後の照合まで説明しません。印字データと業務イベントを同じ案件IDで結び、後から「なぜ・誰が・どの現物へ」を検索できるようにします。プリンタの成功応答を貼付完了と見なさないことも重要です。

工場のラベル再印刷に毎回承認は必要ですか？

一律ではありません。元ラベルが確実に未貼付で回収済みの紙詰まりと、行方不明のラベルではリスクが違います。製品種別、識別粒度、出荷段階、顧客要求で権限マトリクスを作り、軽い事象には簡潔な確認、紛失や誤貼付疑いには品質部門の判断を求めます。どの経路でも理由と作業者の記録は省かない設計にします。

バーコードラベルの再発行で誤貼付をどう防ぎますか？

現物IDと新ラベルを同じ作業場所で照合し、貼付後に再スキャンします。旧ラベルが読める場合は無効状態を返し、同一IDの二重使用を検知します。紛失で元ラベルが読めない場合には、工程記録や刻印など別の証拠で現物を確定してから承認します。バーコードの印字品質検査だけでは、隣の箱への誤貼付は防げません。

MESとWMSのどちらが再発行を管理すべきですか？

製品一個の製造シリアルならMES、箱やパレットの物流単位ならWMSが正本になる構成が考えられます。ただし既存システムの権限と連携によって異なります。ラベル管理サービスは印刷・再発行イベントの正本を担い、採番元のIDを参照する設計が整理しやすいでしょう。二つのシステムが同じIDを発番しないことが最優先です。

まとめ

現品票ラベル再発行管理システムの導入では、プリンタに同じデータを再送する機能より、現物の同一性を確認する判断、旧ラベルの回収・無効・隔離、理由と承認の証拠、貼付後のスキャン、各システムの正本を一続きに設計することが重要です。最初に例外事象とID単位を整理し、RFPで状態遷移と責任を明示し、FAT/SATで失敗時の挙動まで試してください。こうして初めて、ラベルが失われても追跡の鎖を切らずに回復できます。

TOMAS TECHでは、タイ工場の現品票再発行フローを、既存のMES・ERP・WMSと現場動線に合わせて整理できます。まだRFP前で、旧ラベルの扱いや同一シリアルの判断基準を検討している段階でも、お問い合わせからご相談ください。

参照した一次資料

• GS1 Global Traceability Standard — 識別粒度と追跡イベントの考え方。
• GS1 General Specifications — GS1識別キーとバーコード構文。
• GS1 Logistic Label Guideline — 物流単位とSSCC。
• GS1 EPCIS and CBV Implementation Guideline — イベントと対象物の結合。
• Microsoft Learn: Reprint and void wave labels — 再印刷・無効化の製品実装例。
• Microsoft Learn: Configure wave label printing — 印字データと履歴の製品実装例。

*本記事の承認経路、状態名、試験項目は導入設計例です。特定の規格・法令が一律に定める要件として記載していません。適用する顧客仕様、製品規制、社内品質手順と照合してください。*