# Change Impact Scan

> コード・DB・設定の変更が波及する範囲を洗い出す。意図しない副作用・破壊的変更・依存箇所を実装前に特定する。

- Skill: `thinkyou0714/change-impact-scan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/change-impact-scan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/change-impact-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/change-impact-scan

---


## Purpose

「直したら別の箇所が壊れた」を防ぐ。
変更の実行範囲と影響範囲を分けて整理し、波及リスクのある箇所を実装前に明示する。

## Use When

- 既存コード・DB・API の変更を行う前
- リファクタリングや型変更など、波及が広い変更の前
- 「どこを直せばいいか」がわかった後、「どこに影響するか」を確認したい場合
- implementation-gate でゲートチェック後、影響範囲の詳細が必要な場合

## Inputs

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

- **変更内容**: 何を変更するか（ファイル・関数・型・DB カラム等）
- **変更理由**: なぜその変更が必要か
- **現在の利用箇所**: 変更対象が使われている場所の既知情報
- **技術スタック**: 言語・フレームワーク・ORM・テストツール
- **テスト状況**: 既存テストのカバレッジ・実行方法

## Output Contract

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

1. **論点**: この変更の影響範囲を左右する核心的な判断軸
2. **根拠**: その論点をそう判断した理由
3. **影響範囲マップ**: 変更が波及する箇所の一覧
4. **含意**: 影響範囲の広さが示す設計上の意味
5. **改善案**: 影響範囲を最小化するための変更戦略
6. **代替案**: 影響範囲を避けつつ目的を達成する別アプローチ
7. **判断材料**: 「実装に進む / 段階的に進む / 設計を見直す」を選ぶための情報

### 影響範囲マップ フォーマット

| 影響箇所 | 種別 | 重篤度 | 対処方針 |
|---|---|---|---|
| （ファイル/関数/テーブル名） | 直接変更 / 依存 / 副作用 | 高/中/低 | 合わせて修正 / テスト追加 / 監視 / 無視可 |

種別:

- **直接変更**: 実装の主要対象
- **依存**: 変更対象を import / call している箇所
- **副作用**: 変更によって間接的に影響を受ける箇所（型推論・テスト等）

## Review Lens

- **目的妥当性**: 影響範囲の洗い出し基準が変更リスクに対して適切か
- **範囲の過不足**: 依存が深いところまで追えているか（過剰に広くなっていないか）
- **中長期リスク**: 今後の機能追加で影響が拡大しそうな箇所を見落としていないか
- **LAB全体との整合性**: Supabase スキーマ・NextAuth・Stripe との依存が含まれているか
- **非エンジニア理解可能性**: 重篤度と対処方針が非技術者に説明できるか
- **他LLM移植耐性**: 影響種別の定義が Claude 固有の解釈に依存していないか

## Instructions

1. 変更対象を「ファイル / 関数 / 型 / DB カラム / API レスポンス」に分類する
2. 各変更対象について依存元（呼び出し元・参照元）を列挙する
3. 依存元の依存元（2次波及）まで追う（3次以降は概要のみ）
4. 重篤度を「高（動作不能）/ 中（劣化・警告）/ 低（影響軽微）」で評価する
5. 各影響箇所に対処方針（修正 / テスト追加 / 監視 / 無視可）を付ける
6. 「ここは変更前に必ずテストを書くべき」な箇所を明示する
7. 最終判断（実装に進む / 段階的に進む / 設計を見直す）は人間に委ねる

## Guardrails

- 「おそらく影響なし」で済ませず、不明な場合は「要確認」として残す
- DB のカラム変更・型変更は必ず高重篤度候補として扱う
- テストのない箇所への影響は必ず明示する
- 影響範囲を縮小するために変更内容を歪めない
- 破壊的変更（existing API の削除・rename）は必ず「高」重篤度にする

## LAB Cross-Check

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | n8n / Webhook への影響が含まれているか |
| データ / 認証 / ログ | — | Supabase スキーマ・RLS・ログへの影響が含まれているか |
| 実装 / 運用フロー | — | デプロイ手順・環境変数への影響が含まれているか |
| 非エンジニア理解可能性 | — | 重篤度と対処方針を説明できる言葉か |
| 会員共有 / 再利用耐性 | — | 影響範囲マップの形式が他変更にも転用できるか |
| 他LLM移植耐性 | — | 評価基準が Claude 固有に依存していないか |

状態は OK / 注意 / NG / 対象外 で記入すること。

## Handoff Notes

- **要件**: 変更内容と影響対処まで含めた実装仕様
- **成功条件**: 影響範囲の対処が完了し、既存テストが全通過している状態
- **失敗条件**: 依存箇所で型エラー・テスト失敗・実行時エラーが発生した状態
- **実行範囲**: 変更対象 + 影響対処が必要なファイル一覧
- **影響範囲**: 変更が波及する箇所と重篤度のマップ
- **ロールバック方針**: 影響対処に失敗した場合の段階的な切り戻し手順
- **コスト比較**: 影響対処コスト vs 後から問題発覚した場合のコスト

## Further Reading

- `implementation-gate` skill — 実装着手前のゲートチェック
- `patch-readiness` skill — パッチ適用前の準備確認
- `test-scope-definition` skill — テストスコープの定義
- `rollback-plan` skill — ロールバック方針の詳細設計
- [docs/DECISIONS.md](../../../docs/DECISIONS.md) — 設計決定記録（ADR）