チョコ停対策2026｜可用率に出ない停止をOEEのどこで捕まえるか

設備の前に1時間立っていると、ラインは何度も止まる。オペレータがワークの詰まりを手で払い、リセットを押し、20秒後には何事もなかったように動き出す。誰も日報には書かない。ところが月末に出てくる稼働率は95%で、現場の実感とまるで合わない。チョコ停 対策が空振りしやすいのは、現場が「止まった」と呼ぶ現象と、OEEの数式が「停止」として拾う現象が、そもそも同じものを指していないからだ。本稿では、そのズレがどこで生まれ、どの指標のどこを見れば捕まえられるのかを整理する。

なぜチョコ停対策は空振りするのか

チョコ停の改善活動が始まると、たいていは「設備稼働率を上げよう」という号令からスタートする。目標は稼働率何パーセント、担当は生産技術、期限は半期。ところが半年後、指標はほとんど動かず、現場からは「体感は変わっていない」という声が返ってくる。この結末は担当者の力量の問題ではない。測っているものと、減らしたいものが一致していないという構造上の問題である。

現場の「止まった」とOEEの「停止」は同じものではない

現場でオペレータに「今日は何回止まりましたか」と聞くと、素直に「10回か15回」と返ってくる。だがその「止まった」の定義は、設備の前に立っている人の感覚である。ワークが引っかかって手を入れた、センサが誤検知して警告灯が黄色になった、材料の補給待ちでコンベアが空になった。どれも本人にとっては「止まった」だ。

一方、稼働管理システムやMESが「停止」として記録するのは、あらかじめ決めた条件を満たした事象だけである。多くの場合その条件は「設備からの運転信号がオフになった状態が、しきい値を超えて継続したとき」だ。しきい値が5分に設定されていれば、20秒で復帰した詰まりは記録上まったく存在しない。オペレータが15回止めたと言い、システムが2回と答える。この差分がチョコ停の正体そのものである。

ここで重要なのは、記録されなかった時間が消えてなくなるわけではない、という点だ。設備は動いていたことになっているが、実際にはその時間に製品は出ていない。つまり「動いているのに出来高が足りない」状態として、後述する性能率の側に押し込まれる。可用率（Availability）の欄は綺麗なまま、性能率の欄だけが理由不明のまま低い、という数字の形になる。「可用率は高いのにOEEが伸びない」という相談がしばしば出てくるのは、この押し込みが効いている可能性がある。

チョコ停とドカ停を分ける閾値は誰が決めるのか

チョコ停（マイクロストップ）とドカ停（大きな設備故障）を分ける境界線は、物理現象として存在するものではない。運用として誰かが決めるものである。OEEベンチマークを整理しているTeepTrakの2026年版レポートでは、マイクロストップの一般的な閾値として5分未満が挙げられている。そして同レポートは、業種によるばらつきはあるものの、5分未満の停止が全ロスに占める割合が18〜38%に達しうると報告している。上限に近い工場では、全ロスのうち4割近くが、多くの現場では記録されないサイズの停止で構成されているということになる。

問題は、この5分という数字を誰も明示的に決めていない工場が多いことである。PLCの標準ファンクションブロックにたまたま入っていた値、装置メーカーのデフォルト、あるいは前任者が設定した値がそのまま残っている。閾値を決めるという行為は、実は「どのサイズの損失を経営の視界に入れるか」という意思決定であり、生産技術が単独で決めるべきものではない。にもかかわらず、たいていは設定画面の中で静かに決まってしまっている。

閾値を下げれば拾える停止は増えるが、代わりに別の問題が出る。10秒に下げれば、サイクル待ち・段取り中の一時停止・センサの一瞬のチャタリングまで停止として立ち上がる。1日の停止イベントが数千件になり、要因コードを付ける運用が破綻する。閾値の設計とは、拾いたい現象の粒度と、現場が入力を続けられる件数との折り合いをつける作業だ。ここを決めずにセンサを付けると、データは出るが誰も見ないダッシュボードができあがる。

手書き日報のOEEが8〜15ポイント高く出る理由

