PRごとに「Figmaの設定値」と実装を照合し、差分をPRコメントに出す（figma-vrt-review）

どんな問題を解決するか / いつ使うか

AIでPRが増えると、UIの確認（Figmaと実装を人が見比べる作業）がボトルネックになる。WinTicketの事例では、新しいUI実装はマージまで中央値24.4時間・人の指摘が平均7.5件と、UI以外より明らかに重かった。また、普通のVRT（前回の画像との比較）は「変わったか」しか分からず、最初から余白が違えばそれが基準画像になって見逃される。Figmaを正本（SSoT）にすれば、この穴が埋まる。

仕組み（発表資料の要点）

1. 対応付け：コンポーネント（Widget）の上のコードコメントに、Figmaのノードを指すURLを書く（例：/// FigmaLink: https://www.figma.com/design/...?...node-id=...）。
2. Figma側の値：Figma REST APIでノードの構造と設定値（padding、itemSpacing、fontSize、fills など）と表示画像を取る。画像から推測しない。
3. 実装側の値：対象のコンポーネントと表示例（Story）の全文、importを辿ってテーマ・色・角丸などの定義を集め、トークン名を実際の数値に置き換えてから渡す（上限80ファイル）。AIに検索はさせず、ツールが集めた入力だけで判断させる。
4. 機械 → AI → 機械：対応が明らかなものは機械で確定し、入れ子などで機械が決めきれない「どれとどれを比べるか」だけをAIに選ばせる。AIの選択は、値が実在するか・外側の余白を借りていないかなどを機械で検証し、合わなければ一度だけ聞き直す。確かめられないものは「未確認」として出す。
5. 出力：比べた場所を番号の枠で示した画像と、値と判定の表をPRコメントに投稿。人が「このコメントを見て直して」と頼むと、エージェント（事例ではDevin）が修正し、もう一度照合する。
6. 比べる項目：各辺の余白・要素間隔、固定の幅・高さ、文字（サイズ・太さ・行高）、同じ役割の色。

注意点

• 検証では、わざと作った差分120件のうち89件を検出。主な取りこぼしはStoryとFigmaの対応付け（Storyの網羅性）。
• 分かるのは数値の差だけ。ボタンを押して正しい画面へ進むかなどのUXは、テストや人が確かめる。直すかどうかの判断も人に残す。
• 事例はFlutterだが、考え方（Figma URLの紐付け→設定値の取得→トークン解決→差分をPRへ）はWebのコンポーネントとStorybookにもそのまま使える。ツール自体は試作で、公開されているかは資料からは不明。

関連

• Vitest 4のBrowser Mode＋GitHub Actionsで、見た目の変化を検知するテスト（VRT）を入れる
• Claude Code × Figma MCP で清書した画面は、文脈を持たない読み取り専用の検査役に「実測値」で全数検査させる

出典

• @kgsi post（紹介）
• 発表資料：Hirokazu Tanaka（@appgrape）「デザインレビューは自動化できるのか？─ Flutter × Figma で UI 品質保証を考える」FlutterKaigi 2026