Claude Managed Agentsとは？今すぐ試すべき理由

AIエージェントを本番環境に持っていく、あの「壁」

Claude Codeを毎日使っていると、エージェントの可能性は嫌というほど感じる。

ローカルでプロトタイプを作って動かす分には、もう本当に快適なんだよね。コードを書かせて、ファイルを操作させて、テストを回す。「おお、これもうほぼ自動じゃん」ってなる瞬間がある。

でも、そこから先が問題だ。

「これをプロダクションで動かしたい」と思った瞬間に、壁にぶち当たる。サンドボックスの設計、認証情報の管理、エラーハンドリング、コンテキストの永続化。やるべきことが一気に積み上がって、3カ月から6カ月のインフラ構築が必要になる。

プロトタイプはできた。でも本番までが果てしなく遠い。

エージェント開発をやったことがある人なら、この感覚はわかると思う。僕自身、Claude Codeを使い始めた時の衝撃は今でも覚えているけど、チームで使えるようにしようとなった時のギャップには正直参った。

2026年4月8日、Anthropicがそのギャップを埋めるための新しいプラットフォームを発表した。Claude Managed Agentsだ。公式発表は開発者コミュニティとSNSで大きな反響を呼んだ。

この記事では、Managed Agentsとは何か、どう始めるか、そして冷静に見るべきリスクまでを一通り整理してみる。

Claude Managed Agentsとは何か

その壁を壊すために登場したのが、Claude Managed Agentsだ。

一言でいうと、AIエージェントを大規模に構築・展開するためのフルマネージドプラットフォーム。開発者はエージェントのタスク、ツール、ガードレールを定義するだけ。ツールオーケストレーション、コンテキスト管理、エラーリカバリはすべてAnthropicのインフラが処理してくれる。

わかりやすく言えば、完全装備のキッチンを借りるようなもの。食材とレシピ（タスクとプロンプト）は自分で用意するけど、オーブンも冷蔵庫も換気扇も全部セットアップ済み。いきなり料理に取りかかれる。

Managed Agentsは4つの主要コンセプトで構成されている。

• Agent: モデル、システムプロンプト、ツール、MCPサーバー、スキルの定義。いわばエージェントの「設計図」
• Environment: コンテナテンプレート。パッケージやネットワークアクセスの設定を含む「実行環境の仕様」
• Session: 実行中のエージェントインスタンス。AgentとEnvironmentを組み合わせて起動する
• Events: アプリケーションとエージェント間のメッセージ交換。SSEストリームでリアルタイムにやり取りできる

一度Agentを作成すればIDで参照でき、複数のSessionで再利用可能。Environmentも同じだ。つまり「設計図」と「実行環境」を使い回せる仕組みになっている。

Anthropicの内部テストでは、構造化ファイル生成タスクにおいてタスク成功率が標準的なプロンプティングループより最大10ポイント向上したとのこと。これは地味にすごい数字だと思う。

Photo by Taylor Vick on Unsplash

Brain/Hands/Sessionの3層アーキテクチャ

Managed Agentsの概要がわかったところで、その内部設計を見てみよう。ここが個人的に一番面白いところだと思っている。

Anthropicのエンジニアリングブログで公開された3層分離アーキテクチャがある。

• Brain（脳）: Claudeモデルとハーネス。思考と意思決定を担当
• Hands（手）: サンドボックスとツール。実際の作業を実行
• Session（記録）: append-onlyのイベントログ。すべてのやり取りを永続的に記録

この3つを完全に分離したのが設計のキモだ。

従来のエージェントは「ペット」だった。一体型で、状態を内部に持っていて、壊れたら復旧が大変。Managed Agentsはそれを**「キャトル」**に変えた。各コンポーネントが独立しているから、交換可能でスケーラブル。Brainが落ちても、Sessionに全履歴が残っているから、新しいBrainインスタンスが引き継げる。

パフォーマンス面でも成果が出ている。TTFT（Time-to-First-Token、最初のトークンが返るまでの時間）がp50で約60%削減、p95では90%以上削減を達成している。コンテナの事前プロビジョニングコストを排除し、必要な時にオンデマンドで立ち上げる設計によるものだ。

セキュリティ面では、認証情報の扱いが特に重要。OAuthトークンはサンドボックス外のセキュアボールトに保管され、MCPツールは専用プロキシ経由でボールトからトークンを取得する。つまり、トークンはClaudeの生成コードが実行されるサンドボックスからは決して到達できない。スコープ付き権限でツールとデータソースへのアクセスを精密に制御できるのも安心感がある。

