macOS Cron×launchd×ntfyで24時間自律運用を組む全体像｜個人事業主のための業務自動化基盤2026

「業務を24時間止めずに回すには、専用サーバを契約してDockerでデーモンを立てて……」と思いがちですが、個人事業主の規模なら手元のMacBook 1台で十分です。macOS純正のスケジューラ「launchd」と、軽量プッシュ通知サービス「ntfy.sh」、そしてClaude Codeを組み合わせると、毎日の予約投稿・データ取得・経理リマインダー・SNS自動配信まで、寝ている間も止まらない自律運用が組めます。

本記事では、私が自分の個人事業で実際に稼働させているCron 24本（2026年5月時点）の知見から、最小構成・典型的な事故・最初に組むべきCron 5本を、コピペで動くコード付きで全部書き出します。WWDC 2026を控えてMacBookの利用密度が上がる今、業務自動化基盤を組み直すには絶好のタイミングです。

なぜ macOS Cron が個人事業主の業務自動化に最適なのか

業務自動化の基盤候補として、ぱっと思いつくのは AWS Lambda・GitHub Actions・Render・専用VPSのcrontabあたりです。これらは強力ですが、個人事業主が「日々の業務を回すための雑用Cron」を立てる規模では、いずれもオーバースペックでありメンテナンス負荷が割に合いません。

一方、macOS の launchd は次の3点で個人事業主向きです。

第1に、専用サーバが要らない。MacBook が起動していて Wi-Fi につながっていれば、それだけで Cron 基盤が動きます。クラウドの月額費用も、外部から踏み台にされるリスクも発生しません。

第2に、既存業務スタックとの親和性が高い。Claude Code・Google Drive・WordPress MCP・SNS APIなど、普段使っているローカルツールがそのまま使えます。クラウドで動かそうとすると認証情報の引き渡しが面倒になりますが、ローカルなら設定済みのものをそのまま参照すれば済みます。

第3に、コストがほぼゼロ。電気代以外に追加で発生する固定費はありません。ntfy.sh は無料、launchd は OS 標準、Claude Code の使用料金だけは別途ですが、それも Cron に乗せた処理だけ課金されます。

専用サーバ＋自動化基盤＋監視＋通知を SaaS で揃えると、個人事業主の規模でも月¥3,000〜¥5,000のランニングがかかります。MacBook 1台で完結すれば、これがそのまま浮きます。

24時間自律運用に必要な「3点セット」

私が稼働させている自律運用は、次の3レイヤで成り立っています。どれが欠けても運用は止まりません。逆に、この3つだけ揃えれば「最低限の自律運用」は今日から組めます。

① launchd（macOS純正スケジューラ）

時刻トリガーの中核です。「毎日 07:00 に発火」「2026-05-17 12:01 に1回だけ発火」のように、plist ファイルでスケジュールを宣言的に書きます。crontab に比べて記述は長くなりますが、後述するように「環境変数を確実に渡せる」「OS再起動後も復活する」というメリットが大きいので、迷わず launchd を選ぶべきです。

② Claude Code（実行レイヤ）

Cron が発火したあとの「実際に何をするか」は、Claude Code の -p ヘッドレスモードに任せます。MCPサーバへの接続・WordPress REST API直叩き・記事生成・GSC データ取得・SNS 投稿まで、定型業務はだいたい Claude Code でカバーできます。Python スクリプトでも代替できますが、自然文プロンプトでロジック分岐を書ける利点は、個人事業主のように「同じCronで日々違うテーマを投稿する」業務形態に強く効きます。

ただし、Claude Code をCronから呼ぶとそのぶんトークン消費がかかります。後述する「クレジット最小化」運用では、固定文面の Cron は Python 直叩きに振り分けて、可変分だけ Claude Code に回す構成にしています。

③ ntfy.sh（結果通知レイヤ）

Cron が回っていても、結果がオーナーに届かなければ「正常終了したのか、サイレントに失敗したのか」が分かりません。これを解決するのがプッシュ通知サービス ntfy.sh です。HTTPS の POST 1本でスマホに即時通知が届くので、Cron 終了時に必ず「成功 / 失敗 / 主要数字」を1通投げる運用にすると、運用負荷がほぼゼロになります。

