プログラミング（Ruby・Rails）システム開発

RailsでFlipperを使う。Feature Flagでデプロイとリリースを分ける

2026年01月10日更新：2026年07月31日約7分

満を持してリリースはやめにしたい

Railsアプリで新機能をリリースするとき、こんな不安を感じたことはないでしょうか。

本番にデプロイした瞬間、全ユーザーに影響が出てしまう
一部の顧客だけに先行リリースしたい
問題が起きたらすぐに機能を止めたい

こうした課題を解決するのが Feature Flag（機能フラグ） です。
RailsでFeature Flagを導入する文脈では、Ruby gem の Flipper がよく使われます。

この記事では、RailsでFlipperを使うときに何がうれしいのか、ActiveRecordアダプタでどう導入するのか、運用でどこに気をつけるかを整理します。

2026-07-31時点で、Flipper公式ドキュメントとRubyGemsを確認しています。

Flipper README: https://github.com/flippercloud/flipper/blob/main/README.md
ActiveRecord Adapter: https://www.flippercloud.io/docs/adapters/active-record
Actors: https://www.flippercloud.io/docs/features/actors
flipper-active_record 1.4.2: https://rubygems.org/gems/flipper-active_record/versions/1.4.2

Feature Flagとは何か

Feature Flag（機能フラグ）とは、

コードは本番にあるが、機能としてはまだ有効化しない

という状態を作る仕組みです。

つまり、

デプロイ = コードを本番に置く
リリース = ユーザーに見せる

この2つを分離する技術です。

これがないと、Railsアプリは

デプロイ = すぐユーザー影響
問題があればロールバック

という運用になりがちです。
Feature Flagを使えば、

社内だけで有効化
特定の会社だけでON
少しずつ対象を広げる（カナリアリリース）

といった運用が可能になります。

Flipperの思想

FlipperのREADMEでは、RubyとRails向けのFeature Flagライブラリとして説明されています。
具体的には、全員、特定のactor、group、actorの割合、時間の割合に対して機能を有効化できます。

ここで大事なのは、Flipperが単なるif文のラッパーではないことです。

Flipperは、
「この機能を、どのユーザー・どの会社に出すか」
という判断を、コードの再デプロイではなくデータとして扱えるようにします。

保存先は Redis や DB などアダプタで差し替えられます。
ActiveRecordアダプタを使えば、Feature Flagの状態をRailsアプリのDBに保存できます。

Railsのモデルやドメインと一緒に
「この会社にはこの機能を出す」というルールを管理できる。
そこがFlipperの大きな特徴です。

FlipperをActiveRecordで導入する

今回はFlipperの中でも、Railsと相性の良い ActiveRecordアダプタ を使います。
公式ドキュメントでは、ActiveRecord 5.x、6.x、7.x、8.x がサポート対象として示されています。

Gemfile

gem 'flipper'
gem 'flipper-active_record'

bundle install

新しく追加するだけなら、次のように bundle add でも構いません。

bundle add flipper
bundle add flipper-active_record

マイグレーション

ActiveRecordアダプタでは、Flipper用のテーブルが必要です。
2026-07-31時点の公式ドキュメントでは、セットアップ用generatorとして次が案内されています。

rails g flipper:setup
rails db:migrate

これで主に次のテーブルが作られます。

flipper_features
flipper_gates

rails db:migrate はDBを変更するコマンドです。
本番でいきなり実行するのではなく、生成されたmigrationを確認し、stagingやローカルで先に動作を見てから適用するのが安全です。

この時点で、Feature Flagは RailsのDBに保存されるデータ になります。

FlipperのDB構造

flipper_features

id	key
1	new_ui
2	beta_export

機能フラグの一覧です。

flipper_gates

feature_key	key	value
new_ui	boolean	true
new_ui	actors	Company;42
new_ui	groups	admins

ここがFlipperの本体です。

FlipperはFeature Flagを複数のゲートで管理します。

ゲート	意味
boolean	全体ON / OFF
actors	特定のユーザー・会社
groups	管理者・βユーザーなど

単なるtrue / falseではなく、誰に対して有効なのか まで保存できます。

単純なON / OFF

Flipper.enable(:new_ui)
Flipper.disable(:new_ui)

このとき、DBには「この機能は全員に対してON」という状態が保存されます。

feature_key	key	value
new_ui	boolean	true

特定の会社だけONにする

ここがFlipperの真価です。

company = Company.find(42)
Flipper.enable_actor(:new_ui, company)

そして、実際に機能を出すかどうかはアプリ側で確認します。

if Flipper.enabled?(:new_ui, current_company)
  render :new_ui
else
  render :old_ui
end

Flipperのactorは、flipper_id に応答するオブジェクトです。
公式ドキュメントでは、ActiveRecordオブジェクトにはデフォルトで flipper_id が定義されると説明されています。
ActiveRecordではない独自オブジェクトをactorにする場合は、Flipper::Identifier をincludeするか、衝突しない flipper_id を自分で定義します。

ただし、enable_actor は大量の個別actorを登録する用途には向いていません。
公式Actorsドキュメントでは、hundreds or thousands of actors を扱う設計ではないこと、Flipper 1.3.0以降は1 featureあたり既定100 actorsの制限があることが説明されています。
会社ごとに数件だけ先行公開するならactorで十分ですが、対象が増える運用ではgroupsやpercentage of actorsを使う設計に寄せたほうが安全です。

たとえばActiveRecordモデルなら、次のような識別子として扱えます。

Company;42

User ID やメールアドレスを本文や設定に直接書くのではなく、アプリケーション内のactorとして扱う。
ここが、Railsアプリで使うときの自然なところです。

なぜDBで持つ設計が強いのか

Redisや外部サービスと違い、ActiveRecordを使うと

マイグレーションで変更を管理できる
バックアップ・復旧の対象になる
「誰に何をONにしたか」をアプリのデータとして扱える

つまりFeature Flagが、

設定ファイルではなく、運用上の判断データになる

という状態になります。

これはBtoBのRailsアプリでは特に重要です。

Flipperで実現するカナリアリリース

Flipper.enable_actor(:new_ui, Company.find(5))
Flipper.enable_actor(:new_ui, Company.find(8))

これだけで、

まず社内
次に数社
問題なければ対象を広げる

というリリースが再デプロイなしで実現できます。

問題が起きたら、Flipper.disable_actor(:new_ui, company) や Flipper.disable(:new_ui) で有効化状態を戻します。
DBを直接編集するのではなく、FlipperのAPIや管理画面から戻せる形にしておくほうが運用として安全です。

Flipperとは何か

Flipperは単なるif文のラッパーではありません。

Flipperが提供しているのは、

「この機能を、どのユーザー・どの会社に出すか」
という判断を、コードではなくデータとして管理できる仕組み

です。

ActiveRecordアダプタを使えば、

この会社には new_ui をON
あの会社にはまだOFF
管理者だけON

といったリリース状態が、そのままRailsのDBに残ります。

つまりFlipperは、

機能の公開範囲を、デプロイとは切り離してコントロールできるようにするgem

です。

段階リリースや顧客ごとの出し分けが必要なRailsアプリでは、運用と設計の両方をシンプルにしてくれる、かなり実戦的な選択肢だと感じています。

Railsの状態管理そのものを整理したい場合は、Railsのenumを使いこなす。状態管理を読みやすくするも近い考え方として参考になります。