チョコ停対策を30日で検証｜タイ工場の見える化設計

タイ工場でチョコ停対策を進めるとき、最初から「停止回数を何％減らす」と置くと、かえって改善を誤ることがあります。数秒から数十秒の停止には、センサー待ち、部品の姿勢直し、上流の材料切れ、下流の詰まり、品質確認、段取り、正常なサイクル完了、通信欠損が混在するからです。必要なのは推測した回数ではなく、同じ境界で再現できるイベント記録です。本稿では、チョコ停の見える化、設備稼働監視、理由コード、30日PoC、RFP、FAT/SATを一つの導入設計として整理します。

先に結論：チョコ停対策は「検知」と「理由」を分けて設計する

効果のあるチョコ停対策は、次の二層を混ぜません。

1. 事実層：いつ状態が変わり、何秒続き、前後のカウントやアラームがどうだったか
2. 解釈層：なぜ止まったと判断し、誰が確認し、理由コードをどう確定したか

自動検知だけを精密にしても、正常待ちや通信断を設備原因へ入れれば「精密な誤集計」になります。反対に、運転員が理由だけを入力しても、停止の開始・終了が曖昧なら、長さと影響を再現できません。まず生の状態変化を保存し、その後で自動推定理由と確認済み理由を分けて持つことが重要です。

また、「何秒以下がチョコ停」という全工場共通の秒数は、本稿では置きません。通常サイクルが3秒の工程と90秒の工程では、同じ10秒停止の意味が違います。工場が工程特性と改善目的に基づいて帯域を所有し、変更履歴を残します。ISO 22400-1は製造オペレーション管理のKPIに関する業種中立の枠組みと用語を提供しますが、一つの秒数を採用すれば自動的に規格準拠のOEEになる、という意味ではありません。

なぜ短い停止は見逃され、集計すると揉めるのか

運転員は復旧を優先する

短い停止の現場では、運転員の正しい優先順位は安全確認と復旧です。停止のたびに端末を開き、階層メニューから理由を選ばせると、入力遅れ、まとめ入力、無回答が増えます。入力率の低さを個人の問題にせず、イベント終了後の短い確認ウィンドウ、設備近傍の少数候補、後から監督者が見直せる仕組みにします。

PLCの状態だけでは生産文脈が足りない

コントローラは運転・停止・アラームを知っていても、材料待ちが計画されたものか、下流の品質保留が原因か、製品切替中かを必ずしも知りません。OPC UA for Machine Toolsの時間ベースKPIに関する仕様も、状態時間から期間を導く一方、外部文脈がコントローラで得られない場合を想定しています。したがって、設備状態にジョブ、品種、運転モード、前後設備、品質状態を結び付ける必要があります。

「停止回数」の境界がシステムごとに違う

停止信号が0.5秒だけ戻って再び落ちたとき、1件か2件か。上流停止の3秒後に対象設備も停止したとき、双方を原因として数えるのか。ネットワークが12秒切れた間を停止とみなすのか。境界規則が無ければ、PLC画面、稼働監視システム、日報で件数が一致しません。先にイベント再構築規則を合意し、件数はその結果として出します。

チョコ停の定義は一つの閾値ではなく帯域ポリシーにする

閾値は設備ベンダーが固定する値ではなく、工場側が所有するポリシーです。初期案は次のように複数帯域で持ちます。数値はあくまで設定例であり、各工程の通常サイクル、信号品質、復旧行動から検証してください。

例えば通常サイクル40秒の設備では、サイクル完了に伴う短い状態遷移を停止として数えない規則が必要です。高速搬送では2秒でも複数個に影響するかもしれません。一方、手作業供給を含む工程では15秒の待ちが標準作業内という場合があります。閾値は「短いほど高度」ではなく、正常と異常を安定して分け、現場が説明できる値がよいのです。

ポリシーには、帯域値だけでなく、適用設備、適用モード、発効日、承認者、旧版との比較方法を書きます。途中で値を変えた場合、変更前後の件数を単純比較しません。旧ルールで再計算できる生データを残すか、ダッシュボードに定義版を表示します。

