設備保全システムの選び方2026｜台帳の粒度と3本の起票経路

設備保全システムを検討する工場の多くは、製品比較表から入る。だが導入から半年で紙のチェックシートが復活している現場を見ると、原因は機能の不足ではない。決まっていなかったのは、台帳をどの単位まで刻むかと、作業をどの経路で起票するかの2点である。本稿はこの2つの設計変数に絞り、タイの中規模工場を想定したモデル試算とともに、製品選定より前に自社で決めておくべきことを整理する。

設備保全システムが「入れたのに使われない」に終わる理由

保全のシステム化に失敗した工場には、共通の光景がある。システムは稼働している。ライセンス料も払い続けている。それでも保全課の机には紙のチェックシートが戻っていて、故障の記録はホワイトボードと個人のノートに残っている。システム側の起票は月に数件しかない。

この状態を「定着しなかった」と表現すると、原因が現場の意識の問題に見えてしまう。しかし実際に起きているのは、ほぼ例外なく設計の問題である。定着しない工場の台帳を開くと、設備コードが工程名と混ざっていたり、同じ設備が移設のたびに別コードで登録されていたりする。故障の記録を集めても、どの単位に何件積み上がっているのかが分からない。分からないから誰も集計を見ない。見られない記録は書かれなくなる。この順序で崩れていく。

機能比較で選ぶことの問題は、比較軸が「できることの数」になってしまう点にある。実際に現場が毎日触るのは、起票・作業実績入力・完了の3画面だけである。この3画面が自社の保全の流れと合っているかどうかが定着を決めるのに、比較表にはその情報が載らない。載っているのは、バーコード対応・図面添付・多言語UI・予算管理といった機能の有無だけである。どれも重要だが、どれも定着の決定要因ではない。

計画外停止そのものの大きさは、外部の調査でも繰り返し確認されている。2026年時点でも計画外停止に苦しんでいる製造業は79%とされる。管理ツールの普及が進んでもなお、この比率は高い水準にとどまっている。ツールが足りないからではなく、記録の設計が足りないからだと考えるほうが実態に近い。

この表で注目すべきなのは、コストの絶対値ではなく、売上に対する比率が8%から11%へ上がっている点である。設備が高度化し、ラインの連結が密になるほど、1台の停止が波及する範囲が広がる。停止1件あたりの損失は放っておくと増える。一方でCMMS市場は年率9.3%で伸びている。ツールは増えているのに損失比率は増えている。この乖離こそが、本稿の出発点である。

停止時間そのものの分析、特に短時間停止の積み上がりについてはチョコ停とOEEの記事で扱っている。本稿はその手前、記録を取るための器の設計に絞る。器が決まっていない工場でいくら分析手法を導入しても、分析対象のデータが生まれない。

失敗の構造を一文にすると、次のようになる。設備保全システムは、機能数ではなく、①設備台帳の粒度と、②起票経路の本数の2つで決まる。この2つを決めずに製品を選ぶと、MTBFもMTTRも計算できない台帳ができあがる。以降の2章で、この2つを順に設計する。

第1の設計変数｜設備台帳の粒度をどこまで刻むか

設備台帳の粒度とは、「どの単位に故障・時間・費用を積み上げるか」の決定である。多くの工場はこれを台帳の項目設計だと思っているが、実質的には測定単位の決定であり、あとから何が測れるかを規定する。

現実の工場は、次の5階層で表現できる。上から下へ、粒度が細かくなる。

階層を並べると当たり前に見えるが、実際の台帳ではこの5つが2つか3つに潰れていることが多い。よくあるのは、ラインと設備が同じ階層に並んでいるケースと、ユニットが存在せず設備の下がいきなり部品になっているケースである。前者では、ライン全体の停止と設備1台の停止が同じテーブルに混ざるため、稼働率の分母が壊れる。後者では、故障の傾向を部位でまとめられないため、同じ油圧系のトラブルが「ポンプ交換」「シール交換」「配管修理」としてバラバラに残り、原因分析が成立しない。

