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からデザインシステムを作ってもらったバージョン。次に、.figは参照するがデザインシステムを作らないバージョンどちらも生の生成結果ではなく、一部バラつきの出た箇所に一貫性を持たせたり、不自然だった写真は修正しています。ただし、コンポーネントを作り直して全画面に適用、といった調整はしていません。Stitchの生成結果を毎回安定させるのは難しいため一度の結果で判断はできませんが、それでも安定傾向を感じます。3 Flash & デザインシステムあり以外の結果では、セーフエリアを設けた適切な高さのナビゲーションバーとタブバーも生成されています。これに関してはこれまで自分が試してこなかっただけなので、以前からある挙動なのかもしれませんが。一方で、画像は貼りませんが、3つ目の「.figをアップロードせずデザインシステムも作らない」パターンでは、プロンプトでHIGやセーフエリアに言及したものの生成結果がかなり不安定だったので、.figをアップロードする効果は一定以上あるのかもしれません。もともと期待していた「アップロードしたコンポーネントをそのまま再利用してUIの一貫性を担保する」といった役割にはまだ達していませんが、講義利用に耐えられるサービスになりつつあると感じます。

先日のFigmaとStitchの話を書いたときは噂段階だったClaude Designが発表されたので少し触ってみました。基本的には「学校の講義で使えるかどうか。使えないとしたらどうすれば使えそうか」の目線で使っています。出て間もないリサーチプレビューで結論づけるのは早急ですが、現在の印象は「Claude Codeを講義に取り入れられたとしても、週間制限の上限の低さから採用は難しい」といったところでしょうか。 とは言え、それを除けば全体的に使いやすく満足する成果物も作りやすいと思います。Stitchのときにも書きましたが、Claude Designではデザインシステムを構築して生成のベースにできるので、アウトプットに対して一定のクオリティコントロールをできるのは初学者にも嬉しい点です。デザインシステムはFigmaの.figファイルからでも作れるので、こちらでいくつかスタイルの違うパターンを用意して、それを使ってもらう流れができそうです。ただ、これもStitchのときに書きましたが、それが学生の学習にとって良いのか悪いのかは広い視野で考えないといけないトピックでもあります。以下は試しにペーパープロトタイプとコンポーネントを集約した.figファイルを読み込ませて生成したものです（デザインシステムの追加導線が表示されていなかったのか見逃したのか、単に添付ファイルとして渡してしまった）。雑なプロンプトを渡したので細部まで意図した設計にはなっていませんが、元のペーパープロトタイプから大きく逸脱していないのが好印象です。Stitchだと制約をかけても改変されてしまうことがたびたびあるので、この再現性は講義でも役立ちそうです。 一方で、これだけでClaude Designの使用量が7割弱まで埋まったので、小〜中規模のプロダクトを作ってもらう自分の講義だと採用は難しいでしょう。今後、正式版で上限がどれくらいまで上がるのか気になります。なお、この使用量の上がり方が一度の生成に対してなのか画面数に対してなのかは未検証なので、もし一度に10数画面のペーパープロトタイプを渡して生成しても同等なのであれば検討はやや前向きになるかもしれません。 ちなみに上記の出力された画面ですが、これがプレビューというわけではなくhtmlそのものであるのは盲点でした。つまり、このままだとプロトタイプとしては使えないわけです。幸いClaude Codeに渡したあとで変換してもらったら問題なく動作するものができましたが、Stitchのように画面の一覧とプロトタイプの管理に柔軟性がないのはネガティブな評価になります。とは言え今後改善されるでしょうし、最初からプロンプトに含めていればおそらく問題ないでしょう。そのほか、講義に採用する目線で気になるのは共有設定でしょうか。試していないので不明ですが、おそらく個人プランの利用では他人との共同作業ができないのではと思います。自分の講義はグループ課題を含んでいるので、個々人でしか作業できないと無理が発生しそうです。 そしてもちろん、学校がClaudeを契約していない場合、学生個人での支払いが必要な点も忘れてはいけません。というか、これがある意味ではもっともハードルが高いとも言えます。仮にClaude Designが上限を気にせず使えるようになったとしても月契約で2〜3ヶ月使うとなると1万円くらいはしますから、いち講義の受講に対してこの金額の支払いが発生するのは悩ましい点です。また、仮に講義で使えるようになっても、学生にソフトウェアの知識がない前提で講義を設計する必要があります。FigmaのようにPhotoshopやIllustratorの知識や経験が活きるわけではないですし、ソフトウェアやプログラミングといった「よくわからないもの」に対する忌避感をなくすことからスタートしないと使ってもらえないでしょう。使い始めるためにはまとまった準備期間が必要であり、これ以上講義のコマ数を割けないという現実的な問題と直面します。あとは制作物目線でいうと、Figmaで制作するプロトタイプは誤魔化しが効きやすいのに対してClaude Designで作ったものは誤魔化すのが難しい、といったものもあります。FigmaとClaude Designでは「プロトタイプ」に求められる精度や振る舞いは異なるものと言えるでしょう。もちろん、入力系統やデータの扱いが正しく動作しやすいClaude Designの魅力は大きく、作業ボリュームと成果物のバランスがうまく取れれば、UIデザインの講義形態としては次のステップに進める期待もあるのですが。 講義で制作するプロダクトは基本的にネイティブアプリを想定しているので、プロトタイプのプレビュー手段が限定的なのも悩ましい点です。これはStitchでも同様に困っているのですが、htmlで作成したネイティブアプリ風の画面を適切にフルスクリーンで表示・操作するベストプラクティスがなかなか見つかりません。現状だと、ローカルにhtmlを保存してローカルサーバーを起動してSafariでアクセス→ホーム画面に追加…とかになるのでしょうか。学生にターミナルを触らせるというのは、やや過剰に感じてしまいます。と、ここまで書いてふと思いましたが、講義ではなく卒業制作であれば採用の現実味はありそうです。意欲のある学生に個別でサポートするくらいの労力であれば、また卒業制作という長期間であれば、上に挙げた懸念点のいくつかはクリアできそうです。今後はリサーチや検証に力を入れながら、Claude Designなどで作った実働するプロダクトが卒業制作展でも多く見られるようになるかもしれません。余談ですが、これからは「高精度（Hi-Fi）プロトタイプ」という言葉は使われなくなっていくのかなという気がしています。高精度・低精度のラベルは、デジタルプロダクトでは主にペーパープロトタイプとデザインツールで作るプロトタイプの区分けに使われていますが、StitchやClaude Designで作られるプロトタイプはより高精度…というかプロトタイプと本番の製品のグラデーションのようになりつつあります。そうなると、製品の初期状態をプロトタイプと指し、デザインツールで作られるものも低精度に分類されたり、簡素な表現に落ち着く未来もあり得るのでは、なんて思ってしまいました。そういえば、iOSネイティブなプロトタイプが作れることで有名だったPlayはサービスを終了してしまいましたが、あたらしいものに取り組んでいるとのことなので、Figma、Stitch、Claude Designに続く候補として面白いサービスが生まれたら嬉しいな、と密かに願っています。

