Claude Managed Agentsで今日から変わること: 5つのアップデートを実装者目線で読む

こんにちは。もるふぉです。

自前ハーネスでエージェントのループを管理している人なら、このあたりの摩擦に覚えがあるはずです。

「生成が終わるまでスピナー以外に何も出せない」「QAセッションだけツールを絞りたいのに、それだけのために agent version を増やしたくない」「深夜に credential が切れてエージェントが空回りしていた」——PoCを越えて本番で使い始めると、だいたいこのあたりで詰まります。

Claude公式アカウントが2026年7月1日に Claude Managed Agents の更新をアナウンスしました。

短い投稿ですが、そこに並ぶ5機能が、その摩擦を狙い撃ちにしています。

「で、結局これで何ができるようになるのか」を実装者目線で1つずつ翻訳していきます。

このアップデートで Claude Managed Agents の何が変わったか

今回追加されたのは以下の5つです。

それぞれがエージェント運用のどの層に効くか、先に俯瞰しておきます。

私の感覚では、派手な目玉機能というより、本番運用で「これ前からあれば困らなかったのに」と思っていた部分をきれいに塞ぎにきている印象です。

5機能のうち、表示体験にいちばん直結するのが streaming deltas です。

Streaming session event deltas で応答をトークン単位で受け取る

これまで agent.message は、モデルのリクエストが完了してからバッファ済みで一括で届く仕様でした。

エージェント側で生成が終わるまで、UIは「考え中…」のスピナーを回し続けるしかなかった——ユーザーが30秒待ってタブを閉じる、あのやつです。

event_deltas[]=agent.message をクエリパラメタで opt-in すると、event_start と event_delta がストリームに乗って流れてきます。

event_delta の中身は content_delta 型で index 付きでテキストが分割配信されるので、event_id で同一イベントを束ねながらUIに逐次反映できます。

注意点が2つあります。

1つ目は対象が agent.message と agent.thinking のみで、それ以外を指定すると400エラー。

agent.thinking は event_start のみで event_delta は届きません。

2つ目はストリーム限定で、event_start / event_delta はイベント履歴に残らないという点です。

後から取得する側は従来どおりバッファ済みの agent.message を正とする設計です。

deltaはあくまで表示用の補助で、永続化する答えはバッファ済みの本体。

この役割分担を最初に整理しておくと、ログとUIで微妙にズレが出るタイプの事故を避けられます。

ストリームで表示は解決できた。

次は「本番エージェントを汚さずに実験したい」という問題です。

Per-session agent overrides で本番エージェントを汚さず1セッションだけツールを替える

これまでエージェント設定を変えるには新しいバージョンを作る必要があり、「特定のセッションだけツールを少し絞りたい」程度の話に versioning が降ってくる重さがありました。

Git で言えば、小さな実験のたびにリリースタグを打つような重さです。

今回はセッション単位でオーバーライドできるようになります。

粒度は2つです。

sessions.update() は full replacement セマンティクスです。

既存エントリを温存したい場合は GET → 部分修正 → POST の手順を踏むことになります。

「ツールを1つだけ足す」つもりで送るとごっそり消える事故があるので要注意。

じわっと効くポイントですが、これがあると本番エージェントのバージョンを増やさずに、QAセッションだけツールを切ったり、調査用に MCP サーバを差し替えたりできます。

エージェント定義の versioning を「設計が変わった時だけ」に絞れるので、運用台帳が荒れません。

セッション単位で制御できるようになった。

となると次は、エージェントが何をしているかを外から把握する話になります。

New webhook event types / reverse pagination — 非同期通知と履歴ナビゲーションの強化

新規追加された webhook イベントは大きく3系統です。

• multiagent スレッドのライフサイクル: session.thread_created / session.thread_idled / session.thread_terminated
• outcome evaluation 系: session.outcome_evaluation_ended
• Vault credential 系: vault_credential.refresh_failed

session.thread_created が届くのはサブエージェントが起動した瞬間です。

session.thread_idled は処理を終えて次の指示待ち、session.thread_terminated はスレッドの完全終了。

マルチエージェント構成なら、poll なしでサブエージェント全体のライフサイクルを外から追えます。

vault_credential.refresh_failed は Vault の credential リフレッシュが失敗した瞬間に届きます。

SSEストリームには session.thread_status_running / session.thread_status_rescheduled や span.outcome_evaluation_start 系のスパンイベントも流れますが、これらは webhook には届きません。

webhook で受け取れるのは上記の3系統です。

これまで poll で監視するか、サブエージェントの完了を親側のロジックで頑張って待つしかなかった領域が、ほぼ非同期通知で組めるようになります。

