Google Stitchを触ってみた ── Vibe Designツールは「出口」で選ぶ

はじめに

こんにちは。and factory フロントエンドエンジニアの坂内です。

前回はClaude Designを実案件で試した記事を書きました。ワイヤーフレームを作るならFigmaが候補に挙がりますが、普段はデザイン確認専用に使っていました。ディレクターへ共有するモックが必要になったとき、Figmaの使い方を調べながら進めるより手軽な方法を探していた、というのが前回の出発点です。

その後、同僚から「Google Stitchというツールがある」と教えてもらいました。同じくAIでUIを生成するツールですが、Googleが作っている点と無料で使える点が違います。前回とまったく同じお題を投げたら、出てくるものはどう変わるのか。 特にエンジニアとして受け取る側から見て、実装の手触りに差が出るのかを確かめたくなりました。それが今回の動機です。

調べ始めると、Stitch単体の話ではないと分かりました。v0・Lovable・Bolt.newといったツール群が「Vibe Design」という潮流を作っており、それぞれ狙っている領域が違います。この記事では、フロントエンドエンジニアとして「生成物を受け取る側」の視点から、Vibe Designツールの現在地と実務での使いどころを整理します。

注意： 本記事の内容は2026年7月時点の情報に基づいています。StitchはGoogle Labsの実験プロジェクトであり、機能・料金・UIの変更が頻繁に発生します。最新の情報は公式サイトを確認してください。

結論

先に持ち帰ってほしいポイントを3つに絞ります。

• Vibe Designツールは「どれが最強か」ではなく「出口が何か」で選ぶ。デザイン案が欲しいのか、Reactコンポーネントが欲しいのか、動くアプリが欲しいのかで最適解が変わる
• Stitchはプロンプトをそのまま描かず、デザインシステムを立ててから解釈する。「ピンクのヘッダー」という指示が濃紺サイドバー + ピンクのアクセントに変換された理由が、生成されたDESIGN.mdに書かれていた
• DESIGN.mdによるDesign System as Codeの流れが本命。デザイン制約をMarkdownで記述してAIエージェントに読み込ませる発想は、デザイナーとエンジニアの連携そのものを変える可能性がある

「Vibe Design」とは何か

「Vibe Coding」という言葉を聞いたことがある方は多いはずです。元OpenAIのAndrej Karpathyが2025年初頭に提唱した概念で、コードの細部を自分で書かずに意図や雰囲気をAIへ伝えて生成させるスタイルを指します。

その波がデザイン領域にも来ました。Vibe Designとは、「こういう画面にしたい」という意図をプロンプトで伝え、レイアウト・配色・タイポグラフィまでAIに一括生成させる進め方です。ピクセル単位でUIを組み上げる従来の手順とは発想が異なります。

UX研究者のJakob Nielsenも、UIがハードコーディングされる時代から意図とコンテキストに基づいて生成される時代へ移行すると述べています。業界全体がその方向に動き始めています。

Vibe Designツールを「出口」で分類する

ツールを比較するうえで最初に整理したいのが「出口」の違いです。何が手元に残るのかを揃えないと、比較がかみ合いません。

大きく2カテゴリに分かれます。

• UIデザインツール系（Stitch・v0・Figma Make）は、デザイン案やコードの叩き台を出す。本番投入には人手のリファインが必要
• AIアプリビルダー系（Lovable・Bolt.new）は、認証・DB・デプロイまで含む動くアプリを出す。小規模であれば直接デプロイできる

前回試したClaude Designは、この分類では前者に入ります。プロトタイプとドキュメントを出すツールであり、動くアプリを作るツールではありません。

Google Stitchとは

成り立ち

2022年創業のGalileo AIは、テキストプロンプトからUIを生成するパイオニア的なツールでした。Googleがこれを買収し、2025年5月のGoogle I/OでGoogle Labsの実験プロジェクト「Stitch」としてリローンチしました。

