📊 自動化が赤字になる前に止める ― weekly revenue-gate でコンテンツ収支を可視化する

解雇通知を受け取ったとき、Claude APIの請求書は翌月も容赦なく届きます。量産ラインを14本同時に回しながら、月商120万を維持できているのは「いくら稼いだか」ではなく「どのラインが赤字化しているか」を毎週月曜に自動で可視化する仕組みを先に作ったからです。

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

複数の量産ラインを同時に走らせると、奇妙なことが起きます。忙しいほど、数字を見なくなるのです。

アフィリ記事ラインは週28本出力しています。LINEスタンプラインは週19セット。iOSアプリのアイデア出力は週8本。SNS投稿ラインに至っては週120本以上のファイルをはき出します。これだけの量を手作業で管理していると、「このラインは先月いくら稼いだ？」という問いに即答できる人はまずいません。そして答えられない状態というのは、赤字ラインを無意識に養い続けている状態と同義です。

Claude APIの費用は小さく見えます。1回のプロンプト実行は数円です。ところが14ラインが週に合計数百本のファイルを生成し続けると、月のAPI費用は積み上がります。そのとき「どのラインが稼いでいないのか」をすぐに言えないと、コスト削減の判断ができません。

ここで典型的な対応は「スプレッドシートをつける」です。しかし私はそれをやりませんでした。週次でスプレッドシートを開いて記入する作業が、習慣として続いた試しがないからです。続かない作業は「環境」ではなく「意志力」に依存しています。意志力は有限です。

revenue-gate.sh が解決するのはここです。毎週月曜8時20分、Mac が自動でレポートを生成してデスクトップに置く。 開くだけでいい。書くものはない。判断だけを人間がやる。

作業でなく環境を作ることの意味はここにあります。判断のトリガーが外部から自動で届くなら、意志力を消費せずに意思決定できます。レポートが届く＝何かが変わったサインという条件反射を一度作ると、週次の収益確認は「やること」ではなく「自然に起きること」になります。

もう一つの設計思想は**「止める判断は人間がする、でも止めるべきラインを見つけるのは機械がする」**という役割分担です。スクリプトは自動停止しません。コードを読むとこう書いてあります。

KILL推奨のジョブは「何のため/誰が嬉しい/いくら儲かる/いつ見切る」に
答えられなければ停止する（自動停止はしない。判断は人間）

自動停止しない設計は重要です。機械が勝手にラインを止めると、止まった原因の検証もできないし、誤検知で稼ぎ頭を殺す可能性があります。機械の仕事は「このラインは連続2週間、何本も出力したのに収益がゼロです」という事実を突きつけることです。そこから先は人間の判断です。

実際に2026-07-03の初回レポートでは、ASMRラインが週14本出力していて🟢（緑）でした。翌週2026-07-06のレポートでは週0本になり⚠️（出力停止？）になっていました。この変化は、私が意図して止めたのではなく、何らかの理由でジョブが止まっていたことを意味します。レポートがなければ気づかずに「ASMRラインは動いている」と思い込んだまま、別の最適化に時間を使っていたはずです。

全体の流れ

仕組みの全体像を先に示します。

┌─────────────────────────────────────────────────────┐
│  毎週月曜 8:20 / 13:20  (launchd 二重発火)          │
└──────────────────────┬──────────────────────────────┘
                       │
                       ▼
              revenue-gate.sh
                       │
        ┌──────────────┼──────────────┐
        │              │              │
        ▼              ▼              ▼
 revenue.jsonl   revenue-gate.conf  各ラインの
 (売上ログ)      (ライン定義)       出力ディレクトリ
                                   (ファイル数カウント)
        │              │              │
        └──────────────┼──────────────┘
                       │
                       ▼
            revenue-gate-state.json
            (連続ゼロ収益週カウント)
                       │
                       ▼
              Markdown レポート生成
                       │
          ┌────────────┴────────────┐
          ▼                         ▼
  ~/Desktop/Revenue Gate/   Obsidian vault
  (即時確認用)               (briefs/revenue-gate/)

関与するファイルは5種類です。順番に見ていきます。

ライン定義ファイル（revenue-gate.conf）

~/.claude/data/revenue-gate.conf がすべての量産ラインを管理します。フォーマットはパイプ区切りの3列です。

name|出力ディレクトリ|glob

