1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Claude Managed Agents(ベータ)入門 ― エージェントループもサンドボックスも自前で作らない、マネージドなエージェント実行基盤 🤖

1
Posted at

はじめに 📝

Claude Managed Agents は、Anthropic が提供する「事前構築済みで設定可能なエージェントハーネスを、マネージドなインフラ上で動かす」仕組みです(現在ベータ)。

これまで Claude で自律エージェントを作るには、Messages API を使って「エージェントループ」「ツール実行」「サンドボックス」「会話履歴の保存」などを自前で組み立てる必要がありました。Managed Agents では、これらをまるごと Anthropic 側が用意してくれます。Claude はクラウド上の安全なサンドボックスで、ファイルを読み書きし、コマンドを実行し、Web を閲覧し、コードを動かせます。

この記事では、公式ドキュメントをもとに Managed Agents の全体像と主要な機能を解説します。

まずは雰囲気を掴むためのサンプルです 👇(CLI の ant を使った例)

# セッション(エージェントの実行インスタンス)を作成
ant beta:sessions create \
  --agent "$AGENT_ID" \
  --environment-id "$ENVIRONMENT_ID"

# ユーザーメッセージを送って作業を開始させる
ant beta:sessions:events send \
  --session-id "$SESSION_ID" <<'YAML'
events:
  - type: user.message
    content:
      - type: text
        text: List the files in the working directory.
YAML

Python SDK ならこうなります。

session = client.beta.sessions.create(
    agent=agent.id,
    environment_id=environment.id,
)

client.beta.sessions.events.send(
    session.id,
    events=[
        {
            "type": "user.message",
            "content": [
                {"type": "text", "text": "List the files in the working directory."}
            ],
        },
    ],
)

3行まとめ ✨

  • 🏗️ Managed Agents は エージェントループ・ツール実行・サンドボックス・状態管理 をまとめて提供するマネージド基盤。長時間・非同期タスク向け
  • 🧩 中心となる概念は Agent / Environment / Session / Events の4つ。これに Vault(認証情報)・Memory(永続メモリ)・Deployment(cron 実行)・Budget(予算上限)が加わる
  • 🔒 ネットワーク許可リスト、読み取り専用メモリ、送信時に差し込まれる認証情報など、プロンプトインジェクションを前提にした安全設計が用意されている

Messages API との違い 🤔

Messages API Claude Managed Agents
何か モデルへの直接プロンプトアクセス マネージドなインフラで動く、事前構築済み・設定可能なエージェントハーネス
向いている用途 独自のエージェントループ、きめ細かい制御 長時間タスク、非同期の作業

ハーネスにはプロンプトキャッシュやコンパクション(文脈の圧縮)などの最適化も組み込まれています。

こんなときに向いている 👍

  • ⏱️ 長時間実行:何分〜何時間もかかり、ツール呼び出しが何度も発生するタスク
  • ☁️ クラウドインフラ:パッケージ導入済み・ネットワークアクセス可能な安全なサンドボックス
  • 🏢 セルフホスト実行:コンプライアンスやデータ所在地の要件で、自社インフラ上のサンドボックスを使いたい
  • 🪶 インフラを最小限に:エージェントループ、サンドボックス、ツール実行層を自分で作りたくない
  • 💾 ステートフル:ファイルシステムや会話履歴を複数回のやり取りにまたがって保持したい
  • 📅 定期実行:cron スケジュールで繰り返し動かしたい(後述の Scheduled deployments)

コアコンセプト 🧩

概念 説明
Agent モデル、システムプロンプト、ツール、MCP サーバー、スキル
Environment セッションをどこで動かすかの設定。Anthropic 管理のクラウドサンドボックス、または自社インフラ上のセルフホストサンドボックス
Session Environment 内で動くエージェントのインスタンス。特定のタスクを実行し、成果物を生成する
Events アプリとエージェントの間でやり取りされるメッセージ(ユーザーのターン、ツール結果、ステータス更新など)

動作の流れ 🔄

  1. Agent を作成:モデル・システムプロンプト・ツール・MCP サーバー・スキルを定義。一度作れば ID で何度も参照できる
  2. Environment を作成:クラウドサンドボックス or セルフホストサンドボックスを設定
  3. Session を開始:Agent と Environment を参照してセッションを起動
  4. イベント送信とストリーミング:ユーザーメッセージをイベントとして送ると、Claude が自律的にツールを実行し、結果を SSE(Server-Sent Events)でストリーミング。イベント履歴はサーバー側に保存され、あとから全件取得できる
  5. 舵取り・中断:実行中に追加のユーザーイベントを送って方向修正したり、中断したりできる

