0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Figmaは「絵」ではない、UI層のソースコードそのものである 〜UI層の真実源をFigmaへ移譲する、AI時代のフロント開発〜

0
Posted at

はじめに:UI実装の主戦場は、エディタからFigmaへ

フロントエンジニアの主要なタスクの一つは「Figmaを読み解き、UIコードを書き下ろすこと」でした。
しかし、AIエージェントの台頭により、「UIコードは依然としてコードベースに存在するが、人間が書くものではなく、AIがFigmaからコンパイル(生成)するもの」 になりました。

1. 責任境界線の再定義:誰がどこで何を「実装」するのか

このアーキテクチャでは、人間が直接手を動かして「記述・構築」する対象を以下のように分離します。

レイヤー 作業者 場所 役割
Logic Layer エンジニア IDE (TypeScript等) Domain, Repository, Controllerの実装。不変のビジネス論理と型を記述。
UI Layer デザイナー / エンジニア Figma レイアウト、スタイル、状態遷移の「視覚的実装」。UI層の真実源。
UI Artifacts AI (コンパイラ) コードベース Figmaから自動生成されたUIコード。人間は直接編集せず、管理のみ行う。

エンジニアにとって、src/ui/ 配下のファイルは、もはや「人間が苦労して書くソース」ではなく、Figmaというビジュアルソースコードから出力された 「自動生成される成果物」 へと変化します。

2. 「Figmaでの実装」が意味すること

FigmaがUI層のソースコードであるならば、Figma上での作業は単なる「絵描き」ではなく「UI実装」そのものです。

したがって、Figmaに落とし込む際のfigma作成段階で、すべての矛盾が排除されていなければなりません。

  • 型安全なデザイン
    Figmaのプロパティは、コード上の型定義(Enum/Union型)と完全同期している必要がある

  • ドメインルールの反映
    「未決済なら発送ボタンは存在しない」というルールは、Figma上で「発送ボタン」を配置する前に確定させ、Figma上でもその状態が整合性を持って実装されている必要がある

Gemini_Generated_Image_9w7pn39w7pn39w7p.png

Figma上でドメインルールを逸脱した状態を作ることは、 「ビルドエラーを引き起こすコードを書くこと」 と同義になります。

3. 新・開発プロセス:UIコードは「書く」から「生成する」へ

自分の考えでは、ワークフローは以下のようになるはずです。

  1. Domain Design(設計の確定)
    • 言葉と制約を定義。ここでドメイン上の矛盾をすべて検知・排除する
  2. Logic Implementation(論理の実装)
    • エンジニアが、確定した型に基づき論理(Logic/Domain)をコードで実装する
  3. UI Implementation in Figma(UIの実装)
    • デザイナー(またはエンジニア)が、Figmaというビジュアルエディタを用いて、UI層を直接「実装」する
      ※ ドメインによる取りうる状態を忠実に再現することが求められる
  4. AI Generation(自動生成)
    • AIが「FigmaというUIソース」を読み取り、コードベースの src/ui/ を最新の状態に更新する
  5. Integration & Review
    • エンジニアは「Figma上のUI実装」がドメインの型と整合しているかをレビューし、ロジックと結合する

Gemini_Generated_Image_6ouc2z6ouc2z6ouc.png

4. 結論:真のSSOTとしてのFigma

「UIコードはコードベースで管理するが、人間はFigmaでUIを実装する」。
このアプローチにより、デザインと開発の間に存在した「翻訳コスト」と「同期漏れ」は消失します。

UIの修正が必要なとき、私たちはエディタでタグを打ち直すのではなく、Figmaを開いて「ビジュアルソースコード」を修正します。あとはAIがそれを最新のUIコードへと変換してくれます。

「いかに描画するか」はAIに任せ、人間は「何が正しい論理か」に集中する。

これが、AI時代のフロントエンド開発における、最も効率的で堅牢な、人間とAIの共生モデルです。

まとめ

Figmaのキャンバスを汚すことは、もはや単なる「ズレ」ではなく、プロダクトの崩壊を意味する「バグ」です。

「Figmaが綺麗なら、アプリは正しく動く」

このシンプルな真実を信じられる設計を構築できたとき、私たちはAIという強力なコンパイラと共に、これまでにない速度と精度でプロダクトを形にできるはずです。

所管

figmaMCPを使ったAI実装をしていて本記事の必要性をひしひしと感じた。
フロントエンドエンジニアに求められるのは何かというより、デザイナーの領域だったデザインに、エンジニアが行なっていたドメインのUIとの結合が染み込んできている。(デザイナーの役割が増えるのか、 エンジニアとの密な協業がさらに加速するのか、変化のスピードが感じられる)

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?