実際のファイルから抜粋するとこうなっています。

article|~/Desktop/Article/articles|
note|~/Desktop/Article/note|
maker|~/Desktop/Article/solomaker|
affiliate|~/Desktop/アフィリ記事|
asmr|~/dev/asmr-factory/out|
sns-bokuwalily|~/dev/bokuwalily-sns/out|
senior-tube|~/dev/senior-tube-factory/drafts|
line-stamps|~/digital-products/line-stamps-keigo/out|
lead-outreach|~/lead-finder/runs/_logs
idea-ios|~/Desktop/iosアプリ|
idea-chrome-ext|~/Desktop/Chrome拡張|
affiliate-livedoor|~/dev/affiliate-livedoor/queue|
affiliate-blogger|~/dev/affiliate-blogger/queue|
affiliate-fc2|~/dev/affiliate-fc2/published|

14ラインが定義されています。3列目の glob は省略すると *（全ファイル）として扱われます。特定の拡張子だけカウントしたい場合（例：*.mp3、*.md）は3列目に指定できます。

新しいラインを追加するときは、この conf に1行足すだけです。スクリプト本体には触りません。

売上ログ（revenue.jsonl）

~/.claude/data/revenue.jsonl に収益を記録します。形式はJSON Lines（1行1レコード）です。

{"date":"2026-06-15","source":"note","amount_jpy":3200,"note":"有料記事1本"}
{"date":"2026-06-22","source":"affiliate","amount_jpy":8400,"note":"Amazon報酬"}

source が conf の name と一致することで、どのラインの売上かが紐づきます。記録は付属の rev.sh コマンドで行います。

rev.sh note 3200 有料記事1本

ここは唯一の手作業ポイントです。売上通知が来たタイミングで実行します。cronで自動入力できる収益（APIで取れるASP等）は将来的に自動化できますが、現状は手動で十分です。週に数回、5秒の作業です。

状態ファイル（revenue-gate-state.json）

「連続ゼロ収益週」のカウントを保持します。

{
  "updated": "2026-07-06T08:20:05",
  "week": "202628",
  "zero_weeks": {
    "affiliate": 2,
    "article": 2,
    "asmr": 2,
    "idea-chrome-ext": 2,
    "idea-ios": 2,
    "lead-outreach": 2,
    "line-stamps": 2,
    "maker": 2,
    "note": 2,
    "senior-tube": 2,
    "sns-bokuwalily": 2
  }
}

2026-07-06時点では全ラインが zero_weeks: 2 です。収益ログの記録を始めたタイミングがこの週なので、当然の状態です。運用が進むにつれて、稼ぐラインは0にリセットされ、稼がないラインのカウンターだけが上がっていきます。

スケジューラ（revenue-gate.plist）

macOS の launchd に登録した自動実行の定義です。月曜日の2回発火が特徴的です。

<key>StartCalendarInterval</key>
<array>
    <dict>
        <key>Weekday</key><integer>1</integer>
        <key>Hour</key><integer>8</integer>
        <key>Minute</key><integer>20</integer>
    </dict>
    <dict>
        <key>Weekday</key><integer>1</integer>
        <key>Hour</key><integer>13</integer>
        <key>Minute</key><integer>20</integer>
    </dict>
</array>

8:20 に起動していれば1回目に実行されます。Macが起動していなかった場合（週末に閉じたまま月曜を迎えるケース）、launchd は「起動時刻を過ぎた場合は次回まで待つ」のがデフォルト動作なので、13:20 の2回目が保険になっています。

スクリプト側には週内の重複実行を防ぐ仕組みが入っています。

WEEK_MARKER="$LOG_DIR/.revenue-gate-done-$(date +%G%V)"
if [ -f "$WEEK_MARKER" ] && [ "${REVENUE_GATE_FORCE:-0}" != "1" ]; then
  exit 0
fi

%G%V はISO週番号（例：202628）です。レポートを一度生成すると .revenue-gate-done-202628 というマーカーファイルを置き、同じ週に2回目が起動しても即終了します。強制再実行したいときは REVENUE_GATE_FORCE=1 bash ~/.claude/scripts/revenue-gate.sh で上書きできます。

判定ロジック（revenue-gate.sh 内の Python）

スクリプトの中核はシェルに埋め込まれた Python ヒアドキュメントです。Python 3 を直接使うことで、日付計算・ファイル走査・JSON操作を確実に行っています。