刻む深さが浅すぎる場合と深すぎる場合で、失敗の現れ方は逆になる。浅い台帳は、書くのは楽だがあとで何も分からない。設備単位までしか刻まないと、故障が集中している部位が特定できず、対策が「点検頻度を上げる」以外に出てこない。逆に、最初から部品単位まで必須入力にした台帳は、起票の負担が跳ね上がる。夜間の突発対応で、油圧ポンプの型式と製造番号を入力しないと起票が完了しない仕様にすると、現場は起票そのものをやめて口頭で済ませる。この時点でシステムは死んでいる。

実務上の解は、階層を全部作ったうえで、必須入力の階層を用途ごとに分けることである。具体的には、費用を積む単位を設備、故障モードを積む単位をユニットに置く。起票時の必須入力は設備コードとユニットの2つまでとし、部品は作業実績の入力段階で任意に紐づける。この設計にすると、夜間の突発時でも15秒で起票が終わり、翌日の作業実績入力で部品情報が補完される。台帳の深さを保ったまま、起票の負担を上げない唯一の方法がこれである。

推奨案の要点は、ユニットの選択肢を設備ごとに10個以下に固定しておくことである。ユニットをフリーテキストにすると表記ゆれで集計が壊れ、逆に階層マスタから全部品を選ばせると選択に時間がかかる。10個以下のプルダウンなら、タブレットで1タップで選べる。集計の粒度と入力の速度を両立させる境界が、経験上この10という数字の近辺にある。

台帳設計でもう1つ落とすと後戻りできないのが、設備コードの採番ルールである。原則は単純で、コードは「置き場所」ではなく「資産」に付ける。工程名や設置場所を含んだコード、たとえば組立2号ラインの3番目という意味を持つコードを採番すると、レイアウト変更や移設のたびにコードを変える必要が出る。コードを変えると過去の履歴が切れる。履歴が切れた設備のMTBFは計算できない。

資産ベースを選んだ場合、所属ラインや設置場所は台帳の属性として持ち、変更履歴を残す。こうしておくと、ある設備の生涯保全費を追いながら、同時に「2026年上期に組立2号ラインで発生した停止」も集計できる。逆は成立しない。場所ベースで採番したコードから資産の生涯履歴を復元するのは、移設が1回でもあれば手作業になる。採番は初日に決めるべき事項であり、走り出してからの変更コストが最も高い項目でもある。

台帳の属性項目としては、最低限、設備種別・メーカー・型式・製造年・導入年・所属ライン・重要度区分・保守契約の有無を持たせる。このうち重要度区分は、後述する起票経路の設計と部品在庫の設計の両方で使うため、3段階程度で必ず入れておく。区分の定義は「停止したときにラインが止まるか」を基準にするのが最も揉めない。代替機がある、迂回できる、止まると全ラインが止まる、の3つに分けると、現場と保全課の認識が一致しやすい。

第2の設計変数｜起票経路は3本ある（BM・PM・CBM）

2つ目の設計変数は、作業がどうやってシステムに現れるか、つまり起票経路である。保全の作業は、起票のトリガーによって3本に分かれる。この3本は業務の性質がまったく違うのに、多くの導入案件では1本の「作業依頼」画面に押し込められる。

3本を分けるべき理由は、管理指標が違うからである。BMで見たいのは「減っているか」であり、件数が減るほど良い。PMで見たいのは「予定どおりやれているか」であり、実施率が100%に近いほど良い。CBMで見たいのは「検知が当たっているか」であり、しきい値が緩すぎれば見逃し、厳しすぎれば空振りが増える。3本を同じテーブルに混ぜると、この3つの指標がいずれも計算できなくなる。「今月の作業件数120件」という数字は、BMが増えたのかPMが増えたのか区別できない時点で、経営指標として何の意味も持たない。

「予防保全と予知保全の違いは何か」という問いには、思想や高度さの話で答えられることが多いが、システム設計の観点では答えは単純である。違いは起票のトリガーが時間なのか状態なのかの1点に尽きる。PMは、前回実施から3か月、あるいは稼働2,000時間、あるいは生産10万ショットといった時間軸の条件で自動起票される。CBMは、振動が規定値を超えた、モーター電流が上昇した、油温が上限に達したという状態の条件で起票される。同じ「壊れる前にやる」でも、トリガー設計と必要なデータがまったく違う。

