🔧 plistを書き換えてもlaunchdは古い値で動き続ける問題を自動修正する

大学時代に月10万、掛け持ち副業で月60万まで伸ばし、会社都合の解雇でゼロに落ちて、半年でClaude Code自律環境を組み直し今は月商120万のLilyです。

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

launchdが環境変数を「起動時に凍結」する

SNSの自動いいねを複数レーンで走らせているとします。あるレーンのタイムアウトを30秒から45秒に伸ばしたい。~/Library/LaunchAgents/com.lily.autolike.lane1.plist をエディタで開き、EnvironmentVariables の AUTOLIKE_TIMEOUT_SEC を 30 から 45 に書き換えて保存する。「これで次の実行から反映されるはずだ」と思って画面を閉じる。

翌朝ログを確認すると、タイムアウトエラーが昨日と同じ頻度で出ています。

これは launchd の根本的な動作仕様によるものです。macOS の launchd は、ジョブを bootstrap する瞬間に plist の内容を読み込み、環境変数をそのジョブの定義として「凍結」します。その後に plist ファイルを書き換えても、すでにメモリ上にロードされているジョブの環境変数は一切変わりません。ファイルシステム上の plist と launchd が保持する実行定義の間に「乖離」が静かに生まれるわけです。

この乖離は launchctl print gui/$(id -u)/com.lily.autolike.lane1 を実行することで確認できます。出力の中に AUTOLIKE_TIMEOUT_SEC => 30 という行が残ったままであれば、launchd はまだ古い値で動いています。plist ファイルが 45 を持っていても、ジョブは 30 で動き続けます。

解決策は単純で、launchctl bootout でジョブをアンロードし、launchctl bootstrap で再度ロードするだけです。しかし問題はここからです。

走行中のジョブを止めると、その実行分の結果が消える

自動いいねスクリプトが1回の実行でどれだけの処理をするか、想像してください。対象アカウントへの認証、フィードの取得、1件ずつのいいね操作、完了後のログ書き出し——これらを順番にこなす1つの「run」です。その途中で launchctl bootout をかけると、プロセスが強制終了され、その run で行ったいいね操作の成果が消えます。スクリプト冒頭のコメントにも明記されています。

# 走行中のジョブを bootout するとその run のいいねが丸ごと消えるため、必ず待つ。

複数レーンを24時間走らせる環境では、これが累積します。月商120万の自動化基盤において「ジョブを1回潰した」は冗談では済まない損失です。特に深夜帯に複数レーンが同時に走っているとき、何も確認せずに bootout を発行するスクリプトは、自分の成果を自分で削る地雷になります。

かといって「設定変更したら手動で止まっているのを確認してから reload する」では、自律環境とは呼べません。止まっているかどうかをチェックして、止まっているレーンだけ静かに再同期する——この判断をスクリプトに任せるのが autolike-plist-reconcile.sh の設計思想です。

「作業」でなく「環境」を作るという思考

月収ゼロから立て直す過程で学んだことがあります。副業で稼ぐ人には2種類います。仕事を「こなす人」と、仕事を「こなし続ける環境を作る人」です。

前者は毎日ログインして手を動かし、手を止めると収入も止まります。後者は一度環境を組んだあと、自分がいなくても動き続けるシステムを持ちます。Claude Code自律環境を半年かけて構築したのも、まさにこの発想からです。launchd で複数の自動化ジョブを常駐させ、設定を変えれば環境が自分で追いついてくる——人が介入しなくても、設定ファイルと実行状態が常に一致し続ける仕組みを持つことが、月商120万の自律基盤の核になっています。

autolike-plist-reconcile.sh は31行の小さなスクリプトですが、「環境」を作るという思想が凝縮されています。手動で reload するのではなく、スクリプトが定期的に乖離を検知し、安全なタイミングだけを狙って自動修復する。これは「設定変更のたびに人が介入する必要がない」環境そのものです。

全体の流れ

処理の全体像

スクリプトは ~/Library/LaunchAgents/ 以下の com.lily.autolike.*.plist を1ファイルずつ処理します。.bak-* と .disabled* のサフィックスを持つファイルはスキップし、残ったファイルについて plist の設定値と launchd の実行値を比較します。

~/Library/LaunchAgents/com.lily.autolike.*.plist
  （.bak-* / .disabled* は除外）
          │
          │ ① PlistBuddy で plist から設定値を読む
          ▼
      want=45  ← plist に書いてある目標値
          │
          │ ② launchctl print で launchd 内の値を読む
          ▼
      have=30  ← launchd が実際に保持している値
          │
          ├─ want == have ──────────── スキップ（変更なし）
          │
          └─ want != have
                │
                │ ③ launchctl list で PID を確認
                │
                ├─ pid あり（実行中）
                │     └── 見送りログを出力 → 次回実行まで待機
                │
                └─ pid なし（停止中）
                      ├── launchctl bootout でアンロード
                      ├── launchctl bootstrap で再ロード
                      └── "reloaded 30 -> 45" をログに記録

