# Research Design Review

> このスキルは、ユーザーが "/research-design-review" を呼び出したとき、または調査を始める前に、意思決定、調査目的、仮説、前提、証拠ギャップ、調査範囲、検証方法、成功基準を一問ずつ詰めたいときに使用する。プロダクト調査、技術調査、セキュリティ調査、設計改善、障害原因調査、移行計画、ベンダー比較、運用改善などで、いきなり結論や改善案を出す前に調査設計をレビューする。

- Skill: `ken3pei/research-design-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ken3pei/research-design-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ken3pei/research-design-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: KEN3pei (https://skillmd.com/u/ken3pei)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/ken3pei/research-design-review

---


# リサーチ設計レビュー

## 目的

調査を始める前に、何を決めるための調査なのか、どの仮説を検証するのか、どの証拠が不足しているのかを明確にする。

このスキルは結論を急がない。最終成果物は、改善案そのものではなく、意思決定に必要な調査設計、調査順序、証拠ギャップ、判断基準である。

## 基本姿勢

- 質問は一度に一つだけ行う。
- 各質問には、推奨回答を添える。
- ユーザーの回答を受けて、次に詰めるべき分岐を選ぶ。
- ファイル、コード、ログ、設定、ドキュメントから答えられる質問は、ユーザーに聞く前に調べる。
- 事実、推測、未確認事項を分けて扱う。
- 非公式なラベルを使う場合は、非公式な説明であることを明示する。
- 公式用語または対象プロジェクト内の既存用語を優先する。
- 調査を始める前に、調査によって下す意思決定を明文化する。

## 最初に確認すること

最初の質問では、調査の最終目的を絞る。

```md
今回の調査で最終的に決めたいことは何ですか？

推奨回答:
「理想状態の設計」ではなく、「現状を壊さずに次に取るべき判断と移行順序」を決めるための調査にする。
```

ユーザーの入力が抽象的な場合は、次のどれに近いかを一問ずつ確認する。

- 方針を決めたい
- リスクを把握したい
- 改善案を比較したい
- 移行順序を決めたい
- 原因を特定したい
- 仕様または設計の妥当性を確認したい
- 調査タスクへ分解したい

## レビュー手順

1. **意思決定を定義する**
   調査後に決めることを一文で書く。意思決定が複数ある場合は、主要な意思決定と副次的な意思決定に分ける。

2. **現在の仮説を明文化する**
   ユーザーの問題意識を、検証可能な仮説として書き換える。仮説は「何が真なら、どの判断が変わるか」が分かる形にする。

3. **前提と制約を分ける**
   システム制約、組織制約、期間、予算、権限、運用負荷、変更禁止領域、可用性要件、セキュリティ要件を分ける。

4. **調査対象を区切る**
   対象リソース、コードパス、ユーザーセグメント、ログ期間、環境、チーム、ドキュメント、外部仕様などを明示する。対象外も明示する。

5. **証拠ギャップを列挙する**
   現時点で分からないこと、推測に頼っていること、確認できていない依存関係、実使用データ、変更履歴、運用実態を列挙する。

6. **証拠の取り方を設計する**
   どの証拠を、どの順序で、どの方法で集めるかを決める。コストが低く判断を大きく動かす証拠を優先する。

7. **判断基準を決める**
   調査結果をどう解釈するかを先に決める。成功基準、撤退基準、保留基準、追加調査が必要になる条件を定義する。

8. **調査計画に落とす**
   調査タスク、順序、成果物、担当できる主体、想定リスク、未解決の質問をまとめる。

## 質問の進め方

一問ずつ、次の形式で聞く。

```md
質問:
[一つだけ聞く]

推奨回答:
[この時点で合理的と思う回答]

理由:
[なぜこの質問が次の分岐を決めるか]
```

ユーザーが推奨回答を採用した場合は、その前提で次の質問へ進む。ユーザーが違う回答をした場合は、回答に合わせて調査設計を更新する。

## 出力形式

十分に詰まったら、次の形式で調査設計を提示する。

```md
# Research Design Review: [対象]

## Decision To Make
[調査後に決めること]

## Current Hypotheses
- [仮説]

## Known Facts
- [確認済みの事実]

## Assumptions
- [未確認だが置いている前提]

## Evidence Gaps
- [不足している証拠]

## Research Scope
- In scope: [対象]
- Out of scope: [対象外]

## Research Questions
1. [調査質問]

## Investigation Order
1. [最初に調べること]

## Decision Criteria
- Proceed if: [進める条件]
- Change direction if: [方針転換条件]
- Stop or escalate if: [停止またはエスカレーション条件]

## Expected Artifacts
- [成果物]

## Open Questions
- [未解決の質問]
```

## 技術・セキュリティ調査での注意

クラウド権限、認証認可、データ保護、課金、可用性、移行計画など高リスクな調査では、改善案よりも先に次を確認する。

- 現在の実行主体、権限、信頼境界
- 実際に使われている API、permission、設定、コードパス
- 変更すると壊れる可能性がある処理
- 本番変更の前に検証できる環境または観測方法
- 監査ログ、変更履歴、IaC、手動運用の差分
- ロールバックまたは段階導入の方法

この段階では、特定の製品機能や権限名を断定しない。最新仕様や対象環境で確認が必要なものは、確認事項として扱う。