AIネイティブなフロントエンド開発手法 FE-SDDのススメ 〜秘訣はロジックとUIの分割にあり〜

はじめに

先日、「AI 駆動開発勉強会 フロントエンド支部 #1 w/あずもば」にて、「AIネイティブなフロントエンド開発手法 FE-SDDのススメ」というテーマで発表させていただきました。

スライドは下記から確認できます！

時間の都合上お伝えできなかった内容もあったため、本記事で補足させていただきます。

僕自身、仕事でも個人開発でも、フロントエンドを触ることが多いです。ただ、フロントエンド開発でAIを活用しようとすると、なかなか思うように実装してくれないことが多いな、と感じていました。

この記事では、LTでお話しした内容をベースに、フロントエンドをAIで開発するコツと、僕自身が実践している FE-SDD（フロントエンド仕様駆動開発） についてお伝えします。

少しでも皆さんの開発や学びのヒントになれば嬉しいです。

AI を用いたフロントエンド開発での課題

フロントエンド開発でAIを活用しようとすると、大きく3つの課題に直面します。

1. ざっくり指示だとAIに任せても上手くいかない

1番自律性が高いと言われているDevinですら、ざっくりした指示だと上手くいきません。

具体的には：

• デザインの実装漏れが起こる
• 細かいUIの調整が意図通りにならない
• Figmaのデザインとの差異に気づきにくい

などの問題が発生しています。

2. コード生成量がかなり多く、レビュー負荷が高い

フロントエンドは、バックエンドと比較してもコード量が多くなりがちです。

• コンポーネントの数が多い
• ファイル数も増える
• 一度のPRで大量のコード変更が発生

これにより、レビュワーの負担が大きくなります。

3. 重複コードが大量発生する

AIにFigmaを渡せば、同じ見た目のコンポーネントは作れます。
しかし...

• 新規作成が多く、既存コンポーネントを使いまわせない
• 結果的にメンテコストが増大
• 後から統一しようとすると大変な作業になる

の問題が生じます。

フロントエンド開発は、まだAI任せにできない

この状況を踏まえると、フロントエンド開発はまだ完全にAI任せにはできないと感じています。
理由は、大きく2つです。

UIのバグは、人が介入する必要がある

• コード上は問題なくても、挙動がバグっている場合が多々ある
• AIがうまく修正できない場面も多い
• 適宜、人が確認や修正する必要がある

共通コンポーネントの再利用は死活問題

ここを放置すると、メンテコストがかなり大きくなります。

そのため、現状は 「まだ人が動作確認・レビューをする必要がある」 という結論に至りました。

であれば、人がレビューしやすい実装をさせることに注力すべきだと考えました。

AIにどう任せればレビューが楽になるか？

課題を整理した上で、それぞれの対応方法を考えてみました。

特に「レビューしにくい」問題は深刻だと感じています。
UIとロジックが混在していると：

• コード変更量が増加する
• ロジック修正でUIデグレを気にするのが辛い
• どこを確認すればいいか分かりにくい

これらを考えた結果、「SDDを工夫して行えば、解決できるのでは？」 という結論に至りました。

それが FE-SDD です。

FE-SDD を使った開発効率化

SDD（仕様駆動開発）について

では、まず SDD（仕様駆動開発）について簡単にご紹介します。
SDD（Spec-Driven Development） は、仕様ドキュメントを先に定義し、それに従ってコーディングを進める手法です。

SDDのメリット：

• 事前に設計書を作ることで、構造化されたコードを生成できる
• 仕様のブレや実装漏れを回避しやすい
• バイブコーディング時の課題を解決できる

cc-sdd とは？

今回の発表では、@gota_bara さんが作成された cc-sdd を利用しています。

cc-sddの特徴：

• SDDで実装するためのフレームワーク
• OSSで導入も簡単（npx cc-sdd@latest）
• Claude Code、Cursor、Codex CLI等、各種AIエージェントツールで利用可能
• コマンド入力だけで仕様作成から実装まで進められる

主なコマンド：

• /kiro:spec-init <機能名> - 要件定義書の土台作成
• /kiro:spec-design <spec名> - 要件定義書の作成

これらのコマンドを入力するだけで、SDD を行うことができます！

FE-SDD について

FE-SDD は、SDDをフロントエンドの実装に特化させたものです（スナガクの造語です）。

主な特徴

1. 仕様ドキュメント作成時に、実装予定のUIイメージ図を作成させる

• AIとの認識のずれを可視化して、実装漏れに気づける
• 仕様ドキュメントの作成時点で指摘できる
• Figma URLを正しく読み込めているか判断可能

UI イメージ図のサンプル例
イメージ図を作成させることで、AIが実装しようとしている内容と自分の想定が一致しているか確認できます。

2. UI実装とロジック実装を分ける

• 別々にレビューができるので、一度に見るコード量が減る
• 関心事が分離されているので、レビュー時の認知負荷が下がる
• UIを維持したまま、ロジックだけAIに書き直させられる