そして2026年3月18日、Stitch 2.0として大幅アップデートが入りました。Googleはこれを「AIネイティブなソフトウェアデザインキャンバス」と表現しています。単なるテキストからUIを生成するツールから、デザインの探索環境そのものへと位置づけが変わりました。

このアップデートは市場も動かしました。CNBCの報道によると、発表当日にFigmaの株価が約8%下がり、翌日もさらに4%以上下落しています。2日間で1割を超える下げ幅です。無料のAIツールが上場企業の株価を動かした点に、注目度の高さが表れています。

Stitch 2.0の主な機能

以下は公式情報と実際の画面を突き合わせて整理したものです。今回のように1画面だけを作る使い方では触れない機能も含みます。実際に試した結果は次の章にまとめます。

AIネイティブの無限キャンバス

生成のたびに結果が上書きされません。過去の生成結果がキャンバス上に残るため、複数案を並べて比較しながら進められます。この挙動は実際に確認できたので、後半で生成結果とあわせて紹介します。AIの動作を示すAgent Logがリアルタイムで流れる仕組みも用意されています。

マルチスクリーン生成（最大5画面）

Stitch 2.0の目玉機能です。「ログイン → ダッシュボード → 設定画面」のようなアプリフロー全体を、一度のプロンプトで最大5画面まとめて生成できます。画面間ではカラーパレット・タイポグラフィ・コンポーネントスタイルが自動的に統一されます。今回は1画面のみを作ったため、この機能は試していません。

モデルの選択

用途に応じてAIモデルを切り替えられます。Gemini 3系とGemini 2.5系のPro・Flashから選択する形式です。品質重視ならPro、探索フェーズのスピード重視ならFlashという使い分けになります。モデルを選ばせるAIデザインツールは他にあまりなく、差別化ポイントです。

書き出しの選択肢

画面を選ぶと、メニューから書き出し方法を選べます。実際に並んでいたのは「コードを表示」「Figmaにコピー」「エクスポート」「ダウンロード」の4つです。

コードはHTMLとTailwind CSSの組み合わせで出てきます。ReactやVueを選ぶドロップダウンはありませんでした。React・Vue・Flutterなど複数フレームワークへの出力に対応しているという解説も見かけますが、執筆時点のメニューにフレームワークを選ぶ項目は見当たりません。

Figmaにコピーは独立した項目として用意されています。レイヤーとコンポーネント構造を保ったまま渡せるため、「Stitchで探索してFigmaで仕上げる」というワークフローの橋渡しになります。コードとFigmaが対等な出口として並んでいる点は、Stitchの位置づけをよく表しています。

MCPサーバー対応

Stitchはmodel context protocol（MCP）サーバーを提供しています。Claude CodeやCursorなどのAIコーディングツールからStitchのデザインを直接参照できます。デザインとコーディングの境界を溶かす方向性です。

Annotate（注釈フィードバック）

生成された画面に直接テキストや手書きメモを書き込むと、AIがそれを解釈して変更を実装します。非同期・分散したチームのフィードバックループに向いています。

料金

Google Labsフェーズのため無料です。Googleアカウントがあればクレジットカード不要で使い始められます。

利用量はクレジット制で管理されます。ただし2026年3月のアップデート以降、上限の計算方式と数値の改定が続いています。有料プランやクレジットの追加購入は用意されていないため、上限に達したら回復を待つしかありません。正確な上限は公式サイトで確認してください。

制約・注意点

• Google Labsのため将来の終了リスクがある。SLAとサポートはない
• ピクセル単位の編集はできない。細部の仕上げはFigmaに委ねる前提の設計
• 自社のコンポーネントライブラリは使えない。汎用のデザインシステムが生成される
• UI/UX向けの設計。プレゼン資料やSNS素材は対象外とされている。ただし記事末尾のおまけのとおり、カバー画像なら作れた
• URLからのデザインシステム抽出は不安定。2026年3月時点でバグの報告がある

