【イベントレポート】AI駆動デザイン開発勉強会～各社の取り組みや課題から学ぶ会～

こんにちは、TECH Street編集部です！

この記事では、2025年9月25日（木）に開催した「AI駆動デザイン開発勉強会～各社の取り組みや課題から学ぶ会～」の登壇者の発表内容の紹介と、イベント中に回答できなかったQ&Aを記載しています。

登壇者はこちらの方々！

菅家大地

株式会社RightTouch
デザインエンジニア

DTPデザイナーとしてキャリアをスタート後、Webデザイナーへ転身。Webコンサル会社でデザインから実装まで幅広く担当し、その後は株式会社TAMでフロントエンドエンジニアとして大手企業のWebサイト実装に従事。プロダクトに深く関わりたいという想いから、現在はRightTouchの1人目デザインエンジニアとして、UI実装を中心に品質や体験の向上に取り組んでいます。。

篠崎真由美

パーソルキャリア株式会社
UI/UXデザイナー

2022年2月よりパーソルキャリア株式会社に入社し、doda法人向け統合プラットフォーム「doda CONNECT」の新規企画領域でUIUXデザインを担当。これまではWeb/UIUXデザインを中心に、スタートアップ・新規事業開発現場で一人目のデザイナーをしたり、SIerでの法人向けデザイン導入支援などに従事してきました。

近藤英明

株式会社はてな
コンテンツ本部第2グループブログチーム
ディレクター

- Web制作会社にて多数のWebサイト / システムに携わる
- SESとして事業会社のWebサービスを担当し、CS領域を担当
- 2023年はてな入社。はてなブログのサービス運用と並行してはてなCMSの開発に携わる

プロダクト内で混在するUIと技術スタックをコーディングエージェントで整理できるか？

不確実性の時代にみんなで試したFigma × MCP × Cursor ハンズオン「遠くに行きたいならみんなでいけ」の実践

Figma to はてなCMS」開発の裏側〜AI機能開発における課題とアプローチの変遷〜

Q&Aコーナー

（Q）登壇者の皆様にご質問です。品質管理面でAIが生成したコードやデザインをどうレビュー・テストしているのでしょうか？また、品質保証フローにAIはどのように組み込まれているのでしょうか？

菅家：品質管理のプロセス自体は、人が作成した成果物と大きくは変わりません。AIが出力したものも最終的には人間が確認しています。品質保証フローをすべてAIに任せるのはまだ不安がありますが、ユニットテストの段階ではAIを活用しています。

篠崎：人の目でレビューしています。製造コストは短縮できる代わりに、レビューコストが従来より増えたと実感しています。
最近、cursor talk to figmaというプラグインを使ってAIのレビュー内容を自動でFigmaに返す機能が話題でした。今はその機能にも期待しています。

近藤：サービスのローンチ前は、AIが作ったものは必ず人が確認しています。
品質保証フローには評価用のAIを連携させていますが、最終的に「サービスとして良いかどうか」を判断するのは人間の確認と意思決定が重要だと考えています。

（Q）登壇者の皆様にご質問です。失敗からの学びについて実際に失敗した事例や導入効果が出なかった施策はございますか？また、そこからどのような知見を得られましたか？

菅家：AIに依頼する際、指示が曖昧だと期待した結果は得られないことを実感しました。そのため、やりたいことを明確に言語化する必要性を強く感じ、実際の業務でも意識して実践するようになりました。

篠崎：失敗までまだ行きついていないかもしれません。検証を続けている段階です。
ハンズオンの話でいうと、cursorがFigmaの情報をうまく読み取ってくれないという不具合が一時的に発生したことがありました。そのときは事前確認をしておけば…！と思いました。

近藤：そもそも「本当にAIでやるべきか？」という段階からスタートしました。結果として、想定以上に複雑なAIシステムを構築することになり、その過程自体が学びになりました。現在もプロダクトをリリースしている段階なので、今後も継続して課題と成果を見極めていきたいと考えています。

（Q）登壇者の皆様にご質問です。導入効果と評価についてAI導入によってどの程度の効率化や品質改善を得られましたか？またその計量に関しては定量的な評価（開発工数削減率、バグ減少率など）をどのように測っていますか？

菅家：現状は各々の実感ベースで定量的なところはこれから試行錯誤して測っていこうと考えています。

近藤：この機能はリリースして間もないため、多くのユーザー様にご利用いただいた上での厳密な定量評価は、まさにこれからのフェーズとなります。「開発工数が何パーセント削減された」といった具体的なデータは、まだ収集段階にあります。

（Q）デザインシステムの刷新によって、実際にプロダクト開発スピードやチーム間の認知負荷にどの程度影響がありましたか？

