平均修復時間（MTTR）：2026年に実践的な指標にする方法

CMMSは平均修復時間45分と表示している。技術者は障害対応に4時間かかったと知っている。どちらの数値も正しい。それぞれ異なるものを測定しており、そのギャップこそがほとんどのMTTR改善プログラムが失敗する原因だ。

TL;DR

• 🔧 MTTRは同一期間の総是正保全時間を修理件数で割った値に等しい。
• 📉 ほとんどのCMMSシステムは修復フェーズのみを記録し、検知と診断は完全に見えないままだ。
• ⚙️ MTBFが低下しながらMTTRも低下している場合は、成功ではなく警告サインだ。
• 📊 世界クラスの産業用MTTRは2時間未満で、8時間超は不良とみなされる。
• ✅ MTTRを最も効果的に改善するのは、作業時間の削減ではなく、検知と診断を体系化することだ。
• 🗓️ まず最も重要度の高い10資産から始め、自動化を導入する前に4つのフェーズすべてを記録する。

MTTRは実際に何を測定するのか？

平均修復時間は、故障した資産をサービスに復旧させるまでにかかる時間を測定する。これはポート、鉱業、製造、フリート運営における主要な保全パフォーマンス指標だ。資産信頼性の全体像を把握するために、MTBFとMTTRの連携方法と直接対応している。

計算式を見る前に、頭字語の混乱を解消しておく価値がある。MTTRは分野によって4つの異なる意味を持つ。

MTTRの4つのバリアント

頭字語	正式名称	分野	測定対象
MTTR	Mean Time to Repair	産業・保全	故障した資産を物理的に修復する時間
MTTR	Mean Time to Recovery	IT・SRE	システムが障害から回復する時間
MTTR	Mean Time to Respond	IT・通信	アラートから技術者が対応するまでの時間
MTTR	Mean Time to Resolve	ITサービス管理	チケット開設からクローズまでの時間

産業運営においては、Mean Time to Repairが正しい定義だ。本記事では全体を通じてその定義を使用する。

なぜ産業運営にMean Time to Repairを使用するのか？

Mean Time to Repairは、保全チームが故障した資産を復旧させるまでの時間を測定する。計画外ダウンタイムのコストとフリートアベイラビリティに直接関連している。現場主導の産業におけるオペレーショナルエクセレンスは、一貫性のある合意された定義に基づいてこの数値を追跡することにかかっている。

MTTRはどう計算するのか？

MTTRの計算式はシンプルだ。分子に何を含めるかによって、報告される結果が大きく変わる可能性がある。

MTTR = 総是正保全時間 / 同一期間の修理件数

MTTRの計算式

分子に含めるもの：故障確認から資産がサービスに復旧するまでのすべての時間。これには技術者の待機時間、部品の待機時間、診断時間、作業時間、確認作業が含まれる。

計画PMは除外する。定期保全は別カテゴリだ。これを是正MTTRに含めると数値が膨らみ、真の修復チームのパフォーマンスが不明瞭になる。

計算例：ストラドルキャリア

あるコンテナターミナルが1週間で5件のストラドルキャリア故障を記録した：

作業指示	総修復時間
WO-1101	3.5時間
WO-1102	2.0時間
WO-1103	6.5時間
WO-1104	1.5時間
WO-1105	4.0時間

総是正保全時間：17.5時間、修理件数：5件。

MTTR = 17.5 / 5 = 3.5時間

チームがすべてのフェーズを含めていれば、この数値は妥当だ。WO-1103には油圧シールの部品待ちが90分あった。その待機時間を除外すると、報告されるMTTRは3.0時間に下がる。同じ運営、同じ週、異なる数値だ。

同じデータが異なる数値を生み出す仕組み

同一の運営を行う2つのサイトが、実質的に異なるMTTR数値を報告する場合がある。原因はほぼ常に定義にある。部品待ち時間を除外したり、作業時間のみを記録したりするチームは、正確に測定しているチームより常に速く見える。サイトレベルのベンチマーキングでは、数値を比較する前に共通の定義が必要だ。

すべてのMTTR内の4つの実際のフェーズ

ほとんどのMTTR改善プログラムは作業時間を対象にしている。なぜなら、それが作業指示に確実に記録される唯一のフェーズだからだ。ほとんどの運営において、これは最適化すべき間違ったフェーズだ。

すべての修復イベントには4つの明確なフェーズがある。ほとんどのCMMSシステムはそのうち1つのみを確実に記録する。

4つのフェーズ：検知、診断、修復、確認

検知：故障発生から最初の人が認識するまでの時間。これは無線通話、WhatsAppメッセージ、またはオペレーターがヤードで資産がアイドル状態になっているのに気づいたときに発生する。

