ドキュメント Journey Optimizer Journey Optimizer ガイド

ライブジャーニー実行のトラブルシューティング troubleshooting-execution

最終更新日： 2026年10月17日

適用対象：
Journey Orchestration

トピック：
ジャーニー
設定

作成対象：

中級
ユーザー

このページ：ライブジャーニーの実行をトラブルシューティングする方法について説明します。これには、イベントの送信、ジャーニー経由のプロファイルのエントリと進行状況の確認、メッセージの配信の確認が含まれます。

style

shade-box

この節では、ジャーニーイベントのトラブルシューティングを行う方法と、プロファイルがジャーニーにエントリしたかどうか、プロファイルがジャーニーをどのように移動したか、メッセージが送信されたかどうかを確認する方法について説明します。

また、ジャーニーをテストまたは公開する前に、エラーのトラブルシューティングを行うこともできます。ジャーニーをテストまたは公開する前にエラーをトラブルシューティングする方法については、🔗を参照してください。

インバウンドアクションを使用している場合は、ジャーニーでのインバウンドアクションのトラブルシューティングで、インバウンドアクションのトラブルシューティング方法を説明します。

イベントが適切に送信されているかを確認 checking-that-events-are-properly-sent

ジャーニーの開始点は常にイベントです。 Postman などのツールを使用してテストを実行できます。

これらのツールを介して送信する API 呼び出しが正しく送信されているかどうかを確認できます。エラーが返された場合は、呼び出しに問題があるということです。ペイロード、ヘッダー（特に組織 ID）、宛先の URL を再度確認します。ヒットするのに適した URL を管理者に問い合わせることができます。

イベントは、ソースからジャーニーに直接プッシュされるわけではありません。ジャーニーは、Adobe Experience Platform のストリーミング取得 API に依存しています。結果として、イベントに関する問題が発生した場合は、Adobe Experience Platform のドキュメントでストリーミング取得 API のトラブルシューティングを参照してください。

ジャーニーでエラー ERR_MODEL_RULES_16 が発生してテストモードを有効にできない場合は、チャネルアクションを使用する際に、使用するイベントに ID 名前空間が含まれていることを確認してください。

ID 名前空間は、テストプロファイルを一意に識別するために使用されます。例えば、メールを使用してテストプロファイルを識別する場合は、ID 名前空間の メール を選択する必要があります。一意の識別子が電話番号の場合は、ID 名前空間の電話を選択する必要があります。

ジャーニーへのエントリを確認 checking-if-people-enter-the-journey

ジャーニーレポートでは、ジャーニーへのエントリをリアルタイムで測定します。

イベントが正常に送信されたにもかかわらず、ジャーニーへのエントリが確認できない場合、ジャーニーのイベント送信とイベント受信の間に何か問題があるということです。

次の質問に従って、トラブルシューティングを開始できます。

イベントを受信するジャーニーが、テストモードまたはライブになっているか。
ペイロードプレビューからペイロードをコピーする前にイベントを保存したか。
イベントペイロードにイベント ID が含まれているか。
正しい URL をヒットしたか。
イベント設定ペインのペイロード構造プレビューを使用して、ストリーミング取得APIのペイロード構造に従いましたか？ペイロードのプレビューを参照してください。

イベントのヘッダーで正しいキーと値のペアを使用しましたか？

code language-none
`X-gw-ims-org-id - your organization's ID Content-type - application/json`

イベント条件とスキーマデータタイプ - イベント条件（ルール）で使用されるデータタイプがイベントスキーマと一致していることを確認します。一致しないタイプ（例：文字列と整数）は、ルール評価が失敗し、イベントがドロップされます。イベント ID の確認を参照してください。
イベントが破棄されました - 選定条件が満たされていません - ルールベースのイベントで、イベントペイロードが 選定条件 を満たさない場合（例：必須フィールドが空または欠落しているか、フィールドに対する isNotEmpty などの条件が満たされない場合）、イベントは 受信されますが破棄 され、ジャーニーはトリガーされません。ログや Splunk のトレースには、イベントは受信されたが、選定条件を満たさなかったので破棄されたことが示され、破棄コードには notSuitableInitialEvent などが含まれます。これは期待される動作です。選定条件が満たされない場合、イベントは破棄され、そのプロファイルに対してジャーニーがトリガーされません。イベントペイロードに期待されるフィールドと値が含まれており、イベント設定のルールが送信するデータと一致することを確認します。イベントが別のジャーニーから カスタムアクション によってトリガーされる場合は、カスタムアクションのトラブルシューティングにある破棄イベントとアイドルタイムアウトの処理を参照してください。

