RetailBrain 要件定義

1. 目的

消滅期限のある在庫（惣菜・施術枠）について「今いくらで売るべきか」を、限界利益と機会費用から算出し、 現場で実際に行われている一律ルールとの利益差を比較する単一ページのシミュレータ。

目的は事業運用ではなくポートフォリオである。 採用担当者が1つのURLを開き、90秒で「小売の利益構造を理解した上で作られたシステムだ」と判断できる状態を作る。

2. 中核概念 — 消滅期限付き在庫

物販とサービスは一見別物だが、「売れ残りの価値がゼロ」という一点で同じ型に統合できる。 したがって限界利益がプラスである限り、売らないより売るほうが合理的である。 この一点で業種を横断できることが、本プロダクトの主張である。

3. 会計ロジック仕様

会計計算は予測ではなく恒等式である。したがって合成データ上でも一切の疑義が生じない。 本システムで最初に、かつ最も厚く作る層はここになる。

3-1. 用語規約

売上原価ベースの粗利率と変動費ベースの限界利益率は、小売では近い値になるがサービス業では 人件費が売上原価に入るかどうかで結果が反転しうる。用語を混ぜた時点で実装は必ず間違える。

3-2. 動的下限価格

floorPrice = incurredIfSold + opportunityCost - disposalCostAvoided

  incurredIfSold      = (kind === "CAPACITY" ? variableCost : 0) + incrementalSellingCost
  disposalCostAvoided = (kind === "STOCK" ? disposalCost : 0)
  opportunityCost     = この1個を今売らずに残した場合の期待限界利益

この式から2つの帰結が出る。両方を画面で説明する。

1. STOCK で廃棄費用が正なら、下限価格は理論上マイナスになりうる。 処理費を払って捨てるより 0円で配るほうが得な領域が実在する。これが本システムで最も驚かれる結論であり、隠さず目立たせる
2. 第2項の機会費用が「時点間カニバリ」の正体。 値引きが早すぎると、定価で買ったはずの客に安く売ることになる。これが下限価格が時間の関数である理由であり、 本問題が逐次意思決定＝動的計画問題になる理由でもある

fixedCostAlloc（固定費配賦）は表示専用とし、値引き判断のロジックに入れない。 入れた瞬間に全部原価思考へ戻る。

3-3. 値引き耐性 — 中心となる問い

requiredVolumeLift = 値引額 ÷ (元の単位限界利益 − 値引額)

例: 限界利益率40%の商品を10%引き
    10 ÷ (40 − 10) = 0.33  →  33%の販売増がなければ利益は減る

分母が 0 以下なら回収不能なので null を返す（0除算や Infinity を返さない）。 現場担当者はこの数字を知らずに値引きしている。「その値引き、33%売れないと損です」と即座に出せることが、 本プロダクトの最も分かりやすい価値である。

3-4. 実装する関数

netContribution = revenue - variableCost - incrementalSellingCost - disposalCost

  variableCost : STOCK    → unit.variableCost × initialQty（ポリシー間で定数）
                 CAPACITY → sold 比例

4. 需要モデル

営業日は 10:00〜22:00 を30分刻みにした24スロット。商材は slot 0 から自分の expiryAt の直前スロットまで販売でき、expiryAt 到達時点の残数が廃棄になる。

q(p, t) = arrivalCurve[t] × baseQty × (p / listPrice) ^ eps(t)
eps(t)  = elasticity × (1 + elasticityTimeAmp × (1 − remainingRatio))

remainingRatio = 残スロット数 ÷ その商材の全販売可能スロット数

実現需要は平均 q のポアソン乱数（シード固定）。sold = min(demand, remaining)。

4-1. パラメータ台帳と出典

4-2. 既知の限界

• −2.62 はブランドレベル、かつ主に食料品・日用消費財の数値。サービス業や専門サービスにそのまま適用できない。 従うべき法則ではなく、更新すべき事前分布として扱う
• Bijmolt らは、価格の内生性を考慮すると弾力性の絶対値が大きくなる方向に強い影響があると報告している。素朴な推定は過小評価側に振れる
• 本システムは弾力性を推定していない。外部から与える。よって推定精度は主張の対象外である
• baseQty は「定価のままなら初期在庫の約75%が売れる」水準に自動調整している。これは値引き判断に意味が出るように置いた設計値であり、実測値ではない

5. 3ポリシーと評価

ENGINE は後ろ向き帰納法（動的計画法）で解く。状態は (slot, remaining)、遷移はポアソン需要を残数で打ち切ったもの。 opportunityCost(t, r) = V(t+1, r) − V(t+1, r−1)（1個余分に持つことの限界価値＝シャドープライス）。

3ポリシーは必ず同一シードの同一乱数系列で回す。別々に引くと、ポリシーの比較が乱数の比較になる。

5-1. 評価指標

本システムは意思決定エンジンであり、予測精度が上がっても利益が下がることは普通に起きる。 発注・値引きは欠品コストと過剰コストが非対称な newsvendor 構造であり、最適解は期待値ではなく分位点になる。 点予測の誤差最小化は目的関数として構造的に誤りである。

5-2. 主張してよい範囲

6. 感度分析 — 本システムの目玉

「自分が決めた弾力性で、自分のエンジンが勝った」では説得力がない。 弾力性・来店強度・廃棄費用をスライダーで可変にし、勝つ領域と負ける領域の境界を提示する。 検証不能という弱点を、感度分析という機能に転換する。

出力例:

弾力性 −1.2 以上の領域では ENGINE は FLAT_RULE に +8〜+15% の利益差で勝つ
弾力性 −0.8 を下回ると負ける
  （客が価格に反応しないため、早期値引きは定価売上を削るだけになる）

乱数のばらつきで境界が暴れるため、各点は複数シード（既定20）の平均を取る。

7. 画面要件

単一ページ。上から下へ読むだけで結論に到達する構成とする。

領域7は意匠ではなく信頼設計である。隠すと疑われ、出すと誠実に見える。

8. データ構造

type ItemKind = "STOCK" | "CAPACITY";
type PolicyId = "NO_ACTION" | "FLAT_RULE" | "ENGINE";

interface InventoryUnit {
  unitId: string;
  name: string;
  kind: ItemKind;
  listPrice: number;              // 定価（円）
  variableCost: number;           // 単位変動費。仕入原価・材料費・施術人件費を含む
  incrementalSellingCost: number; // 追加販売コスト（値引シール・レジ手間）
  disposalCost: number;           // 単位廃棄費用。CAPACITY は常に 0
  fixedCostAlloc: number;         // 固定費配賦。表示専用。判断に使わない
  initialQty: number;
  expiryAt: string;               // ISO8601。消滅時刻
}

このモデルが通れば、スーパーの惣菜も、整体の空き枠も、美容室のカラー枠も、飲食店の平日ランチ席も 同じエンジンで処理できる。型を分けないこと自体が主張である。 全型定義は types/index.ts（Day 1 に凍結）を正とする。

9. 技術スタック・スコープ境界

スコープ外（着手しかけたら止める）: 外部API接続すべて（気象庁・Open-Meteo・e-Stat・RESAS・国土地理院）／公共データ基盤／ 機械学習による需要予測／顧客・スタッフアプリ／ピッキング・EC機能／LINE連携・クーポン配信／ 認証・マルチテナント・DB永続化／3年分500SKU規模の合成データ生成器。

カニバリ引当と予実差異分析は、型にフィールドだけ用意し実装は後日とする（切ってよい）。

10. 開発計画と成功条件

Day 7 の判定基準