元ファイル:

システム要件定義の分析と汎用化方法/世界最高基準の要件定義・仕様書・技術設計を作るための最終版リサーチプロンプト.md

世界最高基準の要件定義・仕様書・技術設計を作るための最終版リサーチプロンプト

作成者: Manus AI
用途: Claude Code、Opus、Codex、または任意のリサーチAIに貼り付け、素人の「こういうものを作りたい」という曖昧な構想から、要件定義書、仕様書、技術要件、アーキテクチャ、SDD、テスト計画、テストハーネス設計を完成させるための材料を体系的に収集する。
統合元: 添付された「世界最高基準の要件定義を作成する汎用プロンプトと実務フロー」、添付された「Claude Code汎用版質問駆動型・要件定義作成プロンプト」、既存の汎用成果物テンプレート、Codex ⇄ Opus 反復レビュー・収束フロー。

1. 結論

お考えの通り、素人が最初から完璧な要件定義書や仕様書を書くのは現実的ではありません。最初に行うべきことは、要件定義書や設計書の型を埋めるための材料を、専門家の観点でリサーチして集めることです。

世界最高基準の要件定義とは、きれいな文章ではなく、実装、検証、運用、改善、監査、変更判断に使える材料が、要件IDと証跡つきで整理されている状態を指します。

そのため、このプロンプトでは、単に「市場調査してください」とは指示しません。代わりに、リサーチ結果を最終成果物の型、つまり要件定義書、仕様書、技術要件、アーキテクチャ、SDD、テスト計画、テストハーネス設計、運用設計、リスク台帳、レビュー台帳へ流し込める形で集めさせます。

作りたい成果物	リサーチで集めるべき材料	失敗しやすい点
要件定義書	課題、利用者、業務フロー、成功指標、制約、対象外範囲。	「便利そうな機能」の羅列になり、何を実現すれば成功かが曖昧になる。
仕様書	画面、API、データ、状態遷移、例外処理、権限、入力制約。	正常系だけを書き、異常系、境界値、失敗時処理が抜ける。
技術要件	性能、可用性、セキュリティ、監査、運用、コスト、拡張性。	技術選定が好みで決まり、制約や運用負荷に合わない。
アーキテクチャ	コンポーネント、責務分離、データフロー、外部連携、認証、キュー、バッチ。	API制限、レート制限、規約、障害時処理を後から知る。
SDD	モジュール設計、インターフェース、データモデル、処理シーケンス、エラー設計。	実装者が読んでも作れない抽象度で止まる。
テスト計画	テスト種別、対象、観点、環境、合格基準、証跡。	受入基準とテストケースが対応していない。
テストハーネス設計	モック、スタブ、フィクスチャ、テストデータ、外部API代替、再現性。	本番APIや外部サービスに依存し、テストが不安定になる。

2. この最終版プロンプトの使い方

この文書の後半にある 「コピー開始」から「コピー終了」まで を、そのままClaude Codeなどに貼り付けてください。その後、あなたのプロジェクトを一文で伝えます。たとえば、次のように伝えれば十分です。

note、Substack、Kindle、YouTube、Xを組み合わせて、コンテンツ制作、配信、分析、再利用までを自動化する完全自動化システムを作りたいです。

AIには、すぐに要件定義書を書かせるのではなく、まずどの材料が不足しているか、どこを調べるべきか、どの情報源を優先すべきかを設計させます。その後、リサーチ結果を成果物の型に分類し、最後に要件定義書や仕様書へ変換します。

3. リサーチ先マップ

リサーチは、情報源の性質ごとに分けて行う必要があります。公式ドキュメントは制約と実装可否を確認するために使い、SNSやコミュニティは現場の失敗例や運用知を拾うために使います。論文や標準文書は、設計の型や品質基準を補強するために使います。

区分	主なリサーチ先	調べる内容	信頼度	主な使い道
公式ドキュメント	API仕様、利用規約、開発者ガイド、料金、制限、認証方式。	何が可能で何が禁止か、API制限、認証、投稿・取得・削除可否。	高	技術要件、外部連携要件、アーキテクチャ、リスク。
プラットフォームポリシー	利用規約、コンテンツポリシー、自動化ポリシー、スパムポリシー。	自動投稿、スクレイピング、再配信、AI生成物の扱い。	高	法務・運用・停止基準。
技術標準	ISO/IEC/IEEE、NIST、OWASP、C4、ADR、OpenAPI、AsyncAPI。	要件、設計、品質、セキュリティ、API設計の型。	高	SDD、NFR、テスト計画、監査設計。
GitHub	OSS、SDK、サンプル、Issue、Discussions。	実装例、メンテ状況、既知バグ、依存リスク。	中〜高	技術選定、PoC、ハーネス設計。
Stack Overflow / Zenn / Qiita / Dev.to	実装メモ、エラー事例、回避策。	現場で詰まる点、SDKの癖、制限。	中	リスク、テスト観点、実装計画。
Reddit / Hacker News / Indie Hackers	ユーザーの不満、運用失敗、事業課題。	市場ニーズ、反発、失敗例、実運用の現実。	中	課題設定、ペルソナ、リスク。
YouTube	実演、チュートリアル、ツール比較、運用事例。	実際の手順、画面、運用ワークフロー。	中	業務フロー、UI要件、手順書。
X	最新の制限変更、障害、開発者の反応、ツール評判。	リアルタイムの問題、突然の仕様変更、運用者の声。	低〜中	リスク検知、仮説生成。
note / Substack / Medium	個人開発、クリエイター運用、収益化事例。	実務ノウハウ、投稿設計、読者導線。	中	業務要件、運用設計、KPI。
論文 / arXiv / Google Scholar	自動化、推薦、LLMエージェント、品質保証、情報検索。	手法、評価指標、失敗パターン、ベンチマーク。	中〜高	AI要件、評価設計、ハーネス設計。

