Google Stitch でUIを作り始めて、こんな疑問を持ったことはないだろうか。
「スマホ用のデザインはできた。でも、タブレットやPCにも対応させるには、どうすればいい？」
AIがプロンプト1つで画面を生成してくれる便利さに感動しつつも、複数デバイスを意識した設計をしようとすると、途端に壁にぶつかる。「レスポンシブで作って」と書けばいいのか、デバイスを別々に指定すべきなのか、生成されたHTMLはそのまま実装に使えるのか——答えが出ないまま時間だけが過ぎた経験を、私もした。
このブログでは Google Stitch の活用事例をさまざまな角度から書いてきたが、「レスポンシブ対応の実態」についてはあえて後回しにしていた。曖昧な理解のまま書いて、読んだ人が誤解するのが嫌だったからだ。今回は実際に試した操作をもとに、正直に整理することにした。
「Stitch を使えばすべて解決」ではなく、「どう使えば現実的なマルチデバイス対応ができるか」を考えるための記事として読んでほしい。
結論：Stitch でレスポンシブデザインはどこまでできるか
一言で言えば、Google Stitch は「デバイスを指定したUI生成」はできるが、「真のレスポンシブデザイン（自動ブレークポイント管理）」には現時点で対応していない。
スマホ・タブレット・PC それぞれの画面を個別に生成し、デザインを揃えることは可能だ。しかし、1つのUIを生成するだけでブレークポイントに応じてレイアウトが自動切り替えされる、いわゆる「真のレスポンシブ」は 2026 年 4 月時点では未対応である。実装段階での CSS による追加対応が必要になる。
この前提を理解した上で使えば、Google Stitch は依然として強力なツールだ。逆にこの前提を知らずに使い始めると、「思ったより手間がかかる」と感じることになる。
Google Stitch とは何か
Google Stitch とは、テキストプロンプト・スケッチ・スクリーンショットから UI デザインとプロトタイプを自動生成する AI デザインツールのことだ。Google Labs が提供しており、2025 年の公開後、急速にデザイナーや非デザイナーの間に広まった。
Google が Galileo AI を買収した技術を基盤にしており、「テキストを入力するだけで画面が生成される」という体験がデザインの敷居を大きく下げた。
2026 年 3 月に公開された Stitch 2.0（大型アップデート）では、以下の機能が追加されている（Google Labs が 2026 年 3 月に公式発表）。
- 最大 5 画面の同時生成（マルチスクリーンキャンバス）
- 無限キャンバス（Infinite Canvas）
- 音声入力によるプロンプト入力
- インタラクティブなプロトタイプ遷移
2026 年 4 月時点では、月あたり 350 回の標準生成と 200 回の Experimental 生成が無料で利用可能（Google Labs 公式情報）。
レスポンシブデザインとは何か
レスポンシブデザインとは、スマートフォン・タブレット・デスクトップ PC など異なるデバイスの画面サイズに応じて、同一の HTML コードが自動的にレイアウトを切り替える Web デザイン手法のことだ。
CSS のメディアクエリや Flexbox・CSS Grid を使い、「特定の画面幅（ブレークポイント）」を境に表示が変わるよう設計する。デスクトップでは横 3 列に並んでいたカードが、スマホでは縦 1 列に並びかわる——そのような動的なレイアウト変化がレスポンシブデザインの核心だ。
Stitch の「デバイス指定生成」との違い
Google Stitch が現在対応しているのは、「スマホ用のデザイン」「PC 用のデザイン」を個別に生成することだ。これはレスポンシブデザインとは本質的に異なる。
デバイス指定生成（Stitch が対応している機能）：
- スマホ用デザインを 1 画面生成する
- PC 用デザインを別途 1 画面生成する
- 見た目の統一感をプロンプトで調整する
真のレスポンシブデザイン（Stitch が未対応の機能）：
- 1 つの HTML ファイルが画面幅に応じてレイアウトを切り替える
- ブレークポイント（例：768px 以下はモバイル表示）を自動設定する
- デザイナーが意図したメディアクエリ付き CSS が書き出される
この違いを理解することが、Google Stitch を使ったマルチデバイス対応の第一歩だ。
実際にやってみた：スマホ・タブレット・PC の 3 画面を作る
実際に私が試した手順を記録する。テーマは「飲食店向けの予約フォームページ」。スマホ・タブレット・PC の 3 デバイス用 UI を Stitch だけで設計することが目標だった。
スマホ用デザインの生成
試したプロンプト：「飲食店の予約フォームページ、スマートフォン用（375px 幅）。上部にレストランのヘッダー画像、下に名前・人数・日時・コメントのフォーム。送信ボタンはオレンジ色。シンプルで読みやすいデザイン。」
結果：1 回の生成でほぼ意図通りのデザインが出力された。フォームのフィールド配置、ボタンの色、フォントサイズのバランスも自然だ。スマホ縦画面に最適化されたレイアウトを素早く出せることは、Stitch の明確な強みだと感じた。
タブレット・PC 用デザインへの展開
同じプロンプトの末尾を「タブレット用（768px 幅）」「デスクトップ PC 用（1440px 幅）」に変えて、それぞれ生成してみた。
タブレット用では、スマホ版と同じコンポーネントが少し広がった形で出力された。フォームが 2 列になり、ヘッダー画像の高さも適切に変わった。ただし、スマホ版と完全に同じデザインシステム（色・フォント）が適用されているわけではなく、微妙な差異が生まれた。これを揃えるには「スマホ版と同じカラーコードとフォントを使う」という一文をプロンプトに明示する必要があった。
PC 用では、2 カラムレイアウトで左に情報・右にフォームが配置された。デザインとしては洗練されていたが、スマホ版・タブレット版との整合性が取れておらず、3 つの画面をつなぎ合わせるには「統一感の修正プロンプト」を複数回追加する必要があった。
実装者への引き渡しで起きた問題
3 画面のデザインが揃ったところで、エンジニアへの引き渡しを試みた。ここで問題が起きた。
Stitch から書き出した HTML は、それぞれのデバイス向けに独立したファイルになっている。メディアクエリを含む「レスポンシブな 1 ファイル」ではなく、デバイスごとの HTML が別々に出力される形だ。エンジニアがこれを 1 つのレスポンシブなコードに統合するには、手動で CSS のメディアクエリを書き直す必要があった。
実際に使ってみて分かったのは、Stitch はデザインの「たたき台」として使うのが最も効果的だということだ。「完璧な実装ファイルを自動生成するツール」としての期待は手放した方がいい。
レスポンシブ対応を効率化するプロンプト術
Stitch でマルチデバイス対応を効率化するには、プロンプトの書き方が鍵になる。実際に効果があった工夫を整理する。
デバイスを最初に宣言し、画面幅を数値で指定する
プロンプトの冒頭でデバイス種別と画面幅を明示する。「スマートフォン用（375px 幅）」「タブレット用（768px 幅）」「デスクトップ PC 用（1440px 幅）」と数値を添えると、コンポーネントの大きさ・余白・フォントサイズが適切な範囲に収まりやすい。「モバイル用」とだけ書くより、出力の精度が明らかに上がる。
2 画面目以降に「前のデザインを継続する」旨を明示する
2 画面目以降を生成するとき、「前の画面と同じカラーパレット・フォントサイズ・ボタンスタイルを維持してください」という一文を冒頭に追加する。これだけで 3 画面の統一感が大幅に向上した。具体的なカラーコード（例：#FF6B35）を毎回プロンプトに含めると、さらに再現性が上がる。
Stitch 2.0 のマルチスクリーンキャンバスを使えば、最大 5 画面を同一セッション内で生成できるため、デザイン一貫性の維持がより容易になっている。ただし、1 画面を修正した際に他の画面が連動して更新される機能はまだない。
実装を見越した指示を入れる
「このデザインをHTMLとCSSで書き出すとき、Flexbox を使ったレイアウトにしてください」という指示をプロンプトに含めると、書き出されるコードが実装しやすい構造になる傾向がある。また、「コンポーネントを命名してください（例：予約フォームセクション、ヘッダー画像エリア）」と指示すると、エンジニアへの引き渡し時のコミュニケーションコストが下がった。
Stitch の限界を補う補完ワークフロー
Google Stitch 単体で補えない部分は、他のツールとの組み合わせで解消できる。
Stitch → Figma でブレークポイントを管理する
Stitch で生成したデザインを Figma にインポートし、ブレークポイントごとのレイアウト管理を Figma で行う方法だ。Figma の Auto Layout を使えば、コンポーネントが画面幅に応じて自動調整される設計が可能になる。
手順は次のとおり。(1) Stitch でデバイスごとのデザイン案を生成 → (2) Figma にコピー → (3) Figma で統一コンポーネントとして組み直す。「アイデア出しは Stitch で、清書は Figma で」という分担だ。
Stitch → エンジニアへのコードレビューフロー
Stitch が出力した HTML をベースに、エンジニアが CSS のメディアクエリを後付けする方法も現実的だ。この場合、デザイン担当者とエンジニアの間で事前に「どのブレークポイントで何が変わるか」を言語化しておくことが重要になる。
私がプロジェクトで試したときは、Stitch のアウトプットをもとに「スマホ版レイアウトの解説ドキュメント」を Notion にまとめ、それをエンジニアに渡した。コードの移植に要した時間は、ゼロから設計するより大幅に削減できた。
Stitch → Webflow での再実装
Stitch のデザインを視覚的な参考として、Webflow のデザインエディタで UI を再構築する方法も有効だ。Webflow はレスポンシブデザインを前提とした設計ツールなので、Stitch でアイデアを固めてから Webflow で形にするワークフローは相性がいい。
よくある質問（FAQ）
Q1. Google Stitch は「レスポンシブ対応の HTML ファイル」を直接書き出せますか？
2026 年 4 月時点では、Stitch が書き出す HTML は特定デバイス向けの静的なファイルです。メディアクエリを自動で付与してレスポンシブなコードを生成する機能は現在ありません。出力されたコードをエンジニアがメディアクエリ対応に改修するか、Webflow や Bubble などのノーコードツールで再実装するのが現実的なワークフローです。
Q2. スマホ・PC の両方のデザインを一度に生成できますか？
Stitch 2.0（2026 年 3 月アップデート）のマルチスクリーンキャンバス機能を使えば、最大 5 画面を同一セッションで生成できます。ただし「スマホ版とPC版の両方を生成してください」とプロンプトで明示的に指定する必要があります。指定がない場合、多くはモバイル優先の 1 デバイス向けデザインが出力されます。
Q3. タブレット対応はなぜ難しいのですか？
タブレット（768px 幅前後）はスマホでも PC でもない「中間サイズ」のため、Stitch の自動判断が難しいデバイスです。プロンプトで「タブレット用・横幅 768px・2 カラムレイアウト」のように明示しないと、スマホ版を拡大しただけのようなデザインになりがちです。最低でも「カラム数」と「フォントサイズの変化の有無」をプロンプトに含めることをおすすめします。
Q4. デバイスごとに生成したデザインの一貫性はどう保てばいいですか？
同一セッション内で連続して生成し、2 回目以降のプロンプトに「前の画面と同じデザインシステムを維持して」と追記するのが最も確実な方法です。別セッションで生成する場合は、カラーコード・フォント名・ボタン形状を毎回プロンプトに明記する必要があります。Stitch には Figma のようなデザイントークン管理機能がないため、プロンプトによる「言語的な一貫性維持」が唯一の手段です。
Q5. 将来的に Google Stitch はレスポンシブ対応を強化する予定がありますか？
2026 年 4 月時点での公式発表では、レスポンシブデザインの自動生成機能についての具体的なロードマップは示されていません。ただし 2026 年 3 月の Stitch 2.0 では機能の大幅拡充が行われており、継続的な機能追加が進んでいる状況です。今後のアップデートを継続的に確認することをおすすめします。
Q6. Stitch で作ったデザインを Webflow に移せますか？
Stitch の HTML を Webflow にそのままインポートする公式連携機能は現在ありません。ただし、Stitch のデザインを視覚的な参考として Webflow のエディタで再構築する方法は有効です。「Stitch で素早くプロトタイプを繰り返しアイデアを固め、最終実装は Webflow で」というワークフローを取っているチームもあります。
Q7. Stitch と Figma を両方使う必要がありますか？
必須ではありません。Stitch だけでも「デバイスごとのデザイン案」は揃えられます。ただしデザインシステムを厳格に管理したい場合、エンジニアへのハンドオフを洗練させたい場合は、Figma と組み合わせるとスムーズです。プロジェクトの規模と要件に応じて使い分けるのが現実的な判断です。
注意点・失敗しやすいポイント
1. 「レスポンシブで作って」というプロンプトは効かない
「レスポンシブデザインにしてください」とプロンプトに書いても、Stitch はメディアクエリ付きの CSS を出力しない。このプロンプトは現時点では機能しないため、「デバイスを個別に指定して複数の画面を生成する」という思考に切り替える必要がある。
2. 別セッションで生成すると一貫性が崩れる
Stitch はセッションをまたぐとデザインの記憶がリセットされる。スマホ版と PC 版を別のセッションで生成すると、カラーやフォントが微妙に異なるデザインになる。必ず同一セッション内で複数デバイス分を生成するか、カラーコードとフォント名をプロンプトにコピーして使い回すこと。
3. 書き出した HTML をそのまま本番実装に使わない
Stitch の HTML 出力は「デザインの再現」が主目的であり、本番実装を想定したコードではない。インラインスタイルが多く含まれ、クラス名が意味を持たない自動生成名になっていることが多い。エンジニアへの引き渡し時には「デザイン参考用のコード」と明示し、実装はゼロから書き直すか十分なコードレビューを経て使用することを推奨する。
4. タブレット対応を後回しにしない
「まずスマホと PC だけ」と進めると、タブレット対応が後回しになりがちだ。後から追加しようとすると、2 デバイス版との統一感を取るのに余計な時間がかかる。最初から 3 デバイスを 1 セットとして設計する方が、トータルの工数は少なくなる。
5. プロトタイプ遷移とレスポンシブを混同しない
Stitch 2.0 のインタラクティブなプロトタイプ遷移機能は「画面間の遷移を可視化する」機能であり、レスポンシブデザインの確認（画面幅を変えたときにレイアウトが崩れないか）とは別の話だ。プロトタイプを確認したからといって「レスポンシブ対応ができた」と判断しないよう注意が必要だ。
まとめ：Stitch でのレスポンシブ対応、今の現実と向き合い方
この記事の問い——「Google Stitch でレスポンシブデザインは作れるか？」——に対する答えは、「デバイスごとのデザイン生成はできる。真のレスポンシブ（自動ブレークポイント管理）はできない」だ。
これは Stitch の欠点ではなく、現時点でのツールの「立ち位置」だと思っている。Stitch は「アイデアを素早く形にする」ことに特化しており、「完璧な実装ファイルを自動生成する」ことは目指していない。使い方の期待値を正しく設定することが、このツールを使いこなす最大のコツだ。
実際に使い続けて感じるのは、「思考スピードに追いつくデザインツール」という感覚だ。プロンプトを書けば秒単位でデザインが出てくる体験は、ゼロから画面を組む作業と根本的に異なる。そのスピード感を活かして「3 デバイスの設計をたたき台レベルで揃える」だけでも、プロジェクトの進行速度は明らかに変わる。
レスポンシブデザインの「完成形」は Figma・エンジニアとの協業で作る。Stitch はその起点として使う——この分担を意識するだけで、Stitch の限界をほぼ気にせず使えるようになる。
2026 年 3 月の大型アップデートで機能が拡充した Stitch が、次の 1 年でレスポンシブ対応を追加してくる可能性は十分ある。今の段階で「できること・できないこと」を正確に把握しておくことは、次のアップデートを素早く乗りこなすための準備にもなる。
まず今日、Stitch を開いて「スマホ版」と「PC 版」の 2 画面を作ってみてほしい。その体験が、あなた自身のレスポンシブ活用の出発点になるはずだ。
