thinkyou0714 Purpose
単一視点・単一最適化による「見えていない盲点」を発見する。 批判的検討をあえて構造化することで、採用・棄却いずれの判断も根拠のあるものにする。
Use When
- 自分の提案・設計に自信がありすぎる（または不安がある）場合
- 反論・批判を事前に想定しておきたい場合
- 複数のステークホルダーがいて、立場ごとの懸念を整理したい場合
- issue-framing / risk-scan の後にさらに深掘りしたい場合
- 意思決定会議・承認フロー前の最終確認として使う場合
Inputs
以下を準備すること。不足している場合は推測せず、不足を明示する。
- 対象: 批判的検討を行う提案・設計・方針・計画
- 提案者の主張: なぜこれが最善だと考えているか
- 期待するパネリスト: 批判してほしい観点・立場（指定がない場合は後述デフォルトを使う）
- 決定期限: いつまでにこの提案に対して判断を下す必要があるか
Output Contract
以下の順で出力すること。順序を変えない。
- 論点: この提案が内包する批判の核心
- 根拠: その論点をそう判断した理由
- パネル批評: 各パネリストからの批判（後述フォーマット）
- 含意: パネル批評が示す設計上・戦略上の重要な示唆
- 改善案: 批判を踏まえた現実的な改善の選択肢（複数）
- 代替案: 提案全体を見直す場合の別アプローチ
- 判断材料: 批評を踏まえて「採用 / 修正 / 棄却」を判断するための情報
パネリスト批評フォーマット
### [パネリスト名] の視点
**批判の核心**: （1〜2文）
**根拠**: （箇条書き）
**最大の懸念**: （1文）
**改善提案**: （具体的な代替案または修正案）
デフォルトパネリスト
指定がない場合は以下の4視点を使う。
- ユーザー代表: エンドユーザー（LAB会員）の視点から使い勝手・価値を批判
- 技術負債監査役: 長期的な保守性・スケーラビリティ・技術的リスクを批判
- コスト最適化論者: 工数・運用コスト・ROI の観点から効率を批判
- セキュリティ審査官: 認証・データ・プライバシー・脆弱性の観点から安全性を批判
Review Lens
- 目的妥当性: パネリストの批判が、本来の目的に対して有意か
- 範囲の過不足: 重要な視点のパネリストが抜けていないか
- 中長期リスク: 現時点では批判が当たらなくても、将来問題になる観点はないか
- LAB全体との整合性: LAB の運用・事業方針と批判が整合しているか
- 非エンジニア理解可能性: パネリストの批判が非技術者にも説明できる言葉か
- 他LLM移植耐性: パネリスト設定がClaude固有の解釈に依存していないか
Instructions
- 対象の提案・設計を読み、「提案者が最も守りたいポイント」を把握する
- 各パネリストの立場・価値観・優先順位を明確にしてから批判を展開する
- 各パネリストは「この提案を否定する」立場で一貫して批判する（中立にならない）
- 批判は「気持ちの問題」ではなく「具体的な根拠・数字・事例」に基づかせる
- 各パネリストの批判に対して「改善提案」を1つ以上示す
- パネル批評全体を踏まえて、提案の「守れる部分」と「見直すべき部分」を整理する
- 「採用 / 修正 / 棄却」の判断材料を人間が選べる形で提示する（AI が断定しない）
Guardrails
- パネリストの批判を「どうせ問題ない」と打ち消さない
- AI 自身の判断で「採用 / 棄却」を断定しない。パネルは判断材料であり、判断は人間がする
- 批判のための批判（根拠なし）はしない。すべての批判に根拠を添える
- 改善案を1つに絞らない。複数の選択肢を示す
- コスト影響（修正工数・機会損失）を省略しない
- 提案者に都合よくなるようにパネルを誘導しない
LAB Cross-Check
実行結果に対して以下を確認すること。
| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動化の観点からの批判が含まれているか |
| データ / 認証 / ログ | — | セキュリティ審査官の批判が十分に機能しているか |
| 実装 / 運用フロー | — | 技術負債監査役の批判が運用現実を踏まえているか |
| 非エンジニア理解可能性 | — | ユーザー代表の批判が実際の会員視点になっているか |
| 会員共有 / 再利用耐性 | — | このパネル設定が他ケースにも転用できるか |
| 他LLM移植耐性 | — | パネリスト定義が Claude 固有の概念に依存していないか |
状態は OK / 注意 / NG / 対象外 で記入すること。
Handoff Notes
施工AI へ渡す前に以下を確定させること。
- 要件: 批評を踏まえて修正した最終仕様（変更点を明示）
- 成功条件: パネルの批判が対応済みとなる基準
- 失敗条件: 批判が顕在化した場合の判断基準
- 実行範囲: 修正対象のファイル・機能・DB
- 影響範囲: 修正が波及する可能性のあるシステム・機能
- ロールバック方針: 修正後に問題が起きた場合の戻し方
- コスト比較: 「批判を全部対応する」vs「一部受容して進む」のコスト差
Further Reading
issue-framingskill — 批判対象の論点整理に先に使うassumption-auditskill — 提案の前提を洗い出してから批判するrisk-scanskill — 批判から見えたリスクをさらに深掘りするtradeoff-analysisskill — 批判と改善案の間のトレードオフを整理するdecision-materialsskill — 批評を踏まえた最終的な判断材料を整理する