曖昧なアイデアを要件に変えるAI壁打ちテンプレート
連載：AI時代のSE・プログラマのためのAI壁打ち実践入門
全5回 ｜ 第2回 / 5この連載は、AIを「答えを出す機械」ではなく、「前提を掘り、選択肢を増やし、判断を検証する相棒」として使うための実践シリーズです。
はじめに
作りたいものはある。
しかし、仕様に落とそうとすると手が止まる。
こんな経験はありませんか？
個人開発でも業務でも、「やりたいこと」はあるのに、それを「何を作るか」「何を作らないか」に分解できない場面は多いです。AIに企画書を渡しても、それっぽい文章は返ってくるが、実際に開発を始められるレベルの仕様にはなっていない。
前回の記事では、AI壁打ちの基本として G-C-C-J-R（目的・背景・制約・判断基準・役割）の5要素を紹介しました。今回は、この考え方を要件定義に適用します。
この記事で扱うこと
- 要件定義でAIに「答え」を出させると失敗する理由
- AIに未確定事項・矛盾・確認質問を出させる壁打ちの型
- コピペで使える要件定義壁打ちテンプレート
- 壁打ちの実例（「個人用AIタスク管理ツール」を題材に）
- 受け入れ条件（Given-When-Then）の作り方
結論
先に結論を書きます。
要件定義の壁打ちでは、AIに完成版の仕様書をいきなり作らせるより、以下を出させる方が価値が高いです。
| AIに出させるもの | 効果 |
|---|---|
| 不明点 | 自分が気づいていない曖昧さが見える |
| 矛盾 | 前提同士の食い違いが見える |
| 確認質問 | 次に決めるべきことが見える |
| 対象外の候補 | スコープの膨張を防げる |
| 受け入れ条件 | 「完成」の判断基準ができる |
つまり、AIは「仕様書を書く相手」ではなく、「仕様を固める前に穴を見つける相手」として使います。
よくある失敗例
要件定義でAIを使おうとして、以下のような聞き方をしてしまうことがあります。
悪い例
タスク管理アプリの仕様書を作ってください。
この聞き方だと、AIは以下のような「それっぽい」仕様書を返します。
- ユーザー登録機能
- タスクのCRUD
- カテゴリ分類
- リマインダー通知
- ダッシュボード
一見よさそうに見えますが、以下の問題があります。
- 誰のためのタスク管理アプリなのか決まっていない
- どこまで作るのか（MVP or フル機能）が不明
- 自分の制約（技術・時間・予算）が反映されていない
- AIが勝手に機能を増やし、スコープが膨張する
この結果、「仕様書はできたが、開発を始められない」という状態に陥ります。
要件定義の壁打ちで有効な3つの型
要件定義の壁打ちでは、AIの使い方を以下の3つの型に分けると安定します。
型①：課題分解型
アイデアの段階で「何を決めるべきか」を洗い出すための型です。
以下のアイデアを要件定義に落とし込むための壁打ちをしてください。
アイデア：
{アイデア}
背景：
{なぜ作りたいか}
いきなり仕様書を作らず、まず以下を出してください。
1. 不明点（こちらが決めていないこと）
2. 矛盾しそうな点
3. 決めるべきこと（優先度付き）
4. 想定ユーザー候補
5. 成功条件（何ができたら成功か）
6. 対象外にした方がよいこと
ポイントは、「まず仕様書を作らず」と明示することです。この一文がないと、AIはいきなり機能一覧を作り始めます。
型②：確認質問生成型
自分では気づかない「聞くべき質問」をAIに出させる型です。
以下の開発企画について、要件を固めるために私が確認すべき質問を
20個出してください。
企画概要：
{企画の概要}
前提：
{決まっていること}
質問は以下のカテゴリに分けてください。
- ユーザーに関する質問
- 機能に関する質問
- 技術に関する質問
- 運用に関する質問
- スコープに関する質問
この型は、「何を聞けばいいかわからない」という段階で特に有効です。AIが出した質問に自分で答えていくだけで、要件が整理されていきます。
型③：受け入れ条件型
要件が固まってきた段階で、「完成の判断基準」を作るための型です。
以下の要件について、受け入れ条件をGiven-When-Then形式で
作ってください。
要件：
{要件}
出力形式：
- Given（前提）：〜の状態で
- When（操作）：〜したとき
- Then（期待結果）：〜になること
受け入れ条件があると、開発中に「これは作るべきか？」と迷ったとき、判断基準になります。
要件定義壁打ちテンプレート
以下のテンプレートをコピーして使ってみてください。前回のG-C-C-J-Rを要件定義向けにアレンジしたものです。
以下のアイデアを要件定義に落とし込むため、壁打ちしてください。
アイデア：
- {作りたいもの}
背景：
- {なぜ作りたいか}
想定ユーザー：
- {誰が使うか}
制約：
- {技術スタック、開発期間、予算、人数}
現状の仮案：
- {自分なりの機能案があれば}
まず、以下を表で出してください。
| 項目 | 内容 | 確認質問 |
|---|---|---|
| 目的 | | |
| 利用者 | | |
| 利用シーン | | |
| 入力 | | |
| 出力 | | |
| 機能要件 | | |
| 非機能要件 | | |
| 対象外 | | |
| 成功条件 | | |
| リスク | | |
その後、以下を追加で出してください。
1. 私の仮案に対する指摘（抜け漏れ・矛盾）
2. 最初に作るべき最小構成（MVP）の提案
3. 後回しにしてよい機能の候補
壁打ちの実例：「個人用AIタスク管理ツール」
実際にテンプレートを使って壁打ちをしてみます。
壁打ちの入力
以下のアイデアを要件定義に落とし込むため、壁打ちしてください。
アイデア：
- AIエージェントが実行中のタスクを人間が確認・承認できるツール
背景：
- 個人開発でAIエージェントを複数動かしているが、何が進行中か把握しにくい
- 承認が必要なタスクを見逃すことがある
想定ユーザー：
- 自分（個人開発者）
制約：
- Python + FastAPI で構築
- 開発期間は2週間
- 1人で開発
- 外部サービスへの依存は最小限
現状の仮案：
- タスク一覧画面
- タスクのステータス表示（進行中/承認待ち/完了）
- 承認ボタン
まず、以下の表を埋めてください。
その後、仮案への指摘とMVP提案をお願いします。
AIの回答（要約）
🤖 AI（壁打ち相手）:
要件整理表：
項目 内容 確認質問 目的 AIエージェントの進捗把握と承認 「把握」と「承認」のどちらが優先？ 利用者 個人（自分のみ） 将来的に複数人で使う予定は？ 利用シーン 開発中に複数エージェントの状態を確認 1日に何回確認するか？通知は必要？ 入力 エージェントからのタスク登録 どうやってタスクを登録する？API? 出力 タスク一覧、ステータス、承認結果 ログは残す？後から振り返る？ 機能要件 一覧表示、ステータス管理、承認操作 フィルタ・検索は必要？ 非機能要件 レスポンス速度、データ保持期間 同時に何タスクまで想定？ 対象外 マルチユーザー、通知、モバイル対応 本当に通知不要？見逃しが課題では？ 成功条件 承認待ちタスクを見逃さなくなる 具体的に「ゼロにする」？「減らす」？ リスク 2週間では機能を絞り切れない恐れ MVPの範囲を先に決めるべき 仮案への指摘：
- 「タスクの登録方法」が未定義 — APIで受け取るなら、エージェント側の実装も必要
- 「見逃し」が課題なのに通知機能を対象外にしている — 簡易的な通知（ブラウザ通知やSlack連携）は検討すべき
- ログを残すかどうかが未定 — 承認判断の根拠を後から確認できないと、監査性が弱い
MVP提案：
- ✅ タスク一覧（API経由で登録、ブラウザで表示）
- ✅ ステータス管理（進行中/承認待ち/完了）
- ✅ 承認ボタン + 承認ログ保存
- ❌ 通知、フィルタ、検索、マルチユーザーは次フェーズ
この壁打ちから得られた気づき
- 「対象外」の妥当性を問い直せた：見逃しが課題なのに通知を外していた矛盾に気づいた
- 入力経路の欠落：「タスク一覧を表示する」は考えたが、「タスクをどう登録するか」が抜けていた
- 成功条件の具体化：「見逃さない」だけでは曖昧で、計測可能な基準が必要だとわかった
- MVPの線引き：2週間で何を作り、何を後回しにするかが整理できた
壁打ちで仕様書は完成しません。しかし、仕様を固めるために確認すべきことの一覧が手に入ります。
受け入れ条件の作り方
要件が整理できたら、受け入れ条件を作ります。受け入れ条件とは、「この機能が完成した」と判断するための基準です。
Given-When-Thenテンプレート
以下の要件について、受け入れ条件をGiven-When-Then形式で
作ってください。
要件：AIエージェントが登録したタスクを一覧表示し、
承認待ちのタスクを承認できる。
AIの回答例
受け入れ条件：
ケース1：タスク一覧表示
- Given：エージェントが3件のタスクを登録済みの状態で
- When：ブラウザでタスク一覧画面を開いたとき
- Then：3件のタスクがステータス付きで表示されること
ケース2：承認操作
- Given：ステータスが「承認待ち」のタスクがある状態で
- When：承認ボタンを押したとき
- Then：ステータスが「完了」に変わり、承認ログが記録されること
ケース3：登録なし
- Given：タスクが0件の状態で
- When：タスク一覧画面を開いたとき
- Then：「タスクはありません」と表示されること
受け入れ条件があると、開発中に「この機能はどこまで作ればよいか」が明確になります。テストケースの元にもなるため、実装前に作っておくと手戻りが減ります。
実務投入時の注意点
要件定義の壁打ちを実務で使う際には、以下の点に注意してください。
- AIの仕様提案を鵜呑みにしない: AIが「この機能が必要です」と言っても、本当に必要かはユーザーやステークホルダーに確認する必要がある。AIは一般的なパターンを提案するが、個別の業務事情は知らない。
- ステークホルダーへの確認は人間が行う: AIが出した確認質問は有用だが、それを誰に聞くか、どう聞くかは人間の仕事。特に社内システムの場合、実際のユーザーに確認することが重要。
- 機密情報を入れない: 実在のプロジェクト名、顧客名、社内の業務フローをそのままAIに渡さない。架空の例に置き換えてから壁打ちする。
- 要件定義はイテレーション: 1回の壁打ちで全てが決まることはない。壁打ちの結果を持ち帰り、検討し、また壁打ちする。このサイクルを2〜3回繰り返すと、要件の精度が上がる。
チェックリスト
要件定義の壁打ちを始める前に、以下を確認してみてください。
- 作りたいもののアイデアを1文で書けるか
- 誰のためのものかを書いたか
- なぜ作りたいかの背景を書いたか
- 技術・期間・予算の制約を書いたか
- 自分なりの仮案を書いたか（なくてもOK）
- AIに「いきなり仕様書を作らず、不明点を出して」と伝えたか
- 成功条件を考えたか（何ができたら完成か）
まとめ
要件定義の壁打ちは、AIに仕様書を書かせる作業ではありません。AIは、自分が見落としている不明点・矛盾・確認質問を出してくれる相手として使います。
今回の記事で紹介した内容を振り返ります。
- AIに仕様書を丸投げすると失敗する — スコープが膨張し、開発を始められない
- 3つの型（課題分解型・確認質問生成型・受け入れ条件型）で壁打ちが安定する
- テンプレートを使えば、誰でも要件定義の壁打ちを始められる
- 受け入れ条件を先に作ると、開発の判断基準ができる
次回は、要件が固まった後の「設計」フェーズで、AIとどう壁打ちするかを扱います。
次回予告
次回は、実装前にAIと設計レビューするための壁打ち手順を扱います。
「とりあえず実装して後で破綻する」「設計案の比較が苦手」「なぜその設計にしたのか記録が残らない」という悩みに対して、AIとの壁打ちで設計案の比較・トレードオフ整理・ADR化を行う方法を紹介します。
この記事では、AIの回答をそのまま正解として扱うことは推奨しません。
実務利用時は、機密情報を入れないこと、出力を検証すること、必要に応じて人間が判断することを前提にしています。
連載一覧
- AIとの壁打ちは「質問」ではなく「思考プロセス設計」である
- 曖昧なアイデアを要件に変えるAI壁打ちテンプレート ← 今回
- 実装前にAIと設計レビューするための壁打ち手順
- AIに丸投げしないコードレビュー・デバッグ壁打ち術
- AIとの壁打ちログをナレッジ化してポートフォリオに変える