AIエージェントを複数体走らせて、自作UIのデザイン踏襲をレビューさせる

mockup（デザインモック）をもとにUIを実装したあと、こんな不安に襲われたことはないでしょうか。「自分では忠実に作ったつもりだが、本当にmockup通りになっているだろうか」。実装した本人は、作りながら無意識に妥協した箇所や、mockupを見落とした箇所に気づきにくいものです。自分のコードを自分でレビューする限界、というやつです。

人間なら、複数人で見れば視点が増えます。同じことをAIエージェントを複数体走らせて再現する——というのが、この記事で紹介するワークフローです。実装したUIがmockupにどれだけ忠実か（レイアウト構造・配置・コンポーネントの対応）を、独立した複数のレビュー用エージェントに多角的に検証させ、一人のレビューを補強します。

なぜ「一人」だと足りないのか

実装者本人によるセルフレビューには、構造的な弱点があります。

確証バイアス — 「こう作った」という記憶が先にあるので、mockupを見ても自分の実装を追認する方向に見てしまう
見落としの再生産 — 実装時に見落としたmockupの要素は、レビュー時にも同じ理由で見落とす
観点の固定 — 一人だと「色が合っているか」ばかり気にして「配置の階層構造」を見落とす、といった観点の偏りが起きる

AIエージェント一体に「mockupと実装を比べて」と頼んでも、程度の差こそあれ同じ問題が出ます。一回の応答は一つの視点に偏りがちで、見る観点を欲張ると一つひとつが浅くなる。

そこで、観点を分割して複数のエージェントに割り当てる。一体に全部を見させるのではなく、それぞれに専門の担当を持たせて独立に走らせます。

ワークフロー：観点を分けて並列レビュー

1. レビューの「軸」を決める

まず、mockup踏襲を評価する軸を分解します。UIのデザイン踏襲なら、たとえば次のように分けられます。

レイアウト構造 — 全体のグリッド・カラム構成・領域の分割が一致しているか（例：全体2カラムで、右カラムがさらに上下分割されている、という骨格）
要素の配置と階層 — どの要素がどの領域に、どういう順序・入れ子で置かれているか
コンポーネントの対応 — mockupの各パーツ（スライダー、チャート、プレビュー、リストなど）が実装に過不足なく存在するか
見た目のトーン — 色・余白・タイポグラフィなど視覚的な質感

軸を明示的に分けるのがポイントです。各エージェントは自分の軸だけに集中するので、深く見られます。

2. 各軸に独立したエージェントを割り当てる

軸ごとに1体、レビュー専門のエージェントを起動します。それぞれに渡すのは同じ素材——mockup（画像や仕様）と、実装（該当コンポーネントのコード、あるいは実際にレンダリングした画面）——ですが、指示（プロンプト）は担当軸に特化させます。

たとえばレイアウト構造担当には「色やテキストは無視してよい。領域の分割構造だけを、mockupと実装で突き合わせて差分を挙げよ」と指示します。こうすると、他の軸に気を取られず骨格だけを厳密に見ます。

重要なのは、エージェントを独立に走らせることです。互いの結論を見せ合うと引きずられて、独立した視点という利点が消えます。人間のコードレビューで、他人のコメントを見る前に各自の指摘を書き出すのと同じ発想です。

3. 指摘を突き合わせて統合する

各エージェントから上がってきた指摘を、人間（または統合役のエージェント）が突き合わせます。ここで見るべきは主に3種類です。

複数のエージェントが独立に挙げた指摘 — 信頼度が高い。優先的に直す
一体だけが挙げた指摘 — 見落としの拾い上げか、その軸ならではの深い指摘。内容を吟味する
エージェント間で食い違う指摘 — mockupの解釈が割れている箇所。人間が最終判断する

一人のレビューなら「複数が独立に同じ指摘」という強いシグナルは絶対に得られません。ここが複数体を走らせる最大の価値です。

4. 直して、再度レビューにかける

指摘を反映したら、同じエージェント群にもう一度かけます。修正で新たなズレが生まれていないかを確認するためです。実際、レイアウトを2カラム構成へ組み直すような大きめの修正では、一度で完璧にはならず、この往復が効いてきます。

落とし穴と学び

このワークフローを回して分かった注意点です。

軸を分けないと意味が薄れる — 全エージェントに同じ「mockup通りか見て」を投げると、似た表面的な指摘が複数返るだけで、多角性が生まれない。観点の分割が本質。
素材は同一に揃える — 各エージェントに渡すmockupと実装のスナップショットは同じものにする。バラバラだと指摘の突き合わせができない。
エージェントの独立性を守る — 結論を共有させない。共有した瞬間に多数決ではなく同調になる。
最終判断は人間が持つ — エージェントの食い違いは「mockup解釈の曖昧さ」を可視化してくれる。そこは自動で潰さず、人間が意図を決める。
コードだけでなく実画面も渡せると強い — 静的なコードの読み合わせだけでは、実際のレンダリング結果のズレは拾いきれない。可能なら描画済みの画面も素材に含める（ブラウザ自動化で実画面を見せる手法は別記事で扱います）。

まとめ

実装者本人のセルフレビューは確証バイアスと観点の偏りで、mockup踏襲のズレを見落としやすい
観点（レイアウト構造／配置と階層／コンポーネント対応／視覚トーン）を軸に分け、軸ごとに独立したレビュー用エージェントを走らせる
各エージェントは同一素材・担当軸特化のプロンプトで、互いの結論を見せずに独立に評価させる
複数が独立に挙げた指摘は信頼度が高い。食い違いはmockup解釈の曖昧さとして人間が判断する
修正後は同じエージェント群で再レビューし、往復で仕上げる
一人（一体）のレビューを、独立した複数視点で補強する——これがマルチエージェント・レビューの狙い