SPC異常検知AI導入｜タイ工場の管理図・アラート・受入設計

「SPC異常検知AIを導入したい」と相談する前に、どの工程を、どの単位で測り、どの信号で誰が止めるかを決めているでしょうか。管理図の上限・下限をAIの閾値と読み替えるだけでは、誤報で現場が疲弊したり、見逃しで流出を防げなかったりします。本稿はタイの製造拠点で、統計的工程管理（SPC）の基準線を尊重しつつ、複数信号の補助判定を加えるための導入設計をまとめます。扱うのは画像検査の良否判定ではなく、工程変動の早期発見と、アラート後の処置を実行できる仕組みです。

SPC異常検知AI導入で最初に決める「異常」の意味

管理図は、時系列の観測値と中心線、上方・下方管理限界を比べ、工程に特殊原因が生じた可能性を知らせる道具です。ASQの説明では、これらの線は過去データから求められます。NIST/SEMATECHの工程監視章も、現在と以前の工程状態を比較して是正が必要な兆候を知らせるというSPCの役割を説明しています。ここでの「管理外」は製品の規格外と同義ではありません。製品が仕様内でも工程の平均やばらつきが変化すれば管理図は警告し、逆に管理図が落ち着いていても仕様幅に対する能力が不足する場合があります。この二つを混同すると、AIに何を学習させ何を通知させるかが曖昧になります。

最初の会議では、異常を少なくとも三つに分けます。第一はセンサー故障、欠測、単位違いなどの測定異常。第二は工具摩耗、温度変化、供給材変更などによって工程の中心やばらつきが動く工程異常。第三は顧客規格から外れる、または出荷判定に影響する製品異常です。測定異常に対して機械を調整すると、正常な工程を壊しかねません。工程異常を製品不良だけで検出すると、先行して処置できる時間を失います。製品異常は隔離・判定の責任者を伴うため、単なるダッシュボード通知では不十分です。

AIの対象は「管理図で把握できる単変量の変化を置き換えること」ではありません。たとえば各温度が単独では管理内でも、温度と圧力の組み合わせが通常と異なるような場合に、二次的な注意信号を出す設計が考えられます。しかしその信号を採用する前に、通常のSPCで定義できる工程単位、測定系、反応計画を確立します。モデルスコアだけを見せられても、現場は止める根拠や次の測定が分かりません。

管理限界と規格限界を同じ線にしない

管理限界は工程の履歴に基づく変動評価の線で、規格限界は設計・顧客要求の線です。たとえば仮の寸法規格を9.90〜10.10 mmとし、安定時データから計算した管理限界が9.96〜10.04 mmだったとします。この数値は説明用の仮定で、実工場の推奨値ではありません。10.05 mmの測定は規格内でも工程の変化を示す可能性があります。9.99 mmが続いても測定系の校正不良があれば安心できません。画面では両限界を別色・別名称で表示し、通知理由にも「管理図信号」「規格逸脱」を分けて記録します。

アラートは品質判断の入口であって結論ではない

アラート発報を自動的な不良認定、設備停止、ロット廃棄と結びつける前に、危害と操業への影響を評価します。監督者が再測定し、必要なら対象品を保留し、設備状態を点検してから再開を許可する手順を作ります。高リスク工程で自動停止が必要なら、AIの確率スコアだけに依存せず、安全回路や既存インターロックとの責任境界を設計します。通知を読む人と決める人が異なる工場では、役割を画面と標準作業に明記します。

工程と測定単位を固定する：合理的な群分け

SPC 管理図 異常検知の前提は、時刻順の数値が何を代表するかを説明できることです。採取した5個の製品が同一機械・同一キャビティ・同一レシピの連続生産品なのか、別シフトの平均を混ぜたものなのかで、管理図の意味は変わります。NISTの工程監視資料は管理図と工程能力を別の論点として整理しています。導入時には「測定対象」「測定位置」「単位」「採取周期」「サブグループの取り方」「欠測の扱い」「測定器ID」を一枚の定義票にまとめます。

たとえば射出成形の重量を監視するなら、金型のキャビティを混ぜて平均する前にキャビティ別の分布を確認します。炉の温度なら、昇温・保持・冷却のフェーズを区別し、異なるレシピを同じ基準線に載せません。包装機のシール強度なら、ライン速度、材料ロット、ヘッド番号が同時に変わるかを把握します。データ量を増やすために異質な条件をまとめると、管理限界が広がって変化を見逃すことがあります。逆に細分化しすぎると基準線を安定して推定できません。工程の物理と運用を知る人が群分けの根拠を承認することが重要です。

