在庫も価格も正しいのに1件も売れないときの切り分け手順（宿泊・OTA/チャネルマネージャ）

これは何の指示書か

チャネルマネージャ（Beds24 / 手間いらず / ねっぱん 等）と OTA（Airbnb / Booking.com / Agoda）を 繋いで運営していて、「空室はある・価格も下げた・在庫も開いている。なのに予約が入らない」 という状態を診断するための手順。

値下げに走る前に、そもそも売れる状態になっているかを機械的に確かめる。 実例では「一番安い値段を、システム上どのチャネルでも購入できない日に出し続けていた」。

大原則

API の戻り値・管理画面の設定値は「システムがそう思っている状態」であって 「実際に買える状態」ではない。 この2つは日常的にズレる。 外に出ている状態を語る前に、必ず購入導線（予約ページ／OTA の実ページ）を開いて読み戻す。

手順

0. 症状を数値で確定させる（分母を必ず出す）

「N部屋空いている」だけでは判断できない。総室泊（部屋数 × 日数）を分母にした稼働率にする。 さらに空室を3つに割る。混ぜると達成不可能な目標を追って値下げしすぎる。

区分	意味	価格で埋まるか
埋めるべき空室	連続して空いている	○
飛び地1泊	前後を予約に挟まれた1泊	×（最低宿泊日数の下限で物理的に売れない）
在庫が閉じている	予約が無いのに在庫0	×（価格ではなく在庫の閉め忘れ）

1. 「予約が入っていない」のか「予約が届いていない」のかを分ける

予約レコードを 到着日ではなく作成日（および更新日） で取り直す。 到着日で絞ると、窓の外の日付に入った新規予約を取り落とし、「予約ゼロ」と誤診する。

GET /bookings?propertyId=<ID>&bookingTimeFrom=<日付>
GET /bookings?propertyId=<ID>&modifiedFrom=<日付>

2つの結果が一致すれば取り落としではない。最新予約の作成時刻が数日前で止まっていれば 「入口で止まっている」疑いが濃い。

2. 販売を止めている設定を洗う（ここが本命）

在庫と価格が正しくても、次のどれか1つで販売は完全に止まる。全部読む。

設定	症状	確認方法
予約締切（cut-off）	直前の日付が全チャネルで買えない	物件の予約ルールを API で読む。「到着の N 時間前で受付停止」型かを確認
最低宿泊日数	短い滞在が売れない	法令や運用で下限がある場合は変えられない。構造的な天井として受け入れる
最大宿泊日数 / 事前予約可能期間	遠い日付が売れない	同上
手数料（清掃費等）	値下げが効かない	下記 4
在庫の閉め忘れ	特定日だけ売れない	予約が無いのに在庫0の日を機械的に列挙する

予約締切は特に見落とされやすい。 OTA 側の管理画面には 「チェックイン当日の予約締切時間 0:00」のような形で降りてくるが、 OTA 側では編集がロックされていて（チャネルマネージャが値を握っている）、 OTA を何度触っても変えられない。必ず上流で変える。

3. OTA の実ページで確かめる（ここに大きな罠がある）

罠: セット販売／複数ユニットのリスティングを見て「チャネル障害だ」と誤診する

複数部屋をまとめたセット販売用リスティング（「A室&B室」「全部屋セット」等）は、 構成室が1つでも埋まれば売れない。これは正常動作。 これを個別部屋だと思ってテストすると「OTA が直近を全部塞いでいる」という誤った結論になる。

切り分け方（実際にこれで誤診を潰した）:

1. 対象日に空いている部屋を在庫データから特定する
2. 同じ部屋が空いている2つの日付を選び、片方だけ売れないかを見る
   • 同じ部屋なのに日付で結果が変わる → 日付側の設定（予約締切など）
   • 日付を変えても売れない → 在庫かマッピング
3. 個別部屋のリスティングとセット用リスティングを必ず区別する。 管理画面の一覧が実際のリスティング数より少なく見えることがある（グループ表示）

実ページの読み方

• 検証は exit code で機械判定する（期待文字列が出ているか／旧値が残っていないか）
• スクリーンショットは必ず自分で開いて目視する。 テキスト抽出だけでは描画崩れ・二重表示を見逃す
• 「ブロック文言が0件」は売れる証拠にならない。 ページが描画されずに空で返っただけのことがある。 肯定的な証拠（価格が表示されている）を取ること