現状把握のために既存の日報からOEEを計算し、「うちは75%あるから悪くない」と判断してしまう工場は多い。だがTeepTrakの同レポートは、手書き記録に基づくOEEが実際の値より8〜15ポイント高く出る傾向を指摘している。この差は改ざんや怠慢ではなく、記録という行為の性質から自然に生まれるものだ。

第一に、人は自分が解決した問題を記録しない。詰まりを蹴って直した、リセットを押した、ロータリーテーブルを手で少し回した。数十秒で復帰したものは「トラブル」として認識されないため、記入欄に到達しない。第二に、記録は事後にまとめて書かれる。終業前に思い出しながら書くと、印象に残った大きな停止だけが残り、細かいものは丸められる。第三に、記録の単位が粗い。日報の欄が5分単位や10分単位で設計されていれば、それ未満の事象は構造的に書けない。

さらに、要因の欄には別の歪みが働く。選択肢が10個あっても、現場は書きやすい1つか2つに寄せる。「材料不良」「その他」といったコードに集中し、集計するとパレート図の1位が「その他」になる。これは現場の手抜きではなく、忙しい中で分類に迷ったときに最も安全な選択肢を選んだ結果である。手書きデータをもとに対策を立てると、この二重の歪み——小さい停止が落ち、要因が丸まる——の上に計画を立てることになる。

停止の4象限で自社の位置を確かめる

自社のチョコ停がどこにいるのかを整理するには、停止を2つの軸で切ると見通しがよくなる。ひとつは「システムに記録が残るか残らないか」、もうひとつは「人が介入して復帰させるか、設備が自動で復帰するか」である。

この2軸で4つの象限をつくると、それぞれで取るべき手段が違うことがはっきりする。

左上の象限は、すでに見えている。故障で30分止まればライン長は知っているし、保全記録も残る。ここは改善のPDCAが回っている領域で、追加投資の効果は相対的に小さい。問題は下の2つ、特に右下である。

チョコ停の主戦場は「記録されない × 自動復帰」の象限だ。この象限の停止は、人が呼ばれないので誰の記憶にも残らず、設備が自分で復帰するので異常履歴にも残らないことが多い。にもかかわらず、頻度が高いため累積時間は無視できない大きさになる。そしてこの象限の損失は、可用率ではなく性能率の中に溶けて計上される。つまり「可用率を上げよう」という号令をいくらかけても、この象限には一切届かない。号令の宛先が間違っているのである。

左下の「記録されない × 人が介入」も見逃せない。ここはオペレータの熟練で吸収されている領域で、上手い人ほど早く直すため、上手い人の設備ほどデータ上は問題がないように見える。人が替わった瞬間に生産数が落ちる工場は、この象限に依存している可能性が高い。タイやASEANの工場のように人員の入れ替わりが一定程度ある環境では、この象限を可視化しておく価値は日本国内より大きい。

自社がどの象限に偏っているかは、既存データからでもある程度あたりが付く。設備ログの停止イベント件数と、オペレータへのヒアリングで得た体感の停止回数を並べてみればよい。この2つの差が大きいほど、下の2象限に損失が沈んでいる。

OEEの3要素とチョコ停の居場所｜ISO 22400-2で定義を揃える

チョコ停の議論が社内で噛み合わない原因の多くは、指標の定義が人によって違うことにある。「稼働率」という言葉ひとつをとっても、設備が電源オンだった時間の割合を指す人と、計画時間に対する良品生産時間の割合を指す人が同じ会議に座っている。定義を揃えないまま数字の話を始めると、議論は必ず途中で止まる。

製造業のKPIについては、ISO 22400-2という国際規格が34のKPIを定義しており、可用率・性能率・品質率およびOEEもここに含まれる。社内標準としてこの規格を参照点に置いておくと、日本本社・タイ工場・設備メーカーの三者で同じ言葉を使えるようになる。特に複数拠点を比較したい場合、拠点ごとに独自定義の稼働率を使っている状態では比較そのものが成立しない。

可用率・性能率・品質率のどこに落ちるか

