ペース連動の値付けで『達成不能な目標稼働』が遠い日付を恒久的に最大値下げにする罠と、リードタイム閾値で値下げだけ止める実装

ペース連動の値付けで『達成不能な目標稼働』が遠い日付を恒久的に最大値下げにする罠と、リードタイム閾値で値下げだけ止める実装

症状

• 先の日付（例: 91日以上）の価格が常に 係数 0.70 で固定される。
• 1室が売れると係数が 1.025 に跳び、前日比で +46% の段差が生じる。
• 価格を下げても遠い帯は売れない。実際に空室が残っているのはリードタイムが長すぎるため。
• RevPAR が前年同期に比べて減少し、目標稼働率が遠のく。

原因（数式で）

// soldRatio : 実際販売数 ÷ 目標販売数
// target    : 目標販売率（帯ごとに設定、例 0.10）
// shortfall : (target - soldRatio) / target
// excess    : (soldRatio - target) / target

function paceFactor(soldRatio, target) {
    var factor;
    if (soldRatio < target) {
        var shortfall = (target - soldRatio) / target;
        factor = Math.max(0.70, 1 - 0.30 * shortfall);
    } else {
        var excess = (soldRatio - target) / target;
        factor = Math.min(1.10, 1 + 0.10 * excess);
    }
    return factor;
}

• 退化条件: target * inventory < 1 の帯では、目標販売数が 1 室未満になるため soldRatio が常に 0 となり shortfall = 1 → factor = 0.70 が固定化する。

直し方

1. リードタイム閾値を設定できるように config.pace.noDiscountMinLeadDays を導入する。

   • デフォルトは 91 日。
   • 0 以下に設定すると機能を無効化する。

2. 係数計算直後にガードを挿入するだけで完了する。

// 既存の paceFactor 呼び出し直後に追加
var factor = paceFactor(soldRatio, target);

var threshold = (typeof config !== 'undefined' && config.pace && typeof config.pace.noDiscountMinLeadDays === 'number')
    ? config.pace.noDiscountMinLeadDays
    : 91; // デフォルト

if (threshold > 0 && daysAhead >= threshold && factor < 1.0) {
    factor = 1.0;
    record.paceDiscountSuppressed = true; // デバッグフラグ
}

• 値上げ側 (factor > 1.0) と残室連動の上乗せロジックは一切触らない。
• 閾値未満の日付は価格を一切変更しない。

テストの型（旧オラクル方式）

1. 旧オラクルの保存

   • 既存実装を oldPaceFactor.js としてテストディレクトリにコピーする。
   • 同ファイルにガードだけを足した oldPriceGuarded.js を作成する。

2. 全域比較テスト

for (var daysAhead = 8; daysAhead <= 200; daysAhead++) {
    for (var sold = 0; sold <= 4; sold++) {
        var target   = getTargetForBand(daysAhead);
        var inv      = getInventoryForBand(daysAhead);
        var soldRatio= sold / (target * inv);

        var newFactor = computeFactorWithGuard(daysAhead, soldRatio, target);
        var oldFactor = oldPriceGuarded(daysAhead, soldRatio, target);

        // 1円単位の一致を保証
        assert(Math.abs(newFactor - oldFactor) < 0.01, 'Mismatch at d=' + daysAhead + ', s=' + sold);
    }
}

3. リードタイム閾値専用テスト

// ケース 1: 91日以上、販売なし
var f1 = computeFactorWithGuard(100, 0, 0.10);
assert(f1 === 1.0, 'Factor should be 1.0 for distant band with no sales');
assert(record.paceDiscountSuppressed === true, 'Flag must be true');

// ケース 2: 境界 90日、販売なし（従来通り 0.70）
var f2 = computeFactorWithGuard(90, 0, 0.10);
assert(f2 < 1.0, 'Factor must be discounted before threshold');

// ケース 3: 91日以上、販売あり（値上げ側は変わらない）
var f3 = computeFactorWithGuard(110, 7, 0.10);
assert(f3 > 1.0, 'Upsell factor must stay unchanged');

// ケース 4: 閾値 0 で無効化
config.pace.noDiscountMinLeadDays = 0;
var f4 = computeFactorWithGuard(120, 0, 0.10);
assert(f4 === 0.70, 'Discount must apply when guard disabled');

4. 本番コード自己テスト
   • E1 : 91日・0室は割引しないことを assert
   • E2 : 90日は係数 0.70 になること
   • E3 : 値上げ側 (sold > target * inventory) は係数 > 1.0 のまま
   • E4 : config.pace.noDiscountMinLeadDays = 0 でガードが無効になること

デプロイ前に「前」の実値を保存する

1. API で価格取得

   • 対象期間は閾値前後を跨ぐ 8日分（例: threshold-4 〜 threshold+3）。
   • GET /pricing?start=...&end=... のレスポンスを JSON ファイルに保存する。

2. 公開予約ページのスクリーンショット

   • ブラウザ自動化ツールで同期間のページをキャプチャし、ローカルに保存。

3. デプロイ後の検証

   • 同じ API コマンドで再取得し、閾値以上は係数 1.00、閾値未満は従来のカーブになっているか比較。
   • スクリーンショットでも同様に 、閾値以上の日付の表示額が「値下げ前のカーブ価格」に戻り、閾値未満は変わっていないことを自分の目で確認する。
   • 「前」の値は必ずデプロイ前に取ったものを使う。デプロイ後に自分が動かした値を「前」として比べない。

一般化ルール

• target × 在庫 < 1 単位 になる帯では、不足率モデルは退化する（「0 単位」が常に不足率 100% になる）。
• 直すときは値下げ側だけを止め、値上げ側と残室連動の上乗せは触らない。
• 旧オラクル＋ガード付きオラクルで「ガード以外は 1 円も変わっていない」を全域比較で証明してから出す。