Reverse ETL とは：仕組みと、使わなくてよい場合

2025年5月1日、Fivetran は Census の買収契約を結びました。Fivetran の本業は、アプリケーションのデータをウェアハウスへ移すことです。Census はその逆で、ウェアハウスからデータを取り出し、アプリケーションへ戻していました。入り口の道を造った会社が、出口の道を造った会社を買い、製品名を Fivetran Activations に変えました。

その出口の道を Reverse ETL と呼びます。名前は不格好です。解決する問題は昔からあります。

Reverse ETL とは

Reverse ETL とは、データウェアハウスやその他のシステム・オブ・レコード（記録の基幹システム）でモデル化したデータを、チームが実際に行動を起こす業務用 SaaS ツールへコピーするプロセスです。 CRM、メール配信プラットフォーム、サポートデスク、広告ネットワーク。ウェアハウスは、顧客のライフタイムバリューや解約スコアのような有用な値を計算します。Reverse ETL はその値を、営業担当やマーケターが毎朝開くツールの該当レコードに書き込みます。

dbt Labs はこれを「データウェアハウスに保存された変換済みデータを、営業用 CRM や広告プラットフォームなどの最終的なビジネスプラットフォームへ届けるプロセス」と定義しています。同じ記事は、ほかに目にする 2 つの呼び名も挙げています。オペレーショナルアナリティクスとデータアクティベーションです。

「リバース（逆）」という言葉は、逆にする対象があって初めて意味を持ちます。従来の ETL（抽出、変換、ロード）とその現代版である ELT は、分析のためにアプリケーションから生データを取り出してウェアハウスに入れます。Reverse ETL は、その分析結果を外へ押し戻します。一方の流れはレポートを動かします。もう一方は行動を動かします。

病院の検査室を考えてみてください。検査室は検査を行い、結果を出し、保管します。結果が検査室のキャビネットに眠っていれば、病棟の医師は目にしません。Reverse ETL は、その結果を患者のカルテに書き込む工程です。誰も褒めない工程です。それがなければ、検査は無意味でした。

1. SaaS アプリ

   システム・オブ・レコード

   注文、連絡先

   イベント、チケット
   ETL / ELT
2. ウェアハウス

   SQL モデル

   ライフタイムバリュー

   解約スコア
   reverse ETL
3. 実行ツール

   CRM、メール、広告

   レコード上のフィールド

   オーディエンス

Reverse ETL が存在する理由

約 10 年間、モダンデータスタックは一方向だけを得意にしてきました。Fivetran、Stitch、Airbyte が生レコードを Snowflake、BigQuery、Redshift にロードしました。dbt がその生テーブルをきれいなモデルに変えました。Looker や Tableau がその上にグラフを描きました。

そしてグラフは放置されました。アカウントマネージャーが開くのは相変わらず Looker ではなく Salesforce でした。ライフサイクルマーケターは相変わらず SQL ではなくメールツールでセグメントを作っていました。サポート担当は相変わらず Zendesk で仕事をしていました。データチームが生み出した有用な数字はすべて、それを必要とする人からタブ 1 つ分離れた場所にありました。

チームはこの隙間を手作業で埋めました。毎週の CSV エクスポート。誰かのノートパソコンで動く、HubSpot API を呼び出す Python スクリプト。フィールド名が変わると壊れる Zap。Reverse ETL ツールは、この使い捨てスクリプトの山を製品に変えました。何をどこへ送るかを 1 か所で定義でき、ログとリトライが付いています。

Fivetran 自身の解説記事は、購入される 3 つの用途を挙げています。マーケティングチームは、ウェアハウスの属性から作ったセグメントを狙います。営業チームは、CRM レコード上で製品の利用状況と更新日を確認します。カスタマーサクセスチームは、普段使っているツールでヘルススコアと定着指標を確認します。

Reverse ETL の仕組み

市場にあるすべての Reverse ETL ツールは、作業を同じ 4 つの部分に分けます。Segment のドキュメントはそれを「ソース、モデル、デスティネーション、マッピング」と列挙しています。Fivetran の解説記事は、ソース、モデル、同期、デスティネーションという言葉を使います。形は同じです。

