🩸 `--model`省略で無人ジョブが対話枠を3週間食い続けた話

月10万の大学生が掛け持ちで月60万まで上げ、会社都合で解雇されて0に戻り、半年でClaude Codeの自律環境を積み上げて今は月商120万です——「作業する」でなく「環境を育てる」に賭けたことが、その差を作りました。

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

副業で稼ぐ方法を調べると、必ず「スキルを売れ」「コンテンツを作れ」「サービスを作れ」の3択に収束します。どれも正解です。ただし全部に共通する天井がある。自分の時間が有限という事実です。

月60万の掛け持ち時代、私は実際に稼働時間の限界を迎えました。記事1本・DM1通・提案書1枚、全部に自分の手が要る。クライアントが増えるほど品質が落ちる。増やせない、質も落とせない——解雇になったのはちょうどそのタイミングで、「もう一度、同じやり方はしない」と決めました。

再出発で選んだのが**「自分が動かなくても動く環境を先に作る」**というアプローチです。今は launchd ジョブが毎朝8時と10時35分に起動し、記事ストックを生成し、Discordに通知を送ってくれます。私がMacを開いていなくても、眠っていても、記事は増え続けます。

この仕組みが強い理由は3点あります。

時間が積み上がる。人間の作業は時間を消費します。環境の作業は時間を生産します。ジョブが動いた回数は消えずに在庫として積まれる。体調が悪くて3日何もできない間も、ジョブは静かに在庫を増やし続けます。「正常に動いていれば」、ですが——その「もし」が今回の本題です。

スケールの桁が変わる。人間が1日に書ける記事は数本が限界です。ジョブは並列でいくつでも走る。今は記事生成・日次PDCA・外部データの構造化・受信DM判定の4レーンが同じ夜中に動いています。人間1人の処理量を超えたのは、エージェントが横に並んだからです。

クォータの構造を理解する深さが変わる。Claude Codeを「AIに頼む」ツールとして使っている人と、「インフラの一部」として配線している人とでは、月に処理できる量が根本から違います。インフラとして使うには、クォータがどのように共有され、どのように消費されるかを正確に知らなければ詰まります。今回の障害はまさにその知識の穴で起きました。

全体の流れ

コンテンツ生成基盤の骨格を先に見せます。後半で障害を解剖するので、全体像を先に持っておくと読みやすいです。

launchd
 ~/Library/LaunchAgents/com.shun.article-daily.plist
 起動タイミング: 08:00 / 10:35（毎日）
     │
     ▼
 ~/.claude/scripts/claude-quota-guard.py
     --job com.shun.article-daily
     │  ← クォータ残量のガード層
     ▼
 ~/.discord/run-and-notify.sh
     "zenn" "Zenn記事ストック生成"
     │  ← Discord通知ラッパー
     ▼
 ~/.claude/scripts/article-daily-stock.sh  apply
     │  ← 実際の生成ロジック
     ▼
 claude -p "プロンプト..." [--model ???]
     │
     ├─ --model を明示した場合
     │       指定モデルの独立した枠で実行
     │       → 記事テキストが正常に返る ✅
     │
     └─ --model を省略した場合
             対話セッションの「既定モデル枠」を共有消費
             → 枠が切れると以下の1行だけ stdout に吐いて終了:
                 "You've reached your Fable limit."
             → exit code は非0
             → ただしログには「1行返ってきた」としか残らない
             → [ -s output ] 等の素朴なチェックを通り抜ける ❌
             → 何週間でも誰も気づかない ← 実際に3週間気づかなかった

図の最下段が障害の核心です。claude -p は --model を省略してもエラーにはなりません。静かに対話セッションの枠を消費しに行きます。枠が切れると1行のメッセージを返して終了する。その1行が「出力があった」と誤認されることで、検知がすり抜けます。

plistの実装

実際の com.shun.article-daily.plist を抜粋します（実パスは ~ 表記に変換）。

