Claude CodeのConfidenceプラグインでSpotifyの実験基盤にフラグを入れる

ConfidenceプラグインはSpotifyが配布する公式プラグインで、機能フラグと実験の基盤「Confidence」をClaude Codeから操作できます。フラグの作成・一覧・更新・ターゲティング・アーカイブに加え、Statsig・PostHog・Eppo・Optimizelyからの移行、アカウントの初期設定、イベント計装までが1つに入っています。

Confidenceは、OpenFeature標準の上に作られたSpotifyの機能フラグ・実験プラットフォームです。音楽を扱うSpotifyコネクタとは別物で、こちらはアプリのリリース制御と効果測定のための道具です。

Confidenceプラグインの中身と、できること

プラグインは3つの部品でできています。

• MCPサーバー2本:フラグ管理用のconfidence-flagsと、ドキュメント検索用のconfidence-docs
• スラッシュコマンド:/confidence:で始まる各コマンド
• スキル:移行やオンボーディングの手順書。Claudeが依頼内容に応じて自動で読み込む

5つのうち、フラグの操作とドキュメント検索はMCPサーバーが、移行とオンボーディングはスキルが受け持ちます。

コマンド一覧(READMEの表)は次のとおりです。

READMEのコマンド一覧には載っていませんが、リポジトリのcommands/にはinstrument-events、explore-metric、setup-session-recordingもあります。イベント計装の節で使います。

入れ方と、最初の接続

Claude Codeへの導入は1行です。

claude plugin install confidence

リポジトリを手元に置いて試すなら、claude --plugin-dir ./confidence-ai-pluginsで読み込めます。プラグインを入れずにスキルだけ欲しい場合はnpx skills add spotify/confidence-ai-pluginsが使えます。ただしこの方法ではMCPサーバーも/confidence:*コマンドも設定されません。READMEは、フラグ管理を呼ぶスキルが多いので、通常はフル導入を使うよう書いています。

MCPサーバーの接続先は次の2つです。

認証はブラウザのOAuthです。スキルの本文には、MCPが未認証なら/mcpを開いてconfidence-flagsの横の「Authenticate」を押すよう案内する記述があります。つながったかどうかは、「自分のフラグを一覧にして」と頼めば分かります。

まずは自然文でフラグを触る

READMEの使用例は、コマンドではなく普通の依頼文から始まります。

• 「List my feature flags」
• 「Create a flag called new-checkout with a boolean schema」
• 「create a feature flag for the new checkout flow」(マーケットプレイスのページ)

READMEの例のように、フラグ名と型(booleanなど)を添えて頼むと、条件が明確になります。

破壊的な操作を含むので、Claude Code側にも歯止めを置くと安心です。例えば次のような断片をCLAUDE.mdに入れる運用が考えられます(プロジェクトの規約に合わせて書き換えてください)。

## Confidence(フラグ運用)
- フラグを作る前に一覧を取り、同名・類似名がないか確認する
- アーカイブと本番環境のターゲティング変更は、実行前に対象を列挙して承認を取る
- フラグ名はkebab-caseで、機能名と用途が分かる名前にする

これはプラグインの機能ではなく、Claudeへの指示です。フラグの切り替えは本番の挙動に直結するため、承認の段を挟む形にしています。

移行は「計画してから実行」の3段階

移行コマンドは、PostHog・Eppo・Statsigでは「フラグの計画 → コードの計画 → 実行」の順に進みます。マーケットプレイスのページも、全ステップをレビューしてからコミットできると説明しています。

実行コマンドは次の形です。

/confidence:migrate-statsig plan flag
/confidence:migrate-statsig plan code
/confidence:migrate-statsig execute <plan-file>

Statsigの移行に必要なもの

StatsigにはClaude向けのMCPサーバーがないため、スキルはStatsigのConsole APIをcurlで直接呼びます。要るのはConsole APIキーです。SDK用のサーバーキー・クライアントキーでは動きません。取得場所はStatsigコンソールのProject Settings > API Keysで、console-で始まるキーを、読み取り権限付きで用意します。スキルはキーを環境変数STATSIG_API_KEYで受け取れます。

Confidence側は、confidence-flagsのMCPが認証済みであることが前提です。plan codeではconfidence-docsも使います。MCPでは表現しきれない構成(部分割り当ての実験、再利用セグメント、レイヤーの排他、ホールドアウト)を移す場合に限り、管理用REST APIのトークンも求められます。Confidenceの管理画面のAdmin > API Clientsでクライアントを作り、クライアントIDとシークレットでトークンを取得する流れです。

何が移り、何が移らないか

ConfidenceとStatsigでは割り当てに使うハッシュが違うため、同じ利用者を同じグループに留めたまま移すことはできません。そのためスキルは、すべての項目を次のように分類します。

除外した項目も、計画ファイルに区分と理由が1行ずつ残ります。実行中の実験が多い組織では、移行の第一弾が「安定ゲートだけ」になる点を見込んでおくと、計画の読み方が楽になります。

Optimizelyだけは段が増えます。フラグの前に、ユーザー・グループ・ロール・ポリシー・Flagクライアントを移す「access」の段があり、plan → adjust → executeの順で進みます。READMEによると、plan・adjustの間はConfidenceに何も書き込まれません。計画ファイルの招待や作成の項目にチェックを入れ、executeを実行して初めて、招待メールの送信などが行われます。招待の有効期間は7日です。

