章: 第8章: パフォーマンスと本番運用実践
新機能のリリース、一発で全ユーザーに出していますか?
新機能を本番に出した瞬間、全ユーザーに影響が広がる——問題が起きてからロールバックするには遅すぎます。
「ベータユーザーにだけ見せたい」「スタッフで先に動作確認したい」「問題があればすぐOFFにしたい」——こうした要求に応えるのが 機能フラグ(Feature Flag) です。Laravel Pennant を使えば、コードを書き換えることなく機能の公開範囲を動的に制御できます。
問題の本質と解決策
問題: 機能フラグなしでリリースすると、問題発生時のロールバックにデプロイが必要で、影響範囲を限定する手段がありません。
解決策: Pennant の Feature::define() でリリース条件を定義し、Feature::for($user)->active() で条件分岐します。フラグをOFFにするだけで機能を即座に無効化できるため、デプロイなしでロールバックが可能になります。
フラグなし vs フラグあり 比較
| 観点 | フラグなし | Pennant で制御あり |
| リリース範囲 | 全ユーザーに一斉公開 | ユーザー属性で段階的に公開 |
| 問題発生時の対応 | デプロイが必要 | フラグOFFで即時無効化 |
| A/Bテスト | 実装コストが高い | フラグ条件を変えるだけ |
| コードの管理 | if文が散在しやすい | 判定ロジックを一箇所に集約 |
チェックポイント: 機能フラグの判定ロジックが複数箇所に散らばっていませんか?
Feature::define()に集約することで、変更・削除が安全になります。
実装サンプル
<?php
use Laravel\Pennant\Feature;
Feature::define('new-checkout', fn (User $user) => $user->is_beta_user);
if (Feature::for($user)->active('new-checkout')) {
return view('checkout.new');
}
return view('checkout.legacy');
まとめ & 次のステップ
- 機能フラグを使うと、デプロイなしで機能の公開/非公開を切り替えられます
Feature::define()でリリース条件を一箇所に定義します- フラグの判定ロジックを分散させず、集約することが保守性のポイントです
- 使い終わったフラグは積極的に削除して技術的負債を溜めないようにしましょう
- まずは1つの新機能にベータユーザー限定フラグを設定するところから始めましょう
次回は スケジューラ設計と再実行耐性 を学びます。cronジョブを安全に運用するための設計パターンを解説します。