できること
Glitchで公開したURLを受け取ったレビュアーは、Glitchアカウントを持たなくてもブラウザで即座に表示を確認できます。スマートフォンでURLを開けばモバイル表示もその場でチェックでき、修正内容を反映させると自動でリロードされるため、往復の手間が少ないのが利点です。
共有前に送付者側がPC・iOS・Androidの3環境で実際に開き、フォントの読み込みや画像の表示崩れがないことを確認しておきましょう。特に外部フォントをCDNから読み込んでいる場合、ネットワーク環境によって表示速度が変わることがあるため、低速回線での動作も見ておくと安心です。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
できないこと
Glitchには特定の人だけに閲覧を限定する機能がないため、URLが転送・拡散された場合に意図しない第三者がアクセスできてしまいます。NDA締結前のデザイン案や価格交渉中の見積もりページをGlitchで共有するのは、情報管理の観点から避けるべきです。
また、Glitchのデフォルト設定ではHTMLソースが誰でも閲覧・フォーク可能です。HTMLコメントに残した「クライアント名」「修正依頼メモ」「将来のキャンペーン情報」などが外部から読まれるリスクがあるため、共有前に必ずソースを精査してください。
認証と期限の違い
社外レビューでは「誰が・いつまで・何を見られるか」を制御できることが重要です。認証付き共有サービスのメール認証機能を使えば、事前に登録したメールアドレスの持ち主だけが閲覧でき、アクセスログも残るため情報漏洩時の追跡が可能になります。
期限設定を活用することで、レビュー期間終了後にURLが自動失効します。Glitchでは期限後に手動でプロジェクトをプライベートに変更する必要がありますが、作業の多忙期には切り替えを忘れがちです。重要案件ほど自動失効の仕組みを使う方が安全です。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
差し替え・レビュー運用
Glitchは変更が即時反映される一方、「今このURLに何が表示されているか」をレビュアーが把握しにくいです。依頼メールに「〇〇日〇〇時に修正を適用します」と書き添え、更新後にリマインドを送る運用を徹底することで、レビュアーの混乱を防げます。
社外レビューの依頼文には確認してほしい観点を3点以内に絞り、「ボタンのラベルが意図通りか」「価格表示に誤りがないか」など具体的な質問形式にすると、的を絞ったフィードバックが返ってきやすくなります。返信期限と担当者名も忘れずに明記してください。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
向いているケース早見表
Glitchによる社外共有が許容されるのは、公開情報の確認やオープンソースライブラリのデモ、内容がすでに公開済みのランディングページのデザイン微調整といった機密性の低いケースに限られます。「見られても問題ない」と言い切れる内容かどうかが判断基準になります。
機密度が少しでもある案件は、パスワード認証・メール認証・ドメイン認証のいずれかを備えたサービスを使うべきです。ギガサイト便のような専用サービスであればHTMLのzipをドラッグ＆ドロップするだけで3秒以内に認証付きURLが生成でき、Glitchでプロジェクトを作る手間も不要です。
よくある質問
Glitchでソースコードを非公開にしても安全に社外共有できますか？
ソースを非公開にしてもURLを知っている人全員が閲覧でき、アクセス制限や期限設定はできません。社外共有には閲覧者を限定できる認証付きサービスを併用することを推奨します。
Glitchのプレビューにパスワードをかける方法はありますか？
Glitch自体にはHTMLプレビューへのパスワード設定機能がありません。Basic認証をコードで実装する方法もありますが、認証情報がソースに露出するリスクがあるため、専用の共有サービスを使う方が確実です。
社外レビューが終わったGlitchプロジェクトはどう処理すればいいですか？
レビュー完了後はプロジェクトをPrivateに変更し、不要になった場合はDeleteしてください。プライベート化を忘れると旧プレビューURLが永続的にアクセス可能な状態になります。