🔍 動いていないのに動いていた——SNSツールの止まり方3種類を見て変えた、最初の診断

自動ドアが「開かない」状態には、少なくとも3種類あります。

センサーが反応していない場合、電源が落ちている場合、施錠されている場合です。

外から見ると、どれも同じ「閉まったまま」に見えます。でも直し方は、3つともまったく違います。

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

• SNSの自動化ツールを動かしているのに、フォロー数が何日も増えていない • ログを開いても「エラーなし」「処理完了」としか表示されない • 「上限に達したのかも」と考えつつ、他に理由が思いつかない • 設定をいじってみたけれど、状況がまったく変わらない

先に結論を言います。止まった原因が「上限」であることは、実はあまりないです。

この記事では、TikTok・Instagram・ブランドアカウントの3つで実際に起きた「止まり方の違い」を書きます。

3つを並べることで見えてきた、最初の診断を変える考え方をお伝えします。

TikTokで「0件」を報告し続けたフォロー自動化

ログを開いても、何も問題が見当たらない

ある日、TikTokの自動フォローが3日連続でゼロを記録していました。

普段は1日に数十件は処理されるはずのツールが、完全に止まっているように見えました。

「上限に引っかかったのかな」と思いながらログを開きます。

でも画面には「処理が正常に完了しました」という記録が並んでいるだけです。

ログのタイムスタンプを見ると、1時間ごとに処理が走った形跡が残っています。

でもその下の「成功件数」の欄が、ずっとゼロです。

何も問題がないのに、数字がゼロというのは、どこから手をつけていいか分からないからです。

エラーが出ていれば、少なくとも「ここが壊れている」という手がかりになります。

でも「エラーなし・処理完了・でも数字はゼロ」は、何かがおかしいことだけは確かでも、何がおかしいかが見えない状態です。

最初の1日は、ツールの設定を見直しました。

対象アカウントの検索条件が変わっていないか、インターバルの設定がおかしくなっていないかを一つずつ確認しました。

2日目は、TikTok側の制限について公式ドキュメントを調べました。

フォロー上限の数値を確認して、自分のアカウントの実績と照らし合わせました。

でも上限の記録はありませんでした。

3日目に、やっと「判定のロジック自体を見てみよう」という発想が出てきました。

それまでの2日間、まったく違う場所を探し続けていたのです。

成功が「失敗」として記録される仕組み

結論から言うと、ツールはフォローを毎回正常に実行していました。

問題は「フォローできたかどうかを確認する部分」にありました。

フォローのアクションを実行した直後に、対象アカウントの状態を取得して「成功・失敗」を判定する処理が入っていました。

でもTikTok側のフォロー状態の反映には数秒かかります。

アクションの直後に確認すると、「まだフォローされていない」という状態が返ってきます。

ツールはそれを「フォローに失敗した」と記録してしまっていたのです。

つまり、毎回フォロー自体は成功しているのに、全件が「失敗」として記録され、成功カウントがゼロになっていました。

医療の検査に「偽陰性」という言葉があります。実際は陽性なのに、検査が陰性と判定してしまうケースです。

このツールで起きていたのはその逆で、実際は成功しているのに、失敗として記録されていた状態でした。

「ログに『処理完了』と書いてあるから問題ない」という判断が、診断を遅らせていたのです。

「異常なし」のログは「本当に異常なし」ではなく、「記録された範囲では異常なし」だったのです。

修正自体は単純でした。判定の前に数秒の待機を入れるだけです。

でも「タイミングのズレ」に気づくまでに3日かかりました。

原因を見つけるまでにかかったもの

原因がわかってしまえば、修正は数行の変更で済みます。

でもそこに至るまでに、設定確認・ドキュメント読み込み・ツールの仕様確認と、3日間費やしました。

「上限かな」という仮説が先に来てしまったことで、判定ロジックという別の場所に目が向かなかったのです。

最初から「上限以外の可能性」を探していれば、もっと早く気づけていたはずです。

これが最初に感じた違和感でした。「仮説が正しかったことはほとんどないな」という気づきです。

仮説は持っていい。でも仮説を前提にして探し始めると、仮説に合わない答えが見えなくなります。