>>
ストリーミングオーディエンスを含むオーディエンスの選定ジャーニーの場合：オーディエンスの選定アクティビティをジャーニーのエントリポイントとして使用している場合、タイミング要因、オーディエンスからの迅速な退出、プロファイルが公開前にオーディエンス内に既に存在していたなどの理由により、オーディエンスに選定されたすべてのプロファイルが必ずしもジャーニーにエントリするわけではありません。詳しくは、ストリーミングオーディエンスの選定のタイミングに関する考慮事項を参照してください。

イベント ID の確認 verify-event-identity-and-rule-data-types

イベントベースのジャーニーを設定する際は、ペイロードの ID フィールドが、イベントで選択された名前空間と一致していることを確認します。イベントにプロファイルマッチング用のフィールドが含まれている場合は、イベント条件の 大文字と小文字の区別 および データタイプ が、インバウンドデータと完全に一致していることを確認します。例えば、イベントスキーマで roStatus が文字列として定義されている場合、ジャーニールールでもこれを文字列として評価する必要があります。一致しないデータタイプ（例：文字列と整数）は、ルール評価が失敗し、有効なイベントがドロップされます。同様に、イベントに選定条件（例：フィールドが空でない必要があります）がある場合、その条件を満たさないイベントは破棄され、ジャーニーはトリガーされません。その際、ログには notSuitableInitialEvent など破棄コードが表示されることがあります。

Journey Optimizer でイベント条件を検証するには、イベント設定のペイロードプレビューを使用し、ルールのタイプと値がペイロード構造と一致していることを確認します。方法について詳しくは、ペイロードのプレビューおよびルールベースのイベントの設定を参照してください。

テストモードの移行のトラブルシューティング troubleshooting-test-transitions

テストモードでテストプロファイルがジャーニーの進行に失敗した場合や、視覚的なフローにステップの進行を示す緑色の矢印が表示されない場合、問題は移行の検証に関連していることがあります。この節では、一般的なテストモードの問題の診断と解決に関するガイダンスについて説明します。

テストプロファイルが進行しない test-profiles-not-progressing

テストプロファイルがジャーニーにエントリしたが、最初のステップを超えて進まない場合は、次の点を確認してください。

ジャーニーの開始日 - 最も一般的な原因は、ジャーニーの開始日が今後に設定されている場合です。現在の時刻が、ジャーニーで設定された開始日と終了日／時間ウィンドウ外にある場合、テストプロファイルはすぐに破棄され、DISPATCHER DISCARD #16 — unqualified on journey version enablementsというログエントリが生成されます。解決するには：
- ジャーニーの開始日が今後に設定されていないことを確認します
- 現在の時刻がジャーニーのアクティブな日付ウィンドウ内にあることを確認します
- 必要に応じて、開始日を現在より前の時間に一時的に設定してテストを行ってから、公開前に復元します
テストプロファイル設定 - プロファイルが Adobe Experience Platform でテストプロファイルとして正しくフラグ付けされていることを確認します。詳しくは、テストプロファイルの作成方法を参照してください。
ID名前空間の不一致 - 名前空間の不一致により、通知なしでの破棄が発生します。つまり、イベントは受け入れられて成功応答が返されますが、プロファイルはジャーニーにエントリせず、UI でエラーが表示されません。 プロファイル識別子の名前空間が、イベントスキーマで定義されている名前空間と正確に一致することを確認します（大文字と小文字を区別します）。詳しくは、プロファイル識別子の式の形式を参照してください。

Null トランジション指標 null-transition-indicators

