Web制作の仕事をしていて、一番緊張するのは納品直前の最終チェックだ。公開ボタンを押した瞬間に「あ、この画像リンク切れてる」「スマホで見たらボタンがはみ出してる」と気づいても、もう遅い。だからこそチェックリストは毎回作っているのだが、案件が立て込んでいる時期はこの「チェックリスト作り」自体が後回しになりがちだった。
結論から言うと、表示崩れやリンク切れ、フォームの動作確認といった「どのサイトにも共通する一般的なQA項目」の洗い出しはChatGPTにかなり任せられる。ただし、「このクライアントの管理画面特有の操作ミス」や「過去にこの案件で指摘を受けた箇所」といった、案件固有の確認項目は自分から具体的に指示しない限り一切出てこない。今日はその境界線と、実際に使ったプロンプト、そして自分がやっている運用を書いておく。
何に困っていたか
サイト公開前のチェックは「表示崩れがないか」「リンクが正しく飛ぶか」「フォームが送信できるか」といった基本項目に加えて、案件ごとに追加で見るべきポイントが必ず存在する。例えば予約フォームがあるサイトなら通知メールの送信先アドレス、多言語サイトなら言語切り替えボタンの挙動、といった具合だ。
これまでは自分の記憶とExcelの古いテンプレートを頼りにチェックリストを作っていたが、案件によって忘れがちな項目が違うため、テンプレートに載っていない固有の確認漏れが何度かあった。特に「以前このクライアントから指摘された表示崩れ」を再発させてしまったことがあり、そこからチェックリストの作り方を見直すことにした。
TOI
「一度指摘されたことは二度と繰り返さない」はずなのに、案件をまたぐとつい忘れる。チェックリストが記憶の代わりをしてくれないと結局同じミスをする。
試したこと：サイトの構成情報を渡してChatGPTにチェックリストを作らせる
今回は、サイトの構成情報(ページ数、使用しているフォームの種類、対応デバイス、既存で指摘されたことがある項目)を先に伝えたうえで、公開前チェックリストを作らせるやり方を試した。
使ったプロンプト
あなたはWeb制作会社のディレクターが、サイト公開直前の
最終チェックリストを作成するのを手伝うアシスタントです。
以下の条件で、公開前QAチェックリストをカテゴリ別に作成してください。
【サイトの構成】
- 種類：中小企業のコーポレートサイト(全8ページ)
- フォーム：お問い合わせフォーム1つ(送信先メールあり)
- 対応デバイス：PC、スマートフォン
- 埋め込み要素：Googleマップ、Instagram投稿の埋め込み
【出力してほしいカテゴリ】
1. 表示崩れ・レイアウト確認
2. リンク・遷移確認
3. フォームの動作確認
4. スマートフォン表示の確認
5. 埋め込み要素(マップ・SNS)の確認
6. SEO・OGPの基本設定確認
7. ここまでの項目だけでは見落としが残りそうな箇所があれば、
別枠で「人間が実機で確認すべき理由つき」で指摘してくださいポイントは、フォームの種類や埋め込み要素の中身まで具体的に伝えたことと、最後に「見落としが残りそうな箇所」を理由つきで別枠に出させたことだ。これを入れずに「サイト公開前のチェックリストを作って」とだけ頼んだ1回目は、どのサイトにも当てはまる一般論のリストが返ってきただけで、Instagram埋め込みのような今回の案件固有の要素にはまったく触れられていなかった。
実際の出力例(抜粋)
構成を細かく伝えた2回目では、次のような下書きが返ってきた。
- 表示崩れ：「見出しの折り返し位置、画像の縦横比が崩れていないかを主要ブラウザ(Chrome・Safari)で確認」
- リンク確認：「ヘッダー・フッターのナビゲーション、外部リンクに
target="_blank"が正しく設定されているかを確認」 - フォーム確認：「テスト送信を行い、指定した送信先アドレスに正しく届くか、自動返信メールの文面に誤字がないかを確認」
- 別枠の指摘：「Instagram埋め込みは投稿削除やAPI仕様変更で表示が崩れる可能性があるため、公開直前に実際の表示を目視確認することを推奨します」
フォームの「自動返信メールの文面まで確認する」という項目は自分でも見落としがちだったので、素直に助かった。一方で「別枠の指摘」で出てきたInstagram埋め込みの話は、まさに過去に自分たちが痛い目を見た内容そのもので、ChatGPT側もこれは実機確認が要ると正直に線引きしてきた形だ。
やってみて分かった良かった点
- 一般的なQA項目の洗い出しが速い：表示崩れ、リンク切れ、フォーム動作といった、どの案件にも共通する定型チェック項目を文章化する時間がかなり短縮できた
- 構成情報を細かく伝えると、案件固有の投稿要素まで拾ってくれる：「Instagram埋め込み」「Googleマップ」のように具体的な機能名を渡すと、その機能特有の注意点を返してくる
- 「見落としを別枠で指摘させる」プロンプトが効く：チェック項目本体に混ぜずに要確認箇所だけリスト化させることで、公開直前にどこを重点的に見るべきか一目で分かる
TOI
埋め込み要素やフォームの送信先みたいな「その案件だけの部品」を面倒でも書き出して渡すようにしてから、チェックリストの実用度が一気に上がった。
やってみて分かった限界点
一方で、次の2つは結局こちらの記憶と現場の情報に頼るしかなかった。
1. 過去にこの案件で指摘された項目は、伝えない限り絶対に出てこない
ChatGPTは目の前の構成情報からリスクを推測することはできても、「以前このクライアントから受けた指摘」までは知りようがない。前回の納品で「スマホ表示時に電話番号がタップで発信できない」という指摘を受けていたのに、そのことを伝え忘れたら当然チェックリストには一切含まれなかった。過去の指摘事項は案件ごとにメモしておき、チェックリスト作成のたびに読み上げるようにしている。
2. 「このクライアントの管理画面特有の操作ミス」は現場のやり取りがないと書けない
「担当者が公開前に必ず一度プレビューを見たがるが、プレビューURLの共有を忘れがち」「このクライアントはスマホでしか確認しないため、PC表示の崩れに気づかれにくい」といった、そのクライアント特有の運用の癖は、実際にやり取りした人間にしか分からない。この部分はチェックリストの末尾に自分たちで手書きの補足を追加している。
パターン別にどう運用しているか
案件の複雑さと過去の指摘履歴に応じて、次のように使い分けている。
- シンプルなコーポレートサイト(初回納品)：ChatGPTのチェックリストをそのままベースにして、埋め込み要素があれば個別に追記して使う
- リニューアル案件(過去に指摘履歴がある)：プロンプトに過去の指摘事項を箇条書きで貼り付けたうえでチェックリストを作らせ、抜けなく再発防止項目に反映させる
- 複数担当者が確認する大規模サイト：ChatGPTのチェックリストは「共通で見るべき項目」として全員に配布し、担当者ごとの持ち場の確認項目は別途自分たちで割り振っている
まとめ
- 公開前QAチェックリストの下書きは、ページ数・フォームの種類・埋め込み要素といったサイトの構成情報を具体的に伝えるとChatGPTにかなり任せられる
- コツは「表示崩れ」「リンク確認」「フォーム動作」などカテゴリを指定したうえで、「見落としが残りそうな箇所」を理由つきで別枠に出させること
- 過去にそのクライアントから受けた指摘事項は、伝えない限りチェックリストに一切反映されない。案件ごとに指摘履歴をメモしておき、毎回読み上げて渡す運用にしている
- 「このクライアント特有」の確認の癖(プレビューの見方、確認するデバイスの偏りなど)は現場のやり取りでしか分からない領域。チェックリストの末尾に自分たちで手書きの補足を追加している
- 次のアクションとしては、案件ごとの「指摘履歴シート」をテンプレート化しておき、公開前チェックのたびにそのままChatGPTへの入力に使い回せるようにする、という運用が現実的
コメント