フェイルオーバーとは？障害時の自動切替の仕組みと保守契約の確認点

「冗長化してありますので、万一の際も自動で切り替わります」。システムの構成説明を受けたとき、ベンダーからこうした説明を聞いたことがある方は多いはずです。ところが実際に障害が起きてサービスが数時間止まると、「自動で切り替わるはずではなかったのか」という問いが社内から返ってきます。そのとき、技術的な検証手段を持たない発注側の担当者は、ベンダーの報告をそのまま受け取るしかありません。

この「切り替わるはず」と「実際に切り替わった」のあいだにある溝を埋める仕組みが、フェイルオーバーです。ただし、フェイルオーバーは設定さえすれば魔法のように無停止を実現する機能ではありません。何を異常とみなすかの条件設定、待機側を常に使える状態に保つ運用、そして切り替わらなかったときの責任分担、この3つが揃って初めて機能します。

やっかいなのは、この3つのうち後ろの2つが技術ではなく「運用と契約」の領域にあることです。構成図には「アクティブ・スタンバイ構成」と書かれていても、待機系のデータ同期が半年前から止まっていたり、一度も切替テストが実施されていなかったりすることは珍しくありません。そして、そうした状態を発注側が発見できるのは、たいてい障害が起きた後です。

インフラの専任エンジニアがいない組織で、構成図を技術的に検証するのは現実的ではありません。しかし、「記録が残っているか」「契約に書かれているか」という観点であれば、非エンジニアの担当者でも十分に確認できます。ベンダーの説明を鵜呑みにせず、必要な質問を投げられる状態になることが、実効性を担保する最短ルートです。

本記事では、フェイルオーバーの意味と切替が完了するまでの流れ、スイッチオーバー・フェイルバックといった紛らわしい用語との違い、自社の構成パターンの見分け方を整理したうえで、「設定済みなのに切り替わらない」典型パターンと、それを踏まえて保守契約で確認すべき5つの点を解説します。最後に、打ち合わせでそのまま使える確認質問リストもまとめています。

—Free Download / 資料ダウンロード

失敗しないためのシステム保守の引継ぎチェックリスト

この資料でわかること

システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。

こんな方におすすめです

• 現在の保守会社のサービスに不満を感じている方
• 保守会社の変更を検討しているが、何から始めればよいか分からない方
• 引継ぎ作業でトラブルを避けたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

フェイルオーバーとは？障害時に待機系へ自動で切り替える仕組み

フェイルオーバー（failover）とは、稼働中のサーバーやシステムに異常が発生したときに、あらかじめ用意しておいた待機系（予備）へ処理を自動的に引き継がせる仕組みのことです。「fail（失敗する）」と「over（移る）」を組み合わせた言葉で、日本語では「自動切替」「縮退運転への移行」などと説明されます。

重要なのは、人が状況を判断して切り替えるのではなく、あらかじめ決めておいた条件に従って機械が切り替える点です。この「あらかじめ決めておいた条件」が実態と合っていなければ、フェイルオーバーは設定されていても発動しません。まずはこの前提から確認していきます。

フェイルオーバーの意味と「自動」が成立するための前提条件

フェイルオーバーが自動で成立するには、少なくとも次の3つが揃っている必要があります。

1. 異常を検知する仕組みがあること：何をもって「異常」とみなすかの条件（応答が返らない、規定回数連続で失敗した、など）が定義され、常時監視されている状態です。
2. 引き継ぎ先が使える状態で存在すること：待機系のサーバーが起動でき、アプリケーションとデータが本番と同等の状態に保たれている必要があります。
3. 利用者の接続先を付け替える経路があること：切り替わっても、利用者や外部システムの接続が新しい系に向かなければ、サービスは復旧しません。

この3つのうち、どれか1つでも欠けるとフェイルオーバーは機能しません。「フェイルオーバー構成です」という説明は、多くの場合1と2の設備が用意されていることを指しますが、条件設定が適切かどうか、待機系が今この瞬間も使える状態かどうかまでを保証するものではない、という点は押さえておきましょう。

冗長化・高可用性（HA）とフェイルオーバーの関係と違い

似た文脈で登場する「冗長化」「高可用性（HA：High Availability）」との関係を整理しておきます。

つまり、冗長化は「予備を持っている」こと、フェイルオーバーは「予備に自動で持ち替える」こと、高可用性は「その結果として止まりにくい」ことを指します。「冗長化してあるので止まりません」という説明は、厳密には「予備は持っています」までしか言っていない可能性があります。予備を持っていることと、それが自動で使われることは別の話です。

