予約データから「価格が高すぎるのか」を判定する手順（リードタイム・ペース曲線）

宿泊・レンタル・イベント席など日付ごとに在庫が消えるビジネスで、「先の予約が薄い」と言われた時に、 憶測で値下げせずに原因を切り分けるための手順書。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. 外向きの変更は数字を出して承認を取る

値下げも在庫開放も外から見える不可逆な変更。「どの帯を何%」「開けると何室日ぶん」を 数字で出してから実行する。実行後は新しい値が出ていることと古い値が消えていることを セットで読み戻す（片方だけだと残留に気づけない）。

出力テンプレ（このまま報告に使える）

## 結論
仮説「<最初の仮説>」は <支持された / 外れた>。
外れている帯は <N〜M日前>（実勢比 +X%）。<遠い側/近い側> は妥当。

## 根拠
① 実勢ADR（リードタイム別・泊数加重・n=…）
② 同じN日前の過去ペースとの比較
③ 提示価格の実表示（画面で確認した値）

## 確認していないこと
<認証が無くて見られていない画面・分離できていない交絡（季節性など）を正直に書く>

チェックリスト

• ページングを最後まで回した／分割応答を継ぎ足した
• キャンセル・ブロック枠を除外した
• 単価は泊数加重で出した
• 過去との比較は「同じN日前」に揃えた（月別平均と比べていない）
• 提示価格は画面でも確認した
• 在庫（numAvail）を年単位で見た
• 外向きの変更は数字を出して承認を取った