IT-BCPとは BCPとの違いと策定5ステップ・RTOの決め方と対策の具体例

「基幹システムが止まったら、何日で復旧できるのか」。経営層や取引先からこう問われて、即答できる企業は多くありません。

IT-BCPは、災害やサイバー攻撃でITシステムが停止しても、業務を継続または早期に復旧させるための計画です。情報システムBCPとも呼ばれます。

近年、必要性が急速に高まっています。業務のIT依存度が上がる一方で、ランサムウェアによるシステム停止のように、自然災害以外の要因でも長期間止まる事態が現実に起きているためです。

この記事では、BCPとの違いを整理したうえで、押さえるべき指標、策定の5ステップ、具体的な対策、そして参考にできる公的資料までを順に扱います。

確認したいポイント	結論	詳細
IT-BCPとは？	ITに絞った事業継続計画	災害やサイバー攻撃でシステムが止まっても、業務を継続・早期復旧するための計画です。
BCPとの違いは？	対象がITシステムに限られる	BCPは事業全体、IT-BCPはサーバーやデータなどITの継続性に絞って計画します。
最初に決めることは？	重要業務とRTO（目標復旧時間）	どの業務を何時間以内に戻すかを決めないと、対策の水準が決まりません。
よくある失敗は？	文書を作って終わりになる	訓練で検証しないと機能しません。バックアップから復元できるかの確認も必須です。

この記事でわかること

• IT-BCPの位置づけと、BCPおよび災害対策（DR）との違い
• RTO、RPO、MTPDという3つの指標の意味と決め方
• 基本方針の策定から文書化・周知までの5ステップ
• バックアップ、冗長化、代替手段など具体的な対策の選び方
• 無償で使える公的資料と、中小企業での現実的な進め方

システム開発とAI活用の進め方をまとめた資料を無料で配布しています どこから着手すべきかの見極め方、社内で進めるための手順、費用の目安を1冊にまとめました。 社内での検討材料としてご活用いただけます。 ＞ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

IT-BCPとは

IT-BCPは、Information Technology – Business Continuity Planの略です。情報システムに焦点を絞った事業継続計画を指します。

地震や水害といった自然災害、サイバー攻撃、システム障害が起きても、ITシステムの運用を続けるか、早期に復旧させるための取り決めを事前に定めておくものです。

BCPとの違い

違いは対象範囲です。BCPは企業活動の全体を対象にしますが、IT-BCPはサーバー、ネットワーク、データといったITシステムの継続性に絞ります。

BCPでは、人員の安全確保、代替拠点の確保、資金の手当て、取引先への対応といった幅広い項目を扱います。その中のIT部分を詳細化したのがIT-BCPという関係です。

両者は整合していなければ意味がありません。全社BCPで「受注業務を24時間以内に再開する」と定めているのに、IT-BCPの復旧目標が72時間では、計画として成立しません。

災害対策（DR）との違い

混同されやすい言葉として、DR（ディザスタリカバリ）があります。DRは被災したシステムを復旧させるための技術的な仕組みを指します。

遠隔地へのデータ複製、待機系サーバーの用意、クラウドへの切り替え。こうした手段がDRの中心です。

IT-BCPはより広い概念で、DRの仕組みに加えて、誰がどう判断するか、代替手段で業務をどう回すか、関係者へどう連絡するかまでを含みます。技術だけでなく、運用と体制を含めた計画という違いです。

対象に含めるべきもの

対象範囲を絞りすぎると、実際の緊急時に機能しません。最低限含めるべきものがあります。

• 業務の中核システム：受発注、生産管理、会計など、止まると業務が回らないもの
• 情報共有・連絡手段：メール、チャット、社内ポータル
• 認証基盤：各システムへログインするための仕組み
• ネットワークとインターネット接続
• データとそのバックアップ

認証基盤を見落とすと、他のシステムが動いていても誰もログインできません。連絡手段も同様です。緊急時の活動そのものを支える資源であるため、優先度を高く置きます。

