AI は UI デザイナーに取って代わるのか？AI とともに過ごした 1 年で実際に変わったこと

私はデスクトップアプリケーションから、医療用モニター、産業用制御パネル、業務の現場で使われる画面といった組み込みデバイスまで、幅広い文脈で使われる製品の UI をデザインしています。この 1 年、さまざまなタイプの製品に携わり、デザインプロセスの一部としてほぼ毎日 AI を使ってきました。その結果、デザインについての考え方が変わり、しかも一度ならず考えを改めることになりました。

AI はデザイナーの仕事のやり方を大きく変えています。ただし、デザインプロセスそのものを乗っ取ってはいません。もっとも有効なのは、アイデア出しと探索を加速させるために AI を活用し、製品化の段階に入ったら仕上げ・検証・ハンドオフをデザインツールに任せる、という進め方です。

ここからは、私が間違えた部分も含めて、デザインワークフローにおける AI との歩みをお話しします。 

AI は UX デザイナーに取って代わるのか

いいえ。AI が置き換えているのは UX 業務のなかの特定のタスクであり、UX デザイナーそのものではありません。

とはいえ、この問い自体はもっともなもので、デザイナーのあいだでも議論が続いています。AI は数秒でインターフェースを生成し、複数のデザインの方向性を試し、初期段階の作業を高速化できます。しかし研究と実務のいずれにおいても、経験豊富なデザイナーは AI をデザインプロセスの代替とは見ていません。むしろ、探索を加速し、違う視点で考える助けとなる協働相手としてとらえており、デザインの意思決定には人間の判断が不可欠だと考えています。 

Nielsen Norman Group の State of UX 2026 は、より率直です。デザインシステムのコンポーネントを組み合わせているだけなら、あなたはすでに AI に置き換え可能である、と。自動化が難しいのは、磨かれた審美眼、リサーチに裏づけられた文脈理解、批判的思考、そして慎重な判断です。 

AI は UX デザイナーにとって非常に有用です。試行錯誤の 1 年を経てもなお、私はすべてのプロジェクトで AI を使っています。そこから得たもっとも重要な学びは、AI が私の役割を奪うことはないが、デザインプロセスの各段階でどのツールをどう使うかは確実に変わる、ということでした。

熱狂は本物でした

AI がデザインプロセスに入り込み始めたとき、一夜にしてすべてが変わったように感じました。

UI づくりが、白紙のキャンバスからではなくプロンプトから始まるようになったのです。手作業なら数時間かかる画面やユーザーフロー、製品アイデアを、AI は数秒で生成できました。多くのデザイナーが色めき立ったのも当然でしょう。

UX デザイナーとインダストリアルデザイナーによる初期の研究では、生成 AI が、とくにアイデア出しとコンセプト探索において有用な創造的パートナーになりつつあることが示されています。同じ研究は、同じくらい重要な論点も指摘しています。デザイナーが自分でコントロールできていると感じられるかどうかが、ワークフローの一部として AI をどれだけ信頼できるかを左右するという点です。

私もおそらく、ほかの誰にも負けないくらい興奮していました。Claude Design、Figma Make、Lovable など、UI デザインを速くしてくれると謳うツールはほぼすべて試したいと思ったのです。

そして正直に言えば、その体験は素晴らしいものでした。

アイデアをいくつかのプロンプトで説明すれば、数秒後には画面に何かが表示されます。完璧ではありませんが、会話を始めたり、チームにアイデアを共有したり、Figma を開く前にさまざまなユーザーフローを検討したりするには十分以上のものでした。一日の大半をデザイン課題の解決に費やす人間にとって、これは大きな変化でした。

Figma の State of the Designer 2026 では、デザイナー 906 名を対象とした調査で、91% が「AI ツールによってデザインが良くなった」、89% が「作業が速くなった」と回答しています。この熱気は本物であり、根拠のあるものです。

UX のどの部分を、いまの AI は担えるのか

AI がもっとも力を発揮するのは、デザイン作業が本格的に始まる前です。Figma を開く前、コンポーネントをつくる前、デザインの意思決定をする前。課題がまだ曖昧で、可能な方向性がいくつもあり、疑問だらけで、明確な答えがない段階です。ここで AI の効果はもっとも大きくなります。

いまでは、新しいプロジェクトを始めるとき、私が最初に向かう先はたいてい AI です。Claude Design や Figma Make といったツールは、とくに初期段階において、私のワークフローの重要な一部になりました。

