Web制作の受け入れテスト（UAT）チェックリスト｜納品前に確認すべき項目と進め方

受け入れテストとは何か——Web制作における位置づけと発注側の役割

Web制作プロジェクトでは、制作会社がさまざまなテストを経て納品してきます。しかし、制作会社によるテストと、発注側が行う受け入れテストは、目的も確認視点もまったく異なります。この違いを理解しないまま進めると、公開後に思わぬトラブルを招くことになります。

UATとは——Unit TestやQAと何が違うのか

受け入れテストは、英語でUAT（User Acceptance Testing：ユーザー受け入れテスト）と呼ばれます。開発プロセスには複数のテスト工程が存在しており、それぞれ役割が異なります。

• 単体テスト（Unit Test）：個々のプログラムやモジュールが仕様どおりに動くかを開発者が確認する工程
• 結合テスト（Integration Test）：複数の機能を組み合わせたときに正しく連携するかを検証する工程
• QA（品質保証テスト）：制作会社内の品質管理担当者が、全体的な動作や表示の不具合を洗い出す工程
• UAT（受け入れテスト）：発注側が自社の業務要件・ユーザー視点で最終確認を行う工程

単体テストや結合テストは、あくまで「設計書どおりに動いているか」を検証するものです。一方、UATは「自社のビジネス目的やユーザーの利用シナリオに照らして問題がないか」を確認します。確認の主体も、判断基準も、根本的に異なります。

発注側が主体で行う理由——制作会社任せにできない背景

「制作会社がテスト済みなら問題ないはず」と考える担当者は少なくありません。しかし、制作会社が持っていない情報が必ず存在します。

たとえば、フォームから送信された問い合わせを受け取る社内の運用フロー、特定の取引先だけが使う機能の業務上の意味、スマートフォンで閲覧するユーザーが多い特定のページの重要性——こうした業務文脈は、発注側にしか判断できません。制作会社は仕様書に基づいて開発を進めますが、仕様書に書かれなかった暗黙の要件や、運用段階で初めて気づく確認事項までカバーすることは難しいのが実情です。

受け入れテストは、発注側が「自分たちの業務で本当に使えるか」を判定する最終関門です。この工程を発注側が主体的に担うことが、プロジェクトの成否を左右します。

受け入れテストを省いたまま公開するとどうなるか

受け入れテストを省略、または形式的にしか行わないまま公開した場合、以下のようなトラブルが起きやすくなります。

• フォームの不達：問い合わせフォームから送信しても、担当者のメールボックスに届かない。送信完了画面は表示されるため、制作会社のQAでは見落とされやすい
• スマートフォンでのレイアウト崩れ：PCブラウザでは正常に見えても、実機のスマートフォンでボタンが押せない・文字が重なるといった問題が残っている
• リンク切れ・誤リンク：移行前のURLが残っていたり、社内ドキュメントへのリンクが外部公開環境では機能しなかったりする
• 旧コンテンツの残存：更新前の価格情報・廃止したサービスの説明がページ内に残ったまま公開される

これらは制作会社の過失というより、発注側の業務要件や運用ルールを踏まえた確認がなければ発見できないケースがほとんどです。公開後に修正対応が発生すれば、追加費用や対外的な信頼損失につながることもあります。受け入れテストは、こうしたリスクを事前に潰すための仕組みです。

受け入れテストとは何か——Web制作における位置づけと発注側の役割

UATとは——Unit TestやQAと何が違うのか

UAT（User Acceptance Test：ユーザー受け入れテスト）とは、システムやWebサイトを本番公開する前に、発注側が「自分たちの業務要件を満たしているか」を最終確認するテストです。

開発プロセスには複数のテスト工程が存在します。単体テスト（Unit Test）は開発者がコードの部品ごとに動作を検証するもので、結合テストは部品同士を組み合わせた際の整合性を確認するものです。QA（品質保証）は制作会社の内部チームが仕様書との一致を検証します。いずれも制作側の視点による確認です。

UATはこれらとは性質が異なります。「仕様書どおりに動いているか」ではなく、「実際の業務フローやユーザー行動に照らして使えるか」を、発注側自身が確かめる工程です。

発注側が主体で行う理由——制作会社任せにできない背景

「制作会社がテスト済みなら問題ないはず」と考える担当者は少なくありません。しかし、この認識がトラブルの温床になりがちです。

制作会社が確認できるのは、あくまで合意した仕様の範囲内です。発注側の社内業務フロー、実際のユーザー層が使うデバイス・環境、問い合わせ後の社内対応ルートなど、制作会社が把握しきれない要素は多く残ります。

たとえば、フォームの送信先メールアドレスが正しいかどうかは、社内の運用ルールを知っている発注側でなければ判断できません。受け入れテストは、発注側にしか担えない確認工程です。

受け入れテストを省いたまま公開するとどうなるか

受け入れテストを省略したまま公開した場合、以下のようなトラブルが実際に起きやすくなります。

• フォーム不達：問い合わせや資料請求のフォームを送信しても、担当者にメールが届かない。顧客の声がそのまま消える状態が続く
• スマートフォン崩れ：PCでは正常に表示されていても、スマートフォンやタブレットでレイアウトが崩れている
• リンク切れ：ナビゲーションや資料ダウンロードのリンクが404エラーになっている
• 表記・情報の誤り：会社所在地・電話番号・担当部署名が古い情報のまま公開されている