4. 主要リサーチ先URLリスト

以下は、プロジェクトの種類を問わず調査候補に入れるべき代表的なリサーチ先です。実際の調査では、必ず最新の公式ページを開き、利用規約、料金、レート制限、認証、禁止事項、変更履歴を確認してください。

領域	リサーチ先	URL
YouTube API	YouTube Data API Reference	https://developers.google.com/youtube/v3/docs
Google API認証	Google Identity / OAuth	https://developers.google.com/identity/protocols/oauth2
X API	X API Documentation	https://docs.x.com/x-api/introduction
X開発者コミュニティ	X Developer Community	https://devcommunity.x.com
Substack	Substack Support	https://support.substack.com
Substack Developer API候補	Substack Developer API Support Article	https://support.substack.com/hc/en-us/articles/45099095296916-Substack-Developer-API
Kindle / KDP	Kindle Direct Publishing Help	https://kdp.amazon.com/en_US/help
KDP形式	Supported eBook manuscript formats	https://kdp.amazon.com/en_US/help/topic/G200634390
Amazon KDP Community	KDP Community	https://www.kdpcommunity.com/s/?language=en
note	note公式ヘルプ	https://www.help-note.com
note	note公式	https://note.com
API設計	OpenAPI Specification	https://spec.openapis.org/oas/latest.html
イベントAPI	AsyncAPI Initiative	https://www.asyncapi.com/docs
アーキテクチャ	C4 Model	https://c4model.com
意思決定記録	Architecture Decision Records	https://adr.github.io
セキュリティ要件	OWASP ASVS	https://owasp.org/www-project-application-security-verification-standard/
Web脆弱性	OWASP Top 10	https://owasp.org/www-project-top-ten/
セキュア開発	NIST Secure Software Development Framework	https://csrc.nist.gov/Projects/ssdf
ソフトウェア品質	ISO/IEC 25010概要	https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
SRE	Google SRE Book	https://sre.google/books/
APIテスト	Postman Learning Center	https://learning.postman.com/docs/
ブラウザ自動化	Playwright Documentation	https://playwright.dev/docs/intro
E2Eテスト	Cypress Documentation	https://docs.cypress.io
ユニットテスト	pytest Documentation	https://docs.pytest.org
JSテスト	Vitest Documentation	https://vitest.dev
負荷テスト	k6 Documentation	https://grafana.com/docs/k6/latest/
モックAPI	WireMock Documentation	https://wiremock.org/docs/
コンテナ	Docker Documentation	https://docs.docker.com
CI/CD	GitHub Actions Documentation	https://docs.github.com/actions
コード品質	SonarQube Documentation	https://docs.sonarsource.com/sonarqube-server/
LLM評価	OpenAI Evals	https://github.com/openai/evals
LLMアプリ評価	Ragas	https://docs.ragas.io
LLM観測	LangSmith	https://docs.smith.langchain.com

5. リサーチで予測して検証すべき論点

優れたリサーチは、ただ情報を集めるものではありません。最初に「このプロジェクトで失敗しそうな仮説」を立て、それを公式情報と実例で検証します。たとえば、note、Substack、Kindle、YouTube、Xを組み合わせた自動化システムでは、以下の論点が高確率で重要になります。

仮説ID	予測される重要論点	調査すべき理由	成果物への反映先
HYP-001	すべてのプラットフォームに公式投稿APIがあるとは限らない。	APIがない場合、完全自動化ではなく半自動化、手動承認、RPA、エクスポート運用が必要になる。	外部連携要件、アーキテクチャ、リスク台帳。
HYP-002	自動投稿やスクレイピングが規約違反になる可能性がある。	アカウント停止、法務リスク、事業停止につながる。	セキュリティ・法務要件、停止基準。
HYP-003	コンテンツの再利用には著作権、引用、重複投稿、プラットフォームごとの最適化が関わる。	同じ原稿をそのまま多平台に流すと品質・規約・SEO上の問題が起きる。	業務フロー、編集ワークフロー、承認設計。
HYP-004	YouTubeはアップロード、メタデータ、コメントなどAPI範囲が比較的明確だが、認証とクォータが制約になる。	OAuth、API quota、動画処理時間、権限スコープが実装順序を左右する。	技術要件、テスト計画、実装計画。
HYP-005	Kindle/KDPは原稿形式、プレビュー、出版審査、タイトル作成制限が重要になる。	完全自動出版よりも、ファイル生成、検証、手動承認の設計が現実的な可能性がある。	Kindle仕様、運用フロー、ハーネス設計。
HYP-006	AI生成コンテンツには品質評価、ファクトチェック、盗用チェック、ブランドトーン確認が必要になる。	自動化の速度が上がるほど、誤情報や品質劣化も速く拡散する。	AI要件、テストハーネス、受入基準。
HYP-007	各プラットフォームのレート制限、仕様変更、ログイン認証変更が運用障害の主因になる。	自動化は外部依存が強く、運用監視と再試行設計が必須になる。	NFR、運用設計、障害対応。
HYP-008	完全自動化より、最初は「AI生成 + 人間承認 + 自動配信」のハイブリッドが安全である。	品質、法務、アカウント安全性を守りながらPoCできる。	MVP定義、フェーズ別Exit Criteria。
HYP-009	テストでは本番APIを直接叩かず、モック、録画レスポンス、サンドボックス、ドライランが必要になる。	テストコスト、レート制限、誤投稿、アカウント汚染を避けるため。	テスト計画、ハーネス設計。
HYP-010	成果物は要件IDで結び、要件、仕様、テスト、実装タスク、レビュー指摘を追跡可能にする必要がある。	どの要件が実装・テスト済みか不明になることを防ぐ。	要件ID台帳、トレーサビリティ表。

