350画面のUI統一、AIに任せたのは「セルフチェック」だった

はじめに

こんにちは。楽楽販売の開発を担当しているn-chocolatteです。

「AIを活用しよう」とはよく言われますが、いざ自分の現場に当てはめようとすると、「結局、どの作業に使えばいいのか」で手が止まってしまう。そんな経験のある開発者の方は、少なくないのではないでしょうか。

先にお伝えしておくと、今回私たちがAIを使ったのは実装そのものではなく、実装後のセルフチェック工程でした。
なぜそこに使ったのか——その判断の過程を、日々の開発にAIをどう取り込むか模索している方のヒントになればと思い、共有します。

本記事でご紹介するのは、ラクスが掲げる「AIネイティブな開発組織」という方針のもと、楽楽販売開発チームが「楽楽シリーズUI統一プロジェクト」の中で実践したAI活用の一例です。

テーマは「作業の性質を見極めて、AIの勘所を押さえる」。
AIに任せられる作業と、人間が責任を持つべき作業を見極め、適切な領域にAIを投入する。
今回のプロジェクトは、そうした判断の積み重ねの記録でした。

楽楽シリーズUI統一プロジェクトとは

「楽楽シリーズUI統一プロジェクト」は、楽楽シリーズの全商材でデザインを統一する、シリーズ横断の大規模な取り組みです。

きっかけはお客様の体験でした。
楽楽精算など他商材をお使いのお客様が新たに楽楽販売を導入された際、見た目や操作感が全く違うと、それだけで戸惑いの原因になります。
同じシリーズなのにデザインがばらついていて使いづらい――この見えない障壁を取り払うのが目的です。

実装としては、各商材が共通のデザインシステムに準拠する形でUIを再構築していきました。
楽楽販売では、特有のコンポーネントが必要な場面はデザイナーと相談しながら詰めていきました。

プロジェクトはチームで分担し、複数のフェーズに分けて進めました。
フェーズ1とフェーズ2の二段階に分かれており、それぞれ性質の異なる画面群を対象にしています。

フェーズ1: AIに任せられない領域

フェーズ1の対象は一般ユーザ向け画面です。
お客様が日常的に操作する、楽楽販売の中心的な画面群です。

このフェーズでは、56画面を約1年かけて対応しました。
想定以上に時間がかかったのは、対象の画面の作りが非常に複雑だったからです。
長年運用されてきた楽楽販売のコア画面は、既存のデザインやJavaScriptが複雑に絡み合っており、一つ手を入れると別の部分が壊れる(いわゆるデグレが発生する)リスクが常にありました。
UI統一とはいえ、見た目だけを揃えれば良いわけではなく、既存の挙動を維持しながら慎重に改修を進める必要があったのです。

このフェーズで、私たちはAIによる自動実装をほぼ使いませんでした。
理由は単純で、自動化に任せると既存実装を壊すリスクが大きすぎたからです。
画面ごとに個々の微妙な事情があり、汎用的なルールで一律に変換できる作業ではありませんでした。
人間が一つひとつのコードを丁寧に読み解き、責任を持って実装する。それがフェーズ1で必要なことでした。

このフェーズで得たのは、「AIに任せられない領域が確かにある」という現場の体感でした。
この感覚が、次のフェーズでの判断に繋がっていきます。

フェーズ2: 規模がもたらした新たな課題

フェーズ2の対象は設定系画面です。
管理者設定やDB設定など、お客様の日常操作からは少し離れた位置にある画面群です。

フェーズ1とフェーズ2の実績を、下の表で対比してみます。

	フェーズ1(一般ユーザ向け画面)	フェーズ2(設定系画面)
画面数	56	350
開発期間	約1年	約半年
AI活用	なし	Cursor Rulesによるセルフチェック

画面数が約6倍に増えたにもかかわらず、開発期間は半分に収まっている——この点にご注目ください。
ただ、これはAI活用だけによる結果ではありません。
対象画面の性質や実装ルールの明確さといった要因が大きく、後述するAIの役割はそのうちの品質担保を支えた一要素にすぎません。
両フェーズの作業の性質の違いが、この差に表れています。

フェーズ1が、複雑な画面ゆえに何度も手戻りを繰り返す作業だったのに対し、フェーズ2は、設定系画面の比較的シンプルな作りに加え、明確な実装ルールがあったことで、基本的に一画面の対応を一度で完結させられました。
フェーズ1ほど手戻りが発生せず、安定したペースで進められたのです。

