あれは火曜日の午後2時のことだった。
「今日の5時に先方へデモを見せることになりました」——プロジェクトマネージャーからのSlackが飛んできた。
問題は、デモに使う予定だったUIが、まだ白紙だったことだ。ワイヤーフレームはあった。要件定義書もあった。でも「見せられる画面」は一枚もなかった。
残り3時間。普通に考えれば「間に合わない」と断るか、「ラフなワイヤーフレームで対応します」と謝る場面だ。でも私の手元には Google Stitch があった。
「やってみよう」。そう決めたのは、Slackを受け取って30秒後だった。
結論から言うと、3時間でStitchを使ってデモ用UIを仕上げることは「できた」が、そのプロセスで生まれた判断の速さと割り切りの必要性が、通常の制作とは全く異なるものだった。この記事では、あの3時間に何が起きたかを時系列で書く。Stitchを「緊急時のツール」として使おうとしている人に、リアルな体験が伝われば嬉しい。
Google Stitch とは——緊急時に使えるツールとしての特性
Google Stitch（以下、Stitch）とは、テキストや音声のプロンプトをもとにAIがUIデザインを自動生成するGoogleのデザインツールです。stitch.withgoogle.comで無料で使え、プロンプトを入力してから数秒〜十数秒でUIが生成される。
Stitchを緊急時のツールとして評価したとき、最大の強みは「最初の一枚が出るまでの速さ」だ。Figmaで一から始めると「どこから手をつけるか」を考えるだけで時間が過ぎる。Stitchはプロンプトを書き始めた瞬間から「何かが生成される」状態になるため、心理的な起動コストが低い。
2026年3月のStitch 2.0アップデートでは、5画面同時生成機能が追加された。「登録→ホーム→詳細→確認→完了」という一連のフローを一度のプロンプトで生成できるこの機能は、特に「デモで複数の画面遷移を見せたい」という緊急ニーズに対して強力に機能した。
あの3時間の時系列
実際にあの3時間で何をしたかを記録する。
14:00〜14:20（最初の20分）：要件の整理とプロンプトの設計
まずワイヤーフレームと要件定義書を5分で読み直し、「デモで見せるべき画面」を特定した。全機能を見せる必要はない。先方が最も確認したい「コアフロー」だけに絞る。今回は「商品選択→カート→購入確認→完了」の4画面に決めた。
残り15分でプロンプトを書いた。「何を作るか」より「誰のためのどんな体験か」を先に言語化することに集中した。「30代の共働き夫婦が、スマートフォンで週末の食材をまとめ買いするECアプリ。操作ステップが少なく、迷わない動線を最優先に」という基本コンテキストを書き、4画面のフロー説明を続けた。
14:20〜15:00（次の40分）：生成と修正のサイクル
Stitchに最初のプロンプトを入力した。5画面同時生成で4画面（＋トップページ）が出てきた。最初の生成結果を見た瞬間の正直な感想は「思ったより良い。でも3箇所直したい」だった。
修正は「致命的なもの」から順番に対処した。先方が見て誤解を生む可能性のある要素——英語テキストの混入、サービスのコンセプトとズレたボタンラベル、情報の優先順位が逆になっているセクション——をリストアップし、修正プロンプトを順番に入力した。
「微妙に違う気がする」程度の細部は潔く無視した。デモ用のUIに完成度100%は不要だ。「先方が見て、サービスの方向性が伝わる」というラインを基準に判断した。
15:00〜15:40（次の40分）：スライドへの組み込みと文脈整理
生成した画面をスクリーンショットで書き出し、プレゼンスライドに組み込んだ。各画面に「この画面では〇〇ができます」という1行の説明キャプションと、「AIが生成したデザインラフ案（未確定）」という但し書きを加えた。
画面の繋がりを示す簡単な遷移図も1枚作った。PowerPointで5分で作った矢印だけのフロー図だが、「画面の流れ」を見せることでデモの理解度が大きく変わることを過去の経験で知っていた。
15:40〜16:40（次の1時間）：バッファと想定質問の準備
スライドが完成した時点で残り80分。想定質問への回答を準備し、「この画面はまだ検討中です」と言えるポイントを整理した。Stitchのデモ用UIには「ここはまだ決まっていない」という部分が必ず存在する。それを事前に把握しておくことで、当日の場のコントロールができる。
17:00 デモ当日
先方の反応は「想像より具体的で驚いた」だった。「こんな短期間でここまで」という言葉をいただいたが、内心では「Stitchがなければ絶対間に合わなかった」という気持ちだった。
緊急時にStitchを使うときの判断基準
「何を見せるか」の絞り込みが全て
緊急時にStitchを使うとき、最も重要なのは「何を見せるか」の絞り込みだ。
全機能・全画面を作ろうとすると、時間が足りなくなる。緊急時のデモには「コアフロー1〜2本」で十分なことが多い。先方が確認したいのは「このサービスで何ができるか、体験の流れはどうか」であり、全ての機能を網羅する必要はない。
絞り込みのコツは「先方がこのデモで何を決断するか」を逆算することだ。今日のデモで「進める/止める」を判断するなら、判断に必要な情報だけを見せる。「方向性の確認」なら「雰囲気が伝わる画面」だけで十分だ。
「完璧」を諦めるための判断ライン
緊急時のStitch使用で最も難しいのは「どこで妥協するか」の判断だ。
私が使っている判断ラインは「先方が見て誤解が生まれないか」だ。誤解を生む要素——間違った情報、ブランドイメージと大きくズレたビジュアル、ないはずの機能が「ある」ように見える画面——は必ず修正する。それ以外の細部は「次回以降に改善」と割り切る。
「完成度」より「正確性」を優先する——これが緊急時のUIデモの鉄則だ。
緊急対応後に気づいたこと
あのデモが終わった後、私はいくつかのことを考えた。
一つは「Stitchがなければ確実に断っていた」という事実だ。3時間でデモ用UIを揃えることは、Stitchなしでは不可能だった。ツールが「できない」を「できる」に変えた体験は、使い方の幅を実感させてくれた。
もう一つは「緊急対応の経験が、通常の制作の優先順位感覚を研ぎ澄ます」ということだ。3時間という制約の中で「何が本当に必要か」を判断し続けた経験は、通常のデザインプロセスにも活きた。「完成度への執着」より「目的に対する正確性」を優先する判断力は、緊急時の経験から学んだものだ。
そして「Stitchを使う体験は、プレゼンのスキルとセットで磨くべきだ」という気づきもあった。どれだけ良いUIを作っても、「なぜこうした」を言語化してデモの場でコントロールできなければ、その価値は半減する。UIの生成技術と、プレゼンの文脈設計力は、セットで向上させるべきものだ。
失敗したこと・気をつけるべきこと
1. 最初の30分を「プロンプト完璧化」に使いすぎた
最初のプロンプトを丁寧に書こうとして、生成を始めるまでに30分かかった時点があった。緊急時は「とりあえず生成してみる→修正する」のサイクルの方が速い。完璧なプロンプトを追い求めるより、70点の状態で素早く出して修正を重ねた方が効率的だった。
2. 修正のプライオリティを間違えた
最初の修正で「フォントの細かい調整」から始めてしまい、致命的な問題（英語テキストの混入・ボタンラベルのズレ）に後から気づくという失敗があった。緊急時の修正は必ず「誤解を生む可能性の高い順」で対処すべきだった。細部の調整は最後に行うか、時間がなければ潔く諦める。
3. バッファ時間を少なく見積もった
「2時間でUI作成、1時間でスライド準備」と計画したが、実際にはUI作成に2時間20分かかり、スライド準備が40分になった。緊急時はツールの使用時間に20〜30%のバッファを見込んでおくことが必要だった。Stitchの生成時間・修正時間・スクリーンショット取得・スライド組み込みは、それぞれ想定より長くなりやすい。
4. 「AIが生成したラフ案」の注釈を入れ忘れかけた
時間のプレッシャーで、スライドに「これはAIが生成したデザインラフ案です」という注釈を入れることを忘れかけた。後から追加したが、これを省略するとデモ後に「あのデザインはもう確定しているんですよね」という誤解が生まれるリスクがある。緊急時ほど「文脈の注釈」を省かないことが重要だ。
5. デモ後の「次のステップ」を準備していなかった
先方の反応が良く、その場で「次はいつ詳細を見せてもらえますか」という質問が来た。その場で答えられる「次のステップ」を準備していなかったため、曖昧な返答になってしまった。デモが成功した後のことを想定して「次のアクション」を準備しておくことも、デモ準備の一部だった。
よくある質問（FAQ）
Q1. Stitch で3時間以内にデモ用UIを作ることは本当に可能ですか？
可能です。ただし「見せる画面を2〜5画面に絞る」「完成度より正確性を優先する」「細部の修正は割り切る」という条件が必要です。全機能を網羅しようとすると間に合いません。コアフローだけを絞り込み、「方向性が伝わる品質」を目標にすれば、経験者であれば2〜3時間で十分対応可能です。
Q2. 緊急時に使う場合、事前にどんな準備をしておくべきですか？
「サービスの基本コンテキストのプロンプトテンプレートを持っておくこと」が最も有効です。「誰のための、どんなサービスか」を記述した基本プロンプトを事前に用意しておくと、緊急時にそれをベースにして素早く追記できます。また「よく使う修正プロンプトのパターン」（テキストを日本語化して、CTAを1つに絞って、余白を増やして）をメモしておくと修正フェーズが速くなります。
Q3. Stitch の5画面同時生成は緊急時に有効ですか？
非常に有効です。「登録→ホーム→詳細→確認→完了」のようなフロー全体を一度に生成できるため、個別に作るより大幅に速くデモ素材が揃います。ただし5画面全てが100%意図通りに出ることは稀なので、最も重要な2〜3画面を優先的に修正し、残りは「参考程度」として提示する使い方が実践的です。
Q4. 緊急デモの後、先方への正直な説明は必要ですか？
必要です。「これはAIが生成したデザインラフ案で、今後Figmaで詳細を作り込みます」という説明は、デモの場でも、デモ後のフォローでも明確に伝えるべきです。先方が「あのデザインが最終形」と認識したまま進むと、後で大きな認識のズレが生まれます。誠実な説明は短期的なリスクより長期的な信頼を守ります。
Q5. 緊急時のStitch使用で品質を担保するための最低限のチェックは？
3点に絞るとすれば、「テキストが日本語で正確か」「ないはずの機能が『ある』ように見えていないか」「ブランドカラーや雰囲気が大きくズレていないか」です。これら3点だけでも確認してから見せると、誤解を防ぐことができます。時間がある場合は「誰かに1分見せて、印象を聞く」という第三者チェックも有効です。
Q6. 緊急対応の経験は、通常の制作にも活きますか？
活きます。特に「優先順位の判断力」と「妥協ラインの設定能力」は、緊急時の経験から磨かれます。通常の制作では「完成度」を追い求めるあまり、本来不要な細部に時間をかけてしまうことがあります。緊急時に「何が本当に必要か」を判断し続けた経験は、通常時の制作効率にも好影響を与えます。
Q7. Stitch を「緊急時専用」として使うことに問題はありますか？
問題はありませんが、緊急時だけに使うと「Stitchの特性と限界」を把握しないまま使うことになり、緊急時の失敗リスクが高まります。日常的に使い続けることで「このプロンプトでこういうUIが出やすい」「この修正は時間がかかる」という感覚が身につき、緊急時にも冷静に対処できるようになります。Stitchは「普段から使い慣れておく」ことで緊急時の武器になります。
Q8. デモ用UIをStitchで作ることは、クライアントへの誠実さに欠けますか？
誤解を招く形で使えば問題になりますが、適切な文脈説明と合わせて使えば誠実さに欠けません。「AIが生成したラフ案である」「方向性の確認が目的である」「これから詳細を作り込む」という3点を明示したうえで提示することで、クライアントは適切な期待値で見ることができます。ツールの種類より「正直に使うこと」が誠実さの基準です。
まとめ
あの3時間は、Google Stitch というツールへの信頼感を一段階上げた体験だった。
「間に合わない」が「できた」に変わったのは、ツールの力だけではない。「何を見せるかを絞る判断」「完成度より正確性を優先する割り切り」「プレゼンの文脈設計」——これらが組み合わさって、初めて3時間のデモ準備が成立した。
緊急時にStitchを使うために覚えておくべきポイントは以下の通りだ。
- 見せる画面を2〜5画面のコアフローに絞り込む
- 完璧なプロンプトより「70点で出して修正」のサイクルを回す
- 修正は「誤解を生む可能性の高い順」で対処する
- 「AIが生成したラフ案」という注釈は省かない
- デモが成功した後の「次のステップ」も事前に準備する
Stitchを「普段から使い慣れておく」ことで、緊急時に初めてその本領が発揮される。あの3時間の経験が教えてくれたのは、ツールへの信頼は「使い続けること」でしか生まれない、というシンプルな事実だった。
