プレースメントをフローに移行するエージェントスキル
migrate-placements スキルは、ペイウォールで動作するアプリをフローに移行します。AI コーディングツールをあなたのアカウントに向けると、Adapty CLI を通じてすべてのプレースメントを読み取り、移行に必要なフロー数を算出し、移行対象の各ペイウォールプレースメントに対して新しいフロープレースメントを作成します。返ってくるのは、古いプレースメント ID から新しいプレースメント ID への対応表と、アプリ側で変更が必要な1つの呼び出しです。
プレースメントはフローに変換されるのではなく、新たに作成されます。 プレースメントのコンテンツタイプは作成時に固定されるため、ペイウォールのプレースメントをフローのプレースメントに変更することはできません。詳しくはフロー用の新しいプレースメントを作成するをご覧ください。新しいフローのプレースメントは、置き換えるペイウォールのプレースメントと並行して動作し、アプリの更新がリリースされるまで古いプレースメントは引き続き機能します。
このスキルはフローのコンテンツを設計しません（それは flow-generator スキル の役割です）。また、アプリのコードを記述することもありません（それは各プラットフォームの SDK インテグレーションスキル が担当します）。このスキルはペイウォールのプレースメントを読み取るだけで、編集は行いません。
始める前に
- スキルをサポートするAIコーディングツール: Claude Code、GitHub Copilot CLI、OpenAI Codex、Gemini CLI のいずれかが使えます。
- 移行対象の各ペイウォールに対応するフロー、または取得の計画: スキルはペイウォールごとにフローの出所を尋ねます。回答の一つとして、ダッシュボード上でクリックする方法があります。詳しくはフローのコンテンツの出所をご覧ください。
- ロードマップへの Adapty SDK v4 の組み込み: フローは SDK v4 以降でのみ描画されるため、移行はアプリのリリースをもって完了します。そのリリースがリリースされるまで、スキルが作成したものはユーザーに届きません。
スキルをインストールする
migrate-placements は adapty-skills プラグイン（adaptyteam/adapty-skills）に含まれており、flow-generator や flow-audit と同梱されています。1回インストールするだけで、プラグイン内のすべてのスキルが使えます。
別の Adapty スキル用にプラグインをインストール済みですか？このスキルも既に入っています。 プラグインは自動更新されるため、次のセッションから migrate-placements がすぐに使えます。何も実行する必要はありません。
Claude Code に初めてインストールするには：
claude plugin marketplace add adaptyteam/adapty-skills
claude plugin install adapty-skills@adapty/reload-plugins を実行してスキルを有効化してください。その他の AI コーディングツールの場合は、flow-generator のインストール手順に従ってください — 同じリポジトリ、同じコマンドです。これらの方法ではプラグインをインストールする代わりにスキルをコピーするため、前回のインストール以降に追加されたスキルを取得するには再実行が必要です。
その後、スラッシュコマンドをスキルにマッピングするツールでは /migrate-placements、そうでないツールでは「Use the migrate-placements skill」と入力してください。
プロンプトの例
ユーザーに配信しているプレースメントを移行する
アプリのアクティブなペイウォールのプレースメントをフローに移行してください。
非アクティブなものは今回スキップして、除外した数を教えてください。すでに変換済みのフローを再利用する
ペイウォールのプレースメントをフローに移行してください。すでに3つのペイウォールを
「新しいビルダーに移動」で変換済みです。新たにビルドせず、そのフローを再利用してください。静かなプレースメントで先にリハーサルする
ユーザーへの影響なしに全体の動作を確認できるよう、まず非アクティブな
ペイウォールのプレースメントから始め、その後ライブのものを移行してください。アプリの一部エリアのみを移行する
Migrate only the four onboarding placements in my app, not the in-app upsells.
Show me the placement IDs you'd create before you create anything.仕組み
8つのフェーズがあり、実際にアカウントに書き込みを行うのは第7フェーズだけです。
- 解決とプローブ。 Adapty CLI をインストールまたは更新し、Adapty へのログインを確認し、アプリ ID を読み取ります。
- インベントリ。 アプリ内のすべてのプレースメントを読み取ります。最初のページを信頼するのではなく、リストの末尾までページングします。
- 分類とグループ化。 各オーディエンスを「移行可能」「すでにフローあり」「移動するものなし」に振り分け、移行可能なものをそれぞれが提供するペイウォールでグループ化します。このグループ化がフロープランになります。異なるペイウォールごとに 1 つのフローを作成し、それを使用するすべてのプレースメントで共有することで、5 つのコピーではなく 1 つのフローを改善できます。
- 2 つの質問をします。 アカウントのどの程度を移行するか、そして各フローのコンテンツをどこから取得するかです。フローのコンテンツの取得元 を参照してください。
- フローを公開します。 フローがまだないペイウォールに対しては、スキルがフローを作成し、コンフィグを保存して公開し、ステータスが
publishedになるまで待機します。すでに公開済みのフローはそのまま記録されます。ドラフト状態のフローはプレースメントに紐付けられないため、公開は重要なステップです。 - ゲートを表示します。 作成を提案するプレースメント ID の完全なリストと、まだ完了していない内容を表示します。
- プレースメントを作成します。 同意後、対象範囲内のペイウォールプレースメントごとに
placements createを 1 回実行します。 - レポートと引き渡し。 旧から新へのマッピングと、開発者向けの SDK 呼び出しの変更点を提供します。
Proposed IDs follow your existing ones — main becomes main-flow — and each is verified against every placement ID already in the app.
フローのコンテンツはどこから来るか
新しいプレースメントには公開済みのフローが必要で、ペイウォールごとにどのルートを使うかを選択します。4つのルートでユーザーに表示される内容が異なるため、自動的に選択されることはありません。
| ルート | 処理内容 | 適用条件 |
|---|---|---|
| Reuse | スキルが既存のフローをプレースメントに紐づけます。まだ下書きの場合は先に公開します。 | フローがすでに作成済みまたは変換済みの場合。候補が存在する場合は最初に提示されます。 |
| Convert | ペイウォールのページで Move to new builder をクリックします。スキルは処理を待機してからアカウントを再読み込みし、生成されたフローを読み取ります。 | ペイウォールがレガシーのペイウォールビルダーで作成されている場合。ペイウォールをフローに変換するを参照してください。 |
| Build | スキルがペイウォールを flow-generator に渡し、フローをデザインします。 | 変換ではペイウォールを再現できない場合、またはコピーではなく画面を再設計したい場合。 |
| Stub | スキルが最小限の1画面フローを公開し、プレースメントが配信できる状態にします。 | 最終手段。スタブはユーザーにプレースホルダーを表示するため、明示的な確認が必要です。 |
このスキルは、何かを作成する前に既存のフローを検索し、名前のみでペイウォールと照合します。Adapty にはどのペイウォールからフローが作成されたかを記録する仕組みがないため、見つかったすべての候補は確認を求めるための提案にすぎません。また、名前を変更したフローは見つかりません。フローリストで確認してください。CLI にはフローを削除するコマンドがないため、誤って作成したフローはダッシュボードで削除する必要があります。
Move to new builderが特定のペイウォールで利用できるかどうかは、このスキルでは確認できません。このボタンはレガシーペイウォールビルダーで作成されたペイウォールにのみ表示されるものであり、CLIはどのビルダーで作成されたかを報告しないためです。このスキルではボタンの説明と場所をご案内しますので、実際に確認してご報告ください。
承認内容
スキルが何かを作成する前に、確認用のブロックが表示されます。そこには、アプリ名、作成予定のプレースメント数、省略なしの変換前後の対応表が示されます。
「はい」と答えても行われないことも、同じブロックに記載されています。
- ペイウォールのプレースメントはそのまま維持されます: プレースメントはこれまでどおり機能し続けます。これがロールバックの仕組みでもあります。アプリが新しい呼び出しをリリースするまでユーザー側に変化はないため、何もリリースしなければマイグレーションはロールバックされます。
- まだユーザーには届きません: アプリが、現在古いプレースメント ID で呼び出している箇所を、新しいプレースメント ID で
getFlowを呼び出すよう変更する必要があります。 - 「No」はプレースメントを停止しますが、フローは削除されません: 実行中にすでに作成されたフローはアカウントに残り、CLIコマンドでフローを削除することはできません。スキルが対象の件数と削除場所を示します。
得られるもの
実行が完了すると、作成数・スキップ数・失敗数とその理由が表示され、続いて開発者が作業に使うマッピングが出力されます：
| 旧ペイウォールプレースメント | 新フロープレースメント |
|---|---|
onboarding_main | onboarding_main-flow |
paywall_settings | paywall_settings-flow |
SDK v4 では、getFlow はフロープレースメントとペイウォールプレースメントの両方を読み取るため、アプリはどちらの場合も同じメソッドを呼び出します。変わるのはプレースメント ID であり、メソッドではありません。実装については、各プラットフォームの SDK インテグレーションスキルに委ねてください: iOS · Android · React Native · Flutter · Unity · Kotlin Multiplatform · Capacitor。
v4の採用率が十分に高くなるまで、両方のプレースメントを稼働させ続けてください。すでにリリース済みのバージョンを使っているユーザーは、古いプレースメントIDがアプリにコンパイルされているため、アップデートするまでフローにアクセスできません。そのため、各プレースメントは独自の指標で計測されます。両方が稼働している間は、別々のコホートとして比較してください。移行の全手順については、フローへの移行を参照してください。
できないこと
- プレースメントをその場で変換する: そのような操作は存在しません。Adapty はタイプの変更を拒否するため、すべての移行は新しいプレースメントとして作成されます。
- 古いプレースメント ID を再利用する: プレースメント ID はアプリ全体でユニークです（タイプを問わず）。そのため、新しいフロープレースメントには、置き換えるペイウォールプレースメントを含め、他のどのプレースメントとも重複しない ID が必要です。
- 既存のものに触れる: 既存のプレースメント、ペイウォール、フローは編集も削除もされません。スキルはそれらを読み取るだけで、新しいものを並行して作成します。
- あなたの承認なしにプレースメントを作成する: 提案されたすべての ID は、最初に承認ゲートを通過します。
- すでにフローを持つペイウォールに2つ目のフローを作成する: 既存のフローを再利用しないと明示的に断らない限り、重複したフローは手動で削除する必要が生じるためです。
- アプリのコードを書く: 実行はハンドオフの時点で終了します。
制限事項
複数のセグメントを持つオーディエンスは先に解決する必要があります
複数のセグメントをターゲットにしているオーディエンスは読み取りはできますが書き戻しができないため、スキルは新しいプレースメントでそれを再作成できません。該当するプレースメントはブロック済みとして報告され、理由も表示されます。セグメントを分割したり削除したりする提案はしません――それを行うと誰に何が表示されるかが変わってしまうため、判断はあなたに委ねられています。ダッシュボードで解決してから再実行すると、残りの移行はそれらを除いて進みます。
A/B テストのオーディエンスはスキルから見えません
プレースメントを読み取ると、そのペイウォールとフローのオーディエンスのみが返され、それ以外の種類は通知なしに除外されます。A/B テストのオーディエンスはその一例であり、エントリがスキップされたことはレスポンスのどこにも記録されないため、スキルはそれを検出する方法がありません。件数はAPIが返した内容を示しています。A/B テストが実行されていることがわかっているプレースメントについては、ダッシュボードのオーディエンスリストを確認してください。新しいフローのプレースメントには、スキルが認識できなかったオーディエンスは引き継がれません。
リリースするまでエンドツーエンドの検証はできません
スキル自体のチェックは「フローが公開されており、プレースメントが存在する」という点までで止まります。実際のユーザーに対してフローが正しく機能するかどうかは別の問題です。公開前に各フローに対して flow-audit を実行し、アプリがプレースメントを呼び出したら新しいプレースメントでサンドボックス購入を行ってください。
次のステップ
- フローへの移行 — SDKアップグレードを含む移行全体の手順です。
- ペイウォールをフローに変換する — 変換ルートが依存する Move to new builder のクリック操作についての説明です。
- flow-generatorスキル — このスキルが紐付けるフローのコンテンツを構築・編集します。
- flow-auditスキル — フローがプレースメントに配置される前にプロダクション対応かどうかを確認します。
- Adapty CLIリファレンス — スキルが実行するプレースメントコマンドの説明です。