RTOって何？わかりやすく解説

会社のパソコンや使ってるアプリが突然動かなくなった！なんてこと、大人になると意外とよく起きるんだよ。そのとき「いつまでに直せばいいの？」って基準が決まってないと、みんな大パニックになっちゃう。その「いつまでに」を決めるのがRTOっていう考え方で、この記事を読めばどういうことかバッチリわかるよ。

RTOは「Recovery Time Objective」の略で、日本語だと目標復旧時間って言うよ。つまり「システムやサービスが止まったとき、何時間以内に元通りにするか」という目標のことだよ。たとえばネットショッピングのサイトが壊れたとして、「4時間以内に復旧させる！」って決めたなら、それがRTO＝4時間ってわけ。

サービスが止まると、会社はどんどんお金を失っていくんだよ。たとえばコンビニのレジが止まったら、お客さんは買い物できないよね。1時間で10万円の損失が出るとしたら、「絶対に2時間以内に直す！」ってRTOを決めておくと、みんながその目標に向かって動けるんだ。あらかじめ目標を決めておくことで、パニックにならずに素早く動けるってわけ。

いい質問！RPOは「Recovery Point Objective（目標復旧時点）」、つまり「どこまでのデータを取り戻せればOKか」という目標だよ。RTOが「いつまでに直すか＝時間の長さ」なのに対して、RPOは「どこまで巻き戻っていいか＝データのロス許容量」の話。セットで使われることが多いから、一緒に覚えておくといいよ。

そう思いがちだけど、実はそうじゃないんだよ。RTOを短くするためには、バックアップサーバーを増やしたり、自動で切り替わるシステムを用意したりと、お金がたくさんかかるんだ。だから「どのくらいのコストをかけて、どのくらいのスピードで復旧できればビジネスへの影響が許容範囲か」を考えながら決めるのが大事なんだよ。

もうちょっと詳しく

RTOはIT・システムの世界だけじゃなく、BCP（事業継続計画）、つまり「災害や事故が起きてもビジネスを続けるための計画」の中でも中心的な役割を持っている言葉だよ。たとえば地震や火事でオフィスが使えなくなったとき、「何時間以内に業務を再開するか」というRTOを決めておけば、従業員みんなが何をすべきかわかる。システム担当者だけじゃなく、経営者や現場のマネージャーも「うちのRTOは何時間か」を知っておく必要があるんだ。特にネット通販・金融・医療など、止まったら大きな損害が出る業種ほどRTOの設定はシビアで、数分・数秒単位で管理しているところもあるよ。逆に社内の資料共有システムなら「1日以内でいいかな」という場合もある。要はどのシステムがどれだけ大事かによって、RTOの数値は変わってくるんだよ。

⚠️ よくある勘違い

[toc]

RTOとは？まずは基本をおさえよう

RTOの正式名称と意味

RTOは「Recovery Time Objective」の頭文字を取った言葉で、日本語では目標復旧時間と訳されるよ。「復旧」というのはつまり「壊れたり止まったりしたものを元に戻すこと」で、「目標時間」は「このくらいの時間でやり遂げよう」という基準のこと。合わせると「問題が起きたとき、○時間以内に元通りに戻すことを目指す」という意味になるんだ。

たとえば学校の給食システムがバグって使えなくなったとき、「2時間以内に直さないと給食の注文が間に合わない！」という状況を想像してみて。この「2時間以内」という基準がRTOだよ。事前にこの基準を決めておくことで、システム担当者は「2時間で直す」という目標に向かって行動できる。何の基準もなければ「とりあえず頑張ります…」になっちゃうよね。

RTOが登場する場面

RTOは主に以下のような場面で使われるよ。

• ITシステムの障害対応：サーバーが落ちた、ソフトウェアにバグが出たなど
• 自然災害・事故への備え：地震・火災・停電でシステムや拠点が使えなくなった場合
• クラウドサービスの契約：「障害時はRTO〇時間で対応します」とベンダーが約束する場合
• セキュリティインシデント：サイバー攻撃を受けてシステムが止まったとき

どの場面でも「いつまでに元に戻すか」という目標を決めるためにRTOが登場するんだよ。

なぜRTOを決めておく必要があるの？

システムが止まると損害が出る

会社にとってシステムが止まることは、お店のシャッターが突然閉まるのと同じくらい深刻な問題だよ。ネットショッピングのサイトが1時間止まれば、その間に買い物できなかったお客さんの分だけ売上が消える。銀行のATMが止まれば、お客さんはお金を引き出せなくて大混乱になる。医療システムが止まれば、患者の情報が確認できなくて治療に影響が出るかもしれない。

こういった損害を最小限にするために、「何時間以内に直す」という目標＝RTOを事前に決めておくことがとても重要なんだ。RTOがないと、いざトラブルが起きたとき「どのくらいで直せばいいの？」「どこまで急ぐべき？」という判断ができずに時間を無駄にしてしまうよ。

チームが一丸になれる

RTOを決めておくもう一つのメリットは、チーム全員が同じ目標に向かって動けること。たとえばRTO＝4時間と決まっていれば、エンジニアは「4時間で直す方法」を考え、上司は「4時間で直せるよう人員やお金を手配する」という判断ができる。RTOという共通の数字があることで、バラバラだった行動がまとまるんだよ。

サッカーで言えば、「今日の試合は2点以内に抑えて勝つ」という目標があるのとないのとでは、チームの動き方が全然変わるよね。それと同じ感覚で、RTOはトラブル対応チームにとっての「試合の目標スコア」みたいなものなんだ。

RTOの決め方：何を基準にする？

