Fail Fast:失敗は早く分かるようにする

入門 | 8分 で読める | 2026.06.18

公式ドキュメント

Fail Fastは、失敗するならできるだけ早く分かるようにする考え方です。

エラーを隠して処理を続けると、後ろの処理で原因が分かりにくい不具合になります。

一言でいうと

Fail Fastは、問題のある入力や状態を早い段階で検出し、原因が分かる形で止める考え方です。

「落ちないようにする」ことと「エラーを隠す」ことは違います。

悪い例

function calculateDiscount(price?: number) {
 if (!price) {
 return 0;
 }
 return price * 0.1;
}

price が渡されていない場合も、価格が0円の場合も、同じように 0 を返します。呼び出し側のバグが隠れる可能性があります。

Fail Fastの例

function calculateDiscount(price: number) {
 if (price < 0) {
 throw new Error("price must be greater than or equal to 0");
 }
 return price * 0.1;
}

不正な値を早く検出し、原因が分かるメッセージで止めます。

Fail Fastが大切な場面

場面早く検出したい理由
入力チェック不正データが奥まで入るのを防ぐ
設定値起動時に設定ミスを見つけたい
権限確認処理後半で拒否すると危険
外部APIレスポンス想定外形式を早く検知する
DB制約壊れたデータを保存しない

入口で検出できる問題は、入口で止めるほうが原因を追いやすいです。

エラーを握りつぶさない

try {
 await sendMail(user.email);
} catch (error) {
 // 何もしない
}

このように空の catch は危険です。失敗した事実が消えてしまいます。

最低限、ログを出す、利用者へ伝える、再試行する、上位へ投げ直すなど、方針を決めます。

ただし利用者体験も考える

Fail Fastは、ユーザーに雑なエラーを見せることではありません。

内部では早く検出し、画面では分かりやすいメッセージに変換します。たとえば「設定ファイルが壊れています」は開発者向けですが、利用者には「現在処理できません。時間をおいて再試行してください」と出す場合があります。

まとめ

Fail Fastは、問題を早く検出し、原因が分かる形で止める考え方です。

エラーを隠して処理を続けるより、入口で検出して明確に扱うほうが、デバッグと保守が楽になります。

参考リソース

関連記事

← 一覧に戻る
PR
PR
PR
PR