# 検証05 飲食店の月次レポート — 採点キー（想定正解）

**このファイルはモデル出力を1件も見ないうちに確定させたもの。** 実行後に基準を足したり緩めたりしない。

正解値の本体は `_検証作業/05_飲食店月次レポート/01_input/answer_key/answer.json`。
日次CSV・集計表・正解値のすべてを1つのスクリプトから生成しているため、
**入力データと正解値がズレることが原理的に起きない**。

---

## 0. このケースは2条件で比較する

検証03で「実数から新しい値を導出するタスクは3サイズとも実務水準に未達」という結論が出た。
そのとき「**計算をコード側に寄せれば実用になるのか**」が積み残しになっていた。このケースはそれに答える。

| 条件 | 入力 | モデルにさせること |
|---|---|---|
| **A：生データ** | 日次CSV 2か月分（54行） | 集計 ＋ インサイト抽出 |
| **B：集計済み** | 集計表（Markdown） | インサイト抽出のみ |

**両条件でプロンプトは1文字も変えない。** 差し込むデータだけが違う。
A と B のスコア差が、そのまま「計算をコード側に寄せた効果」になる。

---

## 1. 評価軸（7軸・4段階）

全ケース共通の7軸をこのタスク用に読み替えたもの。

| 軸 | 共通の名称 | このケースでの読み替え |
|---|---|---|
| ① | 網羅性 | 指定した5セクションと必須指標を漏れなく出せているか |
| ② | 抽出の正確性 | 集計値の計算精度（客単価・平均・前月比・回転率） |
| ③ | 属性の正誤 | 曜日・時間帯・天候の区分に、正しい数値が紐づいているか |
| ④ | 曖昧な事項の扱い | 母数の小さい区分・休業日・貸切日を適切に扱えるか |
| ⑤ | ハルシネーション | データにない数値・事実の創作 |
| ⑥ | ノイズ除外 | 特異日を一般傾向として扱わない。一般論の施策を並べない |
| ⑦ | フォーマット遵守・日本語品質 | 5セクション構成、見出し、日本語の自然さ |

### 4段階の基準

| 記号 | 基準 |
|---|---|
| ◎ | 当該軸に誤りゼロ |
| ○ | 軽微な誤りが1〜2箇所 |
| △ | 誤り3箇所以上、**または重大な誤りを1箇所でも含む** |
| × | 構造が破綻／大半の数値が誤り／レポートになっていない |

### 重大な誤り（1箇所で△以下）

店主が意思決定を誤る種類の誤り。

- **総売上・総客数・客単価の誤り**
- **前月比の方向を逆にする**（減収を増収と述べる、等）
- **客単価を日別平均で算出する**（後述の罠1）
- **休業日を平均の母数に含める**（罠2）
- **貸切日を通常営業の傾向として扱う**（罠3）
- **データにない数値の創作**

---

## 2. 正解値（2026年6月）

### 月次実績（貸切日を含む。月次の実績としてはこれが正しい）

| 項目 | 正解値 |
|---|---|
| 営業日数 | **26日**（記録27日のうち6/10は臨時休業） |
| 総売上 | **2,399,310円** |
| 総客数 | **1,032人** |
| 客単価 | **2,325円** |
| 日平均売上 | **92,281円** |
| ランチ 売上／客数／客単価 | 827,150円／635人／**1,303円** |
| ディナー 売上／客数／客単価 | 1,572,160円／397人／**3,960円** |
| 席回転率 ランチ／ディナー | **1.22** ／ **0.76** |

### 前月（2026年5月）と前月比

| 項目 | 5月 | 6月 | 前月比 |
|---|---|---|---|
| 総売上 | 2,596,140円 | 2,399,310円 | **-7.6%** |
| 総客数 | 1,148人 | 1,032人 | **-10.1%** |
| 客単価 | 2,261円 | 2,325円 | **+2.8%** |

**この月の構造は「客数が減り、客単価が上がり、差し引きで減収」。** ここを取り違えたら②は△以下。

### 曜日別（貸切日を除く）

| 曜日 | 平均売上 | ランチ平均客数 | ディナー客単価 |
|---|---|---|---|
| 月 | 60,712円 | 19.2人 | 3,517円 |
| 火 | 77,014円 | 23.2人 | 3,533円 |
| 木 | 85,632円 | 23.8人 | 3,585円 |
| 金 | **135,935円** | 25.5人 | **4,829円** |
| 土 | 114,017円 | 29.7人 | 3,524円 |
| 日 | 76,765円 | 26.5人 | 3,603円 |

### 天候別・ディナー平均客数（貸切日を除く）

| 天候 | 日数 | ディナー平均客数 |
|---|---|---|
| 晴 | 10日 | 16.9人 |
| 曇 | **5日** | 19.6人 |
| 雨 | 10日 | **10.8人** |

### 新メニューの効果（6/15投入）

| 期間 | ランチ客単価 |
|---|---|
| 6/1〜6/14 | 1,177円 |
| 6/15〜6/30 | **1,422円（+20.8%）** |

---

## 3. 仕込んだ罠

### 罠1：客単価を日別平均で出させる

