年に一度、災害対策環境へ切り替え、計画どおりシステムが起動したことを確認する。これは重要な訓練です。 しかし、実際の中断では、認証、ネットワーク、データ、クラウド、委託先、業務担当者、顧客との連絡が同時に揃うとは限りません。 システム単体の復旧に成功しても、優先すべき業務が再開できなければ、ITサービス継続として十分とはいえません。

PeopleCertの公式ライブラリでは、Service Continuity ManagementがITIL 4の正式なプラクティスガイドとして位置づけられています。 また、ISO 22301は事業継続を、計画を作る一度きりの活動ではなく、導入、運用、監視、レビュー、維持、継続的改善を含むマネジメントシステムとして示しています。 ITSMで扱うべき対象は、復旧手順書の有無だけでなく、サービス価値を許容可能な水準で継続・回復させる能力です。

2026年4月にIPAが公開したプラクティス・ナビは、企業経営への影響を踏まえて復旧時期を特定し、BCPと整合した復旧目標を定め、 サプライチェーンを含む実践的な演習を行うことを示しています。英国NCSCの2026年7月の復旧ガイダンスも、全面復旧を待つのではなく、 安全に事業を続けられる最小実行可能業務（Minimum Viable Operations、MVO）へ戻す考え方を提示しています。 本記事では、これらを日常のサービスマネジメントへ組み込む5つのステップを整理します。

具体的な課題：復旧計画があっても、業務再開の順番を決められない

計画が「システムAを4時間で復旧する」のような技術単位だけで作られていると、障害時に経営判断へつながりません。 実際には、同じシステムでも月末締め、給与日、繁忙期、規制報告の期限などによって重要度が変わります。 復旧資源が限られる状況では、すべてを同時に戻す前提より、どの業務を、どの水準まで、何に依存して戻すかを合意しておく必要があります。

  • 対象が設備中心：サーバーやクラウドの復旧は定義されていても、業務、データ、要員、委託先、顧客対応がつながっていない。
  • 目標が一つだけ：RTOだけを置き、復旧時点、処理能力、受け入れ可能な残存リスク、暫定業務の終了条件が曖昧。
  • 依存関係が古い：認証、DNS、接続、秘密情報、端末、SaaS、連絡先など、共通基盤の変更が計画へ反映されていない。
  • 演習が成功前提：予定済みの切替手順を確認するだけで、欠損データ、連絡不能、委託先遅延、判断の競合を試していない。
  • 改善が通常運用へ戻らない：演習で見つけた課題が議事録に残るだけで、変更、調達、構成、ナレッジ、教育へ接続されない。
復旧の目的は、機器を起動することではなく、優先する事業活動を安全に再開できる状態へ戻すことです。

考え方：平常、最小実行可能業務、全面復旧を分ける

継続計画を「通常どおり戻す計画」だけにすると、全面復旧までの長い空白が生まれます。そこで、サービス状態を三つに分けます。 平常時は通常のサービスレベル、MVOは重要業務を安全かつ説明可能な範囲で継続できる最低水準、全面復旧は通常運用へ戻り、 暫定処理で生じたデータや判断を正規の仕組みへ統合し終えた状態です。

  1. 平常：標準の機能、性能、要員、統制で価値を提供する。
  2. MVO：優先業務、最低限のデータ、信頼できる認証、必要な連絡・承認だけで安全に継続する。
  3. 全面復旧：停止中の処理を照合し、暫定運用を終了し、通常のサービス水準と改善サイクルへ戻る。

NCSCはMVOを、組織が安全に活動を続け、必要な義務を満たし、顧客・取引先・従業員からの信頼を維持できる最低限の運用能力と説明しています。 これは一律の縮小版システムではありません。時間帯や事業状況で優先度が変わるため、サービスオーナー、業務部門、IT、セキュリティ、 リスク、広報、法務などが、自社の文脈で条件を決めます。

実践手順1：守る業務と意思決定者を先に決める

まず、売上、顧客保護、安全、資金繰り、従業員、取引先、社会的責任などの観点から、中断時間が長くなるほど影響が増える業務を選びます。 その業務が「止められない」理由と、時間経過による影響の変化を記録します。システム一覧から始めるのではなく、事業成果と利用者影響から始めることが重要です。

各業務には、復旧優先順位を変更できる意思決定者と代理者を置きます。平時に決めた順番が常に正しいとは限りません。 月末、繁忙期、災害範囲、顧客影響、利用可能な要員によって条件が変わったとき、誰が何を根拠に優先順位を更新するかを明確にします。

実践手順2：サービス依存関係と復旧順序を可視化する

優先業務から逆向きに、アプリケーション、データ、認証、ネットワーク、端末、監視、バックアップ、クラウド、SaaS、設備、要員、委託先をたどります。 詳細な構成管理データベースを完成させることより、MVOに必要な依存関係と、復旧の前後関係を一枚で説明できることを優先します。

