ツール導入奮闘記

AIと8週間でメルマガ配信システムを自作した記録【メルマガ自作奮闘記 第1回】

2026年8月15日

数年ぶりにメルマガを再開しようと思い立って、以前買った配信ツールの設置マニュアルを開きました。そして、そのまま閉じました。サーバーへの設置からやり直すのが、どうにも面倒だったからです。

こんにちは。AIでDXを加速する専門家、ばんのです。

結局その日、私が選んだのは「配信ツールの設定をする」ではなく「配信ツールを自分で作る」でした。流行りのバイブコーディングでどこまでのものができるのか、正直かなりワクワクしていました。そうしてできあがったのが、約8週間・コードにして約17,000行のプラグインです。117回の更新を重ねて、今も毎日動き続けています。

プログラマーを雇ったわけではありません。私がAIに指示を出しながら、少しずつ育てたものです。コードは1行も書いていません。

今回から数回に分けて、この記録をお届けします。第1回は「なぜ既製品を使わずに自作したのか」という判断の話です。先に断っておくと、費用を浮かせるためではありません。

この記事を読むとわかること

  • 既製の配信ツールがあるのに自作を選んだ、3つの理由
  • 「ツールの設定が面倒」の正体
  • 実際にAIへ作らせたものの規模と、かかった時間
  • 自作をおすすめできる人と、やめておいたほうがいい人の線引き

先に書いておきます。コストが理由ではありません

この手の記事は「月額◯円を浮かせました」という話になりがちですが、私の場合は違います。手元にあるもので済ませようと思えば、済ませられる状況でした。

買い切りも月額も、すでに持っています

これまでにアスメル、エキスパといった配信サービスを使ってきましたし、メルマガと会員サイトを一体で扱えるサーバーインストール型のツールCyfons(サイフォンス)も購入済みでした。購入時で3万円ほどだったと記憶しています。買い切りなので、手元にあるものを使う限り追加の出費はゼロです。

月額型のサービスについても、正直なところ月3,000円くらいなら妥当だと思っています。読者管理、配信の安定性、迷惑メール対策まで面倒を見てもらえることを考えれば、むしろ安いくらいです。

それでも自作を選びました

つまり、既製品に不満があって飛び出したわけでも、コストに耐えかねたわけでもありません。それでも自作を選びました。理由は3つあります。

自作を選んだ3つの理由

順に書いていきます。1つ目は今回限りの事情、2つ目は先を見た判断、3つ目は運用者としての好みです。決め手になったのは2つ目でした。

図1 自作を選んだ3つの理由と、決め手になったもの
理由1 設置のやり直しが必要だった
新しいドメインで一から入れ直すことになった。今回限りの事情
理由2 作り方そのものが手元に残る(決め手)
同じやり方で、次に欲しくなった仕組みも自分で作れる
理由3 自分の運用に合わせたい
どうせ組み直すなら、普段の使い方に合った形にしたい

理由1:新しいドメインでの再開には、設置のやり直しが必要だった

今回のメルマガは、新しく立ち上げたブログのためのものです。つまり、ドメインが以前とは違います。

ここで問題になったのが、Cyfonsが「サーバーインストール型」だという点でした。月額サービスのようにIDとパスワードでログインすれば使えるものではなく、自分のレンタルサーバーにプログラム一式をアップロードして設置し、そのドメインで動かす仕組みです。

以前のドメインに設置したものを、そのまま新しいブログのメルマガに使うこともできなくはありません。ですが、それをやるとブログのドメインとメールの送信元ドメインが食い違います。読者からすれば、Aというサイトに登録したのに、Bという見覚えのないドメインからメールが届くことになります。迷惑メールに振り分けられやすくなりますし、そもそも読者に不審に思われては元も子もありません。

結局、新しいドメインで一から設置し直すことになります。数年前に一度やった作業ですが、当然すべて忘れています。しかもその間にサーバーの管理画面もPHPのバージョンも変わっています。マニュアルを開き直して、手順をたどり直すところからのスタートです。

そして、設置が終わってようやくスタートラインです。そこからステップメールを1本立ち上げるまでに、まだこれだけの作業が残っています。

図2 新しいドメインで再開するのに、必要だった作業
まず、ここまでが設置
1. プログラム一式をサーバーへ上げる

2. 新しいドメインで動くように設定する
ここからが、やっとスタートライン
3. 登録フォームを設置する

4. 確認メールと、承認後のページを用意する

5. ステップメールを書いて、送る日を設定する
送り出す前の準備
6. 配信停止の受付ページを用意する

7. 差出人アドレスと送信サーバーを通す

8. テスト登録して、最後まで動かす
この8つのうち、メルマガの中身が良くなる作業は1つもありません。ほとんどが「ツールの作法を思い出す作業」です。

ファイルの置き場所、画面の位置、項目の名前、独特の言い回し。数年前に一度覚えたものを、もう一度たどり直す。この時間は、メルマガの中身を良くすることには1ミリも貢献しません。

