MECHPHAISTOSとは？

センサーに頼らず停止ロスと修繕費を減らす設備保全DX

MECHPHAISTOSが提案する設備保全DXは、「センサーがあるかどうか」だけで成否が決まるものではありません。
停止ロスと修繕費を前提にした保全の計画性とリスク管理を重視します。

そしてもう一つ大事なのが、故障予測はセンサーに頼らなくても十分に可能だという点です。
点検・交換・修理・停止対応などの「保全行為」そのものは、設備状態を示す強い手がかりになります。過酷な環境やイニシャルコストの制約で状態監視センサーや電流値に頼れない設備でも、保全履歴・停止要因・故障原因・部品交換の流れを整備すれば、故障確率や交換推奨タイミングを推定できます。

一方で、ここで誤解してはいけないのは、センサーがあれば万能というわけではないことです。
データ数が少なければ、たとえセンサーを付けても学習・分析が成立せず、意味のある予測は出ません。重要なのは「データの種類」と「蓄積のされ方」です。

MECHPHAISTOSのコンセプトは、工場内のCMMSデータを整えるだけに留まりません。
ニアミスなどの安全データ、設備の故障原因、設備に使われる汎用パーツのデマンドや納期、代替可否といった情報を、共通データ（コモンデータ）として扱い、必要に応じて会社間でシェアできる世界を目指します。これにより、センサーや電流値だけでは拾いきれない現場知を補強し、より実務に効くリスク管理と保全戦略の最適化につなげます。

その結果として、ブレイクダウンコスト（突発停止）と修繕費のトレードオフを設備ごとに評価し、現場計画に沿って「最適解」を継続的に提案できる保全DXを実現します。

---

この記事でわかること

• センサーに依存しない設備保全DXの考え方
• CMMSを「共通データ基盤」として使う実務ポイント
• 保全計画起点でAIを活かす導入の流れ
• 修繕費・停止ロス・安全リスクを同時に扱う評価軸

---

1. CMMSは「目的」ではなく「共通データ基盤」

設備保全DXが失敗する最大の原因は、CMMSやAIといったツールの導入そのものが目的化してしまうことです。
入力されない、判断に使われない、結局Excelに戻る──こうしたケースは決して珍しくありません。

これは、多くの従来型CMMSが設備の状態管理や記録管理に重きを置きすぎてきた一方で、
実際に現場で保全・メンテナンスを担う「人」の業務内容や痛み、
「本当はこう判断したい」「ここが分かれば動きやすい」といった視点を十分に汲み取ってこなかったことが大きな要因です。

ここで、工場内にある一つのポンプを例に考えてみます。
このポンプは、あえて壊れてから修理したほうが合理的なケースもあります。
予備機が存在し、破損時も即時切り替えが可能で、
かつ部品交換は安価で済む一方、定期的なオーバーホールは高額になる──
このような条件であれば、「計画停止して修理する」ことが必ずしも最適とは限りません。

さらに、生産キャンペーンの終了が目前に迫っている状況で、
わざわざ設備を止めて修理を行う判断が、本当に得策でしょうか。

ツール導入を目的化してしまうと、
「センサーが異常を示しているから整備すべきだ」という判断に過度に引きずられがちです。
一方で現実には、
「代替機があり、万が一の停止にも対応できる」
「多少の振動を許容しても、生産・納期への影響は小さい」
といった条件を踏まえた判断のほうが、経営的に合理的な場合も少なくありません。

こうした保全・生産・経営のトレードオフを踏まえた判断を、
より効率的かつ再現可能に支援すること。
それこそが保全メンテナンスの本来の役割であり、
MECHPHAISTOSが目指している設備保全DXです。

MECHPHAISTOSでは、CMMSを単なる記録ツールではなく、
保全判断と計画を再現可能にするための共通データ基盤と位置づけます。
重要なのは「何を入力するか」ではなく、
そのデータが、保全メンテナンス担当者や管理者のどんな意思決定を助けるかです。

その前提として、まず整えるべき視点は次の3つです。

1. 重要機器リストとしての設備台帳

設備台帳は、単なる設備一覧ではありません。
どの設備が、どれだけのリスクとインパクトを持つかを明確にするための基盤です。

