次のような場合に使用: ユーザーが RevenueCat の実験（A/B テスト）の作成、準備、セットアップを依頼したり、その実験に使う複数のパターンやペイウォール（課金画面）の準備、実験の開始・一時停止・再開・終了を依頼したりするとき。RevenueCat MCP の実験ツールを通じて実行します。
Use when the user asks to create, prepare, or set up a RevenueCat experiment (A/B test), to prepare its variant offerings or paywalls, or to start, pause, resume, or stop an experiment via the RevenueCat MCP experiment tools
RevenueCat の実験は、2～4つのオファリング（販売プラン）を比較するものです。offering_a（基準）を、offering_b～offering_d（試験対象）と比較します。実験に参加した利用者には、プロジェクトの現在のオファリングではなく、割り当てられた試験版のオファリングが提供されます。実験を設定するには、各試験版に対してオファリングを1つずつ準備し、実験を下書き状態で作成します。
各ツールの正確なパラメータについては MCP ツール・スキーマを参照してください。create-experiment スキーマには、利用可能な実験タイプと推奨される主要指標・副次指標も記載されています。
試験版は、テスト対象の1つの側面を除いて同じに保ってください。そうしないと、結果がその変更に起因するものだと判断できません。たとえば、より低いサブスクリプション価格の影響を測定する場合、両方の試験版は同じペイウォール（購入画面）デザインとパッケージを使い、商品の価格だけを変える必要があります。
基準版。基準版が「本番環境で今日実行されている内容」である場合、現在のオファリング（list-offerings の is_current）を offering_a_id として直接渡してください。重複させないでください。基準版自体が本番環境に対して変更が必要な場合にのみ重複させます。
試験版。まず list-offerings で、試験版が配信すべき内容と一致するオファリングがすでに存在するかを確認し、重複させるのではなく再利用してください。そうでない場合は、それに最も近いオファリング（通常は基準版オファリング）のコピーから各試験版を始めてください。duplicate-offering はパッケージをコピー（既存の同じ商品を添付）し、ソースのオファリングにペイウォールがある場合は、新しい未公開の下書きとしてもコピーします。新しいオファリング（新しい paywall_id を含む）が返されます。source_paywall_version: published を渡して、下書き段階の未完成の編集ではなく、本番環境で利用者が見るペイウォールをコピーしてください。ソースペイウォールが公開されたことがない場合はこれは失敗するため、その場合のみデフォルト（draft）を使用してください。その後、テスト対象の1つの変更を適用します：
ペイウォール変更（コピー、レイアウト、行動喚起（ボタンのテキスト）、価格表示など）：これには、アプリが RevenueCat ペイウォールを使用する必要があります。ペイウォールはオファリングのオプションプロパティです。基準版オファリングにペイウォールがない場合（paywall_id が null）、アプリはコード内に独自のペイウォールをレンダリングするため、ペイウォール変更は RevenueCat ではなくアプリ内で行う必要があります。ユーザーに伝えてください。それ以外の場合は、revenuecat-paywall-design を読み込み、edit-paywall-ai でコピーされたペイウォールを編集します。目的の効果を測定するのに必要な最小限の変更のみをリクエストし、結果のペイウォールを確認して検証してください。
価格、試用期間、イントロダクトリーオファー（初期割引）の変更：これらはストア商品に属しているため、試験版オファリングは異なる商品が必要です。list-products で適切な商品がすでに存在するかを確認してください。不足している商品とそのストア対応版（revenuecat-store-state スキルを参照）のみを作成してください。その後、コピーされたオファリングのパッケージにそれらをスワップ（交換）してください：detach-products-from-package でコピーされた商品をデタッチ（切り離し）し、attach-products-to-package で新しい商品をアタッチ（追加）してください。
新規ペイウォール：include_paywall: false でオファリングを重複させ、revenuecat-paywall-design を読み込み、新しいオファリングの offering_id を使用して create-paywall-ai を呼び出し、生成されたドラフトが直接それに添付されるようにしてください。ペイウォールとオファリングは 1 対 1 の関係があります。どちらかの側がすでにペアになっている場合、attach-offering-to-paywall は失敗します。間違ったペアリングを解除するには detach-offering-from-paywall で解除してください（ペイウォールが公開されている場合は最初に非公開にしてください）。
試験版ペイウォールの公開。重複されたまたは新しく作成されたペイウォールは未公開のドラフトであり、試験版が提供するのは公開版のみです。前のステップで新しいペイウォールが作成された場合、実験開始前に publish-paywall で各試験版ペイウォールを公開してください。これは「積極的な公開をしない」というルールの例外ですが、安全です。試験版オファリングは現在のオファリングではないため、実験が登録を開始するまで、顧客はペイウォールを見ません。
create-experiment でドラフトを作成します：表示名、enrollment_percentage（登録割合）、試験版オファリング ID、experiment_type（実験タイプ）、仮説に一致する primary_metric（主要指標）と secondary_metrics（副次指標）、enrollment_mode（登録モード。ユーザーが既存利用者の含有を明示的に希望する場合を除き only_new）、および任意のターゲティングとメモ。実験の作成は実験を開始しません。ドラフトは update-experiment で調整します。
開始前に、各試験版を検証してください：試験版ペイウォールが公開されており、パッケージに意図した商品が含まれており、新しい商品がストアで利用可能です。
start-experiment は実際の利用者の登録を開始します。ユーザーの明示的な確認を得てからのみ実行してください。pause-experiment は登録を停止しますが、登録済みの利用者に試験版の提供とデータ収集は継続します。resume-experiment は登録を再開します。stop-experiment は終了状態です：登録済みの利用者はデフォルトのオファリングにフォールバック（戻す）され、実験は二度と再開できません。実験実行中に結果を解釈するには、revenuecat-experiment-analysis スキルを使用してください。
A RevenueCat experiment compares two to four offerings: offering_a (the control) against offering_b–offering_d (the treatments). Enrolled customers are served their variant's offering instead of the project's current offering. Setting up an experiment means preparing one offering per variant, then creating the experiment as a draft.
Refer to the MCP tool schemas for the exact parameters of each tool; the create-experiment schema also lists the available experiment types with their recommended primary and secondary metrics.
Keep the variants identical except for the one aspect under test, otherwise results cannot be attributed to the change. For example, when measuring the impact of a lower subscription price, both variants should share the same paywall design and packages, differing only in the price of the products.
Control. When the control variant is "what production does today", pass the current offering (is_current in list-offerings) directly as offering_a_id — do not duplicate it. Duplicate only when control itself needs changes relative to production.
Treatments. First check with list-offerings whether an offering already exists that matches what the treatment should serve, and reuse it instead of duplicating. Otherwise, start each treatment from a duplicate of the offering closest to it (usually the control offering). duplicate-offering copies the packages (attaching the same existing products) and, if the source offering has a paywall, also copies it as a new unpublished draft; it returns the new offering, including its new paywall_id. Pass source_paywall_version: published so the treatment copies the paywall customers see in production rather than unfinished draft edits; this fails when the source paywall was never published, so use the default (draft) only then. Then apply the one change under test:
paywall_id is null), the app renders its own paywall in code, so the paywall change has to be made in the app rather than through RevenueCat; tell the user. Otherwise, load revenuecat-paywall-design and edit the duplicated paywall with edit-paywall-ai. Request only the minimum changes required to measure the desired effect, and verify the result by looking at the resulting paywall.list-products whether suitable products already exist; create only the missing ones and their store counterparts (see the revenuecat-store-state skill). Then swap them into the duplicated offering's packages: detach the copied products with detach-products-from-package, then attach the new ones with attach-products-to-package.include_paywall: false, then load revenuecat-paywall-design and call create-paywall-ai with the new offering's offering_id so the generated draft is attached to it directly. A paywall and an offering pair 1:1 — attach-offering-to-paywall fails if either side is already paired; undo a wrong pairing with detach-offering-from-paywall (unpublish the paywall first if it is published).Publish treatment paywalls. A duplicated or newly created paywall is an unpublished draft, and a variant only serves the published version. If new paywalls were created in previous steps, publish each treatment paywall with publish-paywall before the experiment starts. This is the exception to the rule against proactive publishing, and it is safe: the treatment offering is not the current offering, so no customer sees the paywall until the experiment starts enrolling.
Create a draft with create-experiment: display name, enrollment_percentage, the variant offering IDs, experiment_type, a primary_metric (plus secondary_metrics) matching the hypothesis, enrollment_mode (only_new unless the user explicitly wants to include existing customers), and any targeting and notes. Creating never starts the experiment. Adjust a draft with update-experiment.
Before starting, verify each variant: treatment paywalls are published, packages contain the intended products, and any new products are available on the stores.
start-experiment begins enrolling real customers — only run it with the user's explicit confirmation.pause-experiment stops enrollment but keeps serving enrolled customers their variant and keeps collecting data.resume-experiment continues enrollment.stop-experiment is terminal: enrolled customers fall back to the default offering and the experiment can never be restarted.To interpret results once the experiment is running, use the revenuecat-experiment-analysis skill.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。