Claude CodeのGrowthBookプラグインでフラグと実験の運用を回す
GrowthBookプラグインは、フラグの作成から段階リリース、A/Bテストの設計・分析、古いフラグの削除までをClaude Codeから操作します。導入手順、同梱スキル、使えないこと、鍵の扱いをまとめます。
GrowthBookプラグインは、オープンソースのフィーチャーフラグ・実験基盤「GrowthBook」を、Claude Codeの/growthbook:コマンドから操作するスキル集です。フラグの作成、環境ごとの切り替え、段階リリース、A/Bテストの設計と分析、使い終えたフラグの削除までを、自然文の依頼で進められます。
MCPサーバーは使いません。同梱のNodeスクリプトがGrowthBookのREST APIを直接呼びます。導入に要るのはAPIキーとNode 18以上です。
GrowthBookプラグインは何を肩代わりするか
マーケットプレイスの説明では、フラグの管理から実験の設計、フラグの棚卸しまでを一続きで扱うプラグインとされています。提供元はGrowthBook、リポジトリのライセンスはMITです。
中身は4つのスキルです。それぞれが入口(ルーター)で、依頼に合う手順書だけを読み込みます。手順書は参照ファイルとして各スキルに収まり、必要になるまでコンテキストに入りません。
4つのスキルと担当範囲
feature-flags
フラグのライフサイクル全体。作成、検索、依存関係の確認、環境の切り替え、ターゲティング、段階リリース、レビュー、公開、削除まで17本。
experiments
A/Bテストの発案、設計、起動、分析、停止と、実験をまたいだ学びの記録まで6本。
analytics
指標とファクトテーブルの検索・作成、グラフの作成、ダッシュボードの作成と編集で5本。
gb-setup
APIキーと接続先の設定。手順書は持たず、初回の設定専用です。
フラグの変更は、いきなり本番に効きません。下書きのリビジョンを作り、レビューを経て公開する流れが基本です。READMEも、下書き・レビュー・公開の手順書を、変更を作る手順書と並べて置いたと説明しています。
導入から接続確認まで
導入は3段階です。プラグインを入れ、認証情報を置き、動作を確かめます。
導入の流れ
- 1
マーケットプレイスを登録して入れる
Claude Code内で次の2コマンドを実行します。
- 2
gb-setupでAPIキーを置く
/growthbook:gb-setupが鍵を聞き、実際のAPIで検証してから保存します。 - 3
フラグ一覧で確かめる
/growthbook:feature-flagsを開き、フラグの一覧を頼みます。
/plugin marketplace add growthbook/skills
/plugin install growthbook@growthbook-skillsCursor、Codex、Warp、Zedなど、agentskills.ioに対応する他のエージェントでは、npx skills add growthbook/skillsで入れます。こちらはプロジェクト単位の導入です。
APIキーの置き場所は2通り
/growthbook:gb-setupは、APIキーと(セルフホストの場合は)APIとアプリのURLを聞きます。検証後に~/.config/growthbook/.envへ書き、パーミッションはchmod 600にします。いつでも再実行して更新できます。
シェルの環境変数で渡すこともできます。スキルは環境変数を先に見て、設定ファイルは変数が未設定のときだけ読みます。CIや一時的な上書きにはこちらが向きます。
export GB_API_KEY=<your-key> # 必須: PAT かシークレットキー
export GB_API_URL=https://api.your-host # セルフホストのみ
export GB_APP_URL=https://growthbook.your-host個人アクセストークンは、GrowthBookのアカウント設定の画面で発行します。トークンは発行したユーザーに紐づくので、スキルが作ったフラグや実験は自動でそのユーザーの操作として記録されます。
依頼から手順書が選ばれる流れ
手順書を直接呼ぶコマンドはありません。Claude Codeで打てるのは、/growthbook:feature-flags、/growthbook:experiments、/growthbook:analytics、/growthbook:gb-setupの4つで、手順書はこの中から依頼の文面に応じて選ばれます。
「新しい料金ページ用のフラグを作って」と頼めば、feature-flagsがflag-createを読みます。「次に何を試すべきか」と聞けば、experimentsがexperiment-brainstormを読みます。コマンドを明示しなくても、説明文に合う依頼で自動的に起動します。
マーケットプレイスのページは/growthbook:flag-createのような個別名で例を挙げています。READMEでは、この形は直接のコマンドではなく手順書の名前だと整理されています。迷ったら4つのドメインコマンドから入れば足ります。
フラグを作って段階的に広げる
フラグ主体の流れは、READMEではflag-create、flag-toggle、flag-targeting、flag-rampまたはflag-monitoring、flag-cleanupの順です。
フラグ主体の運用
- 作るflag-create
キーの重複を調べ、値の型、環境、既定値を決めます。作った直後は、すべての環境で無効です。
- 切るflag-toggle
環境ごとに有効・無効を切り替えます。いわゆるキルスイッチで、レビューが前提です。
- 絞るflag-targeting
強制値や割合ロールアウトのルールを足し、条件や保存済みグループ、前提フラグで対象を絞ります。
- 広げるflag-ramp / flag-monitoring
時間をかけて割合を上げます。monitoringはガードレール指標を見張り、自動ロールバックも選べます。
- 片付けるflag-cleanup
使い終えたフラグをアーカイブし、確認してから削除します。
段階リリースは2種類ある
flag-rampは、期間ごとの割合や、手動の承認を挟む段階を組めます。公式の例は1%、5%、25%、100%のような刻みです。稼働中のランプを進める、止める、戻す、承認するといった操作も含みます。
flag-monitoringは同じ仕組みに、ガードレール指標の監視を足したものです。GrowthBookのドキュメントでは、短いA/Bテストとしてエラー率やレイテンシ、コンバージョンを見張り、悪化を知らせる仕組みと説明されています。
古いフラグは2段階で消える
flag-cleanupは、先にコード内の参照を解消する手順を踏みます。そのうえで、アーカイブして確認し、最後に削除する二段階の安全弁を置いています。コード参照の置き換えは、Claude Codeがリポジトリを読めるからこそ成り立つ部分です。
マーケットプレイスの説明によると、棚卸しのflag-searchは、プロジェクト、タグ、担当者、環境ごとの状態、古さで絞り込めます。これは読み取り専用です。
実験を設計して終わらせる
experimentsの手順書は、発案から後片付けまでを連ねる設計です。READMEが示す流れは次のとおりです。
learningsで、過去に分かっていることを確かめるexperiment-designで、仮説・バリエーション・主要指標・ガードレール・必要サンプル数を詰め、起動可能な仕様にするexperiment-launchで、実験の作成、フラグの準備または再利用、実験ルールの接続、開始までを行うexperiment-analyzeで、最新のスナップショットを取り、結果を読むexperiment-stopで、実験を止め、必要なら勝者を宣言するflag-cleanupで、フラグを片付ける
experiment-designは読み取りだけで動き、何も書き込みません。分析ではSRM(サンプル比のずれ)の確認、リフト、信頼区間、ガードレールの順に読む流れになっています。
learningsは、複数の実験にまたがる結論を、保存して検索できる記録です。設計の前に引き、結果が一般化できるときに書き戻します。同じ失敗を繰り返さないための記憶として働きます。
既に動いているフラグに実験を足したい場合は、flag-experimentからexperiment-launchに進みます。このときは既存のフラグが再利用されます。
指標の側はanalyticsが受け持ちます。metric-searchで既存の指標を探し、無ければmetric-createで作り、analytics-exploreで数字を確かめてからexperiment-designに戻る、という順です。
実験の統計的な読み方そのものは、ClaudeにA/Bテストの有意差を検定させる手順が別の角度から扱っています。
使い始める前に知っておく制約
READMEには、このプラグインがやらないことが明記されています。
スキルの守備範囲外
データソースの作成
ウェアハウスへの接続はGrowthBookの画面で作り、IDで参照します。
SDKのコード生成
APIでフラグと実験を管理するだけで、SDKを組み込むコードは書きません。
バンディット実験
標準のA/Bテストが対象です。バンディットは見分けたうえで処理を止めます。
リトライ
GrowthBookのレート制限は毎分60リクエストです。429はそのまま表示され、再試行しません。
指標の分析設定(コンバージョン窓、キャップ、事前分布、リスクのしきい値)も、組織の既定値が引き継がれます。調整はGrowthBookの画面で行います。実験に付くダッシュボードは、その実験のページで編集する扱いです。
Claude Codeのフラグ取得を止めるDISABLE_GROWTHBOOKは、名前が似ていても別の話です。あちらはClaude Code自身が内部で使うフラグの取得を止める変数で、このプラグインとは関係しません。違いはDISABLE_GROWTHBOOKの解説にまとめています。
鍵と変更権限の扱い
APIキーはスキルから呼ばれる書き込み系の操作に使われるので、権限は最小にしたほうが安全です。READMEは次の点を挙げています。
gb-setupで貼ったキーは、ローカルの会話記録に残り、モデル提供元にも会話の一部として送られる。後からは消せない- 個人の管理者トークンを流用せず、プラグイン専用のトークンを新しく発行し、問題があれば単独で失効させる
- 漏れたら、アカウント設定のトークン画面で失効させ、
/growthbook:gb-setupをやり直す - ヘルパーは、空白や制御文字を含む値を拒否する。
gb-setupはhttp://のURLを受け付けない
GrowthBook側にも、エージェントのための設定が2つあります。リクエストした本人を記録するヘッダーと、危険な変更を人が確認するまで保留する「Require confirmation」です。ドキュメントのAPIの章で、エージェントやスクリプトが変更を行うときの要点として紹介されています。
設定の具体的な手順はAPI Keys for Agentsの節を参照するのが確実です。プラグインの導入と併せて、保留の対象になる操作を決めておくと、Claudeが誤って本番の割合を動かす余地を狭められます。
チームで使うときの書き方の例
フラグのキー名や、削除の前提といった社内ルールは、プロジェクトのCLAUDE.mdに書いておくと、依頼のたびに言い直さずに済みます。例えば次のような形です(各ルールは仮の運用例で、プラグインの仕様ではありません)。
## GrowthBook運用ルール
- フラグのキーは `<領域>_<機能>_<yyyymm>` の形にする
- 本番環境のフラグを切り替える前に、必ず下書きの差分を表示する
- 実験が終わったフラグは、コード参照を消してからアーカイブする
- 削除はアーカイブ後に、人が確認してから行うプラグインは、依頼の文面に応じて手順書を選びます。ルールを文面で先に伝えておけば、Claudeがそれを前提にflag-createやflag-cleanupへ進みます。キーの命名規則は、flag-createの重複チェックと衝突しない形にそろえておくと、作成時のやり直しが減ります。
つまずきやすい点
接続エラーが出たら、まず/growthbook:gb-setupをやり直します。READMEによると、設定に問題があるとき、エラー表示はgb-setupに誘導する作りです。
並列に動かす手順書を多用すると、毎分60回の制限に当たりえます。ヘルパーは再試行しないため、429は利用者が見る形で表示されます。大きな棚卸しは、範囲を絞って小分けに頼むほうが確実です。
スキルがうまく見つからないときは、エージェントを再起動します。READMEには、スキルがすぐ表示されなければ再起動するよう書かれています。
プラグインの入れ方や配布の仕組み自体は、Claude Codeプラグイン完全ガイドにあります。同じ種類の実験基盤をつなぐ例としては、Confidenceプラグインが、MCPサーバー経由の別方式を取っています。
まとめ
GrowthBookプラグインの価値は、フラグを作る入口よりも、片付けの出口にあります。flag-cleanupがコード内の参照を先に消せるのは、Claude Codeがリポジトリを直接読めるからです。作る手間より放置の負債のほうが大きいチームほど、効果を実感しやすい構成です。
導入前に決めるのは2点です。専用トークンを発行すること、そして本番に効く操作をGrowthBook側の確認機能で保留にしておくこと。この2つがあれば、/growthbook:feature-flagsから小さく試せます。