はじめまして、5月に中途入社したデジスマチームの東です。入社してから早くも3ヶ月が経とうとしていますが、日々学びがあり充実しております。
このブログはデジスマチームブログリレーの3日目の記事です。
この記事では Firebase Remote Config を利用して Web の A/B テストを実施する方法を紹介します。
はじめに
デジスマ診療(以降デジスマ)では、患者さんの利便性向上のための UI/UX 改善を継続的に行っています。今回、ある機能で新しい UI パターンを検討することになり、A/B テストによってどちらのパターンがより良いかを検証することにしました。
デジスマで A/B テストを実施するのは初めてだったため、A/B テストツールの選定から始めました。A/B テストツールを選ぶにあたっての前提条件は次の通りです。
- マルチプラットフォーム対応:Web アプリケーションとモバイルアプリを提供しているため、1つのツールで両プラットフォームに対応したい
- 分析基盤:ユーザ行動ログは Google Analytics と BigQuery で収集・集計・分析している
- 導入コスト:まずはライトに導入できる方法を検討したい
- 既存利用サービスの活用:既に利用中のサービスを活かしたい
Firebase A/B Testing と Remote Config の検討
デジスマでは既に Firebase を利用しているため、Firebase A/B Testing の利用を検討しました。しかし、2025年7月時点ではベータ版でプラットフォームとして Web はサポートされていませんでした。
Firebase A/B Testing は内部的に Firebase Remote Config の機能を活用しているため、「Remote Config を直接使用して A/B テストを実現できないか?」と考え、試しに使ってみました。Firebase Remote Config は、アプリケーションの設定値をクラウド上で管理し、アプリを再デプロイすることなくアプリの動作や UI を変更できるサービスです。Firebase Remote Config を使ってみて、条件機能を利用すれば、A/ B テストの実装が可能であることが分かりました。
Firebase コンソールでの設定
ここからは実際に A/B テストを実施するための Remote Config の設定と実装をご紹介します。例として、2025年7月1日の0時から15日の0時まで10%のユーザに対してテストをするとします。
パラメータの作成
まず、パラメータを作成します。
- パラメータ名:任意の文字列
- データ型:文字列
- ベースとなるパターンの条件 control
- Value: control
- テストパターンの条件 test
- Value: test
- Default Value: アプリ内デフォルト値を使用する

条件の作成
次に、ベースパターンの条件 control とテストパターンの条件 test を作成します。
ベースパターンの条件 control
- ユーザー(ランダム%):0〜10
- シード:条件 test と同じ値にする
- 日時:次よりも後 2025/7/1 00:00 日本時間(テスト開始日時)
- 日時:次よりも前 2025/7/15 00:00 日本時間(テスト終了日時)
テストパターンの条件 test
- ユーザー(ランダム%):10〜20
- シード:条件 control と同じ値にする
- 日時:次よりも後 2025/7/1 00:00 日本時間
- 日時:次よりも前 2025/7/15 00:00 日本時間

A/B テストのテストパターンを増やしたい場合はユーザーの範囲が異なる条件を増やすことで対応できます。
ユーザ振り分けの仕組み
Firebase Remote Config は、Firebase インストール ID を使用してにユーザをランダムにグループに分けます。Firebase インストール ID が変わらない限り、ユーザは同一のグループに振り分けられます。ユーザのグループ分けには設定したシード値が使用されます。条件ごとに異なるシード値を使用した場合、ユーザが複数の条件に合致する可能性があります(複数の条件に合致した場合は最初の条件が優先されます)。そのため、すべての条件で同一のシード値を使う必要があります。
アプリ側の実装
次に、Web アプリケーション側で Remote Config の値を取得し、A/B テストを実装する方法を説明します。Firebase Remote Config の公式ドキュメントに詳しく記載されているのでここでは、値の取得と UI パターンの出し分けイメージだけ記載します。
import { fetchAndActivate, getValue } from "firebase/remote-config"; await fetchAndActivate(remoteConfig); const testVariant = getValue(remoteConfig, "sampleTestVariant"); switch (testVariant) { case "control": return <ControlUI />; case "test": return <TestUI />; default: return <DefaultUI />; }
Firebase Remote Config にユーザの振り分けとテストの開始と終了を任せることで、Remote Config から値を取得して、その値に応じて UI を出し分けるだけで良くなり、実装がシンプルになります。 あとは分析のためにログにユーザがどのテストグループに振り分けられたかの情報を設定します。
注意点
上記の設定と実装で A/B テストを実施できますが、いくつか注意点があります。
- フリッカー対策
- Remote Config の値の取得に時間がかかる場合、デフォルト UI が一瞬表示されてからテスト UI に切り替わる場合があります
- 取得中は対象モジュールを表示せず、取得完了後に表示するなどの対策が必要です
- 一方でモジュール表示に時間がかかってしまうという欠点にもなります
- キャッシュによる設定反映遅延
- スロットリング処理によって、設定の反映に最大12時間かかる場合があります
- ※ モバイルアプリにはリアルタイムに更新を受け取る機能があります
- これにより、テストの開始と終了時刻を厳密な制御はできません
- 不具合があった場合、設定変更では即座にテストを中止できないため、アプリケーションのコードにテストを中止するフラグを設けてデプロイでテストを中止できるようにしました
- スロットリング処理によって、設定の反映に最大12時間かかる場合があります
- デバイス間の整合性
- 同一ユーザでも異なるブラウザやデバイスでは別のグループに振り分けられる可能性があります
- グループ間のユーザ属性の偏り
- 単純なランダム割り当てのため、グループ間でユーザ属性に偏りが生じる可能性があります
まとめ
この記事では、Firebase Remote Config を利用して Web で A/B テストを実施する方法をご紹介しました。 Remote Config を利用することで当初の目的通り、追加のツールを導入することなくライトに A/B テストを実現できました。 また、アプリケーションは Remote Config から値を取得して、パラメータの値を条件分岐に使用するだけでシンプルに実装できました。 今回は Web での実装でしたが、モバイルアプリでも同様の設定と実装で実現できると見込んでいます。
一方でデバイス間での整合性やグループ間のユーザの偏りといった課題は残ります。今後の改善でカスタムシグナル条件の利用や別の手段を検討していきたいと考えています。
最後までお読みいただき、ありがとうございました。
We are Hiring!
エムスリーではエンジニアを絶賛募集しています! ご興味ある方は是非カジュアル面談等ご応募ください!
エンジニア採用ページはこちら
カジュアル面談もお気軽にどうぞ!
エンジニア新卒採用サイトもオープンしました!
インターンもこちらから!