Interactions パネルでは、フロー要素がイベント（タップ、要素の表示、フォームの送信など）にどう反応するかを定義できます。各イベントに対して、1つ以上のアクションを割り当てられます。アクションの種類には、画面間のナビゲーション、要素の表示・非表示、URLを開く、変数の設定などがあります。条件を使うと、ユーザーデータに基づいてフローをカスタマイズできます。

各インタラクションは3つのパーツからなるチェーン構造を持っています。

1. Element（エレメント）: インタラクションを開始するスクリーンコンポーネント。ボタン、クイズの回答、入力フィールドなど、さまざまな要素が該当します。
2. Trigger（トリガー）: ロジックを起動するイベント。タップ、エレメントの表示、フォーム送信などがあります。
3. Action（アクション）: トリガーに応じてフローが実行するタスク。1つのトリガーで複数のアクションを順番に実行できます。

インタラクションの設定

インタラクションを設定するには:

1. 画面上または Layers パネルでエレメントを選択します。
2. 右側で Interactions パネルに切り替え、Add trigger をクリックします。

3. Button triggers セクションで、トリガータイプを選択します。

4. Add action をクリックし、アクション名をクリックして、Edit action ウィンドウのドロップダウンからアクションタイプを選択します。

5. 選択したアクションタイプに基づいて、アクションのプロパティを設定します。
6. 必要に応じて、Add action をクリックして同じトリガーにアクションを追加します。

トリガーの種類

トリガーは、ユーザーの操作、要素の状態変化、または画面の読み込みに応じて発火します。On screen appear はすべての要素に共通で使用できます。それ以外はそれぞれの要素専用です。

トリガー	発火タイミング	対応要素
On screen appear	画面が読み込まれたとき	すべての要素
On tap	ユーザーが要素をタップしたとき	ボタン、クイズの選択肢、トグル、カウントダウン、動画
On changed	ユーザーが入力値を変更したとき（文字入力、日時の選択など）	すべての入力要素
On submit	ユーザーがキーボードのEnterまたはDoneを押してテキスト入力を送信したとき	テキスト系入力要素
On timer end	カウントダウン要素がゼロに達したとき	カウントダウン
On playback finished	動画が最後まで再生されたとき	動画
インタラクションが組み込まれていない要素（ローダーなど）では、On screen appear が唯一利用可能なトリガーです。

アクションの種類

画面への遷移

これはユーザーを画面間で移動させるための主要なアクションです。指定した遷移先の画面にユーザーを誘導します。

このアクションでは、遷移先の画面を設定するだけで十分です。動的なナビゲーションを有効にしたい場合は、ナビゲーションと分岐または条件付きアクションセクションをご覧ください。

次の画面に進む

フロー内の画面順序に従って、ユーザーを次の画面に進めます。エディターでの画面の並び順がそのまま表示順になる、リニアなフローに適しています。

前の画面に戻る

シーケンス上の前の画面ではなく、ナビゲーション履歴上の前の画面にユーザーを戻します。

URLを開く

指定したウェブアドレスを開きます。アプリのネイティブ画面の外にあるウェブページ、記事、ソーシャルメディアのプロフィールなどにユーザーを誘導する際に使用してください。 このアクションでは、次の2つの設定を構成できます：

• URL address：URLアドレスを設定します。また、動的なURLにすることも可能です。たとえば、クイズの回答に基づいてユーザーを異なるページに誘導したり、ユーザーが送信したデータを利用したりできます。これを行うには、 をクリックして、使用する変数を選択します。
• Open in external browser：外部リンクをどこで開くかを定義します。デフォルトでは、ユーザーをアプリ内に留めるためにアプリ内ブラウザで開きます。外部ブラウザでリンクを開く場合は、Open in external browser チェックボックスを選択してください。

フローを閉じる

現在のフローを閉じます。

要素の表示/非表示

画面上の特定の要素を表示または非表示にします。

このアクションは、Design パネルの Visibility で設定した初期状態を上書きします。Visibility が Hide に設定されている場合、Show アクションを使うと要素が表示されます。

アラートを表示する

ネイティブのシステムポップアップウィンドウを表示します。ユーザーは Ok をタップして続行する必要があります。

アラートには、Title と Message を設定する必要があります。どちらにも、変数を使ってコンテンツを動的にすることができます。変数を使用するには、 をクリックして、使用したい変数を選択してください。

変数を設定する

フロー内の変数の値を更新します。このアクションを追加する前に、左側の Variables パネルで変数を作成してください（変数を参照）。

Add variable をクリックして、必要な数だけ変数とその値を設定します。

購入

オンボーディング内のボタンやインタラクションから直接購入フローを起動します。フローを離れることなく、ユーザーがサブスクリプションを開始したりプロダクトを購入したりできるようにします。 このアクションには2つの動作を設定できます：

• In-app store：ネイティブ購入を開始します。Product に特定のプロダクトを設定するか、画面上でユーザーが現在選択しているプロダクトを使用する場合は products.selectedProduct を設定します。
• Web payment：ネイティブ購入を開始する代わりに、ユーザーをウェブペイウォールに誘導します。ウェブベースのサブスクリプションオファーなど、アプリ外でトランザクションを処理したい場合に使用します。

購入を復元する

デバイス上で購入の復元フローを起動します。ユーザーが別のデバイスで以前に購入したサブスクリプションや、アプリを再インストールした後にアクセス権を回復したい場合に使用します。

このアクションに設定項目はありません。復元はAdaptyがネイティブのストアフローを通じて処理します。

