なぜ必要か
- 班分けは制約が多い：役割（CL/SL/係）、運転、通信キャリア、学年や経験などを同時に考慮
- 装備分担は不公平感が出やすい：重量の平準化に加えて、経験に応じた調整も必要
- 手作業だと試行回数が不足しがち：条件比較や説明の難しさがボトルネック
Quantum Mountain Optimizer
Q-Sherpa
ABOUT1 / 6
安全な班分けと、公平な装備配分
登山計画で難しい「安全なチーム編成」と「不公平感のない装備分担」を、数理最適化（量子アニーリング / QUBO風）で支援するデモアプリです。
Scroll / Trackpad で次のスライドへ
BACKGROUND2 / 6
背景：なぜ最適化が必要か
デモの狙い
- 入力（重み・パラメータ）→ 実行 → 出力の流れを体験できる
- ステップ形式で段階的に提示し、理解コストを下げる
- 失敗（解なし等）も UI 上で扱い、再実行しやすい導線を用意
4 フェーズ（UI）
- メンバー選択
- 班分け結果
- 装備選択
- 装備配分結果
OVERVIEW3 / 6
アプリの概要
何を解くか
本システムは、メンバー属性（学年・性別・係・CL/SL資格・運転可否・通信キャリア・経験年数）を入力に、 班分けと装備配分を段階的に最適化します。
キーポイント
- 通信キャリアが偏らないように分散（通信途絶リスクの低減）
- ドライバー人数の偏りを抑制（車両運用の実現性）
- 係（equipment / weather / meal）の偏りを抑制
- 経験年数の分布を調整（チーム間の均等化、または同質化）
- 結果は /demo でステップ形式に可視化
API 連携
フロントは Nuxt の proxy を利用してAWS Lambdaにホストされているバックエンドに /api/* にアクセスします。 例: GET /api/members, POST /api/grouping。
STACK4 / 6
スタック
Frontend
- Nuxt.js
- Vue 3 + TypeScript
- SCSS
- Proxy 経由で API を呼び出し（/api/**）
Backend
- FastAPI
- Pydantic モデル（Member / Equipment / Settings）
- OpenJij（Simulated Annealing）
- jijmodeling + OMMX（問題定式化とアダプタ）
MODEL5 / 6
計算モデル
Phase 1: 班分け（Grouping）
決定変数は「メンバー m をチーム k に割り当てる」二値変数を中心に構成します。 目的関数は、人数・学年・性別・係・ドライバー・キャリア・経験年数の偏りをペナルティとして加え、 制約（例: 全員は必ず1チーム、各チームにCL/SLは各1名、CLとSLは同一人物不可）を満たす解を探索します。
目的関数（各項の意味）
/demo の「班分け設定（重み）」は、このペナルティ項の優先度を調整します。
Phase 2: 装備配分（Equipment Assignment）
装備 e をメンバー m が持つかを二値で表現し、「全ての装備は誰か1人が持つ」制約のもと、 メンバー間の負荷（重量）を平準化します。 経験年数が高いメンバーほど多く持てるように調整パラメータ P を導入しています。
目的関数（各項の意味）
なぜ“重み”が重要か
同じ「二乗誤差」でも、人数差（1人）と経験年数差（数年）ではスケールが異なります。 そのため、重要制約（運転・役割など）を優先させるには、経験系の重みを相対的に小さくする等の調整が有効です。
ROADMAP6 / 6
今後の展開
拡張アイデア
- D-Wave Leap（ハイブリッドソルバー）への接続
- 食料消費など日毎の重量変化を考慮した動的計画
- フォーム連携による自動入力（運用導線の改善）
課題
- 制約が厳しすぎると解が見つからない場合がある（試行回数や重み調整が必要）
- 目的関数のスケール調整（重みの初期値・上限設計）
- 結果の説明可能性（なぜその割当になったか）