Claude Codeのスケジュール実行｜毎朝の定型作業を無人で回す設計【2026年版】

Claude Codeを触って最初に「仕事が変わる」と感じるのは、たいてい同じ作業を2回目にやらせたときです。手順を伝えれば同じ品質で返ってくる。だったら毎朝の定型作業を、自分が起きる前に終わらせておいてほしい——そう考えるのは自然な流れです。

ところが、そこから先で多くの人が同じ場所で止まります。手元で動かせば完璧に動くのに、時刻を決めて無人で走らせた瞬間に、静かに落ちるからです。

当社は営業・マーケの定型業務をClaude Codeの定時実行で回しています。この記事は、その運用で実際に踏んだ失敗をもとに、定期実行を「動く」から「毎朝続く」に変えるための設計をまとめたものです。うまくいった話より、落ちた話のほうを多めに書きます。

この記事の要点

• 定期実行に載せてよい仕事は3条件で判定できる。入力の置き場所が固定・出力の受け手が社内・落ちてもその日のうちに取り返せる。1つでも欠けたら人の手元に残す
• 実行時刻はAIの都合ではなく人の生活時間で決める。当社は移動が入る10〜15時と、PCを私用で使う18〜23時を避けて朝側に寄せている
• 定期実行に固有の壊れ方は「前提条件が変わる」こと。手で動かしたときと、スケジューラから起動されたときでは、読めるファイルもキー入力の届き方も違う
• 当社は自動起動されたプロセスが特定のフォルダを読めず、二重投稿を止めるチェックが4日連続で実行できていなかった。エラーは1件も出ていない
• 落ちたことに気づく仕組みは、落ちる本体とは別のプロセスで持つ。同じ処理の中に検知を書くと、その処理が黙って死んだ日には検知も死ぬ

何を定期実行に載せてよいか｜3つの条件

「毎日やっている作業」がそのまま定期実行の候補になるわけではありません。当社が使っている判定は3つです。

3つとも満たす仕事は、無人で走らせても事故が小さく収まります。逆に、1つでも欠ける仕事を無理に載せると、浮いた時間より事故の後始末のほうが高くつきます。

なかでも2つ目が実務では効きます。社外に届く一手だけは人が押すという線引きにしておくと、定期実行は「下書きを毎朝そこに用意しておく係」になり、失敗しても取り消しの必要が出ません（根拠＝Claude Codeは危険か｜実際に起きた4つの事故と、機械で止める設計）。

なお当社も、この3条件をあとから作りました。最初は「毎日やっているから」というだけで載せて、社外に出る工程まで自動側に置いてしまった時期があります。条件は事故の後に言語化されたもので、先に思いついたものではありません。

実行時刻は「人の生活時間」から逆算する

定期実行の時刻は、サーバーが空いている時間でもAPIが安い時間でもなく、その仕事に人がどう関わるかで決まります。判断の軸は1つだけです。

その処理の最後の一手を人が押すなら、人がPCの前にいる時刻に置く。完全に無人で終わるなら、人が触っていない時刻に置く。

当社は自社の生活時間を実測して、移動が入りやすい10〜15時と、PCを私用で使う18〜23時を避けて朝側に寄せるという運用にしています。理由は単純で、この2つの帯に置いたタスクは、人の確認が必要になった瞬間に止まったまま放置されるからです。処理そのものは正しいのに、成果が出ない。

そのうえで、時刻を決めるときに実際にやることは3つです。

1. 既存のタスクと時刻を重ねない。 同じ資源（同じブラウザ、同じアカウント、同じ台帳）を触るタスクを同時刻に走らせると、片方が黙って負けます
2. 人の確認が要る工程は、朝の一箇所にまとめる。 負担になるのは確認の回数ではなく「確認のために意識を切り替える回数」だからです
3. 失敗したときの再実行枠を、同じ日のうちに用意する（後述）

手で動かすと通り、定時だと落ちる｜前提条件が変わる

ここが、定期実行に固有の、そしていちばん厄介な問題です。

対話で自分が動かすとき、Claude Codeはあなたがログインしている環境で動きます。あなたの画面は開いていて、フォルダへのアクセス許可はあなたの操作として通り、キー入力はそのままアプリに届きます。ところがスケジューラから自動起動されたときは、この前提が全部変わります。

当社が実際に踏んだのは、次の2つです。

① 自動起動されたプロセスが、特定のフォルダを読めない。

