MTTRとは？計算式・MTBFとの違いと稼働率への影響、短縮策を実装目線で解説【2026年版】

MTTR（Mean Time To Repair／平均修復時間）は、障害が起きてから復旧するまでにかかった時間の平均です。計算式は「総修理時間 ÷ 修理回数」とシンプルですが、どこからどこまでを測るか、平均値をどう読むかで意味が大きく変わります。この記事では、MTTRの計算式と測定単位、MTBF・MTTF・MTTDとの違い、稼働率（可用性）を決める関係式、検知から復旧までの計測設計、そしてMTTRを縮める実装策と「MTTRだけを追うと壊れる場面」までを、SRE・インシデント対応の実装目線で整理しました。

まとめ｜MTTRで測る復旧速度と稼働率・SRE指標での位置づけ

MTTRは「壊れにくさ」ではなく「直りの速さ」を測る指標です。故障のしにくさを示すMTBFと対にして使い、稼働率＝MTBF÷（MTBF＋MTTR）で可用性に効いてきます。設計判断としては、まず「どの時刻を開始・終了に取るか」を先に決めることが精度を左右します。

実務での結論は3点です。第一に、MTTRは検知（MTTD）・対応・復旧の合算であり、内訳を分けて計測しないと改善点が見えません。第二に、平均値は長時間の1件に引きずられるため、中央値やパーセンタイルの併記が要点になります。第三に、MTTRの短縮は自動復旧・ランブック・冗長化で狙う一方、数値だけを追うと恒久対策が後回しになりがちです。稼働率設計の全体像は可用性とは？稼働率の計算と高可用性の設計と合わせて読むと、MTTRの位置づけが掴めます。

MTTRの定義と平均修復時間としての計算式、4種類のMTTRの区別

MTTRという略語は文脈で指す範囲が変わります。まず基本の計算式と単位を押さえ、次に「R」が何を指すかで分かれる4系統を区別しましょう。

MTTRの計算式（総修理時間÷修理回数）と測定に使う時間の単位

MTTRの基本式は「対象期間の総修理時間 ÷ その期間の修理（対応）回数」です。例えば1か月で障害が5回起き、復旧に要した時間の合計が10時間なら、MTTRは10 ÷ 5 ＝ 2時間になります。単位は分・時間のいずれでもよく、SLA監視では分単位、設備保全では時間単位が多く使われています。ここで注意したいのは「総修理時間」に何を含めるかです。検知の遅れや連絡待ちの時間を入れるかどうかを社内で定義しておかないと、同じ障害でもMTTRが数倍ずれてしまいます。

Repair・Recover・Respond・ResolveでずれるMTTRの意味

MTTRは1つの言葉に複数の定義が同居しています。実装で混乱しやすいので、測る区間を明示して使い分けましょう。

• Mean Time To Repair（平均修復時間）：修理作業そのものにかかった時間。設備・ハードの保全で中心に使う。
• Mean Time To Recover（平均復旧時間）：障害発生からサービスが正常に戻るまで。SRE・IT運用の主指標。
• Mean Time To Respond（平均応答時間）：検知から対応着手までの反応の速さ。オンコール体制の評価に使う。
• Mean Time To Resolve（平均解決時間）：復旧後の恒久対策・再発防止まで含めた全体。

同じ「MTTR」でもRepairとResolveでは対象時間が数倍違います。ダッシュボードやSLOで扱うときは、どの定義かを列名やメトリクス名に書き込み、チーム間の解釈ずれを防ぎましょう。

MTTD・MTBF・MTTFとMTTRの位置関係（故障ライフサイクルでの役割）

MTTRは故障ライフサイクルの一部分です。障害が起きてから直るまでを、検知・対応・復旧の順に各指標が受け持ちます。MTTD（Mean Time To Detect＝平均検知時間）は「起きてから気づくまで」、MTTRは「気づいてから直るまで」、MTBF（平均故障間隔）は「直ってから次に壊れるまで」を担当します。MTTF（平均故障時間）は修理せず使い切る部品の寿命を指し、繰り返し修理する対象のMTBFとは別物です。この4つを取り違えると、改善すべき区間を誤って投資先を外してしまいます。

MTBF・MTTFとMTTRの違いと、稼働率（可用性）を決める計算関係

MTTRとMTBFは「直りの速さ」と「壊れにくさ」で役割が逆です。両者を組み合わせると稼働率が算出でき、99.9%系の可用性目標に直結します。

MTBF（平均故障間隔）とMTTRの役割分担と、混同しやすいMTTF

MTBF（Mean Time Between Failures）は、ある故障から次の故障までの平均稼働時間で、値が大きいほど壊れにくい設計です。MTTRは値が小さいほど早く直ります。設計改善では「MTBFを伸ばす（壊れにくくする）」と「MTTRを縮める（早く直す）」の二正面があり、コストの掛け先が違います。MTTF（Mean Time To Failure）は交換前提の部品の平均寿命で、修理して使い続けるサーバーやディスクにはMTBFを用いるのが通例です。この区別が曖昧だと、保守契約や部品調達の見積りがずれてしまいます。