エンジニアとして、このアーキテクチャの設計意図を読み解くのは面白い。状態管理をSessionに押し出すことで、Brain側をステートレスにしている。マイクロサービスの設計原則がそのまま活きている感じだ。

Photo by Unsplash on Unsplash

料金体系：$0.08/時間の実際のところ

アーキテクチャの次に気になるのは、やっぱりコストだろう。

Managed Agentsの料金は2層構造になっている。

1. ランタイム費用

アクティブなセッション時間1時間あたり**$0.08（約13円）**。次のメッセージやツール使用の確認を待つアイドル時間は非課金。つまり、エージェントが実際に動いている時間だけ課金される。

2. トークンコスト

通常のClaude Platformと同じレートが適用される。

• Claude Sonnet 4.6: 入力$3 / 出力$15（100万トークンあたり）
• Claude Opus 4.6: 入力$5 / 出力$25（100万トークンあたり）
• Claude Haiku 4.5: 入力$1 / 出力$5（100万トークンあたり）

Web検索を使う場合は1,000回あたり$10が別途かかる。

具体的なコスト感でいうと、こんな感じだ。

• 24時間365日稼働のエージェント: ランタイムだけで月約$58（約8,700円）。トークンコストは別途
• 典型的な4〜6時間のセッション: モデル使用料含めて$1.50〜$3.50程度
• 月額固定費はゼロ。完全従量課金

個人開発者の感覚でいうと、これは「試してみるのに躊躇しない金額」だと思う。$1.50で4時間のセッションなら、ちょっとした検証にはちょうどいい。

コスト制御の仕組みも用意されている。max_budget_usdパラメータでセッションごとの支出上限を設定でき、組織レベルでのスペンドリミットも設定可能。暴走を防ぐセーフティネットがあるのは重要なポイントだ。

今すぐ試せるQuickstart：PythonでManaged Agentを動かす

コスト感がわかったところで、実際に手を動かしてみよう。

公式Quickstartドキュメントを参考に、Python SDKでの基本的な流れを紹介する。4ステップで動かせる。

Step 1: Agentを作成する

from anthropic import Anthropic
 
client = Anthropic()
 
agent = client.beta.agents.create(
    name="my-first-agent",
    model="claude-sonnet-4-6",
    system="あなたは優秀なソフトウェアエンジニアです。"
           "与えられたタスクを丁寧に、コードを書いて解決してください。",
    tools=[{"type": "agent_toolset_20260401"}],
)
print(f"Agent ID: {agent.id}")

agent_toolset_20260401を指定すると、Bash、ファイル操作（read/write/edit/glob/grep）、Web検索・フェッチなどのビルトインツールが一括で有効になる。

Step 2: Environmentを作成する

environment = client.beta.environments.create(
    name="my-env",
    config={
        "type": "cloud",
        "networking": {"type": "unrestricted"},
    },
)
print(f"Environment ID: {environment.id}")

ネットワークアクセスはunrestrictedか、特定ドメインのみに制限するかを選べる。

Step 3: Sessionを開始する

session = client.beta.sessions.create(
    agent=agent.id,
    environment_id=environment.id,
)
print(f"Session ID: {session.id}")

Step 4: メッセージを送信してストリームを受信する

with client.beta.sessions.events.stream(
    session_id=session.id,
) as stream:
    stream.send(
        event={
            "type": "user_event",
            "content": [
                {
                    "type": "text",
                    "text": "Pythonでフィボナッチ数列を計算する関数を書いて、"
                            "テストも作成してください。",
                }
            ],
        }
    )
    for event in stream:
        if event.type == "agent.message":
            print(event.data.content)

SSEストリームでagent.message、agent.tool_use、session.status_idleなどのイベントをリアルタイムに受信できる。

ここで一つ大事なことがある。Claude Codeを使っていて僕が実感しているのは、ゴールを明確にして壁打ちすることで精度が劇的に上がるということ。これはManaged Agentsのsystem prompt設計でもまったく同じだ。「何をさせたいか」を曖昧にすると、エージェントも迷走する。むしろ自律的に動く分、初期設計の重要性はさらに増す。

SDKはPython、TypeScript、Java、Go、C#、Ruby、PHPの7言語に対応している。デプロイ手段もClaude Console（Web UI）、Claude Code、新しいant CLI（Go製）の3つから選べる。

なお、すべてのAPIエンドポイントにはmanaged-agents-2026-04-01ベータヘッダーが必要だが、SDKを使う場合は自動で設定される。

注意点として、現在パブリックベータで利用できるのは上記の基本機能だ。マルチエージェント協調、Outcomes（自己評価・反復）、永続メモリの3つはリサーチプレビュー段階で、別途アクセス申請が必要になる。「今すぐ使えるもの」と「今後期待されるもの」を混同しないようにしておきたい。