① plist から目標値を読む（want）

PB=/usr/libexec/PlistBuddy
want=$($PB -c "Print :EnvironmentVariables:AUTOLIKE_TIMEOUT_SEC" "$P" 2>/dev/null) || continue

PlistBuddy は macOS 標準の plist 操作コマンドです。-c "Print :EnvironmentVariables:AUTOLIKE_TIMEOUT_SEC" でネストしたキーを直接参照できます。2>/dev/null でエラーを捨て、|| continue でそのキーを持たない plist をスキップします。この want が「plist ファイルに書いてある、こうあるべき値」です。

② launchd が実際に持っている値を読む（have）

D="gui/$(id -u)"
have=$(launchctl print "$D/$L" 2>/dev/null | sed -n 's/.*AUTOLIKE_TIMEOUT_SEC => \([0-9]*\).*/\1/p' | head -1)
[ -n "$have" ] || continue

launchctl print gui/501/com.lily.autolike.lane1（501はUID）はそのジョブの完全な情報をテキスト形式で出力します。その中から sed で AUTOLIKE_TIMEOUT_SEC => 30 のパターンを探し、数値部分（30）だけを抽出します。head -1 で複数マッチを防いでいます。

have が空の場合（ジョブ自体がロードされていない状態）は || continue でスキップします。ロードされていないジョブに対して bootout を試みると launchctl がエラーを返すためです。この have が「launchd のメモリ上に現在存在する、実際に動いている値」です。ファイルシステムではなく launchd の内部状態を直接読んでいる点がポイントで、plist を読むだけでは絶対にわからない実行時の実態がここで初めて可視化されます。

③ 値の比較と PID チェック

[ "$want" = "$have" ] && continue
pid=$(launchctl list | awk -v l="$L" '$3==l{print $1}')
if [ -n "$pid" ] && [ "$pid" != "-" ]; then
  echo "[$(date '+%F %T')] $L 実行中(pid=$pid) のため見送り ($have -> $want)" >>"$LOG"
  continue
fi

want == have であれば変更不要なのでスキップします。差異があった場合、次に launchctl list でそのジョブの現在の PID を確認します。launchctl list の出力は PID LastStatus Label の3カラムで、awk でラベルが一致する行の PID を取り出します。PID が -（停止中を示す launchd の慣例表記）でない限り、ジョブは実行中とみなして「見送り」を選択します。

ログには次のような形式で記録されます。

[2026-08-23 08:30:00] com.lily.autolike.lane1 実行中(pid=12345) のため見送り (30 -> 45)

「変更したかったがタイミングを待っている」という意図が次回確認時にもわかります。このスクリプトは定期実行ジョブとして launchd に登録しておくため、見送りになっても次の起動タイミングで再びチェックし、空きが出れば自動的に再同期します。

④ bootout → bootstrap による再同期

launchctl bootout "$D/$L" 2>/dev/null
if launchctl bootstrap "$D" "$P" 2>/dev/null; then
  echo "[$(date '+%F %T')] $L reloaded $have -> $want" >>"$LOG"; changed=$((changed+1))
else
  echo "[$(date '+%F %T')] $L RELOAD FAILED" >>"$LOG"
fi

ジョブが停止中と確認できた場合のみ bootout → bootstrap を実行します。bootout で一度アンロードし、bootstrap で plist を読み直してロードし直すことで、AUTOLIKE_TIMEOUT_SEC の新しい値が launchd のメモリに取り込まれます。

成功時のログ例は次のとおりです。

[2026-08-23 08:30:05] com.lily.autolike.lane1 reloaded 30 -> 45

変更前の値と変更後の値を並べることで、「何が変わったか」が一目でわかります。失敗した場合は RELOAD FAILED と残り、次回の実行で再試行されます。スクリプトの末尾では、1回の実行で何件の再同期が行われたかをまとめてログに記録します。

[ "$changed" -gt 0 ] && echo "[$(date '+%F %T')] done changed=$changed" >>"$LOG"

changed=0 の場合（全レーンが一致していた場合）はログを出力しません。この設計により、ログファイルには「何かが変わった時だけ」記録が残り、日常的なノイズが抑えられます。数十のログファイルを横断して状態を把握する自律環境では、ノイズのないログはデバッグ速度に直結します。

PATH の明示はスクリプト冒頭の1行が担っています。

PATH=/usr/bin:/bin:/usr/sbin:/sbin; export PATH

launchd のジョブとして動くスクリプトは、通常のターミナルセッションとは異なる最小限の実行環境で起動します。PATH を明示しないと PlistBuddy や launchctl のパス解決が失敗し、「手元では動くのに launchd から起動すると動かない」という典型的な沼にはまります。set -uo pipefail と合わせて、意図しない動作を最初から封じる構造になっています。

実装の詳細

