UIデザイン学習でメインツールをFigmaからStitchに変えると何が起こるのか、を考える
2026年3月のアップデート以降、GoogleのStitch（元はGalileo AI）に対する注目はデザイナー層以外にも広がっている印象を受けます。
Stitchが…というかGalileo AIが登場したときから利用している身としては、たしかに使い勝手や機能は少しずつ向上しているものの、世間の反応ほど実務に耐えるレベルにはまだ到達していないな、と思います。一方で、それらはいずれ改善されるだろうから、大きな転換期がやってくるのはそう遠くないだろうなとも思います（Figmaが登場した頃に、ウェブで共同編集できるだけのサービスがSketchより良いと思っていなかった経験から）。
さて、講義のメインツールには現在Figmaを採用しているわけですが、はたしてStitchに切り替えるべきかどうか、というのは悩むところです。その前段には生成AIを学習の主軸にするべきかどうか、という問いがあるわけですが、ここでは純粋に（現在の）FigmaからStitchに移行した際に、制作プロセスや学習過程にどのような差が発生するかを考えてみたいと思います。
まず話の前提として、現在の講義でFigmaを利用する際のシチュエーションを整理します（FigJamについては除外）。
Figmaは主に、講義課題で具体的なUIデザインを制作するフェーズで利用しますが、その前のフェーズでは
- サービスアイデアの発散・収束
- プロダクトのコア機能の発散・収束
- コア機能のペーパープロトタイプの制作
- 簡易的なシナリオの作成
- 未着手のペーパープロトタイプの制作
が発生します。ここからペーパープロトタイプ全体をStitchに渡し、出力されたものをPNGでダウンロードし、トレースはせず参考資料としてFigmaでの画面制作に移ります。トレースをNGにしているのは、現状のStitchのアウトプットに一貫性がないこと、ネイティブアプリのコンポーネントに弱い（特にセーフエリアを考慮したナビゲーションバーとタブバーが出せない）こと、Stitchの生成内容に対するアプローチを案内しておらず、また学生の知識量も不足していることが理由となります。3点目に関しては、生成されたUIに対してどう疑問を抱いてもらうか、どう良し悪しを判断するかといった点で、求められる知識・経験のハードルが講義の範疇を超えている印象を受けます。
では、もし今後Stitchの出力内容に一貫性が担保され、ネイティブアプリのコンポーネントも対応できるとしたら——フォーラムでのGoogle社員の反応などを見ると、ユーザーがコンポーネントを定義したりアップロードするアプローチが採られる気がしますが——どうなるか。
ひとつには、Figmaの役割が限定的になるような気がします。Stitchの生成内容に一貫性があり破綻もなければ、Figmaでおこなうのはプロトタイプ化するために各画面・要素をつなげたり、アラートやメニューなど細かいオーバーレイの作成にとどまるのではないでしょうか。もしアラートやメニューも含めたコンポーネント群を用意するだけでネイティブの振る舞いを再現できるようになれば、いよいよFigmaの利用機会は薄まりますが。ウェブの振る舞いを優先しているStitchがどこまでネイティブのサポート、あるいは再現を視野に入れているかは未知数です。
その話は一旦置いておいて、他に思いつくのは「Figmaの操作方法に割いていた時間をUIデザインの基礎知識の吸収にあてる」でしょうか。具体的には、Stitchの生成をどのようにコントロールするか、出力されたものにどうアプローチするか、そういったプロセスと合わせて、UIデザインの基礎学習の時間を増やせるような気がします。なにしろFigmaの操作を学ぶだけでもそれなりのコマ数と自習時間が必要になりますから、それをスキップ・簡略化できるのは大きな利点のように感じます。
現在でも、代表的なコンポーネントの解説やUIデザインを考える上での基礎知識（タイポグラフィやレイアウトなど）は学習内容に含まれていますが、一過性のもので終わらせず知識の定着を目的に、Stitchの生成結果と基礎学習を組み合わせたり、分析やディスカッションを通して言語化する、といった時間の使い方ができそうです。既存のプロダクトをテキストだけでStitchに伝えてどれくらい再現できるか、といったワークも有用かもしれません。とはいえ、Stitchを使うこと自体を目的化するのは避け、どうしたら学生にUIデザインをより深く学んでもらえるか、といった視点は維持しなければいけません。
もちろん、懸念すべき点もあります。そもそも、FigmaからStitchに移行したとして、Figmaよりも短期間で同等かそれ以上の成果が出せるのかどうかはしっかり測る必要があると感じます。FigmaがStitchと同等になる可能性もあるわけで（とは言えその場合、FigmaのAI機能は学生は使えないですが——その意味はもちろん、念頭に置く必要があります）。
また、現実的な話として、現状のStitchはベータ版ですが正式版になった際に有料化するリスクは見越しておくべきでしょう。Figmaのエデュケーションプランは申請が通れば無料で使えるため、その恩恵は計り知れません。が、Googleがそうした対応をするとは正直思えません。
そしていちばんの懸念は、Stitchをメインツールに据えたときに学生の創造性は広がるのか、狭まるのか、という点です。こればかりは試してみないと判断が難しい。サービスのアイデアやコア機能は自身で考えてもらっているので、根っこにある創造性や独自性は担保できると思うのですが、どのようにUIデザインで表現するかの試行錯誤は、やはり学生には楽しんでほしいポイントでもあります。プロダクトの全体像もペーパープロトタイプで作ってもらっているので、差分が出るとしたらFigmaでの自作かStitchによる生成か、というピンポイントにはなりますが、学生自身のモチベーションも加味するべきでしょう。
慣れないながらも自分で作る（と言いつつ、代表的なコンポーネントは自分がカタログ化して渡してはいるのですが）ことに楽しみを見出すのか、どんどんUIが生まれて対話式でブラッシュアップされる景色に楽しみを見出すのか。UIがコモディティ化しやすいデジタルプロダクトでは、そもそも創造性をどこに宿すか・創造性とは何か、という視点もあると思います。サービスアイデアこそが核だとも言えるし、UI表現が核だとも言える。学校教育におけるUIデザインはどこに軸足を置くべきなのか、なぜ・なんのためにUIデザインを学習し、制作するのか…については（これまでと同様に、あるいはこれまで以上に）しっかり考えないといけないことなのだろうと思います。
（2026.05.22 追記）
先日のアップデートでStitchにデザインファイルのアップロード機能が追加されました。具体的には、ロゴや画像、フォントといったデザインアセットと、Figmaのローカルデータである.figファイルなどがアップロードできるようになりました。
せっかくなので、どのような結果になるか検証してみました。まずは前準備として、AppleがFigmaで公開しているデザインリソースから一部のコンポーネントのみ抽出した.figファイルを作成し、
- .figからデザインシステムを作る
- .figを参照するがデザインシステムは作らない
- .figをアップロードせず、デザインシステムも作らない
の3パターンで、それぞれ3 Flashと3.1 Proで生成しました。生成元には以下のペーパープロトタイプを使用しています。
また、プロンプトには「Human Interface Guidelinesに沿ってiOSアプリとして清書すること」「ナビゲーションバーとタブバーはセーフエリアを設けること（詳細な数値も併記）」を含めています。
まずは.figからデザインシステムを作ってもらったバージョン。
3.1 Pro／デザインシステムあり
次に、.figは参照するがデザインシステムを作らないバージョン
3.1 Pro／デザインシステムなし
どちらも生の生成結果ではなく、一部バラつきの出た箇所に一貫性を持たせたり、不自然だった写真は修正しています。ただし、コンポーネントを作り直して全画面に適用、といった調整はしていません。
Stitchの生成結果を毎回安定させるのは難しいため一度の結果で判断はできませんが、それでも安定傾向を感じます。3 Flash & デザインシステムあり以外の結果では、セーフエリアを設けた適切な高さのナビゲーションバーとタブバーも生成されています。これに関してはこれまで自分が試してこなかっただけなので、以前からある挙動なのかもしれませんが。一方で、画像は貼りませんが、3つ目の「.figをアップロードせずデザインシステムも作らない」パターンでは、プロンプトでHIGやセーフエリアに言及したものの生成結果がかなり不安定だったので、.figをアップロードする効果は一定以上あるのかもしれません。
もともと期待していた「アップロードしたコンポーネントをそのまま再利用してUIの一貫性を担保する」といった役割にはまだ達していませんが、講義利用に耐えられるサービスになりつつあると感じます。
2026年3月のアップデート以降、GoogleのStitch（元はGalileo AI）に対する注目はデザイナー層以外にも広がっている印象を受けます。
Stitchが…というかGalileo AIが登場したときから利用している身としては、たしかに使い勝手や機能は少しずつ向上しているものの、世間の反応ほど実務に耐えるレベルにはまだ到達していないな、と思います。一方で、それらはいずれ改善されるだろうから、大きな転換期がやってくるのはそう遠くないだろうなとも思います（Figmaが登場した頃に、ウェブで共同編集できるだけのサービスがSketchより良いと思っていなかった経験から）。
さて、講義のメインツールには現在Figmaを採用しているわけですが、はたしてStitchに切り替えるべきかどうか、というのは悩むところです。その前段には生成AIを学習の主軸にするべきかどうか、という問いがあるわけですが、ここでは純粋に（現在の）FigmaからStitchに移行した際に、制作プロセスや学習過程にどのような差が発生するかを考えてみたいと思います。
まず話の前提として、現在の講義でFigmaを利用する際のシチュエーションを整理します（FigJamについては除外）。
Figmaは主に、講義課題で具体的なUIデザインを制作するフェーズで利用しますが、その前のフェーズでは
- サービスアイデアの発散・収束
- プロダクトのコア機能の発散・収束
- コア機能のペーパープロトタイプの制作
- 簡易的なシナリオの作成
- 未着手のペーパープロトタイプの制作
が発生します。ここからペーパープロトタイプ全体をStitchに渡し、出力されたものをPNGでダウンロードし、トレースはせず参考資料としてFigmaでの画面制作に移ります。トレースをNGにしているのは、現状のStitchのアウトプットに一貫性がないこと、ネイティブアプリのコンポーネントに弱い（特にセーフエリアを考慮したナビゲーションバーとタブバーが出せない）こと、Stitchの生成内容に対するアプローチを案内しておらず、また学生の知識量も不足していることが理由となります。3点目に関しては、生成されたUIに対してどう疑問を抱いてもらうか、どう良し悪しを判断するかといった点で、求められる知識・経験のハードルが講義の範疇を超えている印象を受けます。
では、もし今後Stitchの出力内容に一貫性が担保され、ネイティブアプリのコンポーネントも対応できるとしたら——フォーラムでのGoogle社員の反応などを見ると、ユーザーがコンポーネントを定義したりアップロードするアプローチが採られる気がしますが——どうなるか。
ひとつには、Figmaの役割が限定的になるような気がします。Stitchの生成内容に一貫性があり破綻もなければ、Figmaでおこなうのはプロトタイプ化するために各画面・要素をつなげたり、アラートやメニューなど細かいオーバーレイの作成にとどまるのではないでしょうか。もしアラートやメニューも含めたコンポーネント群を用意するだけでネイティブの振る舞いを再現できるようになれば、いよいよFigmaの利用機会は薄まりますが。ウェブの振る舞いを優先しているStitchがどこまでネイティブのサポート、あるいは再現を視野に入れているかは未知数です。
その話は一旦置いておいて、他に思いつくのは「Figmaの操作方法に割いていた時間をUIデザインの基礎知識の吸収にあてる」でしょうか。具体的には、Stitchの生成をどのようにコントロールするか、出力されたものにどうアプローチするか、そういったプロセスと合わせて、UIデザインの基礎学習の時間を増やせるような気がします。なにしろFigmaの操作を学ぶだけでもそれなりのコマ数と自習時間が必要になりますから、それをスキップ・簡略化できるのは大きな利点のように感じます。
現在でも、代表的なコンポーネントの解説やUIデザインを考える上での基礎知識（タイポグラフィやレイアウトなど）は学習内容に含まれていますが、一過性のもので終わらせず知識の定着を目的に、Stitchの生成結果と基礎学習を組み合わせたり、分析やディスカッションを通して言語化する、といった時間の使い方ができそうです。既存のプロダクトをテキストだけでStitchに伝えてどれくらい再現できるか、といったワークも有用かもしれません。とはいえ、Stitchを使うこと自体を目的化するのは避け、どうしたら学生にUIデザインをより深く学んでもらえるか、といった視点は維持しなければいけません。
もちろん、懸念すべき点もあります。そもそも、FigmaからStitchに移行したとして、Figmaよりも短期間で同等かそれ以上の成果が出せるのかどうかはしっかり測る必要があると感じます。FigmaがStitchと同等になる可能性もあるわけで（とは言えその場合、FigmaのAI機能は学生は使えないですが——その意味はもちろん、念頭に置く必要があります）。
また、現実的な話として、現状のStitchはベータ版ですが正式版になった際に有料化するリスクは見越しておくべきでしょう。Figmaのエデュケーションプランは申請が通れば無料で使えるため、その恩恵は計り知れません。が、Googleがそうした対応をするとは正直思えません。
そしていちばんの懸念は、Stitchをメインツールに据えたときに学生の創造性は広がるのか、狭まるのか、という点です。こればかりは試してみないと判断が難しい。サービスのアイデアやコア機能は自身で考えてもらっているので、根っこにある創造性や独自性は担保できると思うのですが、どのようにUIデザインで表現するかの試行錯誤は、やはり学生には楽しんでほしいポイントでもあります。プロダクトの全体像もペーパープロトタイプで作ってもらっているので、差分が出るとしたらFigmaでの自作かStitchによる生成か、というピンポイントにはなりますが、学生自身のモチベーションも加味するべきでしょう。
慣れないながらも自分で作る（と言いつつ、代表的なコンポーネントは自分がカタログ化して渡してはいるのですが）ことに楽しみを見出すのか、どんどんUIが生まれて対話式でブラッシュアップされる景色に楽しみを見出すのか。UIがコモディティ化しやすいデジタルプロダクトでは、そもそも創造性をどこに宿すか・創造性とは何か、という視点もあると思います。サービスアイデアこそが核だとも言えるし、UI表現が核だとも言える。学校教育におけるUIデザインはどこに軸足を置くべきなのか、なぜ・なんのためにUIデザインを学習し、制作するのか…については（これまでと同様に、あるいはこれまで以上に）しっかり考えないといけないことなのだろうと思います。
（2026.05.22 追記）
先日のアップデートでStitchにデザインファイルのアップロード機能が追加されました。具体的には、ロゴや画像、フォントといったデザインアセットと、Figmaのローカルデータである.figファイルなどがアップロードできるようになりました。
せっかくなので、どのような結果になるか検証してみました。まずは前準備として、AppleがFigmaで公開しているデザインリソースから一部のコンポーネントのみ抽出した.figファイルを作成し、
- .figからデザインシステムを作る
- .figを参照するがデザインシステムは作らない
- .figをアップロードせず、デザインシステムも作らない
の3パターンで、それぞれ3 Flashと3.1 Proで生成しました。生成元には以下のペーパープロトタイプを使用しています。
また、プロンプトには「Human Interface Guidelinesに沿ってiOSアプリとして清書すること」「ナビゲーションバーとタブバーはセーフエリアを設けること（詳細な数値も併記）」を含めています。
まずは.figからデザインシステムを作ってもらったバージョン。
3.1 Pro／デザインシステムあり
次に、.figは参照するがデザインシステムを作らないバージョン
3.1 Pro／デザインシステムなし
どちらも生の生成結果ではなく、一部バラつきの出た箇所に一貫性を持たせたり、不自然だった写真は修正しています。ただし、コンポーネントを作り直して全画面に適用、といった調整はしていません。
Stitchの生成結果を毎回安定させるのは難しいため一度の結果で判断はできませんが、それでも安定傾向を感じます。3 Flash & デザインシステムあり以外の結果では、セーフエリアを設けた適切な高さのナビゲーションバーとタブバーも生成されています。これに関してはこれまで自分が試してこなかっただけなので、以前からある挙動なのかもしれませんが。一方で、画像は貼りませんが、3つ目の「.figをアップロードせずデザインシステムも作らない」パターンでは、プロンプトでHIGやセーフエリアに言及したものの生成結果がかなり不安定だったので、.figをアップロードする効果は一定以上あるのかもしれません。
もともと期待していた「アップロードしたコンポーネントをそのまま再利用してUIの一貫性を担保する」といった役割にはまだ達していませんが、講義利用に耐えられるサービスになりつつあると感じます。