ntfy.sh は無料で、トピック名（パスのようなもの）を決めるだけで使い始められます。アプリは iOS / Android 両対応で、Apple Watch にも届きます。

旧cron（crontab）ではなくlaunchdを選ぶべき3つの理由

macOSにも昔ながらの crontab -e は残っていますが、個人事業主の本番運用には launchd を強く勧めます。理由は次の3つです。

環境変数の挙動が安定（PATH/HOME問題回避）

crontab で最も詰まるのが、シェルから普段使えているコマンドが Cron から呼ぶとパスが通っていない問題です。launchd では plist の EnvironmentVariables セクションで PATH・HOME・LANG を明示できるので、「シェルでは動くのに Cron だと失敗する」というハマりを起こしません。

GUI環境変数を継承できる

Claude Code や各種 MCP サーバが GUI セッションの環境変数（macOS Keychain など）を参照するケースは多いです。launchd の gui/<uid> ドメインにロードすれば GUI セッションの権限を引き継げます。crontab はバックグラウンドで動くので、ここで詰まりがちです。

失敗時のリトライ・ログがOS標準で扱える

launchd には StandardOutPath / StandardErrorPath を指定する仕組みがあり、Cron が吐き出した stdout / stderr をファイルに自動で書き出してくれます。launchctl print コマンドで状態確認もできるので、デバッグサイクルが回しやすいです。

launchd plistの最小構成（コピペで動く実例）

実際に私が稼働させている plist の最小形を1本そのまま貼っておきます。「2026-05-17 07:34 に X へ単発投稿」を想定した plist です。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.example.cron.2026-05-17_07-34_sns-x-knowledge</string>

  <key>ProgramArguments</key>
  <array>
    <string>/bin/bash</string>
    <string>/Users/yourname/cron-runner/wrapper.sh</string>
    <string>2026-05-17_07-34_sns-x-knowledge</string>
  </array>

  <key>StartCalendarInterval</key>
  <dict>
    <key>Year</key><integer>2026</integer>
    <key>Month</key><integer>5</integer>
    <key>Day</key><integer>17</integer>
    <key>Hour</key><integer>7</integer>
    <key>Minute</key><integer>34</integer>
  </dict>

  <key>RunAtLoad</key>
  <false/>

  <key>StandardOutPath</key>
  <string>/Users/yourname/cron-runner/logs/stdout.log</string>
  <key>StandardErrorPath</key>
  <string>/Users/yourname/cron-runner/logs/stderr.log</string>

  <key>WorkingDirectory</key>
  <string>/Users/yourname/projects/my-business</string>

  <key>EnvironmentVariables</key>
  <dict>
    <key>PATH</key>
    <string>/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin</string>
    <key>HOME</key>
    <string>/Users/yourname</string>
    <key>LANG</key>
    <string>ja_JP.UTF-8</string>
  </dict>
</dict>
</plist>

このファイルを ~/Library/LaunchAgents/com.example.cron.2026-05-17_07-34_sns-x-knowledge.plist に置いて、launchctl bootstrap gui/$(id -u) <plist_path> で登録すれば、指定時刻に発火します。複数本登録する場合は plist の Label と StartCalendarInterval だけを差し替えていけば、いくらでも増やせます。

毎日同じ時刻に動かしたい場合は、StartCalendarInterval から Year/Month/Day を外して Hour/Minute だけにします。週次なら Weekday を足します。

ClaudeCode を Cron から起動する設計パターン

launchd plist の ProgramArguments で呼んでいる wrapper.sh の中身が、Cron 運用の生命線です。私が使っている構成では、wrapper の役割は次の3つです。

1. 引数で渡されたプロンプト basename を受け取る
2. ~/cron-runner/prompts/<basename>.md を読み込む
3. その内容を Claude Code に -p（ヘッドレスモード）で渡して実行する

最小構成だとこんな感じになります。

#!/bin/bash
set -euo pipefail
PROMPT_BASENAME="$1"
PROMPT_FILE="$HOME/cron-runner/prompts/${PROMPT_BASENAME}.md"

if [ ! -f "$PROMPT_FILE" ]; then
    echo "ERROR: prompt not found: $PROMPT_FILE" >&2
    exit 1
