ホールドは「不適合」とは別の機能である
ホールド（保留）と不適合は混同されがちですが、別の概念です。不適合は「規格を満たさないことが判明した」という事実の記録であり、ホールドは「判断がつくまで動かすな」という状態の宣言です。不適合が確定していなくてもホールドはかけます。顧客からのクレーム一報で該当期間の全ロットを予防的に止める、設備の異常が疑われた時間帯の生産分を調査のため止める、監査指摘で文書不備が見つかったバッチを止める、いずれも、不適合かどうかはまだ分かりません。
この区別が実装に効くのは、ホールドには「疑い」の段階で誰でも素早くかけられる軽さが必要だからです。不適合報告書の起票を待たないと止められない設計では、疑わしいロットが止まる前に次工程へ流れます。かけるのは軽く、解除は重く。この非対称がホールド管理の設計原理です。不適合が確定した後の処置・是正の流れは不適合管理とCAPAの守備範囲であり、この記事はその手前の状態管理と権限に絞ります。
状態遷移：「重ね掛け」を最初から設計する
ホールド管理の実装でまず決めるべきは、状態モデルです。最小の設計は「ロットにホールドフラグを1つ持つ」ですが、これは実務に耐えません。同じロットに品質ホールド（逸脱調査中）と技術ホールド（設計変更の確認待ち）が同時にかかることは普通にあり、フラグ1つでは「品質は解除したが技術はまだ」を表現できず、片方の解除で全体が動き出す事故が起きます。
つまりホールドは、ロットの属性ではなくロットに紐づく独立のレコードとして持ちます。各レコードが種別・理由コード・起票者・対象範囲・状態・解除記録を持ち、ロットの可動性は「アクティブなレコードが存在するか」の導出で決まる。この構造なら、重ね掛けも、部分ホールド（ロット内の特定シリアルやコンテナだけ止める）も、履歴の監査も自然に表現できます。
対象範囲の粒度も決めどころです。ロット単位だけでよいか、コンテナ・パレット単位、シリアル単位まで必要か。粒度を細かくするほど止める範囲を最小化でき廃棄・機会損失が減りますが、現物の識別がその粒度でできていることが前提になります。
権限設計：かける・解除する・広げる・狭める
権限設計は4つの操作に分けて考えます。
- かける権限は広く。現場作業者を含む広い範囲に与えます。疑いを持った人がその場で止められない設計は、ホールドの目的そのものを損ないます。誤ホールドのコストは解除の手間だけであり、止め損ないのコストと比べれば常に小さい
- 解除権限は狭く、種別ごとに。品質ホールドは品質責任者、技術ホールドは技術責任者。起票した本人が解除できない設計（自己解除の禁止)を原則にします
- 範囲の拡大は軽く、縮小は重く。「同時期の他ロットにも広げる」は追加のホールドとして誰でも起票可。「対象を狭める」は実質的な部分解除であり、解除と同じ権限で統制します
- 一括操作は権限をさらに絞る。「この期間の全ロットを一括ホールド」は初動対応として必要な機能ですが、一括解除は原則提供しない、が安全側の設計です。解除は1件ずつ、理由を確認しながら行うべき操作です
解除の承認に複数者の署名や段階承認が要る場合は、承認ワークフローと電子署名の仕組みに乗せ、ホールド管理側で独自の承認機構を作らないことも設計判断の1つです。
出荷判定への接続：ホールドゼロは必要条件にすぎない
出荷判定（disposition）は、ホールド解除の延長にある「最後の関門」です。ここで押さえるべきは、「アクティブなホールドがない」ことは出荷可の必要条件であって十分条件ではないという点です。出荷判定では、ホールドの不存在に加えて、全工程の実績が完了しているか、検査結果がすべて合格か、逸脱がクローズしているか、記録のレビューが済んでいるか、といった複数条件の充足を確認します。規制産業では、この確認とリリース署名の権限者が法令・手順書で定められています。
設計上の論点は、出荷判定をMESで行うかERP・QMSで行うかです。判定材料（工程実績・検査結果・逸脱状態）の大半はMESにあるため、条件の充足チェックはMESで行い、判定結果をERPの出荷可否ステータスへ連携する構成が自然です。逆に、判定はERP側で行うがホールド情報が連携されていない構成が、冒頭の「止まってるはずですよね」事故の最頻出パターンです。ホールドの起票・解除イベントは、発生の都度ERP・WMSへ配信し、どのシステムから見ても同じロットが同じように止まっている状態を作ってください。ロットの物理的な所在と履歴の追跡は製品の追跡と系譜管理が支えます。
よくある質問
ホールド中のロットに対して、作業を一切禁止すべきですか。
一律禁止にはしないでください。ホールドの目的は「状態を変えずに保全する」ことと「先へ進めない」ことであり、調査のためのサンプリング、保管場所の移動（隔離エリアへの移動）、追加検査は、むしろホールド中にこそ必要な作業です。設計としては、操作の種類ごとに「ホールド中でも可／権限者の承認があれば可／不可」を定義します。典型的には、次工程への投入・加工・出荷は不可、隔離目的の移動とサンプリングは可、手直し着手は処置決定後のみ可、という区分になります。
予防的なホールドを気軽にかけられるようにすると、乱発されませんか。
乱発よりも、かけるべき場面でかけられないことのほうが実害は大きい、というのが原則です。そのうえで乱発への対処は、権限を絞ることではなく、理由コードの必須化と月次レビューで行います。理由コード別のホールド件数と、そのうち「解除時に問題なしと判明した」比率を集計すれば、過剰に反応している起票元や、逆にホールドが本当に品質事故を止めた件数が見えます。問題なし比率が高いこと自体は悪ではありません。それは保険が機能している状態であり、コストは解除の手間だけです。
出荷判定を自動化してよいのでしょうか。
条件チェックの自動化と、判定の自動化を分けて考えてください。全工程完了・全検査合格・ホールドなし・逸脱クローズといった条件の充足確認は、自動化すべき領域です。人手のチェックリストより速く、漏れがありません。一方、条件をすべて満たしたロットを自動で出荷可にするか、権限者の明示的な承認操作を残すかは、業種によります。規制産業では有資格者による判定行為そのものが要求されるため承認操作は残ります。非規制産業でも、条件全充足時のみワンクリック承認、条件未充足時は理由の確認画面へ、という設計にすれば、統制を保ったまま判定を数秒にできます。