set -uo pipefail が守る3つの壊れかた

スクリプトの2行目は次のとおりです。

set -uo pipefail

この1行が抜けているだけで、スクリプトは「一見動いているが何もしていない」状態に陥ります。-u は未定義変数の参照をエラーにするオプションです。仮に $have の取得に使う変数名をどこかでタイポしていたとします。-u なしの場合、タイポした変数は空文字列として展開され、[ "$want" = "$have" ] の $have が空になります。「want が 45、have が空文字列」は一致しないため比較は偽になり、PIDチェックへ進みます。launchctl list の出力には当然そのラベルは存在しないので PID が取れず、[ -n "$pid" ] は偽、つまり「停止中」と誤判定して bootout → bootstrap が走ります。何も壊れず再同期できてしまう場合もありますが、タイポした変数の「どこかが空」という状態が別のロジックを狂わせる可能性は常に残ります。-u はこの種のバグをシェルがエラーで止めることで早期発見を強制します。

-o pipefail はパイプライン全体の終了コードを制御します。-o pipefail なしの場合、パイプラインの終了コードは最後のコマンドのものになります。つまり launchctl print "$D/$L" 2>/dev/null | sed -n '...' | head -1 の出力が空であっても、head -1 が正常終了（終了コード0）であれば $? は0です。set -e を使っていない本スクリプトでは即座に問題にはなりませんが、将来このスクリプトを改変するときに pipefail の有無が挙動を変えうるため、最初から明示しておくことが安全です。

-o なしの単純な -uo と書いても効果は同じですが、set -uo pipefail と明示することで「pipefailまで意図して設定した」という意図が読み取れます。

glob + case による除外設計

for P in "$HOME"/Library/LaunchAgents/com.lily.autolike.*.plist; do
  case "$P" in *.bak-*|*.disabled*) continue ;; esac

glob パターンで対象ファイルを絞り込んだあと、さらに case で除外する2段構えになっています。除外を find のオプションや glob の否定記法で行わず case を使っている理由は明快です。シェルの否定 glob（!(*.bak*) のような extglob）は移植性が低く、bash と zsh では有効化のオプションが異なります。launchd から起動されるスクリプトは /bin/bash で動くため、set で extglob を明示的に有効にしない限り使えません。また、除外パターンが増えた場合に case は | で追加するだけで済み、可読性が保たれます。

.bak- のサフィックスが問題になるのは、テキストエディタが自動的に作成するバックアップファイルが LaunchAgents ディレクトリ内に残ってしまうケースがあるためです。com.lily.autolike.lane1.plist.bak-20260823 のようなファイルも *.plist にはマッチしませんが、エディタによっては .plist.bak 形式ではなく .plist の隣に別名でバックアップを作るものもあります。.disabled は手動でジョブを無効にしたいときに名前を変えて運用するための規約で、この除外を入れておくことで launchctl unload を使わなくても「このファイルは今は使わない」という意図を伝えられます。

sed による値抽出の正確な動き

have=$(launchctl print "$D/$L" 2>/dev/null \
  | sed -n 's/.*AUTOLIKE_TIMEOUT_SEC => \([0-9]*\).*/\1/p' \
  | head -1)

launchctl print gui/501/com.lily.autolike.lane1 の出力のうち、環境変数が載っている部分は次のような形式です（501 は実際のUID）。

environment = {
	AUTOLIKE_TIMEOUT_SEC => 30
	HOME => /Users/...
}

sed の s/.*AUTOLIKE_TIMEOUT_SEC => \([0-9]*\).*/\1/p は、行全体を対象にキー名の前後を .* で飲み込み、\([0-9]*\) で数値部分だけをキャプチャグループに収めて \1 として出力します。-n と p フラグの組み合わせで「マッチした行だけを出力」するため、環境変数が存在しない場合は何も出力されません。

head -1 で最初の1行に絞っているのは、ジョブ名や他の設定値に偶然 AUTOLIKE_TIMEOUT_SEC => に似た文字列が含まれていた場合の多重マッチを防ぐためです。実際にはあり得ませんが、防衛的に1行だけ取ることで「複数行が返ってきた場合に $have が複数行になり、後続の比較が全て失敗する」という状況を排除しています。

awk による PID 抽出と "-" の意味

pid=$(launchctl list | awk -v l="$L" '$3==l{print $1}')
if [ -n "$pid" ] && [ "$pid" != "-" ]; then

launchctl list の出力は3カラムです。

PID     Status  Label
12345   0       com.lily.autolike.lane1
-       0       com.lily.autolike.lane2

第1カラムが PID で、ジョブが現在実行中の場合は数値が入り、停止中（次回の StartInterval を待っている状態）の場合は - が入ります。awk -v l="$L" '$3==l{print $1}' は第3カラムがラベルと一致する行の第1カラムを出力します。

