AIをプロダクトマネージャーとして使う：施策提案から評価までの対話パターン

1
開発者:   コードを書く
2
テスター: テストを書く・実行する
3
PM:       何を作るか決める ← ここが最もリソースが足りない
4
運用者:   本番を監視する

1
@.wbs/CURRENT.md          ← 53施策のステータス・依存関係
2
@CLAUDE.md                ← プロジェクトルール・制約
3
@memory/measure_workflow_details.md  ← 施策ワークフローの詳細
4
運用ログ・過去の判定結果   ← 実績データ

1
人間: @.wbs/CURRENT.md 現在の自動化プロジェクトの運用状況を分析してください。
2
      特に、直近1ヶ月のパフォーマンスと未解決の課題を整理してください。

1
人間: 月単位でパフォーマンスが低下している月があります。
2
      日単位でも改善が見込める施策案はありますか？

1
人間: 制約として以下を考慮してください。
2
      - 初期リソースは限定的
3
      - 実装は2週間以内
4
      - 既存パイプラインへの影響は最小限
5
      - 新しい外部API依存の追加は避ける

1
人間: 高い月次パフォーマンス改善が期待できるまたはリスク軽減として効果的な施策案はありますか？
2
      現在のWBSの施策一覧を参考に星3以上の効果が期待できるもののみ提案してください。

1
人間: 以下の基準で各案を比較してください。
2
      1. 期待効果（月次パフォーマンスへの影響、定量的に）
3
      2. 実装難易度（日数と必要な変更範囲）
4
      3. リスク（既存機能への影響、パラメータ感度）
5
      4. 既存施策との競合

1
人間: 案2を採用。WBSに追加してください。
2
      施策IDはOPT-35で。

1
人間: @.wbs/CURRENT.md 現在の本番システムにおいて
2
      リスク軽減として効果的な施策案を提案してください。
3
      制約: 実装2週間以内、既存パイプラインへの影響最小
4

5
AI:   現在のWBSを分析しました。リスク軽減観点で
6
      星3以上の効果が期待できる施策は以下の3案です。
7

8
      施策案1: CircuitBreaker閾値の動的調整（★★★★）
9
      - 効果: 急激な負荷変動時の障害を30%削減見込み
10
      - 実装: 3日（既存CircuitBreakerモジュールの拡張）
11
      - リスク: 低（閾値変更のみ、ロジック変更なし）
12
      - 競合: なし
13

14
      施策案2: メトリクス連動バッチサイズ調整（★★★★★）
15
      - 効果: 外部メトリクス高騰時のリスクを自動制御
16 collapsed lines
16
      - 実装: 1週間（外部メトリクスデータ取得 + バッチサイズ計算ロジック追加）
17
      - リスク: 中（パラメータチューニング必要）
18
      - 競合: OPT-30（バッチサイズ自動書き換え）と部分的に競合
19

20
      施策案3: データソース相関による同時処理制限（★★★）
21
      - 効果: 相関の高いデータソースの同時処理を制限し集中リスクを回避
22
      - 実装: 5日（相関マトリクス計算 + フィルター追加）
23
      - リスク: 低（既存のリクエストフィルターに追加するだけ）
24
      - 競合: なし
25

26
      推奨: 案1は低リスク・短期間で実装可能なため即座に着手可能です。
27
      案2は効果が最も高いですが、OPT-30との競合を解消する設計が必要です。
28

29
人間: 案2を採用。OPT-30との競合については、メトリクス連動の調整結果を
30
      OPT-30のバッチサイズ計算に入力として渡す設計にしてください。
31
      WBSにOPT-35として追加してください。

1
人間: 制限期間のデフォルト値はどうすべきか。
2
      現在は固定で30日にしているが、根拠がない。
3

4
AI:   制限期間のデフォルト値について、以下の観点から分析します。
5

6
      1. 過去データからの分析:
7
         - 直近6ヶ月の施策Go/No-Go判定データを見ると、
8
           30回の処理サイクル到達までの平均日数は22.4日
9
         - 標準偏差は8.7日
10
         - 95%の施策が38日以内に30サイクルに到達
11

12
      2. 提案:
13
         デフォルト値 = ceil(平均 + 1σ) = 32日
14

15
         根拠:
10 collapsed lines
16
         - 平均22.4日 + 標準偏差8.7日 = 31.1日 → 32日
17
         - これで約84%の施策がデフォルト期間内に判定可能
18
         - 30日（現行）と大差ないが、統計的根拠がある
19

20
      3. 代替案:
21
         - 保守的: ceil(平均 + 2σ) = 40日（95%カバー）
22
         - 積極的: ceil(平均) = 23日（50%カバー、早期判断）
23

