🟢 exit 0 が嘘をつく ─ 自己締切で止まった自動化は3日ストリークで検知する

月10万の副業から始めて掛け持ちで月60万まで伸ばし、会社都合で一夜にしてゼロになり、半年でClaude Codeの自律実行環境を一から組み直して今は月商120万です。この連載は、その過程で踏んだ穴と拾った設計を書き記すものです。

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

2026年8月の話です。IGのエンゲージジョブ（ig_engage.py）が毎日 exit 124 で終わっていました。

exit 124 は SIGKILL です。launchd がジョブを強制終了したときのコードです。browser-slot.sh 内のPerlスーパーバイザーが、設定タイムアウトを過ぎた瞬間に alarm $timeout; ... exit 124 if $timed_out; を叩く構造になっていて、フレームワーク全体の「タイムアウトしたら exit 124 で終われ」という設計に従っています。

ログを掘ると毎日同じでした。TIMEOUT: killed after 2400s。

コードは1行も壊れていませんでした。likes の上限は62、follows は24、unfollows は15、合計最大101アクション。アクション間の待機はランダムで最小20秒・最大60秒、平均40秒。起動時にランダムジッター最大900秒。どの数字も単独で見ればまともです。

ただし、掛け算を一度もしていませんでした。

101アクション × 平均40秒 = 4,040秒
+ 起動ジッター最大 900秒
────────────────────────
最大所要時間         4,940秒
実行枠（BROWSER_SLOT_TIMEOUT_SEC） 2,400秒

4,940 ÷ 2,400 ≒ 1.7倍。設定値はどれも正しく、組み合わせだけが破綻していました。コードレビューでは絶対に見つからない類の問題です。どの行を読んでも「正しい」と判断されます。

SIGKILLの実害はもう一つありました。Playwright の finally: ctx.close() を通らないため、Chromium プロセスが孤児化して積み上がり続けます。~/.cache/lily-browser-slots/slot.log には毎朝 result=timeout:2400s が並んでいましたが、本当の影響はそこではなく、マシン全体のロードが青天井に上がっていく方でした。

修正の方向は「capsを下げる」ではありませんでした。 caps はそのままエンゲージメント施策の上限です。下げれば成長施策が縮みます。変えるべきは実行時間の使い方でした。「SIGKILLされる前に自分から止まって exit 0 で返す」。上限に到達しないまま終われるように、スクリプト自身が締切を計算して、その前に走行を打ち切る設計に変えました。

ここで新しい問題が生まれます。

exit 0 は嘘をつきます。

ig_engage.py は毎日緑で終わるようになりました。launchd はジョブが成功したと記録します。ダッシュボードのステータスは問題なし。でも実際には、101アクション中60しか終わっていない日があります。予算が切れたから打ち切ったのに、ログ上は「正常終了」です。

これがサイレントサクセスです。自動化が正しく動いているように見えるが、成果は半分で静かに止まっている状態。定期実行の怖さはここにあります。手作業なら「あれ、今日少ないな」と気づきます。自動化は気づかせてくれません。毎日 exit 0 が返ってくるから、誰も疑いません。フォロー数が伸びなくても「アルゴリズムかな」と思います。実際は、毎日40アクションで止まっているだけです。

打ち切りを正常終了にした瞬間に、「静かに止まる仕組みを静かに監視する」仕組みが必要になります。

これは作業の話ではありません。環境の問題です。

自動化の本質的な価値は「寝ている間も動く」ことです。でも「寝ている間も動いているふり」になった瞬間、その価値は消えます。しかも気づかないまま消えます。

読者の皆さんが設定した自動化が今日も正常終了しているとして──それは「想定どおりの成果を出した正常終了」でしょうか。それとも「途中で打ち切った正常終了」でしょうか。exit code だけでは区別がつきません。

この区別をつける仕組みとして設計したのが、「3日連続打ち切りで1日1回だけアラート」という閾値です。

1日では鳴らしません。

重い日は1回の打ち切りで終わることがあります。前日にフォロワーが急増してエンゲージが増えた、APIが重かった、別のジョブと枠が競合した──単発の理由はいくらでもあります。1日で鳴らすと、本当に問題になる前に狼少年になります。通知が毎日来ると、人間は読まなくなります。

毎日は鳴らしません。

3日連続で打ち切りが起きていれば、それは構造問題です。capsと実行時間のバランスが恒常的にずれています。でもその事実を毎日アラートにしても意味がありません。「また来た」になるだけで、対処する気にならない。

