メール配信システム自作の実録。費用と必要機能6つ

メール配信システムを自作するとは、配信ツールを月額で契約する代わりに、購読者名簿・配信停止・ステップ配信・送信の各機能を自社のアプリとして持ち、送信そのものだけを外部の配信基盤に任せる形をとることです。名簿と行動データが自社の手元に残り、フォームや業務システムとの連携を自分の都合で足せるようになります。

僕はAIVESTという会社を経営していて、経営しながら自分でも手を動かします。この記事では、自社で公開しているオープンソースのLINE配信CRMをフォーク（複製して別物に作り替えること）して自社用のメールCRMを組み、実際に資料請求からのメールを流している運用を公開します。ツール契約と比べた費用、最低限そろえるべき機能、そして実際に踏んだ不具合まで書きます。

メール配信システムを自作するという選択肢

メールの配信と聞くと、多くの人がまず配信ツールの契約を思い浮かべます。名簿を入れて、ステップ配信を設定して、月額を払う。これが標準ルートで、大半の会社にとっては正解です。

ただ、この標準ルートには2つの引っかかりがあります。ひとつは費用が購読者数と機能グレードで伸びること。もうひとつは、自社の業務フローに合わせた連携が「ツールができる範囲」で頭打ちになることです。フォームの入力内容で名簿を属性分けし、その属性でシナリオを分岐させ、同時に営業へ通知する。この程度でもツールをまたぐと接着剤（連携ツールや手作業）が要ります。

そこで出てくるのが3つ目の選択肢、「送信そのもの」だけを外部に任せ、名簿・シナリオ・配信停止・連携は自社のアプリとして持つという分け方です。IPの評判管理もバウンス（宛先不明で返ってくること）の処理も、専業の配信基盤のほうが確実だからです。

想定読者は、ツールの制約が気になっている経営者、資料請求フォームと名簿を手作業でつないでいる方、AIコーディングツールで自社の業務システムを組み始めている方です。本記事が扱うのは「送る仕組み」の側で、メルマガの原稿そのものをどう書くかという号づくりの工程は扱いません。いま問題なく回っているなら「やらない理由の確認」として読んでください。

メール配信システムの自作は3層ある。どこまでを自作するのか？

「自作」と一口に言っても、手を入れる深さで3つの層に分かれます。ここを混ぜたまま考えると、必要な体制も費用も見誤ります。

先に用語を3つだけ。SMTPはメールを送るための通信規約、MTA（Mail Transfer Agent）はそのSMTPを話して相手のメールサーバへ実際に配送するプログラム、SMTPリレーは自社のアプリが出したメールを外部の送信基盤に中継してもらう仕組みです。どの層になるかは、このMTAを自分で抱えるかどうかで決まります。

解説記事の多くは「クラウド型かオンプレミス型か」の二択で語りますが、実務の判断はこの3層で見たほうが早いです。①と③の間に②があることを知らないまま、「自作＝メールサーバを立てること」だと思って検討をやめてしまうケースが多い。②なら、到達率を左右する厄介な部分は専業に預けたまま、業務連携だけを自社の都合で持てます。

そしてどの層を選んでも、最初の一歩は同じです。送信用の独自ドメインを取り、DNSにSPF・DKIM・DMARCの認証レコードを立てる。送信元が本物であることを受信側に証明するための3つの設定で、③のSaaS契約でも必ず求められます。ここを飛ばすと、何を選んでも迷惑メール扱いからは抜けられません。

なぜ既存ツールでなくメール配信システムを自作したのか？

正直に言うと、費用が第一の理由ではありませんでした。決め手は3つです。

1つ目、名簿と反応を自社の一次データとして持ちたかった。 どの記事から来た人が、どの資料を取って、その後どのメールに反応したか。配信ツールでも開封やクリックは見られますが、データはツールの中にあり、他のデータと結合するにはエクスポートが要ります。名簿と反応が自社のデータベースにあれば、この線を一発のクエリで出せます。

2つ目、資料請求から相談導線まで一気通貫で組みたかった。 資料請求フォームで起きてほしいことは3つ同時にあります。請求者へ資料を届ける、名簿に登録して経路のタグを付ける、僕に「請求が入った」と知らせる。これを人がツールの外側でつなぐと、必ずどこかで抜けます。

