デザインエンジニアとは何か?
デザインエンジニアは「デザインとコードの重なる領域」(designengineer.xyzの引用)で働き、従来の受け渡しを経ずにインターフェースをコードで直接作る。uithingsのデザインエンジニアリング指南によれば、日常業務には、アニメーションやキーボード、タッチ操作をFigmaから作り直すのではなくコードでプロトタイプすること、アニメーションが実装コストに見合うか、コンポーネントを再利用可能にするか一度限りにするかを判断すること、デザインシステムの保守、最初からアクセシビリティを組み込むことが含まれる。
一般的なスキルは、視覚デザイン(余白、書体、色、グリッド)に加え、HTML、CSS、JavaScript、React、Tailwind CSS、Gitだ。この肩書きは「少しコードが書けるデザイナー」と同じではない。本番に出せるコードを作り、その品質に責任を持つことが要点だ。
なぜこの役割が生まれたのか?
従来の流れでは、デザイナーが画面を渡し、エンジニアがそれを実装する。その間のずれが受け渡しの問題だ(「デザインハンドオフ」を参照)。インタラクション、アニメーション、細かな質感は静的なファイルでは伝えにくい。デザインエンジニアはそれをコードで直接作り、翻訳の手間を省く。
AIがこの道を広げた。State of AI Design 2026のCraft章によれば、回答者の50%がAI生成のコードを本番環境に出した経験があるが、自分をデザインエンジニアだと認識しているのは20%にとどまる。つまり、多くの人が肩書きなしにデザインエンジニアリングの仕事をしており、対応するレビューの仕組みがあるとは限らない。
デザインエンジニアは実際どう働くのか?
デザインエンジニアは通常、デザインシステムの両端を行き来する。一方ではデザインとトークンを読み、もう一方ではコンポーネントとページを書く。Figma MCPのようなツールがあれば、Claude Codeがデザインのレイアウトと変数を読んでコンポーネントを生成できるため、仕事はルールの設定と検収に寄っていく。どのコンポーネントを再利用するかを決め、出力がデザインに近いかを確かめる。
本番側で鍵になるのはレビューの関門だ。DoorDashではデザイナーとエンジニアが同じGitHubのPR承認を通り、Fluxは事後にAIリスクスコアでレビューする。これらは各社の自己申告で、レポートに差し戻し率や事故のデータはない。
私にとってどんな意味があるのか?
デザイナーにとって、これは現実にあるキャリアの道だ。uithingsはBuilt Inの2026年の米国データを引いて、平均基本給を約148,301ドル、幅を8.3万〜23.3万ドルとしている。これは二次的な単一の情報源で、実際の報酬は地域や会社で大きく変わる。また、このガイドはdesignengineer.xyzの講座も宣伝しているので、立場のある情報源として読んでほしい。
マネージャーや経営者にとって大切なのは、コードが書けるかどうかだけでなく、先にレビューの関門を決めることだ。デザイナーのPRを誰が承認し、問題が起きたら誰が責任を負うのか。肩書きよりそちらが重要になる。
Vercelのデザインエンジニアリングチーム(2024年3月、uithingsはRauno Freiberg、Jhey Tompkins、Henry Heffernanを挙げる)はよく知られた例だ。DoorDashでは、デザイナーがエンジニアと同じGitHubのPR承認を通り、さらにデザインレビューの手順で、タグ付けされたデザイナーがUIの変更を承認する。
メリットは、受け渡しの翻訳が不要で、インタラクションや細部がデザインの意図に近づくこと。デメリットは、二つのスキルを同時に維持する必要があること、そして組織がコードレビューの関門を別に設計しないと、品質リスクが特定の誰にも属さなくなることだ。