これらは公開後に外部のユーザーが発見するケースも多く、ブランドへの信頼損失につながります。受け入れテストは「念のための確認」ではなく、公開可否を判断するための正式な検収工程と位置づけることが重要です。

受け入れテストを始める前に整えておく3つの準備

受け入れテスト（UAT）は、チェックリストさえあれば始められると思われがちです。しかし実際には、テストを開始する前に整えておくべき環境・体制・基準の3つが揃っていないと、途中で手戻りが発生し、検収期間が大幅に延びるケースが少なくありません。

ステージング環境の確認と本番との差異リスク

受け入れテストは、原則としてステージング環境（本番公開前の確認用サーバー）で実施します。ただし、ステージング環境と本番環境の設定が完全に一致していないケースは多く、そのまま見過ごすとテスト結果の信頼性が下がります。

事前に制作会社へ確認しておくべき差異の代表例は以下のとおりです。

• フォームの送信先メールアドレスが本番用に切り替わっているか
• 外部サービス（決済、CRM連携など）がテストモードのままになっていないか
• SSL証明書、リダイレクト設定が本番と同じ構成で動作しているか
• 画像やCSS、JavaScriptのパスが本番ドメインを前提にしていないか

これらを確認せずにテストを進めると、「ステージングでは正常だったが本番では動かない」という事態が起きやすくなります。テスト開始前に、制作会社から環境差異の一覧と対応状況を書面で受け取ることを推奨します。

担当者・承認者・制作会社の役割を事前に決める

受け入れテストで多いのが、「誰がどの項目を確認し、誰が最終的にOKを出すのか」が曖昧なまま始めてしまうケースです。テスト中に問題が見つかったとき、確認・判断・連絡の経路が明確でないと、対応が止まります。

最低限、以下の3つの役割を事前に決めておきましょう。

• テスト実施担当者：チェックリストに沿って実際に操作・確認を行う担当者
• 承認権者：テスト結果を踏まえて「合格・差し戻し」を最終判断できる意思決定者
• 制作会社の窓口：不具合報告を受け取り、修正対応・回答の一次窓口となる担当者名

特に承認権者が不在のままテストが進むと、差し戻し判断が後倒しになり、公開スケジュールに影響します。役割分担はプロジェクト開始時のキックオフで合意し、文書化しておくことが理想です。

「合格基準」を先に合意しておかないと検収が長引く

受け入れテストで最も見落とされがちな準備が、合否判定基準の事前合意です。「どの状態になれば合格とするか」を定義しないままテストを行うと、検収終盤になって発注側と制作会社の認識がずれ、追加修正の範囲をめぐる交渉が発生しやすくなります。

合格基準として事前に合意しておくべき論点は以下のとおりです。

• 対応ブラウザ・デバイスの範囲（例：Chrome最新版、iOS Safari 16以上、など）
• 軽微な表示崩れの扱い（修正必須か、許容範囲かの線引き）
• 発見された不具合の優先度分類（公開ブロック／公開後対応可の基準）
• テスト期間中に追加された仕様変更の扱い（UAT対象外とするか）

これらを契約書や仕様書に明記しておくことが理想ですが、難しい場合でもテスト開始前にメールやドキュメントで双方が確認・同意した状態を作っておくことで、検収の長期化を防ぐことができます。

受け入れテストを始める前に整えておく3つの準備

チェックリストを用意しても、テストを始める前の準備が整っていなければ、確認作業の途中で手が止まります。「誰がこれを判断するのか」「この環境で確認して問題ないのか」「ここまでOKにしていいのか」といった疑問が現場で生じると、都度の確認が発生し、検収期間が想定以上に長引くことになります。

受け入れテスト（UAT：User Acceptance Testing）をスムーズに進めるには、テスト環境・役割分担・合否判定基準の3点を事前に固めておくことが重要です。

ステージング環境の確認と本番との差異リスク

受け入れテストは、原則としてステージング環境（本番公開前の検証用サーバー）で実施します。しかし、ステージング環境が本番環境と完全に一致していないケースは少なくありません。

たとえば、以下のような差異が生じていることがあります。

• ドメインやSSL証明書の設定が本番と異なる
• メール送信の設定が無効化されており、フォームのテストができない
• 外部APIやCRMとの連携先がテスト用エンドポイントになっている
• キャッシュ設定やCDNの挙動が本番と異なる

これらの差異を把握せずにテストを始めると、「ステージングでは問題なかったのに本番で動かない」という事態が発生します。テスト開始前に制作会社へ「本番環境との差異一覧」を書面で提出してもらうと、確認漏れを防ぎやすくなります。

担当者・承認者・制作会社の役割を事前に決める

受け入れテストで生じやすい混乱の一つが、「誰が確認して、誰がOKを出すのか」が明確でないまま作業が進むことです。

テスト工程には、大きく3つの役割があります。

• テスト実施担当者：実際にブラウザを操作してチェックリストを埋める担当者
• 承認権者：不具合の修正依頼の可否や公開判断を行う意思決定者
• 制作会社の窓口：不具合報告を受け取り、対応の優先順位を判断するプロジェクト担当者

担当者が自己判断で「これは問題ない」と通過させたり、逆に軽微な表示ズレで承認者に判断を仰いで時間をとったりするのは、役割が曖昧なために起こります。テスト開始前に役割と判断権限の範囲をチーム内で共有しておくことが、工数の無駄を防ぐ上で有効です。