PMの設計で実務的に効くのは、トリガーをカレンダーだけにしないことである。カレンダー基準のPMは、稼働が少ない月にも作業が発生し、逆に繁忙で稼働が2倍になった月でも同じ頻度で回る。稼働時間や生産数を条件に加えられるシステムを選ぶと、実態に合った頻度になる。ただし稼働時間を条件にするには、設備から稼働信号を取れていることが前提になる。取れていない設備は当面カレンダー基準で運用し、稼働監視を入れた設備から順に切り替える、という段階設計にすると現実的に回る。

3本目のCBMは、しきい値の設計そのものが運用になる。導入直後は必ず空振りが出るため、最初の3か月は「起票せず通知だけ」のモードで走らせ、実際に異常だった比率を見てからしきい値を確定する手順を踏む。この助走を飛ばすと、空振りの起票が積み上がって保全員が通知を無視するようになる。しきい値と通知先の設計については設備異常の通知設計の記事で詳しく整理している。

3本の経路を分けたうえで、それぞれのステータス遷移も分けて設計する。BMは「起票→着手→復旧→原因記録→完了」の5段階が要る。復旧と完了を分けるのがポイントで、応急処置でラインを動かした時点と、恒久対策が終わった時点は別の日になることが多い。これを1つのステータスにすると、MTTRが恒久対策の日数まで含んだ数字になり、実態の何倍にも膨らむ。一方でPMは「予定→実施→完了」の3段階で足りる。CBMは「検知→判定→（BMまたはPMへ転送）→完了」となり、判定の段階で空振りを閉じる導線が要る。

この3本の分離ができていない工場に、いきなり高度な仕組みを載せても効果は出ない。むしろ起票の総量だけが増えて、保全員の可処分時間を奪う。順序としては、BMを一本化し、PMの自動起票を載せ、そのうえでCBMを限られた設備に入れる。この順序は後段の導入計画の章で具体的な日数に落とす。

MTBFとMTTRが「出る」ための最低条件

台帳の粒度と起票経路が決まると、次に問題になるのは時刻の取り方である。MTBFとMTTRは、システムに機能があれば出てくる数字ではない。必要な時刻を取っていなければ、どんな製品でも計算できない。

取るべき時刻は4つある。

多くの工場は、このうち発生と復旧の2つしか取っていない。それでもMTTRは計算できる。MTTR＝復旧−発生だからである。だが2点しかないと、短縮すべき区間が特定できない。MTTRが4.5時間と出たときに、そのうち何時間が「誰も気づいていなかった時間」で、何時間が「気づいたが人が来ていない時間」で、何時間が「実際に直していた時間」なのかが分からない。分からないまま「MTTRを短縮せよ」と指示すると、現場は直す速度を上げようとする。しかし多くの場合、最も長いのは直している時間ではない。

4つの時刻を取ると、停止時間は3つの区間に分解できる。発生から検知までが気づきの遅れ、検知から着手までが動員の遅れ、着手から復旧までが実作業である。このうち検知から着手までの区間は、最も長くなりやすいのに最も測られていない。理由は単純で、着手時刻を打刻する仕組みがないからである。保全員は現場に走っていって作業を始めるので、その瞬間に何かを記録する動機がない。ここを取るには、モバイルでの1タップ着手か、設備のQRコードを読ませる運用のどちらかが要る。

稼働率の定義は、稼働率 ＝ MTBF ÷（MTBF ＋ MTTR）である。この式で見落とされやすいのは、分母のMTTRに入るのが「直していた時間」ではなく「復旧までの全時間」だという点である。つまり気づきの遅れも動員の遅れも、そのまま稼働率を下げている。逆に言えば、修理そのものの技術を上げなくても、検知と動員を速くするだけで稼働率は上がる。これが保全のシステム化で最初に取れる効果であり、しかも設備投資をほとんど伴わない。

MTBFの側も、定義を先に決めておかないと数字が揺れる。MTBFは故障間の平均動作時間なので、分子に入れる「動作時間」に計画停止を含めるかどうかで結果が変わる。休日や段取り替えを含めた暦時間で割ると、MTBFは実態より長く出る。原則は、生産に供された時間だけを分子に取ることである。そして分母となる故障件数には、BM経路の起票だけを数える。PMの作業をここに混ぜると、点検をやるほどMTBFが下がるという逆転が起きる。ここでも起票経路の分離が効いてくる。