def weekly_file_count(directory, glob):
    root = pathlib.Path(directory)
    if not root.is_dir():
        return None
    threshold = dt.datetime.now().timestamp() - (7 * 24 * 60 * 60)
    count = 0
    for current_root, _, files in os.walk(root):
        for filename in files:
            if not fnmatch.fnmatch(filename, glob):
                continue
            path = pathlib.Path(current_root) / filename
            try:
                if path.stat().st_mtime >= threshold:
                    count += 1
            except OSError:
                continue
    return count

weekly_file_count は出力ディレクトリ以下を再帰的に走査し、更新タイムスタンプが7日以内のファイルを数えます。 revenue.jsonl の売上記録ではなく、実際のファイルシステムを直接カウントする点が重要です。ジョブが「動いているつもり」でも出力ゼロなら即座に検出できます。

判定の閾値はこのロジックです。

if count is not None and zweeks >= 4 and count > 0:
    verdict = "🔴 KILL推奨"
elif count is None or count == 0:
    verdict = "⚠️ 出力停止?"
elif zweeks >= 2:
    verdict = "🟡 要観察"
else:
    verdict = "🟢"

4段階の判定基準を整理するとこうなります。

🟢（正常） ― 連続ゼロ収益が2週未満、かつ出力あり。まだ早期なので静観。

🟡（要観察） ― 連続ゼロ収益が2〜3週。出力は続いているが収益が出ていない。コスト対効果の検証を始めるシグナル。

⚠️（出力停止？） ― 直近7日間のファイル数がゼロまたは計測不能。ジョブ自体が止まっている可能性。障害かもしれないし、意図的に止めたがconfに残っているだけかもしれない。

🔴（KILL推奨） ― 連続4週以上ゼロ収益なのにファイルは出続けている。これが最も危険な状態です。APIコストだけが流出し続けているラインです。

初回レポート（2026-07-03）と2回目（2026-07-06）を並べると、3日間でラインの状態がどう変わったかが見えます。

ライン	07-03 出力	07-06 出力	判定変化
sns-bokuwalily	237本	120本	🟢→🟡
note	40本	49本	🟢→🟡
maker	36本	30本	🟢→🟡
affiliate	31本	28本	🟢→🟡
asmr	14本	0本	🟢→⚠️
article	14本	11本	🟢→🟡

全ラインが🟡か⚠️に移行したのは収益記録をまだ開始していないためです（revenue.jsonl は空）。しかし重要な変化が1件あります。ASMRラインが07-03時点で週14本の出力をしていたにもかかわらず、07-06では0本になっています。これはスクリプトが自動で検出した異常です。手作業で監視していれば、おそらく数週間は気づかなかったと思います。

実装の詳細

Python をシェルに埋め込む理由

revenue-gate.sh のコアはシェルスクリプトではなく、シェルに埋め込まれた Python です。スクリプトの32行目からこう始まります。

TMP_REPORT="$(mktemp /tmp/revenue-gate.XXXXXX.md)"
if /usr/bin/python3 - "$CONF" "$REVENUE_FILE" "$STATE_FILE" "$REPORT_DATE" > "$TMP_REPORT" <<'PY'
import datetime as dt
import fnmatch
import json
import os
import pathlib
import sys
...
PY

<<'PY' というシングルクォートのヒアドキュメントは、本体中の $ をシェルが展開しないようにするための書き方です。クォートなしで <<PY と書くと、Python コード中の $HOME や ${something} がシェルに食われます。自動化スクリプトでこのミスをやると無音で壊れるので気をつけてください。

/usr/bin/python3 とフルパスで書いているのは、launchd の PATH が貧相だからです。python3 だけ書くと /usr/bin しか通っていない環境では見つからない。Homebrew の /opt/homebrew/bin に入っているライブラリを使う場合はさらに注意が要ります（今回は標準ライブラリのみなので /usr/bin/python3 で問題ありません）。

引数を sys.argv[1] 以降で受け取る方式にしているのは、Python 内でパスを直接文字列として書くことを避けるためです。将来 conf のパスを変えたくなったとき、シェル変数を1か所直すだけで済みます。

zero_weeks カウンタのステートマシン

revenue-gate-state.json の更新ロジックは84〜108行目です。週番号（%G%V）が変わった場合だけカウントを更新します。