OEEは3つの率の積である。それぞれが吸収するロスの種類は次のように整理できる。

この表の2行目が本稿の核心である。閾値未満の停止は、定義上「設備は動いていた」ことになる。しかしその時間に製品は出ていないため、理想サイクルタイムで期待される数量に実績が届かない。結果として性能率が下がる。可用率の欄には一切の痕跡が残らない。

だから「チョコ停対策」と称して可用率の目標値を設定すると、活動は自動的に故障対策と段取り改善に向かう。それ自体は悪いことではないが、減らしたかったチョコ停には触れていない。半年後に「稼働率は上がったが体感は変わらない」となるのは、この経路をたどった結果である。

理想サイクルタイムを決めないと性能率は動かない

性能率を計算するには、分母に「理想サイクルタイム（理論上の最速の1個あたり時間）」が必要になる。ここが決まっていない工場は驚くほど多い。設備メーカーのカタログ値、立ち上げ時のトライアル値、直近3ヶ月の最速記録、標準時間として原価計算に使っている値——候補は複数あり、どれを採るかで性能率は大きく動きうる。

カタログ値を採ると性能率は低く出る。実際の材料や治具の条件が入っていないためだ。直近の最速記録を採ると、その日の条件が良かっただけの値が基準になり、慢性的に達成できない目標になる。原価標準を採ると、そこに含まれる余裕率のぶんだけ甘い基準になり、チョコ停があっても性能率が100%近く出てしまうことがある。

実務的には、対象品番ごとに、良品が連続して出ている安定区間の実測サイクルタイムを取り、その中央値付近を初期値に置くのが扱いやすい。重要なのは値の絶対的な正しさではなく、決めた根拠を文書化し、変えるときは合意の上で変えることだ。基準が動く指標は時系列で比較できず、改善の効果測定に使えなくなる。

もうひとつ、理想サイクルタイムは品番ごとに違う。多品種を流すラインで単一のサイクルタイムを設定すると、品種構成が変わっただけで性能率が動き、チョコ停の増減と区別がつかなくなる。段取り替えの多いラインでチョコ停の見える化をするなら、品番マスタと生産実績の紐付けが前提条件になる。この点は設備側の工事より情報システム側の整備の話であり、工場IoTの導入を5層に分けて費用を見積もる考え方とも接続する部分だ。

設備総合効率OEEの計算例

定義の話を具体化するために、説明用の架空のケースで計算してみる。以下の数字は自社の設備を想定したものではなく、あくまで計算の流れを手で追うための例である。

ある設備の1直を、計画稼働時間480分とする。この直で発生した停止のうち、記録されたもの（故障・段取り・材料待ち）の合計が60分だった。総生産数は630個、そのうち不良が54個で良品は576個。理想サイクルタイムは30秒/個とする。

可用率は、稼働時間 480 − 60 = 420分を計画稼働時間で割って、420 ÷ 480 = 87.5%。性能率は、理想サイクルタイムで630個を作るのに必要な時間 630 × 30秒 = 18,900秒 = 315分を、実際に動いていた420分で割って、315 ÷ 420 = 75.0%。品質率は 576 ÷ 630 = 91.4%。OEEはこの3つの積で、0.875 × 0.750 × 0.914 = 60.0% となる。

この60.0%という値は、TeepTrakの2026年ベンチマーク（450工場）が示すOEE中央値の60%とちょうど同じ水準にあたる。同ベンチマークでは上位25%が75%、ワールドクラスと呼ばれる水準が85%とされている。つまりこの例の設備は、世の中の真ん中にいる。

ここからが本題だ。この直では、5分未満の短時間停止が合計45分あったとする。閾値が5分に設定されているため、この45分は停止として記録されず、設備は動いていた扱いになっている。もしこの45分を停止として記録できたら、数字はどう変わるか。

稼働時間は 420 − 45 = 375分になり、可用率は 375 ÷ 480 = 78.1%に下がる。一方、性能率の分母が375分になるので、315 ÷ 375 = 84.0%に上がる。品質率は変わらず91.4%。積は 0.781 × 0.840 × 0.914 = 60.0% で、OEEの値そのものは変わらない。

