---
argument-hint: <タスク名> [調査項目名]
allowed-tools: ["Read", "Write", "Edit", "Bash", "WebSearch", "Task"]
---

# overview.mdの調査項目を実施し、個別ファイルとして保存します

このコマンドは `specs/[taskname]/overview.md` の調査セクションから調査項目を読み取り、調査を実施して `specs/research/[調査項目名].md` として保存します。

## コマンドの役割

**`/sdd:conduct-research`（このコマンド）の役割**:
- **技術的な調査・検証**を実施
- AIが自律的に調査・実験・ベンチマークなどを行って判断できる項目
- 例：
  - ライブラリやフレームワークの選定（性能比較、機能比較）
  - 実装方法の検証（PoC作成、パフォーマンス測定）
  - アーキテクチャの実現可能性調査
  - セキュリティ手法の選定と検証

**`/sdd:clarify-spec` との違い**:
- **clarify-spec**: ビジネス要件やユーザーの意思決定が必要な項目をユーザーに質問
- **conduct-research**: 技術的な調査が必要な項目をAIが調査・検証
- clarify-specは「ユーザーに聞く」、conduct-researchは「AIが調べる」

**使い分けの例**:
- ✅ research: 「JWT vs セッション認証のパフォーマンス比較」（技術的検証）
- ✅ clarify: 「ログイン時にメールアドレスとユーザー名のどちらを使うか」（ビジネス要件）
- ✅ research: 「PostgreSQL vs MySQL のベンチマーク」（技術的検証）
- ✅ clarify: 「管理者画面の公開範囲（社内のみ or 顧客も使用）」（ビジネス要件）

【引数】
$ARGUMENTS

## 引数の形式
- `[taskname]` - タスク名のみ指定した場合、全ての未完了調査項目を順に実施
- `[taskname] [調査項目名]` - 特定の調査項目のみ実施
  - 例: `user-authentication JWT認証のパフォーマンス検証` → 指定された調査項目のみ実施

## 実行手順

### 1. タスクと調査項目の特定

1. **引数が指定されている場合**
   - `[taskname]`のみ: specs/[taskname]/overview.mdの調査セクションから未完了の調査項目を抽出
   - `[taskname] [調査項目名]`: 指定された調査項目のみを対象

2. **引数が指定されていない場合**
   - `specs/`ディレクトリ内のサブディレクトリを一覧表示
   - 複数のタスクがある場合、AskUserQuestionツールでユーザーに選択させる
   - 単一のタスクのみの場合は自動選択

3. **指定されたタスクディレクトリが存在しない場合**
   - エラーメッセージを表示: 「specs/[taskname]/ ディレクトリが見つかりません」
   - specs/配下の利用可能なタスクを一覧表示

### 2. overview.mdの確認

1. **ファイルの存在確認**
   - `specs/[taskname]/overview.md` の存在を確認
   - 存在しない場合: エラーメッセージを表示し、`/sdd:init-task` コマンドの実行を提案

2. **調査項目の抽出**
   - overview.mdの「調査項目」セクション（表形式）から調査項目を抽出
   - 各調査項目の以下の情報を取得:
     - 状態（未着手/完了）
     - 調査項目名
     - 理由

3. **未完了調査項目のリスト表示**
   - 状態が「未着手」の項目を表示
   - 調査項目が全て完了している場合: 完了メッセージを表示して終了

### 3. ステアリングドキュメントの読み込み

プロジェクト全体のコンテキストを把握するため、以下のステアリングドキュメントを読み込みます：

**`specs/_steering/product.md`**:
- プロダクトの目的とビジョン
- ターゲットユーザー
- 主要機能とビジネス目標

**`specs/_steering/tech.md`**:
- 技術スタックとアーキテクチャ
- 開発標準（型安全性、コード品質、テスト戦略）
- 重要な技術的決定事項

**`specs/_steering/structure.md`**:
- プロジェクト構造と命名規則
- コード組織原則
- モジュール境界

**ステアリングドキュメントが存在しない場合**:
- 警告メッセージを表示: 「⚠️ ステアリングドキュメントが見つかりません。プロジェクト固有のコンテキストなしで進めます。」
- `/sdd:steering` コマンドでステアリングドキュメントを作成することを推奨
- 処理は続行（ステアリングドキュメントは必須ではない）

### 4. 調査項目の選択

**調査項目名が指定されている場合**:
- 指定された名前の調査項目を特定
- その調査項目の詳細を表示
- 手順5へ進む

**調査項目名が指定されていない場合**:
- 未完了の調査項目を表示
- AskUserQuestionツールを使用してユーザーに選択させる
  - 各調査項目を選択肢として提示
  - 「全て順番に実施」オプションも含める

### 5. 調査の実施

選択された調査項目について、以下の手順で調査を実施:

