ジャーニーシミュレーションの基本を学ぶ simulate-journey-gs

「オーディエンスを読み込む」を使用したバッチジャーニー

ジャーニーは​ 読み取りオーディエンス ​によってトリガーされ、キャンバスには単一のイベントアクティビティがありません。 シミュレーション中は、オーディエンス母集団はトリガーされません。 ジャーニーにエントリするのはシミュレートされたユーザーのみです。
シミュレーション用に選択されたシミュレートされたユーザーは、ユーザーのテスト セクションに表示されます。

読み取りオーディエンスのみのバッチジャーニーの

読み取りオーディエンスと単一イベントを使用したバッチジャーニー

トリガーに沿った1つ以上の単一イベントを含む、セグメント経路のジャーニー。 最初にシミュレートされたユーザーをトリガーしてシミュレーションを開始し、次にイベントノードで待機するユーザーのイベントをトリガーします。
シミュレーション用に選択されたシミュレートされたユーザーと設定されたイベントは、「ユーザーをテスト」セクションと「イベントをテスト」セクションにそれぞれ表示されます。 テストイベントセクションは、シミュレートされたユーザーがジャーニーにエントリするまで表示されません。

読み取りオーディエンスのみのバッチジャーニーの

単一ジャーニー

ジャーニーは、オーディエンスの読み取りではなく、単一のイベントから始まります。 シミュレートされたユーザーは、その開始イベントが実行されるまでジャーニーにエントリしません。
シミュレーション用に選択されたシミュレートされたユーザーと設定されたイベントは、それぞれ​ テストユーザー ​および​テストイベント セクションに表示されます。 ユーザーのテスト セクションには、シミュレートされたユーザーをジャーニーにトリガーするアクションは含まれていません。 テストイベント​からエントリをトリガーしました。

読み取りオーディエンスのみのバッチジャーニーの

ノードレベルの制限

一部のノードが​ シミュレーション ​の開始を妨げています。 その他の場合は、以下に説明する動作でシミュレーションを実行します。 シミュレーションを実行する前にノードを削除または変更する必要がある場合は、まずジャーニーを更新します。