• 生産停止時の影響（生産量・納期・品質・安全）
• 故障時の復旧難易度
• 過去の停止・故障履歴
• 代替設備や回避策の有無

これらを踏まえ、設備を「重要機器」として優先度付けすることで、
すべてを平等に保全しないという戦略的な判断が可能になります。

2. 生産計画 × タスクリスト × 故障予測

MECHPHAISTOSでは、保全を単独で考えません。
生産計画と日々のタスクリストに、故障予測という視点を重ねることを重視します。

• いつ、どの設備を止められるのか
• どの作業が生産に影響を与えるのか
• 故障が起きた場合、どの工程がボトルネックになるのか

保全履歴や停止要因から算出される故障確率を、
生産計画と照らし合わせることで、
**「今やるべき保全」と「後回しにできる保全」**を明確にできます。

これは、センサーがなくても実現できる、計画起点の故障予測アプローチです。

3. 部品の消費計画のシェアと需要・在庫の最適化

部品情報は、単なる在庫管理ではなく時間軸を持った計画データです。

• 過去の交換履歴から見た消費傾向
• 故障確率に基づく将来需要
• 納期・代替可否・調達リードタイム

これらを共通データとして扱うことで、
工場内だけでなく、商社やサプライヤーとも需要のタイミングを共有できます。

結果として、

• 欠品による復旧遅延の回避
• 過剰在庫の削減
• 緊急調達コストの抑制

といった、保全と調達をまたいだ最適化が可能になります。

これら3つの視点で整備された共通データが、
後工程のAI分析や故障予測の精度を決定します。

---

2. センサーに頼らない保全DXという現実解

状態監視センサーや電流値データは、設備保全において有効な手段の一つです。
しかし、すべての設備を状態監視で管理すべきかどうかという判断プロセスが、これまで十分に整理されてきたとは言えません。

現場では、次のような制約が存在します。

• イニシャルコストが高く、全設備に導入できない
• 粉塵・高温・腐食などの過酷環境で計測が安定しない
• 重要設備ほど後付け改造が難しく、工事リスクや停止リスクが高い

その結果、「本当に管理したい重要設備ほど、センサーに頼れない」という矛盾が生じます。

状態監視すべき設備かどうかを判断するプロセスの欠如

そもそも、電流値や振動値で状態監視すべき設備なのかどうかを見極めるプロセスが抜け落ちているケースは少なくありません。

設備の寿命管理においては、まず機械故障のバスタブ曲線の形状を前提に、
その設備が「状態管理に適しているかどうか」を判断する必要があります。

バスタブ曲線が示すように、設備の故障特性には次のような違いがあります。

• 初期故障が支配的な設備
• 偶発故障が多く、状態変化が事前に現れにくい設備
• 摩耗故障として、劣化傾向が比較的明確に現れる設備

このうち、状態量（電流値・振動値など）と寿命が明確に相関しない設備については、
状態管理そのものが適さない場合があります。
こうした設備では、状態監視を行っていても前兆なく突然故障することがあり、
結果として保全リスクを下げきれないケースも少なくありません。

そのような場合は、使用年数や稼働時間に基づく時間ベースの保全のほうが、
むしろ確実で合理的な選択となります。

この考え方は、John Moubray が提唱した
**Reliability-Centered Maintenance（RCM）**の中でも示されている通り、
「すべての設備に状態基準保全が有効とは限らない」という前提に基づいています。

重要なのは、
状態管理か時間管理かを一律に決めるのではなく、
設備ごとの故障特性とリスクに応じて、最適な管理方法を選択することです。

生産計画とシャットダウンを前提にした合理的判断

設備保全は、「状態が正常かどうか」だけで判断できるものではありません。
工場には、生産計画に基づくシャットダウンのタイミングが存在します。

たとえ状態監視上は正常であっても、

• 設備の重要度
• 故障時の影響範囲（生産・品質・安全）
• 修繕コスト
• シャットダウン時の立下げ・立上げに伴うロス

を総合的に考慮すると、
車検のように、多少過剰であっても定期的なメンテナンスや交換を行ったほうが、結果的にリスクが低いケースは多く存在します。

