障害復旧の発注は、委託範囲を決め、発注先と契約形態を選び、発注前の準備を整え、委託後にベンダーを統制する流れで進みます。
24時間365日の監視体制、バックアップからの復旧手順、ランサムウェア被害時の初動対応など、求められる専門性と稼働は膨大です。限られた情報システム部門のリソースでは追いつかないのが実情です。そこで、外部に任せる範囲の決め方から発注先と契約形態、発注前の準備、費用までが、発注で押さえる論点になります。
- 障害復旧の外注範囲と、丸投げ・協働の違い
- 発注先、契約形態、RTO・RPOの決め方
- 構成資料、連絡体制、ベンダー管理
- 費用構造と、発注で失敗しない比較方法
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ITシステム障害復旧を外注する全体像と委託範囲
障害復旧の外注といっても、委託できる範囲は幅広くあります。発注を成功させる第一歩は、自社で抱える領域と外部に任せる領域の線引きを明確にすることです。
外注できる障害復旧業務の種類
障害復旧に関わる外注業務は、大きく4つの層に分けると整理しやすくなります。1つ目は「監視・検知」で、24時間365日の死活監視・リソース監視・ログ監視を代行し、異常を即座に検知します。2つ目は「一次対応・復旧作業」で、検知したインシデントに対して、暫定復旧（サービスを止めないための応急措置）や、予備サーバー・バックアップからのリストアを行います。
3つ目は「DR・バックアップ基盤の構築」で、平時に行う準備業務です。遠隔地へのデータレプリケーション、フェイルオーバー環境の設計、定期バックアップの仕組み化を含みます。4つ目は「事後対応・原因調査」で、根本原因分析（RCA）の実施と再発防止策の立案、障害報告書やポストモーテムの作成支援を担います。
これら4層のうち、どこまでを外部に委ねるかが発注設計の核心です。監視だけを外注して復旧作業は自社、というように層の間に分断ができると、つまずきの元になります。一方、検知から原因調査まで一気通貫で同一ベンダーが担えば、責任の所在が曖昧になりにくく、MTTR（平均復旧時間）の短縮にも直結します。
丸投げ型と協働型の使い分け
障害復旧の外注には、「完全アウトソース（丸投げ型）」と「協働型」の2つのスタンスがあります。丸投げ型は、運用代行ベンダーに監視から復旧まで一括で任せ、自社は報告を受ける立場に徹するモデルです。この型は、情報システム部門が小規模、あるいは存在しない企業に向いていますが、ベンダー依存が強まりすぎると、いざという時に自社で判断できなくなるリスクがあります。
協働型は、ベンダーに実作業を委ねつつ、復旧方針の意思決定や優先順位付けは自社が握るモデルです。障害が事業に直結する基幹システムでは、優先して復旧させるサービスや、許容するデータ損失の範囲は事業側にしか判断できません。そのため、重要システムほど協働型が望ましく、ベンダーには「手」を、自社には「頭」を残す役割分担が有効です。
判断軸はシンプルで、障害が事業継続に与える影響の大きさです。影響が限定的な周辺システムは丸投げで効率化し、止まると事業が立ち行かない中核システムは協働型で握りを残します。この使い分けを発注前に決めておくことが、後悔しない委託の前提になります。
障害復旧の発注先と契約形態の選び方
発注先には複数のタイプがあり、それぞれ得意領域が異なります。また、契約の形態によって責任範囲や費用構造も大きく変わります。
発注先の種類と得意領域
発注先は、タイプごとに得意な範囲と弱い点が分かれます。
- 開発元：システムを開発した元のベンダーです。内部を熟知しているため原因特定が速い反面、開発で手一杯だと運用対応が後手に回る懸念があります。
- MSP（マネージドサービスプロバイダー）：運用保守を専門とし、24時間監視と一次対応に強い一方、システム固有のロジックには弱い場合があります。
- インフラ専門ベンダー：クラウド基盤やインフラの運用代行を得意とし、AWSやAzure上のDR構築に強いです。
- SIerやプロダクト開発会社：開発から運用・復旧までを一気通貫で担える会社です。
インフラ専門ベンダーは、フェイルオーバー設計にも強いため、インフラ起因の障害復旧に向いています。SIerやプロダクト開発会社は、設計思想を理解したうえで復旧体制まで設計できるため、新規システムと並行して委託したい場合に適しています。
どのタイプを選ぶかは、対象システムの性質と既存の保守契約の有無で決まります。既に開発元と保守契約がある場合は、復旧対応をそこに含められるか確認するのが先決です。一方、複数システムを横断して監視・復旧体制を整えたい場合は、MSPやSIerへの一括委託が効率的です。
請負契約と準委任契約の使い分け
障害復旧の委託では、契約形態が責任範囲を左右します。請負契約は「成果物の完成」に責任を負う形態で、特定の障害を期限内に復旧させるといった明確なゴールがある作業に向いています。ただし、障害は原因が事前に読めないことが多く、復旧の完成を成果物として定義しにくいため、常駐的な障害対応を請負で縛るのは現実的でない場面が多いです。
準委任契約は「業務の遂行」に責任を負う形態で、24時間監視や定常的な一次対応など、継続的に手を動かす業務に適しています。多くの運用代行や障害対応は、準委任契約をベースに、SLA（サービス品質保証）を付けて対応時間や復旧目標を明文化する形が多いです。さらに、月額固定の運用費に、インシデント発生時のスポット対応を従量で組み合わせる契約も一般的です。
重要なのは、契約形態だけでなくSLAの中身を具体的に詰めることです。たとえば「Critical（極大）の障害は検知から15分以内に連絡、1時間以内に復旧着手」「High（大）の障害は30分以内にエスカレーション」といった目標値を契約に盛り込むことで、対応スピードを担保できます。「迅速に対応します」といった曖昧な文言では、有事に実効性を持ちません。
発注前に準備すべきドキュメントと要件定義
発注の成否は、依頼前の準備でほぼ決まります。何を守りたいのか、どこまで止められるのかを発注者側で言語化できていなければ、ベンダーは適切な提案も見積もりも出せません。
RTO・RPOの定義と優先順位の整理
発注で最初に決めるべきは、RTO（目標復旧時間）とRPO（目標復旧時点）です。RTOは「障害発生からどれだけの時間で復旧させたいか」、RPOは「どの時点までのデータを復旧させたいか、言い換えればどこまでのデータ損失を許容するか」を示す指標です。たとえばRTO4時間・RPO1時間なら、4時間以内に復旧し、最大でも直近1時間分のデータ損失に抑える要件になります。
この数値はシステムごとに異なります。受注を処理する基幹システムは両方とも短く設定すべきですが、社内の情報共有ツールなら、多少の停止やデータ巻き戻りも許容できるかもしれません。とはいえ、全システムを最高水準で守ろうとすると費用が膨らむため、事業インパクトに応じて優先順位をつけ、メリハリのある要件にするのが現実的です。
RTO・RPOを数値で提示できれば、ベンダーは必要なDR構成（同期レプリケーションか非同期か、ホットスタンバイかコールドスタンバイか）を逆算して提案できます。逆に曖昧なまま発注すると、過剰な構成で高くつくか、いざという時に間に合わない構成になるかのどちらかに陥ります。そのため、発注者がこの2指標を握ることが、ベンダーコントロールの出発点です。
システム構成資料と連絡体制の明文化
ベンダーが迅速に復旧するには、対象システムの全体像を把握できる資料が欠かせません。ネットワーク構成図、サーバー・データベースの一覧、利用しているクラウドサービスやミドルウェアの情報、データのバックアップ先と頻度などを整理して渡せると、立ち上がりが格段に速くなります。
これらが整っていないと、ベンダーは障害のたびに構成を手探りで調べることになり、復旧が遅れます。あわせて、障害発生時の連絡体制とエスカレーションルートも事前に文書化しておく必要があります。誰が一次受けをし、どの段階で誰に連絡が上がり、最終的な復旧可否の判断を誰が下すのかを、あらかじめ決めておきます。
発注者側の窓口と、ベンダー側の担当や夜間休日の連絡手段を明確にしておかないと、有事に「連絡がつかない」という最悪の事態を招きます。そのため、連絡体制は契約書の別紙として明記するのが望ましい運用です。発注前のこうした準備は、復旧プロセス全体の設計とも密接に関わります。なお、検知から復旧、事後対応までの一連の流れは、関連記事のITシステム障害復旧の進め方で詳しく解説しています。
委託後にベンダーをコントロールする実務
障害復旧の質を決めるのは、発注後のベンダーコントロールです。とくに外部起因の障害が起きた際は、ベンダー任せにせず、報告の妥当性を検証して必要なら是正を求める発注者の姿勢が問われます。
ベンダーRCAの妥当性評価と差し戻し
障害が収束すると、ベンダーからRCA（根本原因分析報告書）が提出されます。ここで多くの発注者がやりがちなのが、報告書を鵜呑みにしてしまうことです。RCAには、再発防止につながる本質的な原因まで掘り下げられているか、表面的な事象で止まっていないかを見極める目が必要です。
「サーバーの負荷が高騰したため」で終わる報告は、なぜ負荷が高騰し、なぜ検知が遅れたのかに踏み込めていません。評価の観点は、再発防止策が「気をつける」「監視を強化する」といった属人的・抽象的なものに終始していないかです。一方で、実効性のある再発防止策は、完全予防・リスク緩和・迅速検知・影響範囲の最小化の4分類で検討されているべきです。
これらが欠けていれば、発注者は差し戻し、追加の調査と具体策を求めて再発を防ぎます。あわせて確認したいのが「なぜ監視アラートより先にユーザーやサポート窓口が異常に気づいたのか」という点です。検知が外部からの通報に頼っていたなら、それ自体が監視設計の欠陥を示すサインです。また、たまたま早く気づけた要素も洗い出して潜在リスクとして報告に含めると、見えていなかった脆弱性を可視化できます。
SLA違反時の交渉とベンダー依存の回避
SLAが守られなかった場合の動き方も重要な統制ポイントで、復旧目標時間を大きく超えた場合や連絡が約束より遅れた場合は、SLAに紐づくペナルティ条項に基づいて是正を求めます。ペナルティは費用の減額にとどめず、体制改善を求める材料として使うべきものです。そのため、契約段階でSLA違反時の対応を曖昧にせず明文化しておくことが効いてきます。
同時に注意したいのが、ベンダーへの過度な依存です。すべてを任せて自社に知見が残らないと、こうなると切り替えたくても切り替えられず、価格交渉力も失います。そこで、復旧手順書や構成情報を発注者側でも保持し、定期的な報告会で内容を理解して、ベンダーがいなくても最低限の状況は把握できる状態を保つことが、健全な委託関係の鍵です。
また、ベンダーが立てた恒久対策が、新機能開発などの優先タスクに押し出され、実行されないこともよく起こります。そのため、発注者は報告会のたびに恒久対策の進捗を確認し、対応を後回しにさせない圧力をかけ続ける必要があります。再発防止策は立てた時点で終わりではなく、実装されて初めて意味を持つため、この認識を発注者とベンダーで共有しておくことが大切です。
費用感の捉え方と外注で失敗しないポイント
外注を検討するとき、費用は当然の関心事です。ただし、安さだけで選ぶと、有事に対応できない体制を買ってしまいかねません。
見積もりで確認すべき費用構造
障害復旧の外注費用は、平時の固定費と有事の変動費に分かれ、固定費には、24時間監視の月額料金、DR環境の維持費、定期バックアップの運用費などが含まれます。一方、変動費は、障害発生時の緊急対応費や、大規模復旧作業のスポット費用です。見積もりでは両方が明示されているかを確認し、夜間・休日の障害対応が固定費か別途課金かを必ず詰めてください。
とくに注意したいのは、月額の固定費が安く見える見積もりほど、有事の対応が手薄だったり別料金だったりするケースがある点です。そこで、複数社から相見積もりを取り、同じRTO・RPO要件を提示したうえで、何が含まれ何が含まれないかを横並びで比較するのが鉄則です。費用の内訳や相場観は、関連記事のITシステム障害復旧の費用相場で詳しく解説しています。
費用を考えるときは、障害で事業が止まった場合の損失額と天秤にかける視点も欠かせません。たとえば、警察庁の2023年の広報資料によれば、ランサムウェア被害を受けた企業140社のうち95%が業務に何らかの影響を受けたと回答しています。そのため、一度の重大障害が事業に与えるダメージを踏まえれば、復旧体制への投資は保険的なコストとして合理性を持ちます。
よくある発注の失敗と回避策
発注でよくある失敗の一つは、契約時に「平常時の運用」しか想定せず、有事の体制を詰め切らないことです。たとえば、監視は契約に入っていても、障害時に誰がどこまで復旧作業をするのかが曖昧だと、ベンダーと「それは契約範囲外」という押し問答になります。そこで、契約前に想定される障害シナリオを複数挙げ、それぞれで誰が何をするかをベンダーと擦り合わせておくことが回避策です。
もう一つの失敗は、復旧手順を一度も試さずに運用へ入ることです。バックアップがあっても、そこからリストアできるかを検証していなければ、有事に「復元できなかった」という事態が起こり得ます。こうした失敗を防ぐには、本番に近い環境で擬似障害を起こし、復旧手順が機能するかを確かめる訓練を、ベンダーと定期的に行う取り決めを契約に含めておくことが有効です。
こうした回復力の検証によって、MTTRを大幅に短縮できた事例も報告されています。最後に、発注先選びそのもので失敗を避けるには、ベンダーの実績や対応体制を多角的に評価することが欠かせません。比較・選定の基準は、関連記事のITシステム障害復旧でおすすめの開発会社/ベンダー6選と選び方で具体的に紹介しています。
まとめ
ITシステム障害復旧の発注・外注は、有事に確実に復旧できる体制を外部と共同で設計することです。まず、委託範囲を監視・復旧・DR構築・原因調査の4層で整理し、事業インパクトに応じて丸投げ型と協働型を使い分けることが出発点になります。
発注前にはRTO・RPOを数値で定義し、システム構成資料と連絡体制を文書化しておくことで、ベンダーから適切な提案と見積もりを引き出せます。そして委託後は、ベンダー任せにせず統制を効かせることが、復旧の質を左右します。
提出されたRCAの妥当性を評価し、表面的な報告や属人的な再発防止策には差し戻しを求めます。SLA違反には契約に基づいて是正を促し、恒久対策が後回しにされないよう進捗を追い続けます。こうした発注者の能動的な関与が、同じ障害を繰り返さない体制をつくります。
費用は平時の固定費と有事の変動費の両面で比較し、安さだけでなく有事の実効性で選ぶことが、後悔しない外注の条件です。障害復旧の外注を成功させるには、発注前の準備、契約形態の選択、委託後のコントロールという各局面で発注者が主導権を握ることが欠かせません。
本記事で紹介した観点を踏まえ、自社の重要システムを守る復旧パートナーとの最適な委託関係を築いていただければ幸いです。障害復旧を含む運用全体を体系的に理解したい方は、関連記事もあわせてご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。