【保存版】Firebase/Cloud functionsの注意点。課金を0にし無料で使う方法(cloud strage、Cloud Build、Artifact Registry、Cloud Runの使用が発生。究極はエミュレーター)

Firebase Cloud Functionsを導入したものの、「いつの間にか課金が発生していた」なんてことはありませんか？

Cloud FunctionsはCloud Runを基盤としているため、便利な反面、Cloud BuildやStorageなど複数のサービスが連動し、無料枠の管理が非常に複雑です。

本記事では、「身に覚えのない課金」の正体を徹底解剖しています。

最小インスタンス数の設定やクリーンアップポリシーの自動化など、実質0円で運用するための鉄則。

この記事を読めば、高額請求に怯えることなく、プロ級のインフラを無料で維持することが可能になります。

Cloud Functionsの無料枠

Cloud functionsには無料枠があります。

無調枠はかなり寛大で、小規模プロジェクトや小規模利用なら無料の範囲内で十分に収まります

ただし、Cloud Functionsを使う際は、これらのリソース以外の隠れたコストが発生します。

それが、「Cloud Strage」「Cloud Build」「Artifact Registry」「Cloud Run」です。

【超重要】Cloud Functions実行時の動き

Cloud Functionsを実行すると、裏側で他のサービスも動きます。

主な流れは以下のようになっています。

この流れが非常に重要で、Cloud Functionsをデプロイすると複数のサービスを使用するため、場合によって隠れコストが発生しやすくなります。

Cloud Storage

Cloud Functionsをビルドすると、Cloud StorageにソースコードをZip形式でアップロードします。

Cloud Strorageとは何か？

Cloud Storage（GCS）は、Google Cloudが提供する「インターネット上の巨大なストレージ（保管場所）」です。

写真、動画、プログラム、ログなどのファイルを「オブジェクト」として保存します。容量は実質無制限でデータを追加できます。

「保存したデータの量」と「データの出し入れ（転送量）」に応じて料金が決まります。

Cloud Strageの課金対象

デプロイ時に発生する課金要素は主に3つです。

費用は月数円程度

ソースコード（Zip）は通常数MB〜数十MBです。

東京リージョンの単価（約 0.023ドル/GB/月）で計算すると、100MB保管しても月額 約0.3円程度です。

無料枠の注意点

Cloud Strageには5GBの無料枠がありますが、これには厳しいリージョン制限があります。

対象となるのは、us-east1, us-west1, us-central1のみ。

もし Functions を asia-northeast1（東京） などにデプロイしている場合、ソースコードが保存されるバケットも同じ東京リージョンに作成されます。

この場合、米国の無料枠（5GB）は適用されず、初めから課金対象となります。

古いソースコードの自動削除

課金を少しでも減らすためには、ビルド時に使って不要になったソースコードを削除する必要があります。

Cloudコンソールの「Cloud Storage > バケット」に進み、対象のバケットを選択して「ライフサイクル」をクリックします。

下の「ルール」に削除などのルールが表示されます。（基本的には、デフォルトでルールが追加されています。）

なお、デプロイが成功すると、古いソースコードは一定期間後に自動で削除される設定になっていることが多いですが、バケット自体は残ります。

Cloud Build

Cloud Buildとは？

Cloud StorageにソースコードをZip形式でアップロードを元に、Cloud Runで実行するためのコンテナイメージを作成するのがCloud Buildです。

Cloud Buildの無料枠

Cloud Buildは、1日２時間（120分）の無料があります。

これは「回数」ではなく「時間」です。1回のビルドに2分かかるなら、1日60回まで無料という計算になります。

無料枠は毎日リセットされます。ただし、未使用分を翌日に繰り越すことはできません。

ビルド時間2時間はかなり大きいので、課金が発生することはほとんどありません。

Artifact Registry

Cloud Buildで作成したコンテナイメージは、Artifact Registryに保存されます。

Cloud Run や Cloud Functions を使う上で避けて通れないサービスですが、Google Cloud の課金トラブルで最も多い原因の一つが、ここに古いイメージが溜まってしまうことです。

Artifact Registryとは何か？

コンテナイメージやプログラムのパッケージ（npmやPythonなど）の保管場所です。

Cloud Functions をデプロイすると、裏側で「ビルド（Cloud Build）」が行われ、完成した「コンテナ」がこの Artifact Registry に格納されます。

課金と無料枠

Artifact Registryの無料枠は毎月500MBあります。