この表の値はすべて設計の例示であり、採取数や間隔の標準値を示すものではありません。実際には変動速度、検査コスト、測定の独立性、工程停止の影響を踏まえて決めます。作業標準と端末入力欄が食い違えば、正しい統計手法でも監視は破綻します。

測定システムの信頼性を先に確認する

センサーの時刻ずれ、分解能不足、校正期限切れ、測定者間の方法差は、工程変化に見えるノイズを作ります。PoCではモデルの学習精度より先に、測定値の欠損率、再測定率、機器交換履歴を調べます。異常値を機械的に削除すると、本当の特殊原因まで消しかねません。生データ、補正値、採用値を区別し、誰がいつどの根拠で除外したかを残します。現場の紙記録から取り込む場合は、入力の丸め、単位、日付形式、シフト跨ぎの時刻も確認します。

工場内に複数のPLCや検査機がある場合、時刻同期を一つの導入課題として扱います。工程値と品質測定を紐付けるキーは、生産指示、ロット、設備、レシピ、時刻窓の組み合わせかもしれません。タイ工場と本社で同じ数字を見たいなら、時刻帯、権限、言語、承認履歴の仕様も必要です。データの収集・連結・分析を設計する広い論点は、既存記事品質データ管理システムの3層設計で整理しています。本稿ではその上に載せるSPC判定の境界に集中します。

基準期間と管理限界をどう決めるか

工程能力や管理図の計算に使う基準期間は、「直近なら何でもよい」わけではありません。保全直後、立ち上げ直後、レシピ混在、既知の設備故障を含む期間を無批判に学習すると、異常を正常として覚えます。一方、都合の良い最良日だけを選べば、日常操業に対して過敏な限界になります。選定期間、除外理由、承認者、使用した原データのスナップショットを保管します。基準線の作成時には、工程が統計的に安定しているかを検討し、特殊原因を調査したうえで扱いを決めます。NISTの工程安定性の節も、能力評価に先立つ安定性の確認を重視しています。

管理図の種類は、測定値の性質と群分けに合わせます。連続量の単一測定、短いサブグループ、欠点数・不良率を同じ図に押し込めません。個別値の図、平均と範囲の組み合わせ、属性値の図などの選択を、品質部門が理由とともに記録します。ASQは連続量の管理図で平均と範囲を組にして監視することを説明しています。導入ベンダーには、選んだ図の計算式、適用条件、再計算の契機、外れ点の扱いを提示してもらいます。「AIが自動選択します」だけでは監査や現場教育に耐えません。

工程能力Cpkはアラートの代用にならない

工程能力 Cpk 管理を導入会議で一緒に話すときは、評価期間と前提を分けます。Cpkは規格限界と工程分布の関係を要約する指標で、瞬間的な警報器ではありません。NISTの工程能力の説明は、能力分析を安定した工程の評価と結び付けています。安定していない工程に単一のCpkを掲げても、明日の性能を保証しません。規格幅、分布、測定系、工程安定性を確認し、数値の計算期間を明記します。

たとえば「Cpkが1.33以上なら安心」といった一律の合否線を、顧客契約や工程リスクの確認なしに導入しないでください。この数値は現場ごとに決まる条件であり、本稿は推奨閾値を提示しません。管理図の警告、規格外、能力指標、顧客への報告条件は、それぞれ別の列としてダッシュボードに置くと誤判断を減らせます。ISO 22514-1:2014は工程能力と性能に関する一般原則を扱う規格で、個別の受入閾値をこの記事が代わりに定める根拠ではありません。

基準線の凍結と再設定を運用に組み込む

安定していた工程が改善されて中心が変わった場合、古い限界のままでは警告が増えます。しかしアラートが増えたからといって自動的に基準線を広げると、劣化を隠します。再設定には、変更申請、前後の品質比較、対象レシピの確認、品質責任者の承認、旧版への復帰手順が必要です。モデルの再学習も同じ変更管理の下に置きます。比較画面では「旧基準で判定した場合」と「新基準で判定した場合」を一定期間並行表示し、通知件数と見逃し候補を確認します。この期間の長さは工程周期とイベント発生頻度によって決めます。

工程変動AI監視を二次レイヤーとして設計する

AIを使う意義は、単一の値だけでは見えにくい組み合わせ、遅れ、条件別の振る舞いを補助的に見つけることにあります。温度、圧力、電流、振動、速度、材料ロットを一緒に見る場合でも、最初から全信号を放り込んではいけません。対象の品質特性と物理的に関係する信号を、設備担当と品質担当で絞ります。データ漏えいに注意し、検査結果より後にしか分からない情報を予測の入力に混ぜないようにします。高いオフライン精度が、実際の警告時刻で利用できない後知恵から生じることがあります。