これがチョコ停の見える化の意味である。OEEの総合値は動かないが、ロスの居場所が可用率へ移動する。87.5%だった可用率が78.1%になって初めて、「9.4ポイントぶんの停止がここにある」という事実が数字として現れる。逆に言えば、見える化をしていない状態でOEEだけを眺めていても、チョコ停の存在は原理的に検出できない。可用率が高いことは、チョコ停が少ないことの証拠にはならない。

チョコ停 見える化の実装5層

では実際にどう作るか。設備データ収集の構成は、下から順に5つの層として整理すると設計の抜けが見つけやすい。層ごとに「何を決めるか」と「決めないと何が起きるか」を並べる。

この5層は、下から順に難易度が上がるように見えて、実際には第3層と第5層が最も難しい。第1層と第2層は技術の話であり、要件さえ決まれば手が動く。第3層以降は運用と組織の話になる。

第1層で最初に迷うのは、どこから信号を取るかだ。PLCにイーサネットのポートがあり、設備メーカーからアドレスマップをもらえるなら通信で取るのが最も情報量が多い。だが古い設備ではそうもいかない。その場合、三色灯（シグナルタワー。アンドンシステムの表示端末としてもよく使われる）の点灯状態を電圧で拾う、あるいは既存のカウンタ出力に接点を並列で取り出す、といった非侵襲の方法を採ることになる。三色灯は「設備が自分で異常と判断したもの」しか点灯しないという弱点があるが、追加工事が小さく、既存設備を止めずに着手できる利点は大きい。この選択の詳細は既存設備をIoT化するレトロフィットの進め方で整理している。

生産数のカウントには固有の落とし穴がある。1パルスが1個なのか1ショット（多数個取り）なのかを設備ごとに確認しないと、性能率が丸ごとずれる。また、試打ちや空打ちがカウントされる設備では、それを除外する仕組みが要る。ここを詰めずに立ち上げると、最初の月次会議で「この数字は実物と合っていない」と言われ、その後誰もシステムを見なくなる。データの信頼は最初の1回で決まる。

第2層の停止判定では、閾値のほかにチャタリング除去の設計が要る。三色灯やセンサの信号は、機械的な振動や配線の状態で瞬間的に切り替わることがある。数百ミリ秒未満の変化を無視するフィルタを入れないと、実在しない停止が大量に生成される。逆にフィルタを強くしすぎると本物の短時間停止まで消えるため、現場で数日ログを取りながら調整する期間を計画に入れておく。

第3層の要因入力が、この構成でいちばん設計思想が出るところだ。要因コードを細かくすれば分析は精緻になるが、現場の入力負荷が上がる。実務では、第一階層を5〜7個に絞り、必要な設備だけ第二階層を持たせる形が続けやすい。入力の担当をオペレータにするかライン長にするか、その場で入れるか休憩時にまとめて入れるかも、あらかじめ決めておく必要がある。決めずに始めると、入力できる人が入力できるときに入れる運用になり、データの欠損が特定の直や特定の設備に偏る。偏った欠損は、無いことより厄介だ。

第4層と第5層については、指標を出すこと自体より「誰がいつ見て何を決めるか」を先に決めるほうが効く。朝会で前日のパレート上位3件を読み上げる、週次で対策の進捗を確認する、といった運用の型がないと、第1層から第3層への投資は回収されない。

停止要因分析でパレートの1位を潰しても効かないとき

見える化が動き出すと、最初の月にパレート図が出てくる。1位の要因を潰す対策を立て、実行し、翌月に効果を確認する——この流れは正しいが、期待した効果が出ないことがある。原因の多くは、並べ方の選択にある。

頻度で並べるか、累積時間で並べるか

停止要因を並べる軸は少なくとも2つある。発生件数（頻度）と、累積停止時間である。この2つは、順位がしばしば入れ替わる。

