Skill: opt-report（改善提案書の作成）

/opt-report [results_dir] で実行。 実験結果を、意思決定者に渡せる形の提案書にまとめる。

いつ使うか

• 改善策の実験が一通り終わった後
• クライアントや上司に「結果と提案」を報告する時

---

Opus 4.7 ヒント

• 入力は並列 Read: spec.md, reports/baseline_report.md, reports/improve_report.md, results/*.json, .opt_state.yaml を 1 メッセージで一括 Readしてから統合
• 拡張思考は不可能性の翻訳のみ: 「アルゴリズムでは解けない、XX を変える必要がある」を経営に伝わる言葉にする箇所だけ深く考える。それ以外は定型でよい
• 目的別の手法推奨表は外せない: 「全部の目的で1位の手法は存在しない」を明示し、依頼者に選んでもらう。これが Opus 4.7 の比較分析力を活かせる場面
• PowerPoint 化は /pptx スキルに委ねる: 提案書 Markdown を完成させてから /pptx を呼ぶ

詳細は reference/opus47_collaboration.md。

---

実行内容

1. 結果の収集

- 全実験のBefore/After数値を収集
- 最良の手法を特定
- 改善率を計算

2. 提案書の構成

# [テーマ] 最適化 — 改善提案書

## 現状の課題（Before）
- [具体的な問題を数字で。「XX件の違反」「XX%の非効率」]

## 改善策と効果（After）

| 提案 | 追加コスト | 効果 | 導入難易度 |
|------|----------|------|----------|
| A. [コストゼロの運用変更] | なし | [数字] | すぐできる |
| B. [システム変更] | [金額] | [数字] | 中期 |
| C. [投資が必要] | [金額] | [数字] | 要判断 |

## 推奨: 提案Aから着手
- [なぜこれが最優先か]
- [Before/Afterの数字]

## 方針の選択肢（ソフト制約バリエーション）

ソフト制約の優先度を変えた複数の方針を比較します。各スコアは 0-100（100 = 完全遵守）。

| 方針 | 特徴 | 公平性 | 夜勤制限 | ... | 総合 |
|------|------|--------|---------|-----|------|
| A バランス型 | 全指標を均等に | XX | XX | ... | XX |
| B 公平性重視 | 勤務時間の偏りを最小化 | XX | XX | ... | XX |
| C ○○重視 | ... | XX | XX | ... | XX |

→ **どの方針で進めるかをご判断ください。**

## 数学的な限界
- [「この条件下ではXXは不可能」があれば記載]
- [投資判断の根拠として]

## 次のステップ
1. [すぐやること]
2. [追加データがあればできること]
3. [中長期の展望]

3. 提案の優先順位付け

コストゼロ × 効果大 → 最優先（「まずこれやりましょう」）
コスト小 × 効果大  → 次点
コスト大 × 効果大  → 要投資判断
コスト大 × 効果小  → 非推奨

※ 「不可能性の証明」があれば、投資判断の根拠として最も価値がある
  「アルゴリズムではこれ以上無理。設備/人員を変える必要がある」

4. 目的別の手法推奨（報告書に含める）

複数手法を試した場合、目的に応じた推奨を提示する。

報告書には「目的別の推奨手法」を含めること:

| 目的 | 推奨手法 | 理由 |
|------|---------|------|
| 最高品質（スコア最大化） | ソルバー + 目的関数の精密一致 | 証明付き最適解 |
| 公平性（バラつき最小化） | ソルバー + 公平性重視の重み設定 | 重みの調整で対応可能 |
| コストゼロで始めたい | OR-Tools単体 + 重み調整 | 無料ソルバーのみ |
| ソルバーが使えない環境 | SWO+IFS | Python標準ライブラリのみで動く |
| 初期導入・PoC | ハイブリッド（LLM+ソルバー） | バランス最良 |

→ 「全部の目的で1位の手法」は存在しない。
  トレードオフを明示して、依頼者に選んでもらう。

5. Feasibility（実行可能性）の説明

非技術者向けに必ず説明する。

提案書では以下を明示する:

■ Feasibility = 全てのハード制約を満たしているか
  → 1つでも破れば「使えないシフト表/ルート」になる
  → Feasibility=1（全制約充足）が最低条件

■ Feasibleな手法とInfeasibleな手法の境界線
  実験からわかったこと:
    feasible達成に必要 = グローバルな推論能力
      ├── ソルバー（制約伝播+バックトラッキング）
      ├── SWO+IFS（反復フィードバック+バックトラック）
      └── 問題分割+ソルバー
    feasible未達 = 局所的な操作のみ
      ├── 単純な貪欲法
      ├── SA/GA単体（局所探索のみ）
      └── LLMによるスコア関数改善のみ

  → 「貪欲法で作ったシフト表は制約違反のリスクがある」と伝える
  → 「ソルバーを使えば制約は確実に守れる」と伝える

■ 不可能な場合
  「この条件（人数/台数/時間）ではアルゴリズムで解決できません。
   XXを変更する必要があります」
  → 増台、増員、制約の緩和、運用変更 を具体的に提案
  → これが最も価値のある提言になることが多い

6. 出力

バージョンフォルダ内に以下を保存する:

• reports/proposal.md

• Markdown形式の提案書

• 必要に応じてPowerPoint（/pptxスキルと連携）

---

状態管理

読み込み

• バージョンフォルダ内の .opt_state.yaml の全セクション（assess, baseline, improve）を読み込む
• 問題の分類、ベースライン、改善結果の全履歴を参照

書き込み

• 実行完了時にバージョンフォルダ内の .opt_state.yaml の report セクションを書き込む
• 出力ファイルパス、提案リスト、不可能性の発見を記録
• スキーマは reference/state_schema.md を参照

---

トラブルシューティング

改善効果の数字が小さすぎて提案しづらい

対策:
  ├── 絶対値で見せる（「年間XX万円の削減」「月XX時間の省力化」）
  ├── 比較対象を変える（ランダム比ではなく現状比で見せる）
  ├── 間接効果を含める（残業削減、ミス防止、属人化解消）
  └── 「コストゼロで始められる」ことを強調（運用変更だけで改善）

経営陣が技術的な説明を理解してくれない

対策:
  ├── 「制約充足」→「全てのルールを守れるシフト表」と言い換え
  ├── 「目的関数」→「何を一番良くしたいか」と言い換え
  ├── 「不可能性の証明」→「今の条件では数学的に無理。XX を変える必要がある」
  ├── Before/After の数字と具体例（「このシフト表のここが改善」）で説明
  └── 提案を3案に絞り、コスト×効果のマトリクスで見せる

不可能性をどう伝えるか

「不可能」は最も価値ある提言になり得るが、伝え方を間違えると失望される:
  ├── ○「この条件ではどのアルゴリズムでも解けません。ただし車両を1台増やせば解けます」
  ├── ○「数学的に証明できます。代替案として3つの選択肢があります」
  ├── ×「無理です」（対案なし）
  └── ×「もっと良いアルゴリズムがあれば解けるかもしれません」（曖昧）