# チャネルマネージャ価格自動化：「送信成功」を信じず全部屋の実売値を読み戻す 宿泊施設の価格をチャネルマネージャ（Beds24 / 手間いらず / ねっぱん 等）経由で 自動更新する仕組みを作るときの指示書。 **この指示書が防ぐ事故**: 「送信成功」ログが緑なのに、実際には一部の部屋の売値が 何ヶ月も1円も変わっていない、という状態に誰も気づけない。 --- ## 1. なぜ送信ログでは足りないのか 価格エンジンには必ず「どのプラン／部屋に送るか」の対象リストがある。 このリストから漏れた部屋は、**送信ログ上まったく赤くならない**。 `送信成功 count=168` は「設定した分だけ成功した」ことしか証明しない。 さらにチャネルマネージャ側は、書き込めないフィールドに対して **警告付きで HTTP 200/201 を返す**ことがある。 ```json [{"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 が増えた」はいずれも根拠にならない。 ---