フェールセーフ・フールプルーフ・フェールソフトの違いとは？信頼性設計の考え方

2026 8/08

2026年8月8日

システムの信頼性設計を学び始めると、「フェールセーフ」「フールプルーフ」「フェールソフト」「フォールトトレランス」といった似た響きの用語が次々に登場します。どれも「トラブルに強いシステムを作るための考え方」ではあるものの、狙っているタイミングも、故障後にシステムがどうなるかも、まったく異なります。

この記事では、混同されやすい4つの概念に加えて「フォールトアボイダンス」を含めた5つを、比較表と具体例で整理します。さらに、設計しただけでは意味がない——つまりその設計が本当に機能するかをソフトウェアテストでどう検証するのかまで踏み込んで解説します。基本情報技術者試験の対策として調べている方にも、実際にサービスの可用性設計を任された方にも使える内容にまとめました。

まず結論：4つの違いは「いつ」と「故障後どうなるか」で分かれる

細かい定義に入る前に、全体像をつかんでおきましょう。4つの概念は、次の2つの軸で整理すると一気に見通しが良くなります。

いつ効くのか：故障や誤操作が「起きる前」に効くのか、「起きた後」に効くのか
その結果どうなるのか：システムが止まるのか、機能を減らして動き続けるのか、何事もなかったように動き続けるのか

この2軸で並べると、次のようになります。

概念	効くタイミング	その結果	ひとことで言うと
フールプルーフ	誤操作が起きる前	そもそも操作が受け付けられない	間違えさせない
フェールセーフ	故障が起きた後	安全な状態で停止する	危険な側に倒さない
フェールソフト	故障が起きた後	機能を減らして動き続ける	全部は止めない
フォールトトレランス	故障が起きた後	正常なまま動き続ける	止まらない

フールプルーフだけが「予防」の思想で、残りの3つは「起きてしまった後の振る舞い」を決める思想です。そして残り3つの違いは、故障後にシステムがどこまで動き続けるかという一点に集約されます。停止するのがフェールセーフ、一部動くのがフェールソフト、全部動くのがフォールトトレランスです。

なぜ「故障しない設計」だけでは足りないのか

信頼性設計の出発点は、ある割り切りにあります。それは「どんなに丁寧に作っても、機械はいつか壊れるし、人はいつか操作を間違える」という前提です。

部品の品質を上げ、レビューを厚くし、テストを増やせば故障率は下がります。しかしゼロにはなりません。ハードウェアは経年劣化しますし、ネットワークは切れますし、想定外の入力は必ずやってきます。ならば「壊れないようにする努力」と並行して、「壊れたときに何が起きるかを設計しておく」必要がある——これが信頼性設計の基本的な発想です。

この2つの態度には、それぞれ名前が付いています。

フォールトアボイダンス（Fault Avoidance）：そもそも故障を起こさないよう、品質を高めて信頼性を上げるアプローチ
フォールトトレランス（Fault Tolerance）：故障は起きるものと認め、起きても影響が出ないようにするアプローチ

フェールセーフ・フールプルーフ・フェールソフトは、このうち後者の系譜にある具体的な設計手法だと捉えると、位置づけがすっきりします。それでは、ひとつずつ見ていきましょう。

フェールセーフ（Fail Safe）とは：故障したら安全な側へ倒す

定義：故障の影響を「危険でない方向」に限定する

フェールセーフとは、システムに故障が発生した際、必ず安全な状態に移行するようにあらかじめ設計しておく考え方です。英語の「fail safe」がそのまま示すとおり、「失敗するなら安全に失敗せよ」という思想です。

ここで重要なのは、フェールセーフはシステムを動かし続けることを目的にしていないという点です。むしろ多くの場合、システムは停止します。停止すること自体は目的ではなく、「中途半端に動いて人や資産に危害を加えるくらいなら、確実に止まったほうがマシだ」という優先順位の表明なのです。

身近な例

踏切の遮断機：停電したり制御装置が故障したりすると、遮断機は「降りた状態」になります。上がったまま止まれば列車と車が衝突しますが、降りたまま止まれば渋滞は起きても事故は起きません。
信号機：制御装置に異常が出たとき、全方向を赤（または黄点滅）にします。青のまま固まるのが最も危険だからです。
石油ストーブの転倒時消火装置：倒れたことを検知したら、暖房という本来の機能を放棄して即座に消火します。
ガス機器の立ち消え安全装置：炎が消えたのを検知したらガスの供給を止めます。供給し続ければガス漏れになります。