実際に触ってみた

検証条件は以下のとおりです。

試したプロンプト

前回のClaude Designの記事と条件を揃えるため、まったく同じプロンプトを投げました。自社サービスの管理画面に「施策管理ページ」を追加する想定です。

1
2
3
4
5
6
7

XXXXXという管理画面の施策管理ページを作りたい。
- PC向け管理画面
- ピンク（#E91E8C）のヘッダー＋左サイドバー構成
- 施策一覧テーブル（ID・施策名・開始日・終了日・URL・ステータス）
- 詳細ボタン → モーダルで編集
- モーダル内はアコーディオンで項目を折りたたむ
- ステータスは「下書き / 公開 / 非公開」の3種

デザイントーンの参照用に、既存管理画面のスクリーンショットも添付しました。

入力欄で確認できた選択肢は3つあります。

• アプリ / ウェブの切り替え：出力先のプラットフォームを最初に指定する。今回はウェブを選んだ
• モデル選択：入力欄の右下でモデルを切り替える。今回はFlashを選び、まず探索を優先した
• デザインシステムの指定：パレットのアイコンから選ぶ

同じプロンプトを渡したとき、Claude Designは最初に10問のヒアリングを返してきました。一方のStitchは、対話ではなく入力欄そのものに選択肢を並べています。会話で要件を詰めるClaude Designと、設定を先に選ばせるStitchという設計思想の違いが、最初の一手から見て取れます。

DESIGN.mdによるデザインシステムの指定

入力画面で目を引いたのが、デザインシステムの選択UIです。

このパネルはDESIGN.mdという単位でデザインシステムを扱っています。Alexandria・Bauhaus・Glacier・Carbonといったプリセットが用意されており、選ばなければStitchがプロンプトから自動判断します。

重要なのは、デザインシステムがプロンプトの一部ではなく独立したファイルとして分離されている点です。「何を作るか」と「どう見せるか」を別々に指定できます。この設計はあとで触れるDesign System as Codeの話につながります。

生成された一覧画面

最初の生成で出てきた施策管理ページです。

指示していない要素まで自発的に作り込んでいます。

• パンくずリスト
• 件数表示（14件）と「新規施策」ボタン
• ページネーション（Rows per page切替・1-10 of 14の件数表示）
• 「Marketing Admin」というプロダクト名の命名

サイドバーについては、少し性質が違いました。2階層のメニュー構成は、添付した既存管理画面のスクリーンショットから写し取られています。プロンプトでは「左サイドバー構成」としか伝えていないので、並び順や階層は画像から読み取ったことになります。

つまり、画像を渡すと指示していない情報まで拾って反映されます。参照用のつもりで貼ったスクリーンショットが、そのまま生成物に反映されるということです。社内の画面を渡す場合は、写り込む範囲に注意が要ります。なお本記事のスクリーンショットでは、メニュー名を伏せています。

一方で、明示的に指示した内容が2つ、そのままの形では反映されませんでした。

1つ目は配色です。「ピンク（#E91E8C）のヘッダー + 左サイドバー構成」と指定し、既存画面のスクリーンショットも添付しました。しかし出てきたのは濃紺のサイドバーで、ヘッダーバー自体がありません。ピンク系の色はロゴ・アクティブメニュー・ボタン・リンクのアクセントに回されています。前回のClaude Designが同じ指示でピンクのヘッダーを再現したのとは、対照的な結果です。

この理由は、後述するDESIGN.mdを読んで判明しました。指示を無視したのではなく、Stitchが自動生成したデザインシステムのほうで指示を再解釈していました。詳しくは後半で扱います。

2つ目はテーブルの列です。「ID・施策名・開始日・終了日・URL・ステータス」と指定しましたが、生成された6列目は「ステータス」ではなく「操作」でした。ステータスは列として存在せず、一部の行にバッジがつく形に解釈されています。ただし後述する編集モーダルでは、ステータスがプルダウンとして実装されていました。項目を捨てたのではなく、置き場所を変えた形です。

