値下げが元を取れたかを RevPAR で判定する（宿泊・OTA運用）

「稼働率が上がった／下がった」だけを見ると値下げの評価を必ず間違える。 単価×稼働＝RevPAR で見ると逆の結論になることがある。実測でそれが起きた事例をもとに、 予約明細だけから機械判定まで持っていく手順をまとめる。

外部APIを新たに叩かない。手元にある予約明細（1件1レコード）だけで完結する。

0. 前提: 必要なフィールド

チャネルマネージャ／PMS の予約エクスポートに次があれば足りる。

用途	フィールド
有効判定	ステータス、キャンセル日時、予約日時
期間	チェックイン日、チェックアウト日
金額	滞在合計金額（グロス＝客が払う額）、手数料
切り分け	チャネル名（OTA名）
対象絞り	部屋ID

注意: 金額は「滞在合計」であって1泊単価ではないことが多い。 泊数で割る前に必ず確認する。

1. 泊単位に展開する（ここを間違えると全部狂う）

1予約を 泊数 = チェックアウト − チェックイン に展開し、 金額と手数料を泊数で等分して各泊に配る。泊が属する月は その泊の日付で決める（チェックイン日で決めると月境をまたぐ連泊が全部前月に寄る）。

日付演算は必ず UTC で行う。new Date('2026-09-16T00:00:00Z') と + i*86400000。 ローカルタイムゾーンで足すと夏時間・タイムゾーン跨ぎで1泊ずれる。

除外するもの

• セット販売用の仮想部屋（複数部屋を1商品として売るための架空の部屋ID）。 実部屋IDのホワイトリストで絞る。仮想部屋を混ぜると単価が数倍に化ける。
• キャンセル済み・仮予約・金額0。

落とした件数を理由別・年別に必ず出力する。 「有効N件」だけ出すと、 片方の年だけフィルタで大量に落ちていても気付けない。

2. 3つの指標を必ず並べる

指標	式	分母
稼働率	売れた室泊 ÷ capacity	capacity = 部屋数 × 日数
ADR	収益 ÷ 売れた室泊	売れた室泊
RevPAR	収益 ÷ capacity	capacity

RevPAR の分母は売れた室泊ではなく capacity。 ここを間違えると ADR と同じ数字になる。

グロス（客が払う額）とネット（手数料を引いた手残り）の両方を出す。 チャネルごとに手数料率が違うので、構成が変わるとグロスとネットで前年比がずれる。

3. 比較の窓を先に決める（ここで結論が変わる）

3-1. 未完了月を除外する

月末が今日より前の月だけを前年比に使う。当月・未来月はまだ予約が積み上がる途中で、 入れると必ず「今年は激減」に見える。除外した月を明示的に出力する。

3-2. 前年側がイベントで汚染されていないか確かめる

万博・オリンピック・大型国際会議のような一過性の需要イベントは、 前年の ADR を1.3〜1.8倍に膨らませる。その期間と比べると自動的に「今年は半減」になる。

やること: イベント期間にかかる月を前年側から外した窓をもう1本作り、両方の結果を並べる。 片方だけ出すと結論を選んでいるのと同じ。

実例: 前年ADRが 14,000〜18,255 の月はすべてイベント期間内で、 イベント外の月は 9,944〜11,652 だった。前年比 −40% が −28% になった（が符号は変わらなかった）。

4. チャネル構成の変化を分離する（shift-share）

「単価が落ちたのは高単価チャネルが消えたからだ」を検証する。 s_c = チャネル c の室泊シェア（Σ=1）、a_c = チャネル c の ADR。

