Codexで壁打ちして決めた、Stitch用プロンプト生成ツールのMVP設計

AI にデザイン案を作ってもらうためのプロンプトを、毎回手書きするのは少し面倒です。

作りたいサイトの種類、業種、雰囲気、入れたいセクション、色、避けたい方向。毎回だいたい同じ材料を考えているのに、文章にするときだけ手が止まることがあります。

そこで、Stitch に渡すデザイン用の文章を、選択式で組み立てる小さなツールを考えました。

ただ、最初に引っかかったのは「選択肢を並べればプロンプトになるのか」という点です。チェックボックスやチップを用意するだけなら簡単です。でも、その結果が単語の羅列になると、AI に渡す依頼文としては弱くなります。

今回整理したかったのは、選択式 UI の作り方そのものではありません。

選択された材料を、AI が読み取りやすいデザインブリーフに変換するために、何を先に決めておくべきかです。

先に結論

Stitch Prompt Builder の MVP では、次の方針にしました。

• 最初に、AI に渡す最終文の型を決める。
• 入力項目は、サイト種別、業種・テーマ、雰囲気、セクション、色、UI 表現、避けたい方向に絞る。
• 必須項目と任意項目を分ける。
• 選択肢はカテゴリごとに 6〜10 個程度に絞る。
• 選びすぎを防ぐために、選択数の上限を決める。
• 表示用のラベルと、出力文に入れるフレーズを分ける。
• ルール違反があってもプレビューは止めず、警告として見せる。
• 保存、履歴、複数比較、ログイン、AI API 連携は MVP では入れない。

一番大事なのは、UI の部品を増やすことではなく、出力文の読みやすさを先に設計することでした。

前提と制約

今回の題材は、Stitch に渡す英文のデザインブリーフを作るフロントエンドツールです。

やりたいことは、ユーザーの選択をもとに、Web サイトやアプリのデザイン依頼文を組み立てることです。たとえば、マーケティングサイト、SaaS、ポートフォリオ、モバイルアプリのような対象を選び、雰囲気や入れたい画面要素を追加して、自然な英文にまとめます。

一方で、MVP では次のことはやりません。

入れないもの	理由
ログイン	出力文の品質検証には不要
保存・履歴	まずは 1 回の入力と出力の流れを確認したい
複数プロンプト比較	画面と状態管理が重くなる
日本語出力	最初は Stitch に渡す英文に集中する
AI API 連携	選択内容を文章化するだけなら静的アプリで足りる
Stitch 以外のツール対応	対象を広げる前に、1 つの用途で使えるか確認する

この制約を置いたことで、実装の中心がはっきりしました。

「何を保存するか」ではなく、「どの選択肢を、どんな文章に変換するか」です。

実装または作業の流れ

同じような選択式プロンプト生成ツールを作るなら、次の順番で考えると整理しやすいです。

1. 最終的な出力文を先に書く

最初に、理想の出力文を 1 つ手で書きます。

たとえば、次のような形です。

Create a modern landing page for a productivity app.
Use a calm and trustworthy tone, with sections for hero, features, pricing, and FAQ.
Avoid overly playful visuals and heavy gradients.

ここで見るべきなのは、英語のうまさではありません。

文章の中に、どんな材料が必要かです。

• 何を作るのか
• 何の業種・テーマか
• どんな雰囲気にしたいか
• どんなセクションが必要か
• 何を避けたいか

この分解ができると、入力項目が決まります。

2. 入力カテゴリを決める

今回の MVP では、入力カテゴリを次のように整理しました。

カテゴリ	必須/任意	役割
サイト種別	必須	何を作るかを決める
業種・テーマ	必須	文脈を決める
雰囲気	必須	デザインの方向を決める
セクション	必須	画面に必要な要素を決める
色	任意	見た目の方向を補足する
UI 表現	任意	角丸、カード、余白などの見え方を補足する
避けたい方向	任意	出力のブレを減らす

最初から項目を増やしすぎると、ユーザーも作る側も迷います。MVP では、出力文に直接効く項目だけに絞るほうが扱いやすいです。

3. 選択肢を 6〜10 個程度に絞る

選択式 UI では、選択肢を増やすほど便利に見えます。

でも、プロンプト生成ツールでは、選択肢が多すぎると出力文が散らかります。雰囲気を 5 個、色を 4 個、UI 表現を 6 個選べるようにすると、文章の方向が衝突しやすくなります。

そのため、初期選択肢はカテゴリごとに 6〜10 個程度に絞ります。

さらに、複数選択できるカテゴリには上限を置きます。

雰囲気: 最大 3 個
セクション: 最大 6 個
色: 最大 2 個
避けたい方向: 最大 3 個

この上限は、ユーザーを制限するためではありません。AI に渡す文章を読みやすく保つためです。

4. 表示用ラベルと出力用フレーズを分ける

ここが一番大事でした。

画面に見せる言葉と、プロンプトに差し込む言葉は、同じでなくてよいです。

たとえば、画面上では「落ち着いた」と表示したい。でも英文の中では calm and trustworthy のように、文に馴染む形で入れたい場合があります。

そのため、1 つの選択肢には最低限、次の情報を持たせます。

項目	役割
日本語ラベル	ユーザーが選ぶときに読む
英語ラベル	必要なら補助表示に使う
出力用フレーズ	実際の英文に差し込む
説明文	選択肢の意味を補足する

表示用ラベルをそのまま出力文に入れると、文章が不自然になりやすいです。選択式ツールほど、裏側では文章に入れるためのフレーズ設計が必要になります。