「合格基準」を先に合意しておかないと検収が長引く

受け入れテストで最も議論が長引くのは、「これはバグなのか、仕様なのか」という判断が分かれる場面です。この問題は、合否の判定基準を事前に合意していないことが原因である場合がほとんどです。

テスト開始前に、発注側と制作会社の間で以下の基準を明文化しておくことを推奨します。

• 必須修正（公開ブロック）：フォームの送信エラー、決済の不具合、個人情報の漏洩リスクなど、公開を止める水準の不具合
• 修正推奨（公開後対応可）：特定ブラウザ・特定解像度でのレイアウトの微細なズレなど、UXへの影響が限定的なもの
• 対応不要（仕様として受け入れ）：設計段階で合意済みの動作、または優先度が低くコストに見合わないもの

この3段階の基準を書面で合意しておくことで、個々の不具合報告に対して「これはどちらか」という判断を速やかに下せるようになります。基準のないまま検収を進めると、担当者レベルでは判断できない案件が積み上がり、承認者の確認待ちで工程全体が止まるリスクがあります。

カテゴリ別チェックリスト——納品前に確認すべき全項目

受け入れテストの準備が整ったら、次は実際の確認作業に入ります。確認項目は大きく6つのカテゴリに分類できます。各項目には「なぜ確認するか」の理由と「どう確認するか」のヒントを添えているため、技術的な知識がなくても発注側担当者が判断できる粒度で活用できます。

【表示・レイアウト】ブラウザ・デバイス別の見た目の崩れ

制作環境と閲覧環境は異なります。制作会社のPC上では正常に見えても、ユーザーが実際に使うブラウザやデバイスでレイアウトが崩れているケースは少なくありません。

• 確認項目：Chrome・Safari・Edge・Firefoxの最新版で表示を確認する
• 確認項目：スマートフォン（iOS・Android）でのレイアウト・文字サイズ・ボタンの押しやすさを確認する
• 確認項目：画像が指定のサイズ・位置で表示されているか確認する
• なぜ確認するか：ブラウザごとにHTMLやCSSの解釈が微妙に異なるため、特定環境でのみ崩れが発生することがあります。
• 確認方法のヒント：BrowserStackなどのツールを使うと、手元にないデバイスの表示もシミュレーションできます。

【リンク・ナビゲーション】内部リンク・外部リンク・アンカーの動作

リンク切れはユーザー体験を大きく損ないます。特にグローバルナビゲーションや重要なCTAボタンにリンク切れがあると、サイトへの信頼性そのものが下がります。

• 確認項目：全ページのグローバルナビゲーション・フッターリンクが正しいURLに遷移するか確認する
• 確認項目：外部リンクが意図したページに飛び、必要に応じて別タブで開くか確認する
• 確認項目：ページ内アンカーリンクが正確な位置にスクロールするか確認する
• なぜ確認するか：CMSへの移行やページのURL変更によって、制作途中でリンクが断ち切られるケースがよくあります。
• 確認方法のヒント：Screaming Frogなどのクローラーツールでサイトをスキャンすると、リンク切れを一括で検出できます。

【フォーム・入力機能】送信・バリデーション・自動返信メールの確認

フォームはリード獲得や問い合わせの入口です。送信エラーや自動返信メールの不達が起きると、ビジネス上の機会損失に直結します。

• 確認項目：必須項目が空欄のまま送信しようとしたとき、適切なエラーメッセージが表示されるか確認する
• 確認項目：正常送信後に、ユーザーへの自動返信メールと管理者への通知メールが届くか確認する
• 確認項目：メールアドレスや電話番号など、形式チェック（バリデーション）が機能するか確認する
• なぜ確認するか：送信先メールアドレスの設定ミスや迷惑メールフィルターへの誤分類は、テストをしないと公開後まで気づかないことが多いです。
• 確認方法のヒント：テスト用のメールアドレスを複数用意し、実際に送信して受信を確認します。自動化ツールを使う方法については後述のセクションで詳しく解説します。

【コンテンツ・テキスト】誤字脱字・差し替え漏れ・画像の代替テキスト

コンテンツの品質はブランドの信頼性に直結します。特に担当者の氏名・役職・電話番号などの固有情報は、差し替え漏れが起きやすい箇所です。

• 確認項目：仮テキスト（「Lorem ipsum」や「〇〇〇〇」など）が残っていないか全ページを確認する
• 確認項目：会社名・住所・電話番号・担当者名が最新の情報になっているか確認する
• 確認項目：画像にalt属性（代替テキスト）が適切に設定されているか確認する
• なぜ確認するか：alt属性の欠落はアクセシビリティ上の問題になるだけでなく、SEO評価にも影響します。
• 確認方法のヒント：ブラウザの開発者ツールで画像要素を選択し、alt属性の有無と内容を目視で確認できます。

【SEO・メタ情報】タイトルタグ・ディスクリプション・OGP・canonical

メタ情報の設定ミスは公開直後から検索順位や拡散に影響します。特にタイトルタグの重複やcanonicalの設定ミスは、後から修正しても評価の回復に時間がかかります。

