あるコンポーネントが記録したID(処理済みマーカー、外部参照、突き合わせキー)を、別のコンポーネントが後から自分の名前空間(ファイル名、外部システムのID体系など)と照合する構成では、書き込み側が自由形式のIDを発明すると照合が静かに失敗する。JOINに相当する突き合わせは正準形の一致でしか成立しないため、正準形は照合側の仕様が決め、書き込み時点でその形へ正規化する。読み出し側にあいまい一致(部分一致・末尾一致)を足して救う案は、照合ロジックの分岐が増えるうえ書き込み側の亜種が増えるたびに追随が要るので、書き込み側の正規化が取れるなら採らない。

適用条件

• 記録者と照合者が別のコード経路・別のタイミングで動く(同一トランザクション内なら通常問題にならない)。
• 照合先の名前空間に既に正準形がある(ファイルの拡張子なし basename、外部システムの発番IDなど)。書き込み側が正準IDを取得するコストが現実的であること。

失敗時の症状

• 照合が成立しないことはエラーにならず、「未処理として再表示される」「二重に処理される」形で現れる。下流に重複防止の別機構(セマンティック重複チェック等)があると実害が隠れ、再処理コストだけが残り続けるため長期間気づかない。

例外(フォールバック)

• 書き込み側が正準IDをどうしても取得できない環境では自由形式IDを許容するが、「このIDは照合に使えない」ことを仕様として明記し、照合側の統計(一致率)で混入量を観測できるようにしておく。

検証

• 蓄積済みレコードのID形式を分類し、照合先の正準形と一致する割合を実測する。一致率が形式別に偏っていれば(例: 自動採取経路は一致、手動発明経路は不一致)、書き込み経路ごとの正規化漏れが特定できる。
• 修正後は、新規に書かれたIDが照合側の突き合わせで実際にヒットすることをエンドツーエンドで1件確認する。