製造業の不適合品処置にAI照合を導入する方法｜MRB・出荷保留・FAT/SAT

受入検査や工程内検査で規格から外れた部品を見つけたとき、最初に必要なのは「AIが手直し・廃棄・特採を決めること」ではありません。対象の現物とロットを識別して隔離し、どの仕様のどの版で判定するかを確定し、権限を持つ担当者が処置を決めることです。製造業で不適合品処置へのAI照合を導入するなら、AIは証拠の不足や食い違いを早く見つける役割に限定し、その後のMRB（Material Review Board）決裁、MES・ERP・QMSの状態、出荷解除を一つの流れとして設計します。本稿では、タイの製造拠点も想定し、業務設計からRFP、FAT、SATまでを実務の順で整理します。

不適合品の「処置」と「是正処置」を分けて考える

不適合品の処置は、見つかったこの個体・このロットをどう扱うかを決める業務です。受入品なら供給元への返却、代替品への交換、選別、廃棄などが候補になり、工程内品なら手直し、修理、廃棄、顧客承認を伴う特採などが候補になります。ただし選択肢は製品仕様、顧客契約、適用規格、法規、社内権限規程に左右されます。特採を常に許せるわけではなく、修理と手直しも同じ意味ではありません。ここでは「手直し」は元の規定要求に適合させる作業、「修理」は意図した用途には使える状態にするが元の要求に完全には戻らない可能性のある処理、という実務上の区別を使います。自社の適用規格と顧客契約で定義を確認してください。

一方、是正処置は不適合の原因を調べ、再発を防ぐ活動です。不適合ロットを当日中に保留・処置する判断と、数週間かけて原因を分析する8Dは、関連していても別のワークフローです。現物の処置記録から是正処置案件へ参照を張る設計は有効ですが、原因が未確定であることを理由に現物の識別と隔離を遅らせてはいけません。是正処置の有効性評価は、別記事の製造業の是正処置とAIによる有効性評価で扱っています。外観写真から似た不良を探す作業も、処置決裁とは異なります。不良写真の類似検索とAI導入は分類・検索の参考にし、MRB権限の代替として扱わないでください。

不適合という言葉に対して、現場のシステムが一つの「NG」状態しか持たないことがあります。しかし実務には、検査で疑義が出た段階、判定確定、物理隔離済み、MRB審議中、処置作業中、再検査待ち、顧客承認待ち、出荷解除済みなどの違いがあります。この違いが見えないと、品質部門がまだ審議しているロットを倉庫が引き当てたり、手直し後の再検査がないままMESが工程完了にしたりします。AIの導入効果を論じる前に、現物の状態と情報の状態を合わせる必要があります。

本稿は、決裁前に証拠と適用仕様を照合し、どの処置ルートへ進む場合にも共通する「判断材料の品質」を高めるテーマです。手直し作業そのものの工程設計はリワーク管理システムの記事に、特採を認める条件や承認期限の詳細は特採管理システムの記事に譲ります。AI照合の導入で先に解くべき問題は、個々の処置方式を自動選択することではなく、MRBが誤った版や不完全な証拠で判断してしまう経路を閉じることです。

まず定義する対象範囲：受入・工程内・出荷前

初回導入の対象を「受入検査と工程内検査で発見した不適合品」に絞ると、判定時に参照する仕様、在庫・仕掛の状態、責任者を明確にしやすくなります。市場から戻った製品のRMA、保証判定、顧客クレーム対応は別の承認・物流・会計処理を持つため、最初から混ぜない方が要件が明瞭です。出荷前の最終検査で発見したものは、同じ現物保留ルールを使える場合だけ対象へ加えます。

受入品では、購買発注番号、サプライヤー、受入ロット、品番、受入日、図面・購買仕様の版、検査成績、現物ラベルを結びます。工程内品では、製造指図、工程、設備、シリアルまたはロット、投入部材、作業時刻、使用した作業標準と検査規格の版、測定器・校正状態、測定値を結びます。すべてのデータをAIへ投入するという意味ではありません。処置に必要な最小の証拠を、原本へのリンクと版情報を保ったまま提示できることが重要です。