• 確認項目：各ページにユニークなタイトルタグとメタディスクリプションが設定されているか確認する
• 確認項目：OGP（Open Graph Protocol）タグが設定され、SNSシェア時に意図した画像・タイトルが表示されるか確認する
• 確認項目：canonicalタグが正しいURLを指しているか確認する
• なぜ確認するか：テンプレートをコピーして制作した場合、canonicalが別ページのURLを参照したままになっているケースがあります。
• 確認方法のヒント：Google Search ConsoleのURL検査ツール、またはブラウザ拡張のSEO Meta in 1 Clickで各ページのメタ情報を素早く確認できます。

【セキュリティ・パフォーマンス】SSL・表示速度・エラーページの設定

セキュリティとパフォーマンスは、ユーザーの離脱率とサイトへの信頼に直結します。公開後に「サイトが遅い」「404ページがデフォルトのまま」と気づくと、対応コストが余分にかかります。

• 確認項目：サイト全体がHTTPS（SSL）で配信されており、証明書の有効期限に余裕があるか確認する
• 確認項目：Google PageSpeed Insightsで主要ページのスコアを測定し、制作会社と合意した基準を満たしているか確認する
• 確認項目：存在しないURLにアクセスしたときに、カスタマイズされた404エラーページが表示されるか確認する
• なぜ確認するか：混在コンテンツ（HTTPとHTTPSが混在している状態）があると、ブラウザが警告を表示し、ユーザーの信頼を損ないます。
• 確認方法のヒント：Why No Padlock?などの無料ツールを使うと、混在コンテンツを簡単に検出できます。

カテゴリ別チェックリスト——納品前に確認すべき全項目

受け入れテストで確認すべき項目は、大きく6つのカテゴリに整理できます。各項目には「なぜ確認するか」の理由と「確認方法のヒント」を添えています。制作会社への指摘や合否判定の根拠として活用してください。

【表示・レイアウト】ブラウザ・デバイス別の見た目の崩れ

レイアウト崩れは、特定の環境でのみ発生するケースが少なくありません。制作会社の開発環境では問題がなくても、実際の利用者が使うブラウザやデバイスで崩れが起きることがあります。

• 確認項目：Chrome・Safari・Edge・Firefoxの最新版で表示が崩れていないか
• 確認項目：iOS Safari・Android Chromeでの表示・スクロール動作に問題がないか
• 確認項目：画像・ボタン・テキストが想定の位置に収まっているか
• 確認方法のヒント：社内で実際に使われているデバイスと同じ機種・OSバージョンで確認するのが最も確実です。複数機種を用意できない場合は、BrowserStackなどのクロスブラウザ検証ツールを補助的に使う方法もあります。

【リンク・ナビゲーション】内部リンク・外部リンク・アンカーの動作

リンク切れは公開後に発覚しやすく、ユーザーの離脱や信頼低下に直結します。特にページ数の多いサイトでは、差し替えやURL変更に伴うリンク切れが発生しやすいため、網羅的な確認が必要です。

• 確認項目：グローバルナビゲーションのリンクがすべて正しいページに遷移するか
• 確認項目：バナー・テキストリンク・ボタンのリンク先URLが正しいか
• 確認項目：外部リンクが新規タブで開くよう設定されているか
• 確認項目：ページ内アンカーリンクが正しい位置にスクロールするか
• 確認方法のヒント：Screaming FrogなどのURL抽出ツールでリンク一覧を取得し、404エラーが発生するURLを洗い出す方法が効率的です。

【フォーム・入力機能】送信・バリデーション・自動返信メールの確認

フォームはビジネス上の問い合わせや商談につながる重要な接点です。送信エラーや自動返信メールの未着は、機会損失と顧客への信頼失墜を同時に引き起こします。

• 確認項目：必須項目を空欄のまま送信したときにエラーメッセージが表示されるか
• 確認項目：メールアドレス形式のバリデーションが機能しているか
• 確認項目：送信完了後にサンクスページまたは完了メッセージが表示されるか
• 確認項目：自動返信メールが送信者に届くか、管理者宛て通知メールが届くか
• 確認項目：メール本文の差し込み情報（氏名・入力内容など）が正しく反映されているか
• 確認方法のヒント：テスト用のメールアドレスを複数用意し、正常系（正しい入力での送信）と異常系（空欄・不正な形式）の両方を必ず確認します。

【コンテンツ・テキスト】誤字脱字・差し替え漏れ・画像の代替テキスト

テキストや画像の確認は軽視されがちですが、公開後の誤字は企業の信頼性に直接影響します。また、画像の代替テキスト（alt属性）はアクセシビリティとSEOの両面で重要です。

• 確認項目：仮テキスト（「Lorem ipsum」や「◯◯◯」など）が残っていないか
• 確認項目：会社名・サービス名・電話番号・所在地などの基本情報に誤りがないか
• 確認項目：差し替えを依頼した画像・テキストが最新版に更新されているか
• 確認項目：画像にalt属性が設定されており、内容を適切に説明しているか
• 確認方法のヒント：ページをプリントアウトして目視確認すると、画面で見落としていた誤字を発見しやすくなります。

【SEO・メタ情報】タイトルタグ・ディスクリプション・OGP・canonical

メタ情報の設定ミスは、検索エンジンへの誤ったシグナル送信や、SNSでの見た目の崩れにつながります。公開直後は検索エンジンのクロールが集中するため、修正が遅れるほど影響が長引く点に注意が必要です。

