Google Cloud Storage静的ホスティングで公開したページを社外レビューに回すときの注意点

できること

GCSの公開バケットにアップロードしたHTMLは、URLをそのままレビュアーのメールやチャットに貼るだけで開いてもらえます。社外の人間がGoogleアカウントを持っていなくても閲覧できるため、クライアントへの確認依頼として最も摩擦の少ない手段の一つです。

共有前に自分で一通りの動作確認を済ませておくことが前提です。特にスマートフォン表示とPC表示の両方を確認し、フォントの読み込みや外部CSSが正常に取得されているかをDevToolsのNetworkタブで確認してください。外部依存リソースが403や404を返していると、相手の環境では壊れたデザインが表示される可能性があります。

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

できないこと

GCSの公開バケットは、URLを知っていれば誰でもアクセスできます。クライアントに共有したURLが社内Slackに誤って投稿されたり、メール誤送信で転送されたりした場合に、それ以上の閲覧を止める手段がありません。機密性の高いモックアップや未発表の製品情報を含む場合は特に注意が必要です。

バケット全体の公開設定を変えない限り、特定のファイルだけをあとから非公開にすることもIAMでは直感的に行えません。「レビュー完了後に該当ファイルを削除する」という手順を予め決めておかないと、URLが半永久的に有効なまま残り続けます。

認証と期限の違い

社外レビューで問題になりやすいのは「URL流出時に誰でも見られる状態になること」です。ギガサイト便ではパスワードを設定しておけば、URLが流出しても正しいパスワードを入力しないとページが開きません。GCSにこの制御を加えるには Lambda 相当のサーバーレス関数で認証ゲートを自前実装する必要があります。

期限管理についても、ギガサイト便では発行時に「7日間有効」と指定するだけですが、GCSでは期限後に手動でオブジェクトを削除するかObject Lifecycleポリシーを設定する必要があります。レビュー案件が複数重なると管理し忘れるリスクが高まります。

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

差し替え・レビュー運用

GCSでHTMLを差し替える際は、`gsutil cp`コマンドで同じパスに上書きアップロードします。このとき`Cache-Control: no-store`ヘッダーを付与しておくと、ブラウザが古いキャッシュを返すリスクを下げられます。差し替え後はレビュアーにリロードを促すひと言を添えると親切です。

レビュー依頼文には「このURLはいつまで有効か」「修正後に同じURLで確認できるか」を明記してください。GCSの場合は手動削除しない限りURLは有効であることを伝えつつ、「最終確認後にURLを削除する」という処理フローをチームで標準化しておくことが漏洩リスクの低減につながります。

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

向いているケース早見表

GCSの静的ホスティングを社外レビューに使ってよいのは、「内容が公開されても問題ないもの（例：OSSドキュメント、公開前だが機密情報を含まないLP）」かつ「レビュアーが社内のGoogleアカウント管理に含まれている場合」に限ると考えると安全です。

一方で「クライアントとのNDA締結前のデザイン確認」「未発表サービスのUI共有」「個人情報が入力できるフォームのテスト確認」といったケースでは、認証と期限を備えた専用サービスを使う方がリスクを制御できます。コストよりも情報管理の確実性を優先する判断をしてください。