## Error Fix

エラーメッセージから根本原因を特定し、解決時間を予測して実証済みの解決策を提案します。類似エラーのパターンを学習し、即座に適切な対処法を提示します。

### 使い方

```bash
/fix-error [オプション]
```

### オプション

- なし : 標準的なエラー分析
- `--deep` : 深層分析モード (依存関係・環境要因を含む)
- `--preventive` : 予防策重視の分析
- `--quick` : 即座に適用可能な修正のみ提示

### 基本例

```bash
# 標準的なエラー分析
npm run build 2>&1
/fix-error
「ビルドエラーを分析して修正方法を提示して」

# 深層分析モード
python app.py 2>&1
/fix-error --deep
「エラーの根本原因を環境要因も含めて分析して」

# 即座の修正重視
cargo test 2>&1
/fix-error --quick
「すぐに適用できる修正方法を提示して」

# 予防策重視
./app 2>&1 | tail -50
/fix-error --preventive
「エラーの修正と今後の予防策を提示して」
```

### Claude との連携

```bash
# エラーログの分析
cat error.log
/fix-error
「エラーの根本原因を特定し、修正方法を提案して」

# テスト失敗の解決
npm test 2>&1
/fix-error --quick
「失敗したテストを分析し、即座に適用できる修正案を提示して」

# スタックトレースの解析
python script.py 2>&1
/fix-error --deep
「このスタックトレースから問題箇所を特定して環境要因も含めて分析して」

# 複数のエラーをまとめて解決
grep -E "ERROR|WARN" app.log | tail -20
/fix-error
「これらのエラーと警告を優先度順に分類し、それぞれの解決方法を提案して」
```

### エラー解決時間の予測

```text
🚀 即座修正 (5 分以内)
├─ タイポ、import 忘れ
├─ 環境変数未設定
├─ 未定義変数の参照
└─ 予測時間: 2-5 分

⚡ クイック修正 (30 分以内)
├─ 依存関係の不整合
├─ 設定ファイルエラー
├─ 型の不一致
└─ 予測時間: 10-30 分

🔧 調査必要 (2 時間以内)
├─ 複雑なロジックエラー
├─ 非同期処理の競合
├─ API 統合の問題
└─ 予測時間: 30 分-2 時間

🔬 深層分析 (半日以上)
├─ アーキテクチャ起因
├─ 複数システム連携
├─ パフォーマンス劣化
└─ 予測時間: 4 時間-数日
```

### 類似エラーパターン DB

```text
頻出エラーと即座の解決策
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 "Cannot read property 'X' of undefined/null" (頻出度: 極高)
├─ 主要原因: オブジェクトの null チェック不足
├─ 解決時間: 5-10 分
└─ 対処法: Optional chaining (?.) または null チェック追加

📊 "ECONNREFUSED" / "ENOTFOUND" (頻出度: 高)
├─ 主要原因: サービス未起動または URL 設定ミス
├─ 解決時間: 5-15 分
└─ 対処法: サービス起動確認、環境変数チェック

📊 "Module not found" / "Cannot resolve" (頻出度: 高)
├─ 主要原因: パッケージ未インストール、パス指定ミス
├─ 解決時間: 2-5 分
└─ 対処法: npm install 実行、相対パス確認

📊 "Unexpected token" / "SyntaxError" (頻出度: 中)
├─ 主要原因: 括弧・引用符の不一致、予約語使用
├─ 解決時間: 2-10 分
└─ 対処法: シンタックスハイライト確認、Linter 実行

📊 "CORS policy" / "Access-Control-Allow-Origin" (頻出度: 中)
├─ 主要原因: サーバー側の CORS 設定不足
├─ 解決時間: 15-30 分
└─ 対処法: サーバー CORS 設定、プロキシ設定

📊 "Maximum call stack size exceeded" (頻出度: 低)
├─ 主要原因: 無限ループ・再帰、循環参照
├─ 解決時間: 30 分- 2 時間
└─ 対処法: 再帰の終了条件確認、循環参照の解消
```

### エラー分析の優先度マトリクス

| 優先度            | アイコン    | 影響範囲 | 解決難易度 | 対応期限       | 説明                               |
| ----------------- | ----------- | -------- | ---------- | -------------- | ---------------------------------- |
| **Critical**      | 🔴 緊急対応 | 広       | 低         | 15 分以内着手  | システム全体停止、データ損失リスク |
| **High Priority** | 🟠 早期対応 | 広       | 高         | 1 時間以内着手 | 主要機能停止、多数ユーザー影響     |
| **Medium**        | 🟡 計画対応 | 狭       | 高         | 当日中対応     | 一部機能制限、回避策あり           |
| **Low**           | 🟢 経過観察 | 狭       | 低         | 次回改修時     | 軽微な不具合、UX への影響小        |

