Claude Codeのモデル終了をlaunchdで無人移行する ― settings.jsonを自動パッチする使い捨てジョブ

前回、launchdの多重スロットとリトライ設計を書いた話の続きです。今回は「毎回動くジョブ」ではなく、特定の1日にだけ発火して、設定を1回書き換えたら自分で自分を消す使い捨てジョブの話です。

Claude Fable 5が2026-07-07に終了することが決まった時点で、~/.claude/settings.jsonのデフォルトモデルを手動で書き換え忘れるのが怖くて、40行のシェルスクリプトとplist1枚を仕込みました。結論から言うと、このジョブは実際には7/7当日ではなく1日遅れの7/8朝6:50に発火し、それでも正しく動きました。今日（9/4）確認したら、plist本体もログもすでに手元から消えていて、証拠として残っているのは書き換え前のsettings.jsonを保存した.bak-model-transitionファイル1つだけです。この記事は、その実装と「消えた後に何が残るか」の記録です。

困りごと：期限が来た日を自分は覚えていない

モデルのEOL（End of Life）は、来る日が分かっている一過性のイベントです。だからこそ厄介で、

• 当日にPCを開いているとは限らない（睡眠中・外出中）
• CLAUDE.mdや付箋にメモしても、当日忘れる
• 手でjqを叩いて書き換えるのはいいが、間違えて7/7より前に走らせるとFable 5がまだ生きているのに切り替わる
• 逆に何度も走らせて何度も通知が飛ぶのも邪魔

つまり欲しいのは「7/7以降に1回だけ、確実に、静かに」書き換えるジョブでした。launchdのStartCalendarIntervalは指定時刻にスリープ復帰時のcatch-up発火を含めて発火してくれますが、catch-upは早く飛んでくることもあれば遅れることもあるので、ジョブ側で日付を自衛する必要があります。

設計：使い捨て移行ジョブの4ステップ

~/.claude/scripts/model-transition-0707.shの中身はこうなっています。

#!/bin/bash
# model-transition-0707.sh — 2026-07-07にFable 5が終了するため、settings.jsonのmodelをopusへ自動切替
# 冪等: 7/7以降かつ model が fable の時だけ書き換える。成功したら自分のplistをunload。
set -uo pipefail
SETTINGS="$HOME/.claude/settings.json"
LOG="$HOME/.claude/logs/model-transition.log"
PLIST="$HOME/Library/LaunchAgents/com.example.model-transition-0707.plist"

log() { echo "[$(date '+%F %T')] $*" >> "$LOG"; }

# 7/7より前なら何もしない（catch-up発火対策）
if [ "$(date +%Y%m%d)" -lt 20260707 ]; then
  log "skip: before 2026-07-07"; exit 0
fi

current=$(jq -r '.model // empty' "$SETTINGS")
if echo "$current" | grep -qi 'fable'; then
  cp "$SETTINGS" "$SETTINGS.bak-model-transition"
  jq '.model = "opus"' "$SETTINGS" > "$SETTINGS.tmp" && jq . "$SETTINGS.tmp" > /dev/null && mv "$SETTINGS.tmp" "$SETTINGS"
  log "switched model: $current -> opus"
  /usr/bin/osascript -e 'display notification "Fable 5終了に伴いデフォルトモデルをOpusへ切替えました" with title "Claude model transition"' >/dev/null 2>&1 || true
else
  log "no-op: model is already '$current'"
fi

# 役目を終えたらジョブを外す（plistは残す＝再登録可能）
launchctl unload "$PLIST" 2>/dev/null || true
log "done (job unloaded)"

（PLISTのlabelは本記事用に匿名化しています。実物は自分のホームディレクトリ名を含む文字列でした）

やっていることは4つだけです。

