🔴 隣のChromeを毎日殺していた——shared-profileとpkillが消すIGセッション

月10万の大学生が掛け持ちで月60万を稼ぎ、会社都合の解雇でゼロに戻り、半年かけてClaude Codeの自律環境を組み上げて月商120万——その基盤を支えるIGアカウントが、自分が書いたスクリプトに毎日殺されていた。

なぜこの仕組みが効くのか

個人開発で月商を積み上げるとき、最初の壁は「人手が足りない」ではなく「自分が寝ている間に何が起きているかわからない」です。

私の環境では現在、171本のジョブが launchd から毎日自動起動しています。X / Instagram / Threads / TikTok への投稿・いいね・フォロー・アンフォロー・DMをすべて自動化したうえで、sns-output-watchdog.sh というBashスクリプトが「当日ちゃんと出力したか」を成果物のログで監視しています。

しかし監視を整備する前は、2週間気づけなかった実績があります。sns-output-watchdog.sh の先頭コメントにはこう書かれています。

# content-watchdog.sh は article/note/maker/series/ameba だけを見ており、
# X/IG/TikTok/Threads の投稿・返信は誰も監視していなかった。その結果
# IG投稿は7/29から、TikTok投稿は7/28から止まったまま2週間気づかれなかった。

IG投稿が止まれば、新規フォロワーが増えず、公式LINEへの流入が止まり、最終的に売上の伸びが鈍化します。1スロットの失敗は「今日1本投稿できなかった」ではなく、「そこから始まるはずだったファネルが丸ごと死んでいた」という意味を持ちます。