発注者がフェイルオーバーを理解しておくべき理由

インフラの専任者がいない組織であっても、発注側がフェイルオーバーの概要を理解しておく価値は3つあります。

1つ目は、障害報告を評価できるようになることです。「切替に失敗しました」という報告を受けたときに、検知の問題なのか、待機系の問題なのか、接続の付け替えの問題なのかを切り分けて質問できれば、再発防止策の妥当性も判断できます。

2つ目は、契約の抜けに気づけることです。後ほど詳しく述べますが、切替テストの実施義務や、切り替わった後に元へ戻す作業の費用負担は、保守契約に明記されていないケースが少なくありません。

3つ目は、経営層に正確に説明できることです。「障害が起きても止まりません」ではなく「障害の種類によっては数分で復旧します。ただしこの条件では止まります」と条件付きで説明できることは、情報システム担当者としての信頼にも直結します。

フェイルオーバーの仕組み｜障害検知から切替完了までの流れ

フェイルオーバーは一瞬で完了する魔法ではなく、いくつかの段階を順に踏む処理の連なりです。ここでは、障害の発生から利用者が再びサービスを使えるようになるまでを5段階に分けて見ていきます。各段階でどれくらいの時間がかかるのか、何が失われるのかを把握しておくと、ベンダーへの質問が具体的になります。

大まかな流れは次のとおりです。

1. 異常の検知：監視の仕組みが本番系の応答異常を検出する
2. 切替の判定：一時的な不調ではなく障害と判断する（連続失敗回数・タイムアウト時間などの条件を満たす）
3. 待機系の昇格：待機系を本番として動作させる（サービス起動、データベースの書き込み許可など）
4. 接続先の付け替え：VIP（Virtual IP）・DNS・ロードバランサーなどで、利用者の接続先を新しい系に向ける
5. 切替完了：利用者からのリクエストが新しい系で処理され始める

このうち2の「切替の判定」に意図的な待ち時間が設けられている点は、見落とされがちです。ネットワークの一時的な揺らぎで切り替わってしまうと、かえって不安定になるため、通常は「数秒間隔のチェックに数回連続で失敗したら障害とみなす」といった条件が設定されます。したがって、切替の合計所要時間は「検知までの待ち時間 + 昇格処理 + 接続先の反映」の積み上げになります。

死活監視（ヘルスチェック）で障害を検知する

フェイルオーバーの起点は、常時実行されている死活監視です。監視の粒度には段階があり、どこまで見ているかによって検知できる障害の範囲が変わります。

監視が浅いほど「動いているように見えるのに使えない」状態を見逃しやすくなります。監視の設計そのものについてはヘルスチェックとはで詳しく解説しているため、検知側の詳細はそちらを参照してください。本記事では、検知した後の切替に焦点を当てます。

待機系への切替と接続先の引き継ぎ（VIP・DNS・ロードバランサー）

待機系を起動しただけでは、利用者のアクセスは旧本番系に向いたままです。そこで、接続先を付け替える仕組みが必要になります。代表的な方式は次の3つです。

• VIP（Virtual IP）の付け替え：本番系と待機系のあいだで付け替えて使う共用の IP アドレスを、待機系に移す方式です。同一ネットワーク内であれば切替が速く、利用者側の設定変更も不要です。
• DNS の切り替え：ドメイン名が指す接続先を待機系に変更する方式です。柔軟ですが、利用者側や中継サーバーに残る DNS キャッシュの影響で、反映までに時間差が生じます。
• ロードバランサーによる振り分け変更：前面に置いた負荷分散装置が、異常を検知したサーバーへの振り分けを停止し、正常なサーバーへ寄せる方式です。

クラウドのマネージドサービスでもこの考え方は同じです。たとえば Amazon RDS のマルチ AZ 配置では、フェイルオーバー時に DB インスタンスの CNAME レコードをスタンバイに向け替えることで接続先を切り替えており、アプリケーション側でデータベース接続のリトライを実装しておくことが推奨されています（Amazon RDS マルチ AZ）。切替そのものが成功しても、アプリケーション側が古い接続を掴んだままでは復旧しない、という点は重要です。

フェイルオーバークラスターとクラウドのマネージド機能の違い

フェイルオーバーの実現方法は、大きく「自前で組む方式」と「クラウド事業者の機能に任せる方式」に分かれます。

