「言った/言わない」を防ぐ発注術：AIで画面案とデータ例を先に見せる認識合わせの実践法

システム発注で「イメージと違う」が起きるのは、言葉だけで要望を伝えるから。本記事は、AIで画面案・操作例・データ例を先に作り、開発前に認識をそろえる手順と、合意を証拠として残す方法を、非エンジニアの発注者・PM向けに解説します。

この記事の結論

• 言葉だけの要望伝達は解釈のズレを生み、手戻り・追加費用の主因になる
• AIを使えば発注者側でも「画面案・操作の流れ・データ例」を短時間で用意できる
• 具体物を見せた認識合わせは、抽象的な議論より数倍速く合意に至る（筆者の実感。効果は状況による）
• 合意内容は「画面案＋確定日＋変更理由」をセットで残すと後の紛争を防げる
• まずは1画面だけ画面案を作り、レビューで反応を確かめるのが最短の第一歩

この記事が役立つ人

システム開発を外部ベンダーや社内エンジニアに依頼する立場の方が対象です。以下に当てはまるなら効果があります。

• 要件定義や仕様のすり合わせで「認識のズレ」に悩んでいる
• 自分では画面設計やコードは書けないが、要望は明確にしたい
• 過去に「言った/言わない」で揉めた経験がある

前提知識は不要です。ChatGPTやClaudeなどの生成AI（文章や画像を作るAI）を、無料〜低額プランで触れる環境があれば始められます。

なぜ「言葉だけの発注」でズレが起きるのか

言葉は抽象的で、受け手の経験によって解釈が変わります。「使いやすい一覧画面」と伝えても、発注者は「検索付き」を想像し、開発者は「並び替え付き」を作る、といったズレが生まれます。

言葉の危険性は「省略」にあります。 発注者は自分の頭の中では完成イメージがあるため、当たり前だと思う条件を言い忘れます。開発者はその空白を自分の常識で埋めるため、両者の常識が違うほどズレが拡大します。

> 💡 筆者の経験（事例）：ある業務システムで「承認機能をつけて」とだけ伝えた結果、1段階承認で作られました。実際は3段階必要で、後から作り直しに2週間かかりました。「承認者は誰が何人か」を最初に図で示していれば防げた事例です。

図: 言葉だけの伝達では「発注者のイメージ」と「開発者の解釈」の間に隙間が生まれ、その隙間が手戻りとして顕在化する構図。具体物（画面案）を挟むと隙間が縮小する。

解決するための5つのポイント

1. 画面案を「絵」で見せて解釈の幅を消す

結論：文章より1枚の画面案のほうが、認識のズレを桁違いに減らせます。人は具体的な絵があると「ここは違う」と指摘しやすくなるためです。

具体例：「顧客一覧画面」なら、検索欄・列項目・ボタン配置を含んだ簡単なワイヤーフレーム（線画レベルの画面案）を用意します。AIに指示すればHTMLやSVGで叩き台を出せます。

実践方法：後述のプロンプトで、まず1画面だけ作り、ベンダーに「これで合っていますか」と確認します。

2. 操作の流れを「ステップ」で見せて抜け漏れを防ぐ

結論：画面単体でなく「操作の順番」を示すと、画面間の遷移漏れを発見できます。

具体例：「注文→在庫確認→承認→出荷指示」のように、誰が何をするかを矢印でつなぎます。Mermaid（テキストで図を描く記法）を使えば発注者でも書けます。

実践方法：フロー図をレビューで共有し、「この分岐（例：在庫がない場合）はどうなる？」を全員で埋めます。

3. データ例（サンプル）を見せて項目の過不足を洗い出す

結論：実際のデータ例を見せると、「この項目が足りない」が具体的に見えます。

具体例：顧客データなら「氏名・電話・登録日」だけでなく、実際の値（山田太郎／090-xxxx／2024-01-15）を数行分用意します。空欄や異常値の扱いも議論できます。

実践方法：AIにサンプルデータをCSVで生成させ、「この形式で保存されます」とベンダーと合意します。

4. 「やらないこと」を明記して範囲を固める

結論：作る機能だけでなく「今回は作らない機能」を書くと、範囲の膨張（スコープクリープ）を防げます。

具体例：「今回は検索機能まで。CSVエクスポートは次フェーズ」と明記します。曖昧なままだと「当然入ると思った」で揉めます。

実践方法：合意ドキュメントに「対象外」欄を必ず設けます。

5. 合意した内容に「日付」と「変更理由」を残す

結論：合意は口頭でなく、画面案・確定日・変更理由をセットで文書化します。これが「言った/言わない」への最大の防御です。

具体例：「顧客一覧の初期表示件数：20件（2024-06-01確定）／50件から変更、表示速度優先のため」という粒度で残します。

実践方法：後述のテンプレートを議事録の末尾に貼り付けて運用します。

そのまま使えるAIプロンプト（画面案・操作例・データ例の生成）

以下をコピーし、〈〉部分を自分の案件に置き換えてAI（ChatGPT/Claude等）に貼り付けてください。