状態監視だけに判断を委ねると、
生産計画や経営判断と切り離された「部分最適な保全」になりがちです。

保全履歴を「状態の代理変数（proxy）」として扱う

MECHPHAISTOSでは、こうした現実を前提に、
設備の状態を直接計測するのではなく、保全履歴そのものを“状態の代理変数（proxy）”として扱うアプローチを取ります。

具体的には、次のようなデータです。

• 点検頻度の変化
  想定より点検回数が増えている設備は、劣化や不具合の兆候を内包している可能性があります。
• 交換周期の短縮
  同一部品の交換間隔が短くなっている場合、設備全体の健全性低下が疑われます。
• 故障・停止の再発傾向
  同一原因・同一部位での再発は、構造的・運用的な問題を示します。
• 使用部品の偏り
  特定部品の消費集中は、設計・環境・運転条件の歪みを反映します。

これらの保全データを組み合わせることで、
センサーに頼らなくても、設備の劣化傾向や故障確率を推定することが可能になります。

重要なのは、「センサーがあるかどうか」ではなく、
設備の重要度・リスク・生産計画・部品納期を踏まえた上で、どの管理方法を選ぶかです。

この判断を支える共通データとロジックを提供することが、
MECHPHAISTOSが目指すセンサー非依存型の設備保全DXです。

---

3. 現場・保全・経営の「判断スコープ」を揃える

設備保全DXを進めるうえで、もう一つ大きな壁になるのが、
現場（製造）・保全メンテナンス・経営層のあいだで、判断のスコープが揃っていないことです。

特に保全メンテナンスの現場では、次のような「痛み」が頻繁に発生します。

「これはまだ問題ない」と言えない構造

例えば、ある設備からわずかな異音が出ているとします。
保全メンテナンスの立場から見れば、

• この程度の異音であれば直ちに故障にはつながらない
• 今修理すると修繕費がかかりすぎる
• 次の計画停止まで様子を見るほうが合理的

と判断できるケースは少なくありません。

しかし実際には、製造現場や経営層から、

• 「今週末だから」
• 「重要なキャンペーン期間だから」
• 「納期遅延は絶対に許されない」
• 「本当に大丈夫なのか？責任は取れるのか？」

といった強いプレッシャーを受けることになります。

結果として、
手間やコストが過剰であると分かっていても、依頼があれば整備を実施する。
こうした判断が常態化し、修繕費や保全工数が積み上がっていきます。

センサーが生む「逆説的な判断圧力」

この状況に対する、よくある間違った方向性が、
判断の裏付けとしてセンサー類を取り付けることです。

確かに、
「センサー上は問題ありません」という説明は、一時的には説得力を持ちます。
しかしその一方で、

• センサーが異常を示した瞬間に「では今すぐ対応しなさい」
• 状態管理が、かえって判断の自由度を奪う

という逆説的な構造も生まれます。

本来、センサーは判断材料の一つであるはずが、
判断そのものを縛る存在になってしまうのです。

求められるのは「総合的な合理性」に基づく判断

製造や経営層に求めたいのは、
センサー値だけでなく、次のような要素を含めた総合的な合理性での判断です。

• 設備の重要度と停止時の影響
• 現在の生産計画とシャットダウンの有無
• 修繕費と突発停止リスクのバランス
• 代替手段やバックアップの有無

同時に、保全メンテナンス側も、
「感覚」や「経験」だけでなく、

• なぜ今回は問題ないと言えるのか
• どのリスクを受け入れ、どのリスクを回避しているのか

を説明できる保全ストラテジーを提示できる状態である必要があります。

判断スコープを揃えることがDXの本質

MECHPHAISTOSが目指す設備保全DXは、
判断をセンサーやAIに丸投げすることではありません。

• 保全は「なぜ今やらないのか」を説明できる
• 製造は「どこまでなら許容できるか」を共有できる
• 経営は「コストとリスクの最適解」を理解した上で判断できる

このように、判断のスコープと責任範囲を揃えた状態を作ることが目的です。

その結果として、

• 過剰な保全タスクの削減
• 修繕コストの最適化
• 本当に対応すべき設備への集中