table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2 6-row-2 7-row-2 8-row-2 9-row-2 10-row-2 11-row-2
制限付きノード	メモ
ビジネスイベント	シミュレーション​でビジネスイベントで始まるジャーニーを実行することはできません。
インバウンドチャネル	シミュレーション​にインバウンドチャネルノードを含むジャーニーを実行することはできません。
補足ID （複数回の再入力）	複数の再エントリが有効になっていて、同じシミュレートされたユーザーが一度に複数のアクティブなインスタンスを持つ可能性がある場合、シミュレーション​は開始されません。
データセットのルックアップ	シミュレーション​は、キーによる顧客データセットの検索をサポートしていません。 シミュレーションを実行する前に、このアクティビティを削除または変更します。
最適化 アクティビティ	最適化 メソッドは次のように動作します： ​ ターゲティングルール ​: AIは、設定されたルールをシミュレートされたユーザーのプロファイル属性と比較して評価し、ブランチを選択します。 実験 （パス実験）: ルーティングは、50/50の分割または10%のホールドアウトであっても、分割に対してDecisioningによって処理されます。 割り当ては、シミュレートされたユーザーごとにランダムで非決定性であるため、小さなバッチ（例えば、クイックシミュレーション​でAIが生成したバッチでも5人のユーザー）は、すべての処理をカバーすることが保証されないため、偶然に同じバッチに到達する可能性があります。 これは、以下の​ パーセンテージ分割 ​とは異なります。 ​ パーセンテージの分割​: AIは、分岐ごとに1人のシミュレートされたユーザーを作成しますが、分岐のパーセンテージに応じません。 実行時に、ライブ評価はブランチを選択し、生成されたパスとは異なる場合があります。 分岐選択をモックすることはできません。 ユーザーをステアリングするには、キャンバス上のブランチ順序に依存します。 常に一番上のブランチが選択されます。 時間条件：条件は、ライブジャーニーと同様に、実行時に適用されます。 例えば、8:00から20:00までのウィンドウでは、そのウィンドウ内でシミュレーションを実行している間のみユーザーが実行できます。 実行時間をモックすることはできません。 テスト時の現在の時間に合わせて条件を設定します。 日付条件​：条件は、ライブジャーニーと同様に、実行時に適用されます。 例えば、2026年6月8日の日付では、その日付にシミュレーションが実行された場合にのみユーザーが実行できます。 実行日をモックすることはできません。 テスト時に条件を現在の日付に設定します。 ​ プロファイル キャップ: シミュレーション中にキャップが適用されません。 AIは、ブランチごとに1人のシミュレートされたユーザーを作成します。 分岐選択をモックすることはできません。 ユーザーをステアリングするには、キャンバス上のブランチ順序に依存します。 常に一番上のブランチが選択されます。
タイムアウトとエラー分岐	AIは、アクティビティタイムアウトまたはエラーブランチのユーザーを生成しません。 シミュレーション中にリアルタイムのタイムアウトまたはエラーが発生した場合にのみ、ユーザーはこれらのパスを入力します。
タイムアウトブランチ（イベントアクティビティ）	シミュレートされたユーザーは作成されますが、手動シミュレーション​では、AIがイベントタイムアウトブランチに入るユーザーを決定しません。 イベントを送信または送信しないことによって、パスを制御します。 例えば、タイムアウトブランチをテストするには、設定されたタイムアウトを待ち、イベントを送信しません。 クイックシミュレーション​では、タイムアウト分岐をカバーするためにイベントを自動的に送信または保留できます。
反応イベント	反応イベントはシミュレーションで実行されますが、アクションは実際に発生する必要があります。 例えば、電子メール open​の反応には、プルーフメッセージを開く必要があります。 シミュレーション UIではリアクションをモックすることはできません。
外部データソース	シミュレーション中の呼び出しは、ライブジャーニーと同じように実行されます。 ダウンストリームアクティビティは応答を使用できますが、モックすることはできません。 応答値が​Optimize アクティビティをフィードすると、AIはその出力を発明できません。 呼び出しの入力のみを生成します。 例えば、呼び出しがプロファイル都市を取り、天気を返す場合、エージェントはシミュレートされたユーザーに都市を設定し、ライブ呼び出しは天気を返します。
カスタムアクション	行動は外部データソースに一致します。 発信コールがリアルに実行されます。 AIは入力を補完します。 出力はライブ応答から得られます。 回答をモックすることはできません。
外部オーディエンス属性の強化	この検証が適用される場合、外部オーディエンスソースからパーソナライズされた属性を使用するジャーニーは​ シミュレーション ​で開始されません。

決定行動

次の決定要素がサポートされています。

table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2 6-row-2 7-row-2
決定要素	メモ
オファーの実施要件	プロファイル属性に基づく適格性など、サポートされています。
実施要件ルール	サポートされています。 ルールには、プロファイル属性を含めることができます。
実施要件オーディエンス	オーディエンスがシミュレートされたユーザーのプロファイルに追加される場合にサポートされます。
オファーの優先順位によるランキング	サポートされています。 プロファイル属性は関係ありません。
数式別のランキング	サポートされています。 この式では、プロファイル属性を使用できます。
AI モデル – 自動​によるランキング	サポートされています。 ランキングは、オファーと設定されたデータセットのみに基づいています。プロファイル属性は関係しません。 設定されたデータセットに必要なデータが存在する必要があります。
AI モデルによるランキング - Personalization	サポートされています。 オーディエンスはランキング用と見なされ、適格性は考慮されません。 ランキングはAI主導であるため、返されるオファーはシミュレーション実行によって異なる場合があります。

機能の制限

次の機能は、シミュレーション​で​ not ​がサポートされています。

