Google Stitch でプロンプトを書き続けて、自分の「デザイン語彙」が増えていった話

2026.04.16

クライアントに Google Stitch で

作った画面を見せた日——

予想外だった反応と、そこから学んだこと

Google Stitch を使い始めたばかりのころ、私のプロンプトはこんな感じだった。

「ホーム画面を作って」「ログイン画面を作って」「一覧ページを作って」

生成されたUIは、それなりのものが出てきた。でも何かが違う。「こうじゃないんだけど、どう言えばいいんだろう」と感じながら、何度も再生成を繰り返していた。

あれから半年以上が経った今、私のプロンプトはこうなっている。

「情報密度を抑えた、呼吸感のあるレイアウト。ナビゲーションは最小限。CTAは1画面に1つだけ。ユーザーが迷わない動線を最優先に、余白をコンテンツとして扱って」

プロンプトの変化は、単なる「慣れ」ではない。Stitchを使い続けることで、私の中に「デザイン語彙」が蓄積されていったのだ。この記事では、その変化の過程と、語彙が増えることで何が変わるかを書く。

結論から言うと、Google Stitch を使い続けることは「UIを生成する練習」であると同時に、「デザインを言語化する訓練」でもある。プロンプトを書くたびに「自分が何を求めているか」を言葉にする必要があり、その積み重ねが設計思考の言語化力を高める。これはAIへの指示に留まらず、チームやクライアントへの説明能力にも波及していった。

「デザイン語彙」とは何か

「デザイン語彙」とは、デザインの意図や方向性を言葉で表現するための語彙のことです。「カッコいい感じで」「シンプルに」だけでは伝わらない、もう一段具体的な言語化の能力を指す。

Stitchを使う前、私はデザインの「感覚」を持っていたが、それを言葉にする力が弱かった。「なんかこう、もっと洗練された感じ」「ちょっとうるさい気がする」——このような感覚的な表現しかできなかった。

Stitchのプロンプトでは、その感覚を必ず言語化しなければならない。「洗練」の正体は何か。「うるさい」の逆は何か。そういった問いを繰り返すうちに、デザインを説明する語彙が自然と増えていった。

プロンプトが変わった3つのフェーズ

Stitchを使い始めてから今日まで、プロンプトには明確な変化のフェーズがあった。

フェーズ1：要素の羅列（使用開始〜1ヶ月）

「ヘッダー、メインビジュアル、ボタン、リスト」のように、画面に含める「部品の名前」を並べるプロンプトだった。生成結果は平均的なUIで、意図を正確に反映していないことが多かった。このフェーズでは「何を置くか」しか伝えられていなかった。

フェーズ2：目的の言語化（1〜3ヶ月）

「このボタンでユーザーに次の行動を促したい」「最初に見た瞬間に信頼感を感じてほしい」のように、各要素の目的や意図を加えるようになった。生成結果の精度が上がり、「こういう画面が作りたかった」というものが出てきやすくなった。

フェーズ3：文脈と感情の言語化（3ヶ月以降）

「初めて訪れたユーザーが5秒以内に『このサービスは自分向けだ』と感じるレイアウト」「疲れ気味のユーザーが夜に見ても目に優しいトーン」のように、ユーザーの文脈や感情状態まで含めた記述に変わった。このフェーズになると、生成されるUIが「ただ機能する画面」から「意図を持った画面」に変わっていった。

増えていった語彙の具体例

Stitchを使い続けて蓄積された「デザイン語彙」の具体例を挙げると、以下のようになる。

レイアウト・空間に関する語彙

呼吸感のあるレイアウト（= 余白を十分に取り、情報が詰まっていない印象）
余白をコンテンツとして扱う（= 空間自体がデザインの一部）
情報密度を下げる（= 一画面に詰め込む要素を減らす）
視線の自然な流れに従った配置（= F型・Z型などの視線誘導に沿った構成）

色・トーンに関する語彙

ウォームトーン（= 赤・オレンジ・黄系の温かみのある色味）
クールトーン（= 青・紫・グレー系の清潔感・クールな印象）
彩度を落とした落ち着いた配色（= 派手すぎない、目に優しい色調）
アクセントカラーを絞る（= 強調色は1色のみ使用）

インタラクション・動線に関する語彙

1画面1アクション（= 1つの画面でユーザーに求めることは1つだけ）
CTAの優先度を明示する（= 主要なボタンと補助的なボタンを視覚的に差別化）
迷子にならない動線（= どこに進めばいいかが常に明確）
離脱ポイントを減らす（= ユーザーが途中でやめたくなる摩擦を取り除く）

