Remote Config 実務（一人開発）：段階的ロールアウトとキルスイッチ
背景与問題
store リリースなしで機能の ON/OFF と露出率を変えられる Remote Config は一人開発の安全弁。Firebase Remote Config の段階的ロールアウト・キルスイッチ・制限値を実務として整理する（B 方向）。フィーチャーフラグの設計思想は opc-feature-flag-solo、クラッシュ監視は opc-crash-reporting-setup。
发现
（出典はいずれも 2026-09-18 アクセス）
- 事実（Firebase 公式 rollouts）：Remote Config rollouts で機能の露出率を段階的に上げられる（staged rollout）。「user in random percentile」条件は一貫して同じユーザー群に固定（sticky バケッティング、Stack Overflow 記載）——10% ロールアウトは毎回同じ 10%。
- 事実（公式制限ページ）：パラメータ 3,000/条件 2,000 と制限は余裕あり。実務上気にするのは REST API 60 リクエスト/分くらい。
- 事実：solo 開発の実録——Taskito がクラウド同期機能をパーセンテージロールアウトで段階解放（Taskito）。進行パターンは「自分→内部テスター→小%→全開」のホワイトリスト順（Stack Overflow 定説）。
- 事実：real-time updates（2023-06〜）+Crashlytics/Analytics 連携でロールアウト中の crash-free 率を監視しながら%を広げる手順が定着（Firebase blog）。設定ルールのミスで 5% ユーザーのクラッシュ率が倍増した実例談（Medium）もある。
- 推测：一人開発の運用基線——①新機能フラグは既定 false で出荷（キルスイッチ兼用）②ロールアウトは 1%→10%→100% の 3 段で各 24h は待つ ③クリッシュ率が落ちたら即 0% に戻す（opc-rollback-drill と共通の判定）④フラグのライフサイクル（恒久化/削除）を月次点検で掃除。
结论
（調査継続中）
待办 / 下次继续
下次继续：kill switch 1 本の設定から。レビュープロンプトの調整も同じ仕組みで配信後変更可（opc-in-app-review-flow）。
关联
opc-feature-flag-solo opc-crash-reporting-setup opc-rollback-drill opc-in-app-review-flow