特に vault_credential.refresh_failed は重要で、深夜に credential が切れて翌朝までエージェントが空回りしていたタイプの事故を即時検知に変えられます。

webhook ペイロードは resource 本体の完全データは含まず、data.type と data.id を中心に、created_at / organization_id / workspace_id 程度の最小フィールドで届きます。

詳細は ID を使って別途 API で取得する設計です。

webhook を軽く保ち、二次取得の責任を呼び出し側に寄せる、ありがちで正解の作りです。

Reverse pagination は list 系エンドポイントに order=asc/desc と prev_page カーソルが追加された話です。

order=desc で最新側から、order=asc で古い側からたどれます。

カーソルは生成時の order をエンコードしているので、別の order で同じカーソルを再利用すると400エラーになります。

仕様は素直で、長期セッションの直近だけ拾いたい監視UIで効きます。

Credential injection scoping で Vault の秘密を「リクエストのどこに注入するか」絞る

Vault 周りを使い込んでいると、こういう問いが出てきます。

「credential はヘッダーにだけ注入したい。body には入れたくない」——injection_location はその答えです。

Claude Managed Agents の Vault は Vault → Proxy → Sandbox の3層構造です。

Claude のサンドボックスは生 credential を絶対に見ません。

エージェント側にはプレースホルダーが渡り、エグレスプロキシで実シークレットに置換されてから外に出ていく設計です。

今回追加された injection_location は、その置換を「リクエストのどこに対して行うか」を絞れる仕組みです。

{
  "injection_location": {
    "header": true,
    "body": false
  }
}

この設定なら credential はリクエストヘッダーには差し込まれますが、body には差し込まれません。

LLM が prompt injection で意図しないリクエストを組み立てたとしても、body経由で credential を持っていく経路を構造的に塞げます。

networking.allowed_hosts による宛先制限とは独立して効くので、ホスト許可とフィールド許可で二重に絞れる形です。

落とし穴がいくつかあります。

injection_location は environment_variable 認証タイプ専用で、mcp_oauth や static_bearer には効きません。

create 時にフィールドを省略すると false 扱いですが、update 時に省略すると既存値を保持する merge セマンティクスです。

null を明示的に渡すと400エラーで、省略と明示 null が別物として扱われます。

サンドボックス内で AWS SigV4 のようにリクエスト署名を行うクライアントは生 credential を必要とするので併用できません。

5つを組み合わせると Claude Managed Agents でこんなものが作れる

5機能はバラバラに見えますが、組み合わせると「本番で使えるエージェント基盤」のピースが揃います。

例えば、契約書や仕様書を複数のサブエージェントに並列で食わせる構成を考えます。

各サブエージェントの生成テキストは streaming deltas でUIに逐次反映し、session.thread_idled を webhook で拾って親側が次タスクを投入する。

Vault credential の refresh が失敗したら vault_credential.refresh_failed で即通知。

これまで自前ハーネスのループで頑張って吸収していた状態管理が、ほぼ API 側に寄ります。

もう1つは、QAと本番を同じエージェント定義で運用する構成です。

本番セッションには素のエージェントを、QAセッションには agent_with_overrides で tools を本番より狭く絞ったエージェントを当てる。

injection_location で body 経由の credential 漏洩経路を閉じておく。

エージェント定義は1本のまま、環境差分はセッション単位で吸収する——バージョンを増やさずに QA を回せる構成が素直に組めます。

どちらも、自前ハーネスで頭を悩ませていた部分を API 側が引き取った形です。

エージェント基盤を自前で書く理由が、1つずつ減っています。

まとめ — Claude Managed Agents を今すぐ試すべき人は誰か

すでに Claude Managed Agents を本番で使っている人は、streaming deltas と per-session overrides の2つを優先的に試す価値があります。

前者は既存コードに event_deltas[]=agent.message を1行足すだけで、ストリームに何が流れてくるか確認できます。

UI体験と運用安全性の両方が一段上がります。

これから評価する人は、credential injection scoping と webhook イベント追加で「本番で詰まりがちな部分」がどう改善されたかを確認するのが早いです。

今回のアップデートで「ハーネスを自前で書く理由」がまた1つ減りました。

Managed Agents を試すなら、今は良いタイミングだと思います。

主要な公式リファレンスを置いておきます。

Session event stream

Send events, stream responses, and interrupt or redirect your session mid-execution.

platform.claude.com

Start a session

Create a session to run your agent and begin executing tasks.

platform.claude.com

Subscribe to webhooks

Get notified when major events happen without polling.

platform.claude.com

Reference

Event types, self-hosted worker CLI flags, supported MCP server types, rate limits, and branding guidelines for Claude Managed Agents.

platform.claude.com

Authenticate with vaults

Register per-user credentials when creating sessions.

platform.claude.com