Restore purchases アクションは、Links ボタンプリセットの Restore リンクにもあらかじめ設定されています（購入の設定を参照）。

カスタムアクション

カスタムアクションは、自分のアプリコードが処理する Action ID という名前のアクションを発火させます。組み込みのアクションタイプでは対応できない場合に使用します。

Adapty がトリガーを提供し、アプリが実際の動作を実装します：

1. ビルダーで、要素のインタラクションに Action ID を割り当てます。
2. ユーザーがそのインタラクションを起こすと、フローがそのIDをアプリに渡します。
3. アプリはIDを照合し、対応するコードを実行します。

カスタムアクションを設定する

1. Edit action ウィンドウで、Action ID を設定します。これはアプリが識別するための文字列です（例：show_discount）。
2. アプリのコードで、この Action ID に対応するハンドラーを実装します。実装の詳細とコード例については、ペイウォールアクションの処理を参照してください。

カスタムアクションでできること

カスタムアクション自体は何も行いません。ビルダーで静的なアクション ID を設定し、そのIDを受け取ったときの処理はアプリのコードで実装します。以下のユースケースはすべて同じパターンに従います。フローでIDを割り当て、コードでそれを処理する、これだけです。

• アプリ内イベントのトリガー: viewed_special_offer などのIDを発火し、アプリがそれを受け取ったときにアナリティクスへイベントを記録します。
• システム権限のリクエスト: request_location などのIDを発火し、アプリからOSの権限プロンプトを呼び出します。プロンプトで許可できない権限の場合は、スマートフォンのシステム設定を開きます。プロンプトを表示するのはAdaptyではなく、あなたのアプリです。
• ネイティブ認証の開始: login_google などのIDを発火し、独自のログイン画面を表示します。フローはユーザーをサインインさせることはできません。
• ビジネスロジックの適用: apply_discount などのIDを発火し、コンテンツのアンロックやアプリの状態変更を自分のサイドで行います。
• クイズの回答をアプリに渡す: 各選択肢に異なるAction IDを割り当て（例: goal_weight_loss、goal_muscle）、コード内でそのIDを読み取ります。そのIDを使って、後でセグメント化できるカスタムユーザー属性を設定します。アクションは固定のIDしか持てないため、選択内容を報告する唯一の方法はこれだけです。フローは選択された値を送信することはできません。

カスタムアクションでできないこと

カスタムアクションは静的です。Action ID はフローのビルド時に固定され、変数やユーザー入力を読み取ることはできません。アクションが発火すると、アプリが受け取るのはその ID のみで、ユーザーが入力したメールアドレス、電話番号、その他の入力値は渡されません。入力フィールドは、分岐やパーソナライズのための変数としてフロー内に留まります。これらの値をアプリで利用したい場合は、独自の UI や API を通じて収集してください。 カスタムアクションは一方向です。アプリはフローに結果を返すことができず、フローはコードの完了を待ちません。カスタムアクションの後に Navigate next アクションが続く場合、コードが失敗した場合でも（たとえばユーザーがサインインせずにログイン画面を閉じた場合でも）、ユーザーは次の画面に進みます。静的な Action ID と組み合わせると、アプリ内でのユーザー入力の検証（たとえばユーザーが入力した SMS コードを確認して結果に基づいて分岐する）はできません。フローの残りの部分がコードの実行結果に依存する場合は、フローを2つのプレースメントに分割してください。

結果に基づいてフローを継続する

カスタムアクションが成功した場合にのみ表示されるべき画面がある場合（例：ログイン後に続く画面など）、フローを2つのプレースメントに分割し、2番目の部分をいつ表示するかをアプリ側で判断するようにします。

1. 最初のプレースメントで、カスタムアクション（例：login）で終わるフローを作成します。
2. アプリ内でアクションIDを処理します。ログイン画面を表示し、ユーザーがサインインしたかどうかを確認します。
3. ユーザーがサインインした場合、2番目のプレースメントのフローをフォローアップ画面とともに表示します。 このようにすることで、結果に関わらずフローが前に進むのではなく、実際の結果に基づいてアプリが画面遷移を制御できます。

条件付きアクション

条件付きアクションを使うと、ユーザーデータに基づいてフローを異なるパスに分岐させることができます。

よくあるユースケースとしては次のようなものがあります：

• 画面上にクイズがあり、回答に応じて異なる画面に誘導したい場合。この場合、ボタンに条件付きアクションを追加します。
• 異なるユーザーグループに異なるプロダクトやオファーを提示したい場合。それぞれ別の画面に配置し、ナビゲーションボタンに条件を設定します。
• 前回のアプリセッションですでにチュートリアルを完了しているユーザーの特定のステップをスキップしたい場合。 条件アクションは if / else-if / else チェーンのように動作します。アプリはルールを上から順に読み取り、最初に一致したところで処理を止めます：

1. IF：フローはまずプライマリ条件をチェックします。
   • True の場合：フローは THEN アクションをすぐに実行して処理を止めます。
   • False の場合：フローは次のセクションにスキップします。
2. ELSE IF：ここに追加のチェックを設定できます（例：「プレミアムでない場合、ユーザーはトライアル中か？」）。
3. ELSE（フォールバック）：上記のいずれのルールにも一致しなかった場合、フローはこの最終セクションのアクションを実行します。

各ルールについて、評価する変数とアクションを選択してください。1つのルールに複数のアクションを設定することもできます。

セレクタブル要素のグループ化やコンディションでの使い方については、セレクタブル要素とグループを参照してください。

トラブルシューティング

必須フィールドが未入力の場合、プレビューや公開がブロックされます。詳細はフローの保存と公開をご覧ください。