【Web制作業】Webサイト公開前の確認表をAIで整える方法

Webサイト公開前の確認表が必要な理由

Webサイトの公開には、画面の見た目だけでなく、機能の動作、情報の正確性、公開環境の設定、顧客承認などが関係します。確認表は、これらの作業を関係者が同じ基準で進めるための管理資料です。

確認事項が複数の担当者に分散する

デザイナーは表示や余白、エンジニアはフォームやリンク、ディレクターは原稿や承認状況を確認するなど、担当範囲は分かれやすいものです。確認結果が一か所に集まらないと、重複作業や見落としが起きやすくなります。

共通の確認表に対象ページ、担当、結果を記録すれば、公開に向けた進行状況を把握しやすくなります。

確認済みでも公開可能とは限らない

例えば、問い合わせフォームのデザインを確認しても、テスト送信や通知メールの受信が終わっていなければ、フォームの確認は完了していません。また、顧客が原稿を承認していても、本番ページに正しく反映されているかは別途確認する必要があります。

そのため、確認表には項目名だけでなく、具体的な確認方法と完了条件も記載します。

AIが担うのは確認表の整理まで

生成AIは、制作資料から項目を抽出し、分類や重複整理を行う用途に活用できます。一方、ブラウザでの実機表示や本番環境の設定を実際に確かめたという証拠にはなりません。

公開前確認表に入れるべきチェック項目

公開前確認表は、サイトの目的、機能、契約範囲に合わせて構成します。企業サイトとECサイトでは必要なチェックが異なるため、共通項目を出発点として案件固有の内容を追加することが重要です。

確認項目を分類する

フォームは見た目と送信動作を分ける

フォームが画面に表示されても、送信先や通知メールの設定が正しいとは限りません。入力条件、エラー表示、送信完了画面、通知の受信まで別の確認項目として整理します。

SEOや公開設定は本番環境で確認する

制作中に検索エンジンへの登録を制限していた場合は、公開時に意図しないnoindex指定やrobots.txtによる巡回制限が残っていないかを確認します。URLの変更があるリニューアルでは、旧URLから新URLへの転送や内部リンクの修正も対象です。

公開直後の項目も別に設ける

本番URLでのフォーム動作やアクセス解析、転送設定など、公開後に再確認が必要な項目もあります。公開前と公開直後に分けることで、実施時期が曖昧になることを防ぎます。

AIに渡す前に整理する制作資料

AIに一般的な公開前チェックリストだけを作らせると、その案件固有の注意点が不足する場合があります。公開対象の資料を整理し、どの版が正式な情報かを明確にしてから入力しましょう。

最新版の資料を集める

確定した内容と未確認事項を区別する

例えばフォームの送信先が仕様書にあるなら確認対象にできますが、通知先が記載されていない場合は、AIに推測させず未確認として残します。資料内に変更前後の情報が混在する場合も、正式な最新版を担当者が特定します。

顧客情報の入力範囲を決める

顧客の担当者名、未公開の情報、認証情報などが資料に含まれている場合は注意が必要です。使用するAIサービスの契約条件や社内ルールに従い、必要性のない個人情報、パスワード、APIキーなどは入力しないようにします。

AIで確認表を整える5つの手順

確認表の作成は、対象を決め、資料から項目を抽出し、表に整えたあと、担当者が検証する流れで進めます。最初から完成版を求めず、段階ごとに出力を確認する方法が現実的です。

1. STEP 1：対象ページと機能を洗い出す

   ページ一覧と機能仕様から、公開対象を整理します。問い合わせ、採用応募、資料請求などのフォームはそれぞれ別の確認対象にします。

2. STEP 2：制作資料から確認候補を抽出する

   仕様書、修正履歴、顧客からの依頼内容をAIに入力し、公開前に確認すべき内容を挙げさせます。項目ごとに根拠資料や対象ページも出力するよう指示します。

3. STEP 3：分類と重複整理を行う

   表示、原稿、リンク、フォーム、SEO、技術、運用、承認などに分類します。似た項目は統合しながら、ページごとに別の確認が必要なものは残します。

