# 予約データから「価格が高すぎるのか」を判定する手順（リードタイム・ペース曲線） 宿泊・レンタル・イベント席など**日付ごとに在庫が消えるビジネス**で、「先の予約が薄い」と言われた時に、 **憶測で値下げせずに**原因を切り分けるための手順書。AI エージェントにそのまま実行させる想定で書いてある。 ## この指示書が防ぐ失敗 「先が空いている → 高すぎる → 下げよう」は**ほぼ毎回まちがう**。実際に起きた例: - 先の月が空いて見えたのは単に**リードタイムの当たり前**で、過去の同じ「N日前」時点と比べたら むしろ**前倒しで、しかも最高単価**で入っていた。ここを下げていたら一番高く売れている在庫を壊していた。 - 本当に外れていたのは**中間帯（8〜30日前）**で、そこだけ実勢比 +35〜58% だった。 - そして最大の損失は価格ですらなく、**在庫が閉じていて1円も売れない期間**だった（価格の検証では絶対に見つからない）。 ## 前提 - 予約1件ごとに **①予約が入った日時 ②到着日 ③出発日 ④金額 ⑤チャネル** が取れること （多くのチャネルマネージャ／PMS の予約APIで取れる。`bookingTime` 相当の項目が要）。 - 日付ごとの**提示価格**と**在庫数**が取れること（カレンダーAPI）。 ## 手順 ### 0. データを引く（ページングと分割応答に注意） GET /bookings?propertyId=<物件ID>&arrivalFrom=<開始>&arrivalTo=<終了>&page=N - **ページングを最後まで回す。** 1ページ100件が典型。`nextPageExists` が false になるまで。 - ゲートウェイ（GAS 等）を挟んでいる場合、**応答が一定文字数で切られる**ことがある。 `offset` を送って継ぎ足す。切られたまま `JSON.parse` すると「後半のデータが存在しない」ように見える。 - キャンセル・ブロック枠（status がキャンセル系／`cancelTime` あり／金額0）を除外する。 ### 1. 実勢 — 実際に成立した単価をリードタイム別に出す 各予約の `lead = 到着日 − 予約が入った日` でバケット化し、**泊数加重**の平均単価を出す。 | 何日前に予約されたか | 件数 | 泊数 | 実勢ADR | |---|---:|---:|---:| | 0〜7日前 | … | … | … | | 8〜14日前 | … | … | … | | 15〜30日前 | … | … | … | | 31〜60日前 | … | … | … | | 61〜90日前 | … | … | … | | 91日以上前 | … | … | … | **件数加重にしない。** 長期滞在1件が単価を歪める。必ず「金額 ÷ 泊数」を泊数ぶん展開して平均する。 ### 2. ペース — 過去の同じ「N日前」時点で何%埋まっていたか ここが本題。**予約が入った日時があれば、過去の任意時点の在庫状況を再現できる。** ``` ある日付 d が 時点 asOf でどれだけ売れていたか = 予約のうち bookingTime <= asOf かつ arrival <= d < departure の件数 ``` 対象の未来月について「今から何日先か」を出し、**過去の各月を同じ日数前に巻き戻して**比較する。 | 対象月 | 今から | 現在の稼働 | 現在ADR | 過去の同時点 | 判定 | |---|---|---:|---:|---:|---| | 翌月 | 6〜35日先 | 33% | … | 53% | 遅れ | | 翌々月 | 36〜66日先 | 14% | … | 10% | 前倒し | - **月別の単純平均と比べない。** 繁忙期を含む平均と比べると全部「遅れ」に見える。 月ごとに並べ、**近い季節の月**と比べて判断する。 - 「%」だけでなく**泊数の絶対値**を併記する。母数が小さい月の% は簡単に振れる。 ### 3. 提示 — いま実際に出している価格を読む エンジンやルールが「出しているつもり」の値ではなく、**カレンダーAPIの実値**を読む。 さらに**顧客が実際に見る画面を開いて読み戻す**（ヘッドレスブラウザで可）。 API値と実表示は日常的にズレる。特に「値が取れていない」と「値が空」は API 越しには区別がつかない。 ### 4. 突き合わせて、外れている帯を1つに絞る | 何日前 | 提示 | 実勢ADR | 乖離 | |---|---:|---:|---:| | 0〜7日 | … | … | +8% | | 8〜30日 | … | … | **+35〜58%** ← ここ | | 61日〜 | … | … | +18〜27%（妥当） | **全帯が一律に高い、という結論はまず出ない。** 出たら計算を疑う。 ### 5. 倍率・係数も実勢で検算する 曜日倍率・繁忙期倍率のような**全リードタイムに掛かる係数**は、外れていると全期間で外れ続ける。 曜日ごとの実勢単価を出して比べる。 平日基準 = 月〜木の泊数加重ADR 金・土の実勢が 平日比 ×1.06〜1.09 しかないのに 係数 ×1.5 を掛けていた、という実例がある。 ### 6. 価格で説明できない時は在庫を疑う（最重要） **価格をいくら較正しても、在庫が0の日は1円も売れない。** そして在庫の穴は 価格の検証では絶対に見つからない（価格は正常に並び、送信ログも緑のまま）。 GET /inventory/rooms/calendar?propertyId=<物件ID>&startDate=<今日>&endDate=<2年先>&includeNumAvail=true 取れた区間を「開/閉」に畳んで眺める。次の形が出たら**設定の穴**を疑う: - 閉じている区間の境界が**祝日でも季節の変わり目でもない中途半端な日付** - **年末に閉じて元日に開く**ような、運用上ありえない切り方 - ずっと先（2年後など）にも同じ形の閉区間がある ＝「開けた区間の継ぎ目」 判定材料は**去年の同じ期間の実績**。去年そこが高稼働・高単価で売れていたなら、 意図的な休業ではなく開け忘れ。 ### 7. 外向きの変更は数字を出して承認を取る 値下げも在庫開放も**外から見える不可逆な変更**。「どの帯を何%」「開けると何室日ぶん」を 数字で出してから実行する。実行後は**新しい値が出ていること**と**古い値が消えていること**を **セットで**読み戻す（片方だけだと残留に気づけない）。 ## 出力テンプレ（このまま報告に使える） ``` ## 結論 仮説「<最初の仮説>」は <支持された / 外れた>。 外れている帯は （実勢比 +X%）。<遠い側/近い側> は妥当。 ## 根拠 ① 実勢ADR（リードタイム別・泊数加重・n=…） ② 同じN日前の過去ペースとの比較 ③ 提示価格の実表示（画面で確認した値） ## 確認していないこと <認証が無くて見られていない画面・分離できていない交絡（季節性など）を正直に書く> ``` ## チェックリスト - [ ] ページングを最後まで回した／分割応答を継ぎ足した - [ ] キャンセル・ブロック枠を除外した - [ ] 単価は泊数加重で出した - [ ] 過去との比較は「同じN日前」に揃えた（月別平均と比べていない） - [ ] 提示価格は**画面**でも確認した - [ ] 在庫（`numAvail`）を年単位で見た - [ ] 外向きの変更は数字を出して承認を取った ---