Google Stitch にブランドの「らしさ」を伝えようとして、デザインの「言語化」について考えた

2026.04.16

Google Stitch を使い始めた当初、私はある壁にぶつかっていた。

生成されるUIは「きれい」だった。整っていて、モダンで、どこかのSaaS製品のようなデザインが1分以内に出てくる。それ自体はすごいことなのだが、なにかが引っかかっていた。

「うちのサービスっぽくない」

チームで長年育ててきたブランドには、色があり、フォントがあり、余白の使い方があり、ボタンの角の丸みがあった。それは明文化されているものも、されていないものもあった。その「らしさ」を、Stitch が出してくれるUIは持っていなかった。

当然の話だ。私がStitchに伝えたのは「ダッシュボード画面を作って」というプロンプトだけで、ブランドのことは何も言っていなかった。

そこから始まったのが、「Stitch にブランドを教える」という試みだった。そしてその過程で、私は思っていた以上に深いところに迷い込んでいった。デザインの「言語化」という問題に。

結論から言うと——Google Stitch にブランドの一貫性を持たせるには、DESIGN.md というブランドルールファイルを用意するのが最も確実な方法だ。ただし、それを作るプロセス自体が「自分たちのブランドをどう言語化するか」という問いに向き合うことを求めてくる。その作業は、デザイナーにとっても非デザイナーにとっても、予想外に価値のある体験になった。

Google Stitch のブランド対応機能とは

Google Stitchとは、Googleが提供するAIネイティブなUIデザインツールで、自然言語や画像からUIを自動生成できるサービスです。Google Labs が開発し、2025年にリリース後、2026年3月19日には大幅な機能アップデート（Stitch 2.0）が行われました。

Stitch がブランドの一貫性に対応するための仕組みとして、主に以下の3つがあります。

DESIGN.md：ブランドの色・フォント・スペーシング・コンポーネントルールをMarkdownで記述した「設計仕様書」ファイル
Edit Theme：Generate ボタンから Edit Theme を選択し、カラーパレットやフォント・角丸を手動で変更できる機能
URLからのデザインシステム抽出：既存サイトのURLを貼り付けると、StitchがビジュアルデザインのRuleを解析してDESIGN.mdを自動生成する機能

この中でも特に強力なのが DESIGN.md だ。

DESIGN.md とは何か

DESIGN.mdとは、プロジェクトのブランドルール・デザインシステムをMarkdown形式で記述したファイルです。Google Stitch はこのファイルをUI生成の「制約条件」として読み込み、配色・タイポグラフィ・スペーシングがブランドに沿ったUIを生成します。2026年3月のStitch 2.0アップデートで追加された機能で、プロジェクト間でのインポート・エクスポートにも対応しています。

MindStudioの解説（2026年）によると、DESIGN.mdには以下の要素を記述できます：

プライマリーカラー・セカンダリーカラーの正確なHex値
セマンティックカラー（Error, Success, Neutral など）
フォントファミリーとタイポグラフィスケール
スペーシング値・ボーダー半径・シャドウ定義
ボタン・フォーム・カードなどのコンポーネントスタイル

実際に使ってみてわかったのは、このファイルが「AIへのブランド説明書」として機能するということだ。書けば書くほど、生成されるUIがブランドに近づいていく。

Edit Theme の使い方

DESIGN.md を作る前のステップとして、Edit Theme 機能も有効です。

Stitch のエディタで Generate ボタンをクリックし、続いて「Edit Theme」を選択すると、カラーパレット・フォント・角丸（Corner Radius）・ライト/ダークモードの設定画面が開きます。ここでブランドの基本色とフォントを入力しておくだけでも、生成されるUIのトーンはかなり変わります。

ただし Edit Theme はあくまでも「見た目の上書き」であって、余白の使い方やコンポーネントのスタイルポリシーまでは伝えられません。細かいブランドルールを浸透させるには、DESIGN.md が必要になります。

DESIGN.md を作るという体験

私がDESIGN.mdを初めて書いたのは、Stitchを使い始めて2週間目のことだった。