フェイルオーバークラスターは、複数のサーバーをひとつのまとまり（クラスター）として構成し、いずれかに障害が起きた際に別のノードが役割を引き継ぐ方式です。Windows Server ではフェールオーバークラスタリングとして OS の機能に組み込まれており、クラスター化されたサーバー群が相互に監視し合う構成をとります（フェールオーバー クラスタリング）。細かい制御ができる反面、クラスターソフトの設定・保守・検証を自社またはベンダーが担う必要があります。

クラウドのマネージド機能は、データベースやロードバランサーといったサービス単位で、事業者側が冗長構成と切替を提供する方式です。マルチ AZ（複数のデータセンター群にまたがる配置）が代表例で、切替処理そのものは事業者に任せられます。

いずれの方式でも、「クラウドだから自動で全部守られる」わけではない点には注意が必要です。マネージド機能が守るのは、あくまでそのサービスの範囲に限られます。

切替中に起きること（セッション断・処理中データの扱い）

フェイルオーバーは「無停止」ではありません。切替の間、利用者側には次のような事象が発生します。

• ログインセッションの切断：セッション情報を共有していない構成では、利用者は再ログインを求められます。
• 処理中のリクエストの失敗：切替の瞬間に送信中だったリクエストはエラーになります。画面上は「通信エラー」「タイムアウト」として現れます。
• 未確定データの消失：確定（コミット）前のトランザクションは失われます。入力途中のフォームなども同様です。
• 接続先を掴み直すまでの遅延：アプリケーションが古い接続を保持している場合、リトライやタイムアウトを経て新しい接続に切り替わるまでの時間が上乗せされます。

所要時間の目安も押さえておきましょう。Amazon RDS のマルチ AZ 配置では、フェイルオーバーは「プライマリで障害が検出されてからスタンバイでトランザクションが再開されるまでの間隔」と定義され、通常1〜2分以内に完了するとされています（Amazon RDS マルチ AZ）。自前構成のクラスターでも数十秒から数分が一般的な範囲で、コールドスタンバイのように待機系を停止させている構成では数十分以上かかることもあります。

つまり、フェイルオーバーが正常に機能した場合でも「数分間はサービスが使えない」のが実態です。ここを「止まらない」と説明してしまうと、実際に切り替わったときに社内で「やはり止まったではないか」という認識のずれが生じます。ベンダーには「切替に何秒かかる想定か」「切替中に利用者に何が起きるか」を必ず確認しておきましょう。

フェイルオーバーとスイッチオーバー・フェイルバック・フェイルセーフの違い

構成資料や障害報告書には、フェイルオーバーとよく似た用語が並びます。意味を取り違えたまま議論すると、話が噛み合わないまま「大丈夫だと言われた」で終わってしまいます。ここで語彙を確定させておきましょう。

スイッチオーバー（計画的な手動切替）との違い

スイッチオーバーは、障害の発生とは関係なく、計画的に本番系と待機系を切り替える操作です。メンテナンスやバージョンアップの際に、あらかじめ日時を決めて実施します。

両者の決定的な違いは「誰が切替を始めるか」です。フェイルオーバーは監視の仕組みが条件を満たしたと判断して自動的に始まりますが、スイッチオーバーは人が意図して始めます。障害報告書に「スイッチオーバーを実施しました」と書かれていた場合、それは「自動では切り替わらず、人が手動で切り替えた」ことを意味します。自動切替を期待していた発注者にとっては、確認すべきポイントです。

なお、スイッチオーバーは日常的な訓練の機会にもなります。計画的な切替を定期的に実施していれば、待機系が実際に動くことを確認できるためです。

フェイルバック（切り戻し）が必要になる理由と発注者側の負担

フェイルバックは、フェイルオーバーで待機系に移した処理を、復旧した本番系へ戻す操作です。見落とされがちですが、フェイルオーバーが発生した以上、フェイルバックは必ずどこかのタイミングで発生します。

戻す作業が必要になる理由は主に3つです。

• 性能・機能の差：待機系は本番系より低いスペックで用意されている場合があり、そのまま長期運用すると性能が不足します。
• 冗長性の欠如：待機系で稼働している間は予備がない状態です。この状態でもう一度障害が起きればサービスは完全に停止します。
• データの一本化：待機系で更新されたデータを本番系へ反映し、整合性を取り直す作業が必要です。

