チャネルマネージャ価格自動化：「送信成功」を信じず全部屋の実売値を読み戻す

宿泊施設の価格をチャネルマネージャ（Beds24 / 手間いらず / ねっぱん 等）経由で 自動更新する仕組みを作るときの指示書。

この指示書が防ぐ事故: 「送信成功」ログが緑なのに、実際には一部の部屋の売値が 何ヶ月も1円も変わっていない、という状態に誰も気づけない。

---

1. なぜ送信ログでは足りないのか

価格エンジンには必ず「どのプラン／部屋に送るか」の対象リストがある。 このリストから漏れた部屋は、送信ログ上まったく赤くならない。 送信成功 count=168 は「設定した分だけ成功した」ことしか証明しない。

さらにチャネルマネージャ側は、書き込めないフィールドに対して 警告付きで HTTP 200/201 を返すことがある。

[{"success": true,
  "warnings": [{"message": "price1 not available"},
               {"message": "price2 not available"}]}]

success: true を見て「反映OK」と報告すると、値は1円も変わっていない。

結論: 検証は「送信できたか」ではなく **「その部屋のその日の売値がいくらになっているか」**を読み戻して行う。

---

2. 実装する検証関数の仕様

verifyAllRoomPrices(daysAhead) を作る。

入力

• プランマスター（全プランの一覧。ID・名称・チャネルマネージャ側の room ID）
• 価格表（エンジンが算出した「意図値」の日付×プラン表）
• 送信対象リスト（エンジンが実際に送るプランIDの集合）

処理

1. プランマスターの全プランについてチャネルマネージャのカレンダーを取得する。 代表1部屋だけ見るのが最大の失敗要因なので、必ず全件回す。
2. 日付ごとに「期待する売値」と「実際の売値」を突き合わせる（丸め誤差は ±20 程度許容）。
3. 送信対象リストに入っていないプランを notSent として必ず報告する。 これが本体。ここが漏れていたことに気づけないのが事故の正体。
4. 異常時のみ通知する（正常時も毎日鳴らすと即座に無視されるようになる）。

出力

{
  ok, checkedAt, from, to,
  summary: { plansChecked, plansOk, plansMismatch, plansNoData },
  notSent: [プランID...],          // 送信対象から漏れているプラン
  skipped: [{planId, reason}],
  results: [{ planId, planName, days, matched, mismatched,
              sampleMismatches: [{date, expected, actual}],
              liveMin, liveMax, liveAvg, status }]
}

---

3. 必ず踏む3つの罠

罠1: 連動価格（linked price）を計算に入れていない

多くのチャネルマネージャは「price2 = price1 × N」「部屋Bの価格 = 部屋Aの価格」 といった連動設定を持つ。連動先のフィールドは API から書けない （書こうとすると前述の "not available" 警告が返る）。

実際にあった構造:

エンジン → 基準部屋.price2 = 意図値        ← 書けるのはここだけ
              ↓ 連動
他の部屋.price1 = 基準部屋.price2          ← API からは書けない
              ↓ ×1.5 の連動
他の部屋.price2 = 意図値 × 1.5             ← 各OTAが読む値

対処:

• 期待値の計算にプランごとの倍率テーブルを持たせる。

  PLAN_PRICE_MULTIPLIER = { '基準部屋': 1.0, '連動部屋A': 1.5, ... }
  

  設計どおりの倍率を「異常」として鳴らすと、13件中11件が不一致になり 警報が形骸化して本物の異常を見逃す。
• 連動を外したい場合は管理画面から行う。API では変えられない。 外したら倍率テーブルを 1.0 に戻す。

罠2: 「実効価格」ではなく「素の格納値」を読んでいる

連動を解決した後の実効価格を返させるパラメータが要る。 Beds24 なら includeLinkedPrices=true。これが無いと、 連動で導出された実際の売値ではなく素のラックレートが返る。

つけ忘れると「全部屋が同じ丸い数字」という不自然な結果になる。 検証結果が不自然に揃っていたら、まずこのパラメータを疑う。

罠3: 列の対応を「並び順が同じはず」で決めている

価格表の列とプランの対応を配列インデックスで取ると、 どちらかの順序が変わった瞬間に黙って別プランと比較し始める。

対処: まずヘッダ名で突き合わせ、名前で引けない分だけ位置で補い、 位置で補ったものは必ずログに残す。黙って誤対応させない。

---

4. 内部IDと実体の対応を検証する

内部ID（プランID）とチャネルマネージャ側の room ID の対応表は、 連番だと思い込まないこと。実際に飛び番になっていて、 部屋ごとの稼働率を1つずらして分析していた事例がある。

対応表は必ずマスターデータから読み、 分析結果を出す前に「この部屋番号とこのIDは本当に対応しているか」を1回確認する。

---

5. 毎日の運用に載せる

検証は単発で回しても意味が薄い。日次ダイジェストに同梱する。

• 毎朝1回、全プランを照合して結果をチャットへ
• 正常なら1行（✅ 全13プランが意図どおりの売値）
• 異常なら不一致プランと notSent を列挙
• 検証が失敗してもダイジェスト本体は落とさない（try/catch で包む）

チャット通知はレート制限を踏むことがある。retry_after を尊重して 数回リトライし、真偽値ではなく HTTP ステータスコードを戻り値にする （true/false だと失敗原因が追えない）。

---

6. 完了報告の基準

次の全部が揃うまで「反映OK」と言わない。

• 全プラン（代表1部屋ではない）の実売値を読み戻した
• 各OTAが実際に読むフィールドを特定した（送信先フィールドと違うことがある）
• 連動倍率を計算に入れた実効価格で比較した
• 送信対象から漏れているプランがゼロであることを確認した
• 通知が実際に届いた（HTTP ステータスまで確認）

「送信成功」「HTTP 200」「count が増えた」はいずれも根拠にならない。