最初はシンプルに考えていた。「ブランドカラーを書けばいい」と。プライマリーカラー、セカンダリーカラー、背景色、テキスト色の4色だけをMarkdownに書いて貼り付けてみた。

たしかに、色は合っていた。でも、何か違う。ボタンが角ばりすぎている。フォントが太すぎる。全体的に「硬い」感じがする。

「うちのブランドは、もう少しやわらかい印象なんだよな」

そう思ったとき、気づいた。自分は「やわらかい印象」というのをStitchに伝えていない。それどころか、「やわらかい印象」を具体的にどう定義するか、自分自身もちゃんと言語化できていなかった。

ブランドの「感触」を言葉にする作業

「やわらかい」を言語化しようとすると、いくつかの要素に分解できることがわかってきた。

ボーダー半径：sharp（0px）→ rounded（8px）→ pill（9999px）のどれか
シャドウ：強い立体感ではなく、うっすらとした柔らかいドロップシャドウ
フォントウェイト：400（Regular）か500（Medium）を主体に使い、700（Bold）は見出しのみ
余白：要素間のスペースを広めにとり、詰め込まない
ボタンの形：角丸8pxで、サイズは少し大きめ（padding 12px 24px程度）

これをDESIGN.mdに書いていくと、Stitchが生成するUIが少しずつ「うちらしく」なっていった。

URLからDESIGN.mdを自動生成する方法

自分でゼロから書くのが大変な場合、StitchのURL解析機能が役立ちます。

既存のブランドサイトやWebサービスのURLをStitchに貼り付けると、AIがそのビジュアルデザイン言語を解析し、DESIGN.mdの下書きを自動生成してくれます。2026年3月のStitch 2.0アップデートでこの機能が強化されており、実際に試してみると精度は相当高かった。カラーパレット・タイポグラフィ・スペーシング・コンポーネントスタイルをまとめて取り出してくれます。

ただし、自動生成されたDESIGN.mdは「現在のサイトを説明する文書」であって、「これからのブランドルール」とは少し異なります。特にリブランディング中だったり、サイトとアプリのUIが統一されていないケースでは、自動生成の結果をそのまま使うのは注意が必要でした。

試行錯誤でわかったDESIGN.mdの書き方

実際に数ヶ月間、DESIGN.mdを育ててきて気づいたことをまとめます。

具体的な数値で書く

「やわらかい印象」「プロフェッショナルな雰囲気」のような形容詞は、AIには伝わりにくいです。

伝わりにくい例：「ボタンは丸みがあって、親しみやすい印象にしてください」

伝わりやすい例：「Button: border-radius 8px, padding 12px 24px, font-weight 500, background #2A5FD8, hover state: background #1E4FC2」

Stitch に限らず、AIにデザインの意図を伝えるときは、最終的に「数値で表現できる形」まで落とし込む必要があります。その作業そのものが、ブランドの言語化なのだと気づきました。

優先順位をつける

DESIGN.mdにすべてを詰め込もうとすると、Stitchが混乱する場面がありました。特にコンポーネントスタイルの記述が多くなると、生成結果がブレることがあります。

実際に使ってみてわかったのは、「これだけは絶対に守ってほしい」ルールと、「できればこうしてほしい」ルールを分けて書くと生成品質が安定するということです。

優先度の高いルール（必ず守ってほしいもの）：

プライマリーカラー・セカンダリーカラーのHex値
フォントファミリー（Google FontsのNoto Sans JPなど）
ボタンのボーダー半径

優先度の低いルール（ガイドライン程度のもの）：

ホバーステートの細かい挙動
アイコンのスタイル（Outlined / Filled）
アニメーションの速度

この使い分けをするようになってから、生成結果の品質が安定しました。

ブランドの「禁止事項」も書く

「〜してください」だけでなく、「〜しないでください」を書くと効果的でした。

「グラデーション背景は使用しない」
「ドロップシャドウは最大でも box-shadow: 0 2px 8px rgba(0,0,0,0.12) まで。それ以上の強い影は使わない」
「赤色はエラー表示以外に使わない」

