Brevo コネクターガイド：Brevo をスタックにつなぐ 4 つの方法
Brevo のコネクターが実際にどう動くのか。ネイティブプラグイン、iPaaS、連携レイヤー、直接 API の違いを整理し、本番環境の同期障害を乗り切る選び方を解説します。
「Brevo コネクター」と検索すると、マーケットプレイスのプラグイン、サードパーティの自動化アプリ、コミュニティ製モジュールが雑多に並びます。「コネクター」がひとつのものを指していないからです。実際には、まったく異なる 4 つの技術的選択肢をまとめたカテゴリーであり、それぞれ壊れ方も、壊れたときの責任の所在も違います。
このガイドでは、コネクターとは何かを定義し、4 つのアプローチを正直に整理したうえで、ほとんどの記事が扱わない部分、つまりコネクターが本番稼働して実トラフィックを運び始めてから何が起きるのかに大半の紙幅を割きます。
Brevo コネクターの実体
ブランディングを剥ぎ取ると、どの Brevo コネクターも同じ 3 つの要素でできています。
トランスポート。 データが物理的にどう動くか。実際には、片方向は Brevo REST API への呼び出し、もう片方向は Brevo の Webhook です。Brevo は Webhook をマーケティング型とトランザクション型に分けており、ダッシュボードからも、Webhook の作成・更新エンドポイントからも設定できます。上限は 1 アカウントあたり両タイプ合計で 40 件です。
マッピング。 ソースシステムのフィールドが Brevo のどのフィールドになるか。Shopify の顧客には first_name があり、Brevo のコンタクトにはアカウント側で定義した属性があります。そして Brevo は、アカウントに存在しない属性を黙って無視します。多くのコネクターが静かに腐っていくのは、このマッピングの部分です。
状態。 実行と実行のあいだにコネクターが覚えていること。どのレコードを送信済みか、どれが失敗したか、カーソルがどこまで進んだか。状態を持たないコネクターはバックフィルできず、失敗を再送できず、コンタクトが欠落しているのか単に遅れているのかも答えられません。
コネクターは、この 3 つすべてをどれだけうまく扱えるかで評価してください。多くのマーケティングページは 1 つ目しか説明していません。
すべての土台にある識別子の問題
Brevo のコンタクト作成エンドポイントは、email・SMS・ext_id（自社側の外部識別子）のうち少なくとも 1 つの識別子を必要とします。既定では、識別子が衝突すると 4xx エラーが返ります。updateEnabled を true にすると呼び出しはアップサートになり、forceMerge はタイムスタンプが新しいレコードを残して古い方を削除する形で重複をマージします。
どの識別子を主とするか。この設計判断ひとつが、きれいなコンタクトデータベースになるか、すべてが二重に存在するデータベースになるかを決めます。ツールを選ぶ前に決めてください。
Brevo につなぐ 4 つの方法
選択肢 1：ネイティブプラグインとマーケットプレイスアプリ
Brevo は、「Shopify、WordPress、Stripe、Zapier など 150 以上のデジタルツール」と Brevo をつなぐと説明するアプリマーケットプレイスを運営しています。主要な自社製アプリは WordPress・WooCommerce・Shopify・BigCommerce で、マーケットプレイスはカテゴリー別と開発元別で絞り込めます。この開発元という軸は、聞こえ以上に重要です。Brevo 製のアプリとパートナー製のアプリでは、サポートの経路がまったく違います。
強み。 動く状態まで最短で到達できます。認証、基本的なフィールドマッピング、よくあるイベントは配線済みです。Brevo が API を変更したときは、ベンダーがプラグインを更新します。
弱み。 マッピングはベンダーが決めたものしか使えません。カスタム属性、変わったオブジェクト、店舗固有のロジックはたいてい対象外です。デバッグはプラグインが出力するログの範囲に限られ、それが役に立たないことも珍しくありません。さらに、パートナー製アプリが放棄されていたことに気づくのは、たいてい障害の最中です。
適した場面。 標準的なプラットフォームが 1 つ、標準的なフィールドのみ、そして何が同期されたかを証明する要件がない場合です。
選択肢 2：汎用 iPaaS ツール
Zapier、Make、Pabbly Connect はいずれも Brevo に対応しています。Brevo は連携ページに「Zapier 経由でアプリと Brevo をつなぎ、作業を自動化」という見出しで Zapier を直接埋め込んでいます。Make が公開する Brevo アプリのモジュールは、コンタクト・リスト・フォルダー・キャンペーン・イベント・メール・SMS の監視、作成、更新、一覧取得、削除をカバーします。Pabbly Connect も対応アプリとして Brevo を掲載しています。
強み。 ロングテールに対しては本当に優秀です。誰も聞いたことのないフォームベンダー、一度きりの社内ツール、人間の判断を挟む承認ステップ。iPaaS ならこうしたものを半日で処理でき、エンジニアでなくてもシナリオを保守できます。
弱み。 タスク課金は量が増えるほど不利になります。ほとんどのシナリオは 1 レコードずつの処理なので、40,000 件のコンタクトのバックフィルは不可能か、高額になります。エラー処理はたいてい「実行が失敗しました、というメールが届く」だけで、自動再送もなければ、先週火曜日のレコードのうちどれが届かなかったのかを問い合わせる手段もありません。順序も保証されないため、更新が依存元の作成を追い越すことがあります。
適した場面。 データ量が少なく、フローが一方向で、レコードが落ちても損失というより面倒で済む場合です。このカテゴリーの比較は、最良の連携プラットフォームのまとめ記事で直接扱っています。
選択肢 3：専用に作られた連携レイヤー
自社システムと Brevo のあいだに置かれ、マッピングと同期状態を所有し、任意のアプリ間接続ではなくこの仕事のために作られたレイヤーです。
Tajo はその一例です。Brevo のための AI マーケティングチームを名乗り、対応するコマースデータを Brevo に接続し、ルールベースの顧客セグメントを構築し、ガバナンスの効いたメールキャンペーンと SMS キャンペーンを準備します。実務的に見ると、専用レイヤーのトレードオフはどれも同じです。コンタクト・イベント・キャンペーンについて意見のあるモデルを受け入れる代わりに、プラグインにも汎用 iPaaS にもないバックフィル、リトライ、レコード単位の可視性が手に入ります。Brevo 連携ガイドではセットアップを最初から最後まで説明しています。
強み。 一括処理が一級市民として扱われます。失敗はレコード単位で見え、再送できます。マッピングはプラグインの内部に埋もれず、明示的でバージョン管理されます。
弱み。 経路にベンダーが 1 つ増え、評価対象も 1 つ増えます。要件が「WordPress のフォーム 1 つから Brevo のリスト 1 つへ送る」だけなら、小さな仕事に対して重い機械です。そこは正直に判断してください。その場合はネイティブプラグインの方が正解です。
適した場面。 コマースデータの量が実質的にあり、何が同期されたかを証明する必要があり、同期が生み出すのと同じデータモデルの上にセグメントとキャンペーンのロジックを構築したい場合です。
選択肢 4：直接 API 連携
Brevo API に対して自分でコードを書く方法です。
強み。 上限がありません。ID 解決、バッチ処理、リトライ方針、監査ログをすべて思いどおりに制御できます。データウェアハウスからモデリング済みのオーディエンスを Brevo に流し込むような用途では、これが唯一適合する方法であることも多いです。
弱み。 永続的に自分たちの持ち物になります。しかも誰も見積もらない部分、つまりバックオフ付きのリトライ、デッドレターの保管、スキーマ変化のアラート、認証情報のローテーション、運用手順書までを含みます。多くのチームはハッピーパスだけを見積もり、それ以外に 3 倍の工数を費やします。
適した場面。 ロジックが本当に自社固有で、量が投資に見合う場合です。エンドポイント単位の詳細は Brevo API ガイドから始めてください。
意思決定のフレームワーク
決め手になるのは 6 つの問いです。ツールを見る前に答えを出してください。
| 問い | ネイティブプラグイン | iPaaS | 連携レイヤー | 独自 API |
|---|---|---|---|---|
| データ量 | ベンダーが対応する範囲 | 少量、タスク課金 | 大量、バッチ対応 | 無制限 |
| 同期方向 | 通常は片方向の取り込み | シナリオごとに一方向 | 所有者を定めた一方向 | 作れば何でも |
| 必要なレイテンシー | ベンダー次第 | 数分 | ほぼリアルタイム | 自由に設計 |
| マッピングの複雑さ | 固定フィールド | シナリオごとに単純 | 明示的でバージョン管理 | 任意 |
| エラー処理 | 見えないことが多い | 失敗時に通知 | レコード単位のリトライと再送 | 作った範囲 |
| 誰が直すか | プラグインのベンダー | 自社、ビジュアルエディター上で | ベンダー、ただし可視性は自社側にも | 自社、深夜 2 時に |
最後の行こそ、多くの人が飛ばして後悔する行です。コネクターはセットアップ作業ではなく長期的な運用のコミットメントなので、自分が受け入れられる壊れ方をする選択肢を選んでください。
成否を決める同期パターン
一方向と双方向
一方向の同期はフィールドごとに所有者が 1 つで、良い意味で退屈です。双方向の同期はループ抑止、競合解決、優先ルールを必要とし、しかも Brevo は自社のコネクターが今書き込んだばかりの変更に対しても、平然と contact_updated の Webhook を送出します。
「その方が高機能に聞こえる」という理由で双方向同期を作らないでください。代わりにフィールド所有権の表を作ります。EC プラットフォームが注文データを所有し、CRM がライフサイクルステージを所有し、Brevo が同意とエンゲージメントを所有する、といった具合です。各フィールドは一方向にのみ同期します。どうしても双方向に動かす必要があるフィールドがあるなら、すべての書き込みに発生元マーカーを付け、自分のマーカーが付いた受信イベントは破棄してください。
ポーリングと Webhook
Webhook は安価で速いものの、保証はありません。マーケティング Webhook のイベントには delivered、opened、click、hard_bounce、soft_bounce、spam、unsubscribe、contact_updated、contact_deleted、list_addition などがあります。トランザクション Webhook は、送信済みや配信済みから、遅延、ブロック、苦情、エラーまで、送信のライフサイクル全体をカバーします。
計画しておくべきことが 2 つあります。1 つ目は、Brevo の Webhook ドキュメントがペイロード署名ではなく公開 IP アドレスの許可リスト登録を中心に説明している点です。したがって、エンドポイントは既定で認証されていないものとして扱い、重要な内容は API からレコードを読み直して確認してください。2 つ目は、どんな Webhook システムも永久にすべてを配信し切ることはないという点です。低頻度の突合ポーリングと組み合わせて、すり抜けた分を拾ってください。
バッチとリアルタイム
リアルタイム性が効くのはトリガーです。カゴ落ちやウェルカムのフローがイベント呼び出しに値するのはそのためです。夜間の属性更新にはリアルタイム性は不要です。
パターンはレート制限に合わせて選びます。Brevo のコンタクト系エンドポイントと POST /v3/events は標準アカウントで 1 秒あたり 10 リクエスト、トランザクションメールは 1 秒あたり 1,000 リクエスト、それ以外のエンドポイントはすべて 1 時間あたり 100 リクエストが上限です。Professional と Enterprise のアカウントでは、前者の枠がおおむね倍になります。この「その他すべてのエンドポイント」の 1 時間 100 回という上限が、いちばんよくある想定外です。レコードごとにリストやフォルダーを読むコネクターは、昼までに使い切って HTTP 429 を集め始めます。
一括処理では、ループではなくインポートエンドポイントを使ってください。ファイル URL、ファイル本体、または最大 10MB（安全な目安は 8MB）の JSON ボディを受け取り、非同期で実行され、processId を返し、完了時に通知 URL を呼び出します。
冪等性と同一性
Brevo のイベントエンドポイントは、event_name、少なくとも 1 つの識別子、任意のコンタクトプロパティ、最大 50KB の任意のイベントプロパティを受け取り、成功時に 204 を返します。冪等性キーはドキュメント化されていないため、リトライされた呼び出しが重複イベントを作る可能性があります。
冪等性は自分で作り込んでください。ソースレコードとそのバージョンから決定的なキーを導出し、送信済みのキーを保存し、送信前に確認します。コンタクトについては主識別子を 1 つ選び、ext_id にソースシステムの ID を入れ、アップサートには updateEnabled を使って、リトライがエラーではなく更新になるようにします。
信頼できる再同期の設計
再同期は必ず必要になります。初日から設計に入れてください。
- すべての書き込みを冪等にし、再実行が破壊的ではなく安全になるようにします。
- オブジェクト種別ごとにカーソルを持ち、コネクターのメモリ外に保存します。
- 再同期は本番リストの前に使い捨ての Brevo リストでテストします。
- インポート中は
emptyContactsAttributesを既定値の false のままにします。true にすると、空欄のフィールドが既存の値を消してよいと Brevo に伝えることになり、部分的なエクスポートが恒久的なデータ損失に変わります。 - レコード単位の結果を記録します。40,000 件中 400 件が検証で落ちているとき、「ジョブは成功しました」は結果ではありません。
本番で実際に起きること
フィールドマッピングのずれ
誰かが Shopify のメタフィールド名を変更したり、必須のチェックアウト項目を追加したりします。Brevo は認識できない属性を無視するため、コネクターは動き続け、成功を報告し続けます。数週間後、あるセグメントが静かに半分空になっています。
対策。 ソース側のスキーマと Brevo の属性一覧をスナップショットとして保存し、定期的に比較して差分でアラートを出します。エラーだけでなく、属性ごとの非 NULL 率の低下にもアラートを設定してください。
重複コンタクト
典型的な原因は、2 つのコネクターが 2 つの識別子を使っていることです。店舗プラグインはメールアドレスでコンタクトを作り、SMS のフローは電話番号で作り、1 人の人間が 2 つのレコードになってエンゲージメント履歴が分断されます。
対策。 主識別子を 1 つにして、どこでも徹底します。ext_id にソースシステムの値を入れ、常に安定した結合キーを持つようにします。forceMerge は日常の設定としてではなく、古い方のレコードが削除されることを理解したうえで、意図的なクリーンアップ手順として使ってください。
同期ループ
コネクター A が Brevo に書き込み、Brevo が contact_updated を送出し、コネクター B がソースに書き戻し、ソースが自身の変更イベントを出し、そのサイクルが繰り返されます。自分で気づくより先に、レート制限がこれを表面化させるのが普通です。
対策。 すべての書き込みに発生元マーカーを付け、加えてレコードごとの変更カウンターを持ち、一定時間内にしきい値を超えたら警報を鳴らします。
レート制限と部分的な失敗
制限を超えると 429 が返ります。危険なのは 429 そのものではなく、一部のレコードだけが成功したバッチを、コネクターが全体失敗として扱って再送するか、全体成功として扱って失敗分を失うことです。
対策。 指数バックオフとジッターを入れてリトライし、リトライのヒントがあれば尊重し、結果はバッチ単位ではなくレコード単位で追跡します。失敗はペイロード全体とともにデッドレターストアへ送り、修正後に再送できるようにしてください。
静かなデータ損失
最悪の障害は静かなものです。空欄の列があるインポートで emptyContactsAttributes が true になっていた、存在しなくなった属性の値が蒸発した、Webhook のエンドポイントが 1 時間 500 を返していたのに誰も見ていなかった、といったケースです。
対策。 エラーだけでなく件数を監視します。1 日あたりの作成コンタクト数、1 時間あたりの受信イベント数、属性の充足率。ゼロに落ちた指標は、これ以上ないほど明確なアラートです。
2 つのシステムの数字が合わない
いずれ、ソース側は有効コンタクト 18,400 件と言い、Brevo は 18,062 件と言う日が来ます。突合がなければ、どちらが正しいのか判断できません。
対策。 件数と、識別子で抽出したサンプルレコードを比較する突合処理をスケジュール実行し、差分レポートを出力します。再インポートを繰り返すのではなく、原因を修正してください。再インポートは不一致を説明せずに隠すだけです。
実務でよくある接続先
EC。 Shopify と WooCommerce が二大勢力で、どちらも Brevo のマーケットプレイスに自社製アプリがあります。ネイティブ経路はコンタクトと基本的な注文データをうまく扱えます。明細行単位のカスタムロジック、サブスクリプションの状態、ロイヤルティ階層はたいてい収まらず、そこで連携レイヤーや独自コードが価値を発揮します。この組み合わせについては、Brevo と Shopify の連携ガイドで詳しく扱っています。
CMS。 WordPress は EC 以外で最も一般的な Brevo の接続先で、用途はフォーム、ニュースレター登録、Brevo の SMTP を使ったトランザクションメールが中心です。データモデルが単純で量も少ないため、ここではほぼ常にプラグイン経路が正解です。
CRM とデータウェアハウス。 コネクターが難しくなるのはここです。どちらの側も自分が顧客を所有していると考えているからです。フィールド所有権の表を使い、フィールドごとに一方向で同期し、生のレコードを同期するのではなく、ウェアハウスからモデリング済みのオーディエンスを Brevo のリストへ流し込むことを検討してください。Brevo 自身の CRM オブジェクトがこの図のどこに収まるかは、Brevo CRM ガイドをご覧ください。
フォーム。 iPaaS の理想的な用途です。量が少なく、方向は 1 つ、レイテンシーにも寛容です。作り込みすぎないでください。
正しく進めるために
コネクターの選定は、機能というより運用の問題です。どの選択肢でもコンタクトを A から B へ動かせます。違いが出るのは、マッピングがずれた日、レート制限に引っかかった日、40,000 件のインポートのうち 400 件が検証で落ちた日に何が起きるかです。
次の順序で進めてください。
- どのシステムがどのフィールドを所有するかを書き出します。他のすべてはここから決まります。
- コンタクトの主識別子を 1 つ選び、
ext_idにソースシステムの値を入れます。 - 最も高機能なものではなく、自社のデータ量とエラー処理要件に耐えられる最も軽い選択肢を選びます。
- 再同期と突合レポートは、最初のインシデントの後ではなく、本番稼働の前に作ります。
- 件数と充足率を監視します。派手な失敗より、静かな損失の方が起こりやすいからです。
この 5 つをやれば、4 つのアプローチのどれでも機能します。飛ばせば、どれも機能しません。