自動返信が2通届くとき｜止まった処理を再実行する前に

回答: 止まった自動処理をそのまま最初から再実行すると、すでに送った分をもう一度送ってしまうことがあります。防ぐ備えは3つです。①どこまで送ったかを1か所に記録する ②同じ処理が同時に2つ走らないようにする ③途中で止まる前提で処理を区切る。 これは自作かどうかの話ではなく、途中で止まりうる処理に共通して必要になる考え方です。ただし、どう実装できるかは使っている仕組みによって変わります。自社に当てはめるときは、処理の順序・記録の持ち方・送信先の仕様を確認してください。

なお、人が重複して連絡してしまうほうの話（複数人で対応していて、誰がどこまで対応したか分からず2人が同じお客様に連絡する）は別の記事で扱っています。あわせて反響対応の対応漏れ・二重対応を防ぐ方法をご覧ください。この記事で扱うのは、担当者は1人でも、仕組みのほうが2通送ってしまう場合です。

この記事でわかること

• 止まった自動処理を再実行したときに起こりうること
• 「同じ人に2通」が生まれる3つの原因
• もう一度回しても大丈夫にするための3つの備え
• 内製でこの備えを持つときに残る論点

止まった処理を「もう一度回す」と何が起きるか

答え: 送信済みの記録がない仕組みでは、最初から送り直しになることがあります。

ある開発者が公開した実装の記録を紹介します。これは不動産会社の事例ではなく、1件の公開記録です。同じことが必ず起きるという意味ではありません。

この開発者は、毎朝7時に、スプレッドシートに溜まった640件の問い合わせをスクリプトで要約し、チャットに投稿する処理を動かしていました。ある朝、実行時間の上限（Google Apps Scriptの場合は1回あたり6分）に達して、約380件目で処理が止まりました。

ここからが本題です。慌てて手で再実行したところ、どこまで送ったかを記録していなかったため、1件目から処理をやり直しました。再実行も6分で止まり、3回目でようやく最後まで通りました。結果として、最初の380件分の要約がチャットに二重で投稿されました。

記録には、副作用として外部APIの消費が増えたことも書かれています。費用の話はこの記事の主題ではないので、ここでは触れるだけにとどめます。

出典: GAS×AIのバッチが6分で切れて要約380本を二重送信した（Qiita）

なぜ「止まること」より困るのか

止まったこと自体は、気づいて回し直せば取り返せる場合があります。一方で、送ってしまったものを戻せるかどうかは送信先の仕様によります（チャットのように後から削除できる場合もあれば、メールのように取り消せない場合もあります）。

反響対応に置き換えると、次のような形が考えられます（実例ではなく、起こりうる形として挙げています）。

• 同じ問い合わせ者に、同じ内容の自動返信が2通届く
• 同じ物件の案内メッセージが2回流れる
• 担当者への通知が重複し、対応する側が混乱する

重複が顧客向けの自動返信で起きた場合は、同じ連絡が相手に届きます。 社内向けの通知でも、対応する側の混乱につながります。どこまで影響するかは、その処理の送信先によります。いずれの場合も、止まったことには自社で気づける余地がありますが、送られたものは相手側に残ります。

なお、「そもそもなぜ止まるのか」「止まったことにどう気づくのか」は、この記事では扱いません。別記事のGASのエラーに気づかず反響を取りこぼす理由と対策と自動化が「成功」のまま止まるときをご覧ください。この記事は気づいた後、どう戻すかに絞ります。

「同じ人に2通」はどこから生まれるのか

答え: 先ほどの記録では、原因が3つに整理されています。

原因	何が起きるか
処理が途中で止まる	実行時間の上限などで、残りが手つかずのまま終わる
同じ処理が2つ走る	手での再実行と、自動の定期実行が重なることがある
送信済みの記録がない	再実行したときに、送った分と送っていない分を区別できない

出発点は3つ目です。送信済みが分からない状態では、止まるたびに「どこから送り直すか」の判断が人に委ねられます。ただし、記録を持てばそれで防ぎきれるわけではありません。同時に2つの処理が走って両方とも「まだ送っていない」と判断する場合や、送信に成功した直後、記録を書き込む前に止まる場合が残ります。だから3つを組みで考えます。ただし、3つを揃えても「送った直後に止まる」隙間は完全には消えません。送信先に重複を弾く仕組みがあるか、送信履歴と突き合わせられるかも、あわせて確認してください。

この記録には続きがあります。著者は最初、一覧表に「完了」の印を書き込む方式で直そうとしました。ところが「完了」を書き込む直前に処理が止まった行があり、翌日にまた送られたといいます。印を付ける処理自体も、途中で止まりうるという話です。

もう一度回しても大丈夫にするための3つ