組み込みツール 🛠️

  • Bash:サンドボックス内でシェルコマンドを実行
  • ファイル操作:read / write / edit / glob / grep
  • Web 検索・取得:許可リスト/ブロックリストでドメインを制限可能
  • MCP サーバー:外部のツールプロバイダーに接続

はじめ方 🚀

必要なもの

  1. Claude API キー
  2. すべてのリクエストに managed-agents-2026-04-01 ベータヘッダー(SDK は自動で付与、ant CLI も beta: 配下のコマンドで自動付与)
  3. Managed Agents へのアクセス(すべての API アカウントでデフォルト有効)

⚠️ Managed Agents はセッション履歴・サンドボックスの状態・成果物をサーバー側に保存するステートフルな設計のため、現時点では Zero Data Retention(ZDR)や HIPAA BAA の対象外です。セッションやアップロードしたファイルは API からいつでも削除できます。

Agent を定義する

ant apply を使うと、エージェントを Markdown ファイルで管理できます。フロントマターが設定、本文がシステムプロンプトです。

agents/summarizer.md
---
name: Summarizer
model: claude-opus-5-5
tools:
  - type: agent_toolset_20260401
---

You are a helpful assistant that writes concise summaries.
ant apply agents/summarizer.md

Environment:サンドボックスの設定 📦

Environment はエージェントが動くサンドボックスの設定です。一度作ればセッション作成時に ID で参照できます。複数のセッションで同じ Environment を共有しても、各セッションには独立したサンドボックス(新しい Linux コンテナ)が割り当てられ、ファイルシステムは共有されません。

environment.yaml
# yaml-language-server: $schema=https://platform.claude.com/schemas/ant/beta/environment.json
name: data-analysis
config:
  type: cloud
  packages:
    pip:
      - pandas
      - numpy
      - scikit-learn
    npm:
      - express
  networking:
    type: limited
    allow_package_managers: true

パッケージの事前インストール

packages で apt / cargo / gem / go / npm / pip のパッケージを事前に入れておけます。同じ Environment を使うセッション間でキャッシュされます。limited ネットワークで packages を指定する場合は allow_package_managers: true が必須です(ないと 400 エラー)。

ネットワーク 🌐

モード 説明
limited allowed_hosts のホストにのみ通信可能。allow_package_managers / allow_mcp_servers で追加の許可も可能。事前に列挙できないサイトに行く必要がない限りこちらを推奨
unrestricted 一般的な安全ブロックリストを除き、すべての外向き通信が可能
networking:
  type: limited
  allowed_hosts:
    - api.example.com
  allow_mcp_servers: true
  allow_package_managers: true

⚠️ 重要な注意点がいくつかあります。

  • API リクエストで networking を省略すると unrestricted になるので、明示的に指定しましょう(Console のフォームは Limited がデフォルト)
  • allowed_hosts はワイルドカード(*.example.com)も使えるが、example.com 自体にはマッチしない
  • limited のとき、allowed_hosts はサーバー側で動く web_search / web_fetch ツールにも適用される
  • 通信許可はホスト単位であって操作単位ではない。許可したホストには git push やパッケージ公開なども送れてしまうため、信頼できない入力を扱うなら bash ツールの権限ポリシーを always_ask や auto にすることも検討する

Environment はバージョン管理されないので、頻繁に変更する場合はどのセッションがどの設定で動いたか自分で記録しておくと安心です。

Session:エージェントを動かす ▶️

セッションは「Environment の中で動く Agent のインスタンス」で、複数回のやり取りにわたって会話履歴を保持します。ライフサイクルは「①セッション作成 → ②ユーザーイベント送信で作業開始」の2段階です。

バージョンを固定する

Agent はバージョン管理されたリソースです。ID を文字列で渡すと最新バージョン、オブジェクトで渡すと特定バージョンに固定できます。新バージョンの段階的なロールアウトに便利です。

ant beta:sessions create <<YAML
agent:
  type: agent
  id: $AGENT_ID
  version: 1
environment_id: $ENVIRONMENT_ID
YAML

作成と同時に作業を開始する(initial_events)

initial_events を渡すと、セッション作成と最初のメッセージ送信を1回のリクエストで行えます。セッションは最初から running 状態で作成されます(user.message と user.define_outcome のみ、最大50件)。

SEEDED_SESSION_ID=$(ant beta:sessions create \
  --transform id --raw-output <<YAML
agent: $AGENT_ID
environment_id: $ENVIRONMENT_ID
initial_events:
  - type: user.message
    content:
      - type: text
        text: List the files in the working directory.
YAML
)

セッション単位で設定を上書きする

type: agent_with_overrides を使うと、Agent のバージョンを作らずに、そのセッションだけモデルやシステムプロンプト、ツールなどを差し替えられます。上書きはマージではなく置き換えなので、tools を上書きする場合は必要なツールをすべて列挙します。

