Customer.ioの配信過多の原因と対策｜AIに組ませる前の線引き

「製品の利用データと連動したメールを Customer.io で組み始めたら、半年で配信フローが40本を超え、同じ人に1日3通届く日が出てきた」「エージェントに頼めば配信フローも文面も数分でできると聞くが、誰が承認すればよいのか決まっていない」——製品をクラウドで提供するBtoB企業でマーケと開発の両方から聞こえてくる声です。通数が増えすぎる原因は、AIの性能ではなく、配信フローを足すたびに全体の上限と承認の線を引き直していないことにあります。この記事では、Customer.io が何をする道具で、2026年に加わったエージェントやLLMアクションがどこに入るのかを確かめたうえで、配信が増えすぎる原因と、AIに組ませる前に決めておく承認・頻度の上限・データの持ち主・国内の法令への配慮を整理します。

Customer.io は、行動データを起点にメールやアプリ内の通知を送る配信基盤

Customer.io は、製品の中で利用者が何をしたか（登録した、機能を使った、しばらくログインしていない、など）を受け取り、その行動を起点にメール・プッシュ通知・アプリ内メッセージ・SMS などを送る海外の配信基盤です。公式の説明では、行動とデータの属性にもとづいて対象を絞った配信を自動化する仕組みとされており、見込み客の獲得よりも、使い始めた後の定着や有料化に強い道具だと位置づけられます。

国内でよく使われるMAツールとの違いは、データの入り口にあります。フォームや名刺から見込み客を集めて点数を付ける従来型のMAに対し、Customer.io は開発側が製品から送るイベントを主な材料にします。そのため、配信の条件を書くのはマーケでも、条件の材料になるイベントの名前と意味を決めているのは開発、という分担が最初から生まれます。この記事の後半で扱う「データの持ち主」の問題は、ここから来ています。

MAツールの選び方そのものや、メールの出し分けの一般的な考え方は、ほかの記事で扱っています。ここでは、すでに製品の利用データがあり、行動起点の配信を増やしたい、製品をクラウドで提供するBtoB企業が、Customer.io のAIに配信フローを組ませてよいかという一点に絞って判断材料を並べます。

2026年の動き：エージェント、LLMアクション、ラインとWhatsApp

製品の鮮度から確かめます。Customer.io は2026年4月、提供元が最大の更新と呼ぶ発表を行い、作業を代行するエージェント、配信フローの途中で生成AIを呼び出すLLMアクション、配信フローをまたいで成果を見る目標の機能、WhatsApp とライン（国内のメッセージアプリ）への配信、画面の刷新を加えました。発表時点では、エージェント・LLMアクション・目標の三つはベータとして提供されていました。その後も夏の更新でアプリ内の受信箱や位置情報を起点にした配信が加わり、公式ドキュメントは2026年10月時点でも更新が続いています。

エージェントの役割は広く、公式ドキュメントでは画面でできることのほぼすべて（対象者の絞り込み、配信フロー、一回限りの配信、メールの作成、数値の分析）を頼めると説明しています。製品の画面のほか、Slack の中から頼む方法、ChatGPT や Claude などの外部のAIから接続する方法（MCP）、開発者向けのAIが端末から操作するためのコマンドの道具も用意されています。入口が四つあり、それぞれに別の安全設定があることが、後で効いてきます。

ほかに、指定した時間ごとに配信の状況を点検して要約をメールで送る定期実行の機能、ブランドの文体や確認の手順を教え込む独自のスキルの機能も公式ドキュメントに載っています。目標の機能は、公式ドキュメントで次の版を準備中と案内されており、まだ使っていない作業領域では画面に出ない状態です。

• 機能の名称と範囲は、公式ドキュメント（2026年9〜10月更新）の説明にもとづきます。ベータの機能は仕様が変わることがあるため、契約前に最新の案内を確かめてください
• 日本語の画面や国内の窓口についての公式の明記は確認できませんでした。運用する担当者の語学の負担は、試用の段階で確かめておきます

課題：行動起点の配信は、AIに組ませるほど増えていく

行動起点の配信は、一本ずつ見れば理にかなっています。登録して3日たっても初期設定が終わっていない人に案内を送る、主要な機能を初めて使った人に次の使い方を送る、14日間ログインのない人に呼び戻しを送る。どれも妥当です。問題は、これらが別々の配信フローとして動き、同じ人が同じ日に複数の条件を満たしうることです。試用期間の終わりが近く、ログインも途絶えていて、ウェビナーにも申し込んだ人は、三つの配信フローから同時に呼ばれます。

