メインコンテンツまでスキップ

Managed Agents

上級
What you'll learn
  • managed（Anthropic ホスト型）エージェントループが何を代行するかを理解する
  • 2つのコアオブジェクトを区別する：バージョニングされた Agent vs 実行単位の Session
  • Vault で秘密情報を安全に注入する — モデルがそれを目にすることなく
  • Scheduled Deployments で cron スケジュールにエージェントを乗せる — 自分でホストするスケジューラは不要
  • managed がカスタムループに勝る場面、そして依然として適用されるガードレールを知る

自分でエージェントループを構築する のが所有したいインフラを超えるなら、managed（Anthropic ホスト型）エージェントがループを代行してくれます — そうすればあなたはエージェントの 仕事 に集中でき、セッション配管、リトライ、状態、スケジューリングに悩まされません。

2つのオブジェクト：Agent vs Session​

これがすべての基礎となるメンタルモデルです。両者は意図的に分離されています。

  • Agent は 永続化された、バージョニングされた構成 — モデル、システムプロンプト、ツール、MCP サーバー、スキル。一度作成します。すべての更新は新しいイミュータブルなバージョンを作成します。
  • Session は 実行時インスタンス — エージェントを ID で指す1回の実行。構成はエージェントに存在し、セッションには存在しません。
Pro tip

Session は作成時のエージェントバージョンにピン留めされます：実行中のセッションはそのバージョンを保ち、新しいセッションは最新版を得ます。これが in-flight の作業を壊さずに構成変更を出荷する方法です。

「managed」で得られるもの​

ループを自作してホストする代わりに、ホスト型のビルディングブロックが得られます：

  • Sessions — 実行ごとに作成して再開する永続的な実行。SSE でイベントをストリーム。
  • Environments — コンテナインフラ。cloud（Anthropic ホスト）または self_hosted（ツールは自身の VPC で実行）。セッションごとに1つのコンテナがエージェントのワークスペースになります。
  • Memory stores — セッションを越えて永続する状態。サンドボックス内にディレクトリとしてマウントされ、イミュータブルなバージョニングと redact エンドポイントを備えます。あなた側にデータベースは不要です。
  • Vaults — MCP 認証や他のサービス用のシークレット。
  • Scheduled deployments — cron スケジュールで無人実行されるエージェント。

エージェント（バージョニングされた構成）を作成し、それに対してセッションを実行する

# 1. Create the agent once
POST /v1/agents        -> returns $AGENT_ID
# 2. Each execution is a session pinned to that agent
POST /v1/sessions      { "agent": "$AGENT_ID" }

Vault：モデルが見ないシークレット​

自律的なエージェントはしばしば API キーを必要とします — しかし モデル がそれを読むべきではありません。Vault の資格情報（mcp_oauth、static_bearer、environment_variable）は egress で置換されます：environment_variable の資格情報は実行時にサンドボックスに注入され、モデルからは決して見えません。

Watch out

これがエージェントに強力なアクセスを与える安全なパターンです。システムプロンプトやメッセージにキーを貼り付けないでください — モデル（およびログ）が見られるコンテキストの一部になります。Vault に入れましょう。

Scheduled deployments：cron で動くエージェント​

デプロイメントは cron スケジュールをエージェントにアタッチします。スケジュールが発火すると、真新しいセッションを開始してタスクを完了します — 自分で構築したりホストしたりするスケジューラは不要です。夜間のデータ同期、週次のコンプライアンススキャン、日次のダイジェストなどに最適です。

Guided walkthrough1 of 4
  1. POST /v1/deployments に agent、environment_id、initial_events（user.message を含む必要あり）、および schedule：POSIX cron 式と IANA タイムゾーンを渡す。

週次コンプライアンススキャン、金曜20:00 ニューヨーク時間

POST /v1/deployments
{
"name": "Weekly compliance scan",
"agent": "$AGENT_ID",
"environment_id": "$ENVIRONMENT_ID",
"initial_events": [
  {"type": "user.message", "content": [{"type": "text", "text": "Run the compliance scan and summarize findings."}]}
],
"schedule": {"type": "cron", "expression": "0 20 * * 5", "timezone": "America/New_York"}
}
Pro tip

Cron は minute hour day-of-month month day-of-week で、分単位の粒度です。DST は壁時計セマンティクスを使います：春の前進で存在しない時刻はスキップされ、秋の後退で2回発生する時刻は2回発火します。センシティブなものについては、これらのエッジを避けるタイムゾーンと時刻を選んでください。

managed vs custom の選択​

managed を選ぶのは…カスタムループ / SDK を選ぶのは…
ホスティング、状態、スケジューリング、シークレットを代行してほしいループとツールを完全に制御したい
素早くプロトタイピングしている厳格なカスタムインフラ / コンプライアンス要件がある
制御より運用のシンプルさが重要独自スタックに深く組み込んでいる

これはスペクトルです — 単一呼び出し → ワークフロー → カスタムエージェント（SDK） → managed。タスクが許す限りシンプルに始め、必要になったときだけ上に移動してください。

同じガードレールが適用される​

ホスト型かどうかにかかわらず、自律的なエージェントは依然としてアクションを取ります。最小権限、コスト / イテレーションの上限、リスクのあるステップでの人間の承認を維持してください — Securing Agents と Hardening Autonomous Runs を参照してください。

Key takeaways
  • Managed agents はループ、セッション、環境、メモリ、Vault、スケジューリングを代行してくれるので、あなたは仕事に集中できる
  • Agent はバージョニングされた構成、Session はバージョンにピン留めされる1つの実行 — 構成はエージェントに存在し、セッションには存在しない
  • Vault の environment_variable 資格情報は実行時に注入され、モデルからは決して見えない — エージェントにシークレットを与える安全な方法
  • スケジュールされたデプロイメントは cron 式 + IANA タイムゾーン。各発火は run を作成し、unpause は逃したトリガーをバックフィルしない
  • Managed は 単一呼び出し → ワークフロー → カスタム → managed のホスト型の端にある。自律性のガードレールは依然として適用される

自分でチェック​

Check yourself

0/3
  1. Agent と Session の違いは何ですか？
  2. managed エージェントに必要な API キーをどのように与えるべきですか？
  3. スケジュールされたデプロイメントが2日間一時停止された後、再開されました。一時停止中に発火するはずだったトリガーはどうなりますか？

次へ​