Cloud Storage for Firebaseとは｜ルール設計とGCS直接操作の判断【2026年8月時点】

Cloud Storage for Firebaseは、モバイルアプリやWebアプリから画像・動画・PDFといったファイルを直接読み書きするためのFirebaseの機能です。保存先の実体はGoogle Cloud Storageのバケットで、同じデータをFirebase SDKからもGoogle CloudのAPIからも触れます。2024年9月に発表された一連の変更により、デフォルトバケットの名前はfirebasestorage.app形式へ変わり、2026年2月3日からは利用そのものにBlazeプランが必要になりました。本記事では、GCSとの関係、権限を分離するルールの書き方、保存と転送と操作回数という三軸の課金、採用を見送るべき条件を整理します。数値と日付は2026年8月時点の公式ドキュメントおよび料金ページの記載です。

まとめ：Blaze必須化後に見るバケット設計とルール実装の結論

結論を先に置きます。この機能の本質は「ストレージ製品」ではなく、GCSバケットの前に置かれた認証付きのアクセス層です。Firebase側が足しているのは、クライアントSDKからの直接アップロードと、Firebase Authenticationの認証情報に紐づくルール評価。この二つだけと考えると設計を誤りません。

前提条件は二段階で変わりました。2024年10月30日以降に作られるデフォルトバケットはappspot.comではなくfirebasestorage.appになり、新規作成にBlazeプランが要ります。さらに公式FAQのとおり、2026年2月3日からは利用そのものと既存appspot.comバケットの維持にもBlazeが必要です。無料で試せる範囲は残るものの、それは「無料プランのまま使える」ではなく「従量課金の契約下で無料枠が適用される」に変わりました。

採用判断はこう切り分けます。ユーザーが自分のファイルを預け、本人か限られた相手だけが読む要件なら第一候補。大量の画像変換や動画配信が主目的なら見送ります。ルールで守れるのは読み書きの可否だけで、変換も配信の作り込みもFirebase側は担いません。ストレージクラス設計の総論はGCSそのものを扱った解説に譲ります。

Cloud Storage for Firebaseの構成とGCSバケットの関係

最初に押さえるべきは、Firebaseコンソールの「Storage」画面が独立した保管庫ではない点です。誤解したまま設計すると、サーバー側の処理もコスト試算もずれます。

デフォルトバケットの命名がfirebasestorage.appに変わった経緯

公式は「Cloud Storage for Firebase はファイルを Google Cloud Storage バケットに保存し、Firebase と Google Cloud の両方からアクセスできるようにする」と明記しています。バケットはGCSの実体そのもので、Firebaseプロジェクトとひも付いているだけです。

この関係は2024年9月の発表で表面化しました。悪用防止のためGCSのクォータと課金の仕組みに揃える必要が生じ、2024年10月30日を境に新規のデフォルトバケット名がPROJECT_ID.appspot.comからPROJECT_ID.firebasestorage.appへ変わっています。既存バケットの名前はそのままです。落とし穴はここで、SDKの初期化設定やCI環境変数にバケット名を直書きしていると、新旧プロジェクトを行き来した時点で参照先が食い違います。

クライアントから直接アップロードする経路とサーバ経由の使い分け

Firebase SDKの最大の特徴は、アプリからGCSへ直接ファイルを送れる点です。自前のAPIサーバーを経由しないため、大きなファイルでもサーバーの帯域とメモリを消費しません。公式は、アップロードとダウンロードが「停止した地点から再開する」堅牢な設計だと説明しています。JavaScript SDKではuploadBytesResumableが再開可能なアップロードに対応し、進捗を画面へ反映できます。

ではサーバー経由が要らないかというと、違います。分かれ目は「保存前に検証や変換が必要か」。ウイルススキャンやサムネイル生成が要るなら、クライアントは一時領域へ置くだけにして、アップロード完了をトリガーにCloud Functions for Firebaseの関数で受けるのが定石です。検証がサイズと拡張子程度で済むなら、中継サーバーを置く理由はありません。

GCS側のAPIから同じバケットを操作するときの権限と注意点

同じバケットに対し、サーバーサイドではGoogle Cloud Storageのクライアントライブラリをそのまま使えます。公式も「Google Cloud Storage の API を使ってサーバーサイドの処理ができる」と案内しており、バッチ処理や一括削除はこちらが向きます。

ここで効いてくるのが権限モデルの違いです。クライアントSDK経由のアクセスはセキュリティルールで評価されますが、サーバーサイドのGCS APIやAdmin SDKはIAMのサービスアカウント権限で動き、ルールを通りません。「ルールで止めたはずのパスに管理バッチが書き込めてしまう」のは設計ミスではなく仕様です。ルールは利用者からの経路を守る仕組みであって、バケット全体の防護壁ではありません。ストレージクラスの選択やライフサイクルによる自動削除もGCS側の機能で、GCSのストレージクラスと保存期間の考え方を参照してください。