菅家：認知負荷によって一時的に開発スピードは落ちていたと思います。が、新しいデザインシステムの方がコンポーネントの充実度など全体的な品質が高いため、慣れた後は開発スピードも品質も向上したと思います。

（Q）エージェントがうまく対応できなかったケースはありましたか？その場合どうリカバリしましたか？

菅家：うまく対応できない場合は多いです。使えないなと思った時は全部捨てて新しい指示をすることが多いです。ある程度使えそうな時はそこから自分で手直しをします。

篠崎：デザインtoコードだとうまく対応できないのが基本でした。画像はどうやっても生成してくれなかったり、むりやりSVGで形作ったり。まだできてませんが、他所においたリソースを読み込む形になるんだろうなと。

近藤：元々Figmaのデザインを忠実に、かつ常に一定で再現することは難しいので、デザインコンポーネントとしてではなく、取り込んだデザインを編集してマスタとするコンセプトにしています。

（Q）登壇者の皆様にご質問です。ツール選定の基準についてなぜ現在利用しているAIツール（Cursor、MCP、エージェントなど）を選んだのでしょうか？その他の候補との比較検討のポイントはどのようにように判断、洗い出しを行ないましたか？

菅家：基本的に新しいものが出てきて話題になっていれば試してみることが多いです。その上で実際に使用して良かったものが現在利用しているものになります。

篠崎：そのとき一番話題だったから、になります。いまは標準化を期待するより、既存を覆す新しいコンセプトが感じられるものを検証していくフェーズだと考えています。

近藤：話題性と併せて手に取りやすい環境だったもの、というのもあります。他の施策やプロダクトで実際に使用経験のあるものだと選びやすいです。

（Q）Not AI駆動からAI駆動になって、一番の恩恵、そして実はこんな弊害が...もあれば聞いてみたいです。

菅家：手をつけるのが億劫な作業でもとりあえずAIに投げてみるという着手ハードルを下げることができたのが一番の恩恵かもしれません。
弊害で言うと、AIの作ったものは一見良さそうなので確認のハードルも下がってしまって、結果的に良くなかったということがあります。

篠崎：「こんなことがやりたい！」がすぐできるようになりました。以前はナレッジを調べて、周辺情報も探索して、ベストプラクティスを模索する時間はどうしても圧縮できませんでした。AIが登場してからは実現性高い方法がまず最初に提案されるので、その次の試行検証を重ねる時間を増やすことができたとおもいます。ただ、判断を連続して求められるので思考負荷が高まって、それにまだ慣れません。

近藤：すべてのロジックをルールベースで組むことに比べれば大幅に工数の削減ができる時代になったと思います。一方で生成されるものはばらつきがあり精緻なものではないをいうのを許容できるかどうかが大きな見極めのポイントになると思います。

（Q）開発「体験」への影響の課題、めちゃわかる。これを解決するために一番苦労した点と、「これが最強の施策」があればお聞きしたいです。

菅家：結局優先度が下がってしまうので、ちゃんと時間をとって進めることが1番の苦労ですね。最強の施策は僕も聞きたいです(笑)

（Q）菅家大地さんにご質問です。実際のリプレイス作業で「一番役に立ったAIタスク」と「まだ弱い領域」はどこかご教授いただけると幸いです。また、デザインシステム更新の優先度を低コストで上げる工夫がございましたら共有をお願いいたします。

菅家：特に役立ったのは Playwright の MCP 連携です。通常、AIに置き換え作業を依頼すると「完了」と返ってきても実際にはエラーで反映されていないことがありました。MCPを利用することで、その確認や自動化がスムーズになり、作業の確実性が大きく向上しました。
フロントエンドの細かいCSSスタイリングはまだ弱さを感じています。自分で手直しするシーンも多いです。

（Q）なるほど、リプレースに効果的ですね。righttouchさんは新規開発も基本すべてAI駆動ですか？

菅家：メンバー全員が開発のどこかのフェーズでは必ずAIを活用していると思います。その割合がどのくらいかは個人によって異なります。

（Q）メイン開発と並行してリプレイスを進める中で、優先度の衝突や「結局誰もレビューしないコード」が発生してしまった！みたいなことはありましたか？

菅家：基本的に優先度は低いので衝突はしないですね。優先する作業が発生したら後回しになってしまいます…
誰もレビューしないコードは今のところはないです。

（Q）「もう二度とやりたくない」エージェント活用の地雷・落とし穴ってありましたか？

菅家：何も考えずに全ての作業を許可していたらローカル開発環境が起動しなくなった時があり、あの時は焦りました

