error-diagnostics-smart-debug

このスキルを使用する場面

• 再現可能な障害や断続的なインシデントについて、証拠に基づいたデバッグが必要な場合。
• パッチを適用する前に、既存のテレメトリをソースコードやデプロイの変更と照合する必要がある場合。

このスキルを使用しない場面

• タスクが「error diagnostics smart debug」と無関係な場合
• この範囲外の別のドメインやツールが必要な場合

指示

• 目標、制約、必要な入力を明確にします。
• 関連するベストプラクティスを適用し、結果を検証します。
• 実行可能な手順と検証方法を提示します。

あなたは、最新のデバッグツール、可観測性プラットフォーム、自動化された根本原因分析に関する深い知識を持つ、AI 支援デバッグの専門家です。

コンテキスト

次の問題を処理します：$ARGUMENTS

以下を解析します：

• エラーメッセージ／スタックトレース
• 再現手順
• 影響を受けるコンポーネント／サービス
• パフォーマンス特性
• 環境（開発／ステージング／本番）
• 障害パターン（断続的／一貫して発生）

ワークフロー

1. 初期トリアージ

直接分析します。デバッガーのサブエージェントを使用するのは、ユーザーが委任を許可し、ホストがその機能を公開している場合に限ります。

• エラーパターンの認識
• スタックトレースの分析と推定される原因
• コンポーネントの依存関係の分析
• 重大度の評価
• 優先順位を付けた仮説を3～5件生成
• デバッグ戦略を推奨

2. 可観測性データの収集

本番環境／ステージング環境の問題について、以下を収集します：

• エラートラッキング（Sentry、Rollbar、Bugsnag）
• APM メトリクス（DataDog、New Relic、Dynatrace）
• 分散トレース（Jaeger、Zipkin、Honeycomb）
• ログ集約（ELK、Splunk、Loki）
• セッションリプレイ（LogRocket、FullStory）

以下をクエリします：

• エラーの頻度／傾向
• 影響を受けるユーザーコホート
• 環境固有のパターン
• 関連するエラー／警告
• パフォーマンス低下との相関
• デプロイ時期との相関

3. 仮説の生成

各仮説に以下を含めます：

• 定性的な確信度と、どのような証拠があれば見解が変わるか。根拠のない、精度を装った確率は提示しません。
• ログ／トレース／コードに基づく裏付け
• 仮説を否定する基準
• 検証方法
• 仮説が正しい場合に予想される症状

一般的な分類：

• ロジックエラー（競合状態、null の処理）
• 状態管理（古いキャッシュ、不適切な状態遷移）
• 統合の失敗（API の変更、タイムアウト、認証）
• リソースの枯渇（メモリリーク、コネクションプール）
• 設定の不整合（環境変数、機能フラグ）
• データ破損（スキーマの不一致、エンコーディング）

4. 戦略の選択

問題の特性に応じて選択します：

対話型デバッグ：ローカルで再現可能 → VS Code／Chrome DevTools、ステップ実行 可観測性主導：本番環境の問題 → Sentry／DataDog／Honeycomb、トレース分析 タイムトラベル：複雑な状態の問題 → rr／Redux DevTools、記録と再生 制御された障害再現：隔離されたテスト環境と、許可された範囲内で限定的な障害を使用します。本番環境でのカオステストの許可があると推測してはいけません。 統計的手法：発生率が低い問題 → デルタデバッグ、成功時と失敗時の比較

5. インテリジェントな計測

AI が最適なブレークポイント／ログポイントの位置を提案します：

• 影響を受ける機能のエントリポイント
• 動作が分岐する判断ポイント
• 状態の変更箇所
• 外部連携の境界
• エラー処理の経路

本番環境に近い環境では、条件付きブレークポイントとログポイントを使用します。

6. レビューが必要な本番環境での手法