• 確認項目：各ページにユニークなtitleタグとmeta descriptionが設定されているか
• 確認項目：OGP（Open Graph Protocol）タグが設定され、SNSシェア時に正しいタイトル・画像が表示されるか
• 確認項目：canonicalタグが正しいURLを指定しているか
• 確認項目：noindexタグが公開すべきページに誤って設定されていないか
• 確認方法のヒント：FacebookのシェアデバッガーやGoogle Search ConsoleのURL検査ツールを使うと、実際のクローラー視点での確認ができます。

【セキュリティ・パフォーマンス】SSL・表示速度・エラーページの設定

セキュリティとパフォーマンスは、ユーザー体験と検索順位の両方に影響します。特にSSLの設定ミスは、ブラウザに「保護されていない通信」と表示されるため、公開と同時にユーザーの不信感を招くリスクがあります。

• 確認項目：すべてのページがhttpsで配信され、ブラウザのアドレスバーに鍵アイコンが表示されるか
• 確認項目：httpでアクセスした場合にhttpsへ自動リダイレクトされるか
• 確認項目：存在しないURLにアクセスしたときに適切な404ページが表示されるか
• 確認項目：Google PageSpeed Insightsなどで表示速度を計測し、極端なスコア低下がないか
• 確認方法のヒント：表示速度はモバイルとPC両方で計測します。スコアが大きく下がっている場合は、画像サイズや不要なスクリプトの見直しを制作会社に依頼する判断材料になります。

フォームテストは工数がかかりやすい——手作業の限界と見落としリスク

受け入れテストの中でも、フォームの確認は特に工数がかかりやすい領域です。見た目の確認とは異なり、フォームには「入力値の組み合わせ」「送信後の挙動」「エラー時の表示」など、確認すべき軸が複数重なります。結果として、担当者が「代表的なパターン1件だけ送信してOKにした」という判断をしてしまうケースが少なくありません。

フォームの確認項目が多い理由——入力パターン×送信先×レスポンスの組み合わせ

1つのお問い合わせフォームを例に取っても、確認すべき項目は想像以上に多岐にわたります。

• 入力バリデーション：必須項目の未入力、文字数超過、全角・半角の混在、メールアドレス形式の誤りなど
• 送信先の正確性：管理者宛の通知メールが正しいアドレスに届いているか、複数担当者に分岐する場合は条件が正しく機能しているか
• 自動返信メール：送信者に届く内容・差出人名・件名が仕様どおりか
• エラーメッセージの表示：入力ミス時にユーザーが修正できる情報が適切に表示されているか
• 添付ファイル対応：許可する拡張子・ファイルサイズの上限が設定どおりに機能しているか

これらは独立した確認項目ではなく、「どの入力パターンで」「どの送信先に」「どのレスポンスが返るか」という組み合わせとして検証する必要があります。1フォームあたりでも、網羅的に確認しようとすると相応の時間がかかります。

ページ数が増えると全件手動確認は現実的でなくなる

フォームが1つだけのサイトであれば、手動確認も何とか対応できます。しかし、複数のサービスページにそれぞれ資料請求・見積依頼・採用応募などのフォームが設置されている場合、確認対象は一気に増えます。

たとえば10ページのサイトに8種類のフォームがあり、それぞれで5〜10パターンの入力テストが必要だとすると、手動で全件確認するだけで数時間から半日以上かかる計算になります。プロジェクトの納期直前という状況では、この工数を確保すること自体が難しいケースがほとんどです。

時間的な制約から「主要なフォームだけ確認した」「正常系のみ送信して完了とした」という判断が生まれやすく、それが納品後のトラブルにつながります。

見落とされやすいケース——条件分岐・必須チェック・添付ファイル対応

手動テストで特に見落とされやすいのは、通常の操作フローでは発生しにくい条件です。

条件分岐を持つフォームでは、たとえば「お問い合わせ種別」の選択によって送信先が変わる設計になっている場合、全パターンを個別に送信して確認する必要があります。1パターンだけ確認して正常に機能していても、別の選択肢では送信先が未設定のまま本番公開されるリスクがあります。

また、必須項目のバリデーションについても、JavaScriptによるフロント側のチェックだけでサーバー側の検証が実装されていないケースがあります。この場合、ブラウザの設定によってはバリデーションをすり抜けた不正なデータが送信される可能性があります。

添付ファイル対応では、許可された拡張子以外のファイルを送信しようとしたときの挙動や、上限サイズを超えた場合のエラー表示が適切かどうかも確認が必要です。これらは正常系の操作では一切触れない領域であるため、意図的に異常系を試みないと見落としが生じます。

Web制作の受け入れテストにおいて、フォームの確認を「送信できれば完了」と捉えるのは、チェックリストとして不十分です。確認軸の多さと、ページ数・フォーム数の増加に伴う工数の膨張を踏まえたうえで、テスト設計の段階からどう対応するかを考える必要があります。

フォームテストは工数がかかりやすい——手作業の限界と見落としリスク

受け入れテストの中でも、フォームの確認は特に工数がかさみやすい領域です。見た目の確認とは異なり、フォームは「入力値」「送信後の挙動」「受信側の処理」が絡み合うため、確認すべき組み合わせが多くなります。

フォームの確認項目が多い理由——入力パターン×送信先×レスポンスの組み合わせ

一口に「フォームの確認」と言っても、実際にチェックすべき軸は複数あります。

• 入力パターン：正常値・境界値・異常値（空欄・文字数超過・記号入力など）
• バリデーション：必須項目の未入力エラー、メールアドレス形式チェック、電話番号の桁数制限など
• 送信先：担当部署ごとにメール宛先が異なる場合、条件分岐が正しく機能しているか
• 自動返信メール：送信者に届く内容・件名・差出人名が仕様通りか
• エラーメッセージ：表示タイミング・文言・表示位置が適切か

