AI を使って画面案を作ること自体は、もう珍しくなくなってきました。ただ、実際に触ってみると、毎回少しずつ雰囲気が変わったり、ブランドのトーンが揃わなかったりして、「早いけれど整わない」と感じる場面もあります。
そんなときに役立つのが、Google Stitch と design.md の組み合わせです。Stitch は、テキストや画像から UI デザインやフロントエンドコードを素早く生成できる Google Labs の実験的プロダクトで、複数案の比較や、Figma への接続まで見据えた流れを用意しています。 一方で design.md は、色や書体、コンポーネントの役割といったデザインルールを文章で整理し、AI に「どういう見た目で作るべきか」を伝えるための設計文書です。
この記事では、design.md と Google Stitch を一緒に使うと何が変わるのか、どこから試すとよいのかを、やわらかく整理してみます。
Stitch でできること
Google Stitch のわかりやすい魅力は、思いついた画面のイメージを、UI のたたき台に変える速さにあります。Google の公式説明では、Stitch は自然言語による指示だけでなく、画像やワイヤーフレームからも UI を生成できます。また、案を何度か作り直しながら比較したり、Figma に貼り付けたり、フロントエンドコードとして出力したりできる点も特徴です。
この性質は、ゼロから手を動かす前の探索フェーズと相性がよく、たとえば「落ち着いた雰囲気の LP にしたい」「もう少し親しみやすくしたい」といった抽象度の高い要望を、まず形にしてみる用途に向いています。最初の一案を出すスピードが上がるので、会話の起点をつくりやすくなります。
プロンプトだけではぶれやすい
一方で、プロンプトだけに頼ると、AI はその場の言葉から雰囲気を推測して画面を作ります。そのため、ある画面では上品に見えても、別の画面では急にポップになったり、ボタンや見出しの扱いが微妙に揃わなかったりすることがあります。
ここで design.md の出番です。Google は公式ブログの中で、Stitch の DESIGN.md は、プロジェクト間でデザインルールを export / import できる形式であり、Stitch がそのデザインシステムの「理由」を理解することで、ブランドに合った UI を生成しやすくなると説明しています。 さらに、Google はこの DESIGN.md のドラフト仕様をオープンソース化し、単一のツールに閉じない共有可能なビジュアル言語として広げようとしています。
つまり design.md は、単なるメモではありません。AI に対して「この色は何のために使うのか」「このフォントはどんな印象を担うのか」「ボタンはどれくらい目立たせるのか」といった判断基準そのものを渡す文書だと考えると、かなりイメージしやすくなります。
何が変わるか
design.md を使うメリットは、画面の見た目を固定することではなく、判断の軸を揃えられることにあります。たとえば、同じ「親しみやすいデザイン」という言葉でも、丸みの強いポップな UI を想像する人もいれば、やさしい余白で安心感を出す UI を想像する人もいます。design.md があると、その曖昧さを減らせます。
| 比較観点 | プロンプトだけで進める場合 | design.md を併用する場合 |
| トーンの再現 | その都度ぶれやすい | 文章化したルールに寄せやすい |
| 複数画面の整合性 | 画面ごとに差が出やすい | 色・書体・部品ルールを揃えやすい |
| 修正指示 | 「もう少しそれっぽく」が増えやすい | どのルールを直すかで会話しやすい |
| 再利用性 | 毎回ゼロから説明しがち | 別案件や別ページにも流用しやすい |
実務では、この「毎回ゼロから説明しなくてよくなる」ことがかなり大きいです。特に、ブランドの雰囲気を大切にしたい案件や、ページ数が増える案件では、design.md があるだけで会話の手戻りが減ります。
最初に書くこと
design.md を立派な仕様書にしようとすると、最初の一歩が重くなってしまいます。まずは、色・書体・レイアウト・コンポーネント・やってほしくないことの5つくらいに絞るのがおすすめです。
たとえば、次のような内容があるだけでも、AI の解釈はかなり安定します。
| 項目 | 最初に書いておくとよい内容 |
| Overview | プロダクト名、対象ユーザー、画面の目的 |
| Colors | ベース色、アクセント色、避けたい色 |
| Typography | 見出しと本文の書体、印象の方向性 |
| Components | ボタン、カード、フォームの扱い |
| Do’s / Don’ts | やってほしいこと、避けたい表現 |
ここで大切なのは、完璧さよりも判断の言葉を入れることです。たとえば「青を使う」だけでなく、「CTA を目立たせるために使う」と書くほうが、AI に意図が伝わりやすくなります。
小さく試す
運用のイメージとしては、最初から大規模に導入する必要はありません。まずは 1 ページの LP や、キャンペーンページのような小さな単位で、design.md を添えて Stitch に渡してみるのが現実的です。
おすすめの流れは、まず作りたいページを自然言語で簡単に説明し、その後で design.md で色やトーンを補正するやり方です。最初の生成結果を見ながら「想像より硬い」「少し明るすぎる」と感じたら、プロンプトを増やすより design.md 側を直すほうが、次の案に一貫性が出やすくなります。
この進め方だと、Stitch を単なる UI 自動生成ツールとしてではなく、デザイン判断を言語化して育てる場所として使いやすくなります。結果として、生成 AI を使っているのに、チームのデザイン理解がむしろ深まる、という良い循環が生まれます。
運用のチェックポイント
自社で design.md と Stitch を使うときは、見た目の完成度だけでなく、次の観点を見ておくと運用しやすくなります。
| 観点 | 確認したいこと |
| 一貫性 | 別ページでも同じブランドトーンが保てるか |
| 修正しやすさ | デザイン変更時に、プロンプトではなくルール側で直せるか |
| 共有しやすさ | デザイナー以外にも意図が伝わる文章になっているか |
| 拡張性 | 今後ページが増えても流用できる粒度になっているか |
特に、社内で複数人が関わる場合は、design.md があることで「なんとなくこの雰囲気で」という属人的な依頼から少し離れやすくなります。言葉で共有できる設計ルールがあると、AI に対しても、人に対しても、説明がしやすくなります。
まとめ
Google Stitch は、UI の最初の一案を早く出すのが得意なツールです。そして design.md は、その一案を自分たちらしい方向へ揃えるための土台になります。
AI に任せる部分が増えるほど、逆に「何を固定したいのか」を言葉にしておく重要性は高まります。design.md は、そのためのちょうどいい器です。まずは難しく考えすぎず、小さなページひとつ分から試してみると、使いどころがかなり見えてくるはずです。
もしこれから社内で試すなら、最初のゴールは「完璧な design.md を作ること」ではなく、1回修正しても崩れにくい UI の土台を作ることに置くと、導入しやすいと思います。
References
[1] From idea to app: Introducing Stitch, a new way to design UIs – Google Developers Blog
[2] Stitch app’s DESIGN.md format is now open-source for designers – Google Blog
コメント