Web制作のコーディングチェックリスト40項目｜納品前の表示崩れ・ミスを防ぐ

公開後に「スマホで見ると崩れている」「リンクが切れている」「問い合わせが届かない」と指摘された経験はないでしょうか。こうした不具合は、スキルの問題というより、確認の抜け漏れから起こることが少なくありません。

この記事では、コーディングチェックリストとして、HTML・CSS・レスポンシブ・JavaScript・画像・SEO・フォーム・公開前確認・WordPressの9カテゴリ40項目をまとめました。各項目を「確認項目・NGの場合・確認方法」の3点で整理しているので、表示崩れ・フォーム不達・計測漏れ・公開時の設定ミスといった、納品後に起こりやすい不具合を事前に確認できます。40項目の一覧は、自社用のチェックシートを作る際の土台としても使えます。

このコーディングチェックリストの使い方

本チェックリストは、制作中・納品前・公開直前の3つのタイミングで使い分けると、抜け漏れを減らせます。初学者は重要度★★★の26項目から、経験者は40項目全体の再点検に使ってください。

対象読者と使い方（初学者向け／経験者向け）

初学者の方は、まず重要度★★★の項目から確認してください。各項目の「NGの場合」を読むと、確認が必要な理由がわかります。

経験者の方は、全40項目の一覧を、自社の納品基準と照らした差分確認に使えます。チームの共通リストや、新人教育（OJT）の叩き台としても活用できます。

各項目の見方（3点セットと重要度マーク）

各項目は、次の3点で統一しています。

見出し	内容
確認項目	何を見るか
NGの場合	放置した場合に起こりうる不具合
確認方法	使うツールや手順

• Chrome DevTools
  Google Chromeに標準搭載されている開発者向けツールです。F12キーまたは右クリックの「検証」から開けます。
• Lighthouse
  Webページの品質（性能・アクセシビリティ・SEOなど）を自動で採点するGoogle製のツールです。Chrome DevToolsに組み込まれているほか、Chrome拡張機能としても利用できます。

重要度は2段階で示します。

マーク	意味	項目数
★★★	必須。見落とすと表示不具合・機会損失・信用低下につながりやすい	26項目
★★	推奨。品質や保守性を高める	14項目

確認するタイミング（制作中・納品前・公開直前）

チェックは、最後にまとめて行うのではなく、工程ごとに分けると手戻りが減ります。

タイミング	主に見るカテゴリ	該当項目
制作中	HTML構造、CSS、JavaScript	1〜9 15〜19
納品前	レスポンシブ・実機、画像、 アクセシビリティ・SEO、フォーム・計測・原稿	10〜14 20〜32
公開直前 （本番環境）	公開前・納品前の最終確認、WordPress	33〜40

• フォームの送信テストや計測タグなど、本番環境でしか確認できない項目は、納品前に確認したうえで、公開直前にも再確認してください。

初学者は、まず重要度★★★の26項目から

40項目すべてを一度に確認する必要はありません。必須の★★★26項目から確認すれば、影響の大きい不具合を優先して防ぐことができます。残りの★★14項目は、慣れてから加える「発展編」として使ってください。

カテゴリ	★★★の項目番号
HTML構造・セマンティクス	1、2、3
CSS・レイアウト	5、6、7
レスポンシブ・ブラウザ/実機	10、11、12
JavaScript・動作確認	15、16、17、18
画像・パフォーマンス	20、21
アクセシビリティ・SEO基礎	25、26
フォーム・計測・原稿	29、30、31
公開前・納品前	33、34、35
WordPress（WordPress案件のみ）	38、39、40

• WordPress以外の制作では、★★★は23項目になります。

カテゴリ別コーディングチェックリスト40項目

重要度の高い40項目を、9カテゴリに整理しました。表示崩れに影響しやすいCSS・レスポンシブ・画像と、成果への影響が大きいフォーム・計測・公開前確認は、優先して確認してください。

全40項目の一覧