答え: 送信済みの記録・同時実行の抑止・時間で区切る、の3つです。考え方なので、GASでも他の仕組みでも当てはまります。

1. どこまで送ったかを1か所に記録する

送信が成功した時点で、どこまで終わったかを1か所だけに残します。先ほどの記録では、最後に送れた行番号をスクリプトの保存領域に1つだけ置き、それを送信済みの唯一の根拠にしたとあります。一覧表の「完了」印は、人が見るための表示に格下げしています。

要点は、送信済みの根拠を1か所に決めることです。2か所にあると、どちらが正しいかで迷います。なお、行番号で再開する形が使えるのは、処理の順番が変わらず、飛ばす行がない場合です。並び替えや絞り込みが入る仕組みでは、行番号ではなく件ごとの識別子で記録することになります。

2. 同じ処理が同時に2つ走らないようにする

手での再実行と定期実行が重なると、同じ行を2つの処理が同時に扱うことがあります。先ほどの記録では、先に始まった処理だけが動き、後から来た処理は短時間で諦めて終了するという形にしています（Google Apps Scriptには、この用途の仕組みが用意されています）。

3. 途中で止まる前提で区切る

上限ぎりぎりまで走らせて強制的に切られるのではなく、手前で自分から中断し、残りを次に回す形です。記録では、開始から一定時間（280秒）を超えたら中断し、数分後に自分をもう一度起動する設定を作っています。残りがなければ、その設定は作りません。

3つのうち最初に入れるなら1番です。ただし前述のとおり、1番だけでは同時実行や記録前の停止が残ります。1番を入れたら、2番・3番も続けて確認してください。

内製でも作れる。ただし、残る論点がある

答え: この3つは内製でも作れます。先ほどの記録の著者自身が、公開された範囲で対策を入れています。「内製では無理」という話ではありません。

残るのは、作った後に誰が見るかです。止まったことに気づき、再開を確認し、記録のずれを直す役が要ります。その役が1人に依存していて、権限の移管や手順書の整備がない場合、担当が替わったときに引き継ぎが難しくなることがあります。これは重複送信とは別の論点で、反響対応をAI+GASで自作する前の4つのリスクで扱っています。

判断としては、次のように分けて考えられます。

• 自作のままでよい場合 — 件数が少なく、止まったときに気づける人がいて、3つの備えを入れて保守も続けられる
• 外に出すことを検討する場合 — 件数が増えた、担当が替わる予定がある、止まったことに誰も気づけない状態が続いている

どちらが正しいかは、会社の体制によります。

よくある質問

再実行する前に、どこを見ればよいですか

送信済みがどこに記録されているかを先に確認してください。記録が見当たらない場合、最初から回すと送り直しになる可能性があります。その場合は、全件を回さず、未送信と分かる範囲だけを手で処理する方が安全なことがあります。

「完了」の印を一覧表に付けていれば大丈夫ですか

印を付ける処理自体が途中で止まることがあります。先ほどの記録でも、印を書き込む直前に止まった行が翌日に再送されたとあります。一覧表の印を再開の判断に使う設計もありえます。いずれにしても、記録をどこに置くかに関わらず、送信と記録の間で止まった場合への備えは別に必要です。送信済みかどうかが分からない分は、送信履歴と突き合わせてから再実行してください。

2通届いてしまったら、どうすればよいですか

まず、使っている送信先で取り消しや削除ができるかを確認してください（チャットでは削除できる場合があります）。戻せない場合、お詫びの連絡をどうするかは運用の判断になります。技術的には、同じことが繰り返されないよう、再開の記録を入れてから次の実行に進むことになります。

GAS以外の仕組みなら起きませんか

実行時間の上限や再実行の扱いは仕組みによって違いますが、途中で止まりうる処理であれば、再開の設計は同じように必要です。使っている仕組みの仕様を確認してください。

まとめ

自動処理が止まったとき、最初にやりたくなるのは「もう一度回す」ことです。そこで、送信済みの記録がないと、送った分をもう一度送ってしまうことがあります。止まったことには自社で気づける余地がありますが、送られたものは相手側に残ります。

備えは3つ、どこまで送ったかを1か所に記録する／同じ処理を同時に2つ走らせない／途中で止まる前提で区切る。まずは1つ目から、自社の仕組みに入っているかを確認してみてください。

—

この記事を書いた会社

7plus株式会社 不動産会社向けの営業DX支援を行うITソリューションプロバイダーです。反響対応を即時化する「Mail2Link」「Mail2Link×AI」、ノーコード業務アプリ「BizBlock」の開発・提供に加え、Salesforce認定パートナーとして不動産特化型Salesforceパッケージの導入・定着コンサルティングも行っています。

詳しくはこちら → https://7plus.jp/