要件定義・仕様書・設計書を作るための汎用リサーチ指示プロンプト
作成者: Manus AI
用途: Claude Code、Opus、Codex、ChatGPT、その他のAIエージェントに対して、要件定義書、技術要件、アーキテクチャ、SDD、テスト計画、テストハーネス設計を作るための材料を専門的にリサーチさせる。
対象: Webアプリ、SaaS、AI自動化、業務自動化、コンテンツ配信自動化、API連携システム、データ基盤、PoC、MVPなど。
1. 基本方針
ご認識の通り、素人が最初から完璧な要件定義書や仕様書を書くことは困難です。むしろ重要なのは、最初から文書を完成させようとすることではなく、要件定義書・技術仕様書・アーキテクチャ設計書・SDD・テスト計画書・ハーネス設計書に入れるべき材料を、先に専門的に集めることです。
特に、たとえば「note、Substack、Kindle、YouTubeの自動化を組み合わせた完全自動化システムを作りたい」という希望がある場合、最初に必要なのは機能一覧ではありません。必要なのは、各プラットフォームの制約、API可否、利用規約、運用リスク、収益化導線、コンテンツ生成フロー、著作権・二次利用・自動投稿の可否、アカウント停止リスク、既存事例、ユーザーの成功パターン、失敗パターンを調査し、それを設計文書の型へ流し込める形に整理することです。
| 調査対象 | 目的 | 設計書への反映先 |
|---|---|---|
| 公式ドキュメント | API、利用規約、制限、料金、禁止事項を確認する | 技術要件、外部連携仕様、リスク台帳 |
| SNS、X | 現場の不満、成功例、失敗例、運用ノウハウを拾う | ユーザー課題、ユースケース、リスク |
| YouTube | 実演、ワークフロー、ツール比較、運用事例を把握する | 業務フロー、画面要件、運用設計 |
| note、Substack、ブログ | 実践者の知見、収益化導線、コンテンツ運用を把握する | ビジネス要件、コンテンツ要件 |
| 論文、技術記事 | 自動化、推薦、生成AI、品質評価の理論を確認する | アーキテクチャ、SDD、評価指標 |
| コミュニティサイト | エラー、制限、現場の詰まりどころを確認する | テスト計画、監視設計、FAQ |
| GitHub | 既存実装、OSS、サンプルコード、ライブラリを確認する | 技術選定、実装計画、ハーネス設計 |
結論: 要件定義の品質は、文書の文章力ではなく、文書に入れる前のリサーチ設計で決まります。したがって、AIには「要件定義書を書いて」と頼む前に、「要件定義書へ入れるための材料を調査し、型に合わせて分類して」と指示するのが有効です。
2. リサーチで作るべき材料
リサーチの目的は、単に情報を集めることではありません。最終成果物の各章にそのまま流し込める形で材料を集めることです。そのため、調査結果は必ず「どの成果物のどの章に使う情報か」まで分類します。
| 最終成果物 | 必要な材料 | 主な調査先 |
|---|---|---|
| 要件定義書 | 課題、利用者、ユースケース、MVP、In Scope、Out of Scope、成功指標 | SNS、YouTube、note、ブログ、競合サービス |
| 技術要件定義書 | API可否、認証方式、データ制約、レート制限、外部連携制限 | 公式ドキュメント、GitHub、技術記事 |
| アーキテクチャ設計書 | コンポーネント、データフロー、ジョブ設計、キュー、ストレージ、認証、監視 | 公式ドキュメント、OSS、技術記事、論文 |
| SDD | モジュール分割、インターフェース、状態遷移、エラー処理、データモデル | 既存実装、技術記事、社内制約 |
| テスト計画書 | 正常系、異常系、境界値、回帰、E2E、権限、外部API障害 | 公式制限、コミュニティ、障害事例 |
| ハーネス設計書 | モック、スタブ、テストデータ、シナリオ、計測ログ、自動評価 | GitHub、テスト設計記事、CI/CD事例 |
| リスク台帳 | アカウント停止、規約違反、API廃止、品質劣化、著作権、個人情報 | 公式規約、SNS、コミュニティ、法務記事 |
| 実装計画書 | フェーズ、依存関係、MVP順序、Exit Criteria、レビュー計画 | 技術制約、チーム体制、既存資産 |
3. コピー用プロンプト
以下の「コピー開始」から「コピー終了」までを、Claude Code、Opus、ChatGPT、またはリサーチ担当AIにそのまま貼り付けて使ってください。プロジェクト名と作りたいものだけ差し替えれば、どのプロジェクトにも使えます。
コピー開始: 要件定義・仕様書作成のための専門リサーチ指示プロンプト
あなたは、要件定義、技術仕様、アーキテクチャ設計、SDD、テスト計画、テストハーネス設計を作るための上級リサーチャー兼システムアーキテクトです。
今回の目的は、いきなり要件定義書や仕様書を完成させることではありません。まず、要件定義書、技術要件定義書、アーキテクチャ設計書、SDD、テスト計画書、テストハーネス設計書、リスク台帳、実装計画書に入れるための材料を、専門的にリサーチして整理することです。
# 0. プロジェクト概要
以下のプロジェクトについて調査してください。
- プロジェクト名: [ここにプロジェクト名を書く]
- 作りたいもの: [ここに作りたいものを自然文で書く]
- 例: note、Substack、Kindle、YouTubeの自動化を組み合わせた完全自動化システムを作りたい
- 想定利用者: [個人/企業/社内担当者/クリエイター/運用者など]
- 最初に作りたい最小版、MVP: [未定なら未定でよい]
- 予算・期間・技術制約: [未定なら未定でよい]
- 絶対に避けたいこと: [例: 規約違反、アカウント停止、著作権侵害、過剰設計、運用不能など]
# 1. リサーチの最重要方針
この調査では、単なる情報収集ではなく、最終的な設計文書に入れるための材料を集めてください。調査結果は必ず、次の成果物のどこに使う情報かを分類してください。
- 要件定義書
- 技術要件定義書
- アーキテクチャ設計書
- SDD、Software Design Document
- テスト計画書
- テストハーネス設計書
- リスク台帳
- 実装計画書
- Codexレビュー用プロンプト
- Opus再分析用プロンプト
特に、素人が見落としやすい制約、規約、外部APIの制限、運用上の失敗パターン、テストしにくい箇所、監視すべき箇所、法務・著作権・個人情報・アカウント停止リスクを重点的に調べてください。
# 2. 調査対象
以下の情報源を、可能な範囲で幅広く調査してください。ただし、非公式情報は鵜呑みにせず、公式情報または複数ソースで裏取りしてください。
## 2.1 公式情報
- 対象プラットフォームの公式ドキュメント
- APIドキュメント
- 利用規約
- 開発者ポリシー
- レート制限、投稿制限、自動化制限
- 料金体系
- 認証方式
- データ保持、削除、エクスポート可否
- Webhook、RSS、API、CSV、メール連携などの可否
## 2.2 SNS、X、Threads、Redditなど
以下の観点で調査してください。
- 実践者が困っていること
- 自動化で失敗した事例
- アカウント停止、制限、BAN、凍結の事例
- 成功している運用フロー
- 収益化や集客の現実的な導線
- 利用者が実際に求めている機能
- 既存ツールへの不満
## 2.3 YouTube
以下の観点で調査してください。
- 実演されているワークフロー
- 自動化ツールの比較
- コンテンツ制作から配信までの流れ
- 投稿頻度、編集、予約投稿、再利用の運用例
- コメント欄に出ている利用者の不満や疑問
- 実装・運用で詰まりやすいポイント
## 2.4 note、Substack、ブログ、技術記事
以下の観点で調査してください。
- 個人や企業の実践例
- コンテンツ販売、メール配信、サブスク、Kindle出版、動画配信の導線
- 手作業で発生している負担
- 既存自動化ツールの限界
- 著作権、引用、二次利用、AI生成コンテンツに関する注意点
- ビジネス上のKPI、売上、読者獲得、継続率などの指標候補
## 2.5 論文、ホワイトペーパー、技術標準
以下の観点で調査してください。
- コンテンツ推薦、生成AI、品質評価、自動要約、自動分類に関する知見
- 自動化システムの評価方法
- 人間参加型レビュー、Human-in-the-loopの設計
- テスト自動化、評価ハーネス、LLM評価、回帰評価の方法
- セキュリティ、プライバシー、監査ログ、説明可能性に関する知見
## 2.6 コミュニティサイト、フォーラム、GitHub
以下の観点で調査してください。
- 既存OSS、SDK、サンプル実装
- Issueで頻出している障害や制約
- API変更、廃止、互換性問題
- テストに使えるモック、スタブ、CLI、SDK
- CI/CD、監視、ログ設計の参考事例
# 3. 調査観点
次の観点で必ず整理してください。
## 3.1 事業・利用者観点
- 誰が使うのか
- どの課題を解決するのか
- なぜ既存ツールでは不十分なのか
- お金、時間、品質、継続性のどれに効くのか
- 利用者が最初に欲しいMVPは何か
- 成功指標として何を測るべきか
## 3.2 機能要件観点
- 必須機能
- 後回しでよい機能
- 絶対に作らない方がよい機能
- 手動承認が必要な機能
- 完全自動化してよい機能
- 完全自動化すると危険な機能
## 3.3 技術要件観点
- API利用可否
- 認証方式
- レート制限
- Webhook可否
- RSS可否
- ファイル入出力
- データ保存形式
- 外部サービス障害時の挙動
- 将来のAPI変更に備える設計
## 3.4 アーキテクチャ観点
- 必要なコンポーネント
- データフロー
- ジョブキュー
- スケジューラ
- コンテンツ生成・変換・配信パイプライン
- 承認ワークフロー
- 監視、ログ、アラート
- 管理画面
- 手動介入ポイント
## 3.5 SDD観点
- モジュール分割
- クラスまたはサービスの責務
- インターフェース
- 状態遷移
- エラー処理
- リトライ設計
- 冪等性
- データモデル
- 設定管理
- 監査ログ
## 3.6 テスト計画観点
- 単体テスト
- 結合テスト
- E2Eテスト
- 回帰テスト
- API障害テスト
- レート制限テスト
- 権限テスト
- セキュリティテスト
- データ破壊防止テスト
- 手動承認フローのテスト
## 3.7 テストハーネス観点
- モック対象
- スタブ対象
- テストデータ
- ダミー投稿先
- サンドボックス環境
- リプレイ可能なAPIレスポンス
- 失敗注入
- LLM出力評価
- コンテンツ品質評価
- 自動回帰評価
## 3.8 リスク観点
- 利用規約違反
- アカウント停止
- 著作権侵害
- 個人情報漏えい
- API廃止
- 料金増加
- 外部サービス依存
- コンテンツ品質劣化
- 誤投稿
- スパム判定
- 自動化しすぎによるブランド毀損
# 4. 情報の信頼度分類
調査結果には、必ず信頼度を付けてください。
| 信頼度 | 定義 |
|---|---|
| A | 公式ドキュメント、公式規約、一次ソースで確認できる。 |
| B | 公式ではないが、複数の信頼できる情報源で一致している。 |
| C | 個人投稿、SNS、単一ブログなどで、参考情報に留まる。 |
| D | 推測、未確認、要追加確認。 |
# 5. 出力形式
調査結果は、以下の構成で出力してください。
## 1. 調査サマリー
このプロジェクトで作るべきもの、主要な実現可能性、重大な制約、最初に作るべきMVPを要約してください。
## 2. 最重要発見事項
| No | 発見事項 | 根拠URL | 信頼度 | 設計への影響 | 反映先成果物 |
|---:|---|---|---|---|---|
## 3. プラットフォーム別調査結果
| プラットフォーム | API可否 | 自動化可否 | 主な制限 | 規約リスク | 設計上の注意 | 信頼度 |
|---|---|---|---|---|---|---|
## 4. 利用者課題・ユースケース候補
| ID | 利用者 | 課題 | 望む結果 | 現在の代替手段 | MVP優先度 | 根拠 |
|---|---|---|---|---|---|---|
## 5. 機能候補一覧
| ID | 機能候補 | 説明 | Must/Should/Later/Reject | 完全自動化可否 | 手動承認要否 | 理由 | 根拠 |
|---|---|---|---|---|---|---|---|
## 6. 技術制約一覧
| ID | 制約 | 対象 | 内容 | 影響 | 対応案 | 信頼度 | 根拠 |
|---|---|---|---|---|---|---|---|
## 7. アーキテクチャ材料
| コンポーネント | 役割 | 入力 | 出力 | 依存サービス | 障害時対応 | 備考 |
|---|---|---|---|---|---|---|
## 8. SDD材料
| モジュール | 責務 | 主要インターフェース | 状態 | エラー処理 | テスト観点 |
|---|---|---|---|---|---|
## 9. テスト計画材料
| テスト種別 | 対象 | 目的 | 必要なテストデータ | 合格条件 | 優先度 |
|---|---|---|---|---|---|
## 10. テストハーネス材料
| ハーネス要素 | 目的 | モック対象 | 入力データ | 期待出力 | 自動化可否 | 備考 |
|---|---|---|---|---|---|---|
## 11. リスク台帳材料
| ID | リスク | 発生原因 | 影響 | 発生可能性 | 影響度 | 対応方針 | 信頼度 | 根拠 |
|---|---|---|---|---|---|---|---|---|
## 12. MVP提案
調査結果を踏まえ、最初に作るべきMVPを提案してください。MVPは、最小限で価値を確認でき、かつ規約違反やアカウント停止リスクを避けられるものにしてください。
| MVP機能 | 理由 | 含めるもの | 含めないもの | 成功指標 | リスク |
|---|---|---|---|---|---|
## 13. 完全自動化してよい部分・してはいけない部分
| 処理 | 完全自動化可否 | 手動承認要否 | 理由 | リスク |
|---|---|---|---|---|
## 14. 要件定義書に入れるべき項目
要件定義書へ反映すべき内容を、章立て形式で整理してください。
## 15. 技術要件定義書に入れるべき項目
API、認証、データ、外部連携、制約、セキュリティ、運用の観点で整理してください。
## 16. アーキテクチャ設計書に入れるべき項目
コンポーネント、データフロー、ジョブ、承認フロー、監視、エラー処理を整理してください。
## 17. SDDに入れるべき項目
モジュール、責務、インターフェース、状態遷移、例外処理、データモデルを整理してください。
## 18. テスト計画書に入れるべき項目
単体、結合、E2E、回帰、外部API障害、セキュリティ、権限、非機能の観点で整理してください。
## 19. テストハーネス設計書に入れるべき項目
モック、スタブ、テストデータ、失敗注入、LLM評価、自動回帰評価、ログ検証を整理してください。
## 20. 未確認事項と追加調査項目
| ID | 未確認事項 | なぜ重要か | 確認先 | 優先度 | 次アクション |
|---|---|---|---|---|---|
# 6. 調査時の禁止事項
- 公式情報を確認せずに、SNSやブログだけで断定しないでください。
- 利用規約違反の可能性がある自動化を、安全であるかのように扱わないでください。
- 実装できるか不明な機能をMustにしないでください。
- 完全自動化が危険な箇所まで自動化前提にしないでください。
- 不確かな情報は、必ず「未確認」「要追加確認」として扱ってください。
- 文書を完璧に見せるために、根拠のない数値や制約を作らないでください。
# 7. 最終的に作るべき次のプロンプト
調査結果の最後に、次の成果物を作成するためのプロンプトも生成してください。
1. 要件定義書作成プロンプト
2. 技術要件定義書作成プロンプト
3. アーキテクチャ設計書作成プロンプト
4. SDD作成プロンプト
5. テスト計画書作成プロンプト
6. テストハーネス設計書作成プロンプト
7. Codexレビュー依頼プロンプト
8. Opus再分析プロンプト
9. 実装計画書作成プロンプト
# 8. 最重要指示
あなたの役割は、見栄えのよい要件定義書をいきなり書くことではありません。専門家が設計書を書くために必要な材料を、根拠付きで集め、要件定義・仕様書・設計書の型に入れやすい形へ分類することです。
調査結果は、素人でも次の判断ができるように書いてください。
- 何が実現可能なのか
- 何が危険なのか
- 何を最初に作るべきなのか
- 何を後回しにすべきなのか
- どこに手動承認を残すべきなのか
- どの情報が公式根拠に基づくのか
- どの情報が未確認なのか
コピー終了: 要件定義・仕様書作成のための専門リサーチ指示プロンプト
4. note・Substack・Kindle・YouTube自動化システム向けの追記例
もし今回の対象が、note、Substack、Kindle、YouTubeの自動化を組み合わせたシステムであれば、上記プロンプトの「作りたいもの」に次のように書くと、調査の精度が上がります。
作りたいもの: note、Substack、Kindle、YouTubeを横断して、コンテンツ企画、原稿作成、編集、配信、再利用、読者・視聴者分析、収益化導線の改善を支援する自動化システムを作りたい。ただし、各プラットフォームの利用規約に違反する自動投稿、スパム的な大量投稿、著作権侵害、アカウント停止リスクの高い処理は避けたい。完全自動化できる部分と、人間の承認を残すべき部分を分けて設計したい。
この場合、調査では以下の論点を特に重視してください。
| 重点論点 | 調査理由 | 設計への影響 |
|---|---|---|
| 自動投稿可否 | 規約違反やアカウント停止を避けるため | 手動承認フロー、投稿機能の設計 |
| API・RSS・メール連携 | 公式に許可された連携方法を確認するため | 外部連携方式、データ取得方式 |
| Kindle出版フロー | 出版手続き、審査、原稿形式の制約を確認するため | Kindle連携要件、手動工程設計 |
| YouTube連携 | 動画投稿、メタデータ、字幕、コメント、分析の可否を確認するため | YouTube API設計、分析機能 |
| note・Substackの制約 | 投稿、メール配信、読者管理、自動化制限を確認するため | コンテンツ配信設計 |
| 著作権・引用・AI生成 | コンテンツ再利用と生成AI利用のリスクを避けるため | レビュー機能、監査ログ、承認設計 |
| 品質評価 | 低品質コンテンツ量産を防ぐため | LLM評価、校正、スコアリング |
| 収益化導線 | 目的に合うKPIを定義するため | 成功指標、分析機能、MVP |
5. 使い方
このプロンプトは、プロジェクト開始直後に使うのが最も効果的です。最初に「作りたいもの」を自然文で書き、その後にこのリサーチプロンプトを実行します。AIが調査結果を返したら、その結果を材料として、要件定義書、技術要件定義書、アーキテクチャ設計書、SDD、テスト計画書、テストハーネス設計書を順番に作成します。
| 手順 | 実施内容 | 成果物 |
|---|---|---|
| 1 | 作りたいものを自然文で書く | プロジェクト概要 |
| 2 | 本リサーチプロンプトを実行する | 調査レポート |
| 3 | 調査結果を要件定義の型へ流し込む | 要件定義書 |
| 4 | API、制約、データ、セキュリティを整理する | 技術要件定義書 |
| 5 | コンポーネントとデータフローを設計する | アーキテクチャ設計書 |
| 6 | モジュール、状態、エラー、データモデルを設計する | SDD |
| 7 | 正常系、異常系、外部障害、権限を設計する | テスト計画書 |
| 8 | モック、スタブ、失敗注入、評価を設計する | テストハーネス設計書 |
| 9 | CodexレビューとOpus再分析を行う | レビュー結果、改訂計画 |
6. リサーチ後に行うべき判定
リサーチが終わったら、すぐに実装へ進むのではなく、次の判定を行います。
| 判定項目 | GO条件 | NO-GO条件 |
|---|---|---|
| 規約・API制約 | 公式に許可された連携方法がある | 主要機能が規約違反または未確認である |
| MVP | 最小機能で価値検証できる | MVPが大きすぎて実装不能である |
| 手動承認 | 危険な処理に承認ポイントがある | 誤投稿や規約違反が完全自動化されている |
| テスト可能性 | モック、スタブ、テストデータを用意できる | 外部サービス依存で再現テストができない |
| リスク管理 | BlockerとMustリスクが明確である | 重大リスクが未整理である |
7. 次に使う短縮版プロンプト
一度この型に慣れた後は、次の短縮版でも運用できます。
以下のプロジェクトについて、要件定義書、技術要件定義書、アーキテクチャ設計書、SDD、テスト計画書、テストハーネス設計書を作るための材料をリサーチしてください。
作りたいもの: [ここに自然文で書く]
調査対象は、公式ドキュメント、利用規約、API仕様、SNS、YouTube、note、ブログ、論文、コミュニティ、GitHubです。調査結果は、要件定義、技術要件、アーキテクチャ、SDD、テスト計画、ハーネス設計、リスク台帳、実装計画に反映できる形で分類してください。
特に、公式に確認できる制約、規約違反リスク、API制限、完全自動化してよい部分、手動承認を残すべき部分、MVP、テストしにくい箇所、モック化すべき外部依存、重大リスクを重点的に調査してください。
出力は、発見事項、根拠URL、信頼度、設計への影響、反映先成果物を含む表形式で整理してください。最後に、要件定義書、技術要件定義書、アーキテクチャ設計書、SDD、テスト計画書、テストハーネス設計書を作るための次プロンプトも生成してください。