結論：バッチ処理や定期実行（cron）をClaude Codeで自動化するときは、「処理を冪等にしてスクリプト化する」「cronはスケジュールだけ持たせる」「失敗時はリトライと通知でリカバリーする」の3点を押さえれば、深夜の手動オペレーションから解放されます。ただし多重起動・止まらないジョブ・本番データの破壊・機密情報の取り扱いには十分注意が必要で、Claude Codeが生成したコードは必ず人がレビューしてから本番に載せてください。本記事は2026年6月時点のClaude Code公式仕様をもとにした実践ガイドです。
- 要点1：「何を・いつ・どの順で」を先に紙に書き出し、処理をスクリプト1本に閉じ込めてから自動化する
- 要点2：冪等性・ロック・ログをコードに組み込み、cron式はあくまで「いつ動かすか」だけを担わせる
- 要点3：失敗時のリトライ・通知・再実行手順を最初から設計し、本番反映前にdry-runで検証する
対象読者：定期バッチやcronジョブを書く開発者・SRE・データエンジニア。今日できること：手元の手動作業を1つ選び、Claude Codeでスクリプト化→cron登録→失敗通知までの最小構成を作る。
毎晩22時にCSVを集計してSlackに投げる――そういう「人が手で回している定期作業」って、地味に時間を食うし、忘れたり二重に走らせたりして事故ります。正直、僕も以前はターミナルを開いてコマンドを手打ちし、翌朝「あれ、昨日のバッチ流したっけ？」と確認する日々でした。Claude Codeを使い始めてから、この手の定期処理は「会話でスクリプトを作って、cronに任せる」形に置き換わり、夜のオペレーションがだいぶ静かになりました。
ただ、自動化は便利な反面、設計を間違えると静かに壊れます。多重起動でデータが二重登録されたり、止まらないジョブがサーバーのメモリを食い潰したり、最悪は本番DBを消す。この記事では、Claude Codeでバッチ・定期実行を組むときに「どう指示して」「どこに気をつけるか」を、コード例と一緒に整理していきます。
1. 目的と処理を整理する｜何を・いつ・どの順で
自動化でいちばん大事なのは、コードを書く前に「何を・いつ・どの順で」を言語化することです。ここが曖昧なまま「いい感じにバッチ化して」と頼むと、Claude Codeはそれっぽいスクリプトを返してきますが、運用に乗せると穴だらけになります。
僕が最初にやるのは、処理を次の3軸で棚卸しすることです。
- 入力（何を）：どのファイル・テーブル・APIからデータを取るか。読み取り専用か、書き込みもあるか
- タイミング（いつ）：毎日／毎時／月初など。前のジョブが終わってから動かす依存関係はあるか
- 順序と出力（どの順で・どこへ）：処理の手順、最終的にどこに結果を書き、誰に通知するか
この棚卸しをそのままClaude Codeへの指示にすると、精度がぐっと上がります。たとえばこう書きます。
これから定期バッチのスクリプトを書きたいです。仕様を伝えるので、
まず処理フローを箇条書きで整理し直してから実装してください。
- 入力: /data/orders/ 配下の当日分CSV（読み取りのみ）
- 処理: 注文を店舗別に集計し、合計金額と件数を算出
- 出力: /data/reports/YYYY-MM-DD_summary.csv に書き出し
- 通知: 集計件数をSlack Webhookへ1行で送信
- 言語: Python 3.12 / 標準ライブラリ中心
- タイミング: 毎日 02:00 JST に1回ポイントは「読み取りのみ」「書き出し先は新規ファイル」のように、破壊的操作の有無を明示すること。Claude Codeは指示に忠実なので、ここで「既存ファイルを上書きする」と書けば上書きしますし、書かなければ安全側に倒してくれることが多い。曖昧さを残さないのが事故防止の第一歩です。
2. 実装の進め方｜スクリプト化・冪等性・ログ
処理が整理できたら実装です。バッチで僕が必ず入れてもらうのが「冪等性」と「ログ」。この2つがないバッチは、いつか必ず事故ります。
冪等性：同じ入力なら何回流しても同じ結果に
冪等性（idempotency）とは、同じ処理を2回流しても結果が壊れない性質のことです。cronは時々、再起動やリトライで同じジョブを二重に走らせます。このとき「集計結果をDBにINSERTし続ける」設計だと、データが二重登録される。Claude Codeにはこう頼みます。
このバッチを冪等にしてください。同じ日付で2回実行しても、
出力ファイルやDBの状態が壊れないようにしたいです。
- 出力CSVは同名なら上書き（追記しない）
- DB書き込みは INSERT ではなく UPSERT（重複キーで更新）
- 処理開始時に当日分の既存レコードを確認し、あれば再生成扱いにする「追記ではなく上書き／UPSERT」というだけで、二重実行のリスクはかなり減ります。生成されたコードは、UPSERTのキー指定が正しいか、上書きが意図したファイルだけに限定されているかを、必ず自分の目で確認してください。
ログ：あとから「いつ・何が・どうなったか」を追える
無人で動くバッチは、ログがすべてです。標準出力に垂れ流すだけだと、cron実行時にどこにも残らず、朝になって「動いたのか失敗したのか分からない」状態になります。タイムスタンプ付きでファイルに残す形を指示します。
処理の各ステップで、タイムスタンプ付きのログを出力してください。
- ログは標準のloggingモジュールを使う
- 出力先は /var/log/batch/orders-YYYY-MM-DD.log
- 開始・各ステップ・件数・終了・例外を INFO/ERROR で記録
- 機密情報（APIキー・個人情報の中身）はログに書かない最後の「機密情報はログに書かない」は本当に大事です。デバッグのつもりでリクエスト全体をログに吐くと、APIキーや顧客のメールアドレスがログファイルに平文で残ります。ログ・コードに機密情報を残さないのは、自動化における最低限のルールだと思ってください。ログ設計をもっと突き詰めたい人は、ログ・監視をClaude Codeで実装する実践ガイドも合わせて読むと、監視まで一気に設計できます。
多重起動を防ぐロック
前のジョブが終わる前に次が走ると、リソースの取り合いやデータ破損が起きます。バッチには「同時に1つしか走らない」仕組み（排他ロック）を入れておきます。
このバッチに多重起動防止のロックを入れてください。
- ロックファイル方式（/tmp/orders-batch.lock）か flock を使う
- すでに実行中なら、何もせず終了してその旨をログに残す
- 異常終了してもロックが残り続けないようにする（trap で解放）シェルなら flock が手軽です。cron行に直接書く例はこうなります。
# /tmp/orders-batch.lock を排他ロック。すでに実行中ならスキップ
0 2 * * * /usr/bin/flock -n /tmp/orders-batch.lock /opt/batch/run_orders.sh >> /var/log/batch/cron.log 2>&1-n を付けると、ロックが取れなかったときは待たずに即終了します。これで前のジョブが長引いても二重起動しません。スクリプト本体を自作コマンド化して使い回したい場合は、CLIツール・自作コマンドをClaude Codeで作る実践ガイドのやり方が役立ちます。
3. スケジュール設定｜cron式の考え方
スクリプトが安定して動くようになったら、いよいよスケジュール登録です。cronは強力ですが、cron式（実行タイミングの指定）を間違えると「毎分実行されてサーバーが悲鳴を上げる」事故が起きやすい。ここはClaude Codeに式を作らせつつ、自分でも検算します。
cron式の5フィールド
標準的なcronは「分 時 日 月 曜日」の5フィールドです。よく使うパターンを整理しておきます。
# 分 時 日 月 曜日 コマンド
0 2 * * * 毎日 02:00 に実行
*/15 * * * * 15分ごとに実行
0 9 * * 1-5 平日（月〜金）の 09:00 に実行
0 0 1 * * 毎月1日の 00:00 に実行
30 23 * * 0 毎週日曜の 23:30 に実行Claude Codeに依頼するときは、自然言語で要件を伝えて式に変換してもらうと早いです。
「平日の朝8時45分に1回だけ実行する」cron式を書いてください。
タイムゾーンの扱いも教えてください（サーバーがUTCの場合の注意点）。ここで必ず確認したいのがタイムゾーンです。サーバーがUTC設定だと、「JST 02:00で組んだつもりが実際はJST 11:00に動いていた」という事故が起きます。これは過去に自社のメディア運用でも実際にやらかしたミスで、cron式自体は正しくても基準時刻がズレていました。crontab の先頭に CRON_TZ=Asia/Tokyo を書くか、サーバーのタイムゾーンを把握したうえでUTC換算するかを、登録前に必ず決めてください。
cron以外の選択肢も検討する
cronは枯れていて信頼できますが、「実行履歴をUIで見たい」「失敗を自動でリトライしたい」といった要求が強いなら、systemd timer・GitHub Actionsのスケジュールトリガー・クラウドのスケジューラ（マネージドジョブ）といった選択肢もあります。Claude Codeに「この要件ならcronとsystemd timerのどちらが向いているか、メリデメを比較して」と聞くと、判断材料を整理してくれます。無理にcronで全部やらず、要件に合った仕組みを選ぶのがコツです。
4. 失敗時の対応｜リトライ・通知・再実行
バッチは「失敗する前提」で設計します。ネットワークが一瞬切れた、入力ファイルがまだ来ていない、APIがレート制限を返した――こういう一時的な失敗は日常的に起きます。
リトライ：一時的な失敗は数回まで自動で粘る
外部APIやネットワークが絡む処理には、指数バックオフ付きのリトライを入れます。
外部API呼び出しに、リトライを入れてください。
- 最大3回まで、待機は指数バックオフ（2秒→4秒→8秒）
- リトライ対象はタイムアウトと5xx系のみ。4xx（認証エラー等）は即失敗
- すべて失敗したら、エラーをログに残して非ゼロ終了コードで終了注意点として、何でもリトライすればいいわけではない。認証エラー（401）や不正なリクエスト（400）はリトライしても直らないので、即座に失敗させて人を呼ぶべきです。ここを区別しないと「失敗し続けるジョブが延々とAPIを叩く」状態になります。
通知：成功も失敗も「見える化」する
無人バッチは、結果を能動的に知らせないと誰も気づきません。最低限「失敗したら通知」、できれば「成功時も件数を1行で通知」を入れます。
処理の最後に、結果をSlackへ通知する処理を追加してください。
- 成功時: 「✅ 注文集計 完了 / 件数 1,240 / 所要 12秒」のような1行
- 失敗時: 「❌ 注文集計 失敗 / 原因: 入力ファイルなし」とログ末尾を添える
- Webhook URLは環境変数から読む（コードに直書きしない）WebhookのURLやトークンは、必ず環境変数や秘密管理から読ませてください。コードにベタ書きすると、リポジトリに機密がコミットされてしまいます。シークレットの扱いは settings.json のpermission設定とも絡むので、Claude Code 実践テクニック完全ガイドで全体の設計を押さえておくと安心です。
再実行：止まったときに安全にやり直せるか
失敗したジョブを手で再実行するとき、安全にやり直せるかは「2. 冪等性」の設計に戻ってきます。冪等にしてあれば、同じ日付でもう一度流すだけでリカバリーできます。逆に冪等でないと、再実行で二重登録が起きて傷口を広げる。再実行手順は、Claude Codeに「このバッチの手動再実行コマンドと、再実行前に確認すべきこと（出力ファイルの退避など）を手順化して」と頼んで、runbookとして残しておくのがおすすめです。Pythonでスクリプトを組む全体像はPython開発をClaude Codeで効率化する実践ガイドも参考になります。
5. 落とし穴｜自動化で本当に気をつけること
ここが本記事でいちばん伝えたいパートです。自動化は「動いて終わり」ではなく、「壊れたときにどうなるか」まで考えて初めて完成します。失敗パターンを❌（やりがち）と⭕（こうする）で並べます。
❌ 多重起動でデータが二重になる ⭕ ロックで1本に絞る
cronの再実行やジョブの長期化で、同じバッチが並行して走るのは「あるある」です。ロック（flockやロックファイル）を入れていないと、集計が2回走って件数が倍になります。前述の flock -n を必ず入れてください。
❌ 止まらないジョブがサーバーを食い潰す ⭕ タイムアウトを設ける
外部APIの応答待ちや無限ループで、ジョブが終わらないことがあります。これが毎時積み重なると、プロセスが滞留してメモリやコネクションを食い潰す。各処理にタイムアウトを設定し、cron側でも timeout コマンドで上限をかけておくと安全です。
# 最大10分で打ち切る。超えたらプロセスを終了させる
0 2 * * * /usr/bin/timeout 600 /opt/batch/run_orders.sh >> /var/log/batch/cron.log 2>&1❌ 本番データをいきなり書き換える ⭕ dry-runとバックアップを挟む
いちばん怖いのが、本番のDBやファイルを直接書き換える処理を、検証なしで自動化してしまうこと。一度走ったら戻せません。本番データの破壊は最大のリスクです。Claude Codeにバッチを書かせたら、まず「実際には書き込まず、書き込む予定の内容をログに出すだけのdry-runモード」を付けてもらい、テスト環境で挙動を確認してから本番に載せます。削除・上書き系の処理には、直前のバックアップ取得をセットで組み込んでください。
❌ 機密情報がログやコードに残る ⭕ 環境変数と秘密管理に寄せる
APIキー・パスワード・個人情報を、コードに直書きしたりログに吐いたりすると、リポジトリやログファイル経由で漏れます。シークレットは環境変数や秘密管理サービスから読み、ログにはマスクした値だけを残す。これは自動化に限らず鉄則です。
❌ 生成コードをそのまま本番投入 ⭕ 人がレビューしてから動かす
Claude Codeは優秀ですが、生成したコードは必ず人がレビューしてから運用に乗せてください。とくに無人で繰り返し動くバッチは、1つのバグが毎日累積します。ロックの抜け、UPSERTキーの間違い、タイムゾーンのズレ――こうした「動くけど危ない」箇所は、レビューで初めて気づくことが多い。生成→レビュー→dry-run→本番、の順を崩さないのが、自動化を事故なく回すコツです。Claude Code固有の機能や仕様は変わることがあるので、実装時は公式ドキュメントで最新の挙動を確認してください。
6. 最小構成のまとめ｜今日から作れるバッチ自動化
ここまでをまとめると、Claude Codeで作る安全なバッチ自動化の最小構成は次の通りです。
- 処理を「入力・タイミング・順序と出力」で棚卸しし、破壊的操作の有無を明示してClaude Codeに指示する
- スクリプトに冪等性・タイムスタンプ付きログ・多重起動ロックを組み込む
- cron式はタイムゾーンを確認してから登録し、
flockとtimeoutで多重起動・暴走を防ぐ - リトライ（一時的失敗のみ）・通知（成功/失敗）・再実行手順を設計する
- 本番投入前にdry-runとバックアップで検証し、生成コードは人がレビューする
まずは「毎晩手で流している小さな作業」を1つ選んで、この最小構成で組んでみてください。スクリプト1本＋cron1行＋失敗通知、ここまで作れれば、夜のオペレーションは一気に楽になります。自動化全体をもっと無人運用に寄せたい人は、ヘッドレス実行やCIとの組み合わせも検討の価値があります。
CTA｜次の一歩
この記事を読んだら、ぜひ次の3つをやってみてください。
- 手元の手動作業を1つ選ぶ：毎日・毎週やっている定型作業を1つ書き出す
- 最小構成で組む：Claude Codeでスクリプト化→
flock付きcron登録→Slack失敗通知まで作る - dry-runで検証する：本番に載せる前に、テスト環境で1サイクル回して挙動を確認する
次回は「バッチの監視とアラート設計」をテーマに、失敗を早く検知して自動で立て直す仕組みを掘り下げる予定です。Claude Codeでの自動化を業務に本格導入したい、社内のエンジニアにまとめて教えたいという場合は、UravationのClaude Code実装支援・個別指導でも具体的な進め方を相談いただけます。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載を7回執筆。
