WebSimで生成したHTMLスライドをレビュー用URLにして共有する方法

何が共有しづらいのか

HTMLスライドはReveal.jsやimpress.jsなど外部ライブラリをCDN経由で読み込む構成が多く、オフライン環境や社内プロキシが厳しい相手には一部スライドだけ真っ白になることがある。しかも「2枚目から先が表示されない」という報告は受け手が原因を説明しにくいため、問題が隠れやすい。

PCとスマホで最低1回ずつ表示を確認しておくことが欠かせない。スライドはキーボード操作を前提にしていることが多く、スマホではスワイプが効かずに最初の画面で止まってしまうケースがある。事前に「スマホで見る場合は画面をタップで進みます」と案内文を添えるだけでも混乱が減る。

社内向けの発表資料には未発表製品のロードマップや売上数字が含まれることがある。URLを誰でもアクセスできる状態で発行してしまうと、Googleのクローラーに拾われる可能性はゼロではない。noindex設定と認証は目的が違うので、どちらか一方ではなく必要に応じて両方を設定する。

• 相手がログインなしで開ける状態か確認する
• PCとスマホで最低1回ずつ表示を確認する
• 内部情報・個人情報・不要な外部送信が残っていないか見る
• レビュー期限と修正時の差し替え方を決めておく

URL化する前の確認点

CDNで読み込んでいるライブラリ（Reveal.js・highlight.js・Mathjaxなど）は公開後も外部から解決できるが、バージョンが古いと将来的に404になるリスクがある。本番共有する前にライブラリをダウンロードしてzipに同梱し、相対パスで参照する構成に切り替えると長期的に安全だ。

スライド内に埋め込まれた画像のBase64データが肥大化していると、HTMLファイルのサイズが10MB超になることがある。ギガサイト便の無料プランのファイルサイズ上限を超えないよう、TinyPNGなどで画像を事前に圧縮するか、別途ストレージにアップして外部URLで参照する方法を検討する。

スライドノートやコメントアウトされた箇所に口頭説明用のメモが残っていることがある。特にCSSのコメントや非表示divに「クライアントには言えないが…」という記述が混入するケースは実際に起きている。公開前に `Ctrl+F` で「内緒」「非公開」「TODO」などのキーワードを検索しておく。

• HTML内の外部script・form action・iframeを確認する
• APIキーやトークンらしき文字列がないか検索する
• 画像・CSS・JSのパスが公開後も解決できるか見る
• noindexと認証を混同せず、必要なら両方設定する

認証と期限の決め方

社内の少人数レビューならパスワード認証が手軽だ。Slackチャンネルにパスワードを投稿し、URLを同じスレッドで共有すると受け手が迷わない。ただしチャンネルに招待されていない人がパスワードを知った場合に閲覧できてしまうため、情報感度が高いスライドにはメール認証のほうが適している。

顧客向けの提案スライドを特定の担当者1〜2名に見せる場合、メール認証でアドレスを指定すると「誰がいつ開いたか」が記録に残る。商談の進捗管理として「先方が閲覧した」という事実を把握できるのは、営業フローの観点でも有益だ。

期限は発表日の翌日を目安に設定しておくのが原則だ。発表後に不特定多数がアクセスできる状態は情報管理上望ましくない。社内勉強会の資料など継続参照が必要なケースだけ期限を長めに設定し、その旨をチームに周知しておく。

• 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
• 特定の相手だけ: パスワードまたはメール認証を使う
• 会社内だけ: 会社ドメイン認証を検討する
• 短期レビュー: 期限を設定して古いURLを残さない

共有後のフィードバック回収

スライドのレビューは「デザイン」「内容の正確さ」「流れの分かりやすさ」の3軸に絞ると意見が整理しやすい。3軸それぞれに「問題なし/要修正/要確認」で答えてもらうテンプレートをメッセージ内に埋め込むと、曖昧な感想よりも具体的なフィードバックが集まりやすい。

修正後に同じURLを維持したまま差し替えができると、「最新版はこちら」と新しいURLを送り直す手間がなくなる。ただし複数人が並行してフィードバックを書いている途中で差し替えると混乱が生じるので、差し替えは全員の初見フィードバックが出そろってからにする。最終版と途中版が混ざらないよう、タイトルやバージョン番号をスライド冒頭に入れておくと管理しやすい。

• 確認してほしい観点を3つ以内に絞る
• 期限と返信先を明記する
• 修正後も同じURLで見られるか伝える
• 最終版と途中版が混ざらないようタイトルを付ける