製造業の品質保留管理システム導入｜現品・在庫・解除をつなぐ

製造業で「品質保留管理システムを導入したい」と考えるきっかけは、検査結果の入力が遅いことだけではありません。保留と判定された現品が棚に残り、ERPでは引当可能に見え、WMSではピッキングでき、MESでは工程投入できる。この状態が一度でも起これば、検査帳票を電子化しただけでは問題は解決しません。必要なのは、対象物・数量・場所・利用可否・判定権限を同じ時点でそろえる仕組みです。

本稿ではタイの製造拠点を念頭に、受入原材料、仕掛品、完成品を対象とする品質保留の実務を整理します。市販製品の機能紹介ではなく、業務要件、ERP・MES・WMSの責任分界、部分解除、誤出荷防止、RFPとFAT/SATの試験条件までを一続きで示します。規制産業では別途適用法令と顧客要求の確認が必要です。

品質保留管理システムの導入で最初に決めること

品質保留とは、検査待ち、不適合の疑い、工程逸脱、顧客からの連絡などを理由に、対象物の使用・移動・出荷を一時的に制限する業務状態です。「不良確定」と同義ではありません。調査後に合格、手直し、選別、条件付き使用、返品、廃棄などに分かれます。保留の解除は、品質部門の判定だけで終わらず、在庫取引と現場作業にも反映されて初めて完了します。

実務では「保留」という言葉を一つにまとめず、少なくとも四つの問いに分けます。第一に、何を対象にするか。品目全体、ロット、シリアル、パレット、容器、仕掛指図のどれか。第二に、どの数量を止めるか。検査サンプルだけか、同一ロットの全量か。第三に、何を禁止するか。受注引当、ピック、出庫、工程投入、移動、再包装、計画上の可用在庫への算入はそれぞれ別です。第四に、誰が、どの証拠で、何個を、どの状態へ変えられるか。これを決めずに画面だけ作ると、現場ごとに「保留」の意味が変わります。

Microsoft Dynamics 365の公式文書でも、品質指図に対する在庫ブロック、手動ブロック、在庫ステータスによるブロックは別の仕組みとして扱われます。検査サンプル数量とブロック数量も一致するとは限りません。特定製品の設定をそのまま他社に当てはめるべきではありませんが、「何を、どの取引で止めるか」を個別に設計する必要性を示す参考になります。出典: Microsoft Quality orders、Microsoft Inventory blocking。

「検査中」「保留」「不適合確定」を分ける

検査中は結果が未確定で、規則に従って利用を制限する状態です。保留は通常運用から一時的に外し、調査・判定を待つ状態。不適合確定は要求への不一致が確認され、処置方法の決定が必要な状態です。これらを一つの「NG」欄に押し込むと、解除条件、担当者、引当ルール、リードタイム分析があいまいになります。現場画面に表示する短い状態名と、システム内で保持する理由コード・判定コードは分けて設計します。

現品を止める範囲をどう特定するか

対象の識別が弱ければ、どれだけ厳しい承認画面を作っても別の容器が動きます。保留キーの基本は品目、ロットまたはシリアル、保管場所、荷姿・容器ID、数量、単位、品質状態です。仕掛品なら製造指図、工程、作業区、工程通過時刻も必要になることがあります。外注先にある現品を対象に含めるなら、所有権と物理的な所在を別項目にします。識別ラベルは人が読める文字と機械読取コードを併記し、スキャン後に品目・ロット・状態・数量が端末に返るようにします。

「ロットを止める」場合も、ロット内の一部容器だけを対象にするのか、同一ロットを全拠点で止めるのかは別判断です。前者は狭すぎると混入を見逃し、後者は広すぎると供給を止めます。一次調査では安全側に範囲を広げ、その後、工程履歴と検査証拠に基づいて段階的に絞る運用があり得ます。ただし自動縮小は避け、根拠・承認・対象IDを記録します。製造指図をまたいで仕掛品ロットを分割・統合する場合は、親子系譜と数量の扱いを仕掛品ロットの分割・統合管理で確認できます。

GS1のGlobal Traceability Standardは、追跡イベントの主要データとして時刻、対象物の識別子、場所、工程段階、状態、責任者を挙げています。GS1 EPCIS 2.0も、イベント後の状態を表すdispositionと、明示的に解除されるまで継続するpersistentDispositionを定義しています。すべての工場がEPCISを採用する必要はありませんが、「保留開始」と「保留解除」を上書きではなくイベントとして残す設計の参考になります。出典: GS1 Global Traceability Standard、GS1 EPCIS 2.0。

保留範囲の単位を明示する