実は2021年にも、当時使っていたプラグインの導入手順をMailPoet導入奮闘記として8回の連載にまとめています。あれだけ書いておいて、数年経つと結局また同じところでつまずくわけです。

そしてこの「覚え直しコスト」は、買い切りのツールを持っていても消えません。ブランクが空くたび、ツールを乗り換えるたびに、何度でも払わされます。

理由2:バイブコーディングができれば、今後は何でも作れる

これが決め手でした。ちょうどClaude Codeを使い始めた時期で、日本語で指示を出すだけでコードが上がってくるという手応えを得ていたところです。いわゆるバイブコーディングです。始め方そのものはバイブコーディングの始め方に書いたとおりで、プログラミングの文法を覚える必要はありません。

ここで考えたのは、目の前のメルマガのことではありませんでした。この進め方が身につけば、今後「こういう仕組みがあれば楽になるのに」と思ったとき、そのつどAIに作らせられるようになります。顧客管理でも、見積書の自動作成でも、サイトの分析ツールでも同じです。一人社長にとって、これは働き方が変わる話です。

とはいえ、練習のためだけに何かを作らせても続きません。どうせなら、完成したら実際に使うものがいい。そこに「ステップメールを組み直さなければいけない」という現実の課題があったわけです。手始めの題材として、これ以上ないものでした。

理由3:どうせ組み直すなら、自分の運用に合わせたい

既製品を使うということは、用意された機能の範囲に自分の運用を合わせるということです。

たとえば私の場合、「登録から3日たっても確認メールのリンクをクリックしていない人にだけ、もう一度だけ確認メールを送りたい。5日目にもう一度送って、7日目で締め切る。それ以上はしつこいのでやらない」という要望がありました。

この程度のことでも、設定画面に項目がなければ実現できません。要望を送っても、いつ実装されるかは分かりません。サービス側からすれば、利用者一人の都合で機能を追加する理由がないからです。

こういう小さな妥協は、単体では大したことがありません。ですが数年運用すると積み上がって、だんだん自分のメルマガではなくなっていきます。

実際に何を作らせたのか

AIに作らせたのは、WordPressに組み込むステップメール配信プラグインです。運営サイトの名前を取って「BKSM」と呼んでいます。

8週間で、117回の更新

最初のバージョンを動かしたのが6月21日。この記事を書いている時点で8月14日ですから、約8週間です。その間の数字を並べるとこうなります。

項目数字
開発期間約8週間
更新回数117回
バージョンv1.2.0 → v3.21.0
コードの量約17,000行(PHP・テスト除く)
動作確認用のテスト約2,300行
専用のデータ保管場所12種類

17,000行と言われてもピンとこないと思いますが、市販のWordPressプラグインとして十分に成立する規模です。もちろん、この行数を私が打ち込んだわけではありません。私がやったのは、何を作るかを決めて、AIに指示を出し、上がってきたものを確認して、違えば差し戻す。この繰り返しです。

何ができる仕組みなのか

機能を分けて並べると、大きく4つのかたまりになります。配信そのものと、その結果を測る部分。そして読者とのやり取りと、特典の受け渡しです。

図3 AIに作らせたものの全体像
配信する
シナリオに沿った自動配信
一斉配信と、その予約送信
件名を2パターン試すABテスト
測る
開封とクリックの記録
曜日と時間帯ごとの傾向表示
記事内バナーの位置別の成績
やり取りする
読者からの返信を管理画面で受ける
メールソフトを開かずにそのまま返信
渡す
特典PDFの配布
ダウンロードページの自動生成

117回は「足りないと気づいた回数」です

最初からこの全部を設計したわけではありません。運用しながら「これが足りない」と気づくたびに、1つずつ足させていった結果です。

ですから117回の更新という数字は、そのまま「足りないと気づいた回数」だと思ってください。設計が上手だったのではなく、気づいたその日に足せる状態だったというだけの話です。

作ってみて、想定外だった3つのこと

始める前に期待していたのは、自分の運用に合う道具が手に入ることでした。実際に動かしてみると、期待していなかったところで効果がありました。

1. 「思いついた日に足せる」の破壊力

理由3で挙げた「3日目と5日目に確認メールを再送したい」という要望は、この記事を書く前日にAIへ指示を出しました。思いついてから本番で動くまで、1日です。

既製品なら、要望フォームに送って、いつ実装されるか分からないまま待つ機能です。外注なら、見積もりを取って発注する時点で「まあいいか」となっていたはずです。

この差は、1回では大したことがありません。ですが117回積み上がると、まったく別のものになります。

2. 数字が全部つながる

サイトとメールが同じ場所にあるので、「どの記事のどの位置のバナーから登録した人が、その後どのメールを開いたか」まで一本の線で追えます。

外部サービスを使っていたころは、この分析をあきらめていました。つなぐ手間が、得られる情報に見合わなかったからです。

3. 中身がわかると、トラブルの待ち時間がゼロになる

これは予想外の効果でした。自分の持ち物として中身が見えるので、「なぜこのメールが届かなかったのか」をその場でAIに追わせられます。実際、送信エラーが出たときに調べさせてみたら、私が設定していた差出人アドレスが1文字間違っていた、ということがありました。

