はじめに:なぜこの4つの言葉を知っておくべきなのか
空子/情報セキュリティマネジメント担当私たちの生活は、今やITシステムなしには成り立ちません。スマホで銀行振込をする、ネットショッピングで買い物をする、会社の業務システムで仕事をする。こうしたサービスの裏側では、常にサーバーやネットワークが動いています。
しかし、システムは永遠に動き続けるわけではありません。機械である以上、いつかは故障します。地震や停電といった災害で止まることもあります。そんなとき、「どれくらい早く復旧できるのか」「どこまでデータを守れるのか」「そもそもどれくらいの頻度で壊れるのか」を測るための指標が、今回紹介する MTTR・RTO・RPO・MTBF の4つです。
IT業界では当たり前のように使われるこれらの用語ですが、実は考え方自体はとてもシンプルです。身近な例を使いながら、一つずつ見ていきましょう。
MTBF(平均故障間隔)― 「どれくらい持つの?」





MTBF は「Mean Time Between Failures」の略で、日本語では 「平均故障間隔」 と呼ばれます。ひとことで言えば、「システムが正常に動いている平均的な時間」 のことです。
たとえば、あなたの家の洗濯機が3年に1回壊れるとします。この場合、MTBFは「3年」です。もし10年に1回しか壊れない洗濯機があれば、そちらのMTBFは「10年」。つまり、MTBFの数値が大きいほど「壊れにくい=信頼性が高い」ということになります。
ITの世界でも同じです。サーバーのMTBFが10,000時間なら、平均して10,000時間に1回の割合で故障が起きるという意味です。企業がシステムを導入するとき、「この機器のMTBFはどれくらいか」を確認するのは、まさに「どれくらい安心して使い続けられるか」を見極めるためなのです。
MTBFは 「壊れる前」 の話、つまりシステムの耐久力や信頼性を表す指標だと覚えておきましょう。
MTTR(平均復旧時間)― 「壊れたら何時間で直る?」



MTTR は「Mean Time To Repair」の略で、日本語では 「平均復旧時間」 です。これは、故障が発生してから修理が完了し、再び使えるようになるまでの平均時間 を意味します。
先ほどの洗濯機の例で考えてみましょう。洗濯機が壊れて修理業者を呼んだとき、毎回だいたい2日で直るなら、MTTRは「2日」です。もし別のメーカーの洗濯機はいつも1週間かかるなら、MTTRは「1週間」。当然、MTTRは短いほうが嬉しいですよね。
ITシステムにおいても、MTTRの短さは非常に重要です。たとえばオンラインバンキングのシステムが止まったとき、復旧に5分かかるのか、5時間かかるのかで、利用者への影響はまるで違います。企業はこのMTTRをできるだけ短くするために、予備のサーバーを用意したり、監視体制を強化したり、日頃から訓練を行ったりしています。
MTBFが「壊れる前」の指標なら、MTTRは 「壊れた後」 の指標です。この2つはセットで考えることが多く、「壊れにくくて(MTBF大)、壊れても早く直る(MTTR小)」システムが理想とされます。
RTO(目標復旧時間)― 「何時間以内に復旧させなきゃダメ?」





RTO は「Recovery Time Objective」の略で、日本語では 「目標復旧時間」 と呼ばれます。MTTRが「実際にかかった平均時間」だったのに対し、RTOは 「このくらいの時間で復旧させましょう」というビジネス上の目標値 です。
ここが少しややこしいポイントですが、身近な例で考えればすぐにわかります。
あなたがレストランのオーナーだとしましょう。もしキッチンの冷蔵庫が壊れたら、食材がダメになる前に、遅くとも4時間以内には新しい冷蔵庫を用意するか修理を終えたいですよね。この「4時間以内」がRTOです。
RTOは業務やサービスの重要度によって大きく変わります。たとえば、救急病院の電子カルテシステムなら「RTOは数分」と設定されるかもしれません。一方、社内の掲示板システムなら「RTOは24時間」で十分かもしれません。重要なのは、RTOはあくまで 「目標」 であるということです。実際にその時間内に復旧できるよう、日頃から準備や投資を行う必要があります。
よくある誤解として、「MTTRとRTOは同じもの」と思われがちですが、MTTRは過去の実績に基づく平均値、RTOは未来に向けた目標値という違いがあります。理想的にはMTTRがRTOを下回っている状態を維持することが求められます。
RPO(目標復旧時点)― 「どこまでのデータを守れる?」



