準備するもの
デモHTMLが完成したら、アップロード前に「相手がログインなしで開ける状態か」を意図的に確認する。パスワード認証を設定する場合は問題ないが、メール認証では相手が持っているアドレスを正確に把握していないと「認証メールが届かない」というトラブルになる。閲覧者リストとそのメールアドレスをスプレッドシートに整理してから設定に入ると安全だ。
外部送信リクエストの確認も準備段階で行う。フォーム送信先・サードパーティのSDK・広告タグなど、デモに含まれるHTTPリクエストをブラウザの開発者ツールのNetworkタブで一通り確認する。本番APIに実際のリクエストを投げる状態でデモを配布すると、テストデータが本番DBに入ってしまうリスクがある。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
実際の手順
HTMLをZIPにまとめてプレビューURLサービスにアップロードし、認証設定（パスワードか・メール認証か・ドメイン制限か）と有効期限を設定する。設定後、自分でURLにアクセスして認証フローを一通り体験しておく。「パスワードを入力してもエラーになる」「認証メールが届かない」といった問題は、配布前に自分でテストすれば事前に発見できる。
テストOKが確認できたら、閲覧者にURL・認証情報・確認観点・フィードバック期限を明記したメールを送る。PCとスマホ両方で開けることを確認済みであれば、その旨を一言添えると閲覧者の安心感が上がる。モバイルで崩れる場合は「推奨環境：PC（Chrome最新版）」と明記してモバイルでの確認を促さないようにしておく。
失敗しやすい点
「期限と差し替え方を事前に決めておく」という手順が後回しになりがちだ。具体的には「修正版は同じURLで反映か新URLを発行するか」「修正完了の連絡はメールかSlackか」「最終確認のデッドラインをいつにするか」の3点を配布前に決めて、閲覧者にも伝えておく必要がある。決めていないと修正のたびに担当者間で調整が必要になり、無駄なコミュニケーションが発生する。
内部情報の漏えいリスクも見落としやすい。記事デモには本文だけでなく、制作者のコメントがHTMLコメント（<!-- -->）として残っていたり、デモ用の架空個人名や実在する社内プロジェクト名がサンプルテキストとして使われていたりすることがある。共有前にブラウザのソース表示（Ctrl+U）でコメントを検索し、不要な情報が含まれていないかを確認すること。
テンプレ文面
初回共有メール例：「件名：【限定共有】〇〇記事デモのご確認（期限：〇月〇日 18:00）。こちらのURLから記事デモをご覧ください（URL）。ログインにはパスワード：XXXX が必要です。PCのChromeまたはEdgeでのアクセスを推奨します。確認観点：①見出し構成の分かりやすさ ②リード文の興味喚起力 ③全体のトーン。期限までにご意見をこのメールへご返信ください。」
公開終了通知例：「〇月〇日 18:00 にデモURLのアクセスを終了しました。お時間を割いてご確認いただきありがとうございました。いただいたフィードバックを踏まえ、公開版は〇月〇日を予定しています。公開後にもご確認いただけると幸いです。」
よくある質問
記事デモのHTMLをZIPにする際、CSSやJSは分けて格納すべきですか？
相対パスが通る構成であれば分けても一つのHTMLにインラインで書いてもどちらでも問題ありません。ただしファイルが多いと展開後の構造が複雑になるため、依存ファイルが少ない場合はスタイルをインライン化した単一HTMLのほうが共有ミスを防げます。
有効期限が過ぎた後にアクセスしようとした閲覧者から問い合わせが来た場合、どう対応しますか？
公開終了の通知を事前に送っておくことで大半の問い合わせは防げます。それでも問い合わせが来た場合は、期限を短期間だけ延長して対応するか、最終版のスクリーンショットをメールで送る方法が現実的です。
メール認証を設定したのに閲覧者から「メールが届かない」と言われました。原因は何ですか？
メールサーバーのスパムフィルタによる振り分けが最も多い原因です。閲覧者に迷惑メールフォルダを確認してもらうよう伝えてください。それでも届かない場合はドメインのSPF・DKIM設定の問題が考えられ、サービスのサポートに問い合わせるのが早道です。