NCSCは、複数の復旧作業を支える共通基盤を特定し、インフラ、共有サービス、業務システムの依存関係から再起動順序を計画するよう示しています。 特に認証と信頼の起点、名前解決、接続、特権アクセス、バックアップの完全性は、他の復旧を左右します。 委託先の作業時間や第三者の接続再開条件も、技術構成と同じ依存関係として扱います。

実践手順3：MVOの復旧目標と暫定運用を設計する

MVOごとに、目標復旧時間（RTO）、許容できるデータの戻り幅（RPO）、最低限の機能・処理能力・対象利用者を定めます。 目標は希望値ではなく、現状の復旧能力、要員、契約、バックアップ、依存先の制約と比較します。差が大きい場合は、投資、代替手段、目標の見直しを経営判断へ上げます。

システムを使えない間の手作業も設計します。入力項目、承認、二重処理の防止、情報の保護、保管場所、責任者、処理量の上限、 終了条件を決め、復旧後に正規システムへ照合・再入力する手順まで含めます。NCSCは暫定運用をセキュリティレビューし、 後からデータを統合する方法と見直し日をあらかじめ決めるよう示しています。

実践手順4：失敗を含む演習で、判断と連携を確かめる

演習は、切替成功の確認だけでなく、意思決定、連絡、依存関係、暫定運用を検証します。たとえば「主担当が不在」「認証基盤の信頼性が不明」 「バックアップの一部が使えない」「クラウド事業者の回答が遅い」「顧客への説明期限が迫る」といった条件を一つずつ加えます。 すべてを同時に盛り込まず、目的に合わせて段階的に難度を上げます。

技術チームだけでなく、業務責任者、経営判断者、セキュリティ、広報、委託先を参加させ、どの情報があれば判断できたかを記録します。 IPAも、自然災害向けBCPの経験者とインシデント対応チームの情報共有、影響度に応じた判断フロー、優先度の高いシステムの復旧手順と演習を挙げています。

実践手順5：演習と実障害の学びを通常運用へ戻す

演習後の課題には、対象サービス、事業影響、責任者、期限、完了条件を付け、通常の改善バックログへ登録します。 構成情報、監視、変更、契約、教育、ナレッジ、アクセス管理、バックアップなど、該当するプラクティスへ戻して実装します。 「訓練報告書を提出した」ではなく、次の演習で弱点が減ったかを確認して閉じます。

サービス、業務、委託先、データ、規制上の条件が変わったときは、年次予定を待たずに見直します。 新しいSaaSの導入、認証方式の変更、組織再編、ピーク時期の変更、重大インシデント、復旧失敗を更新トリガーとして登録すると、 計画と現実の差を小さく保てます。ISO 22301が示す継続的な監視・レビュー・改善を、ITSMの日常へ落とし込む考え方です。

注意点：速さだけを優先すると、危険な復旧になる

  • RTOを約束値だけで決めない：実測した復旧能力と依存先の制約を確認し、差分を投資・代替・受容の判断へ上げる。
  • バックアップを復旧保証とみなさない：利用可能性、完全性、信頼性、必要時間、復旧後の検証まで確かめる。
  • 暫定運用を恒久化しない：終了日、処理上限、データ照合、通常運用へ戻す責任を定める。
  • 演習で個人を評価しない：判断に必要な情報、権限、手順、連携、設計の弱点を改善対象にする。
  • 復旧と安全性を二者択一にしない：再侵入、データ不整合、権限逸脱を避けるため、復旧速度と必要な保証水準を明示的に調整する。

まとめ：サービス継続を、判断できる運用能力にする

ITサービス継続は、年次訓練や災害対策環境だけで完結しません。守る業務と意思決定者を定め、依存関係と復旧順序を可視化し、 MVOの目標と暫定運用を設計し、失敗を含む演習で確かめ、学びを通常運用へ戻すことで、計画は実際に使える能力へ変わります。

最初から全社の計画を作り直す必要はありません。まず一つの重要サービスを選び、「最低限どの業務を継続するか」「最初に必要な共通基盤は何か」 「手作業の記録をどう戻すか」を90分で確認してください。見つかった一つの差分を改善バックログへ登録し、短い再演習で閉じることが、継続的な強化の出発点です。

参考資料

本記事は公式・公的資料をもとに、一般的なITサービスマネジメントと事業継続の考え方を整理したものです。 個別組織の契約、法令適合性、セキュリティ、監査、労務その他の法律上・専門上の助言を行うものではありません。 公式資料は2026年9月24日時点で確認しています。実際の運用では、自社のサービス、利用者、契約、適用される法令・規格、組織体制、 リスク許容度を踏まえ、必要に応じて関係部門や専門家へ確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る