MTTRとは？ わかりやすく10分で解説

MTTR（Mean Time To Repair）は、障害や故障が発生してから復旧するまでに要した時間の平均を示す指標です。IT運用や設備保守では、障害を減らす取り組みと同時に、発生後にどれだけ早く復旧できるかを評価するために使われます。MTTRを改善するには、検知、初動、原因切り分け、復旧手順、権限、連絡体制を分けて見直し、どの段階で時間を要しているかを特定する必要があります。

MTTRとは

MTTR（Mean Time To Repair）は、システム、機器、設備などに障害や故障が発生した際に、復旧までに要した時間の平均を示す指標です。日本語では「平均修復時間」または「平均復旧時間」と表現されます。

MTTRは、障害対応の速さを測る指標です。値が短いほど、障害発生後に復旧しやすい運用になっていると判断できます。一方で、MTTRだけでは障害の発生頻度は分かりません。復旧は速くても障害が頻発している場合は、別の信頼性指標と組み合わせて評価します。

MTTRの定義

MTTRは一般に、障害や故障が発生してから、対象システムや機器が利用可能な状態に戻るまでの時間を対象にします。ただし、現場によって「発生」「検知」「復旧」の定義が異なるため、測定開始点と終了点を先に決める必要があります。

原因切り分け、修復作業、確認テスト、再起動などをMTTRに含める運用は一般的です。ただし、再発防止策の実装まで含めるかどうかは、指標の目的によって分けます。顧客影響を見る場合はサービス復旧まで、保守作業の効率を見る場合は修復作業の完了まで、というように定義を固定します。

MTTRが示す意味

MTTRが短い場合、障害発生後の検知、判断、復旧作業、確認が比較的速く進んでいると考えられます。MTTRが長い場合は、監視の遅れ、担当者への通知遅延、原因切り分けの難しさ、復旧手順の未整備、権限不足、部品調達の遅れなどが疑われます。

MTTRは、障害対応の結果を平均化した数値です。そのため、単に「短いか長いか」だけでなく、障害の重大度、発生領域、時間帯、担当チーム、復旧手順の有無ごとに分解して見ると、改善すべき工程を特定しやすくなります。

MTTRが重要視される理由

MTTRは、運用品質を「復旧の速さ」という観点から把握できる指標です。システムやサービスの停止時間は、顧客体験、売上、問い合わせ対応、契約上の責任、社内業務の継続に影響します。MTTRを継続的に追うことで、障害発生後の復旧力を評価できます。

ダウンタイムが与える影響

ダウンタイムが長引くほど、利用者はサービスを利用できず、機会損失や業務停止が発生します。B2Bサービスでは、取引先の業務に影響することもあります。契約にSLAが定められている場合は、復旧時間がサービス品質の評価や補償条件に関係することがあります。

また、復旧が遅れると、問い合わせ対応、社内報告、顧客説明、再発防止策の検討にかかる負担も増えます。MTTRは、こうした影響を抑えるために、復旧工程の弱点を見つける指標として使えます。

運用改善のKPIとして使いやすい

MTTRは、監視強化、復旧手順の整備、自動化、教育、権限設計、エスカレーション体制の改善効果を数値で確認しやすい指標です。個別障害の反省だけでなく、月次や四半期で推移を追うことで、運用改善が進んでいるかを確認できます。

ただし、MTTRをKPIにする場合は、数値の短縮だけを目的にしないことが重要です。暫定対応だけを早く行い、恒久対応を後回しにすると、同じ障害が再発する可能性があります。MTTRは、MTBFなどの関連指標とあわせて確認します。

MTTRの計算方法

MTTRは、特定期間内に発生した障害や故障について、修復にかかった合計時間を件数で割って求めます。計算式は単純ですが、集計条件を統一しなければ、期間比較やチーム比較ができません。

基本式

MTTR = 修復にかかった合計時間 ÷ 故障回数

「修復にかかった時間」は、あらかじめ決めた開始点から終了点までの時間です。開始点を障害発生時刻にするのか、検知時刻にするのか、担当者の認知時刻にするのかで、数値の意味が変わります。

