AIにズルをさせない仕組みを作ったあと、同じものが公開されてないか30件調べた

2026年8月時点で、Figmaの画面デザインをAIでコードに変換する道具を30件ほど調べた。前回の記事で、AIにFigmaと実装の一致を直させたら、CSSを消したり改行位置だけを合わせたりする逃げ道を使われた、という話を書いた。その対策として「判定を通るまで止まれない仕組み」を作ったが、同じものが既に公開されていないかを確かめたのが今回の調査だ。結論は車輪の再発明ではなかった。ただし理由が予想と違った。「Figmaからコードを生成できるか」で並べると全部できるため、判断材料にならない。そこで「測定が完了を握っているか」という軸に切り替えて比べ直している。 面白いのはここだ。生成ツール側は、そもそも実装を測っていない。Figma公式のMCPには get_screenshot があるが、これはFigma側の画像を撮るもので、実装側を撮る手段が公式には無い。比較の2枚目が原理的に存在しない構造になっている。検証専門の道具はあるが、差分を見せるだけで合否は出さず、判断を人間に戻す。一方、ビジュアル回帰テストのツールは決定論的な画素比較を持つが、基準（baseline）が「前回の自分」になっている。答えられるのは「前から変わったか」であって、「デザインと合っているか」ではない。ここに気づくと、既存の道具で代用できないのがはっきりする。さらに、AIに自分の出力を見せて直させる方法は、業界標準のベンチマーク Design2Code の自己修正実験で、一部のモデルでわずかに改善したものの、他のモデルでは改善が見られなかったと報告されている。「直す者と判定する者を分けろ」という前回の主張は、感覚ではなく実測の裏付けを得た形だ。 中小企業の実務に引き直すと、AIに「デザイン通りに直して」と頼むだけでは、完了の判定をAIに握らせていることになる。見た目を合わせることと、設計どおりに作ることは別物だ。発注側は、完成の基準を人が持つ仕組みを先に決めておくべきだ。明日からの一言は「直したかどうかを、直した本人に判定させるな」である。