こんにちは。AIあれこれ散歩道、運営者のHARUKAです。
Claudeで毎朝のレポート作成や週次点検を自動化したい時に見かけるのが、Claude Managed Agentsのscheduled deploymentです。ただ、通常のClaudeアプリにある簡単な予約機能だと思って探すと、入口が見つからず迷ってしまいますよね。
Claude Managed Agents設定は、Claude API上でエージェントと実行環境を用意し、初期イベントとcronを含むdeploymentを作る開発者向けの仕組みです。2026年8月時点ではpublic betaで、APIキーとベータヘッダーが必要です。この記事では、最小構成、日本時間、実行履歴、失敗、Vaultで秘密情報を扱う時の考え方までつなげて説明します。
- Managed Agentsと通常のClaudeの違い
- 定期実行に必要な四つの設定
- cronと日本時間を間違えない方法
- 失敗確認と秘密情報の安全な扱い
Claude Managed Agents設定基本
定期実行を作る前に、agent、environment、session、deploymentの役割を分けます。名前は少し難しく見えますが、「誰が」「どこで」「何を」「いつ行うか」に置き換えると分かりやすいです。最初から本番連携を詰め込まず、手動実行で成功する小さな作業から始めましょう。
Claude Managed Agents設定要点
Claude Managed Agentsは、長時間実行や非同期処理向けに、Anthropicが管理するエージェント基盤です。モデルへの一回の質問だけでなく、ファイルの読み書き、コマンド実行、Webの確認、MCP接続などを組み合わせ、複数段階の作業を進められます。
scheduled deploymentを使うと、指定したcronの時刻に新しいsessionが始まり、与えた初期イベントを起点に作業します。自分でcronサーバーや常時起動のスケジューラーを持たずに済むのが特徴です。夜間のデータ同期、週次のコンプライアンス確認、毎日の要約などが公式の用途例として挙げられています。
ただし、これはClaude.aiのチャット画面へ「明日9時に実行して」と頼む機能ではありません。Claude API、エージェント設定、実行環境、Deployments APIを扱います。APIを使わない人が個人の予定を登録する目的なら、別のカレンダーや自動化機能を選ぶほうが簡単です。
最短理解：agentが担当者、environmentが作業場所、initial eventが依頼書、scheduleが時計、deployment runが実行記録です。
Claude Managed Agents設定準備
2026年8月6日時点で、Claude Managed Agentsはpublic betaです。利用にはClaude APIキー、Managed Agentsへのアクセス、すべてのリクエストで`managed-agents-2026-04-01`ベータヘッダーが必要です。公式SDKはベータヘッダーを自動設定しますが、直接HTTPを送る実装では付け忘れに注意してください。
最初に、実行したい作業を一文で決めます。「毎週金曜にレポートを作る」だけでなく、「どの入力を読み、何を成果物にし、どこまでを成功とするか」を書きます。終了条件が曖昧だと、エージェントが調査を続け、費用と確認時間が増えます。
次にagentを作り、モデル、システム指示、使えるツール、MCPサーバー、必要なスキルを設定します。environmentでは、Anthropic管理のクラウドsandboxか、自分で管理する環境を選びます。機密性、ネットワーク許可、必要パッケージ、データの保存先をここで確認します。
本番の定期実行前に、同じagentとenvironmentで一度sessionを手動起動してください。入力ファイルを読めるか、コマンドが通るか、成果物が期待した場所へ出るかを確認します。スケジュールの問題と作業内容の問題を同時に調べるより、切り分けが早くなります。
AIエージェントの権限管理で、最小権限と承認境界も先に決めておくと安全です。
Claude Managed Agents設定作成
scheduled deploymentには、agent、environment、少なくとも一件のinitial event、scheduleが必要です。必要に応じてファイル、GitHub連携、memory store、Vaultも追加できます。initial eventは`user.message`または`user.define_outcome`で、そのsessionが何を始めるかを伝えます。
次の例は、毎週金曜日の20時に点検を始める考え方を示した最小イメージです。実際には先に作成したagent IDとenvironment IDを使い、組織の環境に合わせて名前と依頼文を変えてください。
name: Weekly compliance scan
agent: YOUR_AGENT_ID
environment_id: YOUR_ENVIRONMENT_ID
initial_events:
- type: user.message
content:
- type: text
text: Run the weekly compliance scan.
schedule:
type: cron
expression: "0 20 * * 5"
timezone: Asia/Tokyo作成レスポンスでは、deploymentのstatusと`schedule.upcoming_runs_at`を確認します。APIが成功を返しただけで安心せず、次回予定が意図した日時になっているかを見てください。曜日、タイムゾーン、日付がずれていれば、実行前にcronを修正できます。
本番データを変更する作業では、最初のdeploymentを読み取り専用にします。例えば「差分を調べて報告する」までに止め、削除、送信、公開は人が承認してから行う設計です。予定通り起動することを確認してから、必要な権限を一つずつ追加しましょう。
Claude Managed Agents設定定期
scheduleのexpressionは、標準POSIX cronの五つの欄を使います。順番は「分、時、日、月、曜日」です。`0 20 * * 5`なら、指定したタイムゾーンで毎週金曜日の20時を表します。秒の欄はなく、設定できる最大の細かさは1分です。
よく使う例として、`0 9 * * *`は毎日9時、`30 8 * * 1-5`は平日の8時30分、`0 10 1 * *`は毎月1日の10時です。曜日や月末の扱いを自己流で推測せず、Claude Consoleのcron生成・検証や、運用チームの検証方法で次回時刻を確かめてください。
| 目的 | cron | timezone |
|---|---|---|
| 毎日9時 | 0 9 * * * | Asia/Tokyo |
| 平日8時30分 | 30 8 * * 1-5 | Asia/Tokyo |
| 毎週月曜10時 | 0 10 * * 1 | Asia/Tokyo |
| 毎月1日10時 | 0 10 1 * * | Asia/Tokyo |
設定した時刻ぴったりに開始するとは限りません。Anthropic公式では、負荷分散のため実行間隔の最大15%のジッターが入り、最小5秒、最大9分と説明されています。9時の処理が9時数分に始まる可能性を見込み、厳密な締切の直前には置かないほうが安全です。
cronの確認順：五つの欄、曜日、timezone、upcoming runs、ジッターの順に見ます。ジョブ名だけに「JST」と書いても、timezone設定の代わりにはなりません。
Claude Managed Agents設定時刻
日本時間で実行するなら、timezoneへ`Asia/Tokyo`を指定します。UTCへ変換した時刻をcronへ直接入れる方法もありますが、運用担当が見た時に意図を読み取りにくくなります。特別な理由がなければ、現地時刻とIANAタイムゾーンを一緒に指定するほうが扱いやすいです。
IANAタイムゾーンは`JST`や`Tokyo`のような略記ではなく、`Asia/Tokyo`の形式です。米国のようにサマータイムがある地域では、壁時計の時刻を基準に動きます。例えば現地20時を指定すれば、標準時間でも夏時間でも現地20時に発火します。
ただし、サマータイム開始日に存在しない時刻は実行されず、終了日に二回現れる時刻は二回発火します。欠落や重複が許されない処理は、現地の午前1時から3時を避けるか、UTC基準で設計するよう公式ドキュメントが案内しています。日本だけで動かす場合も、外部システムの締切がUTCか現地時間かを確認してください。
deploymentを作ったら、`upcoming_runs_at`の先頭三件を人が読みます。毎日なのに一週間間隔、月曜のつもりが日曜、午前と午後が逆なら、まだ安全に直せます。時刻のテストは、実行後のログを見るより作成直後の予定を見るほうが早いですよ。
Claude Managed Agents設定運用
定期実行は、作成できた時点では半分です。実際に発火したか、sessionが始まったか、成果物が完成したかを別々に見ます。失敗の記録、Vault、Pause、Archiveを理解しておくと、止めたい時に迷わず対応できます。
Claude Managed Agents設定確認
scheduled deploymentが時刻を迎えると、トリガーを試すたびにdeployment runが作られます。成功したrunには`session_id`が入り、そこからsessionのイベントと最終結果を追えます。つまり、runは「起動の記録」、sessionは「実際の作業」と考えます。
最初にrunの有無を確認し、次にerror、session_id、作成時刻を見ます。runが成功でも、session内のツール呼び出しや成果物作成が失敗することはあります。業務上の完了条件まで自動監視したいなら、sessionのイベントストリームまたはWebhookで結果を受け取ります。
定期実行の確認項目は、開始、完了、成果物、通知の四つです。例えばレポート作成なら、sessionが始まった、成功状態になった、ファイルが正しい場所へ出た、担当者へ通知された、まで確かめます。どれか一つだけでは「自動化できた」と判断しません。
Webhookを使う時は、同じイベントが再送されても一度だけ処理できる仕組みにします。実行IDを保存し、すでに通知済みなら重複送信を避ける方法です。夜間処理の失敗通知が何十通も届く事故を防げます。
Claude Managed Agents設定失敗
deploymentは、environmentやagentがArchiveされている、session作成がレート制限された、といった理由で起動に失敗します。失敗したrunにはerror typeが入り、`environment_archived_error`、`agent_archived_error`、`session_rate_limited_error`などで原因を分けられます。
エラーを見たら、同じrunを無計画に再試行しないでください。Archiveされたresourceなら有効なIDへ直し、レート制限なら許可された待機時間と同時実行数を確認します。認証やネットワークの問題なら、Vault、許可ドメイン、外部サービスの状態を調べます。
手動runが成功しscheduled runだけ失敗する場合は、時刻、deployment status、Pause、同時実行を見ます。両方失敗するなら、agent、environment、initial event、ツール権限など共通部分の可能性が高くなります。切り分けのため、同じ入力を使うことも重要です。
障害対応では、入力データを消したり権限を広げたりする前に、deployment ID、run ID、session ID、error type、発生時刻を保存します。これらがあれば、どの段階で止まったかを追いやすくなります。秘密情報そのものをログへ出さないことも忘れないでください。
注意：自動再試行は便利ですが、外部送信や更新を行うagentでは二重実行につながります。処理済みIDの確認や、同じ入力を一度だけ反映する設計を入れてください。
Claude Managed Agents設定秘密
APIキーや外部サービスの認証情報を、system prompt、initial event、リポジトリへ直接書かないでください。Claude Managed AgentsのVaultは、秘密情報を環境変数として使わせながら、モデルへ実際の値を見せない仕組みです。
Vaultへは、環境変数名、値、通信を許可するドメインを登録します。sandbox内では実値ではなくplaceholderが使われ、許可したドメインへリクエストを送るネットワーク境界で実値が付与されます。これにより、agentの出力やプロンプトへキーがそのまま現れる可能性を抑えられます。
ただし、Vaultへ入れれば何でも安全という意味ではありません。許可ドメインを広くしすぎる、同じキーへ過大な権限を付ける、成果物や外部APIの応答に機密情報が含まれる、といった問題は別に残ります。読み取り専用キー、対象APIだけの権限、短い有効期限を検討してください。
キーを交換する時はVaultを更新します。実行中sessionは次の呼び出しから新しい値を使う仕組みが説明されていますが、外部サービス側の失効時刻と合わせて確認しましょう。緊急ローテーションでは、旧キーを止める前に新キーの接続テストを小さなsessionで行います。
Managed Agentsはステートフルで、会話履歴、sandbox状態、出力をサーバー側へ保存します。2026年8月時点ではZero Data RetentionとHIPAA BAAの対象外です。医療情報や厳しい保持要件があるデータを扱う前に、組織の法務・セキュリティ担当と適格性を確認してください。
関連するClaude製品の変化を追う場合は、Claude Fable 5の使い方も参考になります。
Claude Managed Agents設定停止
定期実行を一時的に止めるならPauseを使います。Pauseは今後のscheduled triggerを抑えますが、すでに始まっているsessionは止めません。また、Pause中でも手動runは許可されます。「Pauseしたから今動いている処理も止まった」と思い込まないでください。
実行中sessionを止めたい場合は、session側で中断する操作が必要です。定期スケジュールを止める操作と、現在の作業を止める操作は別です。外部更新が始まっている時は、途中停止でデータが半端にならないよう、現在の工程を確認してから判断します。
長期間使わないdeploymentはArchiveを検討します。Archive後に同じ設定を戻せるか、履歴をどのくらい残すか、参照しているagentやenvironmentを別のdeploymentが使っていないかを確かめてください。共有resourceを先にArchiveすると、ほかの定期実行まで失敗することがあります。
停止手順を運用メモへ残す時は、deployment名だけでなくID、担当者、外部接続、実行中sessionの確認方法、再開条件を記録します。担当者が不在でも安全に止められる状態が、定期実行ではとても大切です。
ローカルのCodex作業環境と比較したい場合は、CodexをWindowsにインストールする方法も確認できます。クラウド定期実行とローカル作業では、権限や保存場所が違います。
Claude Managed Agents設定疑問
Q1. 通常のClaudeアプリから予約できますか？
A. この記事のscheduled deploymentはClaude APIのManaged Agents向けです。通常チャットの会話予約とは別で、agent、environment、initial event、Deployments APIを使います。
Q2. 日本時間の毎朝9時はどう設定しますか？
A. cronを`0 9 * * *`、timezoneを`Asia/Tokyo`にします。作成後は`upcoming_runs_at`を確認し、最大9分のジッターも見込んでください。
Q3. Pauseで実行中の作業も止まりますか？
A. 止まりません。Pauseは今後のscheduled triggerを抑える操作です。すでに動いているsessionは、session側で状態を確認し、必要に応じて中断します。
Q4. APIキーを指示文へ書いてもよいですか？
A. 書かないでください。Vaultへ登録し、環境変数名と許可ドメインを設定します。キー自体の権限も最小限にし、ログや成果物へ値が出ていないか確認します。
Claude Managed Agents設定要約
Claude Managed Agents設定で定期実行を作るには、agent、environment、initial event、cron scheduleが必要です。2026年8月時点ではpublic betaで、APIキーと`managed-agents-2026-04-01`ベータヘッダーを使います。通常のClaudeチャットとは別の開発者向け機能です。
日本時間ならtimezoneを`Asia/Tokyo`にし、作成レスポンスの`upcoming_runs_at`で次回予定を確認します。cronの最大粒度は1分ですが、実際の開始には最小5秒、最大9分のジッターが入ります。厳密な締切の直前ではなく、余裕を持たせてください。
運用では、deployment runとsessionを分けて見ます。runが成功しても、成果物まで完成したとは限りません。error type、session_id、成果物、通知を確認し、外部更新では二重実行を防ぐID管理を加えましょう。
最初は読み取り専用の小さな作業を手動実行し、その後に定期化するのが安全です。秘密情報はVaultへ置き、権限と許可ドメインを絞ります。Pauseは今後のtriggerだけを止めるため、実行中sessionの確認も忘れないでください。
開始前チェック：手動session成功、次回時刻、ジッター、成果物、失敗通知、Vault、二重実行防止の七点を確認してから本番へ進めます。
Managed Agentsの提供条件、API、料金、データ保持はベータ期間中に変わる可能性があります。正確な情報はAnthropic公式のscheduled deploymentsとManaged Agents概要をご確認ください。機密データや法的要件に関する最終的な判断は、管理者や専門家にご相談ください。