なぜ必要なのか

「うちには必要ない」という判断が難しくなっている背景を整理します。

業務のIT依存度が上がっている

受発注、在庫管理、請求、勤怠、顧客対応。かつて紙や電話で回せた業務が、いまはシステムなしでは進みません。

システムが1日止まれば、受注も出荷も止まります。売上が立たないだけでなく、取引先への納品遅延という形で信用にも影響します。

復旧までの時間が長引くほど、損失は加速度的に増えます。数日の停止で、事業そのものが立て直せなくなる可能性もあります。

リスクが自然災害だけではない

BCPというと地震や水害を想定しがちですが、IT-BCPで想定すべきリスクはもっと広い範囲に及びます。

• ランサムウェア：データが暗号化され、業務が数週間止まる事例が発生している
• クラウドサービスの障害：自社に問題がなくても、利用サービスが止まれば業務は止まる
• 機器の故障：サーバーやストレージの物理的な故障
• 人的ミス：誤操作によるデータ削除、設定変更による障害
• 停電とネットワーク断絶

特にランサムウェアの影響は大きくなっています。バックアップまで暗号化されると、復旧手段が失われます。自然災害とは異なる備えが必要です。

IPA（情報処理推進機構）は重要インフラ分野のシステム障害への対策の取り組みとして、報道された情報システムの障害情報を蓄積し、そこから得られた教訓を分野を越えて共有することで類似障害の再発防止につなげる活動を進めています。他社の事例から学べる領域です。

取引先から求められることがある

見落とされやすい動機です。大手企業との取引において、BCPの策定状況を確認されるケースが増えています。

サプライチェーン全体の継続性が重視されるようになり、自社が止まることで取引先の事業も止まるという認識が広がっているためです。

入札や新規取引の要件として問われることもあります。この場合、計画の有無そのものが商機に影響します。

押さえるべき3つの指標

IT-BCPの議論は、この3つの用語を共有していないと進みません。いずれも「いつまでに」「どこまで」を数値で表すものです。

RTO｜目標復旧時間

Recovery Time Objectiveの略です。障害発生から、システムを復旧させるまでの目標時間を表します。

「受発注システムのRTOは8時間」と定めれば、停止から8時間以内に使える状態に戻すことが目標になります。この数値が、必要な対策の水準を決めます。

RTOを短くするほど、対策の費用は上がります。数時間で戻すには待機系の設備が必要ですが、3日でよいなら別の手段が取れます。費用と業務要件の折り合いをつける指標です。

RPO｜目標復旧時点

Recovery Point Objectiveの略です。どの時点のデータまで復旧させるか、つまり許容できるデータ損失の範囲を表します。

「RPOは24時間」であれば、最大で1日分のデータが失われることを許容するという意味です。バックアップを1日1回取っている場合、これがRPOになります。

RTOとRPOは別の指標です。混同されやすいので区別します。RTOは「いつまでに動くか」、RPOは「どこまでのデータが残るか」です。

【時間の流れと2つの指標】

(1) バックアップ取得

(2) 障害発生　　　 ← (1)から(2)までが RPO（失うデータ）

(3) 復旧完了　　　 ← (2)から(3)までが RTO（停止する時間）

MTPD｜最大許容停止時間

Maximum Tolerable Period of Disruptionの略です。これ以上停止が続くと事業が致命的な影響を受ける、という限界の時間を表します。

RTOは目標、MTPDは限界という関係です。RTOはMTPDより短く設定する必要があります。ここが逆転していれば、計画は成立していません。

MTPDは業務部門と経営層が決めるものです。「3日止まったら主要顧客を失う」という判断は、IT部門だけでは下せません。

指標の決め方

業務部門へのヒアリングから始めます。「このシステムが止まったら、何日で業務が回らなくなるか」を聞き取ります。