エージェントが入ると、この増え方が加速します。「解約の兆しがある人向けの配信フローを作って」と頼めば、対象者の条件と文面と配信の間隔まで下書きが出てきます。作る手間が下がると、配信フローの数は担当者の思いつきの数に近づきます。しかもエージェントは、頼まれた一本を作ることは得意でも、既存の何本と対象者が重なるかを自分から気にかけるわけではありません。全体の通数は、誰かが意図して見ない限り、誰も見ていない数字になります。

• 配信フローを作るたびに担当者が個別に「この条件なら多すぎないはず」と判断し、全体の通数を週次で見る人がいない
• エージェントが作った下書きを、文面だけ見て公開し、対象者の条件と既存の配信フローとの重なりを確かめていない
• 頻度の上限を作ったが、新しく作った配信フローを上限に数えさせる指定を忘れ、上限の外で送られている

原因1：配信フローごとに条件を書くので、全体の通数を誰も見ていない

一つ目の原因は、設計の単位です。Customer.io に限らず、行動起点の配信基盤では、配信フローごとに「誰を入れるか」「何日待つか」「何を送るか」を書きます。この書き方は一本ずつの設計には向いていますが、一人の受け手から見た一週間の通数は、どの画面にも自然には出てきません。担当者が配信フローを足すときに見るのは、その配信フローの開封率やクリック率で、ほかの配信フローとの合計ではありません。

BtoBの場合、受け手は一人でも、会社としての関係は一つです。管理者・一般利用者・決裁者が同じ会社にいて、それぞれに配信が届きます。利用者の一人が配信を迷惑に感じて停止すると、その会社への案内の経路が一本減ります。消費者向けよりも母数が小さい分、一人の停止の重みが大きいのがBtoBの特徴です。全体の通数を見る役目を、配信フローの担当者とは別に置く理由がここにあります。

対策の入口として、まず今ある配信フローを一覧にし、対象者の条件を「試用中」「導入初期」「定着後」「休眠」などの段階に当てはめます。同じ段階に入る配信フローが何本あるかを数えるだけで、重なりの大きいところが見えてきます。この棚卸しは、エージェントに読ませて一覧を下書きさせることができますが、どの配信フローを止めるかの判断はAIに任せません。止めた結果の売上や解約への影響を負うのは人だからです。

原因2：頻度の上限は、選んだ配信フローにしか効かない

Customer.io には、一定の期間に一人が受け取る通数の上限を決める機能があります。公式ドキュメントによれば、上限は作業領域の設定で経路ごと、または複数の経路をまとめて作れます。ただし、既定ではどの配信フローも上限に数えられません。配信フローや個別のメッセージの送信設定で、上限に数えさせる指定をしてはじめて効きます。上限を作ったことで安心し、新しい配信フローに指定を入れ忘れる、という抜けがここで起きます。

上限に達した人への送信は、配信不可として記録され、その人は配信フローの次の段階に進みます。再送の期間を設定しておけば、上限の枠が空いた時点で送り直されます。公式ドキュメントは、上限の期間は暦の日ではなく、直前の配信からの相対的な時間で数えると説明しています。「1日2通」は「24時間に2通」と読むのが正しく、朝と夜に分けたつもりの配信が翌朝の配信を止めることもあります。

もう一つ見落としやすいのが、上限の対象外の経路です。公式ドキュメントでは、メール・プッシュ通知・ライン・外部への通知・SMS・WhatsApp には上限を当てられる一方、アプリ内メッセージと受信箱のメッセージには当てられず、表示期限や表示するページの条件で絞るよう案内しています。メールの上限だけ決めても、アプリ内の案内が同じ日に重なれば、受け手の体感は減りません。経路ごとの抑え方を一枚にまとめておく必要があります。

原因3：イベントの名前と意味を決めているのは開発側

三つ目の原因は、データの持ち主が二つに分かれていることです。配信の条件に使う「機能を使った」「請求情報を登録した」といったイベントは、開発が製品のコードから送っています。名前を変えたり、送る条件を変えたりするのは開発の判断で、マーケは結果として届いたデータを使う立場です。イベントの意味が変わったことにマーケが気づかないまま、配信の条件だけが古い前提で動き続けることがあります。

エージェントはこの問題をさらに見えにくくします。公式ドキュメントは、エージェントの精度は属性やイベントに付けた名前と説明に依存すると明記し、たとえば略語の属性名だけでは会社名なのか顧客名なのかAIには分からない、という例を挙げています。説明のないデータを材料に、エージェントがもっともらしい条件を組むと、人が見ても誤りに気づきにくい配信フローができあがります。データの台帳にある説明文は、AIの下書きの品質を左右する設定だと考えるべきです。