たとえば原材料ロットRに100箱あり、1箱の外装破損が見つかったとします。まず破損箱だけを止めるのか、同じ輸送単位の10箱を止めるのか、100箱すべてを止めるのか。判断は欠陥の種類と流出経路によって変わります。システムには「保留対象の論理単位」と「実際に確保した物理単位」を別々に記録し、差があれば警告を出します。100箱を論理保留にしても、端末で確認できたのが98箱なら未発見の2箱を未解決として表示します。

バーコードだけで現品確認を済ませず、ラベル剥がれ、再包装、パレット積替え、手入力時の誤読も想定します。検品担当者が代替IDで特定した際には元ID、代替ID、理由、時刻、承認者を残します。これらは現品票の設計に関わり、単に在庫残高を一致させる話ではありません。

状態遷移を先に定義する

推奨する最小構成は「利用可能」「検査待ち」「品質保留」「判定待ち」「手直し中」「条件付き利用」「廃棄・返品待ち」「完了」です。ただし状態数を増やすことが目的ではありません。誰が次の状態へ進めるか、どの証拠が必要か、在庫・現場作業に何が起きるかを一行ずつ記すことが重要です。画面上の状態と、ERPの在庫区分、WMSのピック可否、MESの投入許可を一対一で無理に対応させず、マッピング表にします。

「判定済み」と「解除済み」は分けます。品質が合格を入力しても、ERPの在庫区分変更に失敗したなら出庫可能にしてはいけません。逆にERP側だけ手動で区分を変えられると、判定前の現品が出荷されます。状態遷移を一つの画面に見せる場合も、各システムの応答を照合し、未反映を別のエラー状態として残します。

部分解除と残量

同一ロットの100個を保留し、選別後に合格80個、手直し15個、廃棄5個となる例を考えます。これは説明用の仮定であり、実績値ではありません。元の保留100個を一度に「解除」とせず、処置ごとに数量を確定します。保留残量は100−80−15−5＝0です。ただし合格80個が既に引当済みだったか、手直し15個が別工程の仕掛品になるか、廃棄5個に会計処理が必要かは別取引です。数量保存則だけでなく、状態ごとの転記先と責任者を明示します。

端数、重量と個数の換算、サンプルの破壊検査、ロット分割、外注先からの戻りがある場合は、同じ式で単純に閉じられません。単位変換の基準、歩留まり、消費サンプル、差異承認を追加します。数量0になったことと、すべての取引が完了したことも別です。決裁待ちの廃棄取引やWMSの未処理タスクが残るなら、案件は閉じずに未完了として表示します。

ERP・MES・WMSのどこを正本にするか

典型的にはERPが品目・財務在庫・購買・販売の正本、MESが工程実績と仕掛品の正本、WMSが場所・容器・倉庫作業の正本です。しかし既存システムの実際の所有範囲は企業ごとに異なります。新たな品質保留アプリを作る場合、「在庫の真実」をもう一つ増やさず、品質判定・承認・イベント連携の正本に限定する設計が実務的です。各状態をどのシステムが持つかを一覧化し、同じ属性を二つの画面で自由に修正できないようにします。

Microsoftの品質指図では、受入・販売・生産の参照に対して検査を関連付け、検査中の数量をブロックする仕組みが説明されています。SAPの公式文書では、品質検査在庫から利用可能在庫への変更にQMの使用決定とWMS側の転記変更が関わります。これらは製品固有の機能ですが、「品質の決定」と「倉庫で動かせる状態」が別工程であることを示しています。出典: Microsoft Quality orders、SAP Effect of the Usage Decision。完成品については完工から完成品入庫までの管理も参照してください。

連携は「指示成功」と「反映確認」を分ける

品質システムが保留指示を送信した時点では、安全な保留が成立したとは言えません。ERPの在庫ブロック、WMSの未実行ピック取消、MESの投入禁止がそれぞれ確認されて初めて「反映済み」です。API応答がタイムアウトしても実際には処理された可能性があります。再送には同じイベントIDを使い、受信側で重複実行を防ぎます。更新が失敗した系統が一つでもあれば、担当者に通知し、出庫現場には暫定停止を明示します。

逆に解除指示では、すべての許可を同時に広げるのではなく、判定と必要な在庫取引の完了を条件にします。引当解除、販売可能在庫への戻し、WMSピック再開、MES投入再開の順序は品目用途に合わせて決めます。既存の注文へ自動再引当するかは別の業務判断です。品質保留の解除が、そのまま特定顧客への割当を意味するわけではありません。

オフライン端末と既発行タスク