設備稼働監視で先に保存する最小イベントモデル

OPC UA for MachineryのMonitoring building blockは、状態、ヘルス、プロセス、消費情報への入口を整理し、機械状態や運転モードの参照を示しています。実装プロトコルがOPC UAか別方式かにかかわらず、チョコ停の見える化では次の生データを先に保存します。

設備稼働監視の土台を詳しく確認する場合は、設備稼働ログ収集の実務を参照してください。本稿はログ基盤全般ではなく、短時間イベントの再構築と理由確定へ焦点を絞ります。OEE全体の改善順序は工場OEE改善ガイドと接続し、チョコ停の帯域だけでOEEの定義を置き換えないことが大切です。

時刻品質は停止理由と同じくらい重要

PLC、エッジ端末、SCADA、サーバーの時計がずれると、上流停止と下流停止の順序が逆転します。各イベントに収集時刻だけでなく、可能なら発生源時刻、時刻同期状態、受信遅延を持たせます。FAT/SATでは同期を意図的に外し、画面に警告が出るか、集計から「時刻不健全」を除外できるかを確認します。

生データを消して集計値だけ残さない

閾値や統合規則は改善中に変わります。日別の件数と停止分だけを保存すると、新ルールで過去を再計算できません。少なくともPoC中は、状態遷移とルール版、分類結果を結び付け、同じ入力から同じイベント一覧を再現できるようにします。

イベント検知と理由分類を分離する

イベント検知エンジンは「いつ止まったか」を決め、理由分類は「なぜ止まったか」を決めます。データ構造では次を分けます。

• auto_reason：ルールやモデルが推定した理由
• auto_confidence：推定の信頼度または根拠
• confirmed_reason：運転員・監督者が確定した理由
• confirmed_by / confirmed_at：誰がいつ確認したか
• comment：例外説明や改善メモ
• reason_code_version：使用した理由体系の版

自動理由を人の確認で上書きして消すのではなく、両方を残します。これにより「センサー異常と推定したが、実際は部品姿勢だった」という学習材料が残ります。確認期限を過ぎても無理に原因を埋めず、「未確認」とします。

運転員確認は少ない操作で終わらせる

画面には、対象イベント、開始・終了、長さ、前後状態、推奨理由を表示し、頻出理由を上位に出します。ただし自動推定を既定選択にして無意識に確定させない設計も検討します。長い自由記述は例外時だけにし、訂正可能時間と監督者レビューを設けます。

理由コードは小さく始め、変更統制する

最初から100種類を作ると入力が揺れます。PoCでは二〜三階層、現場画面は一度に選べる候補を少数にします。

コードの追加・統合・廃止は、申請理由、影響する設備、発効日、旧コードとの写像、承認者を記録します。「その他」が増えたら自由記述を読み、新コードを足すか、画面順序を直します。不明を禁止すると、入力者は近い理由を選び、見かけ上の完全性だけが上がります。

重複・振動・通信断をどう一件にするか

稼働監視システムの比較では、ダッシュボードの見栄えよりイベント再構築規則を確認します。

1. 重なる中断

一つの停止中に複数アラームが出ても、設備停止時間を重複加算しません。親イベントに複数の証拠を紐付けます。原因確定とアラーム件数は別指標です。

2. 急速な停止・再開振動

信号が短時間に往復する場合は、原信号を保存したうえで、設定した結合間隔以内を一件にまとめる選択肢を持ちます。結合前後の件数を監査できることが必要です。物理チャタリングをソフトで隠すだけにならないよう、入力品質も調べます。

3. ネットワーク欠損

通信が切れた区間は、停止とも運転とも断定しません。最後の値を延長表示する場合も、品質をbad/unknownにします。復旧後にエッジ側のstore-and-forwardで履歴を回収し、同じevent_idの再送は重複排除します。回収不能なら「データ品質失敗」として別管理します。

4. 計画停止と正常待ち

休憩、段取り、清掃、計画保全、品質承認待ちを、適用カレンダーと運転モードで識別します。ただし計画と登録されていても実際の開始・終了は記録し、計画時間との差を確認できるようにします。