ソフトウェア開発での実装例

ソフトウェアの世界でも、フェールセーフの考え方は随所に現れます。

認可判定のデフォルト拒否（Deny by default）：権限チェックの処理で例外が発生した場合、「判定できなかったので通す」ではなく「判定できなかったので拒否する」を既定の動作にします。セキュリティ設計における代表的なフェールセーフです。
決済処理の中断：外部決済APIからの応答が不明瞭なとき、「たぶん成功しただろう」と処理を進めず、明示的にエラーとして中断し、後続の照合処理に委ねます。
バッチ処理のアボート：入力データの整合性チェックに失敗したら、部分的に書き込むのではなくトランザクションごとロールバックして止まります。
ウォッチドッグタイマー：一定時間内に応答がないプロセスを、異常とみなして安全に停止・再起動させます。

「エラー時にどちらへ倒すか」を明示的に決めていないコードは、フェールセーフではありません。何も決めていない場合、たいていは「たまたま通ってしまう」という最悪の側に倒れます。

フールプルーフ（Fool Proof）とは：そもそも間違えられなくする

定義：誤操作を「してはいけない」ではなく「できない」にする

フールプルーフは、利用者が知識を持たなくても、あるいは不注意であっても、危険な操作や誤った操作ができないように設計する考え方です。「fool（愚か者）でも proof（耐えられる）」という語源どおり、利用者のスキルや注意力に依存しないことを目指します。製造業の現場では「ポカヨケ」という日本語で呼ばれることもあります。

フェールセーフとの決定的な違いは、効くタイミングが「故障の後」ではなく「操作の前」だという点です。フールプルーフが対象にするのは機械の故障ではなく、人間のヒューマンエラーです。

ここで注意したいのは、「注意喚起の張り紙をする」「マニュアルに赤字で書く」はフールプルーフとしては弱い、ということです。本来のフールプルーフは、物理的・構造的に誤操作を不可能にすることを狙います。人間の注意力に頼った時点で、いずれ誰かが間違えます。

身近な例

電子レンジ：扉が開いている状態では加熱が始まりません。「開けたまま動かさないでください」と書くのではなく、動かせなくしています。
洗濯機の蓋：脱水中に蓋を開けると回転が止まります。
USB Type-Cやコンセントの形状：物理的な形で、誤った向き・誤った差し込み先を防ぎます。SIMカードの切り欠きも同じ発想です。
自動車のシフトロック：ブレーキを踏まないとPレンジから動かせません。
ATMのカード取り忘れ防止：現金を出す前にカードを返却する順序にすることで、取り忘れという誤りを構造的に減らします。

ソフトウェア開発での実装例

入力バリデーション：数値項目に文字を入れさせない、必須項目が空なら送信ボタンを押させない、範囲外の値を弾く。フールプルーフの最も典型的な実装です。
UIによる選択肢の制限：日付をテキスト自由入力にせずカレンダーピッカーにする、都道府県をプルダウンにする。入力の自由度を下げることで誤りの余地を消します。
危険操作の二段階確認：本番データの削除時に、リソース名を手で入力させてから実行させる。
型システムによる制約：ユーザーIDと注文IDをどちらも整数型にせず、別の型として定義することで、引数の取り違えをコンパイル時に検出します。
権限に応じたUI制御：実行できない操作のボタンをそもそも表示しない（ただしサーバー側の権限チェックは別途必須です）。

入力バリデーションの範囲をどう決めるかは、テスト設計の技法と密接に関係します。境界となる値の扱いについては境界値分析の基礎と実践で詳しく解説していますので、あわせて参照してください。

フェールソフト（Fail Soft）とは：機能を縮退させて動き続ける

定義：全面停止を避け、性能や機能を落として継続する

フェールソフトは、故障が発生してもシステム全体を停止させず、影響を受けた部分を切り離して、残った機能で運転を継続する考え方です。このときの縮退した運転状態をフォールバック運転または縮退運転（デグレード運転）と呼びます。

フェールセーフとの違いは明確です。フェールセーフが「止めることで安全を確保する」のに対し、フェールソフトは「止めないことを優先し、そのために品質を犠牲にする」。どちらが正しいかは、そのシステムにとって「停止」と「劣化した稼働」のどちらが許容できるかで決まります。

具体例