1. 日付ガード：date +%Y%m%d -lt 20260707で「まだ早い」を弾く。ここは-eq（等号）ではなく-ltにしたのがポイントで、当日ぴったりに発火しなくても「その日以降ならいつ発火してもOK」という設計にしています。
2. jqでの安全な書き換え：currentがfableを含む時だけ動く冪等チェック → cpでバックアップ → jqで.tmpに書き出し → jq . "$SETTINGS.tmp" > /dev/nullで壊れたJSONでないことを検証してから → mvで本体に反映。壊れたJSONを直接上書きしてClaude Codeが起動不能になる事故を、この3段構えで防いでいます。
3. osascriptで通知：display notificationはGUIログイン中なら確実にデスクトップ通知を出せます。失敗しても|| trueで本処理を止めない。
4. launchctl unloadで自分を外す：役目を終えたらlaunchctl unloadで自分自身のplistを無効化します。ファイル自体は消さず「再登録すればもう一度使える」形にコメントで残しています。

このパターンの本質は「モデル切替」そのものではなく、日付ガード＋冪等チェック＋atomic write＋通知＋自己unloadという5点セットです。API終了日、証明書の切替日、料金プランの改定日など「特定の1日を境に設定を1回だけ変える」タスクは全部この形に落とし込めます。cronでもlaunchdでも、if 日付ガード; then 冪等チェック; then atomic write; fi; 自己解除の骨格は同じです。

実際に発火した跡：1日遅れの06:50

このジョブを仕込んでから2ヶ月経った今、実物を確認しようとしたら~/Library/LaunchAgents/にplistが見当たりませんでした。ログファイルも同様です。9月頭に環境全体を棚卸しして期限切れのlaunchd成果物を掃除したタイミングで、一緒に片付けられたようです。使い捨てジョブなので「使い捨てられた」のは筋が通っています。

唯一残っていたのが、スクリプトが書き換え前にcpしていた~/.claude/settings.json.bak-model-transitionでした。タイムスタンプを見ると

Jul  8 06:50:05 2026

7/7ではなく7/8朝です。当日は端末がスリープしていたか電源が入っていなかったのだと思います。中身のmodelフィールドを今のsettings.jsonと比べると、fableを含む識別子からopusにきちんと変わっていました。つまり、日付ガードを-lt（「その日より前ならスキップ」）で書いたおかげで、1日遅れてcatch-up発火しても何も困らなかったわけです。もし-eqで「7/7ちょうどだけ実行」と書いていたら、この日ずれで永遠に発火しないジョブになっていました。

踏んだ落とし穴

• catch-up発火は早いとも遅いとも決まっていない → -ltで「その日以降は常に許可」にする。等号一致は事故る
• jqの書き込みをそのまま>でリダイレクトすると失敗時に空ファイルで上書きされる → .tmpに書き出してからjq .で構文検証し、成功した時だけmv
• cpでバックアップを取らずに書き換えると切り戻せない → 1行足すだけで復元手段になる
• plistを消すと再登録できない → unloadだけに留めてファイルは残す設計にしたが、結局は無関係な棚卸し作業で消えた。使い捨てジョブの「証拠」は自分では残せないので、バックアップファイルのような副産物が唯一のログになる
• モデル名をsettings.jsonの1フィールドに頼る設計は無人ジョブ全体に波及する → 後日、別の無人ジョブ（claude -pをヘッドレスで叩くもの）で、--modelを明示していないとインタラクティブセッションの既定モデルの利用枠を無人ジョブが静かに食い潰すことに気づきました。exit codeは0のまま「判定不能」だけが積み上がる型で、原因究明に時間がかかりました。settings.jsonのmodelフィールドを自動で動かす仕組みを持つなら、無人ジョブ側は逆にそのフィールドに依存させず--modelを都度明示するのが安全です

まとめ

• 特定の1日にだけ設定を変えるタスクは「日付ガード＋冪等チェック＋atomic write＋通知＋自己unload」の5点セットに落とし込める
• 日付ガードは等号ではなく不等号で書く。launchdのcatch-up発火は早くも遅くも来る
• jq '...' > tmp && jq . tmp > /dev/null && mv tmp origで、壊れたJSONを本番に反映する事故を防ぐ
• 使い捨てジョブは自分の実行痕跡を自分では残せない。バックアップファイルのような副産物が唯一の証拠になる
• settings.jsonのmodelフィールドを自動で書き換える仕組みがあるなら、無人ジョブ側はそのフィールドに依存せず--modelを明示する方が安全

次回はlaunchd周りの運用細部からいったん離れて、実測ベースの改善記録を書く予定です。

---

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

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

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