はじめに
こんにちは。 DMM.com の プラットフォーム開発本部 > ユーザーレビューグループ > フロントエンドチーム です。
先日公開された AI × Turtle で実現する Vibe Coding では、AI を活用した Turtle Design System の開発支援機能（以下、本記事では AI-Turtle と呼びます）が紹介されています。
本記事では、フロントエンドエンジニアとして実案件でこの機能を使用してみた体験をまとめています。
具体的には、レビュアーマイページのリプレイス案件を例に、静的実装の初動を AI-Turtle に任せた事例を紹介します。
先行記事では主に仕組みや背景が語られていましたが、今回は「実際に使う側」の視点から、導入時の所感や運用上の工夫に焦点を当てました。AI を活用したフロントエンド実装支援に関心のある方にとって、少しでも参考になれば幸いです。
導入の経緯
以前、既存プロジェクトにページを追加する形で AI-Turtle を試したことがありました。
その際は、既存コードの設計や実装方針との整合を取るのに調整が必要となり、
既存プロジェクトとの相性に課題を感じる場面がありました。
そこで今回は、既存ページを流用せず、新規ページを対象として静的実装の初動を AI-Turtle に任せる形で再度導入してみました。
AI-Turtle を使ってみた流れ
今回の実装では、Figma のデザインからコンポーネントを生成するまで、以下の流れで AI-Turtle を利用しました。
Figma で作成されたデザインから実装対象コンポーネントを確認
今回は、実装対象の一例として「並び替えメニュー」の生成を例に説明します。 以下が Figma 上で用意したデザインです（左が PC・右が SP）。
Cursor（Turtle MCP サーバー連携）で、Figma デザインから静的実装コード(.tsx と .stories.tsx)を生成
生成自体は短時間で完了し、実際の生成結果として画面の骨組みはすぐに確認できました。 作成するコンポーネントによっては、細部については一定の調整が必要で、「そのまま使う」というよりは叩き台として活用するイメージでした。
生成結果の DOM 構造・余白・レスポンシブを目視で確認し調整 不要なラッパー要素の削除やレスポンシブの細かな調整を手動で修正
カルーセルなどの動的コンポーネントを手動実装
AI-Turtle利用の効果
静的実装の初動を大幅に短縮できる
静的実装の叩き台をほんの数分程度で生成できるため、画面の骨組みを作る初動をかなり早めることができました。
画面をゼロから組み立てるのではなく、まずベースとなる UI が生成されることで、実装に着手してから画面確認までの時間が短縮されます。
静的部分の土台が短時間で整うことで、状態管理やイベント処理などの動的実装により多くの時間を割けるようになり、実装の優先度付けもしやすくなりました。
Turtle コンポーネントの構成設計負荷を軽減できる
Turtle コンポーネントを使用した構成でコードが生成されるため、コンポーネントの使い方や構造を一から設計する負荷が軽減されました。
これまで手動で実装する際にはドキュメントを確認したり、既存実装を参照したりしながら構造を組み立てていましたが、その工程を省略できたことで、設計よりも調整・改善に時間を使えるようになりました。
Storybook 生成による確認コストを削減できる
Storybook もあわせて生成できたことで、コンポーネント単位での確認がしやすくなりました。
UI 確認のためのセットアップが不要になり、実装と確認の往復がスムーズになった点も実務上は大きなメリットでした。
Figma との整合確認を効率化できる
Figma を見ながら手動で余白や構造を再現する作業に比べ、ベースが生成されることで確認と調整に集中できました。
AI-Turtle利用の課題
完全自動化という観点では、まだ人の調整が必要な領域も多いと感じました。
レイアウト解釈の限界
Turtle MCP を用いることで構造は生成されますが、レイアウトや余白の細かいニュアンスまでは完全には再現できません。
特に PC / SP で構造が異なるデザインの場合、ブレークポイントの解釈やレイアウト差分の吸収に限界があり、最終的には手動での修正が必要になりました。
Figma 構造とコンポーネント設計の不一致
Figma 上のレイヤー構造と Turtle のコンポーネント設計が必ずしも一致するわけではなく、不要なラッパー要素（div）が生成されるケースもありました。
そのため、生成後に DOM 構造を整理する作業は一定発生します。
インタラクションの実装
カルーセルスライダーのように状態管理やイベント処理を伴うコンポーネントについては、現時点では AI に任せきるのは難しく、従来どおり手実装が必要でした。
Figma 構造の事前確認の難しさ
普段 Figma を積極的に触らないフロントエンドエンジニアにとって、実装前にレイヤー構造を細かく確認し、「この構造で生成して問題ないか」を見極めるスキルも求められると感じました。
コスト・運用面で気づいたこと
ツールの使い分けも重要なポイントでした。
普段は Cursor を使用していますが、Turtle MCP を利用する場合はトークン消費が大きく、利用回数によっては制限に近づく懸念もありました。
そのため、以下のように使い分けました。
- Figma を直接参照する必要がある生成・修正 → Cursor
- 構造が固まった後の軽微な修正 → GitHub Copilot
ただし GitHub Copilot では、今回の運用では Figma などの外部デザイン情報は直接参照していなかったため、デザインを前提とした修正をする場合は、文章やコメントで意図を明示的に伝える必要がありました。 この点は運用上の工夫が必要だと感じました。
どんなケースなら向いていそうか
向いているケース
- 新規プロジェクトやリプレイス案件
- 静的実装が中心の画面
- Turtle コンポーネントで表現可能な UI
既存コードの制約が少ない環境では、初動を早めるツールとして相性が良いと感じました。
注意が必要なケース
- 既存設計に強く依存するページ
- PC / SP で構造差が大きいデザイン
- 状態管理やイベント処理を多く含む UI
これらは生成後の調整コストが増えやすい傾向にあります。 ただし、叩き台を生成してもらいながら人が仕上げる「半自動」の運用であれば、工数短縮の効果は得られます。
まとめ
今回 AI-Turtle を実際の開発で活用してみて、 「すべてを置き換えるツール」というよりも、実装の初動を加速させるための強力な補助ツールだと感じました。
特に新規ページや静的実装中心の画面では、生産性向上に大きく寄与する可能性があります。
一方で、レイアウトの細部調整や動的な振る舞いを持つ UI については、現時点ではフロントエンドエンジニアの設計・実装が不可欠です。
AI-Turtle の強みを理解したうえで、 適切な場面で活用していくことが重要だと感じました。
今後も、AI を活用したフロントエンド開発の一つの選択肢として、 実際の開発の中で積極的に活用していきたいと考えています。
