このページはAIにより自動翻訳されており、不正確な内容が含まれている可能性があります。翻訳の誤りを報告するには、ページ右側の目次の下にあるフィードバックをご利用ください。

コンテキスト

コンテキストステップを使用すると、ユーザーがキャンバスを進む際に、1つ以上の変数を作成・更新できます。たとえば、季節割引を管理するキャンバスがある場合、コンテキスト変数を使用して、ユーザーがキャンバスに入るたびに異なる割引コードを保存できます。

重要

キャンバスコンテキストの利用可否はワークスペースによって異なります。キャンバスのステップメニューにコンテキストが表示されず、パーソナライゼーションメニューにコンテキスト変数ではなくキャンバスエントリプロパティが表示される場合は、エントリデータにcanvas_entry_propertiesを使用してください。キャンバスコンテキストへのアクセスが必要な場合は、アカウントマネージャーにお問い合わせください。

仕組み

キャンバスの最初のステップとして配置されたコンテキストステップ。

コンテキストステップを使用すると、特定のキャンバスでのユーザージャーニー中に一時的なデータを作成して使用できます。このデータはそのキャンバスジャーニー内にのみ存在し、別のキャンバス間やセッション外では保持されません。

コンテキスト変数は、その特定のキャンバスジャーニーにのみ存在します。ユーザーのプロファイルを恒久的に変更することはなく、他のキャンバスにも表示されません。そのため、特定のキャンペーンやワークフローにのみ関係する一時的な情報に最適です。

ヒント

データ型、使用方法、ベストプラクティスなど、コンテキスト変数の詳細なリファレンスについては、コンテキスト変数リファレンスを参照してください。

コンテキストステップ内では、最大10個のコンテキスト変数を定義または更新できます。これらの変数を使用して、遅延のパーソナライズ、ユーザーの動的なセグメント化、キャンバス全体のメッセージングの充実を図れます。たとえば、ユーザーのフライト予定時刻のコンテキスト変数を作成し、それを使ってパーソナライズされた遅延を設定し、リマインダーを送信できます。

コンテキスト変数は次の2つの方法で設定できます。

キャンバスへのエントリ時: カスタムイベントまたは API トリガーのプロパティが、コンテキスト変数として自動的に入力されます。
コンテキストステップ内: コンテキストステップを追加して、コンテキスト変数を手動で定義または更新します。

各コンテキスト変数には、名前、データ型、値（Liquid または「パーソナライゼーションを追加」ツールで設定）が必要です。定義したコンテキスト変数は、{{context.${flight_time}}} のように Liquid を使用してキャンバス全体で参照できます。コンテキスト変数名フィールドでは、コンテキスト変数名を入力するか、ステップエディターのドロップダウンから選択することもできます。詳細については、コンテキスト変数リファレンスを参照してください。

キャンバスへのエントリのたびに、最新のエントリデータとキャンバスの設定に基づいてコンテキスト変数が再定義されるため、ユーザーはそれぞれ独自のコンテキストを持つ複数のアクティブなジャーニーを同時に進めることができます。たとえば、顧客に今後のフライトが2便ある場合、2つの独立したジャーニー状態が同時に進行し、それぞれが出発時刻や目的地などのフライト固有のコンテキスト変数を持ちます。これにより、ニューヨーク行きの午後2時のフライトに関するパーソナライズされたリマインダーを送信しながら、明日のロサンゼルス行きの午前8時のフライトについては別の最新情報を送信できるため、各メッセージが特定の予約に関連した内容に保たれます。

ユーザー処理とバッチ処理

コンテキストステップは、パフォーマンスを最適化するためにユーザーをバッチで処理します。ユーザーがコンテキストステップに入ると、Braze はデフォルトで1,000ユーザー単位のバッチでユーザーを処理します。これらのバッチは並列で処理されますが、各バッチ内ではユーザーが順番に処理されます。

これは次のことを意味します。

例: ユーザー1人あたり650ミリ秒かかる Connected Content を含むコンテキストステップに3,500人のユーザーが入る場合:

Braze はユーザーのバッチを4つ作成します（この例では1,000人、1,000人、1,000人、500人）。
各バッチはユーザーを順番に処理するため、1,000ユーザーのバッチには約10.8分（650秒、1,000 × 650ミリ秒）かかります。
バッチはそれぞれ異なるタイミングで完了するため、ユーザーは自分のバッチが完了するにつれて順次次のステップへ進みます。
バッチサイズや Connected Content の応答時間によっては、最初のユーザーが最後のユーザーより数分早く次のステップに到達する場合があります。

