片方は「自分が取りに行く」と思い、もう片方も「自分が行く」と考えて動いていました。
テーブルに届いたのは、注文していない2皿目のパスタでした。お客さんは困惑しています。
スタッフはどちらも悪くないのに。
あなたは今、こうなっていませんか？
- 自動返信やメッセージ送信の仕組みを、2本以上つなげてある
- 「どこかで重複が出ていないかな」と感じながら、まだ確かめていない
- 新しい仕組みを1本追加するたびに、なんとなく不安になる
先に結論を言います。
送る直前に「直近6時間以内に同じ相手へ送っていないか」を確認する1ルールを挟めば、二重送信は止まります。
この記事では、公式LINEの自動送信で実際に二重送信が起きた経験と、1つのルールでどう解決したかを書きます。 技術的な難しい話ではなく、「自動化の仕組みが2本以上になった時に、最初に壊れる場所」の話です。
仕組みが1本だった頃のこと
シンプルな1本には、崩れようのない強さがある
公式LINEへの登録者に、自動でメッセージを送る仕組みを作りました。
登録から数分以内に届く、短い歓迎メッセージです。
「登録ありがとうございます」という内容で、特に複雑なことはしていません。
1本の仕組みが、1つのタイミングで、1つの内容を送るだけです。
この状態では、トラブルが起きる余地はほとんどありません。
「かぶる仕組みが存在しない」ので、かぶりようがないからです。
1本の仕組みには、「他の何かとぶつかる可能性がゼロ」という強さがあります。
複雑さがないから、複雑さからくるトラブルも起きない。
これは後から気づいたことです。
この頃は「シンプルだからうまくいっている」とは、まったく意識していませんでした。
仕組みが1本ある状態は、運用としても確認としても、とても楽でした。
送信の記録を見れば、その日の動きがすべてわかります。
「ここが動いた」「ここが止まった」を判断する対象が1つしかないからです。
問題が起きても、調べる場所は1箇所で済みます。
ログを週に一度ざっと見るだけで、異常があればすぐにわかりました。
確認の習慣として、ほとんど手間がかかりませんでした。
「仕組みが動いているかどうかわからなくなる」という状態を、まだ体験していない頃の話です。
2本目を足した時の判断
しばらく運用していると、「もう少し丁寧にフォローしたい」と思い始めました。
登録直後の歓迎メッセージとは別に、3日後にも追加のメッセージを送りたくなったんです。
内容は別物です。タイミングも3日後です。
登録直後の仕組みとは「独立している」と判断しました。
「独立しているなら、かぶらない」という結論に飛んだのが、少し早かったと思います。
独立していることと、重複しないことは、必ずしも同じではないからです。
でも当時は、そこまで考えていませんでした。
「別のメッセージ、別のタイミング。問題ない」という判断で、2本目を動かし始めました。
2本が共存している状態になっても、特別に不安ではありませんでした。
「それぞれが独立して動くなら、互いに影響しないはず」という前提があったからです。
この前提が、後で崩れることになります。
仕組みの「独立性」は、1本だけの時は自然に満たされます。
でも2本になった瞬間に、独立性を意識的に守る何かが必要になる。
この違いに、当時の自分は気づいていませんでした。
📕 この記事の内容を、実装まで全部まとめた有料記事があります
手順・コード・テンプレをそのまま渡しています
AIで「寝てても回る仕組み」を30日で組む全手順｜コード不要・特典40ファイル・毎月更新
「2通届きました」と言われた朝
連絡が来た瞬間のこと
ある朝、登録者の方から連絡が来ました。
「同じメッセージが2通届いているのですが…」という内容でした。
最初に読んだ時、正直「えっ？」となりました。
2本の仕組みは、内容もタイミングも違うはずだったからです。
「同じメッセージ」という表現を見て、最初は誤読だと思いました。
もう一度読み返しましたが、やはり「同じ内容が2通」と書いてありました。
確認してみると、確かに同じ文面が2通、ほぼ同じ時刻に届いていました。
「2本は別々だから大丈夫」という前提が、そこで一気に崩れた気がしました。
まず謝罪の連絡をして、それから原因を調べ始めました。
「どういう状況で起きたのか」がわかる前に謝罪するのは、何とも言えない気持ちでした。
謝っている内容が正確かどうかもわからない。でも、放置はできません。
「確認中です」という一言を添えながら、とにかく送りました。
謝罪の連絡を入れた後、すぐにログを確認する作業に移りました。
「原因がわかれば、再発を防げる」という気持ちだけで動いていました。
「またいつ起きるかわからない」という不安の方が、原因不明の不快感より大きかったです。
「どちらも正しく動いている」という壁
「どちらかの仕組みにバグがあるはず」と思い、調べ始めました。
1本目のログを確認して、2本目のログを確認して、を繰り返しました。
でも、どちらも正しく動いていました。
エラーも出ていない。条件の判定も正しく行われていた。
これが、一番しんどかったです。
どちらも正しいのに、結果として二重送信になっている。
「何かがおかしい」とわかっているのに、「どこが」がわからない。
普通のバグ探しとは違う種類の難しさがありました。
バグならエラーが出るか、おかしな挙動が記録されるはずです。
でも今回は、どこにもそういった記録がありませんでした。
各仕組みは「自分の仕事だけ」を正しくこなしていました。
でも「自分以外との関係」は、誰も見ていなかったんです。
「条件の設定を間違えたのか」「タイミングの計算が誤っているのか」と、思い当たる箇所を一つずつ確認しました。
でも、どこも問題ありませんでした。
確認を始めてから数時間後、ようやく原因がわかりました。
「2本の仕組みが、ほぼ同じタイミングで、同じ人への送信を開始した」という、それだけのことでした。
それぞれは正しく動いている。でも2本が同時に走ると、同じ相手に2通届く。
「単体で正しい」と「複数になっても問題ない」は、別の話だったんです。
この事実に気づいた時の感覚は、今でも覚えています。
「正しい」の意味が、自分が思っていたより狭かったということでした。
1本1本の「正しさ」は検証できていたけれど、2本が同時に動く状況を想定していなかった。
検証の範囲が、仕組みの数と合っていなかったんです。
「片方を修正すれば終わり」という誤解
条件を調整した後の安心感
原因がわかってから、「1本目の送信条件を調整すれば解決できる」と考えました。
重なりにくいように条件を少し変えて、問題が起きないようにしました。
その後、しばらくは問題が起きませんでした。「直った！」と思いました。
あの時の安心感は、今でも覚えています。
「やっぱり条件を調整すれば大丈夫だった」と、そう信じていました。
数日経っても問題なし。1週間経っても問題なし。
「完全に解決できた」という確信が、徐々に生まれていました。
気持ちとしては、かなりすっきりしていました。
「原因を特定して、適切な対応をした。終わり」という感覚です。
この確信が、少し危険な状態だったと今は思います。
「解決した」という感覚が、問題の構造を深く見ることを妨げていました。
問題が起きていない期間は、問題が解決した証拠にはなりません。
ただ「その条件では起きにくくなった」というだけのことでした。
でも、その時の自分にはそれが見えていませんでした。
条件を変えることで、特定のパターンを避けることはできます。
でも「特定のパターンを避けた」だけでは、別のパターンが出る余地は残ったままです。
今回の問題の根は「条件の中身」ではなく、「2本の仕組みが同じ相手に送ることを誰も確認していない」という構造にありました。
この部分は、条件を変えても何も変わっていませんでした。
2週間後の再発
でも2週間後、また別のパターンで同じことが起きました。
今度は違う人に、前回とは少し違う条件で2通届いていました。
条件を変えたことで、前のパターンは防げていた。
でも、変えた条件が新しい別のケースを生んでいました。
「直した」ではなく、「ずらした」だけだったんです。
問題のある構造はそのままで、症状だけを一時的に回避したに過ぎませんでした。
同じ失敗を2週間で2回したことは、今でも深く反省しています。
どちらも相手に謝罪する状況になりました。
謝罪の言葉は、1回目より2回目の方がずっと重かったです。
「また起きてしまいました」という状況を説明するのは、本当に難しかったです。
「直したはずなのに」という気持ちと、「直っていなかった」という現実のギャップが辛かったです。
2回目の再発で、ようやく気づきました。
「条件を個別に調整し続けるアプローチには、根本的な限界がある」ということに。
仕組みが2本あれば、2本の相性を管理しないといけない。
3本になれば、3本それぞれの組み合わせすべてを考えないといけない。
仕組みが増えるたびに管理コストが増えていく構造は、いずれ限界を迎えます。
それがはっきり見えた瞬間でした。
「何かが起きるたびに条件を調整する」という運用を続けることは、長期的に無理だとわかりました。
条件の修正ではなく、構造の見直しが必要でした。
根本を変えた「出口の1確認」
シンプルすぎた解決策
「構造そのものを変えるしかない」と思い、しばらく考えました。
「複数の仕組みが共存していても、重複が起きない状態にするには？」という問いです。
たどり着いた答えは、シンプルすぎて最初は「これだけ？」と思いました。
送る直前に「直近6時間以内に同じ相手へ送っていないか」を確認する。
送っていたら、今回は送らない。
以上です。
各仕組みの中身を変えるのではなく、送信の直前に確認を1つ挟む。
どの仕組みから送信が来ようとも、最後に必ず1回この確認が入ります。
「こんなにシンプルで本当に効くのか」と思いながら実装しました。
でも、これが一番確実に効く方法でした。
シンプルさには理由がありました。
確認する場所を1つに絞れば、管理するものも1つで済みます。
複数の仕組みを個別に調整する代わりに、全体を通る1箇所だけを厚くする。
これが「構造を変える」ということの正体でした。
「6時間」という数字は、送信の用途とタイミングのパターンを踏まえて決めました。
短すぎると、立て続けに送るべき場面でもブロックされてしまいます。
長すぎると、本当に必要なメッセージが届かなくなる可能性が出てきます。
「何時間にすべきか」は、仕組みが何を目的に動いているかによって変わります。
判断の仕方については、有料記事の方で詳しく書いています。
「入口」ではなく「出口」で止める
このルールが強い理由は、「出口」で確認するからです。
各仕組みの中（入口側）で条件を調整しようとすると、仕組みの本数が増えるほど管理が難しくなります。
でも、送信の出口は常に1つです。
イメージとしては、複数の廊下から人が集まってくる出口を思い浮かべてください。
廊下が2本でも5本でも、最終的に人が通るのは同じ出口です。
その出口に「直近6時間以内に同じ人が通っていないか」を確認する係を1人置く。
どの廊下から来たかは関係ない。
出口で確認するから、どのパターンでも重複が起きません。
このルールを入れてから、二重送信はゼロになりました。
出口に番人を1人置くだけで、これだけ変わります。
複雑な仕組みを全部書き換えたわけではありません。
確認の場所を変えただけで、問題全体が解消されました。
「入口」にこだわって管理しようとすることと、「出口」を一本化することの違いは、仕組みが増えた時に大きく現れます。
入口がいくら増えても、出口は1つのままです。
そこに確認を置くことの強さは、仕組みが増えるほど大きくなります。
「続けて送りたい時」の例外はどうするか
一つだけ問題になったのが、「意図して短時間に2回送りたい場合」です。
緊急の告知など、あえて1時間以内に同じ人に2通送らないといけない場面があります。
6時間のルールに引っかかってしまいます。
この問題は、「明示的に許可した場合だけ例外を通す」という形で解決しました。
基本は止める。「今回は送ってよい」と明示した場合だけ、ルールを通過できます。
「例外があるなら、また重複するのでは？」と思うかもしれません。
でも例外は「明示的に許可した場合だけ」に限定しているので、うっかり重複することはありません。
意図しない重複を防ぐのがルールの目的です。
意図した送信は、明示的に許可してから行う。
この区別を保つことで、ルールが崩れません。
例外の仕組み自体が「意識してやっている」という記録になるので、振り返りにも役立ちます。
「なぜこの時間帯に2通送ったのか」が後から追えるようになりました。
「ルールを設けることで、例外が見えやすくなる」という副次効果は、最初は想定していなかったメリットでした。
入口ではなく出口で止める発想
仕組みが増えると、入口管理は追いつかなくなる
自動化の仕組みを複数持っていると、それぞれの「条件」や「タイミング」を個別に管理する必要が出てきます。
2本なら2倍の確認。4本になれば4倍です。
でも仕組みは、運用していれば増えていくものです。
半年後に5本、1年後に6本になっているかもしれない。
入口をすべて把握し続けることは、仕組みが増えるほど現実的に難しくなります。
「仕組みを増やすたびに不安になる」のは、入口管理の限界が見え始めているサインです。
今思えば、あの「なんとなく怖い」という感覚は、正しい直感でした。
1本ずつ管理する構造には、最初から限界がありました。
増やすたびに不安になるのは、その構造に無理がかかっているからです。
逆に言えば、不安を感じなくなったとしたら、入口管理が追いついていないことに気づいていないだけかもしれません。
どちらも良い状態ではありません。
入口側の管理がどれだけ丁寧でも、「増やすほど複雑になる構造」には限界が来ます。
増やすほど軽くなる構造を最初に用意できるかどうかが、長く安定して運用できるかの分かれ目です。
入口の数は増えても、出口は1つのままで済む。
それだけで、スケールに強い構造ができます。
出口を1つにすることが、スケールのポイント
出口は常に1つです。
仕組みが4本になっても6本になっても、確認するのは出口の1箇所だけでいい。
複雑さを管理するのではなく、複雑さが発生する場所をなくす。
これが、仕組みを増やしながら安定させるための考え方だと思っています。
自動化を複数組んでいる人が最初に意識すべきことは、入口側の条件の整理よりも、出口側の確認の設計です。
仕組みを足す前に、出口に番人を1人置く。
それだけで、かなり安定します。
仕組みが少ない今のうちに出口を設計しておくことが、後で楽になる一番の近道です。
仕組みが増えてから出口を設計しようとすると、既存の仕組みとの整合性を取る作業が増えます。
1本目を動かした直後に、出口の設計もセットで考える。
この順番が、後の自分を最も助けます。
新しく仕組みを足すたびに、「この仕組みは出口を通るか」を確認する習慣を持つだけで、かなり変わります。
出口を通らない仕組みが1本でも増えると、その瞬間に保護が崩れます。
出口を通ることを当たり前の前提として扱えれば、仕組みを追加するたびに安心感が積み上がっていきます。
ルール追加から3週間後の現状
数字より大きかった変化
6時間ルールを入れてから3週間が経ちます。
この間、二重送信は一度も起きていません。
数字より大きかった変化は、仕組みを追加する時の気持ちです。
以前は「また重複しないかな」というヒヤヒヤが毎回ありました。
今は出口で止まるという安心感があるので、新しい仕組みを足す時の怖さがほとんどありません。
「追加しても出口で止まる」という信頼が、少しずつ生まれてきました。
信頼という表現が大げさに聞こえるかもしれません。
でも実際、仕組みを足す時の心理的な負荷はかなり下がりました。
以前は1本追加するたびに「既存との組み合わせを全部確認しないと」という気持ちが出てきていました。
今はそれがほぼありません。
「出口が守ってくれる」という感覚が、新しいことを試すハードルを下げています。
試行のコストが下がると、試せる仮説の数が増えます。
「また確認が増えるから、新しいことを試しにくい」という状態が、少しずつ変わってきました。
仕組みが増えても対応コストが変わらない理由
今の構造では、仕組みの本数が増えても管理コストがほぼ変わりません。
4本になっても5本になっても、確認するのは出口の1箇所だけだからです。
以前のように「全ての仕組みの相性を一つずつ確認する」という作業が不要になりました。
副次的に、改善のための新しい仕組みを試しやすくなりました。
「また確認作業が増える」というストレスがなくなると、動きやすくなります。
試しに1本動かしてみて、うまくいけば残す。うまくいかなければ止める。
この試行のサイクルが、以前より素早く回るようになりました。
試行と検証のサイクルが速くなると、仕組み全体の改善ペースも上がります。
「出口の確認」という1ルールが、仕組みの品質と運用の速さの両方に効いています。
管理コストが増えない構造は、長期で見るとかなり大きな違いになります。
半年・1年単位で積み上がる確認作業の量を考えると、早めに出口を作っておくことの価値がわかります。
この件で学んだこと
1本の時には見えない壊れ方がある
自動化の仕組みが1本だけの時は、問題が見えにくいです。
単体では正しく動いているからです。
問題が出るのは、決まって「2本目を足した時」です。
1本が正しく動いていても、2本合わせると予想外の結果になることがある。
これは、仕組みを増やした人にしか体験できない壊れ方です。
「1本の時は大丈夫だったのに」という感覚は、増やしてみないとわかりません。
仕組みを追加する時には、単体の正しさだけでなく「他の仕組みとの組み合わせ」を意識する必要がありました。
今は出口の確認がその役割を担ってくれています。
1本の時にすべてが順調だったことは、実は何も保証していなかったんです。
「問題が起きていないから大丈夫」と「問題が起きにくい構造になっている」は、まったく別のことです。
問題が起きていない間は、その違いに気づきにくいです。
2本目を足して初めて、1本の時には見えていなかった構造の弱さが現れました。
これは後悔というより、重要な気づきです。
弱さが見えたということは、それを直せるということでもあります。
今では「構造の問題は、仕組みを増やすまで見えにくい」ということを前提として持っています。
地味な確認が一番確実に効く
最終的に効いたのは、複雑な仕組みの改修ではありませんでした。
「送る直前に1回確認を挟む」というシンプルな1ルールです。
複雑な構造を整理・統合しようとするより、最後の出口に確認を1つ置く方が、長期的に安定します。
シンプルな番人を1人置く方が、複雑な入口管理より強い。
これは理屈としてはわかりやすいのに、実際にやろうとすると「もっと根本を直したい」という気持ちが出てきます。
「本当にこれだけでいいのか」という不安が、シンプルな解決策への実行を遅らせることがあります。
でも、シンプルさには根拠があります。
確認する場所が1つなら、確認が壊れた時の発見も早いです。
複雑な仕組みが壊れると、どこが壊れたかの特定が難しくなります。
「シンプルにする」ことは、問題を減らすだけでなく、問題が起きた時の対応を速くすることでもあります。
自動送信の仕組み全体の設計については、別のnoteにまとめています。
複数の仕組みをゼロから組もうとしている方は、参考になるかもしれません。
失敗した時に「なぜ」まで掘ること
この件で一番後悔したのは、最初の失敗の後すぐに「どこを直すか」に飛んだことです。
「なぜ起きたか」を一段深く考える前に、表面の修正に向かいました。
その結果、2週間後に再発しました。同じ失敗を2度することになりました。
問題が起きた時に「どこを直すか」より先に「なぜ起きたか」を深く掘ること。
この順番を間違えると、また同じ場所でつまずきます。
「なぜ起きたか」を問い続けると、「2本の仕組みが同時に動いた」から「なぜそれが問題か」へ、さらに「出口がないから」へとたどり着きます。
この深さまで掘れなかったから、最初の修正が表面的な対応で終わりました。
失敗した直後は「早く解決したい」という焦りが出やすいです。
焦りは、深く掘ることを妨げます。
「一段深く考える」という時間を、あえて取ることが必要でした。
自動化に限らず、仕組みを複数動かしている人に共通することだと思います。
最初の失敗が教えてくれるのは、「どこを直すか」ではなく「どういう構造が問題か」です。
この経験が、「出口の確認」というシンプルな答えに最終的につながりました。
遠回りでしたが、今では確実に前より安定した状態で運用できています。
📕 この記事の内容を、実装まで全部まとめた有料記事があります
手順・コード・テンプレをそのまま渡しています
AIで「寝てても回る仕組み」を30日で組む全手順｜コード不要・特典40ファイル・毎月更新
この記事の販売者