クラウドで提供するBtoBの製品では、会社単位の属性（契約の段階、利用人数、導入日）と個人単位の属性（役職、最終ログイン）が混ざります。どちらの単位で条件を書いたのかが曖昧だと、会社としては有料化済みなのに、未登録の利用者に試用の案内が届く、といった事故が起きます。この単位の取り決めも、開発とマーケのどちらが持つかを決めておく対象です。

原因4：AIが書いた文面が、確認されずに送られる経路がある

四つ目は、文面の確認の経路です。エージェントにメールの下書きを作らせる場合は、人が画面で見てから使うので確認の機会があります。一方、LLMアクションは配信フローの一段階として生成AIを呼び出し、その出力を属性として保存し、後の段階の文面に差し込めます。公式ドキュメントは、この使い方ではチームが確認していない内容が送られると注意し、慎重を要する連絡には使わないこと、確認したい文面はエージェントでひな形として作ることを勧めています。

生成AIの出力は、同じ指示でも受け手ごとに変わります。100人に送れば100通りの文面ができ、事前にすべてを見ることはできません。BtoBの配信には、価格・契約条件・機能の提供時期といった、誤ると約束として受け取られかねない内容が含まれます。こうした内容を、確認の済んでいない生成文で送るのは避けるべきです。

LLMアクションには、生成AIに渡せる材料にも特徴があります。公式ドキュメントでは、指示文に差し込んだ利用者の属性や、配信フローの起点になったデータを処理できるとしています。一方で設定画面の説明には、利用者の属性やイベントの値はAIの機能に使わないという趣旨の記載もあります。どの機能でどの値がモデルに渡るのかは、自社で使う機能ごとに公式の説明を突き合わせ、法務と情シスに確認しておく項目です。

対策1：エージェントの権限は、下書きまでを既定にする

Customer.io のエージェントは、既定で慎重な側に倒れています。公式ドキュメントによれば、エージェントは操作している人の権限の範囲でしか動かず、影響の大きい操作や削除の前には確認を求めます。さらに既定では、稼働中の配信フローや使用中の対象者の条件を変更できず、配信の送信も人の通常の承認と送信の流れに従います。稼働中のデータの編集を許す設定は、アカウントの管理者だけが変更できます。

この設定を有効にすると、変更のたびに人に承認を求める方式と、別のモデルが利用者の意図と照らして変更を承認する方式を選べるようになります。後者は便利ですが、承認する主体がAIになる以上、配信の現場には持ち込まないのが無難です。BtoBの配信で誤送信が起きると、取引先への謝罪と説明が要ります。その責任をAIの判定に預ける理由はありません。

注意したいのは、入口ごとに設定が分かれていることです。外部のAIから接続する口には、稼働中のデータの編集と、機微な属性の読み取りについて独立した許可があり、どちらも既定では無効です。Slack の中のエージェントは、製品の設定と Slack 側の設定の両方が有効なときだけ稼働中のデータを変更できます。一方、開発者向けのコマンドの道具は、発行した認証の鍵が許す範囲なら、この設定に関係なく読み書きできると公式ドキュメントが明記しています。鍵の発行と保管は、情シスの管理に乗せておきます。

対策2：頻度の上限を先に作り、すべての販促の配信フローに数えさせる

頻度の上限は、配信フローを増やす前に作ります。目安は自社の配信の実績から決めるべきで、一律の正解はありませんが、考え方は単純です。販促や育成の配信フローは例外なく上限に数えさせ、契約や請求の通知など、受け手に必ず届ける必要がある連絡だけを上限の外に置く。公式ドキュメントでも、法令に沿うための上限と、規約の変更の告知のような上限を掛けない配信を分ける例が示されています。

上限に数えさせる指定が漏れないよう、配信フローを公開する前の確認項目に入れます。エージェントに配信フローを作らせる場合も、この確認は人が行います。独自のスキルの機能でブランドの文体や確認の手順を教え込めると公式ドキュメントにありますが、スキルは守らせたい手順を伝える手段で、守られたかどうかの保証ではありません。最後に上限の指定を見るのは、公開ボタンを押す人です。

上限が実際に効いているかは、定期実行の機能で点検できます。公式ドキュメントによれば、定期実行は読み取りだけの安全な方式で動き、配信フローや対象者の条件を変更できず、結果を担当者にメールで送ります。3回続けて失敗すると自動で止まる仕組みもあります。「配信不可が増えている配信フロー」「同じ段階に入る配信フローの数」を週に一度点検させ、見るのは人、という分担が現実的です。

