Marc LouのMailCheapに学ぶ、メルマガをAIに任せる手順

メルマガをAIに任せるときは、下書きができた段階で一度受け取り、送る前に内容を確かめる。Marc Louが公開した「MailCheap」は、原稿作成から配信結果の確認までを、別々に呼び出せる配信ツールです。

Marcは自作したツールで初回のニュースレターを送ったと報告し、現在はAIから下書きや配信を操作できる仕組みも公開しています。自分の仕事で試すなら、まず公開済みの記事一本を材料に、配信前の原稿と確認メモを作らせるところから始められます。

使い続けた配信サービスを、自分で作り直す

MarcはMailCheapの公式サイトで、beehiivを二年間使い、値上げに対して自分が使う機能が増えなかったため、自分の配信ツールを作ったと説明しています。また、同じものを使いたいという声を受け、他の人にも提供する形にしたと書いています。

10月10日に最初のコードを公開。13日には、自作のbeehiiv代替で初回配信をしたとXで報告しています。さらに10月14日の更新で、管理画面に加えてAIから操作する仕組みを含むアプリ全体が公開されました。現在は、自分のサーバーで動かす版と、運営側に任せるクラウド版があります。

この流れから読み取れるのは、自分が繰り返している作業を一つの商品にし、他の人やAIも操作できるように広げたことです。ただし、最初からどこまで事業化を計画していたかは不明です。

下書き、テスト、本配信は別々の操作

MailCheapの現在の説明書には、AIなど外部のプログラムから使う操作が載っています。APIとMCPは、その操作を呼び出すための窓口です。原稿を作るだけでなく、テストを送り、本配信し、結果を取得する操作も用意されています。

MailCheapの公開仕様で分かれている主な作業（2026年10月15日確認）

作業	何が起きるか
下書き作成	件名と本文を持つ原稿を保存する。この操作だけでは配信しない。
テスト配信	保存した原稿をアカウント所有者のメールアドレスへ送る。
本配信	そのニュースレターの配信対象の読者へ送る。
結果の取得	配信数、開封、クリック、不達、苦情などの記録を取得する。

下書きの作成を依頼した時点で、誰に送るかまで決める必要はありません。原稿を見てから配信対象を確認し、送った後は結果を読む。途中の成果物を確かめながら、次の作業を渡せます。

送信操作の説明には、取り消せないため先に利用者へ確認するよう書かれています。MCPにもその性質を示す情報が付いています。ただし、これはAIへ確認を促す設計であり、利用するAI側で必ず承認を求めることまで、今回の調査では検証していません。

配信前には件名、配信停止リンク、メールのサイズ、送信元などを調べる仕組みもあります。文章が正しいか、読者に送る価値があるかは、このチェックとは別に人が判断します。

初回配信の数字だけでは、運用の成功は分からない

Marcは10月13日の投稿で、従来の10％の費用で初回配信をしたと述べています。日本時間の翌14日には、配信から約二時間で開封率28％と返信しました。どちらも本人の報告です。費用に開発や保守が含まれるか、開封率の分母と計測方法、以前の配信との比較条件は確認できません。

一方、同じ投稿への返信には、登録・確認を済ませたのにメールが届いていないという読者の申告もあります。個別の不達や原因を検証できる資料はありませんが、初回配信の成功報告だけで、全員へ問題なく届くと判断することもできません。

公開仕様でAIから操作できることは確認できますが、Marcがこの初回配信のどの作業をAIに任せたか、どれだけ手間を減らせたかは不明です。自分の事業で同じ費用や手間になるかは、別に確かめる必要があります。

自分の仕事では、配信前の一通をAIに任せてみる

ここからは、MailCheapの作業の分け方を参考にした編集側の提案です。新しい配信サービスへ移る前に、いま使っている環境のまま、メルマガの下書きを一通作らせてみます。

渡す材料は、公開済みの記事一本、出典のURL、誰に何を伝えたいかを一文で書いたメモです。顧客の連絡先や、公開していない事業の情報はこの試行には要りません。依頼する順序は次のようにします。

1. 記事から一番伝えたいことを一つ選び、その根拠となる事実を抜き出す。
2. 件名、受信箱に表示する短い説明、本文を一通分作る。
3. 数字・日付・条件と出典を照合し、使った根拠と確認できなかった箇所を原稿とは別のメモに残す。

AIへ渡す依頼には、読めなかった資料があればその箇所を報告し、配信予約や送信へ進まないことも書いておきます。人は元記事と原稿を読み比べ、意味や条件が変わっていないか、配信する理由があるかを判断します。

この一作業の完了は、一通分の原稿、根拠のメモ、未確認箇所の一覧がそろい、人が直す箇所を判断できた状態です。確認にかかった時間と、事実・条件の修正が何件必要だったかを残すと、次に任せる範囲を決める材料になります。根拠をたどれない場合は、配信準備を進めず、材料や依頼文を直します。

その後、配信システムへの保存、自分宛てのテストを別の仕事として加えられます。本配信まで任せる段階では、確定した原稿、対象、人数、時刻を一緒に確認し、実行結果も読み戻します。

出典

• MailCheap公式サイト：本人が説明する開発理由と、現在の製品案内。掲載日時は不明。
• MailCheapの10月10日版／10月14日のアプリ全体の公開：コードと更新記録。
• 今回確認した更新後のコードと説明書／MCPの説明：操作、配信前の確認、利用者への確認を促す仕様。
• Marcの初回配信の報告：2026年10月13日。開封率についての本人の返信：日本時間10月14日、UTCでは13日。
• メール未着についての読者の申告：日本時間10月14日。本人の申告として掲載。未着の原因は未確認。

調査日：2026年10月15日。前回の10月8日以降を重ねて確認しました。製品の仕様説明、本人・読者の報告、編集側の試行案を区別して記載しています。