フェーズ2では進め方も変えました。
350画面を半年で完遂するため、チームで手分けして大量の画面を並列に実装していく形に切り替えたのです。

ここで生まれたのが、新たな課題でした。
大量の並列実装を、どうやって品質を担保しながら捌くか。
実装そのものは機械的な作業なので、進めること自体は可能です。問題はその後のレビューでした。

350画面分のレビュー依頼が次々と上がってくる中で、レビュアーが毎回「アイコンが置換されているか」「不要なクラスが消えているか」「パンくず構造が揃っているか」を目視で確認していくのは、現実的ではありません。

一方で、レビューで本当に確認したいのは、UI崩れが起きていないか、特殊ケースで挙動が壊れないか、ユーザ体験として問題ないかといった、人間の判断が必要な部分です。
ルール遵守の機械的なチェックに時間を取られ、肝心の「人間の判断が必要な部分」に目がいかない。
これが、作業規模の拡大によって向き合うことになった課題でした。

なお、フェーズ2の実装を機械的に行えるようにするため、私たちは事前にチーム内で詳細な実装ルールを整理していました。
「z-indexの削除」「特定のCSSクラスから別のクラスへの置換」「<i class="fa ...">形式のアイコンから<span class="material-symbols-rounded">形式への置換」など、変換パターンが網羅的にドキュメント化されていたのです。

このドキュメントの存在が、次に紹介するAI活用の前提条件になりました。

AI活用の勘所: 実装ルールをAIに翻訳する

なぜ「セルフチェック」だったか

私たちがAIを投入した先は、実装そのものではなく、実装ルールに沿っているかのセルフチェックでした。

実装そのものをAIに任せる選択肢もありました。
ただ、フェーズ1で痛感したように、AIに任せると壊れる領域があります。
フェーズ2の画面は比較的シンプルとはいえ、リスクがゼロというわけではありません。
だからこそ、実装は引き続き人間が責任を持って行い、AIにはチェックを支援してもらう。
この役割分担が、フェーズ2の作業の性質に合っていたのです。

セルフチェックを支援する仕組みがあれば、実装者自身が手元で「ルールに沿っているか」を確認できます。
レビュー依頼が来る段階では、ルール遵守の観点でのチェックが一通り済んでいる状態になる。
レビュアーは、人間でなければ判断できない部分にレビューの労力を集中させられるようになります。

Cursor Rulesという仕組み

当時、楽楽販売開発チームではAIコードエディタとしてCursorを採用していました。
Cursorには「Rules」という機能があり、プロジェクトのルートディレクトリに特定の形式でルールファイルを置いておくと、AIが回答を生成する際にそのルールを常に参照してくれます。

このRules機能に、先ほどの実装ルールを記述しました。日本語で書かれた実装ルールを、AIが扱える形のルールファイルに整形する作業です。

完成したファイルは、変換パターンが before / after の具体例つきで章立てされたものでした。下記のような構造です。

## 不要なアイコン要素の削除
- 不要なアイコンは削除しなければならない
  - サンプル
    - before: (元のHTML)
    - after: (修正後のHTML)

観点のカテゴリとしては、以下のようなものがありました(具体的なクラス名やタグ名は伏せています)。

• 不要な装飾要素の削除ルール
• アイコン体系の置換ルール
• パンくず構造の修正ルール
• メッセージ表示パターンの置換ルール
• ページネーション構造の置換ルール
• パネル構造の追加・調整ルール
• JavaScript関数名の置換ルール

実装者は改修作業を終えた後、AIに「このルールに沿っているか確認してください」と依頼します。
すると、変更されたコードがルールに照らしてチェックされ、不足や誤りがある箇所を指摘してくれます。
これがフェーズ2の運用の中核でした。

ここで「決まったルールに沿っているかの確認なら、LinterやFormatterのような静的解析ツールで十分では？」と思われるかもしれません。
実際、不要なクラスの削除のような単純な置換であれば、その通りです。
ただ今回のルールには、パンくずやパネルの構造変更、メッセージ表示パターンの置換など、HTMLの文脈や画面全体の構成を踏まえないと正しく判定できない観点が多く含まれていました。
「どの位置にどの要素を足すべきか」は画面ごとに事情が異なり、機械的なパターンマッチだけでは拾いきれません。

変更内容の意味を汲んで柔軟に判断してもらえる点が、LLMにチェックを任せた理由でした。

ちなみに、現在ではチームのメインツールはVSCode + Claude Codeに移っています。
ツールは流動的に変わっていきますが、プロジェクト固有のルールをAIに与えるという考え方は、ツールが変わっても通用する普遍的なアプローチだと感じています。

