背景：20年モノのメーリングリストが限界だった
長年使われてきたメーリングリストが、ある時期から明確に「届かなく」なった。
- 特定キャリアに届かない
- 迷惑メールに振り分けられる
- 誰に届いて、誰に届いていないのか分からない
- 管理者が原因を説明できない
にもかかわらず、
「今まで使えていたから」という理由だけで使われ続けていた。
そこで一度、根本から作り直すことになった。
方針：派手な新技術は使わない
最初に決めたことはシンプルだ。
- ✔︎ 到達率を最優先
- ✔︎ 管理者が“理解できる”仕組み
- ✔︎ トラブル時に原因を追える
- ✔︎ 無理に全部を自動化しない
つまり「賢すぎない」「ブラックボックスにしない」。
設計の要点①：配信は“分散”が前提
一斉送信はしない。
- 宛先は内部で分割
- 時間帯も分散
- 送信結果はすべてログ化
これだけで、迷惑メール判定の確率は大きく下がる。
設計の要点②：添付ファイルは送らない
添付ファイルは届かない原因の塊だ。
そこで、
- ファイルはサーバー側に保存
- メール本文にはダウンロードURLのみ記載
- URLは一意・期限付き
「メールは通知、実体はWeb」これだけで配信の安定性が一段上がった。
設計の要点③：不達は“自動で止める”
最も重要なのがここ。
- 不達を検知
- 一定回数失敗したら自動停止
- 管理者が手で除外しなくていい
「送り続けない」ことが、結果的に全体の到達率を守る。
設計の要点④：予約配信を“既存資産”で実現
新しい予約配信エンジンは作らなかった。
代わりにやったのは、
- 予約用の受信口を分ける
- 時間が来たら“ファイルを移動”
- 既存の配信処理に自然合流
送信ではなく、ファイル移動。
この発想で、新しいバグの温床を作らずに済んだ。
管理画面で重視したこと
管理画面で意識したのは技術ではない。
- 専門用語を出さない
- 状態は日本語で表示
- 「今どうなっているか」が一目で分かる
裏側がどれだけ複雑でも、触る人はそれを知らなくていい。
まとめ：メーリングリストは「送れればいい」ではない
メール配信はインフラだ。
- 壊れても気づかれない
- でも壊れると致命的
だからこそ、
「分かる・止まる・説明できる」
この3点を満たすことが、一番の安定化策だった。
同じように「なんとなく不調なメーリングリスト」を抱えている人の参考になれば幸いだ。