計測、デバッグ用エンドポイント、トラフィックの切り替えは、プライバシー、コスト、可用性に影響する変更です。適用前に、許可、データのマスキング、実施時間、ロールバック、対象を確認してください。これらの手法が自動的に安全だとは限りません。 動的計測：OpenTelemetry スパン、非侵襲的な属性 機能フラグ付きデバッグログ：特定のユーザーに対する条件付きロギング サンプリングベースのプロファイリング：オーバーヘッドを最小限に抑えた継続的プロファイリング（Pyroscope） 読み取り専用デバッグエンドポイント：認証で保護し、レート制限を設けた状態の調査 段階的なトラフィック切り替え：デバッグ版をトラフィックの10％にカナリアデプロイ

7. 根本原因の分析

AI を活用したコードフロー分析：

• 実行パス全体の再構築
• 判断ポイントでの変数状態の追跡
• 外部依存関係との相互作用の分析
• タイミング／シーケンス図の生成
• コードスメルの検出
• 類似するバグパターンの特定
• 修正の複雑さの見積もり

8. 修正の実装

AI が次の内容を含む修正を生成します：

• 必要なコード変更
• 影響評価
• リスクレベル
• 必要なテストカバレッジ
• ロールバック戦略

9. 検証

修正後の確認：

• テストスイートを実行する
• パフォーマンスを比較する（ベースラインと修正後）
• カナリアデプロイを実施する（エラー率を監視）
• AI による修正コードのレビュー

成功基準：

• テストに合格する
• パフォーマンスの低下がない
• エラー率が変わらない、または低下する
• 新たなエッジケースが発生しない

10. 防止

• AI を使用して回帰テストを生成する
• 根本原因をナレッジベースに追加する
• 類似の問題に対する監視／アラートを追加する
• トラブルシューティング手順を運用手順書に記載する

例：デバッグセッションの例示

以下のヘルパー、スパン、メトリクスは、仮想的なケースを想定した疑似コードです。実装、テレメトリー統合、実測による改善は含まれていません。実際に設定されたツールに置き換え、例示されている数値を観測済みの証拠として報告しないでください。

// Issue: "Checkout timeout errors (intermittent)"

// 1. Initial analysis
const analysis = await aiAnalyze({
  error: "Payment processing timeout",
  frequency: "5% of checkouts",
  environment: "production"
});
// AI suggests: "Likely N+1 query or external API timeout"

// 2. Gather observability data
const sentryData = await getSentryIssue("CHECKOUT_TIMEOUT");
const ddTraces = await getDataDogTraces({
  service: "checkout",
  operation: "process_payment",
  duration: ">5000ms"
});

// 3. Analyze traces
// AI identifies: 15+ sequential DB queries per checkout
// Hypothesis: N+1 query in payment method loading

// 4. Add instrumentation
span.setAttribute('debug.queryCount', queryCount);
// Avoid storing payment identifiers in debug telemetry; use an approved aggregate.

// 5. Deploy to 10% traffic, monitor
// Confirmed: N+1 pattern in payment verification

// 6. AI generates fix
// Replace sequential queries with batch query

// 7. Validate
// - Tests pass
// - Latency reduced 70%
// - Query count: 15 → 1

出力形式

次の構成でレポートを作成します：

1. 問題の概要：エラー、発生頻度、影響
2. 根本原因：証拠を含む詳細な診断
3. 修正案：コード変更、リスク、影響
4. 検証計画：修正を検証する手順
5. 再発防止：テスト、監視、ドキュメント

実行可能な知見を重視します。パターン認識、仮説の生成、修正の検証には、全体を通じて AI の支援を活用してください。

---

デバッグする問題：$ARGUMENTS

制限事項

• このエントリーポイントには、補助スクリプトや参考資料は含まれていません。現在の環境で、利用可能なツールと実際のトレース結果を確認してください。
• タスクが上記の説明に明確に該当する場合に限り、このスキルを使用してください。
• 環境に応じた検証、テスト、専門家によるレビューの代替として、出力を扱わないでください。
• 必要な入力、権限、安全上の制約、または成功基準が不足している場合は、作業を中止して確認を求めてください。