細かい点では、表示上の不整合もあります。ページネーションは「1-10 of 14」と表示されますが、テーブルに並ぶ行数と一致していません。IDも103が欠番です。モックとして眺める分には気になりませんが、そのまま実装の仕様として渡せる精度ではありません。

生成された詳細編集モーダル

一覧の「詳細」ボタンから開くモーダルも生成されました。

セクションはアイコンつきの見出しで区切られ、4つのブロックに整理されています。自社の項目名にあたる部分はマスクしました。ここでもStitchは、指示していない要素を足しています。

• ステータスをプルダウンとして実装（一覧では列にしなかったものを、編集画面では入力項目として配置）
• 選択内容に応じて入力欄を出し分けるラジオボタン
• 構造化された設定値をJSONのテキストエリアで受け取る入力欄
• 機能のオン・オフをトグルで並べたブロック

入力方式の選び方に踏み込んでいる点が特徴的でした。「ここはプルダウン」「ここはラジオボタン」「ここはJSON入力」という判断は、本来ディレクターやデザイナーと詰める部分です。叩き台としては議論の出発点になります。

ただし、指示した「アコーディオンで折りたたむ」形にはなっていません。全項目を展開した1枚のフォームです。キャンバス上には構成の異なる別案も並んでおり、Stitchは指示を1つの正解として受け取るのではなく、解釈の幅を残した複数案として返してきます。

無限キャンバスでの並列比較

Stitch 2.0の目玉である無限キャンバスは、実際に使うと納得感がありました。

注目したいのは、デザインシステムが独立したカードとして生成されている点です。今回は「Vivid Admin」という名前で、カラーパレット・タイポグラフィ・コンポーネントが1枚にまとまっています。画面ごとに配色を指定しなくても、ここが共通の参照元になります。

その下には一覧画面と編集モーダルが並びます。編集モーダルは2案が横に並んでおり、過去の生成結果を消さずに比較できます。前回のClaude Designはライブキャンバスが1つで、修正すると前の状態が消えました。案を潰さずに広げられる点は、探索フェーズでStitchが有利な部分です。

なお、意図した形に近づくまでのやり取りの回数は、前回のClaude Designと同程度でした。最初の生成で大枠が出て、そこから数回の指示で細部を詰める流れです。

出力されたコードを読んでみた

一覧画面のコードを書き出しました。出てきたのは単一のHTMLファイルとTailwind CSSです。ReactやVueを選ぶ項目はありませんでした。

長くなるので、先に結論を3点にまとめます。

• 良かった点：DESIGN.mdのトークンがそのままtailwind.configに展開され、マークアップもトークン名で書かれている
• 壊れていた点：角丸の値が変換時にずれており、rounded-fullが機能しない。テーブルの行定義も二重になっている
• 結論：構造を読む用途には十分だが、そのまま持ち込むと後始末のほうが高くつく

DESIGN.mdがそのままTailwindの設定になっている

まず感心したのがここです。HTMLの<head>に、DESIGN.mdのトークンがそのままtailwind.configとして展開されていました。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

tailwind.config = {
  darkMode: "class",
  theme: {
    extend: {
      "colors": {
        "primary": "#b80049",
        "on-primary": "#ffffff",
        "surface-container-low": "#e6f6ff",
        "on-surface-variant": "#5b3f43"
      },
      "spacing": {
        "touch-target": "44px",
        "container-margin": "24px",
        "gutter": "16px"
      },
      "fontSize": {
        "headline-lg": ["24px", {"lineHeight": "32px", "fontWeight": "700"}],
        "body-md": ["14px", {"lineHeight": "20px", "fontWeight": "400"}]
      }
    }
  }
}