#### 5-1. 調査内容の確認
1. **調査項目の詳細を確認**
   - overview.mdから調査項目名と理由を取得
   - 何を調査すべきかを明確に理解

2. **調査プランの作成（内部処理）**
   - TodoWriteツールを使用して調査ステップを計画
   - 例:
     - コードベースの既存実装を調査
     - ドキュメント・ベストプラクティスを調査（WebSearchツール使用）
     - PoC実装（必要な場合）
     - ベンチマーク実施（必要な場合）
     - 結果の比較と分析
   - **調査プランはspecファイルには書かない**（内部処理のみ）

#### 5-2. 調査の実行

調査方法に応じて適切なアプローチを選択:

**A. コードベース調査**
- 既存の実装パターンを確認
- 使用されているライブラリやフレームワークを確認
- 類似機能の実装方法を分析

**B. ドキュメント調査**
- WebSearchツールを使用して最新のベストプラクティスを調査
- 公式ドキュメントを参照
- 技術記事やブログを調査

**C. PoC（Proof of Concept）実装**
- 小規模な実装例を作成
- 動作確認とパフォーマンス測定
- 実装の難易度や工数を評価

**D. ベンチマーク**
- 複数の選択肢を比較
- パフォーマンス測定
- リソース使用量の確認

#### 5-3. 調査結果のまとめと保存

調査完了後、以下の情報をまとめて `specs/[taskname]/research/[調査項目名].md` として保存:

```markdown
# [調査項目名]

## 結論
- 選択: [選択した技術/手法]
- 理由: [選択の理由を1-3行で簡潔に]

## 詳細（必要な場合のみ）
- パフォーマンス測定結果
- セキュリティ考慮事項
- 実装の難易度評価
- 注意点やリスク

## 関連タスク
- specs/[taskname]/
```

**ファイル名の決定**:
- 調査項目名をそのままファイル名にする
- 例: 「JWT認証のパフォーマンス検証」→ `JWT認証のパフォーマンス検証.md`

### 6. overview.mdの調査セクション更新

#### 6-1. 表の更新
- overview.mdの調査項目表で、該当行の「状態」列を「完了」に更新
- 「概要」列に調査結果の簡潔なサマリーと結果ファイルへのリンクを追加:
  ```markdown
  | 完了 | [調査項目名] | [理由] | [選択した技術/手法](research/[調査項目名].md) |
  ```

#### 6-2. 全調査項目完了時の処理
- 全ての調査項目の状態が「完了」になっている場合
- overview.mdの「次のステップ」を更新:
  ```markdown
  **次のステップ**: `/sdd:define-requirements [taskname]` で要件定義を開始してください
  ```

### 7. 完了報告

```
✅ 調査項目を完了しました
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 対象タスク: [taskname]
📝 完了した調査項目: [調査項目名]
🔍 結論: [選択した技術/手法]

📄 保存先: specs/[taskname]/research/[調査項目名].md
📊 調査の進捗: 完了 {完了数} / {総数}

💡 次のアクション:
   - 残りの調査項目: `/sdd:conduct-research [taskname]`
   - 全調査完了: `/sdd:define-requirements [taskname]`
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**複数の調査項目を順に実施する場合**:
- 1つの調査項目が完了したら、次の未完了項目を自動的に表示
- ユーザーに「続けて次の調査項目を実施しますか？」と確認
- 承認されたら手順4に戻って次の調査項目を実施

## 重要な注意事項

- **調査は丁寧に**: 調査は実装の品質を左右する重要なステップです。時間をかけて丁寧に調査してください
- **エビデンスベース**: 推測ではなく、調査結果（ベンチマーク、ドキュメント、PoC）に基づいて判断すること
- **調査結果は簡潔に**: 結論と理由を明確に。詳細は必要な場合のみ記載
- **個別ファイルで管理**: 各調査項目は `specs/research/[調査項目名].md` として個別に保存
- **調査プランはspecに書かない**: 調査プランは内部処理のみ。結果だけをファイルに保存

## 使用例

1. タスク全体の調査を順に実施:
   `/sdd:conduct-research user-authentication`

2. 特定の調査項目のみ実施:
   `/sdd:conduct-research user-authentication JWT認証のパフォーマンス検証`

3. 引数なしで対話的に選択:
   `/sdd:conduct-research`

## 内部品質チェック

**重要**: 以下のチェックはコマンド内部で実施し、**生成されるspecファイルには結果を記載しません**。

### ステアリングドキュメントレビュー（内部処理）

調査結果ファイル生成後、内部的にステアリングドキュメントとの整合性を確認：
- tech.mdの技術方針と調査結果の整合性
- product.mdのビジネス目標との整合性

問題がある場合のみユーザーに修正を促す。準拠している場合は何も出力しない。