これらの定義は、システムを選ぶ前に社内で文書化しておくべきものである。製品によっては初期設定でしか変えられない項目があり、あとから定義を変えると過去データとの比較ができなくなる。逆に定義さえ固まっていれば、集計そのものはどの製品でも大差なく実現できる。ここでも、決定的なのは製品側ではなく発注側である。

保全部品の在庫と、費用が見えるようになる境界

保全費が見えない工場は多い。理由の大半は、作業と部品が紐づいていないことにある。部品は購買のシステムで発注され、倉庫で受け入れられ、保全員が持ち出して使う。ここまでは記録が残る。だが「どの設備のどの作業に使ったか」が残らないため、部品費が設備別に積み上がらない。結果として、保全費は工場全体の1行としてしか把握できず、どの設備が費用を食っているのかが最後まで分からない。

これを解くのは技術的には難しくない。作業実績の入力画面で、使用部品を選択させるだけである。難しいのは運用のほうで、部品マスタが整備されていないと選択肢が出てこない。実務では、まず金額の大きい上位20%程度の部品だけをマスタ化し、それ以外は「その他部品」として金額のみを入力させる運用から始める。金額ベースで見れば、上位の少数の部品が保全費の大半を占めるため、これだけで設備別の費用はおおよそ見えるようになる。

保全部品の在庫は、生産用の資材在庫とは性質が違う。ここを同じ考え方で管理しようとすると必ず破綻する。

この違いを踏まえると、保全部品の在庫方針は「回転率で切らない」ことになる。年に1回しか出ない部品でも、それが止まるとライン全体が止まる設備の臨界部品であれば常備する。判断基準は回転率ではなく、欠品したときの停止時間と時間単価の積である。台帳の重要度区分をここで使う。重要度が最上位の設備に載っている部品のうち、調達リードタイムが停止許容時間を超えるものだけを常備対象にする、という決め方が最も説明しやすい。

在庫と作業が同じシステムの中でつながると、もう1つ副次的な効果が出る。作業実績から部品の実消費履歴が蓄積されるため、発注点の見直しが実データでできるようになる。それまでは担当者の記憶と勘で決まっていた常備数量が、過去24か月の消費実績から算出できる。これは費用削減としても効くが、それ以上に「なぜこの数量なのか」を説明できるようになる点が大きい。監査や予算折衝の場で、常備在庫の妥当性を数字で示せる工場は少ない。

設備保全システムの費用相場と見積の内訳

費用の形態は大きく3つに分かれる。クラウドの設備課金型、クラウドのユーザー課金型、オンプレミス型である。どれを選ぶかで初期費用と月額の構造がまったく変わるため、設備台数と利用者数の比率で有利不利が入れ替わる。

見積書で必ず金額が割れるのは、次の5項目である。製品のライセンス料は各社ほぼ横並びになるため、総額の差はこの5項目から生まれる。

このうち総額に最も効くのは台帳の初期構築である。設備100台をユニットまで刻むと、ユニットのレコードは数百件になる。これを外部に委託するか自社でやるかで、数十万バーツ単位の差が出る。実務では、台帳の階層設計と採番ルールを自社で決めたうえで、入力作業だけを委託するのが最も費用対効果が高い。設計を委託すると、自社の測定単位を外部が決めることになり、本稿の主張の核心を手放すことになる。

以下はタイの日系・中規模工場を想定したモデル計算である。特定顧客の実績値ではなく、公開情報と一般的な相場から組んだ試算であることを最初に断っておく。

逸失利益の8,000バーツ/時は、ライン1本の粗利ベースで置いた控えめな数字である。実際の工場では、外注振替や残業での挽回を含めるともっと大きくなることが多いが、ここでは過大に見せないために低めに置いている。この前提のもとで、現状の損失は次のように計算できる。月10件 × 4.5時間 ＝ 45時間/月、45時間 × 8,000バーツ ＝ 360,000バーツ/月、年間では 4,320,000バーツになる。

