Anthropic は、ホスト型マルチエージェント ワークフローを Claude 個の管理対象エージェントにもたらします

Anthropic はパブリック ベータ版で Claude 管理対象エージェントに動的なワークフローを追加し、共通のエージェント エンジニアリング パターンをローカル オーケストレーション コードから Claude プラットフォーム自体に移動しました。

10 月 9 日のリリースでは、管理対象エージェントがワークフロー プログラムを作成し、多くのエージェントを段階的に実行し、サーバーがワークフロー実行としてバックグラウンドで作業を実行している間に、その結​​果を組み合わせることができます。開発者は、managed-agents-2026-04-01 ベータ ヘッダーでベータを有効にし、タイプ multiagent_20261001 で multiagent フィールドを構成し、ワークフローを有効にします。 Anthropic はまた、workflow_run イベントがセッション イベント ストリームに表示されることを示し、アプリケーションがワークフローを単一の不透明な呼び出しとして扱うのではなく、進行状況を観察できるようにします。

これは、エージェント システムを構築するチームにとって意味のある変更です。マルチエージェント分解には通常、アプリケーション側のスケジューラ、キュー、状態ストア、再試行、結果マージ ロジックが必要です。 Anthropic は、そのオーケストレーション レイヤーの一部をホストされた API 機能としてパッケージ化するようになりました。

変更点

Claude マネージド エージェントにより、開発者はエージェント セッション用の管理された環境をすでに提供しています。動的ワークフローは、エージェントがフェーズ全体で他のエージェントを調整するワークフロー プログラムを作成できるようにすることで、そのモデルを拡張します。開発者が並行レビューや調査パイプラインの各ステップをハードコーディングする代わりに、マネージド エージェントがワークフローを定義し、Claude プラットフォームでそれを非同期に実行できます。

有用な違いは、単に「エージェントが多い」ということではありません。そこにオーケストレーションが存在します。このベータ版では、作業は Anthropic 側で実行されるワークフローとして表され、イベントはセッション ストリームを通じて表示されます。これにより、チームが Claude 呼び出しを中心に独自のコントローラー サービスを構築する必要があった一部のアーキテクチャが簡素化される可能性があります。

この機能はベータ版のままです。 Anthropic の文書化された構成とイベント名は、ここでレビューしたリリース ノートと管理対象エージェントのドキュメントから入手できる安定した事実です。サードパーティの記事には、実行ごとのエージェントおよび同時エージェントの具体的なスケール制限が記載されていますが、公開可能な操作上の制約として扱う前に、これらの制限を Anthropic の現在のワークフロー実行ドキュメントと照合して確認する必要があります。

API チームにとって重要な理由

ホスト型ワークフロー オーケストレーションにより、エージェント ワークロードの開始は簡単になりますが、気軽に管理するのは困難になります。単一のユーザー リクエストが、多くのモデル呼び出し、中間サマリー、ツール呼び出し、および最終合成ステップに展開される可能性があります。これにより、ユーザー向けの製品が依然として 1 つの「お願い」のように見える場合でも、アプリケーションのコストと可観測性のプロファイルが変化します。

最も明白な使用例は、大規模なコード レビュー、ドキュメント レビュー、移行計画、デューデリジェンス分析、コンプライアンス チェック、調整エージェントが結果をマージする前に並行して専門家が異なるスライスに取り組むことができるリサーチ タスクです。これらのワークロードは、段階的な実行に適切に対応しているため、魅力的です。これらは、プロンプト、再試行、およびサブエージェントの数に制限がない場合、多額のトークン請求が発生する可能性が最も高いワークロードでもあります。

エンジニアリング リーダーにとって、ガバナンスの問題は「このエンドポイントがどのモデルを呼び出したか」から変わります。 「このリクエストはどの自律的なワークフローをトリガーしましたか?各フェーズでどれくらいの量が消費されましたか?」この場合、LLM API コスト アトリビューション が財務報告以上のものとなります。チームは、どの製品機能、顧客、プロジェクト、または API キーがワークフローのファンアウトの原因となったかを知る必要があります。

信頼性の観点もあります。バックグラウンド ワークフローの実行には、進行状況の可視性、キャンセル動作、再試行ポリシー、および永続的な状態の予測が必要です。アプリケーションはやみくもにポーリングするのではなく、ワークフロー実行イベントをサブスクライブできるため、Anthropic のイベント ストリーム サポートが始まりです。ただし、チームは独自のステート マシンのどの程度をプロバイダーの外部に残すかを決定する必要があります。

誰が影響を受けるか

当面の対象者は、すでに Claude 個の管理対象エージェントを使用している開発者、またはホスト型エージェント インフラストラクチャを評価している開発者です。カスタムのマルチエージェント システムを構築したチームは、特に現在の実装が差別化された製品ロジックではなく主に配管である場合、ベータ版を既存のオーケストレーション レイヤーと比較することがあります。

エンタープライズ プラットフォーム チームは、ベータ版を導入する準備ができていない場合でも注意を払う必要があります。ホストされたオーケストレーションは、AI API コントロール プレーン で表示する必要がある内容を変更します。リクエスト数、モデル名、合計トークンのみを記録するコントロール プレーンでは、ワークロードの構造が見逃される可能性があります。管理されたワークフローの場合、チームは実行識別子、フェーズレベルの使用状況、ツールのアクティビティ、障害ポイント、予算のステータスを必要とします。

これは調達とセキュリティのレビューにも影響します。ホスト型マルチエージェント ワークフローは、単なるモデル エンドポイントではありません。これは委任された実行環境です。企業は、各エージェントを介してどのようなデータが流れるか、ワークフローの状態がどのくらいの期間保持されるか、どのようなログが利用できるか、プロジェクトや環境全体でアクセスがどのように範囲設定されるかを理解する必要があります。

B2B LLM 人の顧客と同様のマルチモデル API ユーザーにとって、実際的なつながりはガバナンスです。プロバイダーがエージェントのファンアウトを容易にする場合は、キーまたはプロジェクトごとの支出制限、ワークフローの使用状況分析、モデルの許可リスト、自動化パターンが予想以上に消費し始めたときのアラートなど、プラットフォーム レベルの制御も対応する必要があります。動的なワークフローは製品の機能ですが、エージェントのコストがトークンの価格だけでなくオーケストレーションによって決まることが多いことを思い出させてくれます。

まだ不確実な点

ベータ版では、本番環境での使用を計画しているチームにとって運用上の問題がいくつか残されています。公開リリース ノートでは、動的ワークフロー、ベータ ヘッダー、マルチエージェント構成タイプ、およびイベント ストリーム サーフェスの存在が確立されています。レビューされた資料では、制限、価格設定の動作、保持、または障害のセマンティクスに関する運用計画の詳細がすべて解決されているわけではありません。

開発者は、実行あたりの最大エージェント、同時実行数、タイムアウト動作、および請求エクスポートでの使用量の項目化方法に関する仮定を設定する前に、現在のドキュメントを確認する必要があります。また、マルチエージェント合成ではコストだけでなく出力の一貫性も変化する可能性があるため、機密性の高いレビューやコンプライアンスのワークフローを機能に移行する前に、小規模な評価を実行する必要があります。

ただし、より大きな方向性は明らかです。モデル プロバイダーは、エージェント オーケストレーションをプラットフォーム プリミティブに変えています。これにより、実験に必要なインフラストラクチャの量が削減され、実験が実際のワークフローになった後の可観測性と予算管理の基準が高まります。