既製品だと、画面に「送信に失敗しました」としか出ないことがあります。そこから先はサポートに問い合わせて、返事を待つしかありません。原因が見えていれば、待ち時間そのものがなくなります。

正直に書きます。自作をおすすめしない人

ここまで良い面を書いてきましたが、誰にでもすすめられるものではありません。向き不向きがはっきり分かれます。

図4 自作が向く人と、既製品のほうが幸せな人
既製品のほうが幸せな3タイプ
何を作りたいのかが、まだ定まっていない/不具合を自分で調べる気になれない/読者が数万人規模
はっきりおすすめできる2タイプ
ツールの設定に時間を溶かしている実感がある/今後もこういう仕組みを自分で持てるようになりたい
分かれ目は技術力ではなく、作りたい形が決まっているかどうかです。

既製品を使ったほうが幸せな3タイプ

  • 何を作りたいのかが、まだ定まっていない方。作るものがぼんやりしたまま手を動かすと、途中で「そもそも何が欲しかったんだっけ」に戻ります。先に欲しい形、道具はその後です。
  • 不具合が出たときに、自分で調べる気になれない方。自作したものに問い合わせ先はありません。困ったときに向き合う相手は、AIと自分だけです。
  • 読者が数万人規模の方。この規模になると送信の安定性やサーバーの負荷が別次元の問題になるので、専門の事業者に任せるべきです。

逆に、はっきりおすすめできる人

こちらは2タイプです。

  • ツールの設定に時間を溶かしている実感がある方。既製品を乗り換えるたびに覚え直しのコストを払っています。一度自分で作れば、その支払いが止まります。
  • 今後もこういう仕組みを自分で持てるようになりたい方。1つ目では元が取れなくても、2つ目3つ目で取り返せます。作り方そのものが手元に残るからです。

よくある質問

同じことを考えている方から聞かれそうな点を、4つに絞ってまとめておきます。

Q1. プログラミングの知識がなくても本当に作れますか

コードを書く知識は不要です。ただし、「何がしたいのか」を順序立てて説明する力は必要になります。「いい感じのメルマガ機能を作って」では動くものは出てきません。「登録から3日たっても確認していない人に、1回だけ再送したい」まで具体化できれば、AIは形にしてくれます。

Q2. 結局、既製品より安く済むのですか

単純比較なら微妙なところです。買い切り型のツールは3万円ほど、月額サービスも3,000円前後で、一方でAIの利用料は月額で発生し続けます。金額だけを見て自作に踏み切ると、たぶん割に合いません。

元が取れるのは、作らせ方を覚えたこと自体を次に使い回したときです。2つ目、3つ目のツールを作らせる段になると、費用の計算は変わってきます。

Q3. AIが書いたコードをどうやって信用するのですか

信用しません。というより、信用せずに済む手順を毎回踏んでいます。メールを送る仕組みは、間違えると読者に同じメールを何通も送りつける事故になるので、ここが一番大事なところです。この確かめ方だけで記事1本になるので、次回に譲ります。

Q4. 作ったあと、放っておいても動きますか

動きます。ただしWordPress本体やPHPの更新に追随する必要はあるので、完全に手放しとまではいきません。この手間を許容できるかどうかも、判断材料の1つです。

ばんのの視点:最初に作るものは「今すぐ使うもの」から選ぶ

この連載で一番お伝えしたいのは、技術の話ではなく題材の選び方です。ここを外すと、たいてい途中で止まります。

練習用の題材は、たいてい途中で飽きる

バイブコーディングを覚えようとするとき、多くの方は練習用の題材を探します。ToDoアプリを作ってみる、簡単な家計簿を作ってみる。教材としては正しいのですが、たいてい途中で飽きます。完成しても使わないからです。

作らないと自分が困る状態だったから続いた

私がメルマガの仕組みを最後まで持っていけたのは、才能でも根性でもなく、動かないと自分が困る状態だったからです。止まれば読者にメールが届かない。だから直させる。この繰り返しが、結果として117回の更新になりました。

今あなたが「設定するのが面倒だな」と思って後回しにしている作業があるなら、それが最初の題材の候補です。面倒だと感じているということは、それだけ具体的に不便が分かっているということですから、AIへの指示もはっきり出せます。

次回予告

第2回では、「AIが書いたコードをどうやって確かめるのか」をお話しします。

AIは驚くほど速くコードを書きますが、そのまま使うのは危険です。実際、上がってきたものにも、放置していれば「送信元のサーバーが一時的に不調になっただけで、読者全員が配信停止扱いになる」という事故につながる作りが混ざっていました。動かしてみるだけでは絶対に見つからない類のものです。

これをどうやって見つけて、どう直させたのか。コードを1行も読まずに実践できる手順として整理してお届けします。

第2回は公開済みです。続けてどうぞ。

AIが書いたコードをどうやって確かめるのか【メルマガ自作奮闘記 第2回】

-ツール導入奮闘記
-, , ,