システムごとに数値を置きます。全システムを同じ水準にする必要はありません。受発注は8時間、社内ポータルは3日といった差をつけるのが実務的です。

現在の実力も測っておきます。対策を打たない状態で何時間かかるのかを把握すれば、目標との差が必要な投資の規模になります。

策定の手順｜5ステップ

文書を書くこと自体は最後の工程です。その前の分析に時間を使います。

ステップ1｜基本方針と体制を決める

最初に、対象範囲と達成すべき目標を経営層の承認のもとで定義します。どのシステムを対象とするかを明確にします。

あわせて体制を整えます。全体の責任者、各システムの復旧担当者、その代理者を指名します。誰が最終判断をするのか、どのタイミングで経営層へ報告するのかという意思決定の流れも決めておきます。

中小企業であれば、少人数の体制でも機能します。組織の規模に見合った体制にすることが重要で、大企業向けの体制を無理に真似る必要はありません。

ステップ2｜重要業務とシステムを特定する

すべてを守ろうとすると、何も守れません。優先順位をつけることが、この工程の目的です。

まず、事業の中核となる業務を洗い出します。売上への影響、取引先への影響、法令上の義務という観点で判断します。次に、その業務を支えているシステムを特定します。

システムの依存関係も整理します。認証基盤が止まれば全システムが使えない、といった関係を把握しておかないと、復旧の順序を決められません。業務の棚卸しの進め方は業務効率化アイデア55選｜部門別30＋AI15＋明日から3つで成果を出す方法も参考になります。

ステップ3｜リスクと影響を分析する

想定するリスクを洗い出し、それぞれが発生した場合の影響を評価します。

リスクの洗い出しは、IT部門だけで行わないほうが実効性が上がります。各部署の担当者から意見を聞くと、現場で実際に起きている問題が見えてきます。

影響の評価には、時間軸を入れます。「1時間止まった場合」「1日止まった場合」「1週間止まった場合」で、被害の大きさがどう変わるかを整理します。これがMTPDの根拠になります。

ステップ4｜目標と対策を決める

システムごとにRTOとRPOを設定し、それを達成するための対策を選びます。

ここで費用との折り合いをつけます。目標が厳しければ対策の費用は上がります。投資に見合わない場合は、目標そのものを見直すという判断もあります。

復旧手順も併せて具体化します。「バックアップから戻す」の一文では手順書になりません。どのファイルを、どこから、どのコマンドで戻すのかまで記載します。

ステップ5｜文書化して周知する

決めた内容を文書にまとめます。緊急時に読める形にすることが要件です。

分厚い文書は緊急時に使えません。判断と初動に必要な情報を数ページにまとめた部分を先頭に置き、詳細は別冊にする構成が実務的です。

保管場所も重要です。社内サーバーだけに置いていると、そのサーバーが止まったときに読めません。印刷した冊子、外部のクラウド、担当者の手元など、複数の場所に用意します。

対象範囲や復旧目標の設定からご相談いただけます 手順は分かっても、自社のどこから手をつけるかの判断は別の問題です。 業務とシステムの棚卸しからご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

具体的な対策

対策の選択肢を知っておくと、RTOとRPOの設定が現実的になります。

データのバックアップ

最も基本的で、最も費用対効果の高い対策です。ただし「取っている」だけでは不十分です。

確認すべきは3点あります。取得の頻度がRPOを満たしているか、保管場所が本番と物理的に分かれているか、そして実際に復元できるかです。

ランサムウェア対策としては、ネットワークから切り離した保管が重要になります。同じネットワーク上にあるバックアップは、一緒に暗号化される可能性があります。書き換えできない形式での保管も有効です。

システムの冗長化とクラウド活用

機器の故障に備えて、予備を用意するという対策です。サーバーやストレージ、ネットワーク機器を二重化します。

遠隔地に待機系を置けば、拠点が被災しても切り替えられます。ただし費用は高くなります。RTOが数時間という要件でなければ、ここまでは不要な場合もあります。

