Risk Assessment

目的

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

自問自答フレームワーク

1. 前提の検証

ユーザー: VPC Endpointを追加して

• 本当にVPC Endpointは必要か？
• Public Subnetで済む可能性は？
• コスト対効果は見合うか？

VPC Endpointを追加する前に確認させてください。 現在の構成ではPublic ALBでも要件を満たせる可能性があります。 セキュリティ要件とコストのトレードオフを考慮すると、どちらが適切でしょうか？

2. なぜなぜ分析

状況: undefinedエラーが発生している

問題: undefinedエラー ↓ なぜ？ 値が設定されていない ↓ なぜ？ 初期化処理が不完全 ↓ なぜ？ 非同期処理の完了を待っていない ↓ 根本原因 async/awaitの設計不備

表面的なnullチェックではなく、非同期処理のフロー自体を見直す必要があります。 根本原因は初期化の設計にあります。

3. 深さの検証

提案: 「GitHub Actions連携機能を追加」

• 「連携」という表現は手段であり目的ではない
• ユーザーが本当に得たい価値は何か？
• もっと本質的なアプローチは？

「連携機能」ではなく、ユーザーが達成したいゴールから逆算しましょう。

• CIでの自動実行 → ワークフロー定義のテンプレート提供
• 結果の可視化 → PR Commentへの自動投稿

具体的な価値を軸に設計を進めます。

4. リスクの洗い出し

状況: インフラをTerraformで構築完了

潜在リスクを体系的に洗い出す：

• 再現性: 手動操作が混在していないか
• 状態管理: tfstateの保護は十分か
• 権限: 最小権限原則を満たしているか
• コスト: 想定外のリソース増加リスク

構築完了後のリスク評価：

1. tfstateがローカル管理 → S3 + DynamoDBに移行推奨
2. IAMロールが広すぎる → 最小権限に絞り込み必要
3. タグ付けが不完全 → コスト追跡が困難になる可能性

5. 設計判断の評価

状況: debug, debugFlag, isDebugの3つが混在

• 一貫性がない設計は認知負荷を増やす
• どれか1つに統一すべき
• 既存のコードベースの慣習は？

フラグの命名が統一されていません。 既存コードではisXxxパターンが主流のため、isDebugに統一することを推奨します。

リスク対応戦略

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

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

リスク: 本番DBへの直接アクセス権限が開発者全員にある

• 影響度: 高（データ消失・漏洩の可能性）
• 発生確率: 中（ヒューマンエラー）
• 対応戦略の検討:
• 回避: 直接アクセス禁止 → 運用に支障
• 軽減: 権限を最小化、監査ログ追加 → 現実的
• 転嫁: 該当なし
• 受容: リスクが高すぎる → 不適切

対応: 軽減

• Read権限のみの専用ロールを作成
• 本番変更はCI/CD経由に限定
• 監査ログを有効化し異常検知を設定

リスク: 外部APIの仕様変更でシステムが停止する可能性

• 影響度: 高（サービス停止）
• 発生確率: 低（年1-2回程度）
• 対応戦略の検討:
• 回避: API依存をやめる → 現実的でない
• 軽減: フォールバック実装、バージョン固定 → 有効
• 転嫁: SLA契約で補償を確保 → 補助的に有効
• 受容: 影響が大きすぎる → 単独では不適切

対応: 軽減 + 転嫁

• APIレスポンスのキャッシュ層を追加
• 障害時のフォールバック処理を実装
• SLA契約を確認し、補償条件を明確化

ADRへの記録

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

記録すべき意思決定

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

記録しないもの

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

文体ルール

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

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

意思決定: Public ALBを採用し、VPC Endpointを使わない

ADR-XXXX: Public ALBの採用

ステータス

採用

コンテキスト

VPC Endpoint + NLB構成はTeam Planでのみ利用可能である。

決定

Public ALBを採用する。

理由

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

リスクと対応

• リスク: エンドポイントが公開される
• 対応（軽減）: WAF + IP制限を適用する

適用タイミング

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

アンチパターン

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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: HikaruEgashira
• Source: HikaruEgashira/agent-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.