そして、この作業には人手と時間がかかります。データ量が多い場合は再同期に数時間を要することもあり、切り戻しのために計画停止を設けるケースもあります。「切り替わったから終わり」ではなく、そこから元の状態に戻すまでが一連の対応であることを理解しておくと、後述する契約確認の意味がつかみやすくなります。

フェイルセーフ・フォールバックとの違い

フェイルセーフは、異常が起きたときに安全な側の状態に倒す設計思想です。たとえば、決済処理でエラーが起きたときに「不明な状態のまま進める」のではなく「処理を中止して受付を止める」といった振る舞いが該当します。切替の仕組みではなく、異常時の振る舞いの方針を指す言葉です。

フォールバックは、本来の機能が使えないときに、機能を落とした代替手段に切り替えることです。外部の在庫連携 API が応答しない場合に、リアルタイム在庫の表示をやめて前日時点のデータを表示する、といった対応が該当します。

フェイルオーバーが「同じ機能を別の設備で続ける」ものであるのに対し、フォールバックは「機能を落としてでもサービスを続ける」もの、フェイルセーフは「危険な処理を止める」ものです。この違いを押さえておくと、ベンダーの提案が可用性の話なのか、安全性の話なのかを区別できます。

用語比較表

ここまでの4語を、発注者の視点でまとめます。

フェイルオーバーの構成パターン｜自社がどれに当たるかを見分ける

自社のシステムがどの構成をとっているかが分かると、切替時間の期待値も、確認すべき運用項目も具体的になります。ここでは代表的な構成パターンと、ベンダー資料からの見分け方を整理します。

アクティブ・スタンバイ構成（ホットスタンバイ／コールドスタンバイの違い）

アクティブ・スタンバイは、片方（アクティブ）が実際の処理を担い、もう片方（スタンバイ）は待機に徹する構成です。待機の「温度」によって、さらに3種類に分かれます。

• ホットスタンバイ：待機系のサーバーとアプリケーションが起動済みで、データも継続的に同期されている状態です。切替は最も速く、数十秒程度で完了することもあります。その分、待機系のリソース費用が常時発生します。
• ウォームスタンバイ：サーバーは起動しているが、アプリケーションの一部が停止していたり、データ同期の間隔が長かったりする状態です。切替には数分から数十分程度かかります。
• コールドスタンバイ：待機系は停止しており、障害時に起動してデータを復元してから使い始める状態です。費用は最も安く済みますが、切替には数時間かかることもあり、実質的には「手動復旧」に近い運用になります。

「スタンバイ機がある」と説明されていても、それがホットなのかコールドなのかで復旧時間は桁違いに変わります。ここは必ず確認したいポイントです。

アクティブ・アクティブ構成

アクティブ・アクティブは、複数のサーバーが常に処理を分担して稼働している構成です。1台が停止しても残りの台数で処理を継続できるため、切替という明確な瞬間が存在せず、利用者から見た停止時間は最小になります。

一方で、常時2系統以上を稼働させるためのコストがかかり、複数のサーバーが同時にデータを更新する場合はデータ整合性の設計が複雑になります。また、平常時に2台で処理していた負荷を1台で受けることになるため、1台が停止した際に性能が不足しないだけの余力を持たせておく設計が必要です。「止まらないが遅くなる」状態を許容できるかは、業務要件に照らして判断する必要があります。

構成別の切替時間・コスト・運用負荷の比較

なお、待機系へのデータ同期方式も切替時の結果を左右します。同期レプリケーションは本番系への書き込みを待機系にも反映してから完了とするため、データの欠落は理論上起きませんが、書き込み性能に影響します。非同期レプリケーションは本番系の書き込みを優先し、待機系への反映は遅れて行われるため、性能は保てますが、障害の瞬間に反映が間に合っていない分のデータが失われます。「切替は速いがデータは少し失われる」のか「データは失われないが書き込みが遅い」のかは、業務上の許容度に照らして選ぶべきトレードオフです。

ベンダー資料から自社の構成を見分けるポイント

構成図を技術的に読み解けなくても、次の観点をベンダーに質問すれば、おおよその構成は判別できます。

いずれも技術的な検証ではなく、事実の確認です。回答が曖昧な場合や、資料に明記されていない場合は、その時点で運用実態が把握されていない可能性を疑ってよいでしょう。

サーバー単位の切替と、災害時の DR 切替の守備範囲の違い

フェイルオーバーの話をしていると、しばしば「災害対策」と混同されます。両者は守備範囲が異なります。