クラウドの利用は、IT-BCPの観点では有利に働くことが多くあります。データセンターが分散しており、自社で設備を維持する必要がないためです。一方で、サービス自体の障害に備える必要は残ります。

代替手段の用意

システムが復旧するまでの間、業務をどう回すかという観点です。技術的な対策と並んで重要になります。

紙の伝票で受注を受ける、表計算ソフトで一時的に管理する、電話とFAXで連絡を取る。原始的に見えても、実際に機能する手段を用意しておきます。

復旧後にデータをシステムへ取り込む手順も決めておきます。代替手段で溜まったデータを、どう入力し直すかを考えておかないと、復旧後に別の混乱が起きます。

連絡体制と情報共有

緊急時に最初に必要になるのは、連絡がつくことです。ここが機能しないと、何も始まりません。

社内の連絡先一覧、ベンダーの緊急連絡先、取引先への連絡ルート。これらを社内システムに依存しない形で保持します。印刷して各担当者が持つという原始的な方法が、実は最も確実です。

ベンダーの夜間休日の対応可否も確認しておきます。契約上、平日日中のみの対応であれば、それを前提に計画を立てる必要があります。委託先との体制についてはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方でも触れています。

サイバー攻撃への備え

自然災害とは対策が異なる部分です。侵入を前提とした備えが必要になります。

検知の仕組み、被害範囲を限定するためのネットワーク分離、侵害時の初動手順。加えて、攻撃を受けた場合の外部への報告義務も確認しておきます。

復旧を急いで再感染させるという事例もあります。原因を特定せずにバックアップから戻すと、同じ脆弱性が残ったままになります。調査と復旧の順序を手順に含めます。

参考にできる公的資料

ゼロから考える必要はありません。無償で使える資料が公開されています。

中小企業庁の策定運用指針

中小企業庁が公開している中小企業BCP策定運用指針は、中小企業へのBCPの普及促進を目的に作成されたもので、策定と継続的な運用の具体的な方法が説明されています。

特徴的なのは、投入できる時間と労力に応じて4通りのコースが用意されている点です。入門コースから上級コースまであり、自社の状況に合わせて選べます。小規模事業者を含めた初心者を想定した入門コースも設けられています。

取組状況を診断するチェックリストも含まれています。設問に「はい」「いいえ」で答えることで、現在の事業継続能力の水準が分かります。まずここから着手するのが最短の入口です。

自社に合った粒度を選ぶ

公的資料は網羅的に作られているため、すべてに取り組もうとすると挫折します。

従業員10名の企業が、大企業向けの詳細な計画を真似る必要はありません。A4で数ページの計画でも、訓練して機能するなら価値があります。

中小企業庁の2025年版中小企業白書では、DXに向けた取り組みを進めるうえでの問題点として、費用の負担が大きいことと推進する人材が足りないことが高い割合で挙げられています。限られた資源で何を優先するかという視点が欠かせません。

業界固有の資料も確認する

業種によっては、所管する省庁や業界団体が固有の指針を出していることがあります。金融、医療、建設、下水道など、分野ごとの資料が公開されています。

規制業種であれば、法令上求められる水準が定められている場合もあります。自社の業界に該当する資料があるかを最初に確認しておきます。

よくある失敗

計画があるのに機能しないというパターンには、共通の原因があります。

文書を作って終わりになる

最も多い失敗です。策定が目的になり、作った後の検証が行われないという状態です。

取引先から求められて急いで作った、認証を取得するために形だけ整えた。こうした経緯で作られた計画は、緊急時に開かれることさえありません。

対策は訓練を予定として組み込むことです。年1回でも実施日を決めておけば、計画は見直されます。次章で扱います。

全社BCPと整合していない

IT部門だけで策定した計画に起こりがちです。ITシステムを復旧させても、他部門の業務が再開できなければ事業は継続できません。

