BLOG / AIケア

AIで作ったサイトが崩れる理由と、直す前に見るべきこと

AIで作ったサイトは、なぜ公開後に崩れることがあるのか。よくある原因と、原因を消さずに直すための見方を整理します。

v0、Bolt、ChatGPT、ノーコードツールなどでサイトを作ると、公開までのスピードはかなり上がります。ラフな指示から見た目の整ったページができるので、「これでいけそう」と感じる場面も多いはずです。

一方で、公開後にスマホ表示が崩れたり、フォームが動かなかったり、少し文章を変えただけで余白やボタンがずれたりすることがあります。これは「AIで作ったから全部だめ」という話ではありません。多くの場合、作るスピードに対して、あとから直すための構造や記録が足りていないことが原因です。

この記事では、AIで作ったサイトが崩れやすい理由と、崩れたときにどこから見ればいいかを整理します。焦って直す前に、まず「なぜ崩れたのか」を見える状態にするための記事です。コード自体を公開前に確認したい場合は「動く」と「保守できる」の違いもあわせてご覧ください。

1. AIで作ったサイトが崩れやすい理由

AI生成サイトで起きる表示崩れは、単にCSSが下手だから起きるわけではありません。よくあるのは、見た目は整っているけれど、修正や運用を前提にした整理が不足しているケースです。

たとえば、同じようなボタンのCSSが複数箇所に分かれていたり、PC表示を優先して作ったあとにスマホ用の指定が後付けされていたり、外部ライブラリや埋め込みコードの読み込み順に依存していたりします。最初は動いていても、文章量・画像サイズ・画面幅・外部サービスの変更でバランスが崩れます。

特に起きやすいのは、次のようなパターンです。

  • PCでは問題ないが、スマホで文字やボタンがはみ出す
  • 画像を差し替えたら、セクション全体の高さや余白が崩れる
  • フォームやスライドなど、外部サービスの埋め込み部分だけ動かない
  • AIに一部修正を頼んだら、関係ない箇所まで書き換わる
  • どのファイルを触れば直るのか、作った本人にも分からなくなる
AI生成サイトで大切なのは、「作れたか」だけでなく「あとから直せる形になっているか」です。崩れた箇所だけを見るより、崩れやすい構造になっていないかを見るほうが、再発防止につながります。何度も同じような崩れを繰り返す場合は、応急処置よりも本実装への移行を検討するタイミングかもしれません。

2. 崩れ方を分類する

崩れたときは、いきなりコードを見るより、まず「どの種類の崩れか」を分けます。分類できるだけで、確認すべき場所がかなり絞れます。

最初に見るのは、範囲です。1ページだけなのか、全ページなのか。特定のセクションだけなのか、ヘッダーやフッターなど共通部分なのか。全ページで起きているなら共通CSSや共通パーツ、1ページだけならそのページ固有のHTMLや埋め込みコードを疑います。

次に、環境です。

  • PCだけで起きるのか、スマホだけで起きるのか
  • Chromeだけなのか、SafariやEdgeでも起きるのか
  • 自分の端末だけなのか、別の人が見ても同じなのか
  • 通常ウィンドウだけなのか、シークレットウィンドウでも起きるのか

ここで「スマホだけ」「Safariだけ」「フォーム送信時だけ」のように条件が見えると、原因の候補が一気に減ります。反対に、条件を見ないままAIに「崩れたので直して」と頼むと、AIは広い範囲を推測で書き換えがちです。

3. 直す前に、原因の手がかりを残す

崩れている画面を見ると、すぐに直したくなります。ですが、修正前の状態には原因のヒントが残っています。CSSの読み込み順、消えた画像のパス、エラー文、フォーム送信時の挙動、スマホだけで起きる余白のズレ。こうした情報は、手を入れると簡単に消えてしまいます。

最低限、次の4つを残してください。

  • 崩れている画面のスクリーンショット
  • 対象URLと、崩れているページ名
  • 最後に正常だったタイミング
  • 現在のコード、設定、デザインデータのバックアップ

Gitで管理している場合は、修正前にコミットまたはブランチを切っておくのが理想です。Gitがない場合でも、ファイル一式を日付つきのフォルダにコピーしておくだけで、戻れる場所ができます。

AI生成サイトでは、1つの指示で複数箇所が同時に書き換わることがあります。「ヘッダーの余白だけ直して」と頼んだつもりでも、全体のレイアウトやクラス名、コンポーネント構造まで変わることがあります。だからこそ、修正前の保存は保険ではなく、作業の前提です。

やってはいけない初動

反対に、避けたい行動もあります。特に多いのは、原因が分からないままAIに何度も「直して」と頼み続けることです。AIはそれらしい修正案を出してくれますが、前提情報が足りないと、別の場所を壊す修正を混ぜることがあります。

  • バックアップなしでコードを上書きする
  • エラー文を読まずに消す
  • 複数の修正を一度に入れる
  • 本番環境で直接試行錯誤する
  • 「前に戻す」方法がない状態で作業を進める

修正は、1つずつ入れて、1つずつ確認するのが基本です。小さく戻れる状態を保つほど、作業は落ち着きます。

相談するときに送るとよい情報

制作会社や外部パートナーに相談する場合は、長い説明よりも、判断に必要な情報が揃っていることのほうが大切です。次の内容を送ってもらえると、初回の確認がかなりスムーズになります。

  • 対象URL
  • 崩れている画面のスクリーンショット
  • 最後に正常だった日時
  • 直前に行った操作やAIへの指示
  • PCだけか、スマホでも起きるか
  • ログイン情報や管理画面の有無
  • Git、バックアップ、元データの有無

ここまで整理できていれば、相談する側も説明しやすく、受ける側も「まず何を見るべきか」を決めやすくなります。結果として、やみくもな修正ではなく、原因に近いところから確認できます。

I-to.のAIケアでは、AIで作ったサイトやノーコード由来のサイトを、公開後も扱いやすい状態に整えるご相談を受けています。表示崩れそのものの修正だけでなく、再発しにくい構成への整理、バックアップや更新手順の見直しも含めて対応します。長年放置されていたサイト構造を整理した事例もございます。

よくある質問

小さな崩れで、バックアップが取れているなら試す価値はあります。ただし、原因を特定せずに何度も直しを重ねると、別の箇所を壊すことがあります。範囲が広い、原因が分からない場合は、無理に自分で直そうとせず早めに相談することをおすすめします。

まずこれ以上手を加える前に、今の状態をコピーして残してください。Gitがなくても、ファイル一式やページのスクリーンショットを日付つきで保存するだけで、戻れる場所ができます。

大丈夫です。原因の特定自体がご相談内容になることも多いです。対象URL、スクリーンショット、最後に正常だった時期が分かれば、そこから一緒に切り分けていけます。

上野まのすけ
上野まのすけ(I-to.合同会社 代表)

Webコーダー/ディレクターとして独立後、2026年にI-to.合同会社を設立。Webサイト制作・コーディング代行・AIケアを通じて、社内のWeb業務を整理し、運用しやすい形に整えています。プロフィール詳細

← ブログ一覧へ戻る

読むより聞いた方が
早いこともあります。

記事の内容について「うちの場合は?」があれば、一言どうぞ。ヒアリングは無料です。