条件判定が [ -n "$pid" ] だけでは不十分です。-n は「空文字列でない」をテストするので、- という文字列は非空として真になります。つまり「PID が - の停止中ジョブを実行中と誤判定して永遠に見送り続ける」という状態が発生します。[ "$pid" != "-" ] の追加チェックが、この誤判定を防いでいます。

bootout の 2>/dev/null が持つ冪等性

launchctl bootout "$D/$L" 2>/dev/null
if launchctl bootstrap "$D" "$P" 2>/dev/null; then

bootout の行には || exit 1 も || continue もありません。2>/dev/null でエラーを捨て、終了コードを無視して次の bootstrap へ進む設計です。

これには理由があります。bootout は対象ジョブがすでにアンロードされている状態でも呼び出されることがあります（他のスクリプトが先に bootout した場合や、ジョブがクラッシュした直後など）。このとき launchctl bootout はエラーを返しますが、目的は「ジョブがアンロードされた状態にすること」であり、すでにアンロードされているなら成功と同義です。エラーで止まると、次の bootstrap が走らずに再同期が全て失敗します。2>/dev/null でエラーを捨て、無条件で bootstrap へ進むことで冪等性を確保しています。

bootstrap の方は if で成否を確認しています。plist ファイルのシンタックスエラーや権限不足など、bootstrap の失敗は「再同期に失敗した」という状態異常を意味するためログに RELOAD FAILED を残し、次回実行で再試行する設計にしています。

changed カウンタとログの設計思想

changed=0
# ... ループ内で changed=$((changed+1)) ...
[ "$changed" -gt 0 ] && echo "[$(date '+%F %T')] done changed=$changed" >>"$LOG"

changed が0のときはサマリー行を出力しません。これは意図的な設計です。このスクリプトは launchd の定期実行ジョブとして登録されています。全レーンの want == have が一致しているのが正常な状態であり、正常な実行が毎回ログに1行残れば、数日でログが数百行になります。「異常があったときだけ記録が残る」設計にすることで、ログファイルを見た瞬間に「変化があった日時と内容」だけが目に入ります。

一方、「見送り」はループが回るたびにログを出力します。

echo "[$(date '+%F %T')] $L 実行中(pid=$pid) のため見送り ($have -> $want)" >>"$LOG"

これは意図的に残しています。「変更したのになぜ反映されないのか」をデバッグするとき、見送りのログが複数行続いていれば「実行中のジョブがあって機会待ちをしている」とすぐにわかります。reloaded ログが最終的に現れれば正常に完了したことが確認でき、RELOAD FAILED が来れば異常を知れます。ログの密度がデバッグの速度に直結するため、「常時 verbose」でも「常時 silent」でもなく、「変化と待ちだけを記録する」設計を選んでいます。

---

私が詰まった話

PIDが "-" のジョブを「実行中」と誤判定して永遠に見送り続けた

最初にスクリプトを書いたとき、PID チェックのコードは次のようになっていました。

pid=$(launchctl list | awk -v l="$L" '$3==l{print $1}')
if [ -n "$pid" ]; then
  echo "実行中のため見送り"
  continue
fi

「PID が空でなければ実行中」という判定です。これを登録して1日動かしたところ、ログに「見送り」だけが延々と続いていました。

[2026-08-10 01:00:00] com.lily.autolike.lane2 実行中(pid=-) のため見送り (30 -> 45)
[2026-08-10 02:00:00] com.lily.autolike.lane2 実行中(pid=-) のため見送り (30 -> 45)
[2026-08-10 03:00:00] com.lily.autolike.lane2 実行中(pid=-) のため見送り (30 -> 45)

pid=- という出力を見て気づきました。launchctl list は停止中のジョブに対して PID カラムを空にするのではなく、- という1文字を入れます。- は空文字列ではないので [ -n "$pid" ] は常に真になり、どんなに待っても「実行中」と判定され続けます。

修正は1行追加するだけです。

if [ -n "$pid" ] && [ "$pid" != "-" ]; then

これで「PIDが存在し、かつ停止中を示す"-"でない場合」のみ実行中と判定するようになりました。launchd の慣例表記を知らないと絶対に踏む落とし穴で、man launchctl にもさらっとしか書いていません。実際の launchctl list 出力を目で確認して初めて気づきました。

PATH未設定でPlistBuddyが見つからず全スキップされた

スクリプトをターミナルから手動実行したときは完璧に動いていました。同じスクリプトを launchd に登録して定期実行させると、ログファイルが一切更新されません。changed カウンタが動いていないどころか、見送りログすら出ていない。

set -uo pipefail があるため、エラーで止まっているはずです。実験のためにスクリプト冒頭に exec >> /tmp/debug.log 2>&1 を追加してデバッグ出力を拾うと、次のエラーが出ていました。

/bin/bash: /usr/libexec/PlistBuddy: No such file or directory

