事前準備
クライアントに送る前に、HTML内の「仮」「TODO」「TBD」という文字列をgrepで全件検索します。デザインフェーズで仮置きしたテキストが残ったまま共有されると、クライアントが「これは確定テキストですか？」という確認工数が発生し、承認判断が後ろ倒しになります。検索コマンド例：`grep -rn 'TODO\|TBD\|仮\|FIXME' *.html`
URLを発行したら、クライアントが使う可能性のある環境（iOS Safari・Android Chrome・Windows Edge）でそれぞれ表示を確認します。特に日本語フォントのウェイトはブラウザ間で差が出やすく、デザインカンプと印象が異なることがあります。確認が取れた環境をメモしておき、「Chrome・Safari・Edgeで動作確認済み」と依頼メールに添えると安心感を伝えられます。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
確認観点
クライアント向けHTMLに含まれる外部リンクが全て機能しているか確認します。「お問い合わせはこちら」のリンクが404になっていたり、別のクライアントのドメインに飛んでしまったりする間違いは、信頼を大きく損ないます。特にコピー元の別案件のURLが残っているケースは定期的に発生するため、全リンクを確認する工程を手順書に入れておきます。
個人情報の入力を受け付けるフォームがある場合、プライバシーポリシーへのリンクが存在するか・フォームの送信先が正しいエンドポイントかを確認します。クライアントの法務が「個人情報の取り扱いがプライバシーポリシーへの導線なしになっている」と指摘するケースは珍しくなく、公開後に追加対応する羽目になることがあります。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
NG例
クライアント承認で最もよくある問題は、まだ合意が得られていない料金・機能・キャッチコピーを「たたき台として」HTMLに入れて送ることです。クライアントは「たたき台」と受け取らず、確定版として社内に展開してしまうことがあります。確定していない情報はHTMLには入れず、別資料として添付するか「本URLには確定情報のみ掲載しています」と明示します。
もうひとつのNGは、前回バージョンのURLをそのままクライアントに再送することです。「先ほどのURLでご確認ください」と再送しても、クライアント側でブラウザキャッシュが残っていると旧版が表示されることがあります。修正版は必ず新しいURLで発行し、「旧URLは失効しました・新URLはこちらです」と明示して送ります。
修正後の再共有
クライアントへの修正報告は「指摘番号」「修正箇所」「修正内容（変更前→変更後）」の形式でまとめます。変更前後を並べることで、クライアントが修正を見逃す可能性を下げられます。スクリーンショットのbefore/afterをスライド1枚にまとめて添付すると視覚的に確認が早くなります。
最終承認を確認したら、「本URLは○月○日に失効します。正式版のファイルは別途ご提供します」と明記して締めます。クライアントがURLをブックマークして後日アクセスしようとして「開けない」という問い合わせをよく受けるため、失効予定を事前に伝えることでサポートコストを下げられます。
よくある質問
修正版を再共有する際、ブラウザキャッシュで旧版が表示される問題をクライアントに説明するよい方法はありますか？
「シークレットウィンドウ（プライベートブラウジング）でURLを開いていただくと最新版が表示されます」と伝えるのが最もシンプルです。Ctrl+Shift+Nでシークレットウィンドウを開く手順をスクリーンショット付きで送るとさらに親切です。
クライアントのプライバシーポリシーリンクをHTMLに設置する際、どのURLを使えばよいですか？
クライアントが公式サイトで公開しているプライバシーポリシーのURLを使います。本番公開前にリンク先URLをクライアントに確認し、URLの文字列とリンクが一致しているかを必ず検証してから設置します。
クライアントから「前回確認したURLとどこが変わったか教えてほしい」と言われた場合の最善の対応は？
前回バージョンと今回バージョンのスクリーンショットを並べた比較画像を作成して送ります。変更箇所を赤枠でハイライトし、右下に変更の番号を振ると視覚的に差分がわかりやすくなります。