マークアップ側もbg-primary・text-on-surface・px-lgと、デザイントークン名でそのまま書かれています。デザインシステムの定義と実装が名前で直結している状態です。マジックナンバーが散らばったコードではありません。ここは素直に良い点でした。

ただし、変換の途中で壊れている

一方で、DESIGN.mdと生成コードを突き合わせると、角丸の定義がずれていました。

値が1段ずつずれたうえ、fullが9999pxから0.75remに化けています。rounded-fullは円やピル形状を作るためのキーですが、この設定では12pxの角丸にしかなりません。DESIGN.mdの本文には「バッジやチップは完全な丸み（ピル形状）にする」と書かれているのに、デザインシステム自身が宣言したルールを生成コードが満たせない状態です。

先ほど指摘した色の食い違いと合わせて、DESIGN.mdから実装への変換はまだ信用しきれません。トークンの名前は信じられても、値は突き合わせる必要があります。

叩き台としての粗さ

そのほか、レビューで指摘したくなる箇所がいくつもありました。

同じ行がコード上で二重に定義されています。 <tbody>の中にスクリプトが埋め込まれ、innerHTMLで行を追加しています。ところが同じID（105・106・107）の行が静的なHTMLとしても直後に書かれており、データの定義が2か所に分かれています。どちらが表示されるかが実行順に左右される、危うい構造です。

1
2
3
4
5
6
7
8
9

<script>
  const data = [
    { id: 105, name: 'サンプル施策E・シーズン企画', ... },
    { id: 106, name: 'サンプル施策F・夏末キャンペーン', ... }
  ];
  const tbody = document.querySelector('tbody');
  data.forEach(item => { tbody.innerHTML += `<tr>...</tr>`; });
</script>
<!-- この直後に id=105, 106 の <tr> が静的にも書かれている -->

先ほど触れたページネーションの「1-10 of 14」も、テーブルの中身と噛み合っていません。件数表示が固定の文字列として書かれており、行データと連動していないためです。

CSSで足りる処理をJavaScriptで書き直しています。 詳細ボタンにはすでにhover:bg-primary/5が指定されています。それにもかかわらず、末尾のスクリプトがmouseenterとmouseleaveでクラスを付け外ししています。キーボード操作では発火しないため、フォーカス時の見た目も変わりません。

1
2
3
4
5

document.querySelectorAll('tr').forEach(row => {
  row.addEventListener('mouseenter', () => {
    row.querySelector('button')?.classList.add('bg-primary', 'text-white');
  });
});

アクセシビリティは手つかずです。 ページネーションの矢印ボタンはアイコンのみでアクセシブルな名前がありません。<select>にラベルが紐づいておらず、テーブルの<th>にもscope属性がついていません。DESIGN.mdにはWCAGを意識した記述があり、タップ領域44pxのような配慮は入っているのに、支援技術まわりは抜けています。

中身のない要素が残っています。「Bento Grid - Stats Cards」というコメントつきの空の<div>があり、「Top App Bar」のコメントの下には何も出力されていません。それでいて本文側にはmt-touch-targetの余白だけが残っています。指示したヘッダーバーが画面に見えなかった理由はこれでした。 枠だけ用意して中身を作らないまま止まっています。

TailwindはCDN版です。 cdn.tailwindcss.comを読み込む構成で、これは本番利用が想定されていない配布形態です。そのまま公開する前提のコードではありません。

結論：構造の参考にはなる

Stitchのコードは「読んで参考にするもの」であって、「持っていって動かすもの」ではありません。 レイアウトの組み方、トークンの当て方、レスポンシブの切り替え方針は十分に読み取れます。一方で、重複した実装・欠けたアクセシビリティ・変換ミスが混ざっており、そのまま持ち込むと後始末のほうが高くつきます。

DESIGN.mdをチームのデザイントークンとして受け取り、実装は自分たちのコンポーネントで書き直す。この使い方が現実的だと感じました。

v0・Lovableとの使い分け