Cloud Storageセキュリティルールの設計と権限分離の実装

クライアント直送を選んだ時点で、アクセス制御の責任はほぼすべてセキュリティルールに移ります。ルールが甘いと、認証さえ通れば他人の領域を読めるアプリになります。

request.authとカスタムクレームで書き込み先を絞る書き方

ルール評価では、未認証のリクエストに対してrequest.authがnullになります。認証済みなら公式の記述どおりrequest.auth.uidにユーザーIDが入り、JWTのクレームがrequest.auth.tokenへ展開されます。カスタム認証の追加クレームも同じ場所です。

実装の基本形は、パスにユーザーIDを含めて自分の領域だけに書けるようにする形です。users配下にUIDのディレクトリを切り、そのUIDがrequest.auth.uidと一致するときだけ読み書きを許可します。組織や役割による分岐が要るなら、認証時にカスタムクレームへ役割を載せ、ルール側はrequest.auth.tokenの値で判定する形にします。判定に使う属性は「トークンに載せておく」前提で、Firebase Authenticationの認証方式とカスタムクレームの側から設計してください。

サイズとContent-Typeを条件化して不正アップロードを止める

認証だけを条件にしたルールは穴だらけです。ログイン済みの利用者が数GBのファイルを投げ込めば、保存料と転送料に跳ね返ります。公式は書き込み条件にサイズと種別を併記する例を示しています。

• request.resource.sizeで上限を課す。単位はバイトで、5MBに制限するなら5×1024×1024と書きます
• request.resource.contentTypeのmatchesで種別を絞る。画像だけ許すなら image/.* のパターンを渡します
• パスのワイルドカードで拡張子やディレクトリ階層を限定し、想定外の場所への書き込みを弾きます
• 更新と新規作成を分けたい場合、resourceがnullかどうかで既存ファイルの有無を判定します

優先順位をつけるなら、まずサイズ上限です。種別の判定はクライアントが申告するContent-Typeに依存するため、偽装される前提で考えるべきで、単独では防御になりません。呼び出し元が正規のアプリかどうかを確かめる層はFirebase App Checkのプロバイダ選定と強制移行の解説で扱っています。サイズは実データに対して評価されるので、費用面の被害を確実に止められます。バージョン2ではletで変数を定義でき、条件が増えても読める形に保てます。

rules_version 2への更新が必要になるlist操作の制約

ファイル一覧の取得は、他の操作と扱いが違います。公式は「List API を使うプロジェクトには Cloud Storage for Firebase ルールのバージョン2が必要」と明記しており、バージョン1のままでは一覧表示が許可されずエラーになる。既存プロジェクトに一覧画面を後付けする場面で、ここに引っかかる例が目立ちます。

取得方法にも制約があります。listAllは結果を全件メモリに保持するため、公式は件数が多い場合にページ送りのlistを使うよう促しています。処理中の追加・削除で一貫したスナップショットにならない点も明記されており、一覧をそのまま在庫数として扱う設計は避けてください。返り値はitemsとprefixesに分かれ、後者は下位の仮想ディレクトリです。GCSにディレクトリの実体はなく、prefixesは名前の区切りから導かれた見かけ上の階層にすぎません。

Firestoreドキュメント参照が使えるようになった条件と上限

かつてのStorageルールは外部データを参照できず、判定材料はカスタムクレームに詰め込むしかありませんでした。現在の公式ドキュメントには、Firestoreのドキュメントを参照する条件が載っています。制限は二つ。「1回のルール評価でアクセスできるFirestoreドキュメントは2件まで」、そして「参照できるのはデフォルトのCloud Firestoreデータベースのみ」です。

設計上の勘所は、参照を常用しないことです。ドキュメント参照はルール評価のたびに走り、読み取り課金と遅延が乗ります。役割やプラン区分のように変化が遅い属性はカスタムクレームへ、共有設定のように頻繁に変わる属性だけFirestore参照へ振り分けてください。

Cloud Storage料金の数え方とレガシーバケットの無料枠の差

課金の読み違いが最も起きやすいのが、この機能です。保存容量だけを見て見積もると、操作回数の請求で足をすくわれます。

保存容量とダウンロード量と操作回数に分けて見積もる課金の内訳

数える軸は三つ。保存容量はバケットに置かれたデータ量へ月額で積み上がり、ダウンロード量はアプリが受け取ったバイト数に単価が掛かります。三つ目が操作回数、つまりアップロードとダウンロードのリクエスト数です。

