Treasure Data CJO完全解説①｜Customer Journey Orchestrationの基本構造

Treasure DataのCJO（Customer Journey Orchestration）は、「複雑に見えて、仕組みを理解すれば単純だ」というツールだ。

公式ドキュメント（Treasure Academy Advanced Program）でも「ジャーニーはすごろくのようなもの」という表現が使われている。このメタファーは秀逸で、CJOの挙動を理解する上で最も重要な視点だ。

この記事では、公式ドキュメントの内容をベースに、現場エンジニアとして「ここが分かれば全部分かる」という構造を解説する。

なぜCJOが必要なのか——従来のアクティベーションの3つの限界

CJOを理解するには、「CJOが解決しようとした問題」から入ることが重要だ。

Treasure Dataのオーディエンススタジオ（Audience Studio）には、セグメントを作ってMAツールなどに「アクティベーション（データ送信）」する機能がある。しかし従来のアクティベーションには、現場で頻繁に問題になる3つの限界があった。

限界①：「差分だけ送れない」問題

従来のアクティベーションは「そのとき対象セグメントに属しているプロファイル全員」を毎回送る。

例えば「休眠顧客セグメント」を毎日アクティベーションすると、昨日も今日も休眠中の顧客に、毎日メールが送られ続ける。「昨日初めて休眠状態になった顧客だけに1回だけ送りたい」という「差分アクティベーション」が、従来の方法では難しかった。

限界②：「施策を連鎖させられない」問題

「メール配信→開封した人には3日後にSMS→開封しなかった人には7日後に別のメール」
このようなシナリオの連鎖を、従来のアクティベーションだけで実現するのは困難だった。やるとすればdigdagのワークフローで複雑なロジックを書くしかなく、ハードルが高かった。

限界③：「イベントトリガー施策をUIで管理できない」問題

「商品をカートに入れてから2日以内に購買しなかった顧客に自動でメールを送る」
こういったイベント起点の施策をGUI上で設定・管理できる手段がなかった。

CJOはこれら3つを全て解決する。

CJOの全体構造——「すごろく」のメタファーで理解する

CJOを理解する核心が「ジャーニーはすごろくだ」という公式ドキュメントの言葉だ。

【すごろく ＝ ジャーニー】
  ジャーニー全体    ＝ すごろくのボード全体
  ステージ          ＝ すごろくのエリア（区画）
  ステップ          ＝ すごろくのマス
  プロファイル      ＝ すごろくの駒（プレイヤー）
  journey WFの更新  ＝ サイコロを振る（1日1回）

1日1回、「journey WF（ワークフロー）」が更新される。この更新が「サイコロを振る」行為だ。 更新のたびに、各プロファイル（駒）は「現在のマスから次のマスへ」1つ進む。Wait Stepで「〇日待て」と書いてあるマスに止まった駒は、その日数が過ぎるまで次に進めない。

重要なのは「全プレイヤーの駒が同時に動く」ことだ。100万人のプロファイルがそれぞれ異なるステージ・ステップにいて、毎日の更新のたびに各自が「次のマス」へと進んでいく。これがCJOの動作原理だ。

CJOの構成要素——「ジャーニー → ステージ → ステップ」の入れ子構造

CJOの構造は3層の入れ子になっている。

ジャーニー（Journey）
  └── ステージ1（Stage）          ← 最大8つ
        └── ステップA → ステップB → ステップC ...  ← 最大40オブジェクト
  └── ステージ2（Stage）
        └── ステップX → ステップY ...
  └── ステージ3（Stage）
        └── ...
  └── ゴール（Goal）

ジャーニー（Journey）

1つのカスタマージャーニー全体を表す「プロジェクト」だ。例えば「新規顧客育成ジャーニー」「休眠顧客ウィンバックジャーニー」などが各1つのジャーニーになる。

重要なルール

• 異なるジャーニー同士は独立しており、1人のプロファイルが複数のジャーニーに同時に属することができる
• 1つのジャーニー内には、同じプロファイルが複数存在することはできない（同一ジャーニー内では1人1箇所）
• 最大オブジェクト数は40（ステージ内のステップ数の合計）

ステージ（Stage）

カスタマーファネルの各段階を表す。「認知→興味→検討→購買」のような各フェーズをステージに対応させる。ステージには順序があり、プロファイルは上（前方）のステージから下（後方）へと進んでいく。

