重複発注番号の週次検知— スクリプト要件メモ

1. 何を「重複」と呼ぶか

1-1. 完全一致

同一文字列の発注番号が2行以上あるケースです。
まずは完全一致から実装し、曖昧一致は第2段に回します。

1-2. 正規化後一致

全角半角・ハイフン有無・先頭ゼロの差で別番号に見えて同じ意図のケースです。
正規化ルール（大文字化、ハイフン除去など）を要件に明記し、勝手に変えられる状態にしないでください。

1-3. 除外すべきもの

取消済みの旧番号再利用、テスト環境データ、明示的な改訂版サフィックス（-R1など）は除外条件に入れます。
除外リストが無いと、毎週ノイズで現場が無視し始めます。

2. スクリプトの入出力要件

2-1. 入力

台帳の発注番号、案件ID、取引先ID、作成日、ステータス、適用フラグを読みます。
CSV監査の観点は発注台帳CSVの監査と揃え、必須列欠落行は重複判定の前にエラー報告します。

2-2. 出力

重複グループID、対象案件一覧、最初に作られた行、疑わしい後続行、推奨アクションを出します。
「重複あり」だけでは是正が進みません。

2-3. 通知

購買リードと台帳管理者へ週次で送り、件数ゼロの週も「0件」を通知します。
沈黙はスクリプト停止と区別がつかないためです。

3. 是正フロー要件

3-1. 正の行を決める

原則は最先の有効行を正とし、後続は採番し直すか取消します。
支払や書面が後続に付いている場合は、証跡移行手順をチケットに含めます。

3-2. 書面・支払リンクの付け替え

重複解消後に、3条書面パスと支払実績が正しい案件IDを向くか確認します。
書面の正本確認は発注書面の3条明示、監査リンクは監査用の発注〜支払リンク集の型で点検します。

3-3. 再発防止

採番ルール（部門接頭辞・年度・連番）を文書化し、手入力を減らします。
可能なら登録時の一意制約を本体に置き、スクリプトは最終防衛にします。

4. 現場シナリオ

4-1. 支社が独自採番している

全社一意にならないため、法人コード＋支社コードを発注番号の一部に含めます。
スクリプトは「全社スコープ」と「支社内スコープ」の両方で重複を見ます。

4-2. 取消後に番号を再利用した

再利用を禁止するか、取消から◯日後のみ許可するかを規程で決めます。
再利用を許すなら、履歴上は別案件IDのまま番号だけ戻す危険性を要件に明記します。

4-3. 60日超過リストに同じ番号が2つ出る

KPIが水増しされるため、重複解消を超過対応より先に行います。
期日の見方は支払60日ルールの起算点とダッシュボードKPI（60日）に合わせ、重複補正後の数値で報告します。

5. FAQ

Q. 日次と週次どちらがよいか？

登録量が多い組織は日次、少ない組織は週次で十分です。
重要なのは失敗時に気づける通知です。

Q. 曖昧一致（編集距離）は入れるべきか？

初期は入れない方がよいです。
誤検知が増え、現場がアラートを無視する原因になります。

Q. 自己点検への載せ方は？

月次で「重複未解消件数」を自己点検チェックリストに追加し、ゼロを目標にします。

6. 要件書に書く受け入れ条件

6-1. 検知の受け入れ

既知の重複サンプルを投入し、グループとして検出されること、0件の週に成功通知が来ること、失敗時に別チャネルへアラートが出ることを受け入れにします。
検知漏れより先に、スクリプト沈黙を潰す方が運用上重要です。
実行ログには対象件数、重複グループ数、所要時間を残します。

6-2. 是正の受け入れ

重複チケットが起票され、正行決定、番号変更または取消、書面・支払リンクの付け替え確認が完了してクローズできること。
検知結果を放置できるUIは不合格です。
クローズ時に再実行して同一番号が消えていることも確認します。

6-3. 会話例：現場が「同じ番号で改訂したい」と言うとき

「改訂はサフィックス付きの新番号か、同一案件IDの版管理で扱います。別案件に同じ番号は使えません」と返します。
同じ番号のまま別内容を重ねると、支払と書面がどちらを指すか不明になります。
例外を許すなら、例外理由と期限を必須にし、週次検知の除外に期限付きで載せます。

6-4. 運用開始後のチューニング

最初の1ヶ月は誤検知・見逃しを記録し、正規化ルールと除外条件だけを調整します。
曖昧一致を急いで足すと、通知疲れでスクリプトが無視されます。
安定したら、登録時の一意制約強化を本体改修として起票します。

要件レビューの最短チェック

重複定義、除外条件、0件通知、是正の正行決定ルールの4点が書けていれば実装に進めます。
検知だけ作って是正フローが無いスクリプトは、ノイズ発生装置です。
今週は完全一致の週次実行と0件通知だけでも開始してください。

7. データモデルと採番規程の接続

7-1. 発注番号と案件IDを分ける

人が見る発注番号と、システム内部の案件IDを分け、重複是正でも案件IDは不変にします。
番号を直すたびに案件IDが変わると、証跡リンクが全部切れます。
要件書に「是正時に不変なキー」を明記してください。

7-2. 採番規程の必須条項

接頭辞、年度、連番桁、再利用可否、改訂時サフィックスを条文レベルで決めます。
現場の慣習に任せると、支社ごとに違う規則が生まれ、全社一意が崩壊します。
規程改訂時は検知スクリプトの除外条件も同時更新します。

7-3. 手動採番を残す場合のガード

どうしても手入力が必要な画面では、登録前に重複プレビューを出し、強実行には理由入力を必須にします。
理由なしの強実行は監査で説明不能です。
強実行ログは週次検知の入力にも使い、例外の偏りを見ます。

7-4. 障害時の再実行方針

スクリプトが失敗したら、同日中に再実行し、連続失敗でオンコールへ上げます。
「来週の定期実行で拾う」は、その間に重複発注が増える前提を許すことになります。
再実行手順をRunbookに1ページで残してください。

8. 関係システムへの波及確認

発注番号を直したら、会計・電子契約・倉庫・請求の参照キーが切れないかをチェックリスト化します。
台帳だけ直して周辺が旧番号のまま残ると、監査サンプルで不整合が出ます。
是正チケットの完了条件に「周辺システムの番号更新確認」を必須項目として入れてください。
影響システム一覧は最初に作り、後から足していくより漏れが減ります。
番号変更の通知文テンプレも用意し、関係部門への連絡漏れを防ぎます。

9. 導入判断の一言

重複検知は派手な機能ではありませんが、支払と書面の混線を止める土台です。
完全一致の週次実行、0件通知、是正チケットの3点があれば始められます。
曖昧一致や高度な正規化は、現場が通知を信頼してから足してください。
まずは今四半期の重複グループをゼロに近づけることを目標にします。

10. 週次運用のタイムボックス

月曜朝に検知結果を開き、30分以内にオーナー付けまで終わらせます。
水曜までに正行決定と番号変更案を出し、金曜に周辺システム更新の確認を閉じます。
翌週へ持ち越す場合は、持ち越し理由と監査影響の有無をチケットに残してください。
タイムボックスが無いと、検知だけが積み上がり是正が止まります。
月初は件数が増えやすいので、通常の倍の枠をカレンダーに確保しておくと安全です。

注意

本記事は台帳運用・検知設計の一般的な整理であり、トリカク（torikaku） の機能説明を含みますが、法的助言ではありません。
個別案件の記録・監査対応は社内規程と専門家確認に従ってください。