Cloud Functions for Firebaseとは｜トリガー設計と第2世代の実装判断【2026年8月時点】

Cloud Functions for Firebaseは、Firestoreのドキュメント更新やCloud Storageへのファイル到着といったFirebase側のイベントを直接受け取り、サーバーを持たずに処理だけを走らせる実行環境です。Google Cloud側のCloud Run functionsと基盤を共有しながら、Realtime DatabaseやAuthenticationのトリガー、コードの中で構成を指定するFirebase SDKといった独自の入口を備えています。本記事では、第2世代がCloud RunとEventarcの上に載る構造、Blazeプランが必須になる課金の前提、トリガー種別ごとの関数設計、コールドスタートと無限ループ課金への対処までを実装者の判断材料として整理します。

まとめ：Firebaseトリガー前提で組む関数設計の判断軸

結論から示します。Cloud Functions for Firebaseの本体は、firebase-functions SDKで書いてFirebase CLIからデプロイする関数であり、第2世代の実行基盤はCloud RunとEventarcです。Google Cloud側から同じ土台を使うCloud Run functionsとの差は、基盤の性能ではなくFirebaseのイベントを直接受け取れる入口の有無にあります。

設計で最初に決めるのはトリガー種別です。Firestoreのドキュメント変更、Authenticationのユーザー作成、Cloud Storageのファイル到着、定期実行、クライアントからの直接呼び出しのどれを起点にするかで、渡ってくるデータも失敗時の振る舞いも変わります。費用面の前提も明確で、無料のSparkプランでは関数をデプロイできません。

従量課金のBlazeプランが必須になる一方、呼び出しは月200万回まで無料枠に収まります（2026年8月時点の公式料金ページ）。警戒すべきは単価ではなく、Firestoreトリガーの自己書き込みが引き起こす無限ループのほう。採用の可否は、処理が数分以内で終わりイベント起点であるかどうかで判断できます。

Firebase側の関数とGoogle Cloud側の関数を分ける提供経路と基盤

Firebase SDKで書く関数とGoogle Cloud側の関数の対象読者の差

公式の「Cloud Run functions と Firebase」は、Cloud Functions for FirebaseをFirebaseでアプリを作るモバイル開発者向け、Cloud Run functionsをGoogle Cloudのサービス間をイベントで接続する開発者向けと位置づけています。Firebase版だけが持つのは、Firebase Realtime Database、Firebase Authentication、Firebase向けGoogleアナリティクスのトリガーです。トリガー元になるデータベース側の構造と課金はFirebase Realtime DatabaseのJSONツリー同期と転送量課金で整理しています。

開発体験の側にも差があります。Firebase版はコードの中で関数の構成を書けるSDKを備え、Firebase コンソールとFirebase CLIから扱えます。支払い処理やSMS送信のように端末側へ置けない処理、モバイル端末に載せるには重すぎるカスタムロジックの受け皿として案内されているのがこの形です。Google Cloud側から見た仕組み・料金体系・AWS LambdaやGKEとの比較はGoogle Cloud Functionsとは？仕組み・料金とCloud Run functionsへの改称にまとめています。

第2世代がCloud RunとEventarcの上に載る構造と影響

第2世代の関数は、Cloud Buildでビルドされ、Cloud Runのサービスとしてデプロイされます。イベントの配送はEventarcが受け持ち、90以上のイベントソースと業界標準のCloudEvents形式に対応しました。つまり「関数を書いている」つもりでも、動いている実体はCloud Runのリビジョンです。

この構造は運用に直結します。Cloud Runのサービスとして扱えるため、CPUやメモリ、同時実行数といった設定はCloud Run側の流儀で調整でき、リビジョン間のトラフィック管理も利用可能。コンテナ側の判断材料はCloud Runとは？サーバーレスコンテナの仕組みと違いで確認できます。

Sparkプランでは動かせないBlaze必須の課金前提と無料枠

公式の「使ってみる」は、関数をデプロイするにはプロジェクトがBlazeのお支払いプランを利用している必要があると明記しています。無料のSparkプランでは関数の行が「適用なし」で、デプロイそのものができません。一方でローカルのエミュレータはSparkのままでも動くため、検証だけなら課金を有効にせず進められます。

数値は2026年8月時点の公式料金ページの記載です。小規模な裏側処理なら無料枠に収まる水準ですが、Blazeへ切り替えた瞬間にFirestoreやCloud Storageの従量課金も同時に走り出す点は押さえておきたいところ。プロダクト横断の単価と予算アラートの設定はFirebaseの料金｜無料枠とBlaze超過単価の実額で整理しています。

Firestore・Auth・Storageのトリガー種別ごとの関数設計

Firestoreトリガー4種の使い分けと無変更書き込みの扱い

