株式会社ファストコーディングでフロントエンド開発と技術戦略を担当している黒田です。
AIにコーディングを任せる案件が増える中で、チーム内で一番話題になるのが「タブレット幅の処理」です。PCとSPの2カンプを渡せば、その2つの表示はそれなりに再現してくれる。ところが、768px〜1024pxの中間幅になると、ほぼ確実に崩れます。
以前の記事「AIにデザインカンプからコーディングさせてみた」でもこの問題に触れましたが、今回はレスポンシブ対応に絞って、AIが何を間違えるのか、人間はどこで判断を入れるべきかを具体的に掘り下げます。
AIがレスポンシブで失敗する構造的な理由
まず前提として、AIがレスポンシブ対応を苦手とする理由を整理します。技術的な限界というより、入力情報の構造に起因する問題です。
AIに渡される情報：
- PCカンプ（1280px〜1440px幅のデザイン）
- SPカンプ（375px幅のデザイン）
AIに渡されない情報：
- 768px〜1024pxの間でどう振る舞うか
- どの幅でグリッドの列数を切り替えるか
- ナビゲーションをいつハンバーガーに切り替えるか
- 画像のアスペクト比をどこで変更するか
AIは「与えられた情報から推測する」ことはできますが、「カンプにない判断をする」ことはできません。中間幅の処理は、コーダーの経験則に依存する判断であり、デザインカンプには明示されていない「暗黙のルール」です。
実際に起きた問題パターン
うちのチームがAI生成コードのレスポンシブを検証した際に、繰り返し発生したパターンを5つ紹介します。以下は、コーポレートサイト新規制作案件（10〜15ページ規模）での検証結果に基づいています。
パターン1：グリッドの列数が切り替わらない
PCカンプで3列のサービス紹介カードを、AIはメディアクエリなしのflex-wrap: wrapで処理することがあります。カードの幅がcalc(33.333% - gap)で固定されているため、画面が狭くなると3列のまま縮小され、カード内のテキストが1文字ずつ改行される状態になります。
人間のコーダーであれば、1024px以下で2列、768px以下で1列に切り替えます。この「いつ切り替えるか」の判断は、カードの最小可読幅（通常280px〜320px程度）から逆算するものであり、カンプには書かれていません。
パターン2：ナビゲーションの切り替えタイミング
PCカンプでは横並びのナビゲーション、SPカンプではハンバーガーメニュー。AIはこの2状態だけを実装します。
問題は、ナビゲーション項目が7つある場合、1024px幅ではギリギリ横並びで入るが、900px幅では右端がはみ出すケースです。AIは「PCは横並び、SPはハンバーガー」の2パターンしか書かないため、900pxで表示が壊れます。
うちでは、ナビゲーション項目の合計幅＋余白を実測して、収まらなくなる幅にブレイクポイントを設定します。固定値ではなく、コンテンツに合わせたブレイクポイント設計が必要です。
パターン3：フォントサイズが固定値のまま
AIはFigmaのカンプから読み取ったフォントサイズをそのままピクセル値で指定します。
/* AIが出したコード */
h1 { font-size: 48px; }
h2 { font-size: 32px; }
p { font-size: 16px; }
@media (max-width: 375px) {
h1 { font-size: 28px; }
h2 { font-size: 22px; }
}PC用の48pxとSP用の28pxは指定されていますが、タブレット幅では48pxのままです。768px幅で48pxの見出しは明らかに大きすぎます。
うちではclamp()を使った流動的なフォントサイズを標準にしています。
/* 人間が修正したコード */
h1 { font-size: clamp(28px, 4vw + 12px, 48px); }
h2 { font-size: clamp(22px, 2.5vw + 10px, 32px); }
p { font-size: clamp(15px, 1vw + 12px, 16px); }clamp()は最小値、推奨値、最大値の3つを指定して、画面幅に応じて滑らかにサイズが変化します。ブレイクポイントごとに個別指定する必要がなく、中間幅の問題を根本的に解消できます。
AIにclamp()を使うよう指示すれば対応してくれますが、計算式の設計（どの幅でどのサイズにするか）は人間が決める必要があります。
パターン4：画像のアスペクト比が固定
メインビジュアルの画像がPCでは横長（16:9）、SPでは正方形（1:1）で表示されるデザインの場合、AIはPC用とSP用の2つのスタイルだけを書きます。
タブレット幅では横長のまま縮小され、左右に余白ができるか、コンテナ幅に引き延ばされて画像が歪むことがあります。
人間の判断としては、タブレット幅では4:3のアスペクト比にするか、object-fit: coverとaspect-ratioプロパティを組み合わせて、画面幅に応じた最適な切り出しを設定します。
パターン5：余白が比例縮小されない
PC用の余白（padding: 80px）がタブレット幅でもそのまま適用されるケースです。1024px幅の画面で上下80pxの余白は、コンテンツに対して広すぎます。
/* AIが出したコード */
.section { padding: 80px 40px; }
@media (max-width: 375px) {
.section { padding: 40px 20px; }
}中間幅での余白指定がないため、768px〜1024pxでは80pxのまま。フォントサイズと同様に、clamp()で余白を流動的にするアプローチが有効です。
/* 人間が修正したコード */
.section { padding: clamp(40px, 6vw, 80px) clamp(20px, 4vw, 40px); }AIにレスポンシブを任せるためのプロンプト設計
これらの問題を踏まえて、うちのチームではレスポンシブ対応のプロンプトに以下の情報を含めるようにしています。
プロンプトに含めるべき情報：
- ブレイクポイントの一覧（例：1024px、768px、375px）
- 各ブレイクポイントでのグリッド列数の指定
- ナビゲーションの切り替え幅
- フォントサイズの方針（
clamp()使用の有無） - 余白の方針（固定値 or 流動値）
- 画像のアスペクト比変更の有無
これだけの情報を渡すと、AIの出力精度は大幅に上がります。逆に言えば、これだけの情報を事前に整理する必要があるということです。レスポンシブの仕様書がない状態でAIにコーディングさせると、中間幅の問題が確実に発生します。
「デザインにないことをコーダーが判断する」領域
レスポンシブの中間幅は、デザイナーとコーダーの間にある「暗黙の了解」で処理されてきた領域です。デザイナーはPC/SPの2カンプを出し、コーダーがその間を経験則で埋める。この暗黙知がAIにはありません。
うちで効果があったのは、レスポンシブの仕様を「暗黙知」から「明文化されたルール」に変えることでした。社内のレスポンシブガイドラインとして以下を整備しています。
- 標準ブレイクポイント（1280px / 1024px / 768px / 375px）
- グリッドの列数切り替えルール（カード最小幅280pxを下回ったら列数を減らす）
- フォントサイズの
clamp()計算式テンプレート - 余白の
clamp()計算式テンプレート - ナビゲーション切り替えの判断基準（項目数×項目幅＋余白がコンテナ幅を超えたら）
このガイドラインをプロンプトに含めることで、AI生成コードの中間幅の品質は明らかに向上しました。ガイドラインの整備自体にはコストがかかりますが、一度作れば全案件で再利用できるため、長期的には効率化につながっています。
まとめ
AIがレスポンシブコーディングを苦手とする原因は、技術的な限界ではなく「入力情報の欠如」です。PC/SPの2カンプしか渡されない以上、その間の判断はできません。
対策としてうちで効果があったのは以下の3点です。
- レスポンシブの仕様を「暗黙知」から「明文化されたルール」に変換し、プロンプトに含める
clamp()を使った流動的なフォントサイズ・余白の設計を標準化する- ナビゲーションやグリッドの切り替え基準を「コンテンツの実測値」から逆算して決める
AIに中間幅の処理を任せるには、人間が「何をどう判断すべきか」を言語化して渡す必要がある。その言語化作業こそが、AIを前提としたレスポンシブ設計の本質だと感じています。
コーディング代行のレスポンシブ対応やAI活用について相談したいという方は、株式会社ファストコーディングのお問い合わせフォームからお気軽にご連絡ください。
