opt-request

name	opt-request
description	追加データの依頼書を生成する。何がなぜ必要かを非技術者向けに説明
user_invocable	true

Skill: opt-request（追加データ依頼書の生成）

/opt-request で実行。 最適化の途中で「あのデータも欲しい」となった時に、依頼書を自動生成する。

いつ使うか

• /opt-baseline や /opt-improve の途中で「この情報がないと先に進めない」となった時
• データチームや現場に追加データを依頼する時

---

Opus 4.7 ヒント

• 仮定リストは並列収集: spec.md の仮定テーブル、assess の confidence: low 項目、improve の残課題を 1 メッセージで Read してから依頼書に集約
• 質問は確認型 1 ショットで生成: Q1〜QN の生成は軽い。拡張思考は不要。ただし「回答が変わると結果はこう変わる」の影響説明だけは具体的に書く（数値で）
• 代替データを必ず添える: 「GPS ログがなければ過去の配送伝票でも可」のように代案を 1 つ以上付ける。データが来ない確率を下げる

詳細は reference/opus47_collaboration.md。

---

実行内容

1. 不足情報の分類

必須（これがないと最適化できない）:
  - 制約条件の確認 → 「本当にこの制約は必須？」
  - 目的関数の確認 → 「何を一番良くしたい？」
  - データの欠損補完 → 「この列のNULLは何を意味する？」

強く欲しい（精度が大幅に上がる）:
  - 実績データ → 「今のやり方でどれくらいかかってる？」
  - ドメイン知識 → 「現場のルールやノウハウ」
  - 計測データ → GPS、センサー、ログ等

あると嬉しい（さらなる改善に使える）:
  - 過去の例外 → 「こういうイレギュラーがあった」
  - 季節変動 → 「繁忙期はいつ？」
  - 将来の変化 → 「来年から人が増える？」

2. 確認型質問書の生成

「教えてください」ではなく「こう理解していますが合っていますか？」の形式で書く。 現場の人は白紙の質問には答えにくいが、具体的な仮説を見せると「いやそれは違う」と訂正してくれる。

書き方のルール

✗ 悪い例（答えにくい）:
  「夜勤の必要人数を教えてください」
  「制約を教えてください」
  「どういうルールがありますか？」

○ 良い例（答えやすい）:
  「夜勤は2名必要と理解しています。以下のどれに近いですか？
    A) 2名は絶対必要（安全基準で決まっている）
    B) 通常は2名だが、繁忙期以外は1名でも回る
    C) 2名が理想だが、やむを得ない場合は1名でも可」

○ 良い例（仮定を見せて訂正を促す）:
  「移動速度を30km/hと仮定して計算しました。
   結果、ルートAが2時間かかる計算になりましたが、
   実際の感覚と合っていますか？
    A) だいたい合っている
    B) もっとかかる（実際は○○km/h くらい）
    C) もっと早い」

質問のパターン

パターン1: ハード/ソフトの確認
  「この制約は以下のどちらですか？
    A) 絶対に守らなければならない（法律・安全基準）
    B) できれば守りたいが、他とのバランスで破ることもある」

パターン2: 数値の確認
  「○○を△△と仮定しました。以下のどれに近いですか？
    A) △△で合っている
    B) 実際は□□くらい
    C) 場合による（条件を記入: ＿＿＿）」

パターン3: 優先度の確認
  「以下の2つが両立できない場合、どちらを優先しますか？
    A) ○○を優先（△△は多少犠牲にしてよい）
    B) △△を優先（○○は多少犠牲にしてよい）
    C) ケースバイケース（判断基準: ＿＿＿）」

パターン4: 運用の確認
  「現在は○○のように運用していると理解しています。
    A) その通り
    B) 少し違う（実際は＿＿＿）
    C) 全然違う（実際は＿＿＿）」

3. 依頼書の生成

以下のMarkdownを reports/data_request.md に保存すること。

# 確認事項・追加データ依頼書

## 前提
[最適化のどの段階で、何を検討しているか]
[現時点の結果の要約（例: 「現行10名では2シフト不足。1名追加で全充足可能」）]

---

## 確認事項（ご回答をお願いします）

### Q1: [質問タイトル]
[背景の説明: なぜこれを確認したいか]

現在の理解: **[こう理解しています]**

以下のどれに近いですか？
- [ ] A) [選択肢A]
- [ ] B) [選択肢B]
- [ ] C) その他（具体的に: ＿＿＿＿＿＿＿＿）

→ 回答が変わると、結果はこう変わります: [影響の説明]

---

### Q2: [質問タイトル]
...

---

## 追加データのお願い

| データ | 形式 | なぜ必要か | ないとどうなるか |
|--------|------|----------|---------------|
| [XX] | CSV等 | [理由] | [仮の値で代用するが精度XX%低下] |

- フォーマット: CSV/Excel/JSON いずれでもOK
- 期間: 直近[X]ヶ月分が理想（まず1ヶ月分でも可）

## 現時点の仮定一覧

以下の仮定で進めています。**「これは違う」があればぜひ教えてください。**

| 項目 | 仮定した値 | 根拠 | 結果への影響 |
|------|----------|------|------------|
| [仮定1] | [値] | [根拠] | [この値が変わると○○が変わる] |
| [仮定2] | [値] | [根拠] | [影響] |

4. 仮定の明示

重要: 「データがないからこう仮定した」を常に明示する。 仮定が間違っていれば、最適化結果も間違う。 仮定を具体的な回答候補付きで見せることで、現場の人が訂正しやすくなる。 「教えてください」より「これで合ってますか？」の方が10倍答えやすい。

---

状態管理

読み込み

• .opt_state.yaml の全セクションを読み込む
• 現在の仮定、不足情報、ボトルネック情報を参照

書き込み

• 依頼書を生成した事実を .opt_state.yaml に記録（improve セクション内）
• スキーマは reference/state_schema.md を参照

---

トラブルシューティング

依頼したデータが来ない

対策:
  ├── 優先度を絞る → 「必須」の1-2項目だけに絞って再依頼
  ├── 代替データを提案 → 「GPSログがなければ、過去の配送伝票でもOK」
  ├── 仮定で進める → 「XXと仮定して進めます。結果の精度はYY%低下する見込み」
  │   → 仮定を明示すれば、後から実データで検証・補正できる
  └── 小さく始める → 「まず1週間分だけでも」「1拠点だけでも」

何が必要かわからない

対策:
  ├── /opt-baseline の結果を見る → ボトルネック制約に関連するデータが足りない
  ├── 仮定リストを見る → confidence: low の仮定に対応するデータが必要
  ├── 思考回路②（ボトルネック特定）を再実行
  └── 「このデータがあったら何が変わるか」を Before/After で説明