---
name: risk-assessment
description: |
  設計・計画段階で自律的にリスクアセスメントを行うメタスキルです。
  行動する前に自問自答し、浅い解決策を避け、根本的な問題を特定します。
  Trigger: 設計, 計画, 実装前, アーキテクチャ決定, リスク, 懸念
user-invocable: false
---

## 目的

実装や行動に移る前に、自分自身に問いを投げかけ、深い思考を行う。

## 自問自答フレームワーク

### 1. 前提の検証

<example>
<input>
ユーザー: VPC Endpointを追加して
</input>
<thinking>
- 本当にVPC Endpointは必要か？
- Public Subnetで済む可能性は？
- コスト対効果は見合うか？
</thinking>
<output>
VPC Endpointを追加する前に確認させてください。
現在の構成ではPublic ALBでも要件を満たせる可能性があります。
セキュリティ要件とコストのトレードオフを考慮すると、どちらが適切でしょうか？
</output>
</example>

### 2. なぜなぜ分析

<example>
<input>
状況: undefinedエラーが発生している
</input>
<thinking>
問題: undefinedエラー
↓ なぜ？
値が設定されていない
↓ なぜ？
初期化処理が不完全
↓ なぜ？
非同期処理の完了を待っていない
↓ 根本原因
async/awaitの設計不備
</thinking>
<output>
表面的なnullチェックではなく、非同期処理のフロー自体を見直す必要があります。
根本原因は初期化の設計にあります。
</output>
</example>

### 3. 深さの検証

<example>
<input>
提案: 「GitHub Actions連携機能を追加」
</input>
<thinking>
- 「連携」という表現は手段であり目的ではない
- ユーザーが本当に得たい価値は何か？
- もっと本質的なアプローチは？
</thinking>
<output>
「連携機能」ではなく、ユーザーが達成したいゴールから逆算しましょう。
- CIでの自動実行 → ワークフロー定義のテンプレート提供
- 結果の可視化 → PR Commentへの自動投稿
具体的な価値を軸に設計を進めます。
</output>
</example>

### 4. リスクの洗い出し

<example>
<input>
状況: インフラをTerraformで構築完了
</input>
<thinking>
潜在リスクを体系的に洗い出す：
- 再現性: 手動操作が混在していないか
- 状態管理: tfstateの保護は十分か
- 権限: 最小権限原則を満たしているか
- コスト: 想定外のリソース増加リスク
</thinking>
<output>
構築完了後のリスク評価：
1. tfstateがローカル管理 → S3 + DynamoDBに移行推奨
2. IAMロールが広すぎる → 最小権限に絞り込み必要
3. タグ付けが不完全 → コスト追跡が困難になる可能性
</output>
</example>

### 5. 設計判断の評価

<example>
<input>
状況: debug, debugFlag, isDebugの3つが混在
</input>
<thinking>
- 一貫性がない設計は認知負荷を増やす
- どれか1つに統一すべき
- 既存のコードベースの慣習は？
</thinking>
<output>
フラグの命名が統一されていません。
既存コードでは`isXxx`パターンが主流のため、`isDebug`に統一することを推奨します。
</output>
</example>

## リスク対応戦略

リスクを特定したら、以下の4戦略から選択する：

| 戦略 | 意味 | 適用場面 |
|------|------|----------|
| **回避** | リスクを発生させる活動をやめる | 影響が致命的で代替手段がある |
| **軽減** | 発生確率や影響度を下げる | コストと効果のバランスが取れる |
| **転嫁** | 第三者に移転する | 専門性が必要、保険で対応可能 |
| **受容** | 認識した上で受け入れる | 影響が軽微、対策コストが見合わない |

<example>
<input>
リスク: 本番DBへの直接アクセス権限が開発者全員にある
</input>
<thinking>
- 影響度: 高（データ消失・漏洩の可能性）
- 発生確率: 中（ヒューマンエラー）
- 対応戦略の検討:
  - 回避: 直接アクセス禁止 → 運用に支障
  - 軽減: 権限を最小化、監査ログ追加 → 現実的
  - 転嫁: 該当なし
  - 受容: リスクが高すぎる → 不適切
</thinking>
<output>
対応: 軽減
- Read権限のみの専用ロールを作成
- 本番変更はCI/CD経由に限定
- 監査ログを有効化し異常検知を設定
</output>
</example>

<example>
<input>
リスク: 外部APIの仕様変更でシステムが停止する可能性
</input>
<thinking>
- 影響度: 高（サービス停止）
- 発生確率: 低（年1-2回程度）
- 対応戦略の検討:
  - 回避: API依存をやめる → 現実的でない
  - 軽減: フォールバック実装、バージョン固定 → 有効
  - 転嫁: SLA契約で補償を確保 → 補助的に有効
  - 受容: 影響が大きすぎる → 単独では不適切
</thinking>
<output>
対応: 軽減 + 転嫁
- APIレスポンスのキャッシュ層を追加
- 障害時のフォールバック処理を実装
- SLA契約を確認し、補償条件を明確化
</output>
</example>

## ADRへの記録

プロジェクト固有の重要な意思決定は `./docs/adr` にADRとして記録する。

### 記録すべき意思決定

- 技術選定（フレームワーク、ライブラリ、インフラ）
- アーキテクチャ変更
- リスク対応で「回避」「転嫁」を選択した場合
- トレードオフを伴う設計判断

### 記録しないもの

- 一時的な対応、ワークアラウンド
- 自明な選択
- 実装詳細（設計書ではない）

### 文体ルール

ADRは時間経過で陳腐化しないストック情報とする。現在形で記述する。

| NG | OK |
|----|-----|
| 〜した（過去形） | 〜する（現在形） |
| 現在〜している | 〜である |
| 今後〜する予定 | 〜する方針である |
| 最近〜が発生した | 〜という問題がある |

<example>
<input>
意思決定: Public ALBを採用し、VPC Endpointを使わない
</input>
<output>
# ADR-XXXX: Public ALBの採用

## ステータス
採用

## コンテキスト
VPC Endpoint + NLB構成はTeam Planでのみ利用可能である。

## 決定
Public ALBを採用する。

## 理由
- コスト: VPC Endpoint不要により月額コストを削減できる
- 複雑性: VPC設定が不要となる
- 要件: 内部通信の秘匿性は必須要件ではない

## リスクと対応
- リスク: エンドポイントが公開される
- 対応（軽減）: WAF + IP制限を適用する
</output>
</example>

## 適用タイミング

| タイミング | 適用する問い |
|------------|--------------|
| Plan Mode突入時 | 前提の検証、代替案の検討 |
| 実装開始前 | 深さの検証、設計判断 |
| PR作成前 | リスクの洗い出し → 対応戦略の選択 |
| エラー発生時 | なぜなぜ分析 |
| 重要な意思決定時 | ADRとして `./docs/adr` に記録 |

## アンチパターン

| 振る舞い | 問題 | 代わりに |
|----------|------|----------|
| 言われたことをそのまま実行 | 前提が間違っている可能性 | 「本当に必要か」を問う |
| 症状だけ治す | 再発する | 根本原因まで掘り下げる |
| 一つの方法だけ提案 | 最適解でない可能性 | 代替案を検討する |
| 「連携」「統合」で終わる | 手段が目的化 | 具体的な価値を明示 |