対象単位も先に決めます。個体単位で追う製品にロット全体の解除操作を与えると、未確認個体まで出荷可能になります。逆にロット管理しかない材料でシリアル単位の画面を作っても現場で使えません。RFPでは「現物識別単位」「保留範囲」「部分解除を許す条件」「分割・併合時の履歴」を別項目にします。

設計の起点は識別・隔離・解除ゲート

検査員が疑義を登録した時点で、対象のシリアル・ロットと所在を確定します。バーコードやQRコードで現物を照合し、保留ラベルを貼り、隔離棚または明示した区画へ移動する運用が考えられます。重量物や設備内の仕掛品など物理移動できない場合は、設備や保管場所に明確な表示を付け、誤使用を防ぐ代替統制を定めます。画面の「保留」だけで現物が動いてしまうなら制御は完成していません。

システム側では、QMSが不適合案件の正本を持ち、MESが工程通過と次工程投入を止め、ERPまたはWMSが引当・出荷を止める、という責務分担を例として考えられます。既存システムの機能次第で正本の所在は変わります。重要なのは、どのシステムが「出荷可能」という最終状態を決めるかを一つにし、他システムへ遅延なく反映することです。画面上では解除済みでも出荷実行系が旧状態のまま、あるいはその逆、という競合は受入試験で必ず再現します。

解除ゲートは、単なる管理者ボタンにしない方が安全です。処置決裁、必要なら顧客承認、手直し・修理の作業実績、規定された再検査の合格、数量の照合、対象シリアル・ロットの一致、権限者の電子署名または承認履歴を条件として評価します。条件が一つでも欠ければ解除しません。例外的な緊急出荷を設けるなら、その権限、根拠、対象、期限、後追い確認を品質保証責任者と顧客要求に照らして個別に定義します。AIのスコアで解除を自動化する設計は避けます。

AI照合が見るべき「不足」と「矛盾」

AIに期待するのは、処置の候補を断定することより、審議に必要な情報がそろっているかを早く点検することです。たとえば、受入検査結果の品番と購買発注の品番が一致しない、測定値の単位が仕様の単位と異なる、図面の版が検査時点の有効版と異なる、測定器の校正期限が検査日より前、写真は添付されているがどの個体か結び付かない、といった状態を示します。ルールベースで確実に判定できる照合はまずルールに任せ、文章・図面の記述検索や複数資料の関連付けにAIを使う構成が堅実です。

「仕様の最新版を常に正」とはしません。あるロットには旧版が契約上適用されることがあります。検査日、発注日、製造指図の発行日、顧客の変更通知、適用開始条件を参照して適用版を確定し、それでも曖昧なら「版未確定」と表示して人へ渡します。AIがもっともらしい新版を選び、旧版で合格だった品を誤って不適合とすることも、その逆も避けるべきです。

画面には、AIの結論だけでなく、照合した項目、参照した原本の文書ID・版・ページまたは段落、検出した相違、未取得の証拠を並べます。信頼度の数値を出す場合も、その値だけで品質判断をしません。モデル出力が曖昧、原本への参照が切れている、OCRが読めない、異なる単位が混在する場合は「人手確認必須」に落とします。モデルの入力と出力、プロンプト・ルールの版、実行時刻、レビュー者の修正理由を監査ログに残せれば、後から判断を追跡できます。

AI照合を導入する前に、必須データの「無い」ことを正しく区別します。未入力、原本はあるがアクセス権がない、通信障害で取得できない、対象外として不要、の四つは意味が違います。最初の三つを「異常なし」に丸めると、AIの見逃しより危険な運用上の見逃しになります。エラー時は安全側の保留状態を維持し、回復後に再照合できるようにします。

仮に、部品Aの受入ロットで外径が規格外と記録されたとします。検査員は測定値を登録し、AI照合は購買発注の品番、図面の適用版、測定器ID、校正記録、測定単位を突き合わせます。ここで図面の版が違えば「不適合の程度」を推定する前に止めます。検査日の版が正しいと確認された後も、AIは「手直し可能」と確定せず、同じロットのほかの個体の測定状況と顧客指定特性の有無を提示します。MRB担当者は原本を見て影響範囲を判断し、処置を記録します。この例は設計例で、特定の工場で実測された事例ではありません。