（Q）コーディングエージェントにページのリプレイスを任せることで、自分が思っている実装と違かった場合はどのように修正していますか？

菅家：程度によります。全然違うなというときは、イチからやり直させることもあります。AIの出力は一定ではないため、複数回試して精度を高めることもあります。細かい修正であれば、自分の手で直すこともあります。

（Q）自社の有志さんがMCPサーバーを開発、がキーだと思いますがどれくらいの大変さでしょうか。それもClaude Codeで開発されたのでしょうか

菅家：私が開発に携わっていないので明確にはいえませんが、Slack上で「やってみます」のメッセージがあってから２～３日で完成していたので、比較的やりやすい方法で動くものを作ったのではないかと推測しています。
Claude Codeを利用していたかどうかについては把握していません。

（Q）将来的にデザイナーの日常ワークフローにMCPやAIコーディングが自然に組み込まれるためには、どんな“前提条件”が整う必要があると感じましたか？

篠崎：前後の工程と成果物が連結されることが第一条件だと考えます。インプットされたデータを受け取ってデザインとして形づくり、場合によっては前工程に戻して前校正の成果物を改善して再度受け取る。アウトプットしたデザイン資産も同様に、後工程にシームレスに渡せて、修正があればそのままマージできる。それがないと現状の手作業を続けることになると思いました。

（Q）Figmaからコード化する際に「思ったUIと違う」「動かない」といったズレは発生しましたか？

篠崎：はい、頻繁に期待したのと違うズレはありました。明示的な指定（カラーやフォント）はそこそこ再現されますしたが、余白のズレ、ボーダーの有無、角丸の解釈などで不一致が生じました。どのような違いでズレが発生するのか、今後調査・検証を進めたいです。

（Q）篠崎さんデザイナー視点で「ここは本当に心理的ハードルが高かった」ポイントが気になります！

篠崎：黒い画面（コマンドライン環境）に対する苦手意識とエラーメッセージが出た時の対応が難しいと感じました。

（Q）ワンオフもののこだわりUIなんかだと、AI開発だと細かなこだわりが指示上でも難しいので、結局デザイナーもエンジニアもゴリゴリ作業で対応、みたいなあるあるはやっぱありますか？

篠崎：あると思います。AIの強みをどこに活用するかによると思いますが、ワンオフである必要性があるならば、作業者がAIだろうと人間だろうとコストを注ぎ込むところなのでゴリゴリ作業は発生するとおもいます。

（Q）一連の体験会を企画する工数がめちゃめちゃかかりそうですごいなと思いました。。。通常のプロジェクトと並行しながら体験会実施で参加者もたくさんいてすごいですね。

篠崎：単純なワークの設計であれば、そこまで時間はかかりませんでした。特に、ChatGPTを活用することで準備作業を効率化できたのが大きかったです。
実際に参加者の時間をムダにはできないと思い、トライアル的に何度も確認作業を行ったので、そこは時間が掛かりました。

（Q）ADRのドキュメントも作っているのでしょうか？

菅家：ドキュメント作成はAIの得意分野なので色々なドキュメント作成に利用していますが、現状はADR作成には活用していないです。

（Q）篠崎真由美さんにご質問です。デザイナーが実装体験する際、どの部分で一番ハードルを感じていますか？また、短時間でのAIの成果物と、実運用での活用にはどんなギャップがありますか？（手直しが多く、結局工数が変わらないなどは発生していますか？）

篠崎：ハードルが高かったのは開発環境の構築です。ターミナルでコマンドを入力した経験がないデザイナーが多かったため、エンジニアのサポートを受けながら進めました。また、私が関わっている範囲では、AIの成果物を実運用にそのまま活用する段階にはまだ至っていません。運用レベルに適用するのは今後の課題です。

（Q）篠崎さんに質問です。#3でドキュメントドリブンのコード生成をされたとのことですが、ドキュメント、スタイルガイドと画面設計書はどうやって出力したのですか

篠崎：スタイルガイドと画面設計書はFigma上にあるデザインデータを、用意したフォーマットを基にcursorへ指示を与えて出力しました。フォーマットはChatGPTに「標準的なものをマークダウン形式でサンプルとして用意して」と依頼して生成しました。スタイルガイドはaigisの思想に基づくように構成してもらいました。

（Q）Cursorでなく、VSCodeでもハンズオンはできますか？

篠崎：VSCodeでも可能です。Cursorを選んだ理由は、環境設定がより簡易的だったからです。IDEに不慣れなデザイナーが少なくないので、そこの壁が低い方を選びました。自由度はVSCodeの方が多いので、両面で模索は続けます