ant beta:sessions create <<YAML
agent:
  type: agent_with_overrides
  id: $AGENT_ID
  model:
    id: claude-sonnet-5-5
  system: null
environment_id: $ENVIRONMENT_ID
YAML

Vault:認証情報を安全に渡す 🔑

Vault は、サードパーティサービスの認証情報を一度登録しておき、セッション作成時に ID で参照するための仕組みです。自前でシークレットストアを運用したり、呼び出しのたびにトークンを送ったりする必要がなくなります。Vault はエンドユーザーごとの認証情報の集合として使え、「プロダクトは Agent 単位、ユーザーは Session 単位」で管理できます。

認証情報の種類

種類 用途
mcp_oauth OAuth 2.0 の MCP サーバー。refresh を渡せば Anthropic がトークンを自動更新
static_bearer 固定のベアラートークン(API キーや PAT)を受け付ける MCP サーバー
environment_variable CLI・SDK・直接の API 呼び出しなど、環境変数で認証するサービス

特に面白いのが environment_variable です。サンドボックス内の環境変数には不透明なプレースホルダーだけが入り、外向きリクエストの送信時(egress)に本物のシークレットに置き換えられます。エージェントは実際の値を一切見ません。

ant beta:vaults:credentials create --vault-id "$VAULT_ID" <<'YAML'
display_name: Notion API key for sandbox
auth:
  type: environment_variable
  secret_name: NOTION_API_KEY
  secret_value: ntn_your-secret-here
  injection_location:
    header: true
  networking:
    type: limited
    allowed_hosts: [api.notion.com]
YAML
  • networking.allowed_hosts:どのホスト宛てのリクエストでシークレットを差し込むか(Environment 側の許可も別途必要)
  • injection_location:リクエストのどこに差し込むか(ヘッダー / ボディ)。多くのサービスはヘッダーで足りるので、ヘッダーのみが安全

⚠️ 置き換えは送信時なので、起動時にキーの形式を検証するクライアントや、AWS SigV4 のようにシークレットから署名を計算するクライアントでは使えません。

セッションでは vault_ids で参照します。

ant beta:sessions create \
  --agent "$AGENT_ID" \
  --environment-id "$ENVIRONMENT_ID" \
  --vault-id "$VAULT_ID" \
  --title "Slack digest"

Vault は1つあたり最大20件の認証情報を持てます。認証情報のローテーションやアーカイブは、実行中のセッションにも再起動なしで反映されます。

Memory:セッションをまたぐ永続メモリ 💾

デフォルトでは、各セッションは毎回まっさらなコンテキストで始まります。メモリストアを使うと、ユーザーの好み、プロジェクトの規約、過去の失敗、ドメイン知識などをセッション間で引き継げます。

  • メモリストアはワークスペース単位のテキスト文書の集合
  • セッションにアタッチすると、サンドボックス内の /mnt/memory/<ストア名>/ にディレクトリとしてマウントされる
  • エージェントは普段のファイルツールで読み書きし、マウントの説明は自動でシステムプロンプトに追加される
  • メモリの変更ごとに不変のバージョンが作られ、監査や復元に使える
memory_store.yaml
# yaml-language-server: $schema=https://platform.claude.com/schemas/ant/beta/memory_store.json
name: User Preferences
description: Per-user preferences and project context.

セッション作成時に resources でアタッチします。

ant beta:sessions create <<YAML
agent: $agent_id
environment_id: $environment_id
resources:
  - type: memory_store
    memory_store_id: $store_id
    access: read_write
    instructions: User preferences and project context. Check before starting any task.
YAML

⚠️ access のデフォルトは read_write です。信頼できない入力を扱うエージェントがプロンプトインジェクションを受けると、悪意ある内容がメモリに書き込まれ、後続のセッションがそれを「信頼できる記憶」として読んでしまう恐れがあります。参照用の資料には read_only を使いましょう。

主な制限は次の通りです。

  • 1メモリあたり最大 100 kB(約25kトークン)、1ストアあたり最大 10,000 メモリ → 大きなファイル数個より、小さく焦点を絞ったファイルを多数に
  • 1セッションあたり最大 8 ストア
  • メモリストアはセッション作成時にしかアタッチできない
  • メモリストア API のベータヘッダーは agent-memory-2026-07-22(managed-agents-2026-04-01 と同時に送ると 400)

Scheduled deployments:cron で定期実行 📅

デプロイメントを使うと、エージェントが cron スケジュールで自律的にセッションを開始します。日次レポートや週次スキャンのような定期タスクにぴったりです。

