debugging-log-analyser

デバッグログ解析スキル

生のエラーログ、スタックトレース、クラッシュレポートを解析し、推定される根本原因、影響を受けたコードパス、具体的な次の手順を含む構造化された診断を作成します。曖昧な説明でごまかしません。

このスキルの位置づけ — 診断ステップ

インシデント対応の流れの2番目です：/slo-error-budget（枠組み） → debugging-log-analyser → /incident-postmortem → /oncall-runbook。進行中のインシデントの生の症状を受け取り、根本原因の診断と修正を /incident-postmortem に引き継ぎます。これにより、ポストモーテムは診断をやり直すのではなく、診断に基づいて作成できます。共通用語（根本原因と寄与要因、緩和策と解決策）は、docs/craft/incident-response.md で一度だけ定義されています。

手順

証拠が裏付ける前に修正に飛びつくと、デバッグは失敗します。フェーズ2がこのスキルです。診断の質は確信度に左右され、誤った確信は最悪のタイミングで対応者を誤った方向へ導きます。

1. 証拠を分類して読み取ります。 エラーを分類し、スタックトレースをたどって実際に失敗したフレーム（フレームワーク由来のノイズではなく）を特定し、ログが示していることと示していないことを記録します。引用して返す内容に含まれるシークレットは必ず伏せてください。 完了条件： 失敗したフレームが特定され、証拠の不足（ログからはわからないこと）が推測で補われずに明示されています。
2. 正直な確信度を添えて根本原因を特定します。 最も可能性の高い根本原因とその確信度（確認済み／可能性が高い／不確実）を示し、確実でない場合は別の可能性も示します。確信度のない診断は、白衣を着た推測にすぎません。 完了条件： 根本原因に確信度のラベルが付いており、確認済みでない場合は、それを確認または否定するために次に観察すべき内容が示されています。
3. 修正と緩和策を分けて指定します。 根本原因に対する具体的なコードレベルの修正を示し、さらに、今すぐユーザーへの影響を止める最速の緩和策（ロールバック、フラグの無効化）を明確に分けて示します。出血を止めることと傷を治すことは、緊急度も異なる別の対応だからです。 完了条件： 根本原因に対する具体的な修正と即時の緩和策の両方があり、混同されていません。
4. ポストモーテムに引き継ぎます。 診断、修正、発生時刻を提示し、/incident-postmortem が記憶ではなく証拠に基づいてタイムラインと寄与要因をまとめられるようにします。 完了条件： ポストモーテムが、再診断せずにこの出力から着手できます。

必須入力

以下が提供されていない場合は、質問してください。

• ログ／スタックトレース／エラー出力（直接貼り付けるか、エラーの内容を説明してください）
• 言語とフレームワーク（例：Node.js + Express、Python + Django、Java Spring、Go）
• コンテキスト（発生前に変更した内容。例：最近のデプロイ、設定変更、トラフィック増加、新しい入力データ。「何も変更していない」も有用です）
• 発生頻度（単発／断続的／継続的／特定の変更後の再発）
• 環境（ローカル開発／ステージング／本番）
• すでに試したこと（あれば）

出力形式

---

デバッグレポート：[サービス／アプリ名]

1. エラーの分類

エラーの種類： [実行時例外／ビルドエラー／設定エラー／ネットワークエラー／メモリエラー／不明] 重大度： [致命的／重大／警告／情報] 再発パターン： [単発／断続的／継続的／起動時／高負荷時]

2. スタックトレースの分析

発生元から始めて、各スタックフレームを順に確認します。

• 発生元フレーム： [発生したファイル、行、関数]
• 伝播経路： [コールスタック内をどのように伝播したか]
• クラッシュ地点： [最終的に例外をスロー／パニック／終了した場所]

重要なフレームごとに、以下のどれに該当するかを記録します。

• ユーザーコード（ここで修正可能）
• フレームワーク／ライブラリのコード（通常は誤用が原因）
• システム／ランタイムのコード（通常は設定または環境の問題）

3. 根本原因の評価

考えられる根本原因： [平易な英語で1～2文にまとめた記述] 確信度： [高／中／低 — その理由] 除外すべき別の原因： [確信度が高でない場合]

4. 影響を受けるコードパス

エントリーポイント： [トリガーとなった呼び出しが始まった場所] 関係する主な関数： [トレースに名前が記載されている具体的な関数／メソッド] 原因となったデータ： [ログから推測できる場合 — 例：null 値、不正な JSON]

5. 修正案

具体的なコードレベルの提案を示してください。

• 変更する内容（最小限の修正）
• その修正で根本原因が解消される理由
• 修正に伴うトレードオフやリスク
• 必要に応じて短いコードスニペット

6. 次のデバッグ手順

根本原因がはっきりしない場合は、具体的なデバッグ手順を3～5項目、順番に示してください。

1. [確認する具体的な内容 — ファイル、ログ行、設定値]
2. [具体的な再現手順または切り分けテスト]
3. [具体的なツールコマンド — 例：strace、pprof、--verbose、X へのログ追加]

7. 再発防止

この種のエラーの再発を防ぐための具体策を1～2項目示してください。

• [箇所]で入力検証を強化する
• [条件]を監視／アラートの対象にする
• [シナリオ]をカバーするテストを追加する

---

品質チェック

• 根本原因が具体的である（「null ポインターの問題かもしれない」では不十分）
• コードレベルの具体的な修正案が少なくとも1つ示されている
• 次の手順が曖昧な助言ではなく、実行可能なコマンドになっている
• 提案する修正が、汎用的なものではなく、入力に含まれる実際の言語／フレームワークを参照している
• 確信度に、その理由が明記されている（理由を示さず「高」や「低」とするだけでは不十分）
• 再発防止策が事前対策になっている（単に「エラー処理を追加する」だけでは不十分）

アンチパターン

• 具体的な行やフレームを示さず、「どこかで何かが null になっている」といった曖昧な根本原因
• 実際のスタックトレースを無視した、どの言語にも当てはまる汎用的な修正
• エラーメッセージを言い換えるだけで、その意味を説明しない
• 具体的な防止策を示さず、再発防止として「エラー処理を追加する」とだけ述べる
• 理由を示さずに確信度を「高」または「低」とする

使用例

• 「なぜクラッシュするのですか？」＋［ログを貼り付ける］
• 「このスタックトレースを分析してもらえますか？」
• 「このエラーが発生しています。どういう意味ですか？」
• 「このログをデバッグしてください」
• 「この例外の原因は何ですか？」

トリガーフレーズの例

• 「なぜクラッシュするのですか？」
• 「このスタックトレースを読んで、問題点を教えてください。」
• 「このエラーログを診断してください。」
• 「これらの例外の原因は何ですか？」