効果は2つの経路から出る。1つ目はMTTR側で、先に述べた「検知から着手まで」の短縮である。通知が保全員のモバイルに直接届き、着手が打刻される運用にすると、この区間は 0.9時間 から 0.3時間 まで縮む。1件あたり 0.6時間 の短縮で、月10件 × 0.6時間 ＝ 6時間、6時間 × 8,000バーツ ＝ 48,000バーツ/月となる。短縮後の1件あたり停止時間は 4.5 − 0.6 ＝ 3.9時間 になる。

2つ目はMTBF側で、PMの自動起票による実施率の改善である。紙の点検計画で運用していたときのPM実施率を 68% とし、システムによる自動起票と期限管理で 92% まで上げる。この改善によって計画外停止が月10件から 8.5件 へ、15% 減ると置く。減った 1.5件 × 3.9時間 ＝ 5.85時間 で、46,800バーツ/月 となる。効果合計は 48,000 ＋ 46,800 ＝ 94,800バーツ/月、年間 1,137,600バーツ である。

ここで重要なのは、この効果の側は器を変えても動かないという点である。クラウドを選んでもオンプレミスを選んでも、台帳の粒度と起票経路が同じなら、出てくる効果は同じ 94,800バーツ/月 になる。動くのは費用の側だけである。

設備課金とユーザー課金の優劣は、設備台数と利用者数の比率で決まる。このモデルでは設備100台の月額が 25,000バーツ で固定なのに対し、利用者26名のユーザー課金は 31,200バーツ になるため、設備課金が有利である。分岐点は利用者およそ21名で、これを下回る工場ならユーザー課金のほうが安い。逆に、設備が300台あって利用者が20名の工場では、設備課金が月 75,000バーツ になるためユーザー課金が有利になる。相場を見るときは月額の単価だけでなく、自社の台数と人数の比率をあてはめて計算する必要がある。

効果の立ち上がりも織り込む必要がある。台帳の整備と運用の一本化が終わるまで効果は出ないため、1年目は6か月ぶんとして 568,800バーツ、2年目と3年目は満額の 1,137,600バーツ とする。3年累計の効果は 568,800 ＋ 1,137,600 × 2 ＝ 2,844,000バーツ になる。

差益の開きは 1,594,000 ÷ 234,000 で約 6.8倍 になる。同じ効果を出しているのに、器の選び方だけで3年の投資回収がこれだけ違う。しかもオンプレミスを選んだ場合、3年の差益 234,000バーツ は年あたり8万バーツ弱であり、為替や保守費の変動で簡単に消える水準である。台数がこの規模の工場でオンプレミスを選ぶ合理性は、外部接続を一切許さないセキュリティ要件があるときくらいしか残らない。

繰り返しになるが、上記はすべてモデル計算であり、特定顧客の実績ではない。自社の数字にあてはめるときは、停止1時間あたりの逸失利益と、現状のPM実施率の2つを実測値に置き換えるだけで、おおよその輪郭は出る。この2つが分からない段階でベンダーに相見積もりを取っても、比較の基準が存在しないため、結局は月額の安さで選ぶことになる。

既存システムとの境界線をどこに引くか

保全のシステム化を進めると、必ず既存システムとの重複の議論が起きる。生産管理システムに設備マスタがある、IoTの稼働監視で停止は見えている、といった話である。ここで境界線を曖昧にすると、二重入力が生まれて運用が破綻する。

境界の引き方は、各システムが答えるべき問いで整理すると明快になる。

生産管理と保全は、設備マスタを共有していても目的が違う。生産管理側の設備マスタは工程の能力を表すためのもので、能力・段取り時間・原価センターを持つ。保全側の設備マスタは資産を表すためのもので、製造年・保守契約・部品構成を持つ。両者を1つにまとめようとすると、どちらの用途にも中途半端なマスタができる。実務的には、設備コードだけを共通の主キーとして揃え、属性は各システムが必要なものを持つ形が最も安定する。

IoT稼働監視との関係は、もっと明確に切れる。稼働監視は検知の入口であって、保全の実行系ではない。監視が返すのは「止まった」という事実と時刻であり、そこから先の起票・割り当て・作業実績・費用は保全システムの領域である。両者をつなぐインターフェースは、停止イベントを保全システムのBM起票に自動変換する1本だけでよい。この1本があると、4つの時刻のうち「発生」が人手の記憶ではなく機械の記録になり、MTTRの精度が一段上がる。稼働監視そのものの入れ方は工場IoTの導入の記事で扱っている。

