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

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

Last update: Tue Nov 25 2025 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 に依存しています。結果として、イベントに関する問題が発生した場合は、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
NOTE
ストリーミングオーディエンスを使用したオーディエンス選定ジャーニーの場合：オーディエンス選定アクティビティをジャーニーエントリポイントとして使用している場合、オーディエンスに適合するすべてのプロファイルが、タイミング要因、オーディエンスからの迅速な離脱、または公開前にプロファイルがオーディエンスに既に含まれていた場合に必ずしもジャーニーにエントリするわけではありません。 詳しくは、​ ストリーミングオーディエンスの選定のタイミングに関する考慮事項 ​ を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. メッセージの配信を確認：メッセージフィードバックデータと相互参照して、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;

  3. 一意の識別子でグループ化：実行をカウントする際は、正確なカウントを取得するために _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>'

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

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

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

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

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

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

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

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

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

recommendation-more-help
b22c9c5d-9208-48f4-b874-1cefb8df4d76