フェイルオーバーが対象とするのは、主にサーバーやサービス単位の障害です。ハードウェアの故障、OS のハングアップ、特定のデータセンター群（アベイラビリティゾーン）の停止などが該当し、切替先は同一リージョン内であることが一般的です。

一方、DR（Disaster Recovery：災害復旧）が対象とするのは、地震や大規模停電など、地域一帯が使えなくなる事態です。切替先は地理的に離れた別拠点となり、データの転送距離が長いぶん、同期方式や切替手順もフェイルオーバーとは別に設計されます。切替の判断も自動ではなく、経営判断を含む人の意思決定を伴うことが一般的です。

内閣府の事業継続ガイドライン（2023年3月版）でも、事業継続計画は「目標復旧時間内に重要な機能を再開させる」ための枠組みとして位置づけられており、システム単体の切替設計より広い視点で検討すべき対象とされています。「サーバーが1台壊れたときの備え」と「本社ごと使えなくなったときの備え」は別物として整理しておきましょう。事業継続計画の枠組みそのものについてはBCPとDRの違いで解説しています。

—Free Download / 資料ダウンロード

失敗しないためのシステム保守の引継ぎチェックリスト

この資料でわかること

システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。

こんな方におすすめです

• 現在の保守会社のサービスに不満を感じている方
• 保守会社の変更を検討しているが、何から始めればよいか分からない方
• 引継ぎ作業でトラブルを避けたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

「切り替わるはず」が切り替わらない｜フェイルオーバーが失敗する典型パターン

ここからが本題です。設計上はフェイルオーバー構成になっているのに、実際の障害では切り替わらなかった、あるいは切り替わったのに復旧しなかった。こうしたケースには典型的なパターンがあります。それぞれ「なぜ起きるか」と「発注者が事前に気づくには何を確認すればよいか」をセットで見ていきます。

監視対象がずれていて異常を検知できない

最も多いのが、監視の粒度が浅く、実際の障害を「異常」と判定できないケースです。サーバーは応答を返し、プロセスも起動しているのに、アプリケーションが内部で詰まって画面が表示されない。この状態は、疎通確認やプロセス監視だけでは検知できません。

クラウドのマネージドサービスでも同様の線引きがあります。Amazon RDS のマルチ AZ 配置では、自動フェイルオーバーが実行されるのはアベイラビリティゾーンの可用性喪失やプライマリの障害といったインフラ側の事象であり、長時間実行クエリ・デッドロック・データベース破損といったデータベース操作上のエラーに対しては自動フェイルオーバーは行われない、と明記されています（Amazon RDS マルチ AZ）。つまり「マルチ AZ にしてあるから安心」ではなく、「マルチ AZ が守る障害の種類」を理解しておく必要があるということです。

発注者が確認すべきこと：「どのような状態になったら自動で切り替わりますか。逆に、切り替わらない障害にはどのようなものがありますか」と質問し、切替の対象となる事象の一覧を書面で受け取ります。過去の障害がその一覧に含まれていたかどうかを照合すれば、監視設計の妥当性を評価できます。

待機系が最新でない（データ同期の遅延・パッチ／証明書の未適用）

待機系は平常時に使われないため、劣化が発覚しにくいという構造的な弱点があります。よくあるのは次のような状態です。

• データ同期の処理が数か月前にエラーで停止しており、待機系のデータが古いまま放置されている
• 本番系にだけアプリケーションの更新が適用され、待機系のバージョンが古い
• SSL/TLS 証明書が本番系のみ更新され、待機系の証明書が期限切れになっている
• OS やミドルウェアのセキュリティパッチが本番系にしか当たっていない

この状態で切り替わると、古いデータで業務が再開されたり、証明書エラーで利用者がアクセスできなかったりします。切替という動作自体は成功しているため、原因の特定にも時間がかかります。

発注者が確認すべきこと：「待機系のデータ同期が正常に動作していることを、どのように確認していますか」「その確認結果は月次報告に含まれますか」と質問します。同期エラーの監視・通知が設定されているか、証明書やパッチの適用対象に待機系が含まれているかを、運用手順書のレベルで確認できると理想的です。

両系が同時に稼働してしまう（スプリットブレイン）

ネットワークの分断によって、本番系と待機系がお互いを「相手が落ちた」と誤認し、両方が本番として動き出してしまう状態をスプリットブレインと呼びます。両系が同じデータ領域に書き込もうとするため、データの不整合や破損につながる、非常にやっかいな障害です。