ネガティブな制約を書くことで、Stitchが「やってしまいがちなこと」を防ぐことができます。

「言語化」は誰がやるべきか

この作業を通じて、私が一番考えさせられたのは「誰がDESIGN.mdを書くべきか」という問題だった。

デザイナーがいないチームの場合

デザイン専任がいないチームで、マーケターや事業開発担当がStitchを使っているケースも増えています。そういうチームに「DESIGN.mdを書いてください」と言うと、最初は戸惑われることが多いです。

「ブランドカラーはわかるけど、border-radiusとか言われても…」

そこで私がよく使うのは、「自分たちのブランドに近いサービスをリファレンスにする」というアプローチです。

「Notionみたいなミニマルな感じ」「Airbnbみたいな温かみのある感じ」というように、既存サービスをリファレンスとして挙げてもらいます。そのサービスのURLをStitchに渡してDESIGN.mdを自動生成し、Hex値だけ自分たちのブランドカラーに書き換える。この方法だと、デザイン知識がなくても「それっぽい」DESIGN.mdを作れます。

言語化は「デザインスキル」の一部になった

この体験を通じて、私の中で「デザインを言語化する能力」がひとつの独立したスキルとして認識されるようになりました。

以前は、「デザインの感覚があれば、あとはFigmaで形にするだけ」だと思っていた。でも Stitch を使っていると、AIに意図を伝えるためには「感覚」を「言語」に変換するプロセスが必要です。それはデザイナーにとっては「感覚でわかっていたことを言語化する」という難しい作業であり、非デザイナーにとっては「デザインの感覚を後天的に身につける」きっかけにもなります。

Google Stitch は、UIを生成するツールであると同時に、「デザインの言語化を強制するツール」でもあると思うようになりました。

DESIGN.mdを活用した実際のワークフロー

私が現在使っているワークフローを具体的に紹介します。

Step 1：ブランドの棚卸し
既存のサイト・アプリ・資料からカラーコードを抽出し、フォント名を確認します。ブランドガイドラインがある場合はそれを参照し、ない場合は実際に使われているスタイルを観察して記録します。

Step 2：DESIGN.mdの初稿を作成
StitchのURL解析機能を使って下書きを生成するか、テキストエディタで直接Markdownを書きます。最低限の情報（カラー・フォント・ボーダー半径）だけを入れた小さいDESIGN.mdから始めます。

Step 3：Stitchで検証する
DESIGN.mdをインポートしてダミーの画面を生成し、「ブランドらしさ」が出ているか確認します。「違うな」と感じた部分を具体的に特定し（色が明るすぎる、フォントが小さすぎる、など）、DESIGN.mdを修正します。

Step 4：反復する
1〜2回の修正で完成するケースはまれで、だいたい3〜5回の反復が必要でした。特に「コンポーネントのスタイル」の調整に時間がかかりました。

Step 5：チームに共有する
完成したDESIGN.mdはGitやNotionに保存し、チームメンバーが同じDESIGN.mdをStitchにインポートして使えるようにします。2026年3月のStitch 2.0アップデートでプロジェクト間のインポート・エクスポートが可能になり、チームでの共有がしやすくなりました。

よくある失敗と対処法

Stitch でブランド対応をしようとしたときに私が陥った失敗パターンと対処法をまとめます。

