
- はじめに
- Turtle とは
- わたしたちのこれまでの取り組み
- AI-Turtle プロジェクトの誕生
- Figma MCP サーバーを試す
- Turtle MCP サーバーを作る
- デザインデータは AI-friendly であるべき
- AI に考えさせることを極力減らす
- Turtle の認知度向上
- さいごに
- 一緒に働ける仲間を募集しています
はじめに
こんにちは。DMM.com の プラットフォーム開発本部 > Developer Productivity Group > Turtle チームです。わたしたちのチームは横断チームとして社内の開発生産性を高めるための仕組みづくりを行っており、その一環でデザインシステム Turtle を開発しています。
この記事は、その Turtle と生成 AI を組み合わせ、フロントエンド実装を自動化して生産性を大幅に上げた取り組みについてまとめたものです。
ここでいうフロントエンド実装とはいわゆる Web ページのコーディングのことで、以下のような作業を指します。
- デザイナーが Figma を使ってデザインをする
- デザインデータを元にフロントエンドエンジニアがコーディングする
- 多くの場合、React (Next.js) で実装される
- 部署によっては React 以外のフレームワークや素の HTML で実装される
昨今の生成 AI や MCP サーバー等の盛り上がりにより、これらを上手く使ってどのように生産性を上げていくかが多くの会社にとって大きな関心事になっていると思います。
社内謹製のデザインシステムと生成 AI を組み合わせることで、これまで工数のかかっていたフロントエンドのコーディングを自動化するという試みは、従来のフロントエンド実装の流れを変える可能性を秘めています。
この試みはまだ途上であり、思い描いている機能すべてが実装できたわけではありませんが、現時点での知見や試みを多くの人に共有したいという思いからこの記事を書きました。
同じようなことを考えている方々の一助になれば幸いです。
Turtle とは

わたしたちのチームでは、「Turtle」と呼ばれる社内デザインシステムを開発・運用しています。
Turtle は、DMM の複数事業にまたがるサービスを、ひとつの統一された体験として届けるために生まれたデザインシステムです。「デザイン原則」「デザイントークン」「コンポーネントライブラリ」の三つの柱から成り立ち、どのチームがどのデバイス向けに開発していても、DMM らしい UX / UI を実現できるように設計されています。
コンポーネントは Figma ライブラリと React ライブラリの双方が用意されています。開発者は高品質な画面を簡単に構築でき、余計な実装コストを減らせます。デザイナーはゼロから考える必要がなくなり、体験の設計に集中できます。その結果プロジェクトは早く立ち上がり、高品質な MVP を素早くリリースできるようになります。
Turtle は、ただの UI キットではなく、品質とスピード、そして DMM の「らしさ」を支える基盤と言えるものです。
わたしたちのこれまでの取り組み
Turtle チームでは、フロントエンド実装の生産性を高めるために、いくつもの工夫を重ねてきました。
コンポーネント自体の改善はもちろん、Turtle の設計思想や使い方をきちんと伝えるためにしっかりしたドキュメントを用意し、Storybook には豊富な Story を用意して、実装時に参考になる情報を整えました。
また、Slack に専用チャンネルを設けて、気軽に質問・要望を出せるようにしたり、情報発信を定期的に行って Turtle の認知と活用を促進しています。
新しい技術にも積極的で、Figma の Code Connect も発表後いち早く導入しました。これは Figma の「開発モード(Dev Mode)」で利用できる機能で、Figma 上のコンポーネントを選択すると、右側に実装コード(React など)が表示されるというものです。

