🔒 死んだPIDが2時間ロックを占拠した話

月10万の大学生だったころ、「毎日SNSを更新し続ければ稼げる」と信じてインスタを手で更新していました。毎日1投稿、継続30日。疲弊して辞めました。今は Claude Code の自律環境がその作業を代わりにやってくれているので、私は一切手を動かさず月商120万を維持できています。

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

「作業をする」から「環境を作る」へ

手でSNSを更新し続けることの問題は、意志力を消耗する点にあります。どれだけ熱量が高くても、睡眠・体調・モチベーションのムラは避けられません。特に会社都合で解雇されて収入がゼロになった時期は、精神的な余裕がなく SNS 更新どころではありませんでした。

半年かけて Claude Code で構築した自律環境は、私の感情状態に関係なく動きます。launchd がスクリプトを呼び、スクリプトが claude -p（MAX枠、有料API禁止）でコンテンツを生成し、生成物が自動投稿キューに積まれ、毎日19:30にInstagramへ出ていく。この仕組みが正常に動いている限り、私が何もしなくても月120万の売上が維持される構造です。

読者に渡したいメンタルモデル

「自動化＝スクリプトを書く」と思っている人が多いですが、それは半分しか正しくない。スクリプトは書いた瞬間だけ正しい。時間が経つと外部の依存先が壊れ、プロセスが予期せぬ理由で死に、ロックファイルが残骸になって次回以降の実行をすべて止める。

本当に効く自律環境は「壊れを前提として、壊れを自己修復するレイヤーを持つ」もので、今回扱うロックの話はその典型です。

~/dev/brand-404/sns/gen_feature.py は launchd から毎日定期起動される Instagram 特集記事の自動生成スクリプトです。1回の実行時間が長い（claude -p を最大3回呼び、画像生成まで含めると数十分）ため、前の実行が終わっていないのに次の実行が重なることを防ぐロック機構を持っています。

このロックファイル（~/dev/brand-404/sns/gen_work/.lock）の取り扱いを誤ったことで、pid 94799 が kill 済みにもかかわらずロックを解放しないまま残り、以降の全実行が「lock held — 終了」でスキップされ、生成が約2時間止まりました。

なぜ "2時間" なのか

ロック判定には LOCK_STALE_SEC = 2 * 3600（2時間）という定数があります（gen_feature.py の57行目）。「ロックが存在してもmtimeが2時間より古ければ奪取する」という安全弁として設けたものです。

しかし当初の実装では、pid の生死を確認せずに mtime だけを見ていました。kill 済みの pid が .lock に残っていてもmtimeが2時間以内であれば「実行中」と判断してスキップし続けます。launchd が3回、4回と起動しても、2時間が経過するまで全部「lock held — 終了」。

自動化が「動いている」のに「何も生成されない」という最悪の状態がサイレントに2時間続いていました。

「環境を作る」側に必要な視点

手動作業なら「あれ、今日は生成されていないな」と気づいて手で動かせばいい。しかし自律環境を作るということは、「誰も見ていない状態でも正しく動き続ける」ことへの責任を引き受けることです。

pid の生死チェックは一見「念のため」に思えますが、実際には「スクリプトが kill されたあとにロックが残る」ケースが定常的に発生します。SIGKILL で即死させた場合、finallyブロックの release_lock() は一切走りません。開発中に手で止めた場合も同様です。長時間実行のスクリプトを launchd で定期起動するなら、pid 生死チェックは必須です。

---

全体の流れ

システム全体のアーキテクチャ

launchd (毎日定時 + 毎日19:30)
  │
  ├─ gen_feature.py（毎日定時）
  │     acquire_lock()         ← 今回の話
  │     ↓
  │     キュー残数チェック
  │     QUEUE_TARGET=3 に不足があれば
  │     ↓
  │     brand-catalog.json からブランド選定
  │     ↓
  │     Shopify /products.json 取得
  │     ↓
  │     claude -p #1: コピー生成 (copy.md)
  │     ↓
  │     claude -p #2: 画像役割選定 (images.md)
  │     ↓
  │     スライド生成 (build-post-from-json.mjs)
  │     ↓
  │     claude -p #3: セルフQA (qa.md)
  │     ↓ QAを通過
  │     content/sns/feature-XX-{slug}/ に出力
  │     release_lock()
  │
  └─ ig_autopost.py（毎日19:30）
        content/sns/feature-* のキューから1本取り出し
        ↓
        Instagram Graph API で投稿
        ↓
        state/ig_posted.jsonl に記録

