Critique panel

Purpose

単一視点・単一最適化による「見えていない盲点」を発見する。 批判的検討をあえて構造化することで、採用・棄却いずれの判断も根拠のあるものにする。

Use When

• 自分の提案・設計に自信がありすぎる（または不安がある）場合
• 反論・批判を事前に想定しておきたい場合
• 複数のステークホルダーがいて、立場ごとの懸念を整理したい場合
• issue-framing / risk-scan の後にさらに深掘りしたい場合
• 意思決定会議・承認フロー前の最終確認として使う場合

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 対象: 批判的検討を行う提案・設計・方針・計画
• 提案者の主張: なぜこれが最善だと考えているか
• 期待するパネリスト: 批判してほしい観点・立場（指定がない場合は後述デフォルトを使う）
• 決定期限: いつまでにこの提案に対して判断を下す必要があるか

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: この提案が内包する批判の核心
2. 根拠: その論点をそう判断した理由
3. パネル批評: 各パネリストからの批判（後述フォーマット）
4. 含意: パネル批評が示す設計上・戦略上の重要な示唆
5. 改善案: 批判を踏まえた現実的な改善の選択肢（複数）
6. 代替案: 提案全体を見直す場合の別アプローチ
7. 判断材料: 批評を踏まえて「採用 / 修正 / 棄却」を判断するための情報

パネリスト批評フォーマット

### [パネリスト名] の視点

**批判の核心**: （1〜2文）
**根拠**: （箇条書き）
**最大の懸念**: （1文）
**改善提案**: （具体的な代替案または修正案）

デフォルトパネリスト

指定がない場合は以下の4視点を使う。

1. ユーザー代表: エンドユーザー（LAB会員）の視点から使い勝手・価値を批判
2. 技術負債監査役: 長期的な保守性・スケーラビリティ・技術的リスクを批判
3. コスト最適化論者: 工数・運用コスト・ROI の観点から効率を批判
4. セキュリティ審査官: 認証・データ・プライバシー・脆弱性の観点から安全性を批判

Review Lens

• 目的妥当性: パネリストの批判が、本来の目的に対して有意か
• 範囲の過不足: 重要な視点のパネリストが抜けていないか
• 中長期リスク: 現時点では批判が当たらなくても、将来問題になる観点はないか
• LAB全体との整合性: LAB の運用・事業方針と批判が整合しているか
• 非エンジニア理解可能性: パネリストの批判が非技術者にも説明できる言葉か
• 他LLM移植耐性: パネリスト設定がClaude固有の解釈に依存していないか

Instructions

1. 対象の提案・設計を読み、「提案者が最も守りたいポイント」を把握する
2. 各パネリストの立場・価値観・優先順位を明確にしてから批判を展開する
3. 各パネリストは「この提案を否定する」立場で一貫して批判する（中立にならない）
4. 批判は「気持ちの問題」ではなく「具体的な根拠・数字・事例」に基づかせる
5. 各パネリストの批判に対して「改善提案」を1つ以上示す
6. パネル批評全体を踏まえて、提案の「守れる部分」と「見直すべき部分」を整理する
7. 「採用 / 修正 / 棄却」の判断材料を人間が選べる形で提示する（AI が断定しない）

Guardrails

• パネリストの批判を「どうせ問題ない」と打ち消さない
• AI 自身の判断で「採用 / 棄却」を断定しない。パネルは判断材料であり、判断は人間がする
• 批判のための批判（根拠なし）はしない。すべての批判に根拠を添える
• 改善案を1つに絞らない。複数の選択肢を示す
• コスト影響（修正工数・機会損失）を省略しない
• 提案者に都合よくなるようにパネルを誘導しない

LAB Cross-Check

実行結果に対して以下を確認すること。

観点	状態	備考
自動化フロー	—	自動化の観点からの批判が含まれているか
データ / 認証 / ログ	—	セキュリティ審査官の批判が十分に機能しているか
実装 / 運用フロー	—	技術負債監査役の批判が運用現実を踏まえているか
非エンジニア理解可能性	—	ユーザー代表の批判が実際の会員視点になっているか
会員共有 / 再利用耐性	—	このパネル設定が他ケースにも転用できるか
他LLM移植耐性	—	パネリスト定義が Claude 固有の概念に依存していないか

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

施工AI へ渡す前に以下を確定させること。

• 要件: 批評を踏まえて修正した最終仕様（変更点を明示）
• 成功条件: パネルの批判が対応済みとなる基準
• 失敗条件: 批判が顕在化した場合の判断基準
• 実行範囲: 修正対象のファイル・機能・DB
• 影響範囲: 修正が波及する可能性のあるシステム・機能
• ロールバック方針: 修正後に問題が起きた場合の戻し方
• コスト比較: 「批判を全部対応する」vs「一部受容して進む」のコスト差

Further Reading

• issue-framing skill — 批判対象の論点整理に先に使う
• assumption-audit skill — 提案の前提を洗い出してから批判する
• risk-scan skill — 批判から見えたリスクをさらに深掘りする
• tradeoff-analysis skill — 批判と改善案の間のトレードオフを整理する
• decision-materials skill — 批評を踏まえた最終的な判断材料を整理する