対策3：データの持ち主を、マーケと開発で表に分ける

イベントの意味が知らないうちに変わる問題は、持ち主を表にして防ぎます。ポイントは、データを送る側、意味を決める側、条件に使う側を分けて名前で書くことです。公式ドキュメントが勧める属性やイベントの説明文の記入も、この表の担当者が持ちます。説明文はエージェントに下書きさせる機能がありますが、意味を確定させるのは開発の担当者です。

対象	持ち主	AIに任せること	人が決めること
イベントの名前と送る条件	開発	既存のイベントの一覧化	名前・意味・送る時点の確定
属性とイベントの説明文	開発（マーケが確認）	説明文の下書き	略語や単位の確定、会社単位か個人単位か
対象者の条件	マーケ	条件の下書き、重なりの集計	公開の可否、既存の配信フローとの整理
文面とひな形	マーケ	下書き、言い換え案	価格・契約・提供時期の記述、最終の承認
頻度の上限と例外	マーケの責任者	上限に数えていない配信フローの洗い出し	上限の値、例外にする連絡の範囲
認証の鍵と接続の設定	情シス	なし	発行・保管・失効、許可する範囲

表を作ったら、イベントの名前や意味を変えるときの連絡の流れも決めておきます。開発が名前を変える変更を出すときに、そのイベントを条件に使っている配信フローの一覧をマーケに渡す、という一行の取り決めだけでも、古い前提で動き続ける配信フローは減ります。監査の記録の機能で、誰がいつ何を変えたかは後から追えますが、記録は事故の後に読むもので、事故を防ぐのは事前の連絡です。

対策4：LLMアクションの出力は、本文より分岐に使う

LLMアクションを使うなら、生成した文章をそのまま送るより、受け手を分類して分岐の材料にする使い方から始めるのが安全です。たとえば、問い合わせの文面や利用状況から「導入の相談」「使い方の質問」「解約の検討」に分類させ、分類ごとに人が書いて確認したひな形を送る。生成AIの誤りは分類の誤りとして表に出ますが、送られる文面そのものは確認済みのものに限られます。

分類させる場合も、根拠を書かせます。分類の結果と一緒に、どの属性や文面を見てそう判断したかを短く保存させておけば、誤分類を見つけたときに原因をたどれます。公式ドキュメントによれば、LLMアクションの出力は既定で配信フローの中だけの一時的な属性として保存され、配信フローを抜けると消えます。分類の結果を顧客の属性として残す設定にするかどうかは、保存する目的と期間を決めてから選びます。

費用の面でも、分類の用途は扱いやすくなります。LLMアクションは、ほかのAIの機能と違って専用の点数を消費し、公式ドキュメントでは追加購入が10万点ごとに10ドルとされています。消費量は選ぶモデルと指示文・出力の長さで変わり、推論型の上位モデルは軽いモデルの数十倍を消費すると案内されています。点数が尽きると、あらかじめ決めた代わりの値で配信フローが進みます。短い分類なら消費は小さく、長い本文の生成ほど増えます。

特定電子メール法への配慮：同意・表示・停止を配信基盤の外とも揃える

国内の受け手に販促のメールを送る以上、特定電子メールの送信の適正化等に関する法律（特定電子メール法）への配慮は欠かせません。同法は、営業のための広告や宣伝のメールについて、原則として事前に同意を得た相手にだけ送ること、同意を得たことの記録を残すこと、送信者の名称や受信を拒否するための連絡先などを表示すること、拒否した相手には送らないことを求めています。名刺などで自らアドレスを伝えた相手や、取引関係にある相手など、例外の定めもあります。

行動起点の配信で気をつけたいのは、製品の利用者への連絡と、販促の連絡の境目です。請求や障害の通知は利用契約にもとづく連絡ですが、上位プランの案内や関連サービスの紹介は広告や宣伝の性格を持ちます。同じ配信フローの中で、通知から販促へ内容が移ることがあるため、配信フローごとに「どちらの性格か」を決め、販促の配信フローは同意の確認と停止の導線を必ず通す設計にします。

Customer.io には、全体の配信停止、話題ごとの購読の設定、同意の記録などの仕組みがあると公式ドキュメントにあります。ただし、同意を取得したのが自社の申込みフォームや展示会の名簿である場合、その記録は配信基盤の外にあります。配信基盤の停止の状態と、MAや顧客管理の仕組みにある同意・停止の記録が食い違わないよう、どちらを正とするかを決めて連携します。アプリ内の通知やラインのメッセージが同法の対象になるかは送信の方式で変わるため、法務に個別に確かめてください。