if state.get("week") == current_week:
    # 同じ週の再実行 → カウントは変えない
    for entry in entries:
        name = entry["name"]
        try:
            zero_weeks[name] = int(zero_weeks.get(name, 0))
        except (TypeError, ValueError):
            zero_weeks[name] = 0
else:
    # 新しい週 → 収益ゼロなら+1、収益あれば0にリセット
    for entry in entries:
        name = entry["name"]
        if weekly_revenue.get(name, 0.0) > 0:
            zero_weeks[name] = 0
        else:
            try:
                previous = int(zero_weeks.get(name, 0))
            except (TypeError, ValueError):
                previous = 0
            zero_weeks[name] = previous + 1

state.get("week") == current_week の分岐が効いているのは、REVENUE_GATE_FORCE=1 で強制再実行したときです。同じ週に2回目を走らせても zero_weeks が二重にカウントされません。

try / except (TypeError, ValueError) は JSON にゴミが入っていたときの防御です。たとえば "zero_weeks": {"note": null} のように null が入った状態から int(None) しようとすると TypeError が出ます。自動化ジョブは数ヶ月後に自分が忘れた頃に壊れるので、このくらいの防御は入れておくべきです。

weekly_file_count の os.walk と fnmatch

量産ジョブの実態を見るのが weekly_file_count です（132〜148行目）。

def weekly_file_count(directory, glob):
    root = pathlib.Path(directory)
    if not root.is_dir():
        return None
    threshold = dt.datetime.now().timestamp() - (7 * 24 * 60 * 60)
    count = 0
    for current_root, _, files in os.walk(root):
        for filename in files:
            if not fnmatch.fnmatch(filename, glob):
                continue
            path = pathlib.Path(current_root) / filename
            try:
                if path.stat().st_mtime >= threshold:
                    count += 1
            except OSError:
                continue
    return count

肝は3つあります。

ディレクトリが存在しないときに None を返す。 return None が判定ロジックに流れると count is None で ⚠️ 出力停止? になります。「パスが間違っているのかジョブが止まったのかわからない」という区別を判定結果に含めようとすると設計が複雑になるので、None をそのまま ⚠️ にマッピングするのが妥当です。

st_mtime で過去7日間を切る。 os.path.getmtime ではなく pathlib.Path(...).stat().st_mtime を使っています。どちらも同じですが、ループ中ですでに path オブジェクトを作っているのでメソッド呼び出しが1つで済みます。OSError を continue で飛ばしているのは、走査中にファイルが削除されることへの対処です。

fnmatch.fnmatch でグロブフィルタをかける。 *.md を指定すれば Markdown だけ、*.mp3 なら音声だけを対象にできます。この関数はシェルのグロブより単純で、** による再帰マッチはありません。再帰は os.walk 側が担っています。

出力結果はレポートのこの列に出ます（2026-07-06 の実レポートから抜粋）。

| sns-bokuwalily | 120 | 2 | 🟡 要観察 |
| note           |  49 | 2 | 🟡 要観察 |
| maker          |  30 | 2 | 🟡 要観察 |
| affiliate      |  28 | 2 | 🟡 要観察 |

sns-bokuwalily の120本はSNS投稿ジョブが週120本以上のファイルを吐いていることを意味します。これがAPIコストを押し上げているラインの筆頭候補で、収益が出ない週が続けば🔴になります。

mktemp → Python stdout → cp の2ステップ書き出し

レポートの書き出しはこう流れます。

TMP_REPORT="$(mktemp /tmp/revenue-gate.XXXXXX.md)"
if /usr/bin/python3 - ... > "$TMP_REPORT" <<'PY'
...
PY
then
  mkdir -p "$DESKTOP_DIR" "$VAULT_DIR"
  cp "$TMP_REPORT" "$DESKTOP_DIR/revenue-gate-${REPORT_STAMP}.md"
  cp "$TMP_REPORT" "$VAULT_DIR/revenue-gate-${REPORT_STAMP}.md"
  touch "$WEEK_MARKER"
  echo "[...] revenue-gate archived" >> "$LOG"
else
  status=$?
  echo "[...] ERROR: report generation failed (${status})" >> "$LOG"
  rm -f "$TMP_REPORT"
  exit "$status"
fi

rm -f "$TMP_REPORT"