見落とされるのは三番目です。サムネイルを1画面に50枚並べるアプリなら、1回の表示でダウンロード操作を50回消費します。1日1万回の表示で50万操作。転送量そのものが小さくても、操作回数の側が先に無料枠を突き抜けます。効く手は、画像をサイズ別に束ねて枚数を減らすことと、getDownloadURLで得たURLをキャッシュして再取得を減らすこと。プロジェクト全体の単価合算はFirebaseの料金の全体像にまとめています。

レガシーバケットと新規バケットで異なる無料枠と超過単価の比較

厄介なのは、同じ機能でもバケットの世代で課金体系が違う点です。2026年8月時点の公式料金ページの記載を整理します。

差が際立つのはアップロード操作です。レガシーは1日2万回、新規バケットは1か月5千回。単位が日次と月次で違ううえ、絶対量も一桁以上小さくなります。ユーザー投稿型のアプリを新規プロジェクトで立ち上げるなら、アップロード操作はほぼ課金対象になる前提で試算してください。

無料枠が三つのリージョンに限定される制約とバケット配置の判断

新規バケットの無料枠には地理的な条件が付きます。公式はAlways Freeの対象をUS-CENTRAL1・US-EAST1・US-WEST1の3リージョンに限ると明記しており、東京リージョンに置いた瞬間、無料枠は適用されません。

ここは金額と遅延のトレードオフになります。利用者が日本国内で、画像や動画の初回表示速度が体験を左右するアプリなら東京側に置き、無料枠は諦めるべきです。数十GB規模なら月額は数ドル程度で、遅延を削る価値のほうが上回ります。逆に社内向けの帳票保管やアーカイブのように、参照頻度が低く数百ミリ秒の差が問題にならない用途なら、米国リージョンに置いて無料枠へ収める判断が成立します。デフォルトバケットのロケーションは後から変更できません。

Blazeプラン必須化で変わった検証環境の準備と初期構築の手順

2026年の要件変更で、いちばん影響を受けたのは検証環境です。「まず無料で触ってみる」という入り口が塞がりました。

2026年2月3日以降にBlazeプランが必要になった範囲の確認

公式FAQは「Cloud Storage for Firebase を使用する、または PROJECT_ID.appspot.com のデフォルトバケットへのアクセスを維持するには、従量課金の Blaze 料金プランへのアップグレードが必要です。この要件は 2026年2月3日から適用されました」と記載しています。2024年10月30日時点では新規バケット作成にBlazeが要る状態で、2026年2月3日からは利用そのものとレガシーバケットの維持へ対象が広がった形です。

実務への影響は二つあります。カードを登録せずに検証していた環境では、Storageだけ同じやり方が通りません。一方でBlazeへ移っても無料枠は残り、課金額がいきなり跳ねるわけでもない。要求されているのは支払い手段の登録であって費用の発生ではない、と発注側へ説明できると話が早く進みます。初回デプロイまでの流れはFirebaseの導入手順にまとめてあります。

エミュレータで課金を伴わずルールとアップロード経路を検証する

Blaze必須化と表裏で価値が上がったのがローカルエミュレータです。実バケットへ一切書き込まずに、ルールの分岐とアップロード経路を確認できます。無料枠の消費もなく、本番データを壊す事故も起きません。

特に効くのがルールのテストです。目視のレビューでは「認証済みなら他人の領域も読める」といった抜けを見落とします。UIDを差し替えたテストを並べ、許可と拒否の双方を自動で確認すれば、権限の退行を継続的に検出できる。構成とCIへの組み込み方はFirebase Local Emulator Suiteの解説で扱っています。

予算アラートと操作回数の監視で想定外の請求を止める初期設定の勘所

従量課金になった以上、上限の仕組みを先に入れます。Firebaseの予算アラートは通知にすぎず、閾値を超えても処理は止まりません。止めるならCloud Billingの予算とPub/Subを組み合わせ、超過時に課金アカウントを切り離す仕組みを別途組みます。

監視で見るべき指標は金額より操作回数です。金額が月次で緩やかに動くのに対し、操作回数はキャッシュ設定の変更やリトライのバグで一晩に数十倍へ跳ねます。クライアント側のリトライには上限回数と待ち時間の引き延ばしを必ず入れてください。

Cloud Storage for Firebaseを採用しない方がよい条件

ここは判断を言い切ります。以下の条件に当たる案件で無理にFirebase側へ寄せると、後から作り直しになります。

動画配信や大量の画像変換を伴う要件で採用を見送るべき判断基準

動画をユーザーへ配信する用途では採用しません。提供されるのは素のファイル配信だけだからです。アダプティブビットレート、視聴時間の計測、地域別の配信制御はいずれも範囲外で、結局は別サービスを重ねます。ダウンロード量への従量課金がそのまま乗る点も、配信量が読めない用途では致命的です。