計算例

1か月の間に3回の障害が発生し、復旧までにそれぞれ2時間、3時間、1時間かかった場合、MTTRは次のように計算します。

MTTR = (2 + 3 + 1) ÷ 3 = 2時間

この場合、対象期間の平均復旧時間は2時間です。ただし、3件の障害がすべて同じ重大度とは限りません。重要システムの停止と軽微な機能障害を同じ平均値に含めると、実態を読み違えることがあります。

計算時に決めておくべき前提

MTTRを運用指標として使う場合、次の前提を固定します。

顧客影響の短縮を目的にするなら、終了点はサービスレベルの復帰に合わせる方が実態に近くなります。保守作業の効率を評価するなら、修復作業の開始から完了までを別指標として切り出す方法もあります。

MTTRと関連指標の違い

信頼性や運用品質を評価する際は、MTTRだけでなく、複数の指標を組み合わせます。復旧の速さ、故障しにくさ、初動の速さは、それぞれ異なる問題を示すためです。

MTBF・MTTF・MTTAとの違い

同じ「復旧が遅い」という状況でも、原因が初動にあるのか、原因切り分けにあるのか、修復作業にあるのかで対策は変わります。MTTAとMTTRを分けておくと、通知やエスカレーションの問題と、復旧作業そのものの問題を切り分けやすくなります。

どの指標をいつ使うか

指標は目的に合わせて使い分けます。予防保全や信頼性を評価する場合はMTBF、復旧力を評価する場合はMTTR、初動の速さを評価する場合はMTTAを使います。

例えば、MTTRが短くてもMTBFが短い場合は、復旧は速いものの障害が頻発している状態です。この場合は、復旧手順よりも根本原因の解消や予防策を優先する必要があります。逆に、MTBFは長いがMTTRが長い場合は、障害頻度は低くても、発生時の対応力に課題があります。

MTTRを短縮するための実務ポイント

MTTR短縮は、担当者に復旧を急がせることではありません。復旧までの工程を分解し、時間を要している箇所を減らす取り組みです。検知、初動、原因切り分け、復旧作業、確認、報告の各段階を分けて見ます。

検知を早める

障害の発生に気づくのが遅いと、復旧までの時間も長くなります。監視対象、監視間隔、しきい値、通知先、重大度分類を見直し、利用者影響の大きい事象を早く検知できるようにします。

一方で、アラートが多すぎると重要な通知が埋もれます。通知の重複、低重要度アラート、対応不要のアラートを整理し、担当者が優先順位を判断できる状態にします。

原因切り分けを速くする

復旧に時間を要する原因として、原因切り分けに必要な情報が不足しているケースがあります。ログ、メトリクス、トレース、変更履歴、構成情報を確認できる状態にし、障害時に事実を追えるようにします。

過去の障害対応をナレッジ化し、よくある事象、確認順序、担当領域、エスカレーション先を整理しておくと、初動後の判断が速くなります。可観測性を高めることは、MTTR短縮に直結します。

復旧手順を標準化・自動化する

復旧手順が担当者の経験に依存していると、時間帯や担当者によって復旧時間がばらつきます。ランブック、チェックリスト、判断基準、承認手順を整備し、誰が対応しても同じ順序で確認できるようにします。

再起動、切り戻し、フェールオーバー、構成変更、バックアップからの復元など、手順化できる作業は自動化を検討します。ただし、自動化する前に、実行条件、影響範囲、戻し方を明確にしておく必要があります。

復旧に必要な資源を事前に用意する

部品、権限、連絡先、契約情報、ベンダー窓口がそろっていないと、復旧作業が止まります。夜間・休日を含め、誰が何を承認し、どの権限でどの作業を行うかを決めておきます。

設備保守では交換部品や保守契約、IT運用では管理権限、クラウド操作権限、バックアップ、復旧手順、連絡網が重要です。復旧資源を平時に確認することで、障害時の待ち時間を減らせます。

事後レビューで再発要因を分ける