<key>ProgramArguments</key>
<array>
  <string>~/.claude/scripts/claude-quota-guard.py</string>
  <string>--job</string>
  <string>com.shun.article-daily</string>
  <string>--</string>
  <string>/bin/bash</string>
  <string>~/.discord/run-and-notify.sh</string>
  <string>zenn</string>
  <string>Zenn記事ストック生成</string>
  <string>/bin/bash</string>
  <string>~/.claude/scripts/article-daily-stock.sh</string>
  <string>apply</string>
</array>

<key>StartCalendarInterval</key>
<array>
  <dict>
    <key>Hour</key><integer>8</integer>
    <key>Minute</key><integer>0</integer>
  </dict>
  <dict>
    <key>Hour</key><integer>10</integer>
    <key>Minute</key><integer>35</integer>
  </dict>
</array>

<key>StandardOutPath</key>
<string>~/.claude/logs/article-daily.out.log</string>
<key>StandardErrorPath</key>
<string>~/.claude/logs/article-daily.err.log</string>

<key>ProcessType</key><string>Background</string>
<key>LowPriorityIO</key><true/>
<key>Nice</key><integer>10</integer>

ProcessType: Background・LowPriorityIO: true・Nice: 10 の3つはセットで入れています。OSのI/O調停に「これはバックグラウンドの低優先タスクです」と明示することで、フォアグラウンドの作業（Figmaを開く、Safariで調べ物をする）の邪魔をさせない設定です。

ジョブの呼び出し連鎖は launchd → quota-guard → run-and-notify → article-daily-stock の4段です。article-daily-stock.sh の内部で claude -p が呼ばれ、そこに --model があるかどうかが問題になります。

2026年9月3日に4レーン同時に露出した

私のケースでは、同じ欠落が4つのジョブで同時に表面化しました。ナレッジベースに残っている記録を引用します。

gen-column.mjs は3週間、毎朝「正常に動いているように見える状態」で在庫を消耗し続けました。発覚したのは在庫が残り2本になってからです。ジョブのログには「1行返ってきた」と記録されていました。その1行の中身を誰も読んでいなかった。

「4レーン同時」というのも重要な事実です。1本だけ壊れていれば気づきやすい。複数が同時に黙って止まっているとき、「全体が静かすぎる」という違和感は薄れます。むしろ「自動化が効いて手が空いている」と誤認する方向に引っ張られます。

問題の根本は**「--model を書かない」というコードの欠陥です。それが「1行ある = 成功」というログ監視の甘さ**と組み合わさることで、3週間検知されませんでした。2つの穴がそれぞれ単独では気づきやすい穴だったにもかかわらず、重なることで死角を作った。

この構造を、後半で解剖します。なぜ --model の省略がこれほど気づきにくいのか、検知を確実にする1スクリプトの作り方、そして既存の全 plist に書き忘れがないかを機械的に弾くgrepゲートの実装まで順番に見ていきます。

実装の詳細

--model の位置と書き方

障害を受けて修正したあとの article-daily-stock.sh を見ると、claude -p を呼び出す箇所は2か所あります。ネタ立案（キューが空のときに次のトピックを自動生成）と記事本文の生成です。どちらにも --model が入っています。

# キューが空のとき: 実作業からネタを自動立案（article-daily-stock.sh 327-330行目）
TOPIC_JSON=$(run_to 600 "$CLAUDE" -p "$REPLENISH_PROMPT" \
  --strict-mcp-config --mcp-config '{"mcpServers":{}}' \
  --model "${ARTICLE_MODEL:-sonnet}" --effort high \
  --output-format text --allowedTools "Read,Grep,Glob,Bash" --max-turns 20 2>>"$LOG")