キュー在庫は常時3本を目標にしています（gen_feature.py 60行目 QUEUE_TARGET = 3、61行目 MAX_GEN_PER_RUN = 2）。在庫が3本あれば、生成が1〜2日連続で失敗しても投稿は途切れない設計です。

ロック機構の責務

1実行が長い（最大 CLAUDE_TIMEOUT = 600秒 × 3回＋画像DL）スクリプトを launchd の定期起動で管理する場合、次の問題が起きます。

• 前回の実行が終わっていないのに次のインスタンスが起動し、同じブランドを二重生成する
• 共有の brand-catalog.json を同時に書き換えて破損する

これを防ぐのが gen_work/.lock です。ロックファイルに自プロセスの PID を書き込み、次回起動時にその PID の生死を確認してから動作するかどうかを決めます。

acquire_lock() の実装（修正後）

gen_feature.py の225〜249行目が実装の全体です。

LOCK_STALE_SEC = 2 * 3600       # 57行目

def acquire_lock() -> bool:
    GEN_WORK.mkdir(parents=True, exist_ok=True)
    if LOCK_FILE.exists():
        age = time.time() - LOCK_FILE.stat().st_mtime
        try:
            pid = int(LOCK_FILE.read_text(encoding="utf-8").strip())
            if pid <= 0:
                raise ValueError
        except (OSError, ValueError):
            log("stale lock 奪取: PIDが空または非数値")
        else:
            try:
                os.kill(pid, 0)          # ← プロセス生死チェック
            except ProcessLookupError:
                log(f"stale lock 奪取: pid={pid} は不在")
            except PermissionError:
                if age <= LOCK_STALE_SEC:
                    return False
                log("stale lock 奪取: mtime 2h超")
            else:
                if age <= LOCK_STALE_SEC:
                    return False
                log("stale lock 奪取: mtime 2h超")
    LOCK_FILE.write_text(str(os.getpid()), encoding="utf-8")
    return True

修正前（問題があったコード）の判定ロジックは、mtime だけを見ていました。

# ❌ 修正前: pid の生死を見ない
def acquire_lock() -> bool:
    GEN_WORK.mkdir(parents=True, exist_ok=True)
    if LOCK_FILE.exists():
        age = time.time() - LOCK_FILE.stat().st_mtime
        if age <= LOCK_STALE_SEC:
            return False          # ← kill済みpidでも2h以内は全部ここで返る
        log("stale lock 奪取: mtime 2h超")
    LOCK_FILE.write_text(str(os.getpid()), encoding="utf-8")
    return True

os.kill(pid, 0) の意味

os.kill(pid, 0) はシグナル 0（ヌルシグナル）を送ります。シグナル 0 は実際には何も送信しません。カーネルが pid を確認し、プロセスが存在して送信権限があれば正常終了、プロセスが不在なら ProcessLookupError、プロセスは存在するが別ユーザーのものなら PermissionError を返すだけです。

この挙動を使うと、プロセスの生死を安全に確認できます。

os.kill(pid, 0) の結果	意味	acquire_lock の判断
例外なし	pid のプロセスが存在・実行中	mtime が 2h 以内なら「実行中」としてスキップ
ProcessLookupError	pid のプロセスが不在（kill 済み等）	残骸ロックとして即座に奪取
PermissionError	pid は存在するが別ユーザー所有	mtime fallback（2h 超なら奪取）

pid 94799 が kill されていた今回のケースでは、修正後のコードなら ProcessLookupError が発生して即座に "stale lock 奪取: pid=94799 は不在" とログを出し、次の実行者がロックを取れます。

シェル版の kill -0 イディオム

同じパターンは ~/.claude/scripts/automation-health.sh の多重起動ガード（20〜30行目）でも使われています。

_ah_lock="${TMPDIR:-/tmp}/automation-health.lock"
if ! mkdir "$_ah_lock" 2>/dev/null; then
  if kill -0 "$(cat "$_ah_lock/pid" 2>/dev/null)" 2>/dev/null; then
    echo "automation-health: 別インスタンス稼働中のためスキップ" >&2
    exit 0
  fi
  rm -rf "$_ah_lock"
  mkdir "$_ah_lock" 2>/dev/null || { echo "lock取得失敗・スキップ" >&2; exit 0; }