fi

cd "$HOME/projects/my-business"
/opt/homebrew/bin/claude -p --dangerously-skip-permissions \
  "$(cat "$PROMPT_FILE")" \
  >> "$HOME/cron-runner/logs/claude-${PROMPT_BASENAME}.log" 2>&1

ポイントは2つあります。第1に、プロンプトをファイルに切り出して cat で流し込むこと。これにより plist を触らずにプロンプトだけ更新できるので、編集サイクルが回しやすくなります。第2に、--dangerously-skip-permissions を付けること。ヘッドレスで動かすときは、対話的な許可ダイアログをスキップしないと止まります。フラグ名の通り権限的に強いので、Cron からしか呼ばれないことを必ず確認してください。

「prompt-static」と「prompt-dynamic」の使い分け

私の運用では、プロンプトを「固定文面で済むもの（static）」と「毎回内容が変わるもの（dynamic）」に分けています。

固定文面の SNS 告知や経理リマインダーは Claude Code を介さずに Python の urllib で直接 API を叩く方が、毎回トークン課金が発生せずクレジット消費がゼロになります。Claude Code 経由でないと判断のいる業務（例：その日の記事から告知文を生成する）だけを動的プロンプトに回します。

この棚卸しをしておくと、月のClaude Code利用料金がかなり下がります。私の場合、24本中7本を Python 直叩きに移行したことで、月の使用料金が月¥3,000ほど削減できました。

ntfy.sh で結果通知を仕組み化する

ntfy.sh の使い方は驚くほど単純です。ターミナルから次のコマンドを叩くだけで、スマホにプッシュ通知が届きます。

curl -d "Cron が無事終了しました" "https://ntfy.sh/your-unique-topic-name"

トピック名（your-unique-topic-name の部分）は、推測されにくいランダム文字列にしておきます。誰でもsubscribeできるので、固有名詞や個人情報は入れないでください。

日本語タイトル文字化け回避：Latin-1問題とJSON POSTの正解

HTTP ヘッダーの Title フィールドに日本語を入れると、ntfy のサーバ側で Latin-1 として扱われ文字化けします。これを避けるには、JSON ボディで送るのが正解です。

curl -sS -X POST "https://ntfy.sh" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{
    "topic": "your-unique-topic-name",
    "title": "✅ 朝のSNS自動配信 完了",
    "message": "X/Threads/Instagram 3媒体 投稿完了\nX permalink: https://twitter.com/...",
    "priority": 3,
    "tags": ["white_check_mark"]
  }'

priority は 1（最低）〜5（最高）。経理・税務関連のリマインダーには 4-5 を使い、日次の正常終了通知は 3 にしておくと、重要度に応じてスマホで通知音が変わります。

スマホアプリで受信する流れ

iPhone なら App Store で「ntfy」を検索してインストール、起動後に「Subscribe to topic」で同じトピック名を登録するだけで終わりです。Apple Watch にも自動で通知が飛ぶので、画面を見ないでも完了が把握できます。

24時間自律運用で起きる「3つの事故」と回避策

実運用で踏んだ事故とその回避策を共有します。最初の1ヶ月で必ず1回は踏むので、先回りで知っておくと損しません。

① Google DriveのCloudStorageパスにはlaunchdがアクセスできない

業務ファイルを Google Drive の CloudStorage パス（/Users/yourname/Library/CloudStorage/GoogleDrive-.../）に置いている場合、launchd 経由のスクリプトはここを読めません。macOSの sandbox 制限で、GUI セッション外からのアクセスが拒否されます。

回避策は、Cron で動かすスクリプトと plist は ~/cron-runner/ 配下に置くこと。プロジェクト本体は Google Drive のままでOKですが、Cron から呼ばれるスクリプト・wrapper・プロンプトは必ずホームディレクトリ配下に置きます。

② 「durable:true」が壊れた時の代替

Claude Code 本体にも ScheduleWakeup や CronCreate というスケジューラ機能がありますが、バージョンによっては durable:true（永続化）が機能していないことがあります。私が遭遇したケースでは、Claude Code 2.1.138 で全 Cron がセッション終了とともに消えるという事象が発生しました。

