ジャーニーシミュレーションの基本を学ぶ 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日（PT）の日付では、その日付でシミュレーションが実行されている場合にのみ、ユーザーが実行できます。 実行日はモックできません。 テストする際は、現在の日付に条件を設定します。 プロファイルキャップ：シミュレーション中はキャップが適用されません。 AIは、ブランチごとに1人のシミュレートされたユーザーを作成します。 分岐選択はモックできません。 ユーザーを誘導するには、キャンバス上の分岐の順序に依存します。 常に上位の分岐が選択されます。
タイムアウトとエラー分岐	AIは、アクティビティタイムアウトまたはエラーブランチのユーザーを生成しません。 シミュレーション中にリアルタイムのタイムアウトまたはエラーが発生した場合にのみ、ユーザーはこれらのパスを入力します。
タイムアウト分岐（イベントアクティビティ）	シミュレートされたユーザーは作成されますが、手動シミュレーション​では、AIがイベントタイムアウトブランチに入るユーザーを決定しません。 イベントを送信するかしないかによって、パスを制御します。 例えば、タイムアウト分岐をテストするには、設定されたタイムアウトを待ち、イベントを送信しません。 クイックシミュレーション​では、タイムアウト分岐を対象とするためにイベントを自動的に送信または保留できます。
反応イベント	反応イベントはシミュレーションで実行されますが、アクションは実際に発生する必要があります。 例えば、メールの​ 開封 ​という反応を得るには、本配信前確認メッセージを開く必要があります。 シミュレーション 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）	シミュレーション中は評価も適用もされません。
サンドボックスツール（サンドボックスをまたいでシミュレートされたユーザーをコピー）	サポートされていません。
ジャーニーでのウェーブ送信	サポートされていません。
クワイエットアワー	シミュレーション中は評価も適用もされません。
Privacy Service	シミュレートされたユーザーは、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	ジャーニー全体での累積キャップではなく、すべて送信​または​ 選択したイベントをトリガー ​の各実行ごとにカウントされます。
生成リクエストあたりのシミュレートされたユーザーの最大数	50	最大シミュレートされたユーザーAIは、クイックシミュレーション​または​AIを使用して生成、手動シミュレーション​を通じて1回のリクエストで生成されます。 ジャーニーのパス数が​ 50 ​を超える場合、AIはパスをランダムに選択して、シミュレートされた​ 50 ​人のユーザーを生成します。
単一のシミュレーション実行でテストされた、ユニークなシミュレートされたユーザーの最大数	100	1 回の実行でユニークユーザー数が 100 人に到達すると、新規のシミュレートされたユーザーに対する​ シミュレートされたユーザーを選択 ​がブロックされます。 現在 90 人の場合、同じブロックの前に最大でさらに 10 人を追加できます。
1 つのサンドボックスで、シミュレーション​時に同時に実行可能なジャーニーの最大数	20	キャップは、そのサンドボックス内のすべての​ シミュレーション ​ジャーニーで一度に共有されます。
1 つのサンドボックスでのアクティブなシミュレートされたユーザーの最大数	2,000	一度にサンドボックスに存在できるシミュレートされたユーザーの最大数。 アドビでは、お客様からのフィードバックに基づいて、この制限を調整する場合があります。
イベントの事前入力（ブラウザーのみ）	—	イベントペイロードのフィールドを事前入力できるのは、ブラウザーベースのシミュレーション 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 Simulation 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 three ways to test and validate a journey: Journey Simulation, Journey Test mode, and Journey Dry run
• Understand the difference between Simulation and Test mode for validating journeys
• Launch a Simulation session for a batch or unitary 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
• Understand Quick simulation and Manual simulation

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 Dry run: A validation method that runs a journey against real production audience and segmentation data without contacting real customers or updating profile information (product-specific)
• Experiment (Path Experimentation): An Optimize activity method whose routing is handled by Decisioning, with random assignment that is non-deterministic per simulated user (product-specific)

Guardrails:

• To use Simulation, assign at least one of: Simulate journeys, Publish journeys, or Approve and Publish journeys permissions from the Journeys capability; these permissions also allow users to create and manage simulated users without Simulated Users permissions
• Managing simulated users without Simulation requires Manage Simulated Users or View Simulated Users from the Simulated Users capability
• AI-powered simulation features (Quick simulation, AI-generated users, and Generate event values) require Generate Content from the AI Assistant capability
• Maximum 20 simulated users per Send all or Trigger selected events batch (hard limit)
• Maximum 50 simulated users per AI generation request (hard limit)
• Maximum 100 unique simulated users per single simulation run (hard limit)
• Maximum 20 journeys running Simulation simultaneously in one sandbox (hard limit)
• Maximum 2,000 active simulated users in one sandbox at a time (hard limit)
• Journeys that start with a business event cannot be run in Simulation
• Simulation does not start when multiple re-entrance is enabled and the same simulated user could have several active instances at once
• Consent policies, frequency capping, and quiet hours are not evaluated during Simulation; opt-out management and STO are not evaluated or applied
• Simulated users are not GDPR-compliant persistent profiles; do not include real customer data in simulated users

Terminology:

• Canonical name: Simulation — Acronym: none
• Canonical name: Simulated users — Acronym: none
• Canonical name: Experiment — variants: Path Experimentation
• Do not confuse: “Simulation” ≠ “Test mode” (Test mode uses persistent profiles flagged as test profiles in Adobe Experience Platform; Simulation uses temporary simulated users)
• Do not confuse: “Journey Simulation” ≠ “Journey Test mode” ≠ “Journey Dry run” (the three validation methods use different data and validation approaches)
• Do not confuse: Targeting rule ≠ Experiment (both are Optimize activity methods, but AI evaluates the configured rule for Targeting rule, whereas routing for Experiment is handled by Decisioning)

FAQ:

• Q: What permissions do I need to use Simulation? — Assign at least one of: Simulate journeys, Publish journeys, or Approve and Publish journeys from the Journeys capability. These permissions also let you create and manage simulated users; Simulated Users permissions are not required. AI features additionally require Generate Content from the AI Assistant capability.
• Q: What permissions do I need to manage simulated users without Simulation? — You need Manage Simulated Users or View Simulated Users from the Simulated Users capability.
• Q: What are the three ways to test and validate a journey? — Adobe Journey Optimizer offers Journey Simulation, Journey Test mode, and Journey Dry run.
• Q: How does Simulation differ from Test mode? — Simulation uses temporary simulated users without pre-created profiles in Adobe Experience Platform; Test mode uses persistent profiles explicitly flagged as test profiles in Adobe Experience Platform. 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 that start with a business event cannot be run in Simulation.
• Q: Are the Targeting rule and Experiment methods of the Optimize activity supported in Simulation? — Targeting rule is evaluated by AI against the simulated user’s profile attributes. For Experiment (Path Experimentation), routing is handled by Decisioning and assignment is random and non-deterministic per simulated user.
• 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 policies, frequency capping, and quiet hours are not evaluated during Simulation. Opt-out management is not evaluated or applied.
• Q: What happens if my journey has more than 50 paths during AI generation? — AI randomly selects paths to produce 50 simulated users.