中国の大手フードデリバリーアプリ「美団（Meituan）」のUIが崩壊した複数のスクリーンショットが話題になった。削除ボタンが画面の半分近くを覆う赤いブロックに膨張し、テキストがコンテナに切れ込み、ボタンが不自然な位置に浮かぶ。ユーザーの反応で興味深いのは、バグの原因として多くの人が「AIが書いたコードだから」と推測した点だ。その推測が正しいかどうかよりも、「AIが書いたコードなら崩れても不思議ではない」という感覚が広く共有されるようになったこと自体が、フロントエンド開発の文脈を変えつつある。
バグの技術的な正体を分解する
削除ボタンが巨大化するケースは、CSSのフレックスボックスやグリッドレイアウトにおける伸縮設定の誤りで頻繁に起きる。flex-grow: 1 を意図せず適用した状態で親要素の幅が変わると、子要素が親コンテナを埋め尽くすように拡大する。これはAI生成コードに限らず、人間が書いたコードでも発生する古典的なミスだ。
テキストの切れについても同様で、overflow: hidden と固定高さの組み合わせは、コンテンツの長さが想定より伸びると文字が見えなくなる。多言語対応や動的コンテンツが絡む実装で特に顕れやすい問題だ。美団のような大規模サービスでは商品名の長さ・プロモーションラベルの追加・フォントサイズのユーザー設定など、設計時に想定できなかった状態が本番環境で無数に発生する。
/* 意図せず拡張するパターン */
.action-button {
flex-grow: 1; /* 親要素の残余スペースをすべて埋めてしまう */
background: red;
}
/* 意図した固定サイズ */
.action-button {
flex-grow: 0;
width: 80px;
}このような問題は、コンポーネントを単体でレンダリングするStorybook等のUIカタログツールでは発見しにくい。実際の商品データ・実際のデバイス幅・実際のOS設定が揃って初めて再現する。
NoCodeツールとエッジケースの相性問題
美団は「NoCode」という自然言語でWebアプリや社内ツールを生成できるAIコーディングツールを公開している。プロダクトマネージャーが日本語に近い自然言語でUIを記述すると、動作するコードが返ってくる仕組みだ。このようなツールが普及している背景があるため、ユーザーが「AIが作った画面では」と想像するのは根拠のない飛躍ではない。
NoCodeに限らず、GitHub CopilotやCursorのようなAI補完ツール、あるいはv0（Vercel）のようなUIコンポーネント生成サービスも、プロンプトに与えたサンプルデータに最適化したコードを生成する傾向がある。プロンプトに「商品名は10文字程度」と書けば、15文字の商品名が来たときのレイアウト挙動は保証されない。
これはAIの欠陥というより、仕様の記述漏れがそのままコードに反映される構造的な問題だ。人間がコードを書く場合も同じ落とし穴はあるが、AIが生成する場合は「とりあえず動くもの」が高速に出力されるため、エッジケースの検討が後回しになりやすい。
実際のプロダクトで考慮すべき状態の例を整理すると次のようになる。
- 商品名・店舗名が予想外に長い場合の折り返しとトランケート
- ユーザーがOSのフォントサイズを大きく設定している場合のリフロー
- プロモーションバッジやラベルが動的に挿入された場合のレイアウト変化
- 画像読み込み失敗時のフォールバック表示
- ネットワーク遅延によるローディング状態とスケルトンUIの整合性
これらは設計書には書かれにくく、プロンプトにも含まれにくい。だからこそビジュアルリグレッションテスト（画面のスクリーンショットを自動で比較し差異を検出するテスト手法）やPlaywright・Cypressを使ったE2Eテストが、AI生成コードを実プロダクトに載せる際により重要になる。
「動くコードができた」と「製品が完成した」は別の話
シード記事が指摘する核心は、実行コストが下がっても判断コストは下がらないという点だ。コンポーネントの生成が速くなれば、判断のボトルネックが浮かび上がる。削除ボタンは確認ダイアログを必要とするか。近くの店舗が上位に来るべきロジックは何か。これらはプロンプトで解けるより、ドメイン知識と仕様の精査によって解かれる問題だ。
フロントエンドの文脈では、CSS-in-JSやTailwind CSSのユーティリティクラスを組み合わせたコンポーネントをAIが高速生成できるようになった一方で、デザイントークン（色・スペーシング・タイポグラフィなどのデザイン変数）の一貫性や、アクセシビリティ属性（aria-labelやroleなど）の付与は人間がレビューしなければ抜け落ちやすい。
美団のスクリーンショットが示しているのは、AIへの属人的な非難ではなく、生成AIがフロントエンド開発のワークフローに組み込まれるにつれて、テストとレビューの設計をどう変えるかという問いだ。コードが生成できることと、そのコードが多様な実データ・端末・ユーザー設定のもとで壊れないことの間には、依然として埋めるべきギャップがある。