具体的なUIデザイン制作においては、OOUI（オブジェクト指向ユーザーインターフェイス）の話を挟むことで、UIデザインに対する理解度と成果物の向上を狙うことがあります。 自分の担当講義でも、さわり程度ではありますが説明するセクションを用意しています。もっとも、以下のページで紹介されている内容がとてもわかりやすいので、詳細や理解の促進はそちらに頼りっきりなのですが。さて、最近は「律儀にOOUIの全容を伝えなくてもいいんじゃないか」と考え始めています。というのも、自分にとって学生にOOUIを紹介する目的は、タスク指向のUIを作るのを避けてもらう一点にあるからです。というわけで、もともとOOUIという言葉は使っていませんでしたが、いまは「オブジェクト」や「動詞」といったワードも省くようにしています。UIデザインの学習は基礎学習だけでも多くの概念や用語（しかも横文字が多い）が登場します。そこにOOUIの話を全部入りで加えるのは、けっこうキャパオーバーな印象があります。（概念として）知らない言葉をいろいろ渡すよりも「ドアがたくさん並んでいる画面を作ってない？」「それは使いづらさに直結してるんだよ」と話を絞ったほうが、学生の気付きには貢献するんじゃないか、というのが最近の考えです。ドアの話をしたあとは「この画面が対象にしたいのはなんだと思う？」と続け、そこから改善例を提示しています。先述のとおりオブジェクトや動詞といった概念は避けたいので、いまのところは「作ったドアを基礎学習で学んだコンポーネントに変換してみよう」というアプローチを採用しています。また、セクションの終わりではオブジェクト指向にも少し触れているので、興味がある学生への入口は最低限用意している格好になります。もちろんOOUIの話として見ると歯抜けばかりですが、OOUIを伝えるのが目的ではなく「初学者がやりがちな、一般的には機能性が悪いUIパターンを知り、採用を避けること」が目的なので、自分の講義ではこのアプローチを当面試してみようと思います。と、ここまで書いて思ったのですが、そもそも近年のデジタルプロダクト（のUIデザイン）の質は格段に向上しており、スマートフォン黎明期に見られたようなタスクの指向UI（一旦ここではわかりやすく「ドアが並んでいるUI」とします）のプロダクトはほぼ見かけなくなりました。 それなのに、なぜInstagramやLINEに慣れ親しんでいる学生からタスク指向のUIデザインが生まれるのでしょうか。これは推測ですが、ひょっとするとゲームの影響が大きいのかもしれません。ゲームを起動するとタイトル画面でスタートコンティニュー設定といった「ドア」が並ぶのは珍しいことではありません。意外とこうした体験の積み重ねが、デジタルなUIを作るとき——それもトップ画面——には入口を置きたくなる意識につながっているのかもしれません。 もちろん日常生活の中にはATMや券売機といったタスク指向の機器も多く存在します。それらの影響もあるでしょう。ちゃんと因果関係を調査してみたら、けっこう面白い成果が得られるかもしれません。