### 分析プロセス

#### Phase 1: エラー情報収集

```bash
🔴 必須実行:
- エラーメッセージの完全な取得
- スタックトレースの確認
- 発生条件の特定 (再現可能性)

🟡 早期実行:
- 環境情報の収集 (OS、バージョン、依存関係)
- 直前の変更履歴 (git log、最近のコミット)
- 関連ログの確認

🟢 追加実行:
- システムリソース状況
- ネットワーク状態
- 外部サービス状態
```

#### Phase 2: 根本原因分析

1. **表面的症状の整理**
   - エラーメッセージの正確な内容
   - 発生タイミングとパターン
   - 影響範囲の特定

2. **深層原因の特定**
   - 5 Whys 分析の適用
   - 依存関係の追跡
   - 環境差異の確認

3. **仮説の検証**
   - 最小再現コードの作成
   - 分離テストの実行
   - 原因の絞り込み

#### Phase 3: 解決策の実装

```bash
🔴 即座の対処 (ホットフィックス):
- 症状を抑える最小限の修正
- 一時的な回避策の適用
- 緊急デプロイの準備

🟡 根本的解決:
- 原因に対する本質的な修正
- テストケースの追加
- ドキュメントの更新

🟢 予防策の実装:
- エラーハンドリングの強化
- 監視・アラートの設定
- CI/CD パイプラインの改善
```

### 出力例

```text
🚨 エラー分析レポート
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📍 エラー概要
├─ 種別: [コンパイル/実行時/論理/環境]
├─ 緊急度: 🔴 高 / 🟡 中 / 🟢 低
├─ 影響範囲: [機能名/コンポーネント]
└─ 再現性: [100% / 断続的 / 特定条件]

🔍 根本原因
├─ 直接原因: [具体的な原因]
├─ 背景要因: [環境/設定/依存関係]
└─ トリガー: [発生条件]

💡 解決策
🔴 即座の対処:
1. [具体的な修正コマンド/コード]
2. [一時的な回避策]

🟡 根本的解決:
1. [本質的な修正方法]
2. [必要なリファクタリング]

🟢 予防策:
1. [エラーハンドリング改善]
2. [テスト追加]
3. [監視設定]

📝 検証手順
1. [修正適用後の確認方法]
2. [テスト実行コマンド]
3. [動作確認項目]
```

### エラータイプ別の分析手法

#### コンパイル/ビルドエラー

```bash
# TypeScript の型エラー
必須確認 (高):
- tsconfig.json の設定
- 型定義ファイル (.d.ts) の存在
- import 文の正確性

# Rust のライフタイムエラー
必須確認 (高):
- 所有権の移動
- 参照の有効期間
- ミュータビリティの競合
```

#### 実行時エラー

```bash
# Null/Undefined 参照
必須確認 (高):
- オプショナルチェイニング不足
- 初期化タイミング
- 非同期処理の完了待機

# メモリ関連エラー
必須確認 (高):
- ヒープダンプの取得
- GC ログの分析
- 循環参照の検出
```

#### 依存関係エラー

```bash
# バージョン競合
必須確認 (高):
- lock ファイルの整合性
- peer dependencies の要件
- 推移的依存関係

# モジュール解決エラー
必須確認 (高):
- NODE_PATH 設定
- パスエイリアス設定
- シンボリックリンク
```

### 注意事項

- **絶対禁止**: エラーメッセージの一部のみでの判断、検証なしでの Stack Overflow 解決策の適用
- **例外条件**: 一時的な回避策は以下の 3 つの条件のみ許可
  1. 本番環境の緊急対応 (24 時間以内に根本解決必須)
  2. 外部サービス障害 (復旧待ちの間の代替手段)
  3. 既知のフレームワークバグ (修正版リリース待ち)
- **推奨事項**: 根本原因の特定を最優先し、表面的な修正を避ける

### ベストプラクティス

1. **完全な情報収集**: エラーメッセージの最初から最後まで確認
2. **再現性の確認**: 最小再現コードの作成を最優先
3. **段階的アプローチ**: 小さな修正から始めて検証
4. **ドキュメント化**: 解決過程を記録して知識共有

#### よくある落とし穴

- **症状への対処**: 根本原因を見逃す表面的な修正
- **過度な一般化**: 特定ケースの解決策を広範に適用
- **検証の省略**: 修正後の副作用を確認しない
- **知識の属人化**: 解決方法を文書化しない

### 関連コマンド

- `/design-patterns` : コード構造の問題を分析してパターン提案
- `/tech-debt` : 技術的負債の観点からエラーの根本原因を分析
- `/analyzer` : より深い根本原因分析が必要な場合