🧠 RSSには映らない圧縮メモリ爆弾を自動で倒す

SNSの自動投稿が1日まるごとゼロ件になったあの日から、Macのメモリ監視に対する考え方が根本から変わりました。

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

「RSSが正常なのに死んでいた」という矛盾

2026年8月9日、稼働21時間目のMacで異変が起きました。Claude Codeが動かす自動SNS投稿エージェントが、ぱたりと止まりました。Playwright の launchPersistentContext が180秒でタイムアウトし、全レーンが1件も投稿できないまま24時間が経過しました。

真っ先に疑ったのはメモリ不足です。Activity Monitor を開き、メモリ圧力を確認しました。Topコマンドで RSS 上位を並べました。異常なプロセスは見当たりません。dasd（Duet Activity Scheduler、macOSのバックグラウンド活動スケジューラ）のRSSは 264MB。「重いがこんなもの」という水準です。

しかし実態は違いました。top -l 1 -n 20 -o mem -stats pid,command,mem,cmprs で MEM列とCMPRS列を同時に表示すると、全容が見えました。

PID    COMMAND  MEM    CMPRS
...
1234   dasd     264M   46G

MEM（物理RAMの実使用量）は 264MB。しかし CMPRS（圧縮されてメモリに残っている量）は 46GB。合計でシステムは約 47GB のメモリを dasd のために確保していました。スワップは37GBまで膨らんでいました。

RSS（Resident Set Size）はプロセスが現在物理メモリに展開しているページの合計です。macOSはメモリ圧迫時に、あまり使われていないページを圧縮して同じ物理アドレスに押し込めます（Compressed Memory）。圧縮されたページはRSSにカウントされません。そのため RSS 264MB という「正常値」が表示されていたのです。

Activity Monitor の「メモリ」列も同じトラップです。表示されているのは RSS ベースの値であり、圧縮領域は「メモリ圧力」のグラフに薄く溶け込むだけで、プロセスごとのCMPRS値は出てきません。

ChromeがタイムアウトするメカニズムをRSSが隠す

Playwright が Chrome を起動するとき、カーネルはヒープを確保し、プロファイルディレクトリを mmap します。このとき macOS はスワップ上のページをメモリに戻そうとします。ところが dasd が 46GB の圧縮領域を抱えていると、物理RAMに空きが作れません。非圧縮・展開・ページイン・スワップイン、この一連の操作が連鎖して Chromeの初期化がスタックし、180秒のウォールタイムを超えてタイムアウトします。

エラーログには Target closed Navigation timeout しか残りません。メモリの文字は一行も出てきません。これが「誰も気づけない」理由です。

第二の漏れ犯: iii（agentmemory）

dasd だけが原因ではありませんでした。エージェントのメモリ永続化を担う iii プロセス（agentmemory）も、実測で 時速約4GB のペースでメモリを膨張させる第二の漏れ犯でした。スクリプトのコメントには次のように記録されています。

# iii(agentmemory) は 2026-08-09 実測で時速約4GB増える second leaker。
LAUNCHD_RESTART_MAP="${MEM_HOG_LAUNCHD_MAP:-iii=com.shun.agentmemory:2048}"

dasd と異なり、iii は launchd がユーザーセッションとして管理するジョブです。単に killall iii しても、launchd がすぐに親プロセス（node）を再起動し、iii 自体は ppid=1 の孤児として生き残ります。メモリを抱えた旧プロセスが残ったまま、新しいプロセスが増えるだけという最悪のパターンになりました。これは実装の第一稿で実際にハマった落とし穴であり、後述の kickstart 戦略で解決しています。

「定期的に確認すればいい」ではなく「自動で倒す」が要る

副業の自動化は、眠っている間も動いていなければ意味がありません。SNSの最適投稿時間は朝7時・昼12時・夜21時のような時刻に集中します。稼働21時間で dasd が暴走するなら、夜中に静かに起きた爆発を翌朝発見することになります。手動で sudo killall dasd を打てばすぐ直るにしても、その間の投稿はゼロです。

「定期的にActivity Monitorを確認しよう」は解決策ではありません。確認する人間がいない時間こそが最も危険です。自動で検知し、安全に再起動し、Discordに通知する。この仕組みを launchd に組み込むことで、人間が寝ていても環境が自己修復します。

「安全に」が最重要の条件

なんでも kill すればいいわけではありません。WindowServer を kill すればデスクトップが落ちます。launchd を kill しようとしても OS が無視します。Finder を kill すればデスクトップが再起動します。作業中の Claude Code セッションやノートアプリを落とせば、書きかけのコンテキストが消えます。

そのためスクリプトには「自動再起動するのは、OSが自動再起動する常駐デーモンだけ」という設計原則を埋め込んでいます。それ以外のプロセスがメモリ閾値を超えても、Discordへの通知だけ行い、プロセスには手を触れません。

# 絶対に触らないもの
NEVER_TOUCH="kernel_task WindowServer launchd loginwindow Finder"