運用してみての手応え

正直に申し上げますと、このAI活用によって「具体的に〇時間短縮された」「レビュー工数が〇パーセント減った」といった定量データは、私たちの手元にはありません。
それでも、現場での体感としていくつかの手応えがありました。

ひとつは、人間の目視という不確定要素が減ったことです。
実装ルールが大量にあると、人間がレビューで全てを抜け漏れなくチェックするのは難しい。
AIによる事前チェックが入ることで、この見落としリスクが大きく下がりました。
実際、フェーズ2全体を通じて、手戻りは少なかったという体感があります。

そしてもうひとつ、人間でなければ気づけないところに力を割けたことです。
ルール遵守のチェックをAIに任せられた分、レビュアーである私たちは「この画面の使い勝手はこれで本当に良いのか」「特殊なケースで挙動が崩れないか」といった、人間の判断が必要な観点に集中できるようになりました。

結果として、350画面の改修を約半年で完遂できました。
これはAI活用だけによるものではなく、対象画面の性質や並列開発しやすい構造、事前のルール整備など複数の要因が重なった結果です。

物量だけ見れば、フェーズ1のペースのまま単純計算すると何年もかかる規模です。
AIにセルフチェックを任せ、人間が本質的なレビューに集中できる体制を作れたことが、この規模を半年で進める支えになりました。

正直に言えば、大量の画面をさばき続ける作業は、地道でなかなか骨が折れるものでした。
それでも、無事に完遂できたときの安堵と達成感は大きかったです！

振り返って見えたパターン

プロジェクトを終えてから振り返ると、いくつか一般化できそうな学びが見えてきました。

作業の性質とAI活用の相性

フェーズ1とフェーズ2の対比からは、作業の性質によってAIの勘所が変わることがはっきり見えました。
複雑で固有性が高い作業は人間が向き合う方が結果的に効率が良く、機械的でルール化でき量も多い作業はAI支援の効果が出やすい。

ただ、この見極めは机上では難しく、現場で手を動かして得られる感覚だと思います。
フェーズ1で複雑な画面と格闘したからこそ、フェーズ2でAIを投入する判断ができたのです。

AI活用は、人間の作業との連携で成立する

もう一つ、振り返って気づいたことがあります。
「AI活用」は単独のアクションではなく、人間の作業と組み合わさったワークフロー全体である、ということです。

今回のプロジェクトを工程ごとに分解してみると、こうなります。

1. 実装ルールを決める(人間の作業)
2. ルールをAIが扱える形に翻訳する(人間の作業)
3. AIによるセルフチェック実行(AIの作業)
4. 人間でなければ気づけない部分に集中してレビュー(人間の作業)

このうち、純粋に「AIの仕事」と呼べるのは3だけです。それ以外は全て人間が行っています。
それでも、3を組み込むことで全体の効率と品質が大きく変わる。

特に2の「翻訳作業」は肝になる工程でした。AIが解釈しやすい構造に整え、具体例を添え、抜け漏れなく記述する。
今回うまくいったのは、AIが優秀だったからではなく、AIが判断できる形までルールを整えたからだと感じています。
少なくとも今回のケースでは、成否を分けたのはモデルの性能そのものよりも、「AIに何を、どう渡すか」という設計の方でした。
渡す側でどれだけ作り込めるかは、これからのAI活用でも軽視できないポイントだと思います。

そう考えると、今回行ったことは「AIに仕事を任せた」というより、AIが得意な領域へ仕事を再分配した、と言うのが近い気がします。
大量のルールを機械的に適用していくところはAIへ。
ルールを定義すること、ルール化できない例外を判断すること、最終的な品質に責任を持つことは、引き続き人間へ。
私たちがAIに任せたのは「セルフチェック」だった——その一点に、この再分配の線引きが表れています。

おわりに

楽楽販売開発チームが楽楽シリーズUI統一プロジェクトで実践したAI活用について、なるべく等身大にお伝えしてきました。

派手な成果や劇的なBefore/Afterはない記事だったかもしれません。
それでも、こうした地に足のついた判断の積み重ねこそが、AIネイティブな開発組織の実像なのだと思っています。
ツールはこれからも変わっていくでしょうが、AIをどこに使うかを考え続けること、その姿勢は変わらないはずです。

本記事が、同じように現場でAIと向き合う開発者の方々の参考になれば嬉しいです。
最後までお読みいただき、ありがとうございました。