航空機のエンジン：複数あるエンジンのうち1基が停止しても、残りのエンジンで飛行を継続します。速度や高度には制限がかかりますが、空中で全停止するよりはるかにマシです。
Webサービスの機能縮退：レコメンド機能を提供する外部APIが落ちたとき、サイト全体をエラーにするのではなく、レコメンド欄だけを非表示にして商品購入は継続できるようにします。
ECサイトのアクセス集中時：レビュー表示やポイント計算といった付加機能を一時停止し、カート投入と決済という中核機能にリソースを集中させます。
マルチコアCPUの縮退：一部のコアに異常が出たとき、そのコアを切り離して残りで処理を続けます。

ソフトウェア実装の中心：サーキットブレーカー

マイクロサービス構成でフェールソフトを実現する代表的なパターンがサーキットブレーカーです。呼び出し先のサービスでエラー率が閾値を超えたら、回路を「開いた」状態にして呼び出しそのものを止め、即座にフォールバック値（キャッシュ済みデータや既定値）を返します。

これには2つの効果があります。ひとつは利用者への影響を機能限定にとどめること、もうひとつは応答しない相手を叩き続けて障害を連鎖させない（カスケード障害の防止）ことです。関連するパターンとしては、タイムアウトの明示設定、リトライ回数の上限、バルクヘッド（リソースの隔離）、レートリミットなどがあります。

フォールトトレランスとは：故障しても正常動作を維持する

定義：冗長化によって、故障を利用者に見せない

フォールトトレランスは、構成要素の一部に故障が発生しても、システム全体としては正常な機能を維持し続けるという考え方です。実現手段の中心は冗長化——同じ役割を担う要素を複数持っておき、片方が倒れたらもう片方が引き継ぐという構成です。

フェールソフトとの違いは「故障後の性能・機能をどこまで保てるか」にあります。フェールソフトは劣化を受け入れますが、フォールトトレランスは劣化させないことを目指します。理想的なフォールトトレランス構成では、利用者は障害が起きたことにすら気づきません。

具体例

RAID構成のストレージ：RAID1やRAID5では、ディスクが1台故障してもデータは失われず読み書きが継続できます。
多重化されたサーバー群：ロードバランサ配下に複数のアプリケーションサーバーを並べ、ヘルスチェックに失敗したサーバーを自動的に切り離します。
データベースのレプリケーションと自動フェイルオーバー：プライマリが停止したらスタンバイが昇格して処理を引き継ぎます。
電源の二重化とUPS：商用電源が落ちても給電が途切れません。
マルチAZ／マルチリージョン構成：データセンター単位の障害にも耐えられるよう、地理的に分散させます。

冗長化には方式の違いがある

方式	待機側の状態	切替時間	コスト
ホットスタンバイ	常時起動し同期している	数秒以内	高い
ウォームスタンバイ	起動しているが同期は限定的	数分程度	中程度
コールドスタンバイ	停止している	数十分〜数時間	低い
デュアルシステム	2系統が同じ処理を並行実行し結果を照合	実質ゼロ	非常に高い

「冗長化しています」という一言の中に、これだけの幅があります。要件定義の段階でRTO（目標復旧時間）とRPO（目標復旧時点）を決めておかないと、想定より遅い切替方式を選んでしまい、いざというときに事業要件を満たせません。

フォールトアボイダンスとフォールトトレランスの対比

ここで、冒頭で触れたフォールトアボイダンスにあらためて焦点を当てます。これは「故障そのものを起こさせない」というアプローチで、フォールトトレランスとは対になる概念です。

観点	フォールトアボイダンス	フォールトトレランス
基本姿勢	故障は起こさないようにする	故障は起きる前提で備える
主な手段	高品質な部品、レビュー、静的解析、十分なテスト、教育	冗長化、多重化、自動フェイルオーバー
効くタイミング	設計・実装・製造の段階	運用中に障害が起きた瞬間
限界	故障率をゼロにはできない	コストが増え、構成が複雑になる
ソフトウェアでの例	コーディング規約、単体テスト、コードレビュー	クラスタ構成、レプリケーション

実務では、この2つはどちらかを選ぶものではなく、両方を組み合わせるものです。フォールトアボイダンスで故障の発生確率そのものを下げ、それでもすり抜けた故障をフォールトトレランスやフェールソフトで受け止める——この二段構えが基本形になります。

なお、開発工程の中でどのタイミングにどの品質保証活動を置くかという観点は、Vモデルの基礎と実務での活用で体系的に整理しています。信頼性設計の要件をどのテストレベルで検証するかを決める際の土台になります。

