設備異常 通知システムを入れたのに現場の停止時間が減らない——タイの日系工場で最も多く聞く相談がこれだ。原因はほぼ例外なく、通知が届いていないことではない。届いた後に誰がいつ動くかを設計していないことにある。この記事では通知を「検知層・到達層・記録層」の3層に分解し、MTTRのどこを潰しているのかで投資判断する方法を示す。
設備異常 通知システムとは|アンドンシステムとの違い
設備異常 通知システムとは、設備や工程で発生した異常を自動で検知し、対応できる人に確実に届け、対応の履歴を残す一連の仕組みを指す。言葉としては「呼び出しシステム 工場」「アラート通知 現場」「作業者 呼び出し 通知」など複数の呼び方で流通しているが、実体は同じものを指していることが多い。
一方でアンドンシステムは、もともとトヨタ生産方式で使われてきた「異常を止めて・呼んで・待つ」ための可視化手段だ。回転灯や大型表示板でラインの状態を色で示し、その場にいる人が気づく。国内でもアンドンの基本的な考え方を整理した解説が多数あるとおり、アンドンは思想としては極めて完成度が高い。
アンドンは「到達層の一手段」にすぎない
ここが本記事の出発点になる。アンドン(回転灯・表示板)は、異常を人に届けるための到達手段の一つであって、通知システムそのものではない。 回転灯は「見える範囲にいる人」にしか届かない。24時間稼働の工場で、夜勤の保全担当が反対側の棟にいれば、回転灯は誰にも見られないまま回り続ける。
つまりアンドンの弱点は思想ではなく物理的な到達範囲にある。この弱点を埋めるために「アンドン 通知 スマホ」「異常通知 スマートウォッチ」といった検索が発生している。アンドンをやめてスマホにするのではなく、アンドンという到達手段に別の到達手段を足す、という理解が正しい。
「通知システム」と呼ばれるものの実装レンジ
現場で「設備異常 通知システム」と呼ばれているものは、実装レベルに大きな幅がある。
| レベル | 実装の姿 | 到達手段 | 記録 |
|---|---|---|---|
| L0 | 設備のブザー・回転灯のみ | その場の音と光 | なし |
| L1 | 回転灯+日報の手書き記入 | その場+事後の紙 | 紙(集計されない) |
| L2 | 信号を収集し大型モニタに表示 | 現場モニタ | 一部ログ |
| L3 | 収集した信号をスマホ/ウォッチにプッシュ | 個人端末 | 通知ログ |
| L4 | エスカレーション+ACK(受理)+実績分析 | 個人端末+段階転送 | 対応履歴まで |
多くの工場はL1かL2にいる。そしてL2からL3に上げただけで満足してしまうケースが非常に多い。しかし後述するとおり、投資が回収されるのはL3ではなくL4に到達したときだ。この差を最初に理解しておくと、見積書の読み方が変わる。
通知は届いているのに現場が動かない|3つの失敗パターン
導入後に効果が出ない工場を分解すると、原因は驚くほど共通している。以下の3つに集約される。
失敗1|誰に・何分で・次は誰に、が決まっていない
最も多い。異常が発生すると保全グループ全員のスマホが一斉に鳴る。全員が鳴ると、全員が「誰か行くだろう」と思う。社会心理学でいう傍観者効果が、そのまま工場の床で起きる。
必要なのは一斉通知ではなくエスカレーション設計だ。「一次担当は誰か」「何分応答がなければ次に回すか」「最終的に誰で止めるか」。この3つを設備グループごとに決めていないシステムは、通知の量だけが増えて対応速度は変わらない。
判断の目安として、次の3つを書き出せなければ設計が不足していると考えてよい。
- 一次受け(個人名または役割名。「グループ」は不可)
- 応答期限(分単位。設備の停止コストで変える)
- 二次・三次のエスカレーション先と、通知手段の切り替え(スマホ→電話、など)
失敗2|通知が多すぎてアラート疲労が起きている
L3まで作ると、たいてい通知が多すぎる状態になる。センサから取れる信号を「せっかくだから全部」通知に載せてしまうためだ。1シフトで数十件から百件を超える通知が飛ぶようになると、人はまず見なくなり、次に端末をロッカーに置くようになる。
アラート疲労は「通知の質の問題」ではなく「通知の量の問題」だ。 内容がどれだけ正しくても、量が閾値を超えれば無視される。そして無視が定着した後にシステムを立て直すのは、最初から作り直すよりコストが高い。信頼が一度失われるためだ。
失敗3|通知が記録に残らず、改善に還らない
3つ目が最も見落とされる。通知は飛んだが、その通知に誰がいつ応答し、何分で復旧し、原因は何だったのかが残っていない。結果として、月次の改善会議で使えるデータが一つも増えない。
特にチョコ停は、作業者がその場で復旧してしまうため記録に残りにくく、実態が把握しにくいという性質がある(チョコ停の定義と特徴の解説、短時間停止に関する整理)。通知システムは、この「記録に残らない停止」を自動で記録に変えられる唯一の現実的な手段だ。それを使わないなら、投資の半分を捨てていることになる。
通知設計を3層に分ける|検知層・到達層・記録層