診断：認識から根本原因を特定するまでの時間。技術者が到着し、資産を点検し、ランブックを確認し、シフトスーパーバイザーに相談する。根本原因分析にはこのデータを記録・構造化する必要がある。正しい修復アプローチが確認された時点でフェーズが終了する。

修復：作業時間。技術者が診断を確認し、修復を実行している時間。

確認：試験運転、サインオフ、サービス復旧の確認。

コンピュータ化保全管理システムは修復のタイムスタンプを記録し、確認も記録することがある。検知と診断は作業指示にほとんど記録されない。

油圧故障のケーススタディ

06:30にリーチスタッカーで油圧故障が発生した。オペレーターが無線で報告したが、シフト引き継ぎ中にメッセージが聞き逃された。2人目のオペレーターが08:45に資産のダウンを報告した。技術者が09:15に診断を開始し、10:45にシールの破裂を特定した。修復には45分かかった。資産は11:35にサービスに復旧した。

報告されたMTTR（作業時間のみ）：45分

真のMTTR（故障からサービス復旧まで）：5時間5分

「45分MTTR」目標を追いかけているチームは、実際の数値の約9分の1を最適化していることになる。2時間の未検知故障と90分の診断は完全にシステム外にある。

なぜCMMSは一部しか記録しないのか？

検知と診断は会話の中に存在する。無線通話、WhatsAppスレッド、技術者とシフトスーパーバイザー間の通話がそれだ。ほとんどの作業指示は技術者が現場に到着した後にのみ作成される。それ以前のすべてはダークデータであり、情報は存在している。ただ、システムには届かない。

業界別MTTRベンチマーク

ベンチマーク範囲は設備タイプ、資産の重要度、各組織のMTTR定義によって大きく異なる。これらは方向性の参照点として使用し、パフォーマンスの命令としては使用しないこと。

ベンチマーク比較が意味を持つ前に、一貫した設備ダウンタイムトラッキングが基盤となる。

セクター別ベンチマーク範囲

業界	典型的なMTTR範囲	備考
製造業（一般）	2〜8時間	ライン重要度によって大きく異なる
石油・ガス（陸上）	4〜24時間	部品の入手可能性が主な要因
鉱業	8〜48時間	遠隔地が部品リードタイムを延長
運輸・物流	2〜8時間	フリートタイプとルートの緊急性が範囲に影響
港湾・ターミナル	2〜8時間	設備クラス（クレーン対ストラドルキャリア）が重要

世界クラス：2時間未満、良好：2〜4時間。平均：4〜8時間、不良：8時間超。

なぜこれらのベンチマークはノイズが多いのか？

部品待ち時間をMTTRから除外するサイトは、含めているサイトより常に速く見える。自社のMTTRを業界ベンチマークと比較する前に、同じ定義を共有しているか確認すること。資産クラスを正規化せずにサイトレベルで比較しても、洞察ではなくノイズしか生み出さない。

あるターミナルでの世界クラスのMTTRが、最初のチームがすべての部品待ち時間を除外している場合、別のターミナルでは平均的に見える可能性がある。定義を文書化し、すべてのサイト、すべてのシフト、すべての設備クラスで一貫して適用する。それができて初めて、サイト間の比較に意味が生まれる。

低いMTTRが警告サインとなる場合

低下するMTTRは通常良いニュースであり、常にそうとは限らない。その違いを知ることで、有用な保全指標と虚栄の数値を区別できる。

表面的な修復トラップとは何か？

30分のMTTRは、高度な技術者が根本原因を迅速に解決していることを意味する場合がある。また、5日後に再び故障する応急処置を意味する場合もある。後者のシナリオは、予防保全ソフトウェアへのあらゆる投資を無駄にし、継続的な反応的作業指示の流れを生み出す。

「反応的（MTTR）戦略は予防的（予防保全）戦略の5〜10倍のコストがかかる。」

Andrew Lerner、VP・ディスティングイッシュドアナリスト、Gartner（出典）

MTTRが故障手直しの遅行指標になる前に予防保全戦略にシフトすることが正しい順序だ。30分の修復後に5日ごとに故障する資産はMTTRの成功ではない。それはMTBFの失敗だ。

MTBFと並べてMTTRをどう読むべきか？

アベイラビリティ = MTBF / (MTBF + MTTR)。MTBFが低下しながらMTTRも低下しているということは、修復が速くなっていても資産がより頻繁に故障していることを意味する。その組み合わせは技術者のパフォーマンス問題ではなく、保全戦略の問題を示す。OEEとアベイラビリティコンポーネントと並べてMTTRを読むことで、運営全体の状況を把握できる。

MTTRにおけるダークデータ問題とは何か？

