WWDC26開催に合わせて、Human Interface Guidelines（HIG）のページにデザイン原則（Design principles）が追加されました。6月9日時点ではまだ日本語版は確認できていませんが、下記URLからアクセスできます。また、合わせてデザイン原則を紹介する動画も公開されました。さて、追加されたと書きましたが、実際のところは「戻ってきた」と書いたほうが正しいでしょう。HIGが現在のバージョンにアップデートされたのは2022年の6月でしたが、このタイミングで以前のHIGにあったデザイン原則は取り除かれていました。リニューアル当時、「デザイン原則って削除して大丈夫なんだ」と驚いた記憶があります。自分のデザイン原則に対する印象は「システムやプラットフォームの意思表明」なので、ドキュメントとして軸を失ったように感じていました。寂しい気持ちもありつつも、なくした意図もあるはずで、当時は「HIGがプラットフォーム（端末）を横断する形式に整理されたから、原則はエッセンスとして分散させたのかな」と考えていました。 デザイン原則は意思表明に限らず、ドキュメントに人間らしさや温度感を与えていたと（勝手に）思っていたので、今回戻ってきて嬉しいです。では、その戻ってきたデザイン原則はどのようなものなのか。読んでみたいと思います。 まだ日本語版がないので、内容に関してはツールによる翻訳と動画の日本語字幕を参照しています。ただ字幕のテキストにはやや不自然さが残る（"エージェンシー"よりも"主体性"が適切だろう、など）ので、そのあたりは適宜意訳しています。内容の正確性に関しては、日本語版のページができたら合わせて読んでもらえたらと思います。 また、手元に2012年発行の日本語版HIGがあったので、そちらとの比較も挟んでいきます。内容はリニューアル直前とほぼ変わらない（むしろテキスト量的には多い）ため以降は「旧版」と呼称し、合わせて2026年版は「新版」と呼称します。まずは原則の各セクションタイトルを見ていきます。新版では目的（Purpose）主体性（Agency）責任（Responsibility）親しみやすさ（Familiarity）柔軟性（Flexibility）シンプルさ（Simplicity）クラフト（Craft）喜び（Delight）となっています。一方で旧版は外観の整合性一貫性直接操作フィードバックメタファユーザによる制御となっています。第一印象はやはり項目が増えた点でしょうか。また、旧版よりも抽象度が上がっており、対象範囲も広がっています。逆に言えば、旧版は直接操作やフィードバックなど、ややシステム寄りの原則であることに気が付きます。しかし旧版の項目が消滅したかと言うとそうではなく、例えば旧版の『フィードバック』は新版の『親しみやすさ』の中に『明確なフィードバックを提供する』として含まれています。新版と旧版はテキスト量にも違いが見られます。新版はひとつのセクションに項目が複数ある代わりに、ひとつひとつの文量は最低限に抑えられています。一方、旧版はひとつのセクションで完結しています。例えば『フィードバック』に関して新版ではアプリを利用する中で何が起きているのかを明確に伝えましょう。操作可能な状態を示し、コンテンツの変化を知らせ、システム標準のパターンを用いて警告や選択肢を提示してください。一貫したフィードバックは、人々が状況を理解し、主体的に行動する助けになります。とコンパクトにまとめられていますが、旧版では以下のように細かい挙動にまで言及した詳細なテキストが書かれています。フィードバックは、アクションを受け付けたことをユーザに知らせたり、処理が発生していることをユーザに確信させたりします。ユーザは、コントロールを操作しているときは即座のフィードバックを期待し、処理時間が長くかかっているときには状況の最新情報が得られると助かります。 iOSに標準で組み込まれているアプリケーションは、何らかの目に見える変化によって、ユーザの1つ1つのアクションに反応します。たとえば、ユーザがリスト項目をタップすると、そのリスト項目が短時間ハイライトされます。2～3秒以上継続して処理が行われる場合、コントロールはその間、経過進捗を表示し、妥当と考えられる場合には、アプリケーションが説明メッセージを表示します。
ちょっとしたアニメーションは、ユーザのアクションがもたらした結果を理解しやすくする、意味のあるフィードバックをユーザに与えます。たとえば、リストでは、ユーザが変化を視覚的に追いやすくなるよう、新しい行の追加をアニメーション化できます。 サウンドもユーザにとって有用なフィードバックを与えることができます。しかし、ユーザは音が聞こえない場所や音を出せない場所でデバイスを使用する可能性があるため、サウンドをフィードバックの主要な、または唯一の仕組みとして使用しないでください。こうしたテキストを踏まえると、旧版がシステム寄りである印象がより増します。『目的』が持つメッセージ性HIGに限らず、デザイン原則の多くは自分たちがもっとも伝えたいメッセージを最初に用意している印象があります。それに倣うと、新版で『目的』という抽象的でありながら強度のあるメッセージが置かれているのは、あたらしいデザイン原則が旧版と同様に長期間の運用を見越して制作された痕跡のようにも感じられます。そんな『目的』には3つの項目が内包されており、それぞれ以下のようなことが書かれています。価値を生み出す。優れたデザインは、製品を本当に役立つものにする要素へと絶えず意識を向けています。開発のあらゆる段階で、製品の目的は何か、そしてデザインがその目的に貢献しているかを問い続けましょう。 焦点を絞る。人々がどのように使いたいかに沿って、アプリの最も重要な機能を優先しましょう。そして、それらの機能を本当に優れたものにすることへ集中してください。用途が明確な製品ほど、人々の目標達成を効果的に支援できます。 新しい解決策を見つける。既存の解決策を調査し、それを単に作り直すことは避けましょう。自分たちの製品を特徴づけるものは何かを定義し、その違いをデザインでどのように表現できるかを考えてください。自分はこれを読んだとき、ああ、これは丁寧に考えて書かれているものなのだなと強く感じました。『目的』として最初に語られるのが「価値を生み出す」であることは、強いメッセージ性を含んでいます。「新しい解決策を見つける」もとても素敵です。サービスや製品を考えるうえでは必須のマインドセットですが、意外と表明しているデザイン原則はないのでは？と思います。これはプラットフォーマーであるAppleだからこそ含めることのできた内容だと言えるかもしれません。ほかのセクションもそうですが、あたらしいデザイン原則は「未来と、そこに至る現在地」の両方に意識を向かわせる印象を受けます。また『優れたデザインのための原則』の冒頭では『目的』に関して以下のように述べられています。Appleにとってデザインとは、意図をもってものを作ることです。人々にとって最も重要なことに焦点を当てることです。人々が本当に価値を感じるものを作るためです。 製品に加える機能はすべて使う人に何かを求めます。時間と注意と信頼を求めます。 これらは大切なものなので、無駄にするわけにはいきません。何を作るかを選ぶことは、何を含めないかを決めることでもあります。 スケッチを1枚描く前に、コードを1行書く前に、作ろうとしているものに目的があるかを考えてください。HIGのテキストと合わせて読むと、『目的』で語られている内容はデザインするうえでの大原則を端的にあらわしているように思えます。これらを心に留めてプロダクトに向き合おうという、指針となるメッセージだと感じました。主体性・責任・柔軟性ほかのセクションに目を向けてみます。 『目的』の次にあるのが『主体性』です。このセクションは旧版の『ユーザによる制御』（以下に引用）に近い内容となっています。アクションは、アプリケーションではなく、ユーザが開始し、制御するべきです。アプリケーションはアクションの道筋を示唆したり、危険な影響に関して警告したりできますが、アプリケーションが意思決定をユーザから奪うことは通常、適切ではありません。優れたアプリケーションは、必要な能力をユーザに与えることと、危険な結果をユーザが回避する手助けをすることとの正しいバランスを見つけています。 ユーザは、動作や制御になじみがあり、予測可能である場合に、よりアプリケーションを制御していると感じます。そして、アクションが単純かつ簡単なものであれば、ユーザはアクションを容易に理解し記憶できます。 ユーザは、処理が開始される前にその処理をキャンセルする十分な機会があることを期待し、害を及ぼす可能性のあるアクションを実行する意思を確認する機会が得られることを期待します。最後に、ユーザは、進行中の処理を支障なく停止できることを期待します。新版では動作・制御・処理といったシステム寄りの語彙は使われず、平易な言葉で伝わりやすくなっています。またセクションタイトルからもわかるように「いかにしてユーザーにコントロールさせるか」というよりは「いかにユーザーに主導権を渡し、自由さを感じてもらえるか」といった、よりポジティブなニュアンスを感じます。これはほかのセクションにも言えることですね。比較してみると旧版は全体的に堅苦しいニュアンス、ややドライな印象を受けがちですが、新版は読んだ人のモチベーションが上がるような、ポジティブなニュアンスを感じます。語彙の選択やセクションの細分化が寄与しているのでしょう。『主体性』の次は『責任』ですが、ここは『柔軟性』と合わせて見るのがよさそうです。というのも、この2つではセキュリティやプライバシー、アクセシビリティについて言及されているからです。これらは旧版では言及されていなかったため、時代の変化に対応したアップデートと言えます。特にアクセシビリティは「最初から最優先事項（priority from the start）として扱うべき」と、原則全体の中でも際立った記述があります。現在のAppleはセキュリティやアクセシビリティに関する発信・対応を積極的におこなっているため、それがデザインにもきちんと降りてきたということなのでしょう。 ユーザーのために製品はどうあるべきか、それを作る人はどうあるべきか、を細分化・具体化して漏れなく伝えようという意思を感じます。一貫性は親しみやすさへUIデザインを学び始めた人の多くが最初に学び、UIデザインの奥深さを知ったのが「一貫性」の概念ではないでしょうか。かくいう自分もそうでした。ただ画面をその場その場で適当に作るのではなく、全体を通して一貫性を確保する。部品はコンポーネントと呼ばれ、再利用性によって一貫性に寄与する。この感覚を理解したとき、UIをデザインするとはどういうことなのか、その端緒をつかめたような気がしました。旧版のデザイン原則にも一貫性のセクションが存在します。インターフェイスの一貫性を保つことで、ユーザは自身の知識やスキルを、あるアプリケーションから別のアプリケーションへと持ち越せるようになります。一貫性のあるアプリケーションとは、他のアプリケーションをやみくもに模倣するということではなく、ユーザにとって心地よい標準規格やパラダイムを取り入れたアプリケーションということです。 アプリケーションが一貫性の原則に従っているかどうかを判断するには、以下の問いに対する答えを考えてみます。 ・アプリケーションはiOSの標準との整合性がとれているか。システムが提供するコントロール、ビュー、アイコンを正しく使用しているか。デバイスの機能を信頼できる方法で組み込んでいるか。 ・アプリケーションは、アプリケーション内での一貫性が保たれているか。テキストは均一な用語とスタイルを使用しているか。同じアイコンは常に同じことを意味しているか。ユーザが同じアクションを別の場所で実行するときに、何が起きるかを予測することができるか。独自のUI要素の外観と動作は、そのアプリケーション全体を通じて同一になっているか。 ・アプリケーションは、理にかなう範囲で、それよりも前のバージョンとの一貫性を保っているか。用語とその意味が変わらないままであるか。基本的な概念が本質的に変わらないままであるか。さて、新版には一貫性のセクションがありません。ではAppleは一貫性を捨てたのか？というとそうではなく、『親しみやすさ』の項に多くの影響を見て取れます。人々がすでに知っている概念を活用する。人々は現実世界の仕組みへの理解と、他のソフトウェアで学んだ慣習を新しい体験にも持ち込みます。その両方を活用し、親しみやすく直感的なインターフェイスを実現しましょう。 ビジュアルとインタラクションを一貫させる。要素の見た目や振る舞いを定めたら、それをデザイン全体で統一して適用しましょう。一貫性は学習を容易にし、新しい操作も期待どおりに機能するという安心感を与えます。 明確なフィードバックを提供する。アプリを利用する中で何が起きているのかを明確に伝えましょう。操作可能な状態を示し、コンテンツの変化を知らせ、システム標準のパターンを用いて警告や選択肢を提示してください。一貫したフィードバックは、人々が状況を理解し、主体的に行動する助けになります。この構造から、Appleは「一貫性をソフトウェアに持たせることが親しみやすさにつながる」と考えていることが読み取れます。このセクションに限らず、デザイン原則全体を見渡してみると、旧版の内容は新版ではどれも前提、当たり前の位置づけになっており、その先を新版では提示しているような印象を受けます。そう考えると、なぜHIGリニューアルのタイミングでデザイン原則が除かれたのか、なぜ帰ってきたのかの背景が垣間見えるような気がします。シンプルさシンプルさのセクションについては、正直なところ取り立てて言及する箇所はないように思います。それくらい、まっすぐにわかりやすいメッセージだと思います。必要なものだけを含める。シンプルであることは、最小限であることを意味しません。重要なものを手の届く場所に置き、それ以外を自然に後景へ退かせる、焦点の定まった有用な体験を目指しましょう。 平易な言葉で簡潔に伝える。最もシンプルな言い方を見つけたとき、それは多くの場合、最も普遍的で役立つ表現になります。概念を伝えたり操作要素に名前を付けたりする際には、平易で必要十分な言葉を選びましょう。 明確な階層をつくる。形と機能がすぐに理解できれば、人々は目的の結果へ到達する方法を把握できます。認識しやすい操作要素を優先し、自分がどこにいて次に何が起こるのかを理解できる一貫した構造を提供しましょう。クラフト（こだわり）とデライト（喜び）この2つが原則の最後を務めます。 冒頭に、デザイン原則はドキュメントに人間らしさや温度感を与えていたと書きましたが、この2つはそれをよく体現しているセクションだと思います。個人的にとても好きなセクションですし、Appleらしくもある。原則が『目的』ではじまり『喜び』で終わるというのも詩的で、美しさを感じます。内容に目を向けてみると、まず『クラフト』に関しては、原則のページ冒頭の概要がセクション全体をよく言い表しています。細部にまで気を配る。あなたのデザインは、あなたがどれほど心を込めているかの表れです。それは、人々に最高の体験を届けようとするあなたの献身的な姿勢を示すものです。時間をかけて、丁寧に仕事に取り組んでください。興味深いのは、セクションの詳細を読むと、単にビジュアルなどを作り込む職人的こだわりのニュアンスにとどまらず、プロセスに対する言及が多くを占めている点です。品質がすべてを決める。デザインのあらゆる要素は、どれだけ心を込めているかを人々に伝えます。ひとつひとつの判断を意図的に行い、息をのむようなビジュアル、流れるようなアニメーション、的確な言葉遣い、そして細部まで考え抜かれたサウンドを追求しましょう。 実験し、改善を繰り返す。早い段階でプロトタイプを作成し、新しいアプローチを試し、うまく機能しないものは潔く捨ててください。すべての機能に高い基準を設け、磨き上げ、再び試しましょう。実際の利用環境で製品を検証し、耐久性・信頼性・高いパフォーマンスを確認してください。 こだわりを維持し続ける。リリースはゴールではありません。インターフェイスを最新のプラットフォーム機能やデザインパターンに対応させ続け、品質基準を高く保ちましょう。デザインとは、継続的な取り組みです。個々の要素を作り込むこと、反復したプロセスによってそれらを磨き上げること、そして運用によって維持することがひとつのセクションで語られているのは現代的なアップデートだと言えそうです。プロトタイピングやリリース後の運用改善は、言ってしまえば単体で読むと当たり前の内容ではあるのですが、それが『こだわり』のセクションに含まれることでプラスの意味が生まれているのが構成の妙だなと思わされます。欲を言えば、プロダクトに尋常ならざる「こだわり」を持っているAppleだからこそ生まれる言葉やメッセージがあればもっと魅力的になるのにな、とは思いました。全体のトーンからは外れてしまいそうですが。最後が『デライト』です。呼び起こしたい感情を明確にする。すべてのソフトウェアが同じ感覚を与えるわけではありません。フィットネスアプリは活力を与え、瞑想アプリは心を落ち着かせ、ゲームは興奮をもたらすかもしれません。ユーザーに感じてほしい感情を把握し、それがデザイン全体を形づくるようにしましょう。 印象に残る瞬間をつくる。あらゆるインタラクションは、そのソフトウェアが何を大切にしているかを示す機会です。シンプルなボタン操作からエラーメッセージまで、それぞれの瞬間がデザインの精神を反映した個性を添える機会になり得るかを考えてみてください。 デライトを装飾と混同しない。ユーザーは目的を達成しようとしていることを忘れてはいけません。デライトを追求すること自体を目的にして、プロダクトの本来の目的を妨げないようにしましょう。全体的な美的方向性についても考えてみてください。丁寧に考え抜かれた実用的な表現のデザインもあれば、遊び心が合うデザインもあります。適切なバランスを見つけるために試行錯誤しましょう。 全体として捉える。デライトは、製品に込めた思いやりの積み重ねから生まれます。それは、ユーザーが利用中に経験するすべての要素の集積です。自由に行動できること、安心して探索できること、馴染みのあるメタファーによる心地よさ、そして状況に応じてシームレスに移行できる柔軟性。意図と集中、そして細やかな配慮をもってデザインすると、人々が自然と心地よさを感じるプロダクトが生まれます。『優れたデザインのための原則』の中で、デライトとは「製品に込めた思いやりの総和」であり「すべてのデザイン原則を正しく実行した自然な結果」だと言われています。原則の結びとして、これまでの集大成を「喜び」として提示するのは美しい流れだと言えます。 また、旧版との比較では『外観の整合性』の痕跡を感じ取れます。外観の整合性は、アプリケーションがどれだけ美しいかを示す尺度ではなく、アプリケーションの外観がその機能とどれほど整合しているかを示す尺度です。たとえば、生産的なタスクを実行するアプリケーションは一般に、標準のコントロールや動作を提供することでタスクに目が向くようにする一方で、装飾的な要素は控えめにして背景に溶け込むようになっています。こうしたアプリケーションは、その目的やアイデンティティについて、明確で統一されたメッセージをユーザに与えます。一方、奇抜だったり、真面目には見えないUIの中で生産的な作業を実行するようなアプリケーションでは、ユーザはこの矛盾をどのように解釈したら良いか分からなくなる可能性があります。 同様に、ゲームなどの没入型のアプリケーションでは、楽しさを約束してくれて、発見のありそうな美しい外観をユーザは期待します。ゲームでは真面目な作業や生産的な作業を実行することは期待されませんが、見た目と体験が一体化していることは期待されます。旧版では外観という表層的な面に限定されていますが、新版では抽象度が上がり、端的に伝えようとしています。また、外観の重要性を低めているというよりは「装飾と混同しない」とあるように、単に飾り付けをすることが喜びに直結するわけではない、という最低ラインの提示に転換している印象があります。デザインに喜びをもたらす方法は、紙吹雪を加えることではありません。プロセスの最後に装飾を後付けすることでもありません。喜びをもたらすインターフェイスを作るには、ユーザーに感じてほしい感情を特定することです。リラックス、自信、興奮。そして、デザインを通じてそれを強化する機会を見つけましょう。ユーザーがサービスや製品を通して得る体験は複雑で多層的です。だからこそ、作業の結果が目に見えやすい装飾に逃げず、広い視野で製品とユーザーの結びつきを探求することを示唆しているのだと思います。というわけで、ざっくりですが新しいデザイン原則を読んでみました。全体的な感想としては、旧版を土台にした増改築ではなく、あたらしい土台を作ったうえで旧版のエッセンスを散りばめつつ、耐用年数の長さと現代的なアップデートが施された内容だと感じました。各セクションは具体的なアプローチや技術への入口として機能しており、かつ人間らしい温かみも感じさせるもので、初学者にも経験者にも有用な羅針盤と言えるでしょう。個人的には、この原則がどういった経緯やプロセスで作られたかの裏側や、各セクションをより具体的に深掘りしたセッションや記録が公開されたら嬉しいなと感じます。2017年に何が語られていたかここまで書いて、そういえば過去にHIGに関するWWDCのセッション動画があったな、と思い出しました。日本語字幕はなかったものの、字幕ファイルをツールで日本語訳したところ導入で話されている内容が「めちゃくちゃいいこと言ってるな」と心に響いたので、自分用のメモも兼ねて以下に引用します。「ユーザー（user）」という言葉には、やや無機質で匿名的なニュアンスがあります。人をインターフェースとの関係だけで狭く定義してしまいます。「ヒューマン（human）」という言葉は、私たちがデザインしている相手についての、より豊かなイメージを呼び起こします。「私はただの人間だから」と言うとき、それは自分に欠点や不完全さがあることを認めることです。しかし「ヒューマン」という言葉は、私たちの最も崇高な資質を表す言葉でもあります。誰かの「人間性」を認めることは、その人の優しさ、思いやり、寛大さ、善良さを認めることです。インターフェースをデザインすることは、根本的に他の人間に奉仕することです。 目標は美しいアプリ、整理されたアプリ、シンプルなアプリ、フォーカスされたアプリを作ることではありません。これらはすべて重要ですが、本当の目標ではありません。本当の目標は、あなたが作るアプリを使う人々の人生にポジティブな影響を与えることです。 本当に重要なのは、あなたのアプリが、デザインしている人々の感情的・実際的なニーズをどれだけ満たせるかです。人間には、安全と予測可能性へのニーズがあります。知識、意味、理解へのニーズがあります。タスクを達成し、個人的・職業的な目標を達成するニーズがあります。そして美しさや喜びを体験するニーズがあります。 よくデザインされたアプリはこれらを提供します。アクションの結果を予測しやすくし、安定感・信頼感を与えます。明確で役立つ情報を提供し、人々が情報に基づいた選択をできるよう助けます。合理化・簡略化されたワークフローで効率的にタスクを達成できるようにします。そして、美的に心地よく、楽しく、さらには喜びをもたらすような体験を提供します。 これらの品質を持つアプリを使うとき、アプリを作った人々が自分のニーズをしっかりと考慮してくれたことが伝わってきます。どうすれば素早く成功裏に物事を成し遂げられるかを考えるために、どれほどの時間と努力が注がれたかが感じられます。すべてに意味があり、すべてが理解できる。それはとても「人間的」な感じがします。アプリがそう感じさせてくれるとき、私たちはデザインした人々の人間性を感じます。 では、あなたのアプリのデザインはどうすればそれを実現できるのでしょうか？デザインについて話すとき、私たちはよくテクニックやプロセスに注目しがちです。これらは重要な考慮事項ですが、それだけでは優れたデザインには繋がりません。優れたデザインは、デザインとは何かについての、より根本的で人間的なレベルの深い理解に導かれています。これがデザイン原則の提供するものです。 デザイン原則は、私たちが世界をどう知覚し、情報をどう処理し、意思決定をどう行い、コミュニケーションをどう取るかについての核心的な真実を表現しています。これらの真実は普遍的かつ永続的です。あらゆる種類のグラフィックデザイン、建築、インテリアデザイン、リテールデザイン、ランドスケープデザイン、自動車デザイン、そして他のあらゆるデザインに適用されます。 デザイン原則は「どうするか」ではなく「なぜそうするか」を教えてくれます。優れたデザインの上に築かれる基盤として機能するのです。これを読むと、原則はただリニューアルされたわけではなく、Appleの姿勢や哲学は連綿と続いているのだなと思わされます。新版に合わせて公開されたセッションの抜粋です、と言われても違和感がまったくありません。すごい。ひょっとすると、新版の制作にあたりこのビデオも参考にされているのかもしれません。

自分の講義では、初日の最初のセクションで、講義で取り扱う領域について説明する時間を設けています。デザインリサーチの講義では自分が書いたテキストのみを用意していたのですが、なにか良い資料はないかと探していたところ、キヤノンがYouTubeで公開している動画を見つけました。どちらも、製品開発においてデザインリサーチがどのような役割を持っているのか、実際にどのような仕事をしているのかが端的に説明されており、学生に「デザインリサーチは実際のお仕事だとこういうことをしているよ」と紹介しやすい事例だと感じました。こうした動画コンテンツは特に国内だとなかなかお目にかかれないので、制作されたキヤノンさんに感謝です。

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のバランス」という別テーマが生まれる。