Iterable JourneyとBraze Canvas ジャーニー設計思想の比較と移行論点

高度なパーソナライゼーションを追求するモダンマーケティングにおいて、IterableとBrazeは常に比較の対象となります。両者ともに「クロスチャネル」「リアルタイム」「イベント駆動」を掲げていますが、そのジャーニー設計（オートメーション）の深部に触れると、驚くほど異なる哲学に基づいていることがわかります。

本記事では、Iterableの「Journey（旧Workflow）」とBrazeの「Canvas」を、実務者の視点から徹底比較します。単なる機能の有無ではなく、「なぜその仕様になっているのか」という設計思想から紐解き、ツール間の移行を検討する際に必ず直面する技術的・運用的な論点を解説します。

IterableとBrazeのジャーニー設計における根本的な違い

両ツールを使い分ける、あるいは移行を検討する上で最も重要なのは、ユーザーを「点」で捉えるか「線」で捉えるかの力点の違いです。

Iterable Journey：フレキシブルなデータハブとしての設計思想

Iterableの設計思想は、「データの柔軟性と拡張性」に極振りされています。Iterable Journeyは、非常に細かいロジックの分岐や、ネストされた複雑なJSONデータの処理に長けています。例えば、1つのイベントの中に含まれる配列データを展開し、その中身に基づいてジャーニーのルートを分岐させるような処理が、エンジニアリングに近い自由度で行えます。

Iterableは、顧客データを「単一のテーブル」として見るのではなく、動的な「カタログ」や「データフィード」と組み合わせることで、メッセージ送信の瞬間に最適な情報を外部から引き込むことに特化したアーキテクチャを持っています。

Braze Canvas：ステップベースの顧客体験最適化に特化した設計思想

対するBrazeのCanvasは、「マーケターによる体験設計の完結」を最優先しています。Canvasは、ユーザーが特定のステップに到達した際の反応（開封、クリック、あるいは無反応）に基づいて、次のアクションを直感的に視覚化することに優れています。

Brazeの強みは、インテリジェントな選択（Intelligent Selection）などのAIによるパス最適化や、チャネル間の「摩擦」を減らすUIにあります。Iterableに比べて「制約」が心地よく機能しており、誰が設定しても一貫した顧客体験を作りやすい構造になっています。

このような高度なMAツールを導入する際、土台となるデータ基盤が整理されていないと、ツールのポテンシャルを活かしきれません。特にLINE等の特定チャネルとの親和性を高めるには、高額MAツールは不要。BigQueryとリバースETLで構築する「行動トリガー型LINE配信」の完全アーキテクチャで解説しているような、データ駆動型の設計思考が必要不可欠です。

機能・仕様の徹底比較：Iterable Journey vs Braze Canvas

実務で重要となる主要機能を比較表にまとめました。数値や仕様は各公式ドキュメント（Iterable Support / Braze Docs）に基づきます。

ジャーニーの分岐ロジックとフィルター条件の差異

Iterableでは、ユーザーがジャーニーに入った時点のイベントデータ（Event Property）を、その後のすべての分岐条件で「予約変数」のように使い続けることが容易です。一方、Braze Canvasでは、各ステップの入口で「セグメントフィルター」をかける形式が一般的です。このため、Brazeでは「特定のイベントが発生した瞬間のコンテキスト」を後続のステップに引き継ぐために、ユーザー属性（User Attribute）への一時的な書き込みが必要になるケースがあります。

外部データ連携（Webhook / Connected Content）の挙動

IterableのData Feedsは、メッセージ送信前に外部APIからデータを取得し、それをHandlebarsでレンダリングします。これは、在庫情報やパーソナライズされたおすすめ商品をリアルタイムで差し込むのに適しています。

BrazeのConnected Contentも同様の機能ですが、Liquidエンジンの制限により、非常に巨大なJSONレスポンスのパースには工夫が必要です。エンジニアリングリソースが豊富な組織ではIterableの自由度が、マーケター主導の施策実行ではBrazeのテンプレート管理が好まれる傾向にあります。

実務者が直面する「移行」の5つの主要論点

一方のツールから他方へ移行する際、単純な「UIの慣れ」では解決できない構造的課題が発生します。

1. ユーザープロファイルとイベント属性のマッピング再定義

Iterableはユーザープロファイルのフィールドを比較的ルーズに扱えますが、Brazeは「カスタム属性」と「イベント属性」の区別が厳格です。ジャーニーの途中で参照したいデータが「過去の累積データ（属性）」なのか「その瞬間の行動（イベント）」なのかを再定義する必要があります。

2. キャンペーンの「状態保持（Stateful）」と「ステートレス」の差

Iterable Journeyは、ユーザーが今どのノードにいるかを厳密に管理します。一方、Brazeの旧Canvas（Flow導入以前）は、ステップ間を遷移する際に一定の評価タイミングが存在しました。最新のBraze Canvas Flowではこの差は縮まっていますが、「特定の条件を満たさなくなった瞬間にジャーニーから離脱させる（Re-evaluation）」の挙動は、ツールごとに設定箇所が異なるため注意が必要です。