table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2 6-row-2 7-row-2 8-row-2 9-row-2 10-row-2 11-row-2 12-row-2 13-row-2
機能	メモ
終了条件	シミュレーション​を実行すると、終了条件は適用されません。
カスタムアクション応答をモック	​ カスタムアクション ​は、デフォルトで実際のアウトバウンドコールを実行します。 外部呼び出しの実行がサポートされないように応答をモックします。
同意ポリシーの評価	同意はシミュレートされたユーザーレベルでモックできず、同意ポリシーはシミュレーション中に評価されません。
ジャーニーの上限と調停	シミュレーション中に評価も実行もされません。
配信頻度の上限設定（チャネルまたは通信タイプ別）	シミュレーション中に評価も実行もされません。
オプトアウトの管理、抑制、許可リスト	シミュレーション中に評価も適用もされません。
チャネル設定における動的サブドメインと動的属性	サポートされていません。
送信時間最適化（STO）	シミュレーション中に評価も適用もされません。
サンドボックスツール（サンドボックス間でシミュレートされたユーザーをコピー）	サポートされていません。
ジャーニー内でのウェーブ送信	サポートされていません。
クワイエットアワー	シミュレーション中に評価も適用もされません。
プライバシーサービス	シミュレートされたユーザーは、GDPRに準拠した永続的なプロファイルではありません。 シミュレーションユーザーに実際の顧客データを含めないでください。
プロファイルの永続性	シミュレートされたユーザーをジャーニートリガーに送信すると、標準の配信パイプラインを通じて実際のメッセージが送信されます。 影響を受けるデータセット（フィードバックイベントやトラッキングイベントなど）がプロファイル対応である場合、実行がシミュレーションとしてフラグ付けされていても、そのシミュレーションユーザーのAdobe Experience Platformで永続的なプロファイルが作成される可能性があります。

定量的ガードレール

これらのガードレールは、シミュレーション​に適用されます。 数値キャップは、ジャーニーインターフェイスおよび実行時に適用されます。 制限は、後のリリースで変更される場合があります。 天井付近で実行する場合は、サンドボックス内の動作を確認します。

table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3 6-row-3 7-row-3 8-row-3
ガードレール	上限	メモ
1回のバッチで選択およびトリガーできる最大シミュレーションユーザー（バッチジャーニー、イベントトリガーフロー、オーディエンス選定フロー）	20	各​ Send all ​または​ トリガーが選択したイベント ​ごとにカウントされ、ジャーニー全体の累積上限ではありません。
生成リクエストごとにシミュレートされる最大ユーザー数	50	最大シミュレートされたユーザーAIは、クイックシミュレーション​または​AIを使用して生成、手動シミュレーション​を通じて1回のリクエストで生成されます。 ジャーニーのパス数が​ 50 ​を超える場合、AIはパスをランダムに選択して、シミュレートされた​ 50 ​人のユーザーを生成します。
1回のシミュレーション実行でテストされた最大一意のシミュレートされたユーザー	100	1回の実行ブロックで​ 100 ​人のユニークユーザーにリーチ 新しいシミュレーションユーザーのシミュレーションユーザー​を選択します。 90​の場合は、同じブロックの前に最大​ 10 ​個まで追加できます。
1つのサンドボックスで同時に​ シミュレーション ​で実行できる最大ジャーニー	20	Capは、そのサンドボックス内のすべての​シミュレーション ジャーニーで一度に共有されます。
1つのサンドボックス内の最大アクティブなシミュレーションユーザー	2,000	一度にサンドボックスに存在できるシミュレートされた最大ユーザー。 Adobeは、お客様からのフィードバックに基づいて、この制限を調整する場合があります。
イベントの事前入力（ブラウザーのみ）	—	イベントペイロードフィールドを事前入力できるのは、ブラウザーベースのシミュレーション UIのみです。 事前入力された値は、そのブラウザー内に残り、他のブラウザー、デバイス、セッションとは同期されないため、テストする場所ごとに異なる事前入力データが表示される場合があります。
AI生成のシミュレートされたユーザー維持率	10日間	AI生成のシミュレーションユーザーは、作成後10日以内に自動的に削除されます。
グローバルなユーザー維持率のシミュレーション	12 ヶ月	グローバルシミュレーションユーザーは、作成後12か月で自動的に削除されます。

AI Knowledge Reference

This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.

For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.

• TL;DR: This page introduces the Journey Simulation feature in Adobe Journey Optimizer, explaining how it differs from Test mode, which journey types it supports, how to launch a simulation, how Optimize activity methods and other decisioning elements behave during a simulation, and what its node-level, functional, and quantitative limitations are.

Intents:

• Understand the difference between Simulation and Test mode for validating journeys
• Launch a Simulation session for a batch, unitary, or mixed journey type
• Identify which journey nodes block or restrict Simulation from running
• Determine how Optimize activity methods (Targeting rule, Experiment, Percentage split, Time condition, Date condition, Profile cap) behave during Simulation
• Determine which decisioning elements (offer eligibility, eligibility rule or audience, ranking) are supported during Simulation
• Determine which features are unsupported during Simulation (e.g., consent, frequency capping, STO)
• Plan around quantitative guardrails such as maximum simulated users per sandbox
• Decide whether to use Quick simulation or Manual simulation based on testing needs

