Figmaの役割が変わりつつある
Figmaに代表されるデザインツールは、長らく「実装のマスターデータを作る場所」だった。全画面をFigma上に並べ、コンポーネントを整理し、デザインスペックを書き出す。エンジニアはそれを見ながら実装する。デザインツールが「正」であり、実装はその写しだった。
2026年現在、この構図が崩れ始めている。Claude CodeやCursorのようなAIコーディングツールが実装の速度を劇的に上げたことで、「先にコードで作ってしまう方が速い」場面が増えた。AIにより実装ベースで設計を逆算するプロセスが成立するようになった今、デザインツールの位置づけは「マスターデータの制作」から「AIへの視覚的インプットの生成」へとシフトしつつある。
新しい使い方の実際
具体的にどういうことか。
従来のワークフローは「デザインツールで全画面を仕上げる → エンジニアが見て実装する」だった。新しいワークフローでは、まず実装ベースでプロトタイプを作る。Claude Codeと対話しながらUIを組み上げていく。この過程で「ここの色が寂しいな」「このレイアウトをもう少し変えたい」といった視覚的な修正が必要になったとき、初めてFigmaを立ち上げる。
Figmaで修正のイメージを作り、そのスクリーンショットをAIに渡して「こういう感じにして」と指示する。つまりFigmaは実装の設計図ではなく、AIとのコミュニケーションツールとして機能する。絵で指示を出す道具だ。
さらに、コードからFigmaへ持ってくるプラグインも登場している。Claude Codeで作った実装をFigma上に取り込み、そこで微調整してまたコードに戻す。双方向の行き来が可能になったことで、どちらが「正」かという問い自体が意味を失いつつある。
この変化が起きる条件
ただし、この変化はすべてのプロダクトに均等に起きるわけではない。
設計ロジックが重要なプロダクト、たとえば業務アプリやSaaSツールのようなものは、実装ベースで進めやすい。画面遷移やデータの流れが明確で、ビジュアルよりも構造が優先される。こうしたプロダクトではFigmaの出番は確実に減っていく。
一方で、toC向けのアプリやブランドが重要なプロダクトでは話が異なる。感情に訴えるビジュアル表現、繊細なアニメーション、世界観の統一。これらは言語化が難しく、AIへのテキスト指示だけでは再現しにくい。こうした領域ではFigmaのようなビジュアルツールでの作り込みが引き続き不可欠だ。
デザインをするとは、意図を持って設計と意匠を行うということであるが、「設計」の部分はコードで直接扱えるようになりつつある。残るのは「意匠」の部分であり、ここにこそデザインツールの新しい役割がある。
デザインシステムという接点
この変化の中でデザインシステムの重要性は変わらない。むしろ増している。
コードベースで開発するにしても、Figma Makeで作るにしても、ブランドの一貫性を保つためのベース（カラー、タイポグラフィ、コンポーネント）は必要だ。このベースがデザインシステムとしてFigma側にもコード側にも存在していれば、どちらから作り始めても品質の土台は担保される。
デザイン組織の効果的なリソース配分は外部専門性と内部基幹力の適切な組み合わせによって実現されるのと同様に、ツールのエコシステムにおいても「何を自前で持ち、何をAIに任せるか」の設計が問われる。デザインシステムは「自前で持つべきもの」の最たるものだ。
ツール論を超えて
最終的に重要なのは、特定のツールがどうなるかではなく、デザインのプロセスそのものが再構成されていることだ。デザイナーとストーリーの関係の変化についてが示すように、デザイナーの仕事は常に変化し続けている。
「Figma vs Claude Code」という対立構造で考えるのは本質を見誤る。両方とも道具にすぎない。問われているのは「何を作るか」「なぜそれが良いのか」を判断する力であり、それはツールに依存しない。道具が変わっても、良いものを作る人は良いものを作り続ける。ただし、その人が使う道具のポートフォリオは確実に変わっていく。