この一行が、自動化の「blast radius（被害半径）」を最小化しています。

---

全体の流れ

アーキテクチャ図

[launchd]
    │
    │ StartInterval = 600秒（10分ごと）
    │ Nice=10 / LowPriorityIO=true（バックグラウンド優先度）
    ▼
[~/.claude/scripts/mem-hog-guard.sh]
    │
    ├─① top -l 1 -n 20 -o mem        ← MEM列＋CMPRS列をスキャン
    │     │
    │     ├─ dasd: MEM=47G/CMPRS=46G → 閾値3072MB超
    │     │         └─ sudo -n killall dasd → launchdが即再起動
    │     │
    │     ├─ iii: MEM≥4096MB超
    │     │         └─ SIGTERM → sleep2 → SIGKILL → kickstart -k
    │     │              └─ 孤児残存チェック後にログ記録
    │     │
    │     └─ その他: MEM≥6144MB → 通知のみ（触らない）
    │
    ├─② ps -Aco pid=,%cpu=,comm=     ← CPU軸を別スキャン（CMPRS爆弾は出ない）
    │     │
    │     └─ dasd: CPU≥50% を2回連続
    │               └─ sudo -n killall dasd
    │
    ├─③ クールダウン管理（プロセスごと・30分）
    │     └─ ~/.cache/lily-browser-slots/cooldown/<name>
    │
    └─④ Discord通知 (notify.sh)
              └─ 検知内容 ＋ sysctl vm.swapusage の現在値

launchd が10分おきにスクリプトを起動します。スクリプト自体は Nice=10 / LowPriorityIO=true で動くため、通常作業への影響はほぼゼロです。二重起動は shlock で排除しています。

LOCK_FILE="/tmp/com.lily.mem-hog-guard.lock"
if ! /usr/bin/shlock -f "$LOCK_FILE" -p "$$"; then
  exit 0
fi
trap '/bin/rm -f "$LOCK_FILE"' EXIT HUP INT TERM

shlock は BSD 由来のファイルロックユーティリティで、macOS には標準で入っています。PID が残存ファイルに書かれており、プロセスが落ちれば自動でロックが解除されます。

MEM/CMPRSの取得と単位変換

メモリスキャンは top を使います。-o mem で MEM 列の降順ソート、-stats pid,command,mem,cmprs でCMPRS列も同時取得します。

TOP_RAW=$(top -l 1 -n 20 -o mem -stats pid,command,mem,cmprs 2>/dev/null)

top が返す値は 264M 46G 37G のような人間向けの表記です。これをMB整数に統一する to_mb() 関数を用意しています。

to_mb() {
  awk -v v="$1" 'BEGIN {
    u = substr(v, length(v), 1); n = substr(v, 1, length(v) - 1) + 0
    if (u == "T") { printf "%.0f", n * 1024 * 1024 }
    else if (u == "G") { printf "%.0f", n * 1024 }
    else if (u == "M") { printf "%.0f", n }
    else if (u == "K") { printf "%.0f", n / 1024 }
    else { printf "%.0f", v / 1048576 }
  }'
}

46G は 46 × 1024 = 47104 MB に変換されます。閾値と整数比較できるため、bash の [ "$mem_mb" -ge "$AUTO_RESTART_THRESHOLD_MB" ] で判定できます。

2軸スキャンの設計思想

MEM/CMPRS スキャンと CPU スキャンは独立した2軸で動いています。理由があります。

CMPRS爆弾（dasdの今回の症状）は top -o mem で検出できます。しかし、別の日に dasd が CPU 75% で暴走するケースも起きています（圧縮メモリは正常なのに演算が止まらない）。このケースでは MEM軸には一切現れません。ps -Aco pid=,%cpu=,comm= の CPU軸スキャンが必要です。

CPU_RAW=$(ps -Aco pid=,%cpu=,comm= 2>/dev/null)

-c フラグは実行ファイル名のみを返します。-o comm を使うと列幅が15文字で切られ、/usr/libexec/dasd が /usr/libexec/da になって basename 照合が永久に外れます。これも実際にハマった落とし穴です。

CPU暴走は瞬間的な spike と本物の暴走を区別するため、「N回連続で閾値超え」という streak カウンタを持っています。

CPU_THRESHOLD_PCT="${MEM_HOG_CPU_THRESHOLD_PCT:-50}"
CPU_SUSTAIN_CHECKS="${MEM_HOG_CPU_SUSTAIN_CHECKS:-2}"

デフォルトは「CPU50%超えを2回連続」。10分間隔で動くため、20分間暴走し続けた場合にのみ再起動します。誤検知を避けるための緩衝です。

環境変数で柔軟に調整できる設計

スクリプトの閾値はすべて環境変数で上書きできます。launchd の plist でプロジェクト固有の値を注入することで、スクリプト本体を変更せずに挙動を調整できます。

