ホーム › RPA/ブラウザ自動化 › 自動化で直面した3つの実例: Meta検知、API枯渇、cron不発からの教訓
RPA/ブラウザ自動化

自動化で直面した3つの実例: Meta検知、API枯渇、cron不発からの教訓

公開: 2026-05-19 · 著者: Sasaki Ryuji

自動化を運用すれば必ず会う3つの典型トラブル、その回避策と復旧手順

自動化で直面した3つの実例: Meta検知、API枯渇、cron不発からの教訓

自動化を運用していると、必ずどこかで「動いていたものが突然止まる」事故に遭遇します。私はGramShift Desktop と ai-pick 記事自動生成 Worker を運用する中で、典型的な3つのトラブル (Meta検知警告、Netlify 無料枠枯渇、Windowsタスク exit 9009) を 2026年5月の同月に経験しました。この記事ではそれぞれの発生時の状況、原因究明、恒久対策を実例として残します。同じトラブルに備えるためのチェックリストとして使ってください。

失敗事例1: Meta検知警告で全アカウント停止

2026年5月16日、私が運用していた Instagram アカウント (運営者の検証用Instagramアカウント) で Meta の自動化検知警告を受けました。サイクルログを見ると、通常50件のいいねが実行されるはずが「6件で停止、action_blocked エラー」で終了していました。アカウントにログインすると「We're sorry, but we limit how often certain actions can be performed」という英語の警告がトップに表示されていました。

原因究明のため、過去2週間のサイクルログを洗い直した結果、当時の設定が「サイクル間隔45-60分のランダム、1日約15-20サイクル、1サイクル50いいね = 1日750-1000いいね」という、Meta の暗黙の閾値ギリギリで運用していたことが判明しました。さらに、サイクル間隔のランダム幅が狭く、深夜2時から5時の間にも実行されていたログがあり、機械的なパターンとして検知された可能性が高い状況でした。

恒久対策: Human-Pacing v1.5.0

GramShift v1.5.0 として Human-Pacing 設計を根本から書き直しました。改修ポイントは4つです。

  • サイクル間隔を「60-180分」のランダムに拡大、ランダム幅を3倍に
  • 深夜帯 (23時-6時) は実行スキップ
  • 1サイクルの上限を 30-50件 → 15-50件 の可変に
  • 1日の最大サイクル数を 8 に制限

これにより1日の最大いいね数は理論値で 400件 に下がり、Meta検知警告は消失しました。集客効率は半分以下になりますが、BANリスクとのトレードオフでは妥当な判断です。詳細は PlaywrightでInstagram自動運用の基礎 にまとめています。

失敗事例2: Netlify 無料枠 300credit 枯渇

同じく 2026年5月、別の事故が発生しました。ある運営メディアサイトを Netlify で運用していたところ、「Build minutes usage 75%」というメール、その4日後に「100%、Builds will fail until next cycle」というメールが届きました。次の billing cycle のリセットまで残り 18日、その間サイト更新が完全に止まる状況です。

原因は明確で、自動デプロイバッチ (ai-pick 記事自動生成 Worker) が毎日10:00に自動デプロイする運用が、Netlify の月300 credit を予想以上に早く食っていたことでした。1ビルド = 約 1-5 credit、月60-100ビルドで上限到達というペースです。

恒久対策: 深夜3時間で ConoHa WING に緊急移管

その夜のうちに ConoHa WING への移管を決断、3時間で完了しました。WING にはマルチドメイン無制限プランを既に契約していたため、サーバー追加コストはゼロです。実装した手順は以下です。

  1. WING 管理画面で 該当ドメイン をドメイン追加、無料独自SSL有効化 (10分)
  2. DNS A レコードを WING の IP に変更 (TTL伝播待ち 30分-1時間)
  3. deployer.mjs を deployToNetlify() → deployToWing() に書き換え (basic-ftp で FTPS、90分)
  4. テストデプロイ + 本番記事の再デプロイ (45分)

翌朝、該当サイトは WING で正常配信され、自動デプロイバッチも WING 経由に切替完了。実害ゼロで乗り切れました。教訓は「無料枠依存はリスク、契約済みリソースを優先活用」です。

失敗事例3: Windowsタスク exit code 9009

3つ目は地味ですが頻発する事故です。新しい Windowsタスクを登録した翌朝、Discord に「Result: 9009」の通知が届きました。9009 は「'XXX' は内部コマンドまたは外部コマンドとして認識されていません」というエラーで、原因は WorkingDirectory の設定漏れです。

当時の登録コマンドはこうでした。

# 誤った登録 (WorkingDirectory が空)
$action = New-ScheduledTaskAction \
 -Execute 'node' \
 -Argument 'scripts/generate.mjs'
Register-ScheduledTask -TaskName 'Lab_Daily' -Action $action ...

WorkingDirectory が空欄だと C:\Windows\System32 がカレントディレクトリになり、そこに scripts/generate.mjs は存在しないため即エラーになります。

恒久対策: WorkingDirectory を必ず明示

正しい登録はこうです。-WorkingDirectory をプロジェクトのルートに明示します。

$action = New-ScheduledTaskAction \
 -Execute 'node' \
 -Argument 'scripts/generate.mjs' \
 -WorkingDirectory 'C:\AI_WORK\ai-pick' # 必須

これに加えて、bat ファイルを CRLF 改行で保存することも必須です。VS Code で bat を保存すると LF になりがちで、これも 9009 系エラーの原因になります。.vscode/settings.json に "[bat]": { "files.eol": "\r\n" } を設定して強制 CRLF にしておくと事故が減ります。

3つの事故から得た「自動化運用の3原則」

これらの事故から得た原則を整理すると、以下の3つです。

  • 第1原則: Bot判定への備えは「過剰なほうがマシ」。Meta だけでなく Google、X、Threads にも同様の検知があり、Human-Pacing は設計時から組み込むべきです
  • 第2原則: 無料枠は「いつか必ず枯渇する」前提で代替先を準備。私の場合 ConoHa WING の契約があったことが救いでした
  • 第3原則: 環境設定 (WorkingDirectory, 改行コード) は最初のチェックリストに入れる。後から思い出すと半日溶けます

自動化運用は「動いた瞬間がゴールではなく、止まった瞬間に対応できる体制がゴール」です。Discord webhook によるエラー通知基盤と組み合わせて、止まった瞬間に5分以内に気づける状態にしておくのが、長期運用の鍵になります。

関連する実装ノウハウは 自動化レシピカテゴリ と RPA/ブラウザ自動化カテゴリ に蓄積しています。