sc-log-fix

Log-Fix：ログ分析による反復的なバグ修正

複数のソースからログを分析し、エラーを特定して根本原因を分析し、パターン学習を通じて問題を対話的に修正します。

クイックスタート

# Analyze recent errors from all log sources
/sc:log-fix

# Filter by time and severity
/sc:log-fix --time 1h --level ERROR

# Target specific log source
/sc:log-fix --source backend --component app.services

# Trace a specific request
/sc:log-fix --request-id abc-123-def

# Dry run - analyze without fixing
/sc:log-fix --dry-run

動作フロー

1. 検出 - 利用可能なログソース（ファイル、docker、systemd）を検出します
2. ナレッジの読み込み - 過去の修正で学習したパターンを確認します
3. 収集 - 検出したソースからログを解析して正規化します
4. トリアージ - エラーをクラスタリングし、深刻度で順位付けし、既知のパターンと照合します
5. 分析 - スタックトレースとコード調査による根本原因分析を行います
6. 修正 - ユーザーの承認を得ながら対話的に修正します
7. 学習 - 成功した修正パターンをナレッジベースに保存します
8. レポート - セッションの概要と残っている問題を報告します

フラグ

フラグ	型	デフォルト	説明
--time	string	1h	時間範囲：30m、1h、1d、7d
--source	string	all	ログソース：backend、frontend、docker、all
--level	string	ERROR	最小深刻度：ERROR、WARNING、all
--component	string	-	ロガー／モジュール名でフィルターします
--request-id	string	-	ログ全体から特定のリクエストを追跡します
--dry-run	bool	false	修正を適用せずに分析とレポートを行います
--fix	bool	true	対話的な修正ループを有効にします

フェーズ 0：ログソースの検出

分析の前に、利用可能なすべてのログソースを自動検出します。

検出戦略

ソース	検出方法	一般的な場所
ファイルログ	logs/**/*.log、*.log を Glob で検索します	logs/、var/log/
Docker	docker compose ps を確認します	docker-compose.yml
Systemd	journalctl が利用可能か確認します	システムサービス
PM2	pm2 list を確認します	Node.js アプリ

ログ形式の検出

ログ形式を自動検出します：

• JSON（構造化）- jq で解析します
• テキスト（非構造化）- 正規表現パターンで解析します
• 複合形式（nginx/apache 形式）- 形式固有の正規表現で解析します

# Detect format by reading first line
head -1 logs/app.log | python3 -c "import sys,json; json.loads(sys.stdin.read()); print('json')" 2>/dev/null || echo "text"

フェーズ 1：ナレッジの読み込み

分析を強化するため、過去の修正に関するナレッジを読み込みます。

ナレッジファイルの構造

{
  "version": "1.0",
  "error_patterns": [
    {
      "id": "pattern-001",
      "signature": {
        "message_pattern": "Connection refused.*port \\d+",
        "component": "app.services.database",
        "exception_type": "ConnectionError"
      },
      "fixes": [{
        "description": "Check database is running, verify connection string",
        "file_changed": "src/config.py",
        "validation_command": "pytest tests/test_db.py -v",
        "success_count": 3,
        "confidence": 0.9
      }]
    }
  ],
  "component_knowledge": {},
  "metadata": {
    "total_fixes": 0,
    "updated_at": null
  }
}

場所：.claude/knowledge/log-fix-knowledge.json

ナレッジが読み込まれると：

• トリアージ：過去に確認されたエラーに「既知の問題」バッジを表示します
• 根本原因：過去の成功率に基づいて修正を提案します
• 修正ループ：実績のある修正をワンクリックで適用するオプションを提示します

フェーズ 2：トリアージとクラスタリング

インシデントのクラスタリング

次の条件でグループ化します：

1. 同じエラータイプ（同一または類似のメッセージ）
2. 同じコンポーネント（ロガー／サービス名）
3. 同じリクエスト（request_id による関連付け）
4. 同じ時間枠（5 秒以内のエラー）

深刻度の順位付け

優先度	条件
P0	スタックトレース、サービスのクラッシュ、データベースエラー
P1	ERROR レベル、API の失敗、認証の問題
P2	WARNING レベル、非推奨、パフォーマンス
P3	情報、クリーンアップの提案

トリアージ概要の出力

## Error Triage Summary

**Time Range**: [start] to [end]
**Total Errors**: N | **Unique Types**: M | **Known Patterns**: K

### Top Issues by Frequency

| # | Count | Component | Error Pattern | Priority | Historical |
|---|-------|-----------|---------------|----------|------------|
| 1 | 15 | app.services.api | Connection timeout | P1 | Known: 3 fixes, 90% |
| 2 | 8 | app.models | Validation failed | P1 | New pattern |

フェーズ 3：根本原因分析

各インシデントクラスターについて、次を行います：