plist の EnvironmentVariables セクションに設定されている値がこちらです。

<key>EnvironmentVariables</key>
<dict>
  <key>MEM_HOG_LAUNCHD_MAP</key>
  <string>iii=com.lily.agentmemory:4096</string>
  <key>MEM_HOG_THRESHOLD_MB</key>
  <string>3072</string>
</dict>

MEM_HOG_THRESHOLD_MB=3072 は dasd の MEM 閾値を3GB に設定しています。スクリプトのデフォルト（5120MB）より低い値で、より早期に介入します。これは dasd が3GBを超えた時点でスワップが急増するという実測に基づいた値です。

MEM_HOG_LAUNCHD_MAP はユーザーランドのlaunchdジョブを プロセス名=ラベル:閾値MB 形式で列挙します。iii（agentmemory）は4096MB超えで kickstart -k による再起動対象になります。

また plist には StartInterval=600 が設定されており、ログは ~/.cache/lily-browser-slots/ ディレクトリに記録されます。ブラウザスロット管理ディレクトリと同居しているのは、SNS自動投稿システム全体のログを一か所にまとめるためです。

プロセスごとのクールダウン

初期実装には重大なバグがありました。クールダウン（再起動後30分間は同じプロセスを再起動しない）が全体で1つでした。2026-08-09 の実インシデントで、16:42 に dasd を回収した後の30分間、iii が閾値の1.5倍（3.1GB）まで膨らんでも一切回収されませんでした。

現在の実装はクールダウンをプロセスごとに独立したファイルで管理します。

COOLDOWN_DIR="$STATE_DIR/cooldown"

cooldown_active() {
  local key="$1" file last
  file="$COOLDOWN_DIR/$(printf '%s' "$key" | tr -c 'A-Za-z0-9._-' '_')"
  [ -f "$file" ] || return 1
  last=$(cat "$file" 2>/dev/null)
  [ $(( $(date +%s) - last )) -lt "$COOLDOWN_SEC" ]
}

cooldown_mark() {
  local key="$1"
  date +%s >"$COOLDOWN_DIR/$(printf '%s' "$1" | tr -c 'A-Za-z0-9._-' '_')"
}

dasd と iii のクールダウンファイルは独立して管理されます。dasd を回収した直後でも、iii が閾値を超えていれば即座に対応できます。

iii の再起動が3ステップ必要な理由

dasd は root 権限で動く OS デーモンです。sudo -n killall dasd で落とせば launchd が数秒以内に再起動します。シンプルです。

しかし iii（agentmemory）はユーザーセッションの launchd ジョブです。launchctl kickstart -k は親プロセス（node）を置き換えますが、iii 自体はその下で detach() して独立したプロセスとして spawn されているため、ppid=1 の孤児として生き残ります。親を入れ替えても子が残るのです。

実際の再起動シーケンスは以下の3ステップです。

# まず本体を落とす
kill -TERM "$pid" 2>/dev/null || true
sleep 2
kill -0 "$pid" 2>/dev/null && kill -KILL "$pid" 2>/dev/null || true
# 親（launchdジョブ）を置き換え
launchctl kickstart -k "gui/$(id -u)/$label" >/dev/null 2>&1 || true
sleep 3
# 旧プロセスが本当に消えたか確認
if kill -0 "$pid" 2>/dev/null; then
  log "restart-failed $label pid=$pid が残存"
fi

SIGTERM → 2秒待機 → SIGKILL（まだ生きていれば）→ kickstart -k → 3秒後に残存確認。このシーケンスをスキップすると、メモリを抱えた旧プロセスが生き残り、新プロセスが増えるだけという最悪の結果になります。

dry-runモードで安全に検証できる

本番投入前に --dry-run で動作を確認できます。

~/.claude/scripts/mem-hog-guard.sh --dry-run

実際に kill や kickstart は行わず、「何をするつもりか」を標準出力に表示します。

WOULD RESTART: dasd (pid=1234) が MEM 47G/圧縮 46G を抱えている -> 再起動
swap: total = 37.00G  used = 37.00G  free = 0.00G
dry-run 終了

launchd に登録する前に手元で --dry-run を一度走らせる、が必須の検証手順です。

実装の詳細

launchd 環境での PATH 問題とフルパス戦略

スクリプトの2行目と3行目は地味ですが、launchd 運用では最重要の2行です。

set -uo pipefail
PATH="/usr/bin:/bin:/usr/sbin:/sbin"
export PATH

set -uo pipefail は bash の安全設定3点セットのうち -e を外したものです。launchd から呼ばれるスクリプトでは -e を入れると、意図しないコマンドが非ゼロを返しただけで全体が終了します。kill -0 "$pid" でプロセスが既に消えていたとき、|| true を添えていなければ -e がスクリプトを落とします。そのため -e は外し、重要な操作だけ明示的に確認する設計にしています。