Python が成功したときだけ cp でデスクトップと Obsidian vault の両方にコピーします。失敗したときは $TMP_REPORT を削除してログにエラーを残し、exit "$status" で非ゼロ終了します。mktemp を使うのは、Python が途中で失敗して不完全なファイルが残ることを防ぐためです。宛先に直接書いてしまうと「半分だけ書かれた壊れたレポート」がデスクトップに残ります。

スクリプトの最終行でマーカーファイルの古いものを削除しています。

find "$LOG_DIR" -maxdepth 1 -name '.revenue-gate-done-*' -mtime +35 -delete 2>/dev/null

-mtime +35 は35日以上前のマーカーを消します。週次に1個ずつ溜まるファイルが ~/.claude/logs/ に無限に増えないための掃除です。

---

私が詰まった話

set -u と launchd の環境変数が衝突した

初期版は重複実行チェックをこう書いていました。

if [ "$REVENUE_GATE_FORCE" != "1" ]; then
  # チェックロジック
fi

ターミナルから手動実行すると普通に動きます。しかし launchd 経由で月曜8:20に発火させたとき、ログに何も出ないまま処理が止まる事象が発生しました。

原因は set -u との組み合わせです。launchd は /bin/bash を新しいセッションとして起動するため、REVENUE_GATE_FORCE は環境変数として存在しません。set -u がある状態で未定義変数を参照すると、シェルはその行で即終了します。スクリプトは24行目の echo "[...] ===== revenue-gate 開始 =====" >> "$LOG" に到達する前に死んでいたので、ログには何も記録されませんでした。

直し方はシンプルです。

# 変更前
if [ "$REVENUE_GATE_FORCE" != "1" ]; then

# 変更後
if [ "${REVENUE_GATE_FORCE:-0}" != "1" ]; then

:-0 は「変数が未定義またはnullなら 0 を使う」という Bash の Parameter Expansion です。set -u を全体に効かせたまま特定の変数だけデフォルト値を持たせる、正しいパターンです。現在のコード（20行目）は ${REVENUE_GATE_FORCE:-0} になっています。

自動化スクリプトで set -u を入れるのは正しい判断ですが、「環境変数をオプショナルに受け取りたい変数」は全て :- 形式にしないといけない。ターミナルで動く＝launchd でも動くという思い込みがこのバグの根本です。

.DS_Store が出力数にカウントされていた

revenue-gate.conf でグロブを省略したラインは *（全ファイル）として扱われます。

sns-bokuwalily|~/dev/bokuwalily-sns/out|

このラインの出力ディレクトリを Finder で開いた際、macOS が自動で .DS_Store を生成しました。Python の fnmatch.fnmatch(".DS_Store", "*") は True を返します。os.walk はドットファイルを除外しません。結果として、ジョブが何も出力していないのに「週出力数: 1」と表示されてしまいました。

zero_weeks が1の時点で出力が1本だと 🟢 の判定になります。「問題なし」に見えるのに実際はジョブが死んでいた、という誤検知です。

暫定の直し方は conf の3列目に明示的な拡張子を指定することです。

sns-bokuwalily|~/dev/bokuwalily-sns/out|*.md

根本的には weekly_file_count の中でドットファイルを除外するフィルタを追加するべきですが、「glob を明示しないラインは運用者の責任」という割り切りで現状は設計しています。

revenue.jsonl の source 名をタイポして売上が迷子になった

rev.sh で売上を記録するとき、source の名前は revenue-gate.conf の name 列と完全一致しないといけません。

{"date":"2026-07-01","source":"affiliate","amount_jpy":8400,"note":"Amazon報酬"}

私が実際にやったミスは affiliate-livedoor のつもりで affiliate と打ってしまったことです。8,400円の売上が affiliate-livedoor ラインではなく affiliate ラインに計上されました。気づいたのはレポートを見たとき。affiliate-livedoor の zero_weeks がリセットされていないのに affiliate だけリセットされていたからです。

症状の特徴は「合計収益は正しいが、ラインの判定がズレる」という点です。合計で見ると売上は入っているのに、特定ラインが永遠に🟡から上がってこない。

修正は revenue.jsonl を直接編集することです。JSON Lines なので間違えた行を正しい source 名で書き直します。ただし状態ファイルの zero_weeks は当週のカウントを再計算しないので、修正後に REVENUE_GATE_FORCE=1 で強制再実行する必要があります。

