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

運用や保守の現場では、トラブルの「発生を減らす」だけでなく、「起きたときにどれだけ早く戻せるか」も同じくらい重要です。そこでよく使われるのがMTTRという指標です。本記事では、MTTRの定義、計算方法、近い指標との違い、短縮の実務ポイント、活用時の注意点までを整理します。読み終える頃には、MTTRをどう測り、何を改善すべきかを自分の現場に当てはめて判断できるようになることを目指します。

MTTRとは

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

MTTRの定義

MTTRは一般に、障害が起きてからサービスが元の状態に戻るまでの時間を対象とします。現場によって「どこからどこまでを含めるか」は差が出やすいため、まずは測定範囲（開始点と終了点）を明確にすることが重要です。

よくある測定範囲の例は次のとおりです。

• 開始点：障害発生時刻、監視で検知した時刻、担当者が認知した時刻（いずれを採用するかを決める）
• 終了点：暫定復旧（回避策適用）なのか、本復旧（恒久対応完了）なのか、サービスレベルが復帰した時点なのか

本文で述べられていたように、原因切り分け（診断）・修復作業・テスト・再起動などの時間を含める考え方は一般的です。ただし、恒久対応（再発防止策の実装）まで含めるかは、運用指標としての目的によって分けておくと混乱が減ります。

MTTRが示す意味

MTTRが短いほど、障害発生時にサービスを早く復旧できていることを示します。逆に、MTTRが長い場合は、検知・切り分け・復旧手順・体制・部品調達など、どこかにボトルネックがある可能性が高いと考えられます。

MTTRが重要視される理由

MTTRは、運用品質を「復旧の速さ」という観点から数値化できるため、SLAや顧客体験、事業継続性と結びつけて評価しやすい指標です。

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

サービス停止が長引くほど、機会損失や顧客の不満、問い合わせ対応コストが増えます。B2Bであれば取引先の業務停止に直結することもあり、信頼の毀損は短期では回復しにくいケースもあります。MTTRは、こうした影響を抑えるための「復旧力」を測る入口になります。

運用改善のKPIになりやすい

MTTRは、改善施策（監視強化、手順整備、自動化、教育など）の効果が数値に反映されやすい指標です。個別の障害対応を振り返るだけでなく、一定期間の平均として追うことで、運用の成熟度を継続的に評価できます。

MTTRの計算方法

MTTRの計算自体はシンプルで、特定期間内の「修復にかかった時間の合計」を「故障（障害）件数」で割ります。

基本式

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

計算例

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

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

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

同じ式でも、前提が曖昧だと数値の意味が変わります。特に次の点は、最初に決めておくと運用が安定します。

• 「障害」の定義：監視アラート1件を障害と数えるのか、影響範囲や重大度で数えるのか
• 開始点：発生時刻／検知時刻／認知時刻のどれを採用するのか
• 終了点：暫定復旧で止めるのか、本復旧まで追うのか
• 対象範囲：アプリのみ／インフラのみ／外部依存（クラウド障害など）を含めるか

目的が「顧客影響の短縮」なら、終了点は「サービスレベル復帰」に寄せるのが自然です。一方、目的が「保守作業の効率」なら、修復作業の範囲を明確に切る方が比較しやすくなります。

MTTRと関連指標の違い

信頼性や運用品質の評価では、MTTRだけでなく他の指標と組み合わせて見ることが一般的です。似た名称が多いため、混同しないように整理します。

MTBF・MTTF・MTTAとの違い

• MTBF（Mean Time Between Failures）：故障と故障の間の平均時間（稼働の持続性を見る）
• MTTF（Mean Time To Failure）：修理できない前提の機器などで、故障に至るまでの平均時間（寿命の目安として使われる）
• MTTA（Mean Time To Acknowledge）：障害を検知してから、担当者が認知・対応開始状態になるまでの平均時間（初動の速さを見る）

同じ「復旧が遅い」でも、原因が初動（MTTA）にあるのか、切り分け・修復（MTTR本体）にあるのかで対策は変わります。指標を分けておくことで、改善ポイントが見えやすくなります。

