MTTR・MTBF・MTTAとは？計算式と計算例

結論から： MTTRは、障害が起きてから平均してどれくらいで復旧するかを表す指標です。MTBFは、システムが障害と障害の間に平均してどれくらい動き続けるかを表します。MTTAは、インシデントの発生から誰かが対応を始めるまでの平均時間です。MTTRとMTTAはサポートチームの動きの速さを、MTBFはシステム自体の信頼性を測ります。契約書に書く前に、MTTRの「R」がどの意味なのかを必ず明記してください。

月次のITサポートレポートを開くと、この3つの略語が並んでいることがよくあります。似た名前なので混同されやすく、実際に誤用もよく見かけます。この記事では、それぞれの意味と計算式、簡単な計算例を示したうえで、SLA（サービスレベル契約）に入れるべき指標と、レポートで見るだけにしておくべき指標を整理します。

定義と計算式は、Atlassianのインシデント指標の解説を参照しました。この記事は各指標の計算式を示し、MTTRに4つの意味があることを指摘しています。2026年10月28日に確認しています（確認日：2026-10-28）。以下の計算例の数値はすべて説明用に作った架空のものであり、Brocentの実績ではありません。

MTTR・MTBF・MTTAはそれぞれ何の略？

3つとも「平均時間」です。合計を件数で割った値なので、「平均してどれくらいか」という問いに答えます。違うのは、1件の障害の流れのうち、どの区間を測っているかです。

MTTA（Mean Time To Acknowledge、平均応答確認時間）： アラートやチケットが発生してから、担当者が対応に着手するまで。
MTTR（Mean Time To Repair / Recover / Respond / Resolve）： 障害の発生（またはチケット起票）から、サービスが正常に戻るまで。問題は「R」の意味で、次の章で説明します。
MTBF（Mean Time Between Failures、平均故障間隔）： 修理して使い続けるシステムが、平均してどれくらいの間隔で故障するか。

1件の障害を時間軸で考えるとわかりやすくなります。障害が起き、アラートが鳴り、誰かが気づき、誰かが直し、次の障害までサービスは正常に動きます。最初の空白がMTTA、障害から復旧までがMTTR、復旧から次の障害までの長い区間がMTBFです。

MTTRとは？なぜ4つの意味があるのか

MTTRは、3つの中で最もよく使われる一方で、定義が最も揃っていない指標です。Atlassianは、Rがrepair（修復）、recovery（復旧）、respond（対応）、resolve（解決）のいずれにもなり得ること、4つは重なる部分があっても同じ測定ではないことを指摘しています。私たちの理解は次のとおりです。

平均修復時間（repair）： 故障箇所を実際に直す作業にかかった時間。通常は修復の開始から終了までで、システムが完全に動くようになるまでのテストも含みます。検知や待ち時間は含みません。
平均復旧時間（recovery）： 障害の発生から、利用者がサービスを再び使えるようになるまでの全体の時間。検知、確認、原因調査、修復、動作確認を含みます。経営者が気にするのはこの意味で、いわゆる停止時間そのものです。
平均対応時間（respond）： 最初のアラートから、システムが完全に復旧するまでの平均時間で、アラートの仕組み自体による遅れは含みません。これはAtlassianの定義です。
平均解決時間（resolve）： チケットの起票から解決済みでクローズされるまで。恒久対策やフォローアップを含みます。サービスデスクのツールのレポートでMTTRと表示されるのは、多くの場合この意味です。

どれも間違いではありません。問題は、意味の違う数字どうしを比べてしまうことです。ベンダーが「平均40分で修理しました」と報告し、お客様側は3時間止まったと感じている、ということはどちらも事実でありえます。

実務上のルールは、数字の横に定義を書くことです。どの時点から計り始め、どの時点で止めるのか、お客様の返信待ちの時間を含めるのかを明記します。

MTTRの計算方法：計算例

計算式はシンプルです。

MTTR = 全インシデントの所要時間の合計 ÷ インシデント件数

あるサポートチームが1か月に5件のインシデントを処理し、チケット起票からサービス復旧までの時間が次のとおりだったとします。

インシデントA：45分
インシデントB：90分
インシデントC：30分
インシデントD：240分
インシデントE：15分

合計は45 + 90 + 30 + 240 + 15 = 420分です。5件で割ると、MTTRは84分になります。

同じデータを別の見方で見てみましょう。小さい順に並べると15、30、45、90、240で、中央値は45分です。5件のうち4件は90分以内に解決していますが、Dだけが長引いて平均を84分まで押し上げました。この平均値は計算としては正しいものの、実際に84分かかった案件は1件もないため、誤解を招きます。

そのため、平均値だけでなく、中央値と最も時間がかかった案件も併記することをお勧めします。平均だけを報告すると、ひどい夜が1回あっただけで月全体が悪く見えたり、すぐ終わるパスワードリセットの山が1台のサーバー障害を隠したりします。

MTBFとは？計算方法

MTBFは、修理して再び使えるもの、たとえばサーバー、ファイアウォール、回線、業務アプリケーションの信頼性を測る指標です。

MTBF = 総稼働時間 ÷ 故障回数

計算例：ファイルサーバーを30日間（720時間）監視し、その間に3回故障し、停止時間の合計は6時間でした。

稼働時間 = 720 − 6 = 714時間
故障回数 = 3回
MTBF = 714 ÷ 3 = 238時間

つまり、このサーバーは平均して238時間（約10日弱）ごとに故障した計算です。

注意点が2つあります。1つ目は、MTBFにはある程度の履歴が必要なことです。1か月に3回の故障では、今後1年のことはほとんどわかりません。2つ目は、MTBFは修理して使い続けるシステム向けの指標だということです。修理せず交換する部品にはMTTF（Mean Time To Failure、平均故障寿命）を使います。Atlassianも、修理できない対象にはMTTFが適していると説明しています。