PlistBuddy は /usr/libexec/PlistBuddy という絶対パスを使っているのに、見つからない——原因は行14の PB=/usr/libexec/PlistBuddy で絶対パスを指定しているにもかかわらず、$PB の展開が何らかの理由で空になっていることでした。-u オプションにより空変数の参照でエラーになり、for ループが continue ではなく exit に近い形で終了していたのです。

調べると、PB=/usr/libexec/PlistBuddy の前に別の変数で PlistBuddy を使おうとした試みの痕跡（コメントアウトしたが実は -u のせいで別の問題を引き起こしていた）が残っていました。整理の過程で変数参照が壊れていた、というのが正確な原因です。

が、並行して発見した本質的な問題が PATH でした。launchd から起動されるシェルスクリプトは、通常のターミナルセッションで設定される PATH（.zshrc や .zprofile で追加された /opt/homebrew/bin 等）が一切引き継がれません。PATH=/usr/bin:/bin:/usr/sbin:/sbin を明示しないと、スクリプト内で使うコマンドが「手元では動くが launchd では動かない」という状態になります。

PlistBuddy は /usr/libexec/ にあるため絶対パス指定の PB=/usr/libexec/PlistBuddy は問題ありませんが、launchctl、sed、awk、date はいずれも PATH 経由で解決されます。launchd の最小環境では /usr/bin:/bin:/usr/sbin:/sbin が標準ですが、環境によっては更に狭い場合があります。2行目の PATH 明示は「この問題を一度踏んだあと二度と踏まないための保険」として書いています。

PATH=/usr/bin:/bin:/usr/sbin:/sbin; export PATH

launchctl print の出力が空で全レーンがスキップされた

ある朝、全レーンの have が空になっているためにスクリプトが全スキップしている事象が発生しました。ログに何も出ていないため「正常終了しているがスキップしている」という状態です。

launchctl print gui/501/com.lily.autolike.lane1 をターミナルで直接実行すると、エラーが返ってきました。

Could not find service "com.lily.autolike.lane1" in domain for port

launchd にロードされていないジョブに対して launchctl print は空文字列ではなくエラーを返します。2>/dev/null でエラーを捨てているため have は空になり、[ -n "$have" ] || continue でスキップされます。

原因を遡ると、前夜に別の設定作業で誤って launchctl bootout を複数レーンに対して実行してしまい、bootstrap を忘れたまま朝を迎えていたことがわかりました。ジョブ自体が存在しない状態では autolike-plist-reconcile.sh は何もできません。「ロードされていないジョブを検知したときにアラートを出す」機能はこのスクリプトのスコープ外です。

これは設計の限界であり、バグではありません。このスクリプトの責務は「ロード済みジョブの環境変数のズレを修正すること」であり、ジョブが存在しない場合の復旧は別の仕組みが担います。スクリプトがやることとやらないことを明確に分けることで、1つの処理が肥大化して複数の問題を1つのコードで解こうとする誘惑を断ち切っています。

バックアップファイルを処理してエラーログが溢れた

テキストエディタで plist を直接編集していた時期に、エディタが自動バックアップを ~/Library/LaunchAgents/ 内に作成していました。com.lily.autolike.lane1.plist~ のような形式です（~ は一部のエディタが使うバックアップサフィックス）。このファイルは glob *.plist にはマッチしないため問題ありませんでしたが、com.lily.autolike.lane1.plist.bak-20260810 という形式で残ったファイルが glob にマッチしてしまいました。

バックアップファイルも com.lily.autolike. で始まり .plist で終わるため、スクリプトが処理対象と判断します。PlistBuddy でバックアップの want を読み取り、launchctl print でジョブの have を読み取り、当然一致しているのでスキップ——という流れなら問題ありませんが、バックアップファイルの内容が古い値を持っていた場合、バックアップの want が実行中ジョブの have と異なり、不要な bootout → bootstrap が走ります。

case "$P" in *.bak-*|*.disabled*) continue ;; esac の除外パターンはこの経験から追加したものです。エディタの自動バックアップ命名規則に合わせて .bak- というパターンにしています（- 付きにしているのは .bak 単体では他のケースと混合する可能性があるため）。バックアップ戦略を持つ環境では、このような副作用を先に潰しておくことが自律環境の安定性に直結します。

つまずきポイント

launchd × plist 再同期スクリプトを自律環境に組み込む過程で、実際に踏んだ落とし穴を網羅します。前段で詳述した4件（PIDの-誤判定・PATH未設定・launchctl print空・バックアップファイル混入）に加え、量産フェーズで繰り返し引っかかるパターンを整理しました。

実行環境・起動まわり