たとえば、1回あたり20秒の詰まりが月に600回起きる要因Aと、1回あたり40分の調整が月に4回起きる要因Bを比べる。件数ではAが600件でBが4件、圧倒的にAが1位だ。だが累積時間ではAが200分、Bが160分で、差はかなり縮まる。もう少し件数が少なければ順位は逆転する。頻度で並べたパレートと時間で並べたパレートは、別の絵になる。

どちらを見るべきかは、対策の性質で決まる。設備の機構を変える、治具を作り直すといった恒久対策を考えるなら、累積時間で並べたほうが投資対効果を判断しやすい。一方、オペレータの負荷や品質リスクを考えるなら頻度が効く。20秒の詰まりが月600回起きているということは、1日あたり27回、オペレータが1直で十数回は設備に手を入れているということだ。この頻度は、手を入れる作業そのもののリスク（怪我、位置ずれ、再現性の低下）と、他の設備を見る時間の喪失を伴う。累積時間だけを見ていると、この負荷は視界に入らない。

実務では、両方を並べて出したうえで、上位に共通して現れる要因から着手するのが安全だ。片方でしか上位に来ない要因は、なぜ片方だけなのかを説明できるまで手をつけない。説明できない順位は、たいていデータの取り方の問題を示している。

もうひとつの罠が、要因コードの偏りである。前述のとおり、現場は入力しやすいコードに寄せる。「その他」や「材料不良」が1位に立っているパレートは、現象の分布ではなく入力行動の分布を表している。この状態で1位を潰そうとしても、対象が特定できないので対策が打てない。パレートの1位が「その他」だったら、まず要因コードの設計と入力運用を直すのが先である。

段取り時間短縮とチョコ停対策はどちらが先か

限られたリソースをどちらに配分するかは、よく出る問いだ。判断材料は自社の数字にある。可用率のロスの内訳を出し、段取り替えが占める時間と、チョコ停を可視化した場合に移動してくる時間を比較すればよい。

一般論としては、品種切り替えが1日に何度もあるラインでは段取りの比重が大きく、少品種を長時間流すラインではチョコ停の比重が大きい。ただしこの判断には順序の問題がある。チョコ停を可視化していない状態では、そもそも比較する材料がない。可用率の高さを根拠に「うちは段取りが問題だ」と結論すると、前述のとおり、性能率に沈んでいる時間を見落とす。

もうひとつ、段取り時間短縮とチョコ停対策では効果の現れ方が違う。段取り改善は1回あたりの短縮効果が大きく、成果が見えやすい。チョコ停対策は1件あたりの効果が小さく、件数で効いてくるため、効果の確認に時間がかかる。短期の成果が求められる状況では段取りから入るのが現実的だが、その場合もチョコ停のデータ取得は並行して始めておくほうがよい。データは溜まるのに時間がかかるからだ。工程間の停滞や在庫の観点まで含めて全体を見たい場合は、製造リードタイムを5つの待ちに分解する考え方も合わせて検討材料になる。

費用と投資回収｜タイ工場・対象20台の試算

金額の話に移る。ここではタイの工場で対象設備20台、2直、月22日稼働という条件を置き、5層の構成に沿って初期費用を見積もった例を示す。実際の見積は設備の種類・配線距離・既存ネットワークの状態で変わるため、以下は桁感をつかむための一例として読んでほしい。

この構成で目を引くのは、ハードウェアそのものより設計・配線・教育の430,000バーツが大きいことだろう。信号をどこから取るかの設計、盤内工事、現場への教育は台数に比例して増えるうえ、既存設備の状態によって工数が読みにくい。ここを圧縮しようとして自社対応にすると、立ち上げが数ヶ月遅れることがある。

初期費用に加えて、年間費用として保守180,000バーツ、通信36,000バーツ、予備品24,000バーツの合計240,000バーツを見込む。月あたりに直すと 240,000 ÷ 12 = 20,000バーツである。

次に効果側だが、ここからは仮置きの前提が入ることを明示しておく。以下の計算は「こういう考え方で自社の数字を当てはめてください」という枠組みであって、この金額が保証されるという意味ではない。読者は太字の前提を自社の値に差し替えて、同じ順序で計算しなおしてほしい。