6. コピーして使う最終版リサーチプロンプト

以下の コピー開始 から コピー終了 までを、そのままClaude Code、Opus、Codex、またはリサーチAIに貼り付けてください。

コピー開始: 世界最高基準の要件定義・仕様書・設計書を作るための材料収集リサーチプロンプト

あなたは、世界最高水準のリサーチャー、要件定義コンサルタント、業務設計者、システムアーキテクト、SDD作成者、QA責任者、テストハーネス設計者、セキュリティ責任者、プロダクトマネージャーを兼ねる専門家です。

これから、私が伝える曖昧なプロジェクト構想をもとに、要件定義書、仕様書、技術要件、アーキテクチャ、SDD、テスト計画、テストハーネス設計、運用設計、リスク台帳、Codexレビュー用資料、Opus再分析用資料を完成させるための材料を、専門的にリサーチしてください。

最初から要件定義書を書き切らないでください。まず、どの成果物を作るために、どの材料が必要で、どの情報源を調べるべきかを設計してください。その後、リサーチ、証跡整理、成果物別分類、ギャップ分析、追加質問、ドラフト生成の順に進めてください。

# 0. 私が最初に入力するプロジェクト構想

以下の形式で、私がプロジェクト構想を伝えます。

- プロジェクト名: 【未定なら仮称でよい】
- やりたいこと: 【例: note、Substack、Kindle、YouTube、Xを組み合わせたコンテンツ制作・配信・分析の完全自動化】
- 対象ユーザー: 【自分、チーム、顧客、一般ユーザーなど】
- 目標: 【時間短縮、収益化、品質向上、運用自動化など】
- 既存資料: 【URL、README、メモ、競合、参考サービスなど】
- 制約: 【予算、納期、技術、法務、プラットフォーム規約など】
- 不安な点: 【アカウント停止、品質、API制限、運用負荷、セキュリティなど】

私の入力が曖昧な場合でも、勝手に確定せず、仮説と確認事項に分けて進めてください。

# 1. 最重要方針

このリサーチの目的は、単に情報を集めることではありません。目的は、最終的に以下の成果物へ流し込める材料を集めることです。

1. 要件定義書
2. 要件ID台帳
3. 受入基準表
4. 機能仕様書
5. 非機能要件定義書
6. 技術要件定義書
7. 外部連携仕様書
8. データ要件定義書
9. アーキテクチャ設計書
10. SDD、つまりSoftware Design Document
11. API仕様書
12. セキュリティ・権限・監査設計書
13. 運用・保守設計書
14. 障害対応・バックアップ・復旧設計書
15. テスト計画書
16. テストケース一覧
17. テストハーネス設計書
18. リスク台帳
19. 未決事項・確認事項一覧
20. 実装計画書
21. Codexレビュー依頼プロンプト
22. Opus再分析プロンプト
23. 最終GO / CONDITIONAL GO / NO-GO判定書

リサーチ結果は、必ず「どの成果物のどの章に入る材料か」が分かるように分類してください。

# 2. リサーチ前に行う初回質問

最初の返答では、すぐにリサーチを始めず、以下の質問だけをしてください。ただし、私がすでに回答している項目は重複して聞かず、回答済みとして整理してください。

1. このプロジェクトは一言でいうと何を作るものですか。
2. 誰の、どんな課題を解決したいですか。
3. 最初に作りたい最小版、つまりMVPは何ですか。
4. 完全自動化したい範囲と、人間承認を残してよい範囲はどこですか。
5. 外部プラットフォーム、API、SaaS、データソースは何を使いますか。
6. 投稿、取得、分析、変換、出版、配信、通知、課金など、どの操作を自動化したいですか。
7. 絶対に失敗したくない点は何ですか。例として、アカウント停止、規約違反、個人情報漏洩、誤投稿、品質劣化、著作権侵害、課金事故があります。
8. 予算、納期、技術スタック、人員、運用体制に制約はありますか。
9. 既存資料、競合サービス、参考URL、GitHub、メモがあれば提示してください。
10. リサーチ範囲は日本語中心、英語中心、両方のどれにしますか。

回答後、以下の表で整理してください。

