Firexport / ブログ

2026 年 9 月 1 日から、Firebase Remote Config の料金は、アプリが構成をフェッチする頻度で決まるようになりました。1 日の最初の 100,000 回（10 万回）のフェッチは、どのプランでも無料です。それを超えると、Blaze プロジェクトはフェッチごとに課金され、Spark プロジェクトはいずれスロットリングされます。ほとんどのアプリは無料枠に収まります。自分のアプリが収まるかどうかは、ユーザー数よりも、コードの中の 1 つの設定、つまり最小フェッチ間隔で決まります。

料金

• 100,000 回はプロジェクトごとです。同じプロジェクトの Android アプリ、iOS アプリ、ウェブサイトは、この 100,000 回を共有します。
• 1 日ごとでもあり、フェッチの少ない日が多い日の埋め合わせをすることはありません。1 日に 1,000,000 回のフェッチがあったリリース日は、月のほかの日が 100,000 回を下回っていても $5.40 かかります。
• コードも SDK のバージョンも変える必要はありません。Firebase 側でフェッチを計測します。どちらのプランでも同じです。

新しい料金がプロジェクトに適用される時期

2026 年 9 月 1 日より前に Remote Config を有効にしたプロジェクトには、まず移行期間があります。どの期間になるかは、プロジェクトのプランによります:

11 月 15 日から 12 月 1 日のあいだにアップグレードした Spark プロジェクトがどうなるかは、料金ページに書かれていません。そうするつもりなら、12 月 1 日から課金されるものと考えてください。

11 月 15 日より前にアップグレードすべきか

• プロジェクトのフェッチが 1 日 100,000 回未満なら、その必要はありません。Spark はこれまでどおり使えますし、Blaze も同じです。
• それより多い、または近いなら、11 月 15 日より前にアップグレードすると、何かが課金される前にフェッチを減らすための期間が 2 か月（12 月と 1 月）できます。Spark での代わりはスロットリングで、ほとんどのアプリにとっては数ドルを払うより悪い結果です。
• Blaze ではプロジェクトが Cloud Billing アカウントにリンクされ、支出の上限はありません。ほかのプロダクトの無料枠はそのまま残り、支払うのはそれを超えた分だけです。アップグレードするときに予算アラートを設定しましょう（後述）。

Spark でスロットリングされると何が起きるか

Spark プロジェクトのフェッチが初めて 1 日 100,000 回を超えた日に、30 日間の猶予期間が始まります。その間、フェッチはすべてこれまでどおり処理されます。途中で使用量が無料枠を下回っても、カウントダウンは一時停止もリセットもされません。31 日目からは、毎日 100,000 回目より後のフェッチが拒否されます。アプリは動き続けますが、フェッチを拒否された端末は、すでに持っている値か、アプリ内のデフォルト値のままになります。ロールアウトも A/B テストもキルスイッチも、その端末には届きません。使用量が上限に近づくと、プロジェクトの管理者にメールが届き、コンソールにバナーが表示されます。受信トレイに警告が届いたら、それが確認するタイミングです。

フェッチ数を数える

フェッチとは、Remote Config サーバーに届くリクエストのことです:

ほかの Firebase プロダクトが内部で行う呼び出しもカウントされません。プロジェクトのフェッチ数は、次の場所で確認できます:

• Firebase コンソール: 使用量と請求額（Usage and billing）の Remote Config セクション。Spark では、割り当ての進捗状況カードに、100,000 回に対するその日のフェッチ数が表示されます。Blaze では、棒グラフが各日のフェッチ数を料金階層ごとに分けて表示します。
• Google Cloud コンソール: IAM と管理（IAM & Admin） > 割り当てとシステム上限（Quotas & System Limits）を開き、firebaseremoteconfig.googleapis.com で絞り込みます。どちらのプランでも使えます。Blaze では、Cloud Billing のレポートで、料金が SKU Fetch Requests に計上されます。2026 年 9 月 1 日以降に作成されたプロジェクトは 37B1-4623-6F54、それより前のプロジェクトは 598C-0184-404A です。

次に、普段の 1 日のフェッチ数を、Analytics でのその日のアクティブ ユーザー数で割ります。デフォルトの 12 時間の間隔でリアルタイム リスナーがなければ、1 台の端末がフェッチできるのは 1 日に 2 回ほどまでなので、結果は 2 以下になります。複数の端末にアプリを入れているユーザーや、複数のブラウザからウェブサイトにアクセスするユーザーが多ければ、少し多くなります。2 を大きく超えるなら、コードのどこかが間隔を飛ばしています。どこを見ればよいかは余分なフェッチのセクションで説明しています。

アプリが支払う金額

1 日のフェッチ数は、1 日のアクティブ ユーザー数に、ユーザー 1 人あたりの 1 日のフェッチ数を掛けたものです。自分の数字か、リリース後に見込む数字を入れてください:

いくつかの規模での例です（Blaze、同じ日が 30 日続く月の場合）:

1 日のユーザーが 1,000,000 人なら、1 人あたりのフェッチを 10 回から 2 回に減らすと、月に約 $1,440 節約できます。逆に見ると、無料の 100,000 回に収まる 1 日のユーザー数は次のとおりです:

余分なフェッチの原因と減らし方

どのフェッチ メソッドも、最初に最小フェッチ間隔を確認します。間隔内であれば、SDK はすでに持っている値を返し、リクエストは送られません。そのため、アプリのフェッチ数は、この間隔の設定と、間隔を迂回する少数の要因で決まります。まず、コードの中でこの間隔を設定している箇所と、飛ばしている箇所をすべて見つけましょう:

grep -rniE "minimumfetchinterval|fetch\(0|expirationduration|timespan\.zero" \
  --exclude-dir={node_modules,build,Pods,.dart_tool,.gradle} .

1. 本番環境に残った短いフェッチ間隔

デフォルトは、Android、Apple プラットフォーム、ウェブ、Flutter のいずれでも 12 時間です。それより短い値は、開発用の設定やサンプルから入り込みます。Firebase 自身の Flutter のスタートガイドのコードは「頻繁に更新できるように」1 時間に設定しており、多くのチュートリアルがそれを写しています。そのままリリースすると、1 時間の間隔では、前回のフェッチから 1 時間以上たって始まるセッションごとに各端末が 1 回フェッチでき、最大で 1 日 24 回になります。短い値はデバッグ ビルドだけにとどめましょう:

// Android (Kotlin). On AGP 8+, BuildConfig.DEBUG needs
// buildFeatures { buildConfig = true } in build.gradle.
Firebase.remoteConfig.setConfigSettingsAsync(
    remoteConfigSettings {
        // 12 hours in release builds
        minimumFetchIntervalInSeconds = if (BuildConfig.DEBUG) 60 else 43200
    }
)

// iOS (Swift)
let settings = RemoteConfigSettings()
#if DEBUG
settings.minimumFetchInterval = 60
#else
settings.minimumFetchInterval = 43200 // 12 hours
#endif
RemoteConfig.remoteConfig().configSettings = settings

// Flutter. kDebugMode is in package:flutter/foundation.dart.
await FirebaseRemoteConfig.instance.setConfigSettings(RemoteConfigSettings(
  fetchTimeout: const Duration(minutes: 1),
  minimumFetchInterval:
      kDebugMode ? const Duration(minutes: 1) : const Duration(hours: 12),
));

// Web. 12 hours is the default, so deleting the line does the same.
const remoteConfig = getRemoteConfig(app);
remoteConfig.settings.minimumFetchIntervalMillis = 12 * 60 * 60 * 1000;

めったに変わらない値については、Firebase はさらに長い 24 時間や 48 時間を勧めています。変更をすばやくユーザーに届けるために間隔を短くしていたのなら、リアルタイム更新（4）を使えば、セッションごとに 1 回ではなく、変更ごとに 1 回のフェッチで同じことができます。

2. 「Remote Config が更新されない」の対処で入れた fetch(0)

「新しい値が反映されない」という質問によくある回答が、フェッチの呼び出しに 0 の間隔を渡すことです。Android と Apple プラットフォームでは、この引数が設定より優先されるので、間隔をどう設定していても、呼び出しは毎回サーバーに届きます:

// Each of these ignores the interval and goes to the server on every call:
remoteConfig.fetch(0)                                // Android
remoteConfig.fetch(withExpirationDuration: 0)        // iOS
remoteConfig.FetchAsync(TimeSpan.Zero)               // Unity

引数を削除して、設定した間隔を適用させましょう。それでもユーザーに見える値は 12 時間以内に更新され、リアルタイム リスナーがあればすぐに更新されます。

3. 画面ごと、再開ごと、バックグラウンドでの起動ごとのフェッチ

各画面の初期化、onResume のたび、コンポーネントのマウントのたびに行うフェッチや、プッシュ メッセージやバックグラウンド ジョブがアプリを起動したときにも実行される Application.onCreate でのフェッチは、間隔が許す範囲のフェッチを何倍にも増やします。12 時間の間隔なら、そうした呼び出しのほとんどは端末上で応答されるので、増える分はわずかです。短い間隔や fetch(0) と組み合わさると、ここが大量のフェッチの原因になります。フェッチはアプリがフォアグラウンドで起動したときに 1 回だけ行い、ほかの場所ではゲッターで値を読み取りましょう。Firebase はバックグラウンドでのフェッチを「ゴースト フェッチ」と呼び、最初に監査すべきものの 1 つに挙げています。

4. リアルタイム更新と頻繁な公開

リアルタイム リスナーは、アプリがフォアグラウンドにある間、接続を開いたままにします。この接続は無料です。新しいテンプレート バージョンを公開すると、リッスンしているすべての端末がそれをダウンロードし、そのダウンロードはそれぞれ、間隔を無視するフェッチになります。古いバージョンを持ったまま後でアプリを開いた端末も、同じようにダウンロードします。そのため、公開するたびに、変更の内容にかかわらず、次の公開までにアプリを実行する端末 1 台につき最大 1 回のフェッチがかかります。