3日連続という閾値は「単発ノイズの外」にあり、1日1回という頻度は「対処できる量」に収まっています。この2つの失敗の間に、ちょうど良い点があります。

全体の流れ

構造をひとつの図で示します。

launchd が ig_engage.py を起動
        │
        ▼
  compute_budget()
  ┌─────────────────────────────────────────────┐
  │ 1. IG_ENGAGE_BUDGET_SEC（環境変数）を読む    │
  │ 2. なければ BROWSER_SLOT_TIMEOUT_SEC を読む  │  ← 2,400秒
  │ 3. どちらもなければ 0（全判定を無効化）      │
  │ deadline = START_TS + budget - 120秒         │  ← BUDGET_MARGIN_S
  └─────────────────────────────────────────────┘
        │
        ▼
  起動ジッター（ランダム待機）
  ┌───────────────────────────────────────┐
  │ wait = min(900, (deadline - now) × 0.2) │  ← 残予算の20%でクランプ
  └───────────────────────────────────────┘
        │
        ▼
  アクションループ（likes → follows → unfollows）
  ┌──────────────────────────────────────────────────────┐
  │ ループ先頭: if blocked["hit"] or over_budget(): break │  ← 既存判定に相乗り（4箇所）
  │                                                        │
  │ over_budget() の内訳:                                 │
  │   残予算 < action_min_s(20秒) → True                 │
  │   deadline を過ぎている        → True                 │
  │                                                        │
  │ action_sleep() で待機するとき:                        │
  │   sleep時間を残予算内に収める                         │
  └──────────────────────────────────────────────────────┘
        │
        ▼
  return 0  ← exit 124 の代わりに "正常終了"
  （ブロック検知・ログイン切れの exit 1 経路は一切触れない）
        │
        ▼
  state/engage_budget.json を更新
  ┌─────────────────────────────────────────┐
  │ {                                         │
  │   "streak": N,          // 連続打ち切り回数 │
  │   "last_date": "YYYY-MM-DD",              │
  │   "last_alert_date": "YYYY-MM-DD"         │
  │ }                                         │
  └─────────────────────────────────────────┘
        │
        ├── 今日も打ち切りだった場合
        │       streak += 1
        │       streak ≥ 3 かつ last_alert_date ≠ today
        │              ↓
        │         alerts へ通知（1日1回だけ）
        │         "capsが実行時間に対して過大：予算到達での打ち切りが
        │          N日連続（likes XX/62, follows XX/24, unfollows XX/15）"
        │
        └── 打ち切りなしだった場合
                streak = 0 にリセット

コードの変更量は想像より少ないです。新しい制御構造やクラスは作っていません。既存の if blocked["hit"]: という判定が4箇所あり、それぞれに or over_budget() を追加しただけです。打ち切り時の処理は return 0 の1行。新機能の既定値は「何もしない側」に置くというルールどおり、compute_budget() が予算を取れない（値が 0 または未設定）ときは deadline = None にして全判定を無効化し、既存の挙動を1ミリも変えません。 環境変数が消えた瞬間にジョブが止まる作りにしない、というのが原則です。

起動ジッターのクランプが min(900, (deadline - now) × 0.2) になっている理由も算術です。元の start_jitter_max_s=900 をそのまま使うと、残予算2,400秒のうち最大900秒がジッターで消えます。比率にして37.5%。アクション前の待機だけで予算の4割近くが飛ぶ計算です。残予算の20%という上限を設けることで、jitterが長くなってもアクション本体の時間が確保されます。2,400秒の20%は480秒なので、元の900秒より短く、かつ短い予算のときほどjitterも短くなります。

browser-slot.sh が BROWSER_SLOT_TIMEOUT_SEC をタイムアウト設定として渡し、Perlスーパーバイザーが時間超過時に exit 124 を返す構造は変わりません。ig_engage.py が自分から締切前に終われば、スーパーバイザーは exit $? >> 8（=exit 0）を返します。exit 124 がログに出なくなった時点で、外側のフレームワーク観点では「正常動作している」になります。

だからこそ内側のストリーク監視が要ります。外から見て緑なのに、中では毎日40アクションで止まっている──その差を検知できるのは、ジョブ自身が自分のパフォーマンスを記録しているときだけです。

実装の詳細

browser-slot.sh が外側の締切を作る

まず全体の外枠を整理します。ig_engage.py は直接 launchd から起動されるのではなく、browser-slot.sh を経由して起動されます。この shell スクリプトが「何個まで並列で Chromium を動かすか」を制御するスロット管理層です。