現在のワークフローを説明するなら、探索と制作の 2 つに分かれます。後者については後ほど触れます。もっとも大きく変わったのは、そちらだからです。

探索フェーズでは、まだデザインの意思決定を何もしていません。課題を理解し、さまざまなシナリオを検討し、アイデアを集め、より良い問いを立てようとしている段階です。

当初は、AI がどこまでできるのかを知りたくて、完成した UI 画面を生成させていました。しかし、その後それをやめ、AI を「画面より前の作業」へと移していきました。

• ブレインストーミングと機能の検討

• さまざまなユーザーフローの探索

• UX ライティング

• ドキュメントの整理

• 小さな機能でも、チームに自分の考えを的確に伝えるための簡易デモの作成

   

複数のコンセプトを何時間もかけてつくる代わりに、いくつものアイデアをすばやく比較し、自分の思考を検証し、デザインを始める前にどの方向性を掘り下げるべきかを判断できるようになりました。

AI が力を発揮しにくくなるところ

UI/UX デザインにおける AI の役割は、製品化に近づくほど小さくなります。製品を決定づける部分、つまり、どの方向性にそもそも投資すべきか、インタラクションはどう振る舞うべきか、そして仕上げからハンドオフに至るまでのすべてに AI を使えるとは、私は考えていません。それがワークフローの後半であり、「AI は UX デザイナーに取って代わるのか」という問いに対する私の答えの根拠でもあります。

研究によれば、デザイナーが生成 AI からもっとも価値を得るのは初期のアイデア出しと探索であり、プロジェクトが仕上げ・評価・実装へと進むにつれて人間の専門性の重要性が高まっていくことが示されています。

この段階での課題は、もはや「もう一つインターフェースを生成すること」ではありません。正しいデザイン判断を下すことです。AI が生成する UI は決して悪くありませんが、私が問うことはまったく別のものになります。

「〜の画面をデザインして」とはもう言いません。代わりに、こう問いかけます。

• この挙動は、私たちの UX パターンに沿っているか

• このインタラクションは、私たちのユーザーにとって適切か

• この解決策は、私たちのデザインシステムに合っているか

• チームの技術的制約と両立するか

UX デザイナーは、スクリーンショットには表れない意思決定に、時間の大半を費やしています。その判断こそが体験を形づくり、製品全体の一貫性を生み、そのデザインが製品化に耐えるかどうかを決めます。

ほかの人命に関わるような領域のデザイナーも、同じ線引きを語っています。ある医療 UX チームも最近、ほぼ同じ主張をしています。AI が自動化するのはアイデア出しであって判断ではなく、両者の隔たりは、デザインの誤りが実際の人間に及びうる領域でもっとも大きくなる、と。組み込みデバイスは間違いなくその領域に含まれます。以前の記事で、同僚の Antti も「AI だけで組み込み UI のデザインは解決できない」と述べていましたが、私も同じ考えです。

そしてもう一つ、気づくのに時間がかかった問題があります。

AI をしばらく使ううちに、生成されるインターフェースの多くがどこかで見たようなものに見えてくることに気づきました。きれいで整っているのですが、どれも似通っていて、無個性なのです。

十分な製品コンテキストがなければ、AI は多くの場面でうまく機能する一般的なデザインパターンに頼ります。よくある事例から学習し、誰にとっても破綻しないインターフェースを生成するのです。

しかし、製品は「誰にとっても」のためにつくられるものではありません。製品にはそれぞれ固有のユーザー、技術的制約、プラットフォーム要件、デザイン言語があります。そうしたものは、プロンプトにはめったに現れません。

UX デザイナーがもっとも価値を生むのは、まさにそこだと私は考えています。インターフェースを生成することは日ごとに簡単になっています。しかし、正しい製品判断を下すことは、いまも非常に人間的なプロセスです。

学んだこと：デザインシステムと AI

ある時点で私は、探索と制作のあいだのギャップを埋める鍵を見つけたと思いました。AI が自社のデザインシステムを理解できれば、出力はもっと的確になるはずだ、と。

そこでデザインシステムを接続し、生成される UI が実際の製品にぐっと近づくことを期待しました。

たしかに改善はしました。画面の一貫性は増し、コンポーネントも実際に使っているものにかなり近づきました。しかし、そのデザインで作業を進めるうちに気づいたのです。AI は私たちのデザインシステムを使うだけでなく、足りない部分を勝手に埋めていました。

