あなたのCMMSはフリート全体の平均故障間隔（MTBF）を1つの数値で表示する。その数値は妥当に見えるかもしれない——上昇傾向にすら見えることもある。しかし、1つの集計値では、なぜ夜間チームが昼間チームの2倍の速さで油圧系統を消耗させるのかを教えてくれない。その差こそが、回避可能なダウンタイムが蓄積される場所だ。
TL;DR
- 📐 MTBFは総稼働時間を計画外故障件数で割った値。修理可能な資産にのみ適用される。
- 📊 フリート全体の1つの数値では、どの資産、シフト、オペレーターが信頼性を低下させているかが見えない。
- 🔧 現場故障の50〜90%は記録されず、MTBFの数値を実際より高く見せている。
- ⚙️ 資産クラス、シフト、ルート、オペレーター別にMTBFをセグメント化することで、改善が実行可能になる。
- 🚀 各セグメント分析は4〜12週間のITプロジェクト。Agent Builderなら同じレポートを48時間で納品する。
- ✅ MTBFが運用ツールとなるのは、閾値超過が自動メンテナンスワークフローをトリガーするときのみだ。
平均故障間隔とは何か？
平均故障間隔（MTBF）は、修理可能な資産における計画外故障間の平均稼働時間を測定する指標だ。単位は時間で表され、ベンダーの仕様ではなく、自社の運用故障履歴から算出される。
わかりやすい定義
MTBFが答える問いは1つ：修理可能な資産が計画外故障でオフラインになるまで、どれだけ稼働し続けるか？
計算式：
MTBF ＝ 総稼働時間 ÷ 計画外故障件数
MTBFが500時間であれば、その資産は平均して500稼働時間ごとに予期せず故障することを意味する。次の故障が正確に501時間目に発生すると予測するものではない。
正確なMTBFは完全な設備ダウンタイム追跡に全面的に依存している。すべての計画外故障は、シフト終了時や月曜の朝ではなく、発生した瞬間に記録されなければならない。
MTBFが実際に測定するもの
MTBFが計上するのは計画外・予期せぬ故障のみだ。計画済みの予防保全による停止はMTBFを下げない。計画された点検のために停止させた機械は故障イベントではない。
MTBFは修理可能なシステムにのみ適用される。修理不能な部品には代わりに平均故障時間（MTTF）を使用する。交換・廃棄されるベアリングにはMTBFではなくMTTFを用いる。MTBFは修理後に稼働復帰する資産を対象とする。
より深い運用上の制約：MTBFは故障がどのくらいの頻度で発生するかを教えてくれる。しかし、なぜ起きるのか、どのシフトで、どのオペレーターが、どの資産クラスでかは教えてくれない。本記事が埋めるのはそのギャップだ。
MTBFの計算方法
計算式に必要な入力は3つ：総稼働時間、計画外故障件数、一貫した測定期間。正確なデータを揃えることは、計算そのものよりはるかに重要だ。
ステップ別の計算式
MTBF ＝ 総稼働時間 ÷ 計画外故障件数
5つのステップで計算する：
- 資産のスコープを定義する：単体、資産クラス、またはフリート全体。
- 測定期間を設定する：月次、四半期、または年次。
- その期間内の対象資産の総稼働時間を合計する。
- その期間内に記録されたすべての計画外故障を数える。
- 総稼働時間を故障件数で割る。
自動計算されるメンテナンス指標はスプレッドシートの手順を完全に排除する。稼働時間と故障イベントがイベントエンジンから直接記録されれば、MTBFはリアルタイムで算出される。毎月の手動計算は不要になる。
実例：ストラドルキャリアフリート
10台のストラドルキャリアがそれぞれ12ヶ月間で4,200稼働時間を記録：合計42,000時間。同期間にCMMSは84件の計画外故障を記録した。
MTBF ＝ 42,000 ÷ 84 ＝ 500時間（フリート全体）
シフト別にセグメント化すると、夜間シフトのMTBF：320時間。昼間シフトのMTBF：680時間。
500時間というフリート平均は数学的には正しい。しかし運用上は無意味だ。360時間というシフト間の差こそが是正措置を導く発見であり、1つの集計値ではそれは生まれない。
これがフリートの単一数値サマリーが運用上弱い理由だ。セグメント化こそがMTBFをメンテナンスレビューで機能させる場所だ。
ベンダーのMTBF仕様が信頼できない理由
メーカーのMTBF仕様は管理された実験室環境から生まれる。理想的な温度、標準的な稼働サイクル、熟練オペレーターを前提としている。あなたの24時間港湾サイクルや沿岸の湿度は、そのテスト環境には含まれていない。
常に自社の運用データから計算すること。実際のメンテナンス決定を導くフリート管理KPIは、ベンダーの仕様書ではなく社内のトレンドから生まれる。
重工業における業界別MTBFベンチマーク
ベンチマークは資産タイプ、稼働サイクル、経年、環境、メンテナンス成熟度によって大きく異なる。外部ベンチマークは方向性の参考としてのみ使用すること。長期的な社内トレンドが主要な運用シグナルだ。
| 出典 | 主な知見 |
|---|---|
| Fiix | MTBFは計画外故障のみを計上する。計画済みPM停止は計算から除外される |
| IBM | MTBFは故障の深刻度や運用への影響を捉えない。「良いMTBF」は文脈によって異なる |
| eMaint | 機械の経年劣化は予測可能な形でMTBFを低下させる。トレンド分析による早期発見が重要だ |
| Splunk | シックスナインの稼働率目標では年間31.56秒のダウンタイムしか許容されない。MTBFとMTTRは厳密に管理されなければならない |
製造設備
個別生産・プロセス製造において、高稼働サイクルの設備のMTBFは300〜1,200時間の範囲に及ぶ。メンテナンス成熟度と資産の経年が主要な変数だ。
老朽化した設備における年間MTBF劣化率15〜30%は一般的かつ予測可能だ。継続的なトレンド分析による早期発見は、故障時の事後対応よりはるかにコストが低い。
製造業で広く使用されているMTBF追跡用CMMSツールには、IBM Maximo、SAP EAM、Limble、MaintainX、eMaintがある。いずれもデフォルトではフリート全体の単一数値を表示する。シフトまたはオペレーター別のセグメント化はすべての場合でカスタム開発が必要だ。
採掘・採石業
ダンプトラック、掘削機、粉砕設備は重工業で最も過酷な稼働サイクルで動作する。粉塵、振動、極端な温度は実験室条件の想定を超えて故障率を加速させる。
信頼性に関する採掘業界のKPIは常に設備クラス、鉱山サイト、シフト別にセグメント化すべきだ。露天掘り操業のダンプトラックにおいて、MTBFが200時間を下回ることは単なるメンテナンスアラートではなく、設備投資計画のシグナルだ。
CMMSに届かない無線報告の故障は、遠隔地の鉱山サイトで持続的なダークデータ問題を生み出す。水増しされたMTBFの数値は、実際の故障が到来するまで本物の信頼性低下を隠し続ける。
港湾・コンテナターミナル
ストラドルキャリア、リーチスタッカー、岸壁クレーンは高湿度の沿岸環境で24時間365日稼働する。この資産クラスのMTBFは通常300〜700時間の範囲だ。フリートの経年とPM成熟度が主要な変数となる。
100台超のストラドルキャリアを擁する大手コンテナターミナルには12ヶ月のITバックログがあった。そのバックログにはシフトと資産クラス別にMTBFをセグメント化するために必要なカスタムレポートが含まれていた。データレイヤーが整備されると、ターミナルは信頼性が15%向上し、ストラドル1台あたり約15時間のMTBF追加も達成した。
航空地上支援設備
手荷物トラクターとプッシュバックタグは短い時間枠の中で稼働する。ピーク時とオフピーク時の稼働サイクル変動は激しい。航空GSEのMTBFベンチマークは400〜800時間の範囲だ。
迅速なゲートターンアラウンド中に記録されない故障は頻繁なダークデータの発生源だ。無線で報告されシステムに入力されないイベントはMTBFを人為的に高める。そのような数値に基づくメンテナンス計画は信頼性に欠ける。
石油・ガス田設備
ポンプ、コンプレッサー、坑口設備は上流操業において腐食性環境と高圧稼働サイクルに直面する。石油・ガス分野の現場データ精度は既知の課題だ。MTBF追跡には故障記録と並んで環境的コンテキストが必要だ。
温度、圧力、流量、流体の化学的性質はすべて故障率に影響する。遠隔地でCMMSに届かない無線報告の故障は、大きなMTBFの歪みを生み出す。
なぜほとんどのMTBF数値は誤っているのか？
CMMSが生成するMTBFの数値のほとんどは、不完全なデータに基づく正確な計算だ。計算式が問題なのではない。それに供給するデータパイプラインが問題だ。
フリート全体のMTBFはなぜ分散を隠すのか？
フリート全体の単一数値は、高パフォーマンスの資産と慢性的に故障する資産を組み合わせ、平均値は許容範囲に見える。どちらの資産も的確な注目を受けない。
集計は実際の問題が存在する分散を隠す。平均500時間MTBFのフリートに、200時間で稼働している1台と900時間の別の1台が含まれている可能性がある。平均値はどちらについても有用な情報を伝えない。行動する価値のある発見を浮かび上がらせるのはセグメント化だけだ。
ダークデータはどのようにMTBFを歪めるのか？
現場操業で起きることの50〜90%はシステムに届かない。無線やWhatsAppで報告され正式に記録されない故障はMTBFの計算に現れない。これによりMTBFの数値は人為的に高くなる。
故障まで稼働させるコストは、電話報告され、その場で修理され、記録されないイベントから最も速く蓄積される。このパターンはターミナル操業、採掘、フィールドサービス環境に見られる。記録されないイベントはMTBFの数値を膨らませる。
MTBFはなぜ故障原因を説明しないのか？
MTBFは故障がどのくらいの頻度で発生するかを伝える。なぜ起きるかは伝えない。各イベントに故障根本原因のタグ付けがなければ、低下するMTBFトレンドはただの右肩下がりの線に過ぎない。具体的な是正措置を導くことはできない。
フリート故障パターンの研究によると、同一設備でもオペレーターのコホート間で故障率が18%以上変動することがある。根本原因のタグ付けがなければ、その分散は集計数値の中に見えないまま留まる。主要な故障カテゴリには油圧、電気、オペレーターエラー、摩耗が含まれる。
計画保全はどのようにMTBFを歪めるのか？
MTBFで評価されるチームは境界線上のイベントを一貫性なく記録することがある。計画された早期引き上げの予防停止が故障として記録される。アイドル時間中の非公式な修理はまったく記録されない。
どちらも意図的ではない。チームが標準化された故障定義を持たない場合、両方とも予測可能だ。トレンド分析を始める前にメンテナンスリーダーと定義に合意し、文書化すること。すべてのシフトで一貫して適用すること。
MTBF vs MTTR vs MTTF
重工業の運用計画では3つの信頼性指標が頻繁に共に登場する。それぞれが信頼性の異なる次元を測定する。3つすべてを使用することでメンテナンス決定の完全な全体像が得られる。
MTBF（平均故障間隔）：修理可能な資産における計画外故障間の平均稼働時間。信頼性トレンド分析、PM計画、閾値設定に使用する。
MTTR（平均修復時間）：故障後に資産を復旧させるまでの平均時間。修理効率の追跡とクルーの能力計画に使用する。
MTTF（平均故障時間）：修理不能な部品を交換しなければならないまでの平均耐用年数。設備投資計画と予備部品の予測に使用する。
可用性の関係式が3つをすべて結びつける：
資産可用性 ＝ MTBF ÷ （MTBF ＋ MTTR）
設備稼働時間指標はこの計算式の直接的な関数だ。MTBFが10%向上しMTTRが15%短縮されれば、月あたりの生産的稼働時間に意味のある増加をもたらす。高稼働サイクルのフリートにとって両方のレバーが重要だ。
プラントマネージャーにとって、OEEとTEEPはMTBFとMTTRと並んで設備効率の全体像を完成させる。OEEとTEEPは計画時間対総暦時間を4番目の信頼性次元として加える。
MTBFが高くMTTRも高い場合は信頼性の高い設備だが修理プロセスが遅いことを示す。MTBFが低くMTTRが非常に低い場合は設計上またはオペレーターの根本的な問題を隠している可能性がある。3つすべてを一緒に追跡すること。1つだけを単独で最適化しないこと。
重工業においてMTBFをどのように改善するか？
MTBFの改善はシーケンスに従う。データ基盤は分析レイヤーより先に来なければならない。分析は閾値自動化より先に来なければならない。自動化は根本原因のタグ付けにフィードバックされなければならない。ステップを飛ばすと改善が止まる。
ステップ1：まずデータフィードを修正する
すべての故障を捕捉しなければ、どんなMTBF改善プログラムも機能しない。記録されない無線連絡、WhatsAppメッセージ、口頭での引き継ぎはMTBFを虚構にする。
すべての故障は発生時にメンテナンスデータバックボーンに構造化された記録が必要だ。IBM Maximo、SAP EAM、Limble、MaintainX、eMaintのいずれを運用していても、完全な捕捉は交渉の余地がない。分析レイヤーはそれに供給するデータと同じ品質にしかなれない。
ステップ2：最適化する前にセグメント化する
1つの資産クラスにおけるシフト間の40%のMTBFギャップは実行可能な発見だ。セグメント化がなければ、明確なターゲットのないトレンドだけが残る。
まず資産クラス別にセグメント化し、次にシフト別。次にオペレーターコホート別。次にルートまたはサイトゾーン別。各分割が問題を特定の是正措置に絞り込む。
事後保全から予知保全への移行にはこのセグメント化レイヤーが必要だ。四半期ごとに15%低下傾向にある資産クラスには加速されたPMレビューが必要だ。フリート全体のPM延長はシフトレベルの問題への誤った対応だ。
ステップ3：閾値を設定しワークフローをトリガーする
資産クラスごとに最低許容MTBFを定義する。MTBFが閾値を下回ったら、自動的に行動する。
点検タスクを生成し、PMスケジュールを前倒しにする。メンテナンスリーダーにアラートを送り、次のシフトにブリーフィングする。
ここでMTBFは報告指標から運用ツールへと変わる。AIがトリガーするメンテナンスタスクは閾値トリガーの対応を自動化する。メンテナンスリーダーがダッシュボードを監視するのではなく、ワークフローが監視して行動する。
故障が起きる前に防ぐことが、重工業の現場操業においてMTBFを延ばす最も効果的なレバーだ。メーターベースのトリガーと繰り返し故障検知がメンテナンスを故障イベントの上流に移動させる。
ステップ4：根本原因ループを閉じる
閾値とトリガーされたワークフローは改善の可能性を生み出す。根本的な原因を特定して修正しなければならない。そうしなければ、同じ資産クラスが次のサイクルで同じ閾値を再び超えることになる。
すべての故障を根本原因でタグ付けする：油圧、電気、オペレーターエラー、摩耗、環境要因。タグの分布を毎月監査する。1つのカテゴリが急増したら、それが調査ターゲットだ。このループなしには、MTBFの改善は根本的な修正ではなく応急処置のサイクルになる。
MTBFを運用ツールに変える
ほとんどの運用リーダーはCMMSから1つのMTBF数値を持っている。17のMTBFセグメント分析はITバックログに滞留している。各スライスは個別の開発リクエストだ。メンテナンスプログラムが不十分なデータで稼働している間もバックログは増え続ける。
MTBFのインサイトはなぜ17のレポートを必要とするのか？
MTBFの各セグメント分析は独立したITプロジェクトだ。典型的な産業ITキューでは、それぞれ4〜12週間かかる。17の分析は最大3年間の待ちに等しい。これはデータの問題ではない。ITバックログの問題だ。
運用とITのためのエージェンティックAIこそがOpsima Agent Builderが提供するものだ。運用リーダーはMTBFレポートまたはワークフローを平易な言葉で説明する。Agent Builderがステージング環境でビルドし、ITがレビューして承認する。12ヶ月ではなく48時間で出荷される。
Agent BuilderはMTBFのために何をビルドするか？
Agent Builderはデータバックボーンの上にある分析・ワークフローレイヤーだ。すべての故障が捕捉されたデータバックボーンは引き続き必要だ。それはEquipmentOS、またはすでに運用しているCMMSを意味する。Agent Builder自体は故障イベントを捕捉しない。
MTBFのための4つの具体的なビルド：
- セグメント化されたMTBFダッシュボード。MTBFを資産クラス、シフト、オペレーター、ルート、天候、または時間帯別にスライスする。各スライスは四半期ではなく数日でビルドされる。
- 閾値トリガー型ワークフロー。資産クラスのMTBFが閾値を下回ると、Agent Builderが自動的に行動する。点検タスク、PM前倒し、メンテナンスリーダーへのアラート、次シフトへのブリーフィングをトリガーする。
- 根本原因分類エージェント。Agent Builderは運用チャンネルを監視し故障を原因別にタグ付けするエージェントを設定する。関連する原因には油圧、電気、オペレーターエラー、摩耗が含まれる。構造化された根本原因データがMTBFセグメント化にフィードバックされる。
- 毎週の「何が変わったか」ブリーフ。フリートMTBFが週次で低下すると、Agent Builderエージェントがサマリーブリーフをまとめる。シフトハドルのための寄与故障、根本原因タグ、運用コンテキストをカバーする。
12ヶ月のキューから48時間デプロイへ
100台超のストラドルキャリアを擁する大手コンテナターミナルには12ヶ月のITバックログがあった。そのバックログには、チームがシフトと資産クラス別にMTBFをセグメント化するために必要なカスタムメンテナンスレポートが含まれていた。
データは利用可能だった。セグメント化は利用できなかった。なぜならすべてのレポートがキューに入ったITプロジェクトだったからだ。そのバックログこそAgent Builderが崩壊させるものだ。
データレイヤーが整備されると、ターミナルは信頼性が15%向上した。ストラドル1台あたり約15時間のMTBF追加も達成した。ボトルネックはデータではなかった。どのMTBF分析が必要かを知ることと、それを本番稼働させることの間のキューだった。
あなたのMTBF数値は1つのレポートだ。運用には17が必要だ。
Agent Builderはカスタムのセグメント化されたMTBF、閾値、トリガー型ワークフローを12ヶ月ではなく48時間で出荷する。ITはステージングと承認を通じて完全なコントロールを維持する。
度数率（LTIFR）とともにMTBFを追跡する運用リーダーは、設備の信頼性と安全性が連動して動くことを知っている。重工業における高い計画外故障率は高まるインシデントリスクと相関する。両方の指標は同じ運用レビューに属する。
1つのMTBF数値からAgent Builderを通じたセグメント化・閾値トリガー型ワークフローへ移行するには、15分のディスカバリーコールをご予約ください。
