0
0

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を本番寄りに使う前に整理する - effort・webhooks・initial_events・memory betaを見る

0
Posted at

はじめに

ChatGPT Image 2026年8月17日 05_07_40.png

Claude APIには、長く動くエージェント実行を扱うための Claude Managed Agents というAPI群があります。

2026年7月のClaude Platform release notesでは、Managed Agentsまわりで effort、Webhook対象イベント、initial_events、session threadのevent delta、Memory Store向けbeta headerなどの更新がまとまっていました。

本記事は、これらを「本番寄りに使う前に何を確認するか」という観点で整理する個人メモです。

※本記事は2026-08-17時点で公式Docsを確認した整理です。Managed Agents APIはbeta headerを使う機能を含むため、公開・実装前には最新の公式Docs、SDKバージョン、利用条件、料金条件を再確認してください。この記事では実API呼び出しは行っていません。

まず整理したい全体像

fig_01_overview.png

Managed Agentsを、単発のMessages API呼び出しではなく、次のリソースを組み合わせて動かす仕組みとして捉えると理解しやすいです。

  • agent: 実行するエージェント定義
  • environment: エージェントが動く環境
  • session: agentとenvironmentを参照して動く、会話履歴を持つ実行単位
  • event stream / webhook: 実行状況を追うための観測口
  • memory store: 記憶を扱うためのリソース

公式Docsでは、sessionはagentとenvironmentを参照し、会話履歴を維持する実行単位として説明されています。また、sessionは「作成してからuser eventを送る」2段階でも、initial_eventsで作成時に開始する形でも扱えます。

1. effort は「エージェントにどの程度考えさせるか」の調整点

fig_02_effort.png

2026年7月22日のrelease notesでは、Claude Managed Agentsのagent model configurationで effort levelを設定できるようになったと案内されています。

effort は、モデルにどの程度の推論努力を使わせるかを制御する要素です。公式Docsでは low / medium / high(既定値) / xhigh / max の5段階が案内されており、値を省略した場合は high と同じ扱いになります。記事としては、次のように整理すると安全そうです。

  • 低いeffort(low / medium): 軽い確認・定型処理・コスト重視の作業向け
  • 既定のeffort(high): 中程度のリスクの計画・統合作業向け
  • 高いeffort(xhigh / max): 複雑な調査・設計判断・長時間の推論向け
  • 本番運用: 品質、レイテンシ、コストのバランスを見て決める

ここで注意したいのは、effort を上げれば常に良い結果になる、と断定しないことです。実際の運用では、作業の種類ごとに評価データを用意し、成功率、処理時間、コスト、再試行率を見ながら調整するのが現実的です。

2. initial_events でsession作成と開始を1回にまとめられる

fig_03_initial_events.png

Managed Agentsのsessionは、通常は次のような流れで開始します。

  1. sessionを作成する
  2. user eventを送って作業を開始する

一方、公式Docsでは initial_events を使うと、session作成時に初期イベントを渡し、そのまま作業を開始できると説明されています。2026年7月22日のrelease notesでも、POST /v1/sessions に最大50件の user.message / user.define_outcome eventsを渡せると案内されています。

公式Docsの例を短くすると、イメージは次のようになります。

curl -fsSL https://api.anthropic.com/v1/sessions \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  -d @- <<'JSON'
{
  "agent": "AGENT_ID",
  "environment_id": "ENVIRONMENT_ID",
  "initial_events": [
    {
      "type": "user.message",
      "content": [
        {"type": "text", "text": "List the files in the working directory."}
      ]
    }
  ]
}
JSON

公開記事や社内メモでこの例を書く場合は、実在のAPIキー、agent ID、environment ID、社内ディレクトリ名などを入れないようにします。

3. Webhookは「全部の状態を送ってくれるもの」ではなく、変化を取りに行くきっかけ

fig_04_webhooks.png

公式Docsでは、Managed Agentsのwebhookは、長く動くsessionの大きな状態変化を通知するものとして説明されています。

重要なのは、webhook eventにはevent typeid が返り、完全なオブジェクトそのものは返らない点です。受け取った側は、必要に応じてGET APIで対象オブジェクトを取りに行く構成になります。

2026年7月の更新では、webhookの対象として次のようなライフサイクルイベントが案内されています。

  • session: session.status_run_startedsession.status_idledsession.status_terminated など
  • environment: environment.createdenvironment.updatedenvironment.archivedenvironment.deleted
  • memory store: memory_store.createdmemory_store.archivedmemory_store.deleted
  • deployment / deployment run: scheduled deploymentの開始、成功、失敗など

