📩 届く相手かどうか確かめずに送っていた——IG自動DMの宛先照合を12秒待ちに直した話

留守番電話の設定がない番号に、毎日メッセージを録音し続けていたとします。

画面には「録音完了」と表示される。でも、誰にも届かない。

声は出ている。操作は正しい。機械は正常に動いている。なのに、誰にも届かない。

あなたは今、こうなっていませんか？

• 自動DMをセットして、あとは「動いているはず」で任せきりにしている
• エラーが出ていないから、正しく届いていると思っている
• 相手がDMを受け取れる設定かどうか、確認したことがない
• 「送信ログに完了と書いてある」だけで安心している

先に結論を言います。DM開放していない相手への送信は、エラーにならないから、気づけません。

着地直後の1回判定をやめ、最大12秒・最大5回のリトライ照合に変えて、初めて確実にスキップできるようになりました。

この記事では、IGの自動DM送信を組んだときに起きた「届かない相手にも送り続けていた」という失敗と、最大12秒のリトライ照合に変えて解決した実話を書きます。

そもそも、なぜDM開放を確認していなかったのか

エラーが出なかったから

自動化の一番厄介な失敗は、「エラーが出ない失敗」です。送信処理は正常に完走している。

なのに、相手には何も届いていない。

この状態が一番タチが悪いのは、何かがおかしいと気づく手がかりがないことです。

ログを見ても「正常終了」と表示される。私はずっとそれを信じていました。

手動でDMを送っていたときは、相手の反応で確認ができました。

既読がつかない、返信がない、という状態から「あれ？」と気づけたのです。

自動化してからは、そのフィードバックが完全に切れていました。

「送った」という記録はあるが、「届いた」かどうかは分からない、という状態です。

IGのDM受信設定という「見えない壁」

IGには、DM受信を制限する設定があります。

「フォロワー以外からのメッセージは受け取らない」という設定で、多くのユーザーが使っています。

この設定をしている相手のことを、ここでは「DM開放していない相手」と呼びます。

開放していない相手には、いくら送信操作をしても、メッセージは届きません。

問題は、この設定が「相手にしか変えられないこと」です。

送る側には、相手がDMを受け取れるかどうかを事前に確認する方法がありません。

確認するためには、実際に送ろうとした瞬間の画面の状態を読むしかないのです。

この「瞬間の状態を読む」という部分が、今回の仕組みの核心でした。

IG自動DMの仕組みと、/direct/new/フローへの移行

もともとの組み方

最初に作った自動DM送信は、既存のスレッドを経由するフローでした。

すでにやりとりのある相手のスレッドを開いて、そこに送信する形です。

この方法は、受信設定の影響を受けにくいという利点がありました。

一度メッセージのやりとりが始まっている相手には、設定に関わらず届きやすいからです。

ただ、新規の相手——まだDMのやりとりがない人——への送信には対応できません。

新規の相手へ送る機会が増えてきたとき、新しいフローに切り替える必要が出てきました。

/direct/new/フローとは何か

IGには、宛先を直接入力してDMを送る機能があります。

そのためのURLが /direct/new/ の形をしていて、ここにアクセスすると新規DM作成の画面が開きます。

この画面で宛先のユーザー名を入力すると、候補リストが表示されます。

DM開放している相手なら候補に出てくる。開放していない相手には候補が出ない——。

この「候補が出るかどうか」を確認することで、送れる相手かどうかを判断しようとしました。

宛先を明示して新規DM送信を始める、この /direct/new/ 経由のフローに作り替えることにしました。

入力欄がオーバーレイに阻まれていた

/direct/new/ のフローに切り替えたとき、最初の壁にぶつかりました。

宛先を入力する欄が、画面上の「オーバーレイ」に覆われていて、クリックできないのです。

「オーバーレイ」とは、別の画面要素が上に乗っている状態のことです。

透明なガラスで押さえられているようなイメージです。

通常のクリック操作では、そのガラスの下にある入力欄に届きません。

この問題を解決するために、JavaScriptというプログラムを使って直接フォーカスを当て、キーボードで文字を入力する方法に変えました。

ITに詳しくない方に伝えるなら、「クリックでは届かないので、別のルートから入力した」というイメージです（笑）。

こうして入力欄への文字の送り込みは通るようになりました。

次の問題は、「この相手がDMを受け取れるかどうか」の判断でした。

そしてここで、本当の詰まりポイントが出てきます。

着地直後の「1回判定」では何が足りなかったか

どうやって受け取れるかを確認するか

