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

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

Last update: Wed Apr 08 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

適用対象：
Journey Orchestration

トピック：

作成対象：

中級
ユーザー

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

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

インバウンドアクションを使用している場合、トラブルシューティングを行う方法について詳しくは、このページを参照してください。

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

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

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

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

ジャーニーでエラー 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

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

テストプロファイルが進行しない

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

ジャーニーの開始日 - 最も一般的な原因は、ジャーニーの開始日が今後に設定されている場合です。現在の時刻が、ジャーニーで設定された開始日と終了日／時間ウィンドウ外にある場合、テストプロファイルはすぐに破棄されます。解決するには：
- ジャーニーの開始日が今後に設定されていないことを確認します
- 現在の時刻がジャーニーのアクティブな日付ウィンドウ内にあることを確認します
- 必要に応じて、ジャーニーのプロパティを更新し、開始日を調整します
テストプロファイル設定 - プロファイルがAdobe Experience Platformでテストプロファイルとして正しくフラグ付けされていることを確認します。詳しくは、テストプロファイルの作成方法を参照してください。
ID 名前空間 - イベント設定で使用する ID 名前空間が、テストプロファイルの名前空間と一致することを確認します。

Null トランジション指標

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

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

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

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

NOTE

ジャーニーのアクティブな日付ウィンドウ外に送信されたイベントは、エラーメッセージが表示されず、通知なしで破棄されます。テストプロファイルの進行をトラブルシューティングする際は、常に最初にジャーニーのタイミング設定を確認します。

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

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

以下に、確認すべき点をいくつか示します。

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

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

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

これは、時間枠またはスループットの制限として not です。これは、プロファイルのジャーニーインスタンスが長時間実行中のステップ（長時間待機、エンリッチメント、カスタムアクションの再試行など）でブロックされ、同じプロファイルのイベントがジャーニーでも使用され、イベントの上限10を超えて積み重ねられるときに発生します。

それを識別するには、破棄の理由がmaxInstanceStackEventsReachedに等しいジャーニーステップイベントをクエリします（例：serviceEvents.stateMachine.eventTypeまたは同様のフィールド）。破棄されたイベントタイプについて詳しくは、ステップイベントフィールドリストを参照してください。

実行できること

長い待ち時間や、頻繁に再トリガーされる可能性のあるパスのステップを減らします。
可能な場合は、アップストリームイベントの重複を排除するか、離脱します。
長時間実行しているシナリオを複数のジャーニーに分割し、積み重ねないようにします。

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

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

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

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

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

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

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

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

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

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

この動作の原因は何ですか？

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

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

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

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

いいえ。影響はログにのみ制限されます。Adobe Journey Optimizerには、メッセージ実行レイヤーに次の機能を備えた重複排除メカニズムが組み込まれています。

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

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

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

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

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

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

code language-sql

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;`

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

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>'`

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

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

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

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

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

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

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

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

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

矛盾が解決しない場合は、「概要」タブと「参照」タブの両方のスクリーンショットを使用して、Adobe サポートにお問い合わせください。

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

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

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

recommendation-more-help

b22c9c5d-9208-48f4-b874-1cefb8df4d76