No.	項目名	重要度
HTML構造・セマンティクス
1	HTML文法エラー・閉じタグ漏れ・id重複がない	★★★
2	見出し（h1〜h6）の階層が正しい	★★★
3	lang属性・文字コード・viewportが正しい	★★★
4	適切なセマンティックタグを使用している	★★
CSS・レイアウト
5	デザインカンプと表示が一致している	★★★
6	要素のはみ出し・横スクロールがない	★★★
7	テキスト量の増減でレイアウトが崩れない	★★★
8	フォント指定とフォールバックが適切	★★
9	z-index・position・floatの干渉がない	★★
レスポンシブ・ブラウザ/実機
10	主要ブレイクポイントの前後で崩れない	★★★
11	主要ブラウザで表示が揃っている	★★★
12	iOS/Android実機で表示・操作できる	★★★
13	タップ領域・文字サイズが適切	★★
14	横向き・文字拡大・ズーム時も破綻しない	★★
JavaScript・動作確認
15	コンソールにエラー・警告が出ていない	★★★
16	jQuery・ライブラリの読み込み順と競合がない	★★★
17	メニュー・スライダー等のUI動作が正常	★★★
18	リンク・アンカー・外部リンクが正しい	★★★
19	hover依存のUIがタッチ操作でも使える	★★
画像・パフォーマンス
20	画像の形式・サイズ・圧縮が適切	★★★
21	alt属性・width/height属性が設定されている	★★★
22	遅延読み込み・ファーストビューの最適化	★★
23	CSS・JSの圧縮・未使用コード・!important乱用がない	★★
24	動画・iframe・地図等の埋め込みが崩れず軽量	★★
アクセシビリティ・SEO基礎
25	title・meta description・見出しが設計通り	★★★
26	OGP・canonical・noindexの設定が意図通り	★★★
27	コントラスト比・色だけに依存しない表現	★★
28	キーボード操作・フォーカス表示ができる	★★
フォーム・計測・原稿
29	フォーム送信・メール到達・サンクスページが正常	★★★
30	GA4・GTM等の計測タグが動作する	★★★
31	原稿・指定情報と一致している	★★★
32	必須ページ・フッター表記が揃っている	★★
公開前・納品前
33	本番URL・ダミーテキスト・テスト痕跡が残っていない	★★★
34	HTTPS化・リダイレクト・混在コンテンツがない	★★★
35	noindex解除・robots.txt・sitemap.xml・404・faviconが適切	★★★
36	不要ファイル・秘匿情報が公開領域に残っていない	★★
37	納品形態に応じた納品物・引き継ぎ内容が揃っている	★★
WordPress
38	テーマ・パーマリンク・表示設定が正しい	★★★
39	管理画面からの更新・権限・カスタムフィールドが動作する	★★★
40	プラグイン・デバッグ設定・バックアップが適切	★★★

HTML構造・セマンティクスのチェック

HTMLの構造ミスは、CSS・JavaScript・SEO・アクセシビリティすべての不具合の根本原因になります。閉じタグの漏れ、見出しの飛び、head内の指定漏れがよく起きるミスです。

確認項目	閉じタグの漏れ、タグの入れ子の誤り、同じidの重複がないかを見ます。
NGの場合	ブラウザが誤りを自動補正した結果、意図しない構造になり、表示崩れやJavaScriptの誤動作の原因になります。
確認方法	W3C Markup Validation Service（validator.w3.org）などのHTMLバリデーターで検査します。id重複は、Chrome DevToolsのConsoleで次を実行すると、重複しているidが配列で返ります。

// Consoleで実行
[...document.querySelectorAll('[id]')].map(e => e.id).filter((id, i, a) => a.indexOf(id) !== i)

確認項目	見出しタグが、h1→h2→h3の順で階層を飛ばさずに使われているかを見ます。見出しの大きさはCSSで調整し、タグは文書構造に合わせて選びます。
NGの場合	見た目だけでタグを選ぶと、検索エンジンや読み上げソフトに文書の構造が正しく伝わりません。
確認方法	DevToolsのConsoleで次を実行すると、見出しの一覧を確認できます。