タイ工場では倉庫や工程内で通信が不安定な場所もあります。端末がオフラインでも直前に取得した「利用可能」表示を無期限に信用すると、保留後にピックされる恐れがあります。端末の状態キャッシュに有効期限を設け、期限切れや同期失敗時は対象ロットの重要取引を停止する設計を検討します。対象物が既にピックタスクに組み込まれている場合、未着手、作業中、完了済みで取消方法を分けます。完了済みの物理移動はソフト上の取消だけで戻せないので、場所確認と隔離作業を発行します。

品質保留の起票から解除までの標準業務

第一段階は異常の発見と暫定隔離です。発見者が端末で現品をスキャンし、異常の種類、発見時刻、工程・場所、数量、写真、緊急度を入力します。発見者に「品質判定」の権限まで与える必要はありません。起票直後は、設定済みルールに従って対象物の取引を止め、品質担当へ通知します。スキャン不能品には暫定識別子を付け、後で正式IDと対応させます。

第二段階は対象範囲の確定です。品質担当は同一ロット、同一設備・時間帯、同一原材料、同一顧客出荷先などへの波及を確認します。対象拡大は新たな保留イベントとして残し、既存保留の数量を書き換えて履歴を消さないようにします。過去に出荷済みの可能性がある場合は、保留管理だけでは足りません。別の顧客連絡、回収、トレーサビリティ手順へ接続します。

第三段階は調査と判定です。検査値、仕様書版、測定器、写真、工程条件、サンプル数、判定規則を案件に結びつけます。承認者は証拠の欠落を見たうえで、合格、選別、手直し、特採、返品、廃棄などを選びます。「特採」は顧客契約と社内権限に依存するため、一般的な承認ボタンで自動許可しません。判定の変更が必要な場合は旧判定を消さず、変更理由と再承認を記録します。

第四段階はシステム反映と現品確認です。判定に沿って在庫区分、場所、作業タスク、原価処理を更新します。システム内の保留残量と、実際に隔離棚にある現品の数量が一致するかを確認します。合格品の移動先、手直し品の新しい指図、返品品の輸送、廃棄品の証跡を個別に閉じます。最後に案件を完了とし、検知から反映までの所要時間を分析します。

二重ブロックと見かけの在庫差異を防ぐ

Microsoft Dynamics 365の同一環境で品質指図によるブロックと在庫ステータスによるブロックを併用すると、追加のブロック取引が発生し、利用可能数量の読み方が複雑になる設定例があります。これはERPとWMSという別システムで同じ数量を二重減算する事例ではありません。製品内で複数のブロック機構を重ねる場合は、取引明細と計画計算への影響を試験します。別システム間の連携では、それぞれが何を停止し、どのシステムだけが在庫数量の正本を更新するかを別途定義します。出典: Microsoft Inventory blocking。

設計上は「止める権限の正本」「在庫数量の正本」「倉庫タスクの停止」を区別します。一つの保留イベントから各システムへ命令を出しても、二つのシステムが同じ財務在庫数量を減算しないようにします。引当可能数量、物理在庫、品質保留数量、検査サンプル数量、廃棄予定数量を別列にし、同じ数量を足し引きする場面を図で示します。導入前のデータ移行では、旧システムに残る未解放ブロックと、現品のラベルを突き合わせます。

また、品質保留は棚卸差異の「調整理由」として使うべきではありません。現品があるが使えない状態と、現品が見つからない状態は異なります。保留品の数量差異が出た場合には、品質状態の判定と在庫差異承認を別々に扱います。これにより、保留解除で帳簿上だけ数量が戻る誤りを防げます。

RFPに書くべき要件と選定基準

品質保留管理システムの比較では、機能一覧のチェック数よりも、例外時に現品が動かないかを重視します。RFPには自社の現品識別単位、既存のERP・MES・WMS、対象工程、品目ごとの禁止取引、権限、承認、復旧手順を書きます。ベンダーに「品質管理に対応」とだけ伝えると、検査記録画面はあってもピックや投入の制御が含まれない提案になり得ます。

必須要件は、対象IDのスキャン、範囲拡大・縮小、数量別処置、証拠添付、二段階承認、ERP/MES/WMS反映状態の可視化、再送の冪等性、オフライン時の制御、監査ログ、言語表示です。タイ語・英語・日本語を併用する職場では、理由コードの意味が翻訳で変わらないように、コード自体は共通化し、表示名と説明を言語別に管理します。ベトナム語は利用者がいる場合に追加します。通知はメールだけに頼らず、保留対象が作業画面で認識できるようにします。