二次レイヤーの出力には、スコアだけでなく、比較対象の条件、寄与した測定値、参照したモデル版、発報した時刻、推奨される確認項目を添えます。ただし寄与度表示は因果関係の証明ではありません。調査担当者は、工程ログ、工具交換、材料変更、測定器状態と照らし、原因と対策を記録します。既存のAI品質管理のPoC・RFP・受入設計は品質全体の閉ループを扱っています。本稿の設計範囲は、その中でもSPC信号を発見から現場処置に接続する部分です。

モデルを使う前に単純な基準と比較する

「AI導入」を目的にして、管理図やレシピ別ルールより劣る判定器を入れないようにします。PoCでは少なくとも三つを同じ期間で比較します。第一に、既存の管理図だけ。第二に、管理図と説明可能な組み合わせルール。第三に、候補AIモデルを加えた構成です。各構成で、発報から発見までの時間、適切に調査すべき警報、誤報、見逃し、現場の確認工数を比べます。差が小さいなら、保守が容易な構成を選ぶ理由があります。

学習と評価は時系列で分け、同一ロットや同じトラブルの前後片を両方に跨がせないようにします。運転条件が変わる前のデータだけで後日の変化を評価するのが、実運用に近い見方です。希少な異常の検証は数か月で十分な件数が集まらないこともあります。その場合、「異常検知率の実測値」を断定せず、模擬故障、過去の再現可能なイベント、シャドー運用で何を確認できたかを分けて報告します。異常が起きなかった期間を「見逃しゼロの証明」と書かないことも大切です。

レシピ・設備・モデルの版を一緒に残す

同じ製品でもレシピ改訂、工具交換、設備改造、センサー更新で正常範囲が変わります。判定ログには、製品コード、工程、設備、レシピ版、管理限界版、モデル版、測定器版、データ処理版を一組で残します。後から「なぜこの時だけ警報が出たか」を再現できることが受入条件です。版が異なるデータを無条件に一つの母集団として再学習しないよう、データセットの抽出条件も保存します。モデルの適用範囲外の条件を検出したら、無理に正常・異常を断定せず「判定保留」に落とす設計もあります。

誤報と見逃しを一つの精度で隠さない

アラートの価値は、モデルの正答率だけでは決まりません。現場が調査できる件数、見逃した場合の損失、発報までの時間で評価します。誤報が多ければ作業者が通知を無視し、結果として真の異常も見逃します。逆に誤報を減らすため閾値を厳しくしすぎると、早期兆候を拾えません。受入時には、誤報率だけでなく、1シフト当たりの調査件数、確認にかかる時間、対象ロットを特定できた割合を測ります。これらの値は製品リスクと工程速度に応じて合意します。

仮に1日1000件の測定窓があり、真に要調査の窓が10件、候補方式が8件を検知し、正常窓20件にも警告したとします。これは説明用の架空データです。検知率だけ見ると8/10ですが、現場には28件の調査が届きます。各調査に10分かかるなら280分という仮の負荷になります。一方、2件の見逃しがどの工程・ロットに及ぶかも検証しなければ採用判断はできません。合否は単一指標ではなく、停止・隔離・再測定の運用が成立するかで判断します。

アラート優先度を処置内容と結び付ける

「注意」は次の定期確認で再測定、「調査」は担当者へ即時通知、「保留」は対象品を隔離して品質承認まで出荷を止める、というようにレベルごとに応答を定義します。これも一例であり、実際の停止条件は工程リスク評価に従います。色だけに頼らず、短い動詞と対象を表示します。端末が英語・タイ語・日本語で使われる場合は、訳語の揺れが判断を変えないよう、通知コードと作業標準の対訳表を管理します。通信断や端末停止時の代替手順も設計範囲です。

SPCアラート受入試験をRFPにどう書くか

調達仕様で「AIが異常を高精度に検知する」とだけ書くと、受注側と現場側で成功の意味が違います。RFPには監視する工程、対象品種、測定点、取り込み周期、群分け、表示言語、権限、既存のMES・ERP・設備との接続境界を記載します。管理図の計算とモデルの評価を分け、データ欠損時やレシピ未登録時の挙動も求めます。設備信号の収集可能性を見積前に確認し、API、ファイル、PLC接続のいずれかを明確にします。

