AIエージェントを「呼ばれたら動く」ものから「自分で動き出す」ものに変える設計変更は、障害処理の前提を丸ごと書き換えます。ユーザーが起点のセッションでは失敗は即座にユーザーへ返せますが、cronが起点のセッションでは誰も見ていない深夜3時に失敗が起きます。Managed AgentsのScheduled Deploymentsは、この「無人運用」を前提にした定期実行の仕組みを提供しています。本記事はcronの意味論・失敗記録・ライフサイクル制御・予算設計を公式ドキュメントのレベルで整理します。
Scheduled Deploymentsは何を解決するのか
Scheduled Deploymentsはエージェントがセッションを自律的に開始する仕組みで、Deployments APIで作成・管理します。
デプロイメントの作成には、エージェント設定と環境設定が必須で、ファイル・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イベントとしても配信され、ポーリングなしで検知できます。
予算と手動実行はどう組み込むか
budgetはセッション予算と同形式で、累積上限ではなく実行1回ごとの上限として各セッションにコピーされます。
デプロイメント作成・更新時に任意でbudgetオブジェクトを渡すと、その上限は実行ごとに新しいセッションへコピーされます。つまり1,000回実行されるデプロイメントの予算は、1,000回分の合計ではなく毎回リセットされる個別キャップです。上限に達したセッションは通常のセッションと同じくbudget_reachedで一時停止し、既に走っているセッションは変更後も開始時のキャップを保持します。budget: nullで予算設定自体を解除できる点は、通常のセッション予算にはない柔軟性です。
本番投入前のテストにはrunエンドポイントによる手動実行が使えます。これはtrigger_context.type: "manual"のrunを即時生成するもので、冪等性設計の確認や、ant applyでデプロイしたスケジュールの初回動作確認に向いています。cronを信じて待つ前に、同じ実行経路を手動で1回通しておくことが、深夜の無人失敗を減らす最も安い対策です。
エンタープライズでMulti-tenant構成や複数エージェントの定期実行基盤を構築する際は、障害分離とpause/archiveの運用ルールを事前に決めておく必要があります。KuuのRDEサービスでは、こうしたエージェント基盤の信頼性設計を支援しています。
参考
まとめ
Scheduled Deploymentsの設計は3つの層に分けられます。cronとタイムゾーンはウォールクロック照合とジッターでDSTと負荷集中を吸収し、deployment runはトリガーの成否をセッションのライフサイクルと独立に記録し、pause/archiveは障害の種類（一時的か恒久的か）に応じて自動で制御を切り替えます。無人で動くエージェントを安全に運用するには、この3層それぞれに監視とアラートを設計時点で組み込む必要があります。