3. メッセージテンプレートと言語仕様（Handlebars / Liquid）

これが最も手のかかる作業です。IterableのHandlebarsとBrazeのLiquidは似て非なるものです。特に「if/else」の記法や、配列のループ処理（each vs for）、日付フォーマットの変換などはすべて書き直しになります。正規表現を用いたテキスト置換である程度自動化できますが、最終的なプレビュー確認は1件ずつ行う必要があります。

4. A/Bテストとパス最適化の移行

Brazeの「Winning Variant」による自動最適化機能を多用している場合、Iterableへ移行すると、同様の機能を「Experimentノード」と「Webhook」を組み合わせて自作しなければならない場合があります。逆に、Iterableの多分岐ロジックをBrazeに移す際は、Canvasが横に広がりすぎて視認性が悪化するため、Canvasを分割するなどの設計変更が求められます。

5. 既存ジャーニーの「ドレイン（枯渇）」と並行運用の設計

移行時、最も危険なのが「同じユーザーに新旧両方のツールからメッセージが届く」ことです。既存のIterable Journeyにいるユーザーを最後まで走らせる（ドレイン）期間と、新規流入をBrazeに切り替えるタイミングを厳密に制御しなければなりません。

こうしたツール選定や移行の背景には、企業のSaaSコスト増大という課題も潜んでいます。SaaSコストを削減。フロントオフィス＆コミュニケーションツールの「標的」と現実的剥がし方【前編】で触れているように、機能の重複を整理し、真に必要なツールを見極めることが肝要です。

移行ステップバイステップ：IterableからBraze（またはその逆）へ

具体的な移行手順を整理します。これは、数十のジャーニーを抱える大規模エンタープライズ環境を想定したフローです。

STEP 1：既存ジャーニーのロジック棚卸しと優先順位付け

すべてのジャーニーを移行する必要はありません。過去3ヶ月で有意なコンバージョンに寄与していないものは廃止を検討します。

• トリガーイベントの定義（API Callか、属性変更か）
• 待ち時間（Delay）のロジック
• 分岐条件（Segment/Filter）の複雑さ

これらをスプレッドシートにリストアップし、新ツールでの実現可否を判定します。

STEP 2：データスキーマの互換性チェック

IterableでネストされたJSON（例：purchase.items[0].name）を多用している場合、Braze側でそれを「Nested Custom Attribute」として取り込むか、あるいはフラットな構造に変換して送信するかを決めます。Brazeの現在の仕様ではネストされたオブジェクトも扱えますが、インデックスの張り方やセグメント作成時のパフォーマンスに影響するため、公式ドキュメントで最新の制限値を確認してください。

STEP 3：Webhookと外部連携の再実装

ジャーニー内で外部システム（自社DBやLINE配信サーバーなど）と連携している場合、Webhookのヘッダー設定や認証フローを再構築します。特に、LIFF・LINEミニアプリ活用の本質。Web行動とLINE IDをシームレスに統合する次世代データ基盤で構築したような、ID連携を含む高度な基盤を利用している場合、エンドポイント側でのユーザー識別子（External ID）の受け取り方に差異がないか検証が必要です。

よくあるエラーと対処法

エラー例：Handlebars/Liquidのシンタックスエラー

原因：IterableからBrazeへのコピー時、{{ user.firstName }} を {{ ${first_name} }} に書き換え忘れる、あるいはエスケープ処理の不足。

対処： 各プラットフォームの「プレビューモード」で、実データを流し込んでレンダリング結果を強制確認するプロセスを必須化してください。

どちらを選ぶべきか？ジャーニー設計の判断基準

結論として、どちらのツールが優れているかは「組織のスキルセット」と「データの複雑性」に依存します。

• Iterableを選ぶべきケース： データ構造が複雑で、エンジニアリングチームがマーケティング施策に深く関与できる場合。あるいは、外部APIとの動的なデータ連携を極限まで突き詰めたい場合。
• Brazeを選ぶべきケース： マーケティングチーム単体で高速にPDCAを回したい場合。UI/UXの洗練度や、モバイルアプリへのプッシュ通知・アプリ内メッセージの「手軽さ」を重視する場合。

まとめ：ツール移行を超えた「顧客体験」の再設計

Iterable JourneyからBraze Canvasへ（あるいはその逆）の移行は、単なるツールの乗り換えではなく、自社の顧客コミュニケーションの「設計図」を書き直す作業です。設計思想の違いを理解せずに移行を強行すれば、新ツールの機能を旧ツールのやり方で再現するだけの「劣化コピー」になりかねません。

それぞれのツールが持つ「得意なジャーニーの描き方」に合わせ、データ構造から見直すことで、初めて高額なライセンス費用に見合うCRMの高度化が実現します。移行を機に、サイロ化したデータを整理し、真にリアルタイムでパーソナライズされた顧客体験を再構築していきましょう。