別の例として、工程内でトルク値の外れを検出したが、センサーからMESへの転送が一時停止したケースを考えます。値の欠落は「合格」ではなく「取得不能」です。現物を保留し、設備の元ログ、作業時刻、校正状態を確認し、欠落した区間の個体範囲を確定します。AIは前後の記録から推測値を補間して審議の参考を示せても、その推測値を検査実測値として登録してはなりません。元ログが復旧できない場合の追加検査や廃棄などは、製品リスクと規程に基づく人の判断になります。

MRBの権限表をシステム仕様へ落とす

MRBは一律の組織名ではなく、品質、製造、設計、購買、営業などが案件の性質に応じて関わる意思決定の場です。権限表には、誰が不適合を登録し、誰が技術的影響を評価し、誰が手直し指示を承認し、誰が特採を承認し、どの条件で顧客承認を要するかを記載します。金額だけではなく、安全・機能・法規・顧客指定特性に関わるかで承認経路を分けます。AIはこの表に沿った候補のルーティングを支援できても、本人の権限を借りて最終承認することはできません。

処置を選ぶ画面では、選択肢ごとに必要な証拠を変えます。手直しなら承認された作業手順、対象数量、作業者、再検査項目を要求します。修理なら元の仕様からの差異と意図用途への適合評価、必要な顧客承認を要求します。廃棄なら物理的な処理とERP在庫の減算を結び、二重計上を防ぎます。特採なら対象範囲、逸脱内容、許容期間、承認者、顧客の書面承認が必要かどうかを明示します。これは一般的な設計例であり、各社のQMS・契約・規制に合わせて必須項目を確定してください。

決裁前の状態遷移を固定します。発見 → 保留 → 証拠収集 → MRB審議 → 処置承認 → 実施 → 再検査/確認 → 解除または廃棄完了 が基本例です。差戻し、追加測定、顧客回答待ち、部分数量処置、処置変更などの分岐を設けます。特に「承認済みだが作業未実施」と「作業済みだが再検査未完了」は出荷不可のままです。担当者が変わっても過去の承認を上書きせず、新しいイベントとして残す設計にします。

QMS・MES・ERP間のデータ契約

三つのシステムを単純に双方向同期すると、同じ項目の正本が増えます。RFPには、案件ID、品番、ロット・シリアル、数量、保留理由、処置コード、承認状態、再検査結果、解除時刻について「どこが正本か」「誰が更新できるか」「どこへ通知するか」「失敗時にどう再送するか」を表にします。例えばQMSの案件IDを共通参照キーにし、MESの製造指図とERPの在庫明細を紐付ける設計が考えられます。既存環境に別のID体系があるなら、その対応表と変更履歴が必要です。

同期は「成功したはず」を前提にしません。イベントに一意IDと版番号を付け、同じイベントの再送は一回だけ適用します。受信順が逆転した場合は古い状態で新しい状態を上書きしないようにします。ERPへの解除通知だけ失敗した場合、品質側で解除が承認されていても出荷側は保留を維持し、再送または人手復旧を求めます。逆にERPが解除されたのにQMSが保留のままという不一致はアラートを発し、監査対象にします。インターフェースの遅延許容時間は顧客の出荷リードタイムに合わせて実測して定めます。

数量の整合も重要です。100個の受入ロットのうち10個だけが不適合なら、残り90個を自動的に合格と推定してよいとは限りません。抜取検査の条件、同一原因が全数へ及ぶ可能性、ロット分割の社内規程を確認します。システムには「保留した10個」「追加調査中の90個」「処置済みの数量」を別に保持し、合計が元の受入数量と一致するかを検証します。手直し後に再び不適合になった個体を新しい案件として登録する場合は、元案件への参照を必須にし、件数の二重計上を防ぎます。

処置前の判定表を現場と合意する