これらの軸を掛け合わせると、1つのフォームでも確認パターンは数十件規模になることがあります。問い合わせフォーム・資料請求フォーム・採用エントリーフォームなど、種類が増えるほど総確認数はさらに膨らみます。

ページ数が増えると全件手動確認は現実的でなくなる

サイト規模が大きくなるにつれ、フォームの総数も増加します。サービスサイトやコーポレートサイトでは、フォームが5〜10種類以上設置されているケースは珍しくありません。

仮に1フォームあたり30パターンの確認が必要だとすると、10種類では300件の手動操作が発生します。担当者がテスト期間中にこれを全件こなすのは、通常業務と並行すると現実的に難しいケースがほとんどです。結果として「主要なフォームだけ」「1パターンだけ試してOKにする」という判断が起きやすくなります。

見落とされやすいケース——条件分岐・必須チェック・添付ファイル対応

手作業での確認で特に抜け落ちやすいのは、次のような場面です。

• 条件分岐のある送信先：「お問い合わせ種別」によって通知先メールアドレスが変わる設定で、特定の選択肢だけ宛先が誤っているケース
• 必須チェックの抜け：画面上は必須マークが付いているのに、空欄のまま送信できてしまうケース
• 添付ファイルの制限：ファイルサイズ上限・拡張子制限が仕様通りに機能しているかの未確認
• 自動返信メールの文字化け・リンク切れ：テキスト本文や署名内のURLが正しく表示されないケース

Web制作の受け入れテストチェックリストに「フォームの送信確認」と記載されていても、確認の粒度が担当者任せになっていると、こうした見落としは防ぎにくいです。確認軸と確認パターンをあらかじめ明文化しておくことが、テストの品質を左右します。

フォームテストの自動化——form auto runnerでバッチ実行する方法

フォームのテストを手作業で行う場合、確認すべき項目が多く、工数が膨らみやすい課題があります。CLANEが提供するmacOSアプリ「form auto runner」は、こうした課題に対応するために開発されたフォームテスト自動化ツールです。

form auto runnerでできること——自動入力・送信・結果記録の仕組み

form auto runnerは、指定したWebフォームに対してテストデータを自動で入力し、送信までを一連の流れで実行するツールです。実行後は成功・失敗の結果をスクリーンショット付きで記録するため、テスト実施の証跡をそのまま保存できます。手動で1件ずつ確認していた作業を、ツールが代行する仕組みです。

CSVでURLを一括登録してバッチ実行する手順のイメージ

使い方の流れはシンプルです。まず、テスト対象のフォームURLとテストデータをCSVファイルに記述します。次に、そのCSVをform auto runnerに読み込ませると、登録したURLを順番に処理するバッチ実行が開始されます。複数ページのフォームが存在するサイトでも、CSVに列挙するだけでまとめてテストを走らせることができます。

スクリーンショット付き履歴で制作会社との認識齟齬をなくす

テスト結果はスクリーンショットとともに記録されます。「送信が通った」「エラーが出た」という口頭の報告だけでなく、画面の状態をそのまま証拠として残せるため、制作会社への差し戻し時に認識のズレが生じにくくなります。特に、エラーの再現性が問われる場面では、スクリーンショット付きの記録が正確なコミュニケーションを支えます。

どんな規模・体制の受け入れテストに向いているか

form auto runnerが特に力を発揮するのは、次のような状況です。

• 問い合わせフォーム・資料請求フォームなど、確認対象のフォームが複数ページにわたる場合
• テスト担当者がWebの技術知識を持たない場合でも、CSVの記述さえできれば実行できる点
• リニューアル後の回帰テストなど、同じフォームを繰り返し確認する必要がある場合

専任のQAエンジニアがいない発注側の体制でも運用できる設計になっており、Web制作のUAT（User Acceptance Testing：ユーザー受け入れテスト）において、フォーム確認の抜け漏れを減らしたい担当者に向いています。

フォームテストの自動化——form auto runnerでバッチ実行する方法

フォームのテストを効率化する手段として、CLANEはmacOS向けアプリ「form auto runner」を提供しています。複数のフォームURLをCSVで一括登録し、自動入力・送信・結果記録をバッチ処理で実行できるツールです。

form auto runnerでできること——自動入力・送信・結果記録の仕組み

form auto runnerは、フォームへの入力値をCSVで定義し、その内容をもとにブラウザ操作を自動化します。具体的には次の一連の処理を自動で実行します。

• 指定URLのフォームページを開く
• CSVに記載した入力値を各フィールドに流し込む
• 送信ボタンを押して完了画面への遷移を確認する
• 成功・失敗の判定結果をスクリーンショット付きで保存する

手作業では1件ずつ行っていた確認作業を、ツールが代行します。テスト担当者が画面に張り付く必要がなく、バッチ実行中に別の確認作業を並行して進めることができます。

CSVでURLを一括登録してバッチ実行する手順のイメージ

利用の流れはシンプルです。まずテスト対象のフォームURLと、各フィールドに入力する値をCSVファイルに記載します。次にそのCSVをform auto runnerに読み込ませ、実行ボタンを押すだけです。複数ページのフォームをCSVに並べておけば、順番にテストが実行されます。

