AnthropicはClaude Managed Agentsの本番運用機能を拡張した。

セッション作成時に、公開済みAgentのモデル、System Prompt、Tools、MCP Servers、Skillsを一時的に上書きできる。Vaultの環境変数資格情報は、外部リクエストのHeader、Body、または両方へ注入する場所を設定できる。WebhookはSessionやVaultだけでなく、Agent、Deployment、Deployment Runのライフサイクルも通知する。

これらは運用の柔軟性を高める一方、Agent Versionだけを記録しても「実際に何が実行されたか」を再現できなくなることを意味する。

追加された主要機能

セッション単位のAgent上書き

セッション作成時にagent_with_overridesを指定し、基礎となるAgent IDとVersionに対して一部設定を上書きできる。

対象には次が含まれる。

  • Model
  • System Prompt
  • Tools
  • MCP Servers
  • Skills

Overrideはそのセッションだけへ適用され、Agent Resource自体を変更せず、新しいAgent Versionも作らない。レスポンスにはOverride適用後の解決済みAgent設定が含まれる。

Vaultの資格情報注入位置

環境変数Credentialではinjection_locationを設定し、秘密値を外向きリクエストの次の場所へ注入できる。

  • Header
  • Body
  • HeaderとBodyの両方

注入位置を変更すると、実行中Sessionでも再起動せず、以後の外向きリクエストへ反映される。

Webhookの対象拡大

Webhookは次の大きな状態変更を通知する。

  • Session
  • Vault
  • Agent
  • Deployment
  • Deployment Run

Webhook Payloadは完全なResourceではなく、Event TypeとIDを返す。受信後にGETで最新Resourceを取得する設計である。

Event Deltaと定期実行

Session Event Streamでは、完成したAgent Messageより前にevent_startとevent_deltaで生成途中を取得できる。Managed AgentsはCronによるScheduled Deploymentにも対応している。

柔軟性が再現性を壊す

従来、次の記録があれば実行を説明できると考えられた。

agent_id: agent_123
version: 7
session_id: sess_456

しかしSession Overrideがある場合、Version 7の定義と実際の実行設定が異なる。

Agent v7
  model: claude-sonnet-4-6
  tools: [search]

Session Override
  model: claude-sonnet-5
  system: null
  tools: [search, payment-refund]

この実行をAgent v7として監査すると、実際に使用されたモデル、指示、権限を誤認する。

Resolved Run Manifestを保存する

各SessionまたはDeployment Runについて、解決済みの実行設定を保存する。

{
  "run_id": "run_123",
  "session_id": "sess_456",
  "base_agent_id": "agent_123",
  "base_agent_version": 7,
  "resolved_model": "claude-sonnet-5",
  "resolved_system_sha": "...",
  "resolved_tools": ["search", "payment-refund"],
  "resolved_mcp_servers": ["crm-prod"],
  "resolved_skills": ["refund-policy-v4"],
  "vault_ids": ["vault_abc"],
  "credential_policy_version": "3.2",
  "created_by": "service-account-x",
  "approval_id": "change-789",
  "started_at": "2026-07-12T11:00:00Z"
}

保存すべきなのはOverride差分だけではない。差分を適用した後のResolved Snapshotである。

Override差分だけを保存すると、後でBase Agentが削除または変更された場合に再構成できない。

Overrideを誰でも許可しない

Session Overrideはテストには便利だが、本番で無制限に使うと変更管理を回避できる。

モデル上書き

高価なモデルへの変更、Previewモデルの利用、データ保持条件が異なるモデルへの変更が可能になる。

System Prompt上書き

安全指示、法務文言、個人情報制限、人間承認規則が消える可能性がある。system: nullも明示的な設定変更として扱う。

Tool上書き

読み取り専用Agentへ書き込みToolを追加すると、権限モデルが変わる。

MCP上書き

未承認MCP Serverへの接続は、データ流出とPrompt Injectionの経路になる。

Skill上書き

Skillがコード、指示、外部アクセスを含む場合、Agentの実行能力が変わる。

Overrideポリシー

許可をField単位で定義する。

production:
  model:
    allowed: false
  system:
    allowed: false
  tools:
    allowed_additions: []
    allowed_removals: [optional-search]
  mcp_servers:
    allowed: false
  skills:
    allowed_versions:
      - refund-policy-v4