稼働率＝MTBF÷（MTBF＋MTTR）の計算と、年間停止許容時間への影響

稼働率（可用性）は、稼働率 ＝ MTBF ÷（MTBF ＋ MTTR）× 100 で求めます。MTBFが大きくMTTRが小さいほど100%に近づく関係です。例えばMTBFが1,000時間、MTTRが1時間なら稼働率は約99.9%になります。可用性目標を年間の停止許容時間に換算すると、目標の厳しさが実感できます。

four nines以上になると、1件の障害で許される年間停止は1時間を切る計算です。ここではMTTRを人手で縮めるより、冗長化とは？二重化との違いと企業の設計判断で解説する自動フェイルオーバーへ設計を切り替える判断が必要になります。切り替えられれば、稼働率は人の反応速度に左右されません。

MTTRを稼働率目標（SLA/SLO）に翻訳するときの注意点

稼働率をSLAやSLOとして約束する場合、MTTRは「守れる復旧速度」の裏付けになります。稼働率99.9%を掲げても、実測MTTRが5時間なら年間許容8時間45分をわずか2件で使い切ってしまいます。目標稼働率から逆算して許容MTTRを決め、その値を体制で担保できるかを検証しましょう。稼働率とSLA/SLOの決め方はSLAとは？SLO・SLIとの違いと稼働率の決め方で扱っており、MTTRはその測定側の指標として噛み合います。

MTTRを検知・対応・復旧に分解する計測設計とツール実装のポイント

MTTRを縮めるには、まず正しく測る必要があります。一枚岩の「復旧までの時間」ではなく、区間ごとにタイムスタンプを取ると、遅れの原因が検知にあるのか対応にあるのかが分かります。

検知（MTTD）から対応着手・復旧完了までのタイムスタンプ設計

計測の起点と終点を機械的に定めます。実装では次の順にイベント時刻を記録しましょう。

1. 障害発生時刻：監視のしきい値超過やヘルスチェック失敗を検知した時刻。
2. 検知・通知時刻：アラートが担当者へ届いた時刻（ここまでがMTTD）。
3. 対応着手時刻：オンコール担当が確認・着手した時刻（ここまでがMTTA＝平均応答）。
4. 復旧完了時刻：サービスが正常応答に戻った時刻（発生からここまでがMTTR）。

この4点を取れば、MTTRを「検知の遅れ」「駆けつけの遅れ」「復旧作業そのもの」に分解できます。多くの現場でボトルネックは復旧作業ではなく検知・通知の遅延にあり、まず監視のしきい値と通知経路を見直すと効果が出ます。分解しないまま総時間だけを追っても、どこに手を入れるべきか見えてきません。検知と相関をAIで自動化してこの遅延を縮める考え方はAIOpsとは？IT運用×AIの仕組みと主要機能で整理しています。

インシデント管理ツールでMTTRを自動集計するための実装の勘所

MTTRの集計を手作業の記録に頼ると、多忙な障害対応中に時刻が抜け落ちます。PagerDuty・Opsgenie・New Relic・Datadogなどのインシデント管理／監視基盤は、アラート発報・確認（acknowledge）・解決（resolve）の各イベント時刻を自動で記録し、MTTA・MTTRをレポート化してくれます。実装のポイントは、監視側のアラートとチケット（インシデント）を一意のIDで紐づけ、resolveの押し忘れを運用ルールで防ぐことです。障害対応の体制づくりとの接続について、インシデント管理の全体像は別記事（ITIL準拠のプロセスと実装）で整理しています。

平均値の落とし穴と、中央値・パーセンタイル併用によるMTTRの読み方

MTTRは平均であるため、極端に長い1件が数値を大きく押し上げます。月に10件の障害があり9件は5分で復旧、1件だけ6時間かかった場合、平均MTTRは約41分になりますが、実態の大半は5分です。改善状況を正しく追うには、平均に加えて中央値（p50）や95パーセンタイル（p95）を併記しましょう。p95が突出していれば「まれに起きる長時間障害」に焦点を当てるべきで、平均だけを見ていると打ち手を外します。

MTTRを短縮する実装策と、短縮を優先すべきでない場面の判断基準

MTTR短縮の打ち手は明確です。ただし、数値そのものを目的化すると品質を損なう場面があります。ここでは採用する打ち手と、あえて追わない条件を切り分けましょう。

復旧自動化・ランブック・冗長化でMTTRを縮める打ち手の優先順位

MTTR短縮で効果が大きい順に手を打ちます。まず検知と通知の自動化（監視しきい値・オンコール自動呼び出し）で待ち時間を消しましょう。次に、頻出障害の復旧手順をランブック化し、判断を挟まず実行できる状態にするのが次の一手です。復旧作業の一部はスクリプトで自動化すると、再起動や切り離しを人手から外せます。そのうえで単一障害点を冗長化し、フェイルオーバーで「直す前に切り替える」設計にすれば、体感の復旧時間はほぼゼロに近づきます。障害ノードの切り離しにはロードバランサーによるヘルスチェック連動が有効で、異常なサーバーを自動で振り分け対象から外せる仕組みです。こうした復旧設計と日々の運用体制づくりは、一創の保守運用・内製化支援でも、監視・オンコール・ランブック整備を含めて伴走しています。

