Menü
追加データの依頼書を生成する。何がなぜ必要かを非技術者向けに説明
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
受け取ったデータから最適化問題の構造を把握し、仮説を立てる。最も重要なスキル。
実行可能性（feasibility）を確認する。問題の複雑度に応じて一発解きor段階的解法を選ぶ
最適化モデルの運用設計。自動化・監視・フォールバックを定義する
ボトルネックに合わせた改善策を設計・実行・検証する
最適化結果を非技術者にも伝わる改善提案書にまとめる
| name | opt-request |
| description | 追加データの依頼書を生成する。何がなぜ必要かを非技術者向けに説明 |
| user_invocable | true |
/opt-request で実行。
最適化の途中で「あのデータも欲しい」となった時に、依頼書を自動生成する。
spec.md の仮定テーブル、assess の confidence: low 項目、improve の残課題を 1 メッセージで Read してから依頼書に集約詳細は reference/opus47_collaboration.md。
必須（これがないと最適化できない）:
- 制約条件の確認 → 「本当にこの制約は必須？」
- 目的関数の確認 → 「何を一番良くしたい？」
- データの欠損補完 → 「この列のNULLは何を意味する？」
強く欲しい（精度が大幅に上がる）:
- 実績データ → 「今のやり方でどれくらいかかってる？」
- ドメイン知識 → 「現場のルールやノウハウ」
- 計測データ → GPS、センサー、ログ等
あると嬉しい（さらなる改善に使える）:
- 過去の例外 → 「こういうイレギュラーがあった」
- 季節変動 → 「繁忙期はいつ？」
- 将来の変化 → 「来年から人が増える？」
「教えてください」ではなく「こう理解していますが合っていますか？」の形式で書く。 現場の人は白紙の質問には答えにくいが、具体的な仮説を見せると「いやそれは違う」と訂正してくれる。
✗ 悪い例（答えにくい）:
「夜勤の必要人数を教えてください」
「制約を教えてください」
「どういうルールがありますか？」
○ 良い例（答えやすい）:
「夜勤は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) 全然違う（実際は＿＿＿）」
以下の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] | [値] | [根拠] | [影響] |
重要: 「データがないからこう仮定した」を常に明示する。 仮定が間違っていれば、最適化結果も間違う。 仮定を具体的な回答候補付きで見せることで、現場の人が訂正しやすくなる。 「教えてください」より「これで合ってますか？」の方が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 で説明