| 項目 | 現時点の理解 | 確定/仮置き/要確認 | 次に調べるべきこと |
|---|---|---|---|
| プロジェクト概要 |  |  |  |
| 解決課題 |  |  |  |
| 利用者 |  |  |  |
| MVP |  |  |  |
| 自動化範囲 |  |  |  |
| 外部連携 |  |  |  |
| 重大リスク |  |  |  |
| 制約 |  |  |  |
| 既存資料 |  |  |  |

# 3. リサーチ計画を先に作成する

初回質問への回答を受け取ったら、すぐ調査に入る前に、必ずリサーチ計画を作成してください。リサーチ計画には以下を含めてください。

| 調査ID | 調査テーマ | 調査目的 | 想定仮説 | 優先度 | 調査先 | 成果物への反映先 |
|---|---|---|---|---|---|---|

優先度は以下で分類してください。

- Blocker: 調べないと実装可否や規約違反リスクを判断できない。
- Must: 要件定義、仕様、設計に必須。
- Should: 品質を上げるために重要。
- Later: 後続フェーズでよい。

# 4. 必ず調べるリサーチカテゴリ

以下のカテゴリを、プロジェクトに合わせて必ず調査してください。該当しない場合も「該当なし」と判断理由を記録してください。

## 4.1 公式ドキュメント・API仕様

調査対象には、公式API、開発者ドキュメント、認証方式、レート制限、料金、SDK、エラー仕様、変更履歴、サポート範囲を含めてください。

調査観点:

| 観点 | 確認内容 |
|---|---|
| API可否 | そもそも公式APIで目的の操作ができるか。 |
| 認証 | API key、OAuth、サービスアカウント、ユーザー承認のどれか。 |
| 投稿・更新・削除 | 作成、編集、削除、予約投稿、下書き保存が可能か。 |
| 取得 | コンテンツ、分析値、コメント、購読者、収益、メタデータが取得できるか。 |
| レート制限 | 日次・分次・エンドポイント別制限があるか。 |
| 料金 | 無料枠、有料枠、従量課金、上限設定があるか。 |
| サンドボックス | テスト環境、ドライラン、検証用アカウントがあるか。 |
| 失敗時処理 | エラーコード、再試行、冪等性、重複投稿防止が可能か。 |
| 規約 | 自動化、スクレイピング、AI生成コンテンツ、再配信が許可されるか。 |

## 4.2 プラットフォーム規約・ポリシー

各プラットフォームの利用規約、開発者規約、コンテンツポリシー、スパムポリシー、自動化ポリシー、AI生成コンテンツの扱いを調査してください。

特に以下を確認してください。

| 論点 | 確認内容 |
|---|---|
| 自動投稿 | APIまたはツールによる自動投稿が許可されているか。 |
| スクレイピング | ブラウザ自動化や非公式APIが禁止されていないか。 |
| AI生成物 | AI生成コンテンツの開示、禁止、制限があるか。 |
| 重複投稿 | 同一コンテンツの大量投稿、クロスポストがスパム扱いにならないか。 |
| アカウント停止 | どの行為が停止・制限対象になるか。 |
| 収益化 | 収益化、アフィリエイト、出版、広告との関係。 |
| 著作権 | 引用、転載、二次利用、画像・音声・動画素材の扱い。 |

## 4.3 ユーザー・市場・業務フロー

SNS、YouTube、note、Substack、Medium、Reddit、Hacker News、Indie Hackers、Zenn、Qiita、Stack Overflow、Product Huntなどから、ユーザーの課題、運用事例、失敗例、競合ツール、代替手段を調べてください。

出力は以下の表にしてください。

| 発見ID | 情報源 | 観察された課題・ニーズ | 根拠URL | 信頼度 | 要件への示唆 | 反映先 |
|---|---|---|---|---|---|---|

## 4.4 競合・代替ツール

既存ツール、SaaS、OSS、Zapier、Make、n8n、IFTTT、Buffer、Hootsuite、Publer、Repurpose.io、Typefully、Ghost、WordPress、Beehiiv、ConvertKit、Notion、Airtable、GitHub Actionsなどを調べてください。

調査観点:

| 観点 | 確認内容 |
|---|---|
| 既存ツールで代替できる範囲 | 作る必要があるか、組み合わせで足りるか。 |
| 不足機能 | 既存ツールではできないことは何か。 |
| 料金 | 自作より安いか、高いか。 |
| API連携 | 外部連携しやすいか。 |
| ロックイン | データの持ち出し、移行が可能か。 |
| 運用負荷 | 自作した場合に増える保守負荷。 |

## 4.5 技術標準・設計標準

要件定義、品質、アーキテクチャ、API設計、セキュリティ、テスト、運用に関する標準・ベストプラクティスを調べてください。

必ず候補に入れる調査先:

| 分野 | 調査先例 |
|---|---|
| 要件定義 | IEEE/ISO系の要求仕様、SRSテンプレート、BABOK系資料、実務テンプレート。 |
| アーキテクチャ | C4 Model、ADR、ISO/IEC/IEEE 42010系の考え方。 |
| SDD | SDDテンプレート、政府・大学・大企業の公開テンプレート。 |
| API | OpenAPI、AsyncAPI、REST/GraphQL設計ガイド。 |
| セキュリティ | OWASP ASVS、OWASP Top 10、NIST SSDF、CIS Controls。 |
| 品質 | ISO/IEC 25010、SLO/SLA、SRE、DORA指標。 |
| テスト | ISTQB観点、テストピラミッド、E2E、契約テスト、負荷テスト。 |
| ハーネス | モック、スタブ、サービス仮想化、テストデータ管理、録画再生、CI。 |