• launchd の PATH は /usr/bin:/bin:/usr/sbin:/sbin しかない。ターミナルで動いても launchd から起動すると command not found になる。PATH=/usr/bin:/bin:/usr/sbin:/sbin; export PATH を1行目に書かなければ始まらない。
• PlistBuddy は PATH 経由では解決できない。/usr/libexec/PlistBuddy という絶対パスで変数に収めておく（PB=/usr/libexec/PlistBuddy）。PATH に入れようとしても /usr/libexec はデフォルト PATH 外のため無意味。
• スクリプトに exec 権限を付け忘れる。launchd は ProgramArguments で指定したパスを実行するが、chmod +x を忘れると Permission denied で即死。ログにも何も残らないため原因特定が遅れる。
• plist の Program と ProgramArguments[0] を混在させる。Program を指定すると ProgramArguments[0] が argv[0] 扱いになる仕様を知らずに両方書くと、/bin/bash ではなく自分のスクリプトが直接渡されて構文エラー扱いになる。

ラベル・ファイル命名の不一致

• plist の Label 値とファイル名が一致していない。launchctl list でフィルタする awk -v l="$L" は $L=$(basename "$P" .plist) から取るため、ファイル名と Label が一致していなければ PID を取れず、常に「停止中」と誤判定して不要な bootout が走る。
• glob パターンに引っかかるテスト用 plist を置いてしまう。com.lily.autolike.test.plist のような名前で動作確認用を置くと本番同様に処理される。.disabled サフィックスを付けて除外する規約を守らないと、テスト用設定が本番環境を上書きする。
• Label 名に大文字・スペースが混入する。launchctl list の第3カラムは Label そのものを出力するため、ファイル名と異なる大文字表記があると awk のマッチが失敗する。命名規則は com.lily.autolike. 以降を全て小文字・ドット区切りで統一する。

launchctl の出力仕様まわり

• launchctl print の出力形式が macOS バージョンで微妙に変わる。macOS 14 → 15 のアップグレードで environment = { のインデントが変わり、sed のパターンが一致しなくなったことがある。sed -n 's/.*AUTOLIKE_TIMEOUT_SEC => \([0-9]*\).*/\1/p' の .* が前後を飲み込む設計なので大半のインデント変化には耐えるが、キー名の前後のスペース数が変わった場合は sed パターンの見直しが必要。
• launchctl list がドメインを跨ぐと別プロセスのラベルが混在する。複数ユーザーでログインしている環境では、他ユーザーのジョブが launchctl list に混入する場合がある。ラベル名を com.lily. で始めることで実害は出にくいが、awk のマッチが予期しないラベルに反応しないよう完全一致（$3==l）を使うのが前提。
• launchctl print に渡す domain+label の形式を間違える。gui/$(id -u)/com.lily.autolike.lane1 は正しいが user/$(id -u)/… と書くと別ドメインを指す。D="gui/$(id -u)" を変数化して一箇所だけ管理することで、typo がスクリプト全体に伝播するリスクを消す。

環境変数まわり

• 監視対象のキー名 AUTOLIKE_TIMEOUT_SEC をスクリプトに複数箇所に書いてしまう。want 取得の PlistBuddy コマンド（14行目）と have 取得の sed パターン（15行目）の2箇所が出てくる。将来キー名を変更するとき片方だけ直す事故を防ぐため、変数化して1箇所に集約するのが安全。
• 整数値以外が入ったときに sed の \([0-9]*\) がマッチしない。AUTOLIKE_TIMEOUT_SEC の値が 45s のように単位付きで書かれていると [0-9]* が空になる。PlistBuddy の want 取得と sed の have 取得で値の型が食い違い、異なる文字列として常に差異ありと誤判定されて毎回 bootout が走る。値は純粋な整数で管理する。
• EnvironmentVariables キーが plist に存在しない。$PB -c "Print :EnvironmentVariables:AUTOLIKE_TIMEOUT_SEC" "$P" 2>/dev/null || continue の || continue がこのケースを処理するが、2>/dev/null を外してデバッグすると「Does Not Exist」エラーが出て原因が分かる。沈黙するようにしているため、全スキップされてもログに何も残らない点に注意する。

ログ・診断まわり

• ログディレクトリが存在しない。LOG="$HOME/.claude/logs/autolike-plist-reconcile.log" のディレクトリ（~/.claude/logs/）が未作成だと echo … >>"$LOG" がエラーになり、set -uo pipefail の -u ではなく書き込みエラーでスクリプトが死ぬ。plist に登録する前に mkdir -p ~/.claude/logs を実行しておく。
• changed=0 が続くことを「正常」と取り違える。全レーンが want == have で一致しているなら正常だが、have が空（ジョブ未ロード）で全スキップされている場合も changed=0 かつログ無出力になる。定期的に launchctl list | grep com.lily.autolike で全レーンがロード済みかを別系統で確認する。
• 見送りログが毎時間続いても「問題ない」と放置してしまう。長時間ジョブが終わらない場合、plist の変更が永久に反映されないことになる。見送りが N 時間続いた場合にアラートを出す仕組みを持たないなら、少なくとも週次でログを目視確認する習慣を持つ。

PID チェックの境界

• PID が取れたが、そのプロセスが既に zombie になっている。macOS の launchd はクラッシュしたプロセスをすぐに回収するため実用上は稀だが、launchctl list に PID が残っているのに実プロセスが存在しないタイミングがある。このとき bootout は成功するが「走行中を止めた」形跡がログに残らないため、後からデバッグしにくい。
• StartInterval が長いジョブのみ保有する環境で「永遠に空きが来ない」と錯覚する。StartInterval 3600（1時間）のジョブは1時間に1回しか実行されないため、PID が - になるのも短時間だけ。reconcile スクリプト自身が短い間隔（例: 5分）で定期実行されていれば次の機会に捉えられる。逆にそのジョブの実行時間が StartInterval と同程度に長ければ、実質的に常時実行中の状態になり再同期の機会が永久に来ない。

---

ベストプラクティス

実際の運用で「これを最初からやっておけばよかった」と感じたルールを整理します。31行のスクリプトに詰め込まれた設計思想を、再現可能な形で書き出しました。

① PATH を1行目に固定する

PATH=/usr/bin:/bin:/usr/sbin:/sbin; export PATH

ターミナルで動作確認して「完成」と思い込むのが最大の罠です。launchd 経由の実行は PATH が最小環境しか持たず、.zshrc や .zprofile の設定は一切引き継ぎません。PATH を先頭行で固定することで「手元では動くがlaunchdでは動かない」問題を構造的に排除できます。

② set -uo pipefail を常に書く

set -uo pipefail

-u が未定義変数を即エラーにし、pipefail がパイプライン途中の失敗を終了コードに伝播させます。この1行がなければ、変数名のタイポや途中のコマンド失敗が「何もなかったように」通過し、wrong な状態で処理が続行します。シェルスクリプトの安全装置として例外なく書く。

③ PlistBuddy は絶対パスで変数化する

PB=/usr/libexec/PlistBuddy

PATH 経由では解決できないため、スクリプト冒頭で変数に収めておきます。複数箇所で使う場合も変数参照1本に統一することで、パスが変わったときに1行修正で済みます。

④ launchd のドメイン指定を変数化する

D="gui/$(id -u)"

gui/UID という形式を毎回インラインで書くと typo リスクが上がります。変数1つにまとめれば launchctl print "$D/$L" と launchctl bootout "$D/$L" と launchctl bootstrap "$D" "$P" の全てが1箇所の変更で追従します。

⑤ 除外パターンは case で管理する

case "$P" in *.bak-*|*.disabled*) continue ;; esac