3つ目、土台になるコードをすでに公開していた。 ゼロから書くなら、たぶんやりませんでした。LINE配信のCRMをオープンソース（MITライセンス）として公開していて、購読者管理・タグ・シナリオ配信・管理画面という骨格がすでに動いていました。

メールに必要な機能の大半は、LINE配信に必要な機能とほぼ同じでした。違うのは「送信のやり方」と「配信停止の作法」だけ。だから、送信層だけを差し替える設計にしました。

自作メールCRMの全体像。何を流用し、何を差し替えたか

骨格はCloudflare Workers（サーバーを自分で立てずにコードを走らせる仕組み）とD1（同じ環境で使える軽量データベース）、それに管理画面。ここはLINE版からそのまま持ち越しました。

差し替えたのは3つです。

1つ目、送信チャネル。 LINEのメッセージ送信APIを外し、Resend（メール配信のAPI基盤）に置き換えました。当初はCloudflareのメール送信機能を使う前提で組み始めたのですが、規約を読み直すと、その機能はトランザクショナルメール（購入確認や通知など、相手の行動への応答として送るメール）向けで、マーケティング目的の一斉配信は許可されていませんでした。2026年7月19日にこれを確認し、送信をResendに一本化しています。規約の確認は、コードを書き始める前にやるべき工程でした。

2つ目、配信停止の仕組み。 LINEにはブロックがありますが、メールには自前の配信停止が要ります。ここは新規実装です（後述）。

3つ目、入口。 LINEのリッチメニューやLIFF（LINE内で動くWebページ）は廃止し、自社サイトの資料請求フォームを入口にしました。

逆に、そのまま使えた部分もはっきりしています。購読者テーブルとタグ、シナリオの状態管理、送信ログとイベント記録、管理画面の一覧・検索。メール専用に新しく書いたのは、実質「配信停止」と「送信アダプタ」の2つだけでした。実装はAIコーディングツールに書かせていますが、どの機能が要るか・どこで人が止めるかの設計は自分で決めます。

自作とツール契約、費用はどちらが安いのか？

「自作すれば安い」は、半分だけ正しい話です。比べるべきは月額そのものではなく、月額＋自社が払う時間だから。まず両側の実額を並べます。以下はすべて2026年9月1日に各社の公式料金ページで確認した数字で、プランも価格も変わるため、判断の前には必ず公式で見直してください。

ツール契約側（国内で公開されている料金の例）:

自作側（②の構成で毎月かかる運用費）:

数字だけ見れば、購読者が数千件までの規模なら、自作側の月額は無料枠か数ドルに収まります。ツール契約の月額4,000円〜と比べれば確かに安い。ここまでは自作の勝ちです。

問題は、この表に載らない費用です。自作の本当のコストは、開発と保守にかかる自社の時間で、初期構築では終わりません。配信停止の作法、認証設定の維持、受信側の要件変更への追随、不具合の切り分け。既存の土台があった僕でも、ここに相応の時間を使いました。

だから損益分岐は通数ではなく、次の3つの問いで決まります。

• 規模: 購読者が数千件までなら、月額の差は月に数千円です。その差のために自社の時間を投じる意味があるか

• 連携: 「ツールでは届かない連携」を1つ以上、具体的な業務の言葉で言えるか。言えないなら動機が弱すぎます

• 体制: 壊れたときに自分で調べて直しにいける人が社内にいるか。いないなら月額を払うほうが確実に安い

自作で最低限そろえる機能6つ

自前でメールを配るなら、ここから下は削れません。実際に実装している順に並べます。

実際に踏んだ不具合と対策

ここからは自慢できない話です。2つとも、いまはコードに修正の記録が残っています。

全メールの配信停止リンクが「無効なリンク」になっていた

配信停止URLは、設定値のサイトアドレスに購読者ごとの解除トークンをつないで作ります。問題は、その設定値が未設定だったときの挙動でした。実装が「設定が無ければ空文字」だったため、URLが`/unsub/...`という相対パス（ドメイン名のない、途中からのアドレス）になっていたのです。