技術的なトラブルシューティング中に、ジャーニーの技術的な詳細で isValidTransition プロパティが null に設定されている場合があります。この UI 専用プロパティは、バックエンドの処理やジャーニーのパフォーマンスには影響しません。ただし、null 値は次を示す場合があります。

ジャーニーの設定ミス - ジャーニーの開始日が今後に設定されているので、テストイベントが通知なしで破棄されます。
破損したトランジション - まれに、ジャーニーノードを再接続する必要がある場合があります

永続的な移行の問題が発生する場合：

ジャーニーの開始日が最新であることを確認します
テストモードの非アクティブ化と再アクティブ化
問題が解決しない場合は、影響を受けるジャーニーノードを複製し、再接続することを考慮します
未解決のケースについて詳しくは、ジャーニーログ、影響を受けるプロファイル ID、null トランジションの詳細をサポートにお問い合わせください

NOTE

ジャーニーのアクティブな日付ウィンドウ外に送信されたイベントは、エラーメッセージが表示されず、ログエントリ DISPATCHER DISCARD #16 — unqualified on journey version enablements と共に通知なしで破棄され、UI エラーは発生しません。テストプロファイルの進行をトラブルシューティングする際は、常に最初にジャーニーのタイミング設定を確認します。

ジャーニーの進行状況を確認 checking-how-people-navigate-through-the-journey

ジャーニーレポートは、ジャーニーでの個人の進行状況を測定します。ユーザーがどこで、なぜ停止したのかを容易に特定できます。

次の項目を確認します。

停止の原因が、該当するユーザーを除外する条件であるか。例えば、条件が「性別 = 男性」で、人物が女性の場合。このチェックは、条件が複雑すぎない場合、ビジネスユーザーが実行できます。
データソースへの呼び出しが応答しないためか。この情報は、ジャーニーのテスト中にテストモードログに表示されます。このジャーニーがライブになると、管理者はデータソースへの直接呼び出しをテストし、受け取った回答を確認できます。管理者は、このジャーニーを複製してテストすることもできます。

ブロックされたジャーニーインスタンスによって破棄されるイベント max-instance-stack-events-reached

maxInstanceStackEventsReached という理由で破棄されたイベントが表示される場合、ジャーニーランタイムが、特定のジャーニーバージョンに対する内部プロファイルごとのイベントスタックの上限（10 イベント）に達しました。これは、同じプロファイルに対する別のイベントが引き続き処理されている間に、保留中のイベントが積み重なるのを防ぐ安全ガードレールです。

これは、時間枠やスループットの制限ではありません。これは、プロファイルのジャーニーインスタンスが、長時間実行されている手順（長い待機、エンリッチメント、カスタムアクションの再試行など）でブロックされていて、さらに、そのジャーニーで同じプロファイルのイベントが使用され、10 イベントの制限を超えて積み上げられている場合に発生します。

これを特定するには、破棄理由が maxInstanceStackEventsReached であるジャーニーステップイベントのクエリを実行します（例：serviceEvents.stateMachine.eventType や類似のフィールド）。破棄されたイベントタイプについて詳しくは、ステップイベントフィールドのリストを参照してください。ジャーニーステップイベントのフィールドについては、Adobe Journey Optimizer スキーマ参照を参照してください。

実行できる内容

頻繁に再トリガーされる場合があるパスでは、長い待ち時間や遅いステップを減らします。
可能な場合は、アップストリームイベントを重複排除またはデバウンスします。
長時間実行されるシナリオは、積み重ねを回避するために、複数のジャーニーに分割します。

メッセージが正常に送信されたかを確認 checking-that-messages-are-sent-successfully

個人がジャーニーを適切に進んでいるのに、受信すべきメッセージが届いていない場合は、以下の点を確認します。

Journey Optimizer がメッセージの送信リクエストを正しく認識している。ビジネスユーザーは、送信すべきメッセージにアクセスできます。また、最新の実行時刻がジャーニーの実行時刻と一致するかどうかを確認できます。また、受け取った最新の API 呼び出しやイベントも確認できます。
Journey Optimizer が正常にメッセージを送信している。ジャーニーレポートを調べ、エラーがないことを確認します。

