# システム障害対応費用の相場｜外注・復旧の進め方 - 公開日: 2026-10-22 - 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星 - URL: https://www.geek-bridge.com/column/system-incident-response-cost システム障害対応の費用は、初動調査で10万〜50万円程度、小規模な修正・復旧で30万〜150万円程度が一般的な目安です。復旧を急ぐほど、原因調査、暫定復旧、恒久対応を分け、事業影響と証拠を確認しながら外注することが重要です。 ## システム障害が発生したら最初に判断すること 障害発生直後は、原因を推測して修正を始めるよりも、「誰にどのような影響が出ているか」「安全に止めるべきか」「元の状態へ戻せるか」を先に判断します。慌てて本番環境を変更すると、障害を拡大させたり、原因究明に必要な記録を失ったりするためです。 システム障害には、画面が表示されない、ログインできない、処理が遅い、データが更新されない、外部サービスと連携できないなど、さまざまな状態があります。発注者が技術的な原因を特定する必要はありません。まずは事業への影響を具体的に整理してください。 発生直後に確認したい項目は次のとおりです。 - 障害を最初に確認した日時 - 障害が継続中か、一時的に解消しているか - 影響を受けている利用者、部署、店舗、取引先 - 利用できない機能と、利用できる機能 - 売上、受注、決済、出荷、顧客対応への影響 - 個人情報や機密情報の漏えいが疑われるか - 障害発生前に行ったリリース、設定変更、データ更新 - エラー画面、発生条件、操作手順 - 直近のバックアップが取得できているか 特に優先すべきなのは、人命・安全、情報漏えい、金銭の誤処理、データ消失に関する確認です。セキュリティ侵害の可能性がある場合は、通常の不具合修正ではなく、インシデント対応（＝情報セキュリティ上の事故への対応）として証拠保全や関係者への報告も検討します。 ### 暫定復旧と恒久対応を分ける 障害対応は、すべてを一度に直そうとせず、次の3段階に分けると判断しやすくなります。 | 段階 | 目的 | 対応例 | |---|---|---| | 一次対応 | 被害の拡大を止める | 問題機能の停止、アクセス制限、外部連携の一時停止 | | 暫定復旧 | 最低限の業務を再開する | 直前バージョンへの切り戻し、手作業への代替、予備環境への切り替え | | 恒久対応 | 原因を除去して再発を防ぐ | プログラム修正、構成変更、監視追加、運用手順の見直し | 切り戻しとは、システムを障害発生前のバージョンや設定へ戻すことです。原因が分からなくても短時間で復旧できる場合がありますが、データ構造が変更されていると単純には戻せません。 発注のご相談を受ける開発会社の立場から見ると、「今すぐ完全に直してほしい」という依頼ほど、最初に暫定復旧の条件を合意する必要があります。完全復旧だけを目標にすると、利用停止時間が長くなり、調査費用も膨らみやすいためです。 ## システム障害対応の費用相場と期間 障害対応費用は、画面数や機能数よりも、原因の特定難易度、資料とログの有無、アクセス権限、緊急度、データへの影響によって大きく変わります。以下は一般的な目安であり、システムの規模や契約条件によって増減します。 | 対応内容 | 費用の目安 | 期間の目安 | |---|---:|---:| | 初動調査・影響範囲の確認 | 10万〜50万円 | 数時間〜3営業日 | | 小規模な不具合修正・復旧 | 30万〜150万円 | 1日〜4週間 | | 中規模な原因調査・改修 | 100万〜500万円 | 2週間〜3か月 | | データ復旧・整合性の修正 | 20万〜300万円以上 | 数日〜2か月 | | 再発防止の設計・監視追加 | 30万〜300万円 | 2週間〜3か月 | | 緊急対応を含む保守契約 | 月額10万〜80万円以上 | 継続契約 | ここでいう初動調査には、関係者へのヒアリング、ログ（＝システムの動作記録）の確認、直前の変更内容の確認、再現テスト、影響範囲の整理などが含まれます。調査で原因と修正範囲が確定した後、改めて復旧・改修費用が提示されることもあります。 ### 費用が高くなりやすい条件 次の条件があると、調査や復旧に必要な工数が増えます。 - ソースコードや設計書がなく、システムの構造を把握できない - サーバーやクラウドの管理権限が不明である - 動作記録が十分に保存されていない - 再現条件が分からず、障害が不定期に発生する - 複数の外部サービスや社内システムと連携している - データ破損があり、正しい状態を業務担当者に確認する必要がある - 夜間、休日、即時対応が必要である - 古い技術やサポート終了済みの製品を使用している - 開発会社が変わり、引き継ぎ情報が不足している とくに「管理画面に入れない」「クラウド契約の名義が以前の委託先になっている」といった権限の問題は、技術調査以前の大きな障壁です。自社が契約主体になっているか、管理者アカウントを保有しているかを平時から確認しておきましょう。 ### 見積もり方式による違い 原因が分からない段階では、最終的な復旧費用を固定できないことがあります。その場合は、調査費用に上限を設けた準委任契約が現実的です。準委任契約とは、成果物の完成ではなく、一定の専門業務を行うことに対して報酬を支払う契約です。 一方、原因と修正範囲が明確になれば、完成責任を定める請負契約を選べる場合があります。実務上は、次のように契約を分ける方法があります。 1. 初動調査を上限付きの準委任契約で依頼する 2. 調査結果と復旧方針の報告を受ける 3. 暫定復旧と恒久対応を別々に見積もる 4. 範囲が確定した改修を請負契約または準委任契約で依頼する 最初から総額だけを求めると、開発会社は不確実性を見積もりへ上乗せするか、調査後の追加費用を前提に提示せざるを得ません。見積もり金額だけでなく、どこまで調査・復旧する契約なのかを確認してください。 ## 障害発生から復旧・再発防止までの進め方 障害対応は、「影響確認」「被害抑制」「暫定復旧」「原因調査」「恒久対応」「再発防止」の順に進めます。復旧作業と原因調査を並行しつつ、各段階で判断者と完了条件を明確にすることが重要です。 ### 1. 責任者と連絡経路を決める 最初に、事業上の判断をする責任者と、技術対応を統括する担当者を決めます。関係者が個別に開発会社へ連絡すると、指示が食い違い、復旧作業の妨げになります。 最低限、次の役割を定めます。 - 業務停止やサービス停止を判断する責任者 - 開発会社との連絡窓口 - 顧客、取引先、社内への案内担当 - データや取引内容を確認する業務担当者 - 対応履歴を時系列で記録する担当者 小規模な会社では兼務でも構いません。ただし、設定変更や復旧作業の承認者は明確にしてください。 ### 2. 影響範囲を確認し、証拠を保存する エラーメッセージ、画面のスクリーンショット、発生日時、利用者の操作、サーバーのログなどを保存します。障害発生後に再起動や設定変更をすると、重要な記録が消える場合があります。 そのため、緊急で再起動が必要な場合でも、可能な範囲で現状を記録してから実行します。情報漏えい、不正アクセス、データ改ざんが疑われる場合は、通常の復旧より証拠保全を優先すべきケースもあります。 ### 3. 被害を抑え、暫定復旧する 影響が拡大している場合は、問題機能の停止、アクセス制限、外部連携の遮断などを行います。そのうえで、切り戻し、バックアップからの復元、代替手段への切り替えを検討します。 ただし、バックアップが存在することと、安全に復元できることは別です。復元時点以降に登録された注文や顧客情報が失われないか、外部システムとデータの不一致が発生しないかを確認する必要があります。 復旧の完了条件は、「画面が開いた」だけでは不十分です。次の項目を確認します。 - 主要な業務を最初から最後まで実行できる - 登録、更新、削除したデータが正しく保存される - 決済、メール、会計、在庫などの外部連携が動作する - 障害中に発生した取引の欠損や重複がない - 一般利用者と管理者の権限が正しい - 異常なエラーや負荷が継続していない ### 4. 原因分析と恒久対応を行う サービス再開後は、根本原因分析（＝障害を引き起こした本質的な要因を調べること）を行います。直接の原因だけでなく、なぜ事前に検知できなかったか、なぜ影響が拡大したかも確認します。 たとえば、プログラムの不具合が直接原因でも、背景にはテスト不足、レビュー不足、監視不足、手順書の欠如、アクセス権限の集中などがあるかもしれません。個人のミスだけで終わらせると、同じ条件で再発します。 恒久対応の候補には、次のものがあります。 - プログラムやデータ処理の修正 - 自動テストの追加 - リリース前確認の強化 - エラーや処理遅延を検知する監視の追加 - バックアップと復元テストの見直し - 管理者権限と承認フローの整理 - 障害対応手順と連絡網の整備 - 特定担当者や開発会社への依存解消 古い設計や応急処置の蓄積が障害につながっている場合は、1回の修正で終わらせず、[技術的負債の解消費用｜優先順位と外注方法](https://www.geek-bridge.com/column/technical-debt-remediation-cost)も参考に、事業影響が大きい箇所から段階的に改善するとよいでしょう。 ### 5. 障害報告書を残す 対応後は、関係者が同じ認識を持てるように障害報告書を作成します。責任追及のためではなく、次回の復旧を早め、再発防止策を管理するための資料です。 障害報告書には、次の内容を記載します。 - 発生日時、検知日時、復旧日時 - 利用者と事業への影響 - 発生から復旧までの時系列 - 直接原因と背景要因 - 暫定復旧で実施した内容 - 恒久対応の内容と期限 - データ欠損やセキュリティへの影響 - 顧客や取引先への案内内容 - 再発防止策の責任者と実施期限 再発防止策は、「注意する」「確認を徹底する」ではなく、仕組みとして実行できる内容にします。担当者、期限、確認方法まで決めることが大切です。 ## 障害対応を外注する準備と会社の選び方 障害対応を外注するときは、完全な仕様書を作る必要はありません。ただし、事業影響、システムへのアクセス方法、直前の変更、既存資料を整理して渡すことで、初動を早め、調査費用を抑えられます。 ### 外注先へ渡す情報のチェックリスト 緊急時でも、次の情報を可能な範囲で用意してください。 - システムの用途と主要利用者 - 障害の発生日時と現在の状態 - 影響を受けている機能、利用者、業務 - 再現手順とエラー画面 - 直前のリリース、設定変更、データ更新 - ソースコードの保管場所 - 本番・検証環境へのアクセス方法 - クラウド、サーバー、データベースの管理権限 - 設計書、構成図、運用手順書 - 利用している外部サービスの一覧 - ログとバックアップの保存状況 - 現在の保守会社、過去の開発会社の連絡先 - 希望する復旧時刻と、許容できる業務停止範囲 アクセス情報をメール本文やチャットへ直接記載するのは避け、安全な共有方法を外注先と決めます。不要になった一時アカウントは、対応終了後に無効化してください。 ### 見積もりで確認する項目 障害対応の見積もりは、金額だけでなく、調査の終了条件と報告内容を確認します。 | 確認項目 | 見るべきポイント | |---|---| | 初動調査 | 対象環境、調査時間の上限、報告書の有無 | | 緊急対応 | 対応開始時間、夜間・休日の割増、連絡方法 | | 暫定復旧 | どの業務・機能まで復旧対象か | | 恒久対応 | 修正範囲、テスト範囲、リリース作業の担当 | | データ対応 | 復元対象、整合性確認、欠損時の責任分界 | | 追加費用 | 上限超過前の承認方法、再見積もりの条件 | | 保証・契約 | 修正後の不具合対応、秘密保持、損害賠償条件 | | 成果物 | 原因調査報告書、変更履歴、手順書、ソースコード | 原因不明の状態で「必ず○時間以内に完全復旧します」と断定する会社には、前提条件を確認してください。信頼できる会社ほど、確認できている事実、推測、未調査の範囲を分けて説明します。 ### 対応会社を選ぶ基準 緊急時でも、次の基準は確認したいところです。 - 使用技術やクラウド環境に対応できる - 原因調査と事業影響の確認を分けて説明できる - 本番環境を変更する前に承認を取る - 作業内容を時系列で記録する - データ保護とアクセス権限の管理方法が明確である - 暫定復旧と恒久対応を分けて提案する - 調査費用の上限や追加承認の条件が明確である - 復旧後のテストと報告書作成まで対応できる - 将来の保守契約を強制せず、成果物を引き渡す 最も安い会社が、最終的に最も安くなるとは限りません。調査単価が低くても、対応範囲が曖昧で調査が長期化すれば総額は増えます。担当者の単価だけではなく、初動の速さ、調査計画、報告品質、再発防止まで含めて比較してください。 対応会社の選定や既存システムの緊急調査に迷う場合は、現状と事業影響を整理したうえで[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からご相談ください。 ### よくある失敗と回避策 障害対応では、技術的な難しさだけでなく、発注・判断の進め方が復旧を遅らせることがあります。 | よくある失敗 | 起こり得る問題 | 回避策 | |---|---|---| | 原因を決めつけて修正する | 別の箇所へ影響が広がる | 事実と仮説を分け、変更前に記録する | | 本番環境を直接変更する | 状態を戻せず、証拠も失う | バックアップと切り戻し手順を確認する | | 復旧条件を決めない | どの状態で完了か判断できない | 業務単位で確認項目を決める | | バックアップを無条件で戻す | 新しい取引データが失われる | 復元時点と差分データを確認する | | 初動から固定価格だけを求める | 不確実性が価格に上乗せされる | 調査と改修を分けて契約する | | 復旧後すぐに終了する | 同じ原因で再発する | 原因分析と再発防止策を残す | | 特定担当者だけで対応する | 不在時に復旧できない | 記録、権限、連絡先を組織で共有する | 障害が収束した直後は通常業務を優先しがちですが、このタイミングで記録を残さないと、次回も同じ調査から始めることになります。最低限、原因、変更箇所、復旧確認、残課題を文書化してください。 ## まとめ - システム障害対応の一般的な費用目安は、初動調査が10万〜50万円、小規模な修正・復旧が30万〜150万円です - 発生直後は原因の推測より、事業影響の確認、被害の抑制、証拠の保存を優先します - 一次対応、暫定復旧、恒久対応を分けると、業務再開までの時間と費用を管理しやすくなります - 原因不明の段階では、上限付きの準委任契約で調査し、修正範囲が分かってから改修を見積もる方法が現実的です - 外注前に、管理権限、ソースコード、ログ、バックアップ、直前の変更履歴を確認します - 見積もりでは、調査時間の上限、追加承認、復旧範囲、テスト、報告書の有無を比較します - 復旧後は障害報告書を作り、監視、テスト、バックアップ、運用体制まで見直すことが重要です ## よくある質問 ### システム障害の緊急対応にはいくらかかりますか？ 一般的な目安は、初動調査が10万〜50万円程度、小規模な修正・復旧が30万〜150万円程度、中規模以上の復旧が100万〜500万円以上です。夜間・休日対応、資料不足、データ破損、外部サービスとの複雑な連携がある場合は費用が増えます。 ### 開発した会社以外にも障害対応を依頼できますか？ 依頼できます。ただし、ソースコード、サーバー、クラウド、データベースなどへのアクセス権限が必要です。資料が不足している場合は、緊急対応に入る前に現状調査や環境解析が必要になることがあります。 ### 障害対応は請負契約と準委任契約のどちらが適していますか？ 原因や作業範囲を事前に確定しにくい初動調査は、作業時間に対して費用を支払う準委任契約が適しています。原因と修正範囲が明確になった後の改修は、成果物の完成を約束する請負契約も選択肢になります。 ### 復旧後は何を確認すればよいですか？ 主要機能、データの整合性、外部連携、決済や通知などの定期処理、セキュリティ、監視状況を確認します。原因、対応内容、影響範囲、再発防止策を障害報告書として残すことも重要です。