AI TREND UNIVERSE / BUILD LOG
コードは書けない。
でも、作れる。
非エンジニア＋AIで、自分のサーバーに読者名簿を持つメルマガ配信基盤を実質2日で構築した記録です。
2026年8月1日から2日にかけて、AIと一緒にメルマガ配信の仕組みを自分のサーバー上へ構築しました。
完成したのは、登録フォーム、読者名簿を保存するデータベース、登録・解除処理、管理ダッシュボード、配信APIを組み合わせた小さなメルマガ基盤です。実質2日。既存のXserver契約を利用したため、追加の月額費用は0円でした。
この記事では、完成形だけでなく、DNS認証が進まなかったこと、複数タブによって設定を巻き戻したこと、データベースの権限付与を忘れて詰まったことまで記録します。
この記事で分かること
- 非エンジニアがAIと作ったメルマガ基盤の全体構成
- 「全部を自作しない」という判断が重要だった理由
- メールを受信箱へ届けるために外部サービスへ任せた部分
- DNS認証、複数タブ、DB権限で実際に起きたトラブル
- 記事ごとの登録数を測る
src計測の考え方
先に結論：自作したのは「資産と操作」、借りたのは「到達率」
今回の構成は、すべてを自作したものではありません。
読者名簿、登録フォーム、解除処理、管理画面は自分のサーバーに置きました。一方、メールを実際に届ける部分はBrevoの配信APIを利用しています。
| 項目 | 今回の構成 |
|---|---|
| 構築期間 | 実質2日（2026年8月1日〜2日） |
| 作業者 | コードを書けない非エンジニア＋AI（Claude） |
| 登録画面 | HTML 1枚 |
| 登録・解除 | PHP 2枚 |
| 読者名簿 | 自分のXserver内にあるMySQL 1テーブル |
| 管理画面 | PHP 1枚 |
| メール配信 | Brevo API（無料枠は確認時点で300通／日） |
| 追加月額費用 | 0円（既存Xserver契約を利用） |
なぜ「全部を自作」しなかったのか
メルマガで最も怖いのは、送信処理が動かないことではありません。送信済みと表示されていても、読者の受信箱に届かなければ意味がないことです。
メールの到達率には、送信元の評価、SPF・DKIM・DMARCなどのドメイン認証、解除導線、配信の仕方など、複数の要素が関係します。一般に共有の送信基盤では、同じ基盤を使うほかの送信者の評判の影響を受ける場合もあります。
ここを非エンジニアがゼロから抱える必要はありません。そこで今回は、次のように問題を仕分けました。
自分で持つもの
- 読者名簿
- 興味関心
- 記事別の流入元
- 登録・解除状態
- 管理ダッシュボード
専門サービスへ任せるもの
- 実際のメール送信
- 送信基盤の管理
- ドメイン認証と連携した配信
全部を自作するのでも、全部を月額サービスに預けるのでもありません。問題を分解した結果、「自分で持つべき資産」と「専門サービスに任せるべき危険な部分」が見えるようになりました。
実際に起きた3つのトラブル
1. DNSは反映されているのに認証が進まない
SPF、DKIM、DMARCなどの設定に必要なDNSレコードを追加しました。外部のDNS確認では世界へ反映されていることを確認できていましたが、Brevoの画面では認証がpendingのまま進みません。
ここでAIへ渡したのは、画面の状態とDNSの確認結果です。そして「設定方法をもう一度説明して」ではなく、「どこで止まっているのか切り分けて」と頼みました。
その結果、DNSではなく画面側の認証処理が進んでいない可能性が高いと判断。画面のウィザードとは別の入口であるAPIから認証処理を実行したところ、短時間で認証が完了しました。
画面で詰まったら、同じ操作を繰り返すのではなく、APIなど別の入口がないか探す。
2. 保存した設定が、古いタブによって巻き戻った
WordPressや管理画面を複数タブで開いて作業していると、古いタブには古い設定が残っています。そのタブで保存すると、新しい変更を古い状態で上書きしてしまいます。
今回は実際にこの事故が起きました。それ以降、保存を伴う管理作業は1タブだけで行うルールに変更しました。AIを使った制作では作業速度が上がるため、複数の画面を同時に開きがちです。しかし、速さを優先して正本が分からなくなると、結局は時間を失います。
3. phpMyAdminへ入れても、データベースが使えない
データベース名とユーザーを作成しただけでは不十分でした。対象のMySQLユーザーに、対象データベースへのアクセス権を付与する工程が抜けていたのです。
エラーの原因は高度なプログラムではなく、設定の一手が抜けていたことでした。AIへエラー文と現在の設定を渡して切り分けることで、闇雲にコードを書き換えず、権限設定へ戻ることができました。
Gmailの受信箱に届き、解除導線も表示された
初回テストでは、送信したメールがGmailの受信箱へ届きました。さらに送信者名の付近に、Gmail側の「登録解除」導線も表示されました。
これは法令対応や到達率を保証するものではありません。ただ、設定したドメイン認証と解除用ヘッダーが機能し、Gmail側で解除導線として解釈されたことは実画面で確認できました。
「送信処理が成功した」だけで止めず、実際の受信箱でどのように見えるかまで確認することが重要です。
記事ごとの登録数を測る仕込み
今回の登録フォームには、URLの末尾へ?src=記事名を付けられるようにしました。
この記事末尾の登録URLには、?src=mailmag-build-logが入っています。これにより、管理画面では「どの記事から何人が登録したか」を確認できます。広告運用でいうコンバージョン計測と同じ考え方です。
登録時には、読者が関心を持っているテーマも1つ選べるようにしました。現在の選択肢は、AI活用、ブログ×AI、仕事・会社の業務効率化、パートナー・代理店の4種類です。
単に名簿を増やすのではなく、誰が何を求めて登録したのかを蓄積する。これにより、次に書く記事や配信内容を感覚だけで決めずに済みます。
AIにコードを書かせる前に、問題を分ける
今回、私自身がプログラムを理解してすべて書いたわけではありません。
AIには、エラー文、画面の状態、すでに確認したことを渡し、「次のコードを書いて」ではなく「原因を切り分けて」と頼みました。
- 現在の状態を記録する
- エラーをそのまま渡す
- 原因を切り分ける
- 危険な部分は専門サービスへ任せる
- 動いたかを実画面で確認する
この5つを守るだけでも、AIとの作業はかなり安定します。
作った仕組みそのものを、連続講座にする
今回構築したメルマガは、完成報告のためだけに作ったものではありません。この仕組み自体を使い、「環境構築 連続講座」を配信します。
- AIを使った記事作成
- WordPressサイトの高速化
- メルマガ配信環境の構築
- 登録フォームと解除処理
- 管理ダッシュボードと流入元計測
ENVIRONMENT BUILD SERIES
受け終わった後、同じ環境を
自分の手元で再現できるように。
記事作成から、サイト高速化、メルマガ、フォーム、CRMまで順番に配信します。
環境構築 連続講座を受け取る※Brevoの無料枠や各サービスの仕様は、2026年8月2日の確認時点です。将来変更される可能性があります。Xserverの利用料金は別途必要で、今回は既存契約を利用したため追加月額費用が0円でした。
TODAY’S AI DEMAND SIGNAL 2026.08.02 基準観測
今日、質問が増えそうなAIテーマ
本日は「検索数ランキング」ではなく、公式発表と本日適用の制度から需要の芽を観測しました。初回のため前日比はなく、明日以降の比較基準として保存します。
観測方法：Google Trends日本「急上昇中」の上位可視範囲ではAI語を確認できなかったため、検索量を推定せず、公式更新・期限・利用シェアを需要候補として編集しました。Geminiの数値は検索量ではなく、StatCounter由来の利用シェア参考値です。
参照：欧州委員会 ／ Anthropic ／ OpenAI Health ／ ChatGPT Release Notes ／ AI利用シェア参考
後書き
一番の学びは、技術そのものではありませんでした。問題を仕分ければ、コードを書けない人間でも、自分の資産を自分で持てる仕組みを組み立てられるということです。
一方で、実践ログや記事候補は増えているのに、「今日書く記事」まで迷わず選べる一元管理の仕組みはまだ十分ではありません。この記事も、本来は構築直後に公開すべき実践記でした。
うまくいかなかった画面、巻き戻した設定、抜けていた権限も消さずに残す。そして、実践中のメモ、画像、数値、改善点を公開可能な記事へ順番に変える「記事ストックの作業台」も次に整えます。
まずは、この仕組みに読者が増えていく過程を、管理画面の実数とともに検証していきます。
AIに任せれば、できることは増える。 けれど、正しく選べるとは限らない。
AI時代に必要なのは、AIに丸投げする力ではなく、AIが出した結果を判断できる最低限の基礎です。
活躍できる場所
AI活用と人間力が重なるほど、あなたにしか生み出せない価値の領域は広がっていきます。
AIトレンドロードマップを見る →※ 別タブで開きます。読み終えたらこの記事に戻れます。
この記事へのコメントはありません。