スクリプトの中核は Perl で書かれたスーパーバイザーです。bash ヒアドキュメントで埋め込まれていて、実行時に perl -e で展開されます。

my $timed_out = 0;
local $SIG{ALRM} = sub { $timed_out = 1; stop_tree(); };
alarm $timeout;
while (waitpid($child, 0) == -1) {
  next if $!{EINTR};
  exit 1;
}
alarm 0;
exit 124 if $timed_out;
exit $? >> 8;

alarm $timeout でタイマーをセットし、子プロセスが終了するまで waitpid で待ちます。タイムアウトが来ると SIGALRM で $timed_out = 1 がセットされ、stop_tree() が走ります。stop_tree() は /bin/ps -axo pid=,ppid= でプロセスツリーを構築し、子孫全員に TERM → KILL の順で送信します。

sub stop_tree {
  return if $stopping++;
  my @pids = descendants($child);
  kill "TERM", reverse(@pids), $child;
  select undef, undef, undef, 1;
  kill "KILL", grep { kill 0, $_ } reverse(@pids), $child;
}

ここが重要です。kill "KILL" はプロセスに SIGKILL を送ります。Playwright が async with browser.new_context() as ctx: の finally ブロックで ctx.close() を呼んでいても、SIGKILL には抗えません。finally は実行されず、Chromium プロセスが孤児として残ります。

browser-slot.sh の末尾では exit code によって RESULT を分けます。

if [ "$status" -eq 124 ]; then
  echo "TIMEOUT: killed after ${TIMEOUT_SEC}s"
  RESULT="timeout:${TIMEOUT_SEC}s"
else
  RESULT="exit:$status"
fi

つまり ig_engage.py が自分から exit 0 で終わった場合、$? >> 8 は 0 になり、bash 側のステータスも 0 です。RESULT は exit:0 としてログに記録されます。スーパーバイザーの exit 124 に到達しない限り、タイムアウトとは記録されません。これが「内側から先に止まる」設計の効果です。

deadline の算出と compute_budget()

Python 側の実装は compute_budget() という関数から始まります。環境変数の読み取り順序は3段階になっています。

def compute_budget() -> float | None:
    for key in ("IG_ENGAGE_BUDGET_SEC", "BROWSER_SLOT_TIMEOUT_SEC"):
        val = os.environ.get(key, "")
        if val.strip().isdigit() and int(val) > 0:
            return float(val)
    return None

IG_ENGAGE_BUDGET_SEC を先に読む理由は、ジョブ固有の予算を BROWSER_SLOT_TIMEOUT_SEC と切り離せるようにするためです。スロット側のタイムアウトを変えずに、エンゲージジョブだけ予算を絞りたい場面があります。両方なければ None を返します。

呼び出し側では deadline をこう決めます。

BUDGET_MARGIN_S = 120  # スーパーバイザーがSIGKILLを送る前に確実に終わるための余裕

budget = compute_budget()
if budget is not None:
    deadline = START_TS + budget - BUDGET_MARGIN_S
else:
    deadline = None  # 全判定を無効化

BUDGET_MARGIN_S = 120 という120秒の余裕は、スーパーバイザーの alarm $timeout が鳴るより先に Python 側が return 0 まで到達するためのバッファです。最後のアクションが終わってから engage_budget.json を書いてアラートを送るまでの時間を見込んでいます。

deadline が None のとき、続く over_budget() は常に False を返します。つまり環境変数が消えた瞬間、スクリプトは無制限に動くのではなく、スーパーバイザー任せの以前の状態に戻ります。新機能の既定値は「何もしない側」に置くという原則です。

over_budget() は既存の判定点に相乗りする

ig_engage.py のアクションループには4箇所の中断判定がありました。もともとはブロック検知だけが目的でした。

# 変更前（ブロック検知のみ）
if blocked["hit"]:
    break

# 変更後（予算チェックを相乗り）
if blocked["hit"] or over_budget():
    break

この4箇所に or over_budget() を追加しただけです。新しい if ブロックもクラスも作っていません。over_budget() の中身はこうです。

def over_budget() -> bool:
    if deadline is None:
        return False
    now = time.time()
    if now >= deadline:
        return True
    remaining = deadline - now
    return remaining < ACTION_MIN_S  # 20秒

「残り20秒未満なら打ち切る」という判定が入っています。20秒は action_min_s の値です。次のアクションを始めても途中でスーパーバイザーに打ち切られる可能性が高い、という計算です。中途半端に始めるより、今の時点で return 0 して記録を残す方が良い。

アクション間の待機 action_sleep() も予算内に収めます。