表は契約文案のたたき台です。保証性能や法令適合の判断は対象工程と顧客契約に合わせて行ってください。発注側は「何を渡せば検収できるか」を先に決め、受注側には機能のスクリーンショットだけでなく、再現可能なデータと試験記録を求めます。

FATとSATを同じデモにしない

FAT（工場出荷前試験）では、用意したデータで管理図計算、閾値処理、欠測、重複時刻、異常な単位、レシピ変更、権限分岐、通知履歴を確認します。期待値を手計算または独立した計算で用意し、実装と照合します。SAT（現地受入試験）では、タイ工場の実設備からデータが時刻とロットに正しく結び付き、シフトを跨いで通知が届き、対象品の保留・解除と承認記録が動くことを確かめます。通信断、設備停止、再起動後の重複送信も現地で試します。

性能受入の指標は工程ごとに事前合意します。たとえば「警報表示まで何秒以内」「1シフトに許容する不要警報を何件以内」「重要イベントで何を見逃しとして数えるか」を決める必要があります。ここに固定値を書くと、ゆっくりしたバッチ工程と高速の組立工程を誤って同じ条件で評価することになります。過去イベントが少ない場合は、統計的な検知率を保証させるのではなく、検証可能な試験範囲と残余リスクを明記します。

シャドー運用で「鳴らすだけ」の期間を設ける

初期導入では、現行の品質手順を維持したまま新システムの警報を記録し、実際の工程記録と突き合わせます。これにより通知タイミング、誤報、見逃し候補、作業者の判断の違いを収集できます。シャドー期間に自動隔離・自動停止まで有効にするかは、工程ごとの承認が必要です。運用切替の判定会議には品質、製造、設備、IT、場合によって顧客品質担当を含めます。切替後も閾値とモデルの変更は記録し、一定期間は旧判定との比較を続けます。

タイ工場の導入体制とデータ境界

タイ拠点の導入で詰まりやすいのは、統計式よりも担当の境界です。品質部門は特性と反応計画、製造は採取と初動、設備保全はセンサーと機械状態、IT/OTは接続と権限、管理者は停止・再開と投資判断を持ちます。外部ベンダーは判定ロジックの説明と再現性を提供しますが、品質責任を肩代わりするわけではありません。委託範囲は、監視対象の変更、夜間の通知、障害時の連絡経路まで文書化します。

多言語の作業標準では、英語の統計用語を訳すだけでは足りません。「再測定」「製品保留」「設備停止」「品質承認」を現場で同じ行動として理解できるよう、画面の文言、紙の標準、教育例を揃えます。夜勤で品質担当が常駐しない場合、一次連絡先と保留中の製品置場まで決めます。モデルが警告しても、対象品がどこにあるか分からない仕組みは流出防止に直結しません。製品・ロットの追跡設計とSPCの接続点を明確にします。

データの境界もRFPに含めます。生データ、加工データ、モデル、特徴量、警報ログの所有・保存期間・持ち出し方法を定義します。クラウド利用時は通信断時の挙動と復旧後の再送、時刻順の回復を確かめます。モデルを変更する際に品質部門が承認できる画面・記録が必要です。システムからCSVなどでデータを取り出せても、レシピ版や時刻帯が失われれば移行性は限定的です。

導入費用を見積もる前のスコープ分解

SPC異常検知AIの費用は、モデル開発費だけでは決まりません。測定点の追加、センサー校正、時刻同期、古いPLCからの取得、データ連携、ダッシュボード、現場教育、保守が総額を左右します。見積を比較するには、同じ工程単位と受入試験を各社に渡します。単に「AI PoC一式」とすると、ある提案はCSV分析まで、別の提案はシフト通知と隔離連携まで含み、価格比較が意味を失います。

初期段階では、設備1台・品質特性1〜2件・主要レシピ1件など、現場が追える範囲に絞るのが実務的です。これは説明用のスコープ例であり、あらゆる工場への推奨件数ではありません。PoCの出口では、拡張に必要な追加測定、システム接続、現場工数、モデル保守体制を一覧にします。投資効果を試算するなら、削減できた廃棄数を仮定だけで売上に換算せず、実測期間、処置時間、誤報による負荷、流出防止の評価方法を明示します。

ベンダー比較で尋ねるべき質問

候補に、管理限界の計算根拠を現場が確認できるか、レシピ変更時の扱いをどう決めるか、通知先の欠員時にどうエスカレーションするかを聞きます。加えて、モデルが適用範囲外を示した時の挙動、再学習の承認、過去判定の再現、契約終了時のデータ移管方法を確認します。回答が「AIが自動で最適化します」に終始する場合は、入力・出力・承認点を具体化してもらいます。説明資料の美しさより、現地で同じ試験を再実行できることが大切です。

