要件定義をAIで整理する方法

Q: AIで整理した要件はどのフォーマットに落とし込むのが実用的ですか？

MoSCoW分析（Must/Should/Could/Won't）やユーザーストーリー形式が普及しています。開発チームとの合意がある形式に合わせて変換するようプロンプトで指示すると、そのまま使えるドラフトが出力されます。

結論

ユーザーインタビューや市場調査で集めた情報をAIに渡し、「機能要件・非機能要件への変換」「優先順位の叩き台作成」「ユーザーストーリー形式への変換」を順番に指示すれば、要件定義の初稿を数時間ではなく30〜60分で作れます。AIが出した内容を製品チームでレビューし修正する流れが、現時点で最も効率のよい使い方です。

使うAIツール

要件定義の整理には構造化された長文出力が求められるため、ClaudeまたはChatGPTの上位モデルが向いています。どちらも1万字を超える入力を処理できますが、入力データが社内情報や顧客情報を含む場合は、企業向けプラン（ChatGPT Enterprise、Claude for Work）でデータ学習オフ設定を確認してから使ってください。

Notionや Confluenceに要件書を書く文化がある場合は、Notion AIやAtlassian Intelligenceを組み合わせることで、整形からドキュメント保存までの工程を一本化できます。

手順

ステップ1：ユーザー課題を機能要件に変換する

ユーザーインタビューや調査から「課題・不満・ニーズ」が整理できている前提で始めます。整理できていない場合は先にユーザーインタビューをAIで分析する方法で課題抽出を行ってください。

以下はユーザーリサーチで抽出した「課題・ニーズ・ワークアラウンド」の一覧です。
これをもとに、機能要件の案を作成してください。

出力形式：
## 機能要件
- [機能名]: [機能の説明（1〜2文）]
  - 対応する課題: [元の課題の抜粋]

条件：
- ユーザーの発言に根拠のない機能は追加しない
- 1つの課題に対して複数の機能案が考えられる場合はすべて列挙する
- 実装の難易度は問わない（それは次のステップで扱う）

---
[課題・ニーズ一覧を貼る]
---

ステップ2：非機能要件を洗い出す

機能要件だけでは要件定義として不完全です。パフォーマンス・セキュリティ・アクセシビリティなどの非機能要件もAIに洗い出してもらいます。

以下は商品の機能要件の一覧です。
この製品が [製品ジャンル・対象ユーザー] 向けであることを踏まえ、
非機能要件として検討すべき項目を洗い出してください。

出力カテゴリ：
- パフォーマンス（応答時間・処理件数など）
- セキュリティ・プライバシー
- 可用性・信頼性
- 対応デバイス・ブラウザ
- アクセシビリティ
- その他（製品特性によって追加）

各項目に「なぜその要件が必要か」を1文で添付してください。

---
[機能要件の一覧を貼る]
---

非機能要件はプロダクトの種類によって大きく変わります。特に医療・金融・HR系のプロダクトではセキュリティ・コンプライアンス要件が業界規制と絡む場合があります。AIの出力は出発点として扱い、法的要件については必ず専門家に確認してください。

ステップ3：MoSCoW分析で優先順位の叩き台を作る

機能要件が揃ったら、MoSCoW分析（Must have / Should have / Could have / Won’t have）の形式で優先順位を仮置きします。

以下の機能要件一覧を、MoSCoW分析のフレームワークで分類してください。

分類基準：
- Must have: これがなければ製品としての価値を提供できない
- Should have: あると大幅に価値が高まるが、初期リリースは工夫次第で回避可能
- Could have: あるとよいが、なくてもコアなユーザー価値は損なわれない
- Won't have: 今回のスコープでは対応しない

各項目の分類理由を1文で記載してください。
ただし、これはあくまで仮の分類です。最終判断は製品チームが行うことを前提に出力してください。

---
[機能要件の一覧を貼る]
---

AIはユーザーデータに基づかない推測で「Must have」を判断することがあります。出力されたMoSCoW分析は必ず製品オーナーとエンジニアリードで確認し、実装コスト・事業優先度を加味して修正してください。

ステップ4：ユーザーストーリー形式に変換する

開発チームへの受け渡しにユーザーストーリー形式を使っている場合は、変換もAIに任せられます。

