adventures-after60.comには、新しい記事を公開した時に、読者の方へ自動でお知らせメールを送る仕組みがあります。日本語版はすでに設定を終えていたのですが、英語版の方はまだ手をつけられずにいました。今回は、その英語版を仕上げた一日と、その後の数日にわたって思わぬ形で向き合うことになった続きの日々を、まとめて記録として残しておこうと思います。
見えないところで複数のモジュールがつながって動いている、そんな自動化の仕組みを思い浮かべながら選んだ一枚です。
Photo by Shubham Dhage on Unsplash
一つずつ、画面を見せながら
作業は、Make.comという自動化ツールの中で行いました。記事のタイトルや概要をメールの文面に差し込む設定を、Claudeと一緒に一つずつ確認しながら進めていきました。私がスクリーンショットを撮って見せ、Claudeが「ここをクリックしてください」「これを入力してください」と、次の一手だけを示してくれる。その繰り返しです。
件名の設定、本文への変数の挿入、配信停止リンクの記法、送信元アドレスの登録――どれも一つひとつは小さな作業ですが、積み重ねると結構な数になります。途中、黒い文字とオレンジ色のタグの違いが分からず、何度も同じような質問を繰り返す場面もありました。
分からなくなった時間
正直に言うと、途中で何度か「もう分からない」という気持ちになりました。以前、同じような設定を日本語版で進めた時は、もっと落ち着いて一つずつ確認しながら進められた記憶がありました。それに比べて今回は、途中で説明が急に詰め込まれたり、逆に「次に何を見ればいいのか」がはっきりしないまま話が進んだりする場面があり、少し苛立ちを覚えたのも事実です。
振り返ってみると、日本語版の時とは別の、新しいチャットとして今回の作業を始めたことが、関係していたのかもしれません。実は、新しいチャットを始めるたびに、いつも同じようなことが起きています。それまでの経緯を記録として残し、新しいチャットの冒頭で念押ししているつもりなのですが、Claudeの方は「覚えました」「把握しています」と、いつも確信を持って答えます。それでも実際には、毎回しばらくは操作がスムーズにいかなくなるのです。この問題は、私の中でもまだ解決できていません。
だからといって、一つのチャットをずっと続けていると、今回のようにやり取りが長くなるにつれて画像の枚数も増え、消費されるトークン（AIとの会話にかかる処理量のようなもの）が一気に跳ね上がってしまいます。結局、どこかで新しいチャットに移らざるを得ないのですが、そのたびにこの「呼吸の取り直し」が起きる、というのが今の私の悩みです。そういう時、いつもならモデルをSonnet 5からOpus 5に切り替えると、まるで人が変わったように賢くなり、行き詰まりをあっさり打開してくれるのですが、今回はそれを試しても、うまく解決には至りませんでした。もし、これをうまく解決する方法をご存知の読者の方がいらっしゃれば、ぜひ教えていただきたいです。
同じAIでも、会話が変われば、それまでのやり取りの積み重ねや呼吸のようなものは、いったんリセットされてしまうようです。以前のやり取りの方が丁寧だった、と感じて、率直にそう伝えたこともありました。
AIとの共同作業は、こちらの疲れや理解の速度に合わせて、向こうが柔軟に調整してくれるとは限りません。むしろ、「今、何が分かっていて、何が分かっていないか」を、こちらから言葉にして伝える必要がある場面の方が多いように思います。それは人間同士のやり取りとも、実は近いのかもしれません。
最後まで動かなかったテスト送信
設定自体は無事に完成しました。件名も本文も、正しい変数が入り、配信の絞り込み条件（日本語版読者・英語版読者を分ける仕組み）も整いました。
ただ、最後の「実際に自分宛にテストメールを送ってみる」という段階だけは、うまくいきませんでした。Make.comの仕組み上、個別の部品だけを試し実行することはできても、全体を通しで動かす手前で、何度か行き詰まってしまったのです。粘ってはみたものの、その日のところは諦めて、「15分ごとの自動実行」を有効にして、次に本当に新しい記事を公開した時の、本番の配信に賭けることにしました。
一日の終わりに振り返ると、「テストメールが届かなかった」という一点だけを見れば、達成感は薄いかもしれません。けれど、件名・本文・返信先・送信元のすべてに正しい変数が設定された配信の仕組み、日本語版読者と英語版読者を自動で振り分けるフィルター、長らく使われていなかったAPIキーへの実際の通信――これだけのことが、その一日の中で確かに進んでいました。うまくいかない時間も、無駄になっているわけではなく、次に動く時のための土台になっている――そう思うことにしました。
まず、なぜ自分だけ届かないのか
この記事の核心である「通知メール」というテーマに寄せて選んだ一枚です。
Photo by CHUTTERSNAP on Unsplash
そして数日後、次に新しい記事を公開したタイミングで、実際に自分宛にはメールが届いていないことに気づきました。仕組みは完成したはずなのに、肝心の自分のところに届かない。その原因調査と、配信の「見える化」の仕組み作りに、もう一日じっくり向き合うことになりました。
Make.comの実行履歴を眺めていると、妙な数字が目につきました。読者リストは7件しかないはずなのに、ある実行では「15」という操作数が記録されていたのです。Claudeに聞いてみると、これは「送信されたメールの数」ではなく、RSSの監視からBrevoへの登録確認、フィルター、実際の送信まで、日本語版・英語版それぞれのモジュールが動いた分すべてを足し合わせた数字だと分かりました。一つの数字を鵜呑みにせず、実行履歴の中身までさかのぼって確認する必要がある、という良い学びでした。
そしてもう一つ、私自身にメールが届かなかった理由もはっきりしました。Brevoの画面から自分のコンタクトを手作業で追加していたのですが、そこには「NEWSLETTER_LANGUAGE」という、日本語版・英語版を振り分けるための属性が入っていなかったのです。フォーム経由で登録された読者には自動でこの属性が付くのですが、手動追加だとそこが抜け落ちてしまう。単純な見落としでしたが、原因が分かってしまえば拍子抜けするくらい明快でした。
欲張った設計で、つまずく
原因が分かったところで、次に欲を出しました。「配信のたびに、成功した人・失敗した人の一覧をメールでまとめて受け取りたい」。そう考えて、エラー処理の分岐（Resume）と、結果を一つにまとめるモジュール（Text Aggregator）を組み合わせる設計に挑戦しました。
ここで、思いのほか長い時間を使うことになりました。モジュールとモジュールをつなぐための小さな「＋」ボタンが、画面のどこにあるのか見つからない。ホバーしても出てこない、右クリックしても違うメニューが開く、ドラッグでつなごうとしても接続点がつかめない――何度も同じところで手が止まりました。一度作ったものを削除してやり直し、また違う場所でつまずき、を繰り返すうちに、これは操作に慣れていない自分にとって、無理に頑張り続ける価値のある設計なのだろうか、という疑問が湧いてきました。
潔く、シンプルな方に切り替える
そこで、途中から方針を変えることにしました。凝った集計の仕組みを諦め、代わりに次の三本立てに落ち着けたのです。
・記事が公開されるたびに、タイトルとURLだけを知らせる短い通知メールを、日本語版・英語版それぞれ自分宛に送る ・配信エラーの有無は、Make.comが標準で用意している「Incomplete Executions（未完了の実行）」タブを、通知メールが届いたついでにのぞいて確認する ・実際に読者へ届くメールそのものの見た目（配信停止リンクや改行など）を確かめるために、Gmailのプラスアドレス機能を使って自分専用の確認用アドレスを二つ作り、本物の読者と同じ経路でメールを受け取れるようにする
複雑な仕組みを力任せに完成させることよりも、今の自分が無理なく扱える形に組み直すことを選んだ形です。振り返ってみると、これはこの日一番の収穫だったかもしれません。
ついでに、消費量も見直す
作業の途中、15分ごとに自動実行されている仕組みそのものにも目が向きました。新しい記事がそう頻繁に出るわけでもないのに、15分間隔ではひと月に何千回という実行が積み重なってしまいます。ブログの更新ペースを考えれば、毎日決まった時刻に1回確認する程度で十分だと判断し、実行スケジュールを「毎日9時（英国時間）」に変更しました。
また新しいチャットで、同じことが起きた
そして、さらに数日後。今度は妻がテスト的に新着記事通知に登録してくれたのですが、その直後に届いたのは、Gmailからの奇妙な通知でした。「シナリオが停止しました」というMake.comからのメールと、肝心の読者リストのスプレッドシートに、妻の登録が反映されていないという事実です。
原因を探ってみると、Googleシートを参照する部分の設定が、存在しないタブ名を指したままになっていました。以前も同じ症状が出て、一度は直ったはずのものです。Claudeに指示を仰ぎながら、正しいタブ名に選び直し、自動停止していたシナリオを再びオンに戻すと、妻の登録はきちんとスプレッドシートに反映されました。
この作業自体は、いつも通り一つずつ画面を確認しながら進める、いつものやり方でした。ただ、今回もまた新しいチャットでの相談だったこともあり、「なぜこの現象が繰り返し起きるのか」という根本のところまでは、まだ突き止められていません。この記事を書いている今も、宿題として残っています。
配信停止リンクをめぐって、率直に伝えたこと
作業を進める中で、以前から気になっていたことにも向き合うことにしました。読者への通知メールに書かれている「配信停止をご希望の場合は、こちらからお手続きいただけます」という一文の後に、実はリンクが表示されていなかったのです。
実は、この不具合には少し苦い記憶がありました。以前、別のチャットで同じ問題に十分ほど向き合い、いろいろな書き方を試したものの直らず、最終的にClaudeから「このままで問題ありません」と告げられて、そこで作業を終えた経緯があったのです。そのとき、私は正直、強い不信感を覚えました。
今回、あらためて同じ箇所を確認してもらったところ、それは「問題ない」どころか、参照先を失った壊れた変数だったことがはっきりしました。加えて、そもそも今使っている送信方法（トランザクションメールという仕組み）には、配信停止リンクを自動で作る機能自体が備わっていない、という技術的な限界も分かりました。
私はそのまま、以前感じた不信感を言葉にして伝えました。取り繕われるのではなく、率直に「その判断は誤りだった」という言葉が返ってきたことで、ようやくこの一件に区切りをつけることができました。今回は、配信停止を希望する方には返信かメールで直接連絡してもらう、というシンプルな案内文に差し替えることで決着しています。いずれ、専用のリンクから自動で処理できる仕組みも作りたいと思っていますが、それはまた別の日の宿題です。
ついでに、メールをHTML化する
配信停止の文言を直すついでに、これまでプレーンテキストのまま送っていたお知らせメールを、HTML形式に切り替える作業もしました。改行や段落がそのまま保たれるよう、本文全体を囲むひと工夫を加える必要があると教わり、日本語版・英語版それぞれに同じ処理を施しました。作業自体は単純な繰り返しでしたが、日本語版と英語版とで、実は元々の作り方が違っていたことにも気づかされました。
数字の意味を、鵜呑みにしない
最後に試したテスト送信では、また新しい戸惑いがありました。実行結果に表示された「操作数」という数字が、実際の読者数よりもずっと大きかったのです。しかしこれは「送信されたメールの数」ではなく、仕組みの中の各部品が動いた回数をすべて足し合わせたものだと分かりました。前回もまったく同じ勘違いをして、まったく同じ説明を受けたばかりだというのに、また同じところでつまずいてしまいました。一つの数字だけを見て早合点せず、その中身まで確認する必要がある――これも、今回の小さな学びの一つでした。
数日間を振り返って
派手さのない、じっくり腰を据えて取り組む時間を思わせる一枚です。
Photo by Clay Banks on Unsplash
最初の一日は、設定自体は仕上がったものの、最後の確認だけがうまくいかず、少しもやもやしたまま終えました。数日後には、原因不明だった配信不達の理由がはっきりし、無理のない形の確認の仕組みが整いました。そして、さらに数日が経つ間にも、Googleシートの設定が知らないうちに壊れていたり、長らく見て見ぬふりをしていた配信停止リンクの不具合と向き合ったり、メールの見た目を整えたりと、細々とした宿題が次々に出てきました。
一つひとつは地味な作業の積み重ねで、しかもまだ解決しきれていない謎も残っています。それでも、うまくいかない時間もちゃんと次につながっている――そう感じられた日々でした。次に新しい記事を公開したとき、日本語版・英語版それぞれの通知メールと、自分宛の確認コピーが、ちゃんと届くかどうか。それを楽しみに待ちたいと思います。