「AIが判断する／人が判断する」という大きな分け方だけでは運用できません。照合項目ごとに、必要な原本、ルールで決められる条件、判断不能になる条件、担当者を決めます。例えば品番照合は購買発注、現物ラベル、検査票の三点が一致するかを機械的に確認できます。一点でも読めなければ一致とはせず、受入担当者へ戻します。図面の適用版は、日付だけでなく顧客の変更指示と移行ロットを見なければ決まらない場合があり、そのときは設計または品質部門にエスカレーションします。顧客指定特性に該当するかは、記号や文章の読み取りをAIが支援しても、最終的な判定は承認済みの特性リストとの照合が必要です。

この表は標準的な法定様式ではなく、要件定義のたたき台です。実際には製品群ごとに「仕様」「顧客承認」「再検査」の根拠が違います。表に載らない例外が出たときは、担当者が自由入力で解除できるようにするのではなく、例外を登録して権限者が業務ルールを承認し、その後でルールや検証データに反映します。少数の例外を隠すと、モデルが安定しているように見えても運用上の抜け穴が残ります。

セキュリティ面では、設計図面や顧客仕様を外部モデルへ送る条件を先に決めます。個人名や取引価格は照合に不要なら除外し、機密区分に応じて送信禁止・マスキング・閉域処理を使い分けます。AIの参照範囲は工場・顧客・製品ごとに権限を分離します。原本の改ざん防止と追跡可能性について、NISTは製造データの信頼性・トレーサビリティを扱う実務ガイダンスを公開しています。AI機能の有無にかかわらず、版と出所の管理は土台です。

導入前にそろえるデータと業務ルール

最初のPoCで大量の過去案件をモデルに投入するより、既存の不適合票を一定数抽出して「正しい参照が可能か」を確認します。品番が手入力で揺れている、図面番号はあるが版がない、写真ファイル名から個体が追えない、測定値がPDFの画像にしかない、といった欠落はAI以前の課題です。ここを補うためにOCRや名寄せを使う場合も、誤結合したときの検出手段を用意します。

例として、対象を一つの受入部品群と一つの工程内検査に限定し、直近の処置済み案件から代表例を選ぶ方法があります。正常な記録だけでなく、仕様改訂直後、部分数量のみ保留、計測単位違い、再検査の失敗、顧客承認が必要な特採、原本欠落、同一ロットの複数案件を含めます。件数や期間は工場の発生頻度によって決めるべきで、ここで特定の「標準件数」を示す根拠はありません。

成功指標は「AIが処置を何件決めたか」ではなく、証拠不足の検出率、誤警報率、MRBまでの待ち時間、差戻し回数、保留品の誤使用・誤出荷件数、承認履歴の検索時間、同期不一致の解消時間などに置きます。分母を「案件数」か「照合項目数」か決め、導入前後で対象範囲をそろえます。現場の短縮時間だけで投資回収を計算せず、誤出荷防止という低頻度・高影響の結果は別に評価します。便益の数値は自社の実測値を使い、他社事例の数字を自工場の予測値として転用しません。

RFPに書くべき必須要件

RFPでは「AIで不適合処置を自動化」と一行で済ませず、業務、データ、権限、連携、試験を分けます。ベンダーに対しては、画面デモだけでなく実データに近いサンプルと異常系を用いた動作を求めます。

ベンダー比較では、機能数よりも「欠落時に止まるか」「状態不一致を検出できるか」「後から説明できるか」を重視します。日本語・タイ語の現場運用が必要なら、ラベル、作業指示、差戻し理由の二言語表示や検索も要件にします。ただし一つの不適合コードに言語別で別の意味が割り当たらないよう、コード体系は共通にします。ベトナム拠点への横展開を見込む場合は、表示言語と承認権限の地域差も別に扱います。

FAT・SATで「通ってはいけないもの」を試す

FATはベンダーまたは工場出荷前の環境で、定義した要件を再現する試験です。SATは据付・接続後の実サイトで、実際の端末、ネットワーク、バーコード、既存システム、現場の役割を含めて確認します。IEC 62381:2024はプロセス産業の自動化システムを対象にFAT・SATなどの要件とチェックリストを示しています。本件の全工場へそのまま適用されるという意味ではありませんが、試験範囲と責任を事前合意する考え方は参考になります。