📕 AIエージェントと自動化の全工程をまとめた総集編 手順・コード・テンプレをそのまま渡しています 🤖【完全版】月商160万円の「寝てても回る仕組み」をゼロから30日で組む全工程｜2026年10月版・Claude Code×AIエージェント・特典40ファイル・毎月更新

Instagramで「本当に止まっていた」フォロー自動化

症状はTikTokとまったく同じに見えた

Instagramの自動フォローも、あるとき4日間ほぼ動かない状態になりました。

フォロー数が増えない、という点ではTikTokの件と同じ見え方でした。

TikTokの経験があったので「また判定のズレかな」と思いました。

でも今回は違いました。ツールは本当に止まっていたのです。

フォローのアクション自体が走っておらず、処理ログの行数自体がほぼゼロでした。

TikTokとは逆で、記録ではなく動作そのものが止まっていた状態です。

見え方は同じでも、中身はまったく違いました。

TikTokの経験が「また同じかな」という思い込みにつながりかけていたのは、少し危なかったです。

上限でもなく、候補リストが空になっていた

「上限に達した？」と思い、制限の履歴を確認しました。

でも上限には引っかかっていませんでした。

フォロー上限のカウンターはまだ余裕のある状態でした。

しばらく原因を探して気づいたのが、フォローする候補アカウントのリストが空になっていたことです。

ツールは動く準備ができています。でも「何をするか」の対象がゼロだったのです。

自動化ツールには「誰をフォローするか」のリストが必要です。

そのリストを定期的に補充する仕組みを用意していなかったので、最初に入れた数百件が4日で底をついていました。

工場の機械が完璧に整備されているのに、材料の在庫が切れている状態に近いです（笑）。機械は正常。

でも何も作れない。原因は「機械が壊れた」ではなく「材料切れ」でした。

発見のきっかけは、ツールの設定画面で「次にフォローするアカウント」の件数を確認したことでした。

そこに「0件」と表示されているのを見たとき、「あ、そういうことか！」と思いました。

エラーでも上限でもなく、単純に「次にやることがない」状態だったのです。

2つを並べると見えること

TikTokとInstagramを並べると、こうなります。

TikTok：ツールは動いていた。でも記録が正しくなかった。

Instagram：ツールは止まっていた。原因は上限ではなく、対象リストの枯渇だった。

外から見ると、どちらも「フォロー数が増えない」という同じ症状です。

でも原因はまったく別で、直し方も180度違います。

TikTokに必要なのは判定ロジックのタイミング調整で、Instagramに必要なのは候補リストの補充です。

「上限」という仮説でアプローチしていたら、どちらも解決できませんでした。

この2つを並べたとき、「止まり方には種類がある」ということが、初めてはっきりと見えてきました。

brand-404で同じ構造が3つ目に現れた

数字が「0」なのに、動いている気配がある

brand-404というブランドアカウントで動かしていた別のツールでも、似た停止が起きました。

今度は「レポートの集計数字がゼロになる」という形で現れました。

でも実際にアカウントを確認すると、フォロワーが微妙に増えています。

「止まっているはずなのに、何かが動いている」という状態でした。

ログを見ると「処理完了」と書いてあります。TikTokのときと同じ光景です！

でも今回はTikTokとは別の原因でした。

同じ「止まっているように見える」の中に、また違う理由が隠れていたのです。

「またか！」と思いながら、今度は違う角度から確認を始めました。

集計の基準が実態とずれていた

原因を調べると、レポートが集計するときの「カウントの基準」がツール側とプラットフォーム側でずれていました。

ツールは「自分がフォローした件数」を記録していましたが、集計のタイムゾーン設定に齟齬があり、実際の処理件数が別の日付に計上されていたのです。

JST（日本標準時）で23時台に処理した分が、UTC基準だと翌日扱いになります。

するとレポート上は「今日の処理：0件」になるのに、実際の処理はちゃんと走っている、という状態になります。

つまり、動作は正常なのに、数字が実態を反映していない状態でした。

TikTokと同じ「記録がおかしい」タイプでしたが、原因の場所はまた別でした。

1つ目：判定タイミングのズレ。2つ目：処理対象の枯渇。3つ目：集計基準のズレ。

