できること
Glitchでできる最低限のアクセス制御は、プロジェクトを「Private」に設定してGlitchアカウントを持つ人だけに絞ることです。ただしこれは「Glitchにログインしている誰でも」という制限であり、特定の個人・会社・メールドメインへの限定にはなりません。
HTMLにJavaScriptでパスワード入力フォームを実装する方法もありますが、ソースコードがGlitch上で公開されている場合はパスワードの文字列がコードに埋め込まれた状態で見えてしまいます。コードを非公開にしても根本的な解決にはならず、セキュリティとしては脆弱です。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
できないこと
Glitchには閲覧URLに有効期限を設定する機能がありません。「3日後にはアクセスできなくする」「レビュー期間が終わったら自動失効させる」という管理はGlitch単体では不可能で、手動でプロジェクトをプライベート化するしかありません。
また、誰がいつアクセスしたかのログを取る機能もないため、情報漏洩が疑われても追跡できません。法務・コンプライアンス上の観点から閲覧履歴の保持が必要な案件では、Glitchだけで完結させるのは不適切です。
認証と期限の違い
認証付きHTML共有サービスが提供するアクセス制御は、Glitchでは代替できない機能が揃っています。パスワード認証はURLに加えて合言葉を知らないと開けない仕組みで、メール認証は事前登録したアドレス宛にOTPを送って本人確認します。どちらもGlitchのURL共有では実現できません。
会社ドメイン認証はコーポレートメールを持つ社員・取引先のみに絞る方法で、チームや部署ごとに異なるドメインを許可リストに登録できます。これにより「A社とB社の担当者だけが開ける」という細かいアクセス管理が可能になり、機密性の高い提案書のプレビューにも対応できます。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
差し替え・レビュー運用
Glitchの不足を補う現実的な方法は、開発はGlitchで行い、外部共有は認証付きサービスに切り替えることです。Glitchでコードが固まったら、HTMLファイルをエクスポートして専用サービスにアップロードするだけで認証付きURLが生成されます。この運用であればGlitchの開発体験を損なわずに済みます。
レビュー依頼時は「このURLは〇月〇日まで有効です」と期限を明示することで、レビュアーが後から古いURLを開いて混乱する事態を防げます。修正後の差し替えも同じURLで最新版を反映できるサービスを選ぶと、バージョン管理の手間が減ります。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
向いているケース早見表
Glitch単体でアクセス管理なしに使えるのは、オープンソースのデモや技術勉強会の作例提示など、情報を広く公開することが目的のケースです。不特定多数に見てもらいたい作品のポートフォリオ公開にも向いています。
社外クライアントへのデザイン提案・競合他社に知られたくないプロモーションページの事前確認・法的に機密扱いが必要な契約書関連のWeb表示確認などでは、Glitchは使わず最初から認証付きサービスを採用すべきです。ツール選定を後から変えるほど移行コストが高くなります。
よくある質問
Glitchでパスワード認証を自前実装するのはリスクがありますか？
パスワードをJavaScriptに直書きするとコードが見えている状態では無意味です。サーバーサイドの認証を組み込む方法もありますが、Glitchの無料枠ではスリープ遅延があり、認証フローの信頼性が下がります。
Glitchの「Password」機能はプレビューへのアクセス制限に使えますか？
Glitchのパスワード機能はプロジェクトの編集画面への保護であり、公開プレビューURLへのアクセスは制限できません。プレビューを特定の人だけに限定したい場合は別のサービスが必要です。
認証付きサービスとGlitchを組み合わせると工数が増えますか？
HTMLのエクスポートとアップロードは1〜2分の作業です。開発フェーズはGlitchで高速に進め、社外共有フェーズだけ認証付きサービスを使う分担にすれば、工数の増加は最小限に抑えられます。