次のような場合に使用: ユーザーが 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を含む）が返されます。その後、テスト対象の1つの変更を適用してください。
ペイウォール変更（デザイン、レイアウト、行動喚起ボタン、価格表示など）: これにはアプリがRevenueCatペイウォール機能を使用する必要があります。ペイウォールはサービス内容のオプション属性であり、基準グループのサービス内容がペイウォールを持たない場合（paywall_idがnull）は例外です。それ以外の場合は、edit-paywall-aiで複製されたペイウォールを編集してください。目的の効果を測定するために必要な最小限の変更だけをリクエストし、結果のペイウォールを見て検証してください。
料金、試用期間、または導入オファー（初回の割引など）の変更: これらはストア製品に存在するため、試験グループのサービス内容は異なる製品が必要です。list-productsで適切な製品が既に存在するか確認してください。存在しない製品とそのストア相当物のみを作成し（revenuecat-store-stateスキルを参照）、複製されたサービス内容のパッケージに置き換えてください。detach-products-from-packageでコピーされた製品を削除し、attach-products-to-packageで新しいものを追加してください。
まったく新しいペイウォール: include_paywall: falseでサービス内容を複製し、新しいサービス内容の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. Then apply the one change under test:
paywall_id is null). Otherwise, 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 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 による自動翻訳です。