fi
echo $$ > "$_ah_lock/pid"
trap 'rm -rf "$_ah_lock"' EXIT

コメント（17〜20行目）に理由が書いてあります。「--deep は全走査で I/O が積み上がり多重起動すると load average が跳ねる。アトミックな mkdir ロックで1本に絞る。PID生存チェックで残骸ロックは自動奪取、trap EXIT で正常/異常終了どちらでも必ず解放」。

shell の kill -0 <pid> は Python の os.kill(pid, 0) と全く同じ意味論です。2>/dev/null で stderr を捨てているのは、「プロセス不在」のエラーメッセージをユーザーに見せないためです。プロセスが存在すれば終了コード 0、不在なら終了コード 1 が返るので、if kill -0 ... の成否が生死判定になります。

さらに trap 'rm -rf "$_ah_lock"' EXIT で、正常終了・エラー終了・シグナル受信どれでもロック解放を保証しています。Python の try/finally で release_lock() を呼ぶのと同じ発想です。

2つの実装を並べると見えること

Python (gen_feature.py)          Shell (automation-health.sh)
─────────────────────            ─────────────────────────────
os.kill(pid, 0)                  kill -0 <pid>
  ProcessLookupError → 奪取        終了コード1 → 残骸 → 奪取
  PermissionError    → mtime fb    終了コード≠0→ 同上
  例外なし           → 実行中       終了コード0 → 実行中

try/finally release_lock()       trap 'rm -rf lock' EXIT

言語が違っても、ロック取得の正しいパターンは同じ3ステップです。

1. ロックファイルからPIDを読む
2. kill -0 / os.kill(pid, 0) でプロセスの生死を確認する
3. 不在なら即奪取、存在するなら mtime を副次的な安全弁として使う

mtime はあくまで「pid チェックができなかった時の最終手段」であり、主判定にしてはいけません。

実装の詳細

release_lock() と try/finally の組み合わせ

acquire_lock() の話をしたが、ロックの正しいパターンはリリース側にも肝があります。

gen_feature.py 252〜256行目の release_lock() はシンプルです。

def release_lock() -> None:
    try:
        LOCK_FILE.unlink()
    except FileNotFoundError:
        pass

FileNotFoundError を握りつぶしているのは意図的です。finally ブロックと手動呼び出しが重なった場合にクラッシュしないための防御であり、「ロック解放に失敗して本処理が例外になる」という本末転倒を防ぎます。

重要なのは呼び出し側の main() の構造です（995〜1020行目）。

if not acquire_lock():
    log("lock held（他プロセスが実行中 or 2h以内）— 終了")
    return 0

try:
    made = 0
    attempts = 0
    max_attempts = need + 3
    attempted_brands: set[str] = set()
    while made < need and attempts < max_attempts:
        result = run_pipeline(attempted_brands)
        ...
    log(f"生成完了: {made}/{need}本 試行{attempts}回 (queue残 {count_queue_remaining()}本)")
finally:
    release_lock()

try/finally でロックを取得した後の全処理を包んでいます。run_pipeline() の途中で例外が発生しても finally ブロックは必ず実行されるため、ロックは確実に解放されます。

ただし、これが機能しない例外があります。SIGKILL です。kill -9 <pid> でプロセスを強制終了した場合、Python のランタイムごと即死するため finally ブロックは走りません。これが今回の事故の直接原因でした。

trap EXIT も同様です（automation-health.sh 30行目）。

trap 'rm -rf "$_ah_lock"' EXIT

EXIT トラップは SIGTERM（通常の kill）、正常終了、エラー終了で走りますが、SIGKILL では走りません。どちらの言語でも、強制終了によるロック残骸は try/finally と trap EXIT だけでは防げない。だから os.kill(pid, 0) による死活確認が必要になるのです。

3つの例外分岐、それぞれの理由

acquire_lock() の os.kill(pid, 0) 呼び出しには3つの分岐があります（235〜247行目）。

try:
    os.kill(pid, 0)
except ProcessLookupError:
    log(f"stale lock 奪取: pid={pid} は不在")
except PermissionError:
    if age <= LOCK_STALE_SEC:
        return False
    log("stale lock 奪取: mtime 2h超")