FATでは、同一ロットに二つの不適合案件がある、旧版が正しいロットがある、AIの参照元が取得できない、承認権限がない、特採に顧客承認がない、手直し作業だけ終わって再検査がない、といったケースを準備します。期待結果はすべて「保留を維持」です。正常系として、正しい承認と作業・再検査がそろったときだけ指定数量を解除できることも確認します。AIの検出性能は、現場の有識者が独立に付けた正解ラベルと照合し、見逃しと誤警報を別に集計します。

SATでは、現場スキャナで誤ロットを読んだ場合、ネットワークを切断した場合、ERP連携が遅延した場合、夜勤の権限者が不在の場合、保留棚から誤ってピッキングを試みた場合を試します。紙の代替運用を許すなら、紙の保留票からデータ復旧までの責任と二重解除防止を検証します。試験記録には入力、期待結果、実結果、証拠のスクリーンショットやイベントID、欠陥、再試験結果、承認者を残します。合否を「画面が表示された」だけで判定しません。

異常系で確認したい五つの失敗経路

第一に、仕様書の取得には成功したが、取得したのが別の顧客向けの版だった場合です。文書名だけが似ていても、顧客、品番、適用開始条件が一致しない限り審議資料へ自動採用しません。第二に、AIが参照した段落が正しくても、OCRで公差のプラス・マイナス記号を読み違えた場合です。重要な数値は元画像と構造化データを並べ、人が確認できるようにします。第三に、ネットワーク復旧後に保留イベントと解除イベントが逆順に届いた場合です。イベントの版と発生時刻を比較し、古い解除が新しい保留を覆さないことを確認します。

第四に、MRBの承認者が退職または異動して権限を失った後、過去の承認画面が再利用された場合です。履歴を消さず、現在の権限で新しい承認を要求します。第五に、同じロットの一部数量だけ再検査に合格し、残りが未検査のままの場合です。合格分だけの解除が顧客契約と社内手順で許されるなら対象個体と数量を限定し、許されなければ全体を保留します。これらはAIの正答率とは別の受入基準であり、連携、権限、数量管理の設計を検証するために必要です。

試験で不合格が出た場合は、単に画面のメッセージを直して終了にしません。誤った原本を選んだ理由、版管理の欠落、権限キャッシュの更新周期、イベント処理順、数量分割のデータ構造など、再発する条件を分析します。修正後は同じケースだけでなく、近接する正常ケースも再試験します。たとえば「旧版を拒否する」修正が、旧版の適用が正しいロットまで止めてしまわないかを確かめます。FATとSATの試験票を同じ案件ID・要件IDに紐付けると、設計変更後にどの試験をやり直すべきか追跡できます。

AI部分については、導入前だけでなく運用中の監視と再評価も要ります。NIST AI RMFはAIの役割・責任の定義、文書化、展開前と運用中の試験・評価を勧めています。誤検知が増えた、仕様文書の体裁が変わった、新製品で資料が足りないといった変化を検知したら、モデル更新を即時本番反映するのではなく、影響範囲を確認してから再試験します。閾値やプロンプトの変更も版管理対象です。

段階導入の順序と現場での定着

第一段階では現物識別、保留、MRB承認、解除ゲートを固めます。AIなしでも誤出荷を止められる状態を基準にします。第二段階で、文書ID・版・検査結果の照合と不足通知を導入します。第三段階で、過去案件の検索や自然言語での証拠整理を追加します。いずれの段階でも、AIの推奨を現場で無批判に受け入れないよう、原本を一画面で開ける操作と訂正理由の入力を用意します。

タイの工場では、日本本社の品質規程、タイ語の現場指示、英語の顧客仕様が同時に存在することがあります。翻訳された表示の語句を先に承認し、品番、処置コード、承認権限、版番号は言語をまたいでも同一IDで管理します。「特採」と「顧客承認済み」の意味が画面ごとに違うと、翻訳の問題が品質事故になります。教育では操作手順に加え、保留中にしてはいけない作業、AIの指摘が間違っているときの訂正方法、通信障害時の連絡先を確認します。