Connected Content を使用しない場合、外部 API 呼び出しの待機が発生しないため、コンテキストステップの処理ははるかに高速になります。

考慮事項

1つのコンテキストステップにつき、最大10個のコンテキスト変数を定義できます。
各変数には一意の名前が必要です（英字、数字、アンダースコアのみ、最大100文字）。
1つのステップ内のすべての変数の合計サイズは50 KBを超えることはできません。
APIトリガーを使用して渡された変数は、コンテキストステップで作成された変数と同じ名前空間を共有します。コンテキストステップで変数を再定義すると、APIの値が上書きされます。

詳細および高度な使用方法については、コンテキスト変数リファレンスを参照してください。

コンテキストステップの作成

ヒント

ワークスペースでフィルターとしてコンテキスト変数が利用可能な場合、オーディエンスパスや条件分岐ステップでトリガーイベントのプロパティを参照するためにコンテキストステップは必要ありません。フィルターグループ内でプロパティを直接参照できます。正しいデータ型を選択するようにしてください。

ステップ1: ステップを追加する

キャンバスにステップを追加し、サイドバーからコンポーネントをドラッグ＆ドロップするか、プラスボタンを選択してコンテキストを選択します。

ステップ2: 変数を定義する

注

コンテキストステップごとに最大10個のコンテキスト変数を定義できます。

コンテキスト変数を定義するには、次の手順に従います。

コンテキスト変数に名前を付けます。
データ型を選択します。
Liquid式を手動で記述するか、パーソナライゼーションを追加を使用して既存の属性からLiquidスニペットを作成します。
プレビューを選択して、コンテキスト変数の値を確認します。
(オプション) さらに変数を追加するには、コンテキスト変数を追加を選択し、ステップ1～4を繰り返します。
完了したら、完了を選択します。

これで、パーソナライゼーションを追加を選択することで、メッセージステップやユーザー更新ステップなど、Liquidを使用できる場所であればどこでもコンテキスト変数を使用できます。ステップエディターのコンテキスト変数名フィールドでは、コンテキスト変数名を入力するか、ドロップダウンから選択することもできます。詳しい手順については、コンテキスト変数リファレンスを参照してください。

重要

コンテキスト変数を参照する場合は、必ず {{context.${variable_name}}} の形式を使用してください。

コンテキスト変数フィルター

オーディエンスパスステップと条件分岐ステップでは、コンテキスト変数を使用してフィルターを作成できます。

エージェントステップの応答に基づいてユーザーを振り分けるには、オーディエンスパスステップまたは条件分岐ステップの前にエージェントステップを追加します。エージェントステップは出力をキャンバスコンテキストに保存するため、これらの分岐ステップでコンテキスト変数フィルターを使って評価できます。

エージェントがオブジェクトを返し、ネストされたプロパティでフィルタリングしたい場合は、トップレベルの変数名だけでなく、ドット表記を使用したパスをコンテキスト変数名フィールドに入力します (たとえば、persona が intent_agent の下にネストされている場合は intent_agent.persona)。

注

コンテキスト変数名のリストには、コンテキストステップとエージェントステップの変数が含まれます。キャンバスのエントリプロパティの場合は、その名前を入力して“ENTRY_PROPERTY_NAME“を使用を選択します。ENTRY_PROPERTY_NAME は入力したエントリプロパティ名に置き換えてください。ネストされたプロパティの場合は、order.total のようにドット表記を使用します。

フィルターの設定、比較ロジック、高度な例については、コンテキスト変数リファレンスを参照してください。

重要

「Day of year」と「Time」のフィルタータイプの選択について：日付を含むコンテキスト変数をフィルタリングする際は、その日付が毎年繰り返されるかどうかに基づいて、適切な比較タイプを選択してください。コンテキスト変数が生成する値に年が含まれていない場合にのみ、「Day of year」を使用してください。

毎年繰り返される日付（誕生日、記念日、クリスマスなどの祝日など）には「Day of year」を使用してください。この比較タイプは、年の要素を無視し、その年の日数（1〜365/366）に基づいて計算します。
繰り返されない絶対日付（契約終了日、予約日、購読更新日など）には「Time」を使用してください。この比較タイプは、年を含む完全なタイムスタンプに基づいて計算します。

絶対日付に「Day of year」を使用すると、計算が年の要素を無視するため、誤った結果や予期しない結果が生じることがあります。例えば、4月の将来の契約終了日が63日以内かどうかを判断する場合、「Day of year」を使用すると、日付番号（119対359）のみを比較し、実際には4月まで188日あることを考慮しないため、誤った一致が生じる可能性があります。

ユーザーパスのプレビュー

