MTTRとは、システムに障害が起きてから復旧するまでの平均時間を表す指標で、日本語では平均復旧時間や平均修復時間と訳されます。 ただし、この略語の R が何を指すかには複数の解釈があり、同じ「MTTR」という名前でも、組織や文書によって測っている範囲が違います。 さらに、この指標を Four Keys の一つとして広めた DORA は、現在は MTTR という名前を使っていません。 この記事では、解釈の違い、DORA での扱いの変遷、測るときの落とし穴を整理します。
R の4つの解釈
MTTR の R には、少なくとも4つの読み方があります。
- Repair（平均修理時間）：修理作業の開始から完了まで。ハードウェア保守に由来する最も古い用法
- Recovery / Restore（平均復旧時間）：障害の発生からサービスの復旧まで。ソフトウェア運用で最も一般的な用法
- Resolve（平均解決時間）：復旧に加え、再発防止までを含む
- Respond（平均対応時間）：検知から対応まで。検知にかかった時間を含めない
周辺には、MTTA（Mean Time To Acknowledge、発報から認知までの時間）や MTBF（Mean Time Between Failures、故障から次の故障までの間隔）といった関連指標もあります。
実務で問題になるのは、この揺れが会話の中で表面化しないことです。 「MTTR は4時間です」という報告は、発生からか検知からか、復旧までか恒久対応までかで意味がまったく変わります。 数字を会話に載せる前に、起点と終点をどこに置くかを合意しておく必要があります。
DORA 指標としての変遷
開発生産性の文脈で MTTR と呼ばれてきたのは、DORA の Four Keys に含まれていた「サービス復旧時間（Time to restore service）」です。 障害が起きてからサービスが復旧するまでの時間として、長らく4指標の一つでした。
現在の DORA は、この指標を失敗デプロイの復旧時間（Failed deployment recovery time）に置き換えています。 対象が「あらゆる障害からの復旧」から「失敗したデプロイからの復旧」に絞られました。 インフラの故障や外部サービスの障害まで含む従来の範囲では、開発チームのデリバリ能力というより運用全体の性能を測ってしまうためです。 Four Keys はソフトウェアデリバリの指標群なので、チーム自身のデプロイに起因する失敗に限定するほうが軸が揃う、という整理です。
あわせて、カテゴリも安定性側からスループット側へ移りました。 リードタイムが短いチームは、特別な緊急手順がなくても通常のパイプラインで修正を流せるため、復旧の速さは安定性の性質というよりデリバリ能力の性質だ、という理屈です。 この変遷の全体像はFour Keys の2026年版の解説記事にまとめています。
一般語としての MTTR（サービス全体の復旧時間）が不要になったわけではありません。 運用性能の指標として、SLO やインシデント管理の文脈では引き続き使われます。 Four Keys という枠組みの中の指標ではなくなった、というだけの話です。
「平均」という集計の罠
MTTR には、定義の揺れとは別に、統計としての問題が指摘されています。
復旧時間の分布は長い裾を持ちます。 大半のインシデントは数分から数十分で収束する一方、ごく少数の大規模障害だけが数時間から数日かかる、という形です。 この形の分布では、平均値は少数の大障害に支配され、「典型的なインシデント」を表しません。 公開されたインシデント事例を収集している米国のデータベース（VOID）のレポートでも、復旧時間のばらつきの大きさから、平均を単一の代表値として使うことへの疑義が示されています。
実務では、平均の代わりに中央値やパーセンタイル（たとえば90パーセンタイル）で見る、重大度別に分けて見る、という扱いが安全です。 また、月あたりのインシデント件数が少ない組織では、大障害1件で数字が大きく動くため、単月の増減を評価に使わないほうがよいでしょう。
測るときの決め事
MTTR の計測はインシデント管理の記録が土台になるため、Four Keys の中では測る準備の負担が大きい指標です。 記録を取り始める前に、次の3点を固定しておきます。
- 起点：発生時刻か、検知時刻か、起票時刻か。発生時刻は後からしか分からないことが多く、実務では検知または起票を起点にする場合が多い
- 終点：サービスの復旧か、恒久対応の完了か。復旧を終点にするのが Four Keys 系の用法
- 対象：全インシデントか、デプロイ起因のみか。DORA の現行定義に合わせるならデプロイ起因のみ
復旧を速くする打ち手
復旧までの時間は、検知、診断、修正の反映という3つの区間に分けられます。 打ち手も区間ごとに違います。
- 検知：監視と通知の整備。ユーザーからの問い合わせで障害に気づいている状態なら、まずここに手を入れる
- 診断：ログやトレースといった可観測性の整備。デプロイが小さいほど「直前に何を変えたか」の候補が絞れるため、原因特定は速くなる
- 修正の反映：ロールバック手順の整備と、修正を速く本番に届けられるパイプライン。この区間の能力は変更のリードタイムそのもの
診断と反映の区間を見ると分かるとおり、復旧の速さはスループット系の能力と地続きです。 デプロイ頻度と変更のリードタイムの改善が、そのまま復旧時間の短縮に効きます。
注意点
MTTR が短いことは、信頼性が高いことの証明にはなりません。 障害が頻発していても、毎回すぐ戻せていれば MTTR は短く出ます。 発生側の指標（変更障害率や MTBF）と対で見て、初めて全体像になります。
また、評価指標にすると、復旧の宣言を早める動機や、軽微なインシデントを起票しない動機が生まれます。 起票されないインシデントは計測から消えるため、数字が良くなったように見えて、実際には観測を失っているだけという状態になります。
関連して読める記事
MTTR（失敗デプロイの復旧時間）は、Four Keys の他の指標と組み合わせて初めて全体像になります。枠組みの現行定義から押さえたい方は、2026年版の解説からどうぞ。
Four Keys はもう「4つ」ではない — 2026年版 DORA メトリクスの現在地と、AI導入の効果を証明する唯一の方法
「Four Keys は4つ」という理解は2026年時点では古く、DORA公式の指標は5つに増え、Elite/High/Medium/Lowのランク分けも廃止されています。5つ目は広く誤解されている「信頼性」ではなくデプロイ手戻り率であること、Googleのfourkeys OSSがアーカイブ済みで主要ツールもいまだ4指標止まりであること、そして手戻り率だけはツールなしで今日から測れることを、DORA公式ドキュメントで裏を取りながら整理します。AI導入の効果を数字で証明するための使い方までまとめました。
2026年7月27日
開発生産性とは？測り方の全体像と、指標選びで失敗しない考え方
開発生産性とは、開発組織が投入した人と時間に対して、どれだけ速く確実に価値のあるソフトウェアを届けられているかを表す概念です。行数計測が失敗する理由、Four Keys、SPACE、DevExの使い分け、測り始める5つの手順、指標を個人評価に使ってはいけない理由までを総論として整理します。
2026年7月28日
デプロイ頻度とは？DORAが定義する測り方と、頻度が高いほど安全になる理由
デプロイ頻度とは、開発チームが本番環境へどれくらいの頻度でリリースしているかを測るDORAのFour Keys指標です。定義と測り方、頻度が高いほどデプロイが安全になる理由、ランク分け廃止後の正しい比較のしかた、目標化してはいけない理由までを整理します。
2026年7月28日
変更のリードタイムとは？コミットから本番までを測るDORA指標と短縮の順序
変更のリードタイムとは、コミットから本番デプロイまでの時間を測るDORAのFour Keys指標です。なぜ起点が企画ではなくコミットなのか、レビュー待ちとデプロイ待ちに分解する見方、中央値で測る理由、短縮に取り組む順序までを実務目線で整理します。
2026年7月28日
変更障害率とは？デプロイの失敗割合を測るDORA指標の定義と下げ方
変更障害率（変更失敗率）とは、本番デプロイのうち直後に障害や緊急対応を引き起こした割合を測るDORAのFour Keys指標です。定義と測り方、速さと品質がトレードオフにならない理由、デプロイ手戻り率との違い、ゼロを目指してはいけない理由までを整理します。
2026年7月28日