長期的な防衛策として rev.sh に conf との突き合わせバリデーションを追加する予定ですが、手作業ポイントはここだけなので「打ち間違えたら jsonl を直す」で今は運用しています。

ASMR が14本→0本に落ちた原因はカウント窓のズレだった

前半で触れた「ASMRラインが07-03の週14本から07-06の週0本に突落した」件の実際の原因です。「ジョブが壊れた」と思って調べたのですが、違いました。

weekly_file_count は実行時刻から「過去7日間」のファイルを数えます。

• 07-03（木）のレポート：06-26〜07-03 のファイルを対象。ASMRジョブが06-26（木）に14本をまとめて生成していたため、全14本がカウントに入った。
• 07-06（日）のレポート：06-29〜07-06 のファイルを対象。06-26のファイルは窓の外に出た。その後1週間、ASMRジョブは次のバッチをまだ生成していなかった。結果ゼロ。

ASMRジョブは「週1回まとめて生成」という設計だったのですが、launchd が月曜起動のスケジュールだったのに対し、06-26は木曜でした。私が最初に手動で実行したのが木曜だったため、7日サイクルがずれていました。

この構造的な問題は「週次レポートのカウント窓と、量産ジョブの出力サイクルが一致していない場合、正常なジョブを異常に見せる」という点です。週1回まとめて出力するジョブは、レポートの曜日と出力日が近ければ毎週検出されますが、タイミングが悪いと隔週でゼロになります。

現状の運用上の対処は「⚠️が出たら即座にジョブが壊れたと判断せず、直近の出力日時を手動確認してから判断する」です。完璧ではありませんが、手動監視よりははるかにましです。この問題に気づいたこと自体、レポートがなければ2〜3ヶ月見過ごしていたはずです。スクリプトが示す数字を「事実」ではなく「調査のトリガー」として使う、という距離感が重要です。

つまずきポイント

前半・中段で取り上げた4件（set -uと環境変数衝突・.DS_Store混入・source名タイポ・カウント窓ズレ）の先にも、実運用で踏むポイントがあります。箇条書きでまとめます。

• ISO週番号の年境界バグ　date +%G%V のうち %G はISO年（カレンダー年ではない）を返します。2026年12月28日（月）を例にとると 202701 になります。マーカーファイル名も zero_weeks のキーも %G%V で統一されているので計算自体は狂いませんが、「2026年の最終週を処理したはずなのにファイル名が2027年になっている」という混乱を生みます。自前でフォークして %Y%V に変えると完全に壊れます。ISO weekの年はカレンダー年とズレることが前提であり、このスクリプトが %G%V を選んでいるのは理由があります。

• conf に存在しないsourceで rev.sh を叩くと売上が闇に消える　weekly_revenue と total_revenue はオープンハッシュなので任意の source 名を受け付けます。しかしレポートは entries（conf の name 列）だけをイテレートします。たとえば affilIate（大文字I）と打てば affiliate ラインとは別エントリが生まれ、収益がどこにも表示されません。症状は「rev.sh で記録したのに zero_weeks がリセットされない」です。P2で触れた source 名タイポ（同ライン内の誤記録）と似ていますが、こちらは「conf 自体に定義のない名前への記録」という亜種で、jq -r '.source' ~/.claude/data/revenue.jsonl | sort -u で source 一覧を出し、conf と突き合わせるのが唯一の検出手段です。

• 破損シンボリックリンクが即⚠️になる　weekly_file_count の先頭は if not root.is_dir(): return None です。破損したシンボリックリンク（リンク先のディレクトリが消えた・外付けSSDが未接続など）は is_dir() が False を返し、None → ⚠️ 出力停止? になります。ジョブが正常稼働しているのにレポートが警告を出し続ける状況は、たいていここか4件目のケースです。出力ディレクトリを変更したり外付けドライブに移したりした後は conf も更新する必要があります。

• os.walk がシンボリックリンクディレクトリを追跡しない　os.walk(root) のデフォルトは followlinks=False です。量産ジョブの出力先を ~/Desktop/Article/articles というシンボリックリンクで指し、実体が別パスにある構成だとカウントが常に 0 になります。「Finder では見えているのに週出力数が 0」という症状が出たらこれを疑います。conf の出力ディレクトリ列には実体パスを書くのが安全です。