導入後は、保留件数や滞留日数だけを追って現場に早い解除を促さないことが大切です。滞留の原因を「証拠待ち」「設計判断待ち」「顧客承認待ち」「手直し待ち」「連携障害」などに分ければ、改善すべき工程が見えます。AIの警告を毎回無視する状態なら、モデル精度、ルール、画面表示、担当者教育のどこに原因があるかを調べます。警告を消すだけでなく、誤警報を検証データに戻して改善します。

運用開始後の変更管理をあらかじめ決める

製品図面や検査規格が改訂されるたびに、照合ルールが自動的に正しく更新されるとは限りません。図面改訂通知を受ける部署、適用開始ロットを登録する担当者、旧版で製造中の仕掛品を確認する担当者、AIの検索対象を更新する担当者を分け、更新がそろうまで新旧双方の版を追跡可能にします。AIのプロンプトだけを先に変えると、画面上の説明とMESで有効な検査規格がずれる可能性があります。変更票には対象製品、変更前後の版、適用開始条件、影響を受ける未処置案件、試験結果、承認者を記録します。

月次など自社で定めた周期で、AIの警告が実際に不足・矛盾を示していた割合と、見逃した案件を品質部門がレビューします。警告数だけではモデルの良し悪しは分かりません。検査する製品構成や文書形式が変われば、同じモデルでも結果が変わります。レビュー対象には、AIを使わず人が見つけた証拠不足、AIに指摘されたが担当者が取り消した案件、後に出荷保留へ戻した案件を含めます。理由を分類すれば、文書の版管理、OCR、検索、権限、インターフェースのどこを直すか選べます。

監査の際には「AIを導入したから安心」と説明するより、無作為に選んだ一案件について現物ラベルから出荷解除までを逆向きに追えることを示します。出荷伝票からERP在庫明細、MESの工程記録、QMSの案件とMRB決裁、測定結果、適用仕様の版へ戻り、各時点の担当者と時刻を確認できるかを試します。履歴のリンクが一つでも切れていたら、画面にきれいな要約が表示されても追跡可能とは言えません。NISTの製造データに関する資料も、データの出所と信頼性を扱うものであり、個別工場の処置判断を代行する規程ではありません。

運用責任者は、品質保証だけに置かず、現場と情報システムの責任分界を文書にします。検査員は現物識別と測定原本の登録に責任を持ち、品質担当者は証拠の完全性と隔離を確認し、設計担当者は仕様の適用と技術的影響を評価し、MRB権限者が処置を決裁します。情報システム担当者は連携失敗の検知と復旧を受け持ちますが、品質上の保留を勝手に解除する権限は持ちません。夜勤や休日に権限者が不在なら、代理承認の範囲を事前に定めるか、保留を継続します。「担当者が連絡を取れなかった」ことを解除理由にしない仕組みが要ります。

現場からの訂正申請も管理します。検査員が誤ったロットを選んだと気付いた場合、元の記録を消してなかったことにするのではなく、訂正理由、正しい現物、影響した出庫・工程履歴を残します。AIが誤った文書を参照した場合も、画面上の警告を消すだけでは不十分です。文書索引の誤結合を直し、同じ誤参照が他の未処置案件に及んでいないか再検索します。見直しで別ロットへの影響が分かったら、対象を追加保留してMRBへ報告します。この一連の訂正過程を追跡できることが、単純な作業時間短縮より価値を持つ場合があります。

また、運用開始直後には二重記録が起こりがちです。紙票、表計算、QMSへ同じ情報を別々に記入するなら、どれが正式記録で、どの時点で転記を終えるかを決めます。暫定期間中は、紙の現物札と電子保留の照合をシフト交代時に行い、不一致を発見したら出荷側を安全側に止めます。安定後に紙を減らすとしても、停電や通信断に備えた代替手順と復旧時の照合を残します。AI画面の導入だけで現場の掲示や倉庫のピッキング制御が変わらないなら、業務全体の安全性は上がりません。