ユーザー体験の結びつきが強いプロジェクトにおいて、シナリオを書くことは現状把握（As-Isをどれだけ調査できているか、文章化できるか）と未来予測（まだ起こっていない未来をどれだけ具体的に想像できるか）の面から、初学者にとってバランスのよい訓練方法だと感じます。 私の担当講義でもサービスのアイデアやプロダクトのコアを考えるタイミングで導入しているのですが、どのような書式のシナリオであれば初学者にも書けるのか、そもそもシナリオを初学者が書くハードルをどう乗り越える（あるいは低くする）か、いまだに手応えのある答えに辿り着いていません。 具体的には、講義では構造化シナリオのアクティビティシナリオとインタラクションシナリオに相当する内容を記述してもらうのですが、インタラクションシナリオは「インタラクションの知識がないと書けない」というジレンマがあると感じています。実務経験や長期間の学習・訓練があれば記述はできますが、初学者向けの期間が限られている講義内では「UIデザインを制作する前にUIデザインを想像しなくてはいけない」流れになってしまいます。デザインの制作をある程度（具体的には2〜3コマ相当）経験したのち記述する、といった反復練習ができると好ましいのですが、自分の構成ではそこまでの厚みを持たせられていないのが現状です。また、それだけでシナリオを書ける知識がどれくらい身につくのかは未知数です。シナリオをどう書くと効果的か、についても試行錯誤の段階です。 構造化シナリオがひろく知られたきっかけのひとつであろう『エクスペリエンス・ビジョン』では、アクティビティシナリオとインタラクションシナリオは同等の文章量（300字前後）で書かれています。 一方で、簡略化・分解して記述されている事例も見られます。また、アクティビティシナリオとインタラクションシナリオを混ぜて記述されている事例もあります。これらのバリエーションに良し悪しがあるわけではないと思います。『エクスペリエンス・ビジョン』では工業製品の利用体験の文脈で書かれていますが、現在はデジタルプロダクトの現場で使われているというニュアンスの違いもあるような気がします。細かく書くことで構造化しやすい・インタラクションシナリオを仕様に落とし込みやすい・書きやすくチェックしやすいメリットもありそうです。個人的には、3例目のアクティビティシナリオとインタラクションシナリオを混ぜて書く形式が肌感にあっています。これについては「アクティビティシナリオとインタラクションシナリオを分ける利点は、混ぜることに対してどれくらいあるのか？」という別トピックでも何かしら考えることはできそうです。『エクスペリエンス・ビジョン』の発売は2012年ですが、そこから現在まで大きな改訂が見られないというのもバリエーションが生まれている要因のひとつかもしれません。アクティビティシナリオの記述（の補助）に対するアプローチは、遠山・吉武（2019）の『UXデザインにおける利用状況の記述方法』で見つかりましたが、具体的な記述例は含まれておらず、効果については未知数です。ただ、アクティビティシナリオそのものに対するアプローチでない点に留意は必要ですが、インタビューで得た情報をどのように記述するか、という橋渡しの面で興味深く感じます。シナリオに限定する必要はない、という考え方も重要です。目的はシナリオを書くことではなく「UIデザインの制作にあたり、利用者の行動・体験を具体的に想像し、機能を含めた全体像を把握する」が軸になります。もちろん、その前段には「創出したサービスやコア機能のアイデアが対象となる属性にとって有用か」を試行錯誤するプロセスがあるのですが、一旦講義のプロセスに沿って前者にフォーカスして考えてみたいと思います。代表例としてはストーリーボードがある。ただ、絵で書くと実は文章で書くような状況の流れが分断されてしまうので抜け漏れが多い？テキストを書くことで鍛えられる能力値も見逃せない。一方、両方合わせても相乗効果は高いはず。生成AIが発達してきた近年では、もっと別のアプローチも考えられるかもしれない。例えば、シナリオを1セクション書いたらStitchに渡して画面を生成して、次のシナリオを書いて渡して…といったパラレルでUIを検討する方法。ただ、これに関しては「デザイン学習と生成AIのバランス」という別テーマが生まれる。