2026.08.27 開発

Firebase Remote Configとは｜条件配信と段階ロールアウトの実装と従量課金化【2026年8月時点】

Firebase Remote Config は、アプリを配り直さずに挙動と見た目を切り替えるための値配信サービスです。サーバー側でパラメータを書き換えると、端末が次にフェッチしたときにアプリ内の既定値を上書きします。導入自体は数十行で終わります。難しいのはその先で、いつ取りに行かせるか、誰に何を配るか、そして取りに行った回数がそのまま費用になる前提をどう設計へ織り込むか。2026年9月1日からフェッチ回数の従量課金が始まるため、この設計の重みは以前と変わりました。この記事では値の解決順、条件配信、フェッチ間隔とリアルタイム更新、段階ロールアウト、サーバーサイド版、そして新しい料金体系を、2026年8月時点の一次情報で扱います。

まとめ：フェッチ回数が費用になる前提から設計を逆算する

先に押さえるのは料金の切り替わりです。2026年9月1日から Remote Config はフェッチ要求を単位とする従量制へ移ります。無償枠は1日100,000フェッチ。既存プロジェクトには猶予があり、Spark プランが2026年12月1日、Blaze プランが2027年2月1日から通常の課金に入ります。設計を触るなら猶予のあるうちに。

次に決めるのがフェッチ間隔です。既定の12時間なら1端末あたり1日2回程度に収まり、無償枠は DAU 50,000 前後まで持ちます。開発中の癖で1時間に縮めたまま出荷すると1端末あたり1日12回になり、同じ枠が DAU 8,333 で埋まる。6分の1です。間隔の設定値は費用の設定値でもある、と読み替えておくと事故が減ります。

最後に配り方の使い分け。単に値を切り替えたいだけなら条件配信で足ります。障害の兆候を見ながら段階的に広げたいなら段階ロールアウト、指標の優劣で採否を決めたいなら A/Bテスト。この2つは合算24件という共通の枠を食い合うため、常時走らせる運用には向きません。

Remote Configが配るのは値であって分岐そのものではない

最初に線を引いておくと、Remote Config はコードを配信しません。配るのは文字列・数値・真偽値・JSON といったパラメータの値だけ。分岐そのものはアプリ側に実装済みである必要があります。Feature Toggle（フィーチャートグル、フィーチャーフラグ）とはで扱っている概念を、Firebase が製品として実装したものと捉えると位置づけがはっきりします。

アプリ更新なしで切り替えられるのは値であって処理の中身ではない

「アプリ更新なしで挙動を変えられる」という説明は正しいのですが、変えられる範囲は出荷済みバイナリに書かれた分岐の範囲内です。新しい画面を丸ごと後から降ろすことはできません。つまり切り替えたい可能性のある箇所は、リリース前にフラグ付きで両方の経路を実装しておく必要がある。

この前提は運用コストの形を変えます。分岐が増えるほどテスト対象の組み合わせが増え、古いフラグを消さない限り分岐は残り続ける。設計時に決めておきたいのは、そのフラグを「恒久的な設定値」として持つのか「数週間で消す一時的なスイッチ」として持つのかという区別です。後者を消す期限を決めずに入れると、半年後に誰も意味を説明できないパラメータが3,000件の上限へ向かって積み上がっていきます。

値の優先順位はフェッチ済みの値と端末内の既定値の2段で決まる

アプリが実際に読む値は3段階で解決されます。第1にフェッチして有効化した値、第2にアプリ内に埋め込んだ既定値、第3にどちらも無い場合の型ごとの静的な値。静的な値は int なら0、boolean なら false です。ここが落とし穴になりやすい箇所で、既定値の登録を忘れたパラメータは、通信が失敗した初回起動時に false として振る舞います。

フラグの真偽をどちら向きに設計するかは、この挙動から決めるのが安全です。通信が届かなかった端末に見せたい状態を false 側へ置く。新機能を出す方向のフラグなら「有効化するフラグ」として持たせると、既定値の抜けが安全側へ倒れます。Firebaseの導入手順の段階で既定値ファイルを先に用意しておくと、この抜けを構造的に防げるところ。

val config = Firebase.remoteConfig
config.setConfigSettingsAsync(
    remoteConfigSettings { minimumFetchIntervalInSeconds = 43200 }
)
config.setDefaultsAsync(R.xml.remote_config_defaults)
config.fetchAndActivate()

条件配信の設計は上から順の評価と最初の一致だけが効く前提で組む