たとえば「問い合わせフォーム」「資料請求フォーム」「採用エントリーフォーム」を1つのCSVにまとめれば、3つのフォームを連続してテストできます。手順を覚えれば、非エンジニアの担当者でも運用できる設計になっています。

スクリーンショット付き履歴で制作会社との認識齟齬をなくす

テスト結果はスクリーンショットと合わせて記録されます。「送信後にエラーが表示された」「完了画面に遷移しなかった」といった不具合を、画面キャプチャの状態で制作会社に共有できます。口頭や文章だけの報告では起きやすい「再現できない」「条件が不明確」といった認識のずれを減らせます。

どんな規模・体制の受け入れテストに向いているか

フォームの数が多いサイトリニューアル案件や、複数の入力パターンを網羅したいケースに向いています。一方、フォームが1〜2件程度であれば手動確認でも対応できる場合があります。専任のテスト担当者を置けない体制で、限られた工数の中でフォームテストの品質を担保したい場面で、特に効果を発揮します。

テスト結果の記録・報告——制作会社への差し戻し方と合否判定の進め方

受け入れテスト（UAT）で問題を発見しても、制作会社への伝え方が不明確だと修正の精度が下がり、手戻りが増えます。テスト後の「後処理フェーズ」を丁寧に設計することが、スムーズな検収と本番公開への近道です。

指摘事項の記録フォーマット——再現手順とスクリーンショットをセットで残す

指摘事項は「何が、どこで、どういう状態になっているか」を誰が読んでも再現できる形式で記録します。口頭やチャットの断片的なやり取りでは、制作会社側が問題を正確に把握できないケースが少なくありません。

記録フォーマットには、次の項目を最低限含めるようにします。

• 確認環境：OS・ブラウザ・バージョン・画面サイズ
• 再現手順：「①〇〇ページを開く → ②フォームに△△を入力する → ③送信ボタンを押す」のようにステップ単位で記載
• 期待される動作：仕様書や要件定義に照らした正しい挙動
• 実際の動作：発生した問題の状態
• スクリーンショット：問題が発生している画面をキャプチャし、矢印や赤枠で該当箇所を明示

スクリーンショットは「証拠」ではなく「伝達手段」として活用します。再現手順と組み合わせることで、制作会社が同じ状態を再現しやすくなり、修正対応のスピードが上がります。

修正優先度の分類——必須・推奨・次回対応の3段階で合意する

指摘事項を一律に「修正依頼」としてまとめると、制作会社側での対応優先順位が曖昧になります。本番公開の判断基準を明確にするために、優先度を3段階に分類して合意しておくことが有効です。

• 必須修正：公開前に解消しなければならない問題。フォームが送信できない、リンクが404になる、個人情報の取り扱いに関わる不具合など、ビジネスや法的リスクに直結するもの
• 推奨修正：公開後の品質や体験に影響するが、緊急度は高くない問題。表示崩れ・誤字脱字・画像の縦横比のずれなど
• 次回対応：今回のスコープ外または軽微な改善要望。運用フェーズの改修案件として切り出すことを前提に記録しておく

この分類は、発注側と制作会社が口頭や書面で明示的に合意しておくことが重要です。「必須修正」の定義が両者でずれていると、差し戻し後の再テストで同じ問題が繰り返されます。

再テストと本番公開判断のフロー

差し戻し後の再テストは、修正された箇所だけでなく、その周辺機能も含めて確認します。修正による意図しない影響（デグレード）が起きていないかを確かめるためです。

本番公開の判断フローは、以下のステップを基本とします。

1. 「必須修正」の全項目が解消されていることを確認する
2. 再テストで新たな問題が発生していないかを確認する
3. 「推奨修正」の対応状況と残課題を記録し、発注側・制作会社で共有する
4. 関係者（責任者・承認者）が合否を判定し、公開日を確定する

合否判定は担当者一人で行わず、承認権限を持つ責任者が最終確認するフローを設けておくことで、「担当者レベルでは見落とせない判断」を組織として担保できます。テスト結果と合否判定の記録は、後のトラブル対応や次回プロジェクトの参考資料としても機能します。

テスト結果の記録・報告——制作会社への差し戻し方と合否判定の進め方

テストで問題を発見しても、その後の記録・報告・差し戻しが曖昧だと、修正漏れや認識齟齬が生じます。Web制作のUAT（受け入れテスト）における「後処理フェーズ」は、完成度を左右する重要な工程です。

指摘事項の記録フォーマット——再現手順とスクリーンショットをセットで残す

指摘を口頭やチャットのみで伝えると、制作会社側で現象を再現できないケースが少なくありません。記録には、以下の要素をセットで残すことを推奨します。

• 発生画面のスクリーンショット（エラー表示・レイアウト崩れなど、視覚的な証拠）
• 再現手順（「①トップページにアクセス　②お問い合わせボタンをクリック　③入力欄に〇〇を入力して送信」のように番号付きで記載）
• 確認環境（ブラウザ名・バージョン・OS・デバイス種別）
• 期待される動作と実際の動作（「〇〇が表示されるはずが、△△が表示される」）

これらをスプレッドシートやプロジェクト管理ツール（BacklogやNotionなど）に一元管理すると、抜け漏れの追跡が容易になります。スクリーンショットはファイル名に日付と画面名を含めておくと、後から照合しやすくなります。

修正優先度の分類——必須・推奨・次回対応の3段階で合意する