def action_sleep(min_s: float, max_s: float) -> None:
    if deadline is not None:
        remaining = deadline - time.time()
        max_s = min(max_s, remaining - ACTION_MIN_S)
        if max_s <= 0:
            return  # 待たずに即返す
    time.sleep(random.uniform(min_s, min(min_s, max_s)))

「残予算から次のアクション1回分（20秒）を引いた値」が待機の上限です。残りが20秒を下回っていればスリープせず即返します。次の over_budget() チェックで打ち切られます。

ジッタークランプの算術

起動ジッターのコードは1行です。

wait = min(START_JITTER_MAX_S, (deadline - time.time()) * 0.2)

START_JITTER_MAX_S はもともと 900 秒でした。元の設計では「起動時刻を分散させるためランダム最大900秒待つ」という意図でした。しかし予算 2,400 秒に対して最大 900 秒のジッターは 37.5% です。4割近くが待機だけで消えます。

残予算の20%という上限を設けることで、予算が長ければジッターも長く（分散効果を維持）、予算が短ければジッターも短くなります（アクション時間を食わない）。2,400秒の20%は480秒なので、元の900秒よりは短い。

実際に計算してみます。

deadline = START_TS + 2400 - 120 = START_TS + 2280秒
起動直後の残予算 ≒ 2280秒
20% = 456秒
min(900, 456) = 456秒

これで起動ジッターは最大456秒に収まります。残りの1,824秒でアクションを処理します。101アクション×平均40秒=4,040秒には届きませんが、2,280秒では72アクション相当です。全量は処理できないものの、SIGKILLなしで正常終了できます。

ストリーク管理の実装

state/engage_budget.json の構造はシンプルです。

{
  "streak": 2,
  "last_date": "2026-08-14",
  "last_alert_date": "2026-08-12"
}

ジョブ終了時にこのファイルを更新します。打ち切りが起きたかどうかは、実行したアクション数と caps の比較で判定します。

was_truncated = (
    likes_done < LIKES_CAP or
    follows_done < FOLLOWS_CAP or
    unfollows_done < UNFOLLOWS_CAP
) and budget_hit  # 上限到達で打ち切った場合のみ

budget_hit フラグを別に持つのは、「ブロック検知で止まった」場合と「予算切れで止まった」場合を区別するためです。ブロック検知による中断はストリークに加算しません。あくまで「caps × delays の掛け算が枠に収まっていない」という構造問題を数えたい。

アラート条件は2つの and です。

today = datetime.date.today().isoformat()
if streak >= 3 and state.get("last_alert_date") != today:
    send_alert(
        f"capsが実行時間に対して過大：予算到達での打ち切りが{streak}日連続\n"
        f"likes {likes_done}/{LIKES_CAP}, "
        f"follows {follows_done}/{FOLLOWS_CAP}, "
        f"unfollows {unfollows_done}/{UNFOLLOWS_CAP}"
    )
    state["last_alert_date"] = today

last_alert_date != today という条件が「1日1回だけ」を実現しています。streak >= 3 を満たした日に通知が飛び、その日中に何度ジョブが走っても last_alert_date が今日付けになっているので重複しません。翌日も streak が 3 以上を維持していれば、また1通飛びます。

---

私が詰まった話

設計として「正しい」実装が、動かしてみると別の問題を生み出すという経験が3回ありました。

詰まり①　TypeError で全アクションが止まった

deadline=None のとき over_budget() は False を返す、という設計は正しかったです。問題は action_sleep() の方でした。

# バグのあった版
def action_sleep(min_s, max_s):
    remaining = deadline - time.time()  # deadline が None → TypeError
    max_s = min(max_s, remaining - ACTION_MIN_S)
    ...

deadline を None チェックせずに参照していました。症状は「ジョブが起動直後に死ぬ、exit code 1」です。BROWSER_SLOT_TIMEOUT_SEC が設定されていない開発環境でのみ発生したので、本番では1週間気づきませんでした。

# slot.log で確認したログ
2026-08-09T06:01:03+0900 label=ig-engage group=engage result=exit:1
2026-08-10T06:01:14+0900 label=ig-engage group=engage result=exit:1

result=exit:1 はブロック検知と区別がつきません。ログの見た目はブロックと同じです。それが発見を遅らせた原因でした。

直し方は単純です。action_sleep() の先頭にガードを入れました。

def action_sleep(min_s, max_s):
    if deadline is None:
        time.sleep(random.uniform(min_s, max_s))
        return
    remaining = deadline - time.time()
    ...

