メルマガの下書きができるまでを、人が触らない形にした — 実装の記録
記事を1本公開すると、メールの文面が組まれ、配信システムに下書きが入るところまで人が触りません。どこに承認を置いたか、なぜそこなのか、実際に使っている道具と踏んだ失敗まで、自社の実装をそのまま書きます。
結論から書きます。私たちがメールマガジンで自動化したのは「文章を書くこと」ではなく、書いたものを運ぶことでした。記事を公開すると、その記事がメール用の文面に組み直され、配信の道具の中に下書きとして入るところまで、人は一度も触りません。人が触るのは最後のひとつ、送信の操作だけです。
先に言葉の意味を書いておきます。ここで言う配信システムとは、登録した人のメールアドレスを預かって、まとめてメールを送るための道具のことです。下書きは、その道具の中に「宛先も本文もできているが、まだ送っていない」状態で置いておくことを指します。この記事はこの2つが分かれば読めます。
自動化したのは「書く」ではなく「運ぶ」
メールの自動化と聞くと、AIが文章を考えてくれる話だと思われがちです。私たちの実装は違います。何を伝えるかはすでに記事で決まっていて、それを別の器に移し替えているだけです。
| 工程 | 誰がやるか | 中身 |
|---|---|---|
| 何を書くか決める | 人 | テーマの選択。ここは渡していません |
| 記事の下書きを作る | AI | 公開前に人が読みます |
| 記事をメール用の文面に組み直す | AI | 見出しの立て方も長さも、メールの読み方に合わせて変えます |
| 配信システムに下書きを作る | AI | 件名・本文・宛先の指定まで入った状態で置かれます |
| 送信する | 人 | ここだけ人の操作です |
手で書いていた頃にいちばん時間を食っていたのは、実は文章そのものではありませんでした。記事を開いて、必要な部分を選んで、メールの形に整え直して、配信の画面に貼り付ける——この移し替えの往復です。中身を考える仕事ではないのに、毎回まとまった時間が消えていました。自動化して効いたのはここです。
記事とメールは、同じ文章ではない
そのまま貼れば済む、とはなりませんでした。記事とメールでは読まれ方が違うからです。
- 記事は、検索や紹介からその話を読みに来た人が開きます
- メールは、別のことをしている最中に届きます。開くかどうかは件名と冒頭で決まります
- 記事には目次があり、読み飛ばせます。メールは上から順にしか読まれません
そこで、組み直しの工程では記事の結論を先頭に出し、続きは記事へ送る形に決め打ちしています。メールの中で記事を再現しようとすると、長いだけで最後まで読まれないものができます。メールは入口、記事が本体、という役割分担です。
この分担を決めておくと、AIに渡す指示が短くなります。「良いメールにして」ではなく「結論を先頭に出して、続きは記事へ送る形にして」と書けるからです。自動化の設計でいちばん効くのは、モデルの選定より、渡す仕事の形を決めることでした。
承認は、ひとつだけ置く
私たちは工程のあちこちに確認を挟んでいません。止めるのは外に出る瞬間だけです。
記事を公開 → 文面に組み直す → 配信システムに下書き → 人が読んで送信
(自動) (自動) (自動・ここで止まる) (人)
判断の基準はひとつだけにしています。間違えたとき、取り消せるかどうかです。
| 取り消せる | 取り消せない |
|---|---|
| 下書きを作り直す | 送信したメール |
| 記事を直す | 一度届いた文面 |
| 文面を組み直す | 誤った宛先への配信 |
左の列は何度やり直しても誰にも迷惑がかかりません。だから全部渡しました。右の列は、間違えたと気づいた時点で手遅れです。だから人が持っています。
すべてに承認を挟まないことも同じくらい大事です。 工程ごとに人が確認する形にすると、確認の待ち時間が積み上がって、結局「今日は時間がないから明日」になります。止めるのを1か所に絞ったので、人の仕事は「届いた下書きを読んで、出すか直すか決める」だけになりました。
もうひとつ。ルールとして「送信前に必ず確認する」と決めるだけでは足りません。急いでいる日に必ず飛ばされるからです。私たちは、自動で走る処理からは送信の操作そのものに手が届かない形にしています。決意ではなく構造で止める、という言い方が正確です。
使っている道具と、差し替えられるようにした理由
固有名詞を出しておきます。私たちが実際に使っているのは MyASP と Mailchimp です。サイトのフォームから資料請求があると、その登録は両方に書き込まれ、Mailchimp 側には「どこから来た人か」がタグとメモで残るようにしています。
ここで設計として意識したのは、記事を書くエージェントと、配信システムに書き込むエージェントを分けておくことです。
| 分けて得られたこと | 中身 |
|---|---|
| 壊れた場所が分かる | 文面がおかしいのか、書き込みが失敗したのかを切り分けられます |
| 差し替えが効く | 配信の道具を変えても、記事を書く側は触らずに済みます |
| 片方だけ止められる | 書き込みが不調な日でも、記事の生成は動かし続けられます |
配信ツールは、料金や機能の都合で数年に一度は見直しが起きます。そのときに書く側まで作り直しになる形にしておくと、乗り換えられなくなって、道具のほうに事業が縛られます。 ここを分けておくのは、自動化の話であると同時に、あとで選び直す自由を残しておく話です。
エージェントの分け方そのものについては、マーケティングを4工程に分け、AIエージェントを配置するに全体像を書いています。私たちは2026年8月時点で28体を動かしていますが、体数が増えても回るのは、1体ずつが小さく独立しているからです。
実際につまずいた場所
うまくいった話より、こちらのほうが役に立つはずです。私たちが実際に踏んだものだけ書きます。
承認を挟まずに外部へ書き込ませたことがあります。 取り消せない操作を無人で走らせる形になっていました。動いている間は何も起きません。問題は、間違えた一度だけです。ここから「取り消せない操作の手前には必ず人を置く」を、例外なしのルールにしました。
計測に必要な情報を保存し忘れたこともあります。 送った・投稿したという事実は残っていても、あとから結果を引き当てるための手がかりを残していませんでした。動かすことに集中していると、残すことは後回しになります。作る前に「何を残すか」を決める。 これは自動化そのものより先に決めるべきことでした。
生成まで作って、そこで止まっていた時期もあります。 文面はできるのに、配信システムへは人がコピーして貼っていました。この状態は自動化とは呼べません。移し替えの往復こそが時間を食っていた部分だからです。出力先まで繋がって初めて、かかっていた時間が消えます。
これから作る人への順番
同じものを作るなら、この順で考えると迷いにくいはずです。
- 人が判断する場所を先に1か所決める。 私たちの場合は送信です
- その手前までを、取り消せる操作だけで組む。 下書きを作るところで必ず止める
- 記事とメールの役割を決める。 どちらが本体で、どちらが入口か
- 出力先まで繋ぐ。 人がコピーして貼っている限り、時間は減りません
- 何を残すか決めてから動かす。 あとから足そうとすると、その間のぶんは永久に取れません
順番を逆にして「まず文章の質を上げる」から入ると、たいてい止まります。質が問題になるのは、毎日通るようになってからです。
自動化したあとに人の仕事がどう入れ替わったかは、集客・教育・販売・計測を全部AIに寄せてみたに書きました。作業は減りましたが、暇にはなっていません。
まとめ
- 自動化したのは文章を書くことではなく、記事をメールの形に移し替えて配信システムまで運ぶことです
- 記事とメールは読まれ方が違うので、メールは入口、記事が本体と役割を決めてから組み直しています
- 承認は工程のあちこちではなく、外に出る瞬間のひとつだけに置いています。基準は「取り消せるかどうか」だけです
- 書く側と配信システムに書き込む側を分けたので、配信ツールを乗り換えても書く側は作り直しになりません
- 生成だけ自動にして人がコピーして貼っている状態は、まだ自動化ではありません。出力先まで繋いで初めて時間が消えます
- 作る前に「何を残すか」を決めておかないと、動き出したあとで計測ができなくなります
AIエージェントを実際に入れるとき、どこから手をつけて、どこで人が判断を持つのか。私たちが自社で運用して分かったことを、無料レポート『AIエージェント導入の実際』にまとめました。自己診断シート付きで、/report/ から受け取れます。導入を検討する前の判断材料としてお使いください。
本記事の内容は2026年8月時点のものです。
この記録の仕組みを、御社のマーケティングに実装することもできます。 30分の個別相談で、自動化できる領域を診断します。初回セッションは有料です。
個別相談を申し込む