ビジネスへの影響度で考える

RTOを決めるときに一番大事なのは「このシステムが止まると、どのくらいビジネスに影響するか」を考えることだよ。影響が大きいシステムほど、RTOを短く設定しておく必要がある。逆に、止まってもすぐには困らないシステムなら、RTOは長くてもOKな場合が多いよ。

具体的にはこんなふうに考えるよ：

• 決済システム：止まると1分単位でお金が消えていく → RTO＝数分〜1時間以内
• 顧客管理システム：止まると営業活動ができない → RTO＝数時間以内
• 社内の勤怠管理システム：止まっても給与計算は翌日でもOK → RTO＝24時間以内
• 社内アーカイブシステム：古い資料の倉庫的な用途 → RTO＝数日以内でも許容範囲

このように、同じ会社の中でもシステムごとにRTOは変わってくるんだよ。すべてに短いRTOを設定すると、それだけお金がかかるから、「本当に大事なところ」に集中してRTOを短くするのが現実的な考え方だよ。

コストとのバランスが超重要

RTOを短くするためには、それだけの「準備コスト」が必要になるよ。たとえばRTO＝0分（瞬時に復旧）を目指すなら、全く同じシステムをもう一台常に動かしておいて、一方が壊れたら即座に切り替えるような仕組みが必要。これを冗長化（じょうちょうか）、つまり「バックアップをたくさん用意してリスクを分散すること」と言うよ。こういった設備はとても高額なんだ。

一方でRTO＝24時間なら、毎日夜中にバックアップを取っておいて、翌日までに復旧させるだけでいいから、コストはぐっと下がる。つまり「早く直したいほどお金がかかる」というトレードオフ（どちらかを取るともう一方が犠牲になる関係）があるんだよ。だから経営者やシステム担当者は、「どのくらいの損失までなら許容できるか」を考えながら、コストと復旧速度のバランスを取って決めるんだ。

RTOと一緒に覚えたいRPOの違い

RPOとは何か

RTOとよく一緒に使われる言葉にRPO（Recovery Point Objective：目標復旧時点）があるよ。RTOが「いつまでに直すか＝時間の長さ」を表すのに対して、RPOは「どの時点のデータまで取り戻せればOKか＝データの損失許容量」を表しているよ。

スマートフォンのゲームで例えると、こんな感じ：

• ゲームデータがバグで消えてしまった
• RTO：「3時間以内にゲームをまた遊べる状態にしてほしい」
• RPO：「昨日時点のセーブデータまで戻れれば、今日分は諦める」

RTOは「時間軸で見た復旧の速さ」、RPOは「データ軸で見た復旧の深さ」と考えると整理しやすいよ。

RTOとRPOを組み合わせて考える

実際のシステム設計では、RTOとRPOをセットで決めることが多いよ。たとえば「RTO＝4時間、RPO＝1時間」と決めた場合、「4時間以内にシステムを復旧させ、過去1時間以内のデータは失っても許容する」という意味になる。この2つの数値をセットで管理することで、システムの回復力（レジリエンス）、つまり「問題が起きても跳ね返る強さ」を具体的な数字で表現できるんだよ。

RPOを短くするには、バックアップの頻度を上げる必要があるから、これもまたコストがかかる。RTOとRPOの両方を短くしようとすると費用がどんどん膨らむので、どちらも現実的な数字に落とし込む判断力が大事になってくるんだ。

RTOを実現するための仕組み

バックアップと復旧テスト

RTOを達成するための基本はバックアップだよ。バックアップとはつまり「データや設定を定期的にコピーしておくこと」。バックアップがあれば、システムが壊れたときにそこから復元できる。ただしバックアップを取るだけじゃダメで、「本当に設定した時間内に復旧できるか」を定期的にテストすることが重要なんだよ。

実は多くの会社が「バックアップは取ってるけど、復旧テストはしていない」という状態になっている。いざ本番でシステムが壊れたとき、「バックアップから戻そうとしたら手順を間違えて2倍の時間がかかった」なんてことも起きる。だから日頃から復旧訓練を行って、RTOの目標時間内に本当に動けるかを確かめることが大事なんだ。

フェイルオーバーとホットスタンバイ

より短いRTOを実現するための技術的な手段として、フェイルオーバーという仕組みがあるよ。これはつまり「メインのシステムが壊れたとき、自動的に予備のシステムに切り替える仕組み」のこと。自動で切り替わるから、人が気づいて手動で対応するより圧倒的に速い。

さらに高度なのがホットスタンバイ。これは「予備システムを常に本番と同じ状態で動かしておく」方法で、切り替えがほぼ瞬時に完了する。新幹線で例えると、万が一のために常にもう一両の動力車を連結して走っているようなイメージだよ。当然コストは高いけど、それだけRTOをゼロに近づけられる技術なんだ。

クラウドを活用したRTOの短縮

最近はクラウド（インターネット経由でコンピューターの機能を使うサービス）を使うことで、比較的低コストでRTOを短縮できるようになってきているよ。クラウドなら、必要なときだけ予備のサーバーを立ち上げることができるし、地理的に離れた場所にデータのコピーを置いておくことも簡単にできる。たとえば東京のサーバーが地震で止まっても、大阪のサーバーにすぐ切り替えられるような設計も、クラウドなら比較的手軽に実現できるんだ。

AWSやGoogle Cloud、Azureといった大手のクラウドサービスは、こういったRTO短縮のための機能を豊富に提供しているよ。現代のITシステムでは「クラウドを使って、どのくらいのRTOを実現するか」がシステム設計の重要なテーマになっているんだ。