うちのチームは全員リモートだ。デザイナー・エンジニア・PM、それぞれが違う都市にいる。画面を一緒に見ながら話すのはいつもビデオ会議越しで、「ここのボタンが……」と話しながら相手が同じ場所を見ているかどうか、毎回確認が必要だった。
Google Stitch を導入したのは、その「同じものを見ながら話す」という問題を少しでも解消したかったからだ。テキストで「この画面はこういう方向性で」と伝えるより、Stitch でビジュアルを出してから話す方が早いはずだ、という仮説だった。
3ヶ月使ってみた結果を、正直に書く。
結論から言うと
一言で言えば、Google Stitch はフルリモートチームの「デザイン方向性の合意」を明確に速くした。一方で、リアルタイムの共同編集機能の不足は依然として課題として残っている。「何を作るか」を決める議論は改善されたが、「一緒に作る」体験はまだFigmaには及ばない。
それでも、Stitch 導入前後での会議の質の変化は明確だった。ビジュアルのたたき台がある状態で始まる会議と、言葉だけで始まる会議は、まったく違う。
導入前の課題：テキストだけの設計議論の限界
フルリモートで設計の議論をするとき、最大の問題は「同じイメージを持てない」ことだ。
「ヘッダーをもっとシンプルにしたい」という発言は、人によって全然違うイメージを持つ。あるメンバーは「ロゴだけ残してナビをなくす」と理解し、別のメンバーは「高さを低くする」と理解する。その食い違いは会議中には気づかれないまま進み、実装が始まってから「それは違う」という話になる。
この「イメージの食い違い」のコストは、リモートチームでは特に大きい。オフィスなら隣の席に行って「ちょっと見てほしい」で済むことが、リモートでは「会議を設定する→資料を共有する→画面越しに説明する」というステップが必要になる。
Stitch が解決したこと：ビジュアルを起点に議論を始める
Stitch を導入してから、設計の議論の始まり方が変わった。「ヘッダーをもっとシンプルにしたい」という提案があったとき、PMが即座にStitchで「ミニマルなヘッダー」「ロゴ+ナビのみ」「テキストのみヘッダー」の3パターンを生成してミーティングに持ち込む。チームは同じビジュアルを見ながら「これじゃなくて、もうちょっと……」という具体的な議論ができるようになった。
2026年3月のStitch 2.0アップデートで追加されたワークスペース共有機能・コメント機能・バージョン管理を活用することで、非同期でも「このバージョンのどこをどう変えるか」をコメントでやりとりできるようになった（Google Labs 公式発表）。
3ヶ月で変わったこと
「デザイン方向性の会議」の時間が短縮された
最も顕著に変わったのは、スプリントプランニングでの画面方向性を決める議論だ。Stitch 導入前は「どんなUIにするか」の議論だけで30〜45分かかることが多かった。導入後は、PMが事前にStitchで2〜3パターン作ってくることが習慣になり、会議の冒頭からビジュアルを見ながら話せるようになった。同じ議論が15〜20分に短縮された。
エンジニアが設計の議論に参加するようになった
「デザインはデザイナーが決めること」という空気があったチームで、エンジニアが「この画面、もう少しこうした方がいいと思う」と言えるようになった。Stitch で可視化されたビジュアルがあることで、専門的な訓練を受けていない人でも「ここが使いにくそう」という意見を出しやすくなる。
実際に使ってみて分かったのは、ビジュアルを「見ながら話せる状態」にするだけで、チームのデザインへの参加度が変わるということだ。これはリモート特有の効果ではなく、リモートで特に顕著に出る効果だと思っている。オフィスのホワイトボードでも同じことが起きるが、リモートではそのホワイトボード自体がなかった。
そのまま残っている課題
正直に言うと、Stitch を導入しても解決しなかった課題もある。
リアルタイムの共同編集ができない
Figma の最大の強みのひとつは、複数人が同じファイルをリアルタイムで編集できることだ。会議中にデザイナーが修正しながら、PM がコメントを入れ、エンジニアが別の画面を確認する——この並列作業がFigmaでは自然にできる。
Stitch は2026年4月時点では基本的にシングルユーザーでの操作が主体だ。ワークスペース共有やコメント機能は追加されたが、複数人が同時にキャンバスを操作するリアルタイム共同編集は実現していない。「会議中に全員で一緒にデザインを変えていく」体験は、まだFigmaに依存している。
生成物の「オーナーシップ」が曖昧になる
Stitch で誰かが生成した画面を、別のメンバーが修正するとき、「元のプロンプトが何だったか」が分からなくなることがある。「このデザインを少し変えたい」と思っても、どう変えればいいかが再現できない。
この問題の解決策として、チームでプロンプトをNotionにメモする習慣を作った。「stitch73_dashboard_v1：（プロンプト全文）」という形で管理することで、再生成・修正の際のベースラインが残るようになった。
リモートチームにおける推奨ワークフロー
実際に3ヶ月使って安定してきたワークフローを紹介する。会議前→会議中→会議後の3フェーズで整理する。
会議前：PMまたはデザイン担当者がStitchで2〜3パターンの画面案を生成し、ワークスペースに共有する。各パターンへのコメント記入依頼を非同期で出す。
会議中：共有されたパターンを画面共有しながら、全員で見ながら議論する。決定事項はリアルタイムでNotionに記録。追加の修正案はStitchでその場生成して即確認。
会議後：決定したデザイン方針に基づいてFigmaで詳細仕様を作成。Stitch のプロンプトをNotionに保存。次のスプリントで参照する。
よくある質問（FAQ）
Q1. リモートチームでStitchのワークスペースを複数人で使うには？
Stitch 2.0（2026年3月）で追加されたワークスペース共有機能を使います。プロジェクトのワークスペースにチームメンバーのGoogleアカウントを招待することで、全員が同じプロジェクトにアクセスできます。設定はStitchのプロジェクト設定画面から行います。
Q2. 時差があるグローバルチームでStitchをどう使えばいいですか？
非同期での活用が中心になります。設計案をStitchで生成・ワークスペースに共有→コメントで意見を非同期に集める→次の会議（重複している時間帯）で決定、というサイクルが機能します。会議の準備をStitchで非同期に進められるため、短い同期時間を意思決定に集中して使えます。
Q3. Stitch のキャンバスを会議中に画面共有するベストプラクティスは？
操作者の画面をそのまま共有するシンプルな方法が最も安定しています。Stitch の生成結果はURLで共有できるため、生成後にURLをチャットに貼って全員が自分の画面で確認する方法も有効です。後者は全員がズームしたり並べて比較したりできるメリットがあります。
Q4. Stitch のプロンプトをチームで再利用可能な形で管理するには？
Notionやスプレッドシートにプロンプトライブラリを作るのが最も実用的です。画面名・プロンプト全文・生成日・バージョン・使用した状況を記録しておくと、後から再生成や修正がスムーズになります。チームで共有できるドキュメントで管理することが重要です。
Q5. リモートでのStitch活用で、特に気をつけていることはありますか？
「これはStitchが作ったたたき台である」という認識をチーム全員が持ち続けることです。リモートでは「誰かが作ってきたもの」を「完成形に近いもの」と誤解しやすい傾向があります。会議の冒頭で必ず「これはたたき台です」と一言添えることを習慣にしています。
注意点・失敗しやすいポイント
1. Stitch の出力をそのままSlackに流しすぎない
Stitch で生成した画面をSlackに貼って「意見をください」という文化が生まれると、非同期のコメント量が増えすぎて収拾がつかなくなることがある。Stitch の共有は「議論のための会議前準備」として位置づけ、決定は必ず同期の場で行うことを明確にするとよい。
2. 全員が同じページを見ているか確認してから議論を始める
リモートでは「同じ画面を見ている」という確認を怠りがちだ。会議中に「今みなさんに見ていただいているのはstitch73のv2です」という確認を毎回行うだけで、認識のズレが大幅に減る。
3. 非同期コメントの解釈は対面（ビデオ）で確認する
Stitch のコメント機能でデザインに意見をもらったとき、テキストだけでは意図が伝わらないことがある。重要な方向性の決定は、コメントだけで完結させずに必ず同期の会議で確認する習慣を持つこと。
まとめ：変わったこと、変わらないこと、その先
Google Stitch をフルリモートチームに導入して変わったのは、「デザインの議論の入り口」だ。ビジュアルを起点に話せるようになった。それだけで、会議の質が変わった。
変わらなかったのは、「一緒に作る」体験だ。リアルタイム共同編集の欠如は、まだFigmaとの使い分けが必要な理由になっている。
ただ、この1年でStitchが急速に機能を拡充してきたのは事実だ。リモートコラボレーションの課題も、いずれアップデートで改善されると期待している。今の段階でできることを最大限使いながら、ツールの成長を一緒に待つ——それが今の使い方だ。