最大8ステージまで設定可能。

エントリールールの重要な特性

• プロファイルが複数のステージのエントリー条件を同時に満たしている場合、最後方のステージにエントリーする
• 既にあるステージを進んでいても、後方のステージのエントリー条件を満たしたら、後方のステージへの移動が優先される（これが「ステージアップ」の仕組み）

ステップ（Step）

ステージ内のシナリオを構成する個々の「マス」だ。7種類のステップがある。

7種類のステップ——各マスの役割と使い方

① Activation Step（アクティベーションステップ）

役割： このステップを「通過した」プロファイルにアクティベーション（MAツールへのデータ送信など）を実行する。
最重要の注意点： 「通過するタイミング」と「アクティベーションが実行されるタイミング」は別だ。

【タイミングの関係】
 journey WF更新（例：毎朝1時）
   → プロファイルがActivation Stepを通過（記録される）
   
 Activation実行（例：毎朝6時）
   → 「当日中にActivation Stepを通過したプロファイル」を対象に実行

つまり、journey WFの更新がアクティベーション実行より前に完了していれば、そのプロファイルは当日のアクティベーションの対象になる。逆にアクティベーション実行後にjourney WFが更新された場合、そのプロファイルは翌日まで待つことになる。

この「journey WFとActivation WFの実行順序の設計」が現場で最もよく詰まるポイントだ。
基本的にジャーニー更新後のアクティベーションが良い。

設定のポイント（String Builder）： Activation Stepの設定には、通常のアクティベーションにはない便利な変数が使える。

制約：

• スケジュールはDaily固定（Weekly・Hourlyには変更不可）
• Activation Template・Advanced Activation Scheduleは利用不可

② Wait Step（待機ステップ）

役割： プロファイルが次のステップに進む前に「N日間待機」させる。

Activation Stepの間に挟んで、「メール送信 → 5日待つ → 反応チェック → 次のメール」というシナリオを組む際に使う。

設計のポイント： 連続するActivation Stepの間には必ずWait Stepを入れることを推奨する。Wait Stepがないと、プロファイルは1回のjourney WF更新でActivation Stepを連続通過してしまい、同日中に複数のアクティベーションが発生する。

③ End Step（終了ステップ）

役割： ステージのパスの末尾に配置する終端マーカー。

End Stepがなくてもシナリオは動くが、journeyテーブルのデバッグがしやすくなるため、強く推奨される。「ステージを移動しないプロファイルはEnd Stepに留まり続ける」という動作になる。

④ Decision Point（分岐ポイント）

役割： パスを分岐させる。セグメント条件に基づいてプロファイルを振り分ける。

例：メール開封した人 → 分岐A（フォローアップメール）
    メール開封しなかった人 → 分岐B（リマインドSMS）
    どちらでもない人 → Excluded profiles（デフォルト分岐）

重要： 評価は上から順番に行われる。「Excluded profiles」は、他のどの条件にも当てはまらなかったプロファイルを捕捉するデフォルト分岐だ。Excludedを設定しなければどちらかの条件に当てはまるまで待機する。あえてこのようにすることもある。case文でelseがないようなイメージ。

⑤ Merge（マージ）

役割： 分岐したパスを1本に合流させる。
分岐したパスは必ずしもMergeする必要はなく、そのまま各分岐にEnd Stepを置いて終わらせても良い。

⑥ Jump Step（ジャンプ）

役割： 同じジャーニーの別ステージ、または別のジャーニーのステージへプロファイルを移動させる。

ジャンプのルール（重要）：

• ジャンプ先のジャーニーに既にプロファイルがいる場合、後方のステージにいる状態が優先される（前に進むジャンプのみが成功する）
• ジャンプ後、プロファイルは元のジャーニーに再度エントリーできる状態になる

⑦ A/B Test（A/Bテスト）

役割： パス上のプロファイルをランダムに分岐させる。バリアントごとの割合を設定できる。

注意： A/Bテストの仕組みはランダム分岐のみで、効果測定や統計検定の機能はない。journeyテーブルのデータを使って自分でSQLで分析する必要がある。

3つの基準——「いつ入り、いつ次へ進み、いつ抜けるか」

Entry Criteria / Milestone（エントリー基準 / マイルストーン）

Entry Criteria（エントリー基準）： ジャーニーの最初のステージに入るための条件。「〇〇セグメントに属している」などをセグメントエディタで定義する。

