LINEの新しいキーワードだけが全部無視される — ORDER BY created_atが引き起こした優先順位バグ

LINE公式アカウントで新規キーワード応答システムが失敗していた。既存キーワード2つは正常に機能していたのに、新たに追加した6つすべてが応答しなかった。ログはマッチングの失敗を記録するだけで、データベースには正しく登録されていた。原因は「ORDER BY created_at ASC」で、作成日時の古い順に評価される仕様にあった。フォールバック行（どのキーワードにも該当しない場合の汎用メッセージ）の作成日時が新規キーワードより古かったため、緩い条件の方が先にマッチして、本来のルールに到達しない構造になっていたのだ。

この事例が指摘する本質は「見えない優先順位の危険性」である。優先順位が明示的なフィールドではなく、作成日時という副産物に暗黙的に依存する設計は、後から1個ルールを追加した瞬間に静かに壊れる。ここが怖いのは、既存データが引き続き正常だから問題が部分的で見落としやすいこと。一時的なバグではなく設計の欠陥なので、同じ形式でルールを追加するたびに再発する。修正方法は単純で、フォールバック行の作成日時を未来に設定するだけだが、根本には「見えない優先順位に依存した設計」という構造的な脆弱性が残る。

中小企業が業務システムを組むとき、優先順位が重要な場面では明示的なpriorityフィールドを設ける習慣をつけるべきだ。特にメール配信、キーワードマッチ、ルールエンジンなどで。「古い順」「新しい順」は便利だが、その便利さの代償は「ルール追加時の壊れやすさ」である。フォールバック行の日付修正は応急処置に過ぎない。根本的には優先順位の体系設計そのものを再考するべき時が来ている。