また、MTBFは機器群や期間全体の平均であり、特定の1台がいつ壊れるかを予測するものではありません。「238時間」を、このサーバーが238時間は持つという約束と受け取らないでください。

MTTAとは？計算方法

MTTAは対応の素早さを測る指標です。

MTTA = アラートから対応着手までの時間の合計 ÷ インシデント件数

計算例：5件のインシデントが発生し、エンジニアが着手するまでの時間が4分、6分、10分、3分、12分でした。合計は35分なので、MTTAは35 ÷ 5 = 7分です。

MTTAが低ければ、アラートがすばやく担当者に届き、担当者が動いているということです。MTTAが徐々に伸びる場合は、キューが詰まっている、アラートが無視されている、オンコールの割り振りが適切でないといった早期の警告になります。ただし、復旧にどれくらいかかるかはMTTAからはわかりません。

MTTAは、SLAに出てくる「初回応答時間」に近いものの、同じではありません。初回応答時間は個々のチケットに対する約束（たとえば「緊急チケットは15分以内に初動」）で、MTTAは実績の平均です。MTTAが良好でも、個別のチケットで目標を外すことはあります。優先度ごとの初動目標の考え方は、P1〜P4の優先度レベルの解説をご覧ください。

MTTRとMTBFの違いと関係

2つは表裏の関係にあり、組み合わせると稼働率が求められます。

MTBFは、どれくらいの頻度で壊れるかを表します。
MTTR（「復旧」の意味で使う場合）は、1回の障害がどれくらい続くかを表します。

稼働率は、サービスが正常に動いている時間の割合です。

稼働率 = MTBF ÷ （MTBF + MTTR）

先ほどのファイルサーバーの例では、MTBFは238時間です。3回の故障で合計6時間停止したので、MTTRは6 ÷ 3 = 2時間。稼働率は238 ÷ （238 + 2）= 238 ÷ 240 ≈ 0.9917、約99.2%です。逆から確認すると、720時間のうち714時間稼働していたので、同じく99.2%です。

この関係から、改善の道が2つ見えてきます。1つは故障そのものを減らすこと（MTBFを上げる）で、ハードウェアの更新、パッチ適用、監視、変更管理が中心になります。もう1つは復旧を速くすること（MTTRを下げる）で、手順書、予備機、エスカレーション経路、自動化が効きます。中小企業の場合、後者のほうが費用を抑えやすく、すぐに着手しやすいことが多いと考えています。

SLAに入れる指標、レポートにとどめる指標

契約書の文言と管理レポートでは、役割が違います。私たちの考えは次のとおりです。

チケット単位の初回応答・解決目標はSLAに入れます。 1件ずつ達成したかどうかを確認できる約束だからです。たとえば優先度ごとの初動時間と解決時間です。BrocentはSLAのページでこれらを公開しています。緊急（P1）チケットは初動15分、解決目標は8営業時間で、プレミアムのサービス時間帯では24×7の対応も選べます。数字の読み方はSLAとはで解説しています。
MTTAとMTTRは月次レポートに載せます。 傾向を見るための指標です。平均値なので、1つの平均値だけで違約条項を決めるのは適切ではありません。
MTBFは信頼性や容量のレビューで使います。 インフラ向けの指標で、どのファイアウォール、回線、サーバーが繰り返し故障していて、入れ替えるべきかを判断する材料になります。

契約に平均値を使う場合（たとえば「平均解決時間4時間未満」）は、計測の開始点、終了点、停止ルール（お客様の返信待ちなど）、重大インシデントを除外するかどうかを明記してください。この4点がないと、数字を検証できません。

計測を始める前に定義をそろえるには

ベンダーや社内チームとレポートを設計するときは、次のチェックリストを使ってください。

MTTRが修理・復旧・対応・解決のどれを指すのかを決める。
開始時刻（アラート発生、チケット起票、障害の発生）と終了時刻（サービス復旧、チケット解決、チケットクローズ）を決める。
お客様の返信待ち、ベンダー待ち、承認済みの変更作業時間帯の扱いを決める。
インシデント単位で数えるか、チケット単位で数えるか、重複や誤報を除外するかを決める。
1つの混合値ではなく、優先度別に報告し、P4の依頼がP1の障害を薄めないようにする。
平均値の隣に、中央値と最も遅かった案件を併記する。
定義は、数字と同じ文書に書く。

こうしたレポートを優先度の定義と結びつけるには、重大度と優先度の違いをご覧ください。障害が大きく、専用の手順が必要になったときは、重大インシデント管理が参考になります。稼働率を考えるうえでの復旧側の目標は、RTOとRPOの違いで扱っています。

Brocentが公開しているサービスレベルはどこで見られる？

優先度ごとに約束している対応目標はSLAのページで公開しており、8×5と24×7の2つのサービス時間帯もそこで説明しています。マネージドITサポートのプランとユーザー単価には、マネージドITサポートの公開価格と、契約上のサービス時間帯内での緊急インシデントに対する15分の初回応答が掲載されています。お問い合わせの前に比較していただけます。ご自身の環境にどのサービスレベルとレポートが合うかご相談になりたい方は、お問い合わせください。

よくある質問

MTTRは何の略ですか？

MTTRは、Mean Time To Repair（平均修復時間）、Recover（平均復旧時間）、Respond（平均対応時間）、Resolve（平均解決時間）のいずれかの略として使われます。どれも平均所要時間ですが、計測の開始点と終了点が異なります。レポートを読むときは、どの意味で使っているかを必ず確認してください。