Cloudflare R2公開バケットでは足りない認証・期限管理をどう補うか

できること

R2はHTMLと関連アセットをS3互換APIで管理でき、Cloudflare CDNのエッジから高速に配信されます。バケットに`index.html`を置くとドメインのルートとして機能するため、複数ページ構成のサイトもディレクトリ構造をそのまま維持して公開できます。

R2オブジェクトのメタデータにカスタムヘッダーを設定できるため、`Cache-Control`や`Content-Security-Policy`をオブジェクト単位で調整できます。Workersと組み合わせることでリクエストヘッダーを動的に書き換えることも可能です。

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

できないこと

R2単体でパスワード認証を提供する機能はありません。「このHTMLを見るにはパスワードを入力してください」という画面を出すには、Cloudflare Workersでリクエストをインターセプトしてパスワード検証ロジックを実装する必要があります。簡単なBASIC認証なら数十行で書けますが、ブルートフォース対策や複数ユーザー管理を加えると途端に複雑になります。

アクセス期限については、Cloudflare WorkersのKVストアに「このURLは〇〇日まで有効」というメタデータを持たせ、Workers側でアクセス日時と比較して制御することは技術的に可能です。ただしKVの読み取り遅延（グローバル整合性の制約）を考慮した設計が必要で、実装・テスト・保守のコストが発生します。

認証と期限の違い

Cloudflare Accessを使うと、R2バケットのカスタムドメインへのアクセス時にGoogleやMicrosoftのOAuthログイン、またはワンタイムメールコードによる認証を設定できます。Cloudflare Zero Trustの無料プランでは50ユーザーまで無料で利用できるため、少人数の社外レビューであればコストをかけずに認証を追加できます。

ギガサイト便との比較では、Cloudflare Accessは設定が「ポリシー単位」であり個々のURLに期限を設定するUIがないのに対し、ギガサイト便は「このURLは7日間有効」という発行単位での期限設定が直感的に行えます。レビューURLごとに期限を変えたい場合は専用サービスの方が管理しやすいです。

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

差し替え・レビュー運用

Cloudflare Accessで認証を設定している場合、アクセス許可するメールアドレスのリストを変更することでレビュアーの追加・削除ができます。ただしこの操作はCloudflareダッシュボードまたはAPIを通じて行う必要があり、毎回のレビューで手作業が発生します。

専用の共有サービスを使う場合との差は「一回の設定変更を誰がどこで行うか」です。R2+Accessでは技術者がダッシュボードで操作する必要がありますが、ギガサイト便ではデザイナーや営業担当者がGUIから自分でURL発行・失効ができます。チームの技術分布によって、どちらが運用しやすいかが変わります。

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

向いているケース早見表

R2＋Cloudflare Accessが向くのは「Cloudflare Zero Trustをすでに使っているチーム」「社外レビュアーが同一会社のGoogleワークスペースユーザー」「Workersに慣れた技術者がいて認証ロジックを保守できる」ケースです。

ギガサイト便のような専用サービスが向くのは「技術者以外もURL発行を担当する」「案件ごとに期限や認証方式が変わる」「インフラ保守コストをかけたくない」ケースです。R2はあくまでオブジェクトストレージとして使い、レビュー共有は専用ツールに任せるという役割分担が、長期的に最もメンテナンスコストが低くなる選択肢です。