1. ソース。 行の取得元となるシステムです。ウェアハウスファースト型のツールなら、クラウドウェアハウスかデータレイクです。Segment のセットアップガイドは 7 つを挙げています。Azure、BigQuery、Databricks、Db2、Postgres、Redshift、Snowflake です。

2. モデル。 送りたい行と列を正確に返すクエリです。通常は SQL か dbt モデルで、ビジュアルなフィルタービルダーの場合もあります。各行には安定した識別子が必要です。Segment はこれを Unique Identifier 列と呼び、「新規、更新、削除されたレコードの検出に使われる」と説明しています。値が変わる列を選ぶと、毎回の同期が全件の書き直しに見えてしまいます。

3. フィールドマップ。 翻訳の層です。列 ltv_usd は HubSpot のコンタクトプロパティ lifetime_value になります。email 列は、宛先が既存レコードを見つけるための照合キーになります。判断の大半はここにあり、バグの大半もここから始まります。

4. 同期。 比較し、書き込み、結果を記録するスケジュールジョブです。エンジニアリングの本体はここにあります。

変更検出：テーブルではなく差分を送る

素朴な同期なら、毎回すべての行を送ります。顧客が 200万人で 1 時間ごとのスケジュールなら、実際の変更が数千件程度でも、1 日に 4,800万回の API 書き込みになります。そんな負荷を許容する宛先 API はありませんし、許容すべきでもありません。

だからツールは差分を取ります。Hightouch のドキュメントははっきり書いています。「実行と実行の間に、Hightouch は変更データキャプチャを使って現在のモデル結果を前回の実行と比較し、追加、変更、削除された行だけを送信します。」Segment は識別子列で同じことをします。初回の実行はバックフィルです。それ以降の実行はすべて差分です。

これは Reverse ETL ツールで最も重要な性質です。変更分だけを送る同期は、安価で高速で、レート制限にも負担をかけません。テーブル全体を送り直す同期は負債であり、宛先が 429 を返し始めた日にそれが発覚します。

書き込みモード：インサート、アップデート、アップサート、ミラー

宛先によって許可される操作が異なるため、同期ごとに書き込みモードを選びます。Hightouch は主要なモードを 3 つ文書化しています。インサートは新規レコードを追加するだけです。アップデートは既存レコードを変更するだけです。アップサートは、一致するレコードがなければ挿入し、あれば更新します。RudderStack はさらにミラー動作を加えます。削除も含めて、宛先をソースと同一に保つ動作です。

ほとんどのコンタクト同期やアカウント同期では、アップサートが既定です。CRM にどの顧客がすでに登録されているか、事前にわかることはまずないからです。危険なのはミラーです。モデルから行が外れると、宛先でも削除します。オーディエンスリストなら、それで正しい動作です。CRM の場合、誰かがモデルの WHERE 句を編集した金曜日に大惨事になります。

レート制限と障害処理

どの SaaS API にもレート制限があり、どの一括書き込みもいずれ宛先に拒否されるレコードにぶつかります。不正な形式のメールアドレス。空のままの必須フィールド。存在しない選択リストの値。

Hightouch のリトライに関するドキュメントは、これがどう動くべきかの良い参考になります。拒否されたレコードは同じ実行内で指数バックオフによりリトライされ、既定では 5 回試行します。無効として拒否されたリクエスト（400、401、403、422）はリトライしません。不正なリクエストを再送しても何も変わらないからです。レート制限による応答（429）には、より多くのリトライ枠が与えられます。実行をまたいでは、Hightouch は「拒否されたすべてのレコードのインデックスを、主キーをキーとして」保持し、成功するかモデルから外れるまで、以降の実行で各レコードをリトライします。

1 件の不良行のせいで宛先がバッチ全体を拒否すると、Hightouch はバッチを半分に分け、さらに半分に分け、不良レコードを特定するまで続けます。残りの行は通ります。この細部が、ツールとスクリプトを分けます。

1. スケジュールされた同期の実行