この問題を防ぐ代表的な仕組みがクォーラム（多数決）です。Microsoft の解説では、クォーラムは「ネットワークにパーティションがあり、ノードのサブセットが相互に通信できない場合に発生する可能性があるスプリットブレインシナリオを防ぐために設計」されており、ノードのグループのうち1つだけが稼働を継続するよう制御すると説明されています（クラスターとプールのクォーラムについて）。

発注者が確認すべきこと：「本番系と待機系の通信が途切れた場合、どちらが稼働を継続すると判断されますか」「その判断の仕組みは何ですか」と質問します。専門的な回答が返ってきても構いません。重要なのは、この論点が設計時に検討されていたかどうかが分かることです。

切替は成功したのに利用者がつながらない

切替そのものは正常に完了したのに、利用者からは復旧して見えない、というケースもあります。原因は接続経路側にあります。

• DNS キャッシュ：DNS で切り替える方式の場合、利用者側の端末やネットワーク機器に古い接続先が残り、キャッシュの有効期間（TTL）が切れるまで旧系にアクセスし続けます。
• アプリケーションの接続保持：データベースへの接続を再利用する仕組み（コネクションプール）を使っている場合、古い接続を掴んだままエラーを返し続けることがあります。前述のとおり、切替を前提としたリトライの実装が必要です。
• 外部連携先の IP 許可設定：取引先システムやオンライン決済サービスなど、接続元 IP アドレスを制限している連携先がある場合、待機系の IP アドレスが許可リストに登録されていなければ連携だけが止まります。
• バッチ処理やジョブの起動元：定時バッチの実行サーバーが旧系を直接指定している場合、切替後にバッチだけが動かなくなります。

発注者が確認すべきこと：「切替後、外部との連携（決済・EDI・取引先システム）は自動で追従しますか」「切替時に手動で必要な作業は残っていますか」を確認します。特に外部連携がある業務システムでは、この観点の抜けが実害に直結します。

一度も切替テストをしていない

そして、これらすべてを覆う最大のリスクが、切替テストが一度も実施されていないことです。フェイルオーバーは、設定した時点では「動くはず」の状態にすぎません。実際に切り替えてみるまで、待機系が使える状態にあるかも、切替に何分かかるかも、外部連携が追従するかも分かりません。

テストが実施されていない理由の多くは、悪意ではなく「業務を止めてまでテストする理由を誰も説明できなかった」ことにあります。テストには計画停止か、少なくとも夜間・休日の作業時間が必要で、これは費用と調整コストを伴います。契約に実施義務が書かれていなければ、優先順位が下がるのは自然な帰結です。

発注者が確認すべきこと：「直近のフェイルオーバーテストはいつ実施しましたか。結果の記録はありますか」。この1問が、フェイルオーバーの実効性を測る最も強力な質問です。日付と記録が即答できる体制であれば、他の項目も管理されている可能性が高く、逆に回答が曖昧であれば、構成図に何が書かれていても実効性は未検証と考えるべきです。

保守契約でフェイルオーバーについて確認すべき5つの点

ここまで見てきた失敗パターンは、技術の問題であると同時に、運用と契約の問題です。誰がテストを実施するのか、誰が待機系を維持するのか、切り戻しの費用は誰が負担するのか。これらが契約に書かれていなければ、実施されなくても契約違反にはなりません。

以下では、保守契約の見直しや更新の場で確認したい5つの点を挙げます。なお、契約形態そのもの（準委任か請負か、どこまでが役務の範囲か）の考え方については保守契約の種類で整理していますので、本記事では可用性・切替に関する条項に絞ります。

切替は自動か、連絡後の手動か。対応時間帯はどこまでか

まず確認すべきは、切替が本当に自動なのか、それとも「監視で検知 → ベンダーへ通知 → 担当者が判断して手動で切替」という運用なのかです。後者の場合、実際の復旧時間は担当者が着手するまでの時間に大きく左右されます。

あわせて対応時間帯を確認します。監視が24時間365日でも、人の対応が平日9〜18時であれば、金曜の深夜に起きた障害の手動切替は月曜朝になる可能性があります。

• 契約書のどこを見るか：「サービス提供時間」「対応時間」「受付時間」「一次対応」「緊急連絡」といった項目
• 曖昧なときの依頼：「自動切替の対象となる障害」と「手動対応が必要な障害」を分けて明記し、それぞれの対応開始までの目標時間（受付から着手までの時間）を記載してもらう