端末 200,000 台（20 万台）で 1 日に 10 回公開すると、リアルタイムだけで最大 2,000,000 回（200 万回）のフェッチになり、10,000 回あたり $0.06 で、その日は約 $12 です。小さな公開を何度も行うのではなく、編集をまとめて 1 回で公開し、リスナーはキルスイッチのように即座の変更が重要な場所にだけ追加しましょう。

5. サーバーへのリクエストごとのテンプレートの読み込み

まだプレビュー版のサーバーサイド Remote Config は、Admin SDK でテンプレート全体をダウンロードし、そのダウンロードはそれぞれがフェッチです。Cloud Functions の関数や Cloud Run のハンドラの中で getServerTemplate() を呼び出すと、リクエストごとに 1 回フェッチすることになり、アクセスの多いエンドポイント 1 つだけで 1 日 100,000 回を超えることがあります。サーバー インスタンスごとに 1 回読み込み、タイマーで更新しましょう:

import { initializeApp } from "firebase-admin/app";
import { getRemoteConfig } from "firebase-admin/remote-config";

initializeApp();

const DEFAULTS = { welcome_message: "Hello" };
// At most one fetch per server instance every 10 minutes.
const REFRESH_MS = 10 * 60 * 1000;

let templatePromise; // one template per server instance, kept between requests
let loadedAt = 0;

export async function getConfig() {
  if (!templatePromise) {
    loadedAt = Date.now();
    templatePromise = getRemoteConfig()
      .getServerTemplate({ defaultConfig: DEFAULTS })
      .catch((err) => {
        templatePromise = undefined; // try again on the next request
        throw err;
      });
  }

  const template = await templatePromise;

  if (Date.now() - loadedAt > REFRESH_MS) {
    loadedAt = Date.now();
    // Refreshes in the background. Until it lands, requests get the
    // values already loaded.
    template.load().catch((err) => console.error("Refresh failed", err));
  }

  return template.evaluate();
}

10 分ごとの更新は、トラフィックにかかわらず、実行中のインスタンス 1 つにつき 1 日 144 回のフェッチです。REST API でテンプレートを読み取るスクリプトや CI ジョブもカウントされますが、問題になるほどの回数になることはまれです。

Blaze に移行したら予算アラートを設定する

Blaze には厳密な上限がありません。Google Cloud コンソールでお支払い（Billing） > 予算とアラート（Budgets & alerts）を開き、上の計算ツールで出た金額に近い額で、プロジェクトの予算を作成します。デフォルトでは、金額の 50%、90%、100% で請求先アカウントの管理者にメールが送られます。支出は止まらないので、最初のメールが届いたら、使用量と請求額（Usage and billing）ページの Remote Config のグラフを確認する合図と考えてください。

よくある質問

Firebase Remote Config は今も無料で使えますか？

プロジェクトあたり 1 日 100,000 回のフェッチまでは、Spark でも Blaze でも無料です。端末上での値の読み取り、A/B Testing、ロールアウト、パーソナライズに追加料金はかかりません。1 日 100,000 回を超えると、Blaze プロジェクトは 10,000 回あたり $0.06 を支払い、Spark プロジェクトは 30 日間の猶予期間のあとスロットリングされます。

既存のプロジェクトでは、Remote Config の課金はいつから始まりますか？

Blaze のプロジェクトは 2027 年 2 月 1 日からです。Spark のプロジェクトは課金されません。2026 年 12 月 1 日から 100,000 回の上限が適用されます。ただし、2026 年 11 月 15 日より前に Blaze にアップグレードした場合は、2027 年 2 月 1 日から課金が始まります。

100,000 回の上限はアプリごとですか、プロジェクトごとですか？

プロジェクトごとです。Firebase プロジェクトに登録されたすべてのアプリで共有します。

コードの変更や SDK のアップデートは必要ですか？

いいえ。計測は Firebase のサーバーで行われ、Spark と Blaze の切り替えにもアプリの変更は必要ありません。コードの変更が意味を持つのは、フェッチを減らしたい場合だけです。

リアルタイム Remote Config を使うと料金は高くなりますか？

開いている接続はカウントされません。カウントされるのは、公開後に新しいテンプレート バージョンをダウンロードするたびで、端末ごとに 1 回、最小フェッチ間隔を無視して発生します。

Remote Config の新しい値がユーザーに反映されないのはなぜですか？

たいていは最小フェッチ間隔が原因です。デフォルトでは端末は値を最大 12 時間保持し、フェッチした値は activate() のあとでしか適用されません。新しい料金体系になってからは、1 日 100,000 回を超えるようになって 30 日を過ぎた Spark プロジェクトは、スロットリングされることもあります。間隔を短くする前に、使用量と請求額（Usage and billing）の Remote Config セクションを確認してください。間隔を短くすると、スロットリングが悪化します。

出典

• Remote Config の料金: 料金、移行の日程、フェッチとしてカウントされるもの、使用量の確認場所
• Remote Config のスロットリングと読み込み方法: デフォルトの 12 時間と、それより優先されるもの
• リアルタイム Remote Config: 更新がダウンロードされる仕組み
• サーバーサイド Remote Config
• Cloud Billing の予算とアラート