2. モデルを実行

   • クエリが現在の行を返す

3. 前回の実行と比較

   • 追加、変更、削除分のみ

4. フィールドをマッピング

   • 列を宛先のプロパティへ

5. バッチで書き込み

   • インサート、アップデート、アップサート

6. 拒否分をリトライ

   • 実行内でバックオフ、次回用にインデックス化

7. 実行ログ：同期済み、拒否、リトライ

スケジュール

ほとんどの同期はタイマーで動きます。Segment は 15 分から 1 日までの固定間隔、または指定した曜日の特定時刻を選べます。Hightouch と RudderStack はどちらも cron 式を受け付け、dbt Cloud の実行や Airflow の DAG など、上流のジョブが終わったときに同期を起動することもできます。

dbt のプレイブックは、リアルタイムそのものを目的にすることを戒めています。「『リアルタイム』の領域では慎重に進むこと。」実行が 1 回増えるたびに、料金のかかるウェアハウスクエリが 1 回増えます。誰も 1 日 1 回以上見ないモデルを 1 時間ごとに同期するのは、何も生まないお金の使い方です。

Reverse ETL と ETL、ELT、iPaaS、CDP の違い

この反論は公平に聞く価値があります。内容はこうです。「Reverse ETL は、SQL クエリを前に置いた API 連携にすぎない。Zapier も CDP もすでにある。なぜ 3 つ目を買うのか。」半分は正しい指摘です。確かに、クエリを前に置いた API 連携です。そのクエリこそが要点です。

ETL と ELT はデータをウェアハウスに入れます。Reverse ETL は外に出します。両者は 1 つのループの両半分であり、だから Fivetran は Census を買いました。

iPaaS ツール（Zapier、Make、Workato など）は、あるアプリのイベントに反応して別のアプリの API を呼び出します。「商談が成立したら Slack に投稿する」は得意です。「3 年分の注文から計算したスコアで 40,000 件のコンタクトを更新する」は苦手です。モデルも差分もなく、テーブルという概念もないからです。こうしたツールを比較検討しているなら、統合プラットフォームのベスト 12の比較記事で 1 つずつ解説しています。

従来型のCDPはイベントを収集し、顧客プロフィールの独自コピーを作り、そのコピーからオーディエンスを配信します。Reverse ETLは、モデル化した項目の参照元としてデータウェアハウスを使います。実装によっては変更検知の状態や拒否されたレコードを保存するため、保存内容と保持期間を確認してください。両者の境界は曖昧です。Hightouchはreverse ETLエンジン上に構築されたコンポーザブルCDPを名乗り、SegmentはCDPの機能としてreverse ETLを提供しています。

正直にまとめると、送る値が計算されたものであるとき、Reverse ETL は正しいツールです。複数のシステムのデータを結合し、集計し、スコア化して初めて存在するフィールドです。そのフィールドがソースアプリにすでに存在するなら、必要なのはモデルではなくコピーです。

Reverse ETL は必要か？

1. スコアやセグメントをすでにウェアハウスで作っている

   Reverse ETL

   値はモデル化して初めて存在します。それをツールへ届けます。

2. あるアプリのイベントで別のアプリの操作を起動したい

   iPaaS（Zapier、Make、Workato）

   イベント駆動で、差分を取るテーブルがありません。

3. イベント収集とプロファイルが必要で、データチームがいない

   パッケージ型 CDP

   プロファイルの保存と名寄せを代行します。

4. レコードが Shopify、Stripe、HubSpot にあり、ウェアハウスがない

   アプリ間の直接同期

   同じ差分同期を、ウェアハウスを作らずに実現します。

不要なケース

Hightouch、Fivetran、RudderStack はいずれも「reverse etl」で Google の 1 ページ目に表示され、3 社とも Reverse ETL を販売しています。彼らのガイドは、使わなくてよい場合の説明にほとんど紙幅を割いていません。そのリストがこちらです。

ウェアハウスがなく、導入する計画もないなら、Reverse ETL は不要です。CRM のフィールド 1 つを埋めるためにウェアハウスを構築するのは、パンを 1 斤焼くために工場を建てるようなものです。