/direct/new/ のページで宛先のユーザー名を入力したとき、候補リストが表示されるかどうかで判断しようとしていました。

DM開放している相手なら候補が出る。開放していない相手には候補が出ない。

そこで、ページに着地した直後に1回だけ候補の状態を確認して、候補が出なければスキップ——という設計を入れました。

シンプルな設計で、動いているように見えていました。

「まだ読み込み中」を「存在しない」と誤判定

しかし、ここに問題がありました。ページが完全に読み込まれる前に確認してしまうことがあったのです。

ページを開いてから、すべての要素が表示されるまでには時間がかかります。

その間に確認してしまうと、「候補リストがまだ出ていない状態」を「候補リストが出ない相手」と誤判断してしまいます。

たとえるなら、本屋さんが棚に商品を並べている最中に「この本はありません」と判断してしまうようなものです。

並べる前に確認しても、正しい答えは出ません。

このタイミングのズレは、通信の速さや端末の状態によって変わります。

安定しているときは問題ないのに、少し重いタイミングだと誤判定が起きる——という不安定な状態でした。

誤判定には2つの方向がある

誤判定には2つの方向がありました。1つ目は「届けられるのにスキップしてしまう」ことです。

DM開放している相手なのに、候補リストがまだ読み込まれていないだけなのに、スキップしてしまいます。

送れるのに送らない——という機会損失です。

2つ目は逆に「届かないのに送ってしまう」ことです。

こちらのほうが問題で、本来スキップすべき相手への送信が通ってしまいます。

どちらもエラーにはならないので、ログだけ見ていると気づきません。

最大12秒のリトライ照合に変えた話

解決の方向性

「1回の確認では足りないなら、複数回確認する」というのが解決の方向性でした。

着地直後だけでなく、時間をかけて繰り返し確認するリトライ方式に変えることにしました。

ページの読み込みには時間がかかることがある。

だとすれば、少し間を置いてから確認することで、読み込みが完了した状態を拾える——というアイデアです。

発想自体はシンプルです。

でも、その「何秒ごとに、何回まで確認するか」の設定が、実際にはかなり試行錯誤でした。

5回のリトライと、12秒という設定値

具体的には、ページに着地してから0秒・3秒・6秒・9秒・12秒の5つのタイミングで、宛先候補の状態を確認します。

どこかのタイミングで「DM開放していない」と確認できたら、その時点でスキップします。

12秒経っても候補が確認できなければ、スキップします。

どこかのタイミングで候補が出たら、送信に進みます。

この設計で、1人あたりの最長待機時間は12秒になります。

候補がすぐ出た場合は0秒か3秒で判断が出るので、全体の平均は12秒より短いです。

12秒という数字はどう決めたか

12秒は、試行錯誤で決めた数字です。5秒では、読み込みが遅い場合を拾えないことがありました。

20秒にすると、今度は1人あたりの処理時間が長くなりすぎました。

3秒ごとに確認して、最大12秒——というリズムが、実際の動作に一番合っていました。

この変更を入れてから、誤判定がほぼゼロになりました。

「ページが完全に読み込まれるまで待ってから1回確認する」より、「一定間隔で複数回確認する」ほうが安定することがある、ということです。

処理時間が増えることより、確実にスキップできることのほうが重要でした。

届かない相手への送信を続けることのほうが、時間的にも信頼的にもコストが大きいからです。

失敗談：気づかないまま送り続けた数日間

気づいたきっかけ

/direct/new/ フローに変えてから最初の数日間、私はこの問題に気づいていませんでした。

ログには「送信完了」と出ていたので、確認を怠っていたのです。

気づいたのは、テスト用に作ったDM非開放アカウントに送ってみたときです。

自分で「DM開放していない状態」にしたアカウントに向けて送信したとき、ログには正常終了と書いてある——。

「あ、これは気づけないわけだ」と思いました。

エラーが出ないから、外から見ていると何も気づけないのです。

数日間、続いていたということ

正直に書きますが、数日間は誤った状態のまま動いていました。

その間の何十回という送信処理の中に、届かない相手への送信が混ざっていた可能性があります。

ただ、何百回・何千回という規模ではなかったこと、送信先はすでに接点のある相手だったことで、実害は最小限だったと思います。

「かもしれない」の段階で修正できたのは、早めに自分でテストを入れていたおかげでした。

自動化は「間違いを続ける仕組み」にもなる

この経験で改めて感じたのは、自動化の両面性です。正しく動けば何十倍もの効率になる。

