このページについて：ジャーニーシミュレーション、ジャーニーテストモード、ジャーニードライランを比較します。 デザイン段階での迅速な反復処理から、実際のオーディエンスを対象としたリリース前の最終チェックに至るまで、ジャーニー構築における現在の段階でどれが適しているかを確認します。
Adobe Journey Optimizer では、公開前にジャーニーを検証するための 3 つの方法が用意されています。 これらには互換性はありません。それぞれが異なる種類のデータを使用し、構築プロセスの異なる段階に適しており、実際のケースにおいて異なる結果をもたらします。 最初に違いを理解することで、2 つのよくある間違いを回避することができます。 1 つ目は、簡単なシミュレーションで済むにもかかわらず、時間をかけてテストプロファイルを作成してしまうことです。 2つ目は、実際の受信トレイに連絡したり、アウトバウンドコールを行ったりできる場合でも、検証手順が完全に「安全」であると見なしてしまうことです。
このページでは、ジャーニーフローの検証とロジックの分岐に焦点を当てます。 コンテンツのプレビュー、メールのレンダリングとスパムチェック、A/B 実験、承認ワークフローなど、テストと承認の機能の全体像について詳しくは、テスト、検証、承認を参照してください。
検証を初めて使用する場合 ここから開始 quick-pick
どの方法が適しているかがわからない場合は、次の質問に回答してください。
- まだジャーニーをデザインしている段階ですが、テスト プロファイルを作成せずに分岐のロジックを迅速に検証する必要があります。 → ジャーニーシミュレーションを使用します。
- 実際の（テスト用に指定されている）プロファイルを使用して、ドラフトジャーニーのロジックを手動およびステップバイステップで検証します。 → ジャーニーテストモードを使用します.
- 誰にも連絡せずに、実際の本番環境オーディエンスに対して期待されるボリュームを公開し、最終確認を行おうとしています。 → ジャーニードライランを使用します。
まだよくわからない、または全体像を把握したい場合 続きを読む — 各方法の詳細は以下のとおりです、
3 つの検証方法 validation-methods
使用するタイミング：ジャーニーのデザイン中、特に納期の直前または新しい分岐やパスのテストでの迅速な反復処理を行う場合。 また、ユースケースに適したテストプロファイルを作成するのが実用的でない場合は、継続的な検証方法としても機能します。
ジャーニーシミュレーションは、一時的にシミュレートされたユーザーを使用してジャーニーを検証します。実際の Adobe Experience Platform（AEP）テストプロファイルを作成したり、反映されるのを待ったりする必要はありません。 シミュレートされたユーザーを手動で作成するか、AI にジャーニーに必要なテストイベントを自動的に生成させて、適切なシミュレートされたユーザーにマッチングさせることで、ジャーニーを数秒でトリガーすることもできます。
主な仕組み：
- シミュレート済みユーザーは、AEP 内の実際のプロファイルではありません。毎回ゼロから作成する代わりに、インベントリにシミュレート済みユーザーを保存しておくと、今後のシミュレーションで再利用できます。
- 終了条件、同意ポリシー、頻度/ジャーニーのキャップ、オプトアウト/抑制、クワイエットアワーは評価されません。
- カスタムアクションと外部データソースの呼び出しでは、引き続き実際のアウトバウンドコールが行われます。これらはモックされません。
| note important |
|---|
| IMPORTANT |
| シミュレーションでは、シミュレート済みユーザー（自分のメールアドレスなど）に設定された実行アドレス（メール、電話番号、プッシュトークン）に実際のメッセージが送信されます。 本番環境と同じ配信パイプラインを使用します。 実際の顧客に連絡したり、ライブプロファイルデータを更新したりすることはありませんが、メッセージは実際に送信されます。 |
次の操作に最適： AEP テストプロファイルが反映されるを待たずに新しい分岐（2 つの新しい決定ポリシーパスなど）を検証します。
使用するタイミング：実際の（テスト用に指定されている）プロファイルを使用して、ドラフトジャーニーを順を追って進めながら、分岐とメッセージのロジックを手動およびステップバイステップで検証する場合。
ジャーニーテストモードを使用すると、永続的な AEP テストプロファイルを使用してドラフトジャーニーを検証できます。 本番環境のオーディエンスがジャーニーを利用する前に、分岐ロジックとメッセージ配信の仕組みが設計どおりに機能していることを確認するには、インターフェイスからイベントを手動で実行します。
主な仕組み：
- リアルタイム顧客プロファイルサービスで「テストプロファイル」としてフラグ付けされたプロファイルのみがジャーニーテストモードでジャーニーにエントリできます。
- ジャーニーテストモードは、名前空間を使用するドラフトジャーニーでのみ使用できます。ユーザーがテストプロファイルであるかどうかを AEP と照合する必要があります。
- 1 回のテストセッション中に最大 100 個のテストプロファイルがジャーニーにエントリでき、イベントは API 経由で外部システムから実行するのではなく、インターフェイスからのみ実行できます。
- ジャーニーテストモードを無効にすると、ジャーニーにエントリしたすべてのプロファイルが削除され、レポートがクリアされます。
| note important |
|---|
| IMPORTANT |
| ジャーニーテストモードは、本番環境と同じ配信パイプラインを使用して、テストプロファイルの実際の受信トレイに実際のメッセージを送信します。 実際の顧客には連絡しませんが、「ドライ」シミュレーションではありません。テストプロファイルには、必ず自分で管理可能なアドレスを使用するようにしてください。 |
課題：新しい AEP テストプロファイルの作成と生成には時間がかかります。 ジャーニーシミュレーションは、テストプロファイルをまったく必要としない、高速な代替手段を提供します。 これは、プロファイルの生成を待っている間だけでなく、ユースケースに適したテストプロファイルを作成するのが実用的ではない場合にも役立ちます。
➡️ ジャーニーのテスト
使用するタイミング：公開直前に行う、本番に対して現実的な最終確認。
ジャーニードライランは、実際の顧客への連絡やプロファイル情報の更新を行うことなく、本番のオーディエンスやセグメント化データを使用してジャーニーを実行する、特別なジャーニー公開モードです。 ジャーニーはライブジャーニーのようにアクティブ化し、プロファイルは本番とまったく同じように分岐やノードを通じてフローします。 ただし、電子メール、モバイルメッセージ、カスタムアクションなどの アクションノード はバイパスされます。
主な仕組み：
- 実際の本番オーディエンスを使用するので、実際のリーチやターゲティングを大規模に確認できます（例：ある分岐全体で予期せずプロファイル数がゼロになるバグの検出）。
- 各アクティベーションで、指標をより迅速に取得するために待機アクティビティを無効にし、ジャーニーを完全にサイロ化させるために外部データソースへの呼び出しを無効にすることができます。
- これは現在、限定提供機能であり、時間の経過と共にグローバルにロールアウトされています。
最適な用途：ジャーニーを公開する直前に、条件ノードの入力ミスや、予期せず分岐に到達しないオーディエンスといった問題の検出。
➡️ ジャーニーのドライラン
使用する必要がある方法 decision-guide
シンプルな質問から開始：ユースケースに適合するテストプロファイルは既に用意されていますか？ はいの場合、ジャーニーテストモードを使用すると、ステップバイステップで検証できます。 いいえの場合や、特定のユースケースのためにこれらを作成するのが実用的でない場合は、代わりに ジャーニーシミュレーション を使用すると、数秒で検証できます。
その選択の先にある回答は通常、このテストを本番にどの程度近い状態にする必要があるかというもう 1 つの質問に集約されます。
ジャーニーデザインの反復処理（新しい分岐のテスト、期限に向けた作業）をまだ行っている場合は、ジャーニーシミュレーションを使用します。 実際のプロファイルは不要で、数秒で実行します。 また、ユースケースに適したテストプロファイルを作成するのが実用的ではない場合は、ビルドの後半であっても、依然として有効な選択肢となります。 シミュレートされたユーザーに設定された実行アドレスに実際のメッセージが送信される点に注意してください。
分岐やメッセージのロジックをステップバイステップで手動で検証する必要があり、AEP テストプロファイルを作成または再利用する場合は、ジャーニーテストモードを使用します。 これらのテストプロファイルの実際のインボックスに実際のメッセージが送信される点に注意してください。
実際の本番オーディエンスに対して期待されるボリュームを 公開 しようとしており、最終確認を行う場合は、ジャーニーのドライランを使用します。 任意のユーザーへの連絡や、プロファイルデータの変更を行うことはまったくありません。
クイック比較 quick-comparison
これらの方法はいずれも、実際の顧客に連絡するものではありません。 いずれの場合もプロファイルデータは変更されませんが、例外として、ジャーニーテストモードでは、その実行に使用されるテストプロファイル（実際の顧客プロファイルではない）が更新されます。
回避すべきよくある間違い common-mistakes
- ジャーニーシミュレーションが完全に「安全」であると見なす。 テストを行うには最速の方法ですが、シミュレートされた各ユーザーに設定された実行アドレス（通常は自分の受信トレイ）に、実際のメッセージが送信されます。 何も送信されないと思い込まないでください。
- ジャーニーシミュレーションで済む場合に、AEP テストプロファイルを作成する。 新しい分岐または decision-policy パスを迅速に検証する必要がある場合、シミュレーションを使用すれば、テストプロファイルが完全に反映されるまで待つ必要がありません。ジャーニーテストモードは、実際のテストプロファイルが必要な場合になったときに使用します。
- ジャーニーテストモードを「ドライ」として扱っている。 ジャーニーテストモードのプロファイルは、本番環境の配信パイプラインを通じて実際のメッセージを受け取ります。 テストプロファイルでは、自分で管理可能なアドレスのみを使用するようにします。
- コンテンツまたは配信の問題を検出するために、ジャーニードライランを予定している。 ドライランは、アクションノードを完全にバイパスします。メッセージコンテンツや配信の仕組みではなく、オーディエンスリーチと分岐ロジックを検証します。 この場合は、シミュレーションまたはジャーニーテストモードを使用します。
- ジャーニーテストモードの名前空間要件を忘れている。 ジャーニーテストモードは、名前空間を使用するドラフトジャーニーでのみ機能します。これは、Journey Optimizer でプロファイルがテストプロファイルとしてフラグ付けされているかどうかを確認するには名前空間が必要になるためです。
次の手順 next-steps
- ジャーニーシミュレーションの基本を学ぶ — 最初のシミュテーションを実行する
- ジャーニーをテストする — AEP テストプロファイルを使用してジャーニーテストモードを有効にする
- ジャーニードライを実行する – 本番環境で使えるレベルのドライランを実行する
- ジャーニーを公開する – 前提条件と公開プロセス
- ジャーニーの基本を学ぶ – 基礎と機能の概要
- Journey Orchestration に関する FAQ — よくある質問への回答
- テスト、検証、承認 - コンテンツのプレビュー、レンダリング／スパムチェック、実験、承認ワークフローなど、テストと承認の概要
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 compares Journey Simulation, Journey Test mode, and Journey Dry run to help users choose a validation method for their current stage of building a journey.
Intents:
- Choose the correct validation method for a given stage of journey building
- Compare Journey Simulation, Journey Test mode, and Journey Dry run side by side
- Understand when to use Journey Simulation for fast iteration without real test profiles
- Understand when to use Journey Test mode for step-by-step manual validation with real test profiles
- Understand when to use Journey Dry run for a final pre-launch check against production data
- Understand which validation methods send real messages or contact real customers
Glossary:
- Journey Simulation: A validation method that uses temporary simulated users, manually created or auto-generated, to test a journey without needing real AEP test profiles. (product-specific)
- Journey Test mode: A validation method that uses persistent AEP test profiles, flagged in Real-Time Customer Profile, to manually walk through a draft journey’s branch and message logic. (product-specific)
- Journey Dry run: A publication mode that runs a journey against real production audience data without contacting customers or updating profile data; action nodes are bypassed. (product-specific)
Guardrails:
-
Validate runs configuration checks, including message checks, and shows errors and warnings in the Alerts panel; it does not replace testing. Errors must be resolved and validation rerun before continuing. Edits require revalidation before testing or publishing.
-
Journey Test mode is only available for draft journeys that use a namespace, and supports a maximum of 100 test profiles per session (hard limit)
-
Journey Test mode events can only be fired from the interface, not from external systems via API
-
Journey Test mode sends real messages to test profiles’ real inboxes using the production delivery pipeline
-
Disabling Journey Test mode removes all profiles that entered the journey and clears its reporting
-
Journey Simulation does not evaluate exit criteria, consent policies, frequency/journey capping, opt-out/suppression, or quiet hours
-
Journey Simulation’s custom actions and external data source calls are real, not mocked
-
Journey Simulation sends real messages to the execution addresses (email, phone, push token) configured on the simulated users, using the same delivery pipeline as production
-
Unlike Journey Simulation, Journey Dry run never sends real messages
-
Journey Dry run is currently a Limited Availability feature, being rolled out globally over time
-
Journey Dry run bypasses action nodes (email, Mobile message, custom actions) but still routes profiles through branches and nodes using real production data
Terminology:
- Canonical names: Journey Simulation, Journey Test mode, Journey Dry run
- Do not confuse: Journey Simulation (temporary simulated users, no AEP test profiles needed, sends real messages to the simulated users’ configured execution addresses) ≠ Journey Test mode (persistent AEP test profiles, sends real messages to those profiles’ real inboxes) ≠ Journey Dry run (real production audience data, no contact, no profile update, action nodes bypassed, never sends real messages)
FAQ:
- Q: Which validation method should I use while I am still designing a journey? — Use Journey Simulation; it needs no real test profiles and runs in seconds, making it ideal for fast iteration.
- Q: Does Journey Simulation send real messages? — Yes. Simulation delivers real messages to the execution addresses (email, phone, push token) configured on the simulated users, often the tester’s own address. It uses the same delivery pipeline as production, but it does not contact real customers or update live profile data.
- Q: Does Journey Test mode send real messages? — Yes. Journey Test mode delivers real messages to the actual inboxes of your test profiles, using the same delivery pipeline as production. It does not contact real customers, but the messages themselves are real.
- Q: Does Journey Dry run send any messages? — No. Dry run bypasses action nodes such as email, Mobile message, and custom actions, so profiles flow through the journey logic without any message being sent.
- Q: Is Journey Dry run available to everyone? — It is currently a Limited Availability feature being rolled out globally over time.
- Q: Can I fire Journey Test mode events from an external system? — No; in Journey Test mode, events can only be fired from the interface, not from external systems via API.