Google Stitch への期待は人によって異なります。「デザイナーなしでプロダクトのUIが作れる」と期待する人もいれば、「とりあえず試してみた」という人もいる。実際のところ、Stitch はどこまでできて、どこからはできないのか——この記事で正直に整理します。使い始める前に読んでおくことで、「思ったのと違う」という体験を減らすことができます。
「すごい」という印象だけでも「使えない」という評価だけでも不正確です。Stitch の現実を知った上で使う方が、期待と結果のギャップが生まれにくく、適切な場面で最大限に活用できます。「知ってから使う」ことが、このツールから最大の価値を引き出す第一歩です。
Google Stitch でできること
テキストからUIのビジュアルを生成する
「フィットネスアプリのホーム画面、今日のカロリーと歩数を大きく表示して」のようなテキスト指示からUIデザインのビジュアルを生成できます。入力した数秒後に画面デザインが表示され、会話形式で修正を重ねることができます。これが Stitch の最もコアな機能であり、最も活用できる領域です。
スケッチ画像からUIを生成する
紙に描いたラフスケッチや既存のUI画面のスクリーンショットを画像として入力し、それをもとにUIを生成できます。「このスケッチのレイアウトをベースに、モバイルアプリのデザインとして整えて」という使い方です。言葉より絵で伝えた方がイメージが正確に伝わる場合に有効です。スケッチは粗くても認識しますが、配置が明確に描かれているほど意図に近い結果が得られます。
HTML・CSSコードとして書き出す
生成したデザインをHTML/CSSコードとして出力できます。出力したコードをエディタで開いてブラウザで確認したり、エンジニアに渡して実装の参考にしてもらう用途で使えます。コードの品質はプロトタイプレベルであり、本番実装にそのまま使えるものではありませんが、「どういう構造でUIを作るか」の叩き台として機能します。
複数バリエーションを生成して比較する
同じ画面の複数デザイン案を生成して並べることができます。「カード型レイアウトとリスト型レイアウトを両方作って」という指示で、異なる方向性を視覚的に比較できます。デザインの方向性を決める初期段階で、言葉で議論するより画面を見て議論する方が決定が速くなります。
反復的な修正を対話形式で行う
最初の生成後、「ヘッダーの色を変えて」「ボタンを画面下部に移して」のように、会話形式で修正を重ねることができます。試行錯誤しながら理想のデザインに近づけるこのプロセスは、Stitch の使い方として最も実用的です。修正を積み重ねる中で「違う」と感じたらゼロから作り直すこともできます。
Google Stitch でできないこと
Stitch ができないことを知ることは、ツールを正しく使う上でむしろ重要です。
インタラクティブなプロトタイプの作成
ボタンを押したら次の画面に遷移する、フォームに入力したらバリデーションが働く、といった動的なインタラクションを持つプロトタイプは現時点では作れません。生成されるのはUIの「見た目」であり、「動き」の設計は含まれていません。インタラクティブなプロトタイプが必要な場合は、Figma のプロトタイプモードや、ローカルでHTMLを動かす方法を組み合わせる必要があります。
デザインシステムの管理
複数画面にわたってデザインの一貫性を自動で管理する機能は持っていません。ボタンのスタイル、フォントサイズの規則、余白のガイドライン——こうしたデザインシステムを定義して管理することはStitchの対象外です。複数画面を作る場合、スタイルの一貫性は人間がプロンプトで意識的に指定して維持する必要があります。デザインシステムの管理はFigmaが得意とする領域です。
チームでのリアルタイムコラボレーション
複数人が同時にデザインを編集したり、コメントを残してフィードバックを管理したりするコラボレーション機能は現時点では限定的です。Figma のように「チームでデザインを共同管理する」ことを前提としたツールではありません。Stitch で作ったデザインをチームで共有するには、スクリーンショットを送るかコードをファイルで渡すといったアナログな方法が現実的です。
本番品質のコード生成
出力されるHTML/CSSはプロトタイプとして機能しますが、本番環境のWebサービスやアプリで使えるコードではありません。アクセシビリティ属性の適切な設定、レスポンシブデザインの細かな調整、ブラウザ間の互換性対応、パフォーマンスの最適化——これらは生成されたコードに含まれないことが多く、エンジニアが整える工程が必要です。「コードを生成して開発を大幅に速くする」という期待は、現時点では持ちにくいです。
UXの改善提案
「このユーザーフローは使いにくい」「この情報の優先度が低すぎる」「このボタンの配置はタップしにくい」——こうしたUX改善のアドバイスはStitchからは得られません。UIの見た目を生成するツールであり、UXの設計を評価・改善するツールではありません。UXの改善はユーザー調査や専門的な知識が必要で、AIが自動的に判断することは現時点では難しい領域です。
既存デザインとの完全な統合
すでにFigmaでデザインデータを管理しているチームが、Stitchで生成したデザインをそのままFigmaに取り込んでシームレスに使うことは現時点では難しいです。形式の変換や手作業でのコンポーネント再現が必要になります。ツール間の統合という点では、ワークフローに摩擦が生じます。
「期待値」を設定する重要性
Google Stitch を使う前に「できること・できないこと」を把握しておくことで、期待値を適切に設定できます。期待値のズレは、ツールへの不満や誤った使い方の原因になります。
「Stitch でデザインを全部やってもらえる」という期待で使い始めると、できないことにぶつかるたびに「このツールはダメだ」という評価になりがちです。逆に「Stitch はプロトタイプのたたき台を素早く作るツール」という期待で使い始めると、その用途では十分な価値を感じることができます。同じツールでも、期待値によって「使えるツール」にも「使えないツール」にもなります。
この記事で整理した「できること・できないこと」は、そのままStitchの使い方の指針になります。「できること」に集中してツールを活用し、「できないこと」は他の手段で補う設計をすることで、Stitchの価値を最大化できます。
「できること」を使い切っているか確認する
Stitch を使い始めたけど「使えない」と感じている場合、「できること」を十分に活用できていない可能性があります。テキスト入力のみを使っていて画像入力を試していない、最初の生成で満足/失望して修正を重ねていない、一つの画面しか作っていない——こうした「使い方の浅さ」が「使えない」という感覚につながることがあります。Stitch の「できること」の一覧を振り返り、まだ試していない機能を使ってみることが、評価を変えることがあります。
「できないこと」に代替手段を用意する
インタラクティブプロトタイプが必要ならFigma、実装コードが必要ならv0またはClaude、デザインシステムの管理が必要ならFigma——Stitchが「できないこと」には、それを得意とするツールが存在します。Stitch を中心に置いてその弱点を補うエコシステムを設計することで、「Stitch の限界」は「ワークフロー全体の限界」にはなりません。ツールの組み合わせで、単一ツールの限界を超えることができます。
「できること」が拡大していく可能性
Google Labs のツールとして、Stitch は今後アップデートが続くと予想されます。現時点での「できないこと」が、数ヶ月後には「できること」に変わる可能性があります。
AIデザインツールは2024年から2025年にかけて急速に進化しています。1年前の「できないこと」が現在の「できること」になった例は多く、Stitch も同様の進化を続ける可能性があります。現時点での評価を「Stitch の最終評価」とせず、「現時点での状況」として捉え、定期的に新機能を確認しながら使い方を更新していく姿勢が、このカテゴリのツールとの付き合い方として有効です。
また、AIモデル自体の進化がデザイン生成の品質を上げる効果もあります。Gemini の能力向上がStitch の生成品質に直接影響します。ツールへのアップデートがなくても、バックエンドのAIモデルが改善されることで、「できること」の質が上がっていく側面があります。1年前の生成AIが作るUIと、現在の生成AIが作るUIは、同じプロンプトでも品質が異なります。この進化の速度が続く限り、Stitch の「できること」の実質的な範囲は時間とともに広がっていきます。
「できること・できないこと」をふまえた使い方
Stitch の限界を理解した上で、最もうまく機能する使い方を考えます。
「初期フェーズの視覚化ツール」として位置づける
Stitch が最もよく機能するのは、デザインプロセスの初期段階です。アイデアを言葉で話している段階から、視覚的なUIとして確認できる段階に素早く移行するための道具として使う。この位置づけで使うと、Stitch の速さという強みが最も活きます。Figmaでの本格的なデザイン作業や、エンジニアによる実装の「前段階」として Stitch を使うことで、全体のプロセスがスムーズになります。
「見せて議論する」ために使う
ミーティングのたたき台、クライアントへの初期提案、チーム内でのアイデア共有——「言葉だけでなくビジュアルで見せながら議論する」ための道具として Stitch は効果を発揮します。完成度より「方向性を伝えること」が目的の場面では、Stitch の出力は十分に機能します。議論の質が上がることが、Stitch を使う最も実感しやすい効果です。
ユースケース別の「できること」活用例
Stitch の「できること」をどんな場面で最大限に活かせるかを、具体的なユースケースで整理します。
ユースケース①：スタートアップの初期プロダクト
アイデアを形にしてピッチ（投資家への説明）に使いたいスタートアップにとって、Stitch は「デザイナーなしでプロダクトのビジョンを視覚化する」ためのツールとして理想的です。テキストで説明するだけで、アプリの主要画面を数時間で用意できます。MVP（最小限の製品）の概念を視覚的に説明するためのプロトタイプを作ることで、投資家や潜在ユーザーとの対話の質が上がります。「何を作るか」を言葉だけで説明する段階から、「こんな画面を作る」というビジュアルで説明できる段階に移行するための道具です。
ユースケース②：社内ツールのUI改善提案
「この社内ツールはこう改善できる」という提案を、言葉だけでなくビジュアルで示したい場合に活用できます。「現状の問題点」と「改善案のUI」を並べてプレゼンすることで、提案の説得力が上がります。社内の承認プロセスで「どういうUIになるか」を事前に見せることは、合意形成を速める効果があります。Stitch で作った改善案UIを資料に組み込み、承認を取ってから専門家（デザイナー・エンジニア）に依頼する、という流れがスムーズです。
ユースケース③：クライアントへの初期提案
Web制作やアプリ開発の提案フェーズで、複数のデザイン方向性を素早くビジュアル化して見せることができます。「ミニマル系」「カラフル系」「コンテンツ重視」などの方向性の違いを、言葉だけでなく実際のUIデザインで見せることで、クライアントの好みを早期に把握できます。提案の初期段階で方向性の合意を取ってから詳細なデザイン作業に入ることで、後の修正が減ります。Stitch が「提案の効率化」と「クライアントとのコミュニケーション改善」の両方に貢献します。
ユースケース④：デザイン教育・学習の場
デザインを学ぶ人にとって、Stitch は「試しながら学ぶ」ための教材としても機能します。「カード型レイアウトとリスト型レイアウトの違い」「ダークテーマとライトテーマの印象の違い」を、実際のUIを生成して比較することで、デザインの概念を体感的に理解できます。「こういうプロンプトを書いたら、こういうUIが出た」という経験の積み重ねが、デザインの感覚を養います。専門書を読むだけでなく、Stitch を使って実際に手を動かすことと組み合わせることで、デザインの学習が加速します。
「できないこと」が問題にならないケース
Stitch の「できないこと」は、すべての使い方において問題になるわけではありません。ユースケースによっては、「できないこと」が実際の障害にならないケースが多くあります。
インタラクティブプロトタイプが不要な場面
「デザインの方向性を確認したい」「ステークホルダーに概念を見せたい」という目的では、クリックできる動くプロトタイプは必須ではありません。静的なビジュアルを「説明のための資料」として使う場合、Stitch の出力は十分機能します。「動くプロトタイプが必要か」を考えると、多くの場面では静的なビジュアルで代替できることがわかります。
デザインシステムの管理が不要な段階
プロダクトの初期段階や、1〜2画面程度のプロトタイプを作る場合、複数画面にわたるデザインシステムの管理は不要です。「今必要なのはこの1画面のUI案」という用途では、デザインシステム管理機能の欠如は問題にならません。プロダクトが成長して複数画面の管理が必要になった段階で、Figmaへの移行を検討すれば良いです。
本番品質のコードが不要な場面
「デザインの方向性を示す参考資料としてコードを渡す」という用途では、本番品質でないコードでも価値があります。エンジニアが「このビジュアルイメージで実装してほしい」という指示材料としてコードを受け取り、自分たちのコードベースに合わせて書き直す場合、Stitch のコード出力は「完成したコード」ではなく「参照コード」として機能します。
「できないこと」に対する正直な評価
Stitch の「できないこと」を列挙すると、「欠点が多いツール」に見えるかもしれません。でも現実は少し違います。「できないこと」の多くは「まだ実装されていない」のであり、ツールとしての設計方針や品質の問題ではありません。
Google Labs のツールは「完成品を提供する」のではなく「実験的な価値を届ける」という性質のものです。完成度よりスピードを優先して公開される分、「できること」は限定的でも、「この方向性は価値がある」という判断で提供されています。現時点での限界を「このツールの限界」と見なすより、「この段階での状態」として見ることが、ツールを正しく評価することにつながります。
Figma も、v0 も、最初から今のような機能を持っていたわけではありません。使われながら改善され、フィードバックを受けて機能が拡充されてきました。Stitch も同じ道を歩む可能性が高いです。早い段階から使い続けることは、ツールの成長に伴って「使い方が深まっていく」体験を積める機会でもあります。
今の「できること」で始めることの価値
「もっと機能が増えてから使おう」という先送りより、「今の機能でできることをやる」という姿勢の方が、長期的に見て多くを得られます。ツールに慣れるには使い続けることが必要で、「準備ができてから」ではなく「今できることから」始める人の方が、ツールが進化したときに深い活用ができます。現時点でできることを最大限に使い切っている人が、新機能が追加されたときに最も早くそれを活かせます。Stitch の「今できること」を起点に、使い方を積み上げていくことが、ツールとの良い付き合い方です。
よくある質問
Q. Google Stitch は将来的にもっと多くのことができるようになりますか？
Google Labs のツールとして継続的に改善されることが期待されます。現時点での「できないこと」の多くは、技術的な制約ではなく「まだ実装されていない」ものです。インタラクティブプロトタイプの生成、より高品質なコード出力、チームコラボレーション機能——これらは将来のアップデートで追加される可能性があります。ただしGoogle Labsツールの将来は確約されないため、現時点の機能に基づいて判断することが重要です。
Q. できないことが多いなら使う意味はありますか？
「できること」が自分のユースケースにフィットしているかどうかが重要です。「アイデアを素早くビジュアル化したい」「デザイナーなしでプロトタイプのたたき台を作りたい」「チームのUI議論の質を上げたい」——これらが目的なら、Stitch は十分な価値を提供します。「本番品質のコードを作りたい」「完全なデザインシステムを管理したい」が目的なら、他のツールを選ぶ方が適切です。ツールは万能である必要はなく、自分の目的に合っているかどうかが使う判断基準です。「できること」が自分のニーズの7割を満たしていれば、残り3割を他の方法で補いながら使う価値は十分にあります。
Q. 「できないこと」はどうやって補えばいいですか？
Stitch が「できないこと」は他のツールで補うアプローチが実用的です。インタラクティブプロトタイプはFigmaで、本番コードはv0やClaudeで、デザインシステム管理はFigmaで——それぞれを組み合わせることで、Stitchの弱点を他のツールでカバーできます。「一つのツールで全部やる」より「各ツールの強みを使い分ける」という発想が、AIデザインツールを活用する上での現実的な方針です。ツールの組み合わせパターンを一度設計しておくと、毎回「このケースはどのツールを使うか」を考えずに済み、作業のリズムが安定します。
Q. Stitch を使い始めるのに最適なタイミングはいつですか？
「今すぐ」が最適なタイミングです。Google Labs のツールは変化が速く、「準備が整ってから」という時間を待っていると、ツール自体が変わっていることもあります。また、ツールに慣れるには実際に使うことが最短経路で、「準備」として知識を積み上げるより「使いながら学ぶ」方が効率的です。「まず一つ、シンプルな画面を生成してみる」という小さな一歩から始めることで、Stitch の実際の価値が体感できます。
Q. Stitch は個人利用に向いていますか、チーム利用に向いていますか？
どちらにも向いています。個人利用では「自分のアイデアを素早くビジュアル化する」「個人プロジェクトのUIを手軽に作る」という使い方が有効です。チーム利用では「UIの共通認識を作るためのコミュニケーションツール」としての価値が大きいです。個人では「作る速さ」、チームでは「合意形成の速さ」というそれぞれの価値がありますが、どちらも「テキストからUIを素早く生成できる」というStitchの核心的な機能から来ています。チームで使う場合は、全員が「Stitchはビジュアル確認ツール」という共通認識を持つことが、活用の質を上げる上で重要です。
Google Stitch は「できること」と「できないこと」を正確に把握した上で使うことで、初めてその真価を発揮します。期待値を正しく設定し、強みを活かした使い方を続けていきましょう。
