フィーチャーフラグ運用

フィーチャーフラグ運用とは

フィーチャーフラグ (Feature Flag) の運用は、フラグの作成から削除までのライフサイクルを管理するプラクティスだ。フラグを作るのは簡単だが、不要になったフラグを削除せずに放置すると、コードベースが条件分岐だらけになり技術的負債が蓄積する。

Martin Fowler は自身の bliki 項目「Feature Flag」(2010 年 10 月 / 以降追記) で、リリースフラグは有用な技術だが本番へ機能を出す手段としては最後の選択肢にすべきで、まず機能を分割して安全に一部ずつ出すことを第一に考えるべきだと書いている。どうしても作りかけの機能を隠す必要があるなら、UI の入口だけを最後に足すキーストーンインターフェースが次の選択肢になる。フラグを足すほど組み合わせ状態は増え、10 個で理論上 1,024 通り (2 の 10 乗) になる。ただしこれがそのままテストすべき件数になるわけではない (後述)。

フラグの 4 分類とライフサイクル

Pete Hodgson が 2017 年 10 月に martinfowler.com へ寄せた記事の分類に基づく 4 種類のフラグは、寿命の長さと、判定をどれだけ動的に切り替える必要があるかの 2 軸で性格が分かれ、管理方針も変わる。

短命フラグと長命フラグを同じ仕組みで管理すると、短命フラグの削除が後回しになりやすい。分類ごとに管理ルールを分けることが重要だ。

フラグの技術的負債化を防ぐ

削除戦略

フラグ作成時に「削除予定日」をコードコメントとチケットの両方に記録する。

// TODO: 2026-04-15 までに削除 (TICKET-1234)
// リリースフラグ: 新しい検索アルゴリズム
if (featureFlags.isEnabled('new-search-algorithm')) {
  return newSearch(query);
}
return legacySearch(query);

CI での期限切れ検出

CI パイプラインで期限切れフラグを検出し、ビルドを警告 (または失敗) させる仕組みを設ける。

# 期限切れの TODO コメントを検出
grep -rn "TODO:.*202[0-9]-[0-9][0-9]-[0-9][0-9]" src/ | while read line; do
  date_str=$(echo "$line" | grep -oP '\d{4}-\d{2}-\d{2}')
  if [[ "$date_str" < "$(date +%Y-%m-%d)" ]]; then
    echo "⚠️ 期限切れフラグ: $line"
  fi
done

フラグ数の上限

チーム内でアクティブなフラグ数の上限を設ける (例: 同時に 15 個まで)。上限に達したら、新しいフラグを作る前に既存フラグを削除する。

フラグの実装パターン

シンプルな環境変数方式

// 小規模プロジェクト向け
const isNewUIEnabled = process.env.FEATURE_NEW_UI === 'true';

メリット: 追加の依存なし、デプロイ時に切り替え可能。デメリット: ユーザー単位の制御不可、変更にデプロイが必要。

DynamoDB + Lambda 方式

// サーバーレス環境向け (AWS SDK for JavaScript v3。旧 v2 系はサポート終了済み・2026 年 8 月時点)
import { DynamoDBClient, GetItemCommand } from '@aws-sdk/client-dynamodb';

const ddb = new DynamoDBClient({});
const flags = await ddb.send(new GetItemCommand({
  TableName: 'feature-flags',
  Key: { flagName: { S: 'new-search' } },
}));
const isEnabled = flags.Item?.enabled?.BOOL ?? false;

メリット: リアルタイム切り替え、ユーザー属性による出し分け可能。デメリット: DynamoDB への依存、レイテンシ増加 (キャッシュで緩和)。

よくある落とし穴

• フラグの放置: 「後で消す」が永遠に来ない。3 ヶ月以上残っているリリースフラグは技術的負債と認定し、優先的に削除する
• 組み合わせテストの誤解: フラグが N 個でも 2 の N 乗通りを全部テストする必要はない。Fowler は、リリースフラグなら「次のリリースで有効になる想定の組み合わせ」と「全フラグ有効」の 2 通りを回せば通常は足りると書いている。むしろ危ないのはフラグ間の依存で、依存関係を最小化し独立してテストできる設計にする
• フラグの入れ子: if (flagA && flagB && !flagC) のような複合条件は、どの状態で何が起きるか追跡不能になる。フラグは単独で判定し、入れ子にしない
• 本番でのフラグ切り替え事故: 運用フラグを誤って無効化し、障害を引き起こす。運用フラグには変更時の承認フローを設ける

フラグ管理の成熟度モデル

フラグ管理の成熟度モデルを以下にまとめる。

「Continuous Delivery」(Jez Humble, David Farley 著) でフィーチャーフラグの運用パターンが解説されている。分類とパターンを体系的に整理した Pete Hodgson の記事「Feature Toggles」(martinfowler.com / 2017 年) と、Martin Fowler 自身の bliki 項目「Feature Flag」(2010 年) も必読だ。

全体像を把握するには関連書籍も有用。