Feature Toggle 導入の裏側

こんにちは！
カンリー店舗集客チームでエンジニアをしている有山です。

以前、店舗集客チームの取り組みとして Feature Toggle を導入予定という紹介があったのですが、今回はついに導入に至った Feature Toggle の導入に至るまでの取り組みについて紹介します！

背景と問題

Feature Toggle の導入検討を始めた際、開発チームは以下のような状況でした。

• 複数のチームが別々の機能を開発している
• 完成した機能はリリース前にステージング環境で QA を実施する
• ひとつのシステムが複数のリポジトリに跨っており、複数リポジトリに変更が入るリリースはそれぞれのリポジトリで main ブランチにマージを行う

そのため、以下のような問題を抱えていました。

• QA 待ちの機能数 > ステージング環境の数となり、リリースまでの期間が長期化する
• ある新機能に関する実装が詰まった PR ができあがるため、ビッグバン リリースになりやすい
• PR が大きくなることでレビューの負荷も上がる
• 実装内容によってはすべてのリポジトリのデプロイが完了しきるまでの間、フロントエンドとバックエンドの間で不整合が発生し、エラーが起き得る

解決への取り組み

今回は Feature Toggle に関する取り組みを中心に紹介しますが、それ以外にも上記の問題を解決するために次のような取り組みを行いました。

ステージング環境を増やす

当初ステージング環境は 1 つしかありませんでしたが、これを複数にすることで QA 実施を並列化する狙いです。
単純計算で N 環境あれば N 倍早く進むわけですが、当然そこまで理想的に進むことはなく...。
特に、同時並行で QA を進めている 2 機能が共通の箇所を編集している場合、先にリリースされた方の実装を取り込む際にコンフリクトが発生し、QA のやり直しが発生する、というリスクを抱えることになってしまいました。

デプロイ単位の分割

これまでひとつのリポジトリを特定の環境にデプロイする際は、リポジトリ内のすべてのコードがデプロイの対象となっていました。
そのため、例えば api の改修と batch の改修を同時にテストできず QA 待ちが積み上がるという状況でした。
そこでモジュールごとに個別にデプロイできるようデプロイ用スクリプトを改修することで、部分的に並行テストの実施を可能としました。
この取り組みは問題の完全解決とまではいかないものの一定の効果を得られたと思います。

Feature Toggle とは

さて、上記の問題を解決するべく白羽の矢が立てられた Feature Toggle ですが、そもそも Feature Toggle とは何でしょうか？
Feature Toggle は名前の通り、ある機能のオン・オフを制御できるトグルで、大きく 4 つのカテゴリに分類できるとされています。
(参考: Feature Toggles (aka Feature Flags))

Release Toggles

トランクベースの開発を可能にするために用いられるトグルで、開発中の機能を潜在的なコードとして main ブランチにマージして、本番環境にデプロイすることができます。
開発中の機能がリリースに至れば不要となるため、一般的に数週間で削除されます。

Experiment Toggles

A/B テストのような実験的な変更を実現するためのトグルです。
統計を取る上で十分なデータが集計できるまで維持する必要があります。
また、実験の都合上システム全体の挙動が変わるのではなく、リクエストに応じて動的にオン・オフが切り替わる可能性があります。

Ops Toggles

パフォーマンスへの影響が不透明な場合等、運用面に不安がある際に本番環境で迅速に無効化できるよう設定されるトグルです。
運用面の不安が解消すれば不要となるため、基本的には短期間で削除されます。

Permission Toggles

特定のユーザーだけが利用できる機能や体験を制御するためのトグルです。
その権限が存在する限り必要であるため、非常に長期間有効となる可能性がある上、ユーザーのリクエストに応じて動的にオン・オフを切り替える必要があります。

トグルの状態と生存期間 (引用元: Feature Toggles (aka Feature Flags))

今回はこれら 4 つの内、抱えている問題の解決策としてマッチしている Release Toggles について導入を進めました。

導入にあたって検討したこと

トグルの管理

一言で管理するといっても、以下のように様々な方法が考えられます。

• 環境変数での管理
  • 長所: 既存で環境変数を利用しているフローに乗せやすい
  • 短所: 環境変数の変更反映にデプロイが必要となり、当初の目的を十分に達成できない