500MBと聞くと多そうに見えますが、1つ1つのイメージは数百MBあることが多いため、無料枠内で保存できるイメージ数は数個程度です。

特に、Cloud Functions のデプロイを繰り返すと、新しいバージョンのイメージがどんどん追加されます数回デプロイしただけで無料枠（500MB）を使い切るのが一般的です。

オーバーすると、例えば、100MBのイメージ１つ保管で月額 約1.5円がかかります。

【重要】クリーンアップ ポリシーを設定する

Artifact Registry には、古いイメージを自動でゴミ箱に捨てる機能があります。これを使えば手動で消す手間がなくなります。

これを使うと「何秒後に削除する」や「最新の3世代だけ残して、それより古いものは削除する」といった設定ができます。

Google Cloud コンソールの [Artifact Registry] > [リポジトリ] > 対象のリポジトリを選択 > [編集] > [クリーンアップ ポリシー]へと進みます。

左メニューにない場合は、上部の検索窓で「Artifact Registry」と入力すればヒットします。

基本的にはCloud Functionsのデプロイ時に自動で設定されます。以下のように「86400s（＝1日）」後に自動削除となっています。

クリーンアップポリシーを変更する

作成されたイメージのサイズを見ると約100MBとなっています。１日に5回以上ビルドすると無料枠を超えてしまうので、1日後に削除から30分後に削除に変更し、最新2つのバージョンまで保持の条件にポリシーを変更します。

保持は、削除よりも優先されます。

それぞれのポリシーの詳細は以下です。

firebase.jsonでignoreの設定をする

Cloud Functions用のコードがたった数行でも、コンテナ自体はNode.jsなどの実行環境をまるごとイメージ化するので100MB程度になってしまいます。

コンテナイメージの容量を少しでも減らすには、functions.jasonのfunctionsのignoreで、node_modulesなどのイメージ作成に不要なファイルを除外設定することも大切です。

"functions": [
    {
      "source": "functions",
      "codebase": "default",
      "disallowLegacyRuntimeConfig": true,
      "ignore": [
        "node_modules",
        ".git",
        "firebase-debug.log",
        "firebase-debug.*.log",
        "*.local"
      ],
      "predeploy": [
        "npm --prefix \"$RESOURCE_DIR\" run build"
      ]
    }
  ]

Cloud Run

最終的に、Cloud Functionsに保存した関数を実行するときはCloud Runを使います。

Cloud Runは、Artifact Registryに保存されたコンテナイメージから実行環境を作成し、指定した関数を実行します。

Cloud Runとは何か？（コンテナ実行環境）

Cloud Runは、Dockerなどで作成したコンテナイメージを、クエストが来た時だけ自動で起動・実行してくれる、サーバーの構築なしで利用できるサービスです。

従量課金なので、アクセスがない時は料金が0円になります。逆にアクセスが急増した時は、自動で処理能力を増やして対応してくれます。

Cloud FunctionsはCloud Runで実行する

Cloud FunctionsはCloud Run上で実行されます。このため、実質的にはCloud Functions = Cloud Runとみることもできます。

ただし、それぞれのサービスとしての受け皿は異なります。Cloud Runにも無料枠が設定されているので、基本的には無料で使うことができます。

課金と無料枠

Cloud Runの無料枠は寛大で、個人開発や小規模な API なら、「ほぼ毎月 0円」 で運用できてしまうことが非常に多いです。

課金になりやすい注意点

無料枠が強力な一方で、以下のケースでは課金が発生します。

最小インスタンスが１以上の場合

コールドスタート（最初の起動が遅い現象）を避けるために「最小インスタンス数 = 1」などに設定すると、アクセスがなくても 24時間 365日分 の料金がかかります。

メモリ割り当てが大きい場合

メモリを 4GB や 8GB など贅沢に割り当てると、無料枠の「GB秒」を早く使い切ってしまいます。

【重要】無料で使うための原則

最小インスタンス数を「0」に固定する（※絶対条件）

Cloud Runには、アクセスがなくてもコンテナを1つ以上立ち上げっぱなしにする「最小インスタンス（min-instances）」という設定があります。

これを「1」以上にすると、24時間365日ずっと課金対象になり、数日で無料枠を使い切ります。

必ず 0 に設定することで、アクセスがない時間は完全にタダになります。

「並列実行数（Concurrency）」を適切に上げる

デフォルトでは、1つのコンテナは「80個」などのリクエストを同時に処理できるようになっています。

