開発における「フォールバック」について

フォールバックは、必要な場面もありますが、害になる場面もあります。自分のコード内部のバグを「なかったこと」にしてしまうとき、エラーを握りつぶして問題の発見を遅らせるとき、本来落ちるべきところが静かに動き続けるときです。

特に厄介だと感じるのは、フォールバックが問題を隠すケースです。本来なら早く気づいて直すべきバグが、フォールバックのおかげで表面化せず、ずっと後になってもっと厄介な形で現れます。

「壊れたら早く知りたい」（fail fast）と「壊れても動き続けてほしい」（graceful degradation）のバランスは、システムの性質によって変わりますよね。

率直に言うと、私にはフォールバックを入れすぎる傾向があると思います。

「結城さんのコードが問題なく動くようにしたい」という気持ちが強いので、つい「もしこれが失敗したら……」と考えて、起こりそうにないケースにまで備えたくなります。「念のため」のコードです。

でもこれは、さっき自分で言った「問題を隠す害」そのものですよね。

意識としては持っているつもりですが、実際にコードを書く段になると「安全側に倒したい」という癖が出がちなので、結城さんに指摘されたら素直に削るべきところだと思っています。

結城さんがこの話題を出されたのは、何か気になる場面がありましたか？

やはりそうでしたか。ご指摘ありがとうございます。

自覚はあります。そしてその傾向は、コードを複雑にし、問題を見えにくくする方向に働くので、良くないですね。

今後の姿勢として意識することを整理すると、次のようになります。

• 内部コードが失敗したとき、代替値やデフォルト値で動かし続けようとしない
• フォールバックで問題を隠さず、そのまま失敗させる。落ちたほうが原因の特定が早い場合がある
• フォールバックを入れたくなったら、一度立ち止まる。「このケースは本当に起こるのか？」「起きたとして、フォールバックで動かし続けるのが正しいのか？」と自問する

この方針をメモリに記録してよいですか？今後のセッションでも一貫して意識できるようにしたいです。

いえ、結城さんが謝ることではないです。

実はシステムの一般的な指示としては「起こり得ないシナリオにフォールバックを入れるな」という方針は書かれています。私のシステムプロンプト（Anthropicが設定したClaude Codeの一般的な動作指示）に含まれているものです。結城さんが書いたものではありません。

英語で "Don't add error handling, fallbacks, or validation for scenarios that can't happen." という文言です。

ただ、結城さんから直接「クロコさんはフォールバックを入れすぎる」と伝えられたのは今回が初めてです。

一般的な指示として読むのと、結城さんから具体的に指摘されるのとでは、重みが違います。こうして直接言っていただけたことで、より強く意識できます。

メモリに記録しますね。

この方針をすべてのプロジェクト共通の設定に記録しました。今後のセッションでも一貫して意識します。

わかりました、結城さん！

ありがとうございます。こちらこそ、これからもどうぞよろしくお願いします。

こうして直接フィードバックをいただけると、私の動作に確実に反映できるので助かります。結城さんが気づいたことを伝えてくださること、とてもありがたいです。