• データベースでの管理
  • 長所: 既存のデータベースに管理用テーブルを追加するだけなのでコスト負担なく容易に導入できる
  • 短所: 本番テーブルを適宜操作するための運用設計が必要
• 専用サービスの導入
  • 長所: UI 上での管理や機能が豊富に存在する
  • 短所: 金銭面と学習面でのコストが発生する

今回はコスト面や導入の容易さからデータベースにトグル管理用のテーブルを作成し管理する方法を採用しました。

フロントエンドとバックエンドの連携

データベースでトグルを管理する都合上、フロントエンド側はバックエンドからトグルの状態を取得する必要があります。
その際、フロントエンドからは定期的に取得を行いますが、そのままだとレコードを更新した際にバックエンドが即座に反応する一方で、フロントエンドは再取得まで古い状態が残り続けてしまいます。
そこで、フロントエンドとバックエンドの間で乖離が発生しないよう、データベースでは有効となる期間を管理し、予め状態変更のタイミングを伝達できる方式を採用しました。

具体的には、まずトグル管理用のテーブルで以下のようにトグルを設定します。

id	name	starts_at	ends_at
1	test	2025-10-01 00:00:00	2030-12-31 23:59:59

その上でフロントエンドには、以下のような形式でトグルの状態とともに再取得すべき時刻を伝達します。

{
  "features": [
    { "name": "test", "isEnabled": true }
  ],
  "shouldRefreshAt": "2025-10-10T09:00:00Z"
}

この「再取得すべき時刻」は、通常時はリクエストから 5 分後等の予め決めた間隔を空けた時刻を示しますが、その時刻までにトグルの変更が発生する場合、その変更時刻を示します。
運用時に切り替え時刻を取得間隔よりも先の時刻に指定する必要はありますが、このようにすることでフロントエンドのトグルの状態が置き去りになってしまうことを防ぎました。

利用方法のドキュメント化

開発者が利用しようとした際に使い方に戸惑わないよう、想定している利用方法をドキュメントに起こしました。
また、AI が参照するディレクトリ配下に配置することで、AI のコード生成時にも Feature Toggle が意識されるようにしています。
(ドキュメント自体も AI の力を借りて生成しました。)

Feature Toggle の利用例を示したドキュメント

テストコードによる動作の担保

開発中の機能が本番環境に入っていく都合上、その機能が誤って露出してしまっていないか、また、トグルの設定を入れたことでデグレが起きていないかには十分気をつける必要があります。
とはいえ、それを確認するために QA 工程を挟むのでは問題の解決にならないため、この部分はテストコードの通過をもって検証済みとすることにしました。
具体的には、トグルがオフの場合の動作が変化していないことを検証するルールとしています。
(トグルがオフ時の動作は既存実装の動作と同等なため、もともと適切にテストコードが実装されている箇所であればこのルールによって負担が増えることはほとんどない見込みです。)

導入を進める中で見えてきた課題

こうして導入に至った Feature Toggle ですが、冒頭の問題の解決に役立つ一方で利用にあたって課題も見えてきました。

トグルを削除する運用のルール化

前述した通り Release Toggle としての Feature Toggle は開発中の機能を main ブランチにマージしていけるのが利点ですので、無事にリリースに至ったトグルはコード上から削除しないと不要な分岐が残り続けてしまいます。
機能をリリースした後に Feature Toggle を削除するタスクを追加することに加え、定期的にデータベースを確認することで、放置されているトグルを検知できるようにしていきたいです。

トグルがオフの時の動作保証

上述の通り、実装時のルールとしてテストコードによる検証を必須としていますが、現状テストコードの実装が漏れていたとしてもそれに気付くことができるのは人によるレビューのタイミングのみです。
そのため、レビュー時の見落としを防ぐことができるように AI によるコードレビューの観点として追加できないか検証を続けています。

さいごに

今回はカンリー店舗集客チームでの Feature Toggle の取り組みについて紹介しました。

導入する中で見えてきた課題もありますが、高速な価値提供を継続的に実現するべく、これからも改善に努めていきたいと思います！