全社BCPで定めた事業継続目標と、IT-BCPのRTOが一致しているかを確認します。ずれていれば、どちらかを調整します。

IT部門、経営層、各部署が連携する場を設けることが前提です。策定段階から業務部門を巻き込んでおかないと、後から整合を取るのは困難になります。

復旧手順が担当者の頭の中にある

計画書には「復旧する」と書かれているが、具体的な手順は特定の担当者しか知らないという状態です。

緊急時にその担当者が出勤できるとは限りません。連絡がつかない可能性もあります。担当者が不在でも復旧できる状態を目指します。

対策は手順書の作成です。コマンド、設定値、接続情報、確認方法を記載します。別の担当者が読んで実施できるかをレビューで確認します。

バックアップから戻せない

意外に多い失敗です。バックアップは取っているが、復元を試したことがないというケースです。

取得できていると思っていたデータが実は欠けていた、復元に想定の3倍の時間がかかった、必要な権限が不足していた。いずれも実際に試して初めて分かります。

定期的に復元テストを行うことが唯一の対策です。年に1回でも実施すれば、机上では見つからない問題を発見できます。

訓練と見直し

計画は運用して初めて意味を持ちます。策定後の取り組みを整理します。

訓練の種類

負荷の軽いものから重いものまで、段階があります。最初は読み合わせから始めれば十分です。

• 読み合わせ：関係者が集まり、計画書を声に出して確認する。最も手軽
• 机上訓練：想定シナリオを提示し、各自が何をするかを口頭で確認する
• 部分訓練：バックアップからの復元、連絡手段の確認など、個別に実施する
• 実地訓練：実際に切り替えや復旧作業を行う。最も負荷が高い

読み合わせだけでも、多くの問題が見つかります。「その担当者は退職している」「その連絡先は変わっている」といった指摘は、この場で出てきます。

見直しの頻度

年1回の見直しを基本にします。加えて、次の変化があった場合は随時見直します。

システムの入れ替えや新規導入、担当者の異動、拠点の移転、ベンダーの変更、業務の大きな変更。いずれも計画の前提を変えるものです。

訓練で見つかった課題も反映します。訓練の目的は課題を見つけることであり、うまくいかなかったこと自体は問題ではありません。

中小企業での現実的な進め方

完璧な計画を目指さないことが、続けるための条件です。

まず、重要なシステムを1つ選び、それだけのRTOとRPO、復旧手順を決めます。A4で2ページでも構いません。バックアップから戻せるかを1回試します。ここまでで、備えの水準は大きく変わります。

範囲を広げるのは次の年で構いません。何もない状態と、1システム分でもある状態の差が最も大きいためです。

社内に知見がない場合は、外部の支援を組み合わせる方法もあります。進め方の相談はシステム開発｜AIを活用した開発支援で受け付けています。

まとめ

IT-BCPは、災害やサイバー攻撃でITシステムが停止しても業務を継続・早期復旧させるための計画です。BCPが事業全体を対象にするのに対し、ITシステムの継続性に絞ります。

押さえるべき指標は、RTO（いつまでに復旧するか）、RPO（どこまでのデータを守るか）、MTPD（何時間までなら耐えられるか）の3つです。RTOはMTPDより短く設定します。

策定は5ステップです。基本方針と体制、重要業務とシステムの特定、リスクと影響の分析、目標と対策の決定、文書化と周知。分析に時間を使い、文書化は最後という順序です。

最も多い失敗は、作って終わりになることです。年1回の読み合わせと、バックアップからの復元テストを予定に組み込むことが、計画を機能させる条件になります。

まずは中小企業庁のチェックリストで現状を診断してみてください。そのうえで、最も重要なシステム1つについて復元テストを行うところから始めるのが、最短の一歩になります。

IT体制の見直しから、無料で相談できます 取引先から策定を求められている、社内にIT体制の知見がなく不安があるといった段階のご相談も承っています。 営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