else:
    if age <= LOCK_STALE_SEC:
        return False
    log("stale lock 奪取: mtime 2h超")

ProcessLookupError はプロセスが存在しないケースです。今回の事故（kill済みpid）がこれにあたります。即座に奪取します。mtime を見る必要はありません。

PermissionError は pid が存在しているが別ユーザーのプロセスというケースです。シグナル送信権限がないため存在は確認できますが、それが「自分のスクリプトの前のインスタンスか」は確認できません。この状況では mtime fallback に頼るしかないので、2時間以内なら「実行中として扱う」方向に倒しています。

例外なし（else ブロック） はプロセスが存在して送信権限もある、つまり確実に「まだ動いている」状態です。こちらも mtime が2時間以内なら正当な実行中として扱います。

LOCK_STALE_SEC = 2 * 3600 はあくまで最終手段の安全弁です。pid チェックが通用しない PermissionError ケースと、else ブロックでプロセスが動いているのに何らかの理由で想定外に長時間かかっているケースにだけ機能します。前半で示した「mtime を主判定にしてはいけない」という話はここにつながります。2時間というしきい値が正しいかどうかは問題の本質ではなく、pid チェックを先にやることが本質です。

PID が不正値だった場合の処理

ロックファイルが存在するが中身が壊れているケースも処理しています（229〜234行目）。

try:
    pid = int(LOCK_FILE.read_text(encoding="utf-8").strip())
    if pid <= 0:
        raise ValueError
except (OSError, ValueError):
    log("stale lock 奪取: PIDが空または非数値")

OSError はファイルが読めなかった場合（パーミッション問題等）、ValueError は int 変換に失敗した場合またはpidが0以下の場合です。どちらも「判定不能＝残骸」として奪取します。

pid <= 0 をチェックしているのは、PIDは必ず正の整数という POSIX の保証を使ったバリデーションです。int("0") や int("-1") は変換に成功しますが、実プロセスの PID として有効な値ではありません。空ファイルを strip() した結果が空文字列の場合は int("") で ValueError になるので同じ経路に落ちます。

シェルの mkdir ロックが持つ原子性

automation-health.sh が mkdir でロックを実装しているのは（22行目）、ファイルへの書き込みよりも原子的だからです。

if ! mkdir "$_ah_lock" 2>/dev/null; then
  if kill -0 "$(cat "$_ah_lock/pid" 2>/dev/null)" 2>/dev/null; then
    echo "automation-health: 別インスタンス稼働中のためスキップ" >&2
    exit 0
  fi
  rm -rf "$_ah_lock"
  mkdir "$_ah_lock" 2>/dev/null || { echo "lock取得失敗・スキップ" >&2; exit 0; }
fi
echo $$ > "$_ah_lock/pid"

mkdir はカーネルレベルでアトミックです。ディレクトリが存在しなければ作成して成功、存在すれば失敗する。2つのプロセスが同時に mkdir を呼んでも、カーネルが一方しか成功させません。

Python の write_text() にはこの保証がありません。A が先に書き、B が直後に上書きする競合が理論上ありえます。gen_feature.py の場合、launchd がインターバル起動なので同時実行の確率は極めて低いですが、ゼロではありません。Python で同じ原子性を得るなら os.mkdir() を使う方法があります。gen_feature.py があえてその方式を採用していないのは、このスクリプトで発生頻度の高い問題が「同時起動競合」ではなく「kill済みpidが残る」だったからです。解決すべき問題の優先順位に合わせてシンプルな実装を選んでいます。

---

私が詰まった話

症状：何も生成されないのに「エラー」もない

最初の異変に気づいたのは Discord の #brand-404 チャンネルでした。前日まで毎日届いていた「🆕 o81 IG特集生成: ...」という通知が来ない。

Discord のアラートチャンネルにも何も来ていません。「エラーが出た」ではなく「何も起きなかった」という症状でした。

launchd のジョブが落ちているのかと思い automation-health.sh を走らせると、com.lily.gen-feature は「ロード済 / last exit=0」でした。exit 0 は正常終了です。でも生成は来ていない。

ログを手繰ると、こんな行が3時間分並んでいました。

[gen] lock held（他プロセスが実行中 or 2h以内）— 終了