extglob や否定 glob に頼らず、case で除外する設計が最も移植性が高いです。除外パターンが増えた場合も | で追記するだけ。エディタのバックアップ命名規則に合わせて .bak-（ハイフン付き）にすることで .bak 単体の誤マッチを防ぎます。

⑥ want と have の取得は「失敗したらスキップ」を明示する

want=$($PB -c "Print :EnvironmentVariables:AUTOLIKE_TIMEOUT_SEC" "$P" 2>/dev/null) || continue
have=$(launchctl print "$D/$L" 2>/dev/null | sed -n '...' | head -1)
[ -n "$have" ] || continue

want の取得失敗（キーが存在しない plist）は || continue で即スキップ。have の取得失敗（ジョブ未ロード）は空文字列チェックでスキップ。2種類の失敗パターンを異なる手法で処理している理由は、PlistBuddy は失敗時に非0終了コードを返すのに対し、launchctl print のパイプは全体として0終了になりうるためです。

⑦ PID の - を明示的に「停止中」と判定する

if [ -n "$pid" ] && [ "$pid" != "-" ]; then

launchctl list は停止中のジョブに数値 PID ではなく文字列 - を入れます。-n テストだけでは - を「PIDあり」と誤判定して永遠に見送り続けます。[ "$pid" != "-" ] を必ず追加する。man launchctl に明記されていないため、実際の出力を目で見るまで気づけない落とし穴です。

⑧ bootout は冪等に・bootstrap だけ成否を確認する

launchctl bootout "$D/$L" 2>/dev/null
if launchctl bootstrap "$D" "$P" 2>/dev/null; then
  …; changed=$((changed+1))
else
  echo "… RELOAD FAILED" >>"$LOG"
fi

bootout はすでにアンロード済みの状態でも呼び出されます。エラーで止まると続く bootstrap が走らず再同期が全て失敗します。2>/dev/null でエラーを捨て、無条件で bootstrap へ進むことで冪等性を確保。bootstrap の成否だけをログに記録して次回実行で再試行させます。

⑨ ログは「変化と待ちだけ」記録する

# 見送り → 毎回記録する（デバッグのため）
echo "[$(date '+%F %T')] $L 実行中(pid=$pid) のため見送り ($have -> $want)" >>"$LOG"

# 変更なし → 記録しない
# 変更あり → 記録する
[ "$changed" -gt 0 ] && echo "[$(date '+%F %T')] done changed=$changed" >>"$LOG"

