2026年7月31日、私たちが運用しているLinkedInのアカウントが1つ、止まりました。
その日のうちに原因を特定し、社内のルール文書に書き込みました。そして、その原因は間違っていました。
広島でBtoBの営業支援をしている会社です。LinkedInの運用代行を、自社で作った管制アプリで毎日回しています。この記事は、その現場で起きた事故の記録です。
書くのは、失敗そのものより「原因を決めつけたこと」についてです。復旧の手順を知りたい方より、自動化を運用していて、何かが止まったときに原因を探す立場の方に読んでいただきたい内容です。
結論：時間の近さは、因果ではありませんでした
私たちは「直前に大量の操作をしたから止まった」と考えました。その説明は、実データと合いませんでした。いま有力なのは「接続からの経過日数で期限が切れる」という説ですが、これもまだ確定していません。
判断を誤らせたのは、時間の近さです。最後の操作の48秒後に、アカウントが止まりました。 これ以上ないほど分かりやすい状況に見えました。
正しい原因にたどり着いた方法は、たった1つです。壊れていないアカウントを見に行ったことでした。
この記事の出典
自社のLinkedIn運用管制アプリの実行ログと接続記録（2026年7月31日・8月7日の事象／対象アカウント15個）。数値はすべて自社の実測値です（hoshimi調べ）。
※記事内のアカウントは、運用者を特定できないよう「アカウントA」「アカウントB」と表記しています。
LinkedInのアカウントは、なぜ止まったのですか
7月31日、接続申請の取り下げを237件、6時間半にわたって連続で実行しました。その直後にアカウントが止まりました。
まず、その日に何をしたかを時系列で書きます。
| 項目 | 実測値 |
|---|---|
| 実行した操作 | 接続申請の取り下げ |
| 件数 | 237件 |
| 実行した時間帯 | 9時22分〜15時59分（6時間半ぶっ通し） |
| 最も多かった1時間 | 14時台に154件（約23秒に1件） |
| 停止が確認された時刻 | 最後の1件の48秒後 |
取り下げというのは、送ったまま返事のない接続申請を、こちらから引っ込める操作です。溜まっていた分をまとめて片付けようとしました。
そして8月4日まで、4日間止まったままでした。 その間、そのアカウントではリストの取り込みができていません。誰も気づいていませんでした。
気づいたのは、別の作業で管理画面を開いたときです。アラートが鳴ったわけでも、画面に警告が出たわけでもありません。
私たちが最初に出した結論は、なぜ間違っていたのですか
「6時間半ぶっ通しで機械的に叩いたから切られた」と断定しました。理由は、時間があまりに近かったからです。
その日のうちに、私たちは社内のルール文書に次の趣旨を書き込みました。
1日の上限を守っていても、短時間に集中して叩けば止められる。6時間半の連続実行が今回の原因である。
書いた本人は、確信していました。最後の操作の48秒後という事実が、他の説明を考える気を失わせたからです。
ここが、この記事でいちばん書きたい部分です。 私たちは「もっともらしい説明を1つ見つけた時点で、探すのをやめました」。
特に印象的だったのは、その説明が間違っていることに自分では気づけなかったことです。指摘を受けても、最初は自説を補強する材料を探しました。
つまり、こういうことが起きていました。
- 観察したのは壊れた1個だけだった（n＝1）
- 時間の近さを、因果の証拠として扱った
- 「他に説明はないか」を、1度も検証しなかった
本当の原因は、どうやって分かったのですか
壊れていないアカウントと並べたときです。もっと荒く叩いていたアカウントが、無事でした。
私たちが運用しているアカウントは15個あります。その全部について「接続した日」「その日の操作量」「止まったかどうか」を一覧にしました。
すると、こうなりました。
| アカウントA | アカウントB | |
|---|---|---|
| 7月31日の連続操作 | 237件・6時間半 | Aより荒い操作をしていた |
| 結果 | 止まった | 無事だった |
バースト（＝短時間の集中操作）が原因なら、Bも止まっていなければおかしいのです。 説明できない対照が1つあれば、その説明は間違いです。
代わりに浮かんだのが「接続からの経過日数でセッションの期限が切れる」という説でした。止まった4つのアカウントは、接続から34日・34日・34日・40日が経っていました。
ただし、この説もまだ確定していません。 30日を過ぎても無事だったアカウントがあり、反証のテストは終わっていません。私たちがいま言えるのは「操作量では説明がつかず、経過日数のほうが説明として近い」というところまでです。
1度、時間の近さに引きずられて結論を出しました。だから今度は、確定していないことを確定したように書かないようにしています。
そして、いちばん苦い事実がこれです。15個のアカウントの接続日を1回調べれば、5分で分かることでした。 私たちは、その5分を使わずに結論を出しました。
もう1つ学んだことがあります。連携ツールの提供元の公式ドキュメントには、有効期限として「1年」と書かれていました。 手元の実データは約30日でした。
以上の結果から、公式の記載より手元の実測を優先するという運用に切り替えています。
一方で、公式の記載が誤りだと断定はできません。機能ごとに期限が違う可能性もあります。私たちが言えるのは、自分たちの環境では約30日だったというところまでです。
関連記事: LinkedIn営業の承諾率は何%か｜自社の実測データの記事
4日間も気づけなかったのは、なぜですか
申請以外の失敗を、どこにも記録していなかったからです。止まった事実そのものが、残っていませんでした。
調べていくうちに、バーストより深い問題が見つかりました。ここが本当の穴です。
私たちのアプリには、異常を検知して自動で止める「冷却」の仕組みがあります。ところが、その配線が「接続申請を送る経路」にしかつながっていませんでした。
| 操作 | 失敗したときの記録 |
|---|---|
| 接続申請を送る | 残る（冷却が働く） |
| プロフィールを閲覧する | 残らない |
| 検索・リストを取り込む | 残らない |
| 接続申請を取り下げる | 残らない |
7月31日に止まったのは「検索・リストの取り込み」でした。記録の線が引かれていない側です。
だから、エラーが返っていたのに何も残りませんでした。画面にも出ません。4日間、システムは静かに失敗し続けていました。
原因の誤診は、正直に言えば直せば済む話です。それより重いのは、「気づく仕組みが無かった」ことでした。
止まらないために、何を直したのですか
1時間あたりの上限・深夜の停止・失敗が続いたときの中断を入れました。1日の上限だけでは足りません。
入れた歯止めは5つです。
| # | 入れたもの | 中身 |
|---|---|---|
| 1 | 1時間あたりの上限 | 1日の上限の6分の1以下に抑える |
| 2 | 10分あたりの上限 | 短時間に固まらないようにする |
| 3 | 深夜ガード | 23時〜翌6時は動かさない |
| 4 | 取り下げの上限 | 1日60件まで（237件は多すぎた） |
| 5 | 連続失敗での中断 | 3回続けて失敗したら止める |
第1に、1日の上限は歯止めになりません。1日300件でも、1時間で154件やれば別の意味を持ちます。相手が見ているのは合計ではなく、どれだけ集中したかです。
第2に、「溜まったぶんを一括で片付ける」操作そのものをやめました。数百件を1日で消化する動きは、人の手つきから離れます。
第3に、失敗を記録する配線を、閲覧・検索・取り下げにも引きました。次に止まったときは、その日のうちに分かります。
なお、これで止まらなくなったとは考えていません。経過日数で切れるのだとしたら、操作の丁寧さでは防げないからです。 そちらは「期限が来る前に張り直す」という別の運用で対応しています。
エラーを雑に分類すると、何が起きますか
健全なアカウントまで止まります。私たちは、生きているアカウントを丸2日止めました。
もう1つの失敗も書いておきます。2026年8月7日のことです。
あるアカウントで、リスト1本の取り込みが403というエラーを返しました。「このリストは見られません」という意味のエラーです。リスト1本の問題であって、アカウントの問題ではありません。
ところが、私たちのエラー分類は「文字列に403が含まれていたら冷却する」という雑な判定でした。
結果、こうなりました。
- アカウント全体を48時間、冷却（＝停止）した
- 直後に貼り直した、正常なリストも巻き添えになった
- アカウントは健在なのに、丸2日止まった
しかも最初、この停止を見て「またセッションが切れたのか」と誤診しかけました。管理画面に出ていたのは、丸めた文言だったからです。生のエラーを開いて、ようやく別物だと分かりました。
直したのは1点です。「このリストにアクセスできない」という種類のエラーは冷却せず、画面にそう表示するだけにしました。
安全装置は、強くすれば良いものではありません。判定が雑な安全装置は、守るべきものまで止めます。
よくある質問
LinkedInのアカウントが止まったら、まず何をすればいいですか
止まった原因を推測する前に、同じ条件で止まっていないアカウントがあるかを確認することをおすすめします。1つも無ければ全体の問題、あれば個別の問題です。私たちは、この確認を後回しにして4日を失いました。
どのくらいの頻度なら安全ですか
安全な数字は、私たちにも分かりません。「上限内だったのに止められた」なら、その上限が甘い証拠だと考えています。私たちは事故のたびに数字を下げる方針にしました。具体的な設定値は、上の表のとおりです。
セッションが切れたら、どうやって気づけばいいですか
エラーを記録する場所が、すべての操作経路にあるかを確認してください。私たちの場合、4つの経路のうち3つで記録が残らない状態でした。気づけなかったのは、注意力の問題ではなく配線の問題です。
公式ドキュメントの有効期限は信用できないのですか
私たちの環境では、記載と実測が食い違いました。ただし、これが提供元の誤りだと断定はできません。自分の環境で実測して、記録に残すことをおすすめします。
この記事の原因分析は、今度こそ正しいのですか
正しいと考えていますが、断定はしません。約30日という数字は、15アカウントの実測から出したものです。新しい反証が出たら、この記事を書き換えます。 1度間違えているので、そう書いておくのが誠実だと考えました。
LinkedInのアカウント停止から、私たちが持ち帰ったこと
この記事で書きたかったのは、復旧の手順ではありません。原因を決めつけることの危うさです。
自動化の運用では、何かが止まったとき、たいてい「直前にやったこと」が犯人に見えます。時間が近いからです。けれど、時間の近さは因果ではありません。
私たちが持ち帰ったルールは、2つだけです。
1つ目。原因を決めるときは、必ず「壊れていない側」と並べる。 壊れたものだけを見た分析で、原因を名指ししない。説明できない対照が1つでもあれば、その説明は間違いです。
2つ目。公式の記載より、手元の実データを優先する。 そして、実測できる形で予測を書き残す。当たり外れが後から分かるようにしておきます。
一方で、正直に書いておくべきこともあります。この2つを守っても、事故は起きます。 私たちは8月7日にも別の誤爆を出しました。減らせるのは、気づくまでの時間だけです。
私たちは、LinkedIn運用の代行をしています。アカウントが止まったときに何が起きていたかを、こうして開示できる形で記録するところまでが仕事だと考えています。
「自動化を回しているが、止まったときに気づける仕組みが無い」という状態であれば、一度ご相談ください。
関連記事: /service/linkedin/ LinkedIn運用代行のサービスページ
関連記事: LinkedIn営業の承諾率は何%か｜自社の実測データの記事
関連記事: フォーム営業の返信率は何%か｜19,075件の送信データの記事
この記事を書いた人
丸山 祐介／株式会社hoshimi 代表
広島でBtoBの営業支援（LinkedIn運用代行・フォーム営業・アポ獲得代行）をしています。前職のマーケティング会社ではCOOとして、営業利益を1年で5,000万円から2億円にしました。
自社ツールを内製して毎日運用しており、この記事の数字はすべてその実データです。
この記事の作り方
下書きはAIが書き、数字と事実は人が元データに当たって確認しています。確認が取れなかった数字は載せていません。
広島から、実測データごと営業支援をしています
この記事の数字は、株式会社hoshimi（広島市中区）が自社の本番運用で実測したものです。同じ仕組み・同じ実測レポートつきで、貴社の営業も運用します。
