Claude Codeを使い始めて最初に思ったのは、「これ、自分がターミナルの前に座っていないと何も起きないな」ということでした。
会社員にとって、これは地味に厳しい制約です。平日の日中は当然さわれません。帰宅後に開いて、指示を出して、結果を確認して……とやっていると、それだけで1時間が溶けます。
そこで、Claude Codeを決まった時刻に自動で動かす仕組みを組みました。今は3本動いています。
- 朝の投稿案を作る
- 反応する候補を集める
- 週末に1週間の数字をまとめる
朝起きたら結果ができている状態です。この記事では、その組み方と、実際に踏んだ落とし穴を書きます。
僕はエンジニアではありません。 cronという言葉も、これを組むまで知りませんでした。
前提：Claude Codeは対話なしでも動く
自動化の出発点はここです。
普段はターミナルで claude と打って、対話しながら使います。でも Claude Code には、対話せずに1回だけ実行して結果を返すモードがあります。
claude -p "今日のX投稿案を3つ作って、drafts/today.md に保存して"-p を付けると、Claudeは指示を受け取って、作業して、終了します。人間の入力を待ちません。
つまりこの1行をcronに登録すれば、自動化は成立するということです。仕組みとしては驚くほど単純でした。
オプションの細かい仕様はバージョンで変わることがあります。
claude --helpで手元の環境の対応状況を確認してください。
Step 1｜まず手で動かして確認する
いきなりcronに登録してはいけません。cronは失敗しても画面に何も出ないので、動かない原因が分からなくなります。
先にターミナルで、そのままの形で実行します。
cd ~/Desktop/myproject
claude -p "test.txt というファイルを作って、中に「動きました」と書いて"ファイルができていればOKです。ここが通らないうちは次に進まないでください。
Step 2｜権限の壁を越える（最大の関門）
ここで最初に詰まりました。
Claude Codeは、ファイルを書き換えたりコマンドを実行したりする前に、「これ実行していい？」と確認してきます。普段は Yes を押せばいいだけです。
でも自動実行では、押す人がいません。確認待ちのまま固まって、朝になっても何も終わっていないということが起きます。
解決策：使っていいツールを先に許可しておく
プロジェクトの .claude/settings.json に、許可するものを書いておきます。
{
"permissions": {
"allow": [
"Read",
"Write",
"Edit",
"Bash(python3 scripts/*)"
]
}
}こう書いておくと、この範囲の操作は確認なしで進みます。範囲外のことをやろうとしたときだけ止まります。
「全部許可」は安易に使わない
調べると、確認を全部スキップするオプションも出てきます。たしかに動きます。でも僕は常用していません。
理由は、Claudeが読み込んだ内容の中に指示が紛れていても、そのまま実行されうるからです。ネット上のページやメールの中身を読ませる処理を組んでいると、そこに書かれた文章をClaudeが指示として受け取ってしまう可能性があります。全許可の状態だと、それが確認なしで走ります。
自分のパソコンの中だけで完結する、閉じた作業に限定して使うべきものだと思っています。面倒でも、必要なものだけを許可リストに並べるほうが結果的に安全です。
Step 3｜cronに登録する
cronは、Macに最初から入っている「決まった時刻にコマンドを実行する仕組み」です。
ターミナルで次を打つと、設定ファイルが開きます。
crontab -e書き方はこうです。
0 6 * * * cd /Users/ユーザー名/Desktop/myproject && /usr/local/bin/claude -p "今日の投稿案を作って" >> /Users/ユーザー名/cron.log 2>&1先頭の5つの数字が実行タイミングです。
| 書き方 | 意味 |
|---|---|
0 6 * | 毎日6時00分 |
30 22 * | 毎日22時30分 |
0 21 0 | 毎週日曜21時00分 |
0 7 1-5 | 平日のみ7時00分 |
左から「分・時・日・月・曜日」です。曜日は0が日曜。* は「毎回」という意味です。
保存はエディタによりますが、標準では Esc を押してから :wq と打ってEnterです。
登録されたか確認します。
crontab -lStep 4｜必ずログを残す
上のコマンドの末尾にある、この部分が重要です。
>> /Users/ユーザー名/cron.log 2>&1これは「実行結果をファイルに追記する」という意味です。2>&1 はエラーも一緒に記録する指定です。
これを付けないと、失敗したときに何も分かりません。 僕は最初これを書かずに登録して、「動いていないことは分かるが理由が分からない」という状態で数日溶かしました。
確認はこうします。
tail -50 ~/cron.log実際に踏んだ落とし穴
① claude が見つからない（いちばん多い）
手で打つと動くのに、cronだと動かない。 これが最初の壁でした。
原因は、cronがあなたの普段の環境設定を引き継がないことです。ターミナルでは自動で読まれている設定ファイルが、cronでは読まれません。だから claude というコマンドの居場所が分からず、そこで止まります。
解決策は、フルパスで書くことです。場所はこれで分かります。
which claude出てきたパス（例：/usr/local/bin/claude）を、そのままcronに書きます。
② 作業する場所が違う
cronはホームディレクトリから実行されます。プロジェクトのフォルダにいる前提で書くと、ファイルが見つかりません。
だから先ほどの例では、頭に cd を付けてあります。
cd /Users/ユーザー名/Desktop/myproject && claude -p "..."③ macOSのアクセス許可で弾かれる
デスクトップや書類フォルダの中を触ろうとすると、macOSのセキュリティ機能に止められることがあります。ログに Operation not permitted と出ていたらこれです。
システム設定 →「プライバシーとセキュリティ」→「フルディスクアクセス」で、cronの実行元（/usr/sbin/cron）を追加すると通ります。
④ Macが寝ていると動かない
当たり前ですが、cronはMacが起動していないと実行されません。「朝6時に動かす」なら、Macを閉じずに置いておく必要があります。
僕は電源につないだまま、ディスプレイだけ切れる設定にしています。
⑤ 前回の処理が終わる前に次が走る
短い間隔で登録すると、処理が重なることがあります。5分おきなどにするなら、多重起動を防ぐ仕組みが要ります。
そもそもClaude Codeを高頻度で回す必要はほとんどありません。 1日1〜2回で十分な用途がほとんどです。
何を自動化して、何を自動化しないか
3本運用してみて、はっきりした線引きがあります。
| 自動化して良かった | 自動化しないほうがよかった |
|---|---|
| 案を出す（投稿案、記事の構成案） | 公開・送信すること |
| 情報を集める・整理する | 人に向けた返信の文面を確定させること |
| 数字をまとめる（週次の集計） | 良し悪しの判断 |
| 下書きを作る | お金が動く操作 |
自動化するのは「下書きまで」。最後の一押しは自分がやる。 これが今のところ一番しっくりきています。
理由は単純で、自動で公開まで走らせると、事故ったときに気づくのが公開後になるからです。朝起きて変な投稿が出ている、という事態は避けたい。下書きで止めておけば、確認して直せます。
WordPressへの投稿を自動化したときも同じ設計にしました（→ Claude CodeでWordPressに自動投稿する方法）。下書きまでは自動、公開ボタンだけ手動です。
なお、cronを使うにはサーバー側が対応している必要があります。これから環境を用意する人は、契約前に確認しておいてください。
→ エックスサーバーでWordPressを始める手順｜AIで自動投稿する前提のサーバー選び
まとめ
claude -p "指示"で対話なしに実行できる- 先に手で動かして確認する（cronは失敗が見えない）
.claude/settings.jsonに許可するツールを書いておく（全許可は安易に使わない）crontab -eで時刻を登録するclaudeはフルパスで書く（cronは環境設定を引き継がない）- ログを必ず残す（
>> ログファイル 2>&1） - 自動化は下書きまで。公開は自分の手で
やってみて一番大きかったのは、時間そのものより「帰宅後にゼロから始めなくていい」ことでした。すでに何かができている状態から始められると、続けるハードルが目に見えて下がります。
可処分時間が少ないほど、この差は効いてきます。
この記事は自分の環境（macOS）で実際に動かしている設定をもとに書いています。バージョンや環境で挙動が変わることがあるので、うまくいかない点があればコメントで教えてください。
コメント