間違えたまま動けば、何十倍もの失敗になる。

手動でやっていたときは、相手の反応を見ながら都度調整できました。

自動化すると、そのフィードバックループが切れます。

エラーが出ないから止まらない。止まらないから、同じ間違いが積み重なる。

人間が1回やる失敗は1回で終わります。自動化すると、その1回が何十回・何百回と繰り返されます。

これが、自動化に向き合うときに一番気をつけていることです。

「動いている」と「正しく動いている」は、別のことなのです。

「送れた」と「届いた」は違う——自動化の落とし穴

「送信ログ」が作り出す錯覚

「送れた」と「届いた」は、違います。

これは当たり前のように聞こえますが、自動化するとこの2つが同じように見えてしまいます。

送信ログに「完了」と書いてあると、届いたと感じてしまいます。

でも「届いた」という情報は、そのログには書かれていません。

「送信処理が正常に完了した」という情報と、「相手の受信ボックスに届いた」という情報は、別物です。

この差を意識できるようになったのは、今回の失敗があったからです。

実際に届いたかどうかを確かめるためには、受け取る側の状態を確認するしかありません。

今回の「候補リストが出るかどうか」という確認は、それに近いことをしていました。

確認を「後から複数回」入れるという設計

今回の解決策は「送る前に全部把握する」ではありませんでした。

「送ろうとした瞬間に、何度か確かめる」という設計です。

送る前に全員の受信設定を事前調査する方法も考えられます。でも、IGの仕様は頻繁に変わります。

相手の設定もいつでも変更されます。

事前に把握した情報は、送信の瞬間には古くなっている可能性があります。

「今この瞬間、届けられるかどうか」を知るためには、その瞬間に確認するほうが確実なのです。

この考え方は、自動化全般に使えると思っています。

送る前に準備を整えるより、送ろうとしたときに確かめる——というアプローチです。

この仕組みの全体像——AIと会話しながら自律的な送信フローをどう組んでいるか——は、別のnoteにまとめています。

技術的な詳細や実際のフロー設計に興味があれば、読んでみてください。

非エンジニアとして、自動化に向き合ってきた話

コードは書けなくても、設計は必要

私はコードをほとんど書けません。今回のIG自動DMも、AIと会話しながら仕組みを作り上げました。

コード自体はAIが書きます。

でも、「どういう条件で送ってよくて、どういう条件でスキップするか」は自分で考える必要がありました。

この「条件の設計」こそが、仕組みの品質を決める部分です。

設計がなければ、AIも「とりあえず送り続ける機械」になってしまいます。

今回の失敗も、コードに問題があったわけではありません。

「1回だけ確認する」という設計が甘かった——それだけのことでした。

動かしながら直していく、というやり方

今回の12秒リトライも、最初から設計していたわけではありません。

「おかしい」と気づいてから、後から足した設計です。

最初から完璧な仕組みを作ろうとすると、動かすまでの時間がかかります。

私は「動かしてから直す」というやり方を選んでいます。

これは失敗する可能性を受け入れることでもあります。でも、動かさない限り、何が問題かは見えてきません。

「失敗したら直す」という前提のもとで動かし続けることで、今の仕組みができています。

今回の12秒リトライは、その中の1つの修正でした。

「届く相手だけに届ける」ために

配信の自動化で、一番大事にしたいことがあります。「届く相手だけに届ける」ということです。

届かない相手にも送り続けることは、相手の体験を悪くします。

それは効率化ではなく、迷惑の自動化になってしまいます。

今回の修正は、そのためのものでした。

エラーが出ないからこそ、自分で確認の仕組みを入れる——これが今回の一番大事な学びです。

まとめ

今回起きたことを数字で整理する

IGの自動DM送信で、DM開放していない相手への送信をそのまま続けていました。

着地直後の1回判定では間に合わず、最大12秒・最大5回のリトライ照合に変えて解決しました。

変更内容を整理すると、こうなります。

• 確認タイミング：0秒・3秒・6秒・9秒・12秒の5回
• リトライ間隔：3秒ごと
• 最大待機時間：12秒
• 気づいてから修正完了まで：数日
• 変更後の誤判定：ほぼゼロ

Lilyからひとこと

自動化は「間違いを自動でやり続ける仕組み」にもなります。

エラーが出ないからこそ、意図的に確認の仕組みを入れることが大事だと学びました。

「届く相手だけに届ける」という当たり前のことを、後から直すことになった実話でした。

同じような仕組みを作っている方のヒントに、少しでもなれば嬉しいです。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順