宛先が、必要なフィールドを運ぶネイティブ連携をすでに備えているなら不要です。メールツールに注文データが必要なストアは、SQL で注文をモデル化するのではなく、その連携をインストールすべきです。

データに基づいて行動する人がいないなら不要です。どのワークフローも、ビューも、人も読まない CRM フィールドに解約スコアを同期しても、見返りのないコストが 1 行増えるだけです。dbt のプレイブックも反対側から同じことを指摘しています。その最初のステップは、モデルを書く前に、ビジネスオーナーが何を期待しているかを理解することです。

主要な Reverse ETL ツール

「reverse etl tools」の検索結果は 4 つの製品が占めています。4 つともクラウドウェアハウスから読み取り、SQL でモデル化し、フィールドをマッピングし、実行間の差分を取ります。違いは同期の周辺にあります。

Hightouch

Hightouch は現在、自社を「マーケターのための顧客データ＆AI プラットフォーム」と説明しており、Reverse ETL はコンポーザブル CDP と AI による意思決定製品を下で支えるエンジンです。サイトには、広告、マーケティングオートメーション、CRM、カスタマーサクセスにわたり「300以上のツールと連携」と書かれています。同期とリトライのドキュメントは、Reverse ETL エンジンが変更検出、拒否、レート制限をどう扱うかについて、公開されている中で最も詳しい説明です。ウェアハウスとデータチームがあり、その上にマーケティングの層を築きたいチームに向いています。

Census (Fivetran Activations)

Census は独立した Reverse ETL ベンダーでしたが、2025年5月に Fivetran が買収を発表し、現在は Fivetran Activations として販売されています。Fivetran はこの組み合わせを「データ移動の両側を 1 つのツールでカバーする最初のプラットフォームの 1 つ」と呼んでいます。データの取り込みですでに Fivetran に支払っていて、両方向をベンダー 1 社、請求書 1 枚にまとめたいチームに向いています。

RudderStack Reverse ETL

RudderStack の Reverse ETL 製品ページには、ウェアハウスの行を identify 呼び出しや track 呼び出しに変えるテーブル同期が挙げられています。ほかにも、カスタム SQL モデル、ビジュアルなフィールドマッパー、cron スケジュール、Apache Airflow や Dagster からのオーケストレーションが並びます。「アクティベーション向けに 200 を超えるビジネスツール」をうたっています。すでに RudderStack でイベントを収集している、エンジニアリング主導のチームに向いています。

Twilio Segment Reverse ETL

Segment の Reverse ETL は、先に挙げた 7 つのウェアハウスから読み取り、Salesforce、Google Ads、Braze、Mixpanel などの Segment デスティネーションに書き込みます。特別な Segment Connections デスティネーションはウェアハウスの行を Segment Spec の呼び出しに変換するので、ウェアハウスのデータを既存の Segment パイプラインに流せます。すでに Segment を CDP として運用していて、ウェアハウスからそこへデータを送りたい企業に向いています。

4 つすべてに同じコストがかかり、それは料金ページには載っていません。ウェアハウスが必要で、そのモデルを正しく保つ人が必要で、宛先が API を変えたときに各同期の責任を持つ人が必要です。データチームのある会社なら、そのコストは支払い済みです。従業員 12人のストアにとっては、それがプロジェクトのすべてです。

ウェアハウスなしの Reverse ETL：アプリ間同期

このカテゴリーがまだ解決していない矛盾があります。Reverse ETL の仕組みは汎用的です。モデル、フィールドマップ、差分、アップサート、リトライ。ところが製品のパッケージはウェアハウスを前提にしています。中小企業の多くはウェアハウスを持っておらず、そのシステム・オブ・レコードはすでに SaaS アプリです。

Shopify ストアの注文は Shopify にあります。決済は Stripe にあります。営業パイプラインは HubSpot にあります。メールと SMS は Brevo から配信されます。移す必要のあるデータの大半は、計算されたものではありません。少し翻訳してコピーするだけです。Shopify の total_spent は連絡先の属性に、Stripe のサブスクリプション状態は請求用の属性に、HubSpot のライフサイクル段階はセグメントになります。これらの値はマーケティングへの同意を証明しません。同意には別の記録が必要です。

