Anthropicが「Claude Managed Agents」に dreaming / outcomes / multiagent の3機能を一斉投入した。法務AI Harveyによる実証ではタスク完了率が約6倍に伸び、評価額110億ドル規模の本番運用での効果が示された格好だ。OSSコミュニティで先行していたエージェント運用パターンを、Anthropicが純正基盤として吸収する流れが鮮明になっている。
何が起きたか
Anthropic は、企業がClaudeエージェントを業務組込みで運用するためのマネージド基盤「Claude Managed Agents」に対し、3つの大型機能を追加した。
- dreaming: エージェントがセッション間で過去の業務履歴を横断参照し、メモリを自己更新する仕組み。
- outcomes: ルーブリック（採点表）ベースでタスク成果を自動評価し、成功率を最大10ポイント引き上げる。
- multiagent: 複数エージェントへの並列タスク委任を純正サポート。これまでLangGraphやAutoGen、Anthropic自身のSwarm的サンプル実装で各社が独自に組んでいた階層構造を、API層で標準化する。
法務AIのHarvey（評価額約110億ドルと報じられる）での実証では、タスク完了率が約6倍に向上。エージェントが「PoCで止まる」最大要因だった長期タスクの中断・脱線・引き継ぎ欠落が、設計レベルで潰されてきたことを意味する。
なぜこのニュースが重要か
エージェント運用の現場感として、ここ1年の課題は明確だった。「会話セッションを跨ぐと文脈が消える」「成果物の良し悪しを誰が判定するのか」「複数エージェントのオーケストレーションが秘伝のタレ化する」——この3つだ。
dreamingは1つ目に直接効く。LangChainのConversationSummaryBufferMemoryや、Letta（旧MemGPT）が提示してきた階層型メモリの考え方を、Anthropicがマネージドサービス側に取り込んだ形だ。エージェントがアイドル時間に過去ログを再咀嚼し、長期記憶を再構築する——文字通り「夢を見る」プロセスを基盤側で持つ意味は大きい。アプリ側でベクトルDBを抱え、要約パイプラインを自作運用してきたチームは、相当部分をオフロードできる。
outcomesは、いわゆるLLM-as-a-Judgeのプロダクション化だ。OpenAIのevalsやAnthropic自身が公開してきたルーブリック評価の手法を、本番ループに組み込むAPIとして提供する。「成功率+10pt」という数字は、評価ループを学習信号として返すRLAIF的なアーキテクチャを内製しているとみるのが自然だろう。
multiagentは、これまでフレームワーク選定で割れていた領域に決着をつけにきた。AnthropicがすでにブログでマルチエージェントResearch構成を解説していたが、それがManaged Agentsの一級市民になる。
エンジニア視点・技術深掘り
実装影響として注目すべきは、評価レイヤーがAPIに昇格した点だ。outcomesを使う場合、おそらく以下のようなルーブリック定義を渡す形になると推測される（公開仕様の範囲から再構成）。
agent = client.agents.create(
model="claude-sonnet-4.5",
tools=[...],
outcomes={
"rubric": [
{"criterion": "引用元URLが3件以上含まれる", "weight": 0.3},
{"criterion": "判例の年号が正確", "weight": 0.5},
{"criterion": "結論が要約されている", "weight": 0.2},
],
"min_score": 0.8,
"retry_on_fail": True,
},
)
この設計が興味深いのは、評価結果がそのままリトライ制御の信号になる点だ。従来は「LLM出力 → 別のLLMで採点 → 閾値以下なら再生成」というパイプラインを自前で組む必要があったが、それがエージェントランタイムに内蔵される。SREの観点では、エージェントのSLI/SLOを「タスク成功率」で定義できるようになり、ダッシュボードに乗せやすい。
dreamingは、運用面でコンテキスト課金の最適化にも効くはずだ。毎セッション巨大なシステムプロンプトを送りつける運用から、サーバ側で蒸留された長期記憶を参照する運用へ。Prompt Cachingと組み合わせれば、長期運用エージェントのトークンコストは大きく下がる可能性がある。
一方で懸念もある。dreamingで蓄積される長期記憶は、Prompt Injectionの永続化リスクを抱える。悪意ある入力が一度メモリに焼き付くと、以降のセッションすべてに影響しうる。OWASP LLM Top 10のLLM01: Prompt InjectionとLLM03: Training Data Poisoningが地続きになる構図で、メモリ層のサニタイズと監査ログは必須要件になる。
multiagentについては、サブエージェントの権限分離をどう設計するかが鍵だ。親エージェントが持つツールを子に丸ごと渡すと、最小権限原則が崩れる。Capability-based securityの考え方で、サブエージェントごとにツールサブセットを明示する設計が求められる。
経営者/読者として次に取るべき動き
このリリースは、エージェント運用がPoCフェーズから本番運用フェーズに移行する号砲と捉えるべきだ。これまで「面白いけど本番に乗せられない」と保留していた案件は、再評価のタイミングに来ている。
具体的なアクションは3つ。第一に、社内タスクのルーブリック化から始める。outcomesを活かすには、「良い成果物とは何か」を採点表で記述できる必要がある。これは結局、業務マニュアルの解像度を上げる作業であり、AI導入以前のDXとしても価値がある。
第二に、長期記憶を持つエージェントの責任所在を法務・情シスと整理しておく。dreamingでAIが過去案件を学習し続けるなら、退職者が扱った機密情報の取り扱い、顧客データの記憶範囲、GDPR的な忘れられる権利への対応など、論点は多い。
第三に、Harveyのようなドメイン特化AIベンダーの動向を追うこと。汎用基盤の進化を、特定業界の業務フローに翻訳して提供するレイヤーが、今後の主戦場になる。自社で全部内製するか、ドメインSaaSに乗るかの判断は、向こう半年で大きく分かれるだろう。
引き継ぎコストが消え、品質がKPIで測れ、並列委任が標準になる——エージェント運用の前提が、この1リリースで書き換わった。
動画でも詳しく
動画は記事冒頭の埋め込みからフル尺で視聴できます。