すべて禁止する必要はない。例えば障害時にToolを削除するOverrideは有効である。しかし能力を追加する変更と、能力を減らす変更を同じ扱いにしない。

Break-glass Override

緊急対応でOverrideが必要な場合は、次を必須にする。

  • 時限付き承認
  • 変更理由
  • 対象SessionまたはDeployment
  • 許可されたField
  • 自動失効
  • 実行後レビュー
  • 通知先
approval_id
valid_from
valid_until
allowed_override_hash
approver
incident_id

緊急変更が恒久設定として残らないようにする。

Vaultの注入位置が持つ危険

資格情報をHeaderへ入れるかBodyへ入れるかは単なるAPI形式ではない。

Header注入

一般的なAuthorizationやAPI Keyへ適する。ただしProxy、APM、HTTP Debug LogがHeaderを記録する設定では漏えいする可能性がある。

Body注入

リクエスト本文にTokenを要求するAPIへ対応できる。一方、Bodyは監査、再試行、Dead Letter Queue、エラー記録へ保存されやすい。

HeaderとBodyの両方

互換性目的で必要な場合があるが、露出経路が増える。明確な理由がない限り避ける。

秘密値が見えなくても安全とは限らない

Managed Agentsが秘密値を実行時に注入するため、ClaudeのContextへ直接秘密を渡さずに済む。しかし外向きリクエストの送信先、Path、Header名、Body構造をAgentが制御できる場合、秘密を意図しない宛先へ送る危険は残る。

必要な制御は次である。

  • Credentialごとの許可Domain
  • 許可HTTP Method
  • 許可Path Prefix
  • 注入可能Header名
  • Body内の固定JSON Path
  • Redirect禁止または再検証
  • DNS Rebinding対策
  • Private IPへの接続制限
  • Request Size制限
  • Response Size制限
  • Egress Log

資格情報の安全性は「モデルに値を見せない」だけでは完成しない。値をどの宛先へ注入できるかが重要である。

実行中に注入位置が変わる問題

injection_locationの更新は実行中Sessionへ反映される。これはローテーションに便利だが、長時間Sessionの途中で認証動作が変わる可能性がある。

例えば、前半のTool CallはHeader認証、後半はBody認証になる。監査時にSession開始時のVault設定だけを見ると説明できない。

次を記録する。

  • Credential Version
  • Secret Rotation時刻
  • injection_location変更時刻
  • 各Tool Callで解決されたCredential Version
  • 注入先ポリシーVersion

秘密値自体はログへ保存しない。VersionとPolicyだけを保存する。

Credential構造変更とローテーションを分ける

公式資料では、Secret Value、Display Name、Injection Locationは更新できる。一方、MCP Server URL、Secret Name、Token Endpoint、Client IDなどの構造Fieldは作成後に固定され、変更時はArchiveして新しいCredentialを作成する。

この違いを運用へ反映する。

ローテーション

同じCredentialの秘密値を更新する。利用者や接続先は変わらない。

構造変更

新Credentialを作成し、Vault参照を段階的に切り替える。接続先やOAuth Clientが変わるため、通常のSecret Rotationとして扱わない。

Webhookは完全なイベントログではない

Managed AgentsのWebhookはEvent TypeとIDを通知し、最新ResourceをGETで取得する方式である。

これはPayloadを小さくし、Retryで古い状態を送らない利点がある。一方、受信時点の状態が後から上書きされる可能性がある。

例えば、次の順に状態が変わる。

run.failed
run.retried
run.completed

run.failedのWebhook受信後にGETすると、すでにcompletedになっている可能性がある。

そのため二種類の記録を分ける。

  1. Webhook Envelope

- Event ID - Event Type - 受信時刻 - 署名検証結果

  1. Fetch Snapshot

- GET取得時刻 - Resource状態 - ETagまたは更新時刻

Webhookは状態変化の合図であり、完全な履歴の代替ではない。

Webhook受信の安全設計

  • HTTPS 443
  • Signing SecretをSecrets Managerへ保存
  • Raw Bodyで署名検証
  • Event IDで重複排除
  • 即時に2xxを返し、非同期処理
  • GET取得のRetry
  • Event TypeのAllowlist
  • 未知Eventを破棄せず隔離
  • 配信遅延の監視
  • Signing Secretのローテーション手順

