要点
- 対外発信を全面停止したと判断した後も、2日間で同じ内容が5回、複数の送信先へ送られていた。（出典：自社の実測・2026-09-07「何が起きていたか」）
- 送信する仕組みには停止状態がなく、退避した送信待ちデータも別の仕組みによって自動で補充されていた。（出典：自社の実測・2026-09-07「原因」）
- 停止対象を列挙する設定を新設し、送信処理が起動時に必ず読み、対象を件数の集計にも含めず停止扱いにするよう修正した。（出典：自社の実測・2026-09-07「直したこと」）
- 公開済みの記事から問題のある画像を除去し、修正したスクリプトを実行して停止扱いのログを確認した。（出典：自社の実測・2026-09-07「直したこと」）
本記事でいう停止設定とは、送信処理が起動時に読み込み、停止扱いにするブランド・対象を列挙した設定のことだ。
「全面停止した」という記録と、実際の送信が食い違った
自社のSNS等への自動投稿で、配布していた素材に権利上の問題が見つかった。そのため、対外発信を全面停止したと判断し、記録にもそう残した。
ところが、その後に「本当に止まっているか」を別の角度から監査すると、発信は止まっていなかった。送信ログの実物を確認した結果、停止したと判断した後の2日間で、同じ内容が5回、複数の送信先へ実際に送られていた。
さらに、停止の目的だった画像を埋め込んだ記事も、公開され続けていた。今回確認されたのは、停止判断後の送信と、問題のある画像の公開継続という二つの事実だった。
停止したという判断は記録に残っていた。しかし、送信処理がどう動いていたかを確かめると、その判断とは異なる結果になっていた。停止したと記録することと、送信する仕組みが停止していることが一致していなかった。
出典：自社の実測・2026-09-07「何が起きていたか」
実測と対応の記録
以下は、自社の記録から該当する記述をそのまま転記した表だ。送信回数は停止したと判断した後の2日間についての記録であり、送信先ごとの内訳を示すものではない。
| 確認項目 | 素材に残した記述（原文） |
|---|---|
| 停止判断後の期間・回数・送信先 | 送信ログの実物を確認すると、停止したと判断した後の2日間で、同じ内容が5回、複数の送信先へ実際に送られていた。 |
| 公開され続けていた内容 | さらに、停止の目的だった画像（権利上問題のある素材）を埋め込んだままの記事も、公開され続けていた。 |
| 送信処理の停止状態 | 送信を行う仕組み自体に「停止」という状態が存在しなかった。 |
| 送信待ちデータの補充 | しかも、送信待ちデータを自動で補充する別の仕組みが動いていたため、退避してもすぐに元に戻る構造になっていた。 |
| 停止設定の新設 | 停止するブランド・対象を列挙する設定ファイルを新設した。 |
| 公開記事への対応 | 権利上問題のある画像を埋め込んでいた既存の公開記事から、該当の画像を除去した。 |
| 修正後の実行確認 | 修正後、実際にスクリプトを動かして「停止扱いになっている」ことをログで確認した。 |
出典：自社の実測・2026-09-07「何が起きていたか」「原因」「直したこと」。表は記録本文の転記であり、送信ログそのものの転載ではない。
この記録で確認できたのは、送信待ちデータが存在したということだけではない。停止したと判断した後にも、実際の送信が行われていた。停止のために行った操作と、その後の処理結果を照合したことで、対応が目的を果たしていなかったと分かった。
送信待ちデータを退避しても、停止にはならなかった
原因は、送信を行う仕組み自体に「停止」という状態が存在しなかったことだった。送信条件を満たしているかどうかは、送信用の認証情報があるかだけで判定されていた。
これに対して、停止のために実際に行った操作は、送信待ちデータの退避だった。送信条件を変更する操作ではなく、送信対象になるデータを移す操作だった。
しかも、送信待ちデータを自動で補充する別の仕組みが動いていた。データを退避しても、すぐに元に戻る構造になっていたのである。退避という操作を終えても、補充する仕組みと送信する仕組みは止まっていなかった。
素材には、この原因が次のように記録されている。
つまり、「止めた」と判断した行為は、実際には止める仕組みに一切触れていなかった。
今回の失敗では、送信待ちデータへの対応を、対外発信の停止と判断してしまった。自動補充があるため、データを退避するだけでは送信の停止を維持できなかった。
送信待ちデータを退避したことは、実施した操作として記録できる。しかし、それだけでは、送信する仕組みに停止状態を設けたことにはならない。今回の原因を確認するうえでは、データの退避と、送信処理の停止を区別する必要があった。
出典：自社の実測・2026-09-07「原因」「業務に置き換えると」
停止対象の設定を、送信処理が必ず読むようにした
修正では、停止するブランド・対象を列挙する設定ファイルを新設した。さらに、送信を行う仕組みが起動時に必ずこの設定を読むようにした。
設定に含まれる対象は停止扱いとし、件数の集計にも含めないようにした。停止対象を設定に記載することと、送信処理がその設定を読み取って停止扱いにすることの両方を変更した。
これは、送信待ちデータの退避だけを行っていた対応からの変更だった。送信する仕組みに停止の判断を加え、どの対象を止めるかを設定で列挙できるようにした。
修正内容は、設定ファイルを作成するところで終わっていない。送信処理が起動時に設定を必ず読むこと、列挙された対象を停止扱いにすること、対象を件数の集計にも含めないことまでが、記録された変更の範囲である。
公開済みの記事にも対応した。権利上問題のある画像を埋め込んでいた既存の記事から、該当の画像を除去した。今回の対応には、送信処理の修正に加えて、公開され続けていた画像の除去も含まれている。
出典：自社の実測・2026-09-07「直したこと」
実行して確認したところ、別のエラーも見つかった
修正後は、実際にスクリプトを動かした。その際のログで、対象が停止扱いになっていることを確認した。
この実行では、変更を加えた別の箇所に実行時エラーも見つかった。変数を宣言する前に参照していたことが原因だった。このエラーも合わせて修正した。
見つかったのは構文エラーではなく、構文チェックだけでは検出できないエラーだった。今回の記録では、実際に動かしたことで、停止扱いになっていることの確認と、別の変更箇所にあった不具合の発見につながった。
素材では、実行による確認について次のように整理している。
構文チェックが通ることと、実際に動かして確認することは別。必ず一度実行して確かめる。
今回、修正後にログで確認したのは、スクリプトの実行時に対象が停止扱いになったことだ。修正後の継続監視期間や、その期間の送信件数は素材に記載されていない。
停止判断後の「2日間で5回」は、修正前に送信が続いていたことを示す記録である。一方、修正後について記録されているのは、実際のスクリプト実行によって停止扱いのログを確認したことだ。それぞれ、何を確かめた記録なのかを分けて読む必要がある。
出典：自社の実測・2026-09-07「何が起きていたか」「直したこと」「業務に置き換えると」
業務で停止を判断するときに確認すること
今回の記録を業務に置き換えると、停止の操作と、停止した結果をそれぞれ確かめる必要がある。
まず、送信する仕組みに停止の条件があるかを確認する。送信待ちデータを消したり退避したりしたことだけで、停止したと判断しない。今回のように別の仕組みがデータを自動で補充している場合、データへの対策だけでは元に戻ってしまう。
次に、停止を判断したその日のうちに、送信ログを確認する。「停止した」と記録したことに加えて、本当に送られていないかを見る。今回は、その確認までに2日間、5回の送信を見逃していた。
修正した処理は、構文チェックだけで確認を終えず、一度実行する。今回も、実際に動かすことで停止扱いのログを確認でき、構文チェックでは検出できない実行時エラーも見つかった。
公開済みの内容も確認する。今回は、発信を止める目的だった画像が、既存の記事に埋め込まれたまま公開され続けていたため、該当画像を除去した。
そして、自分で「対応した」と判断した範囲を、別の人や別の角度から確認する。今回も「本当に止まっているか」を改めて監査したことで、記録上の全面停止と、実際に続いていた送信との食い違いが判明した。
出典：自社の実測・2026-09-07「何が起きていたか」「直したこと」「業務に置き換えると」
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。