set -u は未定義変数を参照したときにエラーにする設定です。ただし $1 のような位置引数の参照でも変数が存在しないと爆発します。引数の取り回しを case "${1:-}" in と書いているのはこのためです。${1:-} は $1 が未定義なら空文字を返す展開で、set -u に怒られません。

PATH を4パスに明示固定しているのは、launchd がユーザーのシェル設定（.zshrc や .zprofile）を読み込まないからです。ターミナルなら nvm が PATH を展開してくれますが、launchd から起動されたシェルには nvm が存在しません。shlock を呼ぶとき /usr/bin/shlock のようにフルパスを使っているのも同じ理由で、sudo -n /usr/bin/killall とフルパス指定しているのも、sudo が参照する PATH を外部に依存しないためです。

top 出力を awk で分解するロジック

最も「肝」な部分が、top の生出力から pid/name/mem/cmprs を取り出す awk ブロックです。

awk '/^PID/ { seen = 1; next }
  seen && NF >= 4 {
    cmprs = $NF; mem = $(NF - 1); pid = $1
    name = ""
    for (i = 2; i <= NF - 2; i++) name = name (name == "" ? "" : " ") $i
    gsub(/ /, "", name)
    print pid, name, mem, cmprs
  }' <<<"$TOP_RAW"

/^PID/ でヘッダ行を検出し、それ以降のデータ行だけ処理します。ポイントは列を 前から ではなく 後ろから 取っている点です。MEM は最終列の1つ前（$(NF-1)）、CMPRS は最終列（$NF）。プロセス名は2列目から NF-2 列目までを結合します。

なぜ後ろから取るか。top -stats pid,command,mem,cmprs で出力するとき、command 列が複数の単語を含む場合があります（macOS の一部サービスは /usr/libexec/something agent のようにスペース入りで表示されます）。前から固定列で取ると名前がずれて MEM 列が agent になります。後ろ固定なら MEM/CMPRS の位置は常に安定します。

最後の gsub(/ /, "", name) はスペースを除去してプロセス名を1語にしています。bash の in_list() がスペース区切りリストで照合するため、名前にスペースが入ると2つの要素として誤認識されるのを防いでいます。

in_list() を配列ではなく単純ループにした理由

bash の配列は declare -a が必要で、環境変数経由では渡せません。launchd の plist で EnvironmentVariables に設定した値は文字列として届くため、配列に変換するステップが挟まります。in_list() はスペース区切り文字列をそのまま受け取って for でループします。

in_list() {
  local needle="$1" hay="$2" item
  for item in $hay; do [ "$item" = "$needle" ] && return 0; done
  return 1
}

$hay をクォートしていないのは意図的です。クォートすると for item in "$hay" となり、文字列全体を1要素として扱います。スペース区切りを展開させるためにあえてクォートなしです。IFS 操作が不要なシンプルな書き方を選んでいます。

LAUNCHD_RESTART_MAP のパース

iii のような launchd ジョブの定義は プロセス名=ラベル:閾値MB というフォーマットを使います。plist では iii=com.shun.agentmemory:4096 と設定されています。

for m in $LAUNCHD_RESTART_MAP; do
  case "$m" in "$command="*) entry="${m#*=}"; break ;; esac
done