# 記事本文の生成（article-daily-stock.sh 397-401行目）
run_to 1500 "$CLAUDE" -p "$PROMPT" \
  --strict-mcp-config --mcp-config '{"mcpServers":{}}' \
  --model "${ARTICLE_MODEL:-sonnet}" --effort high \
  --output-format text --allowedTools "Read,Grep,Glob,Write,Bash" --max-turns 40 >> "$LOG" 2>&1 \
  || log "WARN: claude -p exit非0（検証で弾く）"

"${ARTICLE_MODEL:-sonnet}" という書き方が肝です。環境変数 ARTICLE_MODEL が未定義の場合でも sonnet にフォールバックするので、「書き忘れたときに既定モデルへ流れる」という事故が起きません。さらに「コードにモデルIDをハードコードしない」という別の運用ルールも同時に満たしています。モデルIDを文字列で埋め込むと、ベンダーがエイリアスを廃止したときに全スクリプトを書き直す羽目になります。変数一本で切り替えられるようにしておけば、launchctl setenv ARTICLE_MODEL haiku の1行で全レーンを切り替えられます。

もう一点、--strict-mcp-config --mcp-config '{"mcpServers":{}}' の組み合わせを必ずセットで入れています。launchd からの起動はログインシェルを経由しないため、ホームディレクトリの .mcp.json が読まれます。その中に外部MCPサーバーの設定がある場合、バッチが意図せず外部ネットワークを叩きに行くことがあります。空のサーバー設定を明示することで、バッチ内での外部MCP呼び出しを完全に封じています。

strict_quota_message の設計——400字の壁

claude-quota-guard.py の中に strict_quota_message() という関数があります。これが今回の事故で最も重要な検知ロジックです。

# claude-quota-guard.py 41-47行目
STRICT_QUOTA_PATTERNS = (
    r"(?:you(?:'ve| have) )?hit your (?:weekly |5-?hour |usage |session )?limit",
    r"claude (?:ai )?usage limit reached",
    r"approaching your (?:weekly |usage )?limit",
)
STRICT_QUOTA_MAX_CHARS = 400

# claude-quota-guard.py 159-170行目
def strict_quota_message(text: str) -> bool:
    """成功終了(exit 0)の本文が「上限メッセージそのもの」かを判定する。

    上限本文は短く、その一文だけが返る。記事本文にたまたま同じ語が出ても発火させない。
    """
    trimmed = text.strip()
    if not trimmed or len(trimmed) > STRICT_QUOTA_MAX_CHARS:
        return False
    return any(
        re.search(pattern, trimmed, flags=re.IGNORECASE)
        for pattern in STRICT_QUOTA_PATTERNS
    )

STRICT_QUOTA_MAX_CHARS = 400 という上限が要の設計です。Claudeが上限に達したとき返す文字列は「You've reached your Fable limit.」や「You've hit your weekly limit.」の1文で、長くても数十文字です。一方、正常に生成された記事本文が400字以下であることはまずありません。この長さの非対称性を使って「上限メッセージそのものか」「上限に言及した記事本文か」を機械的に分離しています。

パターンを正規表現で書くときも同じ発想で設計しています。ゆるい QUOTA_PATTERNS（exit 非0のとき使う）と厳しい STRICT_QUOTA_PATTERNS（exit 0のとき使う）を分けているのは、記事本文の題材に「クォータ」が出てくる場合に自分でサーキットブレーカーを倒してしまう誤検知を防ぐためです。実際、この判定が甘いまま運用していた時期に「クォータを題材に書いた記事がサーキットブレーカーを落とした」という事故があったので、exit 0 / 非0 で判定ロジックを切り替える現在の実装に落ち着きました。

postcondition gate——「出力があった」では成功にしない

article-daily-stock.sh には article_ok() という関数が入っています（133-181行目）。claude -p の exit code が正常でも、この関数を通過しない限り記事は受け付けません。

# article-daily-stock.sh 133行目
MIN_ARTICLE_BYTES=1200