3回分の launchd 起動が全部ここで終わっていました。ロックを誰かが占有している。

原因特定：ロックファイルを直接見た

~/dev/brand-404/sns/gen_work/.lock を cat すると、

94799

pid 94799 が書いてありました。ps aux | grep 94799 で何も出ません。生きていないプロセスです。

ls -la ~/dev/brand-404/sns/gen_work/.lock で mtime を確認すると、約1.5時間前のタイムスタンプでした。LOCK_STALE_SEC = 2 * 3600（2時間）に対してまだ0.5時間足りない。だからずっと「2h以内 = 実行中」と判断してスキップし続けていたのです。

pid 94799 が死んだのは、前夜のデバッグ中に別ターミナルで kill -9 $(cat ~/dev/brand-404/sns/gen_work/.lock) を実行したからでした。本来なら release_lock() が走って .lock が消えるはずです。しかし -9（SIGKILL）は finally ブロックを飛ばします。ロックが残ったまま翌朝の launchd 起動を全部巻き込んだのです。

最初の誤った修正：LOCK_STALE_SEC を短くした

最初に思いついたのは「2時間は長すぎる、30分にしよう」でした。

実際に LOCK_STALE_SEC = 30 * 60 に変えてコミットしました。これは間違いでした。

問題は「2時間が長いこと」ではなく「kill済みpidを生きていると判断すること」です。30分にしても、kill後30分は同じ問題が継続します。むしろ今度は、正当な長時間実行（claude -p を3回呼ぶ = 最大 CLAUDE_TIMEOUT = 600 秒 × 3回＋画像DL）を途中で奪取してしまうリスクが生まれます。

正しい修正は「mtime を見る前に pid の生死を先に確認する」であって、mtime のしきい値を変えることではありません。しきい値の調整は根治ではなく、症状を軽くするだけの対処です。このコミットは取り消し、os.kill(pid, 0) を先に確認する現在の方針に切り替えました。

二度目の詰まり：PermissionError を見落とした

ProcessLookupError だけを捕まえた最初の修正版を本番に入れた後、テスト中に再び詰まりました。

確認目的で sudo python3 ~/dev/brand-404/sns/gen_feature.py --dry-run を一度走らせた後、通常ユーザーとして走らせると再びロックが残る症状が出ました。

sudo で走ったプロセスは root 所有です。通常ユーザーから os.kill(root_pid, 0) を呼ぶと PermissionError が返ります。私の最初の修正は ProcessLookupError しか見ていなかったため、PermissionError が外へ伝播してスタックトレースが出ていました。

# ❌ PermissionError を見落とした中間バージョン
try:
    os.kill(pid, 0)
except ProcessLookupError:
    log(f"stale lock 奪取: pid={pid} は不在")
# PermissionError は捕まえておらず、外へ伝播する
else:
    if age <= LOCK_STALE_SEC:
        return False

Python の try/except/else の構造として、else は「try ブロックで例外が一切出なかった場合」に実行されます。PermissionError を捕まえていないので、このケースでは except ProcessLookupError にも else にも入らず、例外がそのまま呼び出し元に伝わっていました。最終的に PermissionError も明示的に捕まえ、mtime fallback に回す現在の形（241〜243行目）になりました。

except PermissionError:
    if age <= LOCK_STALE_SEC:
        return False
    log("stale lock 奪取: mtime 2h超")

教訓：「正常終了している」は「正しく動いている」ではない

この件で最も強く刻まれたのは、exit 0 と「生成が完了した」は別物だということです。

log("lock held — 終了"); return 0 は exit 0 です。launchd のジョブ履歴は「成功」として記録されます。automation-health.sh もグリーンを返します。Discord のアラートも来ません。外から見ると全部正常で、でも目的の「コンテンツ生成」は一切起きていない。

この種のサイレント障害は、モニタリングを「プロセスが死んだかどうか」ではなく「意図した副作用が発生したかどうか」で設計しないと検知できません。

今はキュー残数（count_queue_remaining()）が一定時間ゼロのままなら Discord にアラートを飛ばす監視を別で持っています。プロセスの健全性チェックと、出力の健全性チェックは分けて設計する必要があります。自律環境を「壊れを前提とした設計」にするということは、プロセスが生きているかどうかだけでなく、「その環境が意図した出力を生み続けているか」を別のレイヤーで監視することを含みます。

