企画書で悩む前に「動く試作品」で反応を得る：非エンジニアが失敗を減らす検証法

企画会議が「たぶん売れる/売れない」の水掛け論で止まっていませんか。本記事は、AIで画面や簡易機能を素早く作り、顧客や社内から本音の反応を引き出す進め方を解説します。何を確認し、どこで作り込みを止めるかの判断基準も示します。

この記事の結論

企画書の議論は「言葉の解釈違い」で空転しやすい。動く試作品（プロトタイプ）が判断を速める。
AIツールを使えば非エンジニアでも数時間〜数日で画面や簡易機能を作れる。
試作品で確認すべきは「顧客が本当に欲しがるか」「使いこなせるか」の2点に絞る。
作り込みすぎは最大のムダ。検証したい問いに答えられたら止めるのが原則。
反応データ（クリック・離脱・生の声）を記録し、次の意思決定に使う。

この記事が役立つ人

新規事業の企画が会議で止まりがちな経営者・事業責任者
「作る前に売れるか確かめたい」新規事業・DX担当者
エンジニアに依頼する前段階で仮説を検証したい人

前提知識は不要です。プログラミング経験がなくても、AIツールに指示を出せれば実践できます。

なぜこの問題が起きるのか（背景と原因）

企画書は文章と図で作られますが、読み手ごとに「良い画面」「便利な機能」の解釈が異なります。この解釈のズレが、会議での空転を生みます。

さらに人は、実物を見ないと的確な意見を言えません。「便利そう」という抽象的な感想は当てになりにくく、触れる試作品があって初めて「ここが使いにくい」という具体的な反応が出ます。

💡 筆者の見解：企画書の完成度を上げる時間より、粗くても動くものを見せる時間のほうが、意思決定の質を高めます。議論の材料が「想像」から「体験」に変わるためです。

従来は試作品を作るのにエンジニアと数週間が必要でした。しかしAIの登場で、非エンジニアが短時間で画面や簡易機能を作れるようになり、この壁が下がっています。

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

1. 検証したい「問い」を1つに絞ってから作り始める

結論：試作品は「何を確かめたいか」が決まって初めて意味を持ちます。

例えば「中小企業の経理担当は、領収書をスマホ撮影するUIを使いこなせるか？」のように、一文で言い切れる問いを立てます。問いが曖昧だと、作ったものから何も学べません。

実践方法：作業前に「この試作品で〈確かめたいこと〉が分かる」と紙に書く。答えられないなら作らない。

2. 見た目だけの「画面モック」から始める

結論：多くの仮説は、機能が動かなくても画面だけで検証できます。

例：申込フォームの画面だけを見せ、「これなら使いますか」と聞く。実際にデータが保存されなくても、顧客の反応は取れます。画面モック（見た目だけの試作画面）は最速で作れます。

実践方法：AIに「〈サービス名〉の申込画面をHTMLで作って」と指示し、そのまま人に見せる。

3. 本当に必要な機能だけ「1つ」動かす

結論：全機能ではなく、価値の中心となる1機能だけを動かします。

例：AI議事録サービスなら「音声から要約が出る」部分だけ動けば十分。ログイン機能や課金画面は後回しにします。

⚠️ 注意：「一応これも」と機能を足すほど、検証の焦点がぼやけ、時間も溶けます。

4. 反応を「数字」と「生の声」の両方で記録する

結論：印象ではなく記録に基づいて判断します。

記録する項目	取り方の例	分かること
クリック率	ボタンが押された割合	関心の強さ
離脱ポイント	どこで操作をやめたか	つまずく箇所
生の声	使用中の発言をメモ	感情・違和感
支払い意思	「いくらなら払う？」	事業性

実践方法：見せる相手ごとに上記をメモ。5〜10人で傾向が見えます。

5. 「作り込みすぎ」を止める判断基準を持つ

結論：検証の問いに答えが出たら、それ以上は作らないと決めます。

図: 作り込み判断フロー