RPO は「Recovery Point Objective」の略で、日本語では 「目標復旧時点」 です。RTOが「時間の長さ」を扱うのに対して、RPOは 「どの時点までのデータに戻せるか」 を示す指標です。
これも身近な例で説明しましょう。あなたがパソコンで小説を書いているとします。1時間ごとに自動保存する設定にしていたところ、突然パソコンがフリーズしてしまいました。最悪の場合、直近1時間分の原稿が失われます。この「1時間」がRPOにあたります。
もし「1文字も失いたくない」のであれば、RPOは限りなく「0分」に近い設定が必要です。逆に「まあ昨日の状態に戻れれば大丈夫」という場合は、RPOは「24時間」でよいということになります。
企業のシステムでは、RPOの値によってバックアップの方法が変わります。RPOが「0」に近ければ、リアルタイムでデータを別のサーバーにコピーし続ける必要があります。RPOが「24時間」であれば、1日1回のバックアップで十分です。当然、RPOを短くするほどコストがかかるため、「どのデータにどこまでの保護が必要か」を見極めることが大切です。
4つの指標の関係を整理しよう





ここまでの内容を、時間軸で整理するとスッキリ理解できます。
障害が起きる「前」の指標:
- MTBF:前回の故障から今回の故障までの平均稼働時間。長いほど信頼性が高い。
障害が起きた「後」の指標:
- MTTR:故障してから実際に復旧するまでの平均時間。短いほど優秀。
- RTO:「ここまでに復旧しよう」というビジネス上の目標時間。
- RPO:「ここまでのデータは守ろう」というデータ保護の目標時点。
RTOとRPOは、いわば 「ビジネスが許容できるダメージの限界ライン」 を定めたものです。この2つの目標を達成できるように、バックアップ体制や冗長化の仕組みを整えるのが、IT部門の大きな仕事のひとつです。
日常生活でも使える考え方



実はこの4つの概念は、日常生活にも応用できます。
たとえば、スマホのデータ管理を考えてみてください。「スマホは平均して何年壊れずに使えるか(MTBF)」「壊れたら何日で新しいスマホに移行できるか(MTTR)」「写真やLINEの履歴はどこまで復元したいか(RPO)」「仕事で使うなら何時間以内に代替手段を確保すべきか(RTO)」。こう考えると、クラウドへの自動バックアップの大切さや、予備の連絡手段を持っておくことの意味がよくわかるのではないでしょうか。
まとめ


最後にもう一度、4つの指標を一言でまとめます。
MTBF(平均故障間隔)は、「どれくらいの期間、壊れずに動き続けるか」。信頼性の指標です。
MTTR(平均復旧時間)は、「壊れたあと、どれくらいで直るか」。復旧力の指標です。
RTO(目標復旧時間)は、「いつまでに復旧させなければならないか」。ビジネス上の目標です。
RPO(目標復旧時点)は、「どの時点のデータまで守りたいか」。データ保護の目標です。
システムの世界は複雑に見えますが、これらの指標が伝えたいことはシンプルです。「できるだけ壊れないようにして、もし壊れてもすぐ直せるようにして、大切なデータはちゃんと守ろう」。それを数値で表現し、チーム全体で共有するための道具が、MTTR・RTO・RPO・MTBFなのです。



これらの言葉を知っておくだけで、ニュースで「大規模システム障害」と聞いたとき、あるいは自分の会社でIT担当者と話すとき、ぐっと理解が深まるはずです。










コメント