メールを送ったのに、相手に届いていなかった。そういうとき、普通は「このアドレスには届きませんでした」というお知らせが自分のところに返ってきます。宛先が存在しない、受信箱がいっぱいだ、といった内容です。
こんにちは。AIでDXを加速する専門家、ばんのです。
私のメルマガは、特定の1アドレスだけ、数日に1回どうも届いていない気配がありました。届いていないのなら、そのお知らせが返ってきているはずです。ところが私の手元には、1通も見当たりません。
第5回は、登録の途中で止まっている人への督促の話でした。第6回は、その先でメールが相手に届かなかったとき、それを誰がどう判断するかという話です。
結論から言うと、お知らせは返ってきていました。ただ、私が見ていない場所へ返っていました。そして場所を直したあとに待っていたのは、「見えるようになったお知らせを、機械に自動で処理させていいのか」という別の問題です。ここでもAIから確認が飛んできて、私が答える形で決まっていきました。
この記事を読むとわかること
- 届かなかったお知らせが、返信先ではない場所へ返っている理由
- 届かない宛先を放っておくと、届いている読者にまで影響が出る仕組み
- 自動で止める作りをやめた理由（偽のお知らせ1通で、誰でも止められた）
- 機械に任せる部分と、人が決める部分の線の引き方
届かなかったお知らせは、私が見ていない場所に返っていた
最初につまずいたのは、システムの中ではなく、メールそのものの仕組みでした。返信が来る場所と、届かなかったお知らせが返る場所は、別々に決まっています。
手紙で言うと、封筒と便箋は別物です
便箋に「ご返事はこちらへ」と書いておけば、返事はその住所に届きます。ですが宛先不明で戻ってくる封筒は、便箋の中身を読んでもらえません。封筒の差出人欄に書かれた住所へ戻ります。郵便局が見るのは封筒だけだからです。
メールもこれと同じです。私は読者からの返信を受け取る専用アドレスを用意して、そこへ返信が来るようにしていました。返信はきちんとそこへ届きます。ですが届かなかったお知らせのほうは、封筒側に書かれた別のアドレスへ返っていました。
▼
私が毎日見ているアドレス
▼
私が一度も開いていないアドレス
思い込んでいた場所と、実際に使われていた場所が違った
やっかいだったのは、その封筒側のアドレスがどこで決まっているかを、私が取り違えていたことです。管理画面の別の項目だろうと決めつけて、そこばかり眺めていました。実際に使われていたのは、送信元として設定したメールアドレスのほうです。
思い込んだ場所を見ている限り、設定を何度見比べても違和感は出てきません。原因が分からないときは、自分が見ている場所そのものを疑うしかない。今回はそれをAIに聞いて、ようやく別の項目にたどり着きました。
分けるのをやめて、1つのアドレスに揃えた
AIから返ってきた対処は単純でした。メルマガ専用のアドレスを1つ作り、送信元と受け取り用を同じアドレスに揃える。これは私が管理画面でやる作業です。どこに返っても同じ場所に集まるので、見落としようがありません。
用途ごとにアドレスを分けたくなる気持ちは分かります。ただ、分けるなら、どれがどの用途で使われるかを全部言えないといけません。私は言えませんでした。言えないうちは、揃えておくほうが安全です。
受け取れるようにしただけでは、かえって悪くなる
アドレスを揃えて、これで解決だと思いました。ところが今度は、私のシステムの側に問題があることが分かります。
拾ったのに捨てる、という動きになっていた
私のシステムは、受け取り用アドレスを定期的に見にいって、読者からの返信を管理画面へ取り込むようになっています。そして届かなかったお知らせを扱う機能は、1つも入っていませんでした。
結果どうなるか。返ってきたお知らせはシステムに拾われ、読者の返信ではないので何もされず、そのまま捨てられます。今までは誰も見ないアドレスに溜まっていたものが、今度は自分のシステムの中で消えていく。これは改善ではなく悪化です。
そこで、お知らせを読み取って管理画面に一覧として残す機能を、AIに書かせました。どのアドレスへの配達に失敗したのか、そして届かなかった理由は何か。この2つが並ぶだけの画面です。
届かない宛先を放っておくと、届いている読者にも届かなくなる
なぜここまでするのかも書いておきます。届かない宛先へ送り続けると、受信側のサーバーから「この送信者は宛先を管理していない」と見なされます。
そしてその評価は、宛先ごとではなく送信者に付きます。つまり、ちゃんと届いていた読者にまで届きにくくなるということです。1人の不達を放っておくと、全体が少しずつ削られていきます。
AIから「これは自動で止めていいのか」と聞かれた
ここからが、この回でいちばん書きたかった場面です。私が当たり前だと思って進めようとしたことに、AIが待ったをかけてきました。
私は自動で止めるつもりでいました
一覧に出るようになると、次は自動化したくなります。届かないアドレスなのだから、システムが勝手に配信を止めてくれればいい。最初は迷いもなくそのつもりでした。
ここで、検査役として動かしているAIから確認が入りました。「この作りだと、まったく関係のない人が他人の配信を止められます。それでいいですか」。
示されたのは、他人が押せる停止ボタンでした
理由はこうです。届いたメールが本物のお知らせかどうかを、システムは差出人と件名の書き方で見分けています。機械が出すお知らせは決まった書き方をするので、それで判別できます。ところが差出人も件名も、誰でも自由に書けます。そして受け取り用のアドレスは、返信先として全読者に公開されています。
これは第3回で書いた話と同じ形です。差出人欄は、封筒の裏に手書きされた名前でしかありません。あのときは返信を読者と結びつける場面でしたが、今回は配信を止める場面です。同じ材料を、はるかに重い判断に使おうとしていました。
記録するのはシステム、止めるかどうかは私
説明を聞いて、AIが書きかけていた自動停止は、まるごと捨てさせました。捨てると決めたのは私です。システムがやるのは記録までです。止めるかどうかは、私が画面で見てボタンを押したときにだけ実行されます。
あわせて、一覧の画面には「この情報は確認が取れていません」と表示を入れさせました。判断する人が、材料の性質を知らないままボタンを押すのを防ぐためです。
| 役割 | 担当 |
|---|---|
| お知らせを拾って読み取る | システム（自動） |
| 一覧に並べて、記録として残す | システム（自動） |
| この宛先への配信を止める | 私（手動・ボタン） |
そのボタンで、別の人を止めるところだった
人が押すことにしたので安全になったかというと、そうでもありませんでした。次の不具合は、そのボタン自体にありました。これは検査役のAIではなく、私が画面を眺めていて気づいたものです。
3番目を止めたつもりが、3番目ではない
AIが最初に書いた画面では、押されたボタンが一覧の何番目かだけで相手を決めていました。3番目のボタンが押されたら、一覧の3番目を止める。画面が上がってきた時点では、これで何も問題なく見えます。
ですが、この一覧は定期的に書き換わります。新しいお知らせが届けば下に足され、件数の上限を超えれば古いものから消えます。私が画面を開いてコーヒーを淹れている間に、並びが変わるわけです。
▼
その間に一覧が入れ替わる
▼
押した瞬間の3番目：Bさん
▼
Bさんの配信が止まる（画面には正常に完了と出る）
▼
その間に一覧が入れ替わる
▼
押した相手と、その位置の相手を照合
▼
一致しないので何もしない（最新の一覧を出し直す）
この不具合は、私が画面を眺めていて気づいた
気づいたきっかけは単純です。一覧の下のほうに新しい行が増えるのを見ていて、では上から数えた番号は何を指しているのか、と引っかかりました。コードを読んだわけではありません。画面の動きを見ていて、おかしいと思っただけです。
そう伝えたら、AIから直し方が返ってきました。画面の側にも相手を持たせておき、押されたときにその位置の相手と一致するかを確かめる。一致しなければ何もせず、最新の一覧を出し直します。
順番ではなく、相手そのものを指す
これは第5回で書いた「選び出してから実行するまでの間に、状況が変わる」と同じ構図です。あちらは数分、こちらは人が画面を眺めている数十秒。時間の長さが違うだけで、起きることは変わりません。
一覧の何番目という指定は、コードを書く側にとっていちばん簡単な方法です。ただ、その番号は時間が経てば別の意味になります。順番ではなく、相手そのものを指し示す。この考え方は、他の画面にもそのまま使えます。
結局のところ、見えるようにしただけです
ここまでやって、最初の症状は解決したのか。正直に言うと、まだ解決していません。
「もう届かない」と「今回だけ届かなかった」は別
届かない理由には、大きく2種類あります。アドレスそのものが無くなっていて、二度と届かないもの。受信箱がいっぱい、相手のサーバーが一時的に不調など、後で届くかもしれないもの。この2つは、返ってきたお知らせを見れば区別がつきます。
| 種類 | 例 | 扱い |
|---|---|---|
| もう届かない | アドレスが存在しない・廃止された | 配信を止める判断に使える |
| 今回は届かなかった | 受信箱が満杯・相手側の一時的な不調 | 止めると取りこぼしになる |
何回で止めるかは、まだ決めていません
私が困っていた「数日に1回だけ届かない」という症状は、後者である可能性が高いと考えています。この場合、何回続いたら止めるのかという線引きが必要になります。
その回数は決めていません。実際のお知らせが何日おきに、どの種類で来るのかを見てから決めるつもりです。今の段階でそれらしい数字を入れても、根拠が「何となく」になります。
ですから今回の成果は、判断を自動化したことではなく、判断するための材料が画面に出るようになったことです。地味ですが、材料のない状態で決めた基準よりは、はるかにましだと思っています。
よくある質問
同じような場面で疑問になりやすいところを、4つに絞ってまとめておきます。既製のサービスを使っている方にも、確かめる価値のある項目です。
Q1. 既製のサービスなら、この処理は自動でやってくれますよね
やってくれます。届かない宛先の判定と配信停止は、既製のメール配信サービスが確実に持っている機能です。自作でここまで用意するのは、AIに書かせるとしても指示と確認の往復が多い部分でした。
ただし、既製のサービスを使っていても、何回の不達で止まる設定になっているかは知っておく価値があります。読者が減っていて理由が分からないとき、真っ先に見る場所になります。
Q2. 届かない宛先が数件あるくらい、放っておいてはいけませんか
数件なら、すぐに実害が出るわけではありません。問題は、それが増えても気づけないことです。
法人向けに配信していると、退職や部署異動でアドレスが消えていきます。名簿に残ったまま、届かない宛先が少しずつ増える。ある時点から全体の到達率が落ち始めますが、そのときには原因が分かりにくくなっています。定期的に見る仕掛けを持っておくほうが安全です。
Q3. 自動化しないと、手間が増えるだけでは
増えます。ただ、私は自動化するかどうかの基準を「間違えたときに戻せるか」に置いています。
配信を止めるのは、間違えても画面上は何も起きない操作です。止められた読者から苦情も来ません。届かなくなったことに、こちらも相手も気づかないまま終わります。この性質のものは、件数が少ないうちは人が押すほうがいい。件数が増えて手に負えなくなったら、そのとき自動化を考えます。
Q4. 自分のところで確かめるとしたら、何から見ますか
届かなかったお知らせが、どこへ返っているかです。管理画面の設定で「送信元アドレス」を確認し、そのアドレスの受信箱を実際に開いてみてください。誰も見ていない受信箱に、機械からのお知らせが溜まっていることがあります。
私の場合は、存在しないアドレス宛にテスト送信を1通して、お知らせが想定どおりの場所へ返り、システムに記録されるところまで確かめました。この確認は数分で終わります。
ばんのの視点：自動化の線は、取り返しがつくかどうかで引く
今回は、自動でできることをわざと自動にしませんでした。AIに指示すればすぐ書き上がるのに、書かせないという判断です。
間違いが表に出るかどうかで分かれる
決め手になったのは、間違えたときの戻り方でした。誤って止めた読者は、こちらに文句を言ってきません。届かないことに気づかないからです。つまり、間違いが表に出ない。表に出ない間違いは、いつまでも直りません。
この見方は、業務の自動化でもそのまま使えます。自動化を検討するとき、多くの場合は精度の話になります。何パーセント当たるか。ですが同じくらい大事なのは、外れたときにそれが誰かの目に入るかどうかです。
請求書の金額を間違えれば、相手から連絡が来ます。この種のものは自動化しても、間違いが表に出るので直せます。一方、対象から誰かを外す処理は、外された側から連絡が来ません。同じ精度でも、性質がまったく違います。
決めるのは私、確かめるのはAI
今回の流れを振り返ると、危ないところではすべてAIのほうから確認が飛んできました。「届かなかったお知らせに見せかけたメールを送れば、他人の配信を止められます。それでいいですか」。「この一覧に出ている情報は、本物かどうか確かめられていません。そのまま表示しますか」。私はこの2つに、読者から見てどうかという基準で答えただけです。
コードは1行も書いていません。それでも、どこを自分の目で見るかは自分で決められます。既製品なら初期設定に従うところでした。面倒には違いないのですが、想像していたより気持ちの良いものです。
次回予告
第7回は、作ってあった機能を丸ごと消した話です。
配信内容を2パターン用意して成績を比べる機能を、以前にAIへ書かせてありました。それなりの分量で、動いてもいました。ただ、後から似た仕組みを別の場所にもAIへ作らせたので、2つが並んで残る形になっていました。
普通なら、共通化して1つにまとめます。私は、AIに書かせた片方を、まとめずに削除しました。なぜまとめずに消したのか、そして消すときに何を確かめたのかをお話しします。