macOSでは、自動起動の仕組み（launchd）から起動されたプロセスに対して、デスクトップなど一部のフォルダへのアクセスが保護されています。厄介なのは壊れ方が中途半端なことで、ファイル一覧の取得は成功するのに、中身を開こうとした瞬間だけ「操作が許可されていません」で落ちます。「ファイルはある」と確認できてしまうので、パスの間違いを疑っても永久に見つかりません。

これが当社に何をもたらしたか。当日すでに投稿したかどうかを台帳で確認する二重投稿の防止チェックが、2026年8月28日から31日までの4日間、フォールバック側の経路で一度も実行できていませんでした。エラー通知は1件も出ていません。安全装置が外れたことに、4日間気づけていなかったということです。

対策は、判定に使うファイルを保護対象外の場所へ自動で写しておき、自動起動側はその写しを読むようにしたことです。写しの更新は「AIへのお願い」にせず、通常経路の完了条件に組み込んで副作用として起きるようにしました。人が同期を思い出す設計にすると、思い出さなかった日に穴が開きます。

② 画面がロックされているとキー入力だけが届かない。

画面がロックされていても、ファイル操作もブラウザ側の処理も通ります。届かないのはOSのキー入力だけです。前半は成功して最後の一手だけが失敗する。当社ではキー入力に依存する処理が12本あり、ロック中に発火すればまとめて同時に落ちる構造でした。対策は、毎朝ロック状態を1行記録して落ちた日と突き合わせられるようにしたうえで、重要な経路からキー入力を全廃したことです。原因の特定を待つより、依存そのものを外すほうが早い。

この2つに共通しているのは、手元では100回動いても再現しないという点です。だから定期実行を組むときは、実装が終わった直後に必ず「自分が触っていない状態で1回走らせて、成果物が本当に出ているか」を確認してください。ログを見るのではなく、成果物を見ることです。

落ちたことに気づく仕組みは、別プロセスで持つ

定期実行でいちばん高くつく壊れ方は、間違った出力ではなく何も起きなかったことです。間違った出力は目に見えますが、起きなかったことは何も残りません。

原則は1つです。検知は、落ちる本体とは別のプロセスに持たせる。 処理の最後に「成功しました」と書かせる設計は、その処理が黙って死んだ日には何も書かれず、静かに正常に見えます。当社は「その日の成果物が実際に存在するか」を後から別で数える形にしました。

これを入れる前、当社は外部サービス側に保存したはずの下書き8本が、実際には保存されておらず、それに約3週間気づけませんでした。処理は正常終了し、手元の記録には「保存済み」と書かれていて、実物だけが無い。在庫として数えていた記録が、実物と照合されていなかったからです。いまは在庫の各行に外部側のIDを必ず持たせ、毎日そのIDで実物を直接照合しています。

言い換えると、記録を数えるだけの検知は検知ではありません。記録は、失敗した処理自身が書いたものだからです。検知の設計そのものについてはClaude Codeは危険かで、終了コードの分け方や「チェックする側も壊れる」問題まで書いています。

途中で切れても、最初からやり直さない

定期実行が扱う仕事には、記事を5本・企業を10社といった複数ユニットのバッチが混ざります。途中で通信が切れたりセッションが落ちたりすると、次の起動が最初からやり直しになる。時間の無駄というより、外部に副作用が出る処理では二重実行の事故になります。運用ルールは3つだけです。

1. 作業フォルダに進捗ファイルを1つ置き、実行のはじめに必ず読む。 完了済みユニットはスキップして続きから入る
2. 1ユニットずつ完結させ、完了直後に記録する。 「全部作ってから最後にまとめて保存」を禁止する。落ちて消えるのは会話であって、ディスクに書いたものは残る
3. 外部に副作用が出た瞬間にIDやURLを記録する。 再開時に記録が曖昧なユニットは、実行済みとみなして再実行しない（二重投稿・二重送信のほうが実害が大きい）

このルールが効いた実例があります。上で書いた下書き8本の復旧作業は、1本ずつ「保存 → 検証 → 進捗ファイルに追記」を繰り返す形で回し、8本すべてを取りこぼしも二重作成もなく復旧できました。

直らなかったときの受け皿を、三段で持つ

検知ができても、その場で直せるとは限りません。当社は受け皿を三段にしています。

そのうえで、何を自動で直してよいかを種別で機械的に決めています。当社の線引きは「直す・減らす・書き換えるは自動。増やす・払う・送る・消すは人に聞く」の1行です。壊れた自動化の修復・ルールの追記・件数の削減は確認なしで実行し、送信・支払い・削除・増枠だけを人に上げます。