CMMSには構造的な盲点がある。最も多くの時間を失うフェーズは、作業指示が開かれる前に発生するフェーズだ。

測定しないものは改善できるか？

検知と診断は、真の経過修復時間の大半を占めることが多い。その時間のすべての分は、技術者とスーパーバイザー間の無線とWhatsAppスレッドに存在する。

測定しないフェーズは改善できない。無線上に存在するフェーズは測定できない。

ほとんどのMTTR改善プログラムは作業時間に焦点を当てる。それがCMMSが報告するものだからだ。結果として、修復イベント全体の最も小さな部分に多大な努力が費やされる。典型的な油圧故障の作業時間は45分だ。4時間以上の経過時間がその前に測定されないまま残る。

MTTRの真のレバレッジはどこにあるか？

フィールドコミュニケーションをタイムスタンプ付きイベントとして記録することが、検知と診断を測定可能にする唯一の方法だ。油圧故障の診断が平均90分かかる場合、ターゲットを絞ったランブックを構築できる。夜間シフトの検知が平均2時間かかる場合、エスカレーションプロトコルを調整できる。

マルチチャンネルステータスキャプチャは、無線通話とWhatsAppスレッドを作業指示に属する保全記録に変換する。データはすでに存在している。ギャップは技術的ではなく構造的だ。

MTTRを実際にどう改善するか？

レバレッジの順に並べる。検知と診断が最初で、作業時間が最後だ。ほとんどの運営では優先順位が逆になっている。

1. まず検知と診断を記録する

無線通話とWhatsAppメッセージをタイムスタンプ付き記録に構造化する。すべての故障通知は、タイムスタンプ、資産ID、報告された症状を持つイベントになる。各通知はエージェントディスパッチワークフローを通じて自動的に作業指示イベントを作成する。技術者が現場に到着する前に作業指示が開かれる。

2. 資産固有のランブックを作成する

重要度の高い各資産には、現場でモバイル端末からアクセスできるランブックが必要だ。ランブックは最も一般的な故障モード、診断手順、必要な部品をカバーする。保全イベントのAI分類は、過去の作業指示パターンからランブックを充填する。繰り返す故障モードが自動的に表面化されるため、現場に到着する技術者は出発点を持つことができる。

3. MTBFパターンを使用して部品を事前配置する

部品待ち時間は、鉱業、遠隔地、専門フリートにおける主要なMTTRドライバーだ。AI搭載の保全優先順位付けデータは、資産がベアリング故障の間に平均300エンジン時間を示す可能性がある。280時間前にベアリングを在庫する。MTBFパターンが入力で、部品配置が出力だ。

4. シフト間の技術者引き継ぎを評価する

シフト境界をまたぐ進行中の修復は、検知と診断に何時間も追加する可能性がある。引き継ぎ技術者はコンテキストなしに到着し、最初から再診断する。シフト交代がMTTRを膨らませる方法は、保全管理において最も軽視されているドライバーの一つだ。資産ID、故障の説明、現在の修復状況を含む引き継ぎノートは、その再診断のコストを完全に除去する。

5. KPIをフェーズレベルの指標に結びつける

フェーズ内訳なしに総MTTRを報告しても、時間が実際にどこに費やされているかが隠れる。フェーズレベルでの自動MTTR・MTBF計算は、保全マネージャーに1つではなく4つの数値を提供する。検知2.3時間、診断1.4時間、修復0.8時間、確認0.3時間という内訳は実行可能だ。単一の4.8時間合計はそうではない。

エンタープライズシステム統合は、フェーズレベルデータを既存のCMMS、SAP、またはMaximoに接続する。システムの置き換えは不要だ。現在システム外に存在するシグナルソースが、すでに持っている保全記録に拡張される。

MTTRは隣接する指標とどう比較されるか？

MTTRは保全KPIのファミリーにおける1つの指標であり、それぞれが異なる質問に答える。誤った決定に対して誤った指標を使用すると、保全チームが誤った方向に向かう。

比較表：MTTR、MTBF、MTBR、MTTF

指標	測定対象	最適な用途
MTTR	故障した資産の復旧時間	保全チームのパフォーマンス
MTBF	故障間の平均時間	資産信頼性の追跡
MTBR	部品交換間の平均時間	消耗品と摩耗部品の計画
MTTF	最初の故障までの時間（修理不可能な資産）	ベアリング、電球、使い捨てコンポーネント
Availability	MTBF / (MTBF + MTTR)	SLAコミットメントとフリート計画
Reliability	一定期間の無故障運転の確率	資産投資決定

修理不可能なコンポーネントにはMTTFを使用する。修理可能な設備にはMTBFを使用する。保全チームのパフォーマンスにはMTTRを使用する。運営上のコミットメントにはアベイラビリティを使用する。