より高度な故障予測の仕組みは、3本目の起票経路であるCBMをさらに進めたものと位置づけられる。この領域は予知保全システムの記事で詳しく整理しているが、順序としては注意が要る。1本目のBMと2本目のPMが回っていない工場に先に入れると、起票が増えるだけで終わる。予測が「この設備が3週間以内に故障する可能性が高い」と告げたところで、PMの作業計画に組み込む仕組みがなければ、その情報は誰も動かせない。予測の出力先はPMの作業オーダーであり、その受け皿が先に要る。

境界線を引くうえでもう1つ現実的な論点が、図面と手順書の置き場所である。保全システムに図面を格納するか、既存の文書管理に置いてリンクするかで議論になる。判断基準は更新の頻度で、年に数回しか更新されない図面は文書管理に置いてリンクし、作業のたびに更新される点検手順は保全システム側に持たせるのが扱いやすい。保全システムをファイルサーバー代わりにすると、容量課金の製品では月額が跳ね上がる。

タイの工場で追加になる4つの条件

日本国内と同じ設計をタイの工場にそのまま持ち込むと、4つの点で追加の検討が要る。いずれも技術の問題ではなく、人と契約と制度の問題である。

1つ目は保全人材の確保である。タイの製造業就業者は 624万人（2024年12月時点）と厚い層があるが、保全のような技能職では需給が合っていない。製造業の求人 87,000件 に対して求職者は 25,000人 で、実際に成立したのは 16,500件 とされる。求人の8割は埋まっていない計算になる。この状況では、保全のノウハウを個人の頭に置いておくリスクが日本より高い。離職1件で、特定設備の対処法が丸ごと失われる。

だからこそ、作業実績に「何をしたか」の記述を残す運用が効く。手順書の整備は時間がかかるが、過去の類似故障の対処記録は、起票のたびに自動的に蓄積される。同じユニットの過去の作業を起票画面から一覧できるようにしておくと、経験の浅い保全員でも初動が打てる。ここで効いてくるのが、第1の設計変数で決めたユニットの粒度である。設備単位でしか記録していないと、過去の作業一覧が数百件出てきて実用にならない。ユニット単位なら十数件に絞れる。台帳の粒度は、集計のためだけでなく、現場の検索性のためにも効く。

なお、政府側では技能人材の底上げに向けた施策も動いており、BOIによるアップスキル支援として 50億バーツ規模・10万人 を対象とする枠組みが示されている。制度を使うかどうかは別として、保全のような技能領域が政策の対象になっていること自体は、要員計画を立てるうえで前提として押さえておきたい。

2つ目は多言語である。タイの工場では、作業する人・記録を読む人・数字を見る人の言語が違う。ここを1つの言語で通そうとすると必ずどこかで記録が薄くなる。

この3層を意識せずに「多言語対応あり」という機能欄だけで選ぶと、UIは翻訳されているのに帳票が英語のみ、といった状態になる。確認すべきは、UI・マスタの名称・帳票・通知文の4つがそれぞれどこまで多言語化できるかである。特にマスタの名称は見落とされやすい。設備名やユニット名がタイ語でしか登録できないと、日本側の集計表がタイ語で出てくる。名称を言語ごとに複数持てる仕様かどうかを、初期段階で確認しておく。

3つ目は設備ベンダーの保守契約との境界である。タイでは、輸入設備の保守をメーカーの現地法人や代理店の年間契約でカバーしているケースが多い。このとき、契約範囲の作業をどう扱うかを決めておかないと、台帳に穴があく。ベンダーが来て直した故障が自社の記録に残らないと、その設備のMTBFは実態より長く出る。原則は、実施者が社外であっても作業オーダーは自社で起票し、実施者区分だけを社外にすることである。費用も契約に含まれているなら金額ゼロで記録し、別途請求があった場合のみ金額を入れる。こうしておくと、契約更新の交渉時に「この1年でベンダーが何件対応したか」を数字で出せる。

