【実測】Claude Codeの定期実行は本当に毎時動くのか｜20日間の全ログで判明した達成率6.9%と3つの落とし穴

Claude Codeに「毎時07分にニュースを自動投稿して」と頼んで、20日間動かし続けました。結論から言うと、期待した480回に対して実際に投稿できたのは33回。達成率は6.9%でした。

これは失敗談ではありません。この数字の内訳を追いかけると、Claude Codeの定期実行を使ううえで絶対に知っておくべき仕様が3つ見えてきます。しかも、そのうち1つは私自身が完全に誤解していたもので、今日の検証で初めて正体がわかりました。実際のログと、その場で走らせた検証コマンドの結果をすべて公開します。

何を20日間動かしていたのか

検証に使ったのは、私が実際に運用しているX（旧Twitter）の自動投稿です。

・毎時07分に発火する定期タスクをClaude Codeに登録

・Claude Codeが最新のClaude Code関連ニュースを探す

・見つかったら見出しを入れた9秒の動画を自動生成

・専門家コメントを添えてXに投稿

・投稿済みのURLはログファイルに記録して重複を防ぐ

この仕組み自体の作り方は、Claude Codeで動画を自動生成する方法の記事で解説しています。今回はその「動かし続けた結果」の話です。

記録はposted_log.jsonというファイルに残っており、いつ・何を投稿したかが1件ずつ入っています。2026年7月14日から8月2日までの20日間分、33件が記録されていました。この生データを集計したのが本記事です。

実測その1：20日間で33回、達成率6.9%

まず全体の数字です。

・検証期間：2026年7月14日〜8月2日（20日間）

・毎時実行なら期待される回数：20日 × 24時間 = 480回

・実際に投稿された回数：33回

・達成率：6.9%

・投稿があった日：20日のうち11日

・最も長い空白：182.8時間（約7.6日）

「毎時」と指定したのに、実際には1日あたり平均1.65回しか動いていません。しかも9日間はまったく投稿がなく、7月23日から31日までは7.6日連続で沈黙していました。

ここで大事なのは、この数字の中身が3種類に分かれることです。

・仕様どおりの正常なスキップ（新しいニュースがない時間は投稿しない設計）

・知らないと必ずハマる落とし穴（後述する3つ）

・そもそも私が誤解していた挙動（これが最大の発見）

順番に分解していきます。

実測その2：「毎時07分」に投稿された回数はゼロ

次に、投稿された時刻を分単位で数えました。指定したのは毎時07分です。33回の投稿が何分に行われたかを集計した結果がこちらです。

・07分ちょうどの投稿：0回

・最も早い投稿：05分

・最も遅い投稿：59分

・投稿時刻の中央値：28分

1回も指定どおりの時刻に投稿されていませんでした。ばらつきは05分から59分まで、ほぼ1時間フルに散らばっています。

ずれる理由は「ジッター」という公式仕様

これはバグではなく、公式ドキュメントに明記された仕様でした。

Claude Codeの定期タスクにはジッターと呼ばれる意図的な時間のずらしが入っています。ずれ幅は周期の10%（最大15分）で、毎時のタスクなら約6分です。しかもこのずれ幅はランダムではなく、タスクIDから決まる固定値です。同じタスクなら毎回同じだけずれます。

つまり「毎時07分」と指定しても、実際に処理が始まるのは07分から13分ごろになります。世界中の利用者が同じ瞬間に殺到しないよう、意図的に散らす仕組みです。

ただし実測の中央値は28分で、最も遅いものは59分でした。ジッターが6分だとすると、残りの20分から50分はすべて実行時間ということになります。ニュースを検索し、動画を生成し、ブラウザを操作して投稿する。この一連の処理に、それだけの時間がかかっていたわけです。「発火の時刻」と「完了の時刻」はまったく別物だと考えたほうが実態に合います。

何時ちょうどに動かしたい人はどうするか

分単位の正確さが必要な業務には、この仕組みは向きません。「毎朝9時ちょうどにメールを送る」ような用途なら、Google Apps Script（GAS）のような別の仕組みに寄せるほうが確実です。その方法はClaude CodeでGASを書く方法の記事にまとめています。

