こんにちは、RightTouchでデザインエンジニアをしている @kan_dai です。
今回は、プロダクト内に混在していたデザインシステムを統一するために、Claude Codeを活用して移行を進めた話を紹介します。
大規模なリファクタリングのようなプロジェクトを、AIエージェントをどう活用しながら進めたのかを中心に書いているので、「物量が多くて後回しになりがちなタスク」や「やる価値はあるのに優先順位の低いタスク」と向き合っている方の参考になれば嬉しいです！
はじめに
僕がメインで開発しているQANT Webは、歴史的な経緯からフロントエンド開発に複数のデザインシステムを利用していました。
社内では新しいデザインシステムを「Sour」、旧デザインシステムを「Baisu」と呼んでいます。
Sourが導入されたのはQANT Webのリリース後でした。そのため、開発初期に作られたページはBaisu、比較的新しいページがSourといった状態のまま運用されていました。
しかしこの状態では、以下のような問題がありました。
- 同じような機能でもページによってUIが異なるため良くないユーザー体験になってしまう
- コンテキストスイッチや学習コストの増加によって開発体験の低下につながる
そのため、すべてのページを新しいデザインシステムで作り替えたいと常々考えていました。
ただ、リソースが限られていることやページとしての動作は問題ないことから、優先度が上がりにくい課題ではありました。
コーディングエージェントを利用した取り組みの開始
昨年、コーディングエージェントが盛り上がり始めたタイミングで、これを利用すれば旧デザインシステムから新デザインシステムへの置き換えを効率的に進められるのではないか？と考え、取り組みを始めました。
昨年9月時点での取り組みの様子は、TECH Streetさんの「AI駆動デザイン開発勉強会」で登壇した際にも紹介しています。レポート記事もあるので、もし良かったら合わせて読んでみてください。
この時点では14ページほど移行が完了しており、その後も時間があるときに他のページも進めていきたいと考えていました。
ただ、効率化できたとはいえ完全に自動化できるわけではなく、調整や確認にはそれなりに手間がかかります。
そのため、ご想像のとおり時間があるときに進めたいくらいのモチベーションでは続かず、他の開発が忙しくなったタイミングで移行作業は止まってしまいました。
AIアシスタント機能をきっかけに移行を本格的に再開
温度感が一気に変わったのは、全画面にまたがるAIアシスタント機能を入れることが決まったタイミングでした。
新旧のデザインシステムが混在したままでは、実装・動作確認・保守のどの観点から見ても辛くなることは明らかでした。
選択肢としては、以下の2つがありました。
- 全画面をSourに寄せてから機能追加する
- Baisu版のAIアシスタントの実装も作り、混在させたまま機能追加する
作業量を考えれば前者のほうが明らかに大変です。それでも、一度やり切れば今後の開発で大きな恩恵を得られることが目に見えていたため、しっかり腹を決めて全画面のSour化を進めることにしました。
現状把握と計画
最初にやったのは、Baisu（非Sour）で実装されている画面がどれくらいあるのか の棚卸しです。
Claude Codeを活用し、該当のディレクトリを読ませて、ルート名・URL・コンポーネントのパスをリストアップしてもらい、そのままGitHubのissueに起こしました。
結果、合計39ページ という規模感だとわかり、1週間ごとに対応するページを決めて進める計画を立てました。
元々ロードマップにない作業なので、あくまで他の開発と並行しながら進める前提で計画を立てています。
最終的にはスケジュールにビハインドしましたが、そもそもこうして計画を立てて可視化しなければ、今もこのプロジェクトは終わっていなかったはずです。
達成するために工夫したこと
ここからは、全ページ移行という物量との戦いを通して、開発面で工夫していたことを紹介します。
そもそも、このプロジェクトはある程度通常の開発と並行する前提だったので、普通に空き時間で対応していたら終わるはずがありません。
自然と、どうやったらスケジュール通りに終わるのかを考えて工夫をすることになりました。
ページの移行作業をSkill化
今回は、移行作業のほぼ全工程でClaude Codeを活用しました。
まず初めに、作業指示・コンポーネントの置き換えルール・classの置き換えルールをまとめてドキュメント化しました。
最初に試した昨年の段階ではAgent Skillsがなかったこともあり、対象ページの指示に加え、レイアウトや構成の近い参考ページを渡すと精度が向上するとわかっていたため、以下のようなプロンプトで作業していました。
`./baisu-to-sour/index.md` を参考に作業を行ってください。 対象ページ URL: ローカルのURL ページのエンドポイントのコンポーネント: ファイルパス 参考ページ url: ローカルのURL ページのエンドポイントのコンポーネント: ファイルパス
改めて移行を始めた時は、Agent Skillsがあったので、これらを試行錯誤しながら最適化していき、Claude CodeのSkillとしてまとめました。ドキュメント類もSkillの references 配下に移動し、Skillから自動で参照されるようにしています。
また、途中からはSkillを「プラン作成用」と「プラン実行用」の2つに分けています。これは後述する「並列作業」「非同期作業」と関係しており、プランだけ先に溜めておいて、あとから非同期で実行するという使い方をしたかったためです。
実行を簡単にする
Skill化したことで、/ から呼び出せるようになり、都度プロンプトを貼り付ける必要がなくなりました。
あまり準備をせずに実行できるハードルの低さは、移行作業を進めるうえで重要なポイントでした。
呼び出しを軽くするため、以下のような工夫も行いました。
- 元々はコンポーネントのパスも渡していたが、URLから探索させるようにした（サブエージェントを使うように指示）
- 実行フェーズでは、溜めておいたプランファイルを選ぶだけで進行できる
「サッと起動して、すぐ走らせられる」状態になったことで、次節の非同期作業とうまく噛み合いました。
できるだけ精度を高める
このSkillを使っても、それだけで完璧に終わるわけではなく、最終的な調整が必要でした。
そのため、自分が手を入れる範囲をできるだけ減らせるよう、Claude Codeの中で精度を上げるために以下のような工夫をしました。
- 先にプランを作らせたほうが体感で精度も高く、自分でのレビューも挟みやすいためプラン作成 → 実行の2ステップに分ける
- SkillのなかにCodexによるレビューを組み込み、指摘があれば自己修正させる
- 修正作業が発生した内容はAIにフィードバックしてドキュメントを更新させて、同じ修正を次回以降はAIが避けられるようにした
- Playwright MCPを使って画面の動作を確認させる
これらの工夫によって作業の精度が上がり、自分で手を入れる範囲を大幅に減らせました。 また、精度の面でいうと、リプレイスを再開した少し前にリリースされたClaude Opus 4.5のコーディング能力が非常に高く、助かりました。
並列作業と非同期作業
Skillを作成して移行作業へ取り組みやすくしたうえで、作業の進め方でも工夫をして効率化を図りました。
並列で複数のプランを進める
Xで見かけたポスト で、git worktree や multi clone は認知コストが高くて沼にハマりがちだが、プランを作成する部分は並行に進めやすいという投稿を見て、感覚的に納得感があったので試してみました。
前節のSkill化でも触れたとおり、プラン作成Skillとプラン実行Skillに分けることで、プラン作成を並列で進めやすくしました。
未実行のプランをどんどん溜めていき、溜まったプランの中から実行するものを選ぶだけで進行できる状態にしました。
作成したプランを非同期で進める
そして、溜めたプランは非同期で実行することを意識しました。
具体的には、昼休憩やMTGの前に溜めておいたプランの実行を走らせ、Claude Codeで作業を進めてもらうようにしました。プランを選ぶだけで動かせるため、指示の準備時間も不要で気軽に走らせられます。
作業が終わったものは、時間があればそのまま続きの作業に入り、すぐに確認できない場合はざっと見て明らかにおかしくなければ一度コミットして、後から作業するようにしました。
結果的にこの進め方は自分に合っており、移行作業が終わったあとの開発業務でも取り入れています。
確認やレビューはセルフで
今回のプロジェクトは、基本的にフロントだけの修正 ということもあり、確認やレビューも含めてAIを活用しながらセルフで回し切ることを意識しました。
人のレビューを挟むとどうしても進行が遅くなりますし、レビュアー側の負担も大きくなります。
一方で、操作できなくなるなどのデグレは致命的なので、動作確認だけはしっかり行うようにしました。また、機能的なデグレがないかのAIレビューはとくに意識して実行していました。
今回のような「フロントだけの修正なら大事故にはならないはず」という判断は、領域や規模によっては危険な場合もあるため、プロジェクトの性質を見極めたうえで自己責任として進めています。
完璧を目指さずにまず終わらせる
移行作業中は、どうしても 「ついでにここも直したい」「今なら綺麗に書き直せる」 という衝動に駆られることも多かったです。
ただ、やり始めるとキリがないですし、そちらにエネルギーを使うと本体の進捗が落ちてしまいます。
今回は、まず終わらせること を最優先にして、余計な修正は極力入れないようにしました。
無事に完走
このようなやり方で進めて、多少の遅れはありつつも、3月に無事に全ページの移行が完了しました。
まとめ
AIを活用した開発・並列や非同期での作業など、技術的な工夫をいくつか紹介しましたが、改めて振り返ると、最終的に効いたのはもっと単純な部分だったというのが正直な感想です。
やる気とオーナーシップを持つ
全ページSour移行は、やったほうが良いけれど、やらなくても短期的には困らないタイプのプロジェクトでした。こうしたプロジェクトは、やる気とオーナーシップを持った人がいないと進まないと改めて感じました。
スケジュールを作成して期限を決める
こういったサイドプロジェクトは、期限を切らず空き時間で進めるといったケースも多いと思います。
ただ、僕の場合は期限がないと頑張れないタイプの人間なので、スケジュールを作成して期限を切ったのは効きました。期限を守るためにどうすればよいかを考え始めると、やる気と工夫の両方がドライブされます。
AIエージェントの登場によって、「やったほうが良いけれど後回しになりがちな、物量の多い仕事」をかなり現実的なコストで終わらせられるようになってきたと、今回のプロジェクトを通じて強く感じました。
同じような課題を抱えている方の参考になれば嬉しいです！
採用情報
RightTouchでは、プロダクト価値を一緒に育てる仲間を募集しています。
AIを活用した開発フローや、プロダクト内の技術負債との向き合い方に興味のある方は、ぜひお気軽にお声がけください！