監視を整備してからも、次の問題が顔を出しました。exit 0 と「成果があった」は別物だということです。2026-08-08の実測で、IGいいねレーン ig-1 は1日12回の実行のうち8回がいいね0件のまま exit 0 で終わっていました。当時の watchdog は「終了 ( というマーカーの出現回数」を数えるだけだったため、circuit-breakでもneed-loginでも「健全」と判定していました。

# 🔴 従来は '終了 (' の出現回数だけを数えていたため、circuit-break でも need-login でも
#    「健全」と判定していた。2026-08-08 実測で ig-1 は12run中8回、tt-1/tt-2 は6割が
#    いいね0件のまま exit 0 で終わっており、2週間誰も気づけなかった。

この教訓を踏まえて「成果ゼロの run を検知する count_dead_runs()」と「実際のいいね数を集計する sum_likes_today()」を追加しました。それでもまだ、壊している側と壊れたと報告する側が別のリポジトリにあるという構造的な問題は解決していませんでした。これが 2026-08-24 のインシデントです。複数の自動化を同じ Mac で走らせている人なら、同じ穴にはまるリスクが必ずあります。

全体の流れ

リポジトリをまたぐ共有資源

問題を整理するために、まず構成を図にします。

scent-media リポジトリ                social-autolike リポジトリ
──────────────────────────            ──────────────────────────────────
scripts/ensure_chrome.sh              config/accounts.json
  └ CDP :9223 へ接続試行                └ "reuseProfile": ".profiles/chrome-ig"
    応答なし → pkill 実行
         │                            th-scent ジョブ（Playwright）
         │                              └ .profiles/chrome-ig を掴んで起動
         │                                ※ CDP 9223 は一切開かない
         ↓                                         ↓
         └──────────────┬───────────────────────────┘
                        ↓
             .profiles/chrome-ig  ← 両者が同じプロファイルを参照
             Cookie SQLite 強制破壊
             instagram.com の sessionid → 0行

scent-media の ensure_chrome.sh は、IG投稿前に「ChromeがCDPで制御可能な状態か」を確認します。確認方法はポート 9223 への接続試行です。応答がなければ「Chromeは死んでいる」と判断して、次のコマンドで強制終了します。

pkill -f "user-data-dir=$PROFILE"

$PROFILE は .profiles/chrome-ig です。問題は、同じプロファイルを social-autolike の th-scent ジョブが reuseProfile 設定で共用していたことです。th-scent は Playwright 経由で Chrome を起動しますが、CDP ポート 9223 は開きません。ensure_chrome.sh から見ると、「th-scent が使っている Chrome」は常に「9223 が閉じている＝死んでいるプロセス」に見えます。

毎日決まった時刻に起きる衝突

この衝突は偶発ではなく、launchd のスケジュールによって毎日決まった時刻に確定的に発生していました。

22:56 に th-scent unfollow が .profiles/chrome-ig を掴み、23:00 の daily-post が ensure_chrome.sh を呼ぶ。9223 は応答しないので pkill が走る。これが毎晩繰り返されていました。19時・21時のスロットも同様に、th-scent autolike と時間が重なります。

Cookie SQLite の破壊

pkill -f "user-data-dir=..." は SIGTERM のあと SIGKILL を送ります。Chrome はシャットダウン処理を完了できず、プロファイル内の Cookie SQLite を整合性のある状態で書き戻す機会を失います。

Chrome は次回起動時に空の Cookie DB を作り直します。実測値はこうです。

cookies テーブルは全ホスト合計3行まで縮み、instagram.com の Cookie は0行。IG sessionid が消えた

2026-08-24 は 19時・21時・23時の全スロットで投稿ゼロでした。

watchdog が「ログイン切れ」と誤診した理由

sns-output-watchdog.sh の IG 投稿チェックはこうなっています。

check "ig-autopost" \
  "$(count_today "$CL_LOGS/sns-ig-autopost.retry.log" "$TODAY_JST" 'OK posted')" \
  1 "IGカルーセル投稿" \
  "$CL_LOGS/sns-ig-autopost.retry.log" "$TODAY_JST"

OK posted が当日ログに1件もなければ FAILED に積まれ、Discordに 🚨 SNS当日未出力: ig-autopost が飛びます。実際にそのアラートは飛んでいました。しかし、アラートのテキストは「投稿失敗」であり「pkillによるセッション破壊」ではありません。

セッション判定器は「IG の sessionid がない」と正しく報告します。ログには need-login が残ります。人間が見ると「ログインが切れた→再ログインしよう」と判断します。翌日また同じ時刻に pkill が走り、Cookie が消えます。このループが繰り返されていました。

watchdog: 🚨 ig-autopost 未出力
    ↓
session-liveness: sessionid が無い（正しい報告）
    ↓
人間: GUI 再ログインを実行
    ↓
翌日 22:56: th-scent がプロファイルを掴む
    ↓
翌日 23:00: ensure_chrome.sh → pkill → Cookie 消滅
    ↓
watchdog: 🚨 ig-autopost 未出力（同じ報告が出る）

壊している側（ensure_chrome.sh / scent-media）と、壊れたと報告する側（retry.log / session判定器）が別のリポジトリにあるため、片方だけを読んでいては永遠に繋がりません。social-autolike の config/accounts.json に書かれた reuseProfile の設定は、scent-media 側のコードには一切現れません。

修正の骨格

修正の要点は1つです。pkill を全廃し、待つ・見送るに置き換える。

# 修正後の ensure_chrome.sh（概要）
if pgrep -f "user-data-dir=$PROFILE" > /dev/null; then
  # 他プロセスが掴んでいる → 10秒間隔・最大420秒ポーリング
  for i in $(seq 1 42); do
    sleep 10
    pgrep -f "user-data-dir=$PROFILE" > /dev/null || break
  done
  if pgrep -f "user-data-dir=$PROFILE" > /dev/null; then
    echo "他ジョブが使用中(pid=$(pgrep -f "user-data-dir=$PROFILE"))。Cookie破壊を避けるため起動を見送る" >&2
    exit 2   # 「今スロット見送り」の専用コード
  fi
fi
# ここまで来たら誰も掴んでいない → SingletonLock等の掃除 → 起動処理へ

呼び出し側の daily_post.sh は exit 2 を独立した分岐で受け取り、「今スロットは見送り・次スロットで再試行」として exit 0 します。検証は bash -n によるシンタックスチェック2本、grep -c pkill が 0 であること、exit 2 のパスが57行目に実在することを確認し、commit 15307d7 にまとめました。

なぜ exit 2 を「異常」に倒さなかったのか、見送り設計の前提となる「1日3スロット」の意味、そして watchdog が今後同じ構造的な盲点を持たないようにする改修については、次のパートで分解します。

実装の詳細

count_today() と has_today() を絶対に混ぜてはいけない理由

watchdog を書くとき最初に悩むのが「件数ゼロ＝異常か、起動していないだけか」の区別です。sns-output-watchdog.sh ではこれを2つの独立した関数で扱っています。

# 当日分のログ行だけに成功マーカーがあるか数える。
count_today() {
  local file="$1" daymark="$2" marker="$3"
  [ -f "$file" ] || { echo 0; return; }
  /usr/bin/awk -v day="$daymark" -v mark="$marker" '
    index($0, day) { seen = 1 }
    seen && index($0, mark) { n++ }
    END { print n + 0 }
  ' "$file"
}

# そのログに「当日を示す行」自体があるか。
has_today() {
  local file="$1" daymark="$2"
  [ -f "$file" ] || return 1
  /usr/bin/grep -qF "$daymark" "$file"
}

count_today() は「当日マークが出た行以降だけを対象にする」ために awk の seen フラグを使っています。単純な grep -c marker では前日以前の成功行が混入します。ログはローテーションしない設計なので、この1日ずらしが崩れると「昨日投稿できた件数で今日を健全と誤判定」が発生します。

has_today() が重要なのは check() の中の分岐です。

check() {
  local lane="$1" count="$2" min="$3" note="$4" file="${5:-}" daymark="${6:-}"
  # ...
  if [ "$count" -ge "$min" ]; then
    log "ok lane=$lane count=$count"
    return
  fi
  if [ -n "$file" ] && ! has_today "$file" "$daymark"; then
    UNKNOWN="${UNKNOWN:+$UNKNOWN,}$lane"
    log "UNKNOWN lane=$lane 当日行なし"
    return
  fi
  FAILED="${FAILED:+$FAILED,}$lane"
}

件数が min を下回ったとき、has_today() が false を返せば FAILED ではなく UNKNOWN に振り分けます。2つを混在させると、週3回しか起動しないレーンが月曜・水曜・金曜に毎日 UNHEALTHY を出します。アラートが信用されなくなった瞬間に監視は終わります。

count_dead_runs() ——「完走したが成果ゼロ」の run を掴む

count_dead_runs() {
  local file="$1" day="$2"
  [ -f "$file" ] || { echo ""; return; }
  /usr/bin/grep -a "^$day" "$file" 2>/dev/null \
    | /usr/bin/grep -E '終了 \((need-login|circuit-break|error|rate-limit)\)' \
    | /usr/bin/grep -c 'いいね:0' || true
}

2段 grep になっているのには理由があります。1段目の正規表現 終了 \((need-login|circuit-break|error|rate-limit)\) で「有害な終了理由を持つ行」だけに絞り、2段目の grep -c 'いいね:0' で「かつ成果ゼロ」に絞ります。rate-limit で途中終了したが少しいいねを押せたケースを「死んだ run」にカウントすると、夜間の緩やかなレート制限でひっかかるたびにアラートが出ます。2条件の AND で「本当に何もできなかった」に絞るのがポイントです。

この関数は成果ベースの監視ループで使われています。

for lane in x-1 ig-1 ig-2 ig-3 ig-sug th-1 th-2 tt-1 tt-2 tt-3; do
  lf="$SA_LOGS/$lane.log"
  [ -f "$lf" ] || continue
  likes=$(sum_likes_today "$lf" "$TODAY_UTC")
  dead=$(count_dead_runs "$lf" "$TODAY_UTC")
  if [ -n "$likes" ] && [ "$likes" = "0" ]; then
    FAILED="${FAILED:+$FAILED,}$lane-likes0"
    log "UNHEALTHY lane=$lane 本日のいいね合計=0 (成果ゼロrun=${dead:-?}回)"
  elif [ -n "$dead" ] && [ "${dead:-0}" -ge 3 ]; then
    FAILED="${FAILED:+$FAILED,}$lane-dead${dead}"
    log "UNHEALTHY lane=$lane 成果ゼロrunが${dead}回 (いいね合計=${likes})"
  else
    log "OK lane=$lane いいね合計=${likes:-?} 成果ゼロrun=${dead:-0}回"
  fi
done

likes が空文字列の場合（ファイル自体が存在しない）と "0" の場合で分岐が異なります。空の場合は UNKNOWN ではなく単純に skip して次のレーンへ進みます。この微妙な区別が、「監視対象に昇格していないレーン」と「対象なのに動いていないレーン」を混同させない仕組みです。

sum_likes_today() の3段パイプライン

sum_likes_today() {
  local file="$1" day="$2"
  [ -f "$file" ] || { echo ""; return; }
  /usr/bin/grep -a "^$day" "$file" 2>/dev/null \
    | /usr/bin/grep -oE 'いいね:[0-9]+' \
    | /usr/bin/grep -oE '[0-9]+' \
    | /usr/bin/awk '{s+=$1} END {print s+0}'
}

ログの行頭は 2026-08-24 ... 形式で始まるため、"^$day" で当日行に絞るのが1段目です。2段目は grep -oE 'いいね:[0-9]+' でマーカー付き数値を抽出、3段目で数値だけに剥いて awk で合計します。2段 grep を挟んでいる理由は、ログ行に いいね:0 フォロー:3 のように複数のマーカーが出てくることがあり、[0-9]+ だけで抜くと フォロー:3 の 3 まで拾ってしまうからです。

フォロー の集計も同じ構造で sum_follows_today() として独立しています。いいねとフォローは独立した成果であり、いいねが0でもフォローが動いているケースがあるため、必ず別々に判定します。

ensure_chrome.sh ——pkill 廃止から見送り設計へ

修正の核心部分を実際のコードで示します。修正前は1行で解決しようとしていました。

# 修正前：CDP 9223 が応答しない → 無条件で殺す
pkill -f "user-data-dir=$PROFILE"

修正後は3段階です。

# 修正後
if pgrep -f "user-data-dir=$PROFILE" > /dev/null; then
  # 他プロセスが掴んでいる → 10秒間隔・最大420秒ポーリング
  for i in $(seq 1 42); do
    sleep 10
    pgrep -f "user-data-dir=$PROFILE" > /dev/null || break
  done
  if pgrep -f "user-data-dir=$PROFILE" > /dev/null; then
    echo "他ジョブが使用中(pid=$(pgrep -f "user-data-dir=$PROFILE"))。Cookie破壊を避けるため起動を見送る" >&2
    exit 2
  fi
fi
# ここまで来たら誰も掴んでいない → SingletonLock 等の掃除 → 起動処理へ

exit 2 を「異常」（exit 1）に倒さなかった理由は設計上の事実に基づいています。IG カルーセル投稿は1日に19時・21時・23時の3スロットあります。1スロットを見送っても、次スロットで同じコンテンツを投稿できます。一方 exit 1 にすると、毎回 th-scent との衝突時間帯に Discord アラートが飛び続け、真に異常なアラートが雑音に埋もれます。「見送り」は失敗でも成功でもない第三の状態であり、それを専用の終了コードで表すことで呼び出し側の daily_post.sh が独立した分岐で受け取れます。

SingletonLock などの掃除が「誰も掴んでいないと確認できた場合のみ」になっているのも重要です。修正前は pkill の直後に無条件で rm -f SingletonLock SingletonSocket SingletonCookie を実行していました。プロファイルを誰かが使用中にロックファイルを消すと、使用中プロセスがクラッシュしたあとにプロファイルが半壊した状態で残ります。

---

私が詰まった話

「err.log を見ていた」——毎日 UNKNOWN 誤報が出ていた2週間

最初の watchdog 実装では IG 投稿の確認先を間違えていました。

# 🔴 誤り：err.log は 2026-08-09 で更新が止まっている
check "ig-autopost" \
  "$(count_today "$CL_LOGS/sns-ig-autopost.err.log" "$TODAY_JST" 'OK posted')" ...

実際には投稿の成否ログは retry.log に出力されており、err.log は 2026-08-09 を最後に更新が止まっていました。has_today() が false を返し続け、毎朝 ⚠️ SNS監視が判定不能: ig-autopost（当日行がログに無い） が Discord に届きました。

症状だけ見ると「ig-autopost のログが壊れている」に見えます。実際にログが壊れているわけではなく、ファイル名を間違えているだけです。原因特定に2日かかりました。ls -la でファイルの mtime を確認して初めて気づいた話です。コードにはいまもコメントが残っています。

# 成果は err.log ではなく retry.log に出る。err.log は 2026-08-09 で更新が止まっており、
# ここを見ている限り毎日 UNKNOWN 誤報になる(実際は当日3本投稿できていた)。
check "ig-autopost" \
  "$(count_today "$CL_LOGS/sns-ig-autopost.retry.log" "$TODAY_JST" 'OK posted')" ...

ログファイルを参照する監視スクリプトは、参照先ファイルの mtime を定期的に確認する仕組みが無ければ「ファイルが古くなった＝監視が死んだ」に気づけません。2週間誤報を受け取り続けてもアラートが来ない状態と同じです。

TikTok だけ日付フォーマットが違う

TikTok のログは launchd が出力する形式を引き継いでいたため、日付フォーマットが他のレーンと異なっていました。

# X・IG・Threads: TODAY_UTC = "2026-08-24"
# TikTok だけ: TODAY_HUMAN = "Mon Aug 24" （%e で日を空白詰め → "Mon Aug  8"）
TODAY_HUMAN="$(date '+%a %b %e')"

%e は日付を空白詰めで出力するため、8月8日は Aug 8（スペース2つ）になります。"^$TODAY_UTC" で TikTok のログを grep すると、日付形式が全く一致せずに常に 0件 が返っていました。

tt_ok=$(count_today "$CL_LOGS/tiktok-bokuwalily.log" "$TODAY_HUMAN" 'run end (exit 0)')
tt_maybe=$(count_today "$CL_LOGS/tiktok-bokuwalily.log" "$TODAY_HUMAN" 'run end (exit 2)')
check "tt-autopost" "$((tt_ok + tt_maybe))" 1 \
  "TikTok投稿(exit0=$tt_ok exit2=$tt_maybe)" "$CL_LOGS/tiktok-bokuwalily.log" "$TODAY_HUMAN"

修正は TODAY_HUMAN を使う変数を別出しするだけですが、原因特定で詰まった理由は「他のレーンが全部正常に動いているため、TikTok の問題は『TikTok 側の不具合』に見えた」ことです。スクリプト内のフォーマット不整合は、正常なレーンと並べて比較しないと見えません。

「フォロー成功ゼロ・判定不能20件」——friendship API の絞り

2026-08-22 に追加した count_undecidable_today() は、この教訓から生まれています。

count_undecidable_today() {
  local file="$1" day="$2"
  [ -f "$file" ] || { echo "0 0"; return; }
  /usr/bin/awk -v day="$day" '
    index($0, day) && index($0, "follow成功") { success++ }
    index($0, day) && index($0, "follow判定不能") { undecidable++ }
    END { print success + 0, undecidable + 0 }
  ' "$file"
}

friendship API は Instagram の非公開 API で、フォロー関係の確認に使います。API が絞られると「この人は相互フォローか？」が判定できなくなり、ジョブは follow判定不能 を記録しながら先に進みます。いいねは問題なく動いているため、sum_likes_today() のチェックは通過します。外から見ると「ig-1 は今日も healthy」のままです。

実際の症状は ff-ig-2 で2255件の未回収が積み上がった でした。アンフォローできないまま積み上がるため、フォロー上限に近づき、ある日突然フォローも止まります。follow成功=0 かつ follow判定不能>=20 という組み合わせを専用の判定条件として追加しています。

for lane in ff-ig-1 ff-ig-2 ff-ig-3; do
  # ...
  if [ "$follow_success" -eq 0 ] && [ "$undecidable" -ge 20 ]; then
    FAILED="${FAILED:+$FAILED,}$lane-blocked"
    log "UNHEALTHY lane=$lane follow成功=0 判定不能=$undecidable -> friendship APIが絞られている疑い"
  fi
done

「source-follow 全ソース取得失敗」——4回連続で誰にも報告されなかった

source-followers レーンは、フォロー対象を探すためにフォロワーリストを収集するサブプロセスです。2026-08-22 まで監視ループに一切含まれていませんでした。

# 2026-08-22 追加前は、このレーンの成果は一度も監視されていなかった。
# 実害: ig-sug が 23:14/02:13/11:16/14:16 と4回連続で
# 「coverage 0/17 -> 全ソース取得失敗 -> exit 1」になり日次20件で止まっていたのに、
# 誰にも報告されなかった（同時刻に ig-3 も14時間ゼロ成果）。
# 実体は private API の 429。

ig-sug は午後11時・午前2時・午前11時・午後2時の4スロットで 全ソース取得失敗 を出していました。取得対象17アカウントに対してカバレッジ0のまま exit 1 で落ちていましたが、メインレーンである ig-sug.log の sum_likes_today() は別途正常に動いていたため、watchdog のサマリは OK でした。

追加した監視は source-followers-*.log を独立ループで見る形です。

for lane in ig-1 ig-2 ig-3 ig-nagi ig-sug th-1 th-2 th-3 th-nagi x-1 x-2 x-nagi x-reina; do
  sf="$SA_LOGS/source-followers-$lane.log"
  [ -f "$sf" ] || continue
  sf_dead=$(count_today "$sf" "$TODAY_UTC" '全ソース取得失敗')
  if [ "$sf_dead" -ge 2 ]; then
    FAILED="${FAILED:+$FAILED,}$lane-srcfollow-blocked"
    log "UNHEALTHY lane=$lane-srcfollow 全ソース取得失敗=${sf_dead}回 -> APIスロットリング疑い"
  fi
done

sf_dead >= 2 を閾値にしているのは、単発の失敗（一時的な 429）は次の run で自己回復するからです。2回連続で失敗していれば「スロットリングが続いている」と判断できます。

pkill で隣の Cookie を毎日消していた——症状が「ログイン切れ」にしか見えない構造

これが一番タチが悪かった失敗です。症状は明確でした。IG の sns-ig-autopost.retry.log に OK posted が1件もない。watchdog から 🚨 SNS当日未出力: ig-autopost が Discord に届く。セッション判定器は sessionid がない（need-login） と正しく報告する。

毎回 GUI で再ログインしていました。翌朝には復活している。翌夜にはまた消えている。このサイクルが数日続き、「Instagram のセッション有効期間が短くなったのか」という仮説を持ち始めていました。

実際には ensure_chrome.sh が social-autolike の th-scent ジョブが使っているプロファイルを毎晩 pkill していました。th-scent は Playwright で Chrome を起動しますが、CDP ポート 9223 は開きません。ensure_chrome.sh から見ると「9223 が閉じている＝死んでいるプロセス」です。pkill が SIGTERM → SIGKILL を送り、Chrome はシャットダウン処理を完了できず、Cookie SQLite を整合性のある状態で書き戻せません。次の起動時に Chrome は空の Cookie DB を作り直します。

原因が判明したのは、ログの時刻を横並びで比較したときです。

22:56  th-scent unfollow start (.profiles/chrome-ig を掴む)
23:00  daily-post → ensure_chrome.sh → CDP 9223 応答なし
23:00  pkill -f user-data-dir=.profiles/chrome-ig
23:00  Cookie SQLite 破壊 → 空の DB 作り直し
23:00  daily-post: need-login → 投稿ゼロ

「壊している側（ensure_chrome.sh / scent-media）」と「壊れたと報告する側（retry.log / session 判定器）」が別のリポジトリにあるため、片方だけを読んでいても永遠に繋がりません。social-autolike の config/accounts.json にある "reuseProfile": ".profiles/chrome-ig" という設定は、scent-media のコードには一切現れません。

共有資源の在席チェックを「自分の期待するインタフェースが応答するか」で書いてはいけない、という教訓はこのインシデントが初出でした。9223 が閉じているのは「死んでいる」ではなく「自分の流儀で起動されていない」かもしれない。所有者の同定はインタフェース非依存の手段（pgrep / ロックファイル）で行い、kill は「自分が起動したプロセス」にだけ許す——この原則が、commit 15307d7 の pkill 廃止に繋がっています。

つまずきポイント

複数のリポジトリを同じ Mac で走らせる環境で踏んだ落とし穴を整理します。前パートで詳述した「err.log ファイル名の間違い」「TikTok の日付フォーマット差異」「friendship API 絞り」「source-follow 監視漏れ」「pkill による Cookie 破壊」に加えて、同じ構造の穴が別の形でも出てきました。

• アンフォロー監視が丸ごと存在しなかった。 ig-1.unfollow.log / ig-2.unfollow.log / tt-1.unfollow.log などのアンフォローレーンは、2026-08-17 まで監視ループに一切含まれていませんでした。実害は実測値で出ています。ig-1 で72時間超のアンフォロー未回収が712件、ig-2 で2255件まで積み上がり、tt-1 が11回連続でアンフォロー不能になっていたのに、watchdog は毎日 result=healthy を返していました。アンフォローが詰まるとフォロー上限に近づき、数日後にフォローも止まります。直接の症状（フォローが止まった）と根本原因（アンフォローが先に詰まっていた）が1個ずれているため、原因を掘るのに時間がかかります。

• 「いいね試行ゼロ」は「いいね成果ゼロ」と別の異常。 th-2 は likeBudget=400 で毎日起動していましたが、ログを見ると live like の文字列が1行も出ていませんでした。フォローだけ試して circuit-break で終わっていたのです。sum_likes_today() の視点では「いいね合計=0」という1つの判定に見えます。しかし「試みたが全部弾かれた」と「そもそも1回も試みていない」は原因が全く異なります。前者はアカウント制限、後者はセレクタ不一致やアクションフローのバグです。この区別ができるようにしたのが、現在の sns-output-watchdog.sh 244〜259行目にある以下の検知ループです。

# 「起動した」記録があるのに「いいね試行」が0回 = セレクタ不一致/アクション制限の疑い
for lane in x-1 x-4 x-5 ig-1 ig-2 ig-3 ig-sug th-1 th-2 tt-1 tt-2 tt-3; do
  lf="$SA_LOGS/$lane.log"
  [ -f "$lf" ] || continue
  started=$(count_today "$lf" "$TODAY_UTC" '開始 [')
  attempts=$(count_today "$lf" "$TODAY_UTC" 'live like')
  if [ "$started" -ge 1 ] && [ "$attempts" -eq 0 ]; then
    FAILED="${FAILED:+$FAILED,}$lane-noattempt"
    log "UNHEALTHY lane=$lane いいね試行が0回(セレクタ不一致/アクション制限の疑い) 起動=${started}回"
  fi
done

• FAILED と UNKNOWN を混在させるとアラートが信用されなくなる。 週3回しか起動しないレーンを毎日 check() にかけると、起動しない日は当日ログ行が存在しないため件数ゼロと見なされ、毎日 FAILED に積まれます。Discordに「🚨 SNS当日未出力: lane-X」が週4日届き続けると、ある日の真の障害アラートが「また来てる」として読み飛ばされます。アラートが信用されなくなった瞬間に監視インフラは終わりです。has_today() で「当日ログ行が存在するか」を確認し、行が無ければ UNKNOWN に振り分ける分岐を入れた後、誤報率が体感で9割以上落ちました。

• UTC と JST の混在は「時間帯によってだけ壊れる」バグになる。 TODAY_JST と TODAY_UTC の差は9時間です。日本時間の深夜0時〜9時に動くジョブが TODAY_UTC で集計すると、ログの 2026-08-24 という文字列が前日UTC日付と一致してしまい、深夜に完走した成果が「昨日の成功」としてカウントされます。今日の監視上は0件に見え、FAILED アラートが飛びます。昼間に動かすと問題なく通過するため「たまに誤報が出る」に見えて原因特定が遅れます。sns-output-watchdog.sh の先頭でこの混在を明示しています。

TODAY_JST="$(date '+%Y-%m-%d')"
TODAY_UTC="$(date -u '+%Y-%m-%d')"
TODAY_HUMAN="$(date '+%a %b %e')"  # launchdが出す形式。日は空白詰めなので %e

3変数を使い分け、各ログがどちらで出力されているかを一致させることで解消しましたが、新しいレーンを追加するたびに確認が必要です。

• Discord 通知がサイレントに飛んでいない場合がある。 notify() 関数は [ -f "$DISCORD" ] || return 0 で discord_tool.py が存在しない場合は通知せずに正常終了します。watchdog のログには result=unhealthy lanes=ig-1-likes0 と正しく書かれているのに、Discord には何も届かない状態が起き得ます。設置初日にパスが間違っていてサイレントに通知が飛ばなかった実績があります。監視スクリプトが「ちゃんとアラートを上げているか」自体を確認するには、通知の受信側（Discord の最終受信時刻）で確認する必要があります。watchdog のログだけを見ていると永遠に気づきません。

• 参照先ログファイルが古くなっても誰も気づかない。 has_today() は「当日行があるか」を確認しますが、「そのファイルが最近まで更新され続けているか」まで保証しません。ジョブが止まった直後は has_today() も false を返して UNKNOWN になりますが、ファイルが存在して当日行がある状態——つまり「今日1回は動いたが、その後の run が全部サイレント失敗している」——は検知できません。参照先ログの mtime を定期的に確認する仕組みが無いと、監視が「古い証拠で今日を判定し続ける」状態に陥ります。

• 複数リポジトリにまたがる共有設定は「設定ファイルにだけ書かれている」。 social-autolike/config/accounts.json に "reuseProfile": ".profiles/chrome-ig" と書かれていても、scent-media/scripts/ensure_chrome.sh のコードにはそのプロファイルが別リポジトリにも使われているという記述は一切ありません。普段は別々に git log / git diff を見て作業するので接点が見えないまま衝突が起き続けます。学習ノート learning/shared-resource-kill-corrupts-the-neighbor.md に今回の教訓として書きました：「共有を設定する側ではなく、共有される側のコードに書く」——これが発見コストを最小化する唯一の方法です。

• 完走した run のうち「本当に何もできなかった run」は成果ゼロとは別に集計が要る。 rate-limit で早期終了したが2件だけいいねを押せたケースを「死んだ run」にカウントすると、夜間の緩やかなレート制限で毎晩アラートが出ます。count_dead_runs() が「有害な終了理由（need-login / circuit-break / error / rate-limit）かつ いいね:0 の AND 条件」に絞っているのはこのためです。AND を OR にするだけで誤報率が跳ね上がります。

---

ベストプラクティス

実際に踏んで直した設計原則を、再現性のある形でまとめます。

1. 共有資源の在席チェックはインタフェース非依存で行う

「CDP ポート 9223 が応答するか」は「Chrome が起動しているか」ではなく「自分の流儀で起動された Chrome が動いているか」の確認です。他者が起動した同じプロファイルの Chrome はポートを開かなくても存在します。プロセスの在席確認は pgrep -f "user-data-dir=$PROFILE" のように PID ベースで行い、インタフェースの応答可否に依存しないこと。

2. kill は「自分が起動したプロセス」にだけ許す

pkill -f <pattern> はパターンに一致する全プロセスを落とします。そのプロセスを誰が起動したかは問いません。他者が起動した可能性が1%でもあるなら、kill の代わりに「待って見送る」に倒してください。プロセスを誤爆したコストは「今回の失敗」ではなく「復旧までの全スロット＋人間の GUI 作業」です。

3. 確保できない資源は「上限付きポーリング → 専用 exit コード」で返す

# 10秒間隔・最大420秒ポーリング
for i in $(seq 1 42); do
  sleep 10
  pgrep -f "user-data-dir=$PROFILE" > /dev/null || break
done
if pgrep -f "user-data-dir=$PROFILE" > /dev/null; then
  echo "他ジョブが使用中。Cookie破壊を避けるため起動を見送る" >&2
  exit 2   # 「今スロットは見送り」
fi

exit 1（異常）に倒すと、毎スロットの衝突で Discord アラートが飛び続け、真の障害が埋もれます。1日3スロットある設計では「1回見送り＝損失ほぼゼロ」という設計上の事実があるときだけ、exit 2 を「見送り＝正常」として扱えます。アラートを上げる価値がない状態には専用コードを割り当て、呼び出し側が独立分岐で処理する。

4. exit code ではなく「成果ログ」で監視する

exit 0 は「落ちなかった」を意味するだけです。2026-08-08 の実測で ig-1 は12run中8run、tt-1 / tt-2 は6割がいいね0件のまま exit 0 で終わっていました。監視が exit code だけを見ていた期間、この状態が2週間続いても誰も気づかなかった。成果の有無は実際のいいね数・フォロー数・投稿数をログから awk で集計して判定すること。

5. 「0件」と「当日行なし」を必ず分岐で区別する

check() {
  # ...
  if [ "$count" -ge "$min" ]; then return; fi        # 健全
  if ! has_today "$file" "$daymark"; then
    UNKNOWN="${UNKNOWN:+$UNKNOWN,}$lane"; return      # 判定不能
  fi
  FAILED="${FAILED:+$FAILED,}$lane"                   # 異常
}

週3回しか起動しないレーンが4日連続で FAILED を出し続けると、アラートが「また来てる」になります。「今日は起動しない日だった」と「今日起動したが0件だった」を同じアラートに束ねないこと。

6. 成果ゼロ・試行ゼロ・完走ゼロを3段階に分ける

監視の精度は3段階で上がっていきます。

第3段を入れるまで、th-2 のセレクタ不一致は半月以上見えていませんでした。

7. 成果の種類ごとに独立した監視ループを持つ

投稿・いいね・フォロー・アンフォロー・ソース収集はそれぞれ別の処理で別の失敗モードを持ちます。1つのループで全部を見ようとすると、異なる「成果の定義」が混在して誤判定が起きます。sns-output-watchdog.sh は現在、投稿チェック・成果ベースいいね検証・フォロー検証・アンフォロー検証・source-follow 検証・試行ゼロ検知の6ループを独立して持っています。冗長に見えますが、この分離がなければ「ig-2 で2255件のアンフォロー積み上がり」は発見できませんでした。

8. 全レーンが一元管理されているか定期的に棚卸しする

新しいレーンを追加したとき、監視ループへの追加を忘れることがあります。source-followers-*.log は2026-08-22まで監視に含まれておらず、ig-sug が4回連続で全ソース取得失敗を起こしても誰にも報告されませんでした。月1回、起動しているジョブ一覧と監視ループ対象の一覧を突き合わせて、監視されていないレーンがゼロか確認することをルーティンに入れること。

9. 日付フォーマットを揃え、例外があれば変数名で明示する

date '+%Y-%m-%d' と date -u '+%Y-%m-%d' と date '+%a %b %e' の3種類を使い分けるなら、各ログがどのフォーマットで出力しているかを先に確認してから変数に対応させること。launchd が出力するタイムスタンプは %e（空白詰め）形式になる場合があります。Aug 8 と Aug 8 は grep で一致しません。変数名 TODAY_HUMAN のように**「他と形式が違う」という意味を変数名に込める**と、後から読んだ人間が気づきやすくなります。

10. リポジトリをまたぐ共有は「参照される側」のコードに注記する

「参照する側の設定ファイルに書く」だけでは、参照される側のコードを読む人間には見えません。ensure_chrome.sh を読む実装者が「このプロファイルは social-autolike の th-scent も reuseProfile で使っている」を知っていれば、pkill を書く前に立ち止まれます。共有資源には「誰が何の目的で使っているか」をコメントで書き、参照される側のコード内に置くこと。

11. プロセスを強制終了すると永続状態が壊れる前提で設計する

SIGKILL を受けたプロセスはシャットダウンハンドラを実行できません。Chrome の場合、Cookie SQLite を整合性のある状態で書き戻せないまま終了し、次の起動時に空の DB を作り直します。実測値として、instagram.com の Cookie が0行まで縮んだことが確認されています。SQLite・キャッシュ・セッション情報を持つプロセスを強制終了する場合は、永続状態が壊れる前提でリカバリ手順を先に用意するか、そもそも強制終了しない設計に切り替えること。

12. 通知基盤が動いているかどうかを、通知の受信側から確認する

watchdog のログが result=unhealthy と記録していても、Discord に何も届いていないケースがあります。notify() 関数は discord_tool.py のパスが存在しなければサイレントに return 0 します。スクリプトは「通知を試みた」という記録だけを残します。監視が正しく機能しているかを確認するには、watchdog のログだけを見ていては不十分です。Discord の最終受信時刻を別途確認するか、定期的に「テスト通知」を送信して受信側から疎通確認することが必要です。

13. 見送りは失敗でも成功でもない——専用の終了コードで第三の状態を表す

exit 0 = 成功 / exit 1 = 失敗 の2値で足りない場面があります。「今スロットは条件が揃わなかったので見送った」は成功ではないが失敗でもない。exit 2 を「今スロットは見送り」として割り当て、呼び出し側がそれを「次スロットで再試行・exit 0 として扱う」独立した分岐を持つことで、アラートノイズを増やさずに状態を正確に伝えられます。この設計が成立する前提は「1日複数スロットある」という設計上の事実です。スロットが1日1回しかないジョブに見送り設計は合いません。

---

まとめ

今回のインシデントを一言で圧縮すると「自分の自動化が、自分の別の自動化の永続状態を毎日壊していた」です。

壊す側（ensure_chrome.sh / scent-media）と壊れたと報告する側（sns-ig-autopost.retry.log / session 判定器）は別のリポジトリにあり、それぞれが正しく動いていました。ensure_chrome.sh は「CDP 9223 が応答しない Chrome プロセス」を正しく検出していた。session 判定器は「IG sessionid がない」と正しく報告していた。人間が見ると「IG がログイン切れを起こした」にしか見えません。

これが最もタチの悪い障害の構造です。「報告が正しい、でも原因が別のところにある」——この型は、症状をどれだけ詳しく追っても原因に辿り着きません。sns-output-watchdog.sh の成果ログと launchd の起動時刻を横並びで照らし合わせ、22:56 の th-scent unfollow 開始と 23:00 の ensure_chrome.sh 実行が4分差であることを確認したときに初めて、2つのリポジトリが接続しました。学習ノート learning/shared-resource-kill-corrupts-the-neighbor.md に記録した一般形がそのまま今後の設計判断の基準になっています。

修正のコアは pkill を1行削ることです。pkill -f "user-data-dir=$PROFILE" を抜き、10秒間隔の最大420秒ポーリングと exit 2（見送り）に置き換えた commit 15307d7 は、コードとして10行も増えていません。しかし「同じプロファイルを別リポジトリが使っている」という文脈が無ければ、その1行を削る判断にたどり着けません。

sns-output-watchdog.sh は現在270行超のスクリプトになっています。X 投稿・いいね・リプライ / IG 投稿・いいね・フォロー・アンフォロー / Threads 2アカウント / TikTok / source-followers 13レーン——それぞれが異なる成果定義を持ち、独立した集計関数で毎日判定されます。最初のバージョンは「exit code が 0 なら健全」だけを見ていました。そこから count_today() / has_today() / count_dead_runs() / sum_likes_today() / count_undecidable_today() と関数が増えるたびに、見えていなかった「無音の失敗」が1つずつ浮かび上がってきました。

SNS 基盤を「建てた」だけで終わらせると、壊れた瞬間から「動いている体で止まっている」状態になります。IG 投稿が7/29から止まったまま2週間気づけなかったのが出発点でした。171本のジョブが動いているかどうかではなく、171本のジョブが実際に成果を出しているかどうかを毎日確認できる仕組みの上に、今の月商120万の基盤は乗っています。

自動化は「動かす工程」と「監視できる状態にする工程」の2つがセットです。どちらが欠けても、「今月うまくいっているのか失敗しているのか」を自分で把握できません。把握できなければ、次の打ち手を判断できません。

---

仕組みの全体像・月120万の内訳・30日手順は有料noteにまとめています。

📕 Claude Code自律環境で、実際どう稼ぐか ― 仕組み・実例・始め方・サポート

---

Lily（@bokuwalily）― 個人開発者。Claude Code で自動化基盤を組みながら、iOSアプリやWebサービスを量産しています

• AIで「寝てても回る仕組み」を作って月120万にした話は noteの有料記事 に💰
• OSS: github.com/bokuwalily 🐙
• 最新情報・お問い合わせは X @bokuwalily へ🌍
• AI導入・自動化の相談と実装テンプレ7本の配布は 公式LINE から💬

皆さんの ❤️ やシェアが励みになります！