- 「デザイン」の中にある二種類の仕事
- デザインがアセット制作になった理由
- AIが実際に自動化しているもの
- 自動化されない部分:意図
- 30年前からわかっていた。足りなかったのは基盤だけ
- 二層の基盤
- スピードだけでなく、品質の問題でもある理由
- 実践ではどうなるか
- 参考資料
デザインの仕事は昔から、一つの肩書きの下にある二つの仕事でした。何を、なぜ作るのかを決めること。そして、その決定を体現する成果物を生み出すことです。私のキャリアの大半において、労力も、ツールも、「デザイナー」という職業的アイデンティティも、後者、つまり画面やコンポーネント、磨き上げられたFigmaファイルに集中してきました。良い画面を作ること自体が難しく、時間のかかる作業だった頃には、それも理にかなっていました。
もう、そうではありません。
AIによって、決定の実行は取るに足らない作業になりました。つまり、この職業の重心は、AIがまだ手を出せない半分、すなわち意思決定へと移る必要があります。本稿は、その移行が実際にどのような姿になるのかを論じるものです。「戦略に集中しよう」という漠然とした呼びかけではありません。デザインの意図を捉え、構造化された再利用可能なコンテキストに変える基盤を構築し、アセットの生成はパイプラインの最後にある、簡単で自動化可能なステップへと格下げする。その具体的な主張です。
「デザイン」の中にある二種類の仕事
どんなデザインタスクも二つに分けることができ、その分け方は驚くほどさまざまな状況で通用します。
- 決定:この画面は何をすべきか、誰のためか、なぜ他の選択肢ではなくこのアプローチなのか。そして
- その決定の実行:ユーザーや開発者が実際に目にできる成果物に落とし込むこと。デザイン教育も、ポートフォリオも、ツールも、これまでは目に見える側の半分を評価してきました。磨き上げられたFigmaファイルは見栄えがしますが、よく考え抜かれたトレードオフはそうではありません。私は以前、ビジュアルの完成度を重視しすぎて全体的な思考がおろそかになるリスクについて、これに近い主張をしたことがあります。UI/UXデザインとして通用しているものの多くは、実は「Figmaオペレーション」、つまり本来その画面を生み出すべきだった思考を伴わずに、洗練された画面を手際よく量産することにすぎない、というものです。ここでの論点はもっと狭く、もっと機械的なものです。その思考がある場合でさえ、私たちのツールも、成果物も、どこに労力を注ぐべきかという感覚も、成果物を作ること自体がボトルネックだった世界に合わせて調整されてきました。その世界は終わりつつあり、調整もそれに合わせて変わる必要があります。
デザインがアセット制作になった理由
アセットファーストという既定路線は間違いではなく、現実の制約に対する合理的な対応でした。説得力のある画面を作るには、かつては相応の時間と技術が必要でした。だから当然、デザイナーの目に見えるアウトプットの大半、そしてレビューされ、批評され、リリースされるものの大半は、画面そのものだったのです。
実行の側ですでにどれほどの変化が起きているかについては、以前にも書きました。LingoBunを開発したとき、私は紙ナプキンのスケッチからユーザーテストができる動くプロトタイプまでを1日で作り上げました。かつてのFigma、ハンドオフ、実装というパイプラインでは数週間かかっていたはずのことです。モダンなフレームワーク、成熟したコンポーネントライブラリ、そしてAI支援開発によって、逐次的なプロセスはリアルタイムに近いものへと圧縮されました。この圧縮こそが、この主張が10年前ではなくいま重要である理由のすべてです。成果物を作るのにコストがかかった時代には、成果物に注意を向けるのは合理的でした。作るのが安価になったいま、そこに注意を向け続けるのは、もはや当てはまらないコスト構造から持ち越された習慣にすぎません。
AIが実際に自動化しているもの
何が安くなったのかを正確に捉えておく価値があります。「AIでデザインが速くなる」という言い方では、過小評価になるからです。具体的に崩れたのは決定の実行、つまり、すでに下された決定をピクセルやコンポーネント、インタラクションの状態に変換する作業です。Figma Make、Google Stitch、Uizardのようなツールは、プロンプトから一連の画面をまるごと生成できますし、最先端のコーディングエージェントは、言葉で説明したインタラクションを、数分でスタイルの整った動くUIに変えてくれます。私自身も小さなツールを作っています。画面のYAML記述(どのコンポーネントを使い、どんなpropsを渡し、どうレイアウトするか)を受け取り、画面の絵ではなく、実際のブラウザ上で完全にインタラクティブなReactの画面としてレンダリングする、仕様駆動のデザインサーフェスです。生成の問題は本当に解決されたのだと私に確信させたのは、このツールでの作業のうち、レンダリングの品質に関わるものがいかに少ないかでした。興味深い労力のほとんどは、ボタンをボタンらしく見せることではなく、その周りの土台、つまりスキーマ、キャンバス、仮想化に注がれてきました。十分に明確な仕様さえあれば、生成はいまや、ほぼ解決済みのコモディティな問題です。これはツールをけなしているのではなく、まさにそこが要点です。希少な資源は、最初からピクセルではありませんでした。常に、そのピクセルがどうあるべきかについての決定だったのです。
自動化されない部分:意図
AIがいまだにできないこと、それも一時的な能力の不足ではなく構造的にできないことは、何を、なぜ達成しようとしているのかを決めることです。それには、人が与えない限りAIがアクセスできないコンテキストが必要だからです。企業が受け入れるつもりのあるビジネス上のトレードオフ、特定のユーザーのメンタルモデル、そのチームが実際に置かれている技術的な制約、そして複数の妥当な選択肢のうちどれを取るかという判断です。
実は正しかったのに議論に負けた経験のあるすべてのデザイナーに、私は Tom Greever の Articulating Design Decisions を勧めたいと思います。Greeverは、私よりもはっきりとこう言い切っています。「デザインすることではなく、コミュニケーションこそが仕事だ」。その主張は、成果物が重要でないということではありません。デザインがどんな問題を解決するのか、ユーザーにどう影響するのか、なぜ他の案より優れているのかを説明できないデザイナーは、より劣った決定をより明快に説明できるステークホルダーに負けてしまう、ということです。これはAIが代替できないスキルです。そもそも制作のスキルではなく、判断と説明のスキルであり、判断には照らし合わせるべき意図が必要だからです。
これは、要件とは、より強い確信を伴っただけの仮説にすぎない理由について書いたときに、より一般的な形で示したのと同じ区別です。価値は文書そのものにあったのではなく、それを生み出した思考を、現実に照らして検証することにあります。
AIは文書も画面も、思いのままに作り出せます。しかし、思考を提供することはできません。あなたが本当に何を望み、なぜそれを望むのかは、伝えない限りAIにはわからないからです。そして、それを忠実に、繰り返し伝えることこそが、いまや本当のボトルネックになっているのです。
30年前からわかっていた。足りなかったのは基盤だけ
これはどれも新しい指摘ではなく、そのこと自体がよく考える価値のある事実です。1991年、Allan MacLean、Richard Young、Victoria Bellotti、Thomas Moranは、QOC(Questions, Options, Criteria)という手法を発表しました。目的は*デザイン根拠(デザインラショナール)*を記録することです。デザインが答えるべき問い、検討された選択肢、そしてそれらから選ぶために使われた基準を、構造化された成果物としてデザインそのものと並べて記録します。デザインの根拠はデザインと同じくらい価値がある、というのがその考え方でした。根拠があるからこそ、チームは後になって決定を一から議論し直すことなく、デザインを保守し、発展させ、擁護できるからです。
30年たったいまでも、デザイン根拠の記録はニッチな実践にとどまっています。考え方が間違っていたからではなく、あらゆる決定を手作業で文書化するコストが高く、締め切りに追われるチームが合理的に省略してきたからです。根拠は会議が終わった瞬間から朽ちていき、デザインシステムは、もともとそれを形づくった意図から静かにずれていきました。
変わったのは、根拠を記録することの価値ではありません。その主張は1991年になされ、真剣に異論が唱えられたことはありません。変わったのは、記録するコストです。誰にも時間のない専用の文書化作業を求める代わりに、チームがすでに生み出しているスタンドアップ、AIとの相談、実験のレポートから、パイプラインが構造化された根拠を受動的に引き出せるなら、30年間QOC的な実践を阻んできた反論は、もはや成り立たなくなります。
二層の基盤
具体的には、これは二層のシステムを指し示しています。両方の層に名前をつけておく価値があります。それぞれ別の問題を解決するもので、混同すべきではないからです。
一つ目は静的な土台です。デザインシステム、トークンの一覧、明文化された原則といった、ゆっくりと意図的に変化する、比較的安定した「正解」の層です。この層には、特定の企業のツール選択とは関係なく、すでに確かな勢いがあります。W3CのコミュニティグループであるDesign Tokens Community Groupは、2025年後半に、ベンダーに依存しないデザイントークン形式の最初の安定版をリリースしました。色、余白、タイポグラフィといったデザイン上の決定を、ツールごとに手作業で実装し直すのではなく、構造化されたデータとしてデザインツールとコードの間でやり取りできるようにするためです。それが、標準化された静的な層です。
二つ目は、動き続け、蓄積していく層です。具体的な決定とその根拠を、一度文書化して古びるに任せるのではなく、決定が下されるたびに継続的に記録していきます。これはQOCが目指しながらも、それを安価にする基盤を持たなかった層です。そして偶然ではなく、同じチームのエンジニアリング側ですでに進んでいるのと同じ転換でもあります。GitHubのSpec Kitは、AI支援によるコーディングを、「コードがどう振る舞うべきかの契約」として機能する仕様を中心に組み立て直し、場当たり的なプロンプトの代わりに、仕様→計画→タスク→実装という構造化されたパイプラインにつなげています。デザインとエンジニアリングは、逆の方向から同じ気づきに向かって収束しています。生成が安く速くなったとき、守り、持ち運べるようにする価値があるのは、その出力のどれかではなく、仕様そのものだという気づきです。共有された表現があれば、これは理想論ではなく具体的なものになります。構造化データとして記録されたデザイン(たとえばコンポーネントツリーのJSON記述)とJSXによる実装は、同じ構造を二通りに描き出したものです。つまり「デザインからコードへ」と「コードからデザインへ」は、別々の、情報が失われる二つの引き継ぎではなくなり、同じものを二つの方向から見ることになります。生成、つまり実際のピクセルやコンポーネントとしての出力は、両方の層の下流に、安価で自動化可能な最後のステップとして位置します。まさに、いまのAIデザインツールが動いている場所です。
スピードだけでなく、品質の問題でもある理由
これらすべてを「効率化」に分類したくなりますが、品質の面でも確かな根拠があり、それには二つの側面があります。第一に、生成が安価になれば実験も安価になります。そして良いデザインは、一度で正解にたどり着くことよりも、反復によって生まれることのほうがはるかに多いのです。要件と仮説の文脈で、私は以前にもこう主張しました。自分たちの最善のアイデアを、固定された仕様ではなく検証可能な仮説として扱うチームは、より速く学び、より良いプロダクトを作る。そしてそれが成り立つのは、仮説の検証を頻繁に行えるほど安価な場合だけです。アイデアを検証できる形にするコストをAIが劇的に下げると、時間が節約されるだけではありません。一つのアイデアがリリースされるまでに、実際にいくつのアイデアが検証されるかが変わります。これはスピードだけでなく、品質に直接効くレバーです。第二に、こちらは見落とされやすい点ですが、デザイン上の決定が会議の薄れていく記憶の中にしか存在しないとき、そこから作られた成果物には、忠実であるべき拠り所がありません。成果物はずれていきます。半年後、誰かがなぜそう作られたのかを知らないままフローを調整し、ステークホルダーは、その理由がどこにも書き残されていないために選択を覆します。そしてプロダクトは、一つひとつは妥当な小さな変更を重ねるうちに、それを形づくった意図から少しずつ離れていきます。構造化データとして記録され、それが生み出したアセットの隣に置かれたデザイン上の決定は、後からアセットを照らし合わせることのできる決定です。それは生産性のための機能ではありません。プロダクトが年月を経ても一貫性を保つための仕組みなのです。
実践ではどうなるか
デザイナーにとって、これは職務が「画面を作る人」から「意図を持ち、整える人」へと変わることを意味します。プロダクトがなぜそのような見た目と振る舞いをしているのかを把握し、説明できることに責任を持ち、その意図を成果物に変換する機械的な作業はAIが担います。これは格下げではなく役割の格上げですが、鍛えるべき力がFigmaの熟練だけではなく、言語化と判断であることも意味します。開発チームにとっては、デザインのコンテキストが絵ではなく仕様に近いものとして届くことを意味します。持ち運べて、構造化されていて、照合できるもの。それこそが、デザインからコードへの引き継ぎを伝言ゲームでなくする性質です。そして、その場にいる他のステークホルダー、つまりPMや経営層など、最終的にプロダクトの決定を誰かに説明しなければならない人にとっては、実際に示せる記録が残ることを意味します。Articulating Design Decisions は丸ごと一章を割いて、専門知識を持たない非デザイナーにもデザイン上の判断を覆す権限があるという現実を論じています。「これはこの問題を解決する。私たちはこれを検討した。だからあちらは選ばなかった」と明確に示せないデザイナーは、誰が正しかったかにかかわらず、その議論に自動的に負けてしまうのです。記録された決定の履歴は、その問題への実践的な答えです。「信じてください」を、ステークホルダーが実際に確かめられるものに変えてくれます。そしてこれは、ある程度のデザイン成熟度を持つ企業の多くがすでに始めているAIガバナンスの議論の、妥当な出発点にもなります。自らの判断の根拠を示せるシステムは、示せないシステムよりも統制しやすいからです。
これは、AIが生成するアセットに反対する主張ではありません。むしろ逆で、生成はできる限り自動化されるべきです。AIが忠実に作れる成果物の制作に費やす1時間は、本当に人間を必要とした決定に費やされなかった1時間だからです。この主張は、次に労力と基盤への投資をどこに向けるべきかについてのものです。すでにほぼ解決済みの問題であるアセット制作ツールの改良ではなく、私たちがなぜそれを作っているのかを記録する配管に投資すること。そうすれば、生成という驚くほど安価な行為は、意図から離れていくことなく、意図に結びついたままでいられます。
参考資料
- MacLean, A., Young, R. M., Bellotti, V. M. E., & Moran, T. P. (1991). Questions, Options, and Criteria: Elements of Design Space Analysis. Human–Computer Interaction, 6(3–4), 201–250.
- Design Tokens Community Group — Design Tokens Format Module — ツールに依存しない共通のデザイントークン形式を標準化しているW3Cのコミュニティグループ。最初の安定版は2025年10月。
- GitHub Spec Kit と仕様駆動開発の解説記事 — エンジニアリング側で起きている、仕様を信頼できる唯一の情報源とする同じ転換。
- Greever, T. — Articulating Design Decisions: Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience (2nd ed., O'Reilly, 2020).
- プロトタイピングを容易に — 上で述べた「生成はもう安価だ」という主張の根拠となった、LingoBunのケーススタディ。
- 要件から仮説へ — 安価な実験を品質のレバーとして捉える主張。上で参照しています。