5. 未選択のときの補完文を決める

任意項目は、何も選ばれないことがあります。

そのときに文章が欠けたように見えると、出力品質が落ちます。たとえば色が未選択なら、無理に色指定を入れず、「ブランドに合う控えめな配色」のような補完文にすることもできます。

未選択をエラーにするのではなく、自然に補う。この方針にすると、入力途中でもプレビューを見せやすくなります。

6. 警告は出すが、プレビューは止めない

選択数の上限を超えたとき、プレビューを完全に止めると、ユーザーは何が起きたのか分かりにくくなります。

今回の方針では、ルール違反があってもプレビューは表示します。その代わり、警告を出し、コピー時の文言も通常時と分けます。

通常時: Copy prompt
警告あり: Copy with warnings

このほうが、入力と出力の関係を確認しながら調整できます。

判断ポイント

今回の設計で判断基準にしたのは、次の 4 つです。

出力文が自然に読めるか

選択式でも、最終的には文章として読める必要があります。

「modern, clean, SaaS, hero, pricing, blue」のような単語列ではなく、依頼文としてつながっているかを確認します。

ユーザーが迷いすぎないか

選択肢が多いほど、入力前に迷います。MVP では、選択肢の網羅性よりも、選びやすさを優先します。

1 画面で入力と出力を往復できるか

このツールの中心は、選択して、出力文を見て、また調整することです。

デスクトップでは左に入力、右にプレビュー。モバイルでは 1 カラム。複雑な画面遷移は不要です。

静的フロントエンドだけで検証できるか

今回の価値は、AI API を呼ぶことではなく、選択内容を使いやすい文章にすることです。

そのため、まずは Vite、React、TypeScript、Bun で静的に作れば十分です。バックエンドを入れるのは、保存や共有が本当に必要になってからでよいと判断しました。

採らなかった案と理由

MVP では、便利そうに見える機能をいくつか外しました。

採らなかった案	採らなかった理由
保存機能	出力文の質を見る段階では不要
履歴管理	状態管理が増え、MVP の焦点がぼやける
複数プロンプト比較	画面構成が重くなる
出力モード切り替え	標準出力の品質基準が曖昧になる
日本語出力	まずは Stitch 向け英文に集中する
AI API 連携	ルールベースの文章生成で検証できる

機能を削った理由は、実装を楽にするためだけではありません。

「選択肢から自然な英文ブリーフを作れるか」という中心の検証をぼかさないためです。

つまずきやすい点

選択肢を増やしすぎる

最初にやりがちなのは、選択肢をたくさん用意することです。

でも、選択肢が増えると、ユーザーは迷います。さらに、複数選択したときに文章の方向が衝突しやすくなります。最初は少なく作り、実際の出力を見て足すほうが扱いやすいです。

ラベルをそのまま英文に入れてしまう

表示用ラベルは、ユーザーが理解するための言葉です。

出力用フレーズは、文章の中で自然につながる言葉です。この 2 つを分けないと、UI は分かりやすいのに出力文が不自然、またはその逆が起きます。

任意項目の未選択を想定していない

任意項目は、未選択でも成立するように設計しておく必要があります。

未選択時の補完文を決めておくと、入力途中でもプレビューを出せます。これは、1 画面完結のツールではかなり重要です。

警告で操作を止めすぎる

ルール違反をすべてエラーにすると、ユーザーは調整しにくくなります。

選びすぎのような問題は、まず警告として見せる。プレビューは表示する。コピー時に注意を出す。このくらいのほうが、試行錯誤しやすいです。

確認方法

実装後は、次の順番で確認します。

1. 必須項目だけで出力できるか

サイト種別、業種・テーマ、雰囲気、セクションだけを選び、自然な英文になるかを見ます。

• 必須項目だけで文章が欠けない
• 任意項目が未選択でも不自然な空白が出ない
• 出力文が単語の羅列になっていない

2. 任意項目を足しても文章が破綻しないか

色、UI 表現、避けたい方向を追加します。

• 色指定が文脈に自然に入る
• UI 表現が過剰に並ばない
• 避けたい方向が命令文として自然に入る

3. 選択上限を超えたときの表示を見る

あえて選びすぎて、警告とプレビューの関係を確認します。

• 警告が出る
• プレビューは表示される
• コピー時の文言が通常時と分かれている

4. モバイル幅で入力とプレビューを確認する

デスクトップでは 2 カラムでも、モバイルでは 1 カラムになります。

• 入力項目が縦に読みやすい
• プレビューが下に自然につながる
• コピー操作が見失われない

5. 実際に Stitch に入れてみる

最後は、生成した英文を Stitch に入れて確認します。

ここで見るのは、見た目の良し悪しだけではありません。こちらが指定したサイト種別、雰囲気、必要なセクション、避けたい方向が、出力に反映されているかを見ます。

まとめ

選択式のプロンプト生成ツールを作るとき、最初に作るべきなのは UI ではなく、出力文の型です。

どんな文章を AI に渡したいのか。その文章には、どんな材料が必要なのか。どの材料を必須にして、どれを任意にするのか。表示用の言葉と、文章に入れる言葉をどう分けるのか。

この順番で考えると、小さなフロントエンドツールでも実用的な AI 補助ツールになります。

今回の Stitch Prompt Builder では、保存や履歴や AI API 連携を入れる前に、選択肢と文章の接続を丁寧に決めることを優先しました。

機能を増やす前に、出力文が自然に読めるかを見る。

プロンプト生成ツールでは、この確認がかなり大事です。