語彙が増えると何が変わるか

デザイン語彙が増えたことで変わったのは、Stitchへのプロンプトだけではなかった。

最も大きな変化は、チームやクライアントへの説明力だ。以前は「なんかここが違う気がする」としか言えなかった場面で、「ここはCTAの優先度が曖昧で、ユーザーがどのボタンを押すべきか判断できない状態になっている」と具体的に言えるようになった。

デザインレビューの質も変わった。「なんとなくいいと思う」「なんとなく気になる」という感覚的なコメントから脱して、「情報密度が高すぎてスキャンしにくい」「このセクションは視線の流れと逆方向に要素が並んでいる」といった根拠のあるフィードバックができるようになった。

エンジニアやライターとの協働も変わった。「こういう雰囲気で」という曖昧な指示ではなく、「余白は56px、フォントサイズはボディ16px、アクセントカラーは1色だけ使う」といった具体的な指定ができる。これは実務上の摩擦を大きく減らした。

語彙を増やすためにやっていたこと

意識的にやっていたわけではないが、振り返ると語彙を増やすために効果的だったのは以下の習慣だった。

一つ目は「言い換えのサイクル」だ。Stitchで生成されたUIが意図と違うとき、単に「やり直して」と言うのではなく「何が違うのかを言語化してから次のプロンプトを書く」を徹底した。これが最も語彙を増やす訓練になった。

二つ目は「優れたUIの言語化」だ。日常で「このUIがいいな」と感じたとき、スクリーンショットを撮ると同時に「なぜいいと感じたか」を言葉にするメモを残すようにした。「余白が広い」ではなく「コンテンツ間の余白が一定で、画面全体に一定のリズムがある」という形で。

三つ目は「Stitchの失敗を記録すること」だ。プロンプトAで生成したUIと、プロンプトBで生成したUIを並べ、「なぜBの方が意図に近かったか」を分析した。この差分分析が、言語化の精度を高める最速の方法だった。

デザイン語彙の増加がもたらした思わぬ副作用

「批評家目線」が強くなりすぎた問題

語彙が増えることで、日常の中でUIの「欠点」が目につきやすくなった。コンビニのセルフレジで「このボタン配置は1画面1アクション原則を破っている」と考えてしまったり、飲食店の注文タブレットを見て「CTAの優先度が全部同じで迷子になる」と感じたり——半分は職業病として楽しんでいるが、「ただの外食」が「UIの品評会」になる感覚は、良し悪し両方ある。

実際に使ってみてわかったのは、「言語化できること」と「良いデザインを作れること」は別の能力だということだ。語彙が増えると「何が問題か言える」ようになるが、「どう解決するか」はまた別の練習が必要だ。Stitchはその解決策を試す場として最適だが、語彙の増加を「デザイン力の向上」と同一視しないよう注意が必要だった。

「完璧なプロンプト」を追い求めた時期のこと

語彙が増えてきたある時期、私は「完璧なプロンプトを一発で書ければ、一発で完璧なUIが出るはず」という発想に陥った。プロンプトを30分かけて精緻化して、長文の仕様書のようなものを書いてから生成を実行する——そんな使い方をしていた時期がある。

結果はどうだったか。確かに精度は上がった。しかし、プロセスとして非効率だった。Stitchの最大の強みは「速く作って、見て、直す」のサイクルの速さにある。長文プロンプトを作るコストが、Stitchを使うメリットを相殺していた。

気づいたのは、「語彙を持つこと」と「語彙を全部プロンプトに詰め込むこと」は違うということだ。語彙があるから「必要な言葉を選べる」のであって、「持っている語彙を全部使う」のが目的ではない。適切な密度のプロンプトを書く判断力こそ、積み重ねた経験が活きる場所だった。

失敗したこと・気をつけるべきこと

1. 「正しい言葉」にこだわりすぎて手が止まった

語彙が増えてくると、「より正確な表現」を探しすぎてプロンプトを書く手が止まる場面が増えた。最初の1〜2ヶ月はむしろ語彙が少ない方が「とにかく出してみる」サイクルが回っていた面もある。語彙は武器だが、「まず試す」という行動力を失わないよう意識が必要だった。

2. 語彙が「専門用語の羅列」になっていた時期がある

「F型視線誘導に従った情報アーキテクチャ、1画面1アクション原則、スキャナビリティを最大化した情報階層」——こんなプロンプトを書いていた時期がある。Stitchは意外にも、専門用語より「ユーザーの状況と気持ち」を自然言語で説明した方が意図に近いUIを生成することが多かった。