つまずきポイント

前半と中段では「mtime だけを見ていた設計の欠陥」「os.kill(pid, 0) による修正」「PermissionError の見落とし」を扱いました。ここでは、同じ構造のスクリプトを動かす中で実際に詰まった点を補足します。

PID が再利用されると「生きている」誤判定が起きる

Linux/macOS の PID は有限で折り返します。macOS では最大 99999 付近で一周します。長時間稼働する環境では、昨日 kill -9 したプロセスの PID を今日の無関係な別プロセスが使っている、ということが起こり得ます。この状態で os.kill(pid, 0) を呼ぶと「プロセスが生きている」と判定されます。gen_feature.py は現状 PID のみを .lock に書いていますが（248行目 LOCK_FILE.write_text(str(os.getpid()), ...)）、launchd のインターバルが1日1回であることと LOCK_STALE_SEC = 2 * 3600（57行目）の組み合わせで実害はほぼありません。高頻度で呼ばれるスクリプトでは PID と開始タイムスタンプをペアで書き、両方一致した場合のみ「実行中」と判断する実装を検討します。

GEN_WORK.mkdir(parents=True, exist_ok=True) を忘れると初回実行が即死する

acquire_lock() の226行目は GEN_WORK.mkdir(parents=True, exist_ok=True) から始まります。この1行がない場合、gen_work/ ディレクトリが存在しない初回起動で LOCK_FILE.exists() より前の操作が FileNotFoundError を上げます。launchd が起動してもスクリプトが即死し、last exit=1 のまま何も動かない状態になります。解放する前に作成する、という順番を守ります。

write_text() はアトミックではない（理論上の競合が存在する）

Python の Path.write_text() は書き込み途中の状態を他プロセスが読める可能性があります。LOCK_FILE.write_text(str(os.getpid()), ...) の書き込みが完了する前に次のインスタンスが read_text() すると空文字列を読み、int("") が ValueError → 残骸として奪取 → 2つのインスタンスが同時実行される、という競合が理論上成立します。gen_feature.py は launchd からの間欠起動なので同時刻起動はほぼ起きません。しかし1分ごとに呼ばれるような高頻度スクリプトでは os.open(path, os.O_CREAT | os.O_EXCL | os.O_WRONLY) でアトミックな書き込みを使います。automation-health.sh が mkdir でロックを実装している理由はここにあります（22行目 if ! mkdir "$_ah_lock" 2>/dev/null;）。

finally が走らないのは SIGKILL だけではない

SIGKILL（kill -9）が try/finally を飛ばすことは中段で扱いました。もう一つ注意が必要なのは、C 拡張モジュールが内部で os._exit() を呼ぶケースです。sys.exit() は SystemExit 例外として finally が走りますが、os._exit() はプロセスをランタイムごと即終了させるため finally は走りません。外部ライブラリへの依存が増えるほど「finally が走らない可能性」は上がります。「finally が走らない前提で pid 生死チェックを設計する」ことが唯一の根本対策です。

ロックファイルのパスを相対パスで組み立てると環境依存になる

launchd の plist に WorkingDirectory キーが設定されていると、スクリプトの起動ディレクトリがそこに変わります。相対パスでロックファイルのパスを組み立てると、plist の WorkingDirectory 次第で別の場所にロックファイルが作られます。gen_feature.py は ROOT = Path(__file__).resolve().parent.parent（36行目）から全パスを絶対パスで組み立てています。launchd ジョブで動くスクリプトは __file__ ベースの絶対パスを使います。

_draft-feature-XX-{slug} ディレクトリが蓄積する

run_pipeline() は QA 失敗・スライド生成失敗のとき _draft-feature-XX-{slug} ディレクトリを削除せずに残します。これは「失敗したコンテンツを後から確認できるようにする」意図的な設計です（954〜959行目）。count_queue_remaining() は _draft- prefix のものをカウントから除外しているため（203〜218行目）、在庫計算には影響しません。ただし蓄積が続くと content/sns/ がゴミだらけになります。月次の find content/sns -name '_draft-*' -mtime +30 -type d での清掃が必要です。

exit 0 を「正常」と解釈するとサイレント障害が通り抜ける

