OpenClawのcron同時実行クラッシュは、Anthropic APIの共有競合が原因で、スケジュール分散・maxConcurrentRuns・isolatedセッションの3つで解消できます。
- 要点1: cronとSlack対話が重なるとCLIが応答しなくなりタイムアウトする。レーン分離してもAPIは共有
- 要点2: 最も手軽な解決策はスケジュール分散（同時間帯のcronを30分以上ずらす）
- 要点3: sessionTarget: isolatedで独立セッション化すると根本的な競合を回避できる
対象: OpenClawでcronジョブを運用している企業のDX担当者・エンジニア
今日やること: openclaw cron list でジョブの実行時間を確認し、同時間帯のものを30分以上ずらして分散する
この記事の目次
OpenClawのcronジョブを複数設定していたところ、ある日突然すべてがタイムアウトになる——こうした事態は、cronと通常のSlack対話を同時に使っている環境で高確率で起きます。
原因はOpenClawの設計上の特性にあります。cronとSlack対話でレーン（実行キュー）は分かれていますが、最終的に呼び出すAnthropic APIは同じです。そのため、両者が重なるとCLIが応答を返せなくなり、cronがタイムアウト上限まで待機し続けて強制終了されます。
この記事では、実際に6つのcronが全てタイムアウトした事例をもとに、3つの解決策——スケジュール分散・maxConcurrentRuns設定・sessionTarget:isolated——を具体的な設定例と合わせて解説します。
cronジョブが全タイムアウトした — 実際に起きた事例
ある日、朝のcronジョブが全て失敗しているのに気づきました。ログを見ると、実行されてはいるものの、各ジョブがタイムアウト設定の上限秒数ぴったりで強制終了されていました。
正常時と障害時の比較
前日（正常）と当日（異常）の実行時間を比較すると、問題の全体像が見えてきます。
| ジョブ名 | タイムアウト設定 | 前日（正常時） | 当日（異常時） | 状態 |
|---|---|---|---|---|
| info-hub-status-update | 300s | 144s | 144s | ✅ 正常完了 |
| daily-calendar-notify | 120s | 15s | 120s | ❌ 強制終了 |
| info-hub-action-scanner | 600s | 209s | 600s | ❌ 強制終了 |
| ai-coaching-daily-check | 900s | 121s | 900s | ❌ 強制終了 |
| shukatsu-search-console | 1200s | 46s | 1200s | ❌ 強制終了 |
| ga4-seo-report | 1200s | 87s | 1200s | ❌ 強制終了 |
注目すべきは、前日まで15秒や46秒で完了していたジョブが、当日はタイムアウト上限の120秒・1200秒まで待ち続けて強制終了されている点です。処理内容は変わっていません。
「タイムアウト上限ぴったり」が示すもの
ジョブが「タイムアウト上限ぴったりで終了する」という症状は、処理が重くなったのではなく、CLIが一切応答を返さない状態になっていることを意味します。
正常に動作していれば、処理が終わり次第すぐに結果が返ってくるはずです。それが返ってこないということは、Claude CLI（claudeコマンド）がAnthropicのAPIにリクエストを送っても、応答が来ない状態に陥っているということです。
当日の環境を確認したところ、8:30〜9:45のcron実行時間帯に、SlackからOpenClawへ複数のリクエストを送っていたことがわかりました。
なぜ起きるのか — OpenClawのアーキテクチャと根本原因
この問題を理解するには、OpenClawがどのように並行処理を管理しているかを知る必要があります。
OpenClawとは、Claude Codeを24時間稼働させるSlack常駐型のAIエージェントシステムです。Slackのメッセージを受け取り、Claude CLIを呼び出してタスクを実行します。（OpenClawをSlack常駐させる完全ガイドはこちら →）
レーン分離はされているが、APIは共有している
OpenClawは実行の種類によって「レーン（実行キュー）」を分けています。
| レーン | 役割 | maxConcurrent |
|---|---|---|
| mainレーン | Slackからの対話処理 | 4（最大4並行） |
| cronレーン | 定期ジョブの実行 | 1（直列実行） |
| subagentレーン | サブエージェント処理 | 8 |
一見すると、cronとmainは完全に分離されているように見えます。実際、同じレーン内での競合はありません。cronジョブはcronレーンで順番に実行され、Slack対話はmainレーンで並行処理されます。
しかし、どちらのレーンも最終的に呼び出すのは同一のClaude CLIプロセスと同一のAnthropicのAPIです。
同時実行でCLIが応答しなくなるメカニズム
Anthropic APIには、リクエスト数（RPM）とトークン数（ITPM/OTPM）に上限があります。利用プランによって上限は異なりますが、短時間に大量のリクエストが集中すると応答が遅延したり、レートリミットに達してエラーが返ることがあります。
cronジョブが朝の同じ時間帯に複数起動し、さらにSlackからの対話リクエストも重なった場合、Claude CLIが同時にAnthropicのAPIを叩くリクエスト数が急増します。その結果として：
- APIのレートリミットに近づき、レスポンスが遅延する
- CLIが応答を待ち続け、OpenClawのタイムアウト設定に達する
- タイムアウトで強制終了、cronは失敗ログが記録される
この問題への対策は3つあります。
＼ Claude Codeの導入、何から始めればいいかわかります ／
法人向けClaude Code個別指導の無料相談はこちら解決策1 — cronスケジュールを時間分散させる（最も手軽）
最も即効性が高く、設定も簡単な解決策です。複数のcronジョブが同時間帯に集中している場合、それを30分以上の間隔で分散させます。
分散前/後のスケジュール比較
問題が起きた環境では、9:00に3つのジョブが同時起動していました。これを次のように分散しました。
分散前（9:00に集中していた状態）:
| 実行時刻 | ジョブ |
|---|---|
| 8:30 | info-hub-status-update |
| 9:00 | daily-calendar-notify |
| 9:00 | info-hub-action-scanner |
| 9:00 | ai-coaching-daily-check |
| 9:30 | shukatsu-search-console |
| 9:45 | ga4-seo-report |
分散後（30〜60分間隔に変更）:
| 実行時刻 | ジョブ |
|---|---|
| 7:00 | ai-coaching-daily-check |
| 7:30 | daily-calendar-notify |
| 8:00 | info-hub-action-scanner |
| 8:30 | info-hub-status-update |
| 9:30 | shukatsu-search-console |
| 9:45 | ga4-seo-report |
翌日からすべてのcronジョブが正常に完了するようになりました。各ジョブが完了してからAPIのリソースが解放され、次のジョブが開始される形になるため、競合が起きにくくなります。
分散設定のコマンド例
openclaw cron editで既存のcronのスケジュールを変更できます。
# ジョブのIDを確認openclaw cron list# スケジュールを変更（例: 9:00 → 7:00）openclaw cron edit [ジョブID] --schedule "0 7 * * *"スケジュールはcron式（分 時 日 月 曜日）で指定します。毎日7:30に実行する場合は"30 7 * * *"です。
ポイントスケジュール分散の目安は「前のジョブの予想所要時間 + 30分」の余裕を持たせることです。前日までのログを確認し、各ジョブの通常実行時間を把握した上で設定してください。
Claude Codeの設定やOpenClawの運用についてご不明な点がある場合は、個別に相談いただけます。「スケジュール設計はどうすべきか」「自社環境での最適設定を知りたい」といった段階からサポートしています。
解決策2 — maxConcurrentRunsで同時実行数を制御する
スケジュール分散が「そもそも同時に動かさない」対策だとすると、maxConcurrentRunsは「同時に動く場合の上限を制御する」対策です。
maxConcurrentRunsとは何か
maxConcurrentRunsは、cronレーン内で同時に実行できるジョブの最大数を設定するパラメーターです。
- デフォルト値: 1（全ジョブを直列実行）
- 設定可能な値: 整数（1以上）
- 注意: cronレーン内の並行数を増やしても、mainレーンとのAPI競合問題は解消されない
「cronジョブ同士は並行で動かしたいが、無制限には動かしたくない」というケースに有効です。たとえば、互いに独立したジョブ（メール確認・カレンダー確認・レポート生成など）を同時に走らせたい場合、maxConcurrentRuns: 3に設定することで3つまで並行実行できます。
openclaw.jsonへの設定方法
~/.openclaw/openclaw.jsonのcronセクションに追加します。
{ "cron": { "enabled": true, "maxConcurrentRuns": 2 }}変更後はOpenClawのgatewayを再起動してください。
openclaw restart推奨値の考え方:
| maxConcurrentRuns | 適した状況 |
|---|---|
| 1（デフォルト） | 単純なジョブが多い、APIリソースを節約したい |
| 2〜3 | 独立したジョブを並行で走らせたい、全体の完了を早めたい |
| 4以上 | 基本的に非推奨。APIレートリミットに達するリスクが高まる |
ただし、maxConcurrentRunsを増やすだけでは、cronとSlack対話の競合問題は解決しません。あくまでもcronジョブ同士の制御であることを念頭に置いてください。
＼ 業務自動化のお悩み、プロが30分で整理します ／
法人向けClaude Code個別指導の無料相談はこちら解決策3 — sessionTarget: isolatedで独立セッションに切り替える
最も根本的な解決策です。cronジョブを「isolated（独立）」なセッションで実行することで、mainセッション（Slack対話）との履歴・コンテキストの共有を断ち切ります。
sessionTarget: mainとisolatedの違い
OpenClawのcronジョブには2種類のセッションターゲットがあります。
| 設定 | 実行場所 | 会話履歴 | 主な用途 |
|---|---|---|---|
main |
メインセッション内 | 共有する | 対話の続きとしてcronを実行したい場合 |
isolated |
専用セッション（cron:[jobId]） | 共有しない | バックグラウンドで独立したタスクを実行する場合 |
mainはSlackの会話履歴を参照できる反面、mainレーンのリソースを消費します。isolatedは完全に独立したセッションを立ち上げるため、mainレーンへの影響を最小化できます。
定期レポート生成、データ取得、通知送信など、会話履歴が不要なcronジョブはすべてisolated推奨です。
isolated設定の書き方と注意点
openclaw.jsonのcronジョブ定義にsessionTarget: "isolated"を追加します。
{ "cron": { "jobs": [ { "id": "daily-calendar-notify", "schedule": "30 7 * * *", "sessionTarget": "isolated", "message": "今日の予定を取得してSlackに通知してください", "delivery": { "mode": "announce", "channel": "C1234567890" } } ] }}コマンドラインからも設定できます。
openclaw cron edit [ジョブID] --session isolated注意: Workspaceスキルの読み込みについて
sessionTarget: isolatedに設定したcronジョブは、独立したセッションで起動するため、Workspaceに配置したスキルが読み込まれない場合があります（既知の問題）。スキルを使用するcronジョブでは、プロンプト内で明示的にスキルのパスを指定するか、~/.claude/CLAUDE.mdへの記載を活用してください。
3つの対策の組み合わせと優先順位
状況に応じて適切な解決策を選びましょう。
| 対策 | 手軽さ | 効果 | 主なデメリット |
|---|---|---|---|
| スケジュール分散 | ◎ とても手軽 | ○ 有効 | 実行タイミングが希望から変わる |
| maxConcurrentRuns | ○ 設定ファイルを変更 | △ 限定的 | cronとSlack対話の競合には効かない |
| isolated化 | ○ 設定ファイルを変更 | ◎ 根本的 | Workspaceスキルの読み込みに注意が必要 |
まず試すべき対策（スケジュール分散）
今すぐできる対策として、まずスケジュール分散から始めることを推奨します。openclaw cron listで実行時間を確認し、9:00など同時間帯に集中しているジョブを30〜60分ずつずらすだけで、多くの場合は解消します。
対話利用が少ない早朝（6:00〜8:00）にcronを配置することも有効です。
さらに安定化させたい場合（isolated + 分散）
より安定した運用を目指す場合は、スケジュール分散に加えてsessionTarget: isolatedを設定することを検討してください。独立セッションで動作するため、mainセッションの状態に関わらず安定してcronが動作します。
maxConcurrentRunsは、「複数のcronを意図的に並行実行させたい場合」のみ設定を変更してください。それ以外のケースでは、デフォルト（1）のままにしておくほうが安全です。
＼ AI活用の「次の一手」を一緒に考えませんか ／
法人向けClaude Code個別指導の無料相談はこちらよくある質問
Q. cronジョブが実行されているかどうか確認する方法は？
openclaw cron listでジョブの一覧と最終実行時刻を確認できます。ログファイルは~/.openclaw/cron/runs/に保存されており、各ジョブの実行結果（ok / timeout / error）と実行時間が記録されています。タイムアウトになっている場合は status: "timeout" で識別できます。
Q. OpenClawを使いながらcronを動かすには？
完全に競合をなくすことは現状の設計上難しい部分もあります。現実的な対策は2つです。まず、cronの実行時間帯（特に朝7:00〜10:00など）にSlackでOpenClawへの大量リクエストを避けること。次に、sessionTarget: isolatedを設定してcronを独立セッション化すること。この2つを組み合わせると、日常的な対話とcronの共存が実現しやすくなります。
Q. タイムアウト時間を延ばすだけでは解決しない？
タイムアウト時間を延ばしても根本原因（API競合）は解消されません。CLIが応答を返さない原因がAPIの競合である限り、何秒待っても結果は変わりません。「タイムアウト上限ぴったりで終了する」という症状が続く場合は、タイムアウト延長ではなく本記事で紹介した3つの対策を試してください。
なお、OpenClaw全般のトラブルシューティングについては「OpenClawのトラブルシューティング — Slackで返信が来ないときの対処法」も参照してください。
まとめ
OpenClawのcron同時実行クラッシュの主な原因と解決策をまとめます。
- 原因: cronとSlack対話が同一Anthropic APIを共有しており、同時リクエストが集中するとCLIが応答しなくなる
- 解決策1（最優先）: スケジュール分散 — 同時間帯のcronを30分以上ずらす
- 解決策2（補助）: maxConcurrentRuns設定 — cron同士の並行実行数を制御する（1〜3推奨）
- 解決策3（根本対策）: sessionTarget: isolated — cronを独立セッションで実行し、mainセッションとの競合を回避
まずopenclaw cron listで現在の実行スケジュールを確認し、同時間帯のジョブを分散させることから始めてください。それでも改善しない場合は、sessionTarget: isolatedの設定を追加してください。
OpenClawのcronジョブ設定の基本については「OpenClawのcronジョブで定期タスクを自動実行する」もあわせてご覧ください。
Claude Codeの導入・活用をサポートします
株式会社Nexaでは、OpenClawの設定からClaude Codeを活用した業務自動化まで、個別指導・企業研修を提供しています。「設定してみたがうまく動かない」「自社環境での最適な構成を知りたい」という段階からご支援いたします。詳しい設定方法やカスタマイズについては、まずは無料相談でお気軽にご相談ください。