• 法令の要件は、総務省・消費者庁の資料と特定電子メール法の条文で確かめてください。この記事は法的な助言ではありません
• 海外の受け手には、相手国の法令（欧州の個人データ保護の規則や米国の商業メールの規制など）も別に関わります

社内に入れてよいか：データの所在、外に出るもの、止め方

データの所在から確かめます。公式ドキュメントによれば、アカウントの作成時に米国か欧州（ベルギー）のどちらかの地域を選び、顧客のデータはその地域に保存されます。作業領域ごとに地域を分けることはできません。国内の地域は用意されていないため、日本の利用者の個人データを海外の事業者に預ける形になります。個人情報保護法の外国にある第三者への提供や、安全管理措置としての外的環境の把握にあたるかを、法務と確かめておきます。

AIの機能については、提供元は顧客のデータをAIモデルの学習に使わないと設定画面の説明で明言しています。生成AIの機能には Google の Gemini が使われており、安全のための遮断の強さと、生成内容に守らせる社内規程の文（コンプライアンスの指示文）を設定できます。LLMアクションでは Anthropic のモデルも選べると料金の説明にあります。どの機能でどの外部のモデルが動くかを一覧にし、委託先の管理に載せるのが、情シスとしての最初の作業です。

止め方は、比較的はっきりしています。アカウントの設定にある全体の切り替えで、製品内のAIの機能を全員分まとめて無効にでき、外部のAIからの接続は別の切り替えで止められます。止める権限はアカウントの管理者にあるので、管理者を誰が務め、異常時に誰の判断で止めるかを運用の文書に書いておきます。開発者向けのコマンドの道具は認証の鍵で動くため、止めるには鍵を失効させます。

入口	既定の状態	止め方・絞り方
製品内のエージェント	稼働中のデータは編集不可、送信は通常の承認の流れ	管理者が全体の切り替えで無効化
Slack の中のエージェント	製品側と Slack 側の両方の許可が要る	Slack 側の設定で編集を許さない
外部のAIからの接続（MCP）	稼働中のデータの編集と機微な属性の読み取りは不可	専用の切り替えで無効化
開発者向けのコマンドの道具	鍵の範囲で読み書き可能	鍵を失効させる

小さく試す手順

いきなり全部の配信フローをエージェントに任せるのではなく、範囲を区切って試します。期間は1〜2か月を目安に、次の順で進めると、AIに任せてよい範囲が実績から決まります。

試行の成果は、作った配信フローの数ではなく、一人あたりの週の通数、配信停止の率、狙った行動への到達率で測ります。配信フローが増えても停止が増えていれば、AIで速くなったのは作業だけで、受け手との関係は悪くなっています。

よくある質問

エージェントに配信まで任せることはできますか

設定上は、管理者が稼働中のデータの編集を許可すれば、変更の範囲を広げられます。ただ公式ドキュメントでも、エージェントは既定で自ら配信を送らず、送信は通常の承認の流れに従うと説明されています。BtoBの配信では、送信の判断は人に残す前提で使うのが安全です。

頻度の上限はどれくらいに設定すべきですか

一律の正解はありません。過去の配信で停止が増えた時期の通数や、受け手の段階ごとの反応から決めます。最初は控えめに置き、配信不可の件数と停止の率を見ながら調整します。上限の値より、販促の配信フローを漏れなく数えさせることのほうが効果は大きいです。

国内のMAツールと併用できますか

併用している企業は少なくありませんが、同じ人に二つの基盤から販促が届くと、頻度の上限はどちらの基盤でも効きません。見込み客の育成は国内のMA、製品の利用者への行動起点の配信は Customer.io、と受け手の段階で分け、同意と停止の記録をどちらで正とするかを決めてから併用します。

まとめ

Customer.io は、製品の利用データを起点にした配信に強い基盤で、2026年に加わったエージェントやLLMアクションによって、配信フローを作る速さは大きく上がりました。その分、配信が増えすぎる原因（配信フロー単位の設計、選んだものにしか効かない頻度の上限、開発とマーケに分かれたデータの持ち主、確認されない生成文の経路）が表に出やすくなります。エージェントは下書きまでを既定にし、販促の配信フローはすべて上限に数えさせ、データの持ち主を表で分け、特定電子メール法の同意・表示・停止を配信基盤の外の記録とも揃える。AIに作らせる範囲より先に、人が承認する範囲を決めることが、導入の判断の出発点です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。