稼働率（SLA）と RTO・RPO が整合しているか

保守契約には「稼働率99.9%」といった目標値が書かれていることがあります。まず、この数値が実際に何分の停止を許容しているかを把握しておきましょう。

ここで重要なのが、RTO（目標復旧時間）と RPO（目標復旧時点）との整合です。RTO は「停止からどれだけの時間で復旧させるか」、RPO は「どの時点までのデータを復旧できれば許容できるか」を示します。内閣府の事業継続ガイドラインでも、目標復旧時間は業務停止が許容できる時間として位置づけられており、IPA の非機能要求グレードでも可用性を稼働率や目標復旧時間といった指標で段階的に定義する枠組みが提供されています。

チェックすべき不整合は次の3点です。

1. 稼働率と RTO の矛盾：稼働率99.9%（月43分）を掲げながら、RTO が4時間と定義されている場合、1回の障害で年間の許容枠を使い切ります。
2. RPO と同期方式の矛盾：RPO を「0（データ損失なし）」としながら、待機系へのデータ同期が非同期であれば、障害時に一定量のデータが失われます。
3. 計画停止の除外範囲：稼働率の計算から計画メンテナンスを除外する条項があるかを確認します。除外されていること自体は一般的ですが、除外できる時間の上限や事前通知の期限が定められているかは確認が必要です。

• 契約書のどこを見るか：「サービスレベル」「稼働率」「復旧目標」「除外事項」「免責事項」
• 曖昧なときの依頼：稼働率だけでなく RTO・RPO を数値で併記してもらい、その数値が現在の構成で実現可能である根拠（切替方式・同期方式）をセットで説明してもらう

フェイルオーバーテストの実施頻度・実施主体・費用負担

前述のとおり、実施義務が契約に書かれていなければ、切替テストは後回しになりがちです。次の4点を明記できているかを確認します。

• 頻度：年1回、半年に1回など。システムの重要度と変更頻度に応じて決めます

• 実施主体：ベンダーが実施するのか、発注側の立ち会いが必要か

• 実施内容：本番環境で実際に切り替えるのか、検証環境での確認にとどめるのか

• 費用負担：月額保守に含むのか、都度見積もりか。夜間・休日実施の割増があるか

• 契約書のどこを見るか：「定期作業」「保守作業の範囲」「別途費用」「作業実施の条件」

• 曖昧なときの依頼：「年1回のフェイルオーバーテストの実施と結果報告書の提出」を保守業務の一項目として明記してもらう。費用負担の区分（月額に含む／別途見積もり）も併記する

なお、実際の本番環境で切替テストを行うには停止時間の調整が必要です。大がかりな実施が難しい場合でも、検証環境での切替確認や、待機系の起動確認・データ同期状態の確認といった簡易な点検を定期実施項目に入れておくだけで、実効性は大きく変わります。

フェイルバック作業と原因調査は月額保守の範囲か、追加費用か

切替が発生した後には、必ず「元に戻す作業」と「原因を調べる作業」が発生します。ここが契約上の空白地帯になりやすい部分です。

障害対応（切替と復旧）は月額保守に含まれていても、切り戻し作業やデータ再同期、原因調査の報告書作成は「別途作業」と解釈されることがあります。障害の直後は費用交渉をしている余裕がないため、事前に定義しておくことが重要です。

• 契約書のどこを見るか：「障害対応の範囲」「復旧作業」「原因調査」「報告義務」「別途費用となる作業」
• 曖昧なときの依頼：障害発生から通常状態への復帰までを「一次対応（切替）」「二次対応（切り戻し・再同期）」「原因調査と報告」の3段階に分け、それぞれが月額に含まれるかを明記してもらう。報告書の提出期限（例：障害終息後10営業日以内）も定めておくと、後追いの負担が減ります

待機系の維持管理（データ同期・パッチ・証明書更新）の責任分界

最後に、平常時の維持管理です。待機系が最新でない問題は、責任の所在が曖昧なまま放置されることで発生します。

次の項目について、誰が実施し、誰が確認するのかを整理します。

責任分界の考え方については、IPA が公開している情報システム・モデル取引・契約書（第二版）のように、発注者と受注者の役割分担を明文化する枠組みが参考になります。「どちらもやっていると思っていた」を防ぐには、項目ごとに主担当を1つに決めておくことが有効です。