学んだことは「deadline=None を無効化として設計するなら、deadline を参照する全箇所に None チェックが要る」です。当たり前ですが、over_budget() だけ直して action_sleep() を見落とすのは十分起きます。

詰まり②　起動ジッターで予算を全部使い切っていた

クランプを入れる前の話です。予算2,400秒に対して起動ジッターが最大900秒でした。ジッターが長く引かれた日は、起動後に残予算が1,500秒しかなく、even that was not the issue.

実際の問題は、over_budget() のチェックより前にジッターが走るという順序でした。ジッターで900秒待ちながら、その間に deadline を過ぎていた日がありました。ジッター終了時点で残予算がマイナスになっており、最初の over_budget() チェックで即打ち切り、0アクションで return 0 しました。

# state/engage_budget.json を確認
{"streak": 1, "last_date": "2026-08-05", "last_alert_date": null}
# ただし likes_done=0, follows_done=0 という状況

likes が 0 なのに打ち切りのストリークが積まれる。アラートはまだ来ない。でも1日分の処理が完全にスキップされていました。

クランプを入れる前にやるべきだったことは、ジッターも予算から引くという意識を最初から持つことでした。「ジッター・待機・アクション時間」の全部を足し合わせて、実行枠に収まるかチェックする。部分最適の積み重ねで全体が壊れます。

詰まり③　3日連続で鳴るはずの通知が来なかった

ストリークが3を超えても通知が来ない日がありました。ログを掘ると streak が毎日リセットされていました。

// 月曜
{"streak": 1, "last_date": "2026-08-11"}
// 火曜
{"streak": 1, "last_date": "2026-08-12"}  // ← 積み上がっていない

原因は last_date の更新ロジックでした。初期実装では「今日打ち切りが起きたか」を「今日の日付が last_date と一致するかで判定」していました。

# バグのあった版
today = datetime.date.today().isoformat()
if was_truncated:
    if state.get("last_date") == today:
        pass  # 今日は既にカウント済み
    else:
        state["streak"] = state.get("streak", 0) + 1
        state["last_date"] = today

一見正しいように見えます。でも else ブランチで last_date を今日に更新するとき、前日の last_date が昨日以外のケースを想定していませんでした。ジョブが2日間スキップされた（スロット競合で skip:global-limit になった）後に再開すると、streak が前日まで戻らずリセットされます。

正しくは「前日が打ち切りだったか」を streak の継続条件にすることです。

today = datetime.date.today()
yesterday = (today - datetime.timedelta(days=1)).isoformat()
today_str = today.isoformat()

if was_truncated:
    if state.get("last_date") == yesterday:
        state["streak"] = state.get("streak", 0) + 1
    elif state.get("last_date") != today_str:
        state["streak"] = 1  # 連続が途切れた、1から再スタート
    state["last_date"] = today_str
else:
    state["streak"] = 0
    state["last_date"] = today_str

「昨日が打ち切り」なら継続、「昨日以外の日に打ち切り記録がある」なら streak を1にリセット、という判定です。これで2日スキップ後に再開しても、連続カウントが誤って継続されなくなります。

この修正を入れてから1週間後、初めてアラートが飛んできました。「capsが実行時間に対して過大：予算到達での打ち切りが3日連続（likes 58/62, follows 18/24, unfollows 10/15）」。通知が来て初めて、「連続3日という意味でのバランス崩れ」が確認できました。

共通する失敗の型

3つの詰まりに共通する型があります。

実装が「どこか」は正しいが、「接続部分」が抜けている。

deadline=None は over_budget() では動くが action_sleep() では動かない。クランプはアクション時間には効くがジッターには効かない。last_date の更新はカウント継続には使えるが連続性の定義が緩い。どの箇所も単独で読めば「正しい」ように見えます。問題は複数の部品がつながる境目にあります。

自動化の怖さはここです。接続部分のバグは、実行が成功している（exit 0）ので発覚が遅れます。ログを見ても「正常」に見えます。数字を時系列で並べて「増えるべきものが増えていない」と気づくまで、静かに間違ったまま動き続けます。

ストリーク監視を作ったのは、そういう「静かに動いているが中身は半分」な状態を数字として可視化するためでした。ただし監視コード自体も詰まります。監視の監視まで作る気にはなれないので、監視コードは「シンプルに、ロジックが一目でわかる行数に」という方針で書いています。複雑な監視コードはそれ自体がバグの温床になります。

つまずきポイント

前節で deadline=None 参照漏れ・ジッター予算超過・streak の last_date バグの3件を詳述しました。ここではそれらを含め、同じ窓で出た全失敗を集約します。