パラメータには条件付きの値を複数ぶら下げられます。条件が1つも当たらなければ既定値、当たれば条件側の値。ここで効いてくるのが評価の順序です。

条件タイプは18種類ありAnalyticsのオーディエンスも条件に使える

指定できるルールタイプは、アプリ、アプリのバージョン、ビルド番号、プラットフォーム、OS、ブラウザ、デバイスカテゴリ、言語、国と地域、ユーザーオーディエンス、ユーザープロパティ、ランダムな割合、インポートしたセグメント、日時、初回起動、インストールID、ユーザーの存在、カスタムシグナルの18種類。Firebase Analyticsとはで作ったオーディエンスとユーザープロパティをそのまま条件へ持ち込める点が、この製品の実質的な強みになります。

複数の条件が同時に true になったときは、コンソール上で最も上に置かれた条件が勝ちます。優先順位はドラッグで並べ替えるだけ。仕様としては単純ですが、条件が10件を超えたあたりから「どれが実際に効いているのか」が読めなくなります。運用としては、広い条件を下、狭い条件を上へ置くという並べ方を最初に決め、条件名へ狙いを書いておくのが現実的な防衛策です。

カスタムシグナルは端末側から送る任意の値を条件へ持ち込む仕組み

標準のルールタイプで表せない切り分けには、カスタムシグナルを使います。アプリ側から任意のキーと値を送り、それを条件式で評価する形。契約プラン、テナントID、機能の利用実績といった自社固有の属性で配り分けたい場合の受け皿になります。

上限は1アプリインスタンスあたり100件、キーは250文字、値は500文字まで。正規表現で照合する場合の値は250文字までに縮みます。Analytics のオーディエンスと違って集計の待ち時間が無く、送った直後の評価に反映される点が実装上の差になります。

既定値とフェッチ間隔の設計で事故が起きる3つの地点と回避の手順

この製品で最も多い相談は「値を変えたのにアプリへ反映されない」です。原因はたいてい次の3つのどれかに落ちます。

既定のフェッチ間隔は12時間で開発中に値が反映されない原因になる

最小フェッチ間隔の既定値は12時間です。この窓のあいだ何度 fetch を呼んでも、SDK はキャッシュを返してバックエンドへは行きません。コンソールで値を変えた直後に手元の端末で確認しても変わらないのは、多くの場合これが理由。

開発中は間隔を短く設定して回します。ただしサーバー側にも制限があり、SDK v17.0.0 より前は60分間に5回を超えるとフェッチが弾かれました。現行版では緩和されていますが、無制限ではありません。そして本番向けのビルドで短い間隔を残すと、後述の従量課金がそのまま効いてくる。ビルドタイプで値を切り替える形にして、リリースビルドでは既定へ戻すのが安全な組み方です。

リアルタイム更新は最小フェッチ間隔を無視して即時に降りてくる

即時性が要るなら、リアルタイム Remote Config を併用します。SDK がバックエンドへ接続を張り、新しいテンプレートが公開されると無効化の通知が飛び、SDK が自動で再取得してリスナーを呼ぶ仕組み。この再取得はキャッシュと最小フェッチ間隔を迂回します。

対応バージョンは Apple 版が v10.7.0 以上、Android 版が v21.3.0 以上（Firebase BoM v31.2.4 以上）。アプリがバックグラウンドへ入ると購読は止まり、フォアグラウンド復帰で再開します。同時接続の上限はプロジェクトあたり20,000,000で、これを超えた分の接続要求は拒否され、クライアントは通常のフェッチへ自動的に退避する設計。公式が勧める組み合わせは、起動時に fetch を1回、その後はリスナーで待つという形です。React Nativeから扱う場合の導入とモジュール構成は、React Native Firebaseとはで扱っています。

アプリ起動時のロード戦略は3つあり体験の断絶をどこに置くかで選ぶ

取得と有効化のタイミングには3つの型があります。第1に起動時に取得と有効化を同時に行う型。UI が大きく動かない設定値ならこれで足ります。第2に読み込み画面を出して待つ型で、A/Bテストの割り当てを確定させてから描画したい場合に使う形。第3に前回取得した値を起動時に有効化し、新しい取得はバックグラウンドで回して次回起動へ送る型です。

第3の型が既定の推奨になっているのは、待ち時間がゼロで済むからです。代わりに、値の反映が1回遅れます。障害時の緊急停止スイッチをこの型で持たせると、切り戻しが次回起動まで届かない。緊急停止に使うパラメータだけはリアルタイム更新のリスナー側で拾う、という二段構えにしておくと役割が噛み合います。