5つの概念を一枚の表で総まとめ

ここまでの内容を、比較表として集約します。試験対策で暗記が必要な方も、設計方針を議論する場面でも、この表が判断の軸になります。

項目	フェールセーフ	フールプルーフ	フェールソフト	フォールトトレランス	フォールトアボイダンス
故障・誤操作を前提とするか	する（機械の故障）	する（人の誤操作）	する（機械の故障）	する（機械の故障）	しない（起こさせない）
対象とする原因	装置・部品・処理の異常	利用者のヒューマンエラー	構成要素の一部障害	構成要素の一部障害	設計・実装上の欠陥
発生後にシステムはどうなるか	安全な状態で停止する	そもそも発生させない	機能・性能を落として継続	正常なまま継続	発生を想定しない
最優先の目的	人命・資産の安全確保	誤操作の防止	サービス継続性	可用性の最大化	信頼性そのものの向上
身近な例	踏切の遮断機、信号機の赤固定	電子レンジの扉、USB Type-C	航空機のエンジン片系停止	RAID、多重化サーバー	高信頼部品、厳格な検査
ソフトでの例	認可のデフォルト拒否	入力バリデーション	サーキットブレーカー	自動フェイルオーバー	静的解析、コードレビュー
主なコスト	可用性を犠牲にする	UI設計・実装の手間	縮退時の設計が複雑	設備・運用コストが高い	品質活動の工数

よくある取り違えパターン

「エラー画面を出したからフェールセーフだ」：エラーを表示しただけでは不十分です。その時点でデータが中途半端に書き込まれていないか、外部システムへの通知が二重に飛んでいないか——安全側に倒れているかどうかが判定基準です。
「警告メッセージを出したからフールプルーフだ」：警告は人の注意力に依存します。本来のフールプルーフは操作自体を不可能にします。
「サーバーを2台にしたからフェールソフトだ」：2台構成で片方が落ちても性能が変わらないなら、それはフォールトトレランスです。性能が半分になることを許容する設計ならフェールソフトです。

実際のシステムでは、4つを組み合わせて使う

ここまで概念を分けて説明してきましたが、現実のシステムはひとつの思想だけで作られてはいません。同じシステムの中で、機能ごとに異なる方針が採用されます。

たとえば、あるECサイトを例に考えてみましょう。

機能	採用する設計思想	具体的な振る舞い
クレジットカード決済	フェールセーフ	応答が不明なときは処理を中断し、二重課金を絶対に起こさない
注文フォーム	フールプルーフ	不正な形式の入力を送信できないようUIとサーバーの両方で制限
おすすめ商品表示	フェールソフト	推薦APIが落ちたらブロックごと非表示にし、購入導線は維持
商品データベース	フォールトトレランス	レプリカへ自動フェイルオーバーし、利用者には影響を出さない
在庫引当ロジック	フォールトアボイダンス	境界値・並行処理のテストを厚くし、そもそも欠陥を作り込まない

この振り分けの判断基準はシンプルです。「その機能が誤った結果を返したとき、失われるものは何か」を問うこと。失われるのが人命や金銭ならフェールセーフ寄りに、失われるのが利便性ならフェールソフト寄りに倒します。決済で「とりあえず動かし続ける」のは論外ですし、レコメンド表示のためにサイト全体を落とすのも過剰です。

設計しただけでは意味がない：ソフトウェアテストでどう検証するか

ここからが本題と言ってもいい部分です。信頼性設計は、設計書に書いただけでは1ミリも機能しません。「障害時にフェイルオーバーします」と設計書に書かれていたのに、実際にプライマリを落としてみたら切り替わらなかった——という事故は、決して珍しくありません。

信頼性設計が厄介なのは、その振る舞いが「正常時には一度も実行されない」コードパスの上にある点です。普段動かないコードは、普段テストされません。だからこそ、意図的に異常を発生させて確認する工程が不可欠になります。

1. 異常系テスト（フールプルーフ・フェールセーフの検証）

最も基本となるのが異常系テストです。正常な操作ではなく、想定外・境界外の入力や操作を意図的に与えて、システムが設計どおりに振る舞うかを確認します。

入力値の異常系：桁あふれ、負数、ゼロ、空文字、NULL、制御文字、極端に長い文字列、想定外の文字コード
操作順序の異常系：戻るボタンの連打、二重送信、セッション切れ後の送信、複数タブでの同時操作
状態の異常系：ディスク容量枯渇、メモリ不足、コネクションプール枯渇
エラー後の状態確認：エラー画面が出たかではなく、データが中途半端に更新されていないかまで確認する

