AIに共通部品を作らせるとき、どこまでまとめるか

株式会社ファストコーディングでフロントエンド開発と技術戦略を担当している黒田です。

AI導入初期の失敗について書いた記事で、既存のCSSを十分に共有しないまま新しいパーツを生成し、強い上書き指定が増え、CSSの大部分を書き直した例を紹介しました。目の前の表示を合わせるだけでは、既存の設計との関係が抜ける、という失敗です。

AIに共通部品を作らせるときも、同じ問題があります。「似ているカードを共通化して」とだけ指示すると、どこまでを同じ部品として扱うかが曖昧です。全部まとめるのか、同じ土台の上に別の部品を作るのかで、次の修正の影響も変わります。

今回は、ニュースカードと商品カードを仮定例に、AIへ何を定義してから実装させ、生成後に何を検査させるかを整理します。

AIに、見た目と役割の違いを調べさせる

二つのカードは、どちらも画像と見出しを持っています。ただ、ニュースには公開日、商品には価格や在庫の状態がある。形が似ていても、持つデータと表示条件は同じではありません。

この違いを整理しないままAIに一つのカードへまとめさせると、商品だけに必要な在庫切れ表示まで共通部品へ入り、条件分岐が増えるかもしれません。ニュースに在庫情報が出てしまえば不具合ですし、正しく分岐できていても、修正時の確認範囲は複雑になります。

私なら、実装前にFigma、仕様、既存の部品とスタイルをAIに参照させます。そのうえで、共通に使う候補と、分ける理由を一覧にさせます。画像と見出しの余白は共通の候補、公開日と価格・在庫は別に持つ候補、という形です。

ここで欲しいのは、同じ形を見つけたという報告だけではありません。使うデータ、状態、操作、既存ルールまで比較した結果です。共通化の候補をAIに調べさせても、仕様が分からない部分は未確定として残します。

例えば今回は、画像枠と基本の余白を共有し、ニュースと商品の表示内容は別に持つ方針を選んだとします。これは一つの設計例で、すべてのカードへ当てはめる正解ではありません。

AIには、この方針を具体的な条件として渡します。既存の共通部品があるなら新しく作り直さずに参照すること、在庫状態は商品側で扱うこと、共通の余白を変えたら両方へ反映することまで揃えます。

今回の実装条件なら、次のように書けます。

この条件があれば、AIがどの単位で部品を生成すべきかを追えます。見た目を揃えるための共通部分と、商品だけを変える部分を分けて指示するわけです。

逆に、二つのカードが同じデータ構造と動作を持ち、今後も一緒に変える仕様なら、より大きな単位で共通化する案もあります。分ければよい、まとめればよいと決めつけず、AIが実装に使う境界を明示したいと考えています。当社の公開工程でも、構造と共通部品を先に定義し、AIがその定義を参照して実装します。(*1)

生成したカードが一度表示できたら終わり、にはしません。共通化が狙いどおりかは、片方だけを変える場面でも確かめたいところです。

今回なら、共通の余白を変えた場合は、ニュース一覧と商品一覧の両方に反映されるはずです。一方、商品側へ在庫切れ表示を加える変更では、ニュース側に在庫情報が出てはいけません。この二つを、別の期待結果として検査に入れます。

AIへコード修正とブラウザ操作を実行させる環境なら、修正後の一覧ページを開かせ、対象のカードと状態を比較させます。ニュースと商品それぞれの画像なしや長い見出し、商品側の在庫切れなど、仕様で定めた条件も対象にします。

例えば、検査には次の組み合わせを残せます。

変更・状態	確かめる結果
共通の余白を修正	両方の一覧で、新しい余白ルールが反映される
商品の在庫切れ表示を修正	商品側は指定どおり表示され、ニュース側には在庫表示が出ない
画像なし・長い見出し	各カードの仕様を保ち、文字切れや重なりがない
関連する画面幅	共通スタイルの修正で、他の対象幅が崩れていない

この記録があれば、「共通化できました」というAIの回答を、実際のページと状態に照らして確かめられます。差異が出たら、指摘箇所と期待結果を修正工程へ戻し、修正後のコードで再検査します。検査を実行できなければ未確認です。以前のコードでの合格を、そのまま使い回しません。

別々の部品にすれば、共通ルールを両方へ反映する手間が増える場合もあります。共通にしたら波及し、分けたら片方に反映されない。その両方を、AIの検査対象に入れておく必要があります。

この例は、AIへ実装と検査を行わせる際の設計案です。公開している品質工程では、AIの分析や画面比較に加え、共通化の範囲や例外の判断、差異の調整、専任QCも組み合わせています。(*1) AIの検査結果と、最終的な納品承認は分けて扱います。

役割と状態の違いをAIに調べさせる。共通にする土台と、別に持つ内容を実装条件にする。生成後は、変更が伝わる先と、混ざってはいけない先を検査する。今回のカードで揃えたいのは、この三つです。

次にAIへ共通化を依頼するときは、作る部品の名前だけでなく、共通にする理由と検査する状態も一緒に渡してみるとよいと思います。コードの量を減らせたかだけでなく、次の変更をどこまで広げるべきかも確認しやすくなります。