Cloud Storage for Firebase

解決する課題

写真・動画・ユーザー生成ファイルを扱うアプリで、アップロード用のサーバーや署名処理を自前で作らずに、クライアントから直接かつ安全にファイルを保存できます。

• 画像・動画・音声などのユーザー生成コンテンツを、独自バックエンドを書かずに保存
• モバイル/Web のクライアント SDK から直接アップロード/ダウンロードできる
• 電波が不安定でもアップロード/ダウンロードを自動で再開（中断に強い）
• Firebase Authentication のユーザーとSecurity Rulesで、ファイル単位の認可を宣言的に記述

主要概念と用語

• バケット: ファイルを入れる入れ物。実体は Cloud Storage のバケットで、Firebase プロジェクトに既定バケットが 1 つ用意される（追加バケットも利用可）
• 参照（reference）: バケット内のファイルやフォルダを指すポインタ。gs://バケット名/パス または HTTPS の形で表す
• Firebase Security Rules: パスごとに read/write を許可/拒否する宣言的なルール言語。認可はサーバーコードではなくこのルールで行う
• Firebase Authentication 連携: ルール内で request.auth を参照し、ログイン中ユーザーや UID 単位でアクセス制御できる
• メタデータ: 各ファイルに付く contentType（MIME タイプ）、サイズ、作成日時、カスタムメタデータなど
• アップロードタスク: 進捗・一時停止・再開・キャンセルを扱える、再開可能アップロードの単位
• ダウンロード URL: クライアントから共有できる、トークン付きの HTTPS ダウンロードリンク（取り消し可能）
• Admin SDK / サーバーアクセス: サーバー側は Google Cloud の認証情報で同じバケットを直接操作できる

仕様・制限・クォータ

• 実体が Cloud Storage のため、1 ファイル最大 5TiB など Cloud Storage 本体の上限・耐久性を引き継ぐ
• 認可は Security Rules が基本。ルールは既定で拒否寄りで、明示的に許可しない限りアクセスできない
• クライアントからの認可は Security Rules、サーバー側（Admin SDK 等）からのアクセスは Cloud IAM に従う（Security Rules はサーバーアクセスには適用されない）
• 既定バケットは Firebase プロジェクト作成時のロケーション設定に従う。ロケーションは後から変更できないため、最初の選定が重要
• アップロード/ダウンロードは再開可能で、ネットワーク中断後に途中から続行できる
• Security Rules の評価には複雑さの上限があり、ルールはなるべく単純に保つ
• リクエスト数や帯域などの実数値・上限はプロジェクト設定や時期で変わるため、最新値は公式を参照

内部の仕組み

Cloud Storage for Firebase は、Cloud Storage のバケットに対してクライアント向けの認可レイヤーと SDK を載せたものです。クライアントは Firebase の SDK から直接バケットへ接続し、リクエストごとに Firebase Authentication のトークンと Security Rules が照合されて許可/拒否が決まります。

• クライアント SDK はファイルパス（参照）への read/write を発行し、Security Rules が request.auth やパス・メタデータを見て判定する
• ファイルの実体・冗長化・暗号化・耐久性は下位の Cloud Storage がそのまま担う
• サーバー側（Admin SDK や gcloud）からのアクセスは Security Rules を経由せず、Cloud IAM の権限で同じバケットを操作する
• アップロード/ダウンロードは分割転送で行われ、中断時は完了済みの部分を引き継いで再開する

設計パターン / ベストプラクティス

• ユーザーごとのパス分離: user/{uid}/... のようにパスへ UID を含め、ルールで request.auth.uid と一致するパスだけ許可する
• メタデータでバリデーション: ルールで request.resource.size（サイズ）や request.resource.contentType（MIME タイプ）を検査し、巨大ファイルや想定外形式を拒否
• 重い後処理はサーバーへ: サムネ生成や変換は、アップロードをCloud Functions / Eventarc でトリガーし、Cloud Run などで非同期処理
• 公開配信は分離: 公開してよいファイルは専用パス/バケットに分け、非公開データと混在させない
• オフライン耐性: モバイルでは再開可能アップロードを前提に、進捗表示・一時停止・再開の UI を用意する

運用・監視

• バケットは Cloud Storage の実体なので、Cloud Monitoring で容量・リクエスト数・エラー率を可視化できる
• Cloud Audit Logs でアクセスを監査（特にサーバー経路や設定変更）
• アップロード/ダウンロードの失敗の多くは Security Rules の拒否・認証トークン切れ・パス不一致が原因。まずルールとログを確認
• Security Rules は本番反映前にシミュレーター/テストで挙動を検証し、想定外の許可がないかを点検
• ストレージの棚卸し・コスト分析は Storage Insights など Cloud Storage 側のツールを併用

コスト

課金は実体である Cloud Storage の料金に従い、「保存量」「オペレーション（API 呼び出し）」「ネットワーク下り（ダウンロード転送）」が中心です。Firebase 側の料金プラン（無料枠を含む従量課金プラン）と組み合わさります。

セキュリティ

• 認可の基本は Firebase Security Rules。既定は拒否寄りで、許可は明示的に書く
• Firebase Authentication と連携し、request.auth でログイン状態や UID 単位の制御ができる
• ルールでファイルサイズ・MIME タイプ・パスを検査し、不正なアップロードを入口で弾く
• 保存時暗号化は Cloud Storage により既定で有効。要件に応じて CMEK などへ切替可能（バケット設定に従う）
• サーバー経路は Cloud IAM で最小権限。サービスアカウント鍵の管理に注意

関連サービス・比較

サーバーレスな保存先という点で Cloud Firestore と混同されがちですが、役割が異なります。バイナリの大きなファイルは Cloud Storage for Firebase、構造化データやリアルタイム同期は Firestore が適します。

ハンズオン / CLI例

クライアントは Firebase SDK から操作しますが、バケットの実体は Cloud Storage なのでサーバー側からは gcloud storage でも扱えます。Security Rules のデプロイは Firebase CLI を使います。

# Firebase プロジェクトの既定バケットを確認（Google Cloud CLI）
gcloud storage buckets list --project=my-firebase-project

# サーバー側からファイルをアップロード（実体は Cloud Storage バケット）
gcloud storage cp ./avatar.png gs://my-firebase-project.appspot.com/user/uid123/avatar.png

# バケットのライフサイクルを適用（30日経過で Nearline へ等を JSON で定義）
gcloud storage buckets update gs://my-firebase-project.appspot.com \
  --lifecycle-file=lifecycle.json

# Security Rules を Firebase CLI でデプロイ（storage.rules を反映）
firebase deploy --only storage