Firestoreのトリガーは、作成時のonDocumentCreated、更新時のonDocumentUpdated、削除時のonDocumentDeleted、そのすべてを拾うonDocumentWrittenの4種です。ドキュメントのパスにはワイルドカードを置けるので、コレクション配下の全ドキュメントを1つの関数で受けられます。

設計上の勘所は、まとめて拾えるonDocumentWrittenに寄せすぎないこと。作成・更新・削除で処理が分かれるなら、種別ごとに関数を分けたほうが分岐が浅くなり、再デプロイの影響範囲も狭くできます。もう一つ覚えておきたいのは、データが変わらない書き込みではイベントが発生しないという公式の挙動です。同じ値で上書きしても関数は起動しないため、この性質は後述するループ対策にも効いてきます。

Authenticationのブロッキング関数と7秒応答制限

ユーザー作成やサインインの直前に割り込むブロッキング関数は、招待コードの検証や社内ドメイン以外の登録拒否といった用途に向きます。利用にはプロジェクトをFirebase Authentication with Identity Platformへアップグレードする必要があり、通常のトリガーより前提が重くなります。

制約はさらに厳しめです。公式は、関数が7秒以内に応答しなければFirebase Authenticationがエラーを返し、クライアント側の操作が失敗すると明記しています。200以外のHTTPレスポンスコードはそのままクライアントアプリへ渡り、匿名認証とカスタム認証ではブロッキング関数は発火しません。ここから導かれる判断は一つ。応答時間の読めない外部APIへの問い合わせをブロッキング関数の中に置くのは避け、登録後の非同期処理へ回すべきです。

Cloud Storageトリガーでの画像変換と再帰起動の防ぎ方

アップロードされた画像のサムネイル生成は、Cloud Storageトリガーの代表的な使い道です。ファイルの到着を検知して関数が起動し、変換した画像を書き戻します。この「書き戻し」に落とし穴があります。

変換結果を同じバケットの同じ階層へ置くと、その書き込みが再びトリガーとなり、変換と書き込みを延々と繰り返す構造ができてしまう。もっとも確実な回避策は出力先バケットを分けることです。同一バケットで済ませたい場合は、出力ファイル名に固定の接頭辞を付けて関数の冒頭で除外するか、メタデータの処理済みフラグで判定します。発火元となるバケット側の権限設計と操作回数の課金はCloud Storage for Firebaseのルール設計と課金の数え方で整理しています。

定期実行のスケジュール関数とCallable関数の使い分けの基準

イベント起点ではない処理も2種類の入口で書けます。日次集計のような定期実行はスケジュール関数で、内部的にはCloud SchedulerとPub/Subを介して呼び出される仕組み。もう一方のCallable関数は、クライアントSDKから関数名を指定して直接呼ぶ形式です。

Callableを選ぶ判断基準は認証情報の扱いにあります。呼び出したユーザーのFirebase Authenticationの認証情報が関数側のコンテキストへ自動で渡るため、トークン検証のコードを自分で書かずに済みます。Firebaseの外から叩かれるWebhookの入口が必要なら、素のHTTP関数を選び、認証と入力検証を関数側で実装してください。なお不正クライアントを弾く仕組みが保護できるのはCallable関数までで、その範囲はFirebase App Checkのプロバイダ選定と強制移行の解説で扱っています。

Cloud Functions第1世代と第2世代の上限差から決める世代選択

最大実行時間9分と60分の差およびメモリと同時実行数の上限拡張

公式のバージョン比較が示す差は、実行の器の大きさに集約されます。

注意したいのは、60分まで伸びるのがHTTP関数に限られる点です。Firestoreトリガーのようなイベント駆動の関数は第2世代でも9分のままなので、重いバッチをイベント起点で完結させる設計は世代を上げても成立しません。同時リクエスト数が1から最大1,000へ広がった影響は次章のコールドスタート対策に直結します。

第2世代で外れるAnalyticsイベントと代替経路の組み方

第2世代は上位互換ではありません。公式は第2世代についてAnalyticsイベントがサポートされていないと明記しており、Firebase向けGoogleアナリティクスのコンバージョンイベントで関数を起動する構成は第1世代でしか組めません。代わりに第2世代では、認証ブロッキングイベントと90以上のEventarcイベントソースが使えます。

アナリティクスのイベントを起点にしたい場合の現実解は2つ。その関数だけ第1世代で残すか、BigQueryへのエクスポート経由でスケジュール関数から拾う形へ組み替えるかです。公式は第1世代のサポートを今後も継続する予定と述べており、世代は関数単位で選べるため、前者でも当面の運用は成り立ちます。

firebase-functions v1からv2へ移すときの記法差と手順

SDKの側では、v1系とv2系で関数の書き方が変わりました。v1がトリガー種別をメソッドチェーンで積み上げる形だったのに対し、v2ではイベントごとに専用の関数をインポートする形になっています。npm registryで確認したところ、firebase-functionsの最新は7.3.2系です（2026年8月時点）。