前提1。対象設備の操業時間（OEEの計画稼働時間にあたる母数）は、20台 × 16時間/日 × 22日/月 = 7,040 台時/月。

前提2。1台時あたりの粗利貢献を450バーツと仮置きする。ここが最も工場差の大きい変数で、製品単価・材料費比率・設備の位置づけ（ボトルネックかどうか）で大きく変わる。自社の値は、対象設備を通る製品群の月間粗利を、その設備の月間稼働台時で割れば概算できる。ボトルネック工程でなければこの値は小さくなり、投資判断は保守的になる。

前提3。見える化と改善運用によってOEEが3ポイント改善したとする。このとき増える稼働相当は 7,040 × 0.03 = 211.2 台時/月。金額にすると 211.2 × 450 = 95,040バーツ/月。ここから月次の費用20,000バーツを引くと、純増は 95,040 − 20,000 = 75,040バーツ/月となる。初期費用1,100,000バーツをこれで割ると、1,100,000 ÷ 75,040 = 約15ヶ月で回収する計算になる。

問題は、この3ポイントが当たり前ではないことだ。対照として、改善が1ポイントにとどまった場合を同じ式で計算してみる。7,040 × 0.01 = 70.4 台時/月、70.4 × 450 = 31,680バーツ/月、純増は 31,680 − 20,000 = 11,680バーツ/月。回収は 1,100,000 ÷ 11,680 = 約94ヶ月、およそ8年である。設備の更新サイクルやシステムの陳腐化を考えると、これは事実上回収しないと判断すべき水準だ。

同じ初期費用、同じセンサ台数、同じソフトウェアで、回収期間が15ヶ月と8年に分かれる。分岐しているのはハードウェアの仕様ではなく、取れたデータで何ポイント動かせるかという一点である。つまり導入の可否を「センサを何台付けるか」で議論するのは、判断軸の置き場所を間違えている。問うべきは、要因コードを現場が入力し続けられるか、パレートの上位を毎週見て対策を決める人がいるか、対策の効果を同じ基準で測り続けられるか——第3層と第5層が回るかどうかだ。

もし第5層の運用体制に自信が持てないなら、選択肢は「導入しない」ではなく「規模を落として始める」である。対象を20台から数台に絞れば初期費用は下がり、運用が回ることを確認してから広げられる。回収期間の感度が高い投資では、規模より先に運用の再現性を確かめるほうが合理的だ。

タイ・ASEANの工場で追加になる論点

ここまでは国を問わない構造の話だった。タイやASEANの工場では、これに加えていくつかの論点が乗る。

第一に、要因コードの多言語対応である。現場入力端末の画面に日本語だけを出しても入力は続かない。タイ語、必要に応じてミャンマー語やカンボジア語での表示が要る。ここで重要なのは翻訳の品質ではなく、コードとラベルの分離だ。集計はコードで行い、表示だけを言語別に切り替える設計にしておかないと、後から言語を追加するたびに集計が分断される。加えて、アイコンや写真をラベルに添えると、文字の読み書きに依存しない入力ができる。

第二に、人員の入れ替わりと入力運用である。前述の「記録されない × 人が介入」象限は、熟練オペレータの技能で吸収されている領域だ。人が替わればここが表面化する。逆に言えば、この象限を可視化しておくと、教育の対象が具体化する。「詰まりの多い品番はどれか」「どの設備で手が入る回数が多いか」がデータで示せれば、引き継ぎの内容が経験談から手順に変わる。

第三に、投資の外部支援である。BOI（タイ投資委員会）は「Smart and Sustainable Industry」の枠組みで工場のスマート化投資を支援しており、2026年上期には132件・172億バーツの申請があったと公表されている。稼働監視やデータ収集の投資がこの枠に該当するかは案件ごとの判断になるが、金額規模が大きい場合は事前に確認する価値がある。制度の要件は変わりうるため、最新の条件はBOIの公表資料を直接あたるのが確実だ。

