株式会社ファストコーディングでフロントエンド開発と技術戦略を担当している黒田です。
先月、うちの若手コーダーが面白い実験をしてくれました。同じFigmaカンプを「AIだけで仕上げたもの」と「自分が手で書いたもの」を並べて、どこが違うかを検証したんです。
結果は、想像していたよりAIが健闘していた部分と、「ここはさすがに無理か」という部分がはっきり分かれていました。今回はその検証結果をもとに、Figma→HTML/CSS変換でAIがどこまでできるのか、現場の実感をお伝えします。
検証の条件
検証に使ったのは、実際にクライアントから受注したコーポレートサイトのトップページです。クライアントの許可を得た上で、以下の条件で比較しました。
| 項目 | 内容 |
|---|---|
| デザインツール | Figma |
| ページ | コーポレートサイト トップページ |
| セクション数 | 7セクション（ヘッダー、MV、サービス紹介、実績、お知らせ、お問い合わせ、フッター） |
| ブレイクポイント | PC（1280px）、SP（375px）の2カンプ |
| AIへの入力 | Figmaのスクリーンショット + セクションごとのテキスト情報 |
| 人間側 | 経験3年のコーダーが通常フローでコーディング |
AIにはセクション単位で依頼し、最終的に1ページとして統合しました。
検証結果：5つの評価軸
以下は「このまま納品できるか」を基準に、チーム内でAIの出力と人間の出力を比較した結果です。
1. レイアウト再現度
AI：ほぼ再現できる / 人間との差：構造の設計力
大枠のレイアウト（ヘッダー、2カラム、グリッド、フッター等）はAIがほぼ正確に再現しました。Flexboxの方向、カードの並び、セクション間の大まかな余白は問題ない。
差がついたのは「入れ子の構造」です。ある実績セクションで、カード内にタグラベル・画像・タイトル・説明文・日付が入る構造がありました。AIはこれをフラットな構造で出してきたのに対し、人間のコーダーはタグラベルと日付を.card__metaとしてグループ化し、後からのスタイル調整がしやすい構造にしていた。
AIは「見た目が同じならOK」という判断をしますが、保守性まで考慮した構造にはなりにくい。ここは今のところ人間の判断が必要です。
2. 余白・フォント・色の精度
AI：色は正確、余白とフォントに課題あり / 人間との差：現場ルールの反映
色は正確でした。Figmaから直接hex値を読み取れるので、ここはAIの得意分野です。
問題はフォントサイズと余白です。Figmaで「24px」と指定されているフォントサイズをAIはそのまま24pxで出しますが、うちの現場ではclamp()やレスポンシブ対応のためにremに変換するルールがあります。このルールはプロンプトで指定しないと反映されません。
余白はもっと厄介で、Figmaのオートレイアウトのgap値とCSSのgap値が一致しないケースがありました。Figma上では親要素のpaddingとgapの組み合わせで余白が作られていますが、AIがそれをCSSに変換する際に、paddingとgapの配分を間違えることがある。結果として「なんとなく近いけど微妙に違う」状態になります。
3. レスポンシブ対応
AI：PC・SPは対応、中間幅は未考慮 / 人間との差：最も大きい
ここが一番大きな差でした。PC→SPの切り替え自体はAIも対応しますが、中間幅（タブレット）の処理がほぼ考慮されていない。
具体的に問題が出たのは以下の箇所です。
| 箇所 | PC | SP | タブレットでAIが出した結果 | 人間の判断 |
|---|---|---|---|---|
| サービス紹介カード | 3列 | 1列 | 3列のまま縮小 | 2列に切替 |
| ヘッダーナビ | 横並び | ハンバーガー | 横並びのまま（はみ出す） | 1024px以下でハンバーガーに |
| MV画像 | 横長 | 正方形 | 横長のまま（左右に余白） | アスペクト比を変更 |
PCとSPの2カンプしかない場合、「その間をどうするか」はコーダーの経験則に依存します。うちではタブレット幅のルールを社内ガイドラインとして整備していますが、これをAIに渡さない限り対応されません。
4. セマンティクス・アクセシビリティ
AI：動くが精度にばらつきあり / 人間との差：判断基準の有無
AIが出すHTMLは動くのですが、セマンティクスの精度にばらつきがあります。
うちの検証で見つかった問題パターンは以下の通りです。
<section>と<div>の使い分けが曖昧。見出しのないセクションに<section>を使っている- お知らせ一覧が
<div>の繰り返しで、<ul><li>構造になっていない - 画像の
alt属性が空、または「画像」のような無意味な値 - フォームの
<label>と<input>の紐づけがfor属性ではなくネストで実現されているが、一部ネストが漏れている
プロンプトで「セマンティックHTMLを使って」と指定すると改善しますが、「どこまでセマンティックにするか」の判断は結局人間が行う必要があります。
5. コードの保守性
AI：今の表示には最適化、将来の修正には不向き / 人間との差：最も顕著
ここが最も差がついた項目です。AIが出すCSSは「今の表示を実現する」ことに最適化されていて、「半年後に別の人が修正しやすいか」という視点が入りません。
具体的に目立った問題は以下の通りです。
- クラス名が
.section1-title、.section2-titleのように連番で、再利用性がない - 同じスタイルが複数箇所にコピーされていて、共通化されていない
- メディアクエリがセクションごとにバラバラに散在している
- マジックナンバー（
margin-top: 37pxのような根拠不明な数値）がある
うちの納品基準では、命名規則の統一、共通パーツの抽象化、メディアクエリの管理方法が規定されています。AIの出力をこの基準に合わせるには、結局人間が手を入れる必要がある。
「8割AI、2割人間」のワークフロー
検証の結論として、うちでは以下のワークフローに落ち着きました。
| フェーズ | 担当 | 所要時間の目安 |
|---|---|---|
| セクション単位のHTML/CSS生成 | AI | 全体の30%（従来の実装時間比） |
| レスポンシブ中間幅の追加 | 人間 | 15% |
| セマンティクス・アクセシビリティ修正 | 人間 | 10% |
| 命名規則・コード構造の整理 | 人間 | 15% |
| ピクセル調整・ブラウザ検証 | 人間 | 20% |
| 最終レビュー | 人間 | 10% |
AIに任せるのは「8割の骨格」まで。残り2割の仕上げに人間の工数がかかりますが、ゼロから書くよりはトータルで速い。この「8割AI、2割人間」が、少なくとも今の時点での現実的なバランスだと考えています。
ただし、この2割は「誰でもできる2割」ではありません。レスポンシブの判断、セマンティクスの設計、保守性を考慮したコード構造。これらはコーディングの経験と知識がないと対応できない領域です。
まとめ
Figma→HTML/CSSのAI変換精度を検証した結果、AIの強みと限界がかなり明確になりました。
AIが得意な領域は、レイアウトの大枠、色の再現、定型パターンの繰り返しです。ここはAIに任せることで確実に時間を短縮できます。
一方、AIが苦手な領域は、タブレット幅のレスポンシブ判断、セマンティクスの適切な選択、保守性を考慮したコード構造です。ここは人間が判断し、仕上げる必要があります。
うちの若手コーダーは検証後にこう言っていました。「AIが8割作ってくれるなら、自分は残り2割を極めればいい。でもその2割が一番難しい」。これは制作会社としての価値がどこにあるかを端的に表していると思います。
コーディング代行でのAI活用や品質管理について相談したいという方は、株式会社ファストコーディングのお問い合わせフォームからお気軽にご連絡ください。