費用を比較する場合は初期ライセンスや開発費だけでなく、ラベル・端末、ERP/MES/WMS連携、データ洗浄、検証、教育、障害対応、継続運用を分けて見積もります。保留対象を全量停止する設計は誤流出を抑えやすい一方、過大な停止による納期影響もあります。価格だけでなく、対象範囲を絞るための証拠をどれだけ早く集められるかを評価します。製品比較表の数字を一般相場として引用することは避け、自社の件数と既存システム構成を基に概算します。

FAT/SATでは正常系より例外系を試す

FATはベンダー環境で仕様どおりに動くかを確かめ、SATは自社の設備・端末・ネットワーク・運用権限を含めて確かめます。正常な「保留→検査→合格→解除」だけでは、誤出荷の防止力は判断できません。最低限、保留対象を既存の受注引当がつかんでいる場合、WMSピック中の場合、MES投入直前の場合、端末がオフラインの場合を試します。

試験用データは、ロット全量、ロットの一部容器、シリアル単位、複数倉庫、破壊検査サンプル、手直し後の再検査を含めます。保留100個から80個を合格、15個を手直し、5個を廃棄する仮定例では、各状態の合計、ERP在庫区分、WMS場所、MES仕掛数、会計取引が一致するかを確認します。数字は試験シナリオであり、生産効果の実績値ではありません。

APIの失敗試験では、要求が受信側に届いた直後に応答だけ失われる条件を作ります。再送後も一件の保留イベントとして扱われ、数量が二重に移動しないことを確認します。解除の途中でERPだけ成功しWMSが失敗した場合には、画面に「完了」と出さず、作業再開も抑止するべきです。復旧操作の権限、再送回数、手動照合の手順まで受入条件に入れます。

導入後の指標

導入前後で比較する指標は「保留件数が減ったか」だけではありません。起票から全システム反映までの時間、保留中の誤引当・誤ピック試行、期限超過案件、保留残量と現品の差異、判定後の未反映、解除再処理、理由コード未入力率を追います。件数が一時的に増えても、紙や口頭で埋もれていた案件が見えるようになった結果かもしれません。分母を受入件数、製造ロット数、検査対象数などにそろえ、工程別に比較します。

現場の使い勝手も測ります。スキャンから暫定保留までの操作時間、端末の再入力件数、夜勤帯に承認者が不在だった時間、隔離棚の滞留日数です。品質部門だけでなく、倉庫、計画、営業、保全、経理が同じ案件を違う観点で見るため、共通の案件IDと更新時刻が重要です。指標の改善は、機能追加ではなく承認条件や通知先の見直しで得られる場合もあります。

試行導入では「止まる」ことを現品で確認する

最初の試行は、単に保留票を入力して画面表示を確かめるだけでは足りません。対象ロットに対して既に発行されたピッキング指示と製造指図を用意し、品質保留の起票後に倉庫端末と工程端末がその現品を受け付けないことを実物のラベルで確かめます。試験環境の在庫数だけが変わっても、作業者が持つ端末に古い指示が残れば誤出荷や誤投入の可能性は残ります。現品を隔離棚へ移す手順と、移動できなかった現品を「所在未確認」として追跡する手順も同時に試します。

判定後の部分解除は、例えば100箱のうち80箱を合格、15箱を再検査、5箱を廃棄予定とした状態で検証します。80箱だけを引当・ピッキング・工程投入の対象へ戻し、残る20箱の禁止状態とラベルが維持されることを確認します。解除指示を再送した場合、80箱がもう一度加算されないことも重要です。数が一致しても、解除済み80箱のうち別ロットの箱を誤ってスキャンできるなら受入条件を満たしません。数量に加え、品目、ロット、容器ID、場所を突き合わせます。

本番切替の前には、保留中の案件を旧システムから新システムへ移す基準時刻を決め、両方の画面で同じ現品を同時に解除できないようにします。移行リストには案件ID、対象数量、実在確認数量、最終判定、旧システム側の未処理取引を含めます。切替を戻す判断も、単に新システムが停止したかではなく、現品を安全に止め続けられるかで決めます。復旧後は旧・新両方のイベント履歴を案件IDで照合し、重複した解除や未反映の保留がないことを品質と倉庫の担当者が共同で承認します。

試験結果の記録では「ボタンを押せた」「APIが成功を返した」だけを合格にしません。案件ごとに、起票時の現品写真、スキャンした容器ID、端末に表示された禁止理由、各システムが受け取ったイベントID、解除後の実在数量を残します。倉庫作業者が保留を知らずにピッキングを試した場合には、その試行が拒否された時刻と端末を確認します。夜勤や外注先のように品質担当者がその場にいない条件でも同じ試験を繰り返し、代行者が勝手に解除できない権限設定を確かめます。受入試験に失敗した案件は修正後に同じロット・同じ操作順で再試験し、画面、在庫台帳、現品ラベルの三者が一致した証拠を残します。