第四に、事業環境の変化である。タイの製造業生産指数は2026年6月に前年同月比で3.1%下落し、同月の自動車生産は7.55%の下落と報じられている（Business Recorder）。生産量が伸びない局面では、設備を増やす投資より既存設備の取りこぼしを減らす投資のほうが検討されやすい。一方で、稼働率が下がっている状態でOEEを測ると、計画稼働時間の置き方によって数字が大きく動く。需要都合の非稼働を計画停止として除外するのか、含めるのかを先に決めておかないと、月次の比較ができなくなる。

第五に、労務費との比較である。Thai Law Onlineの整理によれば、2026年のタイ最低賃金は県によって337〜400バーツ/日の範囲にある。この水準を前提にすると、「データ入力の手間を人で吸収する」という発想が成立しやすく見える。だが記録の目的は工数の削減ではなく、意思決定に使えるデータを継続的に得ることだ。人手で書いた記録がOEEを8〜15ポイント高く見せるという先の指摘は、この点で重い。人を増やしても、小さい停止が記録に到達しないという構造的な欠落そのものは埋まりにくい。

第六に、日本本社から海外工場の稼働状況を把握する場合の時差とネットワークである。タイと日本の時差は2時間で、タイの朝の立ち上がりを本社が見ようとすると日本時間の朝10時前後になる。リアルタイム性を求めると回線とサーバの構成が重くなるため、本社が見るのは日次の集計で足り、リアルタイムは現地の判断用と割り切る設計が現実的なことが多い。工場側のネットワークを日本本社のシステムに直結する構成は、セキュリティ要件と運用主体の議論を伴うため、要件定義の早い段階で情報システム部門を巻き込んでおきたい。設備の状態監視を保全の高度化まで広げる場合は、予知保全システムの導入判断で扱っている論点とも重なる。

最初の90日で何をするか

いきなり全ラインに展開しない、という前提で90日を組む。目的は成果を出すことではなく、「自社で第3層と第5層が回るか」を確かめることだ。

最初の30日は定義を揃える期間にあてる。対象設備を3〜5台に絞り、可用率・性能率・品質率の定義をISO 22400-2に合わせて文書化する。停止の閾値を仮決めし（多くの場合5分から始める）、計画停止として除外するものの一覧を作る。並行して対象品番の理想サイクルタイムを実測し、根拠とともに記録する。この30日でセンサは1台も付いていなくてよい。

次の30日で第1層と第2層を立ち上げる。信号の取得方法を確定し、対象設備に取り付け、数日間の生ログを見ながらチャタリング除去と閾値を調整する。ここで必ず確認するのは、システムの生産数と現場のカウンタが一致するかだ。合わないまま先に進むと、後段のすべての数字が信用されなくなる。同時に、オペレータへのヒアリングで得た体感の停止回数と、システムが検出したイベント数を突き合わせる。この差が、前述の4象限のどこに損失が沈んでいるかの手がかりになる。

最後の30日は第3層と第5層に集中する。要因コードを5〜7個で仮運用し、入力率と「その他」の比率を毎日見る。入力率が落ちる時間帯や直があれば、コードの数か入力のタイミングを調整する。週に1度、パレートを頻度と累積時間の両方で出し、上位に共通する要因を1つ選んで対策を決める。この90日で対策が1件でも回り、効果が同じ基準で測れたなら、展開してよいと判断できる。回らなかったのなら、その原因を解いてからでないと台数を増やしても同じことが起きる。設備を増やす前に運用を直すほうが、やり直しの費用は小さい。

よくある質問

チョコ停とは何分から何分までの停止を指すのか。

明確な国際的定義はない。TeepTrakの2026年レポートではマイクロストップの一般的な閾値として5分未満が挙げられており、実務でもこの水準を出発点にする例が多い。ただし本文で述べたとおり、閾値は「どのサイズの損失を可視化するか」という運用上の意思決定であり、設備のサイクルタイムによって適切な値は変わる。サイクルタイムが数秒の設備で5分の閾値を使うと、数十サイクル分の損失が1つの閾値の下に隠れることになる。

チョコ停対策の費用はいくらか。