カスタムアクションを介して送信されたメッセージの場合、ジャーニーテストで確認できるのは、カスタムアクションのシステムを呼び出すことでエラーが発生するかどうかだけです。カスタムアクションに関連付けられた外部システムへの呼び出しがエラーにつながらず、メッセージ送信につながらない場合は、外部システム側で調査します。

NOTE

ネイティブ Journey Optimizer チャネルアクションの場合は、メッセージフィードバックイベントデータセットをクエリして、sent や bounce などの配信ステータスを確認します。 Adobe Journey Optimizer では、sent はメッセージ配信の成功に関連するステータスです。Adobe Journey Optimizer メッセージのフィードバックイベントデータセットでは delivered 値は使用されません。カスタムアクションの場合は、ジャーニーステップイベントデータセットをクエリして、Journey Optimizer がアクションを正常に実行したことを確認します。成功した HTTP 呼び出しだけでは、外部システムがメッセージを配信したことを確認することはできません。ユースケースに適したデータセットを選択する方法について説明します。

ジャーニーステップイベントの重複エントリについて duplicate-step-events

この節では、ジャーニーステップイベントに重複する行が表示される理由を説明します。

同じジャーニーインスタンス、プロファイル、ノード、リクエスト IDを持つ複数のエントリが表示されるのはなぜですか？ duplicate-entries-why

ジャーニーステップイベントデータをクエリする際に、同じジャーニー実行に対して重複したログエントリのように見えるものが表示されることがあります。これらのエントリは、次の項目について同じ値を共有します。

profileID - プロファイル ID
instanceID - ジャーニーインスタンス識別子
nodeID - 特定のジャーニーノード
requestID - リクエスト識別子

ただし、これらのエントリには 異なる _id 値 があり、これがこのシナリオを実際のデータ重複と区別する主なインジケーターとなります。

この動作の原因は何ですか？ duplicate-entries-cause

これは、Adobe Journey Optimizer のマイクロサービスアーキテクチャでのバックエンドの自動スケーリング操作（「リバランス」とも呼ばれる）により発生します。負荷が高い期間またはシステムが最適化されている期間：

ジャーニーステップイベントの処理が開始され、ジャーニーステップイベントデータセットに記録されます
自動スケーリング操作により、サービスインスタンス間でワークロードが再配分されます
同じイベントが別のサービスインスタンスにより再処理され、異なる_id を持つ 2 番目のログエントリが作成される場合があります

これは、想定されたシステム動作で、ザインどおりに動作しています。

ジャーニーの実行やメッセージの配信に影響はありますか？ duplicate-entries-impact

いいえ。 影響はログにのみ制限されます。 Adobe Journey Optimizer には、メッセージ実行レイヤーに重複排除メカニズムが組み込まれており、このメカニズムによって次のことを確実に実行します。

1つのメッセージ（メール、モバイルメッセージ、プッシュ通知など）のみ送信されます
アクションは 1 回のみ実行されます
ジャーニーの実行は正しく進行します

これを確認するには、ajo_message_feedback_event_dataset に対してクエリを実行するか、アクション実行ログを確認します。ジャーニーステップイベントエントリが重複しているにもかかわらず、実際に送信されたメッセージは 1 つのみであることがわかります。

クエリでこれらのケースを特定するにはどうすればよいですか？ duplicate-entries-queries

ジャーニーステップイベントデータを分析する場合：

_id フィールドを確認：真のシステムレベルの重複では _id が同じです。 _id 値が異なる場合は、上記のリバランスシナリオとは異なるログエントリであることを示します。

メッセージの配信を確認：メッセージフィードバックデータと相互参照して、1 つのメッセージのみが送信されたことを確認します。

code language-sql

SELECT
  timestamp,
  _experience.customerJourneyManagement.messageExecution.messageExecutionID,
  _experience.customerJourneyManagement.messageDeliveryfeedback.feedbackStatus
