フロントエンドの依存項目フィルタリング（親の値に応じて子の選択肢を絞り込むフォームUI）には、たいてい「絞り込んだ結果に現在選択中の値が含まれていなくても、UIのドロップダウンからその値を消さないための救済分岐」が入っている。これは純粋にUIの見た目を壊さないためのもので、その値が業務的に妥当かどうかとは無関係。

このフィルタリング関数をバックエンドの妥当性チェック（更新後の値が制約に違反していないかの判定）へそのまま移植すると、救済分岐が自己言及になって判定が空洞化する。救済分岐は「渡した値そのものを許可リストに強制的に含める」形をしているため、チェック対象の値をそのままその救済分岐の入力として渡すと、常に許可される結果になり、チェックが常にtrueを返す無意味な関数になる。

判断基準

• FEのフィルタリング/絞り込みロジックを流用してBEの妥当性判定を作るときは、「この分岐は表示上の理由でユーザーが困らないようにするためのものか」「業務ルールとして本当にこの値を許可しているのか」を1つずつ切り分ける。
• 表示上の救済（現在値を消さない、選択済みなら残す等）は判定ロジックには持ち込まず、業務ルール（親の値に対して許可される子の値の集合）だけを移植する。
• 親項目が未設定のときにFEが「新規の選択肢を一切見せない」挙動をしているなら、それは「親未設定時は子に値を設定できない」という業務ルールとして解釈できる。表示上の救済とは区別して判定ロジック側に正しく反映する。

検証方法

移植した判定関数に、意図的に「制約違反のはずの値」を「現在の値」として渡すテストを書く。救済分岐を消し忘れていると、違反のはずの値が常に許可（違反なし）と判定されて発見できないので、このテストが通ることを確認する。あわせて、親項目に対応する許可リストが存在しない場合は制限なしとして扱う、親項目が未設定の場合は子に値を設定できない、といった境界値も個別にテストする。