失敗パターンを裏返すと、設計すべき対象が3つに分かれる。本記事ではこれを検知層・到達層・記録層と呼ぶ。以降の章はすべて、この3層のどこの話かを明示しながら進める。
| 層 | 何を決める層か | 主な構成要素 | この層が弱いと起きること |
|---|---|---|---|
| 検知層 | 「何を異常とみなすか」 | 接点信号、PLCタグ、電流・振動・温度センサ、サイクルタイム監視 | 検知漏れ、または誤報の多発 |
| 到達層 | 「誰にどう届けるか」 | 無線LAN/LTE、通知基盤、スマホ・ウォッチ・アンドン・IP無線 | 届かない、届いても動かない |
| 記録層 | 「何を残し、どう使うか」 | 通知ログ、ACK、対応履歴、原因コード、OEE連携 | 改善に還らない、投資効果が示せない |
MTTRのどこを潰しているのかで測る
3層を導入する意味は、投資対効果を同じ物差しで測れるようになることにある。設備が止まってから復旧するまでの時間(MTTR)は、実務上こう分解できる。
発生 → 検知 → 通知 → 認知 → 着手 → 復旧 → 復帰確認
このうち通知システムが直接短縮できるのは、検知〜着手の区間だけだ。実際の修理時間(着手〜復旧)は、部品の在庫や技能の問題であって通知では縮まない。ここを混同したまま導入すると「入れたのに停止時間が全然減らない」という評価になる。
逆に言えば、検知〜着手の待ち時間が長い工場ほど効果が大きい。導入前に測るべき数字は一つだけで十分だ。異常発生から人が現場に着くまでの実測時間。ストップウォッチで20件も測れば分布が見える。中央値が3分を切っているなら、通知システムへの投資優先度は低い。5分を超えているなら、投資判断の材料としては十分に強い。その中間、つまり3〜5分の帯は「効果は出るが、費用の組み方次第で回収年数が大きく振れる」ゾーンだ。後述の試算はあえてこの帯(4分)を前提に置いている。最も効果が大きいケースではなく、多くの工場が実際にいる位置で試算しておくほうが、稟議に耐えるからだ。
なお、通知の自動化や予兆の事前把握でMTTRが3〜5割改善しうるという主張は、主にソリューションを提供する側のレポートに見られる。方向としては妥当だが、ベンダー系レポートの主張として距離を置いて扱うのが安全だ。自社の実測値を持たないまま他社の改善率を稟議書に書くと、後で説明できなくなる。
検知層は「増やす」より「減らす」ほうが難しい
検知層の設計でよくある誤解が、センサを増やすほど良いというものだ。実際には、通知に載せる異常の種類を最初から絞ったほうが定着する。
第一段階で載せるべきは、人が行かないと復旧しない異常だけだ。自動復帰する軽微なエラーや、オペレーターがその場で必ず気づく異常は、記録層には入れても到達層には載せない。この切り分けだけでアラート疲労の大半は防げる。
異常の「発生後に知る」から「発生前に知る」へ進むのが次の段階になる。振動や電流波形からの予兆検知に踏み込む話は予知保全システムの導入側の論点で、通知システムの土台ができてから着手するほうが失敗が少ない。順序を逆にすると、予兆を掴んでも届ける先がないという状態になる。
到達手段の比較|アンドン・スマホ・スマートウォッチ・呼び出しシステム

