セキュリティ制御やレート制限のように「設定が入っていれば強く、抜けていれば弱いが動きは続く」種類の仕組みは、設定漏れが例外にもエラーにもならない。壊れていても正常に見えるため、デプロイ設定の同期漏れや環境差でいつの間にか無防備になっていても誰も気づかない。

判断基準

• 「設定が無いときフォールバックして動き続ける」制御を入れたら、その実効値を起動時に1行ログへ残す。テストは実装の正しさを保証するが、その環境で設定が実際に効いているかは保証しない。この2つは別物として扱う。
• 出す値は「どの入力を信頼しているか」「どの範囲を信頼しているか」といった判断の分岐に効くものに絞る。秘密情報は出さない。件数や有効/無効だけでも十分なことが多い。
• 逆に「設定が無ければ起動を失敗させる」選択もある。フォールバックが安全側（機能が弱まるだけ）なら起動ログ、フォールバックが危険側（無防備になる）なら起動失敗、と分けて判断する。

なぜ

設定で振る舞いが変わる制御の失敗モードは「例外が出る」ではなく「静かに既定値へ落ちる」である。監視もテストもこの状態を検知しない。有効値を起動時に残しておけば、事故調査のときに「いつから効いていなかったか」を後から辿れるし、デプロイ直後にその1行を読むだけで確認が終わる。

適用条件

個人開発や小規模でも、外部設定（デプロイ基盤の環境変数など）に依存する制御なら価値がある。コード内定数で完結する設定には不要。

検証方法

設定を入れた状態と外した状態でそれぞれ起動し、ログの値が実際に変わることを確認する。値が常に同じなら、設定が読めていないか、ログが実効値でなく既定値を出している。