4. STEP 4：確認方法と完了条件を追加する

   何を見ればよいかだけでなく、どの操作を行い、どの状態なら完了なのかを具体化します。実施時期、担当区分、優先度も設定します。

5. STEP 5：元資料と照合して正式版にする

   存在しない機能や抜けた顧客要望がないか人が確認します。確認表の版、更新日、責任者を決め、実際の検査結果は未実施の状態から記録します。

共通部分と案件固有の部分を分ける

毎回同じ項目をゼロから作成するよりも、会社共通の確認項目を基本テンプレートにし、案件に応じて機能や顧客要望を追加する運用が適しています。

共通テンプレートを更新する際は、過去の不具合や公開後の問い合わせから得られた改善点を反映します。

そのまま使える確認表とプロンプトの例

ここでは、一般的な企業サイトを想定したモデルケースを紹介します。以下は説明用の例であり、実際にチェックやテストを完了した記録ではありません。

公開前確認表の記入例

AIへの指示文テンプレート

次のプロンプトは、資料からチェック項目を分類するための下書きです。社内で利用を許可された情報だけを入力し、案件に合わせて使ってください。

あなたはWeb制作会社の公開前品質確認を支援する担当者です。

入力する制作仕様書、ページ一覧、修正履歴、顧客確認事項をもとに、Webサイト公開前の確認表の下書きを作成してください。

【出力する列】
項目ID／分類／対象ページ・機能／確認項目／確認方法／完了条件／担当区分／実施時期／重要度候補／根拠資料／状態

【作成ルール】
1. 表示、原稿、リンク、フォーム、SEO、技術、セキュリティ、運用、顧客承認に分類する。
2. 同じ項目の重複は整理する。ただし、別ページで個別確認が必要なものは残す。
3. 元資料に明記された項目と、AIが一般的な観点から提案した項目を区別する。
4. 資料にない情報や不明な担当者は推測で埋めず、要確認と記載する。
5. 確認方法と完了条件は、担当者が実際に検証できる表現にする。
6. 確認結果はすべて未実施とし、テスト済みと記載しない。
7. 公開前と公開直後の作業を区別する。
8. 最後に、元資料との照合が必要な項目と担当者への質問を一覧化する。

表を作成した後、根拠が不明な項目を別にまとめてください。

出力を受け取ったあとの確認ポイント

実際に運用する管理表には、確認日、確認結果、修正担当、再確認日、証跡の保存先などを追加すると、公開判断に必要な情報を追いやすくなります。

公開前の確認漏れを防ぐ運用ルール

AIで確認表を作成した後は、実施結果の記録と問題の扱い方を決めます。項目数がそろっていても、未確認や要修正の状態を放置していると、公開時のリスクを把握できません。

確認状況は段階ごとに管理する

公開を見合わせるべき問題を事前に定める

主要フォームが送信できない、未公開情報が表示されている、重要なページが閲覧できない、承認が取れていないといった問題は、公開可否の判断前に優先して確認する必要があります。公開を停止する条件は、案件の目的と影響を踏まえて責任者が決めます。

元資料と確認表を照合する

以下の画像は、AIが整理した確認表と元の仕様書・修正履歴を見比べる場面です。公開直前に追加された修正も含めて確認することで、古い確認表を使い続けることを防げます。

失敗しやすい運用と対策

まずは小規模なサイトで試す

初めてAIを使う場合は、ページや機能が比較的少ない案件で、既存の確認表とAIの下書きを比較すると検証しやすくなります。実際の公開作業で見つかった不足項目を共通テンプレートへ反映し、徐々に運用を改善します。

まとめ

Webサイト公開前の確認表をAIで整える際は、制作資料に基づいて確認項目を分類し、確認方法や完了条件まで明確にすることが大切です。AIは整理の補助として使い、実際のテストと公開判断は担当者が行います。

まずは現在使っている確認表と一つの案件の制作資料を比べ、AIが整理しやすい情報と、人による確認が必要な部分を明確にするところから始めてみましょう。