4つ目はBOIの制度との関係である。BOIの「Smart and Sustainable Industry」枠では、2026年上期に 132件・172億バーツ の申請があり、機械更新や自動化への投資が続いている。設備を更新すると台帳の世代管理が必要になり、旧設備の履歴を引き継ぐのか切るのかという判断が発生する。原則は、資産としては別コードを採番しつつ、置き換え関係を属性として保持することである。こうすると、更新前後の停止件数を比較でき、投資効果の説明材料になる。制度を使って設備を入れ替える計画があるなら、その前に台帳の器を整えておくほうが順序として正しい。

導入の進め方｜90日で回るところまで持っていく順序

最後に、ここまでの設計を実際に動かす順序を示す。目安は90日で、対象を絞ることが前提になる。

最初の30日で最も時間を使うのは、システムの設定ではなく社内の合意である。設備コードの採番ルールと、ユニットの分け方をどうするかは、保全課・生産技術・経理の意見が割れる。経理は資産番号と揃えたがり、生産技術は工程順に並べたがり、保全課は現場の呼び名を使いたがる。ここは、コードは資産に付けて呼び名は別名称として持つ、という原則で切るしかない。この30日を短縮しようとすると、後の2年間を壊すことになる。

31日目から60日目のBM一本化では、紙の併用を止めることが唯一の実質的な作業になる。併用期間を長く取るほど定着しない。実務では、対象ラインについて期日を切って紙の様式を回収し、システム以外の起票を受け付けない運用に切り替える。このとき、起票の手間が紙より重ければ現場は必ず抵抗する。だからこそ台帳の粒度の章で述べた「必須入力は設備コードとユニットの2つまで」という設計が効く。紙のチェックシートに書くより速いことが、切り替えの絶対条件である。

61日目からのPM自動起票は、既存の点検計画をそのまま移すところから始める。頻度の見直しは後回しでよい。まず紙の年間点検計画をシステムに載せ、期限管理と実施記録を回す。これだけでPM実施率が初めて数字として出る。多くの工場で、この数字は最初に見たときに想定より低い。計画があっても実施の記録がなかった、というだけのことだが、可視化された時点で改善が始まる。CBMは3台に絞る。センサーを何台に付けるかではなく、しきい値の運用を学習するための3台である。

「全設備・全機能を一度に」を選んだ案件が失敗する理由は、フィードバックが返る前に不可逆な決定が積み上がるからである。100台すべてのマスタを作ってから運用を始めると、ユニットの分け方が現場に合っていなかったと分かるのが半年後になる。そのときには数百件のレコードが積み上がっていて、修正には過去データの再分類が要る。1ラインに絞れば、この気づきは3週間で得られ、修正は数十件で済む。範囲を絞るのは慎重さの表明ではなく、修正コストを下げる技術的な選択である。

90日を終えたあとの展開は、ラインを増やす方向と、機能を足す方向の2つがある。順序としては、まずラインを増やす。同じ設計を横に広げるだけなので、2ライン目以降は30日程度で載る。機能を足すのは、全ラインが1本の設計で回ってからでよい。逆の順序、つまり1ラインで機能を積み上げてから横展開すると、設計の複雑さがそのまま全ラインに複製される。

よくある質問（FAQ）

設備保全システムとは何か

設備の保全作業を、台帳・作業オーダー・実績・費用の4つで管理する仕組みである。一般にCMMSと呼ばれる。中核にあるのは設備台帳で、そこに作業オーダーが紐づき、作業実績として時間と部品と費用が積み上がる。この積み上げがあって初めて、MTBF・MTTR・保全費といった指標が計算できる。逆に言えば、台帳の単位が決まっていないシステムは、機能があっても指標を出せない。

予防保全と予知保全の違いは何か

起票のトリガーが時間か状態かの違いである。予防保全は、前回実施からの経過時間・稼働時間・生産数といった時間軸の条件でシステムが自動起票する。状態を見る保全は、振動や電流や温度がしきい値を超えたという状態の条件で起票される。思想の高低ではなく、必要なデータと設計がまったく違う2本の経路だと捉えるほうが実務に沿う。順序としては、時間軸の自動起票を回してから状態側を足す。

CMMSとEAMは何が違うのか