• caps × delays の積を一度も計算しなかった。likes 62／follows 24／unfollows 15 = 最大101アクション、平均待機40秒。101 × 40 = 4,040秒。実行枠 BROWSER_SLOT_TIMEOUT_SEC=2400 の1.7倍。コードの1行も間違っていない。どの設定値も単独で見ればまとも。積だけが破綻していました。

• 上限を「名目値×0.8」で削ったが実績に届かなかった。Claudeクォータ枯渇で2026年8月13日に投稿0本になったとき、全レーンを一律2割カットしました。しかし x-autoreply の実績は63〜93、上限は150です。150×0.8=120では実績93に届きません。削れたように見えて何も削れていませんでした。正しい上限は実績×0.8で置く必要があります。ig-autoreply は OPEN_POLICY ? Infinity をやめて160（実績200の8割）に変えました。上限が「実行を縛る値」ではなく「実行の記述」にしかなっていない場面があります。

• SIGKILLでChromiumが孤児化し、マシンロードが青天井になった。~/.cache/lily-browser-slots/slot.log には毎朝 result=timeout:2400s が並んでいました。しかし本当の被害はそこではありませんでした。Playwright の finally: ctx.close() はSIGKILLに抗えません。孤児Chromiumが積み上がり続けてマシン全体が不調になりました。時間予算の超過が、無関係に見えるシステム障害として現れる典型です。

• SLOT_MAXを思い込みで絞り、30%のジョブがスキップされた。browser-slot.sh のコメントにその記録が残っています。

  # 実測(2026-08-09): Chrome系ジョブ9個で合計0.7GB。swap枯渇の主犯は dasd(47GB)/
  # ComfyUI(12GB)/iii(3.5GB)であってブラウザジョブではなかった。上限3は過剰に厳しく
  # 1日で92回のskip(全体の30%)を出していたので5に緩める。
  SLOT_MAX="${BROWSER_SLOT_MAX:-6}"
  

  swap枯渇の原因をブラウザジョブと思い込んで SLOT_MAX=3 に絞ったら、1日92回・全体の30%がスキップされていました。実測したら主犯は dasd（47GB）と ComfyUI（12GB）で、Chromeは0.7GBしか使っていませんでした。

• 投稿ジョブが全スロット占有中に9回スキップされ、時間帯の枠が消えた。browser-slot.sh が当時の経緯を記録しています。

  # 2026-08-15: 朝の7本同時timeoutで枠6が死んだrunに占有され、投稿レーン(xpilot.autopost
  # 等)が global-limit で9回skipした。いいね/フォローは1回落ちても翌回で取り返せるが、
  # 投稿はその時間帯の枠が消えると二度と埋まらない。
  SLOT_RESERVED_GROUPS="${BROWSER_SLOT_RESERVED_GROUPS:-post}"
  SLOT_RESERVE_COUNT="${BROWSER_SLOT_RESERVE:-1}"
  

  「いいねは翌日取り返せる、投稿の9時枠は9時を過ぎたら消える」という優先度の差が、全スロットをフラットに扱う設計に埋もれていました。

• Discord 2000字上限で日次レポートが丸ごと落ちた。lily-line-funnel/scripts/pdca.mjs の sendDiscordReport がレポート全文を1回のPOSTで送っていました。レポートが長い日は通知そのものが消えます。失敗しているのに失敗ログがないサイレントな状態です。直し方は行単位チャンク分割と、文字数カウントを [...s].length（サロゲートペア対応）にすること、Discord送信エラーの本文は先頭800字で切ってログは全文のまま残す構成にすることです。

• Chrome screenshotの高さが「自動fit」しなかった。コード内コメントに「高さは自動（コンテンツfit）にするため大きめwindow」とありましたが誤りでした。--headless=new --screenshot はウィンドウサイズをそのまま撮ります。コンテンツが短くても指定サイズの余白が生まれる。note用の表画像が常に1760×4000px（下に巨大な白余白）のまま公開されていました。直し方は2パス化。1パス目で --dump-dom から scrollHeight を読み、2パス目でその高さを指定して撮影します。ただし1パス目のウィンドウ高さは200にする必要があります。2000のままでは scrollHeight が2000未満にならず同じバグが残ります。結果は 1760×4000 → 1760×1178 になりました。

• imagegen の出力寸法を指定どおりと信じていた。「4:5縦 1024×1280」と指示しても実際の出力は 1122×1402 や 1003×1568 で返ります。生成ツールのアスペクト比指定は保証ではありません。レーンによって sips 正規化したりしなかったりの不統一が残り、AI portraits の仕上がりがレーン間でバラバラになりました。生成後に毎回強制正規化して実寸を確認するのが正解です。

