こんにちは。テクノロジー・コンサルティング課のたです。
最近、提案フェーズで「AIを使ってモックを作る」場面が増えてきました。
スピードも完成度も上がる一方で、きれいだけど議論が進まない／作りすぎて余白がなくなる、という違和感を感じることもあります。
この記事では、提案活動におけるモック開発を題材に、AIを活用しつつも人間の思考と判断を中心に据えるための進め方を、現時点の整理としてまとめます。
（※案件やチームによって最適解は変わります。）
セキュリティ要件を確認しましょう
実務では、案件や現場のガイドラインで許可された範囲のツールだけを使うことになります。場合によっては「AIを使わない」判断になることもあります。
業務で利用する際は、案件ごとのルールや契約条件に従いましょう。
この記事はこんな方におすすめ
- 提案フェーズで「モックを作って見せたい」ことがある
- 生成AIで作れる範囲が広がって、逆に判断が難しくなっている
- 「作り込みすぎ」と「作らなさすぎ」のバランスに悩んでいる
参考：私がよく使うAIサービス
-
リサーチ・前提整理Gemini / ChatGPT / Claude など業界・用語・類似事例の把握、論点の洗い出し。広く当たりをつけたい初期段階
-
壁打ち・整理ChatGPT / Claude前提条件の言語化、複数案の比較、抜け漏れや思考の偏りチェック
-
仕様の構造化ChatGPT / Claude自然言語をJSON・箇条書き・状態定義に落とし、Mermaid等で図にする
-
実装・プロトタイプGitHub Copilot / Codex / Cursor / Claude など手を動かしながら試し、動くモックとして検証するフェーズ
-
レビュー・振り返りGemini / ChatGPT / Claude提案として成立しているか、目的や前提からズレていないかを確認
- この記事はこんな方におすすめ
- 参考：私がよく使うAIサービス
- 全体像：直線的な手順ではなく、往復を前提にする
- 1. ユーザー視点で要件を「仮置き」する
- 2. 既存の類似システムをリサーチする
- 3. AIで壁打ち・比較検討する（まだコーディングしない）
- 4. コーディングAIに渡すために、仕様を少しだけ厳密にする
- 5. コーディングAIで実装・比較検証する
- 6. セルフレビュー：提案として成立しているかを問い直す
- おわりに
- この記事を書いた人
全体像：直線的な手順ではなく、往復を前提にする
提案フェーズのモック開発は、手順を上から順に消化するというより、要件・リサーチ・比較検討・仕様化・実装・レビューを往復しながら形にしていくことが多いです。
まずは全体像を1枚で置いておきます。
1. ユーザー視点で要件を「仮置き」する
提案フェーズで重要なのは、正解を示すことではなく次の議論や意思決定につながる材料を提示できているかです。
この段階で目指すのは精度の高い仕様書ではなく、ユーザーと価値の仮説を一定の納得感で共有できる状態だと考えています。
- 誰が使うのか（職種・立場・ITリテラシー）
- 何が楽になるのか／何が変わるのか
- 何ができるようになったと感じてほしいか
ここで答えを固めすぎると、後で「気づいたが戻れない」状態になりがちです。
まずは仮説として置く、未確定点を自覚する、くらいで十分です。
2. 既存の類似システムをリサーチする
目的は「完成された答えを見つける」ことではなく、世の中にどんな選択肢があるかを把握することです。
Slack / Teams / Notion / Jira など、業界標準ツールを横断的に眺めるだけでも、共通点と思想の違いが見えてきます。
この段階は心理的コストが高くなりがちなので、生成AIは知識を詰め込むためというより、「何が分かっていないか」を言語化する補助として使うとラクです。
3. AIで壁打ち・比較検討する（まだコーディングしない）
ここでは、アイデアや構成案を整理し、比較し、検討するための「壁打ち」を行います。
私はこのフェーズで意図的に「まだ作らない」状態を保つことが多いです。
- 要件や前提条件の言語化
- 複数の構成案・UI案を並べて比較
- メリット・デメリットの洗い出し
- 抜け・偏り（バイアス）の確認
ここで重要なのは、AIを答えを出す存在としてではなく、思考を外在化して整理する相手として扱うことです。
4. コーディングAIに渡すために、仕様を少しだけ厳密にする
実装に踏み込む前に、自然言語の説明から少し距離を取り、構造を表現できる形で仕様を見直します。
文章だけだと解釈の幅が残り、手戻りの原因になりやすいからです。
- 画面構成図・画面遷移図（Figma / FigJam / Mermaid→画像化 など）
- 状態遷移図・シーケンス図
- フローチャート
- JSON風のデータ構造定義
完璧である必要はありませんが、少なくとも「思っていたのと違った」となった時に、どこを直せばいいか分かる状態を目指します。
5. コーディングAIで実装・比較検証する
準備ができたら、コーディングAIを使って動くモックに落とします。
ただし実装は作業ではなく、評価の連続だと捉えています。
- 見た目は自然か
- 操作フローに無理はないか
- 裏側の処理は現実的か
- ユーザー体験として違和感はないか
AIの生成物は「正解っぽく」見えやすいので、最終的には人間が触って判断することが重要です。
6. セルフレビュー：提案として成立しているかを問い直す
モックが形になったら、品質保証というより提案フェーズとしての役割を果たしているかを見直します。
AIで作るスピードが上がるほど、当初の目的から少しずれることがあるためです。
私がよく使う問い：
- 当初のユーザー／ユースケースから外れていないか
- 要件範囲外の機能や表現が入り込んでいないか
- 個人的な好みや思い込みが強く反映されていないか
- 「なぜここまで作ったのか」を説明できるか
おわりに
AIの進化によって「作ること」自体はますます簡単になります。
だからこそ、どこで立ち止まり、どこで決め、どこをAIに任せるかという判断の重みは増していると感じます。
提案フェーズのモック開発は、完成度を競う場ではなく、対話を生み、次の一歩につなげるための手段です。
本記事が、提案活動の中で思考を整理するための参考になれば幸いです。
【合わせて読みたい】
この記事を書いた人
ニックネーム：た
経歴：自称フロントエンドエンジニア。主にWeb開発に関わっていたい（願望）
一言：知人に「土日もコード書いてない人はエンジニア向いてないですよ」と言われて以来へこんでいます。