メッセージが適切なオーディエンスに送信され、コンテキスト変数が想定どおりの結果に評価されることを確認するために、ユーザーパスのテストとプレビューをお勧めします。

注

エディターのプレビューとテスト送信セクションでキャンバスをプレビューする場合、このパネルはプレビューを文字列として生成するため、テストメッセージプレビューのタイムスタンプは UTC に標準化されません。そのため、キャンバスが time オブジェクトを受け付けるように設定されている場合、メッセージプレビューにはキャンバスがライブになったときの動作が正確に反映されません。キャンバスを最も正確にテストするには、代わりにユーザーパスをプレビューすることをお勧めします。

無効なコンテキスト変数が作成される一般的なシナリオに注意してください。ユーザーパスをプレビューすると、コンテキスト変数を使用したパーソナライズされた遅延ステップの結果や、ユーザーをコンテキスト変数と照合するオーディエンスステップまたは条件ステップの比較を確認できます。

コンテキスト変数が有効であれば、キャンバス全体でその変数を参照できます。ただし、コンテキスト変数が正しく作成されていない場合、キャンバス内の後続のステップも正しく動作しません。たとえば、ユーザーに予約時間を割り当てるコンテキストステップを作成し、予約時間の値に過去の日付を設定した場合、メッセージステップのリマインダーメールは送信されません。

Connected Content の文字列をJSONに変換する

コンテキストステップでConnected Content 呼び出しを行うと、一貫性を保ちエラーを防ぐために、呼び出しから返されたJSONは文字列データ型として評価されます。この文字列をJSONに変換したい場合は、as_json_string を使用して変換します。以下に例を示します。

