AI製サイトの品質チェックリスト｜納品前に必ず見る項目
AIにコードを書かせてサイトを作る。ここ1年ほどで、この方法は一気に現実的になりました。見た目の再現度は非常に高く、PCで見る限り「完成している」ように見えます。ただし、結論から言うと、**AIが作ったものをそのまま公開してはいけません**。見た目が完璧でも、スマホ幅での崩れ、想定外の入力に対するフォールバックの誤動作、桁や単位の取り違えなど、目視の一巡だけでは気づかない不具合が潜んでいるからです。この記事では、実際の制作現場で起きた不具合とその直し方をもとに、納品前に必ず見るべきチェック項目を整理します。対象は美容室・店舗経営者、そして制作を発注する立場のWEB担当者です。
—
1. 結論：納品前に必ず見る7項目
AI製サイトを公開する前に、次の7項目は必ず確認します。
1. **スマホ幅を320px・375px・390px・430pxの4サイズで見る**。横スクロールバーの有無、要素のはみ出し、カードグリッドの空白セル、見出しの折返しを確認する
2. **ハンバーガーメニューや固定CTAなど基本UIは「閉」「開」「リンク遷移」「画像読み込みエラー」「コンソールエラー」の5点で見る**
3. **「値が見つからない場合どうなるか」を必ず自問する**。存在しない組み合わせや想定外の入力を、こっそりデフォルト値に丸め込む実装になっていないか確認する
4. **金額・日付・単位の書式を実データで1件検証する**。外部APIやテンプレート由来のデータ形式は思い込みで扱わない
5. **同じ処理が複数箇所に実装されている場合、全箇所を横並びで確認する**。1箇所だけ直して他が直っていない、というケースが起きやすい
6. **削除・切替系の操作は、即座に消さずリネームで数日様子を見る**。他のファイルから参照されていないか、先にルート構成を確認する
7. **公開後の検証は、HTTPステータスコードだけで判断しない**。画面の中身、可能ならページのテキストまで見る
以降、なぜこの7項目が急所になるのか、実際に起きた不具合を交えて説明します。
—
2. なぜAI製サイトでこのチェックが重要なのか
AIは「見た目を再現する」作業が非常に得意です。Figmaのデザインを渡せば、配色もレイアウトも高い精度でHTML/CSSに変換します。ただし、それは「静止画としての再現」がうまいということであり、「あらゆる入力・あらゆる画面幅で正しく動く」ことを保証するものではありません。
AI実装で高品質に仕上げる正しい方法は、承認済みデザインの実画像・正確な座標データをそのまま使い切り、要素の位置とサイズをすべて%指定でオーバーレイする設計にすることです。この設計にしておけば、スマホを含めた横スクロールの発生やレイアウト崩れを防げます。反対に、デザインを画面上で見比べながら「それっぽく」コードに起こすだけの実装は、実データを使い切っていないぶん、見た目のズレやピクセル単位の不一致が起きやすいというリスクを抱えます。実際の制作現場でも、この違いが仕上がり品質の差として表れています。
ここから得られる教訓は明快です。AIに「なんとなく似せて作らせる」だけでは、粗が残ります。実データ・正確な座標・実際に起こりうる入力パターンを人間側が用意し、それに沿ってAIに検証させて初めて、公開できる品質になります。
—
3. 実例で見る、正しい実装と起こりうるリスク
**画像とテキストを横並びにするレイアウト**
2カラムで画像・テキストを並べる構成では、グリッドコンテナに`overflow: hidden`を指定し、画像・テキスト双方の要素に`min-width: 0`を設定するのが正しい実装です。この指定を怠ると、CSSグリッドの内側要素が持つ「暗黙の最小幅」により、画面幅を狭めたときに画像が枠からはみ出す崩れ方をします。見た目のチェックだけでは気づきにくい、CSSの仕様に起因するリスクです。
**選択肢の組み合わせを扱う実装**
ECサイトの商品ページで色・サイズなどのオプションを組み合わせる実装では、対応する在庫データが存在しない組み合わせに対して、ボタンを選択不可にし「ご用意がありません」と明示するのが正しい設計です。ここで「存在しない場合は先頭のデータに自動的に置き換える」実装にしてしまうと、一見エラーにならない親切な作りに見えても、ユーザーが選んだのと異なる商品が静かにカートへ入るという、気づきにくい事故につながります。**存在しないなら「存在しない」と表示する。何かで代用する実装は避けるべきです。**
**金額・単位を扱う実装**
外部の決済・ECプラットフォームを使う実装では、金額データが円ではなく最小通貨単位（例:1円未満のセント相当）で返ってくる前提で変換処理を書き、かつ同じ変換ロジックをテンプレートごとに個別実装せず共通関数にまとめるのが正しい設計です。この前提を怠り、変換処理を一部のテンプレートだけに書き漏らすと、特定のページだけ価格が桁違いに表示されるような不具合が起こります。**同じロジックが複数箇所にコピーされている場合は、全箇所を横に並べて比較するチェックが欠かせません。**
**切り替えボタンなどのイベント登録**
前後の切り替えボタンなど、クリックイベントを登録する処理は、他の要素をループ処理する構文の外側に書くのが正しい実装です。ループの内側に書いてしまうと、意図した回数より多くイベントが登録され、1回のクリックで複数回処理が走って元の位置に戻ってしまい、「ボタンが反応しない」ように見える不具合につながります。イベント登録がループの中に入っていないか、ブラウザの開発者ツールでクリックのたびに何が起きているかを確認するのが確実です。
**サーバー上の削除・切替操作と公開後の検証**
サーバー上のディレクトリやファイルを削除・切り替える際は、事前にルート構成やプログラムからの参照・読み込み関係を確認し、即座に削除せずリネームして数日様子を見るのが正しい手順です。この手順を踏まないと、本番側のプログラムが仮公開用ディレクトリの中身を読み込む構造になっていた場合など、削除した瞬間に本番ページ全体が表示崩壊するリスクがあります。しかもこの種の不具合は、URLへの通信確認（HTTPステータスコード200）だけでは検知できません。ステータスが正常でも、画面の中身にはエラー表示が出ている場合があるため、**公開後の検証は本文の中身まで確認するのが正しいやり方です。**
—
4. 手順・判断基準（実務チェックリスト）
**スマホ幅チェック**
320px・375px・390px・430pxの4サイズで、実機またはブラウザの開発者ツールを使い、横スクロールバーの有無、要素のはみ出し、奇数枚カードをグリッド表示したときの空白セル、見出しの折返しを確認します。特に、奇数枚のカードを偶数カラムのグリッドに詰め込むと、片方の列だけ空白セルが残る崩れ方をしやすいので注意が必要です。
**基本UIの状態チェック**
ハンバーガーメニュー・固定CTA・スライダーなどは、「閉じた状態」「開いた状態」「リンク遷移が正しく動くか」「画像の読み込みエラーがないか」「ブラウザのコンソールにエラーが出ていないか」の5点セットで確認します。見た目が正しく表示されていても、コンソールにはエラーが出続けている、というケースは珍しくありません。
**条件分岐・フォールバックの洗い出し**
「この値が存在しなかったら、コードはどう動くか」を必ず自問します。存在しない組み合わせや想定外の入力に対して、黙ってデフォルト値へ丸め込む実装は避け、ボタンを無効化する、あるいは明示的にエラーメッセージを出す設計にします。
**単位・桁・書式の再検証**
通貨の最小単位、日付のフォーマット(月日の順番など)、外部サービス由来のデータ形式は、思い込みで処理を書かず、実際のデータを1件取得して検証します。同じ処理を複数のテンプレートに個別実装している場合は、全箇所を横並びで比較します。
**削除・切替系操作の手順**
ディレクトリやファイルを削除・切り替える前には、まずサーバー側の構成や、他のファイルからの参照・読み込みがないかを確認します。いきなり削除するのではなく、リネームして数日様子を見る運用にすると、万一の際にすぐ元へ戻せます。
**公開後の実反映検証**
公開作業のあとは、HTTPステータスコードの確認だけで終わらせず、実際にページを開いて画面の中身を目視、あるいはページ本文の文字列まで確認します。ステータスコードが正常でも、画面内にエラーメッセージが表示されているケースは検知できないためです。
—
5. まとめ
AIはサイトの「見た目」を再現することには非常に長けています。しかし、あらゆる画面幅で正しく表示されるか、想定外の入力があってもおかしな動作をしないか、という「動作の正しさ」を保証してくれるわけではありません。だからこそ、公開前には人間の目で、複数のスマホ幅、基本UIの状態、条件分岐の抜け、単位や桁の扱い、そして公開後の実反映まで、一つひとつ確認する工程が欠かせません。この工程を省略しないことが、「AIで速く作る」ことと「プロとして納品できる品質を保つ」ことを両立させる唯一の方法です。