5. starvation、blockage、伝播

対象設備が材料不足で止まった場合、上流の最初の停止を根イベントとして関連付けます。下流満杯によるblockageも同様です。各設備に同じ損失を計上するとライン合計が膨らむため、「設備視点の停止」と「ライン根因損失」を別表示にします。

透明な計算例：回数ではなく停止秒と分類品質を見る

以下は設計を説明するための架空の例で、業界ベンチマーク、顧客実績、期待効果ではありません。通常サイクル40秒の対象設備、1シフト480分、計画休憩30分、計画段取り20分とします。

計画生産時間は 480 - 30 - 20 = 430分、すなわち25,800秒です。自動検知は172候補を出しましたが、正常サイクル境界、重複、計画待ち、通信欠損を規則で除外・統合した結果、確認対象は126件になりました。

別クラスの停止が38.0分なら、説明用の稼働時間は 430 - 22.2 - 38.0 = 369.8分。この例で計画生産時間を分母とする可用率を計算すれば、369.8 ÷ 430 = 86.0%です。ただしこれは例示式であり、実際のKPIでは工場の時間モデル、除外規則、ISO 22400等との対応を確認してください。

理由別に見ると、センサーチャタリング34件・204秒、部品姿勢28件・392秒、下流blockage 22件・440秒、その他42件・296秒で、合計は126件・1,332秒です。仮に最初の二理由の停止秒を半減できたなら、削減候補は (204 + 392) ÷ 2 = 298秒 = 約4.97分/シフト。新しいチョコ停時間は 22.2 - 4.97 = 約17.23分、他条件が同じなら稼働時間は約374.77分、可用率は 374.77 ÷ 430 = 約87.16%です。

さらに2シフト/日、22稼働日/月で同じ条件が繰り返され、改善が完全に維持されたという強い仮定を置くと、時間換算は 4.97 × 2 × 22 = 約218.7分、約3.6時間/月です。これは投資回収の約束ではありません。実データで再現性、品質影響、人の追加作業、保全費、ボトルネック性を確かめてから金額へ換算します。

この例が示すのは、172という生の候補数をKPIにしないことです。統合規則、除外理由、確認率、不明率、データ品質率とともに126件を説明できて初めて、改善前後を比較できます。

30日PoC：2〜3設備でイベント再現性を先に証明する

全工場展開の前に、ボトルネック工程を一つ選び、その工程を構成する2〜3設備で30日PoCを行います。目的は大幅改善を約束することではなく、イベントを再現でき、運転員が無理なく理由を確認でき、改善会議に使える証拠を作れることの検証です。

日程例

最初のシャドー期間は、画面値を人事評価や正式KPIに使いません。誤検知が残る段階で評価へ使うと、現場がシステムを信用しなくなります。週1回、製造、保全、品質、IT/OT担当で理由コードと未確認イベントをレビューし、ルール変更を版管理します。

PoCの受入基準は案件ごとに数値化する

次は受入項目であり、数値目標そのものは設備と現状調査に基づき発注側が決めます。

• 選んだテスト区間を再生すると同じイベント一覧になる
• 開始・終了、長さ、設備状態、品種、カウントが原データと一致する
• 通信断後に欠損、回収、重複排除を説明できる
• 時刻同期異常が可視化され、健全データと分けられる
• 自動理由と確認済み理由の差分・訂正履歴が残る
• 権限のない利用者が理由体系や閾値を変更できない
• 運転員の確認操作時間と未確認率を測定できる
• CSV/API出力から第三者が集計を再計算できる
• ロールバック手順を実行し、元構成へ戻せる

「検知率99%」のような数字を置く場合は、真値をどう作るか、どの時間帯・モードを母集団にするか、許容誤差をどう扱うかも同時に定義します。数字だけの合格条件は避けます。

RFPで比較する設備稼働監視システムの要件

見積依頼では、ライセンス名や画面数だけでなく、以下を同じ様式で回答してもらいます。

