# 自動同期システムの「窓」と「警報」を監査する 外部サービス（予約サイト・在庫管理・広告プラットフォーム・決済など）へ値を定期送信する システムを引き継いだ／直したときに、**構造的に絶対に赤くならない領域**を先に潰すための手順。 対象: 「エンジンが計算した値を API で外部へ書き、別のジョブが検証する」形のシステム全般。 --- ## 1. まず「窓」が2つあることを疑う この形のシステムはほぼ必ず2つの窓を持つ。 | 窓 | 実体 | 典型的な決まり方 | |---|---|---| | 送信窓 | エンジンが値を書く期間 | `SEND_DAYS = 84` のような定数、または元データ表の行数 | | 検証窓 | 検証ジョブが読み戻す期間 | `verify(30)` のような引数 | **この2つは別々に書かれているので、まず一致していない。** そして送信窓の外側には「誰も書かない」「誰も見ない」期間が生まれ、外部サービス側の **既定値（rack rate / default price / fallback）**が何百日も並ぶ。 送信ログは成功、検証結果は緑。**構造的に絶対に赤くならない。** ### 実測の手順（推測で終わらせない） ``` # 1. 送信件数から送信日数を割り出す # sendCount ÷ 対象エンティティ数 = 送信日数 # 例) 1092 ÷ 13 = 84日 # 2. 検証窓をコードから読む grep -rn "verify.*([0-9]\+)" <検証ジョブのファイル> # 3. 両方の外側を1回だけ読む（ここが本番） # from/to を 1年先・2年先に伸ばして、外部APIから直接読み戻す ``` 外側で旧値・既定値が並んでいたら、それが売られている（あるいは配信されている）。 --- ## 2. 窓の外の「正しい値」は元データ表には無い 窓外を直すときの落とし穴。**元データ表（価格表・計画テーブル）は窓外の行を持っていない**ので、 「意図値と比べる」検証はそこでは成立しない。 窓外の期待値は **その時点で外部サービスが実際に持っている値から導く**。 例: セット商品（複数在庫のバンドル）の正しい値 ``` セットの値 = 構成要素それぞれが今その日に持っている公開値の合計 ``` この定義なら元データ表を必要とせず、窓外でも計算できる。 専用スクリプトを1本作り、`--dry` で差分だけ出してから書く。 --- ## 3. 一度潰しても、時間経過で再生成される 窓外を全部書き直しても終わりではない。**外部サービス側の既定値がそのまま**なら、 時間が経って新しい日付・新しい枠が在庫に現れるたびに、また既定値で出てくる。 根治は2つ。両方やるのが理想。 - **定期同期**: 窓外同期スクリプトを月次/日次で回す（自前の定時実行に載せる） - **既定値そのものの是正**: 外部サービスの管理画面 or API で base 値を直す （API から書けない設定項目があるので先に読み戻しで確認する） --- ## 4. 管理方式を変えたら、警報の前提も grep して直す これが一番踏みやすい。 「設定テーブルの一覧に載っているものだけを送信対象とする」実装を、 「コード側の定数で常に送信する」方式に変えると、**設定テーブルだけを見ている警報が 全部誤発報になる**。 実例: 対象4件をコード側の常時送信に移したところ、設定テーブルを見ていた 「送信対象外リスト」が毎朝4件を警告し続け、さらに 「全green判定 = 送信対象外リストが空」という条件が**永久に成立しなくなった**。 値は正しいのに毎朝警報が鳴る＝人が警報を無視するようになる（警報の形骸化）。 ### チェック手順 ``` # 判定条件に使われている変数を全部洗い出す grep -rn "<変えた前提の変数名>" <ソース全体> # 警報・通知・全green判定の3か所を必ず見る ``` **方式を変える変更は、その前提で判定している警報を同じコミットで直す。** --- ## 5. 報告に書いてよい数字・書いてはいけない数字 - ❌ 「13/13 一致」だけ — 何日分・どの期間かが無い一致率は、窓の外を隠す - ✅ 「今日〜30日で 13/13 一致。加えて窓外の 3時点（半年後・1年後・2年後）を読み戻して一致」 **期間を書かない一致率は報告として無効**と扱う。 --- ## 6. 完了チェックリスト - [ ] 送信窓と検証窓の日数を実測で出した（推測ではない） - [ ] 両方の外側を外部APIから直接読み戻した - [ ] 窓外の期待値を「元データ表」ではなく「構成要素の現在値」から導いた - [ ] 外部サービス側の既定値を確認した（再生成するか判断した） - [ ] 定期同期 or 既定値是正のどちらを採るか決めた - [ ] 管理方式を変えた場合、警報・通知・全green判定を grep して直した - [ ] 報告の一致率に「日数と期間」を添えた ---