revenuecat-paywall-design について
RevenueCatのダッシュボード用ペイウォールを作成、複製、編集、監査、公開するスキルです。設定確認やスクリーンショット検査にCLIとMCPの手順を組み合わせ、ドラフトと公開済みの状態を区別します。
主な機能
- 01ペイウォールのドラフト作成と編集
- 02既存ペイウォールの複製
- 03設定とスクリーンショットの確認
- 04コンバージョンに関わるデザインの監査
- 05明示的な依頼に応じた公開
活用シーン
- 01アプリのオファリング向けドラフト作成
- 02公開済みペイウォールを複製して新デザインを作成
- 03ペイウォールの設定と外観を確認
- 04公開前のペイウォール監査
MCP 対応
RevenueCat MCPツールでペイウォール設定の取得、スクリーンショットの描画、作成・編集、複製を行います。公開にはスキルで説明されているCLIの手順を利用します。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ revenuecat/ ai-toolkit --skill revenuecat-paywall-designインストール後、Claude Code で/revenuecat-paywall-designを入力して読み込まれたか確認します。
詳細
RevenueCat ペイウォールの設計と編集
このスキルでは、ダッシュボードのペイウォールの作成、複製、編集、監査、公開を扱います。RevenueCatUI で設定済みのペイウォールをアプリに表示するには、代わりに revenuecat-paywall を使用してください。
ペイウォールについてアドバイスするには、ペイウォールが必要です。paywall_id が null の Offering には RevenueCat のペイウォールがありません。購入 UI はクライアント側にあり、こちらからは見えません。その旨を伝え、RevenueCat が実際に制御する範囲に限ってアドバイスしてください。
rc CLI 経由(revenuecat-cli スキルを参照):rc paywalls generate --prompt "..."、rc paywalls edit --prompt "..."、rc paywalls rewind --session <id>、rc paywalls publish、rc paywalls show。スクリーンショットや構造化された get-paywall の読み取りが必要な場合は、以下の MCP を優先してください。
メディアとフォント
MCP ではプロジェクトの Media Gallery やフォントライブラリにファイルをアップロードできません。サーバーはリモートにあり、ユーザーのディスクを読み取れないためです。シェルを使用できる場合は、ディスク上にファイルを書き込むか生成してから、CLI でアップロードしてください。最初に revenuecat-cli スキルのインストールとログインの確認を実行してください。アップロードのためにブラウザーでダッシュボードを操作しないでください。
- 画像:
rc media-assets upload <file>(jpg/png/webp/avif/heic/heif、最大 2 MiB)。rc media-assets listでギャラリー内の既存アイテムを確認できます。 - フォント:
rc fonts upload <file>(ttf/otf、最大 5 MiB)。アップロード済みフォントはrc fonts listで確認できます。
フラグは rc schema media-assets upload / rc schema fonts upload で確認してください。
シェルを使用できない場合は、ユーザー自身にアップロードしてもらいます。実行する rc コマンドを伝えるか、RevenueCat ダッシュボードでアップロードしてもらってください。
create-paywall-ai / edit-paywall-ai は、編集の一環としてヒーロー画像や背景画像を生成できます。これは Media Gallery へのアップロードではありません。再利用可能なプロジェクトアセットが必要な場合は、rc media-assets upload でアップロードしてください。
ペイウォールの評価
RevenueCat ペイウォールを評価する際は、render-paywall-screenshot を使用して、スクロールせずに表示されるコンテンツの静的レンダリングを確認してください。このレンダリングはあなたが確認するためのものであり、ユーザーに表示するものではありません。
特定済みのペイウォールについて質問された場合は、質問に応じてツールを使い分けてください。
- 正確な設定(デフォルトパッケージ、コンポーネントのバインディング、オファー条件付きコンテンツ):
expand: ["components"]を指定してget-paywallを使用します。この expand がない場合、コンポーネント設定は省略されます。 - 視覚的な確認:
render-paywall-screenshot。スクリーンショットでは、設定に依存する詳細を確認できません。 - ツールの回答とユーザーが見た内容の報告が食い違う場合は、ユーザーの観察に異議を唱える前に
get-paywallで確認してください。get-paywallを利用できない場合は、異議を唱えるのではなく、確認できなかったと伝えてください。
get-paywall と render-paywall-screenshot は、下書きがある場合は下書きを、ない場合は公開済みバージョンを使用し、1 つのペイウォールのみを対象とします。ワークフローや複数ページのペイウォールは対象外です。特定のペイウォールに関するものではない一般的なペイウォールのアドバイスには、これらのツールを呼び出さずに直接回答してください。
get-paywall が失敗しても、スクリーンショットではっきり確認できる内容については報告してかまいません。設定に依存する詳細は確認できていないと明示してください。スクリーンショットに基づく推測で、構造を考慮した分析を黙って置き換えないでください。
編集
ユーザーから既存のペイウォールの編集を明示的に依頼された場合は、edit-paywall-ai を使用してください。このツールは非同期タスクを開始します。返されたタスク ID を使って、完了または失敗するまで約 10~15 秒ごとに get-paywall-ai-task をポーリングしてください。同じ依頼に対して、タスクが失敗しない限り edit-paywall-ai を再度呼び出さないでください。画像生成を伴う編集には数分かかる場合があります。
ユーザーが手動での編集を希望する場合は、ペイウォールビルダーへのリンクを案内してください。
https://app.revenuecat.com/projects/{project id without leading proj prefix}/paywalls/{paywall ID starting with pw}/builder
ビルダーの左側のツールバーには会話型 AI エディターもありますが、そこへ直接リンクすることはできません。
ユーザーが現在のメッセージに画像を添付しており、ツールのスキーマが画像を受け付ける場合は、画像をそのまま渡し、どのように使用すべきかをエディターに伝えてください。視覚的な詳細を不必要に再現しないでください。以前のメッセージの画像は引き継がれません。ユーザーにもう一度添付してもらってください。
MCP に復元バージョンのツールはありません。MCP 経由で行った編集を元に戻すようユーザーから依頼された場合は、ペイウォールエディターで古いバージョンを復元できると伝えてください。CLI を使った場合は、rc paywalls rewind --session <id> でエディターの最後の操作を元に戻せます。復元しても公開はされません。
複製
既存のペイウォールをコピー、複製、または再現したペイウォールをユーザーから依頼された場合は、create-paywall-ai ではなく duplicate-paywall を使用してください。create-paywall-ai は空白のキャンバスとテキストプロンプトをもとにデザインするため、プロンプトに記述された内容だけが再現されます。画像、正確なコンポーネント構成、記載されていない内容はコピーされず、新たに生成されます。
duplicate-paywall はソースのペイウォールを、新しい未公開のペイウォールにコピーします。デフォルトでは現在の下書きをコピーし、source_version: published を渡すと公開済みバージョンをコピーします(ペイウォールが一度も公開されていない場合は失敗します)。どちらをコピーするかは慎重に選んでください。
- ソースに公開済みバージョンがある場合(
get-paywallのpublished_atが null ではない場合)は、source_version: publishedを渡してください。ユーザーが名前やリンクを指定してペイウォールに言及したときは、こちらを指しているためです。 - 下書きがデフォルトで選ばれるのは、ユーザーが未公開で作業中の編集内容をコピーするよう明示的に依頼した場合、またはソースが一度も公開されていない場合に限ります。
どのバージョンをコピーしたかを伝えてください。offering(lookup_key と display_name)を渡すと、ソースのペイウォールのオファリングも複製されます。対象はパッケージのみで、コピーをそのオファリングに紐付けます。コピーを紐付けない場合は offering を省略してください。ユーザーの依頼がオファリングを起点としており、同じペイウォールを持つ2つ目のオファリングを作成する場合は、代わりに duplicate-offering を使用してください。このツールはパッケージと紐付けられたペイウォールをまとめてコピーします。その後、edit-paywall-ai で差分を適用し、新しいデザインではなく元のコピーとして結果を説明してください。
複製はすべてのペイウォールに対応しているわけではなく、複数ページのペイウォールはサポートされていません。複製を利用できない場合や失敗した場合は、create-paywall-ai に切り替えてもかまいません。ただし、その場合はユーザーに、これはコピーではなく説明に基づく再構成であり、画像などの詳細は異なると伝えてください。
作成
ユーザーから新しいペイウォールの作成を依頼された場合は、create-paywall-aiを使用してドラフトのみを作成します。非同期タスクが開始されます。成功または失敗するまで、約30秒ごとにget-paywall-ai-taskを呼び出して状態を確認します。画像の多いペイウォールの作成には5〜10分かかる場合があります。同じ依頼でタスクが失敗しない限り、create-paywall-aiを再度呼び出さないでください。
ユーザーが既存のオファリングを指定した場合、または適切なオファリングを確実に特定できる場合は、そのオファリング用にペイウォールを作成してください。ユーザーがオファリングを指定しない場合は、まずlist-offerings、get-offering、get-offering-prices、list-products、list-apps、get-app、get-project-ui-config、list-paywallsを使用して、アプリ、製品、価格設定、ブランドの慣例、既存のペイウォールを把握してください。アプリやコードベースを調べ、推測できる場合は、簡潔なcodebase_context(プレミアム機能、ブランドカラー、ビジュアルの方向性、トーン、製品、対象ユーザー)とapp_contextを渡してください。明確に適合するものがあれば、最適なオファリングを提案してください。ユーザーが断った場合、または適切なオファリングが明確でない場合は、どのオファリングにも関連付けられていないドラフトを作成します。
1つのオファリングに関連付けられるRevenueCatペイウォールは最大1つです。オファリングにpaywall_idが設定されている場合、そのオファリングをoffering_idとしてcreate-paywall-aiに渡してはいけません。すでにペイウォールがあることを説明し、次の中から適切な選択肢を選んでください。
- 新しいペイウォールを既存のものと同じ見た目にする場合は、複製します。ユーザーが「同じ」「〜のように」「コピー」「ミラー」と指定した場合は、常にこれが適切な選択肢です。
- 既存のペイウォールを変更する場合は、
edit-paywall-aiを使用します。 - 新しいペイウォールがまったく異なるデザインの場合は、別のオファリングまたは未関連付けのオファリングを選ぶか、オファリングの製品と価格設定を参考に、どのオファリングにも関連付けないドラフトを作成します。
複製の依頼に応える方法として、create-paywall-aiでオファリングに関連付けられていないドラフトを作成することを提案してはいけません。
収集したコンテキストをプロンプトに含めます。アプリの概要、対象ユーザー、中核的な価値提案、製品の期間、トライアル、価格、既存のペイウォールのパターン、ブランドカラーやフォント、ユーザーが指定したデザインの方向性などです。一度の生成でドラフトを作成できるよう、プロンプトを具体的にしてください。ツールに公開を依頼してはいけません。
複製または新規作成したペイウォールは未公開のドラフトです。ユーザーから明示的に依頼されない限り公開してはいけません。ただし、実験用のトリートメントオファリングを準備する場合は除きます(revenuecat-experimentsを参照)。
全般的なアイデアとガイダンス
アイデアの収集
RevenueCatのブログとドキュメントで、ペイウォールのデザインとベストプラクティスを調べます。Markdownドキュメントは、ページURLの末尾に.mdを付けたURLで参照できます。
禁止されている手法
AppleのApp Reviewガイドラインは厳格です。ベストプラクティスとしてよく紹介される手法でも、アップデートの却下やストアからの削除につながる場合があります。
- トライアルの切り替え。 トライアルを有効化または無効化する切り替え機能です。Appleはこれを誤解を招くものとして却下します。
- 閉じるボタンの表示遅延。 数秒間閉じられない、閉じることができるペイウォールです。Appleはこれを誤解を招くものと見なします。
- 閉じるとき/購入キャンセル時の2つ目のオファー。 4つの中で最も意図が不明瞭な手法です。キャンセル後にまったく同じ製品を表示することは、望まない購入へユーザーを誘導するものとして却下された例があります。
- アプリ内でのIAP以外のデジタル商品。 デジタル商品の販売に、アプリ内でStripeなどのIAP以外のSDKやアプリ内ウェブビューを使用することです。外部ブラウザーでウェブ購入ページへのリンクを開く方法は別の(米国向けの)選択肢であり、購入はアプリ内で行ってはいけません。
ペイウォールの表示場所
オンボーディングの最初や最後、機能の利用制限時など、さまざまな場所で試してください。オンボーディング中のペイウォールは非常に高い効果が得られる傾向があります。離脱したユーザーがまだおらず、ダウンロード直後は購入意欲が高いため、見込み顧客を最も多く獲得できます。
常に実験する
ペイウォールのデザインによって結果は大きく変わります。継続的にテストしてください。1日あたり数千人の新規ユーザーがいる場合、RevenueCat ExperimentsによるA/Bテストが最適な検証方法です。1日あたり数百人の場合でも、テストから傾向を把握できます。それより少ない場合は、リリースして時間の経過に伴うコンバージョンを観察してください。テストを設定するには、revenuecat-experimentsスキルを使用します。
既存のペイウォールデザインの監査
ペイウォールを分析し、コンバージョン上の問題を特定します。美的な一貫性とコンバージョンが相反する場合は、コンバージョンを優先してください。影響の大きい順に監査します。
視覚的な問題(最も影響が大きい — まずここから修正)
CTA ボタン — 最も影響の大きい要素です。最初に対応してください。
- CTA の色が最優先事項です。 CTA ボタンの背景色を確認し、次にアイコン、バッジ、枠線、カードのアクセントなど、色の付いた要素をすべて確認してください。CTA がそれらのいずれかと同じ色相なら、ページ内のほかの要素で使われていない、対照的な色に変更する必要があります。ページのアクセントカラーに埋もれる CTA は、コンバージョンを損ないます。
- CTA の文言が一般的(「続ける」「登録する」など)なら、具体的で行動を促す表現(例:「年間プランを始める」「無制限で利用する」)にする必要があります。
- 無料トライアルがあるのに CTA にその記載がない場合は、トライアルを示す文言(例:「無料トライアルを始める」「無料で試す」)を CTA に含めてください。トライアルの情報が小さな文字でしか表示されていないと、コンバージョンの機会を逃します。
プランカードの差別化
- おすすめのプランは、ひと目でわかるようにする必要があります。次のうち少なくとも 2 つを適用してください。背景色を変える、色付きの枠線を付ける、「最もお得」/「人気No.1」のバッジを付ける、カードを大きくする/浮き上がらせる。控えめな枠線の変更だけでは不十分です。
- デフォルトで選択されているプランがない場合は、設定してください。
- カードの見た目が同等だと、選択に迷いが生じます。おすすめのプランを差別化してください。
- バッジがテキスト、選択インジケーター、またはほかのコンテンツに重なる場合は、位置を調整してください。
価格のアンカリング — 複数のプランがある場合に必須です。
- 節約額がすぐにわからない場合(取り消し線付きの価格、「X% 割引」、1 日あたりの比較がない場合)、おすすめのプランに節約を示す情報を追加してください。
- 情報は具体的である必要があります。「年間払いでお得」のような曖昧な表現では不十分です。実際の数値を表示してください。割引額、無料期間の訴求、期間あたりの価格比較などを使います。割引率や節約額を固定値として記述しないでください。
- 明確なアンカリング情報を 1 つだけ使ってください。取り消し線付きの価格、節約額バッジ、割引額、元の価格を重ねると、視覚的なノイズが生じます。
価格の視認性。 すべてのパッケージカードに価格を表示する必要があります。
コンテンツの削減。 見出しからパッケージ/CTA までのコンテンツ行数を数えてください。4~5 行を超える場合は、優先度の低いものを削除します。ファーストビュー内の各行が CTA と注意を奪い合います。
レイアウト。 パッケージと CTA はファーストビュー内に配置する必要があります。購入操作(できればパッケージも)がスクロール位置にかかわらず常に表示される状態を保つのが、最も効果的なパターンです。購入ボタンやプライバシーフッターは削除しないでください。
- パッケージ群と購入ボタンは隣接させてください。その間にあるコンテンツは移動してください。
- パッケージと購入ボタンの間に、目に見える間隔(少なくとも 12px)を設けてください。
信頼につながる情報 — 必須です。すべてのペイウォールで、購入ボタンの下(ボタンとプライバシーフッターの間)に、安心感を与える短い文言を表示してください。「いつでも解約可能」「契約の縛りなし」、トライアルの利用条件などです。順序は、パッケージ → 購入ボタン → 安心感を与える文言 → プライバシーフッターです。無料トライアルがある場合は、CTA の近くにトライアルの利用条件(例:「7 日間の無料トライアル、その後は月額 $X」)を表示してください。
トライアルの表示(無料トライアルがある場合)
- CTA にトライアルについて記載してください。「登録する」よりも「無料トライアルを始める」のほうがコンバージョンにつながります。トライアルの詳細を小さな文字で表示するだけでは不十分です。
- トライアルについては、見出し、CTA、またはその両方に記載してください。利用規約にだけ記載するのは避けてください。
- 複数日(7 日以上)のトライアルで、タイムライン形式を使っている場合は、各段階が明確か確認してください。開始日、リマインダーの日付、請求日を示します。
- トライアルの利用条件(期間、終了後の価格)がどこにも表示されていない場合は、CTA の近くに追加してください。
アンチパターンのチェック
- 汎用的な CTA コピー:「Subscribe」「Continue」「Choose」では、ユーザーが何を得られるかではなく、何をすべきかを伝えています。「行動+メリット」に書き換えてください。
- 複数のプランカードに同一の機能リストを掲載:重複を削除してください。比較するのは価格だけにします。
- マイナス面だけを強調した価値提案:「広告なし、中断なし、制限なし」では、なくなるものを売ることになります。一部でも、ユーザーが得られるものを伝える内容に書き換えてください。
- 主要コンテンツとして掲載された法的な文言:利用規約や更新ポリシーがセールスポイントを埋もれさせている場合は、リンクの先に移してください。プライバシーフッターには適用されません。
- CTA ボタンがない。
- 利用規約とプライバシーポリシーへのリンクを含むプライバシーフッターがない — App Store のコンプライアンス要件です。
コピーの問題(最後に修正してください)
- 汎用的、または機能を中心としたコピー → 成果を中心としたコピー。「すべての機能にアクセス」→「どんな言語もマスター」。
- 2 行を超える段落は短くするか、箇条書きにしてください。
- 製品を説明する見出し → ユーザーに語りかける見出し。「AI 搭載の写真編集アプリ」→「どんな写真も見違えるほど美しく」。