{% connected_content http://example.com :save product %}
{{ product | as_json_string }}

トラブルシューティング

無効なコンテキスト変数

コンテキスト変数は、次の場合に無効と見なされます。

埋め込まれたConnected Content の呼び出しが失敗した場合。
実行時に Liquid 式が、データタイプと一致しない値、または空 (null) の値を返した場合。
Liquid 式が {% abort_message() %} を呼び出した場合。

たとえば、コンテキスト変数のデータタイプが数値であるにもかかわらず、Liquid 式が文字列を返した場合、その変数は無効です。

このような場合は次のようになります。

ユーザーは次のステップに進みます。
キャンバスのステップ分析では、これを 未更新 としてカウントします。

トラブルシューティングの際は、未更新 の指標をモニタリングして、コンテキスト変数が正しく更新されていることを確認してください。コンテキスト変数が無効な場合、ユーザーはコンテキストステップを過ぎてキャンバスを続行できますが、後続のステップの対象にならない可能性があります。

各データタイプの設定例については、データタイプを参照してください。

コンテキスト変数は、abort_message を使用して意図的にスキップすることもできます。コンテキスト変数での abort_message の使用を参照してください。

コンテキスト変数での `abort_message` の使用

コンテキスト変数の値に abort_message Liquidタグを使用すると、一部のユーザーに対してその変数をスキップできます。コンテキストステップでは、abort_message はそのタグを含む変数にのみ影響します。ステップが停止することはなく、ユーザーがキャンバスから退出することもありません。

コンテキスト変数の Liquid があるユーザーに対して abort_message を呼び出した場合は、次のようになります。

そのユーザーに対して変数は設定されません。以前のコンテキストステップですでにこの変数が設定されている場合、ユーザーはその以前の値を保持します。
ステップ内の他の変数は引き続き評価され、設定されます。
同じステップ内でこの変数を参照する後続の変数は、この変数から新しい値を受け取りません。
ユーザーは次のステップに進みます。
キャンバスのステップ分析では、この変数を 未更新 としてカウントします。

たとえば、次の変数はフランスのユーザーに対しては true に設定され、それ以外のすべてのユーザーに対してはスキップされます。

{% if ${country} == "France" %}
  true
{% else %}
  {% abort_message("Not in France") %}
{% endif %}

ユーザーパスをプレビューすると、スキップされた変数は「variable_name was not updated because the Liquid logic triggered an abort」と表示されます。

後続のステップがこの変数に依存している場合は、この変数が設定されていないユーザーへの対応を計画してください。たとえば、オーディエンスパスステップを使用してそれらのユーザーを振り分けることができます。

注

コンテキストステップでの中止はメッセージアクティビティログに記録されず、abort_message に渡した理由も表示されません。

Connected Content を使用した送信の遅延

バッチ内のすべてのユーザーが処理されてから、ユーザーが次に進みます。バッチ処理が完了すると、成功したユーザーは次のステップに進み、失敗したユーザーは個別に再試行されます。成功したユーザーは、再試行が成功するのを待たずに次に進みます。

再試行の動作

キャンバス内の Connected Content の呼び出しは、呼び出しに :retry が含まれている場合にのみ再試行されます。

コンテキストステップとユーザー更新ステップ: Braze はステップレベルで Connected Content の呼び出しを再試行します (最大5回)。すべての再試行が失敗した場合、ユーザーはキャンバスから退出します。
メッセージステップ: :retry を含む Connected Content は、引き続きメッセージングパイプラインを使用します。Braze が呼び出しを最大5回再試行する間、受信者は送信キューで待機状態になります。すべての再試行が失敗した場合、メッセージは中止され、ユーザーは次のステップに進みます。

コンテキストステップとユーザー更新ステップでは、プロモーションコードの取得失敗や予期しないステップエラーなど、特定の再試行可能なステップエラーが発生すると、Braze がユーザーをキャンバスから退出させる前に、指数バックオフによる追加のステップレベルの再試行 (約13回) がトリガーされることがあります。

:retry タグの詳細については、Connected Content の再試行を参照してください。

コンテキストステップですべてのユーザーを処理するのにかかる時間は、次の要素によって異なります。

ステップに入るユーザーの数
Connected Content を使用しているかどうか (およびその応答時間)
バッチサイズ (デフォルトはバッチあたり1,000ユーザー)

Connected Content のエンドポイントにレート制限がある場合、コンテキストステップでは各バッチ内でユーザーが順次処理されるため、自然にレート制限を守りやすくなります。ただし、複数のバッチは並行して処理されるため、エンドポイントが複数のバッチからの同時リクエストを処理できることを確認してください。

タイムゾーンの一貫性

キャンバスコンテキストを使用するワークスペースでは、アクションベースのキャンバスにおけるデフォルトのタイムスタンプイベントプロパティはすべて UTC になります。この動作は、キャンバスでコンテキストステップを使用しているかどうかにかかわらず適用されます。

重要

どのような場合でも、タイムスタンプを希望するタイムゾーンで表示するには、Liquidのtime_zoneフィルターを使用することを強くお勧めします。例については、こちらのよくある質問を参照してください。

よくある質問

キャンバスコンテキストはタイムスタンプにどのような影響を与えますか？

キャンバスコンテキストを使用しているワークスペースでは、次のようになります。

アクションベースのキャンバスにおいて、トリガーイベントプロパティに含まれるdatetime 型のタイムスタンプは、すべて UTC になります。
この変更は、コンテキストステップを使用しているかどうかにかかわらず、すべてのアクションベースのキャンバスに影響します。

この変更の理由は何ですか？

この変更は、キャンバスのステップやメッセージを編集する際に、より予測しやすく一貫性のある体験を提供するための幅広い取り組みの一環です。

API トリガーまたはスケジュールされたキャンバスはこの変更の影響を受けますか？

いいえ。

この変更はキャンバスエントリプロパティに影響しますか？

はい。アクションベースのキャンバスで canvas_entry_property を使用していて、そのプロパティタイプが time の場合、canvas_entry_properties に影響します。どのような場合でも、タイムスタンプを目的のタイムゾーンで表示するには、Liquid の time_zone フィルターを使用することをお勧めします。

その方法の例を次に示します。

メッセージステップの Liquid	出力	Liquid でタイムゾーンを正しく表現する方法か？
`{{canvas_entry_properties.${timestamp_property}}}`	`2025-08-05T08:15:30:250-0800`	いいえ
`{{canvas_entry_properties.${timestamp_property} \| date: "%Y-%m-%d %l:%M %p"}}`	`2025-08-05 4:15pm`	いいえ
`{{canvas_entry_properties.${timestamp_property} \| time_zone: "America/Los_Angeles" \| date: "%Y-%m-%d %l:%M %p"}}`	`2025-08-05 8:15am`	はい

新しいタイムスタンプの動作がメッセージにどのように影響するか、実際の例を教えてください。

たとえば、メッセージステップに次の内容を含むアクションベースのキャンバスがあるとします。

Your appointment is scheduled for {{canvas_entry_properties.${appointment_time} | date: "%Y-%m-%d %l:%M %p"}}, we'll see you then!

この場合、次のメッセージになります。

Your appointment is scheduled for 2025-08-05 4:15 PM, we’ll see you then!

Liquid でタイムゾーンが指定されていないため、このタイムスタンプは UTC になります。

タイムゾーンを明確に指定するには、次のように Liquid の time_zone フィルターを使用します。

Your appointment is scheduled for {{canvas_entry_properties.${appointment_time} | time_zone: "America/Los_Angeles" | date: "%Y-%m-%d %l:%M %p"}}, we'll see you then!