メールニュースレターは自前で構築すべきか外注すべきか？ Claude と一緒に意思決定を走りきって、最終的に Resend を選んだ

TL;DR — paulkuo.tw にニュースレターを導入しようとしたとき、最初に知りたかったのはシンプルな問いだった。自分で構築すべきか、それとも Substack をそのまま使うべきか。Claude と議論を重ねた結果、最終的に選んだのは「半自前構築」だった。購読者リストと配信フローは自分で持ち、メール送信は Resend に任せる。その後、同じアーキテクチャの上に開封率トラッキングも追加した。この経験から見えてきたのは、半自前構築のメリットが「その場で楽できる」という点だけにはとどまらないということだ。後から機能を追加したいと思ったとき、プラットフォームの判断を待たなくていい。

「ウェブサイトにニュースレターを持たせるなら、自前で構築すべきか、それとも Substack のような既存サービスを使うべきか？」

これが Claude に投げた最初の問いだった。当時、paulkuo.tw にはすでに安定稼働しているバックエンドがあったため、購読者リストを追加すること自体は技術的に難しくなく、コストも低い。ただ「技術的に難しくない」と「やるべきか・どうやるべきか」は別の話だ。手を動かす前に、アーキテクチャの整理を先にしたかった。

Substack は便利だが、今回の条件には合わない

Substack の強みは明確だ。独自の推薦ネットワークがあり、ニュースレターを始めたばかりの人には最初の読者を集めやすい環境が整っている。ただし、有料購読を設定すると収益の10%が抜かれ、決済手数料も別途かかる。レイアウトや読者とのやり取りも、Substack のアプリや Notes の仕組みの中に少しずつ囲い込まれていく。

多くの人にとって、この取引は十分に划算が合う。しかし paulkuo.tw の場合、私が重視するのは購読者リストを自分で握れるかどうか、そして将来サイトや配信フローを自由に変えられるかどうかだ。

サイトもコンテンツもドメインも自分で管理しながら、購読関係だけ別のプラットフォームに置くとなると、アーキテクチャ全体に明確な依存が生まれる。Substack が持ち込む初期流量が特別に必要でない限り、この交換条件は私にとって割が合わない。

とはいえ、Substack を見送ることは、すべてを自前でやることを意味しない。

半自前構築とはどういうことか

完全自前構築の本当の手間は、配信コードを書くことだけにあるのではない。メールを確実に受信トレイに届け続けることにある。送信ドメインの認証（SPF・DKIM・DMARC）、バウンス処理、スパム苦情への対応、送信履歴の管理。どれか一つ崩れると、メールがまとめて迷惑メールフォルダに落ちる。これらはすでに専門サービスが長年かけて磨いてきた問題だ。自分で一から構築しても、必ずしも楽になるわけではない。

物流に喩えると分かりやすい。既存サービスを丸ごと使うのはデパートのテナントに入るようなもので、何でも整えてもらえるが、顧客リストはデパートのものになる。完全自前構築は自分でビルを建て、配管まで自分で引くようなものだ。最も自由だが、最も消耗する。半自前構築は顧客リストと運営を自分で管理しながら、荷物をどう届けるかはヤマト運輸に任せて、自前の車両は持たないイメージだ。

具体的な切り分けはこうなる。購読者リスト、購読フォーム、「新しい記事が出たら送る」という判断ロジックは自前で持つ。外注するのは、メールを実際に相手の受信トレイに届けるという部分だけだ。アーキテクチャの軸が定まれば、問いは一つに絞れる。外注する配信の層を、どのサービスに任せるか。

4つの候補サービス、どう絞って Resend に至ったか

比較では4つの候補を並べ、それぞれの優位点と懸念点をきちんと展開した。直感で一つを選ぶのではなく、各選択肢に明確な脱落または選出の理由を持たせた。

特筆に値するのは Cloudflare Email Service だ。Cloudflare のエコシステム全体とネイティブに統合でき、Workers からそのまま呼び出せる。最初は最もしっくりくる選択肢に見えた。しかし実装計画を書く前に公式ドキュメントを確認したところ、現時点ではトランザクションメールのみのサポートと明記されており、ニュースレターのような一斉送信はスコープ外だった。今回の Claude との議論で印象に残った転換点の一つだ。表面上は最も相性が良さそうに見えた選択肢が、公式ドキュメントを確認した結果、最初に除外された。Claude がここで果たした役割は、選択肢を列挙することだけではない。各前提を一つずつ確認し、方向を調整するプロセスに付き合うことだった。

最後の問い：配信コストを省くか、運用工数を省くか