4. 手数料が値下げを食い潰していないか計算する

宿泊料と別建ての清掃費等がある場合、短い滞在ほど1泊あたりの負担が重い。

実質1泊単価 = (室料 × 泊数 + 固定手数料) ÷ 泊数

固定手数料 F、最低宿泊日数 2 なら、1泊あたり +F/2 が常に乗る。 室料を下げてもこの分は下がらないので、ゲストが見る総額は思ったほど動かない。

例: 室料を 40% 下げても、固定手数料込みの総額では 26% しか下がらない、という事が起きる。 埋めたいのが最低宿泊日数ちょうどの滞在なら、そこが一番食われる。

対処は「手数料の減額」ではなく「室料への統合」。総収入は同じまま、 検索結果に出る1泊単価の見え方と総額が下がる。減額と混同されやすいので、 提案するときは「収入は1円も減らない」と先に明示する。

5. 「例年より遅れている」の基準を疑う

過去実績との比較で「先行が遅れている」と出たら、比較相手の期間に一過性の特需 （万博・オリンピック・大型イベント等）が入っていないかを必ず確認する。 特需の年を基準にすれば、平常年は必ず「遅れ」に見える。

比較データを引くときは API の件数上限に頭打ちしていないかを確認する。 返却件数がちょうど 100 や 500 で止まっていたら、それは実態ではなく上限。 トレンドを語る前に分母（総件数）を出力する。

設定を書き換えるときの作法

1. 変更前の値を必ず読んで記録する（戻せるようにする）
2. 書き込む
3. 読み戻して確認する。 応答の success: true は判定に使えない。 多くの API は書けない項目をエラーにせず黙って無視する。 応答に modified 等「何を変えたか」を示すキーがあればそれで判定する
4. 購入導線の実ページで確認する
5. 戻し方をコードのコメントに書く（定数を1つ変えて再実行すれば戻る形にしておく）

検証スクリプトの骨子:

const before = await readSetting();
console.log('変更前 =', before);
if (before === NEW_VALUE) { console.log('既に目的の値'); process.exit(0); }

const res = await writeSetting(NEW_VALUE);
console.log('応答:', JSON.stringify(res));

const after = await readSetting();          // ← success を信じず必ず読み戻す
if (after !== NEW_VALUE) {
  console.error(`反映されていない（期待 ${NEW_VALUE} / 実際 ${after}）`);
  process.exit(1);
}

変更前後の因果を主張するときの注意

「直したら売れるようになった」と言うには、変更前の同じ画面を撮っておく必要がある。 撮り忘れた場合は、設定の意味から論理的に言える範囲だけを主張する。

例: 「到着24時間前で締切」だった設定を外した直後、 到着まで18時間しかない日付が購入可能になっている → 旧設定では必ず塞がれていた条件なので、 変更が効いたと言える。

やりがちな誤り（実際にやった）

• 値下げの上限を広げれば直近が埋まると考える → その帯は既に最低価格に張り付いていて1円も動かず、 実際に効いたのは「高くて空いているのが正常」な繁忙日（倍率設定日）だけだった。撤回した
• セット販売用リスティングを見て「チャネルが直近を塞いでいる」と結論する → 誤り
• 管理画面の一覧の行数を見て「リスティングが減った」と結論する → グループ表示だった
• 到着日で予約を絞って「予約ゼロ」と言う → 窓の外の新規を取り落としていた

チェックリスト

• 稼働率を分母付きで出した（空室数だけで判断していない）
• 空室を「埋めるべき／飛び地／閉室」に割った
• 予約を作成日と更新日の両方で引いた
• 予約締切・最低/最大宿泊日数・事前予約期間を全部読んだ
• テストしたのが個別リスティングかセット用かを確認した
• 同じ部屋・別日付で切り分けた
• スクリーンショットを目視した（テキスト一致だけで判定していない）
• 固定手数料込みの実質単価を計算した
• 比較基準の期間に特需が入っていないか確認した
• 比較データが API の件数上限で切れていないか確認した
• 設定変更は変更前値の記録 → 書き込み → 読み戻し → 実ページ確認 の順で行った