Deep Dive

---
name: deep-dive
description: "再帰的な質問で要件・課題を深堀りし、推測をなくし、品質・信頼性を向上させるスキル。トリガーキーワード: 「深堀り」「検討して」「ultrathink」「よく考えて」「他にはないか」「他の案は？」。使用場面: 新機能設計、問題解決、技術調査、学習用途、機能追加など。"
allowed-tools: AskUserQuestion, Read, Grep, Glob, Task
---

# deep-dive (Deep Dive) スキル

## 目的

**推測を排除し、品質・信頼性を向上させる**

再帰的な質問によって、ユーザーの曖昧な要件や課題を段階的に明確化し、認識のズレを最小限に抑えます。

**核心原則**: 推測に基づいて進めない。不明な点は必ず質問して確認する。

## トリガー

以下のキーワードで自動的にトリガー：
- 「深堀り」「深堀りして」
- 「検討して」
- 「ultrathink」
- 「よく考えて」
- 「他にはないか」「他の案は？」

または `/deep-dive [トピック]` コマンドで明示的に呼び出し。

## 基本ワークフロー

### Step 1: 全体を理解する（調査フェーズ含む）

#### 1-A: ユーザーリクエストの把握

ユーザーのリクエストを読み、全体像を把握：
- 何を求めているのか？
- どのような文脈・背景があるのか？
- どの程度の詳細度で理解できているか？

#### 1-B: コンテキスト調査（技術的な深堀りが必要な場合）

**技術的な要件や実装に関する深堀りの場合**、Exploreサブエージェントに調査を委譲することで、より的確な質問が可能になります。

**調査すべきケース:**
- 新機能の設計・実装
- バグの原因調査
- リファクタリング計画
- 技術選定
- 既存コードベースの理解

**調査不要なケース:**
- 概念的な質問（「〇〇とは？」）
- 一般的な相談
- ドキュメント作成のみ

**調査方法（推奨）:**

Taskツールでsubagent_type=Exploreを使用し、コードベースを調査：

```text
「このプロジェクトの[対象領域]について調査してください：
- 関連するコード・ファイル構造
- 既存の実装パターン
- 依存関係・影響範囲
- 設計パターン・アーキテクチャ」
```

この調査により、推測ではなく**実際のコードに基づいた質問**ができます。

#### 1-C: 調査結果を「現在の理解」に統合

調査結果（ある場合）を踏まえて、Step 2の「現在の理解」に反映します。

### Step 2: 現在の理解状態を表示（毎回必須）

質問をする前に、**毎回必ず**現在の理解をまとめて表示：

```markdown
**現在の理解**:
- 目的: [理解した目的]
- 前提: [理解した前提条件]
- スコープ: [理解した範囲]
- 制約: [理解した制約]
- 不明点: [まだ不明な点]
- 推測箇所: [推測している部分]
```

これにより、ユーザーとの認識合わせができ、誤解を早期に発見できます。

### Step 3: 不明点 + 推測箇所を特定

現在の理解の中で：
- **不明な点** - 情報が欠けている箇所
- **推測している箇所** - 確認していない前提や仮定

推測の兆候：「おそらく」「たぶん」「だと思う」「一般的には」「〜のはず」

### Step 4: AskUserQuestion で質問（1-4問）

状況に応じて1-4問の質問。

**質問数の目安**:
- 広く浅く探る初期段階: 3-4問
- 特定領域に焦点: 2-3問
- 詳細を深堀り: 1-2問

**質問の観点**:
1. **5W1Hベース** - 基本情報を網羅的に収集
2. **ゴール逆算** - 最終目標から必要な要素を特定
3. **制約特定** - 技術的・ビジネス的制約を明確化
4. **ケースバイケース** - 具体例で抽象的な要件を明確化

詳細は `references/question-templates.md` を参照。

### Step 5: 回答を元に理解を更新

ユーザーからの回答を受け取ったら：
1. 回答内容を整理
2. 理解を更新
3. 新たな不明点・推測箇所を特定

### Step 6: Step 2-5 を繰り返す

理解が十分に深まるまで繰り返し。