改めて整理します。「どれが最強か」という問いに意味はありません。出口が違うためです。

デザインの叩き台・ラフが欲しい場合はGoogle Stitch

探索フェーズのアイデア出しや、クライアントへの初期モック提示に向いています。無料で使える点も強みです。

本番品質のReactコンポーネントが欲しい場合はv0 by Vercel

shadcn/uiとTailwind CSSをベースにしたコードが出てきます。Next.jsプロジェクトへの組み込みを前提としており、生成コードをそのまま使う目的なら現状もっとも近い選択肢です。

フルスタックのMVPを最速で立てたい場合はLovableかBolt.new

LovableはSupabase連携込みで、認証・DB・デプロイまで一気通貫で用意します。Bolt.newはブラウザ内にフルスタック開発環境（WebContainer）を持ちます。フレームワーク選択の自由度の高さが特徴です。

複数のツールを組み合わせる例もあります。「v0でコンポーネントを作り、Lovableでアプリ全体を組み、Claude Codeで本番向けにクリーンアップする」という流れです。それぞれの強みを段階ごとに使い分ける発想です。

フロントエンドエンジニア視点での評価

Claude Designとの比較

同じプロンプト・同じ添付画像で2つのツールを試した結果、得意領域がはっきり分かれました。

要件が固まっているならClaude Design、まだ広げたいならStitchという住み分けです。今回のように既存画面のトーンへ寄せたい場合は、Claude Designのほうが早く狙いどおりの画面に届きます。逆に「どんな画面がありえるか」を並べて見たい段階なら、Stitchの無限キャンバスが効きます。

副産物の違いも示唆的でした。Claude Designが出すのは実装の引き継ぎ資料（APIペイロード・仕様ドキュメント）で、Stitchが出すのはデザインの制約定義（DESIGN.md）です。前者はエンジニアの次の一手を、後者はデザインの一貫性を支えます。どちらが欲しいかで選ぶ形になります。

使えそうな場面

• 0→1のラフ・案出し：意図をプロンプトで伝えれば数分以内に複数案が出る。チームのブレストや方向性合意の叩き台として、大幅な時短が見込める
• デザイナーが不在のプロジェクト：エンジニアだけでもUIの初稿を用意できる
• クライアントへの素早いモック提示：Figma書き出しを使えばそのまま共有できる
• レイアウト設計の参考：出力されたHTMLとTailwind CSSを読み、構造の当たりをつける

「ここは無理」のライン

• 自社デザインシステムへの準拠：社内のButton・CardコンポーネントはStitchに登録できない。汎用のデザインシステムが生成される
• 本番コードとしての直投入：生成コードの構造は参考になるが、アクセシビリティ・セキュリティ・パフォーマンスのレビューは必須
• ピクセルパーフェクトな仕上げ：ブランドガイドへの完全準拠は人間の手が必要
• UXリサーチ・ユーザーテスト：AIが代替できる領域ではない

生成コードをどう扱うか

Stitchのコードは、UI構造とスタイリング方針を読み取る用途には十分です。ただし、そのまま本番へ投入するには可読性と保守性の整理が必要です。既存のNext.jsプロジェクトへ組み込む前提であれば、Reactコンポーネントを直接出力するv0のほうが距離は近くなります。この点は今回検証していないため、次の機会に実際のコードを比べてみます。

注目している「Design System as Code」の流れ

個人的にもっとも注目しているのがDESIGN.mdです。Googleは2026年4月21日にこのフォーマットをオープンソース化しました。

今回のプロジェクトからも書き出せたので、中身を見ていきます。Modify → Edit → DESIGN.mdタブと進み、More → Downloadで取得できます。

構造：YAMLのトークンとMarkdownの散文

ファイルは2層構造です。前半のYAML frontmatterに機械可読なトークンが並び、後半のMarkdown本文に「なぜそうするか」が散文で書かれています。

まずトークン側の抜粋です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