flowchart TD
    A[試作品を見せた] --> B{問いに<br/>答えは出たか}
    B -- 出た --> C[作り込み停止<br/>次の意思決定へ]
    B -- 出ない --> D{原因は試作品の<br/>粗さか}
    D -- 粗さが原因 --> E[必要最小限だけ改善]
    D -- 仮説が曖昧 --> F[問いを立て直す]
    E --> A
    F --> A

💡 判断の目安：「この機能を足すと、どの問いに答えられるか」を即答できないなら、その作り込みは不要です。

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

非エンジニアでも使える代表的な方法を挙げます。特定ツールが唯一の正解ではなく、手元にあるもので構いません。

Claude / ChatGPT：画面のHTMLや文章を生成。コピペでブラウザ表示可能。
Cursor / Claude Code：指示文だけで動くWebページや簡易機能を生成（エンジニア向けだが非エンジニアも入門可能）。
ノーコードツール：ドラッグ操作でフォームや画面を構築。

以下は、AIに試作品用の画面を作らせるプロンプトです。〈〉を自分の事業に置き換えてください。

# 用途: 新規事業の画面モックをAIに生成させるプロンプト
あなたはUIデザイナー兼フロントエンド開発者です。
以下の条件で、単一のHTMLファイル（CSS内蔵、外部依存なし）を作成してください。

## サービス概要
- サービス名: 〈AI議事録メーカー〉
- 対象ユーザー: 〈中小企業の管理職〉
- 中心となる価値: 〈会議音声から要約と決定事項を自動抽出〉

## 作ってほしい画面
1. トップ画面（サービスの価値が一目で伝わるキャッチと申込ボタン）
2. 〈要約結果を表示する〉画面（サンプルデータを入れて動きが分かる状態に）

## 条件
- スマホ表示に対応
- ダミーデータで実際の使用イメージが伝わるようにする
- ボタンを押したら次の画面に切り替わる程度の簡単な動きを付ける
- 専門用語のラベルには短い補足を付ける

出力はHTMLコードのみ。ファイルとして保存すればブラウザで開ける状態にすること。

生成されたコードを 〈ファイル名〉.html として保存し、ダブルクリックで開けば試作品として人に見せられます。

📌 事例（筆者観測の一般例）：ある新規事業チームは、申込画面モックを5人の見込み顧客に見せ、「価格表示がないと不安」という共通の声を得ました。企画書段階では出なかった指摘で、方向修正に役立ったといいます。

実践チェックリスト

この試作品で確かめたい「問い」を一文で書いた
まず画面モックだけで検証できないか検討した
動かす機能を「価値の中心となる1つ」に絞った
見せる相手を5〜10人リストアップした
クリック率・離脱・生の声・支払い意思を記録する準備をした
「答えが出たら止める」基準をチームで共有した
AIプロンプトの〈〉を自社事業に置き換えた

まとめ

企画書での議論が空転する原因は「解釈のズレ」です。AIで粗くても動く試作品を作れば、想像ではなく体験に基づく反応が得られます。

最初に着手する行動：確かめたい問いを一文で書き、上記プロンプトで画面モックを1枚作る。それを社内の1人に見せるところから始めてください。作り込みは、答えが出たら止めるのが鉄則です。

次に読む記事

基礎：ノーコードツールの選び方入門 — プログラミング不要で試作品を作る第一歩
実践：見込み顧客インタビューの質問設計 — 試作品から本音を引き出す聞き方
発展：MVP（実用最小限の製品）から本開発への移行判断 — いつエンジニアに依頼すべきか

よくある質問

Q. AIが作った試作品を、本番のサービスにそのまま使えますか？ A. 基本的には使えません。試作品は「反応を得る」ことが目的で、セキュリティや安定性は考慮されていません。本番は改めて設計・開発する前提で割り切りましょう。

Q. プログラミングが全く分からなくても作れますか？ A. 画面モック程度なら、AIに指示してHTMLを生成し保存するだけで作れます。動く機能まで求める場合は、ノーコードツールやエンジニアの協力を組み合わせるとスムーズです。

Q. 何人に見せれば判断してよいですか？ A. 明確な正解はありませんが、5〜10人で共通した反応が見えることが多いです。全員が同じ箇所でつまずくなら、その問題は本物だと考えてよいでしょう。

新規事業のアイデアをAIでどうやって試作品にするか