この線引きを作った理由は、判断を仰ぐ側に倒しすぎて改善が1週間止まったからです。安全に見えて、実際は「直せるのに直っていない状態」を毎週作っていました。あわせて、変更前のスナップショットと判定日をセットで残し、判定日に効果が出ていなければ自動で元に戻すようにしています。戻る仕組みがあるから、確認なしで打てます。

ここで必ず返ってくる反論

「そこまで作り込むなら、エンジニアを1人雇うのと変わらないのでは？」

もっともな指摘です。ただ、この記事に書いたものの中に、コードを書く力が要るものはほとんどありません。要るのは「落ちたことにどう気づくか」を決めることと、何を人が押すかの線引きで、これは業務を分かっている人にしか決められません。実装が難しいのではなく、運用の設計が抜けたまま実装だけ進むから落ちるというのが、自社で回してきた実感です。

もう1つ、よく返ってくる反論も先に書いておきます。「毎朝止まるような仕組みなら、手でやったほうが早いのでは？」——これは、載せる仕事を間違えたときには完全に正しいです。冒頭の3条件を満たさない仕事、とくに顧客に届く工程を自動側に置いた場合、確認と後始末で手作業より遅くなります。定期実行が効くのは、価値の低い前工程（集める・整える・下書きを作る・記録する）を人の朝から外すときです。

定期実行を増やす順番

最後に、これから作る人向けの順番です。当社が実際に踏んだ順で、事故の小さいほうから並べています。

1. 観測から始める。 「昨日の数字を集めて1行の記録を書く」だけのタスクを1本作る。壊れても実害がゼロで、しかも壊れたら記録が無いのですぐ分かる
2. 次に下書き。 提案書・議事録・レポートの下書きまでを自動にして、確認と送信は人が持つ
3. その次に、確認済みのものを社内に配る工程。 ここで初めて「送る」に手を出す
4. 社外への送信・公開は、最後まで人が押す。 押す動作は時間を食いません。時間を食っていたのはその手前です

この順番を守ると、最初の1本は1日で組めて、失敗しても誰にも迷惑がかかりません。いきなり社外に届く工程から自動化したところが、いちばん早く止まります。どこから外すかの見立てはClaude Code導入支援の費用相場と失敗しない選び方にまとめています。

よくある質問

Q. 定期実行は毎日でないとダメですか？

いいえ。むしろ最初の1本は週1回で構いません。毎日のタスクは、壊れたときに毎日壊れます。週1回で3〜4周まわして成果物が毎回出ていることを確認してから頻度を上げるほうが、結果的に早く安定します。

Q. 定期実行が落ちたかどうかを、通知で受け取れば十分では？

通知は「処理が動いた」ことしか教えてくれません。当社が踏んだ失敗はどれも、処理が正常終了して通知も出ないまま、成果物だけが存在しないという形でした。通知ではなく、その日に出ているはずの成果物を別の処理が数える形にしてください。

Q. 実行のたびに費用はどれくらいかかりますか？

タスクの中身と、1回の実行でどれだけの文脈を読ませるかで数倍動きます。当社のログ実測では、同じ会話を延々と続けた場合に1ターンあたりの単価が3.9倍になった記録があります。定期実行は1本ずつ独立させ、状態は会話ではなくファイルに持たせるほうが安くなります。内訳はClaude Code法人利用の料金と「本当のコスト」にまとめました。

Q. どこまでなら自動化して、どこからは人がやるべきですか？

取り消せるかどうかの1点で振り分けてください。読む・下書く・記録する・集計するはAIに渡して構いません。社外への送信・公開・削除は人が押します。当社は、削除を自動側に残していた時期に、正常に投稿されたものをAIが「自分の誤りだ」と解釈して消す事故を起こしました。消えたものは戻らないうえ、消えたこと自体に気づけません。

Q. 手順書に「毎回これを確認すること」と書いておけば足りませんか？

足りません。手順書はAIに対しては「お願い」で、読み飛ばしても誰も止めず、「確認しました」と報告することもできます。当社は手順書に書いてあるにもかかわらず、同じ枠に3日連続で二重投稿を出しました。守らせたいことは、文章ではなく実行前のチェックに置き換えてください（詳細）。

---

執筆・監修：佐々木 優希（AIリモートワーカー代表／上場企業 営業統括 兼 AI責任者）

自社の営業・マーケ業務をClaude Codeの定時実行で運用しており、本記事の失敗事例はすべて自社の運用記録に基づいています。