本文の試算では、対象20台・2直の条件で初期費用1,100,000バーツ、年間費用240,000バーツという例を示した。ただしこれは構成例であり、既存設備からの信号の取りやすさ、配線距離、既存ネットワークの有無で大きく変わる。数台から始める場合は初期費用の絶対額は下がるが、サーバ・ソフトの初期費用は台数に比例しないため、1台あたりの単価は高くなる。

OEEはどのくらいを目標にすべきか。

TeepTrakの2026年ベンチマーク（450工場）では、中央値が60%、上位25%が75%、ワールドクラスと呼ばれる水準が85%とされている。ただし業種・設備構成・品種構成で妥当な水準は変わるため、他社の値を目標にするより、自社の同一設備・同一定義での時系列を追うほうが実用的だ。特に手書き日報からシステム計測に切り替えた直後は、それまで記録から落ちていた損失が表面化し、OEEが以前より下がったように見えることがある。これは悪化ではなく計測精度の向上であり、この点を事前に経営層と共有しておかないと、活動が始まった直後に止まる。

古い設備でもチョコ停は取れるか。

取れる。通信ポートのない設備でも、三色灯の点灯状態を電圧で拾う、既存のカウンタ出力に接点を並列で取り出す、外付けの近接センサで動作を検出するといった方法がある。ただし取れる情報の粒度は下がる。三色灯からは「設備が自分で異常と判断した停止」しか分からないため、材料待ちや人の判断による停止は別の手段で補う必要がある。何が取れないかを最初に把握しておけば、要因入力の設計でその穴を埋められる。

生産数の自動カウントだけでも意味はあるか。

意味はある。生産数が自動で取れれば、実績サイクルタイムの分布が見えるようになり、理想サイクルタイムを決める根拠が手に入る。分布の裾が長い（時々極端に遅いサイクルがある）ことが分かれば、そこにチョコ停が潜んでいると推定できる。ただし停止判定と要因入力がないと「なぜ遅いのか」は分からないため、対策の特定には至らない。段階的に進めるなら、生産数カウントから始めて停止判定を足し、要因入力を最後に載せる順序は現実的である。

まとめ

チョコ停対策が空振りする理由は、指標の構造にある。閾値未満の短時間停止は可用率のロスとして記録されず、性能率の中に溶ける。だから可用率を目標に据えた活動は、チョコ停には届かない。捕まえる場所は性能率であり、そのためには理想サイクルタイムを決め、停止判定の閾値を決め、要因コードを現場が入力できる粒度に設計する必要がある。この3つは設備やセンサを買う前に決めるべきものだ。

そして投資判断の本質は、センサの台数ではなく感度にある。本文の試算では、同じ1,100,000バーツの投資でも、OEEを3ポイント動かせれば約15ヶ月で回収し、1ポイントにとどまれば約94ヶ月かかって事実上回収しない。この分岐を決めているのは、要因コードの設計と、数字を毎週見て対策を決める運用——実装5層でいう第3層と第5層である。ハードウェアの見積を取る前に、この2つの層を誰がどう回すのかを社内で決めておくと、投資の議論はずっと具体的になる。

TOMAS TECHでは、タイおよびASEANの日系工場向けに、設備からの信号取得から要因分析・改善運用までを含む稼働の見える化に取り組んでいます。閾値や要因コードをどう置くか、既存設備からどこまで信号が取れるか、自社の粗利貢献をどう見積もるかといった初期の整理の段階でも構いません。検討の材料集めとしてお使いいただければと思いますので、お問い合わせからお気軽にご相談ください。

参考情報

• Manufacturing OEE Benchmark Report 2026 – TeepTrak
• Six Big Losses of OEE – TeepTrak
• State of OEE 2026 – TeepTrak
• OEE Benchmarks by Industry 2026 – Fabrico
• ISO 22400-2 Automation systems and integration – Key performance indicators for manufacturing operations management
• Thai June factory output falls 3.1% y/y – Business Recorder
• BOI Smart and Sustainable Industry 2026年上期の申請状況
• Minimum Wage in Thailand – Thai Law Online
• OEE Benchmark 2026 (450工場・30カ国) – TeepTrak
• Micro Stops in Production – Detect and Eliminate – TeepTrak