## 4.6 OSS・GitHub調査

GitHubで、関連するSDK、非公式API、サンプル実装、CLI、スクレイピングツール、自動投稿ツール、テストハーネス、モックサーバーを調べてください。ただし、非公式APIやスクレイピングは、規約違反や保守不能リスクがあるため、必ずリスクとして扱ってください。

出力は以下の表にしてください。

| リポジトリ | URL | 用途 | Star/更新状況 | ライセンス | 使える可能性 | 主なリスク | 採用判定 |
|---|---|---|---|---|---|---|---|

## 4.7 論文・研究・技術記事

AIエージェント、自動化、情報検索、コンテンツ生成、評価、RAG、LLMテスト、プロンプト評価、品質保証、ファクトチェック、著作権検出に関する論文・研究・技術記事を調べてください。

特にAIが含まれる場合は、以下を調べてください。

| 観点 | 調査内容 |
|---|---|
| 評価指標 | 正確性、網羅性、一貫性、有害性、幻覚、引用妥当性。 |
| ファクトチェック | 一次ソース照合、引用検証、二重チェック、人間承認。 |
| コンテンツ品質 | トーン、重複、盗用、SEO、読者満足。 |
| LLMテスト | ゴールデンデータ、回帰評価、プロンプト差分、モデル変更検知。 |
| 安全性 | 機密情報流出、プロンプトインジェクション、ツール誤操作。 |

# 5. リサーチ先を必ず明示する

調査対象に応じて、以下のようなリサーチ先を候補に含めてください。実際のプロジェクトに関係ないものは除外してよいですが、除外理由を記録してください。

## 5.1 プラットフォーム・API公式

- YouTube Data API: https://developers.google.com/youtube/v3/docs
- Google OAuth: https://developers.google.com/identity/protocols/oauth2
- X API: https://docs.x.com/x-api/introduction
- X Developer Community: https://devcommunity.x.com
- Substack Support: https://support.substack.com
- Substack Developer API候補記事: https://support.substack.com/hc/en-us/articles/45099095296916-Substack-Developer-API
- Kindle Direct Publishing Help: https://kdp.amazon.com/en_US/help
- KDP manuscript formats: https://kdp.amazon.com/en_US/help/topic/G200634390
- KDP Community: https://www.kdpcommunity.com/s/?language=en
- note公式: https://note.com
- noteヘルプ: https://www.help-note.com

## 5.2 自動化・連携ツール

- Zapier: https://zapier.com
- Make: https://www.make.com
- n8n: https://n8n.io
- IFTTT: https://ifttt.com
- GitHub Actions: https://docs.github.com/actions
- Playwright: https://playwright.dev/docs/intro
- Selenium: https://www.selenium.dev/documentation/
- Puppeteer: https://pptr.dev

## 5.3 コンテンツ・配信・出版関連

- WordPress Developer Resources: https://developer.wordpress.org
- Ghost Docs: https://ghost.org/docs/
- Medium Help: https://help.medium.com
- Beehiiv: https://www.beehiiv.com
- ConvertKit: https://convertkit.com
- Buffer: https://buffer.com
- Hootsuite: https://www.hootsuite.com
- Publer: https://publer.com

## 5.4 設計・品質・セキュリティ標準

- OpenAPI Specification: https://spec.openapis.org/oas/latest.html
- AsyncAPI: https://www.asyncapi.com/docs
- C4 Model: https://c4model.com
- Architecture Decision Records: https://adr.github.io
- OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/
- OWASP Top 10: https://owasp.org/www-project-top-ten/
- NIST SSDF: https://csrc.nist.gov/Projects/ssdf
- ISO/IEC 25010 overview: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
- Google SRE Books: https://sre.google/books/

## 5.5 テスト・ハーネス・品質保証

- pytest: https://docs.pytest.org
- Vitest: https://vitest.dev
- Jest: https://jestjs.io
- Playwright Test: https://playwright.dev/docs/test-intro
- Cypress: https://docs.cypress.io
- Postman: https://learning.postman.com/docs/
- k6: https://grafana.com/docs/k6/latest/
- WireMock: https://wiremock.org/docs/
- Pact: https://docs.pact.io
- Testcontainers: https://testcontainers.com
- Docker: https://docs.docker.com

## 5.6 コミュニティ・実務知

- Stack Overflow: https://stackoverflow.com
- GitHub: https://github.com
- Reddit: https://www.reddit.com
- Hacker News: https://news.ycombinator.com
- Indie Hackers: https://www.indiehackers.com
- Product Hunt: https://www.producthunt.com
- Zenn: https://zenn.dev
- Qiita: https://qiita.com
- Dev.to: https://dev.to
- note: https://note.com
- YouTube: https://www.youtube.com
- X: https://x.com

## 5.7 論文・研究

