PostgreSQL などで seed / migration が主キー ID を明示して初期データを投入する場合、テーブルの sequence がその最大 ID まで進んでいるとは限らない。統合テストやアプリ処理で通常の auto increment insert を行うと、sequence が古い値を返して既存 seed の主キーと衝突し、duplicate key value violates unique constraint のような失敗になる。

起きやすい条件:

• migration や seed が id = 1 など固定 ID を明示して insert している。
• その後の insert は ID を省略して sequence / serial / identity に任せている。
• テスト DB は migration + seed を毎回 replay するため、本番より早く顕在化する。

対処の選択肢:

• seed 後に setval 等で sequence を既存最大 ID 以上へ進める。通常 insert と固定 ID seed を共存させるなら根本対策になる。
• テストで作るデータは既存 seed と衝突しない高い ID を明示する。ただし局所回避なので、アプリ本体でも同じテーブルに通常 insert するなら sequence 修正を優先する。
• 可能なら seed でも ID を省略し、自然キーや名前で参照する。固定 ID 前提の外部キーや設定が多い場合は管理が難しくなる。

検証方法: migration / seed 適用直後に対象テーブルへ ID 省略 insert を 1 件実行する。主キー衝突が起きるなら sequence が seed と同期していない。SELECT nextval(...) と SELECT max(id) を比較しても確認できる。