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

マネージドエージェント

上級
What you'll learn
  • マネージド (Anthropic ホスト型) のエージェントループが何を肩代わりしてくれるのかを理解する
  • 2つのコアオブジェクトを区別する: バージョン管理された Agent と、実行ごとの Session
  • Vault でシークレットを安全に注入する — モデルにそれを一切見せることなく
  • Scheduled Deployments でエージェントを cron スケジュールに乗せる — ホストすべきスケジューラは不要
  • マネージドがカスタムループに勝るのはどんなときか、そして依然として適用されるガードレールを知る

独自のエージェントループを構築することが、自分で所有したいインフラ以上のものになってしまう場合、マネージド (Anthropic ホスト型) のエージェントがループを代わりに実行してくれます。これにより、セッションの配線、リトライ、状態管理、スケジューリングではなく、エージェントの仕事そのものに集中できます。

2つのオブジェクト: Agent と Session​

これが、他のすべてが結びつくメンタルモデルです。両者は意図的に分離されています。

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

Session は、作成時に使われたエージェントのバージョンにピン留めされます: 実行中のセッションは自分のバージョンを保持し、新しいセッションは最新を取得します。これが、進行中の作業を壊すことなく構成変更をリリースする方法です。

「マネージド」が得られるもの​

ループを手作業で組み立ててホストする代わりに、ホスト型のビルディングブロックが手に入ります:

  • Sessions — 実行ごとに作成して再開できる永続的な実行。SSE 上でイベントをストリーミングします。
  • Environments — コンテナインフラ。cloud (Anthropic ホスト型) または self_hosted (ツールが自分の VPC 内で実行される) のいずれか。セッションごとに1つのコンテナがエージェントのワークスペースになります。
  • Memory stores — セッションをまたぐ永続的な状態。バージョン管理と編集 (リダクション) を備え、データベースを自分で配線する必要はありません。
  • 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 上のエージェント​

deployment は、エージェントに cron スケジュールを取り付けます。スケジュールが発火すると、新しいセッションを開始してタスクを完了します — あなたが構築・ホストすべきスケジューラはありません。夜間のデータ同期、週次のコンプライアンススキャン、日次のダイジェストに最適です。

Guided walkthrough1 of 4
  1. POST /v1/deployments に agent、environment_id、initial_events (user.message を含む必要があります)、そして schedule を渡します: 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 は壁時計のセマンティクスを使います: 春の繰り上げ (spring-forward) で存在しない時刻はスキップされ、秋の繰り下げ (fall-back) で2回発生する時刻は2回発火します。重要なものについては、これらの境界を避けるタイムゾーンと時刻を選んでください。

マネージドとカスタムのどちらを選ぶか​

マネージド を選ぶのは…カスタムループ / SDK を選ぶのは…
ホスティング、状態、スケジューリング、シークレットを任せたいときループとツールを完全に制御する必要があるとき
素早くプロトタイピングしているとき厳格なカスタムインフラ/コンプライアンス要件があるとき
制御よりも運用のシンプルさが重要なとき自分のスタックに深く埋め込んでいるとき

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

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

ホスト型であろうとなかろうと、自律エージェントは依然としてアクションを実行します。最小権限、コスト/反復回数の制限、そしてリスクのあるステップには人間の承認を維持してください — エージェントのセキュリティ確保と自律実行のハードニングを参照してください。

Key takeaways
  • マネージドエージェントは、ループ、セッション、環境、メモリ、Vault、スケジューリングを肩代わりしてくれるので、あなたは仕事そのものに集中できる
  • Agent はバージョン管理された構成、Session はバージョンにピン留めされる1回の実行 — 構成はエージェント側に存在し、セッション側には存在しない
  • Vault の environment_variable クレデンシャルは実行時に注入され、モデルからは決して見えない — エージェントにシークレットを与える安全な方法
  • scheduled deployment は cron 式 + IANA タイムゾーンであり、各発火が1回の実行を作成し、unpause は見逃したトリガーをバックフィルしない
  • マネージドは「単一呼び出し → ワークフロー → カスタム → マネージド」のホスト型の端に位置する。自律性のガードレールは依然として適用される

理解度チェック​

理解度チェック

0/3
  1. Agent と Session の違いは何ですか?
  2. マネージドエージェントに必要な API キーを、どのように与えるべきですか?
  3. scheduled deployment が2日間一時停止され、その後 unpause されました。一時停止中に発火していたはずのトリガーはどうなりますか?

次へ​