fail-fastとは?早く失敗する設計の話

fail-fast = 「おかしいと気づいた瞬間に止まる」

fail-fast(フェイルファスト)は、直訳すると「速く失敗する」。プログラムや処理が、何かおかしい状態を検知したら、そのまま進まずにすぐエラーとして止まる、という考え方です。

逆の態度は「とりあえず進めてみる」。値が空っぽでも、設定ファイルが見つからなくても、デフォルト値で誤魔化してそのまま突っ走る。一見親切に見えますが、これは後で痛い目を見ます。

料理で例えると

カレーを作っていて、冷蔵庫を開けたら肉がなかったとします。

どちらも最終的に「カレーができない」という結果は同じです。違うのは、気づくのが早いか遅いか、そして無駄になったコストの大きさ。fail-fastは前者を選ぶ設計思想です。

なぜ早く失敗したほうがいいのか

一番大きいのは原因が分かりやすいことです。おかしくなった直後に止まれば、「直前にやったこと」が原因だと即座に分かります。ところが10ステップ先まで進んでから壊れると、どこで狂ったのか探す作業から始まってしまう。

もうひとつは壊れた状態で動き続ける危険を避けられること。中途半端なデータのまま処理が進むと、ファイルを上書きしたり、間違った内容を保存したりと、後始末が面倒な被害が広がります。止まっていれば何も起きません。

具体的にはこういうコード

たとえば設定ファイルを読み込む処理を考えてみます。

# fail-fastではない書き方
config = load_config()
api_key = config.get("api_key", "")  # なかったら空文字
send_request(api_key)  # 空のキーで通信 → 意味不明な401エラー

# fail-fastな書き方
config = load_config()
if "api_key" not in config:
    raise ValueError("api_key が設定ファイルにありません")
send_request(config["api_key"])

下の書き方だと、エラーメッセージを見た瞬間に「あ、設定ファイルに書き忘れた」と分かります。上だと、なぜか通信が失敗する謎に何十分も悩むことになりがちです。

Claude Codeを使うときの話

AIにコードを書かせるときも、この考え方は効いてきます。AIは「それっぽく動くコード」を書くのが得意なぶん、エラーを握りつぶして空の値を返すような、表面上は動いているように見えるコードを生み出すこともあります。

そこで指示の時点で「入力が不正なら例外を投げて止めて。フォールバックで誤魔化さないで」と伝えておくと、後から原因を追いかける手間がぐっと減ります。テストやビルドも同じで、エラーが出たら即座に止まる設定にしておけば、壊れたものが先の工程に流れていきません。

やりすぎ注意のポイント

何でもかんでも止めればいいわけでもありません。ユーザーが使っているアプリが、ちょっとした通信の乱れで毎回強制終了したら困ります。

ざっくり言うと、開発中・内部処理ではfail-fast寄り、ユーザーに見える境界では丁寧にエラーを扱うのがバランスのいいところ。「想定外の状態」は止める、「想定内の失敗(ネットが一時的に不安定など)」はリトライや案内で対応する、と分けて考えると整理しやすいです。

覚えておきたいこと

fail-fastは難しいテクニックではなく、「怪しいと思ったら見ないふりをしない」という態度の話です。デバッグで消耗した経験がある人ほど、この考え方のありがたみが分かるはず。エラーを隠すコードを書きそうになったら、一度立ち止まってみてください。