「記録がおかしい」という大分類の中にも、細かく見ると違う種類があることが分かりました。

3種類の止まり方が揃った

TikTok・Instagram・brand-404の3つを並べると、こうなります。

パターン1（TikTok）：動いているのに失敗と記録される。

判定のタイミングがズレていて、成功が失敗に見える。ログには異常が表示されない。

パターン2（Instagram）：本当に止まっているが、上限ではない。

候補リストが空になって、処理対象がない。ツール自体は正常で、リストを補充すれば再開できる。

パターン3（brand-404）：動作は正常だが、集計が実態と違う。

記録やレポートが実際に起きていることを反映していない。

数字だけ見ていると、存在しない問題を探し続けることになる。

3種類とも、外から見ると「止まっている」に見えます。

でも原因は全部違いますし、対処法もそれぞれ違います。

「上限に達した」という診断は、このどれにも当てはまりませんでした。

ログが「正常完了」を示すときに確認すること

ログが教えてくれることと教えてくれないこと

「処理が完了しました」というログは、「処理を実行した」という事実だけを記録しています。

「その処理が意図した通りに機能したか」は、ログが言える範囲の外にあります。

TikTokの例で言えば、「フォローのAPIリクエストを送った」という事実はログに残ります。

でも「そのフォローが実際に有効だったか、正しく判定されたか」はログには書かれていませんでした。

ログを読むときに「何が書かれているか」だけでなく「何が書かれていないか」を意識するようになったのは、この3件が揃ってからです。

エラーがないのに数字が動かないとき、「ログが見落としている何か」を疑う習慣ができました。

ログの「完了」は「問題なく完了した」ではなく、「処理のステップを最後まで実行した」という意味に過ぎないのです。

実態を確認する3つの方法

「ログが正常でも数字がゼロ」という状態に直面したとき、今は3つの方向から確認しています。

1つ目は、プラットフォーム側を直接見ることです。

ツールのログではなく、実際のSNSアカウントを開いて「フォロー中」のリストや通知履歴を確認します。

これで「実際には処理が走っている」かどうかがすぐ分かります。

2つ目は、処理対象の件数を確認することです。

ツールが次に処理するためのキューや候補リストが空になっていないかを確認します。

設定画面で「残り件数」や「次の処理対象」が表示される場合は、ここを先に確認するのが最も手っ取り早いです。

3つ目は、集計のタイムゾーンと期間の設定を確認することです。

ツール側とプラットフォーム側で日付の区切り方が違うと、実際の処理が別の日付に計上されることがあります。

設定でタイムゾーンが「UTC」になっているか「JST」になっているかを確認すると、意外と解決することがあります。

この3つを確認してから、それでも原因が見つからない場合に初めて「上限・バグ・外部要因」を疑うようにしています。

「止まった＝上限」という診断が最初に出やすい理由

上限は目に見えるルールだから

なぜ「上限に達した」という診断が先に出やすいかというと、上限はプラットフォームが明示しているルールだからです。

「1日にフォローできるのは○件まで」という数字は、検索すればすぐ出てきます。

数字として存在する制限なので、「これに引っかかったかも」と思いやすいのです。

一方で「判定ロジックのタイミングズレ」や「候補リストの枯渇」は、自分のツールの仕様を深く理解していないと出てこない仮説です。

見えやすい原因は先に疑われて、見えにくい原因は後回しになります。

これ自体は自然なことなのですが、見えやすい原因が正解であることは実は少ないのです。

広告運用でも同じ判断ミスが起きていた

以前、広告を運用していたときにも、似た構造の判断ミスをしていました。

CPM（広告を1,000回表示するのにかかるコスト）が急に上がったとき、「オーディエンスが疲弊している」とすぐに判断してしまうことがあります。

でも実際には、競合の入札が増えていたり、季節要因だったり、クリエイティブの品質スコアが下がっていたりします。

「疲弊」はあくまでも仮説の1つで、他の可能性を確認せずに結論を出すのは早すぎます。

SNSの自動化でも広告でも、「最初に浮かぶ仮説が正しいことは、むしろ少ない」という感覚があります。

「止まった＝上限」も、これと同じ構造です。