が可能になります。

判断スコープを揃えること。
それこそが、保全メンテナンスを守り、
工場全体を合理的に動かすための設備保全DXです。

---

4. データ設計は「型」がすべて

AIや高度な分析を語る前に、
データの型が揃っていなければ、設備保全DXは成果につながりません。

データ量が多くても、
判断の粒度や前提がバラバラであれば、
結局は「その場の判断」や「経験」に頼る運用に戻ってしまいます。

MECHPHAISTOSでは、まず次の4つのデータ構造を最低限の型として揃えることを重視します。

• 設備階層
  工場 → ライン → 重要機器（炉・プレスマシン・反応機など）
  → 機器（ブロワー、ポンプ、モーターなど）
  → 部品（ベアリング、オイルシールなど）

• 停止・故障コード
  停止や故障の原因を分類し、
  再発か偶発か、受け入れるべきか対策すべきかを判断できるようにする

• 作業コード
  点検・修理・交換といった作業区分を固定し、
  保全活動の偏りや変化を比較できるようにする

• 部品マスタ
  型番、互換可否、在庫、調達先、納期を統一し、
  修繕判断に調達リスクを組み込めるようにする

ここで重要なのは、
最初からすべてを完璧に揃えようとしないことです。

判断の中心は「ライン」や「重要機器」単位に置き、
必要な場面で機器・部品レベルまで掘り下げる。
このくらいの粒度が、現場運用としては最も現実的です。

このようなデータの型が揃うことで、

• MTBF・MTTRといった指標だけでなく
• どの停止要因が、どれだけの修繕コストを生んでいるのか
• 過剰保全と突発停止のどちらにコストが寄っているのか

といった、停止要因とコストの関係まで一貫して追跡できるようになります。

データ設計の目的は、分析のためではなく、
判断をブレさせないための共通土台を作ることです。

---

5. MECHPHAISTOSの導入は「3つの台帳」から始まる

MECHPHAISTOSの導入は、複雑な設定や高度な分析から始める必要はありません。
最初に整えるべきものは、たった3つの台帳だけです。

この3つが揃えば、あとは日常業務を回すだけで、
保全DXに必要なデータは自然に蓄積・可視化されていきます。

3つの中核台帳

1. Critical Equipment List（重要機器リスト）

最初に作るのは、すべての設備一覧ではなく、
**「判断が難しく、失敗したときのインパクトが大きい機器」**のリストです。

• 生産停止の影響が大きい設備
• 故障時の復旧に時間がかかる設備
• 修繕費・外注費が高額になりやすい設備

MECHPHAISTOSでは、このCritical Equipment Listを起点に、
保全判断・コスト管理・予測のスコープを定めます。

2. Task List（タスクリスト）

次に整えるのが、保全メンテナンスのタスクを定義するTask Listです。

• 定期点検
• 定期交換
• 条件付き対応
• 応急対応

ここで重要なのは、
「完璧な計画」を作ることではなく、
何を“通常業務”として扱うのかを明確にすることです。

このTask Listが、日々の保全判断の基準になります。

3. Spare Parts List（スペアパーツリスト）

3つ目が、**Spare Parts List（予備品・消耗品リスト）**です。

• 型番
• 互換可否
• 納期
• 保管場所

これを整えることで、
修理判断に「部品がいつ手に入るか」という時間軸を組み込めるようになります。

---

日常業務を回すだけで、データは自然に溜まる

3つの台帳を整えた後は、特別な入力作業は必要ありません。

• 日々の点検・作業を Daily Report として記録する
• 製造現場からの修理依頼を Work Order として処理する

これだけで、

• どの設備で
• どの作業が増えているのか
• どの部品が消費されているのか

といった情報が、自然にデータとして蓄積されていきます。

---

アウトプットとして見えてくるもの

日常業務を回していくことで、MECHPHAISTOSは次のようなアウトプットを提示します。

• 設備ごとの故障発生確率
• 修繕費の推移と将来の費用発生タイミング
• 部品の消費傾向と発注アラート
• 過剰保全と突発停止リスクのバランス

これらは、分析のための数字ではなく、
保全・製造・経営が同じ画面で判断するための材料です。