Photo by Marvin Meyer on Unsplash

楽天・Notion・Sentryの採用事例から見える可能性

コードを書いて動かせるようになったところで、実際に企業がどう使っているのか見てみよう。

楽天：各部門専用エージェントを約1週間でデプロイ

日本のエンジニアとして、これは素直に驚いた事例だ。

楽天はSlackとMicrosoft Teamsに連携するエンタープライズエージェントを展開している。プロダクト、営業、マーケティング、財務、人事の各部門向けに専門化されたエージェントを、それぞれ約1週間でデプロイしたという。公式ブログに詳細が記載されている。

従業員はタスクを割り当て、スプレッドシートやスライド、アプリといった成果物を受け取れる。従来なら数カ月かかっていた統合を、週単位で実現している。日本を代表するテック企業がこの速度で採用しているのは、正直驚きだった。

Notion：数十タスクの並列実行

NotionはCustom Agentsを通じて、チームがClaudeに直接作業を委任できる仕組みを構築した。エンジニアはコードを書かせ、ナレッジワーカーはWebサイトやプレゼンテーションを作成させる。数十のタスクを並列で実行し、チーム全体でアウトプットに対して協働作業が可能になっている。

Managed Agentsの長時間セッション、メモリ管理、高品質出力機能をフル活用している例だ。

Sentry：バグ検出からPR作成まで一気通貫

Sentryはデバッグエージェント「Seer」とClaude連携で、バグの検出からパッチ作成、PRオープンまでをワンフローで実行する仕組みを作った。開発者はフラグ付きバグからレビュー可能な修正までをワンアクションで完結できる。

従来数カ月かかった統合を数週間で実現したとのこと。

他にもAsanaはAI Teammatesを構築し、プロジェクト内で人間と協働するエージェントを実現している。VibecodeはManaged Agentsをデフォルト統合として採用し、プロンプトからデプロイ済みアプリまでのプロセスを以前の10倍の速度で提供している。

Agent SDK・競合との使い分け：エンジニアの選択基準

Managed Agentsの実力は見えてきた。でも、既にAgent SDKを使っている人や、OpenAIやGoogleのSDKを検討している人は「結局どれを使えばいいの？」と思うだろう。

まず、Managed AgentsとAgent SDKの位置づけを整理しよう。

• Managed Agents: フルマネージドのエージェント実行環境。Anthropicがインフラ全体を管理する。「完全装備のキッチンを借りる」イメージ
• Agent SDK: 同じエンジンを自分のインフラで動かすライブラリ。ランタイムの完全制御が可能。「業務用オーブンとフライヤーを自宅に届けてもらう」イメージ
• Messages API: 直接的なモデルアクセス。カスタムエージェントループと細かな制御に最適

Managed Agentsは数時間の本番ワークロード向け。Agent SDKはランタイムの完全制御が必要な場合に向いている。MCPプロトコルでツールエコシステムが共通化されているので、どちらを選んでもGitHub、Jira、Slack、Google Driveなど同じツール群にアクセスできる。

ちなみに、Claude Code SDKはClaude Agent SDKに改名されている。

次に競合との比較。エージェントフレームワークの構図は大きく2つに分かれる。

プロバイダーネイティブSDK（Claude、OpenAI、Google）

• OpenAI Agents SDK: ハンドオフモデルによるマルチエージェントオーケストレーションとRealtime API経由のボイスエージェントが強み。ガードレールも組み込み。ただしPythonのみ対応で、フルマネージドインフラは提供していない
• Google ADK + Vertex AI: オープンソースで4言語対応。Gemini以外のモデルもアダプター経由で接続可能。A2A Agent Cardsでクロスチームのエージェント発見が可能。ただしOSレベルのエージェントツールはManaged Agentsほど充実していない

独立フレームワーク（LangChain、CrewAI、AutoGen等）

モデル非依存でベンダーロックインなし。ただしインフラ構築は全部自前。本番までの時間がかかる。

Managed Agentsの独自ポジションは「プロバイダーネイティブかつフルマネージド」という点にある。MCPエコシステムの豊富さとOSレベルのツールアクセスは、現時点で他にない強みだと思う。

AI時代のエンジニアとして大事なのは、特定のフレームワークに全振りしないことだと考えている。ユースケースに応じて最適なツールを選べることが、結局一番の生存戦略になるんじゃないかな。

なお、マルチエージェント協調・Outcomes・永続メモリはまだリサーチプレビューで、利用には別途アクセス申請が必要だ。

