# 「予約が無いのに売れない在庫」を3つの原因に切り分ける（チャネルマネージャ運用） 宿泊・レンタル・予約系をチャネルマネージャ（Beds24 / Beds24 系 API を持つ製品）で回していると、 **空いているはずの日が売れていない**という状態が定期的に発生する。稼働率レポートは 「空室 N 室泊」としか言わないので、**値下げでは絶対に直らない在庫**が値下げ対象に混ざり続ける。 在庫が「売れない」原因は**3つあり、見分け方が違う**。混ぜると打ち手を誤る。 | # | 原因 | カレンダーAPI上の見え方 | 直し方 | |---|---|---|---| | 1 | 実予約が入っている | `availability(numAvail)=0` / `override="none"` | 直すものは無い（正常） | | 2 | 明示的な売り止め | `availability=0` / **`override="blackout"`** | 売り止めを解除する | | 3 | プラットフォーム由来 | `availability=0` / `override="none"` **なのに予約が無い** | API では直らない。管理画面か仕様 | ## 手順 ### 1. カレンダーは override まで取る 多くの実装が `availability` しか取っておらず、**1 と 2 が同じ「0」に見える**。 取得クエリに override 相当のフィールドを必ず含める。 GET /inventory/rooms/calendar?roomId=&startDate=&endDate= &includeNumAvail=true&includeOverride=true&includePrices=true ### 2. 予約は「ページングを追って」「全ステータスで」取る ここが最大の落とし穴。予約APIは**1ページ100件などで頭打ち**になり、 `nextPageExists` を見ずに1回だけ叩くと**予約が黙って欠落**して、 **「予約が無いのに閉じている」という偽陽性**が出る。期間を二分割して再帰で取り切る。 ```js async function fetchBookings(from, to, depth = 0) { const res = await api(`/bookings?propertyId=${PID}&arrivalFrom=${from}&arrivalTo=${to}`); const rows = res.data || []; if (!res.pages?.nextPageExists || depth >= 7 || from === to) return rows; const mid = midDate(from, to); return (await fetchBookings(from, mid, depth + 1)) .concat(await fetchBookings(addDays(mid, 1), to, depth + 1)); } ``` さらに2点: - **窓の外から入ってくる長期滞在**を取り落とす。到着日で絞るなら **30〜45日前から**遡る。 - **手動ブロックが予約レコードとして入る**製品がある（ステータス `black` 等）。 ステータスで絞り込むと**ブロックだけ見えなくなる**ので、全ステータスで取って自分で分類する。 ### 3. 「予約が入っている室日」を対照に取る（これが決め手） 原因3を疑う前に、**同じ日・同じ物件で確実に予約が入っている別の部屋**の override を見る。 - 予約済みの室日が全部 `override="none"` なら → **予約由来のブロックは blackout にならない**。 つまり blackout が出ている室日は予約とは無関係の売り止めで、開けてよい。 - 予約済みの室日にも blackout が出るなら → その製品では両者が区別できないので、 予約レコード側でしか判定できない。 対照を取らずに「孤立した売り止めだから開ける」と判断すると、 **チャネル間のダブルブッキング防止ブロックを自分で外す**事故になる。 ### 4. 書けたかどうかは `success` で判定しない 在庫系のフィールドは**書き込みが黙って無視されても `success: true` が返る**製品がある。 応答の `modified` キー（実際に変わったフィールドの辞書）を見るか、**読み戻して比較**する。 {"success":true,"modified":{"bookingRules":{"bookingCutOffHour":23}}} `modified` が空なら書けていない。 ### 5. 最後は公開ページを開いて目視する API が「売れる状態」と言っていても、公開の予約ページで買えるとは限らない。 **実際に客が見る画面を開き、期待する文字列（金額）と、出ていてはいけない文字列（旧価格・ 「利用できません」）の両方**で判定する。ヘッドレスブラウザで exit code を取るのが確実。 node verify-live.mjs "<公開予約URL>?checkin=<日>&numnight=2" \ --wait 9000 --expect "JPY 19,900" --not-expect "利用できません" --shot out.png スクリーンショットは**必ず自分で開いて見る**。テキスト抽出だけでは描画崩れ・二重表示を見逃す。 ## 原因3（プラットフォーム由来）の見分け方 1 と 2 を潰しても `availability=0` が残るなら、製品仕様を疑う。実例: - **「当日」の在庫が、予約の有無に関係なく全室 0 になる**製品がある。 前夜の時点では 1 だった同じ室日が、日付が変わると予約が入らないまま 0 に落ちる。 翌日以降の同じ部屋は 1 のまま普通に売れるので、**壊れているのは当日だけ**とわかる。 - この場合、**予約締切時刻の設定をどう変えても直らない**。0 / 23 / 24 を実際に入れて 比較し、在庫も公開ページも1ミリも変わらないことを確認して初めて「締切は原因ではない」 と言える（設定の意味を推測で決めない）。 - **カレンダーAPIは過去日を返さない**製品が多く、履歴でこの挙動を追うことはできない。 気づいた時点で日次スナップショットを保存し始める。 **運用上の帰結**: 当日まで段階的に値下げする設計を持っているなら、 **最深段が構造的に成約しえない**ことになる。効かない段を維持し続けないよう、 値付けの設計から外すか、管理画面側の調査に切り替える。 ## チェックリスト - [ ] カレンダーを override 込みで取っている - [ ] 予約をページング（二分割再帰）で取り切っている - [ ] 到着日で絞るなら 30〜45日前から遡っている - [ ] 全ステータス（手動ブロック含む）で取っている - [ ] 同じ日の「予約済み室日」を対照に取ってから開けている - [ ] 書き込みを `modified` か読み戻しで検証している - [ ] 公開ページを開き、スクショを目視している - [ ] 直らない分を「プラットフォーム由来」として分離し、値下げ対象から外している ---