CMMSは保全業務の実行を管理する範囲、EAMは資産のライフサイクル全体を管理する範囲を指す。EAMには、購入から償却・更新・廃棄までの資産管理、予算計画、調達、契約管理といった領域が含まれる。設備100台規模の工場で先に必要になるのはCMMSの範囲であり、EAMの機能まで含んだ製品を選ぶと初期構築の負担が跳ね上がる。将来EAMに広げる可能性があるなら、設備コードを資産ベースで採番しておくことが唯一の準備になる。

設備保全システムの費用相場はどのくらいか

クラウドの場合、設備課金型でおおむね1台あたり月200〜400バーツ、ユーザー課金型で1名あたり月1,000〜2,000バーツが目安である。これに台帳の初期構築とデータ移行が加わる。本稿のモデル計算では、設備100台・利用者26名の工場で、3年合計が設備課金型 1,250,000バーツ、ユーザー課金型 1,473,200バーツ、オンプレミス 2,610,000バーツ となった。総額を左右するのは月額単価より初期構築の範囲である。

Excelの保全台帳から移行できるか

移行できるが、そのまま取り込むと問題が持ち越される。Excelの台帳は多くの場合、1行が1つの故障記録になっていて、設備の階層構造を持っていない。移行の前に、設備コードの採番ルールを決めて、既存の行に新コードを割り当てる作業が要る。ここを飛ばして表記ゆれのまま取り込むと、同じ設備が複数コードで登録され、集計が最初から壊れる。過去の故障履歴を何年分移すかは、原則として直近2年で足りる。それ以前のデータは、集計の粒度が現在と揃っていないことが多い。

保全記録の電子化はどこから始めるべきか

計画外停止のBM起票からである。点検表の電子化から始める工場が多いが、点検表は紙でも回っているため、電子化しても効果が実感されにくい。一方でBM起票は、電子化した瞬間に4つの時刻が取れるようになり、MTTRの区間分解ができるようになる。効果が数字で見える領域から入るほうが、次の投資判断を通しやすい。対象は1ラインに絞り、紙の併用を期日で止めることが条件になる。

まとめ

設備の保全をシステム化するかどうかの判断は、製品の比較表では決まらない。決めるべきなのは、①設備台帳の粒度をどこまで刻むか、②起票経路を3本に分けるか、の2点である。台帳は5階層で持ち、費用を積む単位を設備、故障モードを積む単位をユニットに置く。起票は事後保全・予防保全・状態基準保全の3本に分け、それぞれのステータス遷移と指標を分ける。そのうえで発生・検知・着手・復旧の4つの時刻を取れば、MTBFもMTTRも自動的に出る。

モデル計算では、効果の側は 94,800バーツ/月、3年累計で 2,844,000バーツ となり、これは器を変えても動かない。動くのは費用の側だけで、3年の差益は 1,594,000バーツ から 234,000バーツ まで、器の選び方で約 6.8倍 ひらいた。この構造が意味するのは単純なことである。投資判断の主要な変数は製品側ではなく発注側にある。台帳の粒度と起票経路を自社で決めておくこと、それ自体が投資判断の中身になる。

台帳をどの単位まで刻むか、起票経路をどう分けるかは、製品を決める前の話である。TOMAS TECHはタイの日系工場で生産・設備まわりのシステムを手がけており、この段階の整理だけでも相談を受け付けている。自社の設備構成でユニットをどこまで分けるべきか、現状のExcel台帳から何を残して何を捨てるか、といった粒度の話で構わない。お問い合わせから気軽に声をかけてほしい。

参考情報

• CMMS比較｜製造業向け保全管理システム（IT trend）
• 設備保全システムの選び方（八千代ソリューションズ）
• MTBFとは（八千代ソリューションズ）
• Why Thailand’s Manufacturing Sector Is Facing a Talent Bottleneck（aplus career）
• Thailand FDI Surges in H1 2026（Thailand Business News）
• The Cost of Unplanned Downtime in Manufacturing（reliamag）
• How Unplanned OT Downtime Is Silently Draining Industrial Profits（Acronis）
• Computerized Maintenance Management Systems Market（Future Market Insights）
• Why 79% of Manufacturers Still Struggle with Unplanned Downtime in 2026（ManWinWin）