冷静に見るべき懸念点：ベンダーロックイン・コスト・セキュリティ

ここまでメリットを中心に見てきたけど、当然リスクもある。僕はこういう新技術こそ冷静に見るべきだと思っている。

ベンダーロックインの深さ

Managed AgentsはClaude専用だ。GPT-5、Gemini、Deepseek、Kimi K2など他のモデルは利用できない。Anthropicのインフラ上でエージェントを構築すると、セッションフォーマットやコンテナ仕様への依存が生まれ、移行コストが高くなる。

Hacker Newsでは「勝者総取りのエージェントがない限り、最良のオーケストレーションはミックスになる」という意見も出ている。単一ベンダーに依存するリスクは、エージェントプラットフォームでも変わらない。

コスト予測の難しさ

ランタイム費用は月$58で安く見えるが、トークンコストが別途かかることを忘れてはいけない。大規模なエージェントフリートを運用する場合、トークン消費が主要なコストドライバーになり得る。Web検索の1,000回あたり$10も、リサーチ系エージェントでは無視できない額になる可能性がある。

max_budget_usdでセッション単位の上限は設定できるが、組織全体での予測が難しいのは事実だ。

データプライバシーの懸念

すべてのツールコールと意思決定がAnthropicのインフラを経由する。法務文書、財務記録、プロプライエタリコード、患者データなど機密性の高い情報の処理には慎重になるべきだろう。

なお、2026年3月のClaude Codeソースコード流出により発覚した「Undercover Mode」も議論を呼んだ。これはManaged Agentsの機能ではなく、Claude Codeの内部機能で、Anthropic従業員がパブリックリポジトリで作業する際にAI帰属（Co-Authored-Byなど）を自動除去する仕組みだ。一般ユーザーには適用されないが、AI生成コードの透明性をめぐる議論として注視すべきトピックではある。

本番実績の浅さ

パブリックベータ開始から間もない。楽天やNotionなど大手の初期採用事例はあるが、数カ月にわたる本番運用の信頼性はまだ証明されていない。

さらに重要なのは、マルチエージェント協調とOutcomes（自己評価・反復）という最も強力な機能がまだリサーチプレビューのままだということ。パブリックベータに含まれていない。Hacker Newsのディスカッションでは、プロトタイピングツールとしての評価がある一方で、エージェントへの過度な依存を懸念する声も上がっている。

ゴールを明確にするのが大事だという話をしたけど、リスクを把握した上で使うのもゴール設計の一部だと僕は思う。「何ができて、何がまだできないか」を理解してから手を動かすのが、結局一番効率がいい。

まとめ：Managed Agentsの理解と、最初の一歩

リスクを把握した上で、じゃあエンジニアとして今何をすべきか。

この記事のポイントを整理すると、こうなる。

• Managed Agentsは「プロトタイプから本番環境まで」のギャップを埋めるフルマネージドプラットフォーム
• 料金は$0.08/時間 + トークンコストの従量課金で、小規模から始められる
• Brain/Hands/Sessionの3層分離アーキテクチャでパフォーマンスと信頼性を両立
• 楽天は各部門エージェントを週単位でデプロイ。従来の数カ月から劇的に短縮
• ベンダーロックイン、コスト予測、データプライバシーのリスクは要考慮
• 最強機能（マルチエージェント・Outcomes・メモリ）はまだリサーチプレビュー

読者への具体的なアクションとしては、こんな感じだと思う。

• まず公式Quickstartで小さなエージェントを動かしてみる
• 小さなタスクから始めてコスト感を掴む。max_budget_usdで上限を設定しておくと安心
• Agent SDKとの使い分けは自分のユースケースで判断する。フルマネージドが欲しいか、ランタイムの完全制御が欲しいか

Claude Codeで培った「ゴールを明確にする」スキルは、Managed Agentsでもそのまま活きる。むしろ自律的に動くエージェントだからこそ、最初のsystem prompt設計、つまり初期設計の質がすべてを左右する。

試してみる価値はあると思う。選択肢として知っておくべきプラットフォームであることは間違いない。

参考リンク

• Claude Managed Agents 公式ブログ記事 — Anthropicによる公式発表。概要、採用事例、ロードマップが網羅されている
• Managed Agents Quickstart（公式ドキュメント） — Python SDKでの実装手順を含む公式ガイド
• Scaling Managed Agents: Decoupling the brain from the hands（エンジニアリングブログ） — Brain/Hands/Sessionの3層アーキテクチャの技術的詳細
• Claude Platform 料金ページ — ランタイム費用・トークンコストの最新情報
• Hacker News ディスカッション — 開発者コミュニティの率直な反応と議論