（Q）Figmaのデザインからバイブコーディング、スタイルガイドを生成する上で、Figmaデザインファイルの内のルール（レイヤー構造、命名規則、スタイル、バリアブル、コンポーネント）などで気を付けた方がいい点などはありますか？

篠崎：一般論になりますが、オートレイアウトで組むことは必須だとおもいます。構造化されてることが重要なので、トークン化できるものはして、名前空間もちゃんと設計して、ハードコーディングしないで済むような組み方すると良いんだろうなと感じました。

（Q）近藤英明さんにご質問です。PdMとして「リリース優先」と「品質確保」のバランスをどのように判断されていますか？品質問題はどの層（UI/UX、一貫性、アクセシビリティ、パフォーマンスなど）で最も多かったのでしょうか？

近藤：まず重要なのは、リリースを確実に進めることです。そのうえで、Figmaからのインポートについては用途を明確にし、状況に応じて柔軟に使い分けています。たとえば、一貫性の確保は難しいため、スポット的にラフな利用にとどめたり、一度CMSに取り込んでから視覚的に修正できるようにしたりといった工夫を取り入れています。結果として、どうしても発生してしまうばらつきについては、後工程でCMS上で調整可能な状態を整えておくという考え方を重視しています。

（Q）AI機能の「できること」と「ユーザーが期待すること」のギャップにどう折り合いをつけましたか？

近藤：基本的な考え方としては、AIだけでは解決できない部分をCMSでどのように補完していくかに重きを置いています。現時点は、「折り合いをつけた」というよりは、今後も引き続きチャレンジしていく段階にあると考えています。

（Q）「AI機能をCMSのような商用プロダクトに入れる際に欠かせない前提条件」は何だと感じましたか？

近藤：用途を明確にすることだと思います。今現在、あくまでAIは補助的な役割の範疇を出ないので、CMSによる工程のどの部分を任せるのか、の認識がずれないようにする必要があります。

（Q）デザインのプロンプトを考えるのに、Webデザインの仕方の本のチェックリストを参考にしていますか？どのような本を参考にしたのか、本のタイトルも教えてほしいです、

近藤：していません。プロンプトの中でエージェントにペルソナ設定をしているのみです。

（Q）神プロンプトは不採用としても、どの程度のプロンプトルールを設けていますか？

近藤：主なルールは次の通りです。
ペルソナ設定: Generatorは「デザイナー」、Evaluatorは「評価者」のように、エージェントごとに役割を設定する。

簡潔な要件: 指示は箇条書きにし、失敗するたびに要件を追加して改善する。
出力形式の強制: 機械が読みやすいように、出力はJSON形式に指定する。

（Q）はてなさんに質問です。コードの正しさではなく、figmaデザインが正しく反映されている、ということを評価AIはどのように知るのでしょうか。何かを学習したのでしょうか

近藤：正解データを学習させているというより、APIを活用し「考える仕組み」を活用しています。ルールを固定的に与えるのではなく、AIに状況を判断させる仕組みに振り切って設計しています。

（Q）デザイン自体をAIに考えさせるようなアプローチはしていますか？

近藤：理想的だなと思いつつ、まだ正式なサービスとして取り入れる段階ではないのかなと考えます。

（Q）近藤さんに質問です。聞き逃していたら恐縮なのですが、generatorとevaluatorのフィードバックループのワークフローは具体的にはどんなアーキテクチャ上で動かしていたのでしょうか？

近藤：設計上の工夫として、「最後までコードを書き切らなくてもよい」仕組みを取り入れました。途中までで出力が終わっても会話を繰り返すことで、生成と評価をループさせる形を実現しています。

（Q）登壇者の皆様にご質問です。画面を実装する上でAIエージェントの実装の精度を上げるためにはズバリ何が一番大事だと思われますか？

菅家：自由に実装させてしまうと上手くいかないことが多いので、デザインシステムやFigmaのデザインデータなどのAIが実装する上での「制約」をしっかりと作りこみ、その範囲で実装させることができるかだと思います。

篠崎：AIが読み取るデータが構造化されてること、でしょうか。デザインデータを100%構造化するのは難しいと感じますが、構造化できるところとそうではないとこを分けることはできるとおもうので、まずはその仕分けかなとおもいました

近藤：「実験事例を収集すること」です。
うまくいかない原因を特定することが最も難しく、それを解決するためには、以下の点が重要だと述べられています。
実験と記録の繰り返し: 良いプロンプトを見つけるため、実験を繰り返すことが重要です。その過程でデータ、結果、考察を「実験ノート」として記録し、改善を重ねる必要があります。
実験しやすい環境: LangGraphやLangSmithなどを活用し、実験を効率的に繰り返せる環境を整えることも大切です。