ランタイムの前提も更新されています。公式の「使ってみる」は、Cloud FunctionsとFirebase CLIがNode.js 20と22を完全にサポートし、バージョン18は2025年初期に非推奨になったと記載しています。移行はv1とv2の関数を別名で併存させ、新しい名前で動作を確認してから呼び出し元を切り替え、最後に旧関数を削除する順が安全。同じ関数名のまま世代だけを差し替える手順は避け、名前の付け替えを前提に計画を立てます。

コールドスタートと無限ループ課金を抑える関数の実装と運用設計

運用で効いてくるのは、初回起動の待ち時間と、意図しない再実行による課金の膨らみです。公式の「関数を記述するためのヒント」に沿って打ち手を整理します。

最小インスタンス数と同時実行数の併用で削る初回起動の待ち時間

コールドスタートは、実行環境がゼロから初期化されることで生じます。公式が挙げる対策の一つが最小インスタンス数の設定で、待機中のインスタンスを確保しておけば初回の初期化を待たずに応答できます。ただし待機インスタンスはアイドル中も課金対象になるため、常時1台を確保するかどうかは費用との引き換えです。

もう一つの打ち手が同時実行数の引き上げです。公式は、同時実行数を増やすと1つのインスタンスで複数のリクエストを受けられるようになり、コールドスタートの発生数そのものが減ると説明しています。実務では、ユーザーが応答を待つCallable関数やHTTP関数にだけ最小インスタンスを設定し、非同期のイベント関数は同時実行数の引き上げだけで済ませる配分が費用対効果に見合います。

実装側の打ち手も併せて効きます。公式はグローバルスコープで宣言した変数の値を後続の呼び出しで再利用できるとしており、データベース接続やAPIクライアントはグローバルに置いて使い回すのが基本形。一方でモジュールの読み込みは最小限に抑えるべきとも書かれているため、特定の分岐でしか使わない重いライブラリはその分岐に入ってから読み込みます。

再試行を前提にしたべき等な処理設計とイベントIDでの重複排除

イベント駆動の関数は、少なくとも1回の配送が保証される代わりに、同じイベントで2回起動することがあります。公式も、関数は何回呼び出されても結果が同じになる必要があり、前の呼び出しがコードの途中で失敗した場合は呼び出しを再試行できると明記しています。

べき等にする定石は、イベントに付与されるIDを記録して二重実行を弾く方法です。処理の冒頭でイベントIDをFirestoreの専用コレクションへ書き込み、すでに存在すれば何もせずに終了する。決済の確定やメール送信のように取り消しの効かない処理では、この一手間を省かないでください。逆に、集計値を毎回上書きするような処理はもともとべき等なので、重複排除の仕組みを足す必要はありません。

Firestoreの自己書き込みが無限ループを招く課金事故の回避

Firebaseの関数で起きる事故として頻度が高いのが、書き込み対象と監視対象が重なる構成です。onDocumentWrittenで受けたドキュメントに関数が更新をかけると、その更新が再びトリガーとなって関数が起動し、呼び出し回数と読み書き回数の両方が膨れ上がります。

回避の順序は決まっています。第一に、書き込み先を別コレクションへ逃がす。同じドキュメントを更新せざるを得ないなら、第二に更新前後の値を比較し、変化がなければ処理せずに終える形にします。データが変わらない書き込みはイベントを生成しないため、この比較が停止条件として働きます。第三の保険が関数ごとの最大インスタンス数の設定で、暴走しても並列数の上限までしか課金は伸びません。Google Cloud側の予算アラートも併せて設定しておきます。

Cloud Functions for Firebaseを採用すべき条件と見送る場面

ここは条件を付けて言い切ります。判断の軸は処理の起点、1回あたりの実行時間、常時稼働の要否の3点です。

Firebaseアプリの裏側処理として採用してよい3つの条件

次の3つが揃うなら、Cloud Functions for Firebaseが第一候補になります。処理の起点がFirebaseのイベントかクライアントからの直接呼び出しであること。1回の処理が数分以内で完結すること。常時起動のプロセスやWebSocketのような持続接続を必要としないこと。

典型例は、ユーザー登録直後のプロフィール初期化、投稿の作成をきっかけにしたプッシュ通知の送信、アップロード画像のサムネイル生成、日次の集計バッチ。いずれもイベントが起点で、処理は短く、待機コストを持ちません。こうした構成をどこまで関数で持ち、どこからマネージドサービスへ寄せるかの線引きは案件ごとに変わります。設計と運用まで含めて相談したい場合は、インフラ構築（AWS・Google Cloud・Azure）のようにクラウド横断で支援できる体制と組むと、世代選定や移行方針まで一度に決められます。