main() 関数は、ロック取得失敗時も return 0 で終わります（996〜997行目）。launchd はこれを「正常終了」として記録し、automation-health.sh の launchd チェックも last exit=0 を ✓ と表示します。「キュー在庫が足りていて生成不要だった exit 0」と「ロック取得に失敗して何もしなかった exit 0」が launchd の目には同じに見えます。実際の2時間停止はこれで見えませんでした。

「エラーが来ない＝正常」という設計思想の罠

Discord へのアラートは discord_alert() が呼ばれる失敗ケースだけ来ます（140〜142行目）。ロック取得失敗はエラー扱いではなくスキップなのでアラートは来ません。自動化監視を「悪いことが起きたら通知」だけで設計すると、サイレントスキップは永遠に検知できません。今回の異変に最初に気づいたのも、#brand-404 チャンネルの「🆕 o81 IG特集生成: ...」という成功通知（discord_post_review() = 973行目）が来なかったことでした。

Discord のデフォルト User-Agent が Cloudflare に弾かれる

_discord_post() のコメント（93〜94行目）にある通り、Python の urllib がデフォルトで送る Python-urllib/x.y という User-Agent を Cloudflare が 403/1010 で弾きます。ua_header = "lily-o81-gen/1.0" を明示して回避しています。自動化スクリプトで urllib や requests ライブラリのデフォルト設定のまま外部サービスを叩くと、予告なくブロックされることがあります。

curl のタイムアウトとリトライのバランスを見誤る

fetch_products() は Shopify の products.json を attempts=3 でリトライします（503〜522行目）。失敗時に15秒待ってリトライする設計は「連続アクセスで一時的に空を返す店がある」という実害（Beyond The Vines, 2026-07-26）から来ています。タイムアウトを極端に短くすると「本当は商品があるのに0件と判定されてブランドが skip に降格する」ことが起きます。逆に長すぎると1回の失敗で数分停まります。外部 API を叩くスクリプトは「1回のタイムアウト設定」と「何回リトライするか」と「リトライ間の待機時間」の3つをセットで設計します。

---

ベストプラクティス

前半・中段・つまずきポイントを踏まえて、launchd で動く長時間スクリプトのロック管理に関して実コードから抽出したプラクティスを整理します。

1. pid 生死チェックを主判定に、mtime を副判定に固定する

try:
    os.kill(pid, 0)
except ProcessLookupError:
    pass  # 即奪取
except PermissionError:
    if age <= LOCK_STALE_SEC:
        return False  # mtime fallback
else:
    if age <= LOCK_STALE_SEC:
        return False  # mtime fallback

shell 版は kill -0 "$(cat pid_file)" で同じ意味論を持ちます（automation-health.sh 23行目）。

2. 3つの例外分岐を必ずセットで実装する

ProcessLookupError だけを捕まえると PermissionError が外へ伝播してスクリプトがクラッシュします。3つをセットで書きます。1つでも欠けると「そのケース専用のバグ」になります。

3. try/finally でロック解放を必ず包む

if not acquire_lock():
    return 0

try:
    # メイン処理
finally:
    release_lock()

shell では trap 'rm -rf "$lock"' EXIT が同等です。正常終了・例外発生・sys.exit() どれでも解放されます。

4. release_lock() は FileNotFoundError を握りつぶす

finally と手動呼び出しが重なっても2回目の unlink() でクラッシュしないための防御です。「ロック解放の失敗で本処理が例外になる」本末転倒を防ぎます（252〜256行目のパターン）。

5. LOCK_STALE_SEC は最長実行時間から逆算する

gen_feature.py の最長実行は CLAUDE_TIMEOUT = 600 秒（66行目）× 最大3呼び出し + 画像 DL で約35〜40分です。LOCK_STALE_SEC = 2 * 3600（57行目）はこれに対して十分なマージンがあります。しきい値を短くしても「kill 済み pid が2h以内にロックを手放す」問題は解決しません。しきい値の調整は対症療法であり、pid 生死チェックが根治です。

6. ロックファイルのパスは Path(__file__).resolve() ベースの絶対パスで組み立てる

launchd の WorkingDirectory に依存しない実装が必須です。gen_feature.py の ROOT = Path(__file__).resolve().parent.parent（36行目）からすべてのパスを組み立てるパターンがそのままテンプレートです。

7. ロック取得前に GEN_WORK.mkdir(parents=True, exist_ok=True) を必ず実行する