### Step 7: 終了提案 → ユーザー承認

以下の条件を満たしたら終了を提案：
- **重要な不明点**がなくなった（※）
- 推測箇所が最小限になった
- 具体的な次のアクションが明確になった

**※重要な不明点の定義:**
- 実装アーキテクチャに直接影響する技術要件（例: API仕様、認証方式）
- データフォーマットや制約条件（例: 入力形式、バリデーションルール）
- 非機能要件（例: パフォーマンス、セキュリティ、スケーラビリティ）
- ステークホルダーの承認が必要な意思決定事項

**終了提案の例**:
```markdown
**現在の理解**:
[最終的な理解をまとめる]

深堀りは十分に完了したと思います。
この内容で次のステップに進んで良いでしょうか？

選択肢:
A) はい、次に進む
B) いいえ、まだ不明点がある
```

**ユーザーが「いいえ」と回答した場合:**

Step 3 に戻り、以下の項目を再確認：

1. **新たな不明点を特定**
   - ユーザーに「どの部分が不明確ですか？」と質問
   - 新たに気づいた推測箇所を洗い出す

2. **既存の理解を再検証**
   - 現在の理解で誤解や不足がないか確認
   - 特に以下を重点的にチェック：
     - 目的・ゴールの認識は合っているか？
     - 前提条件に抜けはないか？
     - スコープ・制約の理解は正しいか？

3. **Step 4 で質問を再開**
   - 新たな不明点に対する質問を作成
   - AskUserQuestion で1-4問の質問を実行

このサイクルを、ユーザーが「はい」と答えるまで繰り返す。

## 質問戦略

### 質問の深さ

- **初回（広く浅く）**: 全体像把握のための広範な質問、3-4問、選択肢で回答しやすく
- **中間（焦点を絞る）**: 特定領域に焦点、2-3問、具体例を交えて
- **詳細（深く掘る）**: 1つのトピックを深堀り、1-2問、オープンエンド質問も活用

### 質問の順序（推奨）

1. **全体理解** → 5W1H で基本情報を収集
2. **ゴール明確化** → ゴール逆算で方向性を定める
3. **制約特定** → 実現可能性を確認
4. **具体化** → ケースバイケースで詳細を固める
5. **推測排除** → 不確実な部分を確認

## 出力形式

状況に応じて柔軟に対応：
- **要件定義書** - 新機能設計の場合
- **チェックリスト** - 確認項目を整理
- **マインドマップ** - 階層的な思考の可視化
- **議事録形式** - 質問と回答の記録
- **その他** - ユーザーの希望に応じて

## 注意事項

### やるべきこと ✅

- **毎回「現在の理解」を表示する** - 認識合わせのため必須
- **推測を明示する** - 「これは推測ですが...」と前置きする
- **不明点を隠さない** - わからないことは正直に質問する
- **柔軟に対応する** - ユーザーの回答に応じて質問を調整

### やってはいけないこと ❌

- **推測に基づいて進める** - 必ず確認する
- **質問しすぎる** - 1回に5問以上は避ける
- **同じ質問を繰り返す** - 既に回答された内容を再度聞かない
- **一方的に決める** - ユーザーの意向を無視しない

## 使用例

**ユーザー**: 「新しいAPI機能を追加したい。深堀りして」

**実行フロー**:
1. 現在の理解を表示（目的、スコープ、不明点）
2. 質問: 「どのようなAPIですか？RESTful? GraphQL?」「どのようなデータを扱いますか？」
3. 回答を元に理解を更新
4. 次の質問: 「認証は必要ですか？」「レート制限は？」
5. 繰り返して要件を明確化
6. 最終的な要件をまとめて終了提案

## 終了後のアクション

次のステップを提案：
- `/plan` - 実装計画を立てる
- `/dev` - 実装を開始
- ドキュメント化 - 要件定義書を作成
- 次の質問へ - 別のトピックを深堀り

## 参照

- **質問パターン詳細**: `references/question-templates.md`
- **推測排除テクニック**: `references/question-templates.md` の「推測排除のための質問テンプレート」