よくある質問

SPC管理図の異常検知とAIはどちらを先に導入すべきですか？

測定定義と反応計画を作り、適切な管理図で現在の工程を説明できる状態が先です。AIは複数信号の組み合わせなど、既存の方法で不足する問いに限定して検証します。管理図自体に誤った群分けや古い基準線があるなら、その上にモデルを載せても判断は改善しません。

工程能力Cpkが高ければ工程変動の監視は不要ですか？

不要とは言えません。Cpkは特定期間の工程分布と規格との関係を要約し、将来の特殊原因を消すものではありません。管理図で安定性を見て、規格逸脱と能力評価を別々に記録します。顧客の受入条件があれば、その定義と計算期間に従います。

AIの異常スコアが高いだけで設備を止めてもよいですか？

停止条件は工程リスク、既存の安全設計、製品隔離手順に基づいて決めます。モデルスコアの意味と誤報・見逃しを検証し、誰が再測定、保留、復帰を承認するかを定めてください。安全機能に関わる停止をAI判定だけに委ねる設計は、別途の安全設計と検証を要します。

SPCアラートの受入試験で最低限何を確認しますか？

管理図の計算再現、欠測・重複・レシピ変更の扱い、通知先と時刻、対象品の追跡、保留・解除の権限、版と元値の記録を確認します。FATでは既知データによる計算試験、SATでは現地設備とシフト運用の試験を分けます。検知率だけでは実務上の合否は決まりません。

異常データがほとんど無い場合はPoCを始められますか？

始められますが、「実際の異常を高率で検知できた」とは主張できません。測定品質、基準線、既知イベントの再現、模擬試験、シャドー運用で確認できる範囲を先に定めます。未確認の異常タイプと運用上の残余リスクを受入記録に明示します。

まとめ：先に反応計画、次に補助判定

SPC異常検知AI導入は、管理図を黒箱化する計画ではなく、測定定義、安定した基準線、現場の反応計画をつなぐ計画です。管理限界と規格限界を分け、設備・レシピ・測定器・モデルの版を残し、誤報と見逃しを現場工数と製品リスクの両面で測ります。RFPとFAT/SATでは、モデルのデモよりも、警報から隔離・承認・復帰までを再現できることを受入の中心に置いてください。

タイ工場で対象工程や測定点を絞る段階なら、既存の管理図・レシピ・通知手順を持ち寄ってお問い合わせください。データ取得の可否と受入条件から、無理のない検証範囲を一緒に整理できます。

導入後の定例レビューでは、警報件数の増減だけを成功指標にしないでください。警報が減っていても、通知経路の故障、測定点の欠測、基準線の無断更新が原因なら改善ではありません。毎月のレビューには、データ取得率、測定器の状態、未処理アラート、再発した特殊原因、対象品の隔離解除までの時間、レシピ・モデル変更の承認履歴を並べます。品質責任者と製造責任者が同じ記録を確認し、次の改善を決めることが、モデルを運用可能な工程監視へ変える条件です。比較期間や判定方法を途中で変えた場合は、前月比の数字が直接比較できないことも注記します。

また、警報を出さなかった時刻の記録も残すと検証しやすくなります。対象工程が稼働していたのか、データを受け取っていたのか、判定モデルがそのレシピに対応していたのかを区別できなければ、後から「見逃しなし」とは言えません。無発報を示す画面には最終受信時刻、最後に処理した測定窓、適用中の基準線とモデル版を表示し、監視停止時には別の障害通知を発報します。運用に必要な証跡は正常時から設計してください。

参考情報

• NIST/SEMATECH Engineering Statistics Handbook, Chapter 6: Process or Product Monitoring and Control（2003年公開。SPCと工程監視の基礎）
• ASQ, Control Chart（管理図の中心線・管理限界・使い方）
• NIST Engineering Statistics Handbook, 6.1.6 What is Process Capability?（工程能力の説明）
• NIST Engineering Statistics Handbook, 3.4.5 Assessing Process Stability（安定性評価）
• ISO 22514-1:2014, Statistical methods in process management — Capability and performance（工程能力・性能の一般原則）
• NIST Engineering Statistics Handbook, Process or Product Monitoring and Control（工程監視章）

*注：本稿の数値、工程名、設備名、測定間隔、調査工数は、明示したとおり説明用の仮定です。実在する顧客事例や性能実績ではありません。*