deployment.md
---
name: Weekly compliance scan
agent: agent_011CYm1BLqPXpQRk5khsSXrs
environment_id: env_01595EKxaaTTGwwY3kyXdtbs
schedule:
  type: cron
  expression: "0 20 * * 5"
  timezone: America/New_York
---

Run the weekly compliance scan.
ant apply deployment.md
  • フロントマター下の本文が、各セッションを開始する user.message になる
  • cron は標準 POSIX 形式、タイムゾーンは IANA 形式。夏時間でも現地の壁時計時刻で動く(存在しない時刻はスキップ、2回ある時刻は2回実行されるので、深夜1〜3時は避けるのが無難)
  • 負荷分散のため、実際の実行には最大で実行間隔の15%(最小5秒・最大9分)のジッターが入る
  • 1組織あたり最大1,000デプロイメント

運用まわりのコマンドです。

ant beta:deployments run --deployment-id "$DEPLOYMENT_ID"                   # 手動実行(テストに便利)
ant beta:deployments pause --deployment-id "$DEPLOYMENT_ID"                 # 一時停止
ant beta:deployments unpause --deployment-id "$DEPLOYMENT_ID"               # 再開(取りこぼし分は実行されない)
ant beta:deployment-runs list --deployment-id "$DEPLOYMENT_ID" --has-error  # 失敗した実行の一覧

実行の試行ごとにデプロイメントランが記録され、成功なら session_id、失敗なら error(environment_archived_error など)が残ります。Environment や Vault がアーカイブされているなど回復不能なエラーでは、デプロイメントが自動で一時停止されます。

Budget:支出の上限 💰

セッションにはハードな支出上限を設定できます。セッションが消費したものを公開の定価(list price)で計算し、上限に達すると新しいモデルリクエストを出さなくなります。

# 金額はセント単位の「文字列」。"125" は $1.25
ant beta:sessions create \
  --agent "$AGENT_ID" \
  --environment-id "$ENVIRONMENT_ID" \
  --budget '{type: limit, max_list_cost: {amount: "125", currency: USD}}'

定価計算の対象(list cost)は次の通りです。

  • モデルのトークン:各モデルの定価
  • Web 検索:1,000回あたり $10
  • セッションの実行時間:1時間あたり $0.08

ポイントは以下です。

  • 上限チェックはモデルリクエストの間で行われるため、上限を超えたリクエストは完了まで走る → 最終的な list cost は上限を少しだけ超えることがある(想定内の挙動)
  • 上限に達したセッションは終了ではなく、stop_reason: budget_reached で idle(一時停止) になる。履歴もサンドボックスも残る
  • 予算を引き上げる/削除すると、自動で作業が再開する
  • 予算はセッション作成時にしか付けられない(後から追加は不可、削除すると再設定も不可)
  • デプロイメントに設定した予算は「1回の実行ごと」の上限として各セッションにコピーされる(累計の上限ではない)
  • 交渉済みの割引がある場合でも、判定は定価ベースで行われる

実例:デイリーブリーフエージェント 🗞️

Claude 公式ブログの「Building effective agent automations」では、ここまでの機能を組み合わせて「Slack と GitHub を読んで毎朝要点を Slack に投稿する」エージェントを作っています。

機能 使われ方
Agent agent.md にモデル・GitHub MCP サーバー・実行手順を定義(Web 検索/取得は無効化)
Environment ネットワーク許可リストで通信先を限定
Vault Slack トークンを environment_variable で登録し、slack.com 宛てだけに差し込み
Memory preferences(読み取り専用)と state(読み書き:ブックマーク・台帳・実行記録)の2ストア
Deployment 平日朝に cron 実行、読み手のタイムゾーンで日付を計算
Budget 通常実行コストの3〜5倍で上限を設定し、実測値で絞り込む
budget:
  type: limit
  max_list_cost:
    amount: "500" # a string, in cents: "500" is $5.00
    currency: USD

リファレンス実装は anthropics/claude-quickstarts の daily-brief で公開されています。

まとめ 🎯

  • Claude Managed Agents は、エージェントループ・ツール実行・サンドボックス・状態保存をまとめて提供するマネージドなエージェント実行基盤(ベータ)
  • Agent / Environment / Session / Events の4概念を押さえれば、基本的な使い方はシンプル
  • Vault(送信時に差し込まれる認証情報)、Memory(バージョン付きの永続メモリ)、Deployment(cron 実行)、Budget(定価ベースのハードな上限)で、本番運用に必要な要素が揃っている
  • limited ネットワーク、read_only メモリ、ヘッダー限定の認証情報差し込みなど、最小権限で組むのが安全に使うコツ

まずは ant CLI をインストールして、agents/ と environments/ にファイルを置き、ant apply . → ant beta:sessions create で最初のセッションを動かしてみるのがおすすめです 🚀

参考リンク 🔗

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?