どの指標をいつ使うか

運用改善では、次のような使い分けが典型的です。

• 予防・信頼性の評価：MTBF（どれだけ壊れにくいか）
• 復旧力の評価：MTTR（どれだけ早く戻せるか）
• 初動の評価：MTTA（どれだけ早く動き出せるか）

「故障回数が多いが復旧は速い」「故障は少ないが復旧が遅い」といった状態は、MTTR単体では判断しづらいので、MTBFなどとセットで見るのが安全です。

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

MTTR短縮は、単に作業を急ぐことではなく、復旧までのボトルネックを減らすことです。多くの場合、次の4領域に分解して改善します。

検知を早める

障害の発生に気づくのが遅いと、復旧時間が伸びます。監視の粒度や通知経路を見直し、重要な兆候を取りこぼさない設計にします。アラートが多すぎて埋もれる場合は、重大度の整理やノイズ削減も効果的です。

原因切り分けを速くする

復旧に時間がかかる原因として多いのが、切り分けの迷走です。ログやメトリクスの整備、過去事例のナレッジ化、観測点（可観測性）の拡充により、原因特定までの時間を縮められます。

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

手順が人に依存していると、担当者や時間帯で復旧時間がぶれます。復旧手順のテンプレート化、チェックリスト化、ランブック整備に加え、再起動やフェイルオーバーなどの自動化ができる部分は自動化すると効果が出やすいです。

復旧に必要な資源を事前に揃える

部品や権限、連絡先が揃っていないと復旧が止まります。交換部品の在庫、アクセス権限、ベンダー連絡体制、エスカレーションルートなどを事前に準備し、夜間・休日でも回る形にしておくことが現実的です。

MTTRの活用例

MTTRは、IT運用だけでなく、製造設備や社内基幹システムなど「止まると損失が出る」対象で幅広く使われます。

現場での使い方

多くの組織では、障害対応の記録（インシデント管理）から復旧時間を集計し、月次・四半期などの単位でMTTRの推移を追います。数値が悪化したタイミングで、障害内容の内訳（重大度、原因、担当領域）を分解し、改善施策の優先順位を決めます。

改善につながる読み取りの例

• MTTRは悪化、MTTAは改善：初動は速いが切り分け・修復が重い（観測点不足、手順未整備、属人化など）
• MTTRは改善、MTBFは悪化：壊れやすいが復旧は速い（予防保全や品質改善が必要）

このように、関連指標と組み合わせると、単なる「速い／遅い」以上の判断ができます。

MTTRに関する誤解と注意点

MTTRは便利な指標ですが、使い方を誤ると現場の実態を見失うことがあります。

「短ければ短いほど良い」とは限らない

復旧が速いこと自体は望ましい一方で、障害頻度が高い状態を放置すると、顧客体験や運用負荷は悪化します。MTTRが短くても、MTBFが短い（よく壊れる）なら、根本原因の解消に投資すべき局面かもしれません。

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

「暫定復旧で止めるのか」「本復旧まで含めるのか」などの定義が揺れると、月ごとの比較が成立しません。指標として運用するなら、定義・計測方法・記録方法を先に固定し、変更がある場合は変更日を明示して扱うことが重要です。

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

平均は外れ値の影響を受けます。重大障害が1回入るだけでMTTRが跳ねることもあります。そのため、平均に加えて中央値やパーセンタイル（例：95%）を併記する、重大度別に分ける、といった工夫をすると読み違いを減らせます。

まとめ

MTTRは、障害発生から復旧までの平均時間を表す指標であり、運用の「復旧力」を評価するうえで重要です。計算式自体は単純ですが、障害の定義や計測範囲を明確にしないと、数値の意味がぶれてしまいます。

また、MTTRだけを追うのではなく、MTBFやMTTAなどの関連指標と組み合わせることで、改善すべきポイント（初動、切り分け、復旧手順、予防保全など）を具体化できます。自社の目的に合わせて測り方を揃え、継続的に振り返ることが、MTTRを「使える指標」にするための近道です。