Milestone（マイルストーン）： 2番目以降のステージへ進むための条件。一つ上のステージの「出口基準」として設定し、これを満たしたプロファイルが次のステージへ移動する。

例：購買育成ジャーニーの場合
ステージ1（認知）のEntry Criteria
  「過去30日以内にサイトを閲覧したが、未購買のプロファイル」
ステージ2（検討）のMilestone
  「過去7日以内に同じ商品ページを3回以上閲覧した」
ステージ3（購買直前）のMilestone
  「カートに商品を入れたが24時間以内に購買していない」

Goal Criteria（ゴール基準）

ジャーニーのコンバージョン条件。ゴール基準を満たしたプロファイルは、ジャーニー上のどの位置にいても即座にゴールに移動する。

ゴールをジャーニーの最終ステージとして設定することもできるが、ゴールはステージとは別物として扱うほうが望ましい（セグメントエディタでのゴール到達プロファイルの分析がしやすくなる）。

Exit Criteria（終了基準）

役割： ジャーニーからプロファイルをドロップアウト（除外）させる条件。

ステージごとに設定でき、設定した条件を満たしたプロファイルは即座にジャーニーから除外される。

デフォルトのStale Profile： 「あるステージに入ってからN日以上留まり続けているプロファイル」を自動でドロップアウトさせる。例えば「ステージ1に30日以上いる顧客はジャーニーから除外する」という設定だ。

現場のベストプラクティス： 終了基準には外部セグメントを参照させる設計にしておくと、起動後もその外部セグメントを編集することで終了基準の条件を変更できる。緊急時に「特定のプロファイルをジャーニーから除外したい」という状況での対応が格段に楽になる。

起動と運用——「起動したら基本的に編集できない」という制約を理解する

ジャーニーの3つの状態

最重要の注意点： 起動したジャーニーは、ステージの追加・削除・ステップの変更など、構造的な変更ができない。かつドラフトに戻すことも不可能だ。

起動後にジャーニーを変更したい場合の選択肢：

1. 現在のジャーニーをポーズして、コピーして新たに起動する
2. Exit Criteriaを活用して段階的にプロファイルをドロップアウトさせ、新しいジャーニーへ移行する

起動の仕組み「ペアレントセグメントとの連動」

起動後のジャーニーは、ペアレントセグメント（親セグメント）のスケジュール更新のたびに動く。

ペアレントセグメント更新 → audience WF実行 → (callback) → journey WF実行

重要な注意点

• ペアレントセグメントにスケジュールが設定されていないと、journey WFは更新されない
• Activation Stepはdaily固定のため、ペアレントセグメントのスケジュールも必ずdailyに設定する
• audience WFが正常終了しても、journey WFが正常に終了しているとは限らない（別々に確認が必要）

journey WFの特定方法

journey WFを特定するには、ジャーニーエディタのURLを確認する。

URL例：
https://console-next.treasuredata.com/app/ps/257941/e/13/j/da
この場合：
  ペアレントセグメントID：257941
  ジャーニーID：13
  WFプロジェクト名：cdp_audience_257941
  WF名：journey_13

WF一覧で “Master Segment” フィルターを使えば該当のjourney WFを見つけられる。

オプション機能——実運用で必須の4つ

Duplicate Journey（コピー）

起動中またはドラフトのジャーニーをコピーする機能。コピーされたジャーニーはドラフト状態で、プロファイルは空の状態からスタートする。

使い方： 起動後のジャーニーを変更したい場合に、コピーして編集し、旧ジャーニーをポーズして新ジャーニーを起動する。

Pause & Resume（ポーズ & レジューム）

起動中のジャーニーを一時停止できる。ポーズ中はjourney WFの更新もActivation Stepのアクティベーションも停止する。

Re-Entry of Stale Profiles（再エントリー）

終了基準（Exit Criteria）によってドロップアウトしたプロファイルを、翌日から再エントリーできるようにするオプション。デフォルトはオフ。

注意： Jump後のプロファイルの再エントリーは、このオプションで抑止することはできない。

Jump（ジャンプ）

別のジャーニーのステージへプロファイルを送り出す機能。複数のジャーニーを連携させる際に使う。

現場でよく詰まるポイント——3つの「なぜ動かない？」

詰まりポイント①：「ジャーニーが更新されない」