ここからは到達層の話になる。「アンドン 通知 スマホ」「異常通知 スマートウォッチ」といったキーワードで比較されている選択肢を、工場で実際に効く軸で並べる。
| 到達手段 | 到達範囲 | 騒音下 | 移動中 | 手がふさがった状態 | 応答(ACK) | 端末単価の目安 | 主な弱点 |
|---|---|---|---|---|---|---|---|
| アンドン(回転灯・表示板) | 視界内のみ | ◎(光) | × | ◎(見るだけ) | × | 低〜中 | 見ていないと届かない |
| 構内放送 | 建屋全体 | △(騒音の大きい建屋で不利) | ○ | ○ | × | 低 | 誰宛か曖昧、記録が残らない |
| 工場用スマホ(プッシュ通知) | 電波の届く範囲 | △(音が負ける) | ◎ | △(取り出しが必要) | ◎ | 中 | 手袋・防爆環境で操作しづらい |
| スマートウォッチ(振動) | 電波の届く範囲 | ◎(振動) | ◎ | ◎(腕を見るだけ) | ○ | 中 | 情報量が少ない、充電運用 |
| IP無線・専用呼び出し端末 | 専用網の範囲 | ○ | ◎ | ○ | ○ | 中〜高 | 別系統の保守が発生 |
| メール | どこでも | × | △ | × | × | ほぼゼロ | 即時性がない。緊急通知に不適 |
実務上の使い分けの結論
比較表から導かれる実務的な結論はシンプルだ。単一手段で完結させようとしないこと。 現実的な構成は次のようになる。
- 一次通知=スマートウォッチの振動:騒音下でも確実に本人に届き、手袋のまま腕を見るだけで済む。工場という環境において、振動は音より圧倒的に強い到達手段だ
- 詳細確認=工場用スマホ:どの設備の何のアラームか、過去に同じことが起きていないかを見る
- 状態の共有=アンドン/大型表示:個人ではなくラインの状態を、通りがかりの全員に共有する
- 未応答時のエスカレーション=電話またはIP無線:手段を変えることで到達確率を上げる
「スマートウォッチ 工場」導入で失敗する典型は、ウォッチ1本ですべてをやろうとするパターンだ。画面が小さいため詳細が読めず、結局作業者は毎回設備まで歩いて確認することになる。ウォッチは呼び出しの受信専用と割り切り、判断はスマホか設備前の端末に任せる設計が定着しやすい。
到達層は無線基盤の品質がそのまま上限になる
見落とされがちだが、到達層の性能は通知ソフトの出来ではなく無線の設計で決まる。プッシュ通知は、電波が途切れた瞬間に「遅延して届く」か「届かない」かのどちらかになる。金属だらけの工場は電波環境として厳しく、事務所と同じ感覚でAPを配置すると必ず穴ができる。
導入前に確認すべきは、通知システムのカタログではなく、自社の構内無線がどう設計されているかだ。この観点は工場の無線LAN・産業用ネットワーク構築側の設計論と直結する。通知が届かないという症状の原因が、実は電波の穴だったという事例は珍しくない。
エスカレーション設計とアラート疲労対策
到達層の設計で最も難易度が高いのがこの部分だ。ソフトの設定項目としては地味だが、投資効果の大半がここで決まる。
エスカレーション設計の書き方
エスカレーションは、設備の重要度に応じて時間を変える。すべての設備を同じルールにすると、重要設備の応答が遅れるか、軽微な設備で人が疲弊するかのどちらかになる。
| 重大度 | 対象 | 一次通知 | 未応答時 | 最終エスカレーション |
|---|---|---|---|---|
| P1(ライン全停止) | ボトルネック工程、共通設備 | 担当者ウォッチ即時 | 2分で班長 | 5分で製造課長+電話 |
| P2(単機停止) | 個別設備 | 担当者ウォッチ即時 | 5分で班長 | 15分で保全リーダー |
| P3(軽微・要監視) | 予兆、品質傾向 | シフト内でまとめて | エスカレーションなし | — |
ここで重要なのは、P3を通知しない勇気だ。P3は記録層に貯めて、シフト終わりのレビューや週次の改善会議で使う。リアルタイムに飛ばさないことがアラート疲労の最大の対策になる。
ACK(受理)を必須にする
エスカレーションを機能させるには、受け取った人が「自分が行く」と意思表示する仕組みが要る。これがACKだ。ウォッチのボタン一つ、スマホのワンタップで十分だが、これが無いと「応答がない=次に回す」という判定ができない。
ACKにはもう一つ効用がある。誰がどれだけ呼ばれているかが可視化される。 特定の1人にACKが集中していれば、それは属人化のサインだ。人員配置や教育の優先順位を決める材料になる。離職率の高いタイの現場では、この可視化が引き継ぎリスクの早期発見に直結する。
通知量をKPIとして管理する
アラート疲労を防ぐには、通知量そのものを管理指標にする。運用設計の経験則として我々が最初に置く目安は次のとおりだ(外部統計ではなく、設計の出発点としての社内基準である)。
- 1人あたり1シフト(8時間)で、行動を伴う通知は10件以内に収める
- 同一設備の同一アラームは、一定時間(例:10分)内は集約して1件にする
- 発生と復帰を短時間で繰り返す信号(フラッピング)は、n回以上/m分の条件で初めて通知する
- 月次で「通知件数」「ACK率」「未応答でエスカレーションした件数」をレビューし、しきい値を調整する
このレビューを回さないシステムは、半年で必ず通知過多に戻る。設備は増え、センサは追加され、しきい値だけが放置されるからだ。通知設計は一度きりの設定作業ではなく、継続的なチューニング業務だという前提を、運用体制の見積もりに入れておく必要がある。
チョコ停 見える化|通知ログをOEE改善に接続する
ここからが記録層だ。そして投資回収の議論において、実は最も価値が高い層でもある。
チョコ停とドカ停はOEEの別々の場所を削る
まず用語を整理する。チョコ停は数十秒から10分程度の短時間停止で、作業者がその場で復旧してしまうもの。ドカ停は1時間以上の長時間停止で、故障として認識され報告書が上がるものだ。
OEE(設備総合効率)は「時間稼働率 × 性能稼働率 × 良品率」に分解される。ここで、ドカ停は時間稼働率を下げ、チョコ停は性能稼働率を下げる。管理職が見ているのはたいてい時間稼働率なので、ドカ停は議題に上がるがチョコ停は上がらない。しかし積算するとチョコ停のほうが大きいことは珍しくない。
なぜチョコ停は記録に残らないのか
理由は単純だ。作業者にとって、20秒で直る詰まりをわざわざ紙に書く合理性がないからだ。書く時間のほうが復旧時間より長い。だから記録されない。記録されないから集計できない。集計できないから、どの設備のどのモードが一番多いのかが誰にも分からない。
この構造を破れるのが通知システムの記録層だ。人が書かなくても、設備が止まった事実は信号として残る。 通知が飛んだ回数、ACKまでの時間、復帰までの時間が自動で貯まる。これが「チョコ停 見える化」の実体であり、日報の様式を変えることでは絶対に達成できない部分だ。
記録層で最低限そろえるべき項目
| 項目 | 取得方法 | 何に使うか |
|---|---|---|
| 発生日時・設備・アラーム種別 | 自動(信号) | 発生頻度のパレート分析 |
| 通知先・ACK日時・ACK者 | 自動(システム) | 検知〜着手時間、属人化の把握 |
| 復帰日時 | 自動(信号) | 停止時間の実測、MTTR算出 |
| 原因コード | 半自動(端末で選択式) | 対策の優先順位づけ |
| 対処内容メモ | 任意入力 | ナレッジ化、教育資料 |
原因コードは選択式にすることが定着の条件になる。自由記述にすると入力されない。タイの現場ではタイ語・日本語・英語が混在するため、コード(数字やアイコン)で選ばせて、表示だけを言語別に切り替える設計にしておくと運用が破綻しない。
集めたログは、設備稼働監視の全体設計と合流させると価値が跳ね上がる。稼働率、良品率、エネルギー使用量と同じ土俵に載せる考え方は工場IoT稼働監視の導入で整理している論点と重なる。通知システムを単独のシステムとして閉じさせないことが、5年後の資産価値を決める。
設備異常 通知システムの費用|内訳5層と投資回収の考え方(THB試算)