- Google Scholar: https://scholar.google.com
- arXiv: https://arxiv.org
- ACM Digital Library: https://dl.acm.org
- IEEE Xplore: https://ieeexplore.ieee.org
- Papers with Code: https://paperswithcode.com

# 6. リサーチ結果の証跡ルール

リサーチ結果は、必ず証跡つきで整理してください。一般論、推測、個人ブログ、SNS投稿、公式情報を混ぜないでください。

出力には、以下の証跡表を必ず含めてください。

| 証跡ID | 主張・発見 | 情報源種別 | URL | 確認日 | 信頼度 | 関連成果物 | 採用可否 |
|---|---|---|---|---|---|---|---|

信頼度は以下で分類してください。

- A: 公式ドキュメント、利用規約、標準文書、一次ソース。
- B: 公式に近い技術記事、メンテされたOSS、著名な技術資料。
- C: 個人ブログ、SNS、動画、コミュニティ投稿。ただし実務知として有用。
- D: 出所不明、古い情報、再現性不明。参考扱い。

# 7. 成果物別に材料を分類する

リサーチ後、必ず以下の表で材料を分類してください。

| 成果物 | 必要な材料 | 取得済み情報 | 不足情報 | 追加質問 | 優先度 |
|---|---|---|---|---|---|
| 要件定義書 | 背景、目的、利用者、課題、成功指標、スコープ。 |  |  |  |  |
| 仕様書 | 画面、操作、入力、出力、状態、例外、権限。 |  |  |  |  |
| 技術要件 | 性能、可用性、セキュリティ、監査、運用、コスト。 |  |  |  |  |
| アーキテクチャ | コンポーネント、責務、データフロー、外部連携。 |  |  |  |  |
| SDD | モジュール、DB、API、処理、エラー、ログ。 |  |  |  |  |
| テスト計画 | テスト種別、範囲、環境、合格基準、証跡。 |  |  |  |  |
| テストハーネス | モック、スタブ、フィクスチャ、録画、CI、ドライラン。 |  |  |  |  |
| 運用設計 | 監視、アラート、復旧、バックアップ、手動介入。 |  |  |  |  |
| リスク台帳 | 規約、API制限、品質、セキュリティ、法務、保守。 |  |  |  |  |

# 8. 要件ID体系を提案する

リサーチ結果をもとに、要件ID体系を提案してください。以下を基本形とし、必要に応じて追加してください。

| ID接頭辞 | 意味 | 例 |
|---|---|---|
| OBJ | 目的・ゴール | OBJ-001 |
| USR | 利用者・権限 | USR-001 |
| FLOW | 業務フロー | FLOW-001 |
| FUNC | 機能要件 | FUNC-001 |
| SPEC | 仕様 | SPEC-001 |
| DATA | データ要件 | DATA-001 |
| API | 外部連携・API | API-001 |
| ARCH | アーキテクチャ | ARCH-001 |
| SDD | 詳細設計 | SDD-001 |
| NFR | 非機能要件 | NFR-001 |
| SEC | セキュリティ要件 | SEC-001 |
| OPS | 運用要件 | OPS-001 |
| TEST | テスト要件 | TEST-001 |
| HAR | テストハーネス | HAR-001 |
| ACC | 受入基準 | ACC-001 |
| RISK | リスク | RISK-001 |
| PLAN | 実装計画 | PLAN-001 |
| REV | レビュー指摘 | REV-001 |

# 9. 受入基準とテスト可能性を必ず確認する

すべての主要要件について、受入基準と検証方法をセットで整理してください。

| 要件ID | 要件 | 受入基準 | 検証方法 | テスト種別 | 必要な証跡 | 優先度 |
|---|---|---|---|---|---|---|

受入基準は、可能な限りGiven / When / Then形式でも表現してください。

# 10. テストハーネス設計のために必ず調べること

テストハーネス設計では、以下を必ず調査してください。

| 観点 | 調査内容 |
|---|---|
| 外部APIのモック化 | 公式サンドボックス、モックサーバー、録画レスポンス、ダミーアカウント。 |
| 誤投稿防止 | ドライラン、承認キュー、投稿前プレビュー、送信先制限。 |
| テストデータ | 正常データ、異常データ、境界値、欠損、重複、巨大データ。 |
| 再現性 | 固定シード、固定時刻、フィクスチャ、スナップショット。 |
| CI/CD | 自動テスト実行、失敗時停止、レポート、カバレッジ。 |
| API制限対策 | レート制限、リトライ、バックオフ、キュー、冪等性キー。 |
| セキュリティ | テスト用秘密情報、環境変数、権限分離、ログマスキング。 |
| LLM評価 | ゴールデンデータ、回帰評価、プロンプト変更検知、ファクトチェック。 |

出力は以下の表にしてください。

| HAR-ID | テスト対象 | ハーネス方式 | モック/スタブ対象 | テストデータ | 自動化可否 | 誤操作防止 | 採用理由 |
|---|---|---|---|---|---|---|---|

# 11. アーキテクチャ候補を複数案で比較する

リサーチ結果に基づき、少なくとも3つのアーキテクチャ案を出してください。

例:

- A案: 既存SaaS中心。Zapier、Make、n8nなどで最小構築。
- B案: API連携中心。自作バックエンドと公式APIで構築。
- C案: ハイブリッド。AI生成と人間承認を挟み、API可能部分だけ自動化。
- D案: RPA/ブラウザ自動化を含む。ただし規約・保守リスクが高い場合は原則非推奨。

