Firebase Hostingから一時共有URLへ切り替えるタイミング

できること

Firebase Hostingのデプロイ済みビルド成果物（distフォルダ）をzipにまとめれば、ギガサイト便などの一時共有サービスにそのままアップロードできます。これにより本番デプロイのFirebase Hostingはそのままに、社外レビュー用だけ認証付きURLを使い分けるという二段構えの運用が可能になります。

切り替えを検討する際は、まず相手がスマホで閲覧するかどうかを確認しましょう。ギガサイト便はモバイルブラウザに最適化されたビューアを持ち、PCとスマホで同じURLを開いてレスポンシブ表示を確認できます。Firebase HostingのPreview Channelも同様にURLを送るだけでモバイル確認は可能ですが、認証のかけやすさが異なります。

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

できないこと

Firebase Hosting自体を「一時共有専用」のサービスとして使うことには限界があります。特に、チャンネルごとの閲覧者管理（誰がいつ何回アクセスしたかのログ）がなく、「承認者が本当に確認したか」を追跡できないため、承認フローが厳格な案件では記録として不十分です。

また、Firebase Hostingから切り替えた後に元のURLが残っている場合、両方のURLが共存する期間に古い方へのアクセスが続くことがあります。古いPreview Channelを手動で削除する手順を省くと、「どのURLが最新か」の混乱が発生しやすく、特に複数のレビュワーが関わる場合は確認状況の管理が難しくなります。

認証と期限の違い

「誰でも見てよい」内容であってもFirebase Hostingで長期間放置したURLは、本番公開後もアクセス可能なまま残り続けます。一時共有URLへの切り替えは、レビュー完了後に確実にアクセスを遮断できるという点で期限管理の確実性が高く、特に情報管理が厳しい業種（医療・金融・官公庁向け制作物）では切り替えの効果が大きいです。

特定の相手だけに閲覧を絞りたい場合、Firebase Hosting + Cloud Functionsで実現するより、認証付き共有サービスに切り替えた方が初期設定コストは大幅に下がります。ドメイン認証を使えば「@partner-company.co.jpのアドレスを持つ人のみ」という制限がUIだけで設定でき、コードを書く必要がありません。

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

差し替え・レビュー運用

切り替えのタイミングとして最も明確な基準は「相手が社外かどうか」です。社内チームへの進捗共有はFirebase Hosting Preview Channelで十分ですが、取引先・クライアント・承認権限を持つ外部担当者への共有では、認証付き一時URLに切り替えることでセキュリティとトレーサビリティが向上します。

切り替え後の運用として、修正が入るたびにビルド→zip→再アップロードの手順を踏む必要があります。CIパイプラインにアップロードステップを組み込むと自動化できますが、手動運用の場合は「修正版をデプロイしたら即座にzipも更新する」というルールをチーム内で徹底することが重要です。修正版のアップロードを忘れた状態でレビュワーに確認を依頼すると、旧版に対するフィードバックが集まるという問題が起きます。

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

向いているケース早見表

Firebase Hostingのまま継続が向いているのは、社内エンジニアだけがレビューを行い、Googleアカウントによる認証でアクセス制限できる環境、またはPreview Channelの有効期限管理でセキュリティ要件が満たせるケースです。既存のFirebase Authを使った認証付きサービスのレビューにも適しています。

一時共有URLへの切り替えが有効なのは、非エンジニアのディレクターや広告代理店の担当者が独立してレビューURLを管理したい場合、あるいは複数取引先に対してそれぞれ個別のパスワードで管理されたURLを発行したい場合です。Firebase CLIを操作しなくても共有URLの作成・更新・削除がブラウザだけで完結します。