こんにちは、Lena です。Anthropic の発表を読み終えた後、しばらくそのタブを開いたままにしていました。何か分からないことがあったわけではありません——実際、あのドキュメントは珍しいほど明快でした。ただ、彼らが引いている境界線をじっくり考えたかったのです。新しいモデルではない。その点はすぐに理解できました。でも、もう何度か読み返してようやく、それが実際に何であるか、そしてもっと有用なこととして、何であろうとしていないかが見えてきました。
以下が、私なりにまとめた内容です。
Claude Managed Agents の正体
サンドボックスランタイムであり、新モデルではない
最初にはっきり言っておくべきことがあります。Claude Managed Agents はインフラストラクチャ層であり、モデルのアップグレードではありません。 これは Anthropic がホストするエージェントランタイム——あなたのコードと、すでに使っている Claude モデルの間に位置するマネージド環境です。
Claude Managed Agents は、Claude を自律エージェントとして実行するためのハーネスとインフラを提供します。自前でエージェントループ、ツール実行、ランタイムを構築する代わりに、完全にマネージドされた環境が手に入ります。その中で Claude はファイルの読み取り、コマンドの実行、Web ブラウジング、コードの実行を安全に行えます。
私の理解はこうです。あなたがエージェントの役割を定義し、Anthropic がそれを動かすために必要なすべてを引き受ける。サンドボックスコンテナ、セッション管理、ツール実行、エラーリカバリ、コンテキスト処理——これは本番エージェントを構築する「もう一つの仕事」、知能とは関係なく、ほとんどのチームが正しく作るのに3〜6ヶ月かかる部分です。Managed Agents はその負担を取り除いてくれます。
Sessions、Environments、そして Agent Harness
最初に理解しておくべき4つの概念があります。Agent はモデル、システムプロンプト、ツール、MCP Server、スキルの組み合わせで、一度定義して ID で参照します。Environment はパッケージがプリインストールされ、ネットワークアクセスルールが設定されたクラウドコンテナです。Session はあなたの Agent と Environment を参照するランタイムインスタンスです。そして Harness は、Anthropic がこれらすべてを調整する管理レイヤーと呼んでいるものです。
Anthropic のエンジニアリングチームはこれを「meta-harness」と表現しています。特定の実装よりも長く存続するよう設計されたインターフェースを中心に構築されたホスティングサービスです。Harness は Claude に何ができないかについての前提をエンコードしており、モデルが進化するにつれてその前提は古くなります。
この設計思想は興味深いと思います。彼らは今日のインフラ問題だけを解決しているのではありません。Anthropic が新しいモデルをリリースするたびにエージェントコードが壊れないよう、十分に安定した抽象化レイヤーを構築しようとしています。たとえば session log は、Claude のコンテキストウィンドウの外側にある永続的なコンテキストオブジェクトとして機能し、長時間実行タスクに脆いメモリ内状態ではなくリカバリポイントを提供します。
Managed Agents が解決すること
サンドボックスと安全なツール実行
これは本物であり、重要です。各セッションは隔離された Linux コンテナで実行されます。エージェントはファイルの読み取り、bash コマンドの実行、コードの実行が可能で、設定可能なネットワークアクセスルールのもと、サンドボックスから脱出するリスクはありません。これを自分で構築しようとしたことのあるチームなら、どれほどのエンジニアリングが必要かよく分かるでしょう。本番環境で間違えると、本当に深刻な結果になります。
エージェントは安全なサンドボックス環境で実行されます。認証、ツール実行、シークレット管理は Anthropic のインフラが処理します。サーバーのプロビジョニングや実行分離コードの記述は不要です。
チェックポイント付きの長時間実行セッション
セッションはネットワーク切断後も存続します。マルチステップの調査タスクが、ステップ34で接続が切れたりレート制限に達したりしても、最初からやり直しにはなりません。進捗と中間出力はセッションイベントログに保存されます。数分から数時間にわたるタスク——専用インフラなしでは確実に構築することがほぼ不可能な種類の作業——に対して、Managed Agents はまさにこの問題を直接解決します。
スコープ付き権限と実行トレース
すべてのツール呼び出し、すべての判断、すべての出力が Claude Console で追跡可能です。 スコープ付き権限により、エージェントがアクセスできるツールとデータソースを正確に定義できます。規制産業でエージェントを構築している方、機密システムに関わるエンタープライズワークフローに携わっている方にとって、これはあると便利なレベルではなく、構造を支える核心機能です。
Multi-Agent 協調（Research Preview——ここは明確に注記します）
この項目は慎重な表現が必要です。Multi-agent 協調——あるエージェントが他のエージェントを起動・指揮して複雑な作業を並列処理する機能——は機能として記載されています。しかし、2026年4月8日のパブリックベータ開始時点では、outcomes、multiagent、memory を含む一部機能は research preview 段階であり、別途アクセス申請が必要です。
これは小さな注意書きではありません。multi-agent 協調をリリース済み機能として紹介している記事をいくつか見ましたが、そうではありません。あなたのアーキテクチャがエージェントの自律的な生成に依存しているなら、今日その前提で本番システムを構築しないでください。 Research preview へのアクセスを申請し、機能が成熟するまでは不安定な能力として扱ってください。
Managed Agents が解決しないこと
このセクションは、はっきり考え抜くのに最も時間がかかりました。このプロダクトは自身が行うことにおいて本当に優れています。だからこそ、設計の範囲外のことまで期待してしまいやすいのです。
セッション間の能力永続化——実行が終われば、学習も終わる
Managed Agents のセッションが完了すると、環境はエフェメラル（一時的）です。コンテナはシャットダウンします。エージェントがその実行中に学んだこと、改善したこと、発見したことは、次のセッションに引き継がれません。 次のセッションは、同じ初期エージェント定義から始まります。
セッション A でエージェントが成功した戦略が、セッション B で自動的に利用可能になるメカニズムはありません。Claude が特にエレガントな方法でやっかいなマルチステップデバッグ問題を解決した場合、そのソリューションはセッションログに残ります——レビューのために参照できますが、再利用可能な能力として伝播されることはありません。読み返すことはできます。手動で抽出することもできます。しかし、ネイティブな継承パスは存在しません。
これはインフラがインフラとしての役割を果たしているということです。セッションを確実に実行し、そして閉じる。 進化レイヤーであるとは主張していません。これは批判ではありません。明確に理解すべき設計上の境界です。
エージェント間の継承——共有可能な再利用資産のメカニズムがない
セッションの永続化とは別の話として、Managed Agents には、あるエージェントの検証済み能力をシステム内の他のエージェントが利用できるようにするメカニズムがありません。エージェント間ではデフォルトで何も共有されません。各エージェント定義は隔離されています。チーム内の3つのエージェントすべてが共通のデバッグ戦略から恩恵を受けられる場合でも、その戦略は3つ存在することになります——3回定義され、3回メンテナンスされ、3回改善されます。
これがスケールするチームにとって何を意味するのか、まだ完全には整理できていません。ランダムではないように感じます。解決可能な問題のように感じます。しかし Managed Agents はこれに対処しておらず、正しい境界がどこにあるのか、私もまだ完全には見えていません。
進化ライフサイクル——検証・昇格・ガバナンスレイヤーがない
Managed Agents には実行に対するガバナンスがあります。スコープ付き権限、実行トレース、サンドボックス。ないのは能力の進化に対するガバナンスです。「この戦略は40回成功したので昇格すべき」という検証メカニズム、「セッション内でテスト済み」から「エージェント定義の一部」への昇格パス、能力が時間とともにどう発展したかの系譜追跡——これらがありません。
これは同じ大きな問題の2つの異なるレイヤーです。インフラがガバナンスするのは、エージェントが1回の実行で何をしたかです。進化がガバナンスするのは、エージェントの能力が時間とともにどう変化し改善されるかです。Managed Agents は第1のレイヤーを意図的にうまく解決しています。第2のレイヤーは未解決のままです。
マネージド実行 vs 能力進化
同じ問題の2つの異なるレイヤー
ここを正確に表現してみたいと思います。個々の機能よりもフレーミングのほうが重要だと感じているからです。
Managed Agents は実行インフラです。その仕事は、エージェントの実行が安全で、観測可能で、回復可能で、スケーラブルであることを保証することです。この点は非常に優れています。Anthropic のエンジニアリング記事は、特定の実装よりも長く存続するよう設計された安定したインターフェースを中心に設計を説明しています。将来のハーネスやモデルの改善に対応できるよう構築されています。
能力進化は別のレイヤーです。エージェントが実行間、チーム間、デプロイメント間で成功した行動をどう蓄積し、検証し、共有し、継承するか。そのレイヤーはマネージドランタイムの中にはありません。あり得ません——異なるタイムスケールで異なる問題を解決しているからです。
インフラの解決が進化ギャップの解決にならない理由
私が繰り返し気づくギャップはこうです。セッションが終了し、何かがうまく機能した。それはどこに行くのか？セッションログの中です。復元可能です。しかし次の実行に自動的に反映されるわけではありません。他のエージェントと共有されるわけでもありません。何らかの適応度基準に照らして検証され昇格されるわけでもありません。
これはマネージドインフラの失敗ではありません。技術スタックの異なるレイヤーにあるギャップです——Managed Agents が埋めるよう設計されたことのないギャップです。この区別は重要です。Managed Agents に能力の再利用を期待して構築するチームはその壁にぶつかり、なぜなのかすぐには理解できないでしょう。ランタイムは完璧に動作しています。問題は、その上に進化レイヤーが欠けていることです。
Managed Agents を使うべきチーム
最適：本番エージェントランタイムを自前で構築せずに手に入れたいチーム
ボトルネックがインフラにある場合——エージェントの出荷前にサンドボックス、セッション管理、リトライロジック、実行トレースの構築に何ヶ月も費やしている場合——Managed Agents は正しい問題を解決しています。Claude Managed Agents の課金はトークンとセッションランタイムの2軸で、アクティブランタイム1セッション時間あたり $0.08、ミリ秒単位で計測されます。アイドル時間はランタイムにカウントされません。長時間実行ワークロードの場合、自前構築と比較してコスト構造は妥当です。
Notion、Rakuten、Asana、Sentry を含む初期採用者がすでに本番ユースケースを稼働させています。Rakuten は各スペシャリストエージェントを1週間以内にデプロイしたと報じられています。これはインフラが機能している証です。
能力の再利用がボトルネックなら最適ではない
問題がエージェントの同じソリューションの繰り返し発見、実行間やチームメンバー間での成功戦略の非伝播、有効なものを検証・昇格する手段の欠如にあるなら、Managed Agents はそれを解決しません。ランタイムは確実に動作し、進化ギャップはそのまま残ります。
制限とトレードオフ
ベータステータスは現実のものです。 すべてのリクエストに managed-agents-2026-04-01 ベータヘッダーが必要であり、出力を改善するためにリリース間で動作が変更される可能性があります。Anthropic はハーネスの動作方法を変更する権利を留保しています。変更に対処する計画を持って構築してください。
データは Anthropic のインフラを通過します。 機密性の高いワークロード——法務文書、財務記録、プロプライエタリコード——では、すべてのツール呼び出しと判断が Anthropic のクラウドで実行されます。エンタープライズティアにはデータプライバシーに関するコミットメントがあります。それが許容可能かどうかは、具体的なコンプライアンス要件次第です。
ロックインは認識に値します。 Managed Agents は Claude 専用です。アーキテクチャにプロバイダーの柔軟性やマルチモデルルーティングが必要な場合、Claude Agent SDK または Messages API の直接使用がより多くの制御を提供します。
よくある質問
Claude Managed Agents とは何ですか？
2026年4月8日にパブリックベータとして開始されたマネージドインフラストラクチャ層です。Anthropic のクラウドで稼働する、プリビルトかつ設定可能なエージェントハーネスを提供し、サンドボックス実行、セッション永続化、ツールオーケストレーション、実行トレースを処理します。新しいモデルではありません。
Claude Managed Agents の料金はいくらですか？
すべてのモデル推論に標準の Claude API トークン料金が適用され、さらにアクティブランタイム1セッション時間あたり 10 で課金されます。意思決定前に Anthropic の公式料金ページで最新の料金を確認してください——これらの数字は変更される可能性があります。
Claude Managed Agents はセッション間で学んだことを記憶できますか？
できません。セッションは隔離されています。エージェント定義は永続化され ID で参照されますが、ランタイム環境はエフェメラルです。セッション中に開発された能力や戦略は、次のセッションに自動的に引き継がれません。セッション間メモリは research preview 機能として記載されており、別途アクセス申請が必要です。デフォルトでは利用できません。
Claude Managed Agents と Claude Code の違いは何ですか？
異なるプロダクトが異なる問題を解決しています。Claude Managed Agents は大規模な本番エージェントデプロイのためのホステッド API ランタイムです。Claude Code はローカルのコーディングワークフローツールです。Anthropic のドキュメントは、パートナーに対して Managed Agents を Claude Code やその他の Anthropic ファーストパーティ製品としてブランディングしないよう明確に警告しています。
Claude Managed Agents はマルチエージェントワークフローをサポートしていますか？
2026年4月の開始時点で、Multi-agent 協調は research preview 段階であり、別途アクセス申請が必要です。一般パブリックベータには含まれていません。アクセスを確認し機能が成熟するまで、この能力の安定性や可用性を前提とした本番システムの設計は避けてください。
research preview 機能の発展は引き続き注視していくつもりです。「multi-agent 協調が存在する」と「multi-agent 協調が準備できている」の間のギャップは意味があります。特に memory 機能は、セッション間の能力永続化について何を意味するか（あるいは意味しないか）という点で、最も注目に値するものだと思います。この部分はまだ完全には定まっていないように感じます。