// Consoleで実行
[...document.querySelectorAll('h1,h2,h3,h4,h5,h6')].map(h => h.tagName + ' ' + h.textContent.trim())

確認項目	<html>のlang属性、文字コードの宣言、viewport指定の3点を見ます。viewportとは、画面の表示領域のことです。
NGの場合	文字化けが起きたり、スマートフォンでPC用の幅が縮小表示されたりします。
確認方法	ページのソースで記述を確認し、DevToolsのデバイスモードでスマートフォン表示になるかを見ます。LighthouseのSEO・アクセシビリティ項目でも検出できます。

確認項目	セマンティクス（タグでコンテンツの意味を表すこと）に沿って、header・nav・main・footer・section・articleが用途に合って使われているかを見ます。
NGの場合	divだらけの構造は、意味が伝わらず保守もしにくくなります。
確認方法	DevToolsのElementsパネルで構造を目視確認します。

CSS・レイアウトのチェック

CSSのミスは、「自分の環境では崩れない」ために見落とされがちです。カンプとのずれ、はみ出し、テキスト量の変化に弱い固定指定が、よく起きるミスです。

確認項目	余白、文字サイズ、色、行間、hover状態が、PC・スマートフォンの両方でカンプと一致しているかを見ます。
NGの場合	クライアントから「デザインと違う」と指摘され、手戻りが発生します。
確認方法	PhotoshopやFigma等のカンプの寸法表示と、DevToolsのComputedタブの値を突き合わせます。カンプ画像を半透明にして画面に重ねる比較も有効です。

確認項目	どの画面幅でも、横スクロールが発生していないかを見ます。
NGの場合	スマートフォンで画面が横にずれ、閲覧しづらくなります。
確認方法	DevToolsのデバイスモードで幅を変えながら、横スクロールの有無を確認します。

関連リンク：【レスポンシブ対応】CSSで作るtableレイアウト

確認項目	文章が長い場合・短い場合・長い英数字が続く場合に、レイアウトが保たれるかを見ます。高さの固定指定は崩れの原因になります。
NGの場合	CMSで更新した後に、文字量の変化で表示が崩れます。
確認方法	DevToolsでテキストを直接書き換え、長文と短文の両方を試します。

確認項目	フォールバック（指定フォントが使えない場合の代替）を含めて、font-familyを指定しているかを見ます。
NGの場合	閲覧環境によって、見た目や字詰めが変わります。
確認方法	DevToolsのComputedタブ下部の「Rendered Fonts」で、実際に使われているフォントを確認します。

確認項目	固定ヘッダーやモーダルが他の要素の下に隠れていないか、floatの解除漏れがないかを見ます。
NGの場合	ボタンやメニューが隠れて押せなくなります。
確認方法	DevToolsで該当要素を選び、positionとz-indexの計算値を確認します。

レスポンシブ・ブラウザ/実機確認のチェック

レスポンシブの確認は、ブレイクポイント（レイアウトが切り替わる画面幅）の前後と、実機特有の挙動まで行う必要があります。エミュレーターでは再現できない崩れが、公開後に見つかることがあるためです。

確認環境の優先度は、次のように整理できます。

環境	優先度の目安
iPhone（iOS Safari）	高
Androidスマートフォン（Chrome）	高
Windows PC（Chrome）	高
Windows PC（Edge）	中
Mac（Safari）	中
PC（Firefox）	低〜中
iPad（iPadOS Safari）	案件による

優先度は、案件のアクセス解析で端末・ブラウザ別の利用状況を確認して決めます。対象範囲は、仕様書やクライアントとの合意で事前に決めておきます。いずれも実機での確認を基本とします。

確認項目	320px〜1920px程度の範囲で、幅を連続的に変えながら崩れを見ます。ブレイクポイントの前後（例：767pxと768px）は、特に崩れが出やすい箇所です。
NGの場合	特定の画面幅だけ、レイアウトが破綻します。
確認方法	DevToolsのデバイスモードで、画面右端のハンドルをドラッグして幅を変えます。

