Anthropic のマネージドエージェントプラットフォーム Claude Managed Agents（CMA） が、6項目の増分更新を一挙に出しました。先に線引きをしておくと、CMA は Anthropic がホストする Agent 実行プラットフォームであり、Claude Code Skills、Record a Skill、Cowork とは別物です。この複数の製品をごっちゃにしないでください。

この6項目のうち、開発者にとって最も実用的なのは3つです。セッションあたりのスキル上限が20から500へ引き上がったこと、effort の思考強度を各 Agent のモデル設定へ書き込めること、そして POST /v1/sessions が initial_events を添えて1ステップでセッションを作れること。以下、そのまま動く API ペイロードを載せます。

✅ 事実の出所: 本稿は Anthropic 公式開発者アカウント @ClaudeDevs（ポスト）、公式エバンジェリスト CJ Avilla と Eric Buess の公式 "we just added" ポスト、そして effort パラメータ公式ドキュメント に基づいています。原文のその他の記述的詳細は一つひとつ検証しておらず、本稿は公式の出所に対応づけられる事実だけを述べます。

6項目の更新一覧

以下では、コードを書き替える価値が最も高い3項目を取り上げ、実際のペイロードを示します。

更新一：セッションのスキル上限が20から500へ

CMA の Skills は agent へ専門の指示を注入するナレッジパッケージで、統一されたマネージドサンドボックスの上で走ります。以前は1セッション最大20個でした。それが 500個へ引き上がり、セッション内の全 agent で共有されます。

これは何を意味するか。以前、企業のカスタマーサポートシステムを作るなら、各事業線の SOP を組み込むだけで軽く20個を超え、複数セッションに分けるか動的ロードでしのぐしかありませんでした。いまは1つのセッションに、企業ナレッジベース一式を丸ごと載せられます。

マウント方式に API の変更はありません。もともとセッション設定で skill のリストを指定するだけで、上がったのは上限だけです。鍵となる変化はアーキテクチャの層にあります。会社のドキュメント、コンプライアンス規則、製品マニュアルをすべて一度にプレマウントし、実行時の動的ロードのコストと複雑さを省けるようになったことです。

更新二：effort の5段階を per-agent 設定へ書き込める

effort パラメータは API レベルでは以前から存在しましたが、CMA の agent は個別に設定できず、セッション全体がデフォルトの段階で統一されていました。それが、各 agent のモデル設定へ書き込めるようになり、5段階で調整できます：low / medium / high / xhigh / max。

典型的な使い方は、マルチエージェント協調時の段階別の振り分けです：

• 分流 coordinator：low（単純分類。token を節約）
• 製品の質問応答：medium（これで足りる）
• クレームのエスカレーション：high（より深い推論が必要）
• 法務コンプライアンス：max（ミスは許されない。最大まで）

per-agent 設定の例（主要フィールドを抜粋）：

{
  "agents": {
    "triage": {
      "model": "claude-...",
      "model_config": {
        "effort": "low"
      }
    },
    "complaints": {
      "model": "claude-...",
      "model_config": {
        "effort": "high"
      }
    },
    "legal": {
      "model": "claude-...",
      "model_config": {
        "effort": "max"
      }
    }
  }
}

フィールド構造の全容は effort 公式ドキュメント を正としてください。

更新三：シードセッションを1ステップで作成（initial_events 付き）

コールドスタートは、CMA が以前いちばんこき下ろされてきた点の1つです。セッション作成には以前2ステップが要りました。まず POST /v1/sessions で空枠を作り、それから初期イベントを1件ずつ流し込む。いまは1ステップで済みます。

以下は動くシードセッション作成ペイロードで、POST /v1/sessions に initial_events（最大50件）を添えています：

curl -X POST https://api.claude.com/v1/sessions \
  -H "Authorization: Bearer $CLAUDE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": "agent_01ABC...",
    "initial_events": [
      {
        "type": "user_message",
        "content": "当前用户身份：企业版，剩余额度充足。"
      },
      {
        "type": "system_context",
        "content": "把所有回复限定在 SaaS 计费领域内。"
      }
    ]
  }'

💡 ヒント: initial_events は最大50件。入れるべきは「セッションの冒頭に最初からあるべき文脈」——身分、権限の境界、ドメインの制約——であって、過去のチャット履歴ではありません。大量の履歴を混ぜるとコールドスタートが遅くなります。

更新四：子 agent のストリーミングがスレッド単位まで掘り下げ

6月末に CMA はセッション単位の event_deltas を出したばかりです（セッション全体の層で agent が何をしているか見られます）。今回はスレッド単位まで掘り下げました。各子 agent がどのステップまで進んだか、途中で何を考えているかが、リアルタイムで見えます。

1つのセッションに5、6の子 agent を載せた複雑なワークフローにとって、これは可観測性の分解能を「セッション」から「スレッド」へ引き上げたことに相当します。マルチエージェント編成をデバッグするとき、どの子 agent が詰まったのか、どこで答えを間違えたのかを正確に特定できます。

更新五：新 webhook 7種

CMA は6月末に agent とデプロイのライフサイクル webhook を出しています。今回は残る2大ブロックを補いました：

• 環境イベント4種（environment lifecycle）
• メモリストレージイベント3種（memory storage）

合計で新しいイベント型は7つです。実戦上の意味は：ポーリングは退場できる。以前はループでポーリングして、agent がいつ新しい環境に入るか、メモリの書き込みがいつ完了するかを知るしかありませんでした。いまはすべてイベント駆動で、webhook の受け口を用意すれば済みます。具体的なイベント名は公式の webhook ドキュメントを正としてください。

更新六：agent 更新インターフェースの version フィールドが任意に

agent 更新インターフェースの version フィールドが、必須から任意へ変わりました。

絶えず反復する agent（CI/CD パイプラインの中で頻繁に指示を更新する）にとって、これは更新のたびに version 番号を管理しなくてよいことを意味します。1フローあたり、バージョン管理のオーバーヘッドが丸ごと1塊減ります。

誰に向くか

この一連の更新は、すでに CMA で本番級の agent を組んでいるチームを主な相手にしています。あなたのシーンがこうであれば：

• 企業級マルチエージェントシステム（カスタマーサポート、リスク管理、コンプライアンス）→ スキル上限500 + per-agent effort のいちばん直接の受益者
• コールドスタートに敏感なリアルタイムアプリ（金融、サポートのオープニング）→ シードセッションの1ステップ作成で往復が半減
• マルチエージェント編成の深いデバッグが必要 → スレッド単位のストリーミングイベントは必須級
• イベント駆動アーキテクチャ → 新 webhook 7種でポーリングコードの大部分を削れる

まだ CMA に触れたことがないなら、まず Anthropic 公式ドキュメント で最小のデモを通してから、この6項目の更新を見返すと、それぞれが何を解決するのかがよりはっきりします。