MTTRだけを追うと壊れる場面（恒久対策の軽視・数値操作）の失敗パターン

MTTRの短縮は手段であって目的ではありません。数値だけを評価軸にすると、次の失敗が起きます。ひとつは、暫定復旧（再起動でしのぐ）を繰り返してMTTRは縮むのに、根本原因が残って同じ障害が再発するケースです。この場合はMTBFが縮み、稼働率はむしろ悪化してしまいます。もうひとつは、軽微な事象をインシデントに数えない・resolveを早めに押すといった数値操作で、指標が実態から乖離するパターンです。MTTRを追うなら、MTBF（再発のしにくさ）とResolve（恒久対策完了）を必ず併走させ、短縮と再発防止のどちらかに偏らせないことが判断の軸になります。障害頻度が低い小規模システムに、five nines前提の自動復旧を作り込むのは過剰投資で、この場合はMTTR短縮より監視の整備を先に置くべきです。

受託開発・保守運用でMTTR目標を契約（SLA/SLO）に落とす設計

外部委託や内製移行では、MTTRを合意可能な数値に落とし込みます。運用側が約束できるのは「対応着手までの時間（応答）」までで、復旧完了時間は障害の性質に左右されるため、MTTA（応答）とMTTR（復旧）を分けて目標化するのが実務的です。契約では、稼働率目標→許容ダウンタイム→許容MTTRの順に逆算し、その体制（オンコール・冗長構成・ランブック）を用意できるかで実現性を見極めます。稼働率をSLA/SLOへ落とす具体はSLAとは？SLO・SLIとの違いを、システムの止まらない設計そのものは可用性の設計を土台にすると、MTTR目標が絵に描いた餅になりません。

MTTR（平均修復時間）に関するよくある質問と実務での回答例

MTTRの計算や関連指標について、実務で問われやすい5点に答えます。

MTTRの計算式と単位はどう決めればよいですか？

基本式は「総修理（復旧）時間 ÷ 障害件数」です。単位は分・時間のどちらでも構いませんが、SLA監視では分、設備保全では時間が一般的です。式そのものより定義が肝心で、開始時刻（発生か検知か）と終了時刻（暫定復旧か恒久対策完了か）を社内で固定してから測ります。定義が揺れると、同じ障害でもMTTRが数倍ぶれてしまいます。

MTTRとMTBFの違いは何ですか？

MTTRは「直るまでの平均時間（直りの速さ）」、MTBFは「故障から次の故障までの平均時間（壊れにくさ）」を指します。MTTRは小さいほど良く、MTBFは大きいほど良い、と向きが逆です。両者は稼働率 ＝ MTBF ÷（MTBF ＋ MTTR）で結びつき、可用性の高さを決めます。

MTTRとMTTD・MTTAはどう区別しますか？

故障発生からの時間軸で分かれます。MTTD（平均検知時間）は「起きてから気づくまで」、MTTA（平均応答時間）は「気づいてから対応着手まで」、MTTR（平均復旧時間）は「発生から復旧完了まで」の全体です。MTTRを分解するとMTTD・MTTAが内訳として現れ、どの区間を縮めるべきかが見えてきます。

MTTRの目安・平均値はどのくらいですか？

一律の基準値はなく、システムの可用性目標から逆算します。稼働率99.9%（年間許容約8時間45分）で月数件の障害を見込むなら、1件あたり許容MTTRは1〜2時間程度が目安です。他社比較の絶対値より、自社の目標稼働率と障害頻度から許容値を決め、実測を近づける進め方が実務に合っています。

MTTRを短縮する最初の一手は何ですか？

多くの現場では復旧作業より検知・通知の遅れがボトルネックです。まず監視のしきい値とアラートの通知経路（オンコール自動呼び出し）を見直すと、対応着手が早まりMTTR全体が縮みます。そのうえで頻出障害のランブック化、単一障害点の冗長化へと進めると、費用対効果の高い順に短縮できます。

関連記事

• 可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説：MTTRが効く稼働率・可用性設計の上位概念を整理しています。
• SLAとは？SLO・SLIとの違いと稼働率の決め方・監視実装：MTTRをSLA/SLOの目標へ落とす手順を解説しています。
• 冗長化とは？二重化との違い・種類と構成、企業の設計判断：MTTRを実質ゼロに近づける冗長化・フェイルオーバーの設計を扱います。
• ロードバランサーとは？仕組み・種類・振り分け方式：障害ノードの自動切り離しでMTTRを縮める実装を解説しています。
• スケールアウトとスケールアップとは？水平・垂直スケーリングの違い：可用性を支えるスケーリング設計の基礎を整理しています。