---

判断を支えるための可視化ツール群

MECHPHAISTOSでは、これらのデータを活用するために、
次のようなツールを提供します。

• 看板ツール：現場で一目で分かる設備状態の可視化
• ガントチャート機能：保全計画と生産計画の調整
• Daedalus（サイトレイアウトマップ）：設備配置と影響範囲の把握
• 棚管理ツール：スペアパーツの保管場所を直感的に把握
• データストレージ：図面・履歴・報告書を蓄積する書庫型管理
• AIチャット：過去データを横断した問い合わせと意思決定支援

---

Agora：メーカー・商社とつながる需要共有

さらにMECHPHAISTOSでは、
Agoraと呼ばれるメーカー・商社との需要共有機能を提供します。

• 故障傾向や交換タイミングの共有
• 需要の兆しを前倒しで共有し、調達判断の余地を広げる
• 代替品・改善品の提案

これにより、
自社だけで閉じた保全から、
サプライチェーン全体で支える保全へと進化します。

---

MECHPHAISTOSの導入は、
「システムを使いこなすこと」ではありません。

3つの台帳を整え、日常業務を回す。
それだけで、判断に必要なデータが自然に集まり、
設備保全DXが現場に根付いていきます。

---

6. MECHPHAISTOSにおけるメンテナンス保全AIの代表ユースケース

多くの保全AIは、
「異常を検知する」「寿命を予測する」といった機能単位で語られがちです。
しかし現場で本当に求められているのは、
“なぜその故障が起きたのか”を説明し、次にどう判断すべきかを示すことです。

MECHPHAISTOSのメンテナンス保全AIは、
単なる予測ではなく、問題解決の思考プロセスそのものを支援します。

過去のイベントとトリガーから「なぜ壊れたか」を導く

設備の故障は、単一の原因で起こることはほとんどありません。

• 直前に行われた作業
• 過去の類似トラブル
• 使用条件や運転の変化
• 部品交換の履歴
• 生産計画上の無理な運転

MECHPHAISTOSでは、
これらの過去イベントと、
故障直前に発生した**トリガー（兆候・変化）**を整理し、

• どの要因が重なったのか
• どこが本質的な問題だったのか
• 再発を防ぐには、どこに手を打つべきか

を論理的に分解して提示します。

「異常を検知する」のではなく「異常に至る流れ」を可視化

例えば、

• 点検頻度が徐々に増えていた
• 応急対応が続いていた
• 特定部品の交換間隔が短縮していた
• 生産条件が厳しくなっていた

こうした変化は単体では見逃されがちですが、
連続した流れとして見ることで、故障に至るシナリオが見えてきます。

MECHPHAISTOSのAIは、
「ここで異常が出た」ではなく、
**「ここから壊れる方向に進み始めていた」**という文脈で示します。

解決策まで含めて提示する保全AI

問題を分解したあと、
MECHPHAISTOSは次のような解決の選択肢を提示します。

• 点検項目や頻度を見直す
• 交換対象を部品単位からユニット単位に変更する
• 生産条件を一時的に緩和する
• 代替部品や設計変更を検討する
• 保全計画そのものを見直す

重要なのは、「正解を一つ出す」ことではありません。
コスト・リスク・生産の優先順位に応じて、
合意可能な判断として落とし込める状態を作ります。

---

7. 修繕費・ブレイクダウン・安全リスクのトレードオフ最適化

保全の目的は「壊さないこと」ではありません。
壊さないために、どこまでコストをかけるかが本質です。

• 過剰保全：修繕費・工数が膨らみ、現場負荷とコストが増大する
• 過小保全：突発停止による生産ロスが増え、安全リスクが顕在化する

MECHPHAISTOSは、このトレードオフを設備ごとに可視化し、
最適な整備ストラテジーを継続的に更新します。

---

8. ニアミス（ヒヤリハット）を起点にした安全データの活用

重大事故は、突然起こるわけではありません。
その多くは、事前に**数多くのニアミス（ヒヤリハット）**を伴っています。

MECHPHAISTOSは、工場内で発生するニアミスを
保全メンテナンスのデータとして集計・管理・分析します。

ニアミスを「個人の報告」で終わらせない