本番寄りに考えるなら、webhookを「処理完了を知るため」だけではなく、次の確認にも使うとよさそうです。

  • 長時間runningのまま止まっていないか
  • idled で人間の承認や追加入力を待っていないか
  • retryやrescheduleが頻発していないか
  • environmentやmemory storeの削除・archiveに気づけるか
  • webhook受信後にGETで最新状態を取りに行く実装になっているか

また、公式Docsでは、同じwebhook eventが複数回配信される可能性があり、再試行時も同じ event.id が使われると説明されています。受信側は event.id で重複排除(dedupe)する前提の実装が必要です。配信は最大3回試行されますが、最終試行も失敗するとイベントは破棄されるため、webhookを永続的なイベントログとして扱うことはできません。Webhookだけに依存せず状態を確認したい場合は、必要に応じてAPIでリソースをlist/fetchして突き合わせる設計にします。

加えて、イベントの配信順序は保証されません(例: session.status_idledsession.outcome_evaluation_ended より先に届くことがある)。created_at でイベントの発生時刻は確認できますが、状態管理ではwebhookの到着順に依存せず、GET APIで取得した最新リソースを基準にするのが安全です。

なお、配信には webhook-id / webhook-timestamp / webhook-signature ヘッダーが付与され、SDKの unwrap() などで署名を検証できます。未検証のpayloadは処理しない実装にしておきます。

4. event streamとevent deltaはリアルタイム観測の入口

fig_05_event_stream.png

Managed Agentsのevents and streaming Docsでは、通信はeventベースで、user eventを送り、session eventやagent eventを受け取って進捗を追う形だと説明されています。

また、stream接続でopt-inした場合は event_start / event_delta のようなdelta preview eventsを受け取れると説明されています。2026年7月1日のrelease notesではsession event streamのevent delta、7月22日のrelease notesではsession thread event streamのevent delta対応が案内されています。

ここは「完成した最終結果だけを見る」のではなく、エージェントが途中で何をしているかを観測するための入口と捉えるとよさそうです。

ただし、deltaはpreview的な情報として扱い、最終的な永続イベントや完了状態と混同しないほうが安全です。UIに途中経過を出す場合も、最終結果との差分があり得る前提で表現するとよさそうです。

5. Memory Storeだけbeta headerが異なる点に注意する

fig_06_beta_headers.png

Managed Agents APIではbeta headerが重要です。

公式Docsでは、/v1/agents/v1/sessions/v1/environments には managed-agents-2026-04-01 を使う一方、/v1/memory_stores とそのsub-resourcesには agent-memory-2026-07-22 を使うと整理されています。

さらに、Memory Store endpointsでは agent-memory-2026-07-22managed-agents-2026-04-01 を置き換えるため、同じrequestで両方を送ると 400 errorになる、と公式Docsに記載されています。

つまり、raw HTTPで実装する場合は次の点を確認します。

  • session/agent/environment系: managed-agents-2026-04-01
  • memory store系: agent-memory-2026-07-22
  • SDK利用時: beta namespaceが正しいheaderを付与する前提だが、明示的に betas を渡している既存コードは確認する

特に既存コードでMemory Storeにも managed-agents-2026-04-01 を明示している場合は、2026年7月のrelease notesにある通り、agent-memory-2026-07-22 へ置き換える必要があるか確認したほうがよさそうです。

本番寄りに使う前のチェックリスト

最後に、実装前の確認観点を短くまとめます。

  • Managed Agents APIの提供段階、利用条件、料金条件を最新Docsで確認した
  • SDKを使うかraw HTTPを使うか決めた
  • raw HTTPの場合、endpointごとのbeta headerを分けた
  • effort を作業種別ごとに評価する方針を決めた
  • initial_events に入れる内容が公開・送信してよい情報だけか確認した
  • webhook受信後にGETで最新オブジェクトを取りに行く設計にした
  • webhookを event.id で重複排除し、順序が前後する前提の実装にした
  • webhookの署名(webhook-signature)を検証し、未検証のpayloadを処理しない実装にした
  • idledterminatedrescheduled などの状態を監視対象にした
  • event deltaを最終結果と混同しないUI/ログ表現にした
  • memory storeのbeta headerと既存コードの betas 指定を確認した
  • APIキー、組織名、内部URL、顧客情報をログや記事に出さない方針を決めた

まとめ

fig_08_summary.png

Claude Managed Agentsは、単発のAPI呼び出しというより、session、event、webhook、memory storeを組み合わせて長時間のエージェント作業を管理する仕組みとして捉えると整理しやすいです。

特に2026年7月の更新では、effortinitial_events、webhook対象イベント、event delta、Memory Store向けbeta headerが運用設計に関係します。

まずは「何を自動化するか」よりも、「どう開始し、どう観測し、どう止め、どの情報を渡さないか」を確認してから試すのがよさそうです。

参考(公式情報)

0
0
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
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?