「予約が無いのに売れない在庫」を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=<id>&startDate=<from>&endDate=<to>
    &includeNumAvail=true&includeOverride=true&includePrices=true

2. 予約は「ページングを追って」「全ステータスで」取る

ここが最大の落とし穴。予約APIは1ページ100件などで頭打ちになり、 nextPageExists を見ずに1回だけ叩くと予約が黙って欠落して、 「予約が無いのに閉じている」という偽陽性が出る。期間を二分割して再帰で取り切る。

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 か読み戻しで検証している
• 公開ページを開き、スクショを目視している
• 直らない分を「プラットフォーム由来」として分離し、値下げ対象から外している