これらの指標間の関係が重要だ。高いMTBFは信頼性の高い資産を示す。低いMTTRは有能な保全チームを示す。高いアベイラビリティは両方が連携して機能していることを意味する。資産信頼性が低下している場合、サイトは優れたMTTRを持ちながらアベイラビリティが低い可能性がある。5つすべてを一緒に追跡することで、完全な保全の状況が得られる。

適切な資産管理ソフトウェアは、CMMSがデフォルトで表示する指標だけでなく、これらすべてを一緒に追跡する。

一般的なMTTR測定ミス

ほとんどのチームは少なくとも2つの方法で同時にMTTRを誤って測定している。これらが最も一般的な5つの歪みだ。

チームがMTTRデータを歪める5つの方法

1. 計画PMを分子に含める。定期保全は修復イベントではない。PMコンプライアンスとして別に追跡する。是正MTTRに混入すると、計画外修復パフォーマンスに関するシグナルなしに数値が膨らむ。

2. 部品待ち時間を除外する。油圧シールを待つことはダウンタイムイベントの一部だ。体系的に除外すると真の修復時間が過小評価され、部品在庫決定が難しくなる。Society for Maintenance and Reliability Professionals (SMRP)の基準は、故障からサービス復旧までのすべてのダウンタイムを含む。

3. 資産クラスを正規化せずにサイト間で比較する。80%が重型クレーンで運営されるターミナルは、軽量フリートで運営されるターミナルより高いMTTRを持つ。正規化なしのサイトレベル比較はノイズを生む。

4. トリアージフィルタリングによるMTTR低下を祝う。保全チームが非クリティカルな修復を後続作業指示に延期することで作業指示を早く閉じると、MTTRは低下する。何も改善されていない。バックログが増えただけだ。

5. フェーズ内訳なしに総MTTRを測定する。フェーズレベルの可視性なしでは、改善イニシアティブが誤った段階を対象にする。フェーズレベルでMTTRを追跡するCMMSは、より高機能なプラットフォームに存在するようになった。自社のものがそれを提供していない場合、レポートレイヤーのアップグレードが必要だ。

30日間の実装ロードマップ

フリート全体から始めない。まず10資産から始め、スケールする前に方法論を検証する。

上位10の重要資産から始める

第1〜2週：運営における最も重要度の高い10資産を特定する。各資産について、4つのMTTRフェーズすべてを手動で計測する。各故障イベントの無線トランスクリプトとWhatsAppログを取り出す。作業指示のタイムスタンプと照合する。検知、診断、修復、確認をカバーする4列のログを作成する。

第3〜4週：フェーズ内訳を確認する。時間は実際にどこに費やされているか？ほとんどの運営では、検知と診断が経過時間の大半を占める。それら10資産のフェーズレベルレポートビューを作成する。

30日間のベースラインデータの後にのみ、優先順位ロジックや予測ツールをその上に重ねるべきだ。最初の目標は可視性であり、自動化でも予測でもない。

30日間の手動演習はCMMSのデータ品質問題も明らかにする。最も近い時間に丸められた作業指示タイムスタンプ、診断ノートの欠如、サービス復旧時間のない修復がすべて再構成中に表面化する。4フェーズの内訳によってこれらのデータギャップが可視化される。

Opsimaはこの状況にどう適合するか？

Opsimaはそれ自体でMTTRを低下させるわけではない。これは直接述べる価値がある。多くのCMMSベンダーはダークデータ問題に対処せずに「MTTRのためのAI」を販売している。その問題こそが失われた時間の大半を引き起こす。

見えないフェーズを可視化する

Opsimaの運営データバックボーンであるEquipmentOSは、フィールドコミュニケーションチャンネル（無線、WhatsApp、メール）を保全記録に接続する。検知と診断は文書化されていない会話ではなく、タイムスタンプ付きイベントになる。Agent Builderは48時間で4フェーズのMTTRキャプチャワークフローを構築できる。ワークフローはチームの既存の無線、WhatsApp、CMMS接続に対して実行される。

実際のシグナル密度

主要なコンテナターミナルでは、ステータスイベントが毎月約10倍増加した。フリートアベイラビリティが5%向上し、資産信頼性が15%改善された。レバーはシグナル密度だった。つまり、以前はシステムに届かなかった無線通話とWhatsAppスレッドを記録することだ。

その密度でのライブ資産ステータスとKPI可視性は保全計画を変革する。チームは部品、クルー配置、シフト管理についてより良い決定を下す。

MTTRを正確に測定し、実際にダウンタイムを引き起こすフェーズを短縮するには、15分のディスカバリーコールを予約する。