エラーの根本原因を特定し解決策を提案

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

使い方

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. 表面的症状の整理

• エラーメッセージの正確な内容
• 発生タイミングとパターン
• 影響範囲の特定

1. 深層原因の特定

• 5 Whys 分析の適用
• 依存関係の追跡
• 環境差異の確認

1. 仮説の検証

• 最小再現コードの作成
• 分離テストの実行
• 原因の絞り込み

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 : より深い根本原因分析が必要な場合