レビュー相手に渡す情報
クライアントにURLを送る際は「何を判断してほしいか」と「期限」を必ず明示します。「確認をお願いします」だけでは相手が何をもって確認完了とすればよいかわからず、返答が曖昧になります。「レイアウトの方向性について○月○日（火）15時までにGoかNoGoでご連絡ください」のようにアクションと期限を具体化します。
クライアントの担当者がスマホで確認する可能性がある場合、「PC・スマホの両方でご確認いただけますと幸いです」と依頼します。特にECサイトやサービスLPはモバイルからのアクセスが主流なため、スマホでの表示確認はクライアント側の判断材料として重要です。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
見るべき観点
クライアント向けHTMLには、クライアント社内の承認を経た内容のみを掲載します。制作側が「まだ決まっていない」情報を仮で入れてしまうと、クライアントが「これで確定なのか」と誤解して社内に展開してしまうリスクがあります。テキストや画像の「仮」「TODO」という表記は共有前に全件消去します。
クライアントが社内の法務・コンプライアンス部門にも確認を求める可能性があることを念頭に置きます。特に金融・医療・食品等の規制業種では、担当者が単独でGoを出せない場合が多いです。「必要に応じて社内のご担当者にもURL共有いただいて構いません」と伝えておくと、確認が社内でスムーズに回ります。
認証と期限
クライアントへの共有では、URLをそのまま転送されるリスクを想定してパスワード認証またはメール認証を設定します。パスワード認証の場合、パスワードはURLとは別のメッセージ（Chatworkなど）で送り、同一メールに含めません。メール認証の場合は、クライアント側で確認に関わる担当者のアドレスを事前に聞いてから設定します。
クライアント承認用のURLは承認が下りた時点で失効させます。長期間URLを生かし続けると、クライアント側の担当者が変わったあとに旧担当者が過去のURLを開いて「これが最新版か？」と問い合わせてくるケースがあります。承認確認後に「URLを失効しました。正式なファイルはこちらでお渡しします」と連絡するのがベストプラクティスです。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
指摘回収テンプレ
クライアントからの指摘は「修正必須」「要相談」「次フェーズ対応」の3段階で分類して回収します。クライアントの指摘をすべて同一優先度で受けると、スコープ外の改善提案まで対応する羽目になり、工数が膨らみます。依頼時に「今回確認いただく範囲（スコープ）」を明示しておくと、スコープ外の指摘を「次フェーズ」として切り分けやすくなります。
メールで指摘を回収する場合は、「下記フォーマットでご返信いただけますと助かります」と回収フォーマットをメール本文に貼り付けます。フォーマット例：「【確認箇所】トップページのメインビジュアル 【指摘内容】〜 【優先度】必須/要相談/次フェーズ」。これによりクライアントが自由に書いた長文テキストから指摘を抽出する手間がなくなります。
よくある質問
クライアントが「URLを別の部署にも転送してよいか」と言ってきた場合、どう対応すればよいですか？
転送される相手のメールアドレスを教えてもらい、メール認証の許可リストに追加するかパスワードを共有する方法が安全です。URLの転送自体を禁止するより、適切な認証で対象を広げるほうが協力的な関係を維持できます。
クライアントからの返答が「GoかNoGoか」ではなく「検討中」のまま止まっています。期限を過ぎた場合の対応は？
期限翌日に「本日時点での状況をお知らせいただけますか？」とリマインドします。2営業日応答がない場合は電話でフォローアップします。承認遅れがスケジュールに影響する旨を丁寧に共有し、期限の再設定を合意します。
クライアントがスマホでURLを開いて表示が崩れた場合、まず何を確認すればよいですか？
クライアントが使っているOSとブラウザ（例：iOS17のSafari）を確認します。同じ環境を手元で再現し、DevToolsのエミュレーターまたは実機で崩れを確認してから修正します。崩れの箇所をスクリーンショットで送ってもらうと再現が早くなります。