導入前の準備:アカウントとウェアハウス

Confidenceのアカウントがない場合は、/confidence:onboard-confidenceから始められます。セットアップウィザードに入り、最初の質問は「新しいアカウントを作るか、既存アカウントにサインインするか」の二択です。ウィザードの流れは、クライアント作成、フラグ作成、ターゲティング追加、解決テストの順です。

効果測定まで使うなら、データウェアハウスの接続が要ります。setup-warehouseは対象を尋ね、BigQuery・Snowflake・Databricks・Redshiftのいずれかの専用スキルに引き継ぎます。READMEはこの4つへの対応を挙げています。

イベント計装から指標づくりまで

フラグで出し分けたあとの「効果測定」を支えるのが、/confidence:instrument-eventsです。プロジェクトを読み、計測する価値のあるイベントと、それが支える指標を組にして提案します。

スキルの本文が重視するルールは3つあります。

• すべてのイベント定義に、エンティティ参照(entities/userのようなもの)を持つ文字列フィールドを少なくとも1つ付ける。無いとファクトテーブルが自動作成されず、指標に使えない
• イベント定義のIDは4〜63文字で、小文字・数字・ハイフンのみ
• 既存のtrack()呼び出しと照合し、定義済みのイベントを重複して作らない

イベント定義の例は次の形です(スキルの本文にある購入イベントの例を縮めたものです)。

{
  "user_id": {
    "stringSchema": {},
    "semanticType": {"entityReference": {"entity": "entities/user"}}
  },
  "amount": {"doubleSchema": {}},
  "currency": {"stringSchema": {}}
}

コードへの追加はconfidence.track()で行います。スキルは、OpenFeatureのclient.track()ではなくConfidence純正SDKのものを使うよう指示しています。理由として、OpenFeatureのトラッキング仕様がConfidenceのプロバイダーにまだ接続されていないことが書かれています。

最後にパイプラインを検証します。ウェアハウスの有無、イベント定義、ファクトテーブル、露出テーブルを順に調べ、希望すればアプリを起動して、イベントのpublishCountが増えるかも見ます。ウェアハウスにデータが届くまでは約1時間かかるという記述があります。指標の試算と作成は別のスキル/confidence:explore-metricの担当で、イベントや事実テーブルを渡すと、事前入力済みのMetric Explorerのリンクを作ります。

使う前に知っておきたい条件

READMEとスキルの本文から読み取れる、事前に押さえたい点です。

• 対応クライアントは、Claude Code、Cursor、Codex、Gemini CLI。MCP接続先は共通です
• 認証の経路が2つある:MCPのOAuthと、オンボーディングのスキルが使うブラウザのAuth0ログイン。後者は同梱のauth.pyを実行し、コールバック用にポート8084を使います。この経路では、Bashツールをサンドボックス無効で呼ぶ指示が書かれています
• スキルは進捗の計測イベントを送る指示を含んでいます。ステップ名、所要秒数、利用者の反応の自己評価、エラーコードなどをconfidence.devのイベント受信先へ送る内容で、同じ本文にユーザーへは触れない旨もあります。
• CHANGELOGの0.10.0(2026-09-29)に「privacy fixes」という項目があるので、導入時はそのバージョンのSKILL.mdで現状を読んでください。社内で外部送信を管理している場合は、導入前の確認項目になります
• plugin.jsonのversionは0.10.0、ライセンスはApache 2.0です

マーケットプレイスのページとREADMEには、Claudeのプラン条件の記載がありません。使うにはConfidence側のアカウントが要ります。その料金はConfidenceの契約に属し、両ページには載っていません。

つまずきやすい点

• 「MCPが見つからない」:/mcpでconfidence-flagsの認証状態を見る。getIdentityInfoが通らないと、イベントやウェアハウスの操作も進みません
• 移行計画に実験が出てこない:実行中の実験や通過率つきのルールは、既定で除外区分に入ります。除外区分の既定値は、スコープ確認の段で上書きできます
• イベントが集計に出ない:エンティティ参照の付け忘れが第一候補です。次にウェアハウス未設定、SDKのクライアントシークレット(CONFIDENCE_CLIENT_SECRET)未設定を見ます
• イベント定義の削除:削除すると名前が再利用できなくなり、削除済みの定義に送られたイベントは拒否されます。スキルは削除前に必ず確認を取る設計です

まとめ

Confidenceプラグインは、「フラグを作る」操作だけでなく、他社基盤からの計画つき移行と、イベント計装から指標づくりまでを1つの入口に集めています。自社でStatsigやPostHogを使っている場合は、plan flagで除外区分がどれだけ出るかを見るのが、移行の規模を測る最短の方法です。外部送信の扱いと認証経路は、導入前にスキルの本文で確かめられます。

同じ「計測する側」のプラグインとしては、Logfireプラグインの記事のようにPythonアプリのトレースを扱うものや、Dash0プラグインの記事のようにClaude Code自体のセッションをトレースするものがあります。LLMアプリの品質を測る側はDeepEvalプラグインの記事にあります。