```text

用途: システム発注前の認識合わせ資料をAIに作らせる指示

あなたはUI設計とデータ設計の補助をするアシスタントです。

非エンジニアの発注者にも分かる形で、以下3点を作ってください。

【対象システム】〈例：顧客管理システムの顧客一覧画面〉

【利用者】〈例：営業担当者、1日30回程度利用〉

【実現したいこと】〈例：顧客を素早く検索し、詳細を確認したい〉

出力1（画面案）:

• 単一のHTMLファイルで、指定画面のワイヤーフレームを作成
• 検索欄・一覧の列項目・主要ボタンを含める
• 装飾より構造を優先し、コメントで各要素の意図を書く

出力2（操作フロー）:

• Mermaid記法で、利用者の操作手順を図示
• 「例外時（該当なし等）」の分岐も含める

出力3（データ例）:

• 一覧に表示するサンプルデータを5行、CSV形式で
• 列名と、現実的なダミー値を含める
• 空欄・異常値の扱い方針もコメントで補足

不明な前提は勝手に決めず、確認質問を最後に3つ挙げてください。

```

最後の「確認質問」を出させるのがコツです。AIが仮定した点＝あなたが伝え忘れていた点なので、そのままベンダーへの確認事項になります。

そのまま使える操作フロー図（Mermaid）

レビュー用のたたき台です。矢印と条件を書き換えて使ってください。

```mermaid

flowchart TD

A[営業が顧客一覧を開く] --> B[検索条件を入力]

B --> C{該当あり?}

C -->|あり| D[一覧に表示]

C -->|なし| E[「該当なし」を表示]

D --> F[顧客をクリック]

F --> G[詳細画面へ遷移]

E --> B

```

そのまま使える合意記録テンプレート

議事録の末尾に貼り、確定した項目だけ埋めます。

```markdown

認識合わせ 合意記録

| 項目 | 合意内容 | 確定日 | 変更理由/備考 |

|------|----------|--------|----------------|

| 〈顧客一覧の初期件数〉 | 〈20件〉 | 〈2024-06-01〉 | 〈50→20、速度優先〉 |

| 〈検索対象項目〉 | 〈氏名・電話〉 | 〈2024-06-01〉 | 〈住所検索は次フェーズ〉 |

今回の対象外（作らないこと）

• 〈CSVエクスポート機能〉
• 〈スマホ専用画面〉

添付

• 画面案: 〈ファイル名/URL〉
• 操作フロー図: 〈ファイル名/URL〉
• データ例: 〈ファイル名/URL〉

```

AIやツールで自動化する方法

毎回手作業でなく、仕組みにすると発注のたびに再利用できます。特定製品に依存しない方法を挙げます。

| やりたいこと | 使えるツール例 | 効果 |

|--------------|----------------|------|

| 画面案を対話で作る | ChatGPT / Claude | 文章の要望をHTML画面案に変換 |

| 画面案をブラウザで確認 | Claude（Artifacts）等 | コード不要でその場で表示 |

| フロー図を管理 | Mermaid対応のメモツール | テキストで図を版管理 |

| 合意記録の蓄積 | Notion / スプレッドシート | 案件横断で検索・再利用 |

> ⚠️ 注意：AIが生成した画面案やデータ例は「たたき台」です。そのまま本番仕様にせず、必ず人の目でレビューしてください。AIは前提を勝手に補完するため、事実確認が前提です。

エンジニアがいる場合は、確定した画面案HTMLをGitで管理し、変更履歴を残すとさらに強固になります（この運用の要否はチーム規模による）。

実践チェックリスト

• [ ] 主要画面の「画面案（絵）」を最低1枚用意した
• [ ] 利用者の「操作フロー」を分岐込みで図示した
• [ ] 実際の値を含む「データ例」を数行作った
• [ ] 「今回作らないこと（対象外）」を明記した
• [ ] AIの「確認質問」をベンダーへの確認事項に反映した
• [ ] 合意内容を「日付＋変更理由」付きで文書化した
• [ ] 画面案・フロー・データ例を合意記録に添付した

まとめ

言葉だけの発注はズレを前提とした伝達です。AIで画面案・操作例・データ例という「具体物」を先に作り、それを見ながら認識を合わせることで手戻りを大きく減らせます。合意は日付と理由をセットで残すことが最大の防御になります。

最初の一歩：一番重要な1画面だけ、本記事のプロンプトで画面案を作り、次回のレビューに持ち込んでください。反応の速さで効果を実感できるはずです。

次に読む記事

• 基礎：非エンジニアのための要件定義入門 ― 「要望」と「仕様」の違いを理解する
• 実践：ワイヤーフレームの書き方 ― AIに画面案を正しく作らせる指示のコツ
• 発展：ベンダーとの契約・スコープ管理 ― 変更要求を追加費用トラブルにしないための取り決め方

よくある質問

Q. 絵心もコードの知識もありませんが、画面案を作れますか？

A. 作れます。本記事のプロンプトをAIに貼れば、AIがHTMLの画面案を生成します。あなたの役割は「これで合っているか」を判断することで、ゼロから描く必要はありません。

Q. AIが作った画面案をそのままベンダーに渡してよいですか？

A. たたき台としてなら有効ですが、確定仕様として渡すのは避けてください。AIは不明点を勝手に補完するため、必ず「AIが出した確認質問」を潰し、人の合意を経てから共有します。

Q. 合意記録はどこまで細かく残すべきですか？

A. 「後で解釈が割れそうな数値・条件」を優先します。全項目を網羅する必要はなく、件数・対象範囲・例外時の挙動など、揉めやすい点に絞ると運用が続きます。