確認項目	Chrome・Safari・Edge・Firefoxで、表示と動作に差がないかを見ます。
NGの場合	特定のブラウザのユーザーだけ、不具合に遭遇します。
確認方法	各ブラウザの表示を実機で確認します。

確認項目	アドレスバーの伸縮による高さのずれ、ノッチ（画面上部の切り欠き）周辺の表示、固定要素の挙動を見ます。
NGの場合	PCのエミュレーターでは見えない崩れが、公開後に発覚します。
確認方法	実機で直接確認します。実機を接続して確認する場合は、iPhoneはMacのSafariのWeb Inspectorで、AndroidはPCのChromeのリモートデバッグ（chrome://inspect）で行います。

確認項目	ボタンやリンクの大きさと間隔、入力欄の文字サイズを見ます。
NGの場合	誤タップが増えます。iOSのSafariでは、入力欄の文字サイズが16px未満だと、フォーカス時に画面が自動拡大されます。
確認方法	実機で操作して確認します。

確認項目	端末の横向き、ブラウザのズーム200%、端末の文字サイズ拡大時に、内容が読めるかを見ます。
NGの場合	高齢者や弱視のユーザーが、内容を読めなくなります。
確認方法	実機と、ブラウザのズーム機能（Ctrl/Cmd＋「+」）で確認します。

JavaScript・動作確認のチェック

JavaScriptのエラーは、1か所で止まると以降の処理がすべて動かなくなることがあります。WordPressでは、jQueryの扱いの違いでつまずく初学者が多い領域です。

確認項目	ページを開いた時点と、操作した後の両方で、コンソールに赤いエラーが出ていないかを見ます。
NGの場合	エラー以降のスクリプトが止まり、機能が動かなくなります。
確認方法	DevToolsのConsoleパネルを確認します。404になっているファイルは、Networkパネルで特定します。

確認項目	jQueryがプラグインより先に読み込まれているか、二重に読み込まれていないかを見ます。WordPressは、jQueryを$が使えないモード（noConflict）で読み込みます。
NGの場合	プラグインが動かず、「$ is not a function」などのエラーが出ます。
確認方法	NetworkパネルでjQueryの読み込み回数を確認します。Consoleで「jQuery.fn.jquery」を実行すると、読み込まれているバージョンを確認できます。

確認項目	ハンバーガーメニュー、スライダー、アコーディオン、モーダルが、PC・スマートフォンの両方で動くかを見ます。
NGの場合	ユーザーが目的のページにたどり着けません。
確認方法	操作シナリオ（開く→閉じる→再度開く、など）を決め、実機で確認します。

確認項目	リンク切れ、ページ内リンクの遷移先、外部リンクのrel指定を見ます。
NGの場合	404への誘導や、遷移元ページが意図せず操作されるリスクが生じます。
確認方法	W3C Link Checkerや、リンクチェック用のツールで検査します。

確認項目	hoverでしか表示されないメニュー、ツールチップ、ボタンの変化が、タッチ端末でも使えるかを見ます。タッチ端末にはマウスカーソルがないため、hover（要素にカーソルを重ねた状態）は発生しません。
NGの場合	スマートフォンやタブレットで、メニューが開かない、情報が見えないといった不具合が起きます。
確認方法	DevToolsのデバイスモードでタッチ操作をシミュレートし、実機でも確認します。

画像・パフォーマンスのチェック

表示速度は、離脱率や検索評価に関わります。重い画像、サイズ未指定、不要な読み込みが、よく起こるミスです。

確認項目	表示サイズに対して画像が大きすぎないか、圧縮やWebPなどの軽量な形式を使っているか、高解像度の画面向けに画像を出し分けているかを見ます。
NGの場合	表示が遅くなり、離脱や通信量の増加につながります。
確認方法	DevToolsのNetworkパネルで、画像ごとのファイルサイズを確認します。