段階ロールアウトとA/Bテストの使い分けと24枠という共有上限

条件配信で「10%のユーザーへ」と指定するだけでも段階公開はできます。専用機能を使う価値は、対照群の自動生成と指標の自動監視にあります。

ロールアウトは対照群を自動で作りCrashlyticsで異常を見る

段階ロールアウトは、対象を絞って値を配りながら割合を徐々に上げていく機能です。有効化した群と対照群が自動で切られ、両者の指標が並べて表示されます。監視できるのは Crashlytics 側がクラッシュ・非致命的エラー・応答不能、Analytics 側がコンバージョン・収益・エンゲージメント。Firebase Crashlyticsとはを先に入れておかないと、この監視の半分が空になります。

必要な SDK バージョンは iOS v10.24.0 以上、Android v21.6.0 以上で、Crashlytics 側も Android v18.6.0 以上・iOS v10.24.0 が前提。インフラ層で段階的に切り替えるカナリアリリースとはの考え方をクライアントアプリへ持ち込んだもの、と捉えると使いどころが掴みやすい。サーバーの入れ替えができないアプリ配信の現場で、同じ効果を値の配信で得る仕掛けです。

A/Bテストへ寄せるのは指標の優劣で採否を決めたい場面に限る

A/Bテストは、複数のバリアントを配って目標指標の差を統計的に見る機能です。ロールアウトが「壊れていないか」を見るのに対し、こちらは「どちらが良いか」を見る。目的が違います。

実務で効いてくる制約は枠の共有です。A/Bテストの試験と段階ロールアウトは合算で24件が上限。12件の試験を走らせているなら、同時に持てるロールアウトは12件までに縮みます。恒久的なフラグをロールアウトで持ち続ける運用は、この枠を静かに食い潰す。広げ終えたロールアウトは値を既定へ畳んで枠を返す、という後始末を運用手順に入れておくところです。

サーバーサイドRemote Configはテンプレート全体を落として評価する

2024年以降、サーバー側から Remote Config を使う経路が用意されています。クライアント用とは別のテンプレートを持ち、Admin SDK から読む形。提供段階はプレビューです。

サーバー側はテンプレート全体を落として自前のロジックで評価する

クライアント SDK がバックエンドで評価済みの構成だけを受け取るのに対し、サーバー側 SDK はテンプレート全体をダウンロードし、リクエストごとにローカルで評価します。ネットワーク往復が入らないぶん応答が速く、評価に使う条件も自前のロジックで決められる。必要なのは Admin Node.js SDK v12.1.0 以上で、カスタムシグナルを扱うなら v12.5.0 以上です。

常駐サーバーではテンプレートを定期的に読み直す必要があります。Cloud Functions のような短命な実行環境なら、初期化と読み込みを1回で済ませる非同期の関数が用意されているところ。

const template = await getServerTemplate({
  defaultConfig: { model_name: 'gemini-2.5-flash', max_tokens: 1024 }
});
const config = template.evaluate();
const model = config.getString('model_name');

生成AIのモデル名やプロンプトをAPIキーを晒さずに切り替える

サーバーサイド版の代表的な使いどころが、生成AIのパラメータ管理です。モデル名、温度、最大トークン数、プロンプトの本文をテンプレートへ置いておくと、デプロイせずに差し替えられます。APIキーはサーバー側に留まったまま。

クライアントから直接モデルを呼ぶ構成ならFirebase AI Logicとはの側で扱う話になりますが、コストの上振れを止めたい場合はサーバー側で握るほうが手数が少ない。モデルを安価な系統へ落とす操作が、コンソールの1回の公開で済みます。

2026年9月1日の従量課金化がフェッチ設計の前提をどう変えるか

ここが本記事の芯です。Remote Config は長らく無償で、フェッチ回数を気にする設計動機がありませんでした。2026年9月1日を境に、その前提が消えます。

課金対象はフェッチ回数で猶予期間の終わりは2026年12月と2027年2月

課金単位は、クライアント SDK または REST API から直接呼ばれたフェッチ要求です。他の Firebase サービスが内部的に発生させる通信や、取得済みの値をアプリ内で読む操作は数えません。無償枠は Spark プランが1日100,000フェッチ、Blaze プランも最初の100,000フェッチは無償で、そこから先が1日1,000万まで10,000リクエストあたり0.06ドル、1,000万を超える分が10,000リクエストあたり0.01ドル。