逆に「1時間に1回くらい動けばいい」「朝のうちにレポートができていればいい」という用途なら、30分のずれは実用上まったく問題になりません。用途を選べばよい、というだけの話です。

落とし穴その1：セッションを変えると止まる（今日、実験で確認しました）

ここからが本記事の核心です。

私は長いあいだ、この定期実行を「セッションを閉じると消えてしまうもの」だと理解していました。作業していたウィンドウを閉じるたびに投稿が止まるので、そう思い込んでいたのです。7.6日の空白も、これが原因でした。

ところが公式ドキュメントを読み直すと、まったく違うことが書いてありました。定期タスクはディスクに保存されており、claude --resume で同じセッションを再開すれば復元されるというのです。

どちらが正しいのか。実際に試しました。

実験：同じ条件で3回、登録と確認を繰り返す

手順はシンプルです。テスト用の定期タスクを1つ登録し、それが「同じセッションを再開した場合」と「別の新しいセッションを立ち上げた場合」でどう見えるかを比べます。

結果はこうなりました。

手順1（登録）
  → ジョブID: d15aa3c7 を登録しました

手順2（--resume で同じセッションに戻る）
  → 件数: 1件 / ジョブID: d15aa3c7   ★生きている

手順3（別の新しいセッション）
  → 0件です。ジョブIDはありません     ★見えない

同じセッションを再開すれば1件見えている。別の新しいセッションでは0件。

つまり、定期タスクは消えていませんでした。ディスクにちゃんと残っています。ただし新しいセッションを立ち上げるとそのタスクは見えず、動きもしないのです。

私が「消えた」と思っていたものは、正確には「別の部屋に置いてきた」でした。翌日パソコンを開いて新しくClaude Codeを起動すると、前日のタスクがある部屋には入っていない。だから止まっているように見えていたのです。

実務でどうすればいいか

対処は明快です。

・定期実行を続けたいなら、新しく起動せず claude --resume で同じセッションに戻る

・どのセッションで登録したかを控えておく（セッションIDか、--name で名前を付けておく）

・止まっているように見えたら、まず CronList で現在のセッションに何件あるかを確認する

私は20日間ずっと、止まるたびに「また失効したのか」と新規登録し直していました。実際には再開すればよかっただけです。この誤解だけで、投稿できたはずの機会をかなり落としています。

落とし穴その2：7日で自動的に失効する

再開すれば生き続けるとはいえ、無限には続きません。

公式仕様では、定期タスクは作成から7日で自動的に失効します。7日後に最後の1回が実行され、そこで削除されます。継続したい場合は作り直しが必要です。

これは「うっかり永久に動き続けて課金が膨らむ」ことを防ぐ安全装置だと考えるのが自然です。裏を返せば、7日を超える運用を前提にした業務には使えないということでもあります。毎週の棚卸しや毎月のレポートのような長期の定期業務に使うなら、週に一度は自分で登録し直す運用を組み込むか、後述するクラウド実行に移すことになります。

なお、1つのセッションに登録できる定期タスクは最大50個までです。

落とし穴その3：ネタがない時間は投稿されない（これは正しい挙動）

3つ目は落とし穴というより、設計として意図したものです。

今回の自動投稿には「新しいニュースが見つからなければ投稿しない」という条件を入れてあります。同じニュースを二重に投稿しないよう、過去の投稿URLをログと照合してから判断させています。

深夜帯や、Claude Code関連の発表が何もない日は、この条件によって正しくスキップされます。達成率6.9%のうち相当な部分は、この「投稿すべきものがなかった」時間です。

ここは評価を間違えないよう注意が必要です。「動いた回数」ではなく「投稿すべきときに投稿できたか」で見ないと、正常なスキップまで失敗としてカウントしてしまいます。自動化の成否を測るときは、実行回数そのものではなく、目的に沿った成果が出た回数を数えるべきです。

実際、投稿された33件の中身を見ると、Claude Code v2.1.217や2.1.218のリリース、Anthropicの障害情報、大型の資金調達ニュースなど、拾うべきものはきちんと拾えていました。

結論：3つの選択肢をどう使い分けるか

