thinkyou0714 Purpose
「考えていなかったリスク」が後から顕在化するコストを減らす。 リスクを網羅的に列挙した上で、対応コストと放置コストを比較し、優先度付きの判断材料を揃える。
Use When
- 実装・リリース前の最終チェック
- 大きな設計変更・技術選定の前
- 新機能・施策の投入前
- issue-framing または assumption-audit の後
- 「このまま進んで大丈夫か」という漠然とした不安がある場合
- ステークホルダーへの説明前に穴を埋めたい場合
Inputs
以下を準備すること。不足している場合は推測せず、不足を明示する。
- 対象: リスクをスキャンする対象（設計・実装・方針・施策）
- 現在の状態: 何がどこまで決まっているか
- 前提条件: この判断の根拠となっている前提
- タイムライン: いつまでに実行・リリースする予定か
- 影響範囲: 変更が及ぶシステム・ユーザー・業務フロー
Output Contract
以下の順で出力すること。順序を変えない。
- 論点: このスキャンで最も重大なリスクの核心
- 根拠: そのリスクをそう判断した理由・根拠
- リスク一覧: 分類別リスクの全列挙（後述フォーマット）
- 含意: リスクが示す構造的な問題・設計上の脆弱性
- 改善案: 各リスクへの対応策（コスト付き）
- 代替案: リスクを回避する別アプローチ・段階的移行案
- 判断材料: 「進める / 待つ / 設計変更する」を選ぶための情報
リスク一覧フォーマット
| リスク | 分類 | 発生確率 | 影響度 | 対応方針 |
|---|---|---|---|---|
| （リスクの説明） | 技術/運用/ビジネス/セキュリティ | 高/中/低 | 高/中/低 | 対応/受容/転嫁/回避 |
Review Lens
- 目的妥当性: 列挙したリスクが、本来の目的に対して有意か
- 範囲の過不足: 重要なカテゴリが抜けていないか。些細なリスクで埋まっていないか
- 中長期リスク: 短期は問題ないが半年・1年後に顕在化するリスクはないか
- LAB全体との整合性: LMS / 自動化 / B2B 展開への波及リスクを確認したか
- 非エンジニア理解可能性: リスクの説明が非技術者にも伝わる言葉か
- 他LLM移植耐性: リスク評価がClaude固有の判断基準に偏っていないか
Instructions
- 対象を読み、影響を受けるシステム・業務・ユーザーの範囲を確定する
- 以下のカテゴリ別にリスクを列挙する（各カテゴリ最低1件）:
- 技術的リスク: パフォーマンス・スケーラビリティ・依存ライブラリ・API変更
- セキュリティリスク: 認証・認可・データ漏洩・RLS 抜け
- 運用リスク: デプロイ失敗・障害対応・監視不足・ロールバック困難
- ビジネスリスク: 目標未達・ユーザー離脱・収益影響
- データリスク: 整合性・PII・バックアップ・移行失敗
- 各リスクに発生確率（高/中/低）と影響度（高/中/低）を付ける
- 発生確率×影響度が高いリスクを優先順位上位として明示する
- 各リスクに対応方針（対応/受容/転嫁/回避）と具体的な対応策を提示する
- 対応コストと放置コストを比較する（工数・金銭・機会損失）
- 「今すぐ対応すべき」「次フェーズで対応」「受容可能」に分類して整理する
Guardrails
- リスクを「ない」と断定しない。確認できていない領域は「未確認」として明示する
- 対応策を1つに絞らない。コストが異なる複数案を提示する
- 「低リスクだから問題ない」と結論づけない。発生した場合の影響は必ず記載する
- コスト比較（対応コスト vs 放置コスト）を省略しない
- リスク対応の最終判断は人間に委ねる
- セキュリティリスクは「受容」の判断を AI 単独でしない
LAB Cross-Check
実行結果に対して以下を確認すること。
| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | n8n / Webhook / 自動処理の障害リスクを含んでいるか |
| データ / 認証 / ログ | — | RLS・Supabase Auth・audit_log のリスクを確認したか |
| 実装 / 運用フロー | — | デプロイ・ロールバック・監視のリスクを含んでいるか |
| 非エンジニア理解可能性 | — | リスク説明が 非エンジニアにも説明できる言葉か |
| 会員共有 / 再利用耐性 | — | このリスクスキャンが他ケースにも転用できる形か |
| 他LLM移植耐性 | — | Claude 固有の判断基準に依存していないか |
状態は OK / 注意 / NG / 対象外 で記入すること。
Handoff Notes
施工AI へ渡す前に以下を確定させること。
- 要件: 対応が必要なリスクの一覧（優先度付き）
- 成功条件: 各リスクが「対応済み」となる基準
- 失敗条件: リスクが顕在化したと判断する基準と発動条件
- 実行範囲: リスク対応のために触ってよいファイル・DB・インフラ
- 影響範囲: リスク対応が波及する可能性のあるシステム・機能
- ロールバック方針: リスク対応が失敗した場合の戻し方
- コスト比較: 各リスクの「対応する」vs「受容する」のコスト差
Further Reading
issue-framingskill — リスクスキャン前の論点整理に使うassumption-auditskill — リスクの根拠となる前提を洗い出すfailure-point-reviewskill（lab-automation-architecture）— 自動化フロー固有のリスクを深掘りauth-boundary-checkskill（lab-data-auth-ops）— 認証・認可リスクの詳細確認- docs/CONTEXT.md — ロールバック条件の定義