Cloud Runへ寄せるべき常時接続と長時間処理の見極め方

見送るべき場面も明確です。イベント関数の9分上限を超える処理、常時接続を保ち続けるサービス、独自のミドルウェアやフレームワークを丸ごと載せたいケース、そしてコールドスタートによる初回の待ちを一切許容できない低遅延の同期APIは、コンテナ単位のCloud Runへ寄せるほうが素直に収まります。

判断に迷いやすいのが「たまに重い」処理です。この場合は関数を入口だけに使い、重い本処理はCloud RunやジョブへPub/Sub経由で渡す役割分担が現実解になります。第2世代の基盤がCloud Runである以上、後からの載せ替えは同一プラットフォーム内の移動で済むため、初期段階で関数から始める判断は撤退が効きます。関数実行モデルそのものの制約はFaaSとは？実行時間やコールドスタートの制約と採用判断もあわせて確認してください。

Local Emulator SuiteとCIで固める関数の検証と配信手順

関数の検証は本番デプロイの前にローカルで完結させます。Local Emulator SuiteはFunctions・Firestore・Authenticationなどを手元で再現でき、デプロイと違ってSparkプランのままでも起動可能。トリガーの発火条件やドキュメントパスの指定ミスは、この段階でほぼ潰せます。

配信の流れは、エミュレータ上でのテスト実行、対象関数を絞ったデプロイ、ログでの起動確認という3段です。CIではエミュレータを立ち上げてテストを走らせるコマンドを組み込み、成功した場合だけデプロイへ進む形にします。エミュレータ側で再現されない挙動もあるため、構成と非再現範囲はFirebase Local Emulator Suiteとは｜ローカル再現の構成とCI組み込みで押さえておくと、本番との差分に足をすくわれません。

よくある質問

Cloud Functions for Firebaseの導入検討でよく挙がる論点をまとめました。

Cloud Functions for FirebaseとCloud Run functionsは別のサービスですか？

基盤は同じで、入口が違うと捉えるのが正確です。第2世代の関数はどちらもCloud RunとEventarcの上で動きます。Firebase版だけがRealtime Database・Authentication・Firebase向けGoogleアナリティクスのトリガーを持ち、コードで構成を書くFirebase SDKとFirebase CLIから扱えます。Google Cloud側のサービス連携が主目的ならCloud Run functionsとして扱っても構いません。

無料のSparkプランのままで関数を使えますか？

デプロイはできません。公式は、関数をデプロイするにはプロジェクトがBlazeのお支払いプランを利用している必要があると明記しています。ただしLocal Emulator Suiteでのローカル実行はSparkのままでも可能なので、学習や試作の段階では課金を有効にせず進められます。Blazeへ切り替えても呼び出しは月200万回まで無料枠に収まります（2026年8月時点）。

第1世代のまま使い続けても問題ありませんか？

当面は問題ありません。公式のバージョン比較には、今後もCloud Functions（第1世代）のサポートを継続する予定と記載されています。ただし新しい関数には第2世代が推奨されているため、既存関数は第1世代のまま維持し、新規追加分から第2世代で書く進め方が無理のない移行になります。Analyticsイベントのトリガーだけは第2世代で使えない点に注意してください。

コールドスタートはどの程度気にすべきですか？

用途で切り分けます。Firestoreトリガーやスケジュール実行のような非同期処理では初回の一拍が問題になることはほとんどありません。ユーザーが応答を待つCallable関数やHTTP関数では体感に響くため、最小インスタンス数の設定と同時実行数の引き上げを検討してください。

Firestoreトリガーの関数が二重に実行されることはありますか？

あります。イベント駆動の関数は再試行される前提で設計する必要があり、公式も何回呼び出されても結果が同じになることを求めています。決済確定や通知送信のように取り消せない処理では、イベントIDを記録して処理済みなら早期に終了する重複排除を実装してください。集計値の上書きのように、もともとべき等な処理では追加の対策は不要です。

関連記事

• Google Cloud Functionsとは？仕組み・料金とCloud Run functionsへの改称・採用判断：Google Cloud側から見た同じ基盤の総論と、AWS LambdaやGKEとの比較です。
• Firebaseの導入手順｜プロジェクト作成からSDK導入と初回デプロイまで：関数を書く前提となるプロジェクト作成とCLIの初期化を扱っています。
• Firebase CLIとは｜firebase-tools 15系の認証とデプロイ運用：関数のデプロイに使うCLIの認証方式とコマンド運用です。
• Firebase Authenticationとは？認証方式・導入手順・料金：ブロッキング関数が割り込む認証側の設定と料金を確認できます。
• FCM（Firebase Cloud Messaging）とは｜プッシュ通知の仕組みと使い方：関数から通知を送る際の送信側の仕組みです。