# Managed Agentsのスケジュール実行設計 > Claude Managed AgentsのScheduled Deploymentsはcron式で分単位の定期実行を設定でき、最大15%のジッターとpause/archiveの3段階制御で障害を吸収する。 - Canonical: https://kuucorp.com/blog/managed-agents-scheduled-deployment-cron-design/ - Date: 2026-10-08 - Last modified: 2026-10-08 - Publisher: Kuu株式会社 (https://kuucorp.com) --- AIエージェントを「呼ばれたら動く」ものから「自分で動き出す」ものに変える設計変更は、障害処理の前提を丸ごと書き換えます。ユーザーが起点のセッションでは失敗は即座にユーザーへ返せますが、cronが起点のセッションでは誰も見ていない深夜3時に失敗が起きます。[Managed Agents](/glossary/managed-agents/)の**Scheduled Deployments**は、この「無人運用」を前提にした定期実行の仕組みを提供しています。本記事はcronの意味論・失敗記録・ライフサイクル制御・予算設計を公式ドキュメントのレベルで整理します。 ## Scheduled Deploymentsは何を解決するのか > Scheduled Deploymentsはエージェントがセッションを自律的に開始する仕組みで、Deployments APIで作成・管理します。 デプロイメントの作成には、[エージェント設定](https://platform.claude.com/docs/en/managed-agents/agent-setup)と[環境設定](https://platform.claude.com/docs/en/managed-agents/environments)が必須で、ファイル・GitHub・メモリストア・Vaultは任意で添付できます。制約が1つあり、自己ホスト環境はメモリストアを添付できますが、`file`と`github_repository`リソースはクラウド環境でしか使えません。さらに各セッションの最初の動作を指定する`user.message`または`user.define_outcome`のいずれかを初期イベントとして持たせる必要があります。これが無いと「何をすべきか」が定まらず起動できません。1組織あたり最大1,000件のスケジュールデプロイメントをサポートしています。 ## cronとタイムゾーンはどう解釈されるか > schedule はcron式とIANAタイムゾーンで構成され、分単位が最小粒度で、実行には最大15%のジッターが入ります。 `schedule`オブジェクトは標準POSIX cron式（`分 時 日 月 曜日`）とタイムゾーン識別子（例: `America/New_York`）を持ち、最小粒度は分単位です。重要なのは時刻の解釈方法で、cronはウォールクロック（壁掛け時計）照合のため、`"0 20 * * *"`はEST/EDTのどちらであっても現地時間20:00に発火します。この設計はサマータイム境界で2つの罠を生みます。春の時刻繰り上げで存在しない時刻（深夜2時台など）は発火せず、秋の時刻繰り戻しで2回出現する時刻は2回発火します。公式ドキュメントは、欠落や重複実行が許容できない処理は現地時間1〜3時台を避けるか、UTCでスケジュールするよう明記しています。加えて、実際の発火は負荷分散のため実行間隔の最大15%（最小5秒・最大9分）のジッターを含むため、`upcoming_runs_at`に表示される時刻と実際の実行時刻は厳密には一致しません。 ## 失敗はどう記録され、誰が気づくのか > 各試行は deployment run として記録され、セッションのライフサイクルとは独立に成功・失敗を追跡できます。 無人実行で最も重要なのは「失敗の可視化」です。Scheduled Deploymentsは、環境がアーカイブ済みだったりセッション作成がレート制限されたりして**トリガー自体に失敗した**場合も、**deployment run**という記録を必ず生成します。成功時はrunに`session_id`が入り、失敗時は`error.type`（`environment_archived_error`・`agent_archived_error`・`session_rate_limited_error`など）が入ります。`deployment_runs`エンドポイントは`has_error=true`でのフィルタに対応し、失敗だけを抽出して監視できます。 ライフサイクル管理も障害モード別に設計されています。レート制限は即座にrunを記録して次回スケジュールまで**リトライしません**。エージェントがアーカイブされると、デプロイメント自体が同じ操作で自動アーカイブされ、runは記録されません。エージェントが削除された場合は次回トリガー時に検知して自動アーカイブします。一方、サブエージェントのアーカイブや環境・Vaultのアーカイブのように復旧しうる障害は、失敗runを記録した上でデプロイメントを**自動pause**し、`paused_reason.error.type`に原因を残します。復旧後はunpauseで次回の予定時刻から再開しますが、停止中に欠けた実行は遡って補完されません。デプロイメントの状態変化とrunの結果は[webhookイベント](/blog/managed-agents-webhook-event-driven-design/)としても配信され、ポーリングなしで検知できます。 ## 予算と手動実行はどう組み込むか > budgetはセッション予算と同形式で、累積上限ではなく実行1回ごとの上限として各セッションにコピーされます。 デプロイメント作成・更新時に任意で`budget`オブジェクトを渡すと、その上限は実行ごとに新しいセッションへコピーされます。つまり1,000回実行されるデプロイメントの予算は、1,000回分の合計ではなく**毎回リセットされる個別キャップ**です。上限に達したセッションは通常のセッションと同じく`budget_reached`で一時停止し、既に走っているセッションは変更後も開始時のキャップを保持します。`budget: null`で予算設定自体を解除できる点は、通常のセッション予算にはない柔軟性です。 本番投入前のテストには`run`エンドポイントによる手動実行が使えます。これは`trigger_context.type: "manual"`のrunを即時生成するもので、[冪等性設計](/blog/agent-idempotency-at-least-once-design/)の確認や、[ant apply](/blog/managed-agents-ant-apply-infrastructure-as-code/)でデプロイしたスケジュールの初回動作確認に向いています。cronを信じて待つ前に、同じ実行経路を手動で1回通しておくことが、深夜の無人失敗を減らす最も安い対策です。 エンタープライズでMulti-tenant構成や複数エージェントの定期実行基盤を構築する際は、障害分離とpause/archiveの運用ルールを事前に決めておく必要があります。Kuuの[RDEサービス](/services/rde/)では、こうしたエージェント基盤の信頼性設計を支援しています。 ## 参考 - [Scheduled deployments | Claude Platform Docs](https://platform.claude.com/docs/en/managed-agents/scheduled-deployments) - [Webhooks | Claude Platform Docs](https://platform.claude.com/docs/en/managed-agents/webhooks) ## まとめ Scheduled Deploymentsの設計は3つの層に分けられます。**cronとタイムゾーン**はウォールクロック照合とジッターでDSTと負荷集中を吸収し、**deployment run**はトリガーの成否をセッションのライフサイクルと独立に記録し、**pause/archive**は障害の種類（一時的か恒久的か）に応じて自動で制御を切り替えます。無人で動くエージェントを安全に運用するには、この3層それぞれに監視とアラートを設計時点で組み込む必要があります。