確認項目	意味のある画像にはaltで内容を、装飾画像にはalt=””を指定しているか、widthとheightを指定しているかを見ます。
NGの場合	読み込み中に画面がガタつき、読み上げソフトでも画像の内容が伝わりません。
確認方法	Lighthouseのアクセシビリティ項目とパフォーマンス項目で検出できます。

確認項目	ファーストビュー（最初に見える範囲）より下の画像にloading=”lazy”を指定し、ファーストビューの画像は遅延させていないかを見ます。
NGの場合	ファーストビューの画像を遅延させると、表示が遅くなります。
確認方法	LighthouseまたはPageSpeed Insightsで確認します。

確認項目	minify（空白やコメントを除去して軽量化すること）、未使用のコード、「!important」の多用を見ます。
NGの場合	読み込みが遅くなり、後の修正で不具合が連鎖します。
確認方法	DevToolsのCoverageパネル（コマンドメニューで「Show Coverage」）で未使用コードを確認します。Stylelintを使うと、「!important」の使用を検出できます。

確認項目	埋め込みが縦横比を保ち、スマートフォンではみ出していないかを見ます。
NGの場合	はみ出しや、表示速度の大幅な低下が起きます。
確認方法	DevToolsのデバイスモードと実機で確認します。

アクセシビリティ・SEO基礎のチェック

アクセシビリティとSEOの基礎は、コーディングの時点でほぼ決まります。後から直すと修正範囲が広がりやすいため、納品前に「読めるか・操作できるか・検索結果やSNSで正しく表示されるか」を確認します。

確認項目	ページごとに固有のtitleとmeta descriptionが設定されているか、見出しが設計と一致しているかを見ます。meta descriptionは、検索結果に表示されるページの要約です。
NGの場合	検索結果の表示が不適切になり、クリックされにくくなります。なお、meta descriptionは検索エンジン側で書き換えられる場合があります。
確認方法	ページのソースを確認し、LighthouseのSEO項目で検出します。

関連リンク：SEOに強いサイトを作る！効果的なコーディングのポイント

確認項目	OGP（SNSで共有された際に表示される情報の指定）、canonical（正規URLの指定）、noindex（検索結果に載せない指定）が、設計通りかを見ます。ここでは設計通りかを確認し、公開時にnoindexが解除されているかを確認します。
NGの場合	SNSで画像が表示されない、正規URLが誤って伝わる、といった問題が起きます。
確認方法	ソースを確認します。OGP画像は絶対URLで指定します。公開後は、Google Search ConsoleのURL検査や、各SNSの共有デバッガーで確認します。

確認項目	文字と背景のコントラスト比が、国際基準「WCAG」のAA基準を満たしているかを見ます。リンクが色の違いだけで示されていないかも確認します。
NGの場合	薄い文字が読めない、リンクと本文の区別がつかないユーザーが出ます。
確認方法	DevToolsのカラーピッカーでコントラスト比を確認できます。Lighthouseでも検出できます。

確認項目	Tabキーですべての操作要素に移動でき、現在位置が見えるかを見ます。
NGの場合	マウスを使えないユーザーは、操作できません。
確認方法	マウスを使わず、Tab・Shift＋Tab・Enter・Spaceだけで操作します。

フォーム・計測・原稿のチェック

フォーム・計測・原稿の不備は、見た目に表れないため、公開後まで気づきにくいミスです。問い合わせが届かない、アクセス解析のデータが取れない、連絡先が誤っているといった問題は、成果に影響します。納品前に、実際に送信・発火・照合して確認します。

確認項目	必須入力のエラー表示、送信、管理者宛メール、自動返信メール、サンクスページの表示までを、通しで見ます。
NGの場合	問い合わせが届かず、クライアントの機会損失になります。
確認方法	本番環境で実際に送信し、受信ボックスと迷惑メールフォルダの両方を確認します。送信元ドメインの認証（SPF・DKIM）の設定有無も、迷惑メール判定に影響します。