「設備異常 通知システム 費用」で調べても、レンジが広すぎて参考にならないという声が多い。理由は、見積もりに含まれる範囲が会社ごとにまったく違うからだ。ここでは費用を5層に分解し、どこが変動要因なのかを明示する。
費用の内訳5層(タイ・20ライン規模を想定)
以下は、タイ国内の日系中堅工場(20ライン規模)を前提とした概算レンジである。設備の年式、既存の配線状況、建屋構造で大きく動くため、あくまで検討初期の桁を掴むための数字として扱ってほしい。
| 層 | 含まれるもの | 概算レンジ(THB) | 主な変動要因 |
|---|---|---|---|
| ① 検知層 | 接点/PLCタグの取り出し、追加センサ、I/Oユニット | 8,000〜35,000 / ライン | 既存PLCの有無、空き接点の有無、設備年式 |
| ② 経路層 | 産業用AP、配線、ゲートウェイ、電源工事 | 150,000〜600,000 / 工場 | 建屋面積、金属遮蔽、既存無線の流用可否 |
| ③ 基盤層 | 通知エンジン、サーバまたはクラウド、ライセンス | 200,000〜900,000(初期) | オンプレ/クラウド、ユーザー数、多言語対応 |
| ④ 端末層 | スマートウォッチ、工場用スマホ、アンドン、表示板 | 4,000〜25,000 / 台 | 防塵防水等級、防爆要否、台数 |
| ⑤ 導入・保守層 | 要件定義、設置、教育、年間保守 | 初期費用の15〜25% / 年 | 対応言語数、SLA、遠隔保守の可否 |
20ライン全体を一気にやる場合、端末を60台(2交代で保全・班長クラスに1人1台+予備)と置くと、初期費用はおおむね 120万〜450万THB のレンジに収まることが多い。内訳の目安は次のとおりだ。
- 下限側:①16万+②15万+③20万+④24万(4,000THB×60台)+⑤導入工数 約45万 = 約120万THB
- 上限側:①70万+②60万+③90万+④150万(25,000THB×60台)+⑤導入工数 約80万 = 約450万THB
この5層は「費用がどこで発生するか」で切っているため、記事前半の3層(検知層・到達層・記録層)とは切り口が違う点に注意してほしい。3層でいう記録層にあたる費用——通知ログの蓄積、集計画面、OEEへの接続——は③基盤層に含まれると考えてよい。見積もりを削るときにここから落とすと初期費用は確かに下がるが、本記事で最も価値が出ると述べた層を最初に捨てることになる。
なお⑤の「初期費用の15〜25%」は年間保守の目安であり、上の初期費用には要件定義・設置・教育といった導入時の一時費用として別に積んでいる。導入工数は工場規模に比例せず一定量が必ずかかるため、機材費に対する比率は小規模なほど高く出る(下限ケースでは機材費の約6割、上限ケースでは約2割という置き方になっている)。ここは値切りにくい費目だと考えておいたほうがよい。幅が3倍以上あるのは、①検知層で「既存信号を流用できるか」、②経路層で「無線をゼロから引くか」、④端末層で「どの等級の端末を何台配るか」の3点が効くためだ。逆に言えば、この3点を先に調べるだけで見積もりの精度が一段上がる。
見落とされがちなランニングコスト
初期費用ばかり議論されるが、5年で見ると③と⑤が効いてくる。
- クラウド型の月額(ユーザー課金かデバイス課金かで5年総額が大きく変わる)
- スマートウォッチのバッテリー劣化に伴う更新(実運用では2〜3年で更新を見込む)
- 端末の紛失・破損の補充(現場端末は年間数%の消耗を織り込む)
- しきい値チューニングの工数(前章の月次レビュー分)
5年総保有コストで比較しないと、初期費用の安い提案が高くつく。 特にユーザー課金型のクラウドは、シフト制で人数が多い工場では想定より膨らみやすい。
独自試算|検知〜着手を4分→1分にした場合の年間効果
投資判断のために、効果側を同じ通貨で置いてみる。以下はすべて仮定値による試算であり、外部統計ではない。自社の数字に置き換えて使ってほしい。
前提(すべて仮定)
- 工場規模:20ライン、2交代、年間稼働250日
- チョコ停の発生:1ラインあたり1日8件
- 検知〜着手の待ち時間:平均4分 → 1分に短縮(短縮幅 3分/件)
- ライン停止1時間あたりの機会損失:1,200 THB と仮定
計算
| 計算ステップ | 式 | 結果 |
|---|---|---|
| 年間の短縮時間(分) | 20ライン × 8件/日 × 3分/件 × 250日 | 120,000分/年 |
| 時間に換算 | 120,000分 ÷ 60 | 2,000時間/年 |
| 金額に換算 | 2,000時間 × 1,200 THB/時(仮定) | 2,400,000 THB/年 |
年間およそ 240万THB の効果、という数字が出る。ただしこの数字をそのまま稟議に載せるのは危険だ。理由は2つある。
- 1,200 THB/時は仮定値である。実際の機会損失は、そのラインが受注に対してボトルネックかどうかで大きく変わる。余力のあるラインの停止は、残業で吸収できてしまえば損失にならない
- 短縮した時間が売上に変換される保証がない。停止が減っても、後工程が受けきれなければ在庫が増えるだけになる
なお、製造業の計画外ダウンタイムのコスト水準については複数の調査があり、業界平均で1時間あたり数万USD規模とするものから数十万USD規模とするものまで推計に大きな幅がある。自動車産業は突出して高いとされる(計画外ダウンタイムのコストに関する整理、製造業ダウンタイムコストの見通し)。調査により幅が大きいため、単一の数字を自社の前提に流用しないことを強く勧める。
回収年数は「幅」で示す
上の効果額と費用レンジを突き合わせる。ここで、効果の実現率(設計どおりに待ち時間が縮む割合)を保守的に見る列を足すのが実務的だ。
| ケース | 初期費用 | 年間効果の見込み | 単純回収年数 |
|---|---|---|---|
| 楽観(既存信号流用・無線流用可・効果100%実現) | 120万THB | 240万THB | 約0.5年 |
| 標準(一部工事あり・効果60%実現) | 250万THB | 144万THB | 約1.7年 |
| 保守(全面工事・多言語対応・効果40%実現) | 450万THB | 96万THB | 約4.7年 |
回収年数は おおむね0.5〜5年の幅に散る。この幅の広さこそが、本記事が3層モデルを勧める理由だ。楽観ケースと保守ケースを分けているのは製品の価格ではなく、検知層の既存流用性と、効果の実現率である。つまり、値引き交渉より先に「どの層にいくら必要か」を切り分けたほうが、回収年数への影響が大きい。
そして効果の実現率を決めるのが、冒頭で挙げた実装レベルだ。L3(プッシュ通知が飛ぶ)で止まると、効果は「たまたま早く気づいた分」に留まる。 エスカレーションとACK、そして実績分析まで含むL4に到達して初めて、待ち時間の短縮が再現性のある数字になる。上の表の実現率100%はL4が定着した状態、60%はL4まで作ったが運用が定着途上の状態、40%はL3止まりを想定している。見積書を比べるときは、金額の前に「その提案はL3どまりか、L4まで含んでいるか」を確認してほしい。
タイ・ASEAN工場で追加になる論点(多言語・離職率・騒音・BOI)
日本国内の導入事例をそのまま持ち込むと、タイでは必ず追加論点が出る。設計段階で織り込んでおくべきものを挙げる。
多言語は「翻訳」ではなく「コード化」で解く
タイの工場では、タイ語・日本語・英語に加え、ミャンマー語やカンボジア語の作業者がいる現場も多い。通知文面を全言語で用意する方式は、アラームが増えるたびに翻訳作業が発生して破綻する。
現実的なのは、アラームをコード+アイコンで定義し、表示言語はユーザー設定で切り替える設計だ。通知本体は「設備名+アラームコード+色」で構成し、詳細説明だけを言語テーブルで持つ。この方式なら、アラームの追加は言語テーブルの1行追加で済む。
離職率と属人化の関係
タイの生産年齢人口は減少局面に入っており、EV関連をはじめとする新規進出企業との人材競合で製造技術者の給与が上昇しているという指摘がある(タイの労務動向に関する解説、タイの人口・労働力構造に関する分析)。
これは通知システムの設計に直接効いてくる。「ベテランが常駐して設備を見ている」という前提の運用は、人材流動が高い環境では持続しない。 ベテランが辞めた瞬間に、どの音がどの異常を意味するかという暗黙知が消える。記録層でアラーム種別と対処内容を蓄積しておくことは、教育コストと引き継ぎリスクへの保険でもある。
ACK履歴から「特定の1人にしか対応できていないアラーム」を洗い出せば、その設備が次の離職で止まるリスクを事前に把握できる。これは通知システムの副次効果というより、記録層を持つ主要な理由の一つと考えてよい。
騒音・環境条件
タイの工場は、空調のない建屋やオープンな構造が多く、雨季のスコール音も加わる。騒音レベルが高い建屋では、構内放送やブザーによる到達は著しく不利になる。振動デバイス(スマートウォッチ)の優位性は、日本の空調付き工場より大きく出やすい。
加えて、高温多湿と粉塵に耐える端末保護等級、雷サージ対策(雨季の雷対策は現地で一般的に求められる項目であり、屋外配線を伴うAPやゲートウェイでは特に確認しておきたい)、停電時の通知経路確保(サーバのUPSだけでなくAPの電源も)を設計に含める必要がある。
BOI恩典との関係
タイ投資委員会(BOI)は、自動化・デジタル関連の投資に対する恩典を継続的に用意している(BOIの自動化・ロボット産業向け投資奨励政策)。ただし対象範囲や条件は改定されるため、具体的な税率や適用可否をこの種の記事の情報で判断せず、必ず申請時点の最新条件を確認することを前提としてほしい。
実務上のポイントは、恩典の適用可否ではなく申請のタイミングだ。投資実行後に「恩典の対象だった」と気づくケースが実際にある。通知システム単体では規模が小さくても、自動化投資のパッケージに含めることで検討対象になる場合がある。稟議の初期段階で、社内の管理部門またはBOIコンサルタントに一度確認しておくコストは低い。
導入ステップとPoCの進め方
3層モデルに沿った現実的な進め方を示す。全ラインを一気にやらないことが最大のリスク低減策になる。
ステップ1|現状のMTTRを実測する(1〜2週間)
前述のとおり、測るのは異常発生から人が現場に着くまでの時間だ。特別な仕組みは要らない。ストップウォッチと記録用紙で20〜30件測れば分布が見える。あわせて、そのとき誰が対応したか、何のアラームだったかも記録する。
この実測値が、後の効果検証のベースラインになる。これを取らずに導入すると、導入後に「効果が出た」と主張する根拠が永久に持てない。この2週間を惜しむプロジェクトは、稟議の2回目で必ず詰まる。
ステップ2|対象を絞ってPoC(4〜6週間)
対象は1〜2ライン、通知を載せるアラームは5種類以内、参加者は10人以内に絞る。PoCで確認すべきは製品の機能ではなく、次の4点だ。
| 検証項目 | 測り方 | 判断の目安 |
|---|---|---|
| 到達率 | 送信件数に対する端末受信件数 | 99%未満なら無線設計を疑う |
| ACK率 | 通知件数に対するACK件数 | 80%未満なら運用ルールか通知量の問題 |
| 検知〜着手の中央値 | システムログ | ベースラインから明確に短縮しているか |
| 誤報率 | 通知件数に対する「行ったが異常なし」件数 | 10%を超えると信頼が崩れ始める |
誤報率が高いまま本番展開すると、失敗2(アラート疲労)に直行する。PoCで誤報率が下がりきらない場合、原因はほぼ検知層のしきい値にある。到達層の製品を変えても解決しない。
ステップ3|Go/No-Goの基準を先に決めておく
PoC開始前に、何をもって次に進むかを文書化しておく。後から基準を決めると、投資した手前「成功」に寄せた解釈になる。基準の例としては、到達率99%以上、ACK率80%以上、検知〜着手の中央値がベースライン比で40%以上短縮、誤報率10%以下、といった置き方になる。
ステップ4|段階展開と記録層の立ち上げ(3〜6か月)
展開はボトルネック工程から始める。効果額が最も大きく、社内での説得力も高いためだ。同時に、記録層の月次レビューを最初のラインから開始する。記録層は展開が終わってから作るものではない。最初の1ラインから回し始めないと、レビューの習慣がつかないまま全ラインに広がる。
よくある質問(FAQ)
設備異常 通知システムとアンドンシステムの違いは?
アンドンシステムは、異常を光や表示で「その場にいる人」に伝える到達手段の一つです。設備異常 通知システムは、検知・到達・記録の3層をカバーする仕組み全体を指します。アンドンは到達層の一部と位置づけられ、視界にいない人には届かないという物理的な制約があります。両者は置き換えの関係ではなく、アンドンを残したまま個人端末への通知を足す構成が一般的です。
設備異常 通知システムの費用はどれくらい?
タイの20ライン規模の工場で、初期費用は概算120万〜450万THBのレンジに収まることが多いという整理を本文の費用章で示しました。幅が大きい要因は、既存PLCから信号を流用できるか(検知層)と、構内無線をゼロから構築する必要があるか(経路層)の2点です。加えて、年間保守が初期費用の15〜25%程度、クラウド型なら月額課金が発生します。5年総保有コストで比較してください。
スマートウォッチと工場用スマホ、どちらが向いている?
役割が違うため、どちらか一方ではなく併用が現実的です。整理すると次のようになります。
| 観点 | スマートウォッチ | 工場用スマホ |
|---|---|---|
| 得意なこと | 騒音下・手がふさがった状態での受信 | 詳細確認、履歴参照、原因入力 |
| 情報量 | 少ない(設備名+種別程度) | 多い |
| 装着性 | 常時装着できる | ポケットから取り出す動作が必要 |
| 適した役割 | 一次通知の受信とACK | 二次確認と記録入力 |
騒音の大きいタイの工場では、振動による一次通知の価値が特に高くなります。
既存の古い設備でも通知システムは導入できる?
導入できます。PLCを持たない古い設備でも、実務上は次の順で選択肢を検討します。
- 既存の接点信号を借りる:回転灯やブザーの信号線から分岐して取り出す。最も安価
- 外付けセンサを足す:電流センサ(CT)でモーターのON/OFFを取る、光電センサでワークの流れを見る
- 設備の稼働ランプを光センサで読む:改造できない設備でも非接触で状態が取れる
経験上、1番目の「既存の接点信号を借りる」だけで対象設備のかなりの部分をカバーできる工場が多く、まず現場の回転灯とブザーの配線を確認するところから始めるのが定石です。「古いから無理」という前提で検討を止めているケースが最も多いパターンです。
通知が多すぎて無視されるのを防ぐには?
対策は4つあり、上から順に効果が大きいです。
- 通知に載せる異常を絞る:人が行かないと復旧しない異常のみ。自動復帰する軽微なエラーは記録層のみに入れる
- 重大度でルートを分ける:P3(軽微・要監視)はリアルタイム通知しない
- 集約とフラッピング抑制:同一設備の同一アラームは一定時間内で1件に集約する
- 通知量をKPIとして月次でレビューする:件数、ACK率、未応答件数を見てしきい値を調整する
一度「無視する」習慣がついた現場を立て直すのは、最初から設計するより大幅に高コストです。導入初期こそ通知を絞ってください。
まとめ
設備異常 通知システムの投資判断は、製品比較から始めると必ずぼやける。最初にやるべきは、自社のMTTRのうち「検知〜着手」がどれだけあるかの実測だ。ここが短ければ投資優先度は低く、長ければ効果は大きい。
設計は3層で切り分ける。検知層では何を異常とみなすかを絞り込み、通知に載せるのは人が行かないと復旧しない異常だけにする。到達層では単一手段に頼らず、振動(ウォッチ)で一次通知、スマホで詳細、アンドンで状態共有、未応答時は手段を変えてエスカレーションする。ここで到達品質を決めるのは通知ソフトではなく構内無線の設計だ。記録層では、これまで記録に残らなかったチョコ停を自動で蓄積し、性能稼働率の改善とOEE分析につなげる。
費用は5層(検知・経路・基盤・端末・導入保守)に分解して見る。20ライン規模のタイの工場で初期120万〜450万THBというレンジになり、変動要因は既存信号の流用可否と無線工事の要否に集中する。本文の試算(すべて仮定値)では、検知〜着手を4分から1分に短縮した場合の年間効果は約240万THB、単純回収年数は効果の実現率次第でおおむね0.5〜5年の幅に散った。この幅を縮める鍵は値引きではなく、どの層にいくら要るかの切り分けにある。
そしてタイ特有の論点——多言語はコード化で解く、離職率の高さゆえに記録層が引き継ぎ保険になる、騒音環境では振動デバイスの優位が大きい、BOI恩典は投資実行前に確認する——を設計段階で織り込んでおくこと。後から足すと、いずれも高くつく。
現状のMTTRを測ってみたが自社がどの層から手を付けるべきか判断がつかない、あるいは既存のアンドンを残したまま個人端末への通知を足す構成が現実的か知りたい、といった段階でのご相談を歓迎します。TOMAS TECHはタイ・バンコクを拠点に、日系製造業の設備稼働監視・IoTトレーサビリティ・工場ネットワークの設計を支援しています。製品選定の前に、検知層・到達層・記録層のどこがボトルネックなのかを切り分ける作業だけでも、社外の視点を入れると論点が早く出ます。ご相談はお問い合わせフォームからどうぞ。