• 「律速は上限か供給か」がログから判別できなかった。フォロー数が伸びない原因の調査で、「上限に達して止まっているのか」「候補が枯渇して処理できないのか」がログを読んでも判別できない状態がありました。日次上限に到達して打ち切り: ig-autoreply 160/160 の1行を打ち切り時に出力するだけで、「アルゴリズムかな」という誤解による調査時間が消えます。

• result=exit:1 がエラーの種類を教えてくれなかった。deadline=None 時のTypeError、ブロック検知による中断、ログイン切れによる中断がすべて同じ exit:1 で記録されていました。前節で詳述したとおりです。exit codeが同じなのに原因が異なるとき、調査はログ以外の手がかりを探すことから始まります。

---

ベストプラクティス

1. caps × delays × jitter の積を先に計算する

設定値を書いたあと、最悪ケースの所要時間（最大caps × 最大delay + jitter上限）を出して BROWSER_SLOT_TIMEOUT_SEC と比べてください。「capsが正しい」「delaysが正しい」は別々の確認です。組み合わせが初めて破綻します。今回は 101 × 60 + 900 = 6,960秒 > 2,400秒が実行前に計算できた答えです。

2. 締切は「capsを下げる」ではなく「自分から先に止まる」で解決する

capsは成長施策の上限です。下げれば施策の効果が縮みます。compute_budget() で締切を計算して、締切前に return 0 する設計に変える方が成果の損失が少ない。SIGKILLを受ける側から、自ら止まる側に立場を変える実装です。

3. 新機能の既定値は「何もしない側」に置く

def compute_budget() -> float | None:
    for key in ("IG_ENGAGE_BUDGET_SEC", "BROWSER_SLOT_TIMEOUT_SEC"):
        val = os.environ.get(key, "")
        if val.strip().isdigit() and int(val) > 0:
            return float(val)
    return None  # 全判定を無効化

deadline = None のとき over_budget() は常に False を返します。環境変数が消えた瞬間、以前の動作に戻ります。環境変数が消えた瞬間にジョブが止まる作りにしない、が基本原則です。

4. 既存の判定点に相乗りして、新しい制御構造を作らない

# 変更前
if blocked["hit"]:
    break

# 変更後（4箇所に追加するだけ）
if blocked["hit"] or over_budget():
    break

新しいクラスも if ブロックも作りません。変更量が小さいほど既存の挙動を壊すリスクが下がります。今回の主要なロジック変更は、4箇所への or over_budget() の追加と return 0 の1行です。

5. jitterも予算から差し引き、残予算の20%でクランプする

wait = min(START_JITTER_MAX_S, (deadline - time.time()) * 0.2)

予算2,400秒に対して最大900秒のjitterは37.5%です。残予算の20%（480秒）でクランプすることで、予算が短いほどjitterも短くなります。2,400秒の20%は480秒なので元の900秒より短く、かつ予算が削られるほどjitterも自動的に縮みます。ジッターの後に予算が残っているか確認しない実装は、0アクションで正常終了します。

6. 打ち切りとその他のエラーをフラグで区別する

was_truncated = (
    likes_done < LIKES_CAP or
    follows_done < FOLLOWS_CAP or
    unfollows_done < UNFOLLOWS_CAP
) and budget_hit

budget_hit フラグを別に持つことで、ブロック検知による中断と予算切れによる中断を分離します。ストリークは「capsと実行時間のミスマッチ」だけを数えます。ブロックされた日はストリークを加算しません。

7. 上限は「名目値×0.8」ではなく「実績×0.8」に置く

レーン	実績/日	旧上限	新上限（実績×0.8）
x-autoreply	63〜93	150	75
ig-autoreply（DM）	200	Infinity	160
x-outbound	120	120	96
threads-engage out	47〜50	50	40

実績93に対して上限150を0.8倍した120は、実績に届きません。まず実績を測り、その下に上限を置く順序が正しい。上限が実績を下回っていないなら、それは上限ではなく単なる数字です。

8. 重要なジョブ用の予約枠をスロット管理に組み込む

SLOT_RESERVED_GROUPS="${BROWSER_SLOT_RESERVED_GROUPS:-post}"
SLOT_RESERVE_COUNT="${BROWSER_SLOT_RESERVE:-1}"

