[バグ対応] 3. トラブルシューティング修正策で仮説→合理的な修正策の列挙 (引数:Issue番号)

入力

• $ARGUMENTS

  : 対象のバグIssue番号
  • 例:

    #123

    または

    123

---

🎯 目的

• 既存Issue内の 「考えられる原因（仮説）」 を起点に、実行前の修正策候補一覧 を作成する
• 出典ポリシーは

  CLAUDE.md

  の原則、および

  doc/guide/ai_guidelines.md

  の「情報源・引用（出典）ポリシー（詳細）」に従い、根拠を伴う対応策 を整理する
• 修正はまだ行わず、合理性・現実性・影響範囲・検証手順 を明記した計画としてIssueコメントに追記する

---

GitHub連携の前提

必要な権限

以下の

gh

コマンドが実行可能であること：

• gh issue view

  /

  gh issue edit

• gh issue comment

---

手順

1. Issue内容を取得

gh issue view {ISSUE_NUMBER} --json title,body,labels

以下を抽出：

• 「問題の概要」「再現手順」「期待する動作（理想状態）」「ギャップ」「考えられる原因（仮説）」

2. 各仮説ごとに修正方針を探索

• 優先度：①公式Doc → ②公式GitHub（issue/PR） → ③英語圏Stack Overflow
• 詳細は

  doc/guide/ai_guidelines.md

  を参照

3. 修正策をIssueコメントで提案

gh issue comment {ISSUE_NUMBER} --body "📋 修正策提案

## 修正策（候補一覧）

### 仮説A: {仮説の要約}

#### 修正案1（推奨度: 高）
- **概要**: {提案の要点}
- **期待効果**: {どのギャップをどう埋めるか}
- **影響範囲**: {関係モジュール/サービス/ユーザー影響}
- **リスク**: {副作用、既知の相性問題、ダウンタイム等}
- **前提条件**: {バージョン/設定/権限など}
- **手順**:
  1. {実施手順1}
  2. {実施手順2}
- **検証方法**: {再現テスト/ユニット/E2E/メトリクス等}
- **ロールバック**: {戻し方・確認ポイント}

#### 修正案2（推奨度: 中）
...（同様）

### 仮説B: {仮説の要約}
...（同様）

---

## 参考資料（出典）
- [公式Doc] {タイトル} — {URL}
- [公式GitHub Issue/PR] {番号/タイトル} — {URL}
- [Stack Overflow] {スレッドタイトル} — {URL}

---

## 次のアクション
\`/bug-fix {ISSUE_NUMBER}\` で修正案を実行
"

4. 解決状況を更新

Issue本文の「解決状況」を

🟠 対応中

に更新する

gh issue edit {ISSUE_NUMBER} --body "{解決状況を🟠対応中に更新した本文}"

---

出力（GitHub）

• Issueコメント: 修正策候補一覧と参考資料
• Issue本文: 解決状況を「🟠 対応中」に変更

---

検索・評価ポリシー（参照）

詳細は

doc/guide/ai_guidelines.md

の「情報源・引用（出典）ポリシー（詳細）」に従う（=

CLAUDE.md

の原則を具体化）。

---

品質チェックリスト

• 各仮説に対して複数案 を提示している（決め打ち回避）
• 出典が公式中心 で整理され、URLとタイトルが明記されている
• 手順・検証・ロールバック が揃っており、実運用を想定している
• 影響範囲/リスク を明示し、採用判断材料になる情報がある
• バージョン整合 と互換性の確認ができている
• 二次情報の採用理由（裏付け・妥当性）が記述されている
• 解決状況が「🟠 対応中」に更新されている

---

自己評価

• 成功自信度: (1-10)
• 一言理由: {短く理由を記載。例: 「公式PRでfix方針が確立、影響範囲も軽微」}