わたしたちはこの機能にいち早く対応し、Figma のデザインと React のコードが直接リンクされるようにしました。コードをコピーしてすぐに実装を開始できるようになるため、デザインと実装の距離がぐっと縮まり、工数削減につながっています。
Dev Mode 自体使いこなせるエンジニアが少なかったため、ワークショップを開催するなどしてイネーブリングに注力したことも大きな成果を生みました。
詳しくは2024年12月に公開された記事 入社10ヶ月で行った Turtle デザインシステムの開発と関連する取り組み および2025年5月に公開された記事 【イベントレポート/LT #3】DMM.comでのFigmaを活用したデザインシステム開発と情報の一元化 #Offers_DeepDive をご参照ください。
こうした積み重ねによって、Turtle を活用した開発のスピードと精度は着実に向上しています。ただ、Web ページというものはコンポーネントだけを使って作られているわけではありません。Turtle 以外のもの、テキストや画像、レイアウト等々様々なものを組み合わせたうえで作られています。
Turtle の部分だけを最適化しても工数インパクトは限られてしまう。そのためページ自体を実装コードに落とし込む工数を何とかもっと削減できないか、調査・検証を続けていました。
AI-Turtle プロジェクトの誕生

近年、生成 AI の技術が急速に進化し、DMM でも全社的に AI を業務に取り入れる機運が高まりました。各部署がさまざまな生成 AI ツールを試しながら効率化の可能性を探っていた中で、わたしたち Turtle チームも「Turtle を使ったフロントエンド実装を AI に任せられるのでは?」という仮定のもと、検証を始めました。
わたしたちのチームでは2025年4月頃から AI の活用方法の模索し始めましたが、これが AI-Turtle プロジェクトのスタートとなりました。
DMM での AI 活用と戦略については次の記事を併せてご覧ください。
DMMのプラットフォーム基盤が目指す、AX戦略(AI Transformation)
Figma MCP サーバーを試す
ちょうどその頃、Figma のデザインデータをもとに実装コードを生成できる OSS の Figma MCP サーバーが登場し SNS でも話題になっていました。Figma API を叩き、受け取ったデザインデータの情報を AI エージェントが読みやすい形式に簡素化して返すもので、デザインデータの URL をプロンプトに打ち込むだけで、ある程度の実装まで行ってくれる動画はなかなかのインパクトでした。
わたしたちが最初に試したのは、AI エージェントに Turtle の実装コードを読み込ませたうえで、この Figma MCP サーバーと連携してコードを生成するという構成でした。しかしながら、コンポーネントの誤用や props の間違い、不確実なリトライなど、なかなか精度が出ない問題に直面しました。
大きな原因のひとつは、Figma のコンポーネントプロパティと React コンポーネントの props が必ずしも一致していないことでした。
Figma の Turtle コンポーネントはデザイナーが使いやすいように設計されています。コンポーネント名やプロパティの名称と値、その粒度など、デザイナーが理解しやすい設計になっています。
一方で React コンポーネントの方は開発者が扱いやすい設計になっています。MCP サーバーは Figma のデータを解析しますので、レスポンスも Figma 寄りになります。結果として、React 実装時の props 間違いが頻発し、精度が落ちる主因になっていました。
Code Connect でこういった設定の違いは吸収できているため、その情報を再利用できることを期待したのですが、残念ながら Code Connect のデータまでは Figma API で取得できませんでした。
そこで、この Figma のプロパティと React の props とのマッピング問題を解消できれば精度が上がるのでは?という仮説が生まれます。Figma MCP サーバーは OSS ですので、試しに Turtle 向けのマッピング情報を組み込んでみたところ、精度が飛躍的に向上しました。
Turtle MCP サーバーを作る
この試みを受けて、わたしたちは Figma MCP サーバーを利用して Turtle 向けに最適化するという手法を採用しました。アドオン的に、Turtle のコーディングに必要な情報を加えるという発想です。
MCP サーバーの実装
追加した主な処理は、前述した Figma のプロパティと React の props を結びつけるマッピング情報です。例えば、Figma の Alert コンポーネントの messageType=info というプロパティは React コンポーネントの type=info という props に対応する、といった対応関係の情報です。
他にも例えば以下のような実装を個別に行っています。
- 事情によりコンポーネント名称が Figma と React で異なっている場合の対応
- Turtle が子要素として別の Turtle を持っている場合の対応
- 実装時の HTML タグを任意に指定できる機能
- オートレイアウトのグループを任意のカスタムコンポーネントとして切り出す機能
これらを全コンポーネント分対応し、MCP サーバーのレスポンスに追加しました。