24
人間: 32日を採用。ただし設定ファイルで変更可能にして、
25
      ハードコードはしないでください。

1
人間: 月単位・日単位でも改善が見込める施策案はありますか？
2
      現在、月間でパフォーマンスが低下する月が3割程度ある。
3

4
AI:   月間パフォーマンス低下率30%を改善するための施策を分析します。
5

6
      現在のパフォーマンス構造:
7
      - 好調月の平均改善率: +4.2%
8
      - 低調月の平均低下率: -2.8%
9
      - 低調月の主因: 大きなパフォーマンス低下が月初に発生するケース
10

11
      施策案（星3以上）:
12

13
      1. 月初リスク低減モード（★★★★）
14
         - 月初5営業日はバッチサイズを50%に制限
15
         - 過去データでは低調月の68%が月初のパフォーマンス低下が原因
8 collapsed lines
16
         - 期待効果: 低調月を30% → 20%に削減
17

18
      2. 適応的パフォーマンス回復（★★★★★）
19
         - 月中に一定のパフォーマンス低下が発生したら段階的にバッチサイズ削減
20
         - 3段階: -3%で70%, -5%で50%, -8%で停止
21
         - 期待効果: 低調月の低下幅を平均40%圧縮
22

23
      3. ...

1
# AIが内部的に行っている分析のイメージ
2
def analyze_conflicts(wbs: dict, new_measure: str) -> list[str]:
3
    """新施策と既存施策の競合をチェック"""
4
    conflicts = []
5
    new_scope = wbs[new_measure]["affected_modules"]
6
    for measure_id, measure in wbs.items():
7
        if measure_id == new_measure:
8
            continue
9
        overlap = set(new_scope) & set(measure.get("affected_modules", []))
10
        if overlap:
11
            conflicts.append(
12
                f"{measure_id}: {measure['name']} "
13
                f"(競合モジュール: {', '.join(overlap)})"
14
            )
15
    return conflicts

1
AI: 注意: 提案した施策案2（メトリクス連動バッチサイズ調整）は、
2
    以下の既存施策と競合する可能性があります。
3

4
    - OPT-30（バッチサイズ自動書き換え）: バッチサイズ計算ロジックが重複
5
    - ADD-A2（適応的パフォーマンス回復）: バッチサイズ削減の判断基準が競合
6

7
    解決策:
8
    1. メトリクス連動の結果をOPT-30の入力として統合する
9
    2. パフォーマンス回復モード中はメトリクス連動を無効化する優先順位を設定

1
人間: 案2を採用。OPT-35としてWBSに追加してください。
2

3
AI:   .wbs/CURRENT.md を更新しました。
4

5
      追加内容:
6
      | OPT-35 | メトリクス連動バッチサイズ調整 | 計画中 | OPT-30 | 04-10 |
7

8
      依存関係: OPT-30（バッチサイズ自動書き換え）の完了後に実装開始
9
      Go/No-Go判定: 2026-05-15（Practice期間30日）

1
× AI: 過去6ヶ月のデータでは現在の処理ルールが有効です。
2
       → 過去データに基づく分析は正しいが、環境変化後は通用しない可能性
3

4
○ 人間: 上流APIの仕様変更が予想されるので、フォールバック対応の施策を優先したい。
5
         → 運用環境の「空気」を読んだ判断

1
AI:   効果順: 案2 > 案1 > 案3
2
      リスク順: 案1 > 案3 > 案2
3
      実装速度順: 案1 > 案3 > 案2
4

5
人間: 今月は安定性を優先したいので、リスクが最も低い案1から着手する。
6
      → 人間の「今の状況」に基づく判断

1
## 施策提案ルール
2
- 提案時は必ず★評価（1-5）を付けること
3
- 既存施策との競合を確認すること
4
- 実装期間と期待効果の比（ROI）を明示すること
5
- 制約が明示されていない場合は、以下のデフォルト制約を適用:
6
  - 実装期間: 2週間以内
7
  - 既存パイプラインへの影響: 最小限
8
  - 新しい外部API依存: 原則追加しない

1
× 人間: 何か良い施策はありますか？
2

3
○ 人間: リスク軽減として効果的な施策案を提案してください。
4
        制約: 実装2週間以内、星3以上の効果が期待できるもののみ。

1
× AI:   案2を推奨します。
2
  人間: わかりました、案2で。
3

4
○ AI:   案2を推奨します。
5
  人間: 案2の前提となっている外部メトリクスデータの取得頻度は？
6
        リアルタイムが必要なら実装コストが上がる。

1
× 人間: いい案だね。（セッション終了）
2
  → 次のセッションでは提案内容が消失
3

4
○ 人間: 案2を採用。WBSにOPT-35として追加してください。
5
  → WBSに記録 = 施策の「コミット」