1. 接続範囲：対象PLC、プロトコル、読取周期、エッジ構成、追加ハードウェア
2. イベント再生：指定した原データから同じイベントを再生成できるか
3. 時刻同期：同期源、ずれ監視、タイムゾーン、同期喪失時の扱い
4. 切断復旧：store-and-forward容量、再送順、欠損表示、重複排除
5. 分類統制：理由コードの版、承認、適用日、自動/確認済み理由の保持
6. 監査証跡：誰が閾値、理由、イベントを変更したか
7. 権限：運転員、監督者、保全、管理者の役割分離
8. 出力：CSV、API、時刻・品質を含む原イベントの取得可否
9. 性能：表示遅延、収集遅延、ピークイベント量、保存期間
10. 保守：バックアップ、復旧、更新、ロールバック、遠隔支援条件

安価な案が悪いのではなく、比較範囲が違うことが問題です。PoC費用、現地作業、PLCタグ整備、ネットワーク変更、教育、クラウド費、保守、将来設備追加の単価と前提を分けます。金額は工場調査なしに一般化しません。

FAT/SATで画面ではなく証拠を受け取る

FATでは、模擬イベントと保存済み原データを使い、閾値境界、重複、振動、通信断、時刻ずれ、権限、監査、エクスポート、復元を試します。SATでは、実設備、実ネットワーク、現地時刻同期、実ジョブ、上流・下流伝播、運転員操作を確認します。

受入証拠には、テストID、日時、対象設備、ソフト/設定/理由コード版、入力、期待値、実測値、判定、未解決事項、承認者を含めます。スクリーンショットだけでなく、機械可読なイベント出力と設定バックアップも受け取ります。

OTセキュリティ：監視のために制御経路を増やさない

NIST SP 800-82 Rev. 3は、OT固有の性能、信頼性、安全上の要件を考慮したセキュリティ指針を示します。設備稼働監視を導入する際も、便利だからと監視サーバーからPLCへ書き込める経路を安易に追加しません。実現可能なら読取専用収集を優先し、書込が必要な場合は用途、許可信号、認証、変更手順、失敗時挙動を別途設計します。

最低限、OTゾーンと通信経路、ファイアウォール規則、利用アカウント、秘密情報の保管、遠隔接続の開始・承認・終了、操作ログ、パッチ方針、バックアップ、ロールバックを文書化します。クラウド接続の有無だけで安全性を判断せず、データがどこからどこへ、誰の権限で動くかを図示します。PoC用の一時アカウントや許可規則には終了日を設定します。

改善会議で見るべき指標

チョコ停の件数と秒数に加え、データと運用の健康状態を同じ画面で見ます。

• 候補イベント数、統合後イベント数、除外数と理由
• チョコ停合計秒、帯域別件数、品種・モード別分布
• 確認済み率、未確認率、不明率、訂正率
• source quality不良時間、clock health異常時間、回収不能件数
• 上流・下流へ伝播した時間と根イベント
• 理由上位のParetoと、前週からの増減
• 対策実施日、対象設備、ルール変更版、効果の持続

件数だけを減らすと、二つのイベントを一つに結合する設定変更で「改善」できてしまいます。停止秒、良品数、品質保留、安全、運転員作業を併記し、ルール変更前後を分離します。大停止の分析は長時間ライン停止の根因分析、即時通知の設計は設備アラーム通知システムと役割を分けます。

タイでの投資検討とBOI情報の扱い

タイBOIのSmart and Sustainable Industry施策の公開情報では、対象となる改善投資に最低100万THB、条件に応じて適格投資額の50%を上限とする3年間の法人所得税免除、国内自動化産業との連携が30%以上の場合は上限100%となる枠組みが示されています。ただし、対象活動、申請時期、投資内容、国内連携の判定など、適格性は案件ごとに確認が必要です。本稿のPoCや稼働監視が自動的に対象になるという意味ではありません。必ずBOIまたは有資格の専門家へ最新条件を確認してください。

BOI/OSOSの2026年上期発表では、Smart and Sustainable Industryの申請は132件、投資額は約172億THBとされています。これはタイで改善投資の申請が行われているという市場背景であり、個別のチョコ停対策のROIを証明する数字ではありません。補助・税制を前提にせず、まず現場データと受入基準で投資判断を組み立てます。