FE-SDD 開発フロー

FE-SDDは、大きく2つのフェーズで進めます。

1. UI を SDD を利用して実装する
2. ロジックを SDD を利用して実装する

Phase 1: UI実装パート

cc-sddを用いて、UI部分を実装します。

ポイント：

1. ロジックは書かず、モックデータで表示部分だけ作る

   • この段階で見た目を完成させておく

2. コンポーネント分割の単位を指定する

   • ロジック実装フェーズでコンポーネント構成をいじらなくて済む
   • ロジック修正時の原因切り分けが行いやすくなる

3. Figma URLも仕様書に含める

   • コンポーネントごとにFigma URLを紐づけると精度が上がる

4. 仕様書にUIのイメージ図を含める

   • 正しくFigma URLを読み込めているか判断できる

UI実装の結果

この手法で実装した結果...

• 見た目は、ほぼ完璧な実装を再現できた
• 事前にコンポーネント構成を指定しているので、構造的な手戻りが発生しない
• 修正はスタイルだけなので、サクッと行える

figma ファイル

実装された画面

Phase 2: ロジック実装パート

UI実装が完了したら、cc-sddを用いてロジック部分を実装します。

メリット：

• 基本的にロジック実装部分の差分しか出ない
  • 差分が少ないので、レビューもすぐ終わる
  • 本当に見るべきロジック部分に注力できる
• 動かなければ、もう一回生成させることもできる
  • UI部分は実装できているので、手戻りが少ない
  • Token消費量も抑えられる

AIでフロントエンドを実装する時に気をつけること

実践を通して分かった、4つのポイントをお伝えします。

1. 再利用可能なコンポーネントがないか確認する工程を入れる

• 明示的に仕様書に組み込むと、再利用してくれます
• Planモード等で実装計画を立てる時にも注意できると良さそうです

2. UIとロジックを分けて開発する

• レビュー負荷やデグレリスクを下げられます
• ロジックだけ再生成できるので、複数パターン比較も行いやすいです

3. 必要に応じて、Planモードを使い分ける

• 簡単なロジックならSDD使わない方が速い場合もあります
• UIは完成済みなので、実装のボリュームは小さめになるます
• 状況に応じて使い分けることが大事

4. 画面に複数ロジックがある場合は、分けて実装する

例えば「データ取得」と「Drag & Drop」は、別々に実装する。

理由：

• 単機能ずつ実装するなら、精度高く実装してくれる
• 複数を同時実装すると、AIでも修正しにくくなり、デバッグも困難に
• 実装スピードを早くするためにも、一つずつ機能を作るのが重要

補足） フロントエンド開発時に時間がかかること

大きく二つあると考えています。細かいデザインの適用と、バグ発生時の挙動修正です。

細かいデザインの適用

最近はAIの精度が上がってきたとはいえ、完成度を高めるほど、最終的には人の手での修正・確認が必要になります。
しかし、デザイン修正のタイミングでロジック部分のデグレを気にしながら作業すると、デザインに集中できず生産性が落ちると感じています。

そのため、デザイン修正だけに注力できるよう、ロジック部分は後から実装するというフェーズ分けをおすすめしています。

バグ発生時の挙動修正

フロントエンドでは、ファイル内外を問わずさまざまな処理が行われます。
バックエンドのようなデータの受け渡しに加え、フロントエンド特有の非同期処理も絡み合うため、ロジック部分は煩雑になりがちです。

デバッグ量を減らし、不要なバグの発生を防ぐためにも、一度に全部を開発するのではなく、一つずつ機能を作っていくことが重要だと考えています。
また、コンポーネント構造を事前に決めておくことで、構成変更に起因する不要なバグを防げます。

AI時代において「実装スピードは3倍になったが、デバッグ時間は10倍になった」という現象は、フロントエンドで特に顕著だと感じています。
だからこそ、バグを発生させない設計・開発手法がより重要になるのかな？と感じています。
います。

まとめ

フロントエンド開発はまだレビューが必要です。
であれば、レビューしやすい実装をさせましょう。

そのためにも、

1. UIとロジックを分けて開発する
2. 仕様書作成時に既存コンポーネントの再利用を検討する
3. 実装前にイメージ図を作成し、認識ズレの有無を確認する
4. 画面に複数ロジックがある場合は、分けて実装する

これらを意識することで、AIを使ったフロントエンド開発がより効率的になるかな？と思います！
もし、他にいい実装方法があれば、コメント欄やXで教えて頂けると嬉しいです！

参考情報

• cc-sdd（SDDフレームワーク）：@gota_bara さん作
  

• FE-SDD 参考プロンプト

  • UI実装時：
  • ロジック実装時：

Xフォローしてくれると嬉しいです

Xでも情報発信しているので、フォローしていただけると励みになります！

https://x.com/suna_gaku