最後に残ったのは Resend と AWS SES の二択だ。差は単純に言える。SES の方が送信単価は低いが、ニュースレターに必要な多くの機能を自前で組む必要がある。Resend は少し高いが、一括送信・購読解除・バウンス・苦情処理がすでに整っている。

個人サイトの規模なら、実際の費用差はほとんど出ない。本当に差が出るのは、自分がどれだけの時間を運用に投じるかだ。私は記事を書く時間を優先したいので、Resend を選んだ。

決定後、半自前構築の思想が実際に形になる二つの追加判断があった。

一つ目は、購読者リストをどこに置くか。最初は Resend のリスト管理機能をそのまま使うことも検討したが、最終的にデータは自前の Cloudflare D1 に置き、Resend は配信専用チャネルとして使う構成にした。将来サービスを切り替えることになっても、購読者データを一緒に移行する必要がない。

二つ目は送信元アドレスに関する判断だ。理想的にはサブドメインを別途用意してニュースレターを送信し、メインサイトと配信のレピュテーションを切り離すべきだ。ただそれには有料プランへのアップグレードが必要になる。現在の規模を踏まえ、すでに認証済みのメインドメインを使い [email protected] で送信することにした。最も標準的なアーキテクチャではないが、現時点のコストと使用量のバランスの中では十分な判断だ。

システムは2026年6月末に本番稼働した。購読登録から確認メール受信、確認リンクのクリック、最後に購読解除まで、全フローを自分で一通り歩いた。確認メールは正常に受信トレイに届き、データベースのステータスも連動して更新された。自動テストもすべて通過した。稼働後、コード管理プラットフォームのアカウントが意図せず停止される出来事があったが、サイトとニュースレターは正常に動き続けた。デプロイフローが単一プラットフォームに依存していないことを、期せずして証明した形だ。この経緯は別途書く価値があるので、ここではいったん触れるだけにしておく。

送った後、誰かが開封しているかを知りたくなった

システムが安定稼働してしばらく経った頃、ふと問いが生まれた。この購読者たち、実際に読んでいるのか。一般的なニュースレタープラットフォームなら開封率は標準機能として提供されている。しかしこの半自前構築では、トラッキングをするかどうか、データをどう保存するか、どこで確認するかを、自分で決めなければならない。その代わり、購読者リストと送信履歴が手元にある以上、今後どう活用するかもプラットフォームの既存インターフェースに縛られない。

最初の答えは「まだ分からない」だった。Resend には開封・クリックのトラッキング機能があるが、デフォルトでは無効で、有効にしても Resend がイベントを能動的に通知してくれるわけではない。

実装は複雑ではない。まず Resend のトラッキング機能を有効にし、通知を受け取るエンドポイントを用意する。誰かがメールを開封したり、リンクをクリックしたり、あるいはバウンスや苦情が発生したりすると、Resend がそのイベントを自前のシステムに送ってくる。サービスが別のシステムにイベントを能動的に通知するこの仕組みを、一般に webhook と呼ぶ。

Resend を装った偽のリクエストを防ぐため、各通知に付与されたデジタル署名をシステム側で検証する。最後に、テーブルを2つ追加した。一つはメールの送信先を記録するもの、もう一つはその後のイベントを記録するものだ。追加のライブラリは不要で、ブラウザとサーバーに標準搭載された暗号ライブラリで署名検証が完結する。

現在、このトラッキングの接続は本番稼働済みで、セキュリティ検証のテストも完了している。正当な署名のないリクエストはシステムが直接拒否する。追加したばかりのトラッキングなので、完全な開封イベントはまだ蓄積されていない。開封率は現在、偽りの0%ではなく「データなし」と正直に表示されている。データはまだ入っていないが、パイプラインはすでに接続されているという誠実な状態そのものが、半自前構築アーキテクチャの具体的な証明だ。追加したい機能があれば、いつでも追加できる。誰かに開放してもらうのを待つ必要がない。

このデータは、自前のダッシュボードに組み込むこともできるし、別の分析ツールに接続することも、必要なときだけ API 経由で照会することもできる。今はまだ急いで決めていない。データをしばらく積ませてから判断する。

このニュースレターシステムが稼働してから、次の問いが少しずつ見えてきた。まず送れること、次に購読解除できること、そして読者が開封しているかどうかを知ること。機能はすべて最初から設計したわけではなく、実際に使う中で一つずつ育ってきた。

私にとって、これが半自前構築の最も実際的なメリットだと思う。今すべてを完成させる必要はない。でも先に進みたいと思ったとき、調整する余地が手元に残っている。