ブラウザなら相対パスは解決されますが、メール本文には基準になるページがありません。つまり、押しても何も起きない配信停止リンクが、全メールのフッターに入っていた。原因は設定名の不一致で、似た名前の設定値が複数あり、コードが読んでいる名前だけが埋まっていませんでした。2026年7月20日に設定を追加して修正し、同じ場所に「これが未設定だと解除リンクが相対URLになる」とコメントを残しています。

二重送信を防ぐ冪等ガードが、データベースのエラーで落ちた

同じ人が同じ資料をもう一度請求したとき、資料メールを2通送らない仕組みを入れています。冪等（べきとう）とは、同じ操作を何回実行しても結果が1回分にしかならない性質のことです。

最初はSQLの`LIKE`で送信ログを部分一致検索していたのですが、本番で落ちました。資料PDFのファイル名が日本語で、URLエンコードされると`%E3%82%A2`のような記号の羅列になり、これを検索パターンとして渡すとデータベースが「パターンが複雑すぎる」と返したためです。対策は、パターン解釈が起きない素の部分文字列検索`instr()`への置き換え。検索関数の選択が、そのまま二重送信の防波堤の強度になっていたわけです。

この2つに共通するのは、どちらも「送信が成功しているように見える経路」で起きたことです。自作でメールを回すなら、成功ログとは別に受信側から見た検証を運用に入れる必要があります。AI自動化を安全に組む設計の考え方はAI業務自動化のリスク設計にまとめました。

メールCRMの自作に向く会社、向かない会社

全員に勧める話ではありません。判断基準を正直に書きます。

向いている会社の条件

• 「ツールでは届かない連携」が1つ以上、具体的に言語化できている

• 名簿を自社データとして分析に使う予定がある（他のデータと結合したい要求があるか）

• 土台になるコードか、近い実装経験がある。僕の場合はLINE版がありました

• 障害時に自分たちで直せる体制がある。メールは止まると営業活動が止まります

向いていない会社の条件

• 目的が月額の削減だけ。削れるのはツール代で、代わりに増えるのは自社の運用責任です。前の章のとおり、数千件規模なら月額の差は月に数千円で、この交換は割に合いません

• 配信頻度が月1回程度で、連携の不満もない。作る動機が弱すぎます

• 法対応や到達率の判断を、社内で誰も引き受けられない。ここは外部に任せたほうが安全です

自社では持ちたいけれど作る手が足りない、という場合は外注という中間解があります。何を任せて何を自社に残すかの線引きはAI業務自動化の外注に書きました。自作か外注かで迷っている段階なら、先にそちらを読んだほうが判断が早いと思います。

関連記事AI業務自動化を外注する前に知っておくべき5つのことAI業務自動化の外注で何を頼めて、何は頼めないのか。受託を提供する側で、自社の業務自動化も自分で組んで運用している立場から、費用が決まる構造・失敗の典型パターン・依頼前に済ませるべき準備を解説します。→

よくある質問

まとめ

メール配信システムの自作には3つの層があり、現実的なのは真ん中の②です。送信は専業に任せ、「誰に何をいつ送るか」の判断と名簿だけを自社に持つ。この線引きができれば、作る範囲は思ったより小さくなります。

費用は、月額だけを見れば数千件規模まで自作が安く付きます。ただし勝負を分けるのは月額の差ではなく、保守の時間を払い続けられるか、そして「ツールでは届かない連携」を具体的に言えるかどうかです。言えないなら、契約して運用に集中したほうが速い。

自作するなら、名簿と経路タグ・ウェルカムシーケンス・One-Click配信停止・同意とバウンスの機械ガード・送信ドメイン認証と日次上限・フォーム連携の6つが最低ラインです。そして踏んだ2つの不具合が示すのは、自作の難所がコードではなく検証にあるということ。送信ログは正常なのにリンクが壊れている状態は、送信側からは見えません。受信側から通しで確認する工程を、運用に必ず置いてください。

自社の業務に合わせたシステムを持つべきか、ツールで足りるのか。判断に迷う段階でのご相談も歓迎しています。