# Risk Scan

> 設計・実装・運用の判断に対して、見落としがちなリスクを体系的にスキャンする。実装前・リリース前・大きな方針変更前に使う。

- Skill: `thinkyou0714/risk-scan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/risk-scan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/risk-scan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/risk-scan

---


## Purpose

「考えていなかったリスク」が後から顕在化するコストを減らす。
リスクを網羅的に列挙した上で、対応コストと放置コストを比較し、優先度付きの判断材料を揃える。

## Use When

- 実装・リリース前の最終チェック
- 大きな設計変更・技術選定の前
- 新機能・施策の投入前
- issue-framing または assumption-audit の後
- 「このまま進んで大丈夫か」という漠然とした不安がある場合
- ステークホルダーへの説明前に穴を埋めたい場合

## Inputs

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

- **対象**: リスクをスキャンする対象（設計・実装・方針・施策）
- **現在の状態**: 何がどこまで決まっているか
- **前提条件**: この判断の根拠となっている前提
- **タイムライン**: いつまでに実行・リリースする予定か
- **影響範囲**: 変更が及ぶシステム・ユーザー・業務フロー

## Output Contract

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

1. **論点**: このスキャンで最も重大なリスクの核心
2. **根拠**: そのリスクをそう判断した理由・根拠
3. **リスク一覧**: 分類別リスクの全列挙（後述フォーマット）
4. **含意**: リスクが示す構造的な問題・設計上の脆弱性
5. **改善案**: 各リスクへの対応策（コスト付き）
6. **代替案**: リスクを回避する別アプローチ・段階的移行案
7. **判断材料**: 「進める / 待つ / 設計変更する」を選ぶための情報

### リスク一覧フォーマット

| リスク | 分類 | 発生確率 | 影響度 | 対応方針 |
|---|---|---|---|---|
| （リスクの説明） | 技術/運用/ビジネス/セキュリティ | 高/中/低 | 高/中/低 | 対応/受容/転嫁/回避 |

## Review Lens

- **目的妥当性**: 列挙したリスクが、本来の目的に対して有意か
- **範囲の過不足**: 重要なカテゴリが抜けていないか。些細なリスクで埋まっていないか
- **中長期リスク**: 短期は問題ないが半年・1年後に顕在化するリスクはないか
- **LAB全体との整合性**: LMS / 自動化 / B2B 展開への波及リスクを確認したか
- **非エンジニア理解可能性**: リスクの説明が非技術者にも伝わる言葉か
- **他LLM移植耐性**: リスク評価がClaude固有の判断基準に偏っていないか

## Instructions

1. 対象を読み、影響を受けるシステム・業務・ユーザーの範囲を確定する
2. 以下のカテゴリ別にリスクを列挙する（各カテゴリ最低1件）:
   - **技術的リスク**: パフォーマンス・スケーラビリティ・依存ライブラリ・API変更
   - **セキュリティリスク**: 認証・認可・データ漏洩・RLS 抜け
   - **運用リスク**: デプロイ失敗・障害対応・監視不足・ロールバック困難
   - **ビジネスリスク**: 目標未達・ユーザー離脱・収益影響
   - **データリスク**: 整合性・PII・バックアップ・移行失敗
3. 各リスクに発生確率（高/中/低）と影響度（高/中/低）を付ける
4. 発生確率×影響度が高いリスクを優先順位上位として明示する
5. 各リスクに対応方針（対応/受容/転嫁/回避）と具体的な対応策を提示する
6. 対応コストと放置コストを比較する（工数・金銭・機会損失）
7. 「今すぐ対応すべき」「次フェーズで対応」「受容可能」に分類して整理する

## 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-framing` skill — リスクスキャン前の論点整理に使う
- `assumption-audit` skill — リスクの根拠となる前提を洗い出す
- `failure-point-review` skill（lab-automation-architecture）— 自動化フロー固有のリスクを深掘り
- `auth-boundary-check` skill（lab-data-auth-ops）— 認証・認可リスクの詳細確認
- [docs/CONTEXT.md](../../../docs/CONTEXT.md) — ロールバック条件の定義