存在しないコンポーネントを新たにつくり、私たちが設計したことのないインタラクションパターンを提案してくる。ときには、もっともらしいけれど自社製品の一部ではないレイアウトを持ち込んできました。

どれも、明らかに間違っているようには見えませんでした。むしろ、良く見えるものもありました。しかし、それは「私たちのもの」ではなかったのです。

結果として私は、生成されたデザインをレビューし、不要な要素を取り除き、ファイルを整理するのに何時間も費やすことになりました。

そして、問いが変わりました。「AI はどれだけ速く生成したか」ではなく、「これは本当に時間を節約できたのか」と。

デザインシステムと AI の具体例

私の期待は、AI が自社のコンポーネント・カラー・パターンにアクセスできれば、生成される UI はそれらを正確に踏襲するだろう、というものでした。しかし細部を見ると、自社製品にとって実は重要な相違がいくつも見つかりました。

たとえば下の例では、AI の出力とデザインシステムのあいだの視覚的な差、つまり誤ったトークン、アイコン、コンポーネント、欠落した要素が確認できます。目に見える差だけでなく、余白、フロー、インタラクションパターン、コンポーネントの状態など、ガイドラインに沿っておらず、かつ私が十分にコントロールできていない判断も数多く隠れていました。

図 1 - 左が Qt のデザインシステム、右が Claude Design の出力。Claude がデザインシステムを望ましくない形で解釈したり、存在しないコンポーネントを創作したりしている箇所が明確に見て取れる。

図 1 には、自社のデザインシステムと AI 出力の食い違いがいくつか表れています。細かな点ではありますが、実際の製品に取り組むうえでは無視できません。AI はコンポーネントもカラートークンも知っていましたが、なぜそれを特定の使い方をしているのかまでは、必ずしも理解していなかったのです。

これは重要な学びでした。デザインシステムを接続すれば AI にガードレールを与えられますが、それだけで出力が製品品質になるわけではありません。判断をレビューし、パターンを確認し、最終的なデザインが自社のハードウェア上で、デバイスが実際に使われる環境で、ユーザーにとって機能するかを確かめる作業は、依然として私の仕事です。

デザインシステムはコンポーネントライブラリ以上のもの

デザインシステムを AI に統合した経験は、デザインシステムに対する私の考え方を根本から変えました。

デザインシステムは、単なるコンポーネントのライブラリではありません。長い時間をかけて積み重ねられた、数百のデザイン判断の結果です。すべてのコンポーネントには存在する理由があり、すべてのパターンには製品要件、技術的制約、アクセシビリティへの配慮、そしてデザイナーと開発者のあいだで交わされた数千の会話が反映されています。

AI はそうしたコンポーネントを認識し、説得力のあるインターフェースに組み上げることができます。しかし、なぜそれが存在するのか、いつ使うべきで、いつ使うべきでないのかを理解すること。それこそが、最初のアイデアと、意図的な判断の積み重ねから生まれた製品品質のデザインとを分けるものです。

いまでも私は、ほぼすべてのプロジェクトを AI から始めます。しかし、AI がプロジェクトを完成させてくれるとは、もう期待していません。ビジュアルの出来が悪いからではなく、美しい画面は成功する製品のごく一部にすぎないと学んだからです。その画面の背後にある判断のほうが、はるかに重要なのです。

足りないのはコンテキスト

こうした経験を通じて気づいたのは、AI における最大の難しさはインターフェースを生成することではなく、十分なコンテキストを与え、UX パターンを定義することだ、ということでした。

新しい会話は毎回、ほぼゼロから始まります。AI が的確なものを生成できるようになるまでに、製品、プラットフォーム、制約、期待値を説明しなければなりませんでした。

だからこそ、Qt GUI Design Skill に強く興味を惹かれました。これは開発者向けにつくられたものですが、一連の質問を通じて、目指すデザインのコンテキストと境界を与えられるしくみになっており、UI を返す前に、名前のついたデザイン原則を適用します。毎回ゼロから AI に教え込む必要がなく、スキル側があらかじめコンテキストを提供してくれるのです。

一般的なプロンプトを書くのとはまったく感覚が異なり、実世界のデバイスをデザインする際の複雑さをより忠実にとらえています。組み込みシステム向けにデザインするなら、AI にはターゲットハードウェアを考慮してほしい。オートモーティブ向けなら、車載インターフェースに求められる期待と制約を理解してほしい。医療機器なら、医療従事者が患者の回復を支えるという現実から会話を始めてほしい。しかも、毎回そのすべてをプロンプトに書き込むことなく。

