Claude Codeを常駐させ業務を毎日自動実行する｜PM2 / launchd / cron 実運用
Claude Code は対話だけの道具ではない。CLI を定期実行に組み込めば、日次の調査やレポートを人が見ていない時間に回せる。当社が Mac mini で約 28 本の cron ジョブをどう常駐させているか、踏んだ事故込みで公開します。
Radineer 編集部 ・ 自社の Claude Code 本番運用に基づく解説（2026 年 5 月時点）
Claude Code の自動化とは、対話を介さず CLI を定期実行・常駐させ、日次の調査やレポートといった業務を無人で回す運用を指す。鍵になるのは、プロセスを止めずに動かし続けるプロセス管理(常駐)と、決まった時刻に起動するスケジューリング(cron)の設計である。
CLI を定期実行する設計
自動化の出発点は「Claude Code を対話ではなく CLI として呼ぶ」ことにある。決まったプロンプトやスキルを CLI で実行し、その出力をファイルやレポートに落とす。これを定時に起動すれば、日次ジョブになる。
当社は Mac mini 上でこの仕組みを常駐させ、約 28 本の cron で日次ジョブを回している。求人クロール、各種レポート、SNS の下書き生成などが、人の操作なしに毎日動く。
設計で考えるべきは大きく 2 つ。「決まった時刻に起動する仕組み(スケジューリング)」と「起動したプロセスを面倒見る仕組み(プロセス管理)」だ。ここを誰に任せるかで、安定度が大きく変わる。
launchd の落とし穴
macOS には標準で launchd という常駐・スケジューリングの仕組みがある。最初の選択肢になりがちだが、当社の運用では落とし穴が多かった。
最大の罠は、launchd が ~/Desktop 配下のスクリプトを実行できないこと。macOS の TCC(プライバシー保護)の制約で、Desktop など保護されたフォルダ配下のプロセスは弾かれる。これに当たると EINTR や uv_cwd といったエラーが出て、原因が分かりにくい。
さらに launchd は無音で停止することがある。エラーも出さずジョブが動かなくなり、気づいたら数日止まっていた、という事故が起きやすい。「止まったことに気づけない」のが一番こわい。
PM2 を原則にする理由
こうした経緯から、当社は Mac mini での常駐を PM2 で行うことを原則にしている。PM2 はプロセスを監視し、落ちたら再起動し、ログを残してくれるプロセスマネージャだ。
launchd の「無音停止」「Desktop 配下を実行できない」という二大問題を、PM2 は避けられる。常駐の本体は PM2 に任せ、決まった時刻の起動は cron もしくは PM2 側のスケジュール機能で担う、という分担に落ち着いた。
ポイントは、launchd を全否定しているのではなく、「Desktop 配下を含む業務常駐の本命は PM2」という当社の実運用上の結論だということ。
実例：日次クロール & レポート
具体例として、当社の求人クロールは 5 つのプラットフォームを毎朝クロールし、結果をまとめる日次ジョブとして動いている。競艇予想や M&A 案件の監視など、同種の「毎日決まった時刻に取りに行く」ジョブが約 28 本走っている。
いずれも構造は同じだ。cron が定時に起動 → CLI で Claude Code を実行 → 出力をレポート化 → 必要なら通知。これを PM2 配下で常駐させ、落ちても自動で立ち上がるようにしている。
- 定時に起動する(cron もしくは PM2 のスケジュール)
- CLI で Claude Code を実行し、調査・整形をさせる
- 出力をレポートやファイルに落とす
- 必要なら通知し、ログを残す
環境変数欠落事故の防ぎ方
常駐自動化で最も痛かった事故が、環境変数の欠落だ。
プロセスを .env を読み込まないラッパーで起動してしまうと、起動時に設定が欠けてプロセスが即落ちする。PM2 は「落ちたら再起動」してくれるので、設定が欠けたまま無限に再起動を繰り返す。当社はこれで 52,039 回の再起動事故を起こした。
対策はシンプルで、PM2 のエントリは必ず .env を読み込むラッパー経由で起動する。env が無ければそもそも起動しない、あるいは起動前に検証して落とす。「再起動で粘る」より「設定が無ければ起動させない」方が安全だ。
なお cloudflared のような常駐プロセスを再読込するときは、SIGKILL で強制終了してはいけない。launchctl kickstart のような正規の再起動手段を使う。乱暴に殺すと別の不調を呼ぶ。
PM2 / launchd / cron の使い分け
3 つは役割が違う。常駐の面倒を見るのが PM2、決まった時刻に起動するのが cron、macOS 標準の両刀が launchd。当社の結論は「常駐は PM2、定時起動は cron」。
| 仕組み | 役割 | 当社の評価 |
|---|---|---|
| PM2 | 常駐プロセスの監視・再起動・ログ | 業務常駐の本命。原則これを使う |
| cron | 決まった時刻にコマンドを起動 | 定時起動に。約 28 本のジョブを駆動 |
| launchd | macOS 標準の常駐＋スケジューリング | Desktop 配下不可・無音停止のため非推奨 |
よくある落とし穴
- launchd で ~/Desktop 配下を実行する：TCC で弾かれ、EINTR や uv_cwd エラーになる。配置場所を変えるか PM2 に寄せる。
- launchd の無音停止を放置する：エラーも出ず止まる。気づける監視を別に持つか、PM2 にする。
- .env を読まないラッパーで起動する：設定欠落で無限再起動。当社は 52,039 回の再起動事故を経験した。env 読込ラッパーを必須にする。
- 常駐プロセスを SIGKILL で再読込する：cloudflared 等は launchctl kickstart など正規の手段を使う。
よくある質問
macOS で Claude Code を常駐させるなら launchd と PM2 どっち？
当社は PM2 を原則にしている。launchd は ~/Desktop 配下を実行できず(TCC 制約)、無音で停止することがあるため。常駐は PM2 に任せ、定時起動は cron で担うのが安定する。
launchd で EINTR や uv_cwd エラーが出るのはなぜ？
~/Desktop など保護フォルダ配下のスクリプトを launchd が TCC 制約で実行できないことが原因のことが多い。配置場所を保護外に移すか、PM2 での常駐に切り替える。
常駐プロセスが大量に再起動を繰り返すのはなぜ？
多くは環境変数の欠落。.env を読まないラッパーで起動するとプロセスが即落ちし、PM2 が再起動を繰り返す。当社は 52,039 回の再起動事故を経験した。env を読み込むラッパーを必須にする。
cron は使わなくていい？
常駐の面倒を見る PM2 と、定時起動する cron は役割が違う。当社は約 28 本の cron で日次ジョブを起動し、その実行プロセス自体は PM2 配下で常駐させている。両方を役割分担で使う。