今日、転職エージェントの方と話す機会がありました。これまで作ってきたものをひととおり説明したのですが、いちばん食いついてもらえたのは、意外な部分でした。アプリの数でも、使っている技術でもなく、「ニュースレターを、相手によって送り分けられるようにした」という話です。今日はその機能について、どういう考えで作って、どこで一度つまずいたのかを書いてみます。結論から言うと、この機能でいちばん時間をかけたのは送る部分ではなく、間違って送らないための仕組みでした。
全員に同じものを送るしかなかった状態
前提として、私は自分でニュースレターの配信システムを作って運用しています。Google Apps Script(グーグル・アップス・スクリプト。以下GAS)というGoogleのサービス上で動く仕組みと、スプレッドシートを組み合わせたものです。作った経緯は非エンジニアが配信ツールを自作した話に書きました。
この仕組みには一つ、ずっと引っかかっていた制約がありました。登録してくれた人、全員に同じものしか送れなかったのです。仕組みとしては、購読者を全員Googleグループに入れておいて、そのグループ宛に1通送れば全員に届く、という作りでした。手軽ですし、何千人いても1通で済むので効率は良いです。
ただ、購読者の入り口はひとつではありません。Webのフォームから自分で登録してくれた方もいれば、名刺交換をきっかけに登録した方、ウェビナーに参加して「メールを受け取ってもいい」と意思表示してくれた方もいます。この人たちに、まったく同じ内容を送り続けるのは、正直もったいないなと思っていました。
たとえばウェビナーに参加してくれた方に、次回の案内を送りたい。でも全員に送るのは違う。そういう「この人たちにだけ届けたい」が、これまでは実現できませんでした。
セグメント配信を足しました
そこで、セグメント配信という機能を追加しました。セグメントとは、購読者をいくつかのグループに分けるための区分のことです。今は次の3つを用意しています。
- フォーム登録
- 名刺交換による登録
- ウェビナー参加でのオプトイン
やり方はとてもシンプルで、購読者一覧のスプレッドシートにセグメントの列を作り、そこに区分を入力しておくだけです。入力欄はプルダウン(選択式のメニュー)にしてあるので、毎回手で打ち込む必要はありません。あとは配信の管理画面でセグメントを選べば、その区分の人にだけメールが届きます。
この「スプレッドシートに日本語で入力する」という形にたどり着くまでに、実は一度やり直しがありました。そこは後で書きます。
全体配信とセグメント配信は、送り方の仕組みが違います
ここは作ってみて初めて分かった部分でした。全体配信とセグメント配信では、そもそもメールの送り方を変える必要があったんです。
全体配信はこれまでどおり、Googleグループ宛に1通です。何人いても1通なので、送信の負荷はほぼありません。
一方セグメント配信は、条件に合う人を1人ずつ選んで送ることになるので、人数分のメールを個別に送ることになります。ここに2つの壁がありました。
1つ目は、GASには「1回の実行は6分まで」という制限があることです。何百通も一度に送ろうとすると、途中で強制終了してしまいます。そこで、1回の実行で送るのは100件までにして、続きは自動的に次の回に持ち越す作りにしました。裏側では送信の進み具合をシートに記録しておいて、時間が来たら続きから再開します。
2つ目は、1日に送れるメールの数に上限があることです。私が使っているGoogle Workspaceでは1日1,500通が上限なので、システム側の目安を1,400通に設定して、余裕を持たせています。上限にぶつかると、その日はもう何も送れなくなってしまうためです。
「送り分けたい」という要望は一言ですが、実際に作ると、送信の設計そのものを変える話になるんだなと実感しました。
いちばん時間をかけたのは、間違って送らない仕組みでした
この機能を作るとき、私が最初にAIに伝えた心配ごとは「実験中に、間違ってセグメント分けした人に送ってしまうこと」でした。稼働中のシステムに手を入れるので、テストのつもりで送ったメールが本物の購読者に飛んでしまうのがいちばん怖かったんです。
そこで入れたのが、安全モード(SAFE_MODE)という関門です。この設定がオンのあいだは、あらかじめ許可した自分のアドレス以外に送ろうとすると、送信が止まります。
ここで一つ、設計上こだわった点があります。それは「静かに飛ばす」のではなく「エラーで止める」にしたことです。許可されていない宛先を黙ってスキップする作りにすると、こちらは送ったつもりで先に進んでしまい、後から「あれ、届いていない」と気づくことになります。それなら、その場ではっきり止まって、画面に理由が出たほうが安全です。
もう一つ工夫したのが、本番配信のときの解除の仕方です。安全モードは管理画面から一時的に解除できるのですが、解除は時間制にしました。既定で30分、最長でも2時間で、自動的に安全な状態に戻ります。「解除したまま忘れる」が起きないようにするためです。私は絶対に忘れる自信があったので、ここは自分を信用しない作りにしました。
ちなみに、この安全モードは読者への自動返信(登録完了メールや配信停止の完了メール)には掛けていません。掛けてしまうと、実際に登録してくれた方への返信まで止まってしまうからです。自作の配信ツールでセキュリティの穴を公開直前に見つけた話のときも思いましたが、安全のための仕組みが、正常な動きまで止めてしまっては本末転倒なんですよね。
コードの安全装置とは別に、運用側でも保険をかけました
安全モードはプログラム側の仕組みですが、それとは別に、運用の工夫でもう一枚保険をかけています。実験用のセグメントと、本番用のセグメントを分けるというやり方です。
具体的には、動作を試すときは自分のアドレスだけが入った実験用のセグメントを指定します。こうしておけば、仮に安全モードを解除した状態でうっかりボタンを押しても、届く先は自分だけです。プログラムが正しく動くかどうかとは無関係に成立する防御なので、コード側の仕組みが何かの拍子に効かなくても、被害が外に出ません。
この発想は、稼働中のシステムに手を入れるのが怖い、という気持ちから出てきました。すでに実際の読者が登録してくれている状態で機能を足すわけなので、「壊さないように慎重に作る」だけでは不安が消えないんです。それより、間違えても外に出ない環境で試せるほうが、精神的にずっと楽でした。
実際に作ってみて思ったのは、安全対策には層があるということです。プログラムが止めてくれる層と、そもそも危ないものに触らない層。前者はAIに作ってもらえますが、後者は自分の運用を分かっている人にしか設計できません。ここは非エンジニアでも十分に貢献できる部分だと思います。
もう一つ、作業中に見つかったのが、以前書いた古い関数がそのまま残っていたことでした。実行すると購読者全員に即座にメールが飛ぶもので、しかも件名が書きかけのままでした。開発画面から手動で関数を選んで実行できる状態だったので、選び間違えたら一発で事故です。ここにもガードを入れてもらいました。古い自動化を運用し続けるときは、使っていない機能が残っていないかも見ておいたほうがいいなと反省しました。
AIが「webinar-202609」と名付けようとした話
作っている途中で、一度やり直した場面があります。ここが個人的にはいちばんの学びでした。
AIに実装を進めてもらっていたのですが、途中で画面を見たら、購読者に付ける区分の名前が webinar-202609 のような半角英数字になっていました。しかも、それ以外の文字は入力できないようにする仕組みまで入っていました。
私はここで「タグがわからない」と伝えました。私のイメージはもっと素朴で、セグメントの列を作って、そこに「ウェビナーお知らせ」や「営業案内OK」と日本語で入力して、その名前を管理画面で選ぶ、というものだったからです。
理由を聞いてみると、将来フォームのURLに区分を埋め込む構想があるから、URLに載せても安全な英数字にしておいた、とのことでした。理屈は通っています。ただ、その日の作業では公開フォームには一切触らないと決めていたので、URLに載る場面はそもそも存在しませんでした。
つまり、まだ来ていない将来の制約のために、今日使う私の使いやすさが先に削られていた、ということです。実際にスプレッドシートを開いて手で入力するのは私なので、webinar-202609 と並んでいても何のことか分かりません。管理画面のプルダウンに並ぶ言葉も、日本語であってほしい。
もう一つ気づいたのは、言葉のズレです。AIはずっと「タグ」と呼んでいて、私はずっと「セグメント」と言っていました。同じものを指しているのに、呼び方が違うまま進んでいたんです。完成した画面に見慣れない言葉が並んでいたのは、そのせいでした。
この2つは、どちらもAIの指示書の設計について書いた回で書いたことと地続きだなと思います。違和感を覚えた時点で「その言葉が分からない」と言うのがいちばん早い。遠慮して流すと、そのまま完成してしまいます。
転職エージェントの方が興味を持ったのは、たぶんここでした
冒頭に書いたとおり、今日いちばん反応があったのがこの機能でした。話しながら、なぜだろうと考えていたのですが、おそらく「作れること」ではなく「誰に何を届けるかを設計できること」に見えたのだと思います。
セグメント配信は、技術的にはそこまで複雑ではありません。ただ、この機能を作るには、購読者がどういう経路で入ってきたのかを把握していて、その人たちに何を届けるべきかを考えている必要があります。名刺交換で登録した人と、自分でフォームから登録した人では、こちらへの温度がまったく違いますから。
そして誤送信の防止まで作り込むと、「実際に人に届くものを運用している」という前提が伝わります。個人開発でよくある「作って終わり」ではなく、送ったら取り消せないものを毎回扱っている感覚のほうが、たぶん評価されたのだと思います。
私自身、この機能を作ってから、ニュースレターを「配るもの」ではなく「届け先を選ぶもの」として考えるようになりました。全員に同じものを送っていたころは、内容を無難な方向に寄せがちだったのですが、相手を絞れると書けることが増えます。
まとめ:送る機能より、送らない仕組みに時間をかけました
ニュースレターをセグメントごとに送り分けられるようにした話を書いてきました。振り返ると、実装でいちばん頭を使ったのは「どう送るか」ではなく「どうすれば間違って送らないか」でした。メールは送信ボタンを押した瞬間に取り消せません。だからこそ、止める仕組みのほうに時間をかける価値があります。
そして、AIに任せきりにしないことも学びました。私が「タグがわからない」と言わなければ、あの英数字の区分のまま完成していたはずです。使うのは自分なので、違和感を持ったらその場で言う。これはコードが書けるかどうかとは関係のない話だと思います。
このブログでは、AIと一緒に何かを作ってうまくいったこと、うまくいかなかったことをそのまま書いています。よかったらX(旧Twitter)やInstagramのフォローで、ゆるっとのぞいてもらえたら嬉しいです。「うちはこう分けている」という配信の工夫があれば、ぜひ教えてください。
コメント