タイ工場での運用設計

タイの工場では、現場のタイ語、顧客やグループ会社向け英語、本社向け日本語が同じ案件に混在することがあります。機械的に翻訳した自由記述だけでは判断が割れるため、理由コード、判定コード、処置コードには共通IDを付け、各言語の説明と適用例を管理します。自由記述は原文を保存し、翻訳文が追加されても原文を消さないようにします。品質判定の権限者と夜間の代理者を明示し、承認者不在でも現品の暫定停止はできるようにします。

輸出向け製品やBOI関連原材料を扱う場合、保留解除、返品、廃棄、スクラップ処理には別の記録・承認要件が関わり得ます。品質保留システムだけで税務・通関・BOIの適法性を保証するものではありません。対象事業の登録条件と実際の制度運用を専門担当者が確認し、必要な外部書類番号を案件に関連付けます。廃棄までの処理を検討する場合は、既存のスクラップ管理システムの記事に分けて整理しています。

拠点間で同じ品目コードを使っていても、倉庫・保管状態・単位・ロット採番規則が異なることがあります。最初の対象拠点を一つ選び、保留理由が多い品目群と現品移動が多い工程から試すと、連携境界を検証しやすくなります。ただし試行導入でも、他拠点に移動できる現品を保留対象から漏らさないよう、移送の境界だけは先に決めます。運用者への教育では「起票を早くする」だけでなく「解除できないとき何を確認するか」まで訓練します。

FAQ：品質保留管理システム導入の疑問

品質保留管理システムと検査成績書システムは同じですか？

異なります。検査成績書システムは測定値や合否の記録・発行を中心にします。品質保留管理は、判定前後の現品に対して引当、投入、移動、出荷を制御し、処置数量と在庫状態を確定します。両者は検査指示IDやロットIDで連携できます。成績書が完成しても、在庫区分の更新に失敗していれば保留案件は完了ではありません。

品質保留はロット全量を止めるべきですか？

一律には決められません。欠陥の発生機構、同一ロット内の混在、工程と時刻の記録精度、顧客要求によって範囲を決めます。最初は広めに停止し、証拠を得て承認付きで絞る運用もあります。検査サンプル数量と保留数量は別項目にし、全量停止か部分停止かをルールとして明文化します。

ERPの在庫ステータスだけで十分ですか？

ERP上で引当や出荷を止められても、現場端末の既発行タスク、MESの投入、外注先の現品、オフライン操作まで止まるとは限りません。既存ERPで必要な取引をすべて制御でき、判定と監査ログも管理できるなら追加システムは不要な場合があります。導入判断は製品名ではなく、対象取引の試験結果で行います。

品質保留管理システムの費用はどう見積もりますか？

保留案件数、識別単位、対象拠点、必要言語、ERP/MES/WMSのAPI、端末、ラベル、承認・監査要件で大きく変わります。単一拠点の画面価格と、多拠点で物理現品を止める総費用を混同しないことが大切です。RFPには現行業務と異常系のテストシナリオを付け、機能ごとに初期費と運用費を分けて回答を受けます。

紙の赤札は廃止できますか？

電子的なブロックがあっても、現品を見た作業者がすぐ理解できる表示は必要です。赤札を残すか、印字ラベルや端末表示へ置き換えるかは現場の安全性と通信環境で判断します。紙を残す場合も、手書き番号だけでシステム案件と切れないように、共通IDとスキャンコードを入れます。

まとめ

品質保留管理システム導入の中心は、検査結果を保存する画面ではなく、対象現品を確実に止め、根拠ある判定の後に必要数量だけを正しい取引へ戻すことです。対象ID、状態遷移、禁止する操作、ERP・MES・WMSの正本、部分解除、連携失敗時の動きを先に決めます。RFPとFAT/SATでは、正常系に加えて既発行ピック、オフライン端末、部分処置、API再送を試し、現品とシステムの残量が一致することを確認します。

タイ工場で品質保留と在庫・工程の連携を検討している段階であれば、現在の業務フローと対象システムを基に、保留範囲や試験条件を整理できます。TOMAS TECHに相談する際は、対象品目、ロット識別方法、既存のERP/MES/WMS、最近困った保留案件を共有いただくと、論点を具体化しやすくなります。

参考情報

• Microsoft Learn: Quality orders
• Microsoft Learn: Inventory blocking
• Microsoft Learn: Batch disposition codes
• SAP Help: Effect of the Usage Decision
• SAP Help: Stock Category
• GS1: Global Traceability Standard
• GS1: EPCIS 2.0