画像変換も同じです。サムネイル生成程度なら関数側で処理できますが、1日数万件規模の変換が常時走る要件では、関数の実行時間とストレージ操作回数が二重に積み上がります。この規模なら、変換機能を内蔵した画像配信サービスやCDNへ寄せるほうが費用も実装量も小さく収まる。目安として、変換対象が1日1万件を超えるなら別方式を検討してください。

監査要件が厳しい業務システムでGCSの直接管理に寄せる線引き

金融や医療のように、誰がいつどのファイルへアクセスしたかを厳密に残す案件では、Firebase側の層を挟まずGCSを直接扱う構成を選びます。監査ログの粒度やIAMによる職務分離の表現力が、GCS側の機能に依存するためです。

線引きの基準を示します。求められているのが「利用者ごとの領域分離」までならFirebase側で足ります。「操作ログの長期保管」「鍵の自社管理」「権限付与の承認フロー」のいずれかが加わったら、クライアント直送をやめてGCSのIAMとログ基盤で組む構成へ寄せてください。両方を併用すると、監査時にどちらが実際の制御なのか説明できなくなります。

Webのみの案件でFirebaseを選ぶ前に比較したい代替構成

Webの管理画面から画像を差し替える程度の要件なら、Firebaseを持ち込む必然性は薄いと考えます。すでにサーバーサイドのアプリが動いているなら、そこから署名付きURLを発行してGCSやS3へ直接アップロードさせる構成のほうが依存関係は減ります。Firebaseの強みはモバイルSDKと認証の結び付きにあり、その利点が効かない場面では管理対象が増えるだけです。

逆にiOSとAndroid双方のアプリを持ち、利用者ごとのファイル領域と認証を短期間で立ち上げたいなら、制約を織り込んだうえで有力な選択肢です。データ同期が絡むならRealtime Databaseの同期モデルと組み合わせた構成も検討対象になります。バケット設計とルール実装、課金の見積もりまで含めた判断に迷うなら、スマホアプリ開発の相談窓口で要件を整理するところから進められます。

よくある質問

導入検討で実際に挙がる質問を、公式ドキュメントの記載に沿って整理します。

Cloud Storage for FirebaseとGoogle Cloud Storageは別物ですか？

保存先は同一です。Cloud Storage for FirebaseはGCSバケットを使っており、公式も両方からアクセスできると説明しています。違いは触り方で、Firebase側はクライアントSDKからの直接アクセスとルールによる制御、GCS側はIAMとサーバーサイドのAPIを担います。同じバケットに二つの入り口がある、と捉えてください。

無料プランのままCloud Storageを使うことはできますか？

できません。公式FAQによれば、2026年2月3日から、Cloud Storage for Firebaseの利用および既存appspot.comバケットへのアクセス維持には従量課金のBlazeプランが必要です。ただしBlazeでも無料枠は適用されるため、小規模な検証なら請求額はゼロに近い水準に収まります。支払い手段の登録が必須になった、という理解が正確です。

ファイル一覧の取得でエラーになるのはなぜですか？

ルールのバージョンが原因である場合がほとんどです。公式は、List APIを使うプロジェクトにはバージョン2が必要だと明記しており、1のままだと一覧表示が拒否されます。ルールファイルの先頭でrules_versionを2に指定し、デプロイし直してください。対象パスのread権限も併せて確認します。

アップロードできるファイルサイズの上限はどこで決めますか？

セキュリティルール側で決めます。公式のサンプルは、書き込み条件にrequest.resource.sizeを使い、バイト単位で上限を課す書き方です。5MBなら5×1024×1024と表現します。クライアント側の検証だけでは改変されたリクエストを止められません。上限はルールで担保し、クライアント側は即時フィードバック用と位置づけてください。

アップロード後に自動でサムネイルを作ることはできますか？

可能です。書き込み完了をトリガーに関数を起動し、生成したサムネイルを別パスへ書き戻す構成が一般的です。注意点は二つ。生成物を同じ監視対象パスへ書くと関数が再帰的に起動すること、変換のたびにストレージ操作回数が加算されることです。出力先を分け、操作回数の月額を先に見積もってください。

関連記事

• Cloud Storage（GCS）とは？ストレージクラスとS3との違い：保存先の実体であるGCS側の料金体系と保存期間設計を扱っています。
• Firebaseの料金｜無料枠とBlaze超過単価の実額：プロジェクト横断の単価と予算設計の参照先です。
• Firebaseの導入手順｜プロジェクト作成から初回デプロイまで：Blazeプラン移行を含む初期構築の流れです。
• Firebase CLIとは｜認証とデプロイ運用：ルールのデプロイとエミュレータ起動を担うコマンド側の解説です。
• Firebase Local Emulator Suiteとは｜ローカル再現とCI組み込み：ルールのテストを課金なしで回す環境構築です。