確認項目	計測タグが想定通りに発火するか、重複して計測されていないか、サンクスページでコンバージョンが計測されるかを見ます。GTM（Googleタグマネージャー）は、計測タグを一括管理するツールです。
NGの場合	広告やアクセス解析のデータが取れない、または二重に計上されます。
確認方法	GTMのプレビューモードや、GA4のリアルタイムレポートなどで確認します。

確認項目	誤字、社名の表記、電話番号、住所、「tel:」リンクの番号を、原稿と突き合わせます。表示している番号とhrefの番号が一致しているかも見ます。
NGの場合	誤った連絡先の公開は、信用問題につながります。
確認方法	原稿とページを並べて照合し、スマートフォンで電話番号をタップして、発信画面を確認します。

確認項目	プライバシーポリシー、特定商取引法に基づく表記、コピーライトの年がそろっているかを見ます。特定商取引法に基づく表記は、通信販売など同法の対象となる事業で必要になります。
NGの場合	法的な指摘を受けたり、古い年表記で信頼性が下がったりします。
確認方法	フッターと各ページを目視で確認します。

公開前・納品前の最終確認

制作環境で問題なく動いていても、本番環境に移した途端に不具合が出ることがあります。URLの置き忘れ、HTTPSの設定漏れ、noindexの解除漏れは、本番のURLで実際に開いて初めて気づく場合があります。公開直前に、本番環境で確認します。

確認項目	テスト環境のURL、ダミーテキストなどが残っていないかを見ます。
NGの場合	リンク切れや画像切れが起き、ダミー文の露出は信用を損ないます。
確認方法	ソース一式を文字列検索し、本番では全ページを巡回します。

確認項目	httpからhttpsへ、wwwの有無を統一した形へ、301リダイレクトされるかを見ます。混在コンテンツとは、HTTPSのページ内でHTTPのリソースを読み込んでいる状態です。SSL証明書の有効期限も確認します。
NGの場合	ブラウザに「保護されていない通信」と表示され、信頼性が下がります。
確認方法	DevToolsのConsoleに、混在コンテンツの警告が出ていないかを確認します。

確認項目	公開時にnoindexが解除されているか、robots.txtで全体をブロックしていないか、sitemap.xml・404ページ・faviconが用意されているかを見ます。robots.txtは、検索エンジンのクローラーに巡回の可否を伝えるファイルです。
NGの場合	公開しても検索結果に表示されません。
確認方法	ソースで「noindex」を検索し、「/robots.txt」と「/sitemap.xml」にアクセスします。存在しないURLを開き、404のステータスが返るかをDevToolsのNetworkパネルで確認します。

確認項目	バックアップファイル、テスト用ページ、認証情報を含むファイルが、公開領域に残っていないかを見ます。HTMLコメントに書いた情報も対象です。
NGの場合	内部情報の流出につながります。
確認方法	サーバー上のファイル一覧と納品物を照合し、ブラウザから不要ファイルのURLに直接アクセスできないかを確認します。

確認項目	契約・仕様で決まっている納品形態（データ納品、サーバーへの公開、納品後の保守など）に応じて、渡す物と引き継ぐ内容が揃っているかを見ます。形態が不明な場合は、公開前に依頼元へ確認します。
NGの場合	納品後に更新や修正ができず、追加の問い合わせや認識違いによるトラブルが生じます。
確認方法	次の表のうち、案件に該当する行を、見積書・仕様書と照合して確認します。

＜納品形態別の確認内容＞

データ納品	ソース一式、フォルダ構成、使用ライブラリ（名称・バージョン）、素材の利用条件、更新・ビルド手順
サーバーへの公開	公開先の環境・アクセス情報の受け渡し方法、公開後の動作確認、不要ファイルの整理
納品後の保守あり	対応範囲・期間・連絡窓口、更新の担当分け、バックアップの取り方、アカウント権限の整理
保守なし	対応範囲外であることの合意、更新手順書の受け渡し