総変化  total = Σ s'_c·a'_c − Σ s_c·a_c
構成効果 mix   = Σ (s'_c − s_c) · a_c      ← 構成が変わったことによる分
単価効果 rate  = Σ s_c · (a'_c − a_c)      ← 各チャネルの自単価が動いた分
交差項  inter  = Σ (s'_c − s_c) · (a'_c − a_c)

mix + rate + inter === total を ±1 で assert する。 合わなければ実装が間違っている （片方の年に存在しないチャネルの扱いが典型的な原因）。合わなかったら異常終了させる。

片方の年に0泊のチャネルは、ADR を 0 にすると mix 効果が暴れる。 相手年の ADR を流用して「純粋なシェア移動だけ」を mix に載せる。

説明力の計算で符号を間違えない

「低下のうち構成変化で説明できる割合」= mix / total。 絶対値の比 |mix|/|total| にしてはいけない。 構成変化が単価を押し上げていた場合 （mix と total が逆符号）、絶対値比が 50% を超えて「構成変化で説明できる」と誤判定する。 逆符号なら説明力は 0% と数える。符号付きの生の比も併記して隠さない。

反実仮想も1本出す: Σ s_c(前年の構成) · a'_c(今年の単価) ＝「構成が変わっていなければ今年の ADR はいくらだったか」。

5. RevPAR を単価要因と稼働要因に分ける

RevPAR = ADR × 稼働率 なので同じ形で分解できる。

ADR効果 = (a' − a) · o
稼働効果 = a · (o' − o)
交差項  = (a' − a) · (o' − o)

ここでも和が ΔRevPAR と一致することを assert する。 出力は「RevPAR低下のうち単価由来 X% / 稼働由来 Y%」の1行にする。

6. 値下げの取引レートを出す（これが判定の核心）

値下げは「単価を売って稼働を買う」取引。レートで評価する。

ADR 1% 下げあたり獲得できた稼働pt = 稼働の前年差pt ÷ (−ADR前年比%)
RevPAR中立に必要だった稼働%      = 前年稼働% × (前年ADR ÷ 今年ADR)
不足pt                            = 必要稼働% − 実際の稼働%

必要稼働が 100% を超えたら、その価格帯では構造的に取り返せない。 値下げ幅を議論する前にこれを出す。

実例: ADR −34.4% に対して稼働は +6.6pt しか動かず（1%下げあたり 0.2pt）、 RevPAR 中立に必要な稼働は 128.1% ＝ 満室でも不可能だった。

7. exit code で機械判定する

人が表を読んで解釈すると、見たい結論が出る。判定を式にして終了コードに落とす。

mix / total >= 50%  → チャネル構成変化で説明できる  → exit 0
mix / total <  50%  → 自社の値付け由来が主因        → exit 1
整合性 assert 失敗                                  → exit 2

イベント汚染を外した窓の判定を採用し、汚染込みの窓と食い違ったら警告を出す。 両方の数字を出力してから、採用した窓を1行で宣言する。

--json を付けたら全指標を JSON で出す（表は出さない）。終了コードは同じにする。 これで日次バッチから叩ける。

8. 結論を書くときの限界（誠実さの担保）

この手順で確定できるのは次の2点だけ。

• 構成変化では説明できない
• 獲得した稼働が RevPAR 中立に足りていない

「自社が値下げしたから単価が落ちた」と「市場全体の単価が落ちた」は自社データでは分離できない。 分離するには対照群（同エリアの他施設の公開情報など）が要る。 ただしどちらであっても「現行価格は volume で正当化できない」は変わらないので、 打ち手の判断はこの手順だけで下せる。

値下げの適用日と単価低下の開始日を必ず突き合わせる。 実例では値下げ施策の適用は8月末で、 単価低下は同年1月から始まっていた。施策は原因ではなく、値付け体制全体の問題だった。 日付が合わなければその仮説はそこで終わり。

9. 落とし穴チェックリスト

• 金額は滞在合計か1泊単価か確認したか
• 泊が属する月をチェックイン日でなく泊の日付で決めたか
• 日付演算を UTC でやったか
• 仮想部屋を除外したか
• 落ちた件数を理由別・年別に出力したか
• 未完了月を除外し、除外した月を出力したか
• 前年側のイベント汚染を外した窓を並べたか
• RevPAR の分母を capacity にしたか（売れた室泊ではない）
• グロスとネットを両方出したか
• shift-share の和を assert したか
• 説明力を絶対値比にしていないか
• 月別の予約件数（サンプル数）を出したか
• 判定を exit code に落としたか