ルールの作成
精度を上げるためにもうひとつ重要なのがルールです。ここで言うルールとは、MCP サーバーから返されたデータを AI エージェントがどのように扱うべきかを定義したドキュメントを指します。
通常、生成 AI への作業指示はプロンプトで行います。ユーザーが出した指示に基づいて、具体的にどういった作業をどの順番で行うのかといった判断をエージェント自身がするわけです。この判断の確度を、いかにルールでもって上げられるかが精度向上の鍵になります。
このルールの作成にもかなりの時間をかけました。生成 AI は「温度」の関係で揺れが大きく、同じプロンプトを続けて打ってもまったく違う結果が返ってくるということが珍しくありません。同じ結果が出るよう色々な書き方を試し、試行錯誤を繰り返しました。
ルールの記述を英語にしたり、箇条書きにしたり、マークダウンのテーブルにしたり、思いつくものを試して結果を検証しましたが(おそらく多くの人たちと同じように)「これが正解」と呼べるものをまだ掴みきれていないというのが正直なところです。
ツールや環境によっては温度の設定が可能なものもありますが、現在社内でよく使われている Cursor では温度の設定ができません。そうした環境を考えると、試行錯誤して一番いい結果が出たものを採用するというやり方が今は一番現実的だと思っています。
とは言え、こうした改修により AI-Turtle が出力するコードの品質は目に見えて向上し、AI と Turtle を使ったフロントエンドの自動実装が現実的な水準に近づいていきました。
デザイントークンの処理
Turtle では UI の一貫性を保つため、色やスペース、文字サイズなどの様々なデータはデザイントークン化されています。
フロントエンド実装時のスタイリングでは、直接値を書くのではなく対応するトークンを記述する必要があり、従来のコーディングではこの部分の作業に時間がかかっていました。
AI-Turtle ではトークンと値のマッピング情報をルールとして持つことによりこの変換作業を自動化しています。これまで述べてきた通り、マッピングは MCP サーバー内の処理で行うのが理想ですが、デザイントークンのような大量の情報の処理はルールに委譲してしまうのもひとつの手です。もちろん検証は必要ですが、今回は高い精度が出たためこのやり方を採用しました。

デザインデータは AI-friendly であるべき
さて、こうした一連の取り組みの中で見えてきた大きな課題のひとつが、Figma のデザインデータの質が生成精度を大きく左右するということです。
特に重要だと感じたのが以下の四点です。
- 要素が正しくグループ化されているか
- 意味のあるレイヤー名が付いているか
- 無駄な要素や装飾が排除されているか
- オートレイアウトが適切に使われているか
こうした AI-friendly な構造が整っていないと、いくら MCP サーバー側で整備しても精度は頭打ちになります。セマンティックなレイヤー名だとそれを反映したタグを使用してくれますし、不要な要素がなければ意味不明な要素が出力されることもなくなります。また、テキストが素で置かれているよりもレイヤー化されている方が生成時の取りこぼしがありません。
オートレイアウトというのは Figma の機能の一つで、要素をグループ化したうえで並び順や間隔などを自動で設定できるものです。CSS でいうところの Flexbox のようなものです。これが設定されていればより再現性の高い成果物を得ることが出来ます。
要するに、丁寧で綺麗に構造化されたデータほど精度が上がるということです。人間が理解しやすいデータは、AI も正確に理解・変換できるため精度が上がるということだと思います。
AI-friendly なこういったデータは結果として人間にとっても見通しがよい、メンテナンスしやすいデザインデータになります。デザインデータをきれいに整理するのは手間ですしコストもかかりますが、それが生成 AI の精度向上に直接的につながると考えれば投資する価値があると思えてきます。
現在わたしたちは、この知見をもとに AI-friendly なデザインのガイドラインを策定しています。Do / Don't 的なものからちょっとした tips まで、まだまだ内容は少ないですが今後 AI-Turtle の利用拡大に伴ってより充実させていく予定です。
こうした取り組みは AI-Turtle の精度向上だけでなく、デザイナーの作業効率やチーム全体の品質向上にもつながる可能性を持っていると考えています。