# article-daily-stock.sh 173-181行目
article_ok() {
  local f="$1"
  [ -s "$f" ] || return 1
  [ "$(stat -f%z "$f" 2>/dev/null || echo 0)" -ge "$MIN_ARTICLE_BYTES" ] || return 1
  grep -qE '^title:' "$f" || return 1
  frontmatter_title_ok "$f" || return 1
  grep -qiE 'request timed out|不明な商品|TODO: *本文|\(生成失敗\)' "$f" && return 1
  return 0
}

最低1200バイト、title: frontmatterの存在、タイトルが70字以内、タイムアウト文言の混入なし——この4条件をすべて満たして初めて「生成成功」と記録します。この検証ブロックは claude -p の直後に置き、ファイルが基準を満たさない場合はファイルを削除して終了します（411-415行目）。その日のスロットを無駄にしないよう、マーカーファイル（~/.claude/logs/.article-daily-done-${TODAY}）を「検証を通過してから初めて立てる」設計にしています（509行目）。

postconditionは「生成が正常に完了した」ことの証拠です。ファイルが存在するかどうかではなく、ファイルの中身が期待する品質を持っているかどうかを機械的に確かめる。この発想に切り替えてから、「ジョブが動いた＝成果が積まれた」という誤認がなくなりました。

書き忘れを機械で弾くgrepゲート

--model の書き忘れを人間が見つけるのは難しいです。ファイルが増えるほど目視チェックは限界になります。以下のワンライナーで、~/.claude/scripts/ と ~/Library/LaunchAgents/ 配下を横断して「claude -p はあるが --model が無い行」を抽出できます。

# plist配下のジョブスクリプトで --model を書き忘れている箇所を抽出する
grep -rn "claude -p" ~/.claude/scripts/ \
  | grep -v -- '--model' \
  | grep -v '^Binary'

これをCIやpre-commitフックに組み込むのが理想ですが、launchdジョブは通常のCIと接続されていません。代わりに次の方式を使っています。週次の launchctl list | grep com.shun で全ジョブの存在を確かめるタイミングに合わせて、上記のgrepを一緒に流します。0行で返れば全部セーフ。1行でも返ればどこかに書き忘れがある。

plistから呼ばれるスクリプトが呼ぶスクリプトがさらに呼ぶ……という多段呼び出しのケースでは、末端のスクリプトまで再帰的にたどる必要があります。

# 多段呼び出しも含めて再帰的に検索
grep -rn "claude -p\|claude --print" \
  ~/.claude/scripts/ \
  ~/dev/ \
  --include="*.sh" --include="*.mjs" --include="*.js" --include="*.py" \
  | grep -v -- '--model' \
  | grep -v '#.*claude -p'   # コメント行は除外

--include で対象拡張子を絞らないと結果が膨大になります。.sh .mjs .js .py の4種で自分の環境の9割は網羅できました。

---

私が詰まった話

3週間、在庫が2本になるまで気づかなかった

gen-column.mjs は毎朝LINEコラムを1本生成するジョブです。在庫が5本を下回った段階でアラートが上がる設計にしていたはずが、なぜか発火しませんでした。在庫が2本になったとき、Discordの通知を手動で見ていて初めて「おかしい」と気づきました。

ログを掘ると、毎朝こうなっていました。

[2026-08-14 08:03:12] claude -p "..." 実行
[2026-08-14 08:03:19] 出力: "You've reached your Fable limit."
[2026-08-14 08:03:19] 出力文字数: 32
[2026-08-14 08:03:19] ジョブ完了

ジョブが「完了」して exit 0 を返していたので、quota-guardの集計には「成功」として記録されました。在庫カウントのロジックが「正常完了=1本生成成功」として加算していたため、在庫数は増えているように見えていた。実際には1本も増えていないのに。

発覚した原因は在庫の実ファイル数を直接 ls で数えたことです。それが2だった。ジョブの成功カウントと実ファイル数の乖離が証拠でした。