4番目が特に重要です。異常系テストの合否判定を「エラーメッセージが出ること」で済ませてしまうと、フェールセーフが成立しているかを検証したことになりません。異常終了後にシステムがどの状態にいるかを確認して初めて、安全側に倒れたと言えます。

どのテストレベルでどこまでの異常系を見るかについては、システムテストの種類一覧で全体像を確認しておくと、抜け漏れが減ります。

2. 障害注入テスト／カオスエンジニアリング（フェールソフトの検証）

フェールソフトの設計を検証するには、意図的に障害を注入する必要があります。これをフォールトインジェクション（障害注入テスト）と呼び、本番に近い環境で計画的に行う手法を一般にカオスエンジニアリングと呼びます。

注入する障害の代表例は次のとおりです。

依存サービスの停止：外部APIをモックで502や503を返す状態にし、サーキットブレーカーが開くか、フォールバック値が返るかを確認
レイテンシ注入：応答を意図的に10秒遅延させ、タイムアウト設定が効いているか、呼び出し元のスレッドが枯渇しないかを確認
パケットロス・ネットワーク分断：ノード間の通信を遮断し、スプリットブレインが起きないかを確認
リソース枯渇：CPUやメモリを意図的に消費させ、優先度の低い機能から縮退するかを確認
プロセス強制終了：ランダムにインスタンスを落とし、自己修復するかを確認

ここで検証すべきは「落ちなかったこと」だけではありません。縮退したことを運用チームが検知できるか——アラートが飛ぶか、ログに記録が残るか、ダッシュボードに反映されるか、までがセットです。誰にも気づかれないまま数週間縮退運転を続けていた、という事態は避けなければなりません。

カオスエンジニアリングは「本番でいきなり壊す」手法ではありません。仮説を立て、影響範囲（ブラストラディウス）を限定し、即座に停止できる手段を用意したうえで実施する、統制された実験です。

3. フェイルオーバーテスト（フォールトトレランスの検証）

冗長構成は「組んだ時点」ではなく「切り替わった時点」で初めて価値が確定します。フェイルオーバーテストでは、次の観点を実測します。

切替が起きるか：ヘルスチェックが異常を正しく検知し、自動で切り替わるか
切替時間はRTOを満たすか：検知から復旧完了までを秒単位で計測する
データ欠損はRPOを満たすか：切替の瞬間に処理中だったトランザクションがどう扱われたかを確認する
フェイルバックできるか：復旧した旧系に戻す手順が実行可能か。ここを試していない現場は非常に多いです
切替中の利用者影響：エラーを返した件数、リトライで救済できた件数

また、フェイルオーバー直後は残った系にすべての負荷が集中します。片系だけで本番相当の負荷を処理できるかを確認しない限り、「切り替わったが直後に共倒れした」という結末になりかねません。この検証は負荷テストの領域と重なります。設計手順は負荷テストのシナリオ設計手順を参考にしてください。

4. 概念ごとの検証手法対応表

検証したい設計	主なテスト手法	合否判定の観点
フールプルーフ	同値分割・境界値分析による異常系テスト、ユーザビリティテスト	不正な操作が受け付けられないこと。サーバー側でも弾かれること
フェールセーフ	異常系テスト、例外注入、電源断・強制終了試験	停止後の状態が安全であること。データが不整合でないこと
フェールソフト	障害注入テスト、カオスエンジニアリング、依存サービス停止試験	中核機能が継続し、縮退が検知・通知されること
フォールトトレランス	フェイルオーバーテスト、片系縮退時の負荷テスト、DR訓練	RTO／RPOを満たすこと。フェイルバックまで可能なこと
フォールトアボイダンス	単体テスト、静的解析、コードレビュー、回帰テスト	欠陥の作り込みと再発が抑えられていること

なお、信頼性設計に関わるコードは一度作ったら終わりではありません。リファクタリングや依存ライブラリの更新で、フォールバック処理が静かに壊れることがあります。異常系のテストケースこそ回帰テストの対象に含めるべきで、その運用方法はリグレッションテスト戦略の完全ガイドで解説しています。

機能安全とISO 26262：規格の世界での位置づけ

フェールセーフの考え方は、産業界では機能安全という枠組みの中で規格化されています。中心となるのが電気・電子・プログラマブル電子システムの機能安全を扱う国際規格IEC 61508で、そこから各産業向けに派生規格が定められています。