MECHPHAISTOSでは、

• どの設備・機器で
• どのような作業中に
• どのような危険が発生しかけたのか

を構造化データとして蓄積し、
事故に至る前の兆候として扱います。

コモンデータとしての安全情報の価値

ニアミスや事故の情報を
匿名化・構造化したコモンデータとして扱うことで、

• 自社工場の安全レベルを、他工場・他地域・全体トレンドと比較できる
• 「この設備・この作業で事故が起きやすい」という事前知識を持って判断できる

といった、安全管理が可能になります。

なぜ保全メンテナンスが担うのか

安全データの中心に保全メンテナンスが立つ理由は明確です。

• 設備に最も近い業務であること
• 非定常作業・危険作業が集中すること
• 事故が起きた場合の影響を最も理解していること

つまり、
最も重要で、最も危険な業務が集まるのが保全メンテナンスだからです。

---

9. Agoraによる商社・メーカーとの需要共有

設備保全DXが工場内で完結している限り、
調達や納期の問題は「最後の詰まり」として残り続けます。

MECHPHAISTOSでは、このボトルネックを解消するために、
Agoraと呼ばれるメーカー・商社との需要共有の仕組みを組み込みます。

• 故障予測や交換タイミングの見込みを共有し、調達判断の余地を広げる
• 代替品・改善品の検討時間を確保し、欠品や緊急手配を減らす
• 故障傾向や使用条件の共有により、より適切な手配・提案につなげる

結果として、保全・調達・経営が同じ時間軸・同じ前提で動くようになり、
設備保全DXは工場の外へと拡張されていきます。

---

10. MECHPHAISTOSが目指す全体像

MECHPHAISTOSが目指すのは、
「センサーで状態を監視すること」そのものでも、
「記録をデジタル化すること」そのものでもありません。

目指すのは、工場メンテナンスにおける意思決定を、
現場の経験だけに依存しない形で“再現可能”にし、全社で共有できる状態です。

その中核になるのが、次の循環です。

1. 3つの台帳（Critical Equipment / Task / Spare Parts）で判断の土台を作る
2. Daily Report と Work Order で日常業務を回し、データを自然に蓄積する
3. 故障確率・修繕費推移・費用発生タイミング・発注アラートとしてアウトプットする
4. 看板・ガント・Daedalus・棚管理・ストレージ・AIチャットで意思決定に落とし込む
5. Agoraでサプライチェーンとつながり、調達まで含めて“時間軸”をそろえる

この循環が回り始めると、工場は次の状態に近づきます。

• 保全は「やる／やらない」の判断を、根拠を持って説明できる
• 製造は、生産計画と保全計画を同じ画面で合意できる
• 経営は、コストだけでなく安全と停止リスクを含めて判断できる
• 調達は、「壊れてから」ではなく「起きる前に」準備できる

MECHPHAISTOSは、
工場内に点在していた情報を「共通データ」に変え、
安全・生産・コストのトレードオフを、継続的に最適化するプラットフォームを目指します。

---

11. 90日で進める最小構成プラン

短期で運用を立ち上げるための、現実的な進め方です。

1. 0〜30日：3つの台帳を作る

   • Critical Equipment List / Task List / Spare Parts List を最低限埋める
   • 入力ルール（誰が・いつ・どこまで）を決める

2. 31〜60日：日常運用を回して“自然に溜まる状態”を作る

   • Daily Report と Work Order を現場に定着させる
   • 停止要因・作業区分・部品消費がブレなく記録される状態にする

3. 61〜90日：アウトプットを意思決定に使い始める

   • 故障確率／修繕費推移／費用タイミング／発注アラートを判断に取り込む
   • 看板・ガント・Daedalus等のツールで会話と合意を加速する

---

まとめ

センサーに頼らない設備保全DXでは、
「計測できるか」よりも、
計画・重要度・データの揃え方・意思決定の仕組みが成否を決めます。

MECHPHAISTOSは、
3つの台帳と日常運用を起点に、
故障予測・修繕費最適化・安全データ・調達連携までを一つの流れとしてつなぎ、
工場メンテナンスの意思決定を“再現可能”にしていきます。