外部からEvent IDを送るだけで内部Resourceを取得できないように、Webhook処理の認証権限も最小化する。

Scheduled Deploymentの重複実行

Cron実行では、前回Runが完了する前に次回が開始される可能性を考える。

必要な制御は次である。

  • 同時実行禁止または上限
  • 業務日単位の冪等Key
  • 前回Runの状態確認
  • Timeout
  • Retry上限
  • Dead Letter Queue
  • 手動再実行時の重複防止
  • 実行遅延の扱い
idempotency_key = deployment_id + scheduled_time + business_partition

Agentが同じメール、返金、データ更新を二重実行しないようにする。

Event Deltaを確定結果として扱わない

event_startとevent_deltaは生成途中のPreviewであり、完全なagent.messageより前に届く。

画面表示には有効だが、次へ直接使わない。

  • 顧客への確定通知
  • DB更新
  • Tool実行
  • 監査上の最終回答
  • 法務文書

生成途中の内容は後で変わる、またはRunが失敗する可能性がある。確定EventとPreview EventをUIとデータモデルで分ける。

本番導入の推奨構成

Scheduler / API
  -> Policy Gateway
      -> Override Validator
      -> Managed Agents Session
          -> Vault-controlled Egress
          -> MCP / External API
      -> Webhook Receiver
          -> Signature Verification
          -> Event Queue
          -> Resource Fetcher
      -> Run Manifest Store
      -> Audit / SIEM

Policy GatewayはSessionを作る前に、Base Agent、Override、Vault、Environment、Approvalを検証する。

評価項目

再現性

  • 同じManifestで同等の実行ができるか
  • Base Agentが更新されても過去Runを説明できるか
  • OverrideとVault Versionが保存されているか

セキュリティ

  • 未承認Toolを追加できないか
  • 秘密を未承認Domainへ送れないか
  • Body Logへ秘密が残らないか
  • Redirect後も宛先を検証するか

運用

  • Webhook重複と順序逆転へ対応できるか
  • Scheduled Runが二重実行されないか
  • Credential更新が実行中Sessionへ与える影響を追跡できるか
  • Agent停止時に外部副作用を止められるか

コスト

  • Overrideで高価なモデルへ変わっていないか
  • Tool Loopが発生していないか
  • Scheduled Runの失敗再試行が増えていないか
  • Event Streamの保存量が過大でないか

編集部分析

Managed Agentsの今回の拡張は、Agentを静的な設定Resourceから、実行時に組み替えられる運用基盤へ近づけている。

これは本番自動化に必要な柔軟性である。一時的にModelを変える、障害時にToolを外す、SessionごとにMCPを切り替える、Credentialを再起動なしで更新する、といった操作が可能になる。

一方で、柔軟性が高いほど、公開済みAgent Versionという単一の監査単位は不十分になる。実際の能力は、Base Agent、Session Override、Vault、Environment、Credential Version、外部MCPの組み合わせで決まる。

したがって、企業が管理すべき単位はAgentではなくResolved Runである。

Resolved Run
= Base Agent Version
+ Session Override
+ Model
+ Tools
+ Skills
+ MCP Servers
+ Vault Credentials
+ Environment
+ Policy
+ Approval

このManifestを保存できなければ、Agentが誤操作したときに「なぜその権限を持っていたか」を説明できない。

実務チェックリスト

  • [ ] Session OverrideをField単位で許可・禁止している
  • [ ] 能力追加と能力削除を別の承認強度にしている
  • [ ] Resolved Run Manifestを保存している
  • [ ] System PromptのNull化を監査対象にしている
  • [ ] ToolとMCPの追加をAllowlistで制御している
  • [ ] Vault Credentialごとに許可DomainとPathを設定した
  • [ ] HeaderとBodyのログマスキングを確認した
  • [ ] Credential VersionとInjection Policy Versionを記録した
  • [ ] Webhook署名、重複、順序逆転へ対応した
  • [ ] Webhook受信後にGETしたSnapshotを別保存している
  • [ ] Scheduled Runへ冪等Keyと同時実行制御を設定した
  • [ ] Event Deltaを確定データとして利用していない
  • [ ] Break-glass Overrideに自動失効を設定した
  • [ ] Run単位の費用、Tool回数、外部副作用を監視した

一次情報