2026 年 5 月、Cloudflare が Flagship: an Edge-Native Feature Flag Service Built on OpenFeature を発表し、OpenFeature 互換のエッジネイティブなフィーチャーフラグ基盤を SaaS として提供開始しました。これまで LaunchDarkly / Optimizely / Statsig などが牽引してきた領域に、Cloudflare のグローバル分散ネットワークから判定を返す選択肢が加わります。
弊社では 受託開発で機能リリースを段階化するうえで、フィーチャーフラグは欠かせない仕組みになりました。本記事では、Flagship × OpenFeature を受託に組み込む設計指針、段階リリース戦略、価格モデルまでを整理します。
なぜ受託でフィーチャーフラグが必須になったか
「リリース日 = 全ユーザーに一斉公開」というモデルは、すでに受託開発の現場で限界が来ています。理由は以下の 3 点です。
| 背景 | 受託への影響 |
|---|---|
| 開発速度が AI で 3〜10 倍に | 1 日 5 件のリリースで一斉公開は危険 |
| 顧客のユーザー層が多様化 | プラン・地域・端末で挙動を変えたい要望が増加 |
| インシデントの “数秒復旧” 要求 | デプロイ巻き戻しでは間に合わない |
特に 「AI で書いたコードを段階的に出す」ニーズは、Auto Mode や Cursor 系を組み込んだ案件で急拡大しています。これは Claude Code Auto Mode を受託で安全運用する で扱った “AI が書いた量をコントロールする” 思想の続きで、生成は速くても出し方は段階的にという運用が標準になりつつあります。
Cloudflare Flagship のキャラクター
Flagship を競合と比較すると、特徴は次のようにまとまります。
| 項目 | Flagship | LaunchDarkly | Statsig | 自前実装 |
|---|---|---|---|---|
| エッジ判定遅延 | 〜 5ms（Cloudflare 全拠点） | 〜 50ms | 〜 100ms | 自社設計次第 |
| OpenFeature 準拠 | ✅ ネイティブ | ✅ Provider | ✅ Provider | 実装による |
| 価格 | $0.10 / 100万判定〜 | 月額 $50〜 + 規模課金 | フリーミアム | インフラ費 + 人件費 |
| Workers / R2 連携 | ネイティブ | API 連携 | API 連携 | 自社次第 |
| 既存 Cloudflare アカウント | そのまま使える | 新規契約 | 新規契約 | 不要 |
| SLA | 99.99% (Enterprise) | 99.99% | 99.95% | 自社責任 |
特に 「既に Cloudflare を使っているか」が選定の分岐点になります。Workers / Pages / R2 / D1 を採用済みの案件であれば、追加契約・追加 SDK なしでフラグを開始できる利点が大きく、受託で導入のハードルが一段下がります。
受託で組む段階的リリースの 5 ステージ
弊社では、新機能を以下の 5 ステージで段階的にリリースする運用を標準にしています。
[Stage 1: Internal Dogfooding]
└ 弊社 + 顧客社内のみ（フラグ 100%、外部 0%）
[Stage 2: Friendly Users]
└ 顧客指定の協力ユーザー 5〜20 名（同意取得済み）
[Stage 3: Geographic Canary]
└ 国内の特定地域 / 特定プラン / 1〜5%
[Stage 4: Gradual Rollout]
└ 5% → 25% → 50% → 100% を 1〜2 週間で
[Stage 5: General Availability]
└ 100% 配信、フラグは "Cleanup 待ち" に移行各ステージでの 進行判定基準は以下です。
| ステージ | Go 条件 | No-Go の合図 |
|---|---|---|
| Stage 1 → 2 | 重大バグなし、ログに想定外なし | スタックトレース増加 |
| Stage 2 → 3 | 協力ユーザーから NPS フィードバック取得 | サポート問い合わせ集中 |
| Stage 3 → 4 | エラー率 < 0.1%、レイテンシ p95 維持 | エラー率上昇 |
| Stage 4 → 5 | 5% / 25% / 50% で各 24h 安定 | コンバージョン低下 |
| Stage 5 → Cleanup | フラグ 100% で 2 週間安定 | 該当なし → 即 Cleanup |
このフローを OpenFeature 標準 SDK 経由で組むことで、Flagship から将来 LaunchDarkly や自社実装に切り替えた場合でも、アプリ側のコード変更が不要になります。これは Cloudflare Agent Memory による業務システム永続記憶 で扱った “Cloudflare 依存を抑えつつ性能を取る” 設計思想と同方向です。
OpenFeature を中心に据える理由
Flagship を選んでも、SDK は OpenFeature 標準を使うことを強く推奨します。理由は以下の 3 点です。
- ベンダーロックイン回避: 将来別ベンダーに切り替えても、アプリコードが変わらない
- テスト容易性: テスト時はメモリ Provider に差し替えるだけで済む
- 複数ベンダー併用: A/B テストは Statsig、リリース管理は Flagship、社内向けは自前、といった棲み分けが自然にできる
OpenFeature は Cloud Native Computing Foundation のサンドボックスプロジェクトで、事実上の業界標準になりつつあります。受託で構築する案件では、最初から OpenFeature を入れておくのが将来の選択肢を残すうえでの最小投資です。
価格モデル — フィーチャーフラグを組み込んだ受託パッケージ
フィーチャーフラグ運用を含めた受託パッケージは、以下の価格レンジで提供しています。
| プラン | 初期 / 月額 | 対象 | 内容 |
|---|---|---|---|
| FF Lite | 30 万円 / 3 万円〜 | 既存案件への後付け | OpenFeature 導入 + Flagship 1 環境 |
| FF Standard | 100 万円 / 15 万円〜 | 新規受託・継続案件 | Lite + 5 ステージ運用 + ダッシュボード |
| FF Enterprise | 300 万円〜 / 50 万円〜 | 上場・複雑な権限要件 | Standard + RBAC + 監査ログ + SLA |
特に **「FF Standard を入れたら障害時の MTTR が 30 分から 30 秒になった」事例が複数あり、運用品質の改善幅が大きい領域です。中小企業でも月額 15 万円の投資で、「リリース当日のヒヤリハット」**を構造的に減らせます。
ハマりやすい 5 つの落とし穴
最後に、フィーチャーフラグを受託で運用するときに踏みやすい落とし穴を共有します。
落とし穴 1: フラグの “永久放置”
リリース完了後にフラグを片付けないと、コード内の if 文が際限なく増殖します。フラグごとに「Cleanup 期限」を必ず設定し、CI で期限超過フラグを警告させます。
落とし穴 2: 設計時に “デフォルト値” を決め忘れる
Flagship が一時的に応答しないとき、デフォルト値が false か true かでユーザー体験が大きく変わります。OpenFeature の Provider 設定で 明示的にフェイルセーフ値を入れます。
落とし穴 3: A/B テストとリリース管理の混同
「機能を出すか出さないか」と「ボタンの色を A/B」は、運用ライフサイクルが全く違うフラグです。プレフィックスやタグで分類し、監視ダッシュボードで分けて表示します。
落とし穴 4: 顧客側担当者が直接フラグを ON/OFF
権限管理を雑に渡すと、顧客の担当者が金曜夕方にフラグを切る事故が起きます。RBAC で「誰が」「いつ」「どの環境を」操作できるかを案件ごとに合意し、契約条項に書き起こします。
落とし穴 5: フラグ判定をアプリ起動時のみに行う
サーバーサイドで起動時 1 回しかフラグを取得しないと、フラグ変更が反映されません。OpenFeature の Streaming Provider または Edge での per-request 判定を推奨し、最大反映遅延を 5〜30 秒以内に抑えます。
まとめ — リリースを “イベント” から “日常運用” へ
フィーチャーフラグは、「機能リリース」を一発勝負のイベントから、毎日のスムーズな運用に変える仕組みです。Cloudflare Flagship × OpenFeature の組み合わせは、追加契約のハードルを下げつつベンダーロックインを避ける選択肢として、受託案件で導入しやすい構成です。
弊社では FF Lite / Standard / Enterprise の 3 段階で受託パッケージを提供しています。「毎週金曜の本番リリースが怖い」「機能を一部ユーザーだけに先行公開したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