既存プロジェクトには猶予が置かれ、Spark プランは2026年12月1日、Blaze プランは2027年2月1日から通常の課金に入ります。パーソナライズ・段階ロールアウト・A/Bテスト連携は両プランとも追加費用なしのまま。全体像はFirebaseの料金の側で並べていますが、Remote Config だけは今回この表に新しく載る側です。

区分	数量	単価
無償枠（両プラン）	1日10万フェッチ	0ドル
Blaze 超過分	1日1,000万まで	1万件0.06ドル
Blaze 大規模帯	1,000万超の分	1万件0.01ドル
猶予の終了	Sparkプラン	2026年12月1日
猶予の終了	Blazeプラン	2027年2月1日

フェッチ間隔を縮めた瞬間に無料枠の到達DAUが6分の1になる

数字を当ててみます。既定の12時間間隔なら、1日に起動される端末が生むフェッチは概ね2回。100,000フェッチの無償枠は DAU 50,000 前後で埋まります。ここで間隔を1時間へ縮めると1端末あたり最大12回になり、同じ枠が DAU 8,333 で尽きる。設定値を1行変えただけで、無償で賄える規模が6分の1になる計算です。

有償帯に入ったあとの実額も見ておきます。DAU 100万のアプリで1端末あたり1日2フェッチなら、1日200万フェッチ。無償分を引いた190万が課金対象で、10,000件あたり0.06ドルなら1日11.4ドル、月額でおよそ342ドルという水準です。DAU 10万・1日2フェッチなら課金対象は10万件で1日0.6ドル、月額18ドル程度に収まります。桁を跳ね上げるのは DAU そのものより、1端末あたりの回数のほう。

リアルタイム更新は接続ではなく配信のたびの再取得が費用に乗る

リアルタイム更新の接続を張り続けること自体は課金されません。費用が乗るのは、無効化通知を受けたあとの再取得です。これが1フェッチとして計上されます。

つまりテンプレートを公開するたび、そのとき接続している端末の数だけフェッチが一度に発生する。同時接続10万台のアプリで日に5回公開すれば、それだけで50万フェッチが乗ります。運用として効くのは、細かい修正を都度公開せずまとめて1回で出すこと。サーバー側の REST や Admin SDK 経由のテンプレート操作もフェッチとして数えられるため、常駐サーバーの読み直し間隔も同じ目で見ておく必要があります。

受託開発でRemote Configを主線に据える条件と見送る場面

ここまでの実測値から、採否の線を引きます。

受託でRemote Configを主線に据えてよい3つの条件

第1に、切り替えたい対象がアプリ内の分岐で表せること。値の配信しかできない以上、これが成立しない案件では別の手段が要ります。第2に、切り替えの遅延を12時間または次回起動まで許容できるか、リアルタイム更新の対応バージョンまで SDK を上げられること。第3に、1端末あたりのフェッチ回数を見積もれること。DAU と起動回数の想定が無いまま入れると、2027年以降に読めない請求が立ちます。

この3つが揃うなら、Firebase を既に使っている案件では追加の運用基盤を持たずに済む点が大きい。段階ロールアウトと Crashlytics の連動まで含めて、別サービスを契約せずに完結します。スマホアプリ開発の受託では、リリース後の設定変更をどちらが握るかを契約段階で決めておくと、運用フェーズの手戻りが減ります。

Remote Configを見送るのは監査証跡が即時性に優先する場面

見送る判断が要る場面もあります。ひとつは、誰がいつどのパラメータを変えたかを厳密な監査証跡として残す要件がある場合。テンプレートのバージョン履歴は保持300件で、超えた分は古いものから自動的に削除されます。長期の保管が要件なら、履歴を外部へ書き出す仕組みを別に用意する前提になる。

ふたつめは、切り替えの単位がユーザー個別のデータに寄っている場合です。契約内容や残高のような個別の値を配る用途は、そもそも設定配信の守備範囲から外れます。3つめが、フェッチ回数が構造的に膨らむ設計。画面遷移のたびに設定を取りに行くような組み方をしているなら、従量課金に入ってから効いてきます。設計を変えられないなら、値をアプリ側へ持たせるか自前の設定APIへ寄せるほうが安く収まる場合がある。判断は2026年12月1日と2027年2月1日という猶予の期限から逆算して置くところです。