ディレクトリが存在しない初回起動でクラッシュしないための必須処理です。acquire_lock() の先頭に置きます（226行目）。

8. shell では mkdir ロックで原子性を確保する

mkdir はカーネルレベルでアトミックです。2プロセスが同時に呼んでも一方しか成功しません（automation-health.sh 22〜27行目）。Python でも原子性が必要なら os.open(path, os.O_CREAT | os.O_EXCL | os.O_WRONLY) を使います。

9. モニタリングはプロセスではなく「意図した出力」で設計する

automation-health.sh の launchd チェックは last exit=0 を正常と見ますが、ロック取得スキップも exit 0 です。「コンテンツ生成が完了した」という成功通知（discord_post_review(), 973行目）が一定時間内に来なければアラートを出す、という正方向の監視が正解です。

10. 成功通知を持つ（エラー通知だけに依存しない）

エラーだけを通知する設計は、サイレントスキップを見逃します。「🆕 o81 IG特集生成: ...」という成功通知が「来ない」ことで異常を検知する設計が、今回の障害を気づかせた唯一のシグナルでした。「良いことが起きた通知」を持つことが異常検知の実効性につながります。

11. キュー残数を複数日分確保する

QUEUE_TARGET = 3（60行目）と MAX_GEN_PER_RUN = 2（61行目）の組み合わせは「生成が1〜2日連続で失敗しても投稿が途切れない」在庫設計です。ロック障害で1日止まっても在庫3本あれば投稿は維持できます。バッファを持つことが、自動化の単一障害点を排除します。

12. --dry-run オプションでロックを取らずに状態確認できるようにする

gen_feature.py --dry-run（981〜993行目）はロックを取らずにキュー残数だけを表示します。本番が動いている最中でも安全に呼べます。障害調査時に「ロックを取りに行って競合する」心配をせずに状態を確認できます。

13. --force オプションで E2E テストを本番ロジックのまま実行できるようにする

通常は QUEUE_TARGET を満たすまでしか生成しませんが、--force はキュー残数に関わらず1本生成します（980〜984行目）。本番ロジックを変えずにパイプライン全体をテストでき、修正後の検証に使えます。

14. 外部 API への urllib 呼び出しには必ず User-Agent を明示する

Python デフォルトの Python-urllib/x.y は Cloudflare や一部 CDN に弾かれます。"lily-o81-gen/1.0" のように識別可能な文字列を指定します。Discord・Shopify・その他 Cloudflare 配下の API を叩く場合は必須です。

---

まとめ

pid 94799 が2時間ロックを占拠したのは1行の欠如が原因でした。os.kill(pid, 0) でプロセスの生死を確認する処理が抜けていたために、kill 済みの pid を「まだ実行中」と誤判定し続けた。修正自体は数行です。

しかし本当に理解しなければならないのは、その「なぜ」でした。SIGKILL は finally を飛ばす。launchd の exit 0 は「正しく動いた」ではなく「プロセスが終了した」に過ぎない。モニタリングはプロセスの生死ではなく「意図した出力が発生しているか」で設計する。この3点が自律環境を「壊れを前提とした設計」にするという意味の実体です。

最初の誤った修正（LOCK_STALE_SEC を2時間から30分に縮める）は、症状を軽くしようとして根本原因を無視した典型的な誤りでした。30分に縮めても「kill 済み pid が2h以内に手放す」問題は解決しません。むしろ正当な長時間実行が途中で奪取されるリスクを生みました。CLAUDE_TIMEOUT = 600 秒（66行目）×3呼び出しで最大30分以上かかるスクリプトに30分のしきい値は短すぎます。

自律環境を作るということは、「誰も見ていない状態でも正しく動き続ける」責任を引き受けることです。月10万の大学生だったころは毎日手で動かしていたSNSが、今は launchd + Claude Code の自律環境で回っています。月商120万を維持できているのは、コンテンツそのものではなく「仕組みが止まらない設計」に積み上げてきた修正の積み重ねです。今回の pid 生死チェックも、その一つです。

---

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

---

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

• 制作物・記事は bokuwalily.com にまとめています🖥️
• AIで「寝てても回る仕組み」を作って月120万にした話は noteの有料記事 に💰
• OSS: github.com/bokuwalily 🐙
• 最新情報・お問い合わせは X @bokuwalily へ🌍

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