自動同期システムの「窓」と「警報」を監査する

外部サービス（予約サイト・在庫管理・広告プラットフォーム・決済など）へ値を定期送信する システムを引き継いだ／直したときに、構造的に絶対に赤くならない領域を先に潰すための手順。

対象: 「エンジンが計算した値を 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 して直した
• 報告の一致率に「日数と期間」を添えた