AIとECサイトの要件定義をブレストする：対話パターンと質問設計の実践

ECサイトのリニューアルプロジェクトで、Claude Codeのブレインストーミング機能を使って要件定義を行いました。1人開発では「自分の思い込み」に気づけないという構造的な問題があります。AIとの対話型ブレストは、この問題に対する実践的な解決策になります。

本記事では、サブスクリプション機能付きECサイトの要件定義を例に、AIが投げかける質問の構造、人間がどう答えると精度の高い要件に落ちるか、そしてブレストから仕様書へどう接続するかを記録します。

1人開発の要件定義で何が起きるか

1人で要件定義をすると、以下の問題が必ず起きます。

抜け漏れ: 自分が普段使わない機能を忘れる。ギフト対応、解約導線、初回特典など
思い込み: 「ユーザーは当然こう使うだろう」という前提が検証されないまま仕様になる
優先順位の偏り: 技術的に面白い機能を優先し、ビジネス上重要な機能を後回しにする

チームなら他メンバーが指摘してくれます。1人開発ではAIに「壁打ち相手」を頼むことで、この穴を埋められます。

ブレストコマンドと体系的な質問設計

Claude Codeの /sc:brainstorm コマンドを使ってブレストを開始しました。このコマンドはソクラテス式の対話を通じて、要件を体系的に掘り下げます。

起動は単純です。

1
/sc:brainstorm ECサイトのリニューアル要件を整理したい

AIは一方的に要件を列挙するのではなく、質問を投げかけてきます。この「質問されて考える」プロセスが重要です。自分1人では問いを立てられない領域に、AIが切り込んできます。

Q&Aラウンドの構造：何を聞かれ、なぜその質問が重要か

ブレストは複数ラウンドのQ&Aで進行しました。各ラウンドでAIが聞いてくる質問には明確な意図があります。

ラウンド1: ターゲットユーザーの明確化

1
AI: このECサイトのメインターゲットは誰ですか？
2
    年齢層、購買頻度、リテラシーレベルを教えてください。

なぜこの質問が最初に来るのでしょうか。ターゲットが曖昧なまま機能を決めると、「誰のための機能かわからない」仕様が量産されます。ここで「初心者が迷わず購入できること」と答えるか「リピーターの継続率を上げること」と答えるかで、後続の設計判断がすべて変わります。

ラウンド2: サブスクリプション構造

1
AI: 定期便サービスのコース設計について教えてください。
2
    何コースを想定していますか？各コースの差別化ポイントは？

ここで具体的な回答を返します。

1
人間: 3コース構成。
2
      - ライト: 月1回配送、1種類 × 5個
3
      - スタンダード: 月1回配送、2種類 × 5個
4
      - プレミアム: 月2回配送、4種類 × 5個

AIは回答を受けて、自分では考えなかった論点を突いてきます。「配送頻度が月2回のプレミアムは物流コストが倍になるが、価格設定でカバーできるか？」「スタンダードとプレミアムの間に価格差が大きすぎないか？」といった深掘りが入ります。

ラウンド3: 商品属性とカスタマイズ

1
AI: 商品のバリエーションについて教えてください。
2
    カテゴリ分類、属性による絞り込みはありますか？

1
人間: 5つのテーマで分類。Clear / Rich / Relax / Organic / Decaf。
2
      商品形態は3種類: ホール、グラウンド、ドリップバッグ。

テーマ設計と商品形態の組み合わせは、DB設計とフィルタリングUIに直結します。AIはこの回答から「5テーマ × 3形態 = 最大15パターン。在庫管理の粒度はこの単位でよいか？」と確認してきます。1人で考えていたら「テーマは5つ」で終わっていたところです。

ラウンド4: ギフト・特殊ケース

1
AI: ギフト対応は必要ですか？
2
    もし対応するなら、期間限定か常時か、のしやメッセージカードは？

この質問がなければ、ギフト機能は完全に抜け落ちていました。実際に答えた内容は以下の通りです。

1
人間: ギフトは対応する。ただし3ヶ月・6ヶ月の期間限定ギフトのみ。
2
      常時ギフトは運用が複雑になるのでMVPでは除外。

「期間限定のみ」という判断は、AIの質問がなければ出てきませんでした。質問されて初めて「常時対応は運用が回らない」と明確に判断できました。

良いブレスト回答のコツ

AIとのブレストで精度の高い要件を引き出すには、回答の仕方にコツがあります。

1. 「やらないこと」を明示する

1
良い例: 「ギフトは3ヶ月・6ヶ月のみ。常時ギフトはMVPでは除外」
2
悪い例: 「ギフトは対応する」

「やること」だけ答えると、AIはスコープを広げる方向に進みます。「やらないこと」を明示すると、AIはその制約内で深掘りしてくれます。

2. 具体的な数字で答える

1
良い例: 「3コース、5テーマ、商品形態3種類」
2
悪い例: 「いくつかのコースとテーマを用意したい」

曖昧な回答にはAIも曖昧な深掘りしかできません。数字があれば「3コースの価格差は？」「5テーマの在庫偏りは？」と具体的な追加質問が出ます。

3. 判断の理由を添える

