私たちのチームには専任のデザイナーがいません。3人のメンバーで構成された小さなプロダクトチームで、エンジニア2人とプロダクトマネージャーの私という構成です。UIのデザインはずっと「エンジニアが感覚で作る」か、「私がパワーポイントで手書きのワイヤーフレームを作る」かのどちらかでした。「デザイナーを雇えればいい」とはずっと思いつつ、採用コストと固定費の問題で、解決できていない課題でした。
Google Stitch を使い始めてから半年が経ちます。この記事では、デザイナーが不在のチームがStitchを導入してみて、実際に何が変わり、何が変わらなかったかを正直に書きます。「すごかった」という話だけでなく、「期待外れだった部分」も含めて書くことで、同じような状況のチームの現実的な判断材料になればと思っています。
導入前の状況
Stitch を使い始める前、チームのUIデザインプロセスは正直なところうまく機能していませんでした。毎回「なんとかする」状態で乗り越えていたものの、それが蓄積するにつれてUIの質への不安が高まっていました。
私がパワーポイントで作るワイヤーフレームは、四角とテキストを並べた程度のもので、実際のUIの見た目を想像するには経験が必要でした。チームミーティングでワイヤーフレームを見せても、「これがどういう見た目になるのか」は各メンバーが頭の中で補完するしかなかった。「私のイメージと違った」という会話が何度もありました。
エンジニアが「感覚で作った」UIは、機能的には問題ないのに見た目がいまいちということが多かった。デザイナーがいれば解決する問題でも、費用や採用の問題で専任デザイナーを雇えない状態が続いていました。
解決したかった課題
導入前に感じていた具体的な課題は次の3つでした。「チームメンバー間でUIのイメージを共有できていない」「ユーザーテストに持っていけるクオリティのプロトタイプが作れない」「UIの議論に時間がかかりすぎる」——これらを解決できるか、という視点でStitchを試し始めました。半年後に振り返ると、この3つの課題のうち2つは改善され、1つ（コードの実装への活用）は想定外の壁にぶつかりました。その詳細を以下で説明します。
導入してから変わったこと
半年使い続けて、実際に変わったと感じることがいくつかあります。
UIの共通イメージが持てるようになった
最も大きな変化は「チームでUIのイメージを共有する」ことができるようになった点です。以前のワイヤーフレームは抽象的すぎて、メンバーによって思い描くイメージが違っていました。Stitch で生成した画面を見せると、「こういう見た目のものを作る」という認識が一致しやすくなりました。
「このボタンはもう少し目立たせたい」「このリストは横スクロールよりタブで切り替えたい」という具体的な議論がしやすくなりました。抽象的なワイヤーフレームを見ながら話すより、ビジュアルを見ながら話す方が議論が速く、「言っていることが伝わらない」というストレスが減りました。
プロトタイプを外部に見せられるようになった
以前は「パワーポイントのワイヤーフレームは外に見せられない」と感じて、ユーザーインタビューやステークホルダーへの提案に出せていませんでした。Stitch で作ったプロトタイプは、クオリティとして「方向性を伝える」には十分なレベルで、外に見せられるものになりました。
ユーザーインタビューで「この画面のここが使いにくそう」というフィードバックを早い段階で得られるようになったことは、開発サイクル全体の質を上げる効果がありました。「作ってから直す」より「作る前に確認する」ができるようになった分、手戻りが減りました。プロトタイプを外に見せることで「想定していなかった使い方をするユーザーがいる」という発見も生まれ、要件の見直しに役立ったケースもありました。
UIの議論に使う時間が変わった
UIに関する会議の質が変わりました。以前は「どういうUIにするか」という抽象的な議論が長続きしていました。Stitch でたたき台を用意してから会議に臨むと、「このたたき台のこの部分をどう変えるか」という具体的な議論になります。会議の時間は変わっていませんが、「決まること」の量が増えました。
変わらなかったこと・限界を感じたこと
良い変化がある一方で、Stitch では解決しなかった課題もあります。
デザインシステムの不在は解決しない
Stitch で各画面を個別に作れるようになりましたが、「画面をまたいだデザインの一貫性」は依然として難しい問題です。ボタンのスタイル、フォントサイズのルール、余白の基準——こうしたデザインシステムが定義されていないと、画面を追加するたびにスタイルがばらつきます。Stitch は一画面を素早く作る助けにはなりますが、デザインシステムを構築・管理する機能は持っていません。複数画面の一貫性を保つためには、人間が意識的にルールを管理し続ける必要があります。
微妙なUX判断は人間が必要
「このユーザーにとってこのフローは自然か」「この情報の優先度は正しいか」というUXの判断は、Stitch には委ねられません。UIの「見た目」は生成できますが、「使いやすさ」の判断にはユーザーへの理解が必要で、それはAIが自動的に判断できるものではありません。デザイナーがいないチームにとって、この判断力の不在は継続的な課題です。Stitch は見た目を作ることを助けてくれましたが、「良いUX」を作ることは別の問題として残り続けています。
生成したコードを実装で使う壁
Stitch が出力するHTML/CSSを実際の開発に活用しようとしたとき、エンジニアから「このコードはそのまま使えない」という反応がありました。構造やクラス名の設計が既存のコードベースと合わないため、参考にはなるが手動で書き直す必要があるというのが現実でした。「Stitch でコードを生成すれば実装も速くなる」という期待は、私たちのチームでは実現しませんでした。「ビジュアルを確認する」ために使うと割り切った時点で、使い方が安定しました。「完成コードを生成するツール」として期待していたときより、「UIビジュアルを素早く確認するツール」として使ったときの方が、チームへの価値提供が明確で、使い続けるモチベーションも維持できました。
チームへの浸透について
私（プロダクトマネージャー）が使い始めた Stitch を、チームに広げるプロセスも一つの経験でした。
エンジニアの一人は最初「Stitch で作ったUIをそのまま実装するのは無理がある」という懸念を持っていました。「Stitch はあくまでビジュアル確認ツールで、実装コードの生成は期待していない」と伝えると、使い方の期待値が揃いました。もう一人のエンジニアはStitchに対してニュートラルで、「プロトタイプを見ながら議論できるなら便利」とすぐに受け入れてくれました。
チームへの導入で重要だったのは「このツールで何を期待するか、何を期待しないか」を最初に合わせることでした。過大な期待と過小な評価の両方を避けるための「期待値の設定」が、チーム導入の成否に関わると感じています。ツールを導入するとき、機能の説明より「このツールを使うことでチームの何が変わるか」を言語化して共有することの方が、浸透には重要です。「Stitch はビジュアル確認ツール」というシンプルな定義を全員が持つことで、使い方の方向性が揃いました。
デザイナー不在チームへのアドバイス
同じようにデザイナーがいないチームが Google Stitch を検討している場合、経験からいくつかアドバイスできることがあります。
まず「Stitch でできること」の範囲を最初から明確にしておくことが重要です。「UIのビジュアルを素早くたたき台として作れる」というのが現実的な期待値で、「デザイナーの代替になる」という期待は持たない方が良いです。ビジュアルのたたき台を作ることでチームのコミュニケーションが改善されるというのが、Stitch の最大の貢献でした。
次に、Stitch を使いながら「デザインの基礎知識」を少しずつ積み重ねることをおすすめします。プロンプトを書く中で「ヒエラルキー」「ホワイトスペース」「一貫性」といったデザインの概念に自然と触れます。専門書を読んで学ぶより、実際にデザインを作りながら学ぶ方が身につきやすいことがあります。Stitch は「使いながら学べるデザイン入門ツール」としての側面も持っています。
Stitch 導入で変わったチームの動き方
Google Stitch を使うようになってから、チームの作業の進め方に変化がありました。ツールが変わることで、チームの行動パターンも変わるということを実感した半年間でした。
「会議の前にたたき台を用意する」が習慣になった
Stitch を使う前は、「UIについて話し合う会議」が「何を作るか決める場」でもありました。白紙から議論するため、話がまとまりにくく、会議が長くなりがちでした。Stitch を使うようになってから、「会議の前にStitchでたたき台を2〜3案作って持ち込む」という習慣が自然に生まれました。たたき台があると「このたたき台のこの部分をどう変えるか」という具体的な議論になり、決定が速くなりました。「空白の会議室でゼロから議論する」から「ビジュアルを見ながら改善を議論する」への変化は、会議の質を変えました。
「実装の前に確認する」プロセスが入った
エンジニアが実装を始める前に「こういうUIになる予定です」という確認を、Stitch のプロトタイプを使って行うようになりました。以前は「実装してから見てみないとわからない」という流れで、「できたけど思ったのと違う」という状況が発生していました。Stitch を確認フォーマットとして使うことで、「作る前に合意する」プロセスが入り、実装後の修正が減りました。
UIに関する会話が増えた
Stitch を使うようになってから、エンジニアがUIについて自分の意見を言いやすくなった気がします。言葉だけで「こういうUIにしたい」と話すより、画面を見ながら「このボタンはここに移した方が操作しやすい」と話す方が、意見が出やすいです。Stitch がUIの共通言語を作る助けになったと感じています。チーム全体がUIの議論に参加できるようになったことは、デザイナーがいないチームにとって特に大きな変化でした。
Stitch が特に役に立ったシーン
半年間の使用の中で、Stitch が特に役に立ったと感じた具体的な場面があります。
投資家へのデモ資料を2時間で用意したとき
突然「来週、投資家との面談がある。プロダクトのUIを見せたい」という状況になりました。以前ならデザイナーなしでは対応できなかったこの状況を、Stitch で乗り切りました。主要な画面（ホーム・詳細・設定）を2時間で生成し、スクリーンショットを資料に組み込みました。「完成したプロダクトのUI」ではなく「プロダクトのビジョンを伝えるビジュアル」として提示することで、投資家に方向性を伝えることができました。デザイナーに依頼していたら納期に間に合わなかった場面で、Stitch が時間的な制約を解決してくれました。
ユーザーインタビューの直前にUIを変えたとき
ユーザーインタビューの前日に「現在のUIでは伝わりにくい部分がある」と気づき、急いで改善案を作る必要がありました。Stitch で修正版のUIを30分で生成し、翌日のインタビューで使うことができました。「インタビューを延期するか、現状のUIで臨むか」という二択が「改善したUIで臨む」という選択肢に変わりました。この柔軟性は、Stitch がなければ得られなかったものです。
機能追加の議論でアイデアを即座に可視化したとき
チームミーティングで「新しい機能のUIをどうするか」という議論が始まったとき、その場でStitchを開いて「こういうことですか?」という画面をリアルタイムで生成しました。言葉で説明するより生成した画面を見せる方が議論が速く進み、15分で方向性が決まりました。「ミーティング中にプロトタイプを作って議論の即席ツールにする」という使い方は、導入前には想定していなかった活用法でした。
正直な改善要望
6ヶ月使った上での、Stitch への率直な改善要望もあります。
最も強く感じるのは「複数画面にわたるスタイルの一貫性管理」機能です。「このプロジェクトのデザインシステム」を一度設定すれば、その後の生成に自動的に引き継がれる仕組みがあれば、複数画面を作るときの手間が大幅に減ります。現時点では毎回プロンプトにスタイル情報を書く必要があり、これを忘れると画面間でスタイルがばらつきます。
次に「Figmaへのエクスポート機能」です。Stitch で作ったデザインをFigmaのコンポーネントとしてエクスポートできれば、「Stitch で方向性を決める→Figmaで精密化する」というワークフローがよりスムーズになります。現時点ではスクリーンショットを参照しながらFigmaで作り直す手間があり、ここに摩擦があります。ツール間の橋渡しがより滑らかになれば、Stitchの活用価値はさらに高まります。
これらは現時点での要望であり、Google Labs のツールとして今後改善されることも期待しています。現状の機能でも十分な価値があることは確かで、今後の改善があれば活用の幅がさらに広がると感じています。半年間の利用を通じて、このツールへの信頼感は増しています。
導入してから6ヶ月でわかったこと
半年使い続けて、Stitch との付き合い方について自分なりの結論が出てきました。
「Stitch は魔法のツールではない」というのが正直な感想です。デザイナーの代わりにはなりません。プロのUIデザイナーが作るものとは、現時点では明らかな差があります。でも「専任デザイナーがいないチームが、デザインについて議論できる状態を作る」という目的には、十分に機能しています。
Stitch を使うことで、「UIについて考えること」の頻度が増えました。ツールを使ってデザインを作るプロセスを繰り返すうちに、「なぜこのレイアウトがいいのか」「このボタンの色は何を伝えているのか」という問いを持つようになりました。デザイン専門書を読んで学ぶより、実際に手を動かしながら試行錯誤することの方が、私には合った学び方でした。
「デザイナーがいない」という状況は変わっていませんが、「デザインについて考え、議論できる」という状況は変わりました。この変化は、Stitch なしでは生まれにくかったと思っています。ツールは使うことで習慣を作り、習慣が文化を作る——これが半年使い続けて実感したことです。デザイナーのいないチームにとって、UIデザインを「画面を見ながら議論する」という文化が生まれたことは、Stitch が残した最も重要な変化でした。完璧な解決策ではないけれど、「何もない状態より確実に良くなった」と言えます。同じような状況のチームに、まず一度試してみることをおすすめします。
よくある質問
Q. Stitch を使い始めるのに準備は必要ですか？
特別な準備は必要ありません。Google アカウントでログインして、Google Labs からStitchにアクセスできれば始められます。デザインの知識も、コードの知識も必要ありません。「こんな画面が欲しい」というアイデアと、それを日本語か英語で説明できることが唯一の条件です。最初は「シンプルなログイン画面を作って」のような短い一文から始めて、生成結果を見ながら修正していけば、使い方の感覚は自然につかめます。チームで導入する場合も、まず一人が試して「こういう使い方ができる」という体験を持ってから、チームに見せるという順序が浸透しやすいです。
Q. Stitch の学習コストはどのくらいですか？
「基本的な使い方に慣れる」には1〜2時間程度です。テキストを入力してUIを生成し、修正を加えるという基本フローは非常にシンプルなため、長い学習期間は必要ありません。「より精度の高いプロンプトを書けるようになる」という意味での習熟には、使い続けることが必要で、数週間から1ヶ月程度のアクティブな利用で体感的な上達が感じられます。デザインの知識があると習熟が早くなりますが、知識がない人でも使いながら学べる設計です。私のチームでは、使い始めて最初の2週間が最も多く試行錯誤をした期間で、その後は作業の流れが安定していきました。
Q. デザイナーがいないチームはStitchだけで対応できますか？
初期のプロトタイプやアイデア検討の段階では対応できます。ただし「本番プロダクトのUIデザイン全体をStitchだけで管理する」のは難しいです。プロダクトが成長するにつれて、デザインシステムの構築、UXの改善、ブランドの統一感など、専門知識が必要な領域が出てきます。Stitch は「デザイナーがいない状態でのつなぎ」として機能しますが、長期的にはデザインの専門知識を持つ人を関与させることが、プロダクトの質を上げる上で重要です。
Q. Stitch を使うのに、チーム内で誰が担当すべきですか？
プロダクトマネージャーやプロジェクトリーダーが担当するケースが多いです。UIの要件を一番把握しているポジションの人が使うと、プロンプトの質が上がります。ただし全員が使えるようにしておく方が、議論の中で「すぐに試してみる」ができるため便利です。チームの状況によりますが、まず一人が習熟して使い方を共有し、必要に応じて他のメンバーも使えるようにするという段階的なアプローチが現実的です。
Q. Stitch と Figma、どちらを先に導入すべきですか？
デザイナーがいないチームで、今すぐUIプロトタイプを作る必要があるなら Stitch から始めることをおすすめします。Figmaは強力なツールですが、習熟に時間がかかります。「今週の会議に間に合わせたい」という緊急の用途ではStitchの方が速いです。Figmaは「本格的にデザインシステムを構築したい」「チームでデザインを共同管理したい」という段階になってから導入を検討するのが合理的です。私のチームでは今後Figmaの導入も検討していますが、Stitch で「デザインの議論に慣れる」プロセスを経てからFigmaに移行する方が、Figmaの習熟も速くなると考えています。基本的なデザインの概念（レイアウト、カラー、コンポーネント）をStitchを使いながら学んでから、より高度なツールに移行するという段階的なアプローチが、デザイン初学者のチームには合っています。
Q. Stitch を使って失敗したことはありましたか？
あります。一番の失敗は「Stitch で作ったUIをそのままエンジニアに渡して実装を依頼したこと」です。エンジニアから「このコードは既存のコードベースと全然合わない」と返ってきて、結局エンジニアが全部書き直すことになりました。「ビジュアルの参考として渡す」と「コードをそのまま実装する」という用途の違いを事前に伝えていなかったのが原因でした。これ以来、Stitch のアウトプットを渡すときは「これはビジュアルの参考です、コードは実装の際に書き直してください」という一言を必ず添えるようにしています。期待値の伝達が、ツール活用の成否に大きく影響することを学んだ経験でした。
Stitch はデザイナーなしのチームに「始めの一歩」を与えてくれます。
