Google Stitch を使い始めたとき、思ったより早く「使いこなせている」気になった。プロンプトを入力すればUIが出てくる。それだけで十分すごいじゃないか、と。でも実際に仕事に使おうとすると、何か足りない。「なんか違う」が続く。何度試しても「惜しいけど使えない」UIが出てくる。
それが数週間続いて、ようやく気づいた。失敗には「型」がある。同じパターンの間違いを繰り返していただけだった。この記事では、私が Google Stitch で繰り返した5つの失敗とそこから学んだことを書く。同じところで詰まっている人に届いてほしい。
結論から言うと
Google Stitch がうまくいかない原因のほとんどは「ツールの問題」ではなく「プロンプトの設計の問題」だった。具体的には、①プロンプトが抽象的すぎる、②出力を完成品として扱おうとしている、③修正指示が感情的で具体性がない——この3つが大半の失敗の根本原因だった。逆に言えば、これを直すだけで使える場面が一気に広がる。
失敗その1：プロンプトが「一言」だった
最初の頃、私のプロンプトはこんな感じだった。「スタイリッシュなランディングページ」「医療アプリのホーム画面」「シンプルなダッシュボード」——一言から数語。これで良いUIが出ると思っていた。
出てくるものは悪くない。でも「どこかで見たことがある汎用デザイン」という印象を拭えなかった。修正しようとしても「もっとかっこよくして」という曖昧な指示しか出てこない。結果、同じようなUIが何パターンも並んで、どれも「惜しい」で終わる。
学んだこと：プロンプトは「デザインブリーフ」だ。良いデザインブリーフには最低でも「誰のための」「何のための」「どんな印象を与える」の3要素が入っている。この3つをプロンプトに盛り込むだけで、出力の質が一段階上がる。
一言プロンプトから脱出するための習慣
具体的な改善策として、プロンプトを書く前に「5W1H」を自問する習慣を付けた。誰が使うのか（Who）、何のために使うのか（What）、どんな状況で使うのか（When/Where）、なぜこの画面が必要なのか（Why）、どうやって使うのか（How）。全部答える必要はないが、少なくとも「Who」と「What」は必ず書くようにした。
例えば「医療アプリのホーム画面」を「40代の慢性疾患患者が毎朝確認する服薬管理アプリのホーム画面。今日の服薬リスト・体調記録ボタン・医師へのメッセージ機能が中心。安心感と見やすさが最優先」に変えると、まったく違うUIが出てきた。
「言葉が多いと良い」という誤解
ただし、プロンプトは長ければ良いわけでもない。矛盾する要件を詰め込んだり、関係のない情報を大量に入れたりすると、Stitch が混乱した結果を出すことがある。「ミニマルでシンプルなのに、情報量が多く機能豊富なダッシュボード」のような矛盾は、Stitch にとって処理しにくい。長いプロンプトより「矛盾のない、具体的なプロンプト」の方が良い結果につながる。
失敗その2：出てきたUIをそのまま使おうとした
Stitch が出したUIを見て「いいな」と思ったとき、そのまま使おうとしたことが何度かある。結果は毎回「惜しいけど使えない」だった。フォントが実際のブランドと合わない、コンポーネントの間隔が微妙にバラついている、レスポンシブで崩れる——細部を見ると問題が出てくる。
Stitch の出力は「完成品」ではなく「たたき台」だ。この認識を最初から持っていればよかった。でも使い始めた頃は「AIが出したUIだからクオリティが高いはず」という過信があった。
学んだこと：Stitch のUIは「設計の方向性を決めるもの」であり、そこから先は自分の手で詳細を詰める必要がある。Figmaに持ち込んでコンポーネント化する、実際のブランドフォントやカラーに差し替える、実データをはめ込んで崩れを確認する——これらが必ずセットになる。
「たたき台」として使う思考シフト
Stitch の出力を「たたき台」と捉えてからは、使い方が変わった。完成に近い一つを求めるより、複数パターンを生成してそれぞれの「良い部分」を抽出する使い方が主流になった。Aのレイアウト＋Bのカラートーン＋Cのコンポーネント配置、という組み合わせを自分で作る。Stitch は「部品を提案してくれるツール」という位置づけが正確かもしれない。
クライアントへの見せ方の失敗
Stitch の出力をそのままクライアントに「デザイン案」として見せたことが一度あった。クライアントが「これで完成ですか？」という反応をしたとき、説明の手間が大幅に増えた。Stitch の出力であることを最初に伝え「ここから詳細を詰めます」という文脈を添えることが必要だと痛感した。Stitch はプロセスの中に存在するツールであり、成果物として扱うものではない。
失敗その3：修正指示が「なんか違う」止まりだった
最初のUIが出た後、修正しようとして壁にぶつかった。「なんか違う」「もっとシンプルに」「もう少しおしゃれに」——こういう言葉しか出てこなかった。Stitch はこういう曖昧な指示でもそれなりに動くが、期待した方向に進まないことが多かった。
問題は自分の側にあった。「なんか違う」と感じた理由を言語化できていなかった。デザインを見て感じる違和感を、具体的なUI要素の言葉に変換する力が足りなかった。
学んだこと：修正指示は「要素名＋状態＋理由」の形で書く。「ヘッダーのナビゲーションリンク間の余白が狭すぎて窮屈な印象。各リンク間に少なくとも24px以上のスペースを入れる」のように具体化する。「感情」を「仕様」に変換する習慣が、修正のサイクルを速める。
違和感を言語化するための「解剖習慣」
「なんか違う」を言語化するために取り入れたのが「解剖習慣」だ。気に入らないUIを見たとき、5つの視点から分解する。①レイアウト（配置・グリッド・余白）、②タイポグラフィ（フォントの種類・サイズ・太さ・行間）、③カラー（色の種類・比率・明度・彩度）、④コンポーネント（ボタン・カード・アイコンの形・サイズ）、⑤全体のトーン（硬い/柔らかい、モダン/クラシック）。この5つのどこが「違う」かを特定するだけで、修正指示が格段に具体的になった。
良いUIを見て「逆プロンプティング」する練習
修正指示の言語化力を上げるために効果的だった練習が「逆プロンプティング」だ。気に入ったUIを見つけたとき、それをプロンプトで再現しようとする。「このUIを生成するためにはどう書けばいいか？」を考えることで、UIの要素を言語化する力が自然に上がった。Dribbble やデザインの参考サイトを見ながらプロンプトを書く練習を週に数回続けるだけで、修正指示のクオリティが変わった。
失敗その4：一度で完成させようとした
使い始めの頃、「最初のプロンプトで完璧なUIを出そう」としていた。プロンプトを長く書き込んで、一発で理想通りのUIが出ることを期待した。うまくいかないと「このツールには限界がある」と感じていた。
でも考えてみれば、人間のデザイナーでも最初のスケッチで完成品は作らない。ラフ→フィードバック→修正→詳細化のサイクルが当たり前だ。Stitch でも同じプロセスを取ることが正しい使い方だった。
学んだこと：Stitch との作業は「対話」だ。最初のプロンプトは「会話の始まり」と捉える。出てきたUIを見て、良い部分を言語化し、変えたい部分を指示する。このサイクルを5〜10回回すことで、最初のプロンプトだけでは絶対に出なかったUIに辿り着く。「一発解」を求めず「対話を通じた収束」を目指すことがコツだ。
「保存」しながら進む習慣
対話を重ねる中で、「良かった中間案」を保存しておく習慣が大事だと気づいた。修正を重ねる中で、かえって最初の方が良かったということがある。方向性のAとBを両方持ちながら進むことで、行き過ぎた修正から戻れるようになった。
一度で完成させようとする心理の正体
なぜ「一発で完成」を求めてしまうか。振り返ると「修正をお願いすることへの申し訳なさ」のような感覚があった。人間のデザイナーへの依頼なら「何度も変更をお願いしては悪い」と感じるのと同じ心理が、AIに対しても出ていた。でも Stitch は何度修正してもコストも疲弊もない。この「AIに遠慮しなくていい」という認識を持ってから、使い方が変わった。
失敗その5：自分のブランドをプロンプトに入れなかった
汎用的なサービスのUI（ECサイト、ブログ、アプリ）を作るなら、Stitch は最初から良い結果を出す。でも「自分たちのブランドのUI」を作ろうとしたとき、出てくるものが「それっぽいけど自分たちじゃない」UIになりやすかった。
原因は、自社のブランドアイデンティティをプロンプトに入れていなかったことだ。ミッション、ターゲット、価値観、競合との差別化——これらをプロンプトに含めると、出てくるUIが「自分たちらしい」ものに近づく。ブランドをインプットしないと、汎用UIしか出ない。
学んだこと：新しいプロジェクトで Stitch を使い始める前に「ブランドプロンプト」を作る。これはそのプロジェクト専用のプロンプトの冒頭に置く定型文で、ターゲット・トーン・カラー・ブランドが連想させるもの（例：「Notionのようなミニマル感×Starbucksのような温かみ」）を含む。このブランドプロンプトを先に作っておくことで、各画面のプロンプトを書くときの質が安定した。
よくある質問（FAQ）
Q1. Google Stitch でうまくいかないときの最初の対処法は？
A. プロンプトに「ターゲットユーザー」を追加することが最初の対処法です。「誰のための画面か」が明記されていないプロンプトは汎用UIになりやすいです。たった一文「30代の共働き夫婦向け」のような追記で、出力の方向性が変わることが多いです。
Q2. 何回試しても良いUIが出ない場合はどうすれば？
A. プロンプトをいったんリセットして「一番シンプルな指定」から始めることをすすめます。複雑なプロンプトで行き詰まっているときは、要素を削ぎ落とした最小プロンプトで出力を確認し、そこから少しずつ要件を足していく方が結果的に早く到達できます。
Q3. 修正を繰り返していると最初より悪くなることがあります。どうすれば？
A. 修正途中の「良かった状態」を都度スクリーンショットやプロンプトとして保存しておくことが対策です。戻れるチェックポイントを作りながら進むことで、行き過ぎた修正からリカバリーできます。
Q4. Stitch のプロンプトを書くのが苦手です。どこから練習すれば？
A. 「好きなUIの言語化」から始めることをすすめます。Dribbble や使いやすいアプリのUIを見て「このUIをプロンプトで再現するなら何と書くか」を考える練習が、言語化力を最も効率よく上げます。最初は100%再現できなくても、繰り返すことで確実に精度が上がります。
Q5. 失敗を減らすために事前にやっておくべきことはありますか？
A. プロジェクト開始時に「ブランドプロンプト」を作っておくことが最も効果的でした。ターゲット・トーン・カラー・避けたいスタイルを1〜2段落にまとめた定型文を用意しておくと、各画面のプロンプトを書く際の土台になり、一貫性のある出力が安定して得られます。
Q6. Stitch の失敗から学んだ一番重要なことは何ですか？
A. 「Stitch は相棒であり、答えを出してくれる機械ではない」という認識です。プロンプトという形で自分の思考を整理してインプットし、出てきたものを評価・修正する——この往復が「使いこなす」の本質です。うまくいかないとき、原因はほぼ自分のインプット側にあります。ツールのせいにする前に、プロンプトを見直すことが最初の一手です。
まとめ——失敗は「使い方の地図」になる
Google Stitch での失敗を振り返ると、どれも「ツールが悪い」のではなく「自分の使い方に問題があった」という共通点がある。抽象的なプロンプト、完成品として扱う期待、感情的な修正指示、一発解を求める姿勢、ブランドをインプットしない習慣——これらを一つずつ直すだけで、使える場面が着実に広がった。
Stitch に限らず、AIツールとの関係はすべてこれに当てはまると思う。ツールの精度より、自分の問いの精度の方がアウトプットに影響する。失敗は「どう使えばいいか」の地図だ。詰まったとき、この記事に書いたパターンと照らし合わせてみてほしい。