この形のデータにとって、ウェアハウスはホップを 1 つ、請求書を 1 枚、チームを 1 つ増やすだけで、同期に必要なものは何も返しません。同期に本当に必要なのは、ウェアハウス型ツールが学んできたことのすべてです。増分の変更検出、安定した識別子をキーにしたアップサート、レート制限のバックオフ、拒否されたすべてのレコードのログ。間にウェアハウスがなくても、これらの要件は小さくなりません。むしろアプリの API は、ウェアハウスへのクエリより融通が利きません。

アプリ間の具体的な経路はShopifyからBrevoへのガイドをご覧ください。Brevo PushOwl、同意済みの顧客1人、注文1件から始めます。この標準経路はTajoコネクターの提供状況とは別です。アプリが既に保有する項目をコピーするだけのために、ウェアハウスを追加しないでください。

最初の有用な結果を検証可能にする

これは設計演習であり、稼働中のTajoウェアハウスコネクターの実績報告ではありません。モデルはcustomer_id、email、order_countを出力します。書き込む前にレコードの照合規則を決め、正しい型の宛先属性を作成します。

自分で管理でき、同意を得た連絡先を1件使います。計算した件数を対応するBrevoレコードに書き込み、読み戻して確認します。同じモデル出力を再実行しても連絡先が増えないことを確かめます。件数を変更したら、対象属性だけが変わるはずです。古いモデル行に購読中と残っていても、その後の配信停止は維持されなければなりません。

モデルの版、送信元ID、宛先ID、結果を一緒に保存します。この短い記録で、リクエストの受理と、対象レコードが実際に意図した値を持つことを区別できます。Brevo APIガイドは宛先への書き込みを説明しますが、ウェアハウス接続やスケジューラーは提供しません。

エージェントによる Reverse ETL

Reverse ETL の難所は、HTTP 呼び出しだったことは一度もありません。フィールドマップでした。どの列がどのプロパティに対応するか。どの識別子が安定しているか。どの書き込みモードなら CRM の半分を消さずに済むか。それは判断であり、少し前までは、データエンジニアが午後いっぱいかけて 2 つの API リファレンスを並べて読むことを意味していました。

これをエージェントに任せることへの反論は公平で、内容はこうです。「エージェントはフィールドマップを推測する。顧客レコードに書き込むシステムで推測を誤れば、顧客レコードが壊れる。」後半は正しい指摘です。前半は、エージェントの出力が書き込みではなく提案であるなら誤りです。

エージェントは送信元と宛先のスキーマから項目マッピング案を作れます。有効化前に、本人照合、空値の扱い、書き込み方向、同意の正本を確認してください。有用な案には変更対象レコードと成功を判定する証拠が示されています。

ツールへのアクセスは仕組みの一部です。ジョブを動かすスケジューラー、進捗を保存する永続状態、安全な再試行と結果不明の副作用を区別する障害処理も必要です。MCPサーバーとはでは、読み取り専用のTajo例でこの境界を説明します。

Tajoは早期アクセス段階です。ワークスペースで実際に使える送信元と宛先を確認し、有効化前に実演を伴うテストを求めてください。統合ガイドやMCPツール一覧だけでは、本番の同期が動く証拠にはなりません。

進む道の選び方

カテゴリーではなく、成果物から始めてください。誰かが行動を起こす 1 つのツールに必要な、1 つのフィールドを書き出します。次に、そのフィールドがどこで計算されているかを問います。

ウェアハウスで計算されているなら、Reverse ETL ツールを買い、すでに支払っているベンダーを基準に選んでください。ソースアプリにすでに存在するなら、アプリ同士を直接同期し、ウェアハウスは省いてください。そのフィールドで誰も行動しないなら、何も同期しないでください。

ウェアハウスは最初から目的ではありませんでした。目的は、レコード上のフィールドでした。