MTTRを短縮するには、障害後の振り返りも必要です。発生原因、検知の遅れ、初動判断、切り分け、復旧作業、確認、社内外連絡を分けて記録します。

復旧時間が長かった理由を「担当者の判断が遅かった」とまとめるだけでは改善につながりません。ログ不足、権限不足、手順未整備、連絡先不明、承認待ち、部品不足など、次回減らせる待ち時間として扱います。

MTTRの活用例

MTTRは、ITシステム、ネットワーク、製造設備、社内基幹システムなど、停止すると損失が出る対象で使われます。単体の障害対応を評価するだけでなく、一定期間の傾向を見ることで、運用改善の優先順位を決められます。

IT運用での使い方

IT運用では、インシデント管理ツールや監視システムの記録から、障害ごとの復旧時間を集計します。月次や四半期ごとにMTTRを確認し、重大度、システム、原因分類、担当領域ごとに分解します。

例えば、特定のアプリケーションだけMTTRが長い場合は、ログ不足、復旧手順の不足、担当者依存が疑われます。ネットワーク障害のMTTRが長い場合は、構成情報、監視点、ベンダー連絡、代替経路の確認が必要です。

設備保守での使い方

設備保守では、機器が故障してから修理が完了するまでの平均時間としてMTTRを使います。修理担当者の到着時間、部品交換時間、確認運転、再稼働判断などが対象になります。

MTTRが長い場合は、交換部品の在庫不足、作業手順の未整備、保守契約の条件、担当者の到着時間、設備構成の複雑さなどを確認します。設備の可用性を高めるには、故障しにくさだけでなく、修理しやすさも設計対象になります。

改善につながる読み取り方

MTTRは平均値であるため、集計結果だけを見るのではなく、障害の内訳を分解して判断します。

MTTRに関する誤解と注意点

MTTRは分かりやすい指標ですが、使い方を誤ると現場の実態を見落とします。特に、短縮だけを目的にする、測定範囲をそろえない、平均値だけで判断する、という使い方には注意が必要です。

短ければ常に良いとは限らない

復旧が速いこと自体は望ましい状態です。しかし、障害が頻発している場合、MTTRが短くても利用者影響や運用負荷は大きくなります。復旧時間だけでなく、障害件数、再発率、RTO、MTBFとあわせて確認します。

暫定復旧だけを優先し、根本原因の解消が遅れると、同じ障害が繰り返されます。MTTR短縮と再発防止は、別々の目的として管理する必要があります。

測定範囲が曖昧だと比較できない

暫定復旧で計測を止めるのか、本復旧まで含めるのかが月ごとに変わると、MTTRの比較は成立しません。開始点や終了点を変更した場合は、変更日と理由を記録します。

チーム間で比較する場合も同じです。障害の重大度、対象システム、計測範囲、外部依存の扱いが異なる場合、単純な数値比較は避けます。

平均値だけでは実態を隠すことがある

MTTRは平均値であるため、外れ値の影響を受けます。重大障害が1件発生するだけで平均値が大きく変わることがあります。逆に、軽微な障害が多いと、重大障害の復旧遅延が目立ちにくくなる場合もあります。

読み違いを減らすには、平均値に加えて中央値、95パーセンタイル、重大度別MTTR、システム別MTTRを確認します。経営報告では平均値を使い、改善活動では内訳を分解する、といった使い分けが有効です。

MTTR改善の確認項目

まとめ

MTTRは、障害や故障が発生してから復旧するまでの平均時間を示す指標です。復旧力を把握するうえで有用ですが、計算式だけを使っても、測定開始点、終了点、障害の定義がそろっていなければ比較できません。

MTTRを改善するには、検知、初動、原因切り分け、復旧手順、権限、連絡体制を分けて見直します。また、MTBF、MTTA、RTOなどの関連指標と組み合わせることで、復旧を速くするべきなのか、障害頻度を減らすべきなのかを判断しやすくなります。MTTRは、単なる平均値ではなく、運用改善の対象を特定するための指標として使うことが重要です。

MTTRに関するよくある質問