AIでWebアプリの範囲定義を行う方法：私たちが使う6つのプロンプト連鎖（アイデアからSOWまで）
直近の5件のクライアント案件における範囲定義では、従来12〜16時間かかっていたヒアリング会議の部分が、約3時間のAI作業と1時間の人間によるレビューに短縮されました。私たちはこの全体のプロセスを単一の Claude Project 内で実行し、コンテキストを引き継いでいます。ただし注意点として、AIは毎回必ず3つの点で間違いを犯しました。そのため、クライアントに提出する前にゲート（確認工程）を設けています。
ここでは、私たちが実際に使用している6つのプロンプト連鎖、各プロンプトが生成する成果物、完全な実例、そして自分自身で捕捉しなければならない失敗パターンについて解説します。
AIはWebアプリプロジェクトの範囲定義を行えるのか？ はい。AIは数日ではなく数時間で、完全なスコープ（問題定義、ユーザーストーリー、機能、MoSCoW優先順位、作業範囲書）の下書きを作成できます。しかし、その下書きを検証することはできません。AIは要件を捏造し、工数を過小評価するため、署名前の人間のチェックは必須です。
主なポイント
- AIは数日ではなく数時間でWebアプリの完全なスコープを下書きしますが、自身の出力を検証することはできません。
- この連鎖は6つのプロンプトで構成されます：問題定義、ユーザーストーリー、機能リスト、MoSCoW優先順位付け、見積もり、SOW。
- AIは統合機能を捏造し、エッジケースを過小評価するため、必ず人間による確認工程を実行してください。
- この連鎖には Claude Projects または ChatGPT Projects を使用し、エージェントの利用はスコープが確定した後に行います。
AIは午後だけで最初のスコープ下書きを作成できます。ただし、それが間違っているかどうかを伝えることはできません。
AI支援スコーピングとは何か（そして何ではないか）？
AI支援スコーピングとは、一連のLLMプロンプトを使用して、曖昧なアイデアを構造化されたスコープ成果物（要件、ユーザーストーリー、機能リスト、優先順位、作業範囲書）に変換することを意味します。AIは下書き作成と構造化を担当します。決定、ステークホルダーとの対話、検証は依然として人間が行います。
つまり、AIがあなたの代わりに思考を行っているのでしょうか？ 必ずしもそうではありません。AIは ai requirements gathering（AI要件収集）、つまり「予約アプリを作りたい」という要望を開発者が見積もりできる形に翻訳するために空白のページと格闘する部分においては高速です。しかし、クライアントが実際に必要としていることと、もっともらしく聞こえることの区別をつけるのは苦手です。
AI支援スコーピングが ではない いくつかの点：自律的ではない、実際のステークホルダーとの対話の代替ではない、精度の保証ではないことです。モデルは、誰も求めていない機能に対しても、自信に満ちた整形式の仕様書を喜んで作成してしまいます。
この記事は、スコーピングプロセス自体をすでに理解していることを前提としています。基礎知識が必要な場合は、ステップバイステップのスコーピングガイド で、AIを使用しない基本プロセス、7つのステップ、および完全なスコープドキュメントの構造について解説しています。ここでは、AIレイヤー、つまりどのプロンプトをどのような順序で使用し、どこで破綻するかという点に焦点を当てます。
一目でわかるAIスコーピングプロンプト連鎖
この連鎖は、6つのプロンプトを順次実行し、それぞれの出力を次に引き継ぐものです。順序は以下の通りです：(1) 問題と目標、(2) ユーザーストーリー、(3) 機能リスト、(4) MoSCoW優先順位付け、(5) 工数・コスト・スケジュール見積もり、(6) SOW下書き。コンテキストを維持するために、これらはすべて1つのプロジェクト内で実行します。
素晴らしい点は、各プロンプトが前のプロンプトに基づいて構築されるため、アプリについて6回説明し直す必要がないことです。モデルはユーザーストーリーを作成する際に問題をすでに理解しており、機能を優先順位付けする際にはストーリーをすでに把握しています。
- 問題と目標： 曖昧なアイデアを問題定義とSMARTゴールに変換します。
- ユーザーストーリー： 目標を受入基準付きのユーザーストーリーに変換します。
- 機能リスト： ストーリーから具体的な機能一覧を導き出します。
- MoSCoW優先順位付け： 機能をMust（必須）、Should（推奨）、Could（可能）、Won't（今回除外）に分類します。
- 見積もり： 工数、コスト範囲、スケジュールを算出します。
- SOW下書き： すべての情報を作業範囲書にまとめます。
これは一般的にも ai prompts for project management（プロジェクト管理向けAIプロンプト）のクリーンなセットですが、私たちはすべてのプロンプトをWebアプリ特有のもの（技術スタック、統合、エッジケース）に合わせて調整しています。この調整こそが、利用可能なスコープと一般的なスコープを分けるものです。
重要なのは1つの魔法のようなプロンプトではありません。互いに出力を受け渡す6つのプロンプトです。
チェインを段階的に実行する方法
Claude Project または ChatGPT Project 内で上から下へと連鎖を実行し、各プロンプトを順番に貼り付け、前の回答がコンテキストに残るようにします。以下は、私たちが使用する正確なプロンプトを含む6つの簡単なステップです。汎用的なビジネス分析プロンプトは汎用的なスコープを生み出すため、意図的にすべてWebアプリ固有のものにしています。
開始前の注意：括弧内のプレースホルダーは独自の詳細に置き換え、最初の出力を決して最終版として受け入れないでください。プロの手法は、各結果を読み、修正してから次のプロンプトを実行することです。
プロンプト1：問題定義と目標
You are a senior product manager scoping a web application.
Here is the rough idea: [describe the app in 2-4 sentences].
The target users are [who]. The business wants [outcome].
Write:
1. A one-paragraph problem statement.
2. 3-5 SMART goals with success metrics.
3. 3 assumptions you are making that I should confirm.
Flag anything that is unclear instead of guessing.これにより、概要と目標セクションが作成されます。プロのヒント：「3つの仮定」という行は重要な役割を果たしています。これにより、AIが otherwise 覆い隠してしまうギャップが表面化します。
プロンプト2：ユーザーストーリー
Acting as the same product manager, turn the goals above into
user stories for a web app. Use the format:
"As a [role], I want [action], so that [benefit]."
Cover every user role. For each story, add 2-3 acceptance
criteria. Group stories by feature area.これで機能要件が揃いました。これはクリーンな ai user story generator（AIユーザーストーリー生成）ステップです。注意点：管理者やエッジケースのロールを忘れがちなので、「今度は管理者、支払い失敗、空の状態に関するストーリーを追加して」と再度プロンプトを出してください。
プロンプト3：機能リスト
Based on the user stories above, produce a flat feature
inventory for this web app. Group features into: core, account
and auth, admin, integrations, and notifications. Note any
feature that requires a third-party service or API.これがスコープ内の機能候補リストです。AIが統合機能の捏造を開始する場所であるため、このステップは closely 監視してください（詳細は後述）。
プロンプト4：MoSCoW優先順位付け
Prioritize the feature list using MoSCoW (Must, Should, Could,
Won't) for a first release (MVP). For each feature give a
one-line reason. Assume a 3-month MVP budget and be ruthless:
most features should NOT be "Must."これにより、スコープ内およびスコープ外の項目にタグ付けされます。「容赦なく」という指示が重要です。これがないと、モデルはほぼすべてをMust（必須）としてマークしてしまいます。
プロンプト5：工数、コスト、スケジュール見積もり
Estimate effort, cost, and timeline for the Must-have features
only. Assume a stack of [e.g. Next.js, Supabase, Stripe] and a
team of [N] developers. Break the estimate down by feature in
days. State every assumption. Give a cost RANGE, not a single
number, and flag the 3 riskiest estimates.これは予算とスケジュールのための ai scope of work generator（AI作業範囲書生成）への入力となります。単一の自信満々な数字はAIが出力する中で最も危険なものなので、必ず範囲と仮定を要求してください。
プロンプト6：SOW下書き
Assemble everything above into a draft statement of work for a
client. Include: overview, goals and success metrics, in-scope
features, explicit out-of-scope items, timeline, budget range,
deliverables, assumptions, and a sign-off section. Mark any
section where you are uncertain with [REVIEW].[REVIEW] タグが人間による確認チェックリストとなります。このステップは、連鎖全体が約束した「アイデアからSOWまで」の範囲を組み立てます。
プロンプト → スコープセクションのマッピング
各プロンプトは質問に答えるだけでなく、クライアントに提出するドキュメントの特定のセクションを埋めます。このマッピングにより、通常の11セクションテンプレートが置き換わります。骨格を暗記するのではなく、連鎖を実行することでドキュメントが自動的に組み立てられるのです。どのプロンプトがどの成果物を生成するかは以下の通りです。
| プロンプト | 生成物 | 埋めるスコープドキュメントのセクション |
|---|---|---|
| 1. 問題と目標 | 問題定義 + SMARTゴール | 概要、目標と成功指標 |
| 2. ユーザーストーリー | ユーザーストーリー + 受入基準 | 機能要件 |
| 3. 機能リスト | 機能一覧 | スコープ内機能 |
| 4. MoSCoW | 優先順位付けされたMust/Should/Could/Won't | スコープ内（タグ付き）+ スコープ外 |
| 5. 見積もり | 工数、コスト範囲、スケジュール | スケジュール、予算範囲 |
| 6. SOW下書き | 組み立てられた作業範囲書 | 完全なSOW + 成果物 + 署名 |
プロンプト6を終える頃には、クライアントが実際に読み、署名できるドキュメントの完全な初稿ができあがっており、バラバラのメモの山ではありません。
各プロンプトは単に質問に答えるだけではありません。クライアントに提出するドキュメントの特定のセクションを埋めます。
完全な実例：予約管理SaaSのスコープ定義
ここでは、具体的なケース、つまり小規模な歯科チェーン向けの予約管理SaaSに対して連鎖を端到端で実行した例を示します。これは説明的な例であり、実際のクライアント納品物ではありません。また、はい、私たちはAIの出力で2つのエラーを発見しました。これらは以下の人間による確認セクションで修正しています。
プロンプト1の出力（問題と目標）。 問題：3拠点の歯科チェーンが、電話の取り合いとノーショー（無断欠席）により予約を失っている。目標：リマインダーによりノーショーを30%削減、患者のオンライン自助予約、フロントデスクスタッフ向けの共有カレンダー1つ。明示された仮定：単一タイムゾーン、英語のみ、保険請求なし。
プロンプト2の出力（サンプルユーザーストーリー）。
- 患者として、電話をかけなくても済むように、オンラインで予約をしたい。
- 患者として、予約を忘れないように、SMSリマインダーを受け取りたい。
- フロントデスクスタッフとして、重複を管理できるように、3拠点すべてを1つのカレンダーで表示したい。
プロンプト3の出力（機能リスト、要約）。 オンライン予約、カレンダー同期、SMSおよびメールリマインダー、患者アカウント、マルチロケーション管理、基本レポート、および支払いステップ（最後の一つは捏造されており、誰も求めていませんでした）。
プロンプト4の出力（MoSCoWグリッド）。
| 優先度 | 機能 |
|---|---|
| Must（必須） | オンライン予約、マルチロケーションカレンダー、SMSリマインダー、患者アカウント |
| Should（推奨） | メールリマインダー、基本レポート |
| Could（可能） | 患者による自助再予約 |
| Won't（v1では除外） | 支払い、保険請求、ネイティブモバイルアプリ |
プロンプト5の出力（見積もり、要約）。 Next.js、Supabase、Twilioを使用し、開発者2名を想定：Must-have機能で約45〜60開発者日、コスト範囲は約$35K〜$55K、スケジュールは8〜10週間。最もリスクの高い見積もりとしてフラグ付けされたもの：マルチロケーションカレンダーのロジック。
プロンプト6の出力（SOW抜粋）。 「スコープ内：オンライン予約、マルチロケーション共有カレンダー、SMSリマインダー（Twilio）、患者アカウント。スコープ外：支払い、保険、ネイティブモバイル。スケジュール：8-10週間。予算範囲：$35K-$55K。[REVIEW] クライアントとTwilioまたは代替SMSプロバイダーを確認。」
ざっと見れば、署名可能な現実的なスコープが一度のセッションで形作られたことがわかります。後でスマート機能を追加する予定であれば、アプリにAI機能を追加する に関する私たちのガイドが、ここから続きを行います。
AIでコストとスケジュールを見積もる方法
モデルに対して、見積もりを機能別に日数で分解し、特定の技術スタックを想定し、すべての仮定を明記し、単一の数字ではなく範囲を返すようプロンプトを出します。その後、AIはほとんど常に工数について楽観的にアンカー設定するため、その範囲を既知の市場ティアに対してサニティチェック（妥当性確認）します。
AIの見積もりは出発点として扱い、決して見積書として扱わないでください。最も有用な指示は「リスクの高い見積もり3つをフラグ付けせよ」であり、これにより自身の判断をどこに注ぐべきかが明確になります。以下は、すべてのAI見積もりをチェックする際に参照するティアです。
| Webアプリの複雑さ | 典型的なコスト範囲 | 典型的なスケジュール |
|---|---|---|
| シンプルなMVP | $10K-$50K | 1-3ヶ月 |
| 中程度（認証、支払い、ダッシュボード） | $50K-$100K | 3-6ヶ月 |
| 複雑（マルチロール、統合、スケール） | $75K-$150K+ | 6-12ヶ月 |
これらの範囲は公開されている代理店およびマーケットプレイスのベンチマークと一致しており、Clutchのアプリ開発コスト調査 は合理的な公的な参照点です。AIの見積もりが関連するティアを大幅に下回る場合、おそらくエッジケースを見逃しています。ここでより大きな質問、つまり ビルド vs バイ を問う時でもあります。複雑なティアを超えて膨れ上がるスコープの場合、構築よりも購入を主張することがあります。
各作業にどのAIツールを使用すべきか？
連鎖全体には Claude Projects または ChatGPT Projects を使用してください。両方ともプロンプト間でコンテキストを保持するため、再貼り付けなしで出力を引き継ぐことができます。スタンドアロンのエージェントは、スコープが確定し、再現可能な成果物を生成している段階になってから使用してください。一回限りのスコーピングでは、Projects がエージェントを常に上回ります。
私たちは Claude Projects で連鎖を実行し、長文コンテキストを必要とするステップ（ユーザーストーリー、SOW組み立て）に使用し、見積もりに対する第二の意見が欲しいときは ChatGPT を利用します。AnthropicのProjectsドキュメント によると、Project は会話間で共有コンテキストと指示を保持するため、这正是 6プロンプトの claude projects for requirements ワークフローに必要なものです。OpenAIのProjects も chatgpt prompts software development において同様に動作します。
盗む価値のあるテクニック：ステップごとにAIの役割を分割することです。ユーザーストーリーには「プロダクトマネージャーとして振る舞え」、見積もりには「シニアエンジニアとして振る舞え」と指示します。役割の切り替えは推論方法を変化させ、エンジニアのペルソナは工数に関して顕著に保守的になります。
スコープが出荷され、構築が開始されると、ツールの質問は AIコーディングエージェント に移行しますが、これは全く異なる決定です。
AIはスコーピングをどこで間違えるのか？人間による検証ゲート
AIは予測可能な方法でスコーピングを間違えます：誰も依頼していない統合機能を幻覚し、エッジケースやエラー状態を過小評価し、コンプライアンス要件を捏造するか、あるいは実際の要件を静かに省略します。また、コスト見積もりを楽観的にアンカー設定します。これらは稀なことではなく、本質的にすべての実行で発生するため、人間によるゲートは交渉の余地がありません。
悪い要件は、人間が書いたとしてもモデルが書いたとしても高価です。PMIのPulse of the Profession調査 によれば、不正確な要件収集は失敗したプロジェクトの約37%においてプロジェクト失敗の主要因であり、ゲートの目的は、それらの見落としが見積もり段階に到達する前に捕捉することです。
解決策は、スコープがクライアントに到達する前に人間が実行する短いチェックリストです：
- 捏造された機能の削除： クライアントが求めていないもの（支払い、エクスポート、統合）をすべて削除します。
- 不足しているエッジケースの追加： 支払い失敗、空の状態、権限、エラー処理。
- すべての統合の確認： 指定されたサードパーティサービスが実在し、必要であり、予算計上されていることを確認します。
- コンプライアンス主張の確認： AIが主張した認証、プライバシー、または規制要件を確認または修正します。
- 見積もりのバッファ追加： 特にフラグ付けされたリスクの高いものについて、自身のベロシティに対して楽観的な数字を調整します。
AIは自身が捏造した支払いフローを自信を持ってスコープに含めます。あなたの仕事は、誰も求めていない部分を削除することです。
実際のクライアントスコープでこれを実行して学んだこと
直近の複数のクライアントスコープにおいて、従来約12〜16時間の会議と文書作成にかかっていた発見作業が、約2〜3時間のAI作業と1時間の人間によるレビューで初稿SOWに至るようになりました。これらは私たちの実際の実行に基づく正直な範囲であり、正確な見出し統計ではありません。また、人間の1時間は決して削ることのない部分です。
私たちは Claude Projects で連鎖を実行し、ChatGPT を見積もりのサニティチェックとして使用します。節約される時間は現実的ですが、価値は毎回同じ3つの失敗を捕捉することにあります：
- 統合機能を捏造する。 歯科の例では、誰も求めていない支払いステップが含まれていました。ほぼすべてのスコープに少なくとも1つの幻影機能がありました。
- エッジケースを過小評価する。 エラー状態、空の状態、管理者フローは一貫して欠落しているか過少計上されており、ここで実際の予算が膨れ上がります。
- コンプライアンスと認証を誤って処理する。 時々要件を幻覚し、時々実際の要件を省略します。この点については決して信頼しません。
したがって、上記の人間によるゲートを固定ステップとして追加しました。連鎖は迅速に下書きを作成しますが、ゲートこそが送信を安全にするものです。ゲートをスキップすると、自信に満ちた整形式の推測を送りつけるだけになります。
TechsyのAI支援スコーピングへのアプローチ
この連鎖と人間によるゲートは、Webアプリを構築するクライアントのために私たちが実行する正確なワークフローです。AIで迅速に下書きを作成し、その後、実際の構築を出荷した経験のある人物が、見積もりとなる前にすべての行を検証します。これを毎日行うチームにスコープを任せたい場合は、それが私たちの仕事です。2週間の発見会議に費用を支払うことなく、防御可能なSOWを得ることができます。
著者について
Mert Batur Gurbuz は Techsy.io の共同創業者であり、同社ではB2Bクライアント向けにAIエージェント、自動化システム、および音声/SDRパイプラインを出荷しています。バーミンガム大学で学び、Techsyチームが生産環境で実際に使用しているLLMツールスタックについて執筆しています。
共同創業者、Techsy.io — バーミンガム大学。LinkedIn でつながる。
よくある質問
AIはプロジェクトスコープやSOWを作成できますか？
はい、AIは問題、ユーザーストーリー、機能、優先順位、スケジュール、予算範囲を含む完全なプロジェクトスコープまたは作業範囲書を下書きできます。Claude または ChatGPT Project 内で6プロンプト連鎖を実行してください。下書きは出発点としては信頼できますが、署名前に人間が検証する必要があります。
ソフトウェアプロジェクトのスコープ定義に最適なAIツールは何ですか？
Claude Projects と ChatGPT Projects がスコープ定義に最適なツールです。両方ともプロンプト連鎖間でコンテキストを保持するため、各出力が次に引き継がれるからです。私たちはユーザーストーリーやSOW組み立てなどの長文コンテキストステップに Claude Projects を使用し、見積もりの第二の意見として ChatGPT を使用します。エージェントはスコープ後の構築作業に適しています。
ChatGPT や Claude を使って要件を収集するにはどうすればよいですか？
プロンプト連鎖を順序通りに実行します：問題定義と目標を求め、次に受入基準付きのユーザーストーリー、次に機能リスト、次にMoSCoW優先順位を求めます。コンテキストを引き継ぐために、すべてを1つのProject内に保持してください。各プロンプトの出力が次の入力となることで、AI要件収集が高速化されます。
AIはソフトウェアプロジェクトのコストとスケジュールを見積もれますか？
はい、あくまで出発点としてのみ可能です。モデルに対して、見積もりを機能別に日数で分解し、特定のスタックを想定し、仮定を明記し、範囲を返すようプロンプトを出してください。その後、市場ティアに対してサニティチェックを行います：シンプルなMVPで$10K-$50K、複雑なアプリで最大$150K+。AIは傾向として楽観的にアンカー設定します。
AI生成スコープは実際に信頼できますか？
初稿としては信頼できますが、署名用としては信頼できません。AIは構造化されたスコープを迅速に作成しますが、ほぼすべての実行で統合機能を捏造し、エッジケースを過小評価し、コンプライアンスを誤って処理します。出力を迅速な下書きとして扱い、誰も求めていない機能を削除し、不足しているエッジケースを追加するために人間による検証ゲートを実行してから、署名に進んでください。
AIを使って曖昧なアイデアを仕様書に変換するにはどうすればよいですか？
プロンプト1から始めます：アイデアを2〜4文で貼り付け、AIに問題定義、SMARTゴール、および仮定を作成するよう依頼します。その後、次の5つのプロンプトを順次実行します。プロンプト6までにSOW下書きが出来上がります。連鎖全体は数日ではなく数時間で完了します。
AI支援スコーピングは発見フェーズを置き換えますか？
いいえ、発見フェーズを置き換えるのではなく圧縮します。クライアントが実際に何を望んでいるかを知るためには、依然として実際のステークホルダーとの対話が必要です。AIは下書きと構造化を担当し、メモを数時間で要件とSOWに変換します。人間は依然として検証、優先順位付け、スコープに関する最終判断を行います。
AIでWebアプリのスコープ定義にはどのくらい時間がかかりますか？
私たちの経験では、初稿SOWは手動での発見と文書作成に12〜16時間かかるのに対し、約2〜3時間のAI作業と約1時間の人間によるレビューで完了します。AIの時間は高速ですが、レビューの1時間は交渉の余地がありません。なぜなら、そこでAIが捏造した機能と見逃したエッジケースを捕捉するからです。