生協メニュー評価診断アプリ

ジェネレータの渡し方は docs/guides/student-sharing.md を参照。

Windows 初回: docs/guides/windows-setup.md

• 制作中: リポジトリ共有 + npm run dev → /scenario/
• 提出: ZIP エクスポート（.scenario.zip）
• menuPick: メニュー画像を使うためローカル or デプロイ URL が必要

目的

• Excel/PDF 由来データの JSON・画像表示を確認する
• スマホ向けペアワイズ比較 UI を試し、本番運用の設計材料とする

権利・データ

• メニュー情報・画像は内部検討のみ。再配布・一般公開禁止
• 画像の権利は生協・仕入先規約に従う
• 本番想定: 会員番号は SHA-256 ハッシュ、回答は D1 保存（試作版は端末内のみ）
• 公開ホスティング時はアクセス制限を検討

UX（試作で採用）

• 縦2カード・1タップ・450ms で次へ。比較中は価格非表示

出題方式

現状（試作 Phase 1）

• 固定 JSON（test-2026-05）— 主菜・副菜・デザート各5問、計15問
• ペアは事前に人手選定。全員が同じ問に回答（再現性重視）
• 回答は端末内のみ。集計・ランキングは未実装

理想（本番想定）

• カテゴリ単位のプロジェクト — 例「今月の主菜評価」のみ15問。混在カテゴリは集計が分散するため避ける
• サーバー側ランダムペア生成 — group で絞り込み → 出現回数の少ないペアを優先 → セッション内で同一 menu_cd を1回まで
• 1セッション上限15問（約3〜5分）。session_type: "random" で試作データと区別
• 極端に速い回答（response_time_ms < 300）は集計から除外

Bradley-Terry と必要回答数

• 目安: 各品目が約10回以上、対戦に登場すると推定が安定（計画書・レビューより）
• 主菜52品の例: 52品 × 10回 ≒ 520回の品目登場 → ペア対戦は約 260回（1対戦で2品目）
• 1人15問・主菜のみ → 260 ÷ 15 ≒ 18人が理論下限。ランダム配分の偏りを考慮し 50〜80人で上位ランキングの傾向が見える想定
• 試作のように主菜5問のみ/人 → 520 ÷ 5 ≒ 100人以上で主菜全体を厚くカバー
• 50人未満 → 単純勝率で参考程度。50人以上 → Bradley-Terry を本採用

※試作の15問固定（主菜5問のみ）では全ペアの0.4%未満しかカバーできず、メニュー決定には使えない。本番はカテゴリ別＋ランダム生成が前提。

集客・プロモーション（案）

• 学食店内 — レジ・テーブル QR、メニュー決定に参加する旨の POP（1〜2週間の期間限定）
• 会員向け告知 — 生協アプリ通知・メールマガジン・公式 LINE（「次月メニューに反映」など参加動機を明示）
• インセンティブ — 回答完了で抽選（商品券・学食割引）、または先着特典（コストと回答数のバランス要検討）
• タイミング — 昼食時間帯・メニュー企画の締切2〜3週前。所要3〜5分を明記
• 目標人数 — 傾向把握: 50人 / 主菜を厚く: 80〜100人 / 副菜・デザートは品数に応じて同様に試算
• 重複防止 — 会員番号ハッシュで1人1回（またはカテゴリごと1回）。スタッフ・関係者回答は集計から除外するルールも検討