以下の機能要件を、ユーザーストーリー形式に変換してください。

フォーマット：
「[ユーザー属性] として、[目的・ゴール] のために、[機能・手段] を使いたい。」

各ストーリーに以下を追加してください：
- 受け入れ条件（Acceptance Criteria）: 3〜5箇条
- 対応する元の機能要件名

---
[機能要件の一覧（MoSCoW分類済み）を貼る]
---

具体例1：タスク管理ツールの新機能要件定義

ある企業の商品企画担当者が、既存のタスク管理ツールに「チーム進捗のサマリー表示機能」を追加するかどうか検討したケースです。

5名へのインタビューから抽出した課題が12件ありました。ステップ1のプロンプトで機能要件を出力したところ、17件の機能案が上がりました。そのうち「週次サマリーメール」「ダッシュボードへのグラフ追加」「チームごとの進捗率の数値表示」の3点が複数インタビューの課題に対応する機能として浮かび上がり、他の14件はエッジケースとして候補から外れました。

機能を17件から3件に絞り込む判断自体はAIではなく担当者が行いましたが、絞り込むための情報整理にかかった時間が半日から1時間程度に短縮されました。

具体例2：ECサイトのチェックアウト改善での活用

ECサイトのカート離脱率が高い問題について、ユーザーテストとアンケートから課題を収集し、要件定義に落とし込んだ事例です。

課題が23件あり、そのうち「決済情報の入力ステップが多い」「在庫状況の表示タイミングが遅い」の2点が高頻度で出現していました。ステップ2の非機能要件洗い出しでは、決済処理のPCI DSS対応がAIから指摘されました。担当者がその観点を見落としていたため、法務・セキュリティチームへの確認を早い段階で行えたと言っています。

ただし、PCI DSSの具体的な要件解釈についてはAIの出力を参照せず、セキュリティ担当者に直接確認したとのことで、AIを「論点を出す道具」として使い、判断は人間が行う使い方が適切です。

うまくいかない場合

機能要件が抽象的すぎて使えない

「ユーザーが使いやすいUIを提供する」のような曖昧な要件が出てくる場合は、プロンプトに「機能要件は、ユーザーが何を操作でき、システムがどう応答するかを具体的に書いてください。UIの定性的な評価は含めない」と追記します。

競合製品の機能をそのまま列挙する

AIが競合他社の機能をリサーチデータなしに混ぜ込むことがあります。プロンプトに「入力データ以外の情報源から機能を追加しない」と明記し、出力後に「このデータに根拠があるか」を確認する習慣をつけてください。

ユーザーストーリーの受け入れ条件が測定できない

「スムーズに動作する」のような測定不可能な受け入れ条件が出る場合は、「受け入れ条件は数値または動作の有無で測定できる形で書くこと（例：3秒以内に表示される、エラーなく送信できる）」と指示を加えます。

整形後の使い方

作成した要件定義の初稿は、ロードマップに落とし込む作業に進みます。プロダクトロードマップをAIで整理する方法では、要件の優先順位とタイムラインの整合をAIで行う手順を説明しています。

競合製品との機能差分を要件に反映する場合は競合機能比較をAIで作る方法も参照してください。

FAQ

Q. 要件定義にAIを使うと何が変わりますか？

ユーザーインタビューや競合調査の情報を整理する時間が短縮されます。ただしAIは製品判断を代替しません。要件の優先順位や実現可否は必ず人間が決定してください。

Q. AIが出した要件をそのまま開発チームに渡してよいですか？

そのまま渡すのは推奨しません。AIの出力はたたき台です。製品オーナーとエンジニアが内容を確認し、技術的な実現可能性と事業優先度を加えてから渡してください。

Q. 要件定義に使うデータに個人情報が含まれる場合はどうすればよいですか？

ユーザー名や連絡先など個人を特定できる情報はAIに入力する前に匿名化してください。企業の機密情報についてはサービスの学習利用設定を確認し、必要であれば企業契約版を使ってください。

Q. AIで整理した要件はどのフォーマットに落とし込むのが実用的ですか？

MoSCoW分析やユーザーストーリー形式が普及しています。開発チームとの合意がある形式に合わせて変換するようプロンプトで指示すると、そのまま使えるドラフトが出力されます。