比較表を必ず出してください。

| 案 | 概要 | 長所 | 短所 | 規約リスク | 実装難易度 | 運用負荷 | MVP適性 | 推奨度 |
|---|---|---|---|---|---|---|---|---|

# 12. フェーズ別Exit Criteriaを作る

PoC、MVP、β、本番、運用改善のフェーズに分け、Exit Criteriaを作成してください。

| フェーズ | 目的 | 対象範囲 | 必須成果物 | Exit Criteria | 次フェーズへ進めない条件 | 証跡 |
|---|---|---|---|---|---|---|

# 13. リスク・停止基準を作る

自動化、AI、外部API、投稿、出版、配信、課金、個人情報を扱う場合、採用基準、警告基準、一時停止基準、強制停止基準を作ってください。

| リスクID | リスク | 発生条件 | 影響 | 検知方法 | 警告基準 | 一時停止基準 | 強制停止基準 | 対応策 |
|---|---|---|---|---|---|---|---|---|

# 14. CodexレビューとOpus再分析の準備をする

リサーチ結果とドラフト成果物ができたら、Codexレビュー用プロンプトとOpus再分析用プロンプトを作成してください。

Codexレビューでは、以下を確認させてください。

- 要件の曖昧さ
- 実装不能な要件
- 仕様と要件の矛盾
- API制限・規約リスクの見落とし
- セキュリティ・権限・監査の不足
- テスト計画の不足
- テストハーネス設計の不足
- 過剰設計
- MVPに不要な論点
- NO-GO要因

Opus再分析では、Codexの結果を鵜呑みにせず、ACCEPT / MODIFY / REJECT / HOLD / ESCALATEで判定させてください。

最大3ラウンドまで反復し、収束しない場合は人間判断へエスカレーションしてください。

# 15. 最終出力形式

リサーチ完了後、以下の構成で出力してください。

## 1. エグゼクティブサマリー

何を作ろうとしているのか、リサーチで何が分かったのか、実装に進める可能性があるのかを非エンジニアにも分かる言葉で説明してください。

## 2. リサーチ計画と実施範囲

| 調査ID | 調査テーマ | 調査先 | 実施結果 | 優先度 |
|---|---|---|---|---|

## 3. 主要発見事項

| 発見ID | 発見 | 根拠URL | 信頼度 | 要件・設計への影響 |
|---|---|---|---|---|

## 4. 公式ドキュメント・規約確認結果

| 対象 | できること | できない/不明なこと | 制限 | 規約リスク | 設計方針 |
|---|---|---|---|---|---|

## 5. 成果物別材料分類

| 成果物 | 取得済み材料 | 不足材料 | 追加質問 | 優先度 |
|---|---|---|---|---|

## 6. 要件ID体系案

| 接頭辞 | 意味 | 使用方針 |
|---|---|---|

## 7. 要件・受入基準・検証方法の初期台帳

| 要件ID | 要件 | 優先度 | 受入基準 | 検証方法 | 根拠 |
|---|---|---|---|---|---|

## 8. アーキテクチャ候補比較

| 案 | 概要 | 長所 | 短所 | リスク | 推奨度 |
|---|---|---|---|---|---|

## 9. SDD作成に必要な材料

| SDD章 | 必要情報 | 取得済み | 不足 | 次アクション |
|---|---|---|---|---|

## 10. テスト計画材料

| テスト種別 | 対象 | 観点 | 合格基準 | 必要な環境 | 自動化可否 |
|---|---|---|---|---|---|

## 11. テストハーネス設計材料

| HAR-ID | 対象 | ハーネス方式 | モック対象 | テストデータ | CI連携 | 誤操作防止 |
|---|---|---|---|---|---|---|

## 12. リスク台帳

| リスクID | リスク | 影響 | 発生可能性 | 対応策 | 優先度 |
|---|---|---|---|---|---|

## 13. 追加質問

人間に確認しないと確定できないことだけを、優先度順に質問してください。

## 14. 次に生成すべき成果物

リサーチ結果をもとに、次に作るべき成果物を順番に提示してください。

## 15. Codexレビュー用プロンプト

今回のリサーチ結果とドラフト成果物をCodexにレビューさせるためのプロンプトを、コピー可能な形で出してください。

## 16. Opus再分析用プロンプト

Codexレビュー結果を鵜呑みにせず再分析するためのプロンプトを、コピー可能な形で出してください。

# 16. 最重要制約

1. 公式ドキュメントや規約で確認できないことを、できると断定しないでください。
2. 非公式API、スクレイピング、ブラウザ自動化は、実装案に入れてもよいが、必ず規約・保守・アカウント停止リスクを明記してください。
3. SNSや個人ブログの情報は、仮説生成には使ってよいが、最終判断の根拠にはしないでください。
4. 完全自動化が危険な場合は、「完全自動化」ではなく「人間承認つき半自動化」を推奨してください。
5. MVPでは、実装開始に必要な最低限に絞り、後でよい論点はLaterに分類してください。
6. すべての主要な発見には、根拠URL、信頼度、成果物への反映先を付けてください。
7. 最終的に、GO / CONDITIONAL GO / NO-GO / ESCALATEの判定を出せる材料を集めてください。

