CodexをWeb制作で使う方法｜要件整理・実装・品質確認・CMS更新の実務フロー
VIEW →
AIコーディングで作ったWebサイトの品質チェックリスト｜公開前に確認する表示・SEO・保守性
AIコーディングエージェントを使うと、Webサイトの初期実装は短時間で形になります。ただし、ブラウザに一通りのページが表示された状態と、そのまま公開できる状態は同じではありません。
WebサイトをAIで実際に制作してみると、デザインカンプや元のHTMLと照合しながら調整する箇所が残りました。制作中の記録を整理すると、コミットは340件を超え、AIへの修正指示も300回以上あります。
初期実装に残っていたのは、大きな機能の不足だけではありません。文字間の違い、スマートフォンでの余白、画面の高さによるレイアウト崩れ、ホバーする範囲の違和感など、一見しただけでは見落としやすい差分が多くありました。SEO設定や公開後のページ遷移も、見た目からは判断できません。
この記事では、AIで実際に制作し、その過程で確認・修正した内容をもとに、Webサイトの公開前チェックを整理します。特定のCMS、フレームワーク、AIコーディングツールに限定せず、別の制作でも確認できる形にまとめます。
先に結論：完成の基準は「表示されたか」ではなく「意図どおり使えるか」
AIがエラーなくコードを書き、ページが表示されても、品質確認は終わりではありません。公開前には、次の7つの観点から確認します。
確認する観点 | 判断する内容 |
|---|---|
デザイン・要件 | デザインカンプや元データの仕様と一致しているか |
表示条件 | 文字量、画像、メニュー数などが変わっても破綻しないか |
デバイス・操作性 | 画面の幅と高さが変わっても内容を読めて操作できるか |
表示速度 | 画像、JavaScript、フォントなどが表示を遅らせていないか |
SEO | title、canonical、クロール設定がページごとに正しいか |
本番環境 | 公開URLで最新の内容と機能を確認できるか |
保守性 | 次の修正で影響範囲を把握でき、設定を継続して管理できるか |
実際に制作してみると、修正が多かったのは初期実装が成立していなかったからではありません。AIが一般的な実装へ整えた結果、元のデザインで決めていた表現や条件分岐が変わっていたためです。
そのため、公開前のレビューでは「足りない機能を探す」だけでなく、「元の仕様から変わった部分を戻す」「不要な表現を減らす」という見方が重要でした。
一見似ていても、元デザインとの差分は残る
デザインカンプや元のHTMLがある場合、完成の基準は「雰囲気が似ていること」ではなく、指定された構造と数値が再現されていることです。
実際の初期実装では、フォントサイズや色はおおむね合っていても、本文のletter-spacingや日付に指定されていた等幅フォントが抜けていました。ファーストビューも、元デザインで決めていた高さや上下余白が、一般的な値へ置き換わっていました。
ほかにも、次のような差分を修正しています。
- タイトルとサブタイトルの間隔を元デザインへ合わせる
- FAQのパディングとHTML構造を元データへ戻す
- カルーセルの拡大率、アニメーション時間、イージングを指定値へ戻す
- 2〜3言語では横並び、4言語以上ではドロップダウンにする条件分岐を復元する
- プラットフォームの標準スタイルが混ざったブログやフォームを、サイト全体のデザインへ統一する
細かな数値だけを確認するのではなく、条件によって表示方法が変わる箇所も比較します。言語数、メニュー項目数、本文の長さ、画像の有無などが変わると、初期データでは見えなかった差分が表れます。
デザインの再現確認では、完成画面だけを眺めるよりも、デザインカンプ、元HTML、実装結果を同じ単位で比較する方が差分を見つけやすくなります。
品質を上げたのは、装飾を足すより減らす修正だった
今回の初期実装には、カードの影、セクションの境界線、FAQのバッジなど、元デザインにない装飾が加わっていました。個別には小さな違いでも、同じ表現がサイト全体で繰り返されると、印象が変わります。
そこで、不要なシャドウや枠線を削除し、装飾記号と番号を整理しました。角丸のコンテナから画像がはみ出す箇所では、画像と外枠の形が一致するようにクリッピングも調整しています。色についても、近い色へ置き換えず、ブランドで決めた指定色へ統一しました。
アニメーションも同様です。3Dのフェードインや多層パララックスなど、動きとして成立していてもデザインの方向性に合わない演出は削除しました。
公開前には、何を追加すれば豪華に見えるかではなく、その影、線、角丸、アニメーションに役割があるかを確認します。役割を説明できない装飾を減らすことで、見出し、画像、ボタンなど本来見せたい要素が明確になります。
スマートフォンでは画面幅だけでなく、高さも確認する
レスポンシブ表示の確認では、デスクトップとスマートフォンの代表的な幅を一度ずつ見るだけでは不十分でした。同じ横幅でも、画面の高さやブラウザのUIによって表示できる範囲が変わります。
たとえば、カードをスクロールに合わせて重ねる演出は、大きな画面では問題なくても、高さの低いノートPCや横向きのスマートフォンでは画面を覆い、次の内容へ進みにくくなりました。低い画面では演出を解除する条件を追加し、通常の縦並びへ切り替えています。
実際に確認した項目は次のとおりです。
- スマートフォンの左右余白が狭すぎず、本文を読みやすいか
- 画像や地図がつぶれず、内容に合った縦横比になっているか
- モバイルメニューを開いたとき、背面のページがスクロールしないか
- 言語切り替えとハンバーガーメニューが重ならないか
- 横スクロールの先頭と末尾に、意図した余白が残るか
- Stickyや積み重なりの演出が、画面の低い端末で操作を妨げないか
W3CのWCAG 2.2では、画面を拡大した場合でも、情報や機能を失わずに内容を読み取れることが求められています。公開前は端末名だけで分けず、画面の幅、画面の高さ、内容量の組み合わせを変えて確認します。
インタラクションは「動くか」だけでなく「自然に操作できるか」を見る
ホバーやアニメーションは、実装されているだけでは品質を判断できません。どこへカーソルを置くと反応するのか、押せる範囲が見た目と合っているか、開閉中にレイアウトが揺れないかまで確認します。
今回のカードでは、カード全体へカーソルを置くと文字色が変わる実装を、ボタンへホバーしたときだけ色と矢印が変わる動きへ修正しました。反応する範囲をリンクの役割と合わせたことで、どこを操作できるのかが分かりやすくなります。
画像のズームは、継続時間とイージングを調整しました。カルーセルでは、中央と左右のカードの拡大率を元デザインへ戻しています。FAQのアコーディオンは、開閉時に高さが引っ掛からないように、高さの計算方法とCSSの遷移を整理しました。
あわせて、キーボードだけでリンクやメニューを操作できるか、フォーカス位置を確認できるか、画像の役割に合ったaltがあるかも確認します。W3CのWCAG 2.2でも、キーボード操作、画像の代替テキスト、見出し、色のコントラスト、フォーカス表示などが確認項目として示されています。
SEOは画面上の見た目だけでは確認できない
ページのデザインが合っていても、<head>やHTTPレスポンスに問題があれば、検索エンジンへページの内容と公開状態を正しく伝えられません。
公開前には、ページの種類ごとに次の項目を確認します。
<title>とH1がページ固有の内容になっている- meta descriptionが本文の内容と一致している
- canonicalが公開する正規URLを指している
- OGPのタイトル、説明、画像、URLがそろっている
- 構造化データの内容が画面上の情報と一致している
noindex、robots.txt、サイトマップの対象が意図どおりになっている- 内部リンクと外部リンクが正しいページへ到達する
共通のSEOコンポーネントを用意しても、すべてのページが正しくなるとは限りません。記事、一覧、カテゴリー、固定ページなど、テンプレートごとに必要な値が渡されているかを公開HTMLで確認します。具体的な実装項目は「microCMSのSEO対策チェックリスト」にまとめています。
Googleは、生成AIを使った検索機能でも、従来のSEOの基本、独自性のある内容、一次体験、分かりやすいページ構成が重要だと案内しています。AI検索だけに向けた特別な構造化データや別ファイルを追加するのではなく、ユーザーが内容を理解しやすく、検索エンジンがクロールできる状態を整えることがAIOの土台になります。
参考：AI検索機能とウェブサイトの最適化｜Google Search Central
公開後のページでしか見つからない問題もある
ローカルプレビューが正常でも、本番の配信経路やCMSの更新を含めると挙動が変わります。そのため、デプロイの成功だけで公開確認を終わらせず、実際のURLを開いて確認します。
当サイトでも、静的生成したページの遷移時だけ一瞬白くなる問題を、本番配信のレスポンスまで追って修正しました。原因と確認手順は「GPT SitesのSSGサイトでページ遷移が白くなる原因」で紹介しています。
CMSを使うサイトでは、記事を公開しても再ビルドが完了するまでは本番ページへ反映されない構成もあります。新規ページのURL、既存ページの更新内容、一覧やサイトマップへの反映を確認します。microCMSとSSGの確認方法は「microCMSの記事が反映されない原因」にまとめました。
本番では、次の順番で確認すると原因を切り分けやすくなります。
- ビルドとデプロイが完了しているか
- 対象URLが200を返すか
- HTMLに最新の本文とSEO情報が含まれているか
- ページ遷移、メニュー、フォームが動くか
- スマートフォンの実機でも表示と操作に問題がないか
保守性は、次の変更を安全に続けられるかで判断する
公開時に動いていても、同じ値が複数のファイルへ直接書かれていたり、条件分岐の意図が分からなかったりすると、次の変更で差分が生まれやすくなります。
今回の制作では、AIがFAQのHTML構造を変更したことで、既存CSSとの対応が分かりにくくなった箇所がありました。また、プラットフォーム側のベースCSSと追加したリストスタイルが重なり、箇条書きの記号が二重に表示されたこともあります。単独のコンポーネントだけでなく、サイト全体のCSSや既存構造との関係を確認する必要がありました。
保守性の確認では、次の点を見ます。
- 同じ色、余白、アニメーション値を重複して定義していないか
- 既存コンポーネントを使える箇所で、似た実装を新しく増やしていないか
- 条件分岐が、必要なパターンを省略していないか
- CMSやテーマの標準スタイルと独自CSSが競合していないか
- 変更したファイルと影響するページを説明できるか
- ビルド、静的解析、リンク確認を再実行できるか
AIには実装だけでなく、既存コードの調査、差分の説明、テストまで続けて依頼できます。ただし、最終的にどのデザインを正とするか、どの違和感を修正するかは、要件と実際の画面を見て判断します。構成、デザイン、コード編集でAIをどう使い分けているかは「CodexとGoogle Antigravityを実務で比較」で詳しく紹介しています。
AIコーディング後に確認したい公開前チェックリスト
ここまで紹介した制作時の確認内容に、当サイトで確認した公開後の問題と、Google・W3Cの公式情報を加え、AIコーディング後に確認したい項目を整理します。
チェックリストの目的は、今回と同じ修正を探すことではありません。元の要件と実装を比較し、表示条件を変え、本番環境まで確認するための判断基準として使います。
1. 元デザイン・要件との一致
- □ フォント、文字サイズ、行間、文字間が指定どおりか
- □ ファーストビューの高さと余白が変わっていないか
- □ 影、枠線、角丸、バッジなど、元デザインにない装飾が増えていないか
- □ 画像が角丸やコンテナからはみ出していないか
- □ アニメーションの秒数、拡大率、イージングが指定どおりか
- □ 見た目だけでなく、HTML構造やコンポーネントの役割も変わっていないか
2. 内容量・表示条件の変化
- □ タイトルや本文が長くなっても、要素の重なりや途切れが起きないか
- □ 画像がない場合や縦横比が異なる場合も、レイアウトを保てるか
- □ メニュー、カード、タグなどの件数が増減しても操作できるか
- □ 言語数や表示対象など、条件による表示の切り替えを省略していないか
- □ CMSを使う場合は、実際のデータを入れた状態で一覧と詳細を確認したか
3. デバイス・操作性・アクセシビリティ
- □ スマートフォンの左右余白と文字量が読みやすいか
- □ 画像、地図、カードの縦横比が画面ごとに崩れていないか
- □ 画面の高さが低い端末でもStickyや演出を操作できるか
- □ メニューを開いたときに背面がスクロールしないか
- □ ヘッダー内のボタンや言語切り替えが重なっていないか
- □ ホバーする範囲とリンクの範囲が一致しているか
- □ アニメーションが多すぎず、内容を読む妨げになっていないか
- □ アコーディオンの開閉時にガタつきやチラつきがないか
- □ スライダーの先頭、末尾、切り替え位置が意図どおりか
- □ タッチ、マウス、キーボードの各操作で主要な機能を利用できるか
- □ フォーカス表示、見出し構造、画像の
alt、文字色のコントラストを確認したか
4. 表示速度
- □ ファーストビューの主要画像を遅延読み込みにしていないか
- □ 端末の表示幅に対して、必要以上に大きな画像を配信していないか
- □ 初期表示に不要なJavaScriptを先に読み込んでいないか
- □ 表示直後のアニメーションが、主要な内容の描画を遅らせていないか
- □ 使用していないCSS、フォント、外部サービスのスクリプトが残っていないか
- □ Lighthouseなどで主要ページを計測し、変更前より悪化していないか
参考：Largest Contentful Paintを改善する方法｜web.dev
5. SEO・クロール設定
- □ title、H1、meta descriptionがページ固有の内容か
- □ canonical、OGP、構造化データが公開URLと一致しているか
- □
noindex、robots.txt、サイトマップの対象が正しいか - □ ページの内容と関係のないキーワードや見出しを追加していないか
- □ 重要なページへ、本文中の自然な内部リンクから到達できるか
- □ 画像の
altとリンクテキストから、対象の内容や移動先が分かるか
6. 本番環境・公開後の動作
- □ ビルドとデプロイが完了し、対象URLが200を返しているか
- □ 本番HTMLへ最新の本文とSEO情報が反映されているか
- □ メニュー、ページ遷移、フォーム、アコーディオンが公開URLで動くか
- □ 内部リンク、外部リンク、存在しないURLの404表示を確認したか
- □ CMSの更新が、詳細、一覧、カテゴリー、サイトマップへ反映されているか
- □ スマートフォンの実機で主要なページと操作を確認したか
7. 保守性・変更しやすさ
- □ 共通化すべき値や処理が重複していないか
- □ 既存コンポーネントと似た実装を増やしていないか
- □ CMSやテーマの標準CSSと追加CSSの競合がないか
- □ 条件分岐や例外処理の目的をコードから追えるか
- □ 変更理由と影響するページを差分から説明できるか
- □ ビルド、静的解析、主要ページの確認を再実行できるか
要件整理から実装、CMS更新、公開確認までCodexを使う流れは、CodexをWeb制作で使う実務フローで紹介しています。
記事制作で事実確認、CMS反映、公開後の改善まで進める方法は、AI時代の記事執筆・更新・改善フローにまとめています。
まとめ
AIコーディングで作ったWebサイトは、ページが表示された時点ではなく、元の仕様と一致し、実際の端末で自然に操作でき、検索エンジンと運用者にも正しい情報が伝わる状態になって完成です。
340件を超えるコミットと300回以上の修正指示を振り返ると、品質を左右したのは大きな機能追加だけではありませんでした。文字間、余白、ホバー範囲、画面の高さ、SEO情報など、小さな差分を一つずつ確認したことが最終的な完成度につながっています。
AIは初期実装を速めるだけでなく、既存コードの調査、差分の抽出、修正、テストにも使えます。そのうえで、人がデザインの意図と利用時の違和感を確認し、公開の基準を満たしているか判断する。この工程まで含めることで、AIコーディングを実務のWeb制作へ組み込めます。
- 執筆者 | 西條輝
- 1995年生まれ。
Web業界は8年目です。それ以前は、実製品の品質管理などを5年ほど担当していました。
生成AIの進歩で「作ること自体のハードル」は下がったからこそ、現場の課題を丁寧に言葉にし、Webというカタチに落とし込むことが、これからますます重要になると感じています。
X（Twitter）
お問い合わせはこちら