case "$m" in "$command="* は「文字列が $command= で始まるか」を確認するパターンマッチです。grep や awk を使わず、bash 組み込みの case で完結させています。マッチしたら ${m#*=} で = 以降（com.shun.agentmemory:4096）を取り出し、そこから : でラベルと閾値に分割します。

label="${entry%:*}"   # com.shun.agentmemory
limit="${entry##*:}"  # 4096

%:* は最後の : より前、##*: は最後の : より後ろです。外部コマンド不要で、パスに依存しない文字列操作です。

CPU streak の状態機械

CPU暴走の検知は、ファイルベースの streak カウンタで実装しています。

streak=$(cpu_streak_get "$name")
if cpu_at_least_threshold "$cpu" "$CPU_THRESHOLD_PCT"; then
  streak=$((streak + 1))
else
  streak=0
fi
[ "$DRY_RUN" -eq 1 ] || cpu_streak_set "$name" "$streak"

cpu_at_least_threshold() は awk で浮動小数点比較します。bash の [ ] は整数比較しかできません。top が返す CPU 値は 75.3 のような小数なので、awk -v cpu="$1" -v threshold="$2" 'BEGIN { exit !(cpu + 0 >= threshold + 0) }' で判定しています。

streak が CPU_SUSTAIN_CHECKS（デフォルト 2）に達し、かつ今この瞬間も閾値を超えていて、かつクールダウン中でない場合のみ再起動します。「streak が溜まった後に収まっていた」ケースで誤発火しないよう、再起動直前にも閾値を再確認している点が重要です。

---

私が詰まった話

詰まり①: ps -o comm が15文字で切れて照合が永久に外れた

CPU 軸のスキャンを最初に実装したとき、プロセス名の取得に ps -Ao comm を使っていました。数日稼働させても dasd の CPU 暴走は一度も検出されません。ログには何も残りません。

原因を調べると、-o comm は 列幅を15文字に切ります。dasd は4文字なので問題ありません。しかし実際に ps -Ao comm を実行すると、フルパスで登録されているプロセスは /usr/libexec/dasd として取得され、それが /usr/libexec/da に切られます。basename で照合しようとしても da になるため、in_list "da" "dasd" は永遠にマッチしません。

コードのコメントにも残しています。

# ps -Ao comm は列幅15文字で切られ /usr/libexec/dasd が /usr/libexec/da になる。
# それだと basename 照合が永久に外れるので -c(実行ファイル名のみ)+ヘッダ抑止を使う。
CPU_RAW=$(ps -Aco pid=,%cpu=,comm= 2>/dev/null)

-c は「実行ファイル名のみ」を返すフラグで、フルパスを含まず切り捨ても起きません。列ヘッダを抑止する = サフィックスと組み合わせると、pid=,%cpu=,comm= という形で書きます。-Aco の順番が変わるとオプションの意味が変わるため、このまま固定しています。

詰まり②: クールダウンが全体で1ファイルだった代償

最初の実装は COOLDOWN_FILE="$STATE_DIR/.mem-hog-last" という1ファイルでした。「何かを再起動したら30分は何もしない」というロジックです。

2026年8月9日のインシデントで、16:42 に dasd を回収しました。その直後から iii が時速4GBのペースで膨らみ始め、16:55 には閾値の1.5倍（3.1GB）を超えました。しかしスクリプトは dasd を回収したことによるクールダウン中だと判断し、iii には一切手を付けませんでした。

dasd のクールダウン中に iii が膨らむ。これは同時多発する可能性が十分あるシナリオです。「1件直したら他が30分放置」は設計としておかしいと、事後分析で気づきました。

修正後はクールダウンをプロセスごとに独立したファイルへ分けています。コメントに当時の具体的な経緯が残っています。

# クールダウンは「プロセスごと」に持つ。
# 2026-08-09: 全体で1つにしていたため、16:42にdasdを回収した30分間は
# iii が閾値の1.5倍(3.1GB)まで膨らんでも一切回収されなかった。
# 1件直したら他が30分放置になるのは誤り。
COOLDOWN_DIR="$STATE_DIR/cooldown"

ファイル名は printf '%s' "$key" | tr -c 'A-Za-z0-9._-' '_' で安全なファイル名に変換します。: が含まれるラベル（com.shun.agentmemory）や、CPU 用の dasd:cpu というキーが / に展開されてディレクトリが作られるのを防ぐためです。

詰まり③: kickstart だけでは iii の旧プロセスが生き残った

iii（agentmemory）の最初の再起動戦略は launchctl kickstart -k "gui/$(id -u)/com.shun.agentmemory" だけでした。launchd が管理するジョブなら、これで親プロセス（node）ごと置き換わるはずという想定です。

実際には旧 iii プロセスが生き残りました。ps aux | grep iii で確認すると、ppid=1 の孤児プロセスとして存在し続け、4GBのメモリを抱えたままでした。新しい iii も起動したため、プロセスが2本になりメモリ使用量が倍になりました。

原因は iii の起動方法です。agentmemory は node が起動した後に detach() して独立した子プロセスとして spawn されます。launchd が管理しているのは親（node）です。kickstart -k は親を入れ替えますが、detach された子の ppid はすでに 1（launchd 本体）に書き換わっているため、親の再起動に影響を受けません。

正しい順序は「先に iii 本体を落とす → 親を kickstart する」です。

kill -TERM "$pid" 2>/dev/null || true
sleep 2
kill -0 "$pid" 2>/dev/null && kill -KILL "$pid" 2>/dev/null || true
launchctl kickstart -k "gui/$(id -u)/$label" >/dev/null 2>&1 || true
sleep 3
if kill -0 "$pid" 2>/dev/null; then
  log "restart-failed $label pid=$pid が残存"
fi

SIGTERM を送り、2秒後にまだ生きていれば SIGKILL。その後 kickstart で親を置き換え、3秒待って旧 pid が本当に消えたか確認します。残存確認を kill -0 でやっているのは、pid に読み取り権限があれば生死確認ができるからです。プロセスが消えていれば kill -0 は非ゼロを返し、if の中には入りません。

詰まり④: sudo -n が launchd 環境で通らなかった

dasd の再起動は sudo -n /usr/bin/killall dasd で行います。-n は「パスワードプロンプトを出さず、権限がなければ即失敗する」オプションです。

開発時にターミナルから手動実行すると動きます。launchd 経由で動かすと sudo: a password is required でスキップされます。

原因はふたつありました。ひとつは PATH の問題（sudoers の secure_path と環境の PATH が食い違うため、/usr/bin/killall のフルパス指定が必要）。もうひとつは、NOPASSWD 設定が私の Mac ではデフォルトで入っていなかった点です。

対処は sudo -n の失敗をエラーではなく「通知して終了」として扱う設計に変えることでした。

if sudo -n /usr/bin/killall "$command" 2>/dev/null; then
  log "restarted $command pid=$pid mem=$mem cmprs=$cmprs"
  findings="${findings}✅ ${msg}"$'\n'
  restarted=$((restarted + 1))
else
  log "restart-failed(no-sudo) $command pid=$pid mem=$mem"
  findings="${findings}⚠️ ${msg} — sudo権限が無く再起動できず。手動: sudo killall ${command}"$'\n'
fi

NOPASSWD が設定されていない環境では、Discord に「手動で実行してください」という通知が飛びます。自動化が失敗したことを黙って握りつぶさず、人間に渡す設計です。NOPASSWD の設定方法は sudo visudo で %admin ALL=(ALL) NOPASSWD: /usr/bin/killall を追記します。私の Mac では追記済みです。

詰まり⑤: top ヘッダ行の検出で NF 条件が甘かった

最初の awk は /^PID/ で seen フラグを立てた後、seen && NF > 0 で全行を拾っていました。top の出力には空行が挟まることがあります。空行は NF=0 なので問題ないと思っていましたが、区切り行（--- のような行）が NF=1 で通り抜けて $(NF-1) が $0 と同じになり、パースが壊れました。

修正は NF >= 4 の条件を加えることです。pid/name/mem/cmprs の最低4フィールドが揃っていない行は無視します。

seen && NF >= 4 {
  cmprs = $NF; mem = $(NF - 1); ...
}

この変更で、ヘッダ直後の空行・区切り行・フォーマット例外が全て無視されるようになりました。top の出力フォーマットは macOS バージョンによって微妙に変わります。固定列インデックスへの依存を最小化し、NF 条件でガードするのが安全です。

---

次の章では、実際にこのスクリプトを launchd に登録して使う手順と、稼働後のログの読み方を解説します。

つまずきポイント

実装・登録・運用の各フェーズで踏んだ落とし穴を一覧します。前段で深掘りした5つ（ps -c切り捨て・全体クールダウン・kickstart孤児・sudo -n不通・NF条件）はここでは繰り返しません。登録フェーズと長期運用フェーズに絞ります。

• launchctl load はVentura以降で非推奨・無音で失敗することがある
  launchctl load ~/Library/LaunchAgents/com.lily.mem-hog-guard.plist は古いAPIです。macOS Ventura（13）以降は launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.lily.mem-hog-guard.plist を使います。load でもエラーが出ないまま登録済みに見えることがあり、launchctl list | grep mem-hog で動作確認するまで気づきません。

• StandardErrorPath/StandardOutPath が指すディレクトリを先に作っておかないと無音で失敗する
  plist には StandardErrorPath として ~/.cache/lily-browser-slots/mem-hog-guard.launchd.log を設定しています。このディレクトリが存在しない状態で bootstrap すると、launchd はログファイルを開けずにジョブを落とします。エラーログも吐かないため「10分待っても一度も起動しない」でハマります。mkdir -p ~/.cache/lily-browser-slots を先に実行してから登録します。

• RunAtLoad=true のまま本番Macに配置したら bootstrap した瞬間に dasd が落ちた
  検証中に RunAtLoad=true にしていたのを戻し忘れてPCに配置すると、bootstrap した瞬間スクリプトが走ります。dasd がたまたま閾値（plist では MEM_HOG_THRESHOLD_MB=3072）を超えていれば、即座に sudo killall dasd が実行されます。plist には <key>RunAtLoad</key><false/> を明記し、最初の実行は launchctl start com.lily.mem-hog-guard で手動トリガーします。

• StartInterval のタイマーはロード時刻ではなくカレンダー区切りで動く
  600秒を設定すると「ロードから600秒後」ではなく「次の600秒の境界で起動」します。登録直後に「なぜ10分待っても動かないのか」と混乱します。launchctl start com.lily.mem-hog-guard で即座に手動起動して初回の挙動を確認してから放置します。

• ProcessType / Nice / LowPriorityIO の3点セットを省略するとバッテリー警告に出る
  省略すると top を数秒実行する間、macOS のエネルギー診断に「CPUを多く使ったアプリ」として記録されます。ProcessType=Background・Nice=10・LowPriorityIO=true の3つを plist に揃えることで、バックグラウンド処理として正しく分類されます。

• sudo visudo の NOPASSWD を広く書きすぎると別のリスクを招く
  NOPASSWD: ALL で通すとスクリプトが侵害されたときの被害が最大になります。NOPASSWD: /usr/bin/killall と killall のみに限定するのが最小権限です。スクリプト内でも sudo -n /usr/bin/killall dasd とフルパス指定することで、sudoers の対象コマンドが一致します。

• ログファイルが無制限に肥大化する
  log() 関数は >> で追記するだけで、ローテーションの仕組みがありません。週次で truncate -s 0 する別の launchd ジョブを仕込むか、ログ確認の際は tail -n 100 で読む習慣をつけておかないと、数か月後に数百MBになります。

• launchd.log（plist の StandardErrorPath）とスクリプト内 log() が別ファイルになる
  plist の StandardErrorPath は標準エラー出力（シェルの >&2）を受け取ります。スクリプト内の log() は mem-hog-guard.log に直接書きます。「動いているはずなのに log() が空」という状態は、スクリプトが起動前に launchd レベルでクラッシュしていること（plist syntax error・権限・ディレクトリ未作成）を意味します。まず mem-hog-guard.launchd.log を確認します。

• in_list の $hay をクォートなしで書いていたら別のエンジニアに「修正」された
  for item in $hay のクォートなしは意図的です。IFSによる word splitting でスペース区切りリストを展開するためです。"$hay" に「修正」されると文字列全体が1要素として扱われ、照合が永久に外れます。理由コメントを1行書いておかないと正しいコードを壊されます。

• kill -0 で dasd の残存を確認しようとしたら権限エラーで偽陰性になった
  dasd は root 所有プロセスです。一般ユーザーから kill -0 "$pid" を打つと EPERM が返り非ゼロになります。「プロセスが消えた」ではなく「権限がない」という意味の非ゼロです。スクリプトでは dasd の残存確認ステップを省略し、sudo -n killall が成功した時点で再起動成功とみなしています。kill -0 による残存確認は launchd ユーザージョブ（iii）専用にしています。

• vm_stat の出力が OS バージョンで列順が変わる
  Discord 通知に含めるスワップ情報は sysctl -n vm.swapusage を使っています。vm_stat コマンドは「Pages free」「Pages wired down」などのページ単位の生値を返し、計算が必要なうえ列名がバージョンで変わります。一行で人間が読めるスワップ現在値が欲しいなら sysctl -n vm.swapusage が最も堅牢です。

---

ベストプラクティス

1. NEVER_TOUCH リストを先に定義する

NEVER_TOUCH="kernel_task WindowServer launchd loginwindow Finder"

「何を触ってよいか」より「何を絶対に触らないか」を先に決めます。このリストがあるかぎり、閾値を超えた WindowServer を自動killしてデスクトップを落とすことはありません。blast radius を最初に宣言するのが自動化の設計原則です。

2. 本番登録の前に --dry-run を必ず1回走らせる

~/.claude/scripts/mem-hog-guard.sh --dry-run

WOULD RESTART: dasd (pid=1234) が MEM 47G/圧縮 46G を抱えている -> 再起動 という出力が、何が起きるかを事前に教えてくれます。この5秒がインシデントを防ぎます。

3. launchd 環境では全コマンドをフルパスで書く

launchd は .zshrc や .zprofile を読みません。スクリプト冒頭で PATH="/usr/bin:/bin:/usr/sbin:/sbin" と4パスに固定し、shlock は /usr/bin/shlock、killall は /usr/bin/killall とフルパスで書きます。「ターミナルで動くのに launchd 経由で動かない」の大半はこれが原因です。

4. set -uo pipefail を使い set -e は外す

-e は launchd 環境で誤爆します。kill -0 "$pid" でプロセスが既に消えていた場合（正常な状態）、非ゼロが返り -e がスクリプト全体を落とします。重要な操作だけ if と || true で明示的に確認し、-e には頼りません。

5. 閾値はすべて環境変数で上書き可能にする

AUTO_RESTART_THRESHOLD_MB="${MEM_HOG_THRESHOLD_MB:-5120}"

スクリプト本体は変えず、plist の EnvironmentVariables から値を注入できる設計にします。実際の plist では MEM_HOG_THRESHOLD_MB=3072 を設定しています。これは dasd が3GBを超えた時点でスワップが急増するという実測から決めた値です。スクリプトのデフォルト（5120MB）より低い値を外から入れることで、より早期に介入します。

6. クールダウンはプロセスごとに独立ファイルで持つ

COOLDOWN_DIR="$STATE_DIR/cooldown"

全体で1ファイルにすると「dasd を回収した30分間、iii が4GB超えても放置」が起きます。2026年8月9日のインシデントで実証されています。ファイル名は printf '%s' "$key" | tr -c 'A-Za-z0-9._-' '_' でサニタイズし、コロン（iii:cpu など複合キー）がディレクトリとして解釈されるのを防ぎます。

7. MEM軸とCPU軸を独立した2ループで回す

CMPRS爆弾は top -o mem で出ますが、CPUのみの暴走は MEM欄に現れません。dasd が CPU 75%で暴走する別日のインシデントでは、MEM軸だけでは何も検出できませんでした。top ループと ps -Aco ループを完全に分離することで、どちらの症状にも独立して対応できます。

8. CPU 判定はストリーク（N回連続）の2段構えにする

1回のスパイクで再起動すると一時的な処理ピークで誤発火します。ファイルベースのストリークカウンタで「2回連続 CPU 50%超え」を条件にし、かつ再起動直前にも閾値を再確認します。「streak が溜まった後に収まっていた」ケースで誤発火しないための二重チェックです。

if [ "$streak" -ge "$CPU_SUSTAIN_CHECKS" ] && cpu_at_least_threshold "$cpu" "$CPU_THRESHOLD_PCT" && ! cooldown_active "$name:cpu"; then

9. sudo -n の失敗をgraceful degradationで処理する

NOPASSWD が設定されていない環境では自動killは通りません。そのとき黙って終了するのではなく、Discord に「手動で sudo killall dasd を実行してください」という通知を送ります。自動化が失敗したことを人間に渡す設計が、長期運用の信頼性を作ります。

if sudo -n /usr/bin/killall "$command" 2>/dev/null; then
  log "restarted $command ..."
else
  log "restart-failed(no-sudo) ..."
  findings="${findings}⚠️ ${msg} — sudo権限が無く再起動できず。手動: sudo killall ${command}"$'\n'
fi

10. launchd ユーザージョブの再起動は SIGTERM → SIGKILL → kickstart の3ステップ

detach されて ppid=1 になった子プロセスは kickstart -k だけでは落ちません。先に本体を SIGTERM、2秒後に生きていれば SIGKILL、その後 kickstart で親を置き換えます。kickstart だけで済ませると、メモリを抱えた旧プロセスが生き残りながら新プロセスが増えるという最悪の状態になります。

11. ps には -c フラグを使う

CPU_RAW=$(ps -Aco pid=,%cpu=,comm= 2>/dev/null)

-o comm は列幅15文字でプロセス名を切ります。/usr/libexec/dasd が /usr/libexec/da になり、basename 照合が永遠に外れます。-c は実行ファイル名のみを返し切り捨てが起きません。ヘッダ抑止の = サフィックスとセットで使います。

12. top の awk パースは列を後ろから取る

cmprs = $NF; mem = $(NF - 1)

プロセス名にスペースが含まれると前から固定列で取ると MEM 列がずれます。最終列（CMPRS）・最終の1つ前（MEM）を固定にして名前は残りを結合します。NF >= 4 で空行・区切り行をガードします。

13. 通知に sysctl vm.swapusage を含める

swap=$(sysctl -n vm.swapusage | sed 's/vm.swapusage: //')
notify "🧠 mem-hog-guard\n${findings}\nswap: $swap"

「dasd を再起動した」という情報だけでは、スワップが37GBまで積み上がっていたかどうかがわかりません。スワップの現在値を通知に含めることで、Mac自体の再起動が必要かどうかを手元で判断できます。

14. 再起動後に kill -0 で旧プロセスの残存を確認する

sleep 3
if kill -0 "$pid" 2>/dev/null; then
  log "restart-failed $label pid=$pid が残存"
fi

kickstart 後に3秒待って旧 pid が本当に消えたか確認します。まだ生きていれば restart-failed としてログし通知します。「再起動した」と「旧プロセスが消えた」は別の確認です。

15. shlock で二重起動を防ぐ

LOCK_FILE="/tmp/com.lily.mem-hog-guard.lock"
if ! /usr/bin/shlock -f "$LOCK_FILE" -p "$$"; then
  exit 0
fi
trap '/bin/rm -f "$LOCK_FILE"' EXIT HUP INT TERM

launchd の StartInterval は「前の実行が終わっているかどうか」を確認しません。top と ps が同時に走ると同じ pid を2回 kill しにいくことになります。shlock はプロセスが落ちた瞬間に自動でロックを解除するため、デッドロックになりません。

---

まとめ

RSS に映らない CMPRS 爆弾は、Activity Monitor でもデフォルトの top でも捉えられません。top -l 1 -n 20 -o mem -stats pid,command,mem,cmprs を実行して初めて、dasd の RSS 264MB / CMPRS 46GB という実態が見えます。この数字に気づかなければ、Chrome の launchPersistentContext が180秒でタイムアウトして SNS 全レーンが1日分まるごとゼロになっても、メモリの文字はエラーログに一行も出てきません。

手動監視は解決策になりません。深夜3時に dasd が暴走しても、翌朝に発見できるのはゼロ件のログだけです。launchd が10分おきにスクリプトを起動し、スクリプトが MEM/CMPRS 軸と CPU 軸の2ループで圧縮メモリ爆弾を検知し、NEVER_TOUCH リストで安全を担保しながら自動再起動し、Discord にスワップ現在値つきで報告する。このサイクルが自分の知らない間に回り続けることで、投稿レーンは眠っている間も止まらなくなりました。

実装にたどり着くまでの詰まりはすべて、スクリプト本体のコメントに日時つきで残しています。コードはナレッジです。次に壊れたとき、コメントが何が起きたかを教えてくれます。

---

仕組みの全体像・月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 から💬

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