導入効果の報告では、数値の定義と観測期間を明示します。たとえば「MRBまでの時間」は、不適合の発見時刻から証拠一式がそろって審議可能になった時刻までなのか、決裁時刻までなのかで結果が変わります。夜勤や休日を含む経過時間と稼働時間も分けます。「証拠不足の検出率」なら、有識者が後から確認した不足案件を分母にし、AIが正しく指摘した件数を分子にします。誤警報率も同じ母集団で追います。案件が少ない期間に百分率だけ示すと変動が大きいため、件数も併記します。誤出荷がゼロだったという結果だけでは統制が働いた証明にならないので、保留品のピッキング拒否記録や解除条件の監査結果も確認します。こうした測定方法をRFPと試験計画に先に書いておけば、導入後に都合のよい指標だけを選ぶことを防げます。

よくある質問

不適合品の処置判定をAIに任せられますか？

証拠の収集・照合、処置候補に必要な条件の表示、類似案件の検索は支援できます。しかし最終的な手直し・修理・廃棄・特採の決裁と出荷解除は、製品リスクと顧客要求を理解した権限者に残す設計を勧めます。AIが「問題なし」と出しただけでは、実物の隔離や承認を省略できません。

MRB判定支援システムはQMSだけで完結しますか？

不適合記録と承認だけならQMSで管理できる場合があります。しかし保留品がMESで次工程へ流れたり、ERPで引当・出荷されたりするなら、実行系との状態連携が必要です。どこを正本とするかは既存システムの機能と運用で決めます。

手直し、廃棄、特採をAI照合する際の優先順位は？

最初に、対象の識別と保留が確実であることを確認します。次に、適用仕様の版、測定証拠、権限と顧客承認条件を照合します。その後で各処置の実施条件と再検査を確認します。処置名の推定精度より、必要な証拠が欠けている案件を止める性能を優先します。

不適合品AIのRFP・FAT・SATでは何を確認しますか？

RFPに対象単位、状態遷移、正本、承認権限、原本の版、AIの判定不能時の動作を明記します。FATでは旧版、証拠欠落、権限外、通信断、重複イベントを試し、SATでは現場端末、実在庫、実ネットワークと既存システムの動きを確認します。「条件が欠けたら解除できない」が中心の合否基準です。

まとめ

不適合品処置へのAI導入では、現物を識別・隔離し、仕様と証拠の版をそろえ、AIが不足や矛盾を見つけ、権限者がMRBで処置を決め、作業・再検査・承認が完了して初めてMES・ERPの解除ゲートを通す流れが核心です。導入の成否はAIモデル単体の精度だけでは決まりません。状態の正本、顧客承認、障害時の保留、監査証跡、FAT/SATの異常系まで一体で設計することが必要です。

受入または工程内の不適合品について、現行の保留・MRB・出荷解除の流れを整理する段階でも、TOMAS TECHへご相談いただけます。既存のQMS、MES、ERPと現場の紙運用を見ながら、AI照合を置くべき箇所と先に整えるべき統制を一緒に検討します。

参考情報

• ISO 9001:2026 Quality management systems — Requirements — 適用する品質マネジメントシステム要求事項と版の確認先。個別の処置手順は自社の適用規格・顧客契約で確認する。
• NIST AI Risk Management Framework — AIリスク管理の枠組み。
• NIST AI RMF Core — 役割、文書化、評価・監視に関する具体的な項目。
• NIST Recommendations on Ensuring Traceability and Trustworthiness of Manufacturing-Related Data — 製造データの出所と信頼性。
• NIST IR 8536 Supply Chain Traceability: Manufacturing Meta-Framework — 製造サプライチェーンにおける追跡データの出所と関連付けを扱う概念的枠組み。2026年9月公開。
• IEC 62381:2024 Automation systems in the process industry — FAT/SAT/SIT — プロセス産業向け試験範囲と責任の参考。

※本文の業務フロー、データ項目、試験ケースは導入設計例です。製品固有の法規・顧客契約・適用規格に基づく判断の代わりにはなりません。