共有前の確認点
アプリ操作デモHTMLにはモックデータとして実際のユーザーIDや社内システムの画面キャプチャが混入していることがある。共有前にブラウザの開発者ツールを開き、ネットワークタブで外部APIへのリクエストが発生していないか確認する。本番APIに接続したままのデモを外部に公開すると、デモ操作中に実データが書き換わるリスクがある。
JavaScriptで動くインタラクティブなデモの場合、ローカル環境では動いていたアニメーションが共有URL上では壊れることがある。これはWebfontやlocalStorageの依存、Service Workerのスコープが変わることが原因だ。アップロード後に必ずゲストモードのブラウザで動作確認し、主要な操作フローが再現できるかをチェックする。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
向いている認証方式
営業先へのデモ提示を目的とした共有では、パスワード認証が最も現実的だ。訪問直前に発行したURLとパスワードをその場で口頭伝達すれば、相手がアカウントを作らず即座に閲覧できる。ただし商談が終わった後もパスワードが有効なままにならないよう、商談当日から3〜5日で期限が切れるよう設定しておく。
社内の開発チームや品質保証チームにレビューしてもらう場合は、会社ドメイン認証を使うとメールアドレスを個別登録せずに全員がアクセスできる。デモの内容がまだ機密段階にある場合、ドメイン制限で社員だけに絞りつつ、Slackの特定チャンネルでURLを案内する方法が情報管理と利便性を両立しやすい。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
相手への送り方
営業先には「このURLでデモをご確認いただけます。パスワードは○○です。○月○日まで有効です」という短いメッセージと合わせて送る。HTMLデモは操作を試してもらうことで価値が伝わるため、メール本文に「トップ画面→検索→詳細画面の順に操作してみてください」のような誘導を添えると反応率が上がる。
開発チームへのレビュー依頼では、デモのどのバージョンを共有しているかをコミットハッシュやバージョン番号とともに伝える。「v1.2のデモです」と明記しておけば、「この動作はv1.3で修正予定」という形でフィードバックをバージョンに紐付けて管理しやすくなる。
更新・期限管理
デモのUIが修正されたらHTMLを差し替えて同じURLで再共有できる。ただし営業先がブラウザのキャッシュを持っている場合、差し替えても古い版が表示されることがある。「キャッシュクリアをお願いします（Ctrl+Shift+R）」と案内するか、URLにクエリパラメータを付加してキャッシュを回避する方法を取る。
商談フェーズが終わってデモを見せる必要がなくなったら、URLを即日無効化する。特に競合他社との商談が重なる時期は、古いデモURLが残ったままだと意図しない関係者に参照されるリスクがある。契約締結または失注確定のタイミングをトリガーにURL無効化をフローに組み込んでおくと管理しやすい。
よくある質問
デモHTMLがlocalStorageにデータを保存する仕組みになっています。共有URL上でも正常に動作しますか？
localStorageは閲覧者のブラウザに保存されるため、共有URL上でも基本的に動作します。ただし同一オリジンポリシーの制約上、アップロード先のドメインとローカル環境のオリジンが異なるため、ローカルで保存したデータは引き継がれません。デモ初期状態でのデータを埋め込んでおくことを推奨します。
営業先が社内のセキュリティポリシーで外部URLへのアクセスを制限している場合、デモを見せられないことがありますか？
社内プロキシで外部URLがブロックされている環境では閲覧できない場合があります。その場合はHTMLファイルをZIPで直接渡す方法や、オフライン対応のデモを事前に用意しておくことで対応できます。商談前に相手の環境制約を確認することをお勧めします。
同じデモを複数の営業先に別々のパスワードで共有したいのですが、URLは1つですか？
1つのURLに対して1つのパスワードを設定する仕様です。営業先ごとに異なるアクセス制御をかけたい場合は、同じHTMLを複数のURLとして発行し、それぞれ別のパスワードと期限を設定してください。どのURLをどの営業先に渡したかを記録しておくことで、アクセスログと顧客を照合できます。