Cloudflare R2公開バケットから一時共有URLへ切り替えるタイミング

できること

R2公開バケットで公開したHTMLを継続的に更新しながら同じURLで維持するのは、R2の得意な使い方です。Cloudflare Workersと組み合わせてURLのルーティングを制御したり、Headers Transformationで適切なCache-Controlを付与したりすることで、プロダクション配信に近いクオリティのプレビュー環境を作れます。

社内レビューや開発チーム内の確認フェーズでは、R2公開URLを社内SlackやNotionに貼るだけで共有が完結します。IAMの設定不要でリンクを貼るだけのシンプルさは、スピードが重視される開発フェーズに向いています。

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

できないこと

R2単体では「このURLは今週末に失効します」という期限付き公開ができません。Lifecycleルールでオブジェクトを削除できても、削除後に「期限切れです」という説明ページを表示する仕組みはなく、レビュアーに適切な情報を伝えられません。

また複数のレビュアーごとに異なる閲覧権限を設定することもR2では困難です。「AさんはページAのみ」「BさんはページAとBを見られる」という粒度のアクセス制御は、Cloudflare AccessやWorkersで実装しない限り不可能です。

認証と期限の違い

切り替えのサインとして最もわかりやすいのは「社外の人に送る段階になったとき」です。社内確認が完了してクライアントや取引先に確認依頼を出す際、R2の公開URLをそのまま使うのはリスクが伴います。このタイミングでギガサイト便のような認証付き共有サービスに切り替えることで、URLの流出・転送による情報漏洩リスクを下げられます。

もう一つの切り替えサインは「コンテンツに未発表情報や個人情報が含まれる場合」です。開発フェーズでは問題なかった内容でも、完成度が上がるにつれて機密情報が盛り込まれることがあります。「このHTMLには個人情報の入力フォームのデモが含まれる」という場合は、その時点でR2公開URLを閉じ、認証付きURLに切り替える判断をしてください。

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

差し替え・レビュー運用

R2から一時共有URLへ切り替える際の手順として、まず新サービスにコンテンツをアップロードして認証設定と期限を設定し、新URLをレビュアーに送ります。次にR2上の旧コンテンツを削除してURLを無効化します。この順序を守ることで、短い時間でも「アクセスできないURL」が発生するのを防げます。

切り替え時によく発生するのは「旧R2 URLをまだ持っているレビュアーが古いバージョンを参照し続ける」問題です。切り替え通知のメッセージには「旧URLは削除しました。以降はこちらのURLからご確認ください」と明示し、旧URLへのアクセスが404になることを先に伝えておくと混乱を防げます。

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

向いているケース早見表

R2公開バケットを維持してよいケース：社内メンバーのみがアクセスする開発プレビュー、機密情報を含まないOSSドキュメントの公開、長期間同じURLを維持する必要がある静的サイト。一時共有URLへの切り替えが必要なケース：社外への共有、機密情報を含む、期限を設定したい、アクセスログを手軽に確認したい。

「開発フェーズはR2、対外共有フェーズは専用サービス」というルールをチームで事前に決めておくと、毎回判断する手間が省けます。フェーズの境界を「コードレビューが完了してデザインレビュー依頼を出すとき」などのマイルストーンと紐づけるとワークフローに自然に組み込めます。