WordPress案件の追加チェック

WordPress案件では、ここまでの項目に加えて、次の3項目を確認します。静的サイトの案件では省略できます。

確認項目	パーマリンク（記事や固定ページのURL構造）の設定、投稿・固定ページ・アーカイブ・404・検索結果の各テンプレートの表示、検索エンジンへの表示設定を見ます。URLをテンプレートに直書きしていないかも確認します。
NGの場合	ページが404になる、本番でリンクが切れる、といった問題が起きます。
確認方法	管理画面の「設定 ＞ パーマリンク」で設定を確認します。構造を変えた後は、保存し直して反映します。「設定 ＞ 表示設定」の検索エンジンに関する項目は、公開時に必ず確認します。

関連リンク：WordPress必須テンプレートタグ一覧

確認項目	クライアントが使う権限（編集者など）でログインし、投稿・固定ページの更新、画像のアップロード、カスタムフィールド（独自の入力欄）の入力と表示反映ができるかを見ます。
NGの場合	クライアントが更新できず、運用開始後に問い合わせが発生します。
確認方法	納品後の運用を想定して、実際に更新作業を一通り行います。

確認項目	不要なプラグインの削除、デバッグ表示の無効化、バックアップの取得と復元の可否を見ます。
NGの場合	エラーメッセージが画面に露出したり、更新時のトラブルから復旧できなくなったりします。
確認方法	管理画面のプラグイン一覧と、「wp-config.php」のデバッグ設定を確認します。バックアップは、取得するだけでなく復元できるかまで試します。

関連リンク：WordPressサイトが表示されない原因と対処法

チェック漏れを減らす運用のコツ

チェック漏れは、ツールで検出できる確認と人の目が必要な確認を分け、制作者以外の目を入れ、自社用のチェックシートを作って更新し続けることで減らせます。リストは一度使って終わりではなく、運用しながら育てるものです。

ツールによる自動化と人の目によるチェック

40項目は、ツールで検出しやすいものと、人が見て判断するものに分けられます。前者はツールに任せて確認の手間を減らし、後者に時間を使うと、確認の精度と効率の両方が上がります。

ツールに任せられる確認と、任せられない確認

ツールが得意なのは、「ルールに照らして機械的に判定できること」です。HTMLの文法エラー、コンソールのエラー、altの未設定、リンク切れなどが該当します。

一方で、「内容が正しいか」「意図どおりか」「使いやすいか」は、ツールでは判定できません。たとえば、altの有無は検出できても、altの文章が画像の内容を適切に説明しているかまでは判断できません。

そのため、40項目は次の3区分で考えると運用しやすくなります。

• 区分は目安です。案件の内容やツールの設定によって変わるため、自社の運用に合わせて調整してください。

ツールで検出できる項目と、目視・実機が必要な項目の比較

観点	ツールで検出できる項目	目視・実機が必要な項目
該当区分	A・B	C
得意なこと	文法エラー、コンソールのエラー、属性の有無、リンク切れ、数値の測定	見た目の照合、操作感、環境による差、内容の正誤
項目の例	HTML文法エラー、コンソールのエラー、リンク切れ、alt・width/height、コントラスト比、計測タグ、HTTPS・リダイレクト	カンプとの照合、ブラウザ・実機・ズーム、UI・埋め込みの操作、フォームの実送信、原稿照合、WordPressの管理画面
人が判断すること	検出された問題の影響範囲と修正の要否 （例：altの内容が適切か）	すべての判断 （ツールでは代替できない）
見落としの原因に なりやすい点	ツールの結果が良いと、問題がないと思い込む	確認の観点が人によってばらつく
漏れを防ぐ工夫	制作中に検査し、手動実行を習慣にする	確認の観点と手順を固定する

この表のとおり、ツールで検出できる項目は「手間を減らす」ことが目的で、目視・実機が必要な項目は「確認の手順を固定する」ことが目的です。たとえば【17】なら、「メニューを開く→閉じる→再度開く」といった操作シナリオを決めておきます。

