自動価格配信の「是正済み」を誤認しない — 配信窓・検証窓の外を読む手順

在庫や価格を外部システム（チャネルマネージャ・EC・広告フィード等）へ定期配信している構成で、 「値を直した」「検証も通った」のに旧値が売れ続ける事故を止めるための手順書。

前提となる構成

• 価格・在庫を計算するエンジンがあり、今日から N 日先までを外部APIへ書いている
• 別に検証ジョブがあり、今日から M 日先までを読み戻して一致率を出している
• 外部システム側には**既定値（base rate / default price）**があり、誰も書かない日付はそれが並ぶ

この3つが揃うと、N と M の外側は「エンジンが書かない・検証も見ない」死角になる。 配信ログは成功、検証は「M/M 一致」で緑のまま、構造的に絶対に赤くならない。 予約・受注が1年以上先まで入る商売では、ここがそのまま実害になる。

手順

1. 2つの窓の幅を数字で出す

配信窓 N = 1回の配信件数 ÷ 対象アイテム数     # 例: 1092件 ÷ 13アイテム = 84日
検証窓 M = 検証ジョブの引数（既定値を疑う）    # 例: daysAhead=30

N > M なら検証は配信の一部しか見ていない。N の外側は誰も見ていない。 「M/M 一致」という数字を報告に書くときは、必ず「何日分・どの期間か」を添える。 期間を書かない一致率は窓の外を隠す。

2. 窓の外を1回読む

外部APIのカレンダー取得を from = 今日, to = 2年先 まで伸ばし、旧値が残っている日を数える。

旧値が残っている日数 / 最初に旧値が出る日 / 是正済みの最終日

「最初に旧値が出る日」が配信窓の直後（例: 84日目の翌日）なら、窓境界の取りこぼしが確定する。

3. 窓の外の「正しい値」は価格表から作らない

価格表・計算エンジンは窓外の日付を持っていない。窓外の正解は その時点で外部システムが実際に持っている値から組み立てる。

• 複合商品（セット・パッケージ・バンドル）なら → 構成要素の現在値の合計
• 単品なら → 既定値そのものが妥当かを判定し、妥当でなければ既定値を直す

構成要素の値が取れない日（在庫期間外で価格が空）は書かずにスキップする。 「値が取れない」と「値がゼロ」を同一視すると、0円やゴミ値を書き込む事故になる。

4. 差分だけを、レンジに畳んで書く

1. 構成要素の現在値を日付キーのマップで取得
2. 対象アイテムの現在値と比較し、不一致の日だけ抽出
3. 連続する同額の日を from/to レンジに畳む（payload とAPI回数の削減）
4. --dry で件数とサンプル差分を出して目視 → 本実行
5. 同じ --dry をもう一度回して「不一致 0」を確認（読み戻し）

--dry を実装に必ず入れる。外向きの価格書き込みは、件数と代表差分を人が見てから撃つ。

5. 根本原因は「既定値」

一度潰しても、時間が経って新しい日付が在庫に現れるとまた既定値で出てくる。 恒久対策は次のどちらか。片方を選んで記録する。

• 定期同期: 上記スクリプトを月次で回す（配信窓より広い範囲を毎回上書き）
• 既定値の是正: 外部システム側の base rate を直す（根治だが設定調査が必要）

表示面の確認で踏む罠

• 公開ページが読んでいるフィールドと、チャネルが読んでいるフィールドは別のことがある。 直販ページは price1、OTA は price2 のような構成では、price2 を直しても直販ページには映らない。 「画面に出ないから直っていない」も「画面に出たから全部直った」もどちらも誤り。
• 複合商品は公開ページに出ていないことがある。 在庫があるのに単体URLが「利用できません」を返す なら、そのページは検証面として使えない。使えないと分かったことを報告に書く（黙って API値だけで「実表示確認済み」と言わない）。
• 検証に使った画面のスクショは自分で開いて目視する。テキスト抽出では描画崩れ・文字化けを見逃す。

完了の言い方

- 対象: <アイテム数>件 × <期間>（YYYY-MM-DD 〜 YYYY-MM-DD）
- 配信窓内: <一致数>/<総数> 一致
- 配信窓外: <書き換え日数>日を是正、読み戻し不一致 0
- 在庫期間外（価格なし・予約不可）: <日数>日は対象外
- 未確認: <実表示を確認できなかった面とその理由>

「N/N 一致」だけを書いた完了報告は、窓の外を隠している可能性を常に疑う。