デザイナー不要論のただ中で、仕事の本質はどこに戻るのか
「AIがあればデザイナーは要らない」というデザイナー不要論が、AIでUIが生成できるようになった2026年3月から4月にかけて、以前より重みを持って語られ るようになってきました。実際、AIコーディングエージェントやデザイン生成AIが現場に入り、「作るだけならすぐ作れる」世界が一気に近づいてきたのは事実です。
ただ、「デザイナー」と言う言葉自体の主語がとても大きいので、誰が何を論じているのかはよく吟味すべきと思われます。非デザイナーがデザインプロセスを漠然としたコストと捉えていて、その主張を強化するために都合よく使っている場合や、なんらかのデザイナー自身が自己防衛の反応として悲観/楽観論で語る場合など、主張はさまざまです。言葉を選ばずに言えば、これらは近視眼的なポジショントークの域を出ておらず、結論を出すには実践と学習が十分ではないように思われます。おそらく、これは「デザイナー」に限った話でもないはずです。
そこで、この記事では「デジタルプロダクトのデザイナー」にフォーカスを当てて、今後短期的に起こるであること、すでに起きていること、その先にどのような実践と学習を積んでいくべきかについて検討する試みとしています。
私自身は、デザイナーとしてプロダクト組織でAIを使ってみると、速度は上がる一方で、別の種類のボトルネックも顔を出しているように感じています。
レビューをさばき切れずタスクやPRが滞留する、クレジットを使い切って開発が止まる、AI生成物の品質を人が裁定する場所がどんどん増えるなど、開発サイクル全体で見ると、人の介入プロセスの配分とAIクレジットをどれだけ無駄なく使えるかがこれからの勝負所になりつつあるように思います。組織で開発する、という前提が変わらなければの話ですが。
もう一つ、もっと根本 的な動きとして、AIが表層を引き受けた結果、プロダクトデザインの本質にあたる部分が前面に出てきている、という感覚もあります。
以前このAI時代にデザイナーがこの先生きのこるにはという記事で、デザイナーの仕事が「作る」から「選ぶ・判断する」側にシフトしていくという話を書きました。この記事はその延長線上で、組織レベルで何が起きるのか、本質的な仕事がどこに残るのかを、もう少し踏み込んで考察してみたいと思います。
構成としては、構造変化のOpsレベルの話と、その先でデザイナーの仕事がどう本質へ戻っていくのか、という二つの論点を、B2B SaaSのデザイナーを主人公にした二つの未来シナリオで扱います。書いている内容は現時点での筆者の偏見に満ちた推論・妄想の域を超えないものであり、一つのフィクションとしてお読みください。
この記事のターゲット
AIツールを前提にしたとき、組織でどんな変化が起きるのかを占いたい方
デザイン組織のマネジメントに携わっており、今後の役割変化の示唆を得たい方
B2B SaaSプロダクトのデザインOps（Design Ops）に関心がある方
プロダクトデザインの本質は、何が変わり何が変わらないか
ボトルネックの話に入る前に、プロダクトデザインという仕事の骨格を一度振り返っておきたいと思います。AI時代のデザインを語る前に、そもそも自分たちの仕事の核はどこにあるのか、という整理です。
ドン・ノーマン博士の「誰のためのデザイン？」で述べられているように、プロダクトデザインには3 つのモデルが重要とされてきました。設計者が想定するデザインモデル、ユーザーの頭の中に形成されるユーザーモデル（メンタルモデル）、そして実際にユーザーが触れるシステムイメージ。
設計者とユーザーは直接話せないことが多いので、設計者は自分の理解を表出に翻訳し、ユーザーはそのシステムイメージから自分のメンタルモデルを形成する。間に立って双方を噛み合わせる営みが、プロダクトデザインの仕事の骨格だと考えられています。
B2B SaaSのように業務ドメインが深い領域では、この「ユーザーのメンタルモデル」は個人の認知だけでなくドメイン全体の暗黙知まで含みます。月末の締め作業、法改正の伝搬、部門をまたぐ承認フロー、会計区分のクセなど。こうした業務の実態を読み取って構造として整理し、相応しい形（UI）に翻訳する仕事は、エリック・エヴァンス氏のドメイン駆動設計でいう「ユビキタス言語」にまつわる営みと、根本は同じ仕事だと思います。
メンタルモデルと情報設計の関係については、以前メンタルモデル不在のUIがユーザーに受け入れられない理由という記事でも書きました。表面的に整っていても、ユーザーの頭の中のメンタルモデルと噛み合っていないUIは受け入れられない、という話です。AI時代はこの古典的な論点が、生成UIの均質化という新しい形で再浮上してくるのではないかと感じています。
若輩ではありますが、個人的な実感としてプロダクトデザインの本質はAI時代になったからといって通じてそれほど変わっていないと思っています。変わってきたのは表出の手段 で、紙面からGUI、モバイル、音声、そして生成UIへと移ってきました。変わらないのは、ユーザーやドメインに宿るメンタルモデルを構造化し、時代や環境に相応しいインターフェースに適用する、という情報設計の営みです。
この見立てからAI時代を見つめ直すと、見え方が少し変わります。AIが得意になってきたのは、構造をインターフェースとして表出する部分、前述のシステムイメージを翻訳して実装に落とす層です。一方、その前段にあるメンタルモデルの読み取りと構造化にはユーザーとの接触機会が不可欠であり、現時点の「生成AI」が踏み込めていない領域であり、しばらくは踏み込めなさそうな領域でもあります。
これは「AIにはできない本質」という守りの話ではなく、むしろ逆で、AIが表層の実装を引き受けた結果、これまで表出作業に埋もれがちだった本質の側が前面に出てきていると考えたほうが、AI時代のデザインプロセスをうまく説明できる気がしています。
この本質が前面化するという読みを土台に、以下ではOpsレベルの変化とデザイナーの役割変化を想像してみます。
ボトルネックはどこに移るのか
AI前提の開発現場で何が本当のボトルネックになるか、という議論は英語圏で先行しています。最近日本国内のSNSを中心に議論されているハーネスエンジニアリングの整理や、Anthropicが公式ブログで公開しているハーネス設計の記事は、「モデルよりもハーネスの設計が結果を決める」という見方があるようです。
参考：Effective harnesses for long-running agents（Anthropic Engineering）
1年前にAIコーディングを「vibe coding」と名付けた当人、Andrej Karpathy氏（OpenAIやTeslaを経た著名なAI研究者）自身が、その1年後にはこのスタイルを「passé（時代遅れ）」と位置づけ、「これからはエージェントを差配して監督する側の仕事、agentic engineeringが新しいデフォルトになる」と整理を上書きして主張しています。巷では生成速度ではなく運用設計が勝負所だという見立てが広く共有されつつあるようです。
参考：Vibe coding is passé. Karpathy has a new name for the future of software.（The New Stack）
現場で起きるレベルの事象で言い換えると、短期的なボトルネックは次の2つに集約されていきそうです。
人がレビュー・意思決定・修正に介入する量をどれだけ最小限にできるか
AIクレジット（トークン）をどれだけ無駄なく最小限で使えるか
この2点は表裏の関係にあります。人の介入を増やせばレビュー待ち行列で時間が溶け、介入を減らせばAI任せで品質が落ちてやり直しが発生し、結果的にクレジットが燃えます。「どの工程を人が決め、どの工程をAIに任せ、どこでクレジットを使うか」という責任の所在とフロー効率の問題解決に、仕事の中身がだんだんと置き換わっていく感覚です。
前述の言い方に戻すと、ここで自動化が進むのはシステムイメージへの翻訳の層であり、ドメインとユーザーのメンタルモデルを読み取って構造化する層は、人の側に残るであろうと考えています。この前提で、以下を読み進めていただければと思います。
クレジット経済という新しい制約
コスト面でも、既に実務の話題として上がり始めています。Claude Codeではプランごとに5時間ローリング制限と週次のキャップがあり、Maxプランのヘビーユーザーでは月3,650ドル相当のAPI利用を200ドルで賄えている、といった試算がnoteやtech blogで流通しています。AIインフラ側でもOpenAIのトークン処理量が2026年の半年で2.5倍に伸びており、「クレジット」が実在の経済単位として認識され始めています。
参考：Using Claude Code with your Pro or Max plan（Claude Help Center）
使っている側の感覚としても、クレジットは意識せざるを得ないリソースになってきています。ここで効いてくるのは、この制約が個人の金銭感覚ではなく、組織の予算管理と地続きになり始めているという点です。エージェントを回す業務フローが増えれば、部署別のクレジット予算、使用量モニタリング、成果単価の議論が現実の経営課題として浮上してきます。
現時点ではまだ、多くの組織がこの問題を個人利用の延長として扱っています。ただ、プロダクトごとに月額数百万円単位でクレジットが動き始めれば、CFO側から消費の透明性を求められるのは時間の問題です。そのとき誰が責任を持つ職能なのか、が各社で次の論点になりそうです。
一部のメディアで取り上げられたように、すでにAnthropicがサービスの実質値上げを検討するフェーズにあることが示唆されるようなニュースも出てきており、思っているよりも早く適応を迫られることになるかもしれません。
シナリオ：同じ会社で起きうる、二つの未来
ここからは具体的に、同じB2B SaaS企業に所属するデザイナーを主人公に、起きうる二つのシナリオを並べて考えてみます。いずれも架空の想定ですが、主要な国内B2B SaaS企業のイメージで構成しています。
主人公はW氏。従業員500名規模のB2B SaaSで、プロダクトデザイナーとして8年目。自社プロダクトの基幹UIを長く担当してきたベテランで、業務ドメインの知識もそれなりに蓄えています。プロダクトデザイン組織はプロダクトデザイン・デザインシステム部門、合計20名前後。Claude Codeは承認制で本番導入済み、FigmaのAI系プラグインやデザイン生成AIはデザイナー個人レベルで使い始めている、という状況からスタートします。
背景として、冒頭で触れた不要論の文脈が、W氏の会社の経営陣の耳にも入りつつあります。Figmaが登場した頃にも同種の議論はありましたが、今回はAIが実際にUIを生成できてしまうぶん重みが違います。これが共通の前提です。
二つのシナリオは優劣の話ではなく、同じ条件から枝分かれしうる可能性として並べています。どちらに転んでもおかしくない、というスタンスで読んでいただければと思います。
シナリオA：デザイナー不要論が現実化する場合
年が明けて最初の四半期レビュー。経営会議で「デザイン部の人件費に対して、プロダクトの出荷速度が上がっていない」という指摘が出ます。デザイナー不要論の文脈が、実際の意思決定にも染み込み始めている時期です。
まず、PMチームがClaude Codeを使って自前でUI試作をする動きが始まります。PRD とデザインシステムを参照させれば、既存プロダクトに混ざっても違和感のない画面はそれなりに生成される。初期のクオリティは粗いものの、「PRレビューでデザイナーが細かい指摘を入れればむしろ往復回数が増える」という現場の実感から、「デザイナーを通さず直接実装に入ったほうが早い」という判断が少しずつ通るようになっていきます。
W氏は、PMが自分で作ったUIのレビューに加わったとき、あるドロップダウンの違和感に気づきます。見た目の色や余白は整っているのですが、選択肢の並び順が業務の実態と合っていない。実務では9割のユーザーが最初に選ぶオプションが、画面上では下のほうに配置されている。AIは表出としては整った画面を出せても、ユーザーの業務のメンタルモデル、つまり「この人が月末に何をどの順でやっているか」という構造までは読めていない小さな兆しです。
W氏は「これ、本当にAIに任せきっていい領域ですか。ユーザーの業務の流れと画面の順序が噛み合っていないんです」と切り出そうとします。ただ、その違和感を「ドメインのメンタルモデルとズレている」という言葉で整理して出せない。結果として「経験からくるこだわり」の話に聞こえてしまい、会議での発言権がじわじわと細くなっていきます。
1年後、組織再編のアナウンスが出ます。開発技術責任者はこう説明しました。「デザイナーがプロダクトに関わるレイヤーは、AIの前段で定まる要件整理に寄せたい」。言葉としては筋が通っていますが、実際にはその前段の仕事もPMに吸い上げられていきます。
プロダクトデザイン部は縮小、残るメンバーはデザインシステム部門か 他の開発部門に吸収されます。W氏は「デザインシステム運用担当」に配置転換になりました。自分で画面を設計する仕事はなくなり、AIが吐くUIの品質を監視し、違反パターンをルールに反映する保守業務が中心になります。
1年半経った頃、新卒3年目のジュニアメンバーが退職します。面談でこう言われました。「もう少し自分の判断が残る会社に行きたいんです」。W氏はそれを止める言葉を持っていませんでした。
2年後、社内でデザイナーを名乗る人はコミュニケーションデザイン部門の数名だけ。プロダクト側の「デザイン」はPMとエンジニアとエージェントの三者で回っていて、品質が下がったという証拠はなく、売上に直結している証拠もありません。
W氏はふと、自分のキャリアを振り返ります。「自分が時間をかけて蓄えてきた業務ドメインの理解は、本当は誰の役に立てるはずだったのだろうか」。
これが、起きうる未来の一つです。
シナリオB：デザイナーが本質的な仕事に寄っていく場合
同じ会社、同じW氏、同じ出発点。ただ、分岐する最初のイベントがほんの少し違います。
年明けの四半期レビューで同じ問題提起が経営から上がったとき、W氏のチームは先回りで「AI前提のデザイナーの仕事の置き直し」という提案を出していました。提案書はスライド3枚。
1枚目は本質論です。AIが肩代わりできるのは「表層の翻訳」までで、ドメインとユーザーのメンタルモデルを読み解いて構造化する部分は、プロダクトの当たり前品質を支える人間の領域として残し、ここを誰も握らないと表層だけ整って中身が噛み合わない使いにくさが後から効いてくる、と いう主張。
2枚目は、それを踏まえたデザイナーの仕事の重心の置き直しです。これまでの「画面を組み立てる」中心の働きから、「ユーザーとドメインのメンタルモデルを読み解いて情報設計に落とす」中心の働きに、重心を移していく。AIに任せる範囲が増えるぶん、人が時間を使う場所も明確に変える。
3枚目は、その重心移動を組織として機能させるための周辺整備です。デザインシステムを「AIが正しく参照できるユビキタス言語」に育てる作業と、AIに任せる範囲・人が握る範囲をハーネスで線引きする運用（デザインOps）。この支援機能があって初めて、メンタルモデル構造化の仕事が組織の規模で回ります。初期ROIはデザイン関連の手戻り削減と、差別化につながる品質改善で十分回収できる試算。
PMと事業責任者が腹落ちし、提案はそのまま採用されました。W氏は「メンタルモデル構造化と情報設計」をリードする役割を担うことになります。デザインOpsは、その働きを下支えする組織機能として並走する位置づけです。
半年後、W氏の仕事の中身はだいぶ変わっています。ある日の午前は、ユーザーへの定期インタビューで聞いた業務の流れを、PMやエンジニアと一緒に構造として言語化する。「この担当者は月末の3日間、こういう順序で4つのタスクを切り替えながら進めている」という業務メンタルモデルを、画面にする前にまず言葉とフロー図で固めておく。午後は、その語彙とデザインシステムの命名規則を突き合わせ、AIが参照する際にユーザーの業務の語彙でコンポーネントを検索できるよう書き換えていく。並行してクレジット消費ダッシュボードにも目を通し、人が 決めるべき領域とAIに任せて良い領域の線引きをハーネスのルールに反映していく。Figmaを開いた時間は1時間もありません。
W氏自身、最初は「自分の仕事が減った気がする」と違和感を持ちましたが、3ヶ月もすると「こっちのほうが影響範囲が広い」と実感が追いついてきます。1枚の画面の質を上げる仕事だったものが、ユーザーの頭の中の構造そのものを定義し、それが社内の共通言語になっていく仕事に変わったわけです。
1年後、プロダクト戦略会議の常連メンバーになっています。きっかけは、ある新機能の設計会議でした。新しいユーザー導入フローの設計で、W氏は10名の新規ユーザーへの観察とインタビューから「初週にユーザーが作るメンタルモデル」をフロー図と語彙集の形でチームに提示します。そのうえで「ここは絶対にAIに任せず、人間が握るべきです」と提案。根拠として、初回のユーザー体験はユーザーの業務メンタルモデルの形成に直結する局面で、ユーザー理解とメンタルモデルを反映した情報設計をしなければ、以降の業務全体でユーザーの頭の中の構造と画面のズレが積み重なっていく。AIは現状、ドメインやユーザーのメンタルモデルを読み取って構造化する部分には踏み込めない。だからこそ、ここは人間が握らないと、表層だけ整って中身が噛み合わない使いにくさが広がってしまう。
決定から3ヶ月後、そのフローは実際に離脱率を下げました。W氏が作った業務メンタルモデルの図と語彙集は、PMやエンジニアの仕様議論の共通言語として使われるようになります。以降、「どの機能をAIに任せ、どれを人間で握るか」という判断が、プロダクトの差別化と直 結するという認識が社内に定着していきます。
同じ頃、ジュニアメンバーがW氏に相談してきました。「自分は将来、何をやっている人になるんでしょうか」。W氏はこう答えました。「表層を作る作業者としての自分はどんどん縮む。でも、そこが縮むからこそ、ユーザーやドメインのメンタルモデルを読み取って構造化する時間にちゃんと投資できるようになる。そこが本来のデザイナーの仕事の中心だったわけで、むしろ本質的な仕事に集中できるようになっていく。その分、要求される難易度も高くなっていく」。
半年後、そのメンバーは社内の機械学習チームと組み、エージェントハーネスのプロンプト改善を主導しながら、ユーザーインタビューにも深く関わる役割に就きます。
2年後、デザイン組織は縮んでおらず、むしろ「プロダクトデザイン」「デザインシステム／Ops」という部門の粒度がより明確になり、合計人数もゆるやかに増えています。かつて「デザイナー不要論」が出ていた会社で、デザイナーの戦略的重要性がむしろ上がっている、という景色です。
W氏はふと、今度はこう思います。「作業者でいた頃より、今のほうがちゃんとユーザーと向き合ってデザインをしている気がする」。
これもまた、起きうる未来の一つでしょう。
二つのシナリオの分岐点と共通点
二つのシナリオは、同じ技術トレンド、同じ会社、同じ人を前提にしても、組織と個人の受け止め方次第で違う方向に伸びていきます。分岐点になりうる要因を整理すると、次のあたりに見えてきます。
シナリオAではデザイナーが「今の作業の守り」に入り、シナリオBでは「本 質への時間の再投資」に先回りした
シナリオAでは組織がAI導入を「人件費最適化」の文脈で解釈し、シナリオBでは「ドメインとメンタルモデルの構造化に人の時間を再配分する」文脈で解釈した
シナリオAではデザイナー不要論が経営の語彙に吸収され、シナリオBでは「AI前提のデザインの本質とは何か」が経営の語彙に吸収された
シナリオAではクレジット管理の責任者が曖昧なまま消費だけが膨らみ、シナリオBではデザインOpsがその責任を引き受けた
一方で、両方のシナリオに共通しているのは次の点です。
FigmaでUIを手で組み直す比率はどちらでも目に見えて減る
AIクレジットはどちらでも経営マターに昇格する
デザインシステムの厳密さは今まで以上に問われる
人間としての判断・設計・ディレクション・ファシリテーションの力が前面に出る
AIが表層を引き受けた結果、メンタルモデルを構造化する営みがより前面に出てくる
つまり、起きる変化の輪郭はほぼ共通していて、違うのはそこでデザイナーと組織がどう動くかだけです。「FigmaでUIを組む作業を最後まで死守する」という発想は、どちらのシナリオでも割に合わなくなります。動くとしたら、その手前の「ドメインとユーザーのメンタルモデルをどう構造化し、AIに何をどこまで翻訳させ、どこを人が握るか」という設計レイヤーに前倒しするしかない、というのが両シナリオから読み取れる示唆です。
以前ドメイン理解のないデザイナーの末路という記事で、業務ド メインの知識を軽視したデザインがどういう帰結をたどるかについて書きました。シナリオAで描いたW氏の2年後は、それを組織レベルで加速させたバージョンに近いと思います。個人レベルでも厳しい話ですが、AIが表層の生成速度を引き上げるぶん、ドメイン理解の欠落は前より早く表面化してしまいます。
先日、AIで速く作るほど遅くなる、手戻りを生む変換コストを潰すための基盤整備という主旨の記事が公式noteで公開されていました。そこで語られている「AIが機能するための前提を整備する仕事」は、シナリオBのW氏がやっていたことと重なるところがありそうです。国内でも、このレイヤーに重心を寄せ始めている組織が既に出てきている証左かもしれません。
国内B2B SaaS大手のなかには、2026年内にClaude Agent SDK基盤のAIサービスを提供開始すると発表している例も出ています。エージェントSDK上で自社プロダクトが組み上がっていく以上、デザイン組織もその基盤の上で動く前提に組み替わっていくのは自然な流れだと思います。
自分の組織は、今どちらの軌道に向かっているのか
抽象論だけだと自分の組織の現在地がつかみづらいので、二つのシナリオの分岐に寄与する小さな兆候を考えてみます。全部が揃っている必要はありません。シナリオB寄りのサインが一つでもあれば、軌道修正の余地はかなりあるはずです。
クレジット消費の責任者が社内で誰なのか、明示的に答えられる人がいる
組織設計や予算配分の議論に、デザインのリードが呼ばれている
「AI前提のデザイン」を自社の事業文脈で、経営に説明し直せる人が社内にいる
直近3ヶ月で、デザイナーがFigmaを開いている時間より、ユーザーやドメインのメンタルモデルを読み解いている時間のほうが伸びている
「ユーザーの業務の頭の中」を構造として説明できる共通言語が、デザイナーとPMとエンジニアの間で通じている
ジュニアデザイナーのキャリア相談に、AI時代の役割像を自分の言葉で返せている
逆に、どれも曖昧だと感じるのであれば、シナリオA寄りの初期条件にかなり近い可能性があります。組織がまだ静かだからといって安心できる状況ではなく、むしろ「誰も構造変化を言語化していない」こと自体が兆候だと考えるほうが自然です。
ただし、これは一つの見通しでしかない
ここまで書いてきた内容は、あくまで現時点の推論です。AIツールの進化速度は速く、今想定している制約（クレジットの希少性、ハーネス設計の難しさ）が数ヶ月先にどうなっているかは分かりません。AIビジネスがコモディティとなり料金が今の数分の一になれば「クレジット経済」という言い方自体が古びる可能性もありますし、逆にもっと厳しくなるかもしれません。
あるいは、シナリオAの発展系として、「プロダクトデザイン」を含めた開発の営みや役割の全てがSKILLで表現され、人間は目的に応じて「判断・設計・ディレクション・ファシリテーション」する役割としての「開発者」という肩書きだけが残る世界観が本当に到来すれば、そもそも「デザイナー」や「デ ザイン組織」という分類やラベリングは本当に不要になるでしょう。そして、それはデザイナーだけの話ではなくなっているはずです。
ただ、どちらのシナリオに転んでも、「どの工程を人が決定し、どこを仕組みに任せるか」というフロー効率や責任の所在の重要性は変わらないはずです。そしてその判断の土台になる「ユーザーやドメインのメンタルモデルを構造化し、相応しい形に適用する」というプロセスも、表出手段がどう変わっても残り続けるはずです。Figma公式ブログがAI時代に磨くべきデザインスキルとして挙げている「taste」「judgment」「systems thinking」「product strategy」という整理は、シナリオBで描いたW氏の姿や、この記事で何度か言い直してきた本質論と、だいたい重なります。
参考：5 Design Skills To Sharpen in the AI Era（Figma Blog）
プロダクトデザインの本質は、ユーザーが人間であり続ける限り、時代が変わっても変わらないでしょう。変わるのは表出の手段と、本質に時間を使うための条件のほうです。AI時代のデザイナーの仕事は、縮むというよりは、むしろ本来の中心に戻っていく変化なのかもしれません。
悲観と楽観を分ける最後の要因は、おそらく技術でも経営判断でもなく、デザイナー自身がこの本質回帰に主体的に向き合おうとするかどうかという点です。まだ誰も正解を持っていないからこそ、自分ごととしてデザイナーが自ら取り組む価値はあるのではないでしょうか。
今日から動くとしたら
最後に、少しだけ実務寄りの話を書いておきます。大掛かりな提案である必要 はなくて、次の3つくらいから始められると思います。
1つ目は、自分が担当しているプロダクトのユーザーが、どんなメンタルモデルで業務を遂行しているかを、3人以上から聞き直してみること。画面を見せてもらいながら「なぜこの順でやるのか」を聞くだけでも、自分の頭の中のドメインモデルの解像度はじわじわ上がります。AIが画面を作れる時代こそ、この足元の時間が効いてきます。
2つ目は、デザインシステムの記述を「AIが参照する前提」で読み直し、曖昧な箇所を一つでも厳密化してみること。コンポーネントの命名規則、状態の定義、Do/Don'tの組み合わせのルール。こうした部分を具体化するだけで、AIが生成したUIの妥当性を後から説明しやすくなりますし、デザインシステム自体がドメインのユビキタス言語に近づいていきます。
3つ目は、「AI前提のデザインの本質」を1分で説明できる自分の言葉として持っておくこと。「AIは表層の翻訳までを引き受けて、ドメインとユーザーのメンタルモデルの構造化はデザイナーが持つ領域。だからAI時代こそ、デザイナーはドメインとユーザーの理解に時間を使う側に戻っていく」という趣旨を、自分の会社の言葉で書き下しておくイメージです。シナリオAでW氏が「会議で言葉に詰まった」場面は、この足場を事前に作っていなかったことの帰結だと見ると、地味ですが効く投資だと思います。
どれも完全解ではありませんが、今日の自分と3ヶ月後の自分の景色を少し変えるには、このくらいの小さな踏み出しが現実的ではないでしょうか。