• mktemp のガードがない　現行コードは TMP_REPORT="$(mktemp /tmp/revenue-gate.XXXXXX.md)" の後に || exit 1 がありません。/tmp が枯渇すると mktemp が失敗して空文字を返し、> "$TMP_REPORT" がカレントディレクトリに空ファイルを生成するか、Pythonの出力が捨てられます。通常のMacでは発生しませんが、/tmp を共有するCI環境や残量が逼迫したマシンでは起きます。フォークして使う場合は || { echo "ERROR: mktemp failed" >> "$LOG"; exit 1; } を追加してください。

• 収益集計窓とファイルカウント窓の基準点がズレる　収益集計は week_start = report_date - timedelta(days=7)（日付ベース、0:00:00起点）、ファイルカウントは datetime.now().timestamp() - (7 * 24 * 60 * 60)（実行時刻ベース、8:20:00起点）です。ちょうど7日前のファイルがどちらの窓に入るかで判定が変わることがあります。「今週の収益はあるのに出力ゼロ」「出力はあるのに収益ゼロ」という1日分のズレが境界付近で生じます。実運用上は誤差の範囲ですが、日次バッチで1ファイルずつ生成するラインでは精度に影響します。

• launchd のログには Python の stdout が入らない　plist の StandardOutPath と StandardErrorPath は同じ revenue-gate-launchd.log を指しています。しかし埋め込みPythonの print() 出力はシェルの > "$TMP_REPORT" にリダイレクトされるため launchd.log には残りません。Python 側にデバッグ出力を入れて launchd.log を追いかけても何も出てこない理由はここにあります。Python のデバッグ出力は import sys; sys.stderr.write("debug\n") として stderr に流すと launchd.log に入ります。

• 新ラインを追加した週は過去のゼロ履歴が引き継がれない　conf に新しいラインを追加した週、zero_weeks.get(name, 0) で 0 からカウントが始まります。これはコード上正しい動作ですが、「conf 追加前から数週間稼いでいないラインを0週スタートで追加した」という文脈が消えます。将来🔴になったとき「いつから不採算だったか」が追えません。新ラインを追加するときは revenue.jsonl に amount_jpy: 0・note: "ライン開始" で開始記録を残す習慣が、後から経緯を読むうえで役立ちます。

• アーカイブファイルは自動削除されない　マーカーファイル（.revenue-gate-done-*）は -mtime +35 -delete で35日後に掃除されますが、~/Desktop/Revenue Gate/ のレポート本体と Obsidian vault の briefs/revenue-gate/ にコピーされたファイルは消えません。週次で1ファイル増え続け、1年で50ファイル超になります。Obsidian の全文検索にレポートがヒットし始めたら settings.json の userIgnoreFilters に briefs/revenue-gate を追加するか、月次 cron で6ヶ月以上前のレポートを archive/ に移す処理を足すのが現実的です。

---

ベストプラクティス

3週間運用して整理したルールを14条にまとめます。

1. set -u を入れるなら全オプション環境変数に :- デフォルト値を付ける　${REVENUE_GATE_FORCE:-0} のパターン。launchd は新しいセッションで起動するためターミナルとは環境変数が異なります。手動実行で通るスクリプトが launchd で無音死する最多原因です。

2. launchd の登録は二重発火スロットにする　8:20 に加えて 13:20 も登録し、週内重複実行はマーカーファイル（%G%V ベース）で防ぎます。Mac を週末に閉じるなら必須です。plist の StartCalendarInterval が配列を受け付けることは公式ドキュメントでは目立たないのでこのスニペットはそのまま使えます。

3. 宛先への直接書き出しは禁止。mktemp → Python stdout → cp の順にする　Python が途中でクラッシュしたとき、宛先ファイルが半壊した状態で残るのを防ぎます。if python3 ... > $TMP; then cp $TMP $DEST; fi という構造が原子性の保証になります。

4. Python ヒアドキュメントは <<'PY'（シングルクォート）で書く　<<PY だとPythonコード中の $HOME や ${var} がシェルに展開されます。現時点でコード内に変数がなくても、将来追加したときにシレッと壊れます。シングルクォートはコストゼロの保険です。

