AIコーディングツールの普及で「フロントエンド開発が楽になった」という声は増えた。しかし実務で使い込むほど、ある壁にぶつかる。定型的なコンポーネントはすんなり出てくるのに、少しでも凝ったUIを頼むと途端に崩壊する——この非対称性は、いったいどこから来るのか。

米国の著名フロントエンドエンジニアが公開した論考が、Hacker Newsで話題を呼んでいる。「AIは膨大なチュートリアルをかじった、お世辞上手な開発見習いだ」という辛口な書き出しから始まる同記事は、AIがフロントエンドで躓く構造的な理由を鋭く分析している。

AIが得意なこと：「平均的なUI」の量産

AIが力を発揮するのは、ありふれたパターンの組み合わせだ。具体的には次のような作業が挙げられる。

  • スキャフォールディング：よく見るレイアウトやコンポーネント構造の雛形生成
  • トークン移行：デザイントークンのマッピングや一括置換といった単調作業
  • 機能の概要列挙：「こういう機能が必要」という汎用リストの作成

これらは確かに有用だ。繰り返しが多く、正解パターンが存在する作業ではAIは大幅な時間短縮をもたらしてくれる。

AIが苦手なこと：固有の解を要求される局面

一方、「舗装された道を外れた瞬間に転ぶ」とこの記事は表現する。苦手な領域は次の通りだ。

  • ビスポーク（オーダーメイド）インタラクション：スクロール駆動アニメーションやカスタムマイクロインタラクション。存在しないCSS構文を自信満々に書いてくる
  • レイアウト・スペーシング：ページの固有サイズや余白の計算。数学が苦手なAIには動的なレイアウト計算は鬼門
  • 複合状態の管理：複雑なコンポーネントの状態遷移を理解して正確に編集する作業
  • アクセシビリティ：aria-hidden="true" を壁に投げつけて終わり、という対応が横行する
  • パフォーマンス：明示的に指示しない限り、最も重くて動作の鈍い実装を選ぶ

そして致命的なのが、コンポーネントが複雑になるほど急速に性能が落ちるという傾向だ。シンプルなデザインは一発で出てくるのに、一手加えた追加依頼で全部崩れる——この落差こそが、AIの本質を如実に示している。

なぜそうなるのか：4つの構造的な理由

1. 学習データが古い

AIはインターネット上に溢れる「定番のチュートリアル」で学習している。現代のCSSやWeb APIの進化には追いついておらず、古い解法に依存しがちだ。

2. 「見る」ことができない

LLMはレンダリングエンジンではない。スクリーンショットを渡しても、ピクセル単位の整合性を確認する手段がない。「アイコンが消えている」と指摘すると「修正しました」と返ってくるが、実際には何も直っていない——という体験は誰もが経験しているはずだ。

3. 「なぜ」を知らない

アーキテクチャ上の判断には必ず背景がある。SDD・BDD・ステートマシン設計の「なぜそうするか」の文脈を持たないまま、パターンだけをつなぎ合わせるのがAIの現状だ。文脈を事前に丁寧に渡さないと、的外れな実装が返ってくる。

4. 実行環境をコントロールできない

RustやTypeScript・Pythonはバージョンを固定できるが、HTMLとCSSはそうではない。ブラウザの種類・バージョン・ウィンドウサイズ・入力デバイス・ユーザー設定——これらの変数をレンダリングエンジンは常に考慮しているが、LLMはそれを無視する。明示的に聞かなければ、論理プロパティ（logical properties）すら使ってこない。

実務への影響

この分析が示す実践的な含意は明快だ。

AIに任せていい作業：

  • ページの雛形・コンポーネントスケルトンの生成
  • 既存コードのリファクタリング（状態が単純な場合）
  • CSSトークンの一括置換や命名整理
  • 繰り返しパターンのバリエーション生成

人間が主導すべき作業：

  • デザイン仕様に基づくピクセル精度のUI実装
  • アクセシビリティ対応（WCAG基準の確認は必ず人間が行う）
  • 複雑なアニメーション・スクロール挙動の設計
  • パフォーマンスクリティカルな最適化

ポイントは「AIを信頼しすぎないこと」ではなく、「何を頼むか」を明確に設計することだ。AIへの指示に「Logical CSSプロパティを使え」「アクセシビリティ要件はWCAG AAを満たせ」「パフォーマンスを最優先にしろ」と制約を明示するだけで、出力品質は大幅に改善する。

筆者の見解

この記事が指摘する限界は、AIそのものの限界というより、現時点のAI活用の設計が浅いという問題だと筆者は受け止めている。

AIエージェントが真価を発揮するのは、単発の「これ書いて」ではなく、目的・制約・文脈を最初に渡した上で反復的に動かし続けたときだ。フロントエンド開発でも同様で、デザイン仕様・アクセシビリティ要件・パフォーマンス目標・対象ブラウザをセットで渡すプロンプト設計ができるかどうかが、使いこなしの分岐点になる。

AIが古い学習データに基づいて「それっぽい答え」を返してくるのは事実だ。しかし「AIはダメだ」と結論づけるのは早計で、問題の本質は「何を・どう頼むか」の設計力にある。この記事が「AIは使えない」という諦めに使われるのではなく、「どう使えば使えるか」を考えるための出発点になることを願う。

フロントエンドの複雑さとブラウザ環境の多様性は、AIにとって現時点で最も手強い領域であることは間違いない。だからこそ、そこに人間のエンジニアリング判断が入る余地があり続ける。AIに仕事を奪われるのではなく、AIが得意なことを任せて、自分は本質的な判断に集中する——その役割分担を明確にするほど、生産性は跳ね上がる。

出典: この記事は Why AI Sucks at Front End の内容をもとに、筆者の見解を加えて独自に執筆したものです。