このリスクをゼロにするには、永続化が必要な Cron はすべて launchd に書き出すのが安全です。Claude Code 側の Cron はあくまでセッション内の短期スケジューラとして使い、本番運用は OS のスケジューラに寄せる、という割り切りが事故を防ぎます。

③ Cronが大量増殖して制御不能になる

最初は5本、3ヶ月後には24本になっていた、というのは私の実体験です。launchctl list | grep com.example で全件確認できる仕組みを最初から作っておかないと、棚卸しできなくなります。

私のルールは「plist のファイル名に日付を入れる」「one-shot Cron は発火後に自動で plist を削除する」の2点。これだけで、半年運用しても plist ディレクトリは50本以内に収まります。

個人事業主向け：最初に組むべきCron 5本

ここまでが基盤の話。実際に何を自動化すれば日々の業務が楽になるのか、個人事業主に効くCronを5本だけ挙げます。

① 朝SNS自動投稿（X / Threads / Instagram）

毎朝07:00に前夜書いた告知文をXとThreadsとInstagramに同時投稿する。これだけで朝の30分が解放されます。Claude Code から各 SNS の API に投げるパターンか、Python の tweepy などのライブラリを直叩きするパターンの2択です。

② 日次振り返り＋翌日タスクの自動生成

23:50頃に「今日のTODOを見て、未完了タスクを明日のファイルに繰り越し、ついでに翌朝のCron発火予定を確認」させる Cron。私の場合、これが翌朝の業務開始を5分早めてくれます。

③ GSC・GA4データの自動取得＆通知

毎週月曜の朝08:00に、GSC からクリック上位10件・GA4 から人気ページ上位10件を取得して、ntfy で1通通知。「今週何を強化するか」が朝のうちに見えます。

④ 経理リマインダー

給料計算・引落し設定・税務申告など、忘れたら大ごとになる業務を Cron でリマインドする。私の場合、給料計算は支給日の4営業日前の08:13、資金決済は前日の08:17、といった具体時刻で 5-6 本走らせています。

⑤ バックアップ＆セキュリティチェック

毎日深夜02:00に重要ディレクトリを別ボリュームにrsyncで同期する Cron と、週次でWP/各種SaaSのログイン状況を確認する Cron。これは「動いている」より「失敗を即時検知できる」価値の方が大きいです。

1日30分で組める「最小自律運用」スターターキット

最後に、本記事を読んで実際に組み始める方のためのスターターキットを置きます。

必要なもの

• MacBook 1台（M1以降推奨・Intel機でも動作はする）
• 無料のntfy.shトピック1つ
• Claude Code（任意・なくてもPython直叩きで代替可）
• 30分の作業時間

段階導入の3ステップ

1. Day 1（10分）：ntfy.sh のトピックを決めて iPhone アプリで購読 → curl コマンドで「Hello」が届くまで確認
2. Day 1（10分）：~/cron-runner/ を作り、wrapper.sh と plist 1本を配置 → 5分後の時刻にテスト発火させて launchd が動くことを確認
3. Day 1（10分）：最初の本番Cronを1本だけ書く（おすすめは「毎朝07:00に ntfy で今日のTODOを通知」）

これで初日が完結します。2日目以降に Cron を1本ずつ増やしていけば、1週間で5本、1ヶ月で 15-20 本の運用基盤が手に入ります。

まとめ：24時間動くチームを1人で持つ感覚

launchd + Claude Code + ntfy.sh の3点セットは、個人事業主の業務自動化基盤として2026年時点で最もコストパフォーマンスの良い選択肢です。専用サーバの月額も、SaaSの月額も、外部委託の月額も発生せず、それでいて「寝ている間にSNS配信が回り、朝起きたらGSCサマリが届いている」という感覚が手に入ります。

次回の記事では、この基盤の上に「Claude Code を1日2回呼んで月60本の記事を回す実装パターン」を、実際に稼働させているCronの中身を晒しながら解説します。本シリーズの最終目標は、「1人だけど24時間動いている会社」を持つことです。

WWDC 2026 まで残り2週間、Macの利用密度が高まる5月後半に、業務自動化基盤を組み直しておくと、6月以降のApple新製品ラッシュを「学ぶ＋発信する」で受け止める体力が一段引き上がります。

—