その後、在庫監視をカウンタではなく実ファイル数にすること、生成後の postcondition checkを入れること、の2点を入れました。カウンタは「生成した」という意思表示であって「生成できた」という証拠にはなりません。

文言が変わっただけでサーキットブレーカーが素通りした

2026年9月2日、claude-quota-guard.pyの QUOTA_PATTERNS が session limit を含んでいなかったことが判明しました。

その日のエラーメッセージは以下のような形式でした。

You've hit your session limit · resets 6:50pm (Asia/Tokyo)

これは「5時間セッション上限」の文言です。従来の「weekly limit」や「Fable limit」とは表現が違う。当時の QUOTA_PATTERNS にはこのパターンが入っていなかったため、クォータ検知が通り抜けました。結果、その日の note 3レーン含む全ジョブが上限中に空撃ちし続け、306行分の無駄なClaude呼び出しが4時間続きました。

修正は QUOTA_PATTERNS に r"resets?\s+(?:at\s+)?\d{1,2}(?::\d{2})?\s*[ap]m" を追加することでした（claude-quota-guard.py 37行目）。「resets」という動詞と「時刻（am/pm形式）」の組み合わせを拾うパターンです。この行は現在もコードの中に残っており、コメントに「2026-09-02: 5時間上限は〜の形式で返る」と実況が記録されています。

ここで学んだのは「クォータ検知をベンダーの文言に依存させてはいけない」という原則です。文言はベンダーが変えます。変えたことをアナウンスしません。Anthropicは過去にも「You've reached your limit」「You've hit your Fable limit」「You've hit your session limit」と複数の表現を使ってきました。パターンマッチは「文言の完全一致」ではなく「文言の構造的特徴」で書く必要があります。

サーキットブレーカーが投稿ジョブまで止めた

2026年8月21日、サーキットブレーカーが開いた（=クォータ超過を検知した）とき、生成ジョブだけでなく投稿ジョブまで止まるという問題が起きました。

claude-quota-guard.pyのコメントに記録があります。

# 🔴 2026-08-21: circuit が開くと全ジョブが一律で止まるため、消費の大半を占める
# 返信/エンゲージ系がクォータを使い切った巻き添えで「投稿」まで停止していた。
# 実測(launchd.log 累計): xpilot.autopost は 231実行/308スキップ＝実行率43%で、
# threadspilot.engage(64%) より優先度が低い扱いになっていた。投稿はその時間帯を逃すと
# 二度と埋まらないので...

投稿はタイミングが命です。朝8時のスロットを逃した投稿は夜に上げても同じ効果はありません。生成ジョブとは優先度が根本から違う。

問題の原因は「サーキットブレーカーが全ジョブを区別なく止める」設計にあります。クォータを使い切ったのは生成ジョブなのに、投稿ジョブまで巻き添えで止まっていました。

対処として --priority フラグを入れました（現在のコードに run_job() の priority: bool 引数として残っています）。優先ジョブは claim_priority_probe() によって PRIORITY_PROBE_INTERVAL（既定30分）ごとに1回だけ、サーキットが開いていても試行を許します（claude-quota-guard.py 454-468行目）。試行が成功すれば「クォータが回復した」と判断してサーキットを閉じる。この設計により、「投稿は止まらない、回復の早期検知もできる」という二重の目的を1機構で達成しています。

exit 0 を返しながらクォータメッセージだった

最も見つけにくかったのが「exit code が 0 で、stdout に上限メッセージが返ってくる」パターンです。これは --model を省略したときだけでなく、特定の条件下でclaudeがクォータメッセージを「成功」として返す場合にも起きます。

当初の quota-guard は exit code が 0 のとき「成功」として記録し、サーキットを閉じる方向に判定していました。このため、exit 0 で上限メッセージが返ってきてもサーキットは開かず、ジョブは「成功」と記録され、実際の出力は上限の1行だけ——という状態が何サイクルも続くことがありました。