AI に考えさせることを極力減らす
もうひとつの発見は、ルールでもって AI に判断させるのではなく、MCP のレスポンスとして固定化してしまった方が生成精度が上がる、ということでした。
例えば、横幅 100% の Button コンポーネントを考えてみます。
Figma 上でそのようにデザインされていれば MCP のレスポンスとしてそのスタイル情報も入ってきます。しかし、そのスタイル情報を参照して width:100% のスタイリングをするようにせよというルールを書いても、取得できたスタイル情報を適切な CSS に変換できないこともあり生成物にバラつきが出てしまいます。上手くやってくれる時もあればそうでない時もある。典型的な揺れが生じます。
一方で、例えば fullWidth といった React の props を用意して、その props が指定されているかどうかで前述のマッピングを用いて処理を行う方が精度が安定しやすいという結果が得られました。props 化していれば AI の作業はただ単にそれを設定するだけになり揺れが減ります。TypeScript や ESLint を使っていれば型チェックや lint も効いて、より品質の向上が見込めます。
この経験を受けて、わたしたちは Turtle の React コンポーネントをより props 中心の設計にリファクタリングすることも検討し始めています。こうすることで AI-Turtle の精度がさらに高まり、将来的にはより完全な自動化にもつながる可能性があります。
Turtle の認知度向上
DMM 社内でも Turtle の利用率は 100% ではなく、その存在すら知らないチームもあります。そうしたチームにも AI-Turtle をきっかけに Turtle を知ってもらうことができ、利用の検討につながる機会が増えました。
2025年6月には「AI-Turtle ガイドツアー」と銘打った全社参加型のお披露目会を行い、エンジニア・非エンジニアを問わず多くの方に参加いただき好評を得ています。

すべてのプロダクトで Turtle を使うことが必ずしも適切であるとは言えませんが、UI ライブラリの使用を検討しているけれど何を使えばいいのか分からないといった時に、Turtle という選択肢があることを知ってもらえるようになった、というのはすごく大きいと思っています。
AI-Turtle はまだ生まれたばかりなので幅広く利用されている状況ではありませんが、すでにいくつかのチームで AI-Turtle の導入が決定しています。しっかり効果測定を行ってどれだけ効果があったのかを検証する予定です。その結果はまた別の機会に記事にする予定ですのでぜひ楽しみにお待ちください。
さいごに
Turtle と 生成 AI の組み合わせは単なる工数削減にとどまりません。プロトタイピングのコストが大幅に下がるため、短期間で大量の検証が可能になります。
デザイナーだけで動くものを作れるため本格的な開発に入る前に思う存分 UI 等の試行錯誤ができるはずですし、エンジニアも時間のかかっていた初期構築が自動化されればビジネスロジック等のコアな作業に集中できるのでより多くの時間を実装にさけるようになります。
そしてこういった生産性の向上が見込めればより多くのプロダクトが Turtle を使う理由になり、結果として UI の一貫性やアクセシビリティが担保され、ひいては DMM 全体のプロダクトの品質向上につながるはずです。このエコシステムが本格的に機能している未来は、思っているよりずっと早く来そうな気がしています。
一緒に働ける仲間を募集しています
DMM では一緒に働ける仲間を募集しています。この記事で紹介したような活動に興味のある方はぜひお気軽にご応募ください。