Glossary:

• Simulated users: Temporary profile-like entities created for Simulation. Sending a simulated user triggers a real message send, which can currently result in a persistent profile being created in Adobe Experience Platform (product-specific)
• Simulation: A journey state (alongside Draft, Test mode, and Live) used for testing with simulated users rather than persistent test profiles (product-specific)
• Journey Agent: The AI component that generates simulated users, event values, and test settings during Quick simulation and AI-assisted Manual simulation (product-specific)
• Quick simulation: An automated end-to-end simulation run that generates users and events with minimal manual input (product-specific)
• Manual simulation: A step-by-step simulation mode where users and events are created and triggered individually (product-specific)
• Experiment (Path Experimentation): An Optimize activity method whose eligibility and allocation the Journey Agent evaluates against the simulated user’s profile attributes to select the branch (product-specific)

Guardrails:

• Requires at least one of: Simulate journeys, Publish journeys, or Approve and Publish journeys permissions
• AI-powered simulation features require the Generate Content permission from the AI Assistant capability
• Maximum 20 simulated users per Send all or Trigger selected events batch
• Maximum 50 simulated users per AI generation request
• Maximum 100 unique simulated users per single simulation run
• Maximum 20 journeys running Simulation simultaneously in one sandbox
• Maximum 2,000 active simulated users in one sandbox at a time
• Business event-triggered journeys cannot be simulated
• Supplemental ID journeys with multiple re-entrance enabled cannot be simulated
• Consent policies, frequency capping, opt-out, STO, and quiet hours are not evaluated during Simulation
• Simulated users must not contain real customer data (not GDPR-compliant)

Terminology:

• Canonical name: Simulation — Acronym: none — variants: Journey Simulation, Simulation mode
• Canonical name: Simulated users — Acronym: none — variants: test users (in UI labels)
• Canonical name: Experiment — variants: Path Experimentation
• Synonyms: “Simulation” = “Simulation mode”; “simulated users” = “test users” (UI label only)
• Do not confuse: “Simulation” ≠ “Test mode” (Test mode uses persistent AEP test profiles; Simulation uses temporary simulated users)
• Do not confuse: Targeting rule ≠ Experiment (both are Optimize activity methods, but the Journey Agent evaluates a configured rule for Targeting rule versus eligibility and allocation for Experiment)

FAQ:

• Q: What permissions do I need to use Simulation? — You need at least one of: Simulate journeys, Publish journeys, or Approve and Publish journeys. AI features additionally require Generate Content permission from the AI Assistant capability.
• Q: How does Simulation differ from Test mode? — Simulation uses temporary simulated users created on the fly, generally without pre-created profiles in Adobe Experience Platform; Test mode uses persistent profiles explicitly flagged as test profiles in AEP. Sending a simulated user still triggers a real message send, which can result in a persistent profile being created.
• Q: Can I simulate a journey that starts with a Business Event? — No. Journeys triggered by a Business Event cannot be run in Simulation.
• Q: Are the Targeting rule and Experiment methods of the Optimize activity supported in Simulation? — Yes. The Journey Agent evaluates the configured rule for Targeting rule, or the eligibility and allocation for Experiment (Path Experimentation), against the simulated user’s profile attributes to select the branch.
• Q: Are decisioning elements such as offer eligibility and ranking supported during Simulation? — Yes. Offer eligibility, eligibility rule, eligibility audience, and ranking by offer priority, formula, or AI Model — Auto are supported. Ranking by AI Model — Personalization is also supported, though returned offers may vary between simulation runs.
• Q: How many simulated users can I test in a single simulation run? — Up to 100 unique simulated users per run; each Send all action is capped at 20 users at once.
• Q: Are consent policies enforced during Simulation? — No. Consent policy evaluation, frequency capping, opt-out management, and quiet hours are all not evaluated during Simulation.
• Q: What happens if my journey has more than 50 paths during AI generation? — The Journey Agent randomly selects paths to produce a maximum of 50 simulated users.