3. チームへの「語彙の展開」を忘れていた

自分の語彙は増えたが、チームメンバーへの共有が遅れた。「呼吸感のあるレイアウト」「1画面1アクション」が自分の中では当たり前になっても、チームには伝わっていなかった。語彙の共有・共通言語化は、チームでStitchを使うなら必須の取り組みだと後から気づいた。

4. 語彙に依存して「見る力」が落ちた時期があった

言語化ができるようになると、UIを「言葉で分析する」ことが先に来て、「見て感じる」という感覚的な受け取り方が弱くなる時期があった。UIデザインには言語化できない「なんとなく良い」という感性も大切で、語彙と感性のバランスを意識的に保つ必要がある。

5. 他のツールに語彙を活かすのに時間がかかった

Stitchで積み上げた語彙を、FigmaやAdobe XDでの作業に活かすには、追加の実践が必要だった。語彙はツールに依存しないはずだが、「Stitch文脈の言語化」と「Figma作業の言語化」には微妙なズレがある。語彙を汎用化するには、複数ツールでの意識的な適用練習が必要だった。

よくある質問（FAQ）

Q1. デザイン経験がなくてもプロンプトの語彙は増えますか？

増えます。むしろデザイン未経験の方がゼロから語彙を作るため、変化が大きく感じられることが多いです。最初は「なんかいい感じに」程度のプロンプトで始めても、「なぜこのUIが自分の意図と違うのか」を繰り返し考えるうちに、自然と語彙が蓄積されます。重要なのはデザインの知識より「なぜそう感じるかを言葉にする習慣」です。

Q2. どのくらい使えば語彙が増えていると実感できますか？

個人差はありますが、週に3〜4回Stitchを使って1〜2ヶ月後に「以前より具体的にプロンプトを書けている」と感じる人が多いです。劇的な変化より「気づいたら使う言葉が変わっていた」という変化の方が多く、振り返ったときに気づくことがほとんどです。

Q3. Stitch 以外でも「デザイン語彙」は増やせますか？

増やせます。ただStitchは「すぐ試して結果が見える」というサイクルの速さが語彙の定着を早める点で優れています。デザインの本を読んでも語彙は増えますが、「この言葉を使うと何が生成されるか」という実体験との結びつきがないと、語彙が実践で使えないことも多いです。Stitchは学習とアウトプットが同時に起きるツールです。

Q4. プロンプトで意図が伝わらないとき、どう改善すればいいですか？

最も効果的なのは「何が違うか」を最初に言語化することです。「なんか違う」で再生成するのではなく、「色調が想定より暗い」「ボタンが多すぎて主要アクションが埋もれている」「余白が均一ではなく場所によってばらばらに見える」のように差分を具体化してから次のプロンプトを書くと、改善の精度が上がります。

Q5. プロンプトは日本語と英語どちらで書く方が良いですか？

どちらでも機能しますが、日本語のプロンプトは「ユーザーの状況や感情」を記述するのに向いており、英語は「デザイン仕様・数値・技術的な指定」に向いています。実際に使ってみて感じるのは、「シニア向けの操作が少ないシンプルなUI。文字は大きく、タップ領域も広めに」のような自然言語日本語プロンプトが、専門用語英語より意図に近い結果を返すことが多いということです。

Q6. チームで語彙を統一するにはどうすればいいですか？

最も実践的な方法は「チームのプロンプト集を作ること」です。メンバーが使って効果的だったプロンプトの表現をドキュメント化し、共有するだけで「語彙の共通言語化」が進みます。週次の振り返りで「今週一番うまくいったプロンプト」を共有する時間を設けると、語彙の蓄積がチーム全体のものになっていきます。

Q7. デザイン語彙はビジネスの場でも使えますか？

非常に使えます。特にクライアントへの提案や、エンジニアとの仕様確認、マーケターとのLP設計ディスカッションなど、デザインを他職種の人に説明する場面で力を発揮します。「なんとなくシンプルに」ではなく「1画面に含める情報を3項目以内に絞り、主要なCTAを1つだけ配置する」と言えると、指示の解釈ズレが大幅に減ります。

Q8. プロンプトの語彙が増えた後も、Stitchの使い方は変わり続けますか？

変わり続けます。語彙が増えると「試したいこと」も増えるため、Stitchの使い方の幅が広がります。また新しい機能（Voice CanvasやDesign System Importなど）が追加されると、それに対応した語彙・表現も追加で必要になります。Stitchを使い続けることは語彙の「完成」ではなく「継続的な拡張」のプロセスです。