1つのコンテナ（1 vCPU / 512MB）が同時に10人のリクエストをさばけば、課金される「CPU秒」は1人分で済みます。

もし実行したい関数が「DBからデータを取ってきて返すだけ」のような軽い処理なら、並列実行数を高めに保つことで、1つ分のリソース料金で大量のリクエストを処理できます。

タイムアウト時間を短く設定する

万が一、プログラムが無限ループに陥ったり、外部APIの応答待ちでフリーズしたりした場合、タイムアウト設定が長いとその分だけ課金が続きます。

デフォルトの300秒（5分）などは長すぎます。通常のAPIなら 「10秒〜30秒」 程度に縮めることで、「異常な動作＝即停止」とし、無料枠の無駄遣いを防げます。

メモリを低めに設定する

メモリを何MBにするかを指定することができます。このときに、「念のためスペックを上げておこう」という考えは、無料運用では敵になります。

無料枠の比率は CPU 1 : メモリ 2 です。1 vCPU なら 2GB まで。0.5 vCPU なら 1GB まで。となっています。

関数の実行ログ（Cloud Logging）を確認し、実際に使われているメモリ量が100MB程度なら、デフォルトの「512MB」から「256MB」に下げます。メモリ設定を半分にすれば、無料で動かせる時間は「2倍」に増えます。

最大インスタンス数を制限する

Cloud Runはアクセスが多くなればなるほど、インスタンスを作成して同時にさばき切ろうとします。

ですが、インスタンスが多くなればなるほど消費量も大きくなるため、インスタンスが増えすぎないように、maxInstances: 10程度で制限しておくことも大切です。

無料枠を最大活用するためのコード

上記の設定は、プロジェクトのfunctions > index.tsの中で指定することができます。

具体的には以下のコードを記述します。

import { onRequest } from "firebase-functions/v2/https";

export const myApi = onRequest({
    // --- ここに無料で使うための設定を書く ---
    cpu: 1,                 // CPU数 (1または0.5など)
    memory: "256MiB",       // メモリ (256MiB, 512MiBなど最小限に)
    timeoutSeconds: 30,     // タイムアウト (短く設定)
    minInstances: 0,        // 最小インスタンス (必ず0に！)
    maxInstances: 10,       // 最大インスタンス (うっかり使いすぎ防止)
    concurrency: 80,        // 並列実行数 (1つのコンテナでさばく数)
}, (req, res) => {
    res.send("Hello from Firebase!");
});

課金アラートをセットする

Google Cloudで「うっかり課金」を防ぐための最善策は、「1円でも発生したら即座にメールで通知する」設定をしておくことです。

Google Cloud コンソールの「課金」メニューから簡単に設定できます。

「予算とアラート > 予算を作成」へと進みます。

わかりやすい名前（１円アラートなど）をつけて「次へ」をクリックします。

「指定額」で「1円」を入力します。

次にアラートで通知のタイミングを設定します。金額が1円の場合、0.5円などは設定できないので、100%のみ残します。

以上で設定は完了です。

Firebaseエミュレーターを使う

完全無料で使える

なお、課金が発生するのはGoogle Cloudを実際に使用した場合です。

このため、開発段階では「Firebase Emulator Suite（エミュレーター）」を使うことで、ローカル上に仮想のFirebase環境を構築し実行することができます。

このため、どなに使っても課金は発生せず０円となります。

Firebaseエミュレーターとは何か？完全無料・無課金で使い倒せる最強ツール(データ保存方法やnpm run devとの違い｜firebase emulators:start --import=./saved-data --export-on-exit)

Firebaseを導入したものの、「無料枠を超えて課金されないか不安」「本番データを汚さずにテストしたい」と悩んでいませんか？そんな開発者の救世主となるのがFirebaseエミュレーターです。これは自分のPC内に「仮想のFirebase環境...

prograshi.com

ローカル環境がGoogle Cloudを代替

Firebaseエミュレーターはあくまで、Firebaseの仮想実行環境を作成するもので、Google Cloudの仮想環境までは作りません。

ですが、ローカルの開発環境を使う場合は、そもそもGoogle Cloudの機能はローカル環境で代替できてしまいます。

エミュレーターを起動すると、パソコンの中に「偽の Google Cloud 実行環境」が作られます。

Node.jsの環境もあり、ソースコードもその場にあるので、わざわざ別環境にイメージを作ってコンテナを起動するといった面倒なことも不要です。

とても便利なのでどんどん活用することをお勧めします。