制作者本人以外の「第三者チェック」を入れる

セルフチェックだけでは、見落としが残ります。制作者とは別の人が確認する工程を1回入れるだけで、公開後の指摘を減らせます。

セルフチェックだけでは見落とす理由

制作者は、自分が作ったものの意図や仕様を知っています。そのため、確認するときも「こう動くはず」という前提で見てしまい、思い込みによる見落としが起こります。

これらは、スキルの問題ではなく、確認する側の見え方の問題です。確認する人を変えるだけで、拾える範囲が変わります。

第三者に任せる項目

セルフチェックで済ませる項目と、第三者に確認してもらう項目を分けると、レビューの負担を抑えられます。以下は目安ですので、自社の体制に合わせて調整してください。

レビューを依頼するときのポイント

第三者チェックは、依頼の仕方で精度が変わります。

自社用チェックシートを作成する

本記事の40項目の一覧を元に、スプレッドシートなどで自社用のシートを作ると、チームの標準として使えます。40項目をそのまま使うだけでなく、案件や体制に合わせて増減させることで、確認の精度と手間のバランスが取れます。

まず整えておきたい列

チェック	OK／NG／対象外の3択。「対象外」があると、該当しない項目で止まらない
No.・項目名・重要度	本記事の一覧のとおり。★★★だけを抽出できる
対象案件	全案件、WordPressのみ など。案件ごとの絞り込みに使う
確認者・確認日	セルフチェックとレビューは列を分けて記録する
備考	NGの内容、対応方法、クライアントとの合意事項

自社の項目を足す

本記事の40項目は、一般的な案件を想定した内容です。自社の案件で繰り返し起きるミスや、クライアント固有のルールは、項目として追加してください。

追加の例	特定のCMSやフレームワーク特有の確認、クライアントのブランドガイドラインとの照合、特定の業界で必要な表記の確認など。
追加の目安	同じミスが2回以上起きた場合や、起きたときの影響が大きい場合は、項目に追加する価値があります。
削除の目安	自社の案件では発生し得ない項目は、「対象外」にするか、シートから外します。

ミスをチェックリストに反映して更新する

チェックリストの精度は、ミスが起きたときに更新することで上がります。公開後に不具合が見つかったら、原因を調べてリストに反映してください。使いながら育てることで、自社の案件に合ったリストになります。

更新の手順

定期的に項目全体を見直す

ミスが起きたときだけでなく、定期的な見直しも必要です。ブラウザの仕様、ツールの画面、法令に関わる表記などが変わるためです。

まとめ

コーディングのミスは、確認の順番と基準を決めておくことで減らせます。本記事の40項目を土台に、自分の案件や自社の運用に合わせて育てていくのが現実的な方法です。

この記事の要点

表示崩れ・フォーム不達・計測漏れ・公開時の設定ミスといった、納品後に起こりやすい不具合を防ぐために、9カテゴリ40項目を整理しました。

項目数	重要な項目で40。★★★の26項目から始め、案件に合わせて増減する
確認のタイミング	制作中・納品前・公開直前に分けると、手戻りが減る
優先して見る領域	表示崩れはCSS・レスポンシブ・画像、成果への影響はフォーム・計測・公開前確認
自動化	文法エラー・コンソールのエラー・リンク切れなどはツールで検出できる。実機確認・フォーム到達・原稿照合は人の目が必要
確認する人	制作者のセルフチェックに加え、第三者の確認を1回入れる
WordPress案件	通常の項目に、【38】〜【40】を加えて確認する

チェックリストは育てて使う

チェックリストは、一度作って終わりではありません。ミスが起きたら原因を調べて項目に反映し、半年に1回など日を決めて、全体を見直します。ブラウザやツールの仕様は変わるため、定期的な更新が、リストの精度を保ちます。

確認の抜け漏れが減るほど、公開後の指摘や手戻りに使っていた時間を、制作に回せます。まずは次の案件で、★★★の項目から試してみてください。