Statsig MCPサーバーでフラグと実験をClaude Codeから操作する
Statsig公式のMCPサーバーをOAuthまたはConsole APIキーでClaude Codeに接続し、実験・ゲート・レイヤーの操作とReviewsの承認フローを会話から使う手順をまとめます。
Statsigは、フィーチャーフラグ管理とA/Bテストの実験基盤を1つのコンソールにまとめたプラットフォームです。公式のMCPサーバーはhttps://api.statsig.com/v1/mcpにホストされたHTTPエンドポイント1つだけで、OAuthまたはConsole APIキーで認証します。Claude Codeから接続すると、ゲートや実験の作成・確認、陳腐化したフラグの洗い出しまでを会話の中で扱えます。
Claude Codeへの接続
Claude CodeでのStatsig MCPサーバー接続は、OAuthを使うHTTPトランスポートが標準の経路です。次のコマンドを実行します。
claude mcp add --transport http statsig https://api.statsig.com/v1/mcpこのコマンドはStatsig MCPサーバーをHTTPトランスポート・OAuth認証で登録するだけで、この時点では認証は完了していません。続けてClaude Code内で/mcpを実行し、表示される手順に従います。ブラウザが自動で開き、Statsigアカウントへのサインインとプロジェクトへのアクセス許可を求められます。許可するとClaude Codeが認証情報を保存し、次回以降のセッションでも再認証なしで使えます。
注意点として、MCP OAuthが使えるのはPersonal Console API Keyに限られます。組織のオーナーがこの権限を有効にしていない場合、OAuthでの認証自体が成立しません。事前にStatsigのOrganization設定でPersonal Console API Keysの作成が許可されているかを確認します。
OAuthを使わず、Console APIキーで直接認証する方法もあります。
claude mcp add --transport http statsig-local https://api.statsig.com/v1/mcp \
--header "statsig-api-key: console-YOUR-CONSOLE-API-KEY"サーバー名をstatsig-localとしているのは公式ドキュメントの命名で、OAuth接続のstatsigと区別するためです。名前自体は任意に変更できますが、両方を同時に登録すると同じ接続先が2つ並ぶため、どちらか一方の運用に統一します。Console APIキーはconsole.statsig.com/api_keysで発行し、読み取り専用キーは閲覧のみ、書き込み権限を持つキーは変更操作まで実行できます。
Claude.aiやClaude DesktopからStatsigのデータを扱いたい場合は、Settings → Connectors → Add custom connectorで同じURL(https://api.statsig.com/v1/mcp)をカスタムconnectorとして追加します。接続先のサーバー実体はどの面から使っても同じ1つです。
接続を確認する
登録後は次の手順で動作を確認します。
- Claude Codeを開く
- 「実験の一覧を見せて」または「フィーチャーフラグの一覧を見せて」と聞く
- Statsigのデータが返ってくることを確認する
応答が返らない場合は、Claude Codeのバージョンが最新か、StatsigアカウントのAPI権限が足りているか、サーバーURLがhttps://api.statsig.com/v1/mcpと一致しているかを順に確認します。それでも解決しなければ、登録コマンドを再実行します。
Claude Codeでの具体的な聞き方
接続後は、次のような聞き方でそのままツール呼び出しにつながります。
- 実験の状況を聞く: 「いま動いている実験は?」
- ゲートを一覧する: 「自分のフィーチャーフラグを全部見せて」
- 詳細を確認する: 「
new-featureゲートの設定を見せて」 - エンティティを作る: 「
checkout-testという実験を作って」
自然文の指示がそのままGet_List_of_ExperimentsやCreate_Gateといった個別ツールの呼び出しに変換されるため、コンソールの画面を開かずに、いま追っている作業の文脈の中で状態を確認できます。
使えるツールの全体像
Statsig MCPサーバーが提供するツールは11のカテゴリに分かれます。
| カテゴリ | 主なツール | できること |
|---|---|---|
| Audit Logs | 主なツールGet_Audit_Logs | できること監査ログの一覧取得(ID・期間・タグで絞り込み) |
| Dynamic Configs | 主なツールCreate/Get/Update_Dynamic_Config等 | できること動的設定の作成・取得・更新・バージョン履歴確認 |
| Experiments | 主なツールCreate/Get/Update_Experiment等 | できることA/Bテストの作成・結果取得・メトリクス別の分析 |
| Autotunes | 主なツールCreate_Autotune | できること多腕バンディット型の自動最適化実験を作成(既定は下書き) |
| Gates | 主なツールCreate/Get/Update_Gate等 | できることフィーチャーフラグの作成・詳細取得・結果確認 |
| Layers | 主なツールCreate/Get/Update_Layer | できることレイヤーの作成・パラメータやメタデータの取得・全体設定の置き換え |
| Metrics | 主なツールGet_List_of_Metrics等 | できることメトリクス定義の一覧・詳細取得 |
| Parameter Stores | 主なツールCreate/Update/Delete_Param_Store | できることパラメータストアの作成・更新・削除 |
| Segments | 主なツールCreate/Update_Segment等 | できることユーザーセグメントの作成・更新 |
| Reviews | 主なツールCreate/Approve/Reject/Commit_*_Review | できることゲート・実験・Autotuneの変更を承認フローに乗せる |
| Logs and Observability | 主なツールQuery_Logs_Explorer等 | できること生ログの検索とパターンのクラスタリング |
Experimentsのツール群には、レスポンスを絞り込むfieldsパラメータがあります。必要なフィールドだけを指定すると、コンテキスト消費を最大95〜99%削減できると公式ドキュメントに明記されています。実験の詳細を何度も参照する運用では、この絞り込みが効きます。
Autotuneは多腕バンディット型の自動最適化実験です。Create_Autotuneツールに腕(arms)・成功イベント・探索期間と貢献期間(exploration/attribution windows)・勝者判定のしきい値を伝えると、Claudeがそれらを踏まえてAutotuneを組み立てます。作成されるのは既定で下書き状態で、実際にトラフィックを配分するにはコンソール側で明示的に開始する操作が別途必要です。作成前には必ず確認を求められるため、意図しないAutotuneがいきなり動き出すことはありません。
Segmentsはid_list(IDリスト)・rule_based(ルールベース)・analysis_list・user_store_id_listの4種類のセグメントタイプに対応します。条件付きセグメントのルール更新や、ユーザーストア・IDリストへのID追加もMCP経由で行え、対象ユーザー群の定義を実験やゲートのターゲティングと同じ会話の中で調整できます。
読み取り専用と書き込みの権限差
Statsig MCPサーバーはGETとPOSTの両方に対応します。読み取り専用ユーザーは全ての読み取りツールを使えますが、書き込みツールには書き込み権限を持つAPIキーが必要です。OAuth接続でもConsole APIキー接続でも、この権限はStatsig側のキー・ロール設定がそのまま反映されます。
変更を即座に反映させたくない場合は、Reviewsのツール群が使えます。ゲート・実験・Autotuneの変更をレビュー申請として作成し、承認(Approve)・却下(Reject)・コミット(Commit)・取り消し(Cancel)まで一連の操作をMCP経由で行えます。書き込み権限を持つユーザーでも、変更を直接適用せずレビューを経由する運用にすれば、Claude Codeが作った変更案を人が確認してから反映する流れを作れます。レビューの対象ごとに、承認資格を持つユーザーを取得するツール(Get_Gate_Eligible_Reviewers等)も用意されており、誰に承認を依頼すればよいかもMCP経由で確認できます。
使い方の例 — 陳腐化したフラグのクリーンアップ
公式ドキュメントは代表的な使い方として、陳腐化した(stale)フィーチャーゲートのコードベースからの除去を挙げています。type="STALE"のゲートを一覧し、該当のフラグ名をコードベースからgrepで探し、そのゲート呼び出しを固定値の挙動に書き換えるという流れです。公式のプロンプト例では、一度に1つのゲートだけを対象にすること、単純にtrue/falseへ置き換えるのではなく呼び出し元のロジックを追跡して書き換えること、コメントやデバッグ文を残さないことが条件として明記されています。
このほか、コンソールの情報をIDEのワークフロー内で要約する使い方や、複数のゲートをまとめて作成・削除しつつ対応するコード変更までを一括で行う使い方が公式に挙げられています。
LaunchDarklyのMCPサーバーとの違い
フィーチャーフラグ系のMCPサーバーはStatsigだけではありません。LaunchDarklyも公式のホスト型MCPサーバーを提供しており、両者の設計には違いがあります。
| 観点 | Statsig MCP | LaunchDarkly MCP |
|---|---|---|
| 対象範囲 | Statsig MCP実験・ゲート・レイヤー・セグメント・パラメータストア・監査ログ・生ログ | LaunchDarkly MCPフィーチャー管理・AgentControl設定・オブザーバビリティ(ログ/トレース/エラー) |
| 承認フロー | Statsig MCPReviewsツールで変更を申請・承認・コミット | LaunchDarkly MCP公式ドキュメントに承認フローの言及なし |
| 定型ワークフロー | Statsig MCP例示プロンプト(stale gate cleanupなど)をユーザー側で用意 | LaunchDarkly MCPインストール可能な公式Agent Skills(npx skills add launchdarkly/agent-skills)として配布 |
| 導入経路 | Statsig MCPclaude mcp addまたは.mcp.jsonへの手動追加 | LaunchDarkly MCP専用インストールページからプロバイダを選ぶ |
LaunchDarklyはフラグ削除の安全性をsafe/caution/not-readyの3段階で判定する専用ツールとAgent Skillsを組み合わせ、クリーンアップの手順そのものを配布パッケージとして提供します。Statsigは同等の作業をプロンプト例として示すに留まり、手順の実装はユーザー側のプロンプト設計に委ねられます。Reviewsによる承認フローを重視するか、配布可能な定型ワークフローを重視するかで選択が分かれます。
よくあるつまずき
statsigとstatsig-localを混同する: 公式ドキュメントの命名では、OAuth接続をstatsig、APIキー接続をstatsig-localとしています。名前は変更可能ですが、両方を同時に登録すると同じサーバーへの接続が2つ並ぶため、どちらか一方に統一します- 書き込みツールが拒否される: 読み取り専用のAPIキーやスコープでは、Create・Update・Delete系のツールがStatsig側で拒否されます。書き込みが必要な操作は、書き込み権限のあるキーで再接続します
- OAuthが使えない: MCP OAuthはPersonal Console API Keyの発行が組織で許可されている場合のみ動作します。許可されていなければOrganization設定を確認するか、APIキー方式に切り替えます
--headerの構文を誤る: APIキー接続は--header "statsig-api-key: console-YOUR-CONSOLE-API-KEY"という1つのヘッダー文字列で渡します。キー名はstatsig-api-keyで固定です
まとめ
Statsig MCPサーバーはhttps://api.statsig.com/v1/mcpの1エンドポイントにOAuthまたはConsole APIキーで接続するだけで、実験・ゲート・レイヤー・セグメントの操作からReviewsによる承認フローまでを会話から扱えます。読み取りは権限を問わず使え、書き込みはAPIキーやOAuthスコープの権限がそのまま反映されます。Claude CodeでのMCP登録の基本や認証方式の全体像はClaude Code MCP設定ガイド、OAuthスコープの考え方はMCPセキュリティガイド、同じくホスト型1系統にOAuthで繋ぐ構成の例はTurso MCPサーバーでOAuth接続のエッジSQLiteを管理するで扱っています。