失敗1：DESIGN.mdが長くなりすぎて機能しなくなった——「全部書けばいい」と思って、あらゆるルールを詰め込みました。その結果、Stitchが生成するUIがかえってバラバラになりました。対処法は「本当に重要なルールだけを書く」こと。多くても20〜30行程度に収めると生成品質が安定します。
失敗2：色名だけ書いてHex値を書かなかった——「ブランドブルー」「コーポレートオレンジ」のような色名を書いても、AIには色が伝わりません。必ずHex値（例：#2A5FD8）で記述します。
失敗3：DESIGN.mdをStitchに読み込ませていなかった——DESIGN.mdを用意しても、Stitchのプロジェクト設定にインポートしていないと反映されません。プロジェクト設定からDESIGN.mdをアップロードする手順を忘れずに。
失敗4：リファレンスの解釈がズレた——「マテリアルデザインの雰囲気で」とプロンプトに書いたところ、古い（Material Design 1.0的な）UIが生成されることがありました。「マテリアル3（Material You）の雰囲気で」のように、バージョンまで指定するのが有効です。
失敗5：更新が属人化した——DESIGN.mdは特定のメンバーだけが管理するのではなく、GitやNotionで管理してチーム全員が更新できる状態にしないと、実態からズレたファイルになっていきます。

よくある質問（FAQ）

Q. DESIGN.mdはどうやってStitchに読み込ませますか？

A. Google Stitch のプロジェクト設定画面にある「Import Design System」のオプションからアップロードします。一度インポートすると、同じプロジェクト内で生成するUIすべてにブランドルールが適用されます。2026年3月のStitch 2.0アップデートでプロジェクト間のエクスポート・インポートにも対応しました。

Q. ブランドガイドラインのPDFがある場合、そのままStitchに使えますか？

A. PDFをそのまま読み込む機能は現時点では提供されていませんが、画像として書き出したカラーパレットや書体サンプルをStitchに画像として添付すると、AIが解析してデザインルールを抽出してくれます。またPDFに記載されているHex値やフォント名を手動でDESIGN.mdに転記する方法が最も確実です。

Q. 英語と日本語のブランド名・フォントが混在する場合、どうすれば一貫性が保てますか？

A. DESIGN.mdに英語フォントと日本語フォントを別々に指定します。たとえば「Font: Latin: Inter, Japanese: Noto Sans JP」のように記述します。Stitchは多言語フォントの指定に対応しており、UIに日本語テキストが含まれる場合も正しいフォントを適用してくれます。ただし、フォントが正しく生成されているかは必ず目視で確認することを推奨します。

Q. 競合他社のサイトをリファレンスとして使ってもいいですか？

A. URLを貼り付けてデザインシステムを抽出することは技術的には可能ですが、著作権・ブランドの独自性の観点から、競合のデザインをそのまま流用することは避けるべきです。「雰囲気を参考にする」程度であれば問題ありませんが、最終的にはHex値やスペーシング値を自分たちのブランドに合わせた数値に必ず変更してください。

Q. DESIGN.mdがあれば、毎回プロンプトにブランドの説明を書かなくても大丈夫ですか？

A. はい、DESIGN.mdをプロジェクトにインポートしておけば、毎回のプロンプトにブランドルールを書く必要はありません。「ダッシュボード画面を作って」というシンプルなプロンプトでも、DESIGN.mdのルールに沿ったUIが生成されます。ただし、DESIGN.mdに書かれていないスタイルについてはStitchが独自に判断するため、重要なルールはすべてDESIGN.mdに明記しておくことが望ましいです。

Q. DESIGN.mdを作っても、生成されるUIのクオリティにばらつきがあります。なぜですか？

A. いくつかの原因が考えられます。DESIGN.mdに矛盾するルールが含まれている、プロンプトとDESIGN.mdの指定が競合している（プロンプトで「赤いボタン」と指定しているのにDESIGN.mdでは「赤は使わない」とある）、DESIGN.mdの記述が抽象的すぎる（具体的な数値が少ない）——などが主な原因です。プロンプトとDESIGN.mdの整合性を確認し、より具体的な数値での記述に見直してみてください。

Q. デザイナーがいない小規模チームでも、DESIGN.mdは作れますか？

A. 作れます。最初から完璧なDESIGN.mdを目指す必要はありません。ブランドカラー3色・フォント名・ボーダー半径の3つだけを書いた最小限のDESIGN.mdから始め、使いながら少しずつ追記していくアプローチが現実的です。StitchのURL解析機能を使えば、自社サイトやリファレンスサイトから下書きを自動生成できるので、ゼロから書く必要もありません。