5. Python はフルパス /usr/bin/python3 で呼ぶ　launchd の PATH は /usr/bin:/bin:/usr/sbin:/sbin 程度しか通っていません。python3 だけ書くとHomebrew環境では見つからないことがあります。スクリプト冒頭で export PATH="/opt/homebrew/bin:..." を追加してあるため実際は問題ありませんが、Python の呼び出しにはフルパスを維持しておくと launchd デバッグが楽になります。

6. conf の glob 列は省略せず必ず明示する　*.md, *.mp3 など。省略すると * として扱われ、.DS_Store・.gitkeep・__pycache__ が混入します。出力数1になっているのにジョブが止まっている、という誤検知の根本原因がここにあります。

7. 収益記録コマンドは5秒で完結させる　rev.sh note 3200 有料記事1本 という形式が維持できているのは、記録が3単語で終わるからです。記録が手間だと続かなくなり、zero_weeks が意味をなさなくなります。ASP自動連携できるものは将来的にcronで自動化しますが、手動記録の抵抗を最小化することが今の現実解です。

8. JSON Lines は jq で常時ヘルスチェックできる状態を維持する　jq -c . ~/.claude/data/revenue.jsonl > /dev/null でパースエラーを即検出できます。手動編集で修正したあとは必ずこのコマンドを通してから REVENUE_GATE_FORCE=1 で強制再実行します。

9. スクリプト本体は自動停止しない設計を維持する　🔴 KILL推奨 はレポート内の文言であり、ジョブを止めるアクションはコードに持たせていません。機械が自動停止すると「なぜ止まったか」の文脈が失われ、誤検知で稼ぎ頭を殺すリスクがあります。ライン停止は人間が手動で行う。この設計思想は変えないほうがいいです。

10. ⚠️ を「ジョブが壊れた確定」と読まない　カウント窓のズレ・シンボリックリンク問題・月次まとめ出力のタイミングなど、正常なジョブが ⚠️ になるパターンが複数あります。最初に確認するのは ls -lt <出力ディレクトリ> | head -5 でファイルの最終更新日時を確認することです。ファイルが存在してmtimeが最近なら窓ズレ、存在しなければジョブ障害です。

11. state.json のゼロ週カウントは定期的に手動確認する　レポートには🟡 要観察とだけ表示されますが、その裏にある数字は state.json にあります。jq .zero_weeks ~/.claude/data/revenue-gate-state.json で各ライン2週か3週かが見えます。3週ならそろそろ判断を始めるタイミングです。

12. 強制再実行の alias を用意する　.zshrc に alias rg-force='REVENUE_GATE_FORCE=1 bash ~/.claude/scripts/revenue-gate.sh' を追加しておくと、タイポ修正後の再集計が1コマンドで済みます。REVENUE_GATE_FORCE を手打ちするたびにスペルミスするので alias は必須です。

13. conf を編集したら必ず手動で1回実行して出力を確認する　新ラインを追加した直後や globを変えた後は、rg-force で即レポートを生成し、週出力数と判定が期待通りかを確認します。次の月曜まで待ってから「実は設定が間違っていた」に気づくと1週間分のデータが飛びます。

14. 4関門リマインドは毎週读む　レポート末尾の「何のため／誰が嬉しい／いくら儲かる／いつ見切る」は自分で書いた文言なので読み飛ばしがちです。しかし🟡が3週目に入ったラインに対してこの4問に答えられない場合は、それが「止めどき」のシグナルです。KILLの判断はここから始まります。

---

まとめ

revenue-gate.sh の構造をコードレベルで追ってきました。全体で見えてくることは1つです。量産ラインを増やすほど、見る時間が減る。 毎週月曜に自動で数字が届かなければ、14ラインのコスト対効果を同時に把握することは物理的に不可能です。

月商120万の内訳が「どのラインが稼いでいるか」と「どのラインがAPIコストを食い潰しているか」の両方を毎週把握していることで成り立っているように、自動化の規模を広げるほど「自動で止まれる仕組み」が収益を守ります。ASMR ラインが07-03から07-06の3日間で週14本から0本に落ちたことを、レポートがなければ数週間見過ごしていたはずです。

実装コストは revenue-gate.sh（204行）と plist（37行）の2ファイル、設置15分です。それで週次の収益判断に必要な情報が毎月曜に自動で届くなら、ROIは初日に回収できます。

収益ゼロのラインを4週間回し続けるコストが、月に一度でも止めていれば浮いたAPIコストを超える前に。今週の月曜レポートを見て、判断してください。

---

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

---

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

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

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