コピー終了: 世界最高基準の要件定義・仕様書・設計書を作るための材料収集リサーチプロンプト

7. 追加で使う短縮プロンプト

上記のマスタープロンプトを実行した後、特定の成果物だけ深掘りしたい場合は、以下を追加で使ってください。

7.1 要件定義材料だけを深掘りするプロンプト

ここまでのリサーチ結果をもとに、要件定義書に入れる材料だけを抽出してください。背景、目的、利用者、課題、現行業務、To-Be業務、スコープ、対象外、成功指標、制約、前提、リスク、未決事項に分類し、要件IDを付けてください。不足している情報は、追加質問として優先度順に出してください。

7.2 技術要件とアーキテクチャだけを深掘りするプロンプト

ここまでのリサーチ結果をもとに、技術要件とアーキテクチャ設計に必要な材料だけを抽出してください。外部API制限、認証、レート制限、データ保存、非同期処理、キュー、ジョブ管理、ログ、監視、障害復旧、セキュリティ、コスト、拡張性、保守性を整理し、最低3つのアーキテクチャ案を比較してください。

7.3 SDD材料だけを深掘りするプロンプト

ここまでのリサーチ結果をもとに、SDD、つまりSoftware Design Documentに必要な材料を抽出してください。モジュール構成、責務、インターフェース、データモデル、状態遷移、処理シーケンス、エラー処理、ログ、設定、環境変数、依存ライブラリ、デプロイ構成、テスト容易性を章立てで整理してください。

7.4 テスト計画とテストハーネスだけを深掘りするプロンプト

ここまでのリサーチ結果をもとに、テスト計画とテストハーネス設計に必要な材料だけを抽出してください。単体、結合、E2E、契約テスト、回帰、負荷、セキュリティ、権限、異常系、境界値、ユーザー受入、LLM評価を分類し、モック、スタブ、フィクスチャ、録画レスポンス、ドライラン、誤投稿防止、CI連携、テストデータ管理の設計案を出してください。

7.5 Codexレビュー用プロンプト生成

ここまで作成したリサーチ結果、要件定義、仕様、技術要件、アーキテクチャ、SDD、テスト計画、テストハーネス設計を、Codexに独立レビューさせるためのプロンプトを作成してください。レビュー観点には、実装不能要件、曖昧要件、API制限、規約違反、セキュリティ不足、テスト不足、ハーネス不足、過剰設計、MVP範囲逸脱、NO-GO要因を含めてください。

7.6 Opus再分析用プロンプト生成

Codexレビュー結果を鵜呑みにせず、Opusが一次ソース、公式ドキュメント、実ファイル、リサーチ証跡を確認して再分析するためのプロンプトを作成してください。各指摘に対してACCEPT、MODIFY、REJECT、HOLD、ESCALATEを判定し、最大3ラウンドの反復レビュー・収束プロトコルを含めてください。

8. 最終的な運用フロー

このプロンプトは、以下の順序で使うと品質が安定します。重要なのは、リサーチ、構造化、要件化、仕様化、設計化、テスト化、レビュー、確定を分けることです。

フェーズ	目的	成果物
1	曖昧な構想を入力する。	プロジェクト概要、初回質問回答。
2	リサーチ計画を作る。	調査ID、仮説、調査先、優先度。
3	公式情報と規約を確認する。	API可否、制限、規約リスク。
4	市場・ユーザー・競合を調べる。	課題、代替手段、差別化。
5	技術標準と設計標準を調べる。	SDD、NFR、テスト、セキュリティの型。
6	成果物別に材料を分類する。	要件、仕様、設計、テスト、ハーネス材料表。
7	不足情報を質問で埋める。	追加質問、仮定、未決事項。
8	要件定義書・仕様書・設計書へ変換する。	requirements.md、spec.md、architecture.md、sdd.md。
9	テスト計画・ハーネス設計を作る。	test_plan.md、test_harness_design.md。
10	CodexレビューとOpus再分析を行う。	review_result.md、final_decision.md。

9. このプロンプトで特に強化した点

添付された2つの要件定義プロンプトは、すでに質問駆動、要件ID、受入基準、テスト計画、実装計画、Codex/Opusレビューを含む強い構成でした。今回の最終版では、それに加えて、要件定義に入れる前段階として、材料収集リサーチそのものを成果物別に制御する設計にしています。

強化点	内容
リサーチ先の明示	公式API、規約、標準、OSS、コミュニティ、論文、SNS、YouTubeまで調査候補を明示。
仮説駆動	調べる前に、失敗しそうな論点を予測して検証する。
成果物別分類	リサーチ結果を要件、仕様、技術、アーキテクチャ、SDD、テスト、ハーネスに分類。
証跡管理	URL、信頼度、確認日、反映先を必ず記録。
規約リスク重視	完全自動化、スクレイピング、非公式API、AI生成物を危険論点として扱う。
テストハーネス強化	モック、スタブ、ドライラン、録画レスポンス、CI、誤投稿防止まで含める。
レビュー収束	Codex ⇄ Opusの最大3ラウンド反復レビューを前提化。

世界最高基準の要件定義・設計を作る最終版・材料収集リサーチプロンプト

要約

要点