---
name: Vivid Admin
colors:
  surface-container-lowest: '#ffffff'
  surface-container-high: '#ceedfd'
  on-surface: '#001f2a'
  primary: '#b80049'
  on-primary: '#ffffff'
  primary-container: '#e2165f'
  inverse-primary: '#ffb2be'
  error: '#ba1a1a'
  on-error-container: '#93000a'
typography:
  headline-lg:
    fontFamily: Plus Jakarta Sans
    fontSize: 24px
    fontWeight: '700'
    lineHeight: 32px
  body-md:
    fontFamily: Noto Sans
    fontSize: 14px
    fontWeight: '400'
    lineHeight: 20px
spacing:
  unit: 4px
  container-margin: 24px
  touch-target: 44px
---

on-surface・primary-container・inverse-primaryといった命名から分かるとおり、カラートークンはMaterial Design 3のカラーロールに準拠しています。独自形式ではないため、既存のM3ベースの実装があれば対応づけしやすい作りです。

散文側に「意図」が書かれている

このフォーマットの本質は後半にあります。トークンだけならJSONで足りますが、DESIGN.mdは判断の根拠を自然言語で持ちます。

1
2
3
4
5
6
7
8
9

## Colors

The color palette is anchored by a high-visibility **Primary Pink (#e91e63)**,
used for primary actions, floating action buttons, and active states.

- **Primary:** Pink is the "action" color. It must be used sparingly but
  consistently for buttons, toggles, and critical highlights.
- **Secondary:** A deep charcoal/dark blue-grey is reserved for the sidebar
  and main navigation background, providing a stable frame for the content.

ここに、生成画面が濃紺のサイドバーになった理由がありました。 Stitchはプロンプトの「ピンク」を受け取ったうえで、独自のルールを2つ立てています。「ピンクはアクションを示す色なので控えめに使う」「サイドバーは濃色で固定する」の2点です。指示を落としたのではなく、デザインシステムとして再解釈した結果です。生成画面はこのルールに忠実でした。

同じことがタイポグラフィにも起きています。

1
2
3
4

- **Plus Jakarta Sans** is used for headings and UI labels.
- **Noto Sans (JP)** is the workhorse for body text, data tables, and input
  values. It is chosen for its superior rendering of CJK characters and
  balanced weight distribution, essential for data-heavy dashboard views.

日本語のプロンプトから、CJK文字の描画品質を理由にNoto Sansを選んだと明記しています。見出しと本文でフォントを使い分ける判断まで含めて、根拠つきで残る点が良いところです。

レイアウトの記述も具体的でした。サイドバーはデスクトップで240px固定、モバイルではハンバーガーメニューのドロワーに切り替えます。テーブルはモバイルで横スクロールを許可し、1列目を固定します。モーダルの影は0px 8px 24px rgba(0,0,0,0.12)と定めています。行の高さはtouch-targetの44pxを下限にしてアクセシビリティを確保します。そのままCSSに落とせる粒度です。

気になった点

一方で、扱いには注意が必要だと感じた箇所もあります。トークンと散文で色の値が食い違っています。

3つとも違う値です。人間が読む分には「ピンク系」で済みますが、AIエージェントに読み込ませる前提のフォーマットとしては危うい部分です。機械可読なトークンと自然言語の説明を両立させる設計である以上、両者の整合はツール側で保証してほしいところです。実運用では、frontmatterを正とみなす運用ルールが要ります。

エンジニアから見た位置づけ

このファイルをClaude CodeやCursorのコンテキストへ読み込ませると、「このデザイン制約に従ってコードを書いて」という指示ができます。Googleの公式ブログによれば、AIエージェントが色の用途を理解し、WCAGのアクセシビリティ基準に照らして選択を検証できる形式を目指しているとのことです。

つまり、デザインシステムを「Figmaの中にある共有知識」から「リポジトリに置けるテキストファイル」へ移す試みです。エンジニア側から見ると、これはCLAUDE.mdやREADMEと同じレイヤーの資産として扱えます。レビューもdiffも効きます。デザイナーとエンジニアの連携の形そのものを変える可能性を持ちます。

来月はFigma MCPを調査する予定です。「デザイナーがFigmaで作ったコンポーネントをAIが直接コード化する」ワークフローが現実的かを検証し、DESIGN.mdのアプローチと比較してみます。

まとめ

• Vibe Designは実用段階に入った。バズワードではなく、業務のどこかに組み込めるレベルまでツールが成熟した
• Google Stitch 2.0は0→1のデザイン探索に強い。無料で使えて、過去案を消さずに並べられる無限キャンバスが効く
• 「どれが最強か」は間違った問い。デザイン案・Reactコード・動くアプリという出口の違いで、使うツールが変わる
• Stitchは指示をそのまま描かず、デザインシステム経由で解釈する。狙ったトーンに寄せたいときは、生成物より先にDESIGN.mdを直すほうが早い
• DESIGN.mdは実用的だが、まだ粗さがある。トークンと散文で色の値が食い違っていた。AIエージェントへ渡す前に人間が一度読む前提で扱う

おまけ：この記事のカバー画像もStitchで作った

Vibe Designの記事を書きながらカバー画像を手作業で用意するのもちぐはぐなので、これもStitchに任せました。かかった時間は5分ほどです。

やり取りはこれだけでした。

1. サイズとタイトルを伝え、「公式ロゴは使わない」とだけ条件をつけた
2. 「別のデザイン案も見てみたい」を2回繰り返した
3. 「Stitchっぽい色味とシンプルさの案も見たい」と方向を指定した
4. 「どれが推し？」と聞いた

5往復で7案が出ました。最後に推してきた案をそのまま採用しています。この記事の一番上にある画像がそれです。

ここでも無限キャンバスが効きました。7案すべてが消えずに残るため、並べて見比べたうえで選べます。 カードの見出しが生成プロンプトの先頭になっているのも分かりやすい点です。

見比べると、案によって日本語の描画に差が出ています。ダッシュや鉤括弧の位置が崩れているものもあり、日本語テキストを含む画像生成は、まだ当たり外れがあります。

そのほか、エンジニアとして興味深かった点が3つあります。

日本語の指示を英語のプロンプトに組み立て直していました。 生成に使ったプロンプトが案ごとに提示され、何を狙ったのかを読み取れます。採用案では次のような指定が並んでいました。

1
2
3

soft, subtle off-white background
glass-morphism shape with a soft rainbow gradient
generous letter spacing

プロンプトが手元に残るため、次回同じトーンで作りたいときに再利用できます。

「どれが推し？」に理由つきで答えてきました。 ブランドとの親和性・タイポグラフィの美しさ・記事一覧での視認性という3点を挙げ、次点の案とその使いどころまで示してきます。生成機というより、相談相手に近い振る舞いでした。

ここでも指示どおりには描いていません。 採用案のプロンプトにはperfectly centered（中央揃え）と書かれていますが、実際の出力は左にシェイプ、右にテキストという左右分割です。本文で見たピンクの一件とまったく同じ構造で、Stitchは指示を受け取ったうえで必ず自分の解釈を挟みます。今回は結果が良かったのでそのまま採用しました。

なお、出力先は「ウェブ」を選んでいます。StitchはUI/UX専用でプレゼン資料やSNS素材は作れないと説明されることが多いのですが、記事のカバー画像くらいであれば問題なく作れました。制約は思ったより緩いようです。

参考リンク

• Google Stitch 公式サイト
• Google Blog：Introducing “vibe design” with Stitch
• Google Blog：DESIGN.mdフォーマットのオープンソース化
• CNBC：Figma stock drops after Google releases vibe design product Stitch
• v0 by Vercel
• Lovable
• Bolt.new