最初に浮かぶから疑うのではなく、検証してから採用する仮説にするのが大事だと思います。

最初の仮説を持ち続けるコスト

TikTokの件では「上限かな」という仮説のまま3日間調べ続けました。

でも原因は判定ロジックのズレで、上限は一切関係ありませんでした。

Instagramも同じです。

「上限を前提に設定を変えよう」という方向で動いていたら、候補リストの空きには一生気づけませんでした。

最初の仮説が間違っていると、どんなに調べても答えにたどり着けません。

特にログに異常がない場合、「でもエラーが出ていないから…」という思い込みがなかなか外れないのです。

仮説を持つこと自体は問題ありません。問題は、仮説を検証せずに前提にしてしまうことです。

診断のやり方を3つに分けた

最初に聞く問いを変えた

今は、何かが止まったように見えたとき、まずこれを確認しています。

「本当に止まっているのか、それとも記録が止まっているのか？」

この問いを先に置くだけで、その後の動き方が変わります。

「止まっている」前提で調べると、「なぜ止まったか」を探します。

「記録がずれているかもしれない」と思っていると、「実際に動いているかどうか」を先に確認します。

TikTokの件は、最初にこの問いがあれば1日以内に解決できた可能性があります。

「ログに完了と書いてあるのに、本当にゼロ件なのか？」を確認するだけでよかったのです。

問いの立て方が変わると、確認する場所が変わります。

確認する場所が変わると、答えを見つける速度が変わります。

3つの確認を順番に行う

止まったように見えたとき、今はこの順番で確認しています。

まず：記録は実態を反映しているか。

ログやレポートの数字が実際に起きていることと一致しているか確認します。

プラットフォーム側を直接見て、「動いているのに失敗と記録されている」可能性を先に排除します。

次に：処理する対象はあるか。

ツールが処理する素材（候補リスト・キューなど）が残っているか確認します。

「対象がゼロで止まっている」可能性を確認します。

最後に：上限・バグ・外部要因。

ここで初めて「上限に達したか」「ツールにバグがあるか」「プラットフォーム側に変更があったか」を確認します。

最初ではなく、最後に来る確認です。

この順番は、「外から見えやすいもの」から始めるのではなく、「誤診が起きやすいもの」から除外する順番です。

この順番に変えてから変わったこと

この確認順にしてから、原因不明の停止で何日も詰まることが減りました。

以前は「上限・バグ」を先に疑ってしまっていたので、記録のズレや材料切れを見落としていたのです。

変わったのは使っているツールでも、設定の数値でもありません。「何を先に疑うか」という順番だけです。

ツールが止まったときの全体の仕組みをどう整理しているかは、Claude Code自律環境についてまとめた記事に書いています。

診断の考え方だけでなく、自動化全体の設計が気になった方は、そちらも見てみてください。

止まった理由は、1種類ではない

診断が変わると、見えるものが変わる

「止まった＝上限」という第一診断を外してから、ツールの問題が早く解決するようになりました。

3日かかっていたものが、1日以内に原因がわかるようになってきた感覚があります。

変えたのは技術的な知識よりも、最初に立てる問いです。

「なぜ止まったか」より先に「本当に止まっているか」を確認する習慣が、診断の精度を変えました。

3件の実例を通じて見えてきたのは、「止まり方の種類を先に仕分けること」が最初の一手になる、ということです。

種類が特定できれば、調べる場所が絞れます。調べる場所が絞れれば、答えに早くたどり着けます。

最初の仮説は出発点に過ぎない

「上限に達した」という仮説が悪いわけではありません。

仮説はあくまでも出発点で、そこから検証するのが診断です。

でも検証をせずに仮説を前提にしてしまうと、答えが見つからない迷路に入ります。

TikTokで3日、Instagramで4日——最初の仮説に固執したコストです。

自動ドアが開かないとき、センサーを見るか、電源を確認するか、鍵を開けるか——正しい診断がないと、直し方が合いません。

「止まっている」という見え方の裏には少なくとも3種類の理由があることを、3つの実例から見てきました。

診断の起点は「上限に達したか」ではなく、「本当に止まっているのか、記録がずれているのか」——ここから始めると、次の一手が変わってくると思います。

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