最多原因：ペアレントセグメントにdailyスケジュールが設定されていない。

Journey WFは自動起動できず、ペアレントセグメントのaudience WF経由でしか実行されない。ペアレントセグメントのスケジュールを確認すること。

詰まりポイント②：「アクティベーションが実行されない」

原因1：journey WFの実行時刻がアクティベーション実行時刻より後になっている。

例：journey WFが6時、Activation実行が5時 → Activation実行時点でまだ当日の通過プロファイルがいないため、誰もアクティベーションされない。

解決策： journey WFを先に実行（例：深夜1時）し、Activation実行をその後（例：朝6時）に設定する。

原因2：プロファイルがActivation Stepを通過していない。

Entry Criteriaの条件が厳しすぎてプロファイルがエントリーできていない、またはWait Stepで待機中でまだActivation Stepに到達していない可能性がある。journeyテーブルを確認する。

詰まりポイント③：「意図しないプロファイルがステージにエントリーしている」

解決策（公式Tipsより）： 終了基準に外部セグメントを参照させておき、その外部セグメントに除外したいプロファイルのIDを追加する。

終了基準（外部セグメント参照）：
  「既存の条件」 OR 「除外したいプロファイルのtd_client_idリスト」

これにより、次回のjourney WF更新時に該当プロファイルが自動でドロップアウトする。

実践ユースケース——ウィンバックジャーニーの設計例

公式ドキュメントの内容を踏まえて、現場でよく使う「休眠顧客ウィンバックジャーニー」の設計例を示す。

【ウィンバックジャーニー設計例】
ペアレントセグメント：
  全会員（daily更新）
ジャーニー名：休眠顧客ウィンバック
───────────────────────────────
ステージ1：ライトな休眠（60〜90日未購買）
───────────────────────────────
  Entry Criteria：
    「最終購買から60日〜90日経過 かつ 過去LTV > 3万円」
  パス：
    Activation Step（A）     ← 「お久しぶりです」メール配信
    ↓
    Wait Step（3日）
    ↓
    Decision Point（分岐）
      ├─ 開封した → Activation Step（B）「特別クーポン」メール
      └─ 開封していない → End Step
  Exit Criteria：
    購買した（→ ゴールへ）
    90日以上経過（→ ステージ2へ）
  Goal Criteria：
    「直近7日以内に購買した」
───────────────────────────────
ステージ2：ディープな休眠（91〜180日未購買）
───────────────────────────────
  Milestone：
    「最終購買から91日以上経過 かつ 過去LTV > 3万円」
  パス：
    Activation Step（C）     ← 「特別オファー」メール配信
    ↓
    Wait Step（7日）
    ↓
    Decision Point（分岐）
      ├─ 購買した → End Step（ゴールが自動検出）
      └─ 購買していない → Activation Step（D）「最後のオファー」
  Exit Criteria：
    180日以上経過（ジャーニーから除外）
───────────────────────────────
ゴール：購買完了
───────────────────────────────
  Goal Criteria：
    「直近7日以内に購買した」
    （ジャーニー上のどこにいても即座にゴールへ移動）

この設計のポイント

• ステージ1の Exit Criteria に「90日以上経過→ステージ2へ」ではなく、ステージ2のMilestoneに「91日以上経過」を設定することで、ステージアップの条件を明確にしている
• Goal Criteriaはジャーニー全体に適用されるため、どのステージにいても購買した瞬間にゴールへ移動する
• 終了基準に外部セグメントを参照させることで、運用中に除外プロファイルを動的に管理できる

まとめ：CJO設計の鉄則5箇条

鉄則①：ドラフト段階で全ての設計を完成させる
  → 起動後の構造変更は不可。「あとで直せる」と思わないこと。
鉄則②：journey WFはActivation実行より前に完了するよう時刻設定する
  → ペアレントセグメント更新 → journey WF → Activation の順で時間を設計。
鉄則③：End Stepを必ず各パスの末尾に置く
  → journeyテーブルのデバッグが格段に楽になる。
鉄則④：Exit Criteriaは外部セグメントを参照させる
  → 起動後に条件を変更・除外プロファイルを追加できる。緊急対応の生命線。
鉄則⑤：Wait Stepを省かない
  → Activation Stepが連続すると、1回のjourney WF更新で連続通過が発生する。
    意図しない連続アクティベーションを防ぐために必ず挟む。

参考ドキュメント