ここまでの実測を踏まえると、Claude Codeで定期実行を組む方法は3つあり、性質がはっきり違います。

セッション内の定期実行（今回検証したもの）

最短1分間隔で動かせて、手元のファイルにも自由にアクセスできます。ただし同じセッションを開いておく（または再開する）必要があり、7日で失効します。試作や、その日のうちに終わる繰り返し作業に向いています。

デスクトップアプリの定期タスク

Claude Codeのデスクトップアプリで登録するもので、こちらも最短1分。手元のファイルにフルアクセスできます。アプリが起動していてパソコンが動いていれば実行されるため、セッションを意識せずに済みます。パソコンがスリープしていた時間はスキップされますが、7日以内の実行漏れは一度だけ拾い直してくれます。

Routines（クラウド実行）

Anthropicのクラウド側で動くため、パソコンの電源を切っていても実行されます。ただし手元のファイルには一切アクセスできず、GitHubリポジトリと連携する形になります。最短間隔も1時間です。

私が今回の自動投稿をクラウドに移せなかったのは、この「手元のファイルにアクセスできない」制約が理由でした。ブラウザを操作してXに投稿する方式は、クラウド側では実行できません。

選び方の目安

・その日のうちに終わる繰り返し → セッション内の定期実行

・毎日決まった時刻に手元のファイルを処理したい → デスクトップアプリの定期タスク

・パソコンを閉じていても動かしたい／サーバー上の作業 → Routines

「パソコンを閉じていても動かしたい」が要件なら、最初からRoutinesかGASを選ぶべきです。セッション内の定期実行でそれをやろうとすると、私のように20日かけて達成率6.9%という結果になります。

よくある質問

Q. 定期実行を使うのに追加料金はかかりますか?

定期タスクの実行分は通常の利用と同じ扱いで、プランの使用量を消費します。専用の追加料金があるわけではありません。ただし1時間に1回動かせば、その分だけ確実に使用量は増えます。動かす前に「1回あたりどれくらいの作業をさせるか」を小さく設計しておくのが安全です。

Q. 止まっているかどうかを確認する方法は?

現在のセッションで CronList を実行すれば、登録されている定期タスクの一覧と件数が返ってきます。0件と表示されたら、そのセッションには何も登録されていません。別のセッションで登録したものを動かしたい場合は claude --resume で戻ってください。

Q. 毎時ではなく毎日決まった時刻にしたい場合は?

指定方法自体は同じで、時刻を1日1回に変えるだけです。ただし本記事のとおりジッターと実行時間の分だけ後ろにずれるため、「9時ちょうど」ではなく「9時すぎから、処理が終わるまで」と考えてください。分単位の正確さが必要なら、GASのような外部の仕組みに寄せるのが確実です。

Q. 自動化の仕組みごと作ってほしい場合は?

毎月の定型業務を自動化するツールの構築を代行しています。仕組みの設計から相談したい方は、お仕事のご依頼をご覧ください。

まとめ

Claude Codeの定期実行を20日間動かして実測した結果をまとめます。

・達成率6.9%（期待480回に対して実測33回、投稿があったのは11日）

・「毎時07分」指定で07分ちょうどの投稿は0回。ジッター（周期の10%・毎時なら約6分）に加え、実行時間そのものが20分以上乗る

・セッションを変えると止まる。ただし消えてはおらず、claude --resume で同じセッションに戻れば生きている（今回の実験で確認）

・7日で自動失効するので、長期運用には作り直しかクラウド実行が必要

・ネタがない時間のスキップは正常な挙動。実行回数ではなく成果の回数で評価する

いちばんの教訓は、3つ目の「消えていなかった」です。仕様を誤解したまま20日間、止まるたびに新規登録を繰り返していました。自動化がうまく動かないとき、原因が仕組みそのものではなく自分の理解にあることは珍しくありません。まずは CronList で現状を確認するところから始めてみてください。

あわせて読みたい関連記事：

AIの最新情報をリアルタイムで受け取りませんか?

X（旧Twitter）@ai_hack_dxでは、Claude Codeの実践テクニックやAI業界の最新動向を毎日発信しています。記事の更新情報もいち早くお届けしますので、ぜひフォローをお願いします。