1
良い例: 「月1のサブスクリプション目標。MVPを早期リリースして検証したい」
2
悪い例: 「サブスクリプションを始めたい」

理由がわかると、AIは目的に沿った質問を組み立てられます。「月1目標なら、初回のハードルを下げる導線が重要ですね。お試しセットは検討していますか？」のように。

ブレストから要件定義書への接続

ブレストが一通り終わると、Claude Codeは対話内容を構造化した要件定義書にまとめます。ここがAIブレストの真価です。

1
ブレスト対話（非構造化）
2
  ↓ AIが整理
3
要件定義書（構造化）
4
  - 機能要件: サブスクリプション3コース、ギフト対応...
5
  - 非機能要件: Astro (SSG) + Google Cloud Storage...
6
  - ビジネス要件: MVP早期リリース、SEO資産の保全...
7
  - 除外事項: 常時ギフト、カスタムブレンド...

特筆すべきは、ブレスト中に話した「除外事項」が明示的にドキュメント化される点です。1人で仕様書を書くと「やること」しか書きません。「やらないこと」が書かれた仕様書は、後のスコープクリープを防ぎます。

さらに、ブレスト後に追加で「VPC（Value Proposition Canvas）の再検討」やGA4カートイベントのトラッキング要件も対話の中で出てきました。これらもブレストの成果として要件定義書に統合されました。

Spec-Driven Development：要件定義から実装までの5段階

ブレストで作った要件定義書は、5段階のSpec-Driven Developmentフローに接続します。

1
1. Requirements（要件定義）← ブレストの成果がここに入る
2
   ↓
3
2. Design（技術設計）
4
   ↓
5
3. Test Design（テスト設計）
6
   ↓
7
4. Task List（タスク分解）
8
   ↓
9
5. Implementation（実装）

各段階でAIが叩き台を作り、人間がレビューして承認します。承認なしに次の段階に進みません。ブレストは「段階1の入力を作る作業」です。ここが曖昧だと、後続の設計・テスト・実装がすべて手戻りになります。

AIが正しく引き出せたこと、見落としたこと

AIが引き出せたこと

ギフト機能の要否と制約: 質問されなければ完全に抜けていました
商品形態のバリエーション: ホール/グラウンド/ドリップバッグの3形態とその在庫管理への影響
MVPスコープの線引き: 「やらないこと」の明確化

AIが見落としたこと

既存サイトからのSEO移行の具体的手順: 301リダイレクトの設計、URL構造の互換性など、技術的な移行詳細はブレストでは出てきませんでした。後から人間側で追加しました
配送業者との連携仕様: 実際の物流オペレーションに関する質問は薄い傾向がありました。AIはソフトウェア設計には強いですが、物理世界との接点は弱いです
決済手段の具体的な選定: [要確認] 決済プロバイダの比較検討はブレスト段階では深掘りされませんでした

AIは「ソフトウェアとして何を作るか」の質問は得意ですが、「ビジネスオペレーションとしてどう回すか」の質問は手薄になる傾向があります。この偏りを知った上で使うことが重要です。

テンプレート：EC/サブスクリプションサービスの要件ブレスト質問リスト

自分の経験から、ECサイト・サブスクリプションサービスの要件定義で聞くべき質問をまとめました。

1
【ユーザー定義】
2
- メインターゲットは誰か（年齢層、リテラシー、購買頻度）
3
- 新規獲得とリピーター維持、どちらを優先するか
4

5
【商品・サービス設計】
6
- コース数と各コースの差別化ポイントは何か
7
- 商品のカテゴリ分類と属性はどう設計するか
8
- 配送頻度のバリエーションは必要か
9
- 商品形態（物理/デジタル）のバリエーションはあるか
10

11
【特殊ケース】
12
- ギフト対応は必要か。常時か期間限定か
13
- お試し/初回割引はあるか
14
- 解約・休止・スキップの導線はどうするか
15

10 collapsed lines
16
【技術要件】
17
- 技術スタック（SSG/SSR/SPA）
18
- ホスティングとストレージ
19
- 既存サイトからの移行要件（SEO、URL構造）
20
- アクセス解析・イベントトラッキング
21

22
【ビジネス要件】
23
- MVP vs フル機能、どこで線を引くか
24
- 初期の目標指標（サブスクリプション数、PV等）
25
- 既存資産（コンテンツ、SEO評価）の保全方針

まとめ

AIとのブレストで要件定義を行う際のポイントは3つです。

AIに質問させる: 自分で要件を列挙するのではなく、AIの質問に答える形で進めます。自分では思いつかない論点（ギフト対応、スコープの除外事項など）が引き出されます
回答は具体的に、「やらないこと」も明示する: 曖昧な回答は曖昧な要件を生みます。数字で答え、除外事項を明言することで、精度の高い要件定義書が作られます
ブレストの成果をSpec-Driven Developmentに接続する: ブレストで終わらせず、要件定義書→設計→テスト→タスクの5段階フローに乗せます。各段階で人間がレビューし、承認後に次へ進みます

AIは「ソフトウェア設計の質問」は得意ですが「ビジネスオペレーションの質問」は弱い傾向があります。この偏りを理解した上で、物流・決済・運用オペレーションについては人間側から補完する必要があります。