ジャーニーシミュレーションの基本を学ぶ 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
制限付きノード	メモ
ビジネスイベント	シミュレーション​では、ビジネスイベントで開始するジャーニーを実行できません。
インバウンドチャネル	シミュレーション​では、インバウンドチャネルノードを含むジャーニーを実行できません。
データセットの参照	シミュレーション​は、キーによる顧客データセットの参照をサポートしていません。 シミュレーションを実行する前に、このアクティビティを削除または変更します。
最適化​アクティビティ	最適化​メソッドは次のように動作します。 ターゲティングルール​：AI は、シミュレートされたユーザーのプロファイル属性に対して設定されたルールを評価し、分岐を選択します。 実験（パス実験）：ルーティングは、50/50 の分割や 10％の除外でも分割に対して決定によって処理されます。 シミュレートされたユーザーごとの割り当ては、ランダムで非決定論的です。そのため、例えば、クイックシミュレーション​で AI 生成ユーザーを含む 5 人程度のユーザーの小規模なバッチでは、すべての処理を対象とすることは保証されず、偶然、全員が同じ処理に割り当てられる可能性があります。 これは、以下の​ 割合分割 ​とは異なります。 割合分割​：AI は、分岐の割合に従うのではなく、分岐ごとに 1 人のシミュレートされたユーザーを作成します。 実行時には、ライブ評価によって分岐が選択され、生成されたパスとは異なる場合があります。 分岐選択はモックできません。 ユーザーを誘導するには、キャンバス上の分岐の順序に依存します。 常に上位の分岐が選択されます。 時間条件：条件は、ライブジャーニーと同様に、実行時に適用されます。 例えば、8:00 から 20:00 までのウィンドウでは、そのウィンドウ内でシミュレーションが実行されている間にのみ、ユーザーが実行できます。 実行時間はモックできません。 テストする際は、現在の時間に合わせて条件を設定します。 日付条件​：条件は、ライブジャーニーと同様に、実行時に適用されます。 例えば、2026年6月8日（PT）の日付では、その日付でシミュレーションが実行されている場合にのみ、ユーザーが実行できます。 実行日はモックできません。 テストする際は、現在の日付に条件を設定します。 プロファイルキャップ：シミュレーション中はキャップが適用されません。 AI では、分岐ごとに 1 人のシミュレートされたユーザーが作成されます。 分岐選択はモックできません。 ユーザーを誘導するには、キャンバス上の分岐の順序に依存します。 常に上位の分岐が選択されます。
タイムアウトとエラー分岐	AI では、アクティビティタイムアウトまたはエラー分岐のユーザーが生成されません。 シミュレーション中にリアルタイムのタイムアウトまたはエラーが発生した場合にのみ、ユーザーはこれらのパスを入力します。
タイムアウト分岐（イベントアクティビティ）	シミュレートされたユーザーは作成されますが、手動シミュレーション​では、AI はイベントタイムアウト分岐にエントリするユーザーを決定しません。 イベントを送信するかしないかによって、パスを制御します。 例えば、タイムアウト分岐をテストするには、設定されたタイムアウトを待ち、イベントを送信しません。 クイックシミュレーション​では、タイムアウト分岐を対象とするためにイベントを自動的に送信または保留できます。
反応イベント	反応イベントはシミュレーションで実行されますが、アクションは実際に発生する必要があります。 例えば、メールの​ 開封 ​という反応を得るには、本配信前確認メッセージを開く必要があります。 シミュレーション UI では、反応はモックできません。
外部データソース	シミュレーション中の呼び出しは、ライブジャーニーと同様に実行されます。 ダウンストリームアクティビティで応答は使用できますが、モックできません。 応答の値が​ 最適化 ​アクティビティをフィードする場合、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 モデル - パーソナライゼーション​によるランキング	サポートされています。 オーディエンスはランキングに対して考慮され、実施要件に対して考慮されません。 ランキングは 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 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 人を追加できます。 オーディエンスの読み取りジャーニーで補足 ID を使用すると、この制限は、一意のユーザーではなく​ 合計ジャーニー実行数 ​を追跡します。 例えば、同じ 5 人のシミュレート済みユーザーを 20 回再実行すると、制限に達します。 シミュレーションを停止して再起動するか、リセットすると、カウントがクリアされます。
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 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)

Glossary:

• Simulated users: Temporary profile-like entities created for Simulation. Sending a simulated user triggers a real message send; if an impacted dataset, such as feedback or tracking events, is profile-enabled, a persistent profile can be created in Adobe Experience Platform (product-specific)
• Simulation: A journey feature 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:

• The journey must be validated before entering Simulation. Errors in the Alerts panel must be resolved and validation rerun before continuing.
• 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); with a supplemental ID on a Read audience journey, this counts total journey runs rather than unique users
• 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
• 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
• Canonical name: Simulated users
• 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: 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 triggers a real message send; if an impacted dataset is profile-enabled, a persistent profile can be 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, and ranking by offer priority or formula are supported. Eligibility audience is supported when the audience is added to the simulated user’s profile. AI Model - Auto requires the necessary data in the configured dataset. AI Model - Personalization considers the audience for ranking, not eligibility; 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; with a supplemental ID on a Read audience journey, the limit counts total journey runs. Each Send all action is capped at 20 users at once.