FROM ajo_message_feedback_event_dataset
WHERE
  _experience.customerJourneyManagement.messageExecution.journeyVersionID = '<journeyVersionID>'
  AND TO_JSON(identityMap) like '%<profileID>%'
ORDER BY timestamp DESC;

一意の識別子でグループ化：実行をカウントする際は、正確なカウントを取得するために _id を使用します。

code language-sql

SELECT
  COUNT(DISTINCT _id) as unique_executions
FROM journey_step_events
WHERE
  _experience.journeyOrchestration.stepEvents.journeyVersionID = '<journeyVersionID>'
  AND _experience.journeyOrchestration.stepEvents.profileID = '<profileID>'

これを確認する場合はどうすればよいですか？ duplicate-entries-action

これは、通常のシステム動作で、アクションは不要です。重複したログは、ジャーニー設定やメッセージ配信に問題があることを示すものではありません。

ジャーニーステップイベントに基づいてレポートや分析を作成する場合：

一意のイベントをカウントするプライマリキーとして _id を使用します
メッセージ配信を分析する際は、メッセージフィードバックデータセットと相互参照します
タイミング分析では、互いに数秒以内にクラスター化されたエントリが表示されることがあります

ジャーニーステップイベントのクエリについて詳しくは、クエリの例を参照してください。

ダッシュボードの指標の不一致に関するトラブルシューティング dashboard-metrics

概要ダッシュボードに表示される指標が「参照」タブの実際のジャーニー数と一致しない場合は、次の点を確認してください。

最近のアクティビティがないジャーニーはダッシュボードから除外されるので、該当するジャーニーに過去 24 時間以内にトラフィックが含まれていたことを確認します。
組織内のすべてのジャーニーを表示する適切なアクセス権限があることを確認します。
ジャーニーに変更を行った後、指標が更新されるまで最大 30 分かかります。

不一致が解決しない場合は、「概要」タブと「参照」タブの両方のスクリーンショットを添えてアドビサポートに連絡して、調査を行ってください。

クローズしたジャーニーの空のプレースホルダーを示すトラッキングパラメーター tracking-parameters-closed-journeys

送信済みメールのトラッキング URL に cid=em-acou-adob{} などの空のプレースホルダーが含まれている場合、context.system.source.actionId などのコンテキストフィールドを解決できなかったことを示していることがあります。これは、ジャーニーが閉じられ、関連する製品の変更後に再公開されなかった場合に発生します。再公開されたジャーニーのみが、トラッキング URLのこれらのコンテキストフィールドに正しく入力されます。

これを解決するには、ジャーニーを再公開する（新しいバージョンを作成して公開する）か、チャネル設定またはメールコンテンツの URL トラッキングパラメーターから、影響を受けるコンテキストフィールドへの参照を削除します。

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 is a troubleshooting reference for live journey execution in Adobe Journey Optimizer, covering event delivery, profile entry, test mode transition issues, discarded events, duplicate journey step event entries, message delivery checks, dashboard metric discrepancies, and empty tracking parameter placeholders.

Intents:

Diagnose why events are not entering a journey by checking payload structure, headers, event condition data types, and qualification conditions
Verify whether profiles are entering and progressing through a journey in test mode or live
Resolve test profiles that do not progress, using the journey start date, test profile configuration, and identity namespace checks
Understand and handle the maxInstanceStackEventsReached discard reason for blocked journey instances
Identify and correctly query duplicate Journey Step Events entries that have different _id values
Investigate missing messages by checking journey reporting, message feedback, and custom action call results
Fix empty tracking URL placeholders in emails from closed journeys

Glossary:

Journey Step Events: The dataset to which journey step events are logged; queried to find discard reasons and duplicate rows, and to confirm that Journey Optimizer executed a custom action (product-specific)
notSuitableInitialEvent: A discard code that logs can show when an event was received but discarded because it did not meet the qualification condition (product-specific)
maxInstanceStackEventsReached: A discard reason that appears when the journey runtime reaches its internal per-profile event stack limit for a specific journey version (see Guardrails) (product-specific)
isValidTransition: A UI-only property in the journey’s technical details; the page states it does not impact backend processing or journey performance, and a null value can indicate a journey misconfiguration (start date set in the future) or a corrupted transition (product-specific)
Qualification condition: A condition on rule-based events; when the event payload does not satisfy it (for example, a required field is empty or missing), the event is received but discarded and the journey is not triggered
Rebalancing: A backend auto-scaling operation in Adobe Journey Optimizer’s microservices architecture that can cause the same event to be reprocessed by another service instance, creating a second log entry with a different _id