「投稿は今日の時間帯が消えると二度と埋まらない」「いいねは翌日取り返せる」という優先度の差をスロット設計に反映します。全スロットをフラットに扱うと、重要なジョブが間引かれます。engage系（いいね・フォロー）は effective_max = SLOT_MAX - SLOT_RESERVE_COUNT の実効上限で動かし、post系は SLOT_MAX まで使えます。

9. 「器のサイズ」は必ず掛け算した結果で管理する

Discord 2000字・Chrome scrollHeight・imagegen 出力寸法──いずれも「指定した値が出る」前提で実装すると壊れます。制約は「書いた数字」ではなく「出てくる数字の最悪ケース」で持つ必要があります。送信前にチャンク分割、撮影前にサイズ計測、生成後に強制正規化を工程に組み込むことで、「指定と実際の乖離」が後になって発覚するバグを防げます。

10. アラートは「3日連続 + 1日1回」の閾値で設計する

1日で鳴らすと単発ノイズで読まれなくなります。毎日鳴らすと「また来た」になります。3日連続は「単発の重い日の外」にある最短の連続です。1日1回は「人間が対処できる量」です。last_alert_date != today の条件1つで、同日中の重複通知を防げます。

today = datetime.date.today().isoformat()
if streak >= 3 and state.get("last_alert_date") != today:
    send_alert(
        f"capsが実行時間に対して過大：予算到達での打ち切りが{streak}日連続\n"
        f"likes {likes_done}/{LIKES_CAP}, "
        f"follows {follows_done}/{FOLLOWS_CAP}, "
        f"unfollows {unfollows_done}/{UNFOLLOWS_CAP}"
    )
    state["last_alert_date"] = today

11. streakカウントは「前日が打ち切り」で継続条件を定義する

「last_dateが今日か」で判定すると、2日スキップ後の再開でstreakが正しく積まれません。「last_dateが昨日か」を継続条件にすることで、スキップをまたいでも連続性が正しく定義されます。

yesterday = (today - datetime.timedelta(days=1)).isoformat()
if was_truncated:
    if state.get("last_date") == yesterday:
        state["streak"] = state.get("streak", 0) + 1
    elif state.get("last_date") != today_str:
        state["streak"] = 1  # 連続が途切れた
    state["last_date"] = today_str
else:
    state["streak"] = 0
    state["last_date"] = today_str

12. 「律速は上限か供給か」を打ち切り時の1行で残す

日次上限に到達して打ち切り: ig-autoreply 160/160

この1行があるだけで、「フォロー数が伸びない原因は上限か供給不足か」の調査が2分で終わります。ないと、ログを2時間掘っても判別できません。処理が止まった理由は、止まった時点で書き出してください。

13. SLOT_MAXは実測値から決め、コメントに根拠を残す

browser-slot.sh のコメントは計測した数値とその判断根拠を書いています。「Chrome系9個で0.7GB・主犯はdasd47GB」という実測が、次回の調査を2分で終わらせます。設定値にコメントがないとき、次の担当者（未来の自分）は同じ調査を一から始めます。

---

まとめ

自動化が「静かに動いているが中身は半分」になっていた期間、ダッシュボードは問題なし、launchdは成功を記録し、毎朝 exit 0 が返ってきていました。

問題の構造は単純です。capsと実行時間を別々の場所に書いて、一度も掛け算しなかった。その結果、毎日SIGKILLされ、Chromiumが孤児化し、マシン全体が不調になりました。Discord の2000字、Chrome の scrollHeight、imagegen の出力寸法も同じ型です。コードのどの行を読んでも「正しい」。組み合わせだけが破綻している。このバグはコードレビューでは見つかりません。設定値どうしの積を出す習慣だけが防ぎます。

修正は変更量が少ない方が正しい実装です。compute_budget() で締切を計算し、over_budget() を既存の4箇所の判定点に相乗りし、return 0 で自分から止まる。コアのロジック変更は2桁の行数で終わりました。

ただし「自分から止まって exit 0 にする」を選んだ瞬間、「静かに止まる仕組みを静かに監視する」責任が生まれます。3日連続+1日1回アラートという設計は、その責任を果たす最小の構造です。1日では鳴らさない、毎日も鳴らさないという閾値の間にある点が、狼少年を避けながら構造問題を検知できる唯一の場所でした。

exit 0 を信じるか、exit 0 の中身を確認するか──その差が、月商120万を維持する自律環境と、静かに止まり続ける環境の分岐点です。

---

仕組みの全体像・月120万の内訳・30日手順は有料noteにまとめています。
📕 Claude Code自律環境で、実際どう稼ぐか ― 仕組み・実例・始め方・サポート

---

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

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

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