すべての指摘を同列に扱うと、制作会社の対応工数が見積もれず、本番公開判断も遅れます。指摘事項は以下の3段階で優先度を分類し、発注側と制作会社の間で事前に定義・合意しておくことが重要です。

• 必須修正：本番公開の条件。フォームが送信できない、リンクが全件404エラーになるなど、ビジネス上の致命的な不具合が該当します。
• 推奨修正：公開前に対応できれば望ましいが、代替手段があれば許容できる指摘。表示の微妙なズレや一部デバイスでのレイアウト崩れなどが例として挙げられます。
• 次回対応：現バージョンでは許容し、次期改修で対応する事項。要望追加や軽微なUI改善など、スコープ外の変更が多くなります。

この分類を差し戻し時に明示することで、制作会社は対応順序を判断しやすくなり、やり取りの往復回数を減らすことができます。

再テストと本番公開判断のフロー

差し戻し後は、修正が完了した旨の連絡を受けてから再テストを実施します。再テストの対象は「必須修正として指摘した項目」に絞るのが原則です。全項目を一から確認し直すと工数が膨らみ、公開スケジュールが遅延するリスクがあります。

本番公開の合否判定は、次の基準を目安にするとよいでしょう。

1. 必須修正の指摘がすべてクローズされていること
2. 推奨修正について、未対応のものは発注側が内容を確認し、許容を明示していること
3. 発注側の担当者が最終確認を行い、承認の意思表示（メールや管理ツール上のコメント）を残していること

承認の記録を残すことは、後日トラブルが生じた際の責任の所在を明確にするうえでも重要です。口頭での「OKです」ではなく、テキストで証跡を残す習慣を徹底してください。

まとめ——受け入れテストを「作業」から「検収の仕組み」に変えるために

Web制作の受け入れテスト（UAT）は、納品物の品質を発注側が最終確認する重要な工程です。しかし、場当たり的なチェックにとどまっている限り、確認漏れやトラブルの再発を防ぐことは難しいです。チェックリストを整備するだけでなく、テストの進め方そのものを「検収の仕組み」として設計することが求められます。

準備・実行・記録・判定のサイクルを整える

受け入れテストを仕組みとして機能させるには、4つのフェーズを順序立てて運用することが有効です。

1. 準備：合否の判定基準と担当者を事前に決め、チェックリストを環境・機能・デザイン・SEO・セキュリティなどのカテゴリで整理する
2. 実行：ステージング環境で項目を順番に確認し、確認済み・未確認・指摘の3段階で記録する
3. 記録：スクリーンショットと再現手順を添えて証跡を残し、制作会社への差し戻し根拠を明確にする
4. 判定：重大度を分類したうえで合否を判定し、修正対応が完了した時点で最終承認する

このサイクルを毎回のプロジェクトで繰り返すことで、担当者が変わっても一定の納品品質を維持しやすくなります。

フォームのような繰り返し負荷が高い工程は自動化で補う

お問い合わせフォームや資料請求フォームのテストは、入力パターンが多く、手作業による確認だけでは見落としが生じやすいです。form auto runnerのようなツールを使ってバッチ実行する方法を取り入れることで、確認工数を抑えながら網羅性を高められます。自動化はエンジニアの専任作業ではなく、テスト運用の一部として発注側でも検討できる選択肢の一つです。

チェックリストは「毎回使い回せる資産」にする

Webサイトの納品前チェックリストは、一度作れば次のプロジェクトでも流用できます。今回のテスト結果をもとに、見落とした観点や追加が必要な項目を補足しておくことで、リストの精度は更新のたびに高まります。受け入れテストを「一時的な作業」ではなく、組織として積み上げていく「検収の仕組み」として位置づけることが、長期的な品質管理の基盤になります。

まとめ——受け入れテストを「作業」から「検収の仕組み」に変えるために

Webサイトの納品前チェックは、担当者の記憶や経験に頼る「作業」として行うかぎり、毎回品質がばらつきます。受け入れテストを「検収の仕組み」として整備することで、プロジェクトが変わっても一定の納品品質を維持できるようになります。

本記事で解説してきた内容を、以下の4つのステップに整理します。

1. 準備：テスト環境・確認端末・担当者・合否基準をプロジェクト開始時点で決める
2. 実行：カテゴリ別チェックリストを使い、表示・動作・フォーム・SEO・セキュリティの各項目を順に確認する
3. 記録：確認結果をスプレッドシートなどに残し、不具合は再現手順・スクリーンショットとともに制作会社へ差し戻す
4. 判定：重大度の基準に沿って合否を判定し、修正完了後に再テストを実施する

このサイクルを一度テンプレート化しておけば、次のプロジェクトからは準備コストが大幅に下がります。チェックリスト自体の内容も、プロジェクトごとに発生した見落としを反映して更新することで、精度が継続的に高まります。

また、フォームのような入力パターンが多く手作業の負荷が高い工程は、form auto runnerのようなツールを使ったバッチ実行が有効です。繰り返し発生する確認作業を自動化することで、担当者はより判断が必要な確認項目に集中できます。

Web制作の受け入れテストにおいてチェックリストは出発点であり、それを運用する「準備・実行・記録・判定」のサイクルこそが、納品品質を安定させる本質的な仕組みです。発注側の担当者がこの仕組みを持つことで、制作会社との品質認識のずれを減らし、検収を確実なプロセスとして機能させることができます。