株式会社ファストコーディングでフロントエンド開発と技術戦略を担当している黒田です。
AIに画面を作らせたあとで、Figmaが更新される。「このデザインに合わせて直して」と追加で指示するだけでよさそうですが、そこでコードだけを更新すると、検査が変更前の条件で走ることがあります。
以前のワークフローの記事でも、AIへの判断基準と、実装・検証の工程を分ける話を書きました。デザイン変更が入ったときは、その両方を更新する必要があります。
今回は、コード修正とブラウザ操作を実行できるAIエージェントを使う前提で、変更後の工程をどう組むかを整理します。実装するAIと検査するAIに何を参照させ、どこからやり直させるか、という話です。
新しいFigmaと、変更点をセットでAIへ渡す
仮に、共通ヘッダーのスマートフォン表示を変更するとします。メニューを開くボタンを左から右へ移し、メニューの表示順もA・BからB・Aへ変える例です。
ここでAIがボタンの位置だけを修正し、表示順を取りこぼしたとします。さらに、検査するAIが変更前のA・Bを正しい順序として使っていたらどうでしょうか。表示順の変更漏れを、その検査では拾えません。
私なら、まずAIへ渡す入力を揃えます。Figmaのどの画面を採用するかを特定し、変更前との差分を明示する。その同じ内容を、実装と検査の両方へ渡します。新しい画像を渡しても、前の指示や検査項目が残っていれば、基準は揃いません。
今回の例なら、入力は次のように整理できます。
| AIへ渡す内容 | 今回の例 |
|---|---|
| 採用する基準 | 変更後のスマートフォン用ヘッダーの画面と仕様 |
| 修正する内容 | ボタンを左から右へ移す。表示順をA・BからB・Aへ変える |
| 変えない条件 | 閉じた状態からメニューを開閉できること |
| 検査する結果 | 指定幅でボタンが右にあり、開くとB・Aの順に並ぶこと |
これで、AIが修正すべき内容と、修正後に確かめる内容を対応付けられます。Figmaにない動作は推測で埋めず、未確定の条件として止める設計にします。決まっていない仕様までAIに決めさせると、何をもって合格とするかも曖昧になるからです。
AIに参照関係を調べさせ、再検査するページを選ぶ
次に更新するのは、AIが作業する範囲です。共通ヘッダーを直しても、最初に開いた1ページだけを検査して終わらせるわけにはいきません。
AIには、修正前にその部品を使うページと、関連するスタイル・動作処理を調べさせます。今回なら、共通ヘッダーを使う一覧ページと詳細ページが対象になります。別構成のヘッダーがあれば、同じスタイルや処理を共有していないかを調べてから、影響範囲を判断させます。
見た目が似ているかどうかだけで選ぶと、コードの共有による影響を見落とします。逆に、ヘッダーという名前の部品をすべて修正させると、別の構成まで変えてしまうかもしれません。参照関係を調べた結果を、AIの実装範囲と再検査の対象一覧に反映します。
ページだけでなく、画面幅と操作も指定します。今回の例なら、次のような検査です。
| 対象 | AIに実行させる確認 |
|---|---|
| 一覧・詳細ページのSP表示 | メニューを閉じた状態でボタン位置を確認する |
| メニューを開いた状態 | B・Aの順に表示されるか確認する |
| 開閉操作 | ボタンを操作し、開く・閉じるの両方を確かめる |
| 関連するPC表示 | 共有スタイルや処理の変更で、表示・動作が崩れていないか確認する |
対象一覧があれば、AIがどのページと状態を確認したかを結果と照合できます。参照先の調査に漏れがないとは限らないため、実際のコード構成と変更内容に照らして対象を見直す工程も残します。
新版の基準で、AIの修正と再検査を回す
変更前の検査合格は、変更前のコードと仕様に対する結果です。その履歴は残します。ただし、新版の検査を省略する根拠にはしません。
実装するAIがコードを直したら、検査するAIには修正後の画面をブラウザで開かせます。新版のFigmaと仕様を基準に、先ほどの対象一覧に沿って表示と動作を確認する。差異があれば、該当箇所と期待する状態を実装工程へ戻し、修正後に同じ条件で再検査します。
私は、実装と検査を別の実行単位に分けたいと考えています。実装したAIの「直しました」という回答を、そのまま検査結果として使わないためです。検査側には、仕様と対象一覧、実際に確認するコードの版を渡します。
結果には、新版の基準、コードの版、確認したページ・画面幅・操作、期待した結果と実際の結果を残します。スクリーンショットだけでなく、メニューを開閉したか、順序を確認したかまで追える記録にします。
再検査を実行できなかった場合は、未確認です。差異が残った場合も、合格にはしません。AIによる自動修正には回数の上限を設け、同じ失敗が続く場合や仕様が未確定の場合は、原因と未解決項目を残して判断待ちにします。何度も実行したことと、必要な検査に通ったことは別です。ここでの合格は指定した検査項目への合格であり、最終的な納品承認とは分けます。
当社が公開している品質工程でも、画面比較、差異の修正、修正後の再確認を扱っています。ここで紹介した例は、その考え方をデザイン変更後のAIの実行手順へ落とし込んだものです。AIMESで工程を管理する場合も、変更後の基準と各実行結果を対応付け、古い合格記録で新版の工程を閉じないようにします。
コードと一緒に、AIの検査条件も更新する
Figmaが変わったら、AIへ渡す入力、コードから調べた影響範囲、再検査する条件を更新する。コードの修正だけで終わらず、新版の基準で確認し直した結果まで揃える。今回の例で組み込みたいのは、この流れです。
まずは、次のデザイン変更で使うAIの指示と検査項目を並べてみるとよいと思います。変更点が両方に入っているか。関連ページと操作が対象になっているか。修正後に再実行した記録があるか。そこまで追うと、AIがどこまで作業を終えたのかが見えてきます。
変更前後のFigmaと現在の実装状況を添えて、ファストコーディングへご相談ください。AIによる修正と検査を、どの条件で実行するかから整理します。
