※本レポートは、2025年9月に開催された発表内容をもとに作成されています。
登壇者はこの方
菅家 大地
株式会社RightTouch
デザインエンジニア
DTPデザイナーとしてキャリアをスタート後、Webデザイナーへ転身。Webコンサル会社でデザインから実装まで幅広く担当し、その後は株式会社TAMでフロントエンドエンジニアとして大手企業のWebサイト実装に従事。 プロダクトに深く関わりたいという想いから、現在はRightTouchの1人目デザインエンジニアとして、UI実装を中心に品質や体験の向上に取り組んでいます。。
菅家：株式会社RightTouchでデザインエンジニアを務めています。菅家と申します。もともとデザイナーとしてWeb業界に入り、その後フロントエンドエンジニアとして働いた後、現在はRightTouchで一人目のデザインエンジニアとして主にフロントエンドのUI実装をメインに従事しています。
また、宮城県在住で、仙台フロントエンドユーザーグループという地元のコミュニティ運営に関わっているほか、RightTouchが東京の会社であることから、Product Engineer Sessionという主に東京で開催されているプロダクトエンジニア向けのコミュニティ運営にも携わっています。
本セッションでは、プロダクト内で混在するUIと技術スタックをコーディングエージェントで整理できるかというテーマで、実際の取り組みと結果を共有します。
会社紹介・プロダクト紹介
株式会社RightTouchについて
株式会社RightTouchは2021年12月に設立された、まだ4年弱の会社です。従業員は52名（2025年7月時点）の規模で運営されています。
ミッション
「あらゆる人を負の体験から解放し、可能性を引き出す」というミッションを掲げています。一般生活者と企業・サービスの間にある「負の体験」を解決することで、企業やサービスの本来価値が伝わり、豊かな生活者体験が広がり、経済が活性化することを目指しています。
事業内容：カスタマーサポートプラットフォーム
カスタマーサポートの領域で、一般生活者と企業が提供するサービスをフルポテンシャルで提供できるようなプロダクトを展開しています。
カスタマーサポートというと、一般的には問い合わせをしてオペレーターに対応してもらうイメージがありますが、それだけではありません。問い合わせ前にユーザーがWebサイトで困りごとがあった時にWebツールでサポートしたり、実際に問い合わせがあったものを分析したりと、カスタマーサポート全体に関わるプロダクトを展開しています。
RightSupport by KARTE
「RightSupport by KARTE（※1）」は、RightTouchのファーストプロダクトです。
Webサイトにタグを入れることで、エンドユーザーが実際にどういうことで困って、どういう問い合わせをしてきたのかがレポートで見られるようになっています。そこから、困っているユーザーに対して適切なサポート（例えばポップアップでよくある質問を表示したり、チャットに誘導したり）を提供できます。
さらに、実際に提供したサポートがどういう効果があったのか、問い合わせが減ったのかといったデータが見られるようになっており、カスタマーサポート全体のPDCAを回せるプロダクトとなっています。
（※1）「RightSupport by KARTE」は2025年10月1日より「QANT Web」に刷新しました
異なるUIや技術スタック混在問題
プロダクトの歴史
RightSupport by KARTEは2022年3月にβ版としてリリースされました。このプロダクトは、元々「KARTE」というCXプラットフォームがあり、そのプラットフォームに乗る形でRightSupportというプロダクトを提供しています。
最初の技術スタック（BAISU）
リリース当初は、KARTEで使っていた「BAISU」というデザインシステムを使って開発が進められました。
- フレームワーク：React
- スタイリング：Vanilla Extract（CSS in JS）
- UIコンポーネント：BAISU
新しい技術スタック（Sour）
2023年10月、リリースから約1年半後に、KARTEプラットフォーム全体で新しいデザインシステム「Sour」が適用されました。
- フレームワーク：React（変わらず）
- スタイリング：Tailwind CSS
- UIコンポーネント：Sour
見た目の変化としては、全体的にフォントが大きくなり、メリハリが効いて、少しモダンな感じのデザインになっています。
混在が発生した経緯
新デザインシステムを適用する際、元々のページを一気に変えるということはせずに、Reactなので混在ができる状態であることから、新しいページは新しいデザインシステムで作っていくという方針で進められました。その結果、古いものと新しいものが混在・共存する状態となりました。
何が問題なのか？
この混在状態には、いくつかの問題がありました。
ユーザー体験への影響
ページによってUIが異なるため、ユーザー体験に影響があります。RightSupportの場合は色味などはそこまで変わらないため、大きく変わるわけではありませんが、やはり影響はあると言えます。
開発体験への影響
開発者側への影響が大きく、以下のような問題がありました。
- コンテキストスイッチの発生：古いページを全く触らなくなるわけではなく、バグがあれば修正が必要で、ページの変更なども発生するため、異なる技術スタックの開発を行き来することになり、コンテキストスイッチが発生してしまいます。
- 学習コストの増加：新しく入社した方などは、古い技術スタックはそもそも知らなくていい情報のはずですが、それに対する学習コストがかかってしまいます。
- 開発スピードへの影響：デザインシステムによって、新しいデザインシステムにはあるコンポーネントが古い方にはないといった状況があり、開発に時間がかかってしまい、開発スピードに影響が出ます。
統一できないのか？
できるならもちろん統一したいという思いはありましたが、以下の理由で実現が難しい状況でした。
- リソースの制約：スタートアップでリソースも限られているため、手が回らないというのが正直なところです。
- 工数の問題：作業を実際にやろうと思うと、意外と工数がかかってしまいます。
- 優先度の問題：元々ページとして動作に問題があるわけではないので、デザインシステムのリプレイス作業は優先度が上がりにくいという状況でした。
AIコーディングツールを使って整理
コーディングエージェントの登場
2025年になってから、CursorやClaude Codeのようなコーディングエージェントが登場しました。RightTouchでも積極的にこれらのツールを使っていく方針でした。
これらを使うことで、デザインシステムのリプレイスを効率的に行うことができるのではないかと考え、試してみることにしました。
前提として、デザイナーが作ったFigmaのデザインデータはなく、あくまでも既存の古い技術スタックのページを新しく置き換えることがメインとなります。
デモ紹介
※Claude Codeを使った実際のデモが紹介されました。対象ページは「リーズン」というページで、どういう問い合わせがあったのかをタグ付けできるページです。このページを、構成が非常に似ている「サポートアクション」というページ（ポップアップを出すなどの機能を持つページ）を参考に置き換える作業が実演されました。デモでは、移行用のドキュメントを作成し、そこに記載されたルールに従ってCSSを変更したり、コンポーネントを置き換えたりする様子が示されました。
MCPの活用
※デモの中で、Sourの「MCPサーバー」が登場しました。MCPとは、AIがアプリケーションや別のツールにアクセスするためのツールです。これを使うことで、新しいデザインシステムの情報を取得しに行き、コンポーネントがどういうプロパティを使えるのかを確認することができます。
Playwrightによる自動確認
※さらに、Playwrightという実際のブラウザをプログラムから操作できるライブラリを使って、AIが自動でページを確認します。エラーが発生している場合は、AIがそれを検知して自動で修正を行います。
この自動確認と修正のループにより、人間が見に行ってエラーで表示されていなかったという状況を発見してから追加指示を出すという無駄なプロセスを省くことができます。
やったこと・やり方
効率的にリプレイスを進めるために、以下のアプローチを取りました。
1. 移行用のドキュメント作成
前提条件やルールをまとめた移行用のドキュメントを作成しました。「コンポーネントAはコンポーネントBに置き換える」のような決まったルールは、AIにドキュメントを作ってもらいました。
2. 参考ページの提示
指示する時に、構成が近い参考ページを提示するようにしました。
3. デザインシステムのMCPで移行をサポート
自社の有志が開発したデザインシステムのMCPを活用し、移行をサポートしました。
4. Playwright MCPで実際のページを確認
Playwright MCPを使って、AIに実際のページを確認させるようにしました。
段階的な精度向上
実際には、これらのアプローチを一つずつ試しながら、段階的に精度を上げていきました。
結果その1（ルールのみ）
最初に、ドキュメントを作って「それを参考に新しく移行してください」と指示しただけでは、使い物にならない結果となりました。
結果その2（ルール + 参考ページ）
次に参考ページを提示すると、ルールだけに比べて明らかに精度が向上しました。
結果その3（ルール + 参考ページ + Playwright MCP）
Playwright MCPを使って実際にAIにブラウザを確認させるようにしたところ、だいぶ精度が向上して、少し調整したら使えそうなレベルになりました。
やったこと・やり方（2回目）
特に精度を上げるのに効果があったポイントは資料の赤文字の部分です。
結果と所感
7月から活動を始め、基本的にはメインのタスクがあるのでそちらと並行で進めて、14ページほどのリプレイスが完了しました。
これを多いと見るか少ないと見るかは個人の感覚次第ではありますが、メインの開発タスクを進めながらであれば、かなり良い成果だったと言えます。やらなければそのままになっていたはずなので、良かったという評価です。
人のチェックと調整は必須
正直、ゼロから百まで全て任せるのは難しく、人のチェックと調整は前提となります。
工数削減とリプレイスのきっかけ
全体的にかかる工数は少なくなりますし、きっかけがなければそのままズルズルとやらずに行ってしまうリプレイス作業に手をつけるきっかけとしても良いと感じました。
並行作業の難しさ
これはやり方の問題で個人差が完全にあると思いますが、メインの開発の裏で走らせておくという完全な並行作業は難しかったという感想です。コーディングエージェントが作業している間、気になって「終わったかな？」と見に行ったり、終わったら終わったで気になるところがあって修正したくなったりと、そこでコンテキストスイッチが起こり、集中力が途切れるのがつらかったです。
今後試したいアプローチ
業務が終わった後にコーディングエージェントにお願いして、朝に確認するというやり方を試すと、より効率がいい進め方ができるのではないかと考えており、今後試してみたいです。
▼▼ ぜひ他登壇者の発表レポートもご覧ください！
