デザイナーは翻訳者ではなくなるのか
Algomatic のデザイナーは、AI 時代において Figma などのツールが「伝える手段」から「目的化」する現状を批判し、実装後のプロダクトこそが真のマスターとなるべきだと主張している。
キーポイント
デザインツールの目的と手段の逆転
Figma は伝えるための手段であるべきだが、現場では成果物（Figma）の精度維持自体が目的化し、実装されたプロダクトとの二重管理が発生している。
AI による役割変容への懸念
記事タイトルが示す通り、AI の発展によりデザイナーが単なる「翻訳者（仕様書からデザインへ）」としての役割を失う可能性や、その先にある新しい役割の必要性が示唆されている。
コンポーネント設計への過度な執着
トークン設計や Slot 機能など、ツール内の構造化に熱狂する風潮に対し、実装との整合性よりもツール内での完璧さを求める姿勢への警鐘を鳴らしている。
デザインツールの進化は伝達コストの削減
IllustratorからFigmaへの進化は、実装方法や状態変化まで含め、より少ないコミュニケーションコストで正確に伝えるための歴史であった。
デザイナーの役割は「翻訳」だった
実際に動くものを確認できない環境下で、エンジニアが実装可能な形へ頭の中の設計を変換する作業こそが、デザイナーの主な役割（翻訳）であった。
AIによる翻訳コストの低下
AIは曖昧な入力から意図を汲み取り動くものを生成するため、詳細な仕様書やプロトタイプを作成して伝える「翻訳コスト」が実装コスト以上に劇的に低下する。
デザイン QA の自動化と役割変化
AI の登場により、デザイナーが自らプロダクションコードを修正できるようになり、Figma を介した詳細な修正指示（翻訳）の必要性が消失しました。
影響分析・編集コメントを表示
影響分析
この記事は、生成 AI の普及が進む中でデザイン業務のあり方が根本から問われるべき時期に来ていることを示唆しています。デザイナーがツール操作や詳細な仕様書作成に時間を割くのではなく、AI を活用して本質的な価値伝達とプロダクト推進に注力するパラダイムシフトを促す重要な提言です。
編集コメント
AI ツールの進化がデザイナーの役割を「実装前の仕様作成」から「プロダクト全体の最適化」へとシフトさせる必然性を、現場の違和感を通じて鋭く指摘した記事です。
はじめまして。Algomatic でプロダクトデザイン/デザインリードをしているbuchiです。
Tech blog に書くのはハードルがめちゃめちゃ高くて怯えているのですが、デザイナー視点で昨今の開発におけるデザインやデザインツールのあり方について、自身が思っていることを書いてみます。
この記事は Algomatic 初夏のアドベントカレンダー 21 日目です。前回は ぴやてぃさんの「AI 開発時代の多層防御を設計する〜AWS アクセスキーにまつわる怖い話〜 - Algomatic Tech Blog」でした。
はじめに
私はプロダクト開発に関わる中で、ずっと同じことを言ってきました。
「Figma はあくまでも伝えるための手段であり、目的は伝えることだ」と言うこと。
UI デザインも仕様も、伝えたい相手にちゃんと伝わりさえすればいい。受け取る立場に立ち、欲しい情報を欲しい粒度で渡す。Web デザインやプロダクトデザインの成果物は、それそのものに価値があるわけではなく、何かを前に進めるための手段でしかないからです。
それなのに、現場では成果物（Figma）の精度そのものが目的になりがちです。なかでも、実装されたプロダクトを追いかけて、Figma の中に実物と同じ状態を作り、それを維持し続ける作業です。実装で余白が変われば Figma にも反映し、コンポーネントが増えれば Figma にも足し、修正のたびに両方を直していく。実装された時点で、本当のマスターはプロダクトに移っているはずなのに、それとほとんど同じ複製を別の場所に作って保管し続ける違和感。
他にも、Figma 内のコンポーネント設計やトークン設計にこだわり出したり、全てをコンポーネントで扱うがために Slot（スロット）なんてテクニックも登場し、そこに熱狂するデザイナーたちも少なくありませんでした。かくいう私もその一人だったのですが。
ただし、それでもこれまでは、Figma でデザインデータを作り込む理由が 2 つありました。
伝えるために進化したデザインツール
1 つ目は、より正確に伝えるためです。
デザインツールの歴史をたどると、Illustrator（ベクター描画ツール）、Photoshop（写真編集ツール）で Web デザインをしていました。これらのツールはそもそも Web デザインツールではないので、「どんなものを作ろうとしているか？」をクライアントやディレクターに伝えることは出来ても、エンジニアに「どう実装するか？」「どう動くか（動かすか）？」を伝えることは出来ませんでした。
そこから、Prott や ProtoPie などのプロトタイプツールの登場により、「どう動くか（動かすか）？」をより伝えやすくなりました。
その後、Sketch や XD、Figma などの UI デザインツールが登場しました。中でも Figma は、AutoLayout や Components、Variants など、実装により近づけるという設計思想を持っていたために、「どう実装するか？」「どう状態変化するか？」までをデザインツール上でエンジニアに伝えやすくなりました。
つまりデザインツールの歴史は、より少ないコミュニケーションコストで、より正確に伝えるための歴史だったと考えています。
越えられなかった実装コスト
2 つ目は、実装コストの高さです。
どれだけ精巧なデザインカンプや仕様書を作っても、実際に動くものを確認するにはエンジニアの協力が必要不可欠でした。だからデザイナーは、デザインツールの中で思考しました。
余白を調整し、色を変え、様々なパターンのレイアウトを試す。コンポーネントを整理し、状態変化を書き出す。動く実物に触れない代わりに、Figma の中で考えられる極限まで試行錯誤をしていました。
実装後の認識齟齬を減らすため、Figma の中に多くの情報を詰め込みました。Figma はいつしか単なるデザインツールではなく、設計図・仕様書・プロトタイプ・実装の参照元（マスター）を兼ねる存在になっていったように思います。
正確に伝えるため、そして動かして確かめられない分を補うため。この 2 つの理由が、Figma を大きく作り込ませていました。
デザイナーがやっていたことの多くは翻訳でした。頭の中にある設計を、エンジニアが実装できる形へと変換する。Figma はそのための翻訳ツールでした。
AI によって変わったのは実装コスト以上に翻訳コストかもしれない
AI によってまず変わったのは実装コストです。ラフな UI やざっくりした意図を渡すだけで、ものの数分から数十分で動くものが出てくるようになりました。
しかし、実際に現場で感じているのは、それ以上に翻訳コストの変化です。以前は、「こういうプロダクト（画面）を作りたい」を伝えるために、多くの成果物が必要でした。画面を作り込み、状態を書き出し、補足を書き、仕様を整理していました。
AI は、曖昧な入力でもかなりの精度で意図を汲み取ってくれます。また、AI による能力拡張によって一人が担える領域の幅も広がりました。それにより、そもそも次のプロセスを担う人へ伝えること自体が減りました。
意図を相手に伝わる形へ変換するための翻訳コストが減ったのです。
実際の現場で起きたこと
デザイン QA
最近は、フロントエンドに関してのみ、自身でプロダクションコードを触って修正しています。
これまでは、Figma にデザイン QA というページを作り、スクリーンショットとデザインカンプを左右に並べ、一つひとつ丁寧な修正指示をエンジニアに伝えていました。それが、AI の登場によって、自分で直せてしまうようになり、そもそも修正指示を伝える必要がなくなりました。翻訳すべき相手が消えたのです。
Web サイト制作
Claude Code を使って、自社のコーポレートサイトを一人で作りました。（色々あり、まだ公開できてないのが悔しいです…）
以前なら画面単位で Figma を作り込んでいましたが、今回最初に作ったのは、大枠のトンマナを決めるための一画面だけです。サイト全体のトンマナさえ決めれば、あとは Claude Code にぶん投げてスタートです。
一発で綺麗にはできませんから、そこから先はセクションごとに必要な要素やパーツだけを Figma でサクッと作り、その都度 AI に渡してブラウザ上で細かく作り込みました。AI に対して「ここはざっくりこう見せたい」が伝わればよく、Figma 上での作り込みは必要ありません。言葉で伝えるほうが速ければプロンプトを書き、絵で見せたほうが速ければ、その一部分だけを Figma に描いて渡します。（個人的には、昔コーダーをやっていたことから、ブラウザ上で試行錯誤していたコーダー時代を思い出したりもしました笑）
渡す成果物の作り込みが要らなくなりました。
チームでのプロダクト開発
現在、実験的にプロダクト（プロトタイプ）上での要件定義・仕様詳細化を試しています。
具体的には、大枠の体験設計・情報設計をして Figma にざっくりの UI を作りつつ、その時点から AI を使って 1〜2日でフロントエンドを実装。開発チームやユーザーにも実際に触ってもらい、フィードバックを集める、という進め方です。実際にユーザーが触って試せるプロダクトが出来上がるまでには、プロジェクト立ち上げから 1〜2週間程度でした。
業務システムで重要なのは、ユーザーが業務をスムーズに行えるかどうかです。入力のしやすさ、状況の把握のしやすさ、状態が切り替わるときの挙動。こうした部分は、静止画の Figma ではよく分かりません。
この進め方にしてから、認識のズレや抜け漏れに、以前より格段に早く気づけるようになりました。そして何より、チームやユーザーに伝える媒体が、Figma の成果物（絵）から実物そのものへと変化しました。絵や仕様書で説明するより、触れる実物のほうが、ずっと正確に多くのことを伝えてくれます。Figma を使って翻訳する必要性が低くなりました。
「翻訳」することは必要なくなるのか
この記事を書いている途中に、Config の発表がありました。実はこの発表を受けて、記事の大半を書き換えています笑
新機能はどれも楽しみですが、中でも Code layers が興味深いです。
Figma 上でコードを扱い、より実物に近い形で試行錯誤ができるようになるとのこと。これまでは、どこまで行っても「絵」でしかなかった Figma が、より「実物」に近づいてきました。Figma 自身も、「実物を絵に翻訳して伝えるツール」から、「実物そのものを扱うツール」へと進化しようとしていると感じます。
では、デザイナーの仕事から「翻訳」はなくなるのでしょうか。
翻訳に追われて見失っていた、本当に伝えるべき相手
なくなっていくのは、中間に存在した制作における翻訳作業だけです。
作り込み、仕様化、ハンドオフ。意図を次の作業者へ伝わる形へ変換する、これらの手間のことです。デザインツールの歴史は、その翻訳コストを下げ続けてきた歴史でした。AI によって、作ることと伝えることの境界は更に融けていきます。
私はずっと「目的は伝えることだ」と言ってきました。でも今なら、こう付け足します。
本当に伝えるべき相手は、エンジニアや PdM ではなく、その先にいるユーザーである。
デザイナーはようやく本来向き合うべき相手へ、まっすぐに向き合えるようになるのだと思います。
エンジニアだけでなく、デザイナーも募集しています
Algomatic では、変化の速い領域でも 学びや試行錯誤を続けられる デザイナーを募集しています。
弊社には、まだデザイン組織も文化もありません。これから一緒に一から作り上げていく気概を持った方、お待ちしています！
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
原文を表示
はじめまして。Algomaticでプロダクトデザイン/デザインリードをしているbuchiです。
Tech blogに書くのはハードルがめちゃめちゃ高くて怯えているのですが、デザイナー視点で昨今の開発におけるデザインやデザインツールのあり方について、自身が思っていることを書いてみます。
この記事は Algomatic 初夏のアドベントカレンダー 21日目です。前回は ぴやてぃさんの「AI開発時代の多層防御を設計する〜AWSアクセスキーにまつわる怖い話〜 - Algomatic Tech Blog」でした。
はじめに
私はプロダクト開発に関わる中で、ずっと同じことを言ってきました。
「Figmaはあくまでも伝えるための手段であり、目的は伝えることだ」と言うこと。
UIデザインも仕様も、伝えたい相手にちゃんと伝わりさえすればいい。受け取る立場に立ち、欲しい情報を欲しい粒度で渡す。Webデザインやプロダクトデザインの成果物は、それそのものに価値があるわけではなく、何かを前に進めるための手段でしかないからです。
それなのに、現場では成果物（Figma）の精度そのものが目的になりがちです。なかでも、実装されたプロダクトを追いかけて、Figmaの中に実物と同じ状態を作り、それを維持し続ける作業です。実装で余白が変わればFigmaにも反映し、コンポーネントが増えればFigmaにも足し、修正のたびに両方を直していく。実装された時点で、本当のマスターはプロダクトに移っているはずなのに、それとほとんど同じ複製を別の場所に作って保管し続ける違和感。
他にも、Figma内のコンポーネント設計やトークン設計にこだわり出したり、全てをコンポーネントで扱うがためにSlotなんてテクニックも登場し、そこに熱狂するデザイナーたちも少なくありませんでした。かくいう私もその一人だったのですが。
ただし、それでもこれまでは、Figmaでデザインデータを作り込む理由が2つありました。
伝えるために進化したデザインツール
1つ目は、より正確に伝えるためです。
デザインツールの歴史をたどると、Illustrator（ベクター描画ツール）、Photoshop（写真編集ツール）でWebデザインをしていました。これらのツールはそもそもWebデザインツールではないので、「どんなものを作ろうとしているか？」をクライアントやディレクターに伝えることは出来ても、エンジニアに「どう実装するか？」「どう動くか（動かすか）？」を伝えることは出来ませんでした。
そこから、ProttやProtoPieなどのプロトタイプツールの登場により、「どう動くか（動かすか）？」をより伝えやすくなりました。
その後、SketchやXD、FigmaなどのUIデザインツールが登場しました。中でもFigmaは、AutoLayoutやComponents、Variantsなど、実装により近づけるという設計思想を持っていたために、「どう実装するか？」「どう状態変化するか？」までをデザインツール上でエンジニアに伝えやすくなりました。
つまりデザインツールの歴史は、より少ないコミュニケーションコストで、より正確に伝えるための歴史だったと考えています。
越えられなかった実装コスト
2つ目は、実装コストの高さです。
どれだけ精巧なデザインカンプや仕様書を作っても、実際に動くものを確認するにはエンジニアの協力が必要不可欠でした。だからデザイナーは、デザインツールの中で思考しました。
余白を調整し、色を変え、様々なパターンのレイアウトを試す。コンポーネントを整理し、状態変化を書き出す。動く実物に触れない代わりに、Figmaの中で考えられる極限まで試行錯誤をしていました。
実装後の認識齟齬を減らすため、Figmaの中に多くの情報を詰め込みました。Figmaはいつしか単なるデザインツールではなく、設計図・仕様書・プロトタイプ・実装の参照元（マスター）を兼ねる存在になっていったように思います。
正確に伝えるため、そして動かして確かめられない分を補うため。この2つの理由が、Figmaを大きく作り込ませていました。
デザイナーがやっていたことの多くは翻訳でした。頭の中にある設計を、エンジニアが実装できる形へと変換する。Figmaはそのための翻訳ツールでした。
AIによって変わったのは実装コスト以上に翻訳コストかもしれない
AIによってまず変わったのは実装コストです。ラフなUIやざっくりした意図を渡すだけで、ものの数分から数十分で動くものが出てくるようになりました。
しかし、実際に現場で感じているのは、それ以上に翻訳コストの変化です。以前は、「こういうプロダクト（画面）を作りたい」を伝えるために、多くの成果物が必要でした。画面を作り込み、状態を書き出し、補足を書き、仕様を整理していました。
AIは、曖昧な入力でもかなりの精度で意図を汲み取ってくれます。また、AIによる能力拡張によって一人が担える領域の幅も広がりました。それにより、そもそも次のプロセスを担う人へ伝えること自体が減りました。
意図を相手に伝わる形へ変換するための翻訳コストが減ったのです。
実際の現場で起きたこと
デザインQA
最近は、フロントエンドに関してのみ、自身でプロダクションコードを触って修正しています。
これまでは、FigmaにデザインQAというページを作り、スクリーンショットとデザインカンプを左右に並べ、一つひとつ丁寧な修正指示をエンジニアに伝えていました。それが、AIの登場によって、自分で直せてしまうようになり、そもそも修正指示を伝える必要がなくなりました。翻訳すべき相手が消えたのです。
Webサイト制作
Claude Codeを使って、自社のコーポレートサイトを一人で作りました。（色々あり、まだ公開できてないのが悔しいです…）
以前なら画面単位でFigmaを作り込んでいましたが、今回最初に作ったのは、大枠のトンマナを決めるための一画面だけです。サイト全体のトンマナさえ決めれば、あとはClaude Codeにぶん投げてスタートです。
一発で綺麗にはできませんから、そこから先はセクションごとに必要な要素やパーツだけをFigmaでサクッと作り、その都度AIに渡してブラウザ上で細かく作り込みました。AIに対して「ここはざっくりこう見せたい」が伝わればよく、Figma上での作り込みは必要ありません。言葉で伝えるほうが速ければプロンプトを書き、絵で見せたほうが速ければ、その一部分だけをFigmaに描いて渡します。（個人的には、昔コーダーをやっていたことから、ブラウザ上で試行錯誤していたコーダー時代を思い出したりもしました笑）
渡す成果物の作り込みが要らなくなりました。
チームでのプロダクト開発
現在、実験的にプロダクト（プロトタイプ）上での要件定義・仕様詳細化を試しています。
具体的には、大枠の体験設計・情報設計をしてFigmaにざっくりのUIを作りつつ、その時点からAIを使って1〜2日でフロントエンドを実装。開発チームやユーザーにも実際に触ってもらい、フィードバックを集める、という進め方です。実際にユーザーが触って試せるプロダクトが出来上がるまでには、プロジェクト立ち上げから1〜2週間程度でした。
業務システムで重要なのは、ユーザーが業務をスムーズに行えるかどうかです。入力のしやすさ、状況の把握のしやすさ、状態が切り替わるときの挙動。こうした部分は、静止画のFigmaではよく分かりません。
この進め方にしてから、認識のズレや抜け漏れに、以前より格段に早く気づけるようになりました。そして何より、チームやユーザーに伝える媒体が、Figmaの成果物（絵）から実物そのものへと変化しました。絵や仕様書で説明するより、触れる実物のほうが、ずっと正確に多くのことを伝えてくれます。Figmaを使って翻訳する必要性が低くなりました。
「翻訳」することは必要なくなるのか
この記事を書いている途中に、Configの発表がありました。実はこの発表を受けて、記事の大半を書き換えています笑
新機能はどれも楽しみですが、中でもCode layersが興味深いです。
Figma上でコードを扱い、より実物に近い形で試行錯誤ができるようになるとのこと。これまでは、どこまで行っても「絵」でしかなかったFigmaが、より「実物」に近づいてきました。Figma自身も、「実物を絵に翻訳して伝えるツール」から、「実物そのものを扱うツール」へと進化しようとしていると感じます。
では、デザイナーの仕事から「翻訳」はなくなるのでしょうか。
翻訳に追われて見失っていた、本当に伝えるべき相手
なくなっていくのは、中間に存在した制作における翻訳作業だけです。
作り込み、仕様化、ハンドオフ。意図を次の作業者へ伝わる形へ変換する、これらの手間のことです。デザインツールの歴史は、その翻訳コストを下げ続けてきた歴史でした。AIによって、作ることと伝えることの境界は更に融けていきます。
私はずっと「目的は伝えることだ」と言ってきました。でも今なら、こう付け足します。
本当に伝えるべき相手は、エンジニアやPdMではなく、その先にいるユーザーである。
デザイナーはようやく本来向き合うべき相手へ、まっすぐに向き合えるようになるのだと思います。
エンジニアだけでなく、デザイナーも募集しています
Algomatic では、変化の速い領域でも 学びや試行錯誤を続けられるデザイナーを募集しています。
弊社には、まだデザイン組織も文化もありません。これから一緒に一から作り上げていく気概を持った方、お待ちしています！
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み