全て正常な実行は silent にする。見送りは「変更したのに反映されない」デバッグに必要なので残す。reloaded と RELOAD FAILED は状態変化なので必ず残す。この3段階により、ログを開いた瞬間に「何かあったかどうか」が1行で判断できます。

⑩ スクリプトの責務を1つに絞る

このスクリプトが行うのは「ロード済みジョブの環境変数のズレを修正すること」だけです。「ジョブが未ロードなら自動でロードする」「失敗が続いたらSlack通知を送る」「ログを圧縮・ローテーションする」といった機能は持ちません。責務を1つに絞ることで、テストが容易になり、他のスクリプトと組み合わせやすくなります。アラートが必要なら別スクリプトに切り出す。

⑪ 監視対象キー名を1箇所で管理する

AUTOLIKE_TIMEOUT_SEC というキー名が PlistBuddy コマンドと sed パターンの2箇所に出てきます。将来的に監視対象を追加・変更する場合に備え、変数化して上部に定義しておくと保守性が上がります。

KEY=AUTOLIKE_TIMEOUT_SEC
want=$($PB -c "Print :EnvironmentVariables:$KEY" "$P" 2>/dev/null) || continue
have=$(launchctl print "$D/$L" 2>/dev/null | sed -n "s/.*$KEY => \\([0-9]*\\).*/\\1/p" | head -1)

現行の31行スクリプトはシングルファイル・シングルキー用途として完結しているため変数化していませんが、複数環境変数を監視する場合はループに展開します。

⑫ 定期実行の間隔は「許容できる反映遅延」から逆算する

reconcile スクリプト自身を launchd に登録するときの StartInterval は、「plist を書き換えてから環境変数が実際に反映されるまでの最大待ち時間」になります。5分以内の反映を期待するなら StartInterval 300 で登録します。ただし実行中のジョブを見送るケースがあるため、実際の反映遅延は「reconcile の間隔 + ジョブの最大実行時間」が上限です。

⑬ ログファイルの場所を launchd の StandardOutPath と揃えない

launchd の StandardOutPath と StandardErrorPath は plist で指定する stdout/stderr のリダイレクト先です。reconcile スクリプト自身のアプリケーションログ（LOG 変数で指す ~/.claude/logs/autolike-plist-reconcile.log）はこれとは別に管理します。両者が同じファイルを指すと、launchd のシステムメッセージとアプリログが混在して解析が困難になります。

⑭ テスト実行は bash -x で

launchd に登録する前に動作確認するときは、bash -x でコマンドをトレース出力しながら実行します。

bash -x ~/.claude/scripts/autolike-plist-reconcile.sh

各行の実際の展開値が + 付きで出力されるため、変数が期待どおり展開されているか、launchctl print の出力が sed にきちんと渡っているかを目視確認できます。手元で動作を確認してから plist に登録することで、沈黙バグ（ログが出ずに何もしない状態）を未然に防げます。

⑮ exit 0 で明示的に正常終了させる

exit 0

スクリプトの末尾に exit 0 を置くことで、launchd に必ず正常終了コードを返します。KeepAlive などの設定と組み合わせたとき、非0終了がジョブを予期しない再起動ループに誘導するケースを防ぎます。最後のコマンドが [ "$changed" -gt 0 ] && … の形式だと、条件が偽の場合に && 全体が偽（終了コード1）を返すため、明示的な exit 0 が必要です。

---

まとめ

autolike-plist-reconcile.sh がやっていることを一言で言えば、「launchd のメモリ上の値をファイルシステムの plist と定期的に比較し、ジョブが止まっているときだけ静かに再同期する」です。

具体的には次の4ステップです。

1. PlistBuddy で plist の目標値（want）を読む
2. launchctl print で launchd の実行値（have）を読む
3. 差異がある場合、launchctl list の PID を確認する
4. PID が -（停止中）なら bootout → bootstrap で再同期、PID が数値（実行中）なら見送ってログだけ残す

この「走行中は見送り・空きを待つ」設計により、実行中の自動化ジョブを中断せずに設定を反映できます。手動で reload タイミングを見計らう必要がなく、reconcile スクリプト自身を launchd に登録しておけば次の停止タイミングで自動的に処理されます。

ポイントは設計の潔さです。31行のスクリプトが担うのは「ロード済みジョブのズレ修正」だけで、ジョブ起動・アラート・ログローテーションは持ちません。1スクリプト1責務が自律環境の基本です。複数のジョブが24時間動き続ける環境では、「壊れたら気づく」より「壊れない仕組みを作る」ほうが長期的なメンテナンスコストが圧倒的に低いです。

月商120万の自律基盤は、こうした「地味だけど確実に機能する31行」の積み重ねでできています。派手な機能は1つもありません。launchd の仕様を正確に把握し、失敗パターンを先に潰し、ログ設計を丁寧にする——その繰り返しが「人がいなくても動き続ける環境」を作ります。

---

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

---

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

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

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