strict_quota_message() の導入（前述の400字チェック）はこの問題への直接の対処です。exit 0 であっても、stdout がその関数の条件を満たす場合はクォータ検知として扱い、サーキットを開きます（claude-quota-guard.py 187-190行目）。

def is_quota_response(returncode: int, text: str) -> bool:
    if returncode != 0:
        return quota_message(text)        # ゆるいパターン
    return strict_quota_message(text)     # 厳しいパターン（400字以下＋構造マッチ）

exit code と出力内容を両方見て判定する。この設計が入ってから「exit 0 の偽成功」による見逃しがなくなりました。

---

今から振り返ると、4つの障害はすべて同じ1本の根から生えていました。「claude -p は引数が不完全でもエラーにならない」という性質です。不完全な引数でも、予想外の挙動でも、Claudeは何かを返します。その「何か」が出力として記録されるため、監視が甘いとすべてが正常に見える。

完璧な前提でジョブを設計するのではなく、不完全な実行を前提にして検知と回復を積み重ねる——その思想に移行してから、4レーン同時停止のような事故は起きていません。

つまずきポイント

実際にやらかした順に並べます。どれも「そのうち気づくだろう」と思っていたら気づきませんでした。

--model を省略しても、コマンドがエラーにならない claude -p は引数が不完全でも黙って実行します。省略時は対話セッションの枠を共有消費するため、問題が表面化するのは「対話枠が切れたとき」であり、バッチを書いた瞬間ではありません。書き忘れたその日に壊れるわけではなく、何週間かあとに別のタイミングで静かに死にます。因果が離れているほど原因に気づけない。

exit 0 で上限メッセージが返ってくる --model を省略して対話枠が切れると、claude -p は「You've reached your Fable limit.」を stdout に吐いて終了します。このとき exit code が 0 のケースが存在します。$? で成功判定しているスクリプトは、上限メッセージを正常な出力と区別できません。[ -s output.txt ] もファイルが空でなければ通過します。32文字でも「出力があった」と判定される。

在庫カウンタと実ファイル数が乖離する gen-column.mjs のケースでは、ジョブが「完了」して exit 0 を返すたびに成功カウンタが増え、在庫が「増えているように見えていた」。実際には1本も増えていない。カウンタは「生成しようとした」という意思表示であって、「生成できた」という証拠ではありません。在庫が実際に2本になるまで3週間気づかなかったのは、監視の指標をカウンタに置いていたからです。

4レーン同時停止で「自動化が効いている」と誤認する 1本のジョブが止まっていれば「どこかおかしい」と気づきやすい。4本が同時に黙って止まると、「全体が静かすぎる」という違和感は薄れます。むしろ「手が空いている＝自動化が効いている」という方向に引っ張られます。9/3に露出した4レーン同時停止は、まさにこのメカニズムで3週間見逃されました。

クォータの文言はベンダーが無告知で変える 9/2のエラーは「You've hit your session limit · resets 6:50pm (Asia/Tokyo)」という形式で、従来の「weekly limit」「Fable limit」とは表現が違いました。当時の QUOTA_PATTERNS にこのパターンが入っておらず、クォータ検知をすり抜けました。結果、4時間で306行分の無駄なClaude呼び出しが続きました。「文言の完全一致」で検知を書くと、ベンダーが表現を変えた瞬間に無力化されます。

サーキットブレーカーが投稿ジョブまで一律で止める 8/21に起きた事故です。生成ジョブがクォータを使い切ったとき、投稿ジョブまで巻き添えで停止しました。実測では xpilot.autopost の実行率が43%まで落ちていました。生成ジョブは失敗してもリトライできます。投稿はその時間帯を逃すと二度と埋まりません。優先度が根本から違うジョブを同じサーキットブレーカーで止める設計が問題でした。