1. スタックトレース分析 - ファイルパスを抽出し、失敗した行を特定して、コンポーネントに対応付けます
2. ログの関連付け - サービス間で request_id を追跡します
3. パターン照合 - ナレッジベースを確認してから、コードレベルの分析を行います
4. コード調査 - 関連するソースファイルを読み、バグを特定します

根本原因の出力

## Root Cause: [Error Type]

**Occurrences**: N | **Component**: [logger]

### Error Details
[Full error and stack trace]

### Relevant Code
**File**: `src/services/api.py:145`
[Code context with highlighted line]

### Probable Cause
[Analysis explaining why the error occurs]

### Suggested Fix
[Specific code change with diff preview]

フェーズ 4：対話的な修正ループ

修正ワークフロー

1. 提示 - エラー、根本原因、影響を受けるファイルを表示します
2. 差分を表示 - 提案するコード変更を正確に表示します
3. 許可を求める - ユーザーが承認、スキップ、または変更します
4. 承認された場合に適用 - Edit ツールを使用します
5. 検証 - 関連するテストを実行します
6. 学習 - パターンをナレッジベースに保存するか確認します

ユーザーオプション

アクション	説明
適用	提案された修正を適用します
スキップ	この問題をスキップして、次に進みます
編集	適用する前に提案された修正を変更します
先にテスト	修正する前にテストを作成します（/sc:tdd を実行）
詳細	エラーの詳しいコンテキストを表示します
終了	修正ループを終了します

修正後の検証

修正の種類	検証
Python コード	pytest -k "test_function" -v
JavaScript	npm test -- --testPathPattern=file
設定	再起動して正常性を確認します
データベース	マイグレーションを実行します

フェーズ 5：ナレッジの学習

修正に成功したら、パターンを保存するかどうかを確認します。

1. エラーシグネチャを抽出 - 固有の値を正規表現パターンに変換します
2. 修正の詳細を記録 - 変更内容、変更箇所、検証コマンドを記録します
3. ナレッジファイルを更新 - 既存のパターンに追記または更新します
4. 信頼度を報告 - 初期信頼度は 1.0 で、時間とともに調整されます

学習プロンプト

Fix applied and validated!

Save this pattern for future similar errors?
  [Y] Yes, save pattern and fix
  [n] No, this was a one-off fix
  [e] Yes, but let me edit the description first

フェーズ 6：セッションレポート

## Log-Fix Session Summary

**Logs Analyzed**: [sources] | **Time Range**: [range]
**Errors Found**: N | **Unique Issues**: M

### Issues Addressed

| # | Component | Issue | Status | Action |
|---|-----------|-------|--------|--------|
| 1 | app.services | Connection timeout | FIXED | Added retry config |
| 2 | app.models | Validation error | SKIPPED | User deferred |

### Files Modified
- src/services/api.py
- src/config.py

### Patterns Learned
- 1 new pattern saved to knowledge base

### Next Steps
- Run `/sc:pr-check` to validate all changes
- Consider `/sc:tdd` for issues without test coverage

MCP 統合

PAL MCP（デバッグと分析）

ツール	使用する場面	目的
mcp__pal__debug	複雑なバグ	複数段階の根本原因分析
mcp__pal__thinkdeep	パターンが不明確な場合	繰り返し発生する問題を詳しく調査します
mcp__pal__codereview	修正の検証	提案された修正の品質をレビューします
mcp__pal__apilookup	依存関係のエラー	バージョンの問題に関する最新ドキュメントを取得します

PAL の使用パターン

# Debug complex error pattern
mcp__pal__debug(
    step="Investigating recurring connection timeout in API layer",
    hypothesis="Connection pool exhaustion under load",
    confidence="medium",
    relevant_files=["src/services/api.py", "src/config.py"]
)

# Deep analysis of unclear pattern
mcp__pal__thinkdeep(
    step="Why do these errors only occur during peak hours?",
    hypothesis="Race condition in connection pooling",
    confidence="low"
)

Rube MCP（通知）

ツール	使用する場面	目的
mcp__rube__RUBE_SEARCH_TOOLS	外部ロギング	ロギングサービスのツールを検索します
mcp__rube__RUBE_MULTI_EXECUTE_TOOL	通知	修正の概要を Slack/Jira に投稿します

ツールの連携

• Bash - ログの解析（jq、grep）、テストの実行、docker コマンド
• Glob - ログファイルの検索
• Grep - エラーパターンの検索、リクエスト ID の追跡
• Read - ソースコードの確認、ログファイルの読み取り
• Edit - コード修正の適用
• Write - ナレッジベースの更新、セッションレポートの作成

関連スキル

• /sc:tdd - 修正する前にテストを作成します（TDD アプローチ）
• /sc:pr-check - PR の前にすべての変更を検証します
• /sc:analyze - 根本原因が不明確な場合に、コードを詳しく分析します