コンテキストが適切であるほど、返ってくるアイデアも適切になります。

Qt GUI Design Skill をはじめとする同種のスキルは、デザイナーの専門性を置き換えるものではありません。実際、UX デザイナーと協働する環境にない開発チームのために特化して設計されています。それでもなお、AI との対話をはるかに意味のあるものにしてくれます。

もう一つの実験

Qt GUI Design Skill が実際にどれほどの差を生むのかが気になり、Claude で簡単な実験をしてみました。まったく同じプロンプトを 2 回与えたのです。

1 回目は通常のプロンプト：「ICU で使用するベッドサイド患者モニターをデザインして」。

図 2 - Qt GUI Design Skill を使わずに AI で作成した ICU ベッドサイド患者モニターの UI。清潔でモダンに見えるが、汎用的で、臨床現場の UX ニーズを優先していない。

結果は、清潔でモダンなものでした。図 2 のとおり、レイアウトは明快で、コントラストは強く、数値は大きく、色は鮮やかで、モダンなダッシュボードらしい仕上がりです。たしかに洗練されていて、見やすくもあります。

しかし同時に、汎用的でもあります。そして正直なところ、ここでなされた選択は、医療用モニターよりもコンシューマー向けダッシュボードに適したものでしょう。臨床環境では、視覚的なインパクトよりも、安全性、アラームの明瞭さ、一貫性、そして素早く読み取れることのほうが重要です。

つまり、見た目は本当に良いのですが、臨床の UX ニーズよりも美しさを優先してしまっていました。

2 回目は、まったく同じプロンプトを Qt GUI Design Skill を有効にして実行しました。Claude は何かを生成する前に、製品と使用環境について質問してきました。

図 3 - UI の作業に入る前に、Qt GUI Design Skill はデザインのコンテキストを得るための質問をする。たとえば、ターゲットハードウェアやプラットフォームについて尋ねる。

最終的なデザインには、その追加コンテキストが反映されていました。情報の階層はより明快になり、レイアウトには意図が感じられ、実際の組み込み医療機器のデザインにぐっと近づきました。

図 4 - Qt GUI Design Skill を使って AI で作成した ICU ベッドサイド患者モニターの UI。医療機器の UX 原則を考慮しており、図 2 の汎用的な UI よりも強力な出発点になっている。

図 4 を UI の観点から見ると、次の点に気づきます。

• 一貫した配色：バイタルごとに固有の色を割り当て、アラーム色の意味を明確に保っている

• 一貫したレイアウト：すべてのバイタルサインが同じ視覚構造に従い、画面を読み取りやすくしている

• 波形の表示：各数値に波形を併記し、視覚的な文脈を補っている

• 明確なアラームバー：アラームの状態が常に見え、理解しやすい

• 改善された操作系：大きく統一されたコントロールで、手袋をしたままでも視認・操作しやすい

• 実機を想定したフレーミング：固定ベゼル内に UI を設計し、適切な余白と波形領域の収まりを確保している

これらは単なる見た目の違いではありません。明確なアラーム階層、一貫した色の意味づけ、患者識別、エラー防止、アクセシビリティ、時間的プレッシャー下での安全な操作といった、確立されたヘルスケア UX 原則に対応するものです。

このスキルによって、デザインは医療機器インターフェースの慣行と安全要求に近づきました。ただし、最終ハンドオフの前に臨床面と UX/UI 面のレビューが必要であることに変わりはありません。

以下の表は、スキルによるガイドで改善された主要な医療機器 UX 原則をまとめたものです。

私にとって最大の学びはここでした。Qt GUI Design Skill が変えたのは UI そのものではなく、UI が生成される前に交わされる会話だったのです。

だからといってデザインが製品品質になったわけではありません。それでも、汎用的な UI よりもはるかに強力な出発点を与えてくれました。

そして、デザインのコントロールを失い始めた

Qt GUI Design Skill をワークフローに組み込んでもなお、予想していなかった変化にすぐ気づきました。AI に頼るほど、自分が実際にデザインしているという感覚が薄れていったのです。

最初は気になりませんでした。しかししばらくすると、デザインの意思決定に費やす時間が減り、プロンプトを書いて調整する時間が増えていることに気づきました。