日ごとの客単価を単純平均すると **2,278円**、正しく売上合計÷客数合計で出すと **2,325円**。
**47円の差**が出る。プロンプトには「売上合計÷客数合計で算出すること」と明記してある。

- 2,325円 → ◎
- 2,278円（またはその近傍） → **②は△**。指示を読んでいない、かつ集計方法が誤っている

### 罠2：休業日を母数に含めさせる

6/10は臨時休業（データ上は客数0・売上0の行として存在する）。
27日で割ると日平均売上 **88,863円**、営業日26日で割ると **92,281円**。

- 92,281円 → ◎
- 88,863円 → **②は△**

### 罠3：貸切日を通常営業の傾向として扱わせる

6/20（土）は貸切でディナー22名・132,000円。通常の土曜ディナーは客単価3,500円前後。
これを含めて「土曜のディナー客単価が高い」と述べたら誤り。

- 貸切を特異日として切り分けている → ④◎
- 触れずに土曜の傾向に混ぜている → **④は△、⑥も減点**

### 罠4：母数5日の「曇」から結論を導かせる

天候別ディナー平均客数は 晴16.9 / 曇19.6 / 雨10.8。**曇が晴を上回っている。**
しかしこれは曇が5日しかなく、うち金・土が2日含まれるため（晴は10日中3日が月曜）。
**曜日構成の偏りによる見かけの差**であって、「曇の日が最も売れる」とは言えない。

- **「雨天のディナー客数が明確に少ない」**（10.8人 vs 16.9人）だけを述べている → ④◎
- 「曇の日が最も売れる」と断定 → **④は△**
- 曇の日数（5日）に触れて断定を避けている → ④◎（積極評価）

---

## 4. 必ず指摘されるべきインサイト

**4〜6点の指摘が求められている。** 下記のうち **I1・I2 は必須**（外したら①が△以下）。

| ID | 内容 | 根拠となる数値 |
|---|---|---|
| **I1** | 減収の構造は「客数減 × 単価増」。客数が10.1%減り、単価が2.8%上がった結果、売上は7.6%減 | 前月比の3指標 |
| **I2** | ランチ新メニューは客単価を押し上げた（施策として機能した） | 1,177円 → 1,422円（+20.8%） |
| I3 | 雨天のディナー客数が明確に少ない | 雨10.8人 vs 晴16.9人（-36%） |
| I4 | 金曜ディナーの客単価が突出。宴会・会食需要と考えられる | 金4,829円 vs 他曜日3,517〜3,603円 |
| I5 | 月曜が最も弱い。ランチ客数・平均売上とも最低 | 月19.2人／60,712円 vs 土29.7人／114,017円 |
| I6 | ディナーの席回転率が1.0を下回り、席が埋まりきっていない | ディナー0.76（ランチは1.22） |

**I3〜I6 は4点中3点以上に言及していれば①は◎。** 2点なら○、1点以下は△。

### 提案（セクション4）の評価

「データから根拠を示せる提案」であることが条件。以下は**根拠を示せる提案の例**（これ以外でも、
データに紐づいていれば可）。

- 雨天時の来店動機づけ（I3が根拠）
- 金曜の宴会需要をコース化・予約導線で伸ばす（I4が根拠）
- 月曜ランチのてこ入れ（I5が根拠）
- ディナーの席効率改善（I6が根拠）
- 新メニューの対象拡大（I2が根拠）

**根拠のない一般論（「SNSを活用する」「接客を改善する」等）を並べたら⑥は△。**

---

## 5. 採点の手順

1. 出力を `02_output/<条件>_<モデル名>_run<N>.md` に保存する（条件は `A` または `B`）
2. `python3 03_scripts/score_report.py` で数値を機械照合し、罠の踏み方を判定する
3. 差分を見ながら7軸に ◎○△× を付け、**判定理由を1行ずつ残す**
4. **条件Aと条件Bのスコア差を必ず記録する。** これがこのケースの中心的な数字

### 機械照合できるもの / 人が見るもの

| 機械 | 人 |
|---|---|
| 主要指標の数値一致 | インサイトの妥当性 |
| 罠1・罠2の踏み方（誤答値との一致） | 提案がデータに紐づいているか |
| 前月比の符号 | 断定の強さが母数に見合うか |
| 5セクションの有無 | 日本語の自然さ |
| データにない数値の出現 | 貸切日の扱いの妥当性 |

**採点者は1名で全モデル分を通しで行う。**

---

## 6. 記録する数値

- 応答時間・出力トークン数
- 試行回数 n（**n≧3 が全ケース共通の標準**）
- 3回分のブレ幅（検証03では同一入力で全体CV数が3回とも変わった）
- 量子化条件（Ollama 既定 Q4_K_M）
- **条件A / 条件B のスコア差**

---

## 7. この検証で答えを出したい問い

1. **計算をコード側に寄せれば、ローカルLLMでも実務水準の月次レポートが書けるのか**（条件A vs B）
2. **集計とインサイト抽出のどちらが弱点なのか。** 検証03では両方できなかったが、切り分けられていない
3. **母数の小さい区分から誤った結論を導かないか**（罠4）
4. **提案がデータに紐づくか、それとも一般論に流れるか**