Guardrails:

Events sent outside the journey’s active date window are discarded silently with the log entry DISPATCHER DISCARD #16 — unqualified on journey version enablements and no UI error
The journey runtime has an internal per-profile event stack limit of 10 events for a specific journey version; events beyond it are discarded with maxInstanceStackEventsReached. This is not a time-window or throughput limit
The namespace in the Profile Identifier must match the namespace defined in the event schema exactly (case-sensitive); a mismatch causes a silent drop: the event is accepted and returns a success response, but the profile never enters the journey and no error is surfaced in the UI
Overview dashboard metrics only include journeys that had traffic in the last 24 hours; allow up to 30 minutes for metrics to refresh after changes
Only republished journeys correctly populate context fields in tracking URLs; a closed journey that was not republished after a relevant product change can show empty placeholders

Terminology:

Canonical name: Journey Step Events — variants: journey step events, Journey Step Events dataset, step events
Synonyms: “rebalancing” = “auto-scaling” (the backend operation that can create duplicate log entries)
Do not confuse: entries with the same _id (duplicates at system level) ≠ entries with different _id values (separate log entries from the rebalancing scenario)
Do not confuse: sent ≠ delivered — in Adobe Journey Optimizer Message Feedback Event datasets, sent is the relevant status for successful message delivery outcomes and the delivered value is not used

FAQ:

Q: Why are my events not entering a journey even though they are sent successfully? — Check that the journey is in test mode or live, that the event was saved before copying the payload from the payload preview, that the payload has an event id and follows the streaming ingestion APIs payload structure, that the URL and the header key-value pairs (X-gw-ims-org-id, Content-type) are right, that the data types in the event condition match the event schema, and that the qualification condition is satisfied.
Q: Why does the journey fail to enable test mode with ERR_MODEL_RULES_16? — Ensure the event used includes an identity namespace when using a channel action.
Q: Why do test profiles enter the journey but not advance past the initial step? — The most common cause is a journey start date set in the future; events outside the active date window are discarded silently. Also check the test profile configuration and the identity namespace.
Q: What does maxInstanceStackEventsReached mean? — The journey runtime has reached its internal per-profile event stack limit of 10 events for a specific journey version, because the profile’s journey instance is blocked on a long-running step. Reduce long waits or slow steps, deduplicate or debounce upstream events, or split long-running scenarios into multiple journeys.
Q: I see duplicate rows in journey step events - is something wrong? — No. Entries with the same profileID, instanceID, nodeID, and requestID but different _id values are expected system behavior from backend auto-scaling; the impact is limited to logging, and only one message is sent. Verify with ajo_message_feedback_event_dataset.
Q: Why do tracking URLs in emails show empty placeholders like cid=em-acou-adob{}? — A context field such as context.system.source.actionId could not be resolved because the journey was closed and not republished after a relevant product change. Republish the journey, or remove the reference to the affected context field from the URL tracking parameters.
Q: Why does the Overview dashboard show different numbers than the Browse tab? — Check that the journeys had traffic in the last 24 hours, that you have the access permissions to view all journeys in your organization, and allow up to 30 minutes for metrics to refresh.

Related pages:

Troubleshooting errors before testing or publishing a journey: Troubleshoot errors before testing or publishing your journey (building-journeys/troubleshooting.md)
Troubleshooting inbound actions: Troubleshoot inbound actions in journeys (building-journeys/troubleshooting-inbound.md)
Understanding journey step events: Journey step events (reports/journey-step-events-overview.md)
Journey error codes: Error codes reference (building-journeys/error-codes-reference.md)

recommendation-more-help

journey-optimizer-help