Google Stitch で作ったUIを、Cursor でどう実装に繋げているか——そのワークフローを整理したくてこの記事を書くことにした。
「Stitch と Cursor を両方使っているけど、うまく繋がっていない」という感覚を持ったことはないだろうか。私はずっとそうだった。Stitch でデザインを作り、Cursor でコードを書く——二つのツールはどちらも優れているのに、その間に奇妙な断絶があった。
デザインはあるのにコードが違う方向に走っていく。コードを書いているのにデザインの意図が伝わっていない。そのギャップを埋めるための「バトンの渡し方」を試行錯誤してきた結果、少しずつ形になってきたことがある。この記事では、その過程と現時点での自分なりの答えを共有する。
結論から言うと： Google Stitch と Cursor を効果的に連携させるカギは「DESIGN.md という引き継ぎ文書を中心に置くこと」と「Stitch のコード出力をそのまま使わず設計仕様書として読むこと」にある。この2点を意識するだけで、デザインとコードの断絶は大幅に縮まる。
Google Stitch と Cursor——それぞれの役割を整理する
まず、両ツールの役割を整理することから始めたい。混乱の多くはここが曖昧なまま使い始めることで起きる。
Google Stitch とは、Google Labs が2025年5月の Google I/O で発表したAI UIデザインツールのことです。プロンプトや画像からUIコンポーネント・画面を生成し、Figma 的なビジュアルエディタとしても使えるツールだ。デザインの初稿生成・ビジュアルの方向性確認・プロトタイプ作成が主な用途となる。
Cursor とは、AI が統合されたコードエディタのことだ。コードの自動補完・自然言語によるコード生成・リファクタリング提案などを提供し、2024〜2026年にかけてエンジニアに広く普及した。コードを書く・修正する・テストするという実装フェーズのツールだ。
つまり、Stitch は「デザイン」のツールであり、Cursor は「コード実装」のツールだ。この二つは本来異なるフェーズを担うものであり、「Stitch から直接 Cursor にコードを渡して完成」という夢のような連携は現実には難しい。では何が必要か——それが「バトン」だ。
なぜ断絶が生まれるのか
私が最初に感じた断絶の原因を振り返ると、主に3つあった。
第一に、Stitch が出力するコードはスタイリングに特化しており、ロジック・状態管理・API連携が含まれていないため、そのまま Cursor に貼り付けてもアプリとして機能するコードにはならない。
第二に、Stitch のデザインに含まれる「意図」（なぜこのレイアウトなのか、なぜこの色なのか、インタラクションはどうあるべきか）が、コードファイルだけでは伝わらない。Cursor の AI が文脈なしにコードを生成すると、見た目は近くても意図とずれることが多い。
第三に、Stitch でのデザイン変更がコードに反映されないため、時間が経つにつれてデザインとコードが乖離していく。
実際に使ってみてわかった、両ツールの相性
実際に Google Stitch と Cursor を数ヶ月組み合わせて使った経験から言うと、両者の相性は「補完的に使えば非常に良い」だ。ただし「シームレスに繋がる」という期待は持たない方がいい。
Stitch が得意なのはビジュアルの方向性を素早く固めることだ。「こういう見た目にしたい」を5分で10パターン試せる。Cursor が得意なのはコードの生成・修正・テストを高速に回すことだ。「この見た目を動くコードにしたい」を効率化する。
この二つを「デザイン確定 → 仕様文書化 → コード実装」というフローでつなぐことで、それぞれの強みが活きる。
DESIGN.md がバトンになる
私が今使っているワークフローの中心にあるのが「DESIGN.md」という引き継ぎ文書だ。Google Stitch には DESIGN.md を出力する機能が2026年3月のアップデートで追加されており、デザインの仕様をMarkdown形式で書き出せる。
DESIGN.md とは、Stitch が生成するデザイン仕様書のことで、コンポーネントの構造・色・フォント・スペーシング・インタラクション要件などが記述されたMarkdownファイルだ。このファイルを Cursor に渡すことで、AI がデザインの意図を理解した上でコードを生成できるようになる。
実際に試してみたところ、DESIGN.md を context として渡した状態で Cursor に実装を依頼すると、そうでない場合と比べてコンポーネントの構造・クラス名・スペーシングが明らかにデザインに近くなった。「Stitch で作ったデザインと全然違うコードが生成される」という悩みの多くは、この context の欠如が原因だと思っている。
DESIGN.md を活用した具体的なワークフロー
私が実際に使っているフローを手順として書き出す。
ステップ1として、Google Stitch でUIの全体像を設計する。この段階では細部より「方向性の確定」を優先する。Vibe Design で雰囲気を固め、主要画面（一覧・詳細・フォーム）の初稿を生成する。
ステップ2として、Stitch で各コンポーネントの仕様を固める。ここで使う色・フォントサイズ・スペーシングを明示的に決め、DESIGN.md に反映する。「なんとなくいい感じ」から「再現可能な仕様」への変換作業だ。
ステップ3として、DESIGN.md を Cursor のプロジェクトルートに配置し、Cursor Rules（.cursorrules ファイル）で「このプロジェクトでは DESIGN.md のデザイン仕様に従うこと」という指示を加える。
ステップ4として、Cursor でコンポーネント実装を開始する。Cursor に「DESIGN.md を参照して、○○コンポーネントを実装して」と指示すると、デザイン仕様に沿ったコードが生成される。
ステップ5として、実装後に Stitch のプロトタイプと比較確認を行う。差分があれば Cursor に修正指示を出すか、DESIGN.md を更新して仕様を明確化する。
DESIGN.md に何を書くべきか
DESIGN.md の自動生成を使いつつ、私が手動で補足している項目がある。
- カラーパレット：プライマリ・セカンダリ・アクセント・エラー・成功・背景の6色を HEX 値で定義
- タイポグラフィ：見出し・本文・キャプションのフォントサイズ・フォントウェイト・行間
- スペーシング規則：4px ベースか8px ベースかを明示し、コンポーネント間・セクション間の余白を定義
- コンポーネント一覧：使用するコンポーネントとその変種（ボタンのプライマリ・セカンダリ・無効状態など）
- インタラクション仕様：ホバー時の変化・フォーカス表示・アニメーション要件（Stitch で対応できないため文章で記述）
- レスポンシブルール：ブレークポイントとデバイス別のレイアウト変化
Stitch のコード出力の使い方を変えた
Google Stitch はHTMLやReactコードを出力する機能を持っている。以前の私はこのコードをそのまま Cursor に貼り付けて「これをベースに実装して」と使っていた。しかし、これが断絶の一因だった。
Stitch が出力するコードは「このUIを再現するためのスタイル実装」であり、アプリケーションのコンポーネントとして機能するコードではない。状態管理・イベントハンドリング・APIコール——こうした「動かすための要素」が含まれていない。Stitch のコードをそのまま使おうとすると、Cursor が混乱するコードを生成することがある。
実際に Google Stitch を使ってみてわかったのは、Stitch のコード出力は「参考情報」として使うのが正しいということだ。「このコンポーネントにはこんなクラス名・スタイルが付いている」という情報源として読み、実際のコード実装は Cursor に DESIGN.md を参照させながら一から書かせる方が、結果として綺麗なコードになる。
コード出力の読み方と活用ポイント
Stitch のコード出力から私が抽出するのは主に3点だ。
第一に、クラス名の命名規則だ。Stitch が付けているクラス名はコンポーネントの構造を反映していることが多く、これを Cursor に渡す命名規則のヒントとして使う。
第二に、CSS 変数の定義だ。Stitch が生成するスタイルに含まれる色・フォントサイズの値を拾い、DESIGN.md の CSS 変数セクションに反映する。
第三に、グリッド・フレックスの構造だ。Stitch が選んだレイアウト構造（どこで flex を使い、どこで grid を使うか）は参考になることが多い。
Cursor Rules で Stitch のデザイン仕様を常に参照させる
Cursor には「.cursorrules」というファイルにプロジェクトのルールを書いておくと、すべての AI 応答に適用される機能がある。このファイルに DESIGN.md の参照指示を入れることで、Cursor が常にデザイン仕様を意識したコードを生成するようになる。
私が実際に .cursorrules に書いているのは以下のような内容だ。「このプロジェクトのデザイン仕様は DESIGN.md に従うこと。コンポーネントを実装する際は必ず DESIGN.md のカラーパレット・タイポグラフィ・スペーシング規則を参照すること。DESIGN.md に定義されていない色・フォント・余白は使わないこと。」
この数行を加えるだけで、Cursor の生成するコードがデザイン仕様から外れにくくなる。特に複数のコンポーネントにわたって色やスペーシングが統一されるようになった点が、実際に使って感じた最大の恩恵だ。
MCP 連携の可能性
2026年3月の Google Stitch アップデートでは MCP（Model Context Protocol）統合が追加された。MCP とは、AIツール同士がコンテキストを共有するための標準プロトコルのことだ。この機能により、理論上は Stitch のデザインコンテキストを外部ツールと共有できる。
Cursor も MCP に対応しているため、Stitch の MCP サーバーを Cursor に接続することで、Stitch で作業中のデザインの状態を Cursor がリアルタイムで参照できる可能性がある。私自身は現在この設定を試している途中だが、実現すれば「DESIGN.md を手動で更新する」手間が省けるかもしれない。
デザインの「意図」をコードに伝える工夫
DESIGN.md に仕様を書くことに加えて、私がやっている「意図の伝え方」がある。
Stitch でUIを設計するとき、私は各コンポーネントの横にコメントを付けるようにした。「このボタンが赤なのは、取り消し不可能な操作のためのビジュアル警告」「このスペーシングが広いのは、ユーザーが誤ってタップしないように」——こうした設計の意図は、コードには現れない。
これらのコメントを DESIGN.md の「設計意図」セクションとしてまとめ、Cursor に渡すことで、AIが「なぜこうなっているのか」を理解した上でコードを生成してくれるようになる。「なぜ」を知っていれば、AIは近似的な実装をするとき正しい判断ができる。
レビューのサイクルを短くする
Stitch と Cursor の連携ワークフローで私が最も重視しているのは、「デザインとコードのレビューサイクルを短くすること」だ。
デザイン確定 → コード実装 → デザインとの差分確認 → 修正 → 再確認——このサイクルを素早く回すほど、最終的な品質が上がる。Stitch の Play ボタンでプロトタイプを確認しながら、Cursor で実装を進め、こまめに比較する。
私は実際に「Stitch のプロトタイプを画面の半分に表示し、もう半分でブラウザの実装プレビューを見る」という並べて確認する作業を取り入れた。ピクセル単位での一致を目指す必要はないが、「雰囲気が違う」と感じた時点で修正することで、乖離が蓄積しにくくなった。
よくある質問（FAQ）
Q：Google Stitch と Cursor を連携するにはどちらから始めればいいですか？
A：必ず Google Stitch でのデザインを先に固めてから、Cursor での実装に入ることをおすすめします。実装先行でデザインを後から当てようとすると、コードの構造とデザインの構造が合わずに二度手間になりやすいためです。Stitch で主要画面の方向性を確定 → DESIGN.md に仕様を書き出す → Cursor で実装開始、という順序が最も効率的でした。
Q：Stitch のコード出力をそのまま使っていいですか？
A：そのまま貼り付けてアプリを作ろうとするのはおすすめしません。Stitch のコード出力はスタイリング実装であり、状態管理・イベント処理・API連携が含まれていません。「デザイン仕様のリファレンス」として読み、実際の実装は Cursor に DESIGN.md を参照させながら行う方が、品質の高いコードになります。
Q：DESIGN.md は自動生成されますか？手動で書く必要がありますか？
A：Google Stitch には DESIGN.md を自動生成する機能があります（2026年3月のアップデートで追加）。ただし、自動生成された内容に「設計意図」「インタラクション要件」「レスポンシブルール」を手動で補足すると、Cursor が生成するコードの精度が上がります。私は自動生成をベースに、30〜60分かけて補足を加えています。
Q：Cursor Rules はどこに書けばいいですか？
A：プロジェクトのルートディレクトリに .cursorrules というファイルを作成し、そこに記述します。内容はプレーンテキスト（または Markdown）で書けます。「DESIGN.md のカラーパレットとスペーシングを必ず参照すること」「Tailwind CSS のクラスを使用すること」のように、プロジェクト固有のルールを箇条書きで列挙するだけで有効です。
Q：Stitch で作ったコンポーネントと Cursor で実装したコンポーネントがどんどん乖離していくのを防ぐには？
A：DESIGN.md を「変更が起きたら必ず更新する」ドキュメントとして扱うことが重要です。Stitch でデザインを修正したら DESIGN.md も更新し、Cursor Rules で「このプロジェクトは DESIGN.md のバージョン○を使用」と明記しておくと管理しやすいです。また、週に一度「Stitch プロトタイプとブラウザ実装の見た目比較」を行うレビューサイクルを設けることで、乖離の蓄積を防げます。
Q：MCP 連携は実用的なレベルに達していますか？
A：2026年4月時点では、Google Stitch の MCP 機能は実験的な段階です。Cursor との接続設定はやや複雑で、安定して動作するかはプロジェクトの環境によります。現時点での私の評価は「将来有望だが、今は DESIGN.md の手動管理と組み合わせて使う段階」です。MCP が安定してくれば、Stitch と Cursor の連携はさらに自動化できるはずです。
Q：Figma と Cursor の連携と比べて、Google Stitch と Cursor の連携はどうですか？
A：Figma は Cursor との連携プラグインが成熟しており、デザイントークンの自動同期や Dev Mode での仕様確認など、より整備されたエコシステムがあります。Google Stitch の連携は現時点では発展途上で、手動での DESIGN.md 管理が主な方法です。ただし、Stitch は AI によるUI生成速度が圧倒的に速いため、「デザイン初稿の生成は Stitch、仕様の管理は DESIGN.md、実装は Cursor」という分業が今の現実的な選択です。
注意点・失敗しやすいポイント
- Stitch のコードをそのまま Cursor に貼り込まない：Stitch のコード出力は見た目の実装であり、アプリとして機能するコードではない。そのまま使おうとするとコードの品質が下がる。
- DESIGN.md を更新し忘れない：Stitch でデザインを修正したのに DESIGN.md を更新しないと、Cursor が古い仕様でコードを生成し続ける。デザイン変更のたびに DESIGN.md も更新するルールを自分に課す。
- Cursor に「なぜ」を伝える：コードの要件だけでなく、設計の意図も DESIGN.md に含めることで、AI が適切な判断をしやすくなる。「このスペーシングが広い理由」「このボタンが赤い理由」を記述しておく。
- Stitch のプロトタイプとコードのレビューを定期的に行う：時間が経つと差分が蓄積する。週次でビジュアル比較を行い、乖離を早期に発見する習慣が大切だ。
- ツールの役割を明確に分ける：Stitch はデザインツール、Cursor はコードツール。どちらかで「もう一方の仕事」をしようとすると非効率になる。
まとめ
Google Stitch と Cursor を組み合わせるワークフローの核心は、「DESIGN.md というバトンを作ること」だ。
Stitch で作ったデザインをそのまま Cursor に渡そうとすると、コードと見た目が乖離していく。しかし、デザインの仕様・意図・ルールを DESIGN.md にまとめ、Cursor がそれを参照してコードを生成するフローを整えると、二つのツールが初めて本当の意味で連携する。
私が今のワークフローにたどり着くまでに試行錯誤したポイントを3つに絞るとすれば——
まず、Stitch のコード出力は「参考資料」として読み、実装のベースとして使わないこと。コードの構造は Cursor に DESIGN.md から生成させた方が品質が高い。
次に、DESIGN.md に「仕様」だけでなく「設計の意図」も書くこと。「なぜこのデザインか」を AI に伝えることで、実装の方向性がぶれにくくなる。
最後に、Stitch のプロトタイプとブラウザ実装を定期的に並べて比較すること。完璧な一致を目指す必要はないが、「雰囲気が違う」と感じた時点で修正することが、乖離の蓄積を防ぐ。
Stitch と Cursor という二つのツールが手元にある。その間にバトンを作る手間を惜しまないことが、デザインとコードを繋げるための、今のところ一番確かな方法だと思っている。
補足：Stitch × Cursor ワークフローのツール設定
このワークフローを試したい人向けに、私が実際に使っている設定を補足しておく。
Google Stitch の設定
Google Stitch は Google Labs が提供しており、Google アカウントがあれば無料で使い始められる（2026年4月時点。無料枠は Standard 生成が月350回、Experimental が月50回）。
Stitch を Cursor 連携向けに使うときのポイントは、デザイン確定後に「DESIGN.md をエクスポート」する操作を習慣化することだ。エクスポートしたファイルをプロジェクトのルートに置き、Git 管理下に入れることで、デザインの変更履歴を追えるようになる。
また、Stitch の Agent Manager 機能（2026年3月追加）を使うと、複数のUIコンポーネントを一括生成・管理できる。ボタン・カード・フォームなどのコンポーネントをまとめて設計し、DESIGN.md に一括書き出すフローは、コンポーネントライブラリを構築する際に特に有効だ。
Cursor の設定
Cursor を Stitch 連携向けに最適化するためにやっていることは3点だ。
まず、.cursorrules ファイルの整備だ。DESIGN.md を参照する指示だけでなく、プロジェクトで使用するフレームワーク（React・Next.js・Tailwind CSS など）とコーディング規則（コンポーネントの命名規則・ファイル構成）を記述しておくと、Cursor が一貫したコードを生成しやすくなる。
次に、コンポーネントディレクトリの構成を Stitch のコンポーネント設計と合わせることだ。Stitch で「Header」「Sidebar」「Card」という命名でコンポーネントを設計したなら、Cursor で生成するファイル名も同じ命名にする。これだけで「どのコードがどのデザインに対応しているか」の追跡が格段に楽になる。
最後に、Cursor Chat でデザイン仕様の確認クエリを使うことだ。「DESIGN.md によると、このボタンのホバー状態は何色？」といったクエリを Cursor に投げると、仕様を参照して回答してくれる。実装中にデザインドキュメントを別途開く手間が省けて効率的だ。
