準備するもの
チェックリストを使い始める前に「確認で使う実機」を決めて担当者全員に共有する。チームによって人によって使う端末が違うと、チェック結果の再現性がなくなる。「iOS SafariとChrome for Androidを必ず使う」という最低基準を文書化してチームWikiに置くと、新メンバーが加わったときもすぐ同じ基準で動ける。
チェックリストはプロジェクト管理ツール（Notion・Jira・Asana等）のテンプレートとして登録し、案件ごとにサブタスクとして複製する運用にすると漏れが防ぎやすい。リストの各項目をタスクとして担当者に割り当てることで、誰がいつ確認したかのトレーサビリティも生まれる。
送付前の情報確認として、HTMLに埋め込まれたメタ情報（og:titleやdescription）が社外秘の表現を含んでいないかも調べる。SNSでURLが共有されたときにOGPタグの内容がサムネイルに表示されるため、社内向けのタイトルや開発中の機能名が露出しないよう確認が必要だ。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
実際の手順
チェックリストは「1. HTMLアップロード前」「2. URL発行後・送付前」「3. 送付後24時間以内」の3段階に分けて運用する。アップロード前はファイルサイズ・外部スクリプトの有無・個人情報の削除を確認。URL発行後は実機でのURL開通確認・パスワード動作確認を実施。送付後はクライアントの開封確認と質問への初期応答を行う。
チェック項目を埋める際は「確認した日時と確認者名」を記録する。特に複数人が関わる大型案件では「誰が確認したか」が後から追跡できることが重要だ。Slackのスレッドに「スマホ確認済み（yamada, 2026/07/01 14:00）」と書き込むだけでも記録として機能する。
失敗しやすい点
チェックリストの「PCとスマホで最低1回ずつ表示を確認する」という項目を、ブラウザのDevTools（モバイルエミュレーター）での確認で代替してしまうパターンが多い。DevToolsは便利だがSafariの特有バグや実機フォント描画は再現できないため、実機確認を明確に「実機（物理端末）に限る」と項目に書き添えることで誤解を防ぐ。
有効期限を設定し忘れる失敗も頻発する。チェックリストに「有効期限：〇年〇月〇日まで」の記入欄を設け、空欄のまま送付できない仕組みにする。期限の基準を「送付日から7日間」と決めておくと、毎回期限を考える手間も省ける。
テンプレ文面
チェックリスト完了後の送付テンプレ：「スマホ確認URLをお送りします。社内確認（iOS Safari・Android Chrome）完了済みです。URL：https://…/proj-sp-r1 パスワード：別途SMSにてお伝えします。有効期限：2026年7月8日。スマホとPCの両方でご確認いただき、お気づきの点をご共有ください。」
問題発見時の差し替えテンプレ：「先ほどお送りしたURLに表示上の問題が確認されました。修正版（r2）を発行しました。URL：https://…/proj-sp-r2 旧URLは無効化しています。ご迷惑をおかけしました。引き続きよろしくお願いします。」差し替え理由を一行添えると状況が明確になる。
よくある質問
チェックリストにある「内部情報が残っていないか見る」とは、具体的に何を確認すればよいですか？
HTMLのコメントアウト（<!-- -->）に開発メモや社内メンバー名が書かれていないか、console.log()デバッグコードが残っていないか、localStorageやCookieに認証トークンが書き込まれていないかを確認する。ブラウザのソースビューとDevToolsで5分あれば確認できる。
チェックリストを毎回埋めるのが面倒で担当者が省略しています。どうすれば続けられますか？
チェックリストの項目数を5項目以内に絞ることが定着の鍵。全項目を並べると圧倒されて省略が起きる。「NG時に致命的なもの」だけを必須とし、残りは推奨扱いにして段階的に習慣化させるアプローチが現場では効果的だ。
クライアント企業の担当者が複数いて、同じURLを全員に送ってよいですか？
同一URLを複数人に送ることは問題ない。ただし受信者全員がパスワードを知ることになるため、パスワードの取り扱いをメールに一言添える（「このパスワードは本プロジェクト関係者限りでご共有ください」等）と情報管理のルールが明確になる。