Cloudflare R2公開バケットで公開したページを社外レビューに回すときの注意点

できること

R2の公開バケットを使うと、HTMLと関連するCSSや画像を正しいディレクトリ構造でアップロードすることで、相対パスが壊れないサイトをそのまま公開できます。`wrangler r2 object put`コマンドでディレクトリを再帰的にアップロードするか、Cloudflareダッシュボードのファイルマネージャーで確認しながら作業できます。

社外レビュー送付前にURLを自分で開き、PC・スマートフォン双方でフォントが正しく表示されるか、画像が読み込まれるかを確認してください。外部フォントをCDN経由で読み込んでいる場合、CSPヘッダーの設定によってはCloudflare経由で配信した際にブロックされることがあります。

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

できないこと

R2公開バケットはアクセスを特定のユーザーに限定する標準機能を持ちません。URLをクライアントに送った後、そのURLが別の人に転送されても止める手段がないため、競合他社の関係者などに閲覧されるリスクを排除できません。

社外レビューで頻繁に問題になるのは「レビュー完了後もURLが有効なままになる」ことです。R2ではオブジェクトを手動で削除しない限りファイルは残り続けます。「3ヶ月前に確認を依頼したHTMLがまだ公開されていた」という状況は、管理が煩雑になるほど発生しやすくなります。

認証と期限の違い

R2で認証を付けるにはCloudflare Accessを使う方法が現実的です。Custom Domainを設定したR2バケットにAccessポリシーを適用すると、アクセス時にCloudflareのログイン画面が表示されます。ただしR2.dev形式のデフォルトURLではAccessを適用できないため、独自ドメインの設定が前提になります。

期限管理については、Cloudflare Accessのポリシーに有効期間を設定する方法とR2のライフサイクルルールでオブジェクトを削除する方法の組み合わせで対応できますが、設定項目が複数に分散するため管理が煩雑です。ギガサイト便では「公開期限」を一カ所で設定するだけで済みます。

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

差し替え・レビュー運用

R2上のファイルを差し替えた後、Cloudflareのエッジキャッシュに古い版が残ることがあります。カスタムドメインでCache-Controlを`no-cache`に設定しておくか、Cloudflareダッシュボードの「キャッシュ」→「設定」から「カスタムパージ」でURLを指定してキャッシュを削除してください。

レビュー依頼文には「URLの有効期限はいつか」「修正後に同じURLで確認できるか」を明記してください。R2の場合、手動削除しない限りURLは有効なので「有効期限は未設定で、レビュー完了後に削除する予定」と伝えると透明性が保たれます。

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

向いているケース早見表

R2公開バケットの社外レビュー利用が比較的安全なのは「公開に支障のない内容（非機密）」「Cloudflare Accessで認証を設定している」「独自ドメインでURLを管理している」の3条件が揃う場合です。

逆に「認証なし・Cloudflare WorkersによるカスタムロジックなしでR2のデフォルトURLを直接共有」という運用は、機密コンテンツには不適切です。この場合はギガサイト便などの専用サービスを社外レビュー専用チャンネルとして活用し、R2はプロダクション配信に専念させる構成が安全で管理しやすいです。