導入判断チェックリスト

データ境界

• [ ] 対象設備とボトルネック工程を選んだ
• [ ] 正常サイクル、計画待ち、停止候補の状態を定義した
• [ ] 時刻源、source quality、通信欠損の扱いを決めた
• [ ] 原状態と再構築イベントを両方保存できる

現場運用

• [ ] 理由コードを少数から始め、不明とデータ品質失敗を残した
• [ ] 運転員の確認ウィンドウと監督者訂正を設計した
• [ ] 人事評価や正式KPIへ使わないシャドー期間を設けた
• [ ] 週次レビューの参加者と変更承認者を決めた

調達・受入

• [ ] 30日PoCの対象、終了条件、撤退条件をRFPに書いた
• [ ] event replay、切断復旧、重複排除、監査、権限、APIを比較する
• [ ] FAT/SATで異常条件を注入し、機械可読証拠を受け取る
• [ ] 読取専用境界、遠隔接続、ログ、バックアップ、ロールバックを確認する

よくある質問

チョコ停対策とは何から始めるべきですか？

ボトルネック工程の2〜3設備を選び、通常サイクル、計画待ち、停止候補の状態を定義することから始めます。いきなり全設備へ展開せず、10日程度のシャドー収集を含む30日PoCで、同じ原データから同じイベントを再現できるか確認します。

チョコ停の見える化では何秒を閾値にしますか？

全工程共通の正解はありません。通常サイクル、信号ノイズ、運転員の復旧行動、生産影響を見て複数帯域を仮設定し、原データとの照合で調整します。閾値、適用範囲、発効日、承認者を版管理してください。

設備稼働監視システムの費用はどう比較しますか？

ライセンスだけでなく、PLCタグ整備、エッジ機器、ネットワーク、PoC、現地作業、教育、クラウド、保守、設備追加を同じ範囲で比較します。価格を一般化せず、イベント再生、切断復旧、監査証跡、API、ロールバックが見積に含まれるか確認します。

設備稼働率向上とOEE改善にどう結び付きますか？

チョコ停秒を工場の時間モデルへ正しく配置し、可用性損失として扱うか、別区分にするかを合意します。性能や品質との重複を避け、閾値を変えただけでOEEが改善したように見えない管理が必要です。一つの閾値が自動的にISO準拠を保証するわけではありません。

運転員が理由を入力しない場合はどうしますか？

入力を強制して近い理由を選ばせるのではなく、候補を少数化し、短い確認ウィンドウを設け、未確認を正直に残します。週次レビューで未確認の多い設備・時間帯を調べ、画面やコードを改善します。

PoCで制御PLCへ書き込む必要がありますか？

監視だけなら読取専用で成立する構成を優先します。書込が不可避な場合は、対象タグ、権限、許可条件、変更管理、失敗時動作、安全境界を別途設計し、FAT/SATで確認します。

まとめ：改善できるチョコ停は、説明できるイベントから始まる

チョコ停対策の出発点は、停止回数の目標ではありません。工場が所有する時間帯域、再現可能な開始・終了、設備と生産の文脈、時刻・source quality、自動理由と確認済み理由、変更統制されたコードを一つのイベントへ結び付けることです。2〜3設備の30日PoCでシャドー収集、週次レビュー、event replay、切断復旧、監査、権限、FAT/SAT証拠を確認してから、全工場展開を判断します。

チョコ停の定義、PLCタグ、理由コード、PoCの受入基準がまだ一枚にまとまっていない段階でも、TOMAS TECHは設備稼働監視の要件整理、データ接続、30日PoC、RFP/FAT/SAT設計を支援できます。既製品の押し付けではなく、対象設備と現状データから相談したい場合は、お問い合わせページをご利用ください。

参考資料

• ISO 22400-1:2014（2025年確認）
• OPC UA for Machinery — Monitoring
• OPC UA for Machine Tools — Production running overview
• OPC UA for Machine Tools — Time-based KPIs
• NIST SP 800-82 Rev. 3
• Thailand BOI — Smart and Sustainable Industry
• BOI/OSOS — 1H 2026 investment update