feature-flag-manager
機能フラグ、段階的リリース、実験的なユーザー割り当てなどを実現したい場合に、フラグ評価やユーザーの割り当てルール、ライフサイクル管理を支援し、新機能の効果的な導入やテストを可能にするSkill。
📜 元の英語説明(参考)
When the user needs to implement feature flags, gradual rollouts, or experiment bucketing. Use when the user mentions "feature flag," "feature toggle," "gradual rollout," "canary release," "percentage rollout," "kill switch," "user bucketing," "experiment assignment," or "dark launch." Covers flag evaluation, deterministic user assignment, targeting rules, and flag lifecycle management. For experiment design, see ab-test-setup. For event tracking, see analytics-tracking.
🇯🇵 日本人クリエイター向け解説
機能フラグ、段階的リリース、実験的なユーザー割り当てなどを実現したい場合に、フラグ評価やユーザーの割り当てルール、ライフサイクル管理を支援し、新機能の効果的な導入やテストを可能にするSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o feature-flag-manager.zip https://jpskill.com/download/14892.zip && unzip -o feature-flag-manager.zip && rm feature-flag-manager.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/14892.zip -OutFile "$d\feature-flag-manager.zip"; Expand-Archive "$d\feature-flag-manager.zip" -DestinationPath $d -Force; ri "$d\feature-flag-manager.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
feature-flag-manager.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
feature-flag-managerフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
Feature Flag Manager
概要
コントロールされたロールアウトとA/Bテストのためのフィーチャーフラグシステムを実装します。フラグの定義、決定論的なユーザーのバケット分け(同じユーザーは常に同じバリアントを見る)、属性ベースのターゲティング、パーセンテージロールアウト、およびフラグのライフサイクル管理をカバーします。サードパーティの依存関係なしに、自己ホスト型のソリューションを構築します。
手順
1. フラグ定義スキーマ
interface FeatureFlag {
key: string; // "checkout-redesign"
type: 'boolean' | 'multivariate';
enabled: boolean; // グローバルキルスイッチ
variants: string[]; // ["control", "new-checkout"]
allocation: number[]; // [50, 50] — バリアントごとのパーセンテージ
targeting?: TargetingRule[];
createdAt: Date;
updatedAt: Date;
}
interface TargetingRule {
attribute: string; // "plan", "country", "signupDate"
operator: 'eq' | 'neq' | 'in' | 'gt' | 'lt' | 'contains';
values: any[];
allocation?: number[]; // このセグメントに対する割り当てのオーバーライド
}
フラグをデータベースに保存し、インメモリキャッシュを使用します(30秒ごとまたはwebhookでリフレッシュ)。
2. 決定論的なバケット分け
安定した均一な分布のために MurmurHash3 を使用します。
import murmurhash from 'murmurhash';
function assignVariant(flagKey: string, userId: string, variants: string[], allocation: number[]): string {
const hash = murmurhash.v3(flagKey + ':' + userId);
const bucket = hash % 10000; // 0-9999 で 0.01% の粒度
let cumulative = 0;
for (let i = 0; i < variants.length; i++) {
cumulative += allocation[i] * 100; // パーセンテージをベーシスポイントに変換
if (bucket < cumulative) return variants[i];
}
return variants[0]; // 最初のバリアントへのフォールバック
}
プロパティ:
- Deterministic: 同じユーザー + 同じフラグ = 常に同じバリアント
- Independent: 異なるフラグは独立した割り当てを生成します
- Uniform: MurmurHash3 はバケット全体に均等に分散します
- Stable on resize: 50/50 を 70/30 に変更しても、ほとんどのユーザーは元のバケットにとどまります
3. フラグ評価パイプライン
evaluateFlag(flagKey, userId, userAttributes):
1. キャッシュからフラグ設定をロード
2. If flag.enabled === false → デフォルトのバリアント(control)を返す
3. ターゲティングルールを順番にチェック:
- ユーザーがルールに一致する場合 → そのルールの割り当てを使用する
- ルールが一致しない場合 → デフォルトの割り当てを使用する
4. 決定論的ハッシュでバケットを計算
5. 割り当てパーセンテージを介してバケットをバリアントにマッピング
6. 割り当てイベントをログに記録(分析用)
7. バリアント名を返す
4. サーバーサイド統合
// Express ミドルウェア — リクエストごとにすべてのアクティブなフラグを評価
app.use((req, res, next) => {
const userId = req.user?.id || req.cookies.anonymousId;
const attributes = {
plan: req.user?.plan,
country: req.headers['cf-ipcountry'],
signupDate: req.user?.createdAt,
};
req.flags = evaluateAllFlags(userId, attributes);
next();
});
// ルートハンドラー内
app.get('/checkout', (req, res) => {
if (req.flags['checkout-redesign'] === 'new-checkout') {
return renderNewCheckout(req, res);
}
return renderCurrentCheckout(req, res);
});
5. フラグのライフサイクル
1. CREATED — フラグが定義され、enabled=false、トラフィックなし
2. TESTING — ターゲティングを介して内部ユーザーに対して有効(email に @company.com が含まれる)
3. RAMPING — 段階的なロールアウト: 5% → 25% → 50% → 100%
4. DECIDED — 実験が終了し、勝者が 100%
5. ARCHIVED — フラグコードが削除され、構成は監査証跡のために保持される
データベースでライフサイクルを追跡します。フラグが DECIDED 状態になってから14日以上経過した場合にアラートを出します(クリーンアップのリマインダー)。
6. 管理 API
GET /api/flags — すべてのフラグをリスト表示
POST /api/flags — フラグを作成
PATCH /api/flags/:key — 割り当て/ターゲティングを更新
PATCH /api/flags/:key/toggle — 有効/無効(キルスイッチ)
GET /api/flags/:key/assignments — ユーザー分布を表示
DELETE /api/flags/:key — フラグをアーカイブ
例
例 1: ブール型のフィーチャーフラグ
プロンプト: 「新しい検索バーのフィーチャーフラグを追加します。まず、ユーザーの10%にロールアウトします。」
出力: ブール型のフラグ定義、90/10 の割り当て、評価ミドルウェア、および管理トグルエンドポイント。
例 2: 多変量実験
プロンプト: 「3つの料金ページレイアウトをテストします。現在のレイアウト、簡略化されたレイアウト、詳細なレイアウトです。無料プランの米国のユーザーのみを対象とします。」
出力: ターゲティングルール(country=US, plan=free)を持つ多変量フラグ、3方向の割り当て(34/33/33)、バケット分けの実装、および分析のための割り当てログ。
ガイドライン
- 常にサーバーサイド評価を使用する — クライアントサイドのフラグは実験の詳細をリークし、ちらつきが発生します
- 実験キーでハッシュする — 実験間で独立したランダム化を保証します
- フラグ設定をキャッシュする — すべてのリクエストでデータベースをクエリしないでください。30秒の TTL で十分です
- すべての割り当てをログに記録する — 実験分析に必要です。フラグ、バリアント、userId、タイムスタンプを含めます
- キルスイッチを構築する —
enabled: falseはフラグをグローバルに即座に無効にする必要があります - 古いフラグをクリーンアップする — 古くなったフラグは技術的負債になります。決定後14日後にアラートを出します
- バケット分けをテストする — 出荷前に、10,000人以上のシミュレートされたユーザーで分布が均一であることを確認します
- 匿名ユーザーをサポートする — ログイン前のバケット分けには、Cookieベースの匿名IDを使用します
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Feature Flag Manager
Overview
Implements feature flag systems for controlled rollouts and A/B testing. Covers flag definition, deterministic user bucketing (same user always sees the same variant), attribute-based targeting, percentage rollouts, and flag lifecycle management. Builds self-hosted solutions — no third-party dependencies.
Instructions
1. Flag Definition Schema
interface FeatureFlag {
key: string; // "checkout-redesign"
type: 'boolean' | 'multivariate';
enabled: boolean; // Global kill switch
variants: string[]; // ["control", "new-checkout"]
allocation: number[]; // [50, 50] — percentage per variant
targeting?: TargetingRule[];
createdAt: Date;
updatedAt: Date;
}
interface TargetingRule {
attribute: string; // "plan", "country", "signupDate"
operator: 'eq' | 'neq' | 'in' | 'gt' | 'lt' | 'contains';
values: any[];
allocation?: number[]; // Override allocation for this segment
}
Store flags in database with in-memory cache (refresh every 30 seconds or on webhook).
2. Deterministic Bucketing
Use MurmurHash3 for stable, uniform distribution:
import murmurhash from 'murmurhash';
function assignVariant(flagKey: string, userId: string, variants: string[], allocation: number[]): string {
const hash = murmurhash.v3(flagKey + ':' + userId);
const bucket = hash % 10000; // 0-9999 for 0.01% granularity
let cumulative = 0;
for (let i = 0; i < variants.length; i++) {
cumulative += allocation[i] * 100; // Convert percentage to basis points
if (bucket < cumulative) return variants[i];
}
return variants[0]; // Fallback to first variant
}
Properties:
- Deterministic: Same user + same flag = same variant, always
- Independent: Different flags produce independent assignments
- Uniform: MurmurHash3 distributes evenly across buckets
- Stable on resize: Changing 50/50 to 70/30 keeps most users in their original bucket
3. Flag Evaluation Pipeline
evaluateFlag(flagKey, userId, userAttributes):
1. Load flag config from cache
2. If flag.enabled === false → return default variant (control)
3. Check targeting rules in order:
- If user matches a rule → use that rule's allocation
- If no rules match → use default allocation
4. Compute bucket via deterministic hash
5. Map bucket to variant via allocation percentages
6. Log assignment event (for analytics)
7. Return variant name
4. Server-Side Integration
// Express middleware — evaluate all active flags per request
app.use((req, res, next) => {
const userId = req.user?.id || req.cookies.anonymousId;
const attributes = {
plan: req.user?.plan,
country: req.headers['cf-ipcountry'],
signupDate: req.user?.createdAt,
};
req.flags = evaluateAllFlags(userId, attributes);
next();
});
// In route handler
app.get('/checkout', (req, res) => {
if (req.flags['checkout-redesign'] === 'new-checkout') {
return renderNewCheckout(req, res);
}
return renderCurrentCheckout(req, res);
});
5. Flag Lifecycle
1. CREATED — Flag defined, enabled=false, no traffic
2. TESTING — Enabled for internal users via targeting (email contains @company.com)
3. RAMPING — Gradual rollout: 5% → 25% → 50% → 100%
4. DECIDED — Experiment concluded, winner at 100%
5. ARCHIVED — Flag code removed, config kept for audit trail
Track lifecycle in database. Alert when flags are in DECIDED state for > 14 days (cleanup reminder).
6. Admin API
GET /api/flags — List all flags
POST /api/flags — Create flag
PATCH /api/flags/:key — Update allocation/targeting
PATCH /api/flags/:key/toggle — Enable/disable (kill switch)
GET /api/flags/:key/assignments — View user distribution
DELETE /api/flags/:key — Archive flag
Examples
Example 1: Boolean Feature Flag
Prompt: "Add a feature flag for our new search bar. Roll out to 10% of users first."
Output: Flag definition with boolean type, 90/10 allocation, evaluation middleware, and admin toggle endpoint.
Example 2: Multi-Variant Experiment
Prompt: "Test three pricing page layouts: current, simplified, and detailed. Only for US users on free plan."
Output: Multivariate flag with targeting rules (country=US, plan=free), three-way allocation (34/33/33), bucketing implementation, and assignment logging for analytics.
Guidelines
- Always use server-side evaluation — client-side flags leak experiment details and flicker
- Hash with experiment key — ensures independent randomization across experiments
- Cache flag configs — don't query database on every request; 30s TTL is fine
- Log every assignment — needed for experiment analysis; include flag, variant, userId, timestamp
- Build a kill switch —
enabled: falsemust immediately disable the flag globally - Clean up old flags — stale flags become tech debt; alert after 14 days post-decision
- Test the bucketing — verify distribution is uniform with 10K+ simulated users before shipping
- Support anonymous users — use a cookie-based anonymous ID for pre-login bucketing