Figma × Google Antigravity × SDD。フロントエンドを「UIとロジック」に分断するAI開発の最適解
はじめに
本記事は どすこい塾 Advent Calendar 2025 の2日目の記事です。
過去の記事で、デザインとフロントエンドの境界が薄くなり、UI実装はよりデザイン層に近づき、ロジック側を人間（とAI）が描くようになるという話をしました。
今回は、そこから一歩進んで「アプリ全体を一貫してAIで開発する場合のベストな構成（アーキテクチャ）」について、現時点での私の考えをまとめたいと思います。
※以下、モバイル開発も全て「フロントエンド」に含めて記載します。
※なお、Google Antigravityは商用プロダクトへの本格適用は難しい状況です。ここで述べているAntigravityについては、「この方向に進むだろう」という未来予測であり、今すぐ採用できるソリューションではない点にご注意ください。
最近の開発では「AIにコードを書かせる」ことが当たり前になりつつありますが、フロントエンド、アプリ、バックエンド、インフラなど、全ての領域を同じアプローチで進めようとすると、次第に整合性が取れなくなり、プロジェクトに歪みが生まれると感じています。
結論から言うと、以下の4層に分け、それぞれに適したAIツールを使い分けるのが最適解ではないか、という考察です。
- フロントエンド UI
- フロントエンド ビジネスロジック
- バックエンド
- インフラ
特に「フロントエンドをUIとロジックに分断し、別のアプローチを取る」という点と、「バックエンドの成果物をフロントエンド生成の燃料にする」という点が肝になります。
1. フロントエンド UI：Figmaを完全な「SSOT」にする
まず、フロントエンドの「見た目」の層です。ここは明確にやり方が固まってきました。
- 手法: Figma Dev Mode MCP / Custom UI MCP
- 戦略: FigmaをSSOT（Single Source of Truth：信頼できる唯一の情報源）とする
※これ関連で登壇した時の資料はこちら。
「翻訳」に徹させる
コードを書く際、余白や色、配置といった視覚情報を、言葉（プロンプト）でAIに説明するのは非効率であり、解釈のズレ（ハルシネーション）を生みます。
「コードが正」ではなく「Figmaが正」。
AIには創造させるのではなく、Figmaという正解データからコードへの変換（Translate）だけを行わせるのが、手戻りが少ない方法です。
「動き」もSSOTに含める
さらに最近では、静的な見た目だけでなく、動的な振る舞い（インタラクションやアニメーション）も指定できる仕組みが整いつつあります。
これまでは、プロトタイプ機能だけでは表現しきれない「手触り」や「複雑な動きの挙動」を伝えるのが困難でした。
しかし最新のFigma Dev Mode MCPでは、FigmaのAnnotation機能を使えば、メモをコンテキストに含めることが可能になり、そういった「Figma上では表現しきれない動きのコンテキスト」さえも、明確な指示データとしてAIに注入することが可能になりつつあります。
つまり、「見た目」も「動き」もFigmaをSSOTとし、そこからUIコンポーネントを生成する。これがこの層のゴールです。
2. フロントエンド ビジネスロジック：Google Antigravityによる「オートパイロット」
※以降、Google AntigravityをAntigravityと省略します。
次に、UIとバックエンドを繋ぐ「ビジネスロジック」の層です。
個人的には、ここが今後最もAIによる変革が進む部分だと考えています。
なぜここを分けるのか？
「UI」と「ロジック（データの紐付け、状態管理、APIコール）」を同時に生成しようとすると、コンテキストが複雑になりすぎて破綻しやすいからです。
また、「このボタンを押したら、API Bを叩いて、ローディングを出して...」という細かい紐付けをすべて仕様書（ドキュメント）として書くのは、コードを書くのと同じくらいコストがかかり、手戻りも発生します。
エージェントに「オートパイロット」させる
そこで、この層には Agentic Workflow（エージェント主導のワークフロー）を採用します。
現状、この「オートパイロット」のビジョンを実用レベルで実現できているのは、おそらく Antigravity だけではないでしょうか。
- 入力A: Figmaから生成された「UIコンポーネント」（Layer 1の成果物）
- 入力B: バックエンドの「詳細設計書・API仕様」（Layer 3の成果物 ※後述）
- 指示: 「AとBに含まれない指示 + これらを仕様通りに動くように繋ぎこんで」
このように指示し、あとはエージェントに任せます。人間が細かく指示するのではなく、「UI」と「仕様」という2つの正解を渡して、その間を埋めさせるイメージです。
マルチモーダルな証拠提出
重要なのは、エージェントが単にコードを書くだけでなく、実行と検証まで行う点です。
Antigravityのようなエージェントは、実際にブラウザを操作し、「仕様通りに動いたか」を確認します。
そして、その結果は単なるテキストログではありません。
「実際にテストが成功した瞬間のスクリーンショット」や「操作の様子を記録した動画」といった、マルチモーダルな証拠が提出されます。
これにより、「AIが何をしたか分からない」というブラックボックス化が防げます。人間は提出された動画を見て「確かに仕様通り動いているな」と瞬時に判断できるため、安心してロジックの実装を任せることができるのです。
AIネイティブエディタという「思想」
補足すると、Antigravityは単なる自動化ツールではなく、「AIネイティブなコードエディタ（IDE）」です。
既存のエディタにプラグインを入れるのではなく、エディタそのものが「人間とAIが協働し、AIが自律的にコードをいじる」ことを前提に再発明されています。
将来的にAntigravityそのものが覇権を握るかどうかは分かりませんが、この「開発環境（エディタ）自体がエージェント化していく」という思想は非常に面白く、開発ツールの進化の方向性として「あり得る未来」だと強く感じています。
3. バックエンド & インフラ：DDDを守らせるための「SDD」
そして、バックエンドおよびインフラの領域です。
これらはUIのような「曖昧さ」が少なく、構造化されたロジックが主体となるため、SDD (Specification Driven Development: 仕様駆動開発) のアプローチが相性が良いと考えています。
AIにDDDを遵守させるための ガードレール として
バックエンド開発において、保守性を高めるために DDD（ドメイン駆動設計）を採用したいケースは多いはずです。しかし、AIに漫然と実装させると、レイヤー構造を無視したり、ドメインロジックが散らばったりしがちです。
そこで、「AIにDDDのアーキテクチャを可能な限り守らせるための手段」としてSDDを使います。
人間が「仕様書（Specification）」という形で、Entityの定義やUseCaseの責務を厳密に定義し、AIはそれらをもとに、詳細設計書、タスクを作成し、一言一句違わずコードに落とし込む。こうすることで、AIの「手抜き」や「構造破綻」をある程度防ぐことができます。
※課題点：それでもDDDは難しい
もちろん、仕様書と詳細設計書を用意したからといって、AIがDDDの概念を完全に理解できるわけではありません。DDD自体が人間にとっても習得難易度の高い概念であり、AIが微妙なコンテキストを読み違えることは多々あります。
ですので、ここは「SDDにしたから全自動」ではなく、あくまで人間が設計したドメインモデルを逸脱させないためのガードレールとしてSDD機能させる、という認識が現実的です。
副産物としての「仕様書」が燃料になる
そして、このプロセスにおける非常に大きな付随メリットが、「正確な仕様書・詳細設計書」が成果物として手元に残るという点です。
Swagger (OpenAPI) だけでは「型」はわかっても「振る舞い」までは読み取れません。しかし、SDDで記述されたドキュメントがあれば、それが前述したフロントエンドのビジネスロジック生成（Layer 2）において、最強の「入力データ」になります。
インフラ（IaC）に関しても同様です。
構成定義をドキュメントとして明確にし、それをコード化させることで、バックエンド同様に「仕様」を明確にした運用が可能になります。
どのようなプロジェクトに向いているか？
今回の構成は、それぞれの層で「SSOT（正解データ）」を厳密に定義し、実装していくスタイルです。そのため、プロジェクトの性質によって向き不向きがあります。
-
使い捨てのスクリプト / 検証用デモ:
「今日動けばよく、来週は捨てる」ようなコードであれば、ここまでの構成は不要です。単一のAIチャットで対話しながら書き殴る方が速いでしょう。 -
継続的に開発するプロダクト / チーム開発:
一方で、長く運用するアプリや、少しでも規模が大きくなるプロジェクトにおいては、今回の構成が真価を発揮します。
「AIが書いたコードが複雑すぎて誰も読めない」「UIを少し直そうとしたらロジックが壊れた」といった、いわゆる「AI製スパゲッティコード」の問題を防げるからです。
もちろん、他にも要素はいくつもあるので、それはプロジェクトで要検討すると良いでしょう。
目的に合わせて、適切なものを選択していきましょう。
まとめ：AI開発のエコシステム
これらをまとめると、今後のAI時代の私の考える構成は以下のようになります。
-
Frontend UI:
FigmaをSSOTとし、視覚と動きの定義からコードを生成する。 -
Frontend Business Logic:
UIとバックエンドの仕様書を入力として、AIネイティブエディタ(Antigravity)上のエージェントに自律的に繋ぎ込みを行わせ、動画やスクショで検証する。 -
Backend & Infra:
SDDのアプローチで実装する。DDD等の設計思想を完全に自動化するのは難しいが、仕様書をガードレールにすることで品質を担保し、かつ副産物としての「正確な仕様書」がフロントエンドの燃料となる。
この構成がベストであるかはまだわからないですが、「責務と生成手法の分離」こそが、高品質なプロダクトをAIと共に作り上げる鍵になるのではないでしょうか。
Discussion