AI が私の意図を的確に汲み取ってくれる日もあります。一方で、同じプロンプトを何時間も書き直し、一文を変え、コンテキストを足し、詳細を削り、見当違いなデザイン出力を言葉で正しい方向へ導こうとする日もありました。

そして、ようやく近づいてきたと思った矢先に、利用上限に達することもありました。

その瞬間、私は望ましくない形で何かが変わってしまったと気づきました。私はもう、デザインをしていなかったのです。

デザイナーは小さな判断を積み重ねることを楽しみます。そこにこそ創造性があり、自分の仕事とのつながりをもっとも強く感じられるからです。先に引用した Figma の調査でも、デザイナーは創造的な自由を仕事満足度の最大の要因に挙げています。回答者の 87% が、創造的な裁量が最高の仕事につながると答えました。

AI との歩みのこの段階で私が感じていたのは、Nielsen Norman Group が「AI 疲れ（AI fatigue）」と呼ぶものに近いものでした。そこで私は、ワークフローをふたたび変えました。デザインツールに戻ったのです。AI が役に立たないからではなく、そこでなら自分が判断を下せると分かっていたからです。

UX ワークフローで AI をどう使うか

私が見つけた最良の方法は、AI ツールと従来の UX ツールの境界線をはっきりさせることでした。

先に述べたとおり、私はワークフローを探索と制作の 2 つに分けています。AI ツールは前者に、UX ツールは後者に属します。両者は競合しません。解いている問題が違うのです。

この見方は複数の研究にも支持されています。デザイナーは AI に製品をデザインしてほしいわけではない、というのが研究者の見立てです。デザイナーが AI に求めているのは、とくにプロジェクトの初期段階で作業を速めることであり、最終的なデザインのコントロールは手放さないことです。

私の使い方もまさにそうです。探索側では、AI が立ち上がりを助け、多様なアイデアをすばやく試し、ドキュメントを整え、チームの認識を揃えてくれます。制作側では、デザインツールが構築とイテレーションを支え、実ユーザーによる検証、インタラクションの仕上げ、制約のなかでの作業、そして自信を持って開発にハンドオフできるデザインの準備を可能にしてくれます。

AI 時代の UX デザインはどこへ向かうのか

AI 時代の UX デザインの行方を考えるとき、もっとも的確な枠組みは、Qt が先日開催した組み込みアプリケーション向けデザインに関するパネルディスカッションの視点だと考えています。UX デザインの歴史を通じて、ツールは大きく変わってきましたが、基本原理はまったく動いていない、というものです。

優れた UX デザインは、いまも非常に人間的なプロセスです。観察を重ね、ユーザーと対話し、ビジネス目標を理解し、技術的制約と折り合いをつけ、最終的なユーザー体験を形づくる数百の小さな判断を下していく。それはプロンプトのなかでは起こりません。デザインプロセス全体を通じて起こることです。

探索フェーズが終わり、アイデアが固まり、デザインが実際の製品になり始めると、私の優先順位は変わります。もはやコンセプトやバリエーションを増やそうとはしません。意図したとおりにデザインが実装されることを確実にしようとします。

ここで、従来の UX デザインワークフローがとくに重要になります。インタラクションを磨き、余白を調整し、判断を検証し、体験を仕上げるのに何時間もかけたのです。実装用のプロンプトが曖昧だったり、詳細が足りなかったりしたせいでその成果が失われるのは、避けたいところです。

3 年間にわたる 8,000 件超の回答をもとにした Figma の 2026 AI report も、同じ主旨を述べています。AI はほぼ何でもつくれるが、何をつくる価値があるかを決めることはできない、と。回答者の 90%（開発者に限っても 65%）が、AI 以前と比べてデザインの重要性は少なくとも変わっていないと答えています。

それで、AI は UX デザイナーに取って代わるのか

いいえ。そして 1 年以上にわたり AI ツールとその能力を試してきたいま、私はこの問い自体がもう興味深いものだとは思いません。本当に興味深いのは、UX デザインプロセスのどこに AI を置くのか、そして代わりに何を手放さないと決めるのか、という問いです。

いまの私のワークフローは、とても自然に感じられます。AI は考えることを助けてくれる。デザインツールは世に出すことを助けてくれる。それぞれに異なる役割があり、組み合わせることで速さと確かさを両立したワークフローになります。

変わっていないのは、もともと仕事の核だった部分です。これは誰のためのものか、何に耐えなければならないのか、そして数百の小さな判断のうちどれが正しいのか。それはいまも、プロンプトの外で起きています。