何が共有しづらいのか
Difyが出力するHTMLスライドはSPAライクな画面遷移を実装しているものがあり、ローカルのfile://で開くとhistory.pushStateが機能せず、キーボードナビゲーションやページジャンプが壊れる。Dify自体のプレビュー画面URLは共有できないため、動作するURLを別途用意する必要がある。
スライドに埋め込まれたスピーカーノートやアニメーション遅延設定がブラウザのバージョンによって異なる動作をすることがある。共有前にChrome・Safari・Edgeの最低3ブラウザで確認し、問題があればCSSアニメーションのフォールバックを追加する。スマートフォンでの縦持ち表示もチェックすると、プレゼン当日の事故を未然に防げる。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
URL化する前の確認点
Dify生成のスライドHTMLではWebSocketによるリアルタイム同期機能（発表者と聴衆で同じページを表示する機能）が含まれる場合がある。レビュー用に共有する際はこの機能が不要なため、WebSocket接続コードを削除するかコメントアウトする。接続先のサーバーが社内環境の場合、社外レビュアーから繋がらずエラーになる。
スライド内にQRコードや短縮URLが生成されて埋め込まれているケースがある。これらが古いリンクや本番ページを指している場合、レビュアーがクリックして意図しないページに飛ぶ。すべてのリンクを確認し、レビュー段階で不要なものは削除またはダミーリンクに置き換える。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
認証と期限の決め方
社内向けプレゼン資料のドラフトを共有する場合は、会社ドメイン認証で自社社員のみに絞るのが望ましい。役員レビューなど限られた人数であればパスワード認証でも十分で、パスワードを会議招待メールに記載しておくと当日スムーズだ。
スライドは提案後に第三者への転送リスクがある。期限を提案日の翌日まで短く設定しておくことで、提案終了後に相手方社内で広まるリスクを軽減できる。修正版を事前に差し替えたい場合は、共有URLの上書きアップロード機能があるサービスを選ぶと期限を延ばして継続利用できる。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
共有後のフィードバック回収
スライドレビューでは観点を「内容」「構成」「デザイン」の3つに分けて依頼すると、部門を跨いだレビュアーが自分の担当観点だけ答えられる。例えば営業は内容、デザイナーはデザイン、PMは構成という分担をURL送付時に明記する。
修正後は変更したスライド番号を具体的に伝える。「3枚目の訴求文言を修正、7枚目のグラフを差し替えました」という形式だと、レビュアーは全スライドを見直さなくて済む。スライド番号はHTMLのページ送りカウンターと一致していることを確認してから送ると、コミュニケーションの齟齬が起きない。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
よくある質問
DifyのHTMLスライドでキーボードナビゲーションが動かない場合の原因は何ですか？
ローカルのfile://プロトコルでhistory APIが制限されるためです。HTTPSで配信される共有URLから開けば解決します。それでも動かない場合はDifyが出力したJS内のイベントリスナーを確認してください。
発表前夜に内容を変更したい場合、新しいURLをレビュアーに送り直す必要がありますか？
上書きアップロードに対応した共有サービスを使えば、既存のURLのまま最新版に差し替えられます。レビュアーへの再送不要で当日朝に修正内容が反映されます。
スライドのレビューURLを提案先クライアントに送ってもよいですか？
パスワードまたはメール認証を設定し、有効期限を提案日翌日までに絞れば社外共有可能です。ただし転送リスクがあるため、機密度の高い資料はパスワードを別送することを推奨します。