この記事の要点
- AIモック先行の要件定義とは、仕様書を書く前に、AIで動く画面モックを作り、それを見ながら依頼者と認識を合わせる進め方です。
- 文章の要件定義では「読んだ人ごとに違う絵が頭に浮かぶ」ためズレが残りますが、モックなら同じ画面を全員が見るので、ズレを実装前に表に出せます。
- ただし、モックは見た目の合意に強い反面、非機能要件や例外処理には弱いため、文章の仕様と併用する前提で使うのが現実的です。
要件定義で認識ズレが起きるのはなぜか
要件定義書を書いたのに、実装後に「思っていたのと違う」と言われた経験はないでしょうか。
原因は、文章が曖昧だからだけではありません。同じ文章を読んでも、人は自分の経験で空白を埋めます。たとえば「一覧画面で絞り込みできること」と書いたとします。
- 依頼者は、画面上部の検索ボックスを想像する
- デザイナーは、左側のフィルターパネルを想像する
- 実装者は、とりあえずプルダウンを置けばよいと考える
全員が「合意した」つもりで、頭の中の絵は三者三様です。しかも、この差は文章レビューではまず見つかりません。誰も間違ったことを書いていないからです。
文章の仕様が抱える3つの弱点
- 空白を読み手が勝手に補完する
- 画面遷移や状態の変化が、文字だと追いにくい
- 依頼者がレビューを流し読みしやすい（長い文書は読まれない）
3つ目は特に深刻です。長い仕様書に「問題ありません」と返した人が、動く画面を見たとたん修正点を10個挙げる。現場ではよくある光景です。
AIモック先行の要件定義とは
AIモック先行とは、要件を文章で固める前に、AIコーディングツールで動く画面のたたき台を作り、それを共通の「正解候補」として議論する方法です。
以前なら、モック作りはデザイナーの仕事でした。時間も手間もかかるので、要件が固まってから作るのが普通です。AIがここを数分から数十分に縮めたことで、順番を入れ替える意味が出てきました。つまり「モックは合意の結果」から「モックは合意の材料」に変わったわけです。
従来のやり方との比較
| 観点 | 文章先行 | モック先行 |
|---|---|---|
| 合意の材料 | 仕様書・議事録 | 触れる画面 |
| ズレが見つかる時期 | 実装中〜受け入れテスト | 初回レビュー |
| 依頼者の負担 | 長文を読む | 画面を触って指摘する |
| 非機能要件の扱い | 書きやすい | 別途文章が必要 |
| 手戻りコスト | 大きくなりやすい | 小さい（モックは捨てられる） |
| 向いている案件 | 基幹系・契約ありきの案件 | 業務ツール・新規サービス |
手順：AIモック先行で要件を固める5ステップ
ここでは、Claude Code のようなコーディングエージェントを使う想定で書きます（公式ドキュメント: https://docs.claude.com/en/docs/claude-code/overview）。他のツールでも考え方は同じです。
ステップ1：箇条書き1枚だけ用意する
仕様書は書きません。ヒアリングメモを、A4で1枚程度の箇条書きにまとめます。
- 誰が使うか（役割）
- 何を達成したいか（目的）
- 今困っていること（現状）
機能一覧は、この段階では不要です。機能を先に並べると、モックが「機能の展示」になってしまいます。
ステップ2：「作り捨て」と明示してモックを生成させる
最初の指示で、本番品質を求めないことを伝えます。次はプロンプトの一例です。
以下のメモから、画面モックを1つ作ってください。
- 目的: 営業担当が当日の訪問予定を確認し、結果を入力する
- 制約: バックエンドは不要。データはダミーをコード内に持つ
- 作り捨て前提。見た目と画面遷移の確認が目的
- 不明点は勝手に決めず、画面上の「要確認」バッジで示す
出力は単一の HTML ファイルにしてください。
ポイントは「不明点を要確認バッジで示させる」ことです。AIは空白を自然に埋めてしまうので、埋めた箇所を可視化させると、そこがそのまま質問リストになります。
ステップ3：依頼者に「触ってもらう」
画面共有で眺めるだけでは足りません。依頼者本人に操作してもらい、止まった場所、聞き返した場所を記録します。
- 「このボタンは何が起きるの？」と聞かれた箇所
- 想定外の順番で操作された箇所
- 「あ、そういえば」と別の要件が出た箇所
特に3つ目が価値の源泉です。文章では出てこなかった業務ルールが、画面を前にした瞬間に思い出されます。
ステップ4：指摘を差分としてAIに戻す
指摘は、チャットでそのまま追加指示にします。
次の指摘を反映してください。
1. 訪問結果は「受注・見送り・再訪」の3択にする
2. 見送りの場合のみ理由の入力欄を必須にする
3. 一覧は担当者別ではなく、日付別を初期表示にする
変更した箇所は一覧で報告してください。
この往復を数回回します。1往復が短いので、その場で直して再確認することも珍しくありません。
ステップ5：モックから文章の仕様を逆に起こす
認識が揃ったら、確定したモックを根拠に仕様を文章化します。画面ごとの項目、入力チェック、状態遷移を、モックを見ながら書き出します。
ここで初めて文章が登場します。順番が逆になっただけで、文章の精度はかなり上がるはずです。「書く前に答えが手元にある」状態だからです。
モックで見つかる認識ズレの典型例
参考記事と、一般的な開発現場の事例から、モックで表に出やすいズレを整理します。
- 用語のズレ：「顧客」が法人を指すのか個人を指すのか
- 粒度のズレ：1画面で済ませたい人と、ウィザード形式を想像した人
- 権限のズレ：誰が編集でき、誰が閲覧のみか
- 状態のズレ：「完了」の後に取り消せるのか
- 優先度のズレ：依頼者が本当に使うのは、実は2機能だけだった
用語や権限のズレは、文章でも書けるはずです。それでも漏れるのは、書く側が「当たり前」と思っているからです。画面にダミーデータを置くと、その当たり前が実際の数字や文字になって、違和感として現れます。
実際に整理してみた所感
参考記事を読み、同じ手順を自分の業務に置き換えて頭の中で追ってみました。いちばん効きそうだと感じたのは、ステップ2の「要確認バッジ」です。
私は普段、曖昧な箇所を質問リストにまとめて依頼者に送っています。しかし、リストは「質問を思いついた分」しか書けません。AIが勝手に補った箇所を機械的に洗い出す形なら、思いつかなかった質問まで拾えるはずだ、というのが読んだ時点での見立てです。この点は小規模な案件で実際に試して確かめたいところです。
デメリット・向いていない人・うまくいかないケース
便利な手法ですが、万能ではありません。次のようなケースでは、文章先行のほうが安全です。
向いていないケース
- 画面がほぼない案件：バッチ処理、データ連携、API設計が中心だと、見せるものがありません
- 非機能要件が主役の案件：性能、可用性、セキュリティはモックでは確認できません
- 契約上、仕様書が成果物になる案件：モックだけでは、後から「どこまでが範囲か」を示しにくくなります
- 法令・監査対応が重い領域：根拠を文章で残す必要があります
起こりやすい失敗
- モックが立派すぎて「もう完成している」と誤解される
- 見た目の議論ばかりが盛り上がり、業務ルールの確認が疎かになる
- AIが補った仕様が、確認されないまま確定してしまう
- モックのコードをそのまま本番に流用して、品質の負債を抱える
1つ目への対策は、最初から「作り捨てです」と口に出すことです。ダミーデータであることを画面上にも明記しておくと、さらに誤解されにくくなります。
向いていない人
「文章で論理的に詰めたい」タイプの依頼者には、モックが軽く見えることがあります。その場合は、モックと短い文章を並べて提示すると受け入れられやすくなります。
運用のコツ：モックを仕様の「正」にしない
モックと仕様書の両方があると、どちらが正しいのか迷う場面が出ます。決めておくべきルールは次の2点です。
- 合意後、正は仕様書とし、モックは参考資料に降格する
- モックのコードは、原則として本番に持ち込まない
アジャイルソフトウェア開発宣言にも「包括的なドキュメントよりも動くソフトウェアを」とありますが（https://agilemanifesto.org/iso/ja/manifesto.html）、これは文書を捨てる意味ではありません。右側（文書）にも価値があると明記されています。モックと文書は、役割分担で使うものです。
次に取る行動
まずは、手元の小さな案件を1つ選んでください。仕様書を書き始める前の30分を、モック生成と依頼者との操作確認に使います。
試したあとに確認したいのは、次の問いです。
- 文章だけなら、見つからなかったズレはいくつあったか
- 要確認バッジのうち、依頼者が即答できなかったものは何か
この2つの答えが、自分のチームでモック先行を標準にすべきかを判断する材料になります。
よくある質問
AIでモックを作るとき、どのツールを使えばよいですか？
コードを書いて動かせるAIコーディングツールなら、基本的にどれでも構いません。Claude Code のようなエージェント型ツールは、ファイル生成から修正まで一貫して依頼できます。単一のHTMLファイルで出力させると、共有も簡単です。
モック先行だと、要件定義書は不要になりますか？
不要にはなりません。モックでは非機能要件、例外処理、権限の細則などが伝わらないため、合意後にモックから仕様を文章に起こすのが基本です。文章を書く順番が変わるだけです。
非エンジニアの依頼者にもモックを触ってもらえますか？
単一のHTMLファイルなら、ブラウザで開くだけで触れます。画面共有で説明するより、本人が操作したほうが指摘の質は上がります。操作中の発言を記録しておくと、あとで要件に反映しやすくなります。
AIが作ったモックの内容が間違っていたらどうしますか？
間違いは、むしろ想定内です。モックの目的は正解を作ることではなく、ズレを見つけることだからです。AIに「不明点は要確認バッジで示す」と指示しておくと、誤った補完を見つけやすくなります。
モックのコードをそのまま本番に使ってもよいですか？
おすすめしません。モックはダミーデータ前提で、設計やテストも考慮されていないためです。画面構成や文言は参考にしつつ、本番実装は別に設計し直すほうが安全です。
モック先行が特に向いているのはどんな案件ですか？
画面を中心に使う業務ツールや、新規サービスの立ち上げが向いています。依頼者自身も要件を言語化できていない段階で、特に効果が出やすい手法です。反対に、バッチ処理やAPI中心の案件では、効果が限られます。
社内でモック先行を提案するとき、何から始めればよいですか？
小さな案件で1回だけ試し、ズレが見つかった件数を記録するのが現実的です。実績を示せば、チーム全体への提案が通りやすくなります。最初から標準プロセスに組み込もうとしないほうがうまくいきます。