launchd はログインシェルを通らない plistから起動されるスクリプトは、ターミナルで手動実行するときと実行環境が違います。~/.zshrc の PATH が読まれない。nvm で管理している node や claude コマンドが見つからない。com.shun.article-daily.plist に EnvironmentVariables で PATH を明示しているのはそのためです。手元で動くのに launchd では死ぬ原因の大半はこれです。

.mcp.json が読まれてバッチが外部ネットワークを叩く launchd 起動では、ホームディレクトリの .mcp.json が自動で読まれます。ローカル開発用のMCPサーバー設定がある場合、バッチが意図せず外部に接続しに行きます。--strict-mcp-config --mcp-config '{"mcpServers":{}}' を入れないと、バッチが何をしているか手元では再現できない動作をすることがあります。

モデルIDをスクリプトにハードコードすると一斉破綻する モデルのエイリアスをベンダーが廃止・改名したとき、文字列を埋め込んでいるスクリプトを全部書き直す羽目になります。--model claude-sonnet-4-5 のようにバージョン込みで書いていると、モデルが更新されるたびに全スクリプトを巡回する作業が発生します。

`在庫5本以下でアラート」が発火しなかった アラートのロジックが在庫数をカウンタから取得していたため、カウンタが「増えている（実際には増えていない）」間はアラートが発火しませんでした。監視の指標は生成ジョブの成功カウントではなく、ファイルシステムの実ファイル数でなければいけません。

---

ベストプラクティス

4レーン同時停止と3週間の気づかないロスから蒸留した、今でも全ジョブに適用しているルールです。

1. claude -p には必ず --model を明示する これがすべての起点です。省略は禁止。ジョブを書く前から「--model のない claude -p は存在しない」をルールにします。

2. 環境変数フォールバックで書く

--model "${ARTICLE_MODEL:-sonnet}"

モデルIDをスクリプトに直書きしません。未定義時の :-sonnet フォールバックにより「書き忘れて既定枠に落ちる」を防ぎ、launchctl setenv ARTICLE_MODEL haiku の1行で全ジョブを切り替えられます。

3. postcondition gate を claude -p の直後に置く

MIN_ARTICLE_BYTES=1200
article_ok() {
  [ -s "$f" ] || return 1
  [ "$(stat -f%z "$f")" -ge "$MIN_ARTICLE_BYTES" ] || return 1
  grep -qE '^title:' "$f" || return 1
  grep -qiE 'request timed out|TODO: *本文' "$f" && return 1
  return 0
}

「出力があった」では成功にしません。最低バイト数・frontmatterの存在・タイムアウト文言の混入——この3条件をすべて満たして初めて「生成成功」と記録します。

4. 在庫監視は実ファイル数で行う カウンタは意思表示、実ファイル数は証拠です。アラートの指標は ls ~/.claude/stock/ | wc -l の実数に置きます。カウンタが増えていてもファイルが増えていなければ失敗です。

5. クォータ検知は「文言の構造」で書く "Fable limit" のような完全一致ではなく、以下のような構造パターンを使います。

r"(?:you(?:'ve| have) )?hit your (?:weekly |5-?hour |usage |session )?limit"
r"resets?\s+(?:at\s+)?\d{1,2}(?::\d{2})?\s*[ap]m"

ベンダーが文言を変えても、「上限に達した」という構造を持つ表現であれば拾えます。

6. exit code と出力内容を両方見て判定する

def is_quota_response(returncode: int, text: str) -> bool:
    if returncode != 0:
        return quota_message(text)        # ゆるいパターン
    return strict_quota_message(text)     # 厳しいパターン（400字以下＋構造マッチ）

exit 0 の偽成功を防ぐには、exit code と stdout の両方を独立してチェックします。

7. 400字の上限でクォータメッセージと記事本文を分離する Claudeが上限で返すメッセージは数十文字です。正常な記事本文が400字以下になることはまずありません。len(trimmed) > 400 なら上限メッセージとして判定しない——この1行が「クォータを題材にした記事が自分のサーキットブレーカーを落とす」という誤検知を防ぎます。

8. バッチには --strict-mcp-config --mcp-config '{"mcpServers":{}}' をセットで入れる launchd 経由の起動では .mcp.json が読まれます。空のサーバー設定を明示することで、バッチが外部MCPを意図せず呼びに行く事故を封じます。この2フラグはセットで1つの設定です。片方だけでは機能しません。

9. ジョブの優先度でサーキットブレーカーの挙動を変える 投稿ジョブと生成ジョブを同じサーキットブレーカーで止めません。投稿は priority: true でマークし、サーキットが開いていても PRIORITY_PROBE_INTERVAL（30分ごと）に1回だけ試行を許します。試行成功でクォータ回復を検知してサーキットを閉じる——投稿の停止防止と回復の早期検知を1機構で達成します。

10. plist を書いたらその場で grep ゲートを流す

grep -rn "claude -p\|claude --print" \
  ~/.claude/scripts/ ~/dev/ \
  --include="*.sh" --include="*.mjs" --include="*.js" --include="*.py" \
  | grep -v -- '--model' \
  | grep -v '#.*claude -p'

0行なら全ジョブセーフ。1行でも返れば書き忘れがあります。plist を追加したタイミングで必ず流します。週次の launchctl list 確認のタイミングに合わせて流すと習慣になります。

11. ProcessType: Background / LowPriorityIO: true / Nice: 10 の3点セット この組み合わせをすべてのバッチジョブに入れます。OSに「低優先バックグラウンドタスク」と明示することで、Figmaを開いている・ブラウザで調べ物をしているといったフォアグラウンド作業の邪魔をしません。plistのデフォルトは何も設定しない（Standard優先）なので、明示しなければ削られます。

12. launchd 用 PATH は EnvironmentVariables で明示する nvm で管理している node や claude は、ログインシェルの PATH にしか存在しません。launchd からの起動はログインシェルを経由しないため、EnvironmentVariables キーに nvm のバイナリパスを含む PATH を明示します。com.shun.article-daily.plist の実装では ~/.nvm/versions/node/v24.13.0/bin をPATHの先頭に入れています。

13. 多段呼び出しは末端まで再帰 grep する plist → quota-guard.py → run-and-notify.sh → article-daily-stock.sh → claude -p という連鎖では、grep ゲートを plist だけにかけても末端のスクリプトは検査されません。--include で .sh .mjs .js .py を指定して、呼び出し連鎖の末端まで再帰的に検索します。

14. スクリプトに日付つきコメントで事故記録を残す claude-quota-guard.py の37行目に # 2026-09-02: 5時間上限は〜の形式で返る というコメントが残っています。パターンを追加した理由と日付を書いておくことで、半年後の自分（あるいは Claude Code）がコードを読んだときに「なぜこのパターンがあるのか」を推測しなくて済みます。障害の経緯はコミットメッセージより、コードの隣に書く方が読まれます。

---

まとめ

--model の省略は1行の書き忘れです。それが3週間、4レーン同時、在庫2本まで枯渇という障害を作りました。コマンドがエラーにならない・exit 0 で返ってくる・ログには「1行あった」と残る——この3つが重なると、人間の目視では何週間でも気づきません。

自動化をインフラとして使うには、「完璧に動く」という前提でジョブを設計してはいけません。不完全な実行を前提にして、検知と回復を積み重ねるのが正しい思想です。--model の明示は出発点で、postcondition gate・実ファイル数監視・構造パターン検知・優先度付きサーキットブレーカーはその延長にあります。

今は4レーンが同時に黙って止まるような事故は起きていません。ジョブが増えても同じ原則が適用できるので、171本のジョブが動いていても追加のメンタルコストはほぼゼロです。「環境が自分の代わりに動く」が成立するのは、環境が壊れたときに自分で気づき、自分で回復する仕組みが入っているからです。

---

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

---

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

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

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