アイデアがあるのに、UIデザインに形にできない——そんな状況を変えてくれるのが Google Stitch です。テキストで説明するだけでUIが生成されるため、デザインツールの習熟なしにプロトタイプを作れます。「デザインのことはよくわからないけど、こういうUIを作りたい」という人が最もメリットを感じやすいツールの一つです。
この記事では、Google Stitch を使ってプロトタイプを作る実践的な流れを、具体的なステップで解説します。「何から始めればいいかわからない」という人が、一連の手順を追うことでStitchを使いこなせるようになることを目指します。フェーズごとに「何をする」「なぜする」を説明するので、初めてプロトタイプを作る人にも参考になる内容です。
プロトタイプ作成の全体的な流れ
Google Stitch を使ったプロトタイプ作成は、大きく5つのフェーズで進みます。それぞれのフェーズで何をするかを把握してから作業に入ると、迷わずに進められます。「フェーズがある」と知っておくだけで、「今何をすべきか」が明確になり作業が詰まりにくくなります。
- フェーズ1：作るものの整理（何の画面を、誰のために、なぜ作るか）
- フェーズ2：最初のUIを生成（プロンプトを書いて最初の出力を得る）
- フェーズ3：修正の反復（気になる点を対話形式で修正する）
- フェーズ4：複数画面の作成（必要な画面を順番に生成する）
- フェーズ5：書き出しと共有（コードまたはスクリーンショットとして保存する）
このフローを念頭に置いておくと、「今自分はどのフェーズにいるか」が明確になり、作業が詰まったときに立ち戻る基準になります。
フェーズ1：作るものを整理する
Google Stitch を開く前に、作るものを頭の中で整理する時間を少しとることが、後の作業を効率化します。
「誰のための、何の画面か」を決める
「フードデリバリーアプリを使うユーザーの注文画面」のように、ユーザーと目的を一文で言えるレベルまで整理します。この一文がプロンプトの核心になります。曖昧なまま作り始めると、生成を繰り返しながら「何が作りたかったのか」がぶれてしまうことがあります。「誰が使うか」を明確にすることで、デザインの優先事項も自然と決まります。高齢者が使う行政サービスの画面と、若いクリエイター向けのポートフォリオサイトでは、必要なUIの方向性がまったく異なります。ユーザーを明確にすることが、プロンプトの精度を上げる第一歩です。
必要な画面の一覧を出す
プロトタイプに必要な画面を書き出します。「ログイン画面」「ホーム画面」「商品一覧」「商品詳細」「カート」「決済確認」のようなリストです。全部を一度に作ろうとせず、「まずこの2〜3画面を作る」と優先順位をつけると作業が進みやすいです。
参考にするデザインを集めておく
既存のアプリやWebサイトで「こんな雰囲気にしたい」という参考があれば、スクリーンショットを事前に用意しておきます。Stitch の画像入力機能で参考画像をアップロードすると、雰囲気を伝えやすくなります。参考がなくても作れますが、方向性が明確な方がプロンプトが書きやすいです。「色のトーン」「レイアウトの密度（情報量が多い・少ない）」「ビジュアルの重さ（写真多め・テキスト中心）」といった軸で方向性を言語化しておくと、参考画像がなくてもプロンプトに落とし込みやすくなります。よく使うアプリのUIを普段から「デザインの観点」で見る習慣をつけると、「言語化」の引き出しが増えていきます。
フェーズ2：最初のUIを生成する
整理ができたら Google Stitch を開いてプロンプトを入力します。
最初のプロンプトは「詳しめ」に書く
最初の生成で方向性を合わせるために、プロンプトは詳しめに書きます。「[アプリの目的]の[画面名]。[含める要素1]、[要素2]、[要素3]。[デザインスタイル]」という構成が基本です。たとえば「フリーランス向けの請求書管理アプリのダッシュボード。上部に今月の売上合計と未回収金額のサマリーカード、下部に最近の請求書リスト（クライアント名・金額・ステータス）、右上にプロフィールアイコン。シンプルでプロフェッショナルなデザイン、アクセントカラーはネイビー」のように書きます。
生成結果を「方向性の確認」として見る
最初の生成結果を「完成品」として見ず、「方向性の確認」として見ます。「大まかにこの方向で合っているか」を判断して、大きくズレている場合は次のフェーズで修正します。細部が気になっても、まず全体の方向性が合っているかを優先して確認します。「ボタンの色が微妙」「フォントが気に入らない」という細部は、全体のレイアウト方向性が固まってから直す方が効率的です。最初から細部を詰めようとすると、後で大きく変えた際に細部の修正がやり直しになるため、大→小の順番を意識することが重要です。
フェーズ3：修正を重ねる
最初の生成後、対話形式で修正を積み重ねてデザインを改善します。
大きな変更から小さな変更へ
修正の順番は「全体のレイアウト変更」→「色やフォントの調整」→「細部の修正」という順で進めます。細部から直そうとすると、後で全体レイアウトを変えたときに細部の修正がやり直しになることがあります。大きなところから固めて、小さなところを詰めていく順序を意識します。
気に入ったバージョンを保存しながら進める
修正を重ねる中で「このバージョンは良かった」と思うものが出たら、スクリーンショットを撮るか、コードを保存しておきます。修正を続けていくうちに「以前の方が良かった」と感じることがあるため、良いと思った時点でのバージョンを残しておく習慣が有効です。
行き詰まったら「新しい指示」を試す
細かい修正を繰り返しても改善しない場合、プロンプトを根本から変えて新しいバージョンを生成する方が早いことがあります。「最初から作り直し」を恐れず、良い方向性を見つけるための試行錯誤として捉えます。Stitch の生成は速いため、新しいバリエーションを試すコストは低いです。「この方向ではうまくいかない」とわかることも前進です。試行錯誤の記録（どんなプロンプトでどんな結果が出たか）を手元に残しておくと、「すでに試したアプローチ」を繰り返さずに済み、探索の効率が上がります。
フェーズ4：複数画面を作る
一画面のデザインが固まったら、他の画面も同じスタイルで作っていきます。
スタイルを「引き継ぐ」プロンプトを書く
最初に作った画面のデザイン要素（色、フォント、レイアウトスタイル）を次の画面のプロンプトに引き継ぎます。「先ほど作ったダッシュボードと同じデザインスタイル（ネイビーアクセント、カード型レイアウト）で、請求書の詳細画面を作って」のように書きます。
スタイルの一貫性を保つことで、複数画面を並べてもバラバラに見えないプロトタイプになります。一貫したデザインシステムがないStitchの弱点を、この「スタイルを引き継ぐプロンプト」でカバーします。最初の画面を作った後、「このデザインの主要なスタイル要素」をメモしておき、以降の画面を作るときにそのメモを参照してプロンプトに含めるという習慣が有効です。プロンプトの冒頭に「デザイン基準：[色・スタイル・フォントの指定]」を定型文として書く方法も、複数画面にわたる一貫性を保つ実践的なアプローチです。
ユーザーフローを意識して順番に作る
ユーザーが辿る画面の流れに沿って作ると、後でプロトタイプとして見せるときにスムーズです。「ログイン→ホーム→詳細→アクション→完了」のように、画面遷移のフローを意識した順番で作成します。フローが明確なプロトタイプは、デモやレビューの場での説明がしやすくなります。「この画面の次はこの画面に遷移します」という���明をしながら複数画面を見せることで、「どんなユーザー体験を想定しているか」が伝わりやすくなります。画面単体ではなくフロー全体を見せることが、プロトタイプをステークホルダーやユーザーに見せるときの最大の価値です。
フェーズ5：書き出しと共有
プロトタイプが完成したら、用途に合わせた形式で保存・共有します。
スクリーンショットで共有する場合
プレゼンや提案資料への添付、チームへの共有はスクリーンショットが最も簡単です。各画面のスクリーンショットを撮り、PowerPointやGoogleスライドに貼り付けて「画面遷移のフロー」として見せる形式がよく使われます。静的な画像なのでインタラクションは見せられませんが、「どんなUIになるか」を伝えることが目的なら十分です。
コードとして書き出す場合
実際の開発に活用したい場合やブラウザでプレビューしたい場合は、HTML/CSSコードとして書き出します。書き出したコードはそのままエンジニアに渡すというより、「このUIをベースに実装してほしい」という参考資料として渡す使い方が現実的です。コードを書けるメンバーがいる場合、スクリーンショットよりもコードを渡した方が実装のスタート地点として使いやすいです。
プロトタイプ作成を速くするための工夫
Google Stitch を使い込んでいくと、作業をさらに効率化できる工夫が見えてきます。
「スタイルシート」をプロンプト冒頭に書く習慣をつける
アプリ全体で統一したいデザイン要素（ブランドカラー、フォントスタイル、ボタンの見た目）を、各プロンプトの冒頭に定型文として書く習慣をつけると、複数画面を作るときのスタイル一貫性が保ちやすくなります。たとえば「このアプリのデザイン基準：プライマリカラー#3B82F6（ブルー）、セカンダリカラー白、フォントはサンセリフ系、角丸のカード、ドロップシャドウなし。この基準に沿って[以下の画面の説明]を作って」という形で使えます。
「ビフォーアフター」の確認をこまめに行う
修正を重ねる中で「修正前の方が良かった」と感じることがあります。これを防ぐために、修正のたびにスクリーンショットを撮る習慣をつけます。特に「これはいい」と感じた時点のものを保存しておけば、修正が行き過ぎた場合の参照点になります。修正の履歴が視覚的に追えると、デザインの方向性に迷ったときに「どこから来て、どこに向かっているか」を確認できます。
ユーザーフローを文章化してからStitchを開く
「ログイン→商品一覧→商品詳細→カート追加→決済→完了」のようなユーザーフローを箇条書きにしてから、それに沿って画面を順番に作ると、プロトタイプ全体の構造が整います。Stitchを開く前に「何の画面を、どの順番で作るか」が決まっていると、作業中に迷わなくて済みます。この準備5分が、Stitch上での作業30分を効率化します。
プロトタイプを使った「早いフィードバックループ」の作り方
Stitch でプロトタイプを作ることの本当の価値は、「作るのが速い」ことより「早くフィードバックを得られる」ことにあります。
プロダクト開発において、「作る→使ってもらう→フィードバックを得る→改善する」というサイクルを速く回すことがプロダクトの質を高めます。Stitch があると、このサイクルの最初の「作る」フェーズにかかる時間が大幅に縮まります。以前は「プロトタイプを作るのに2日かかった」という状況が「1時間で作れる」になれば、フィードバックを得るタイミングが2日分前倒しになります。その2日を使って改善を繰り返せるなら、最終的なプロダクトの質が上がります。「速く作る」ことの価値は「速く仕上げる」ことではなく、「速くフィードバックを得て、速く学ぶ」ことにあります。
早いフィードバックループを活かすには、プロトタイプができたら「できるだけ早く誰かに見せる」ことが重要です。「まだ完成じゃないから」「もう少し直してから」という完璧主義がフィードバックを遅らせます。Stitch で作ったプロトタイプは「完成品」ではなく「方向性の確認ツール」です。早めに見せることで、方向性のズレを早期に発見できます。「完成後に直す」より「途中で確認して方向を調整する」方が、最終的な手戻りが少なくなります。
Stitch を使った後の次のステップ
Google Stitch でプロトタイプが完成した後、それをどう活用するかについても整理します。
Figma に移行する場合
Stitch で方向性が固まったら、Figmaでデザインを本格的に作り込むという流れが有効です。Stitch の画面を参考画像として表示しながら Figma でコンポーネントを作成する方法や、Stitch の出力を「ビジュアルリファレンス」として活用する形です。「Stitch で速く方向性を決め、Figmaで精密に仕上げる」という役割分担で、デザインプロセス全体の効率が上がります。
開発チームに渡す場合
エンジニアへの引き渡しには、スクリーンショットを整理したドキュメントと、必要に応じてHTML/CSSコードを添付する形が実用的です。「このUIを実装してほしい」という依頼に、ビジュアルとコード参照の両方を渡すことで、エンジニアの解釈のズレが減ります。「こんな見た目にしてほしい」を言葉だけで伝えるより、画面を見せながら伝える方が実装の精度が上がります。
ユーザーインタビューに使う場合
Stitch で作ったプロトタイプをユーザーインタビューに使う場合、「このUIを見てどう思いますか」「どこに目が行きますか」「使いにくそうな部分はありますか」という質問を事前に用意します。Stitch の出力は本物そっくりの完成度ではないため、「実際のアプリではなく、デザイン案を見てもらっている」という前提を最初に共有した上でインタビューを進めます。UIの方向性についての感想を得るためには、完成度は問題にならないことが多いです。「完成したアプリより、デザイン案の段階でフィードバックをもらう方が修正コストが低い」という原則から考えると、Stitchで作ったプロトタイプでのユーザーインタビューは、開発効率を上げる上で非常に価値があります。プロトタイプの見た目の粗さより、「早くフィードバックを得ること」の価値の方が大きいです。
よくある質問
Q. プロトタイプをステークホルダーに見せるときの注意点はありますか？
「これはデザイン案です、完成品ではありません」という前提を最初に共有することが重要です。Stitch のプロトタイプは実際のUIに近い見た目をしているため、見せた相手が「もうほぼ完成している」と誤解することがあります。「このビジュアルを元に実際のUIを作っていく」というプロセスの説明を添えると、期待値の管理ができます。また、フォントやアイコンが最終的なものと違う可能性があることも事前に伝えておくと、細部への指摘より方向性のフィードバックに集中してもらいやすくなります。
Q. 非エンジニア・非デザイナーが一人でプロトタイプを完成させることは現実的ですか？
現実的です。Stitch はデザインの専門知識がなくても使えるツールとして設計されています。ただし「完成度の高いプロダクトUIを一人で作る」という目的には向きません。「チームに見せるためのたたき台を一人で用意する」「ユーザーインタビューに使うビジュアルを準備する」「クライアントへの初期提案に使う画面を用意する」——こうした目的なら、一人でも十分に対応できます。「何を目的に作るか」を明確にしてから取り組むことで、一人でも完結できる作業量になります。
Q. 何画面くらいのプロトタイプが作れますか？
制作できる画面数に明確な上限はありませんが、現実的には5〜10画面程度のプロトタイプを作るケースが多いです。それ以上になると各画面のスタイル統一の管理が難しくなってきます。主要な画面フローをカバーする最小限の画面数に絞ることで、作成時間を短縮しつつ伝えたい内容をカバーできます。
Q. 生成したプロトタイプをクリックして動かせますか？
現時点のStitchでは、静的なデザインの生成が主な機能です。ボタンをクリックして次の画面に遷移するような、インタラクティブなプロトタイプとしての機能は限定的です。インタラクティブなプロトタイプが必要な場合は、生成したコードをローカル環境で動かすか、Figmaにデザインをインポートしてプロトタイプモードを使うという方法があります。
Q. 作ったプロトタイプを実際の開発にそのまま使えますか？
書き出したコードを開発の出発点として使うことはできますが、そのまま本番実装に使えるクオリティではないことがほとんどです。アクセシビリティの考慮、レスポンシブ対応の細かな調整、実際のデータとの連携、エラー状態の表示など、開発に必要な要素が省略されています。「デザインの方向性をコードで渡す参考資料」として扱い、エンジニアが整える工程を前提に使うのが現実的です。
Q. 一人でプロトタイプを作るのにかかる時間は？
目的や画面数によりますが、3〜5画面のプロトタイプなら1〜2時間で形にできる���とが多いです。��初のうちはプロンプトの試行錯誤に時間がかかりますが、慣れてくると「最初のプロンプトで概ね意図通り」になる確率が上がります。「今日中に提案用の画面を用意したい」という場面でも、十分対応できる速度感です。
Q. デザインの知識がまったくない人でも使いこなせますか？
使いこなせます。「デザインの知識がな���ても使える」のがStitchの設計思想です。デザインの専門用語を知らなくても、「ここにボタンを置きたい」「この色は明るすぎる」「もっとシンプルにしたい」という日常的な感覚でフィードバックを与えながら修正できます。デザイン知識がある人の方が生成精度の高いプロンプトを書けることは確かですが、知識がなくても「試して、修正する」反復を繰り返すことで十分に使いこなせます。「デザイン知識がない人が、デザイン知識を持つ人に近い成果を出す」のを助けるのが、Stitchのような AIデザインツールの役割です。
Q. プロトタイプを作った後、どうやって改善のサイクルを回せばいいですか？
プロトタイプを作る→誰かに見せてフィードバックを得る→フィードバックをもとにStitchで修正する、というサイクルを設計することが大切です。フィードバックは社内のメンバーでも、実際のユーザーでも構いません。最初は「作る」だけで満足してしまいがちですが、プロトタイプの本当の価値は「フィードバックを得るための道具」として使うことで発揮されます。プロトタイプを作ったら「誰に見せて何を聞くか」まで計画に含めておくことが、Stitch活用を「ただ画面を作る作業」から「プロダクトを良くするプロセス」に変えるポイントです。
Google Stitch を使ったプロトタイプ作成のワークフローは、「準備→最初の生成→修正→複数画面化→書き出し」という流れです。各フェーズで何をするかを意識しながら進めることで、迷わずに作業を完結できます。ツールに慣れるにつれ、このフローの各フェーズにかかる時間が短くなっていきます。「今日中に3画面を用意する」という目標を持ってStitchを開くことで、集中して作業できます。プロトタイプを作ることは手段であり、目的は「フィードバックを早く得ること」です。この目的を忘れずに、Stitchを実際の開発プロセスに組み込んでいきましょう。
Stitch を使いこなすほど、プロトタイプ作成という作業が「アイデアを形にする楽しいプロセス」に変わっていきます。まず始めてみることが、最短の習熟への道です。
