「こんなシステムが欲しい」を専門知識なしでAIとどうやって形にするか
2026/8/2
アイデアを1日で試作品に:非エンジニアがAIと対話して形にする5ステップ
「頭の中にある業務改善アイデアを、開発チームに頼まず自分で形にしたい」——そんな事業責任者・業務担当者へ。本記事はAIとの対話でアイデアを目的・利用者・機能・画面へ分解し、触れる試作品まで持っていく手順を、具体例とコピペ用プロンプト付きで解説します。
この記事の結論
- アイデアを「目的→利用者→機能→画面」の順に分解すると、AIが的確に手伝える状態になる
- AIは分解と試作の作業を高速化するが、何が正しいかを決めるのはあなた(業務知識を持つ本人)
- 試作品は「見た目だけ動くモックアップ」で十分。完璧なシステムは不要
- プロンプトを型にすれば、非エンジニアでも半日〜1日で触れる試作品に到達できる
- 最初にやるべきは「1文で目的を言語化する」こと。ここが曖昧だと全工程が崩れる
> 強調ボックス:試作品とは何か
> ここでいう試作品(プロトタイプ)は「画面をクリックすると次の画面に進む、見た目だけの模型」です。データベースや本番ロジックは不要。関係者に見せて「これで合ってる?」を確認するための道具です。
この記事が役立つ人
- 業務改善やサービスのアイデアはあるが、要件を言語化できず止まっている人
- 開発チームやベンダーに説明する前に、自分でイメージを固めたい人
- 「AIに丸投げしたら微妙なものが出てきた」経験がある人
前提条件は特にありません。ChatGPT・Claude などの対話AIと、後半で紹介する試作ツール(無料枠あり)が使えれば十分です。
なぜこの問題が起きるのか
多くのアイデアが試作にたどり着けない原因は、頭の中の「なんとなく」を、AIや開発者に渡せる粒度まで分解できていないことです。人は完成イメージを一度に思い描きますが、作るには順序立てた分解が必要です。
AIに丸投げすると失敗しがちなのも同じ理由です。目的や利用者が曖昧なままだと、AIは統計的にありそうな「平均的な機能」を出力します。あなたの業務固有の事情は、あなたしか知りません(筆者の意見)。
図: アイデアが試作品になるまでの分解ピラミッド
```
目的(なぜ作る) ← 1文で
利用者(誰が使う) ← 2〜3タイプ
機能(何ができる) ← 箇条書き5〜10個
画面(どう見える・操作する) ← 3〜6画面
```
解決するための5つのポイント
1. 目的を「1文」に絞ると、以降の判断軸ができる
結論:最初に目的を1文で書くと、機能を足すか捨てるかを迷わず判断できます。
具体例:「営業担当が外出先から日報を書くのが面倒」という課題なら、目的は「営業日報の入力時間を10分から2分に減らす」。この1文があれば「グラフ機能」は目的外だと即判断できます。
実践方法:AIに「この目的文は具体的で測定可能か、3案に書き直して」と依頼し、自分で1つ選ぶ。選ぶのはあなたの仕事です。
2. 利用者を2〜3タイプに具体化すると、機能の優先順位が決まる
結論:「誰が」を具体化すると、機能の要不要が自然に見えてきます。
具体例:日報アプリなら「①外回りの若手営業(スマホ中心・急いでいる)」「②確認する営業マネージャー(PC・一覧で見たい)」。この2人で必要な画面が変わります。
実践方法:AIに人物像(ペルソナ)の下書きを作らせ、実在の同僚を思い浮かべて修正します。「うちの田中さんならこう使わない」という補正はAIにできません。
3. 機能はMoSCoWで仕分けし、試作は「Must」だけに絞る
結論:全機能を作ろうとすると挫折します。試作は必須機能だけに絞ります。
MoSCoW(モスクワ)法は機能を4段階で仕分けする手法です。
| 区分 | 意味 | 日報アプリの例 |
|------|------|----------------|
| Must | ないと成立しない | 訪問先・商談内容の入力/送信 |
| Should | あると良い | 音声入力 |
| Could | 余裕があれば | テンプレート選択 |
| Won't | 今回はやらない | 売上グラフ・分析 |
実践方法:機能を全部書き出し、AIに「MoSCoWで仕分け案を出して」と依頼。最終判断は業務を知るあなたが行います。
4. 画面は「利用者の1回の作業の流れ」で並べる
結論:機能一覧を、利用者が実際にたどる画面の順番に並べ替えると試作設計になります。
具体例:若手営業の流れは「ログイン → 今日の訪問先を選ぶ → 商談内容を入力 → 送信完了」の4画面。この流れを言葉で書けたら試作の設計図は完成です。
実践方法:後述のMermaid図でAIに画面遷移を書かせ、抜けや不自然な戻り道を目視で確認します。
5. 触れる試作品にして「関係者に見せる」までを1周とする
結論:頭の中で完璧にせず、粗くても触れる形にして人に見せることでアイデアが磨かれます。
具体例:あるバックオフィス担当者(筆者が支援した事例・詳細は簡略化)は、経費申請フローの試作を半日で作り、上長に見せた結果「承認ステップが1つ足りない」と即発覚。開発前に手戻りを防げました。
実践方法:試作ツールに画面遷移図を渡して生成させ、社内の想定利用者2〜3人にクリックしてもらいます。
> 強調ボックス:AIに任せてよい作業/自分がやる判断
> 任せてよい:文章の整形、選択肢の列挙、たたき台の生成、画面遷移の下書き。
> 自分がやる:目的の決定、利用者の実像補正、機能の取捨選択、「業務上ありえない」の指摘。
AIやツールで自動化する方法
対話AIで分解を進め、生成したMermaidをAIコーディングツールに渡すと、触れる試作品まで一気通貫で進められます。特定製品に依存しない汎用的な流れを示します。
図: ツールの役割分担
```
対話AI(ChatGPT/Claude)→ 分解・要件整理・Mermaid生成
↓ 画面遷移図を渡す
AIコーディング(Claude Code/Cursor/v0等)→ 動くモックHTML生成
↓
ブラウザで確認 → 関係者に共有
```
そのまま使えるアイデア分解プロンプト
対話AIに貼り付け、〈〉を自分のアイデアに置き換えて使います。
```text
用途: アイデアをAIと対話で分解するためのプロンプト
あなたは新規サービスの要件整理を手伝うファシリテーターです。
私は非エンジニアの業務担当者です。以下のアイデアを、私が判断しやすい
形で段階的に分解してください。各段階で私に確認を取り、私の回答を待って
から次に進んでください。勝手に先へ進めないでください。
私のアイデア
〈例:営業が外出先からスマホで日報を書くのが面倒なので楽にしたい〉
進めてほしい順番
1. 目的を「測定可能な1文」で3案提示(私が1つ選ぶ)
2. 想定利用者を2〜3タイプ、簡単なペルソナで提示
3. 必要そうな機能を列挙し、MoSCoW(Must/Should/Could/Won't)で仕分け案
4. Must機能だけで成立する画面の流れを、画面名のリストで提示
5. 上記4をMermaidのflowchartで出力
ルール
- 専門用語には短い説明を添える
- 各段階の最後に「この内容で合っていますか?修正はありますか?」と質問する
```
そのまま使える画面遷移図(Mermaid)
対話AIが出力する形式の見本です。これをAIコーディングツールに渡すと試作HTMLになります。
```mermaid
flowchart TD
A[ログイン画面] --> B[今日の訪問先一覧]
B --> C[商談内容 入力画面]
C --> D{必須項目は<br>埋まっている?}
D -- いいえ --> C
D -- はい --> E[送信完了画面]
B --> F[過去の日報を見る]
```
そのまま使える試作生成プロンプト
上記Mermaidや画面リストを、AIコーディングツール(Claude Code / Cursor / v0 等)に渡します。
```text
用途: 画面遷移図から触れるモックアップを生成する
以下の画面遷移をもとに、1つのHTMLファイルで動くモックアップを作って
ください。ボタンを押すと画面が切り替わる程度で十分です。データベースや
サーバー処理は不要。スマホ表示を優先。日本語UI。
画面遷移
〈ここに上のMermaidまたは画面リストを貼る〉
条件
- 見た目より「流れが確認できること」を優先
- 各画面にダミーの入力欄・ボタンを配置
- 1ファイルで完結し、ブラウザで開けばそのまま動くこと
```
実践チェックリスト
- [ ] 目的を「測定可能な1文」で書けた
- [ ] 利用者を2〜3タイプ、実在の人物を思い浮かべて具体化した
- [ ] 機能をMoSCoWで仕分けし、Mustを5個以内に絞った
- [ ] Must機能で成立する画面の流れを言葉で書けた
- [ ] AIにMermaidの画面遷移図を出させ、抜けを目視確認した
- [ ] 触れるモックアップを生成し、想定利用者2〜3人に見せた
- [ ] AIの出力を鵜呑みにせず「業務上おかしい点」を自分で補正した
まとめ
アイデアを試作品にする鍵は、AIに丸投げせず「目的→利用者→機能→画面」の順で分解し、各段階の判断を業務知識のある自分が下すことです。AIは高速な下書き係、あなたは最終決定者です。
最初に着手する行動:本記事の「アイデア分解プロンプト」を対話AIに貼り、目的の1文を決めるところから始めてください。ここが決まれば残りは驚くほど進みます。
次に読む記事
- 基礎:対話AIへの指示が上手くなる「プロンプトの型」入門
- 実践:MoSCoW法で機能の優先順位を30分で決めるワークショップ設計
- 発展:試作品を開発チーム・ベンダーに渡すための要件伝達ドキュメントの作り方
よくある質問
Q. プログラミングを全く知らなくても試作品は作れますか?
A. はい。本記事の試作生成プロンプトを使えば、AIがHTMLを書きます。あなたはブラウザで開いて「流れが正しいか」を確認するだけです。コードを読む必要はありません。
Q. AIに全部任せた方が早いのでは?
A. 下書きは任せて構いませんが、目的・利用者・機能の取捨選択は任せられません。AIは平均的な提案しかできず、あなたの業務固有の事情(承認フローや例外処理など)を知らないためです。
Q. 試作品はそのまま本番システムに使えますか?
A. 使えません。試作品は関係者と認識を合わせる「模型」です。ただし試作で固めた要件と画面は、開発チームへの発注資料としてそのまま活用でき、手戻りを大きく減らせます。