ISO 26262：自動車の電気・電子システム向け。危険度に応じてASIL（A〜D）というレベルを割り当て、レベルごとに要求される開発プロセスとテストの厳密さが変わります
IEC 62304：医療機器ソフトウェア向け
IEC 61511：プロセス産業（プラント）向け
DO-178C：航空機搭載ソフトウェア向け

これらの規格に共通するのは、「安全である」と主張するには、その根拠を文書とテスト結果で示さなければならないという要求です。設計思想としてフェールセーフを謳うだけでなく、ハザード分析を行い、安全要求を定義し、それを満たすことをテストで実証し、トレーサビリティを保つ——この一連の証跡が求められます。

一般的なWebサービスやアプリ開発でこれらの規格に準拠する必要はありませんが、「安全側の振る舞いを要求として明文化し、テストで確認し、記録を残す」という進め方は規模を問わず有効です。障害報告書を書く段になって「そもそもこの機能は落ちたときどうなるべきだったのか」を誰も定義していなかった、という事態を防げます。

信頼性設計チェックリスト

自分のプロジェクトに当てはめて確認できるよう、実務的なチェック項目を挙げます。

主要な機能ごとに「障害時にどうなるべきか」が要件として明文化されているか
外部連携すべてにタイムアウトが設定されているか（未設定はフェールソフトの最大の敵です）
リトライに上限と指数バックオフがあるか。リトライ自体が相手を殺していないか
権限チェックやバリデーションが、例外発生時に「拒否」側へ倒れる実装になっているか
フロントエンドのバリデーションが、サーバー側でも同等に実施されているか
縮退運転に入ったことを検知するアラートが設定されているか
フェイルオーバーを実際に実行した記録が、直近1年以内にあるか
片系のみで本番相当の負荷を捌けることを実測しているか
異常系のテストケースが回帰テストのスイートに含まれているか

このうち下の4項目にチェックが付かない現場は多いはずです。正常系の開発だけでスケジュールが埋まり、異常系の検証が後回しになるのは、どの組織でも起きる構造的な問題です。

異常系テストこそ、外部の目を入れる価値がある

信頼性設計の検証が後回しになりやすい理由は、工数不足だけではありません。もうひとつ、作った本人には異常系のシナリオが思いつきにくいという根本的な事情があります。

開発者は「このシステムはこう使われるはずだ」という前提を持って実装します。その前提が、そのままテストケースの前提にもなってしまう。結果として、想定内の異常しか試されず、想定外の異常——本番で実際に起きるのはたいていこちらです——は素通りします。フールプルーフの検証は特にこの影響を受けやすく、設計者が「こんな操作をする人はいない」と考えた操作を、利用者は普通にします。

ソフトウェアテスト代行サービス『テスター10』では、こうした開発チームの前提の外側にあるテスト観点を、第三者の視点で洗い出して実行します。異常系テストの観点設計、境界値・同値分割にもとづくバリデーション検証、障害注入を含むフェールソフトの確認、フェイルオーバー試験の計画と実施まで、必要な範囲だけを切り出してご依頼いただけます。

正常系は自社で担保できているが、異常系まで手が回らない
リリース前に第三者の視点で観点の抜け漏れを洗い出したい
フェイルオーバーテストを計画したいが、手順設計のノウハウがない
異常系のテストケースを整備して、回帰テストの資産として残したい

こうした課題に心当たりがあれば、まずは対象範囲と現状のテスト資産をお聞かせください。工程まるごとではなく、「異常系だけ」「フェイルオーバー試験だけ」といったスポット単位での支援も可能です。

よくある質問（FAQ）

Q. フェールセーフとフェールソフトは、どちらを選ぶべきですか？

「動き続けることで生じる危険」と「止まることで生じる損失」を比べて決めます。人命や重大な資産に関わる機能はフェールセーフを、止まると事業が止まるが誤作動しても危険が少ない機能はフェールソフトを選びます。ひとつのシステム内で機能ごとに使い分けるのが実務的です。

Q. フェールソフトとフォールトトレランスは同じものではないのですか？

近い関係ですが同じではありません。フォールトトレランスは「故障しても正常な状態を維持する」ことを目指し、フェールソフトは「性能や機能が落ちてもいいから継続する」ことを目指します。フェールソフトはフォールトトレランスを実現する手段のひとつと位置づけられることもありますが、達成水準が異なる点を押さえておけば混同しません。