フィーチャーフラグの仕組み — 新しい検索画面を少しずつ公開する

ひよこ

新しい検索画面を作ったら、全員に一気に見せるしかないの？

ペンギン先生

フィーチャーフラグを使うと、コードを置く時点と、使ってもらう時点を分けられるよ。アプリに新旧の処理を用意し、設定や利用者の条件でどちらを使うか決めるんだ。

ひよこ

フラグって、特別な仕組みなの？

ペンギン先生

最初はON/OFFで分かれるif文でも考えられるよ。下の例では同じ商品に対し、OFFなら文字の一覧、ONならカード用の表示を選ぶ。まずどこで分岐するかを見ると分かりやすいね。

ひよこ

設定を変えるだけで、デプロイし直さなくていい？

ペンギン先生

実行中に読み直す設定やサービスを使っていれば、そのようにできるよ。一方、ビルド時に値を埋め込む設計なら、再ビルドが必要になることもある。フラグを置くだけで、どんな設定も動的に変わるわけではないんだ。

ひよこ

社内の人から試してもらえる？

ペンギン先生

利用者の条件でONにできるよ。その後、一定割合へ広げる段階的公開もある。同じ人に毎回同じ版を見せたいなら、安定したIDを使った割り当てなど、対象を固定する仕組みも確認しよう。

ひよこ

不具合が出たらOFFですぐ元通り？

ペンギン先生

今後の処理を旧方式へ戻せることはあるよ。ただしSDKの更新やキャッシュで反映が遅れたり、既に保存したデータが残ったりする。フラグを戻すことと、データの巻き戻しは別なんだ。

ひよこ

有料機能もフラグで隠せば守れる？

ペンギン先生

画面の表示制御には使えるけど、隠すだけではアクセス権を守れないよ。サーバーでも権限を確認しよう。利用者が書き換えられるブラウザーの値を、そのまま権限の根拠にしてはいけないんだ。

ひよこ

どのフラグも、いつか削除するの？

ペンギン先生

一時的な公開用フラグは、安定したら古い分岐ごと片付けると見通しが良くなるよ。運用用の切り替えなど、長く残すものもある。目的、担当者、見直す条件を決めておこう。

ひよこ

テストはONだけでいい？

ペンギン先生

OFFの処理、設定取得に失敗した場合、対象が変わる場面も試そう。複数フラグを組み合わせると確認が増える。切り替えの記録と結果を観測し、使わない分岐を増やし続けないことが大切だね。

まずは、同じりんごを「一覧」と「カード」で切り替える

フィーチャーフラグは、機能の使い方を設定や条件で選ぶ仕組みです。新機能を本番へ置くデプロイと、利用者へ見せるリリースを分けるためにも使われます。

Node.jsが使える場合は、練習用フォルダーにflag-demo.jsを保存してnode flag-demo.jsを実行してみましょう。まずは、画面へ渡す文字列の選び分けだけを試します。

const product = { name: 'りんご', price: 120 };

function searchLabel(newSearch) {
  return newSearch
    ? `[カード] ${product.name}: ${product.price}円`
    : `[一覧] ${product.name}: ${product.price}円`;
}

console.log(searchLabel(false));
console.log(searchLabel(true));

OFFとONで次のように変わります。商品データは同じで、表示に使う処理を選んでいます。

[一覧] りんご: 120円
[カード] りんご: 120円

これはON/OFFを引数で渡す練習例です。管理画面で切り替える本番の仕組みを作るには、値の取得・更新、アクセス権、監査などを別に用意します。ブラウザーのボタンからフラグを変更できるだけでは、運用や認可の仕組みがそろったことにはなりません。

少しずつ見せるときに確認すること

社内で試す、対象利用者の一部へ広げる、十分に確認して全員へ公開する、といった順で進められます。割合はサービスや目的に応じて決めるもので、一律に10%から始める必要はありません。

同じ人に毎回同じ版を使ってもらいたい場合は、安定した利用者IDなどで割り当てます。例えばUnleashではstickinessの設定があり、randomでは評価のたびに結果が変わり得ます。「10%」という設定だけで、必ず固定の10%の人に同じ版が出るとは言えません。

測定したい成功率やエラー、問い合わせを先に決め、切り替えの記録も残しましょう。段階的公開とA/Bテストは目的が違い、ON/OFFに分けただけで実験の偏りや統計的な判断まで解決するわけではありません。

もう少し詳しく：OFFでも戻らないもの

実行中に評価するフラグなら再デプロイなしで処理を選べますが、設定の配信やSDKの取得方式によって反映時間が変わります。設定サービスへ接続できないときの既定値も決めます。

フラグをOFFにしても、既に書き込んだデータ、送信済みの通知、変更したDB構造は元へ戻りません。旧方式が新しいデータ形式を読めるか、切り替え中の処理が混ざっても成り立つかを確かめてください。

画面を隠すことも、APIのアクセスを拒否することとは別です。認可の確認はサーバー側でも行い、利用者が変更できるフラグ値を権限の根拠にしません。

目的に応じて片付ける

公開、実験、運用、利用者別の機能提供など、フラグには異なる用途があります。一時的な公開用フラグは、役目を終えたら旧分岐・不要なテスト・設定を整理します。運用上の切り替えなど、長期に残すフラグもあります。すべてのフラグを全員公開後に削除する、という一律のルールではありません。

担当者と目的、終了・見直しの条件を記録しておくと、残す理由を判断できます。フラグがあればレビューや短いブランチが不要になるわけでもありません。

覚え方と次の一歩

「フィーチャーフラグ」って出てきたら「機能の使い方を選ぶスイッチ」と思えばだいたいOK！

まず上の例で両方の結果を見て、次はブルーグリーンデプロイの仕組みやCI/CDの仕組みと、切り替える対象の違いを比べられます。

参考資料

• Pete Hodgson：Feature Toggles — 動的な切り替え、用途と寿命、分岐の確認と管理
• Unleash：Gradual rollout — 段階的公開とstickiness、randomでの評価