• 契約書のどこを見るか：「業務分担表」「役割分担」「定期報告」「保守対象範囲」
• 曖昧なときの依頼：保守対象の一覧に待機系のサーバー・証明書・同期処理を明示的に列挙してもらう

フェイルオーバーの実効性を確かめる発注者向けチェックリスト

最後に、打ち合わせや契約更新の場でそのまま使える確認項目をまとめます。技術的な検証はできなくても、「記録があるか」「書面に定義されているか」という観点であれば、非エンジニアの担当者でも確実に確認できます。

ベンダーへの確認質問リスト

すべてに即答が返ってくる必要はありません。回答が曖昧だった項目こそ、契約更新時に明文化を依頼すべき箇所です。

月次報告書で継続的に確認する項目

一度確認して終わりにせず、月次の運用報告で継続的に見ておきたい項目です。

• 稼働率の実績値と目標値の対比：目標を下回った月に、原因と対策が記載されているか
• 切替の発生有無：発生していた場合、原因・所要時間・利用者への影響が記載されているか
• 待機系の点検結果：データ同期の状態、待機系のパッチ適用状況
• 監視アラートの発生件数と対応内容：検知した異常のうち、切替に至らなかったものの扱い
• 証明書・ライセンスの有効期限：本番系だけでなく待機系の分も記載されているか

これらが報告書のフォーマットに含まれていない場合は、次回以降の追加を依頼しておくとよいでしょう。継続して記録が残ること自体が、実効性を保つ仕組みになります。

経営層への説明で使える言い換え

社内説明の場では、正確さと分かりやすさを両立させる表現が必要です。次のような言い換えが有効です。

「止まらない」ではなく「◯分以内に復旧する設計で、この条件では止まる」と条件付きで説明できると、障害が実際に起きたときの認識のずれを防げます。加えて、切替テストの実施記録を根拠として提示できれば、説明の信頼性は大きく高まります。

まとめ｜フェイルオーバーは「設定済み」ではなく「検証済み」かで判断する

フェイルオーバーは、稼働中のシステムに異常が発生したときに、あらかじめ用意した待機系へ処理を自動的に引き継がせる仕組みです。ただし、それは「異常を検知する条件が実態と合っている」「待機系が使える状態に維持されている」「接続先の付け替えが利用者と外部連携まで届く」という3つの前提のうえに成り立っています。冗長化された設備があることと、それが実際に切り替わることは、別の話です。

そして、この3つの前提を担保するのは技術ではなく運用と契約です。切替テストの実施義務、待機系の維持管理の責任分界、切り戻しと原因調査の費用負担。これらが契約に書かれていなければ、実施されなくても誰の落ち度にもなりません。だからこそ、発注側が確認すべきなのは構成図の正しさではなく、記録と条項の有無なのです。

保守契約の更新前に確認したい点を、最後に3つに絞ってまとめます。

1. 直近のフェイルオーバーテストの実施日と結果記録があるか：日付と記録が即答できるかどうかが、実効性を測る最も端的な指標です
2. 稼働率と RTO・RPO が数値で併記され、現在の構成と整合しているか：目標値だけが独り歩きしていないかを確認します
3. 切り戻し作業・原因調査・待機系の維持管理が、月額保守の範囲として明記されているか：障害後に費用交渉が発生しない状態にしておきます

この3点を押さえておけば、「冗長化してあるので大丈夫です」という説明に対して、「では直近のテストはいつですか」と一歩踏み込んだ確認ができます。フェイルオーバーが設定済みかどうかではなく、検証済みかどうか。この視点を持つことが、障害時に説明責任を果たせる状態への第一歩になります。

関連情報

保守運用の体制やベンダーとの役割分担を見直したい方は、失敗しないためのシステム保守の引継ぎチェックリストをご活用ください。保守範囲の確認項目や引き継ぎ時の抜け漏れを点検するための資料としてまとめています。

現在の保守契約や可用性の設計が自社の要件に合っているか判断が難しい場合は、お問い合わせフォームからご相談いただけます。現状の構成整理の段階からご相談を承っています。

—Free Download / 資料ダウンロード

失敗しないためのシステム保守の引継ぎチェックリスト

この資料でわかること

システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。

こんな方におすすめです

• 現在の保守会社のサービスに不満を感じている方
• 保守会社の変更を検討しているが、何から始めればよいか分からない方
• 引継ぎ作業でトラブルを避けたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。