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ポイント向上したとのこと。これは地味にすごい数字だと思う。

サーバーラックとクラウドレイヤーが積層された抽象インフラ図

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

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

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

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

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

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

公式データではTTFTがp50で約60%、p95で90%以上削減。OAuthトークンはサンドボックス外のボールトに格納され、Claude生成コードからアクセス不能な設計になっている。スコープ付き権限でツールとデータソースへのアクセスを精密に制御できる。

エンジニアとして、このアーキテクチャの設計意図を読み解くのは面白い。状態管理をSessionに押し出すことで、Brain側をステートレスにしている。マイクロサービスの設計原則がそのまま活きている感じだ。Claude Codeを長く使っていると、サブエージェントが毎回新しいコンテキストで起動するのが当たり前になる。Managed Agentsの3層分離は、その「ステートレスを徹底する」発想を本番ワークロード向けに引き上げた版だと感じる。

ノートPC上のパフォーマンス分析グラフ

料金体系：$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が別途かかる。

公式ドキュメントの数値だけ見ても抽象的なので、自分のClaude Code利用パターンに当てはめて月額を試算してみる。以下はあくまで公式料金から導出した想定計算で、僕がManaged Agentsを丸1ヶ月運用した実測値ではない点は最初に断っておく。

僕のClaude Code利用は MAX プラン（$100/月） で、SaaS開発の支援に毎日2〜4時間使うペース。ここにManaged Agentsを1つ追加するとどうなるかを試算した。

ケース 1: 個人開発の検証用に「夜だけ動かす」エージェント

  • 想定: 1日2セッション × 30分 = 1時間 / 日（実稼働）、月30日
  • ランタイム: 30時間 × $0.08 = 月 $2.40
  • トークン: Sonnet 4.6 で1セッション平均 入力50K + 出力20K と仮定
    • 入力 50K × 30日 × 2 = 3M トークン → $9
    • 出力 20K × 30日 × 2 = 1.2M トークン → $18
    • 合計 約 $27/月
  • 月合計: 約 $30 / 約 4,500 円

ケース 2: 業務でユーザー応答チャネルに常駐させるエージェント

  • 想定: 平日のみ・1日10時間 × 22日稼働、入出力トークンはケース1の3倍
  • ランタイム: 220時間 × $0.08 = 月 $17.60
  • トークン: Sonnet 4.6 で月 21M入力 / 7.2M出力 と仮定 → 約 $171
  • 月合計: 約 $190 / 約 28,500 円

「Claude Code MAX プランをすでに払っているなら、その上に乗せる増分コストはケース1で月$30前後、ケース2で月$190前後」という感覚値。検証用途のケース1なら「試すのを躊躇する金額ではない」と思う。

ここで重要なのは max_budget_usd パラメータでセッション単位の上限を設定できること。例えば「1セッション最大$5」とすれば、暴走しても上限で止まる。組織レベルのスペンドリミットと組み合わせると、想定外の請求は構造的に抑えられる。

なお、上記試算で1セッションの入出力トークン量はあくまで仮置きで、実コストは「system promptの長さ × ツール呼び出し回数 × ループ深さ」で大きく振れる。Claude Codeでも、雑な指示を出した日は1セッションのトークン消費が普段の3〜5倍に跳ねる感覚があるので、Managed Agentsでも同じ振れ幅を覚悟しておきたい。

今すぐ試せる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 / Go等7言語対応。Console・Claude Code・ant CLIの3経路でデプロイできる（ベータヘッダーはSDK使用時に自動付与）。

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

公式Quickstartを読んで設計を予測する：イベントストリームの「クセ」

公式ドキュメントとサンプルコードを実際に読み込んだ上で、実環境で動かしたときに何が起きそうかを、Claude CodeとAgent SDKの運用経験から予測してみる。ここは「実測ログそのもの」ではなく「公式の設計を読み解いた予測判断」として書く。実コストや実測時間で僕自身の運用記録に差し替える作業は、しばらく走らせてからの追記になる。

予測ポイントは3つある。

1. TTFTはMessages APIを直接叩くより体感で速くなりそう

公式が出しているTTFT削減（p50で約60%、p95で90%以上）は、コンテナの事前プロビジョニングコストを排除した設計から来ている。Claude Codeでも、サブエージェント起動時の初動が以前より明らかに速くなった瞬間があったので、Managed Agentsの初回応答も体感で快適になるはずだ。

2. agent.tool_useイベントが想定より細かく流れてくる

Quickstartのサンプルはagent.messageしか拾っていないが、実装はSSEでagent.tool_useも流れる構造になっている。フィボナッチ程度の最小タスクでも、ファイル読み書きやテスト実行のたびにイベントが発火するはず。UIに垂れ流しで出すと「動いてる感」は出るが情報過多になるので、ツールカテゴリでフィルタしてから表示するか、進捗バー的な集約UIに寄せる設計が現実的だと思う。Claude Codeでも--verboseの出力をそのまま見せると人間が追えないので、これと同じ問題が起きる。

3. 詰まったときの一次診断はagent.errorイベントとセッションログ

ローカルでprintデバッグできない以上、Anthropic Consoleのセッションログに行くしかない。Claude Codeで何か変な挙動があったときに「ログ見れば10秒でわかるけど、見ない人は1時間悩む」という現象を何度か見ているので、Managed Agents運用でも**「セッションログを開く」を最初に教えるべき習慣**として位置づけたい。

ここまでが、僕が公式Quickstartを動かす前に立てている予測だ。実際に動かしてみて予測と外れた点があれば、後日この記事に追記して更新する予定だ。

僕のユースケースでの判断軸：Agent SDKとManaged Agents、どっちを選ぶか

Agent SDKとManaged Agentsの使い分けを、自分のユースケース（SaaSの生成AI統合）に当てはめて整理した。これはManaged Agentsの実環境ログではなく、Claude CodeとAgent SDKを実際に運用してきた経験から導いた判断軸だ。

僕が業務で触ってきたのは、Claude Code（ローカル開発支援を3ヶ月以上、毎日2〜4時間）と、Agent SDK（一部の本番ワークロードでツール呼び出しの抽象化に使用）。ここにManaged Agentsを入れるかどうかの判断軸はこうなる。

Managed Agentsを選ぶ条件

  • インフラ運用の人手を削りたい: サンドボックス・コンテナ・トークン管理を自前で持ちたくない。これが一番大きい
  • セッション粒度の従量課金で済むワークロード: 1リクエスト = 1セッションで完結する系（検索、要約、定型分析）
  • 本番までのリードタイムを最短化したい: 「3〜6ヶ月のインフラ構築」を「数日〜数週間」に圧縮したいケース
  • OAuthトークンを自前で安全に保管する自信がない: ボールト分離設計に乗せる方が事故リスクが低い

Agent SDKを選ぶ条件

  • ランタイムを完全に握りたい: モデル呼び出しの前後に独自のバリデーション・ロギング・PII マスキングを差し込みたい
  • 既存のサンドボックス環境がすでにある: Docker / k8s 上で動く既存のジョブ基盤があり、そこに乗せるだけで済む
  • データ滞留をAnthropic外に保ちたい: 法務・財務・医療データなど、外に出せない情報を扱う
  • モデルを混ぜて使う前提がある: GPTやGeminiにフォールバックする設計を想定するなら、ランタイム側で抽象化しておかないと辛い

現業務での暫定解は「ローカルはClaude Code、本番のコア処理はAgent SDKで握ったまま、ユーザー向け直接応答チャネルだけManaged Agentsを試す」が現時点の妥当解だと思っている。応答チャネルはセッション粒度で完結しやすく、ボールト分離の恩恵が大きいから、最初の一手としては筋がいい。

逆に、機密データを触る基幹側にいきなりManaged Agentsを入れるのは、データ滞留の制御が読み切れないうちは保留したい。

ハマりやすいポイント：Claude Codeを3ヶ月使った僕からの注意点

リスク話の最後に、Claude Codeを3ヶ月使ってきた自分から見て「Managed Agentsで同じ轍を踏みそうな点」を3つ挙げておく。これらはManaged Agents固有の実測ではなく、Claude Code運用で実際に詰まった経験を、Managed Agentsの設計と料金体系に当てはめて予測した注意点だ。

1. system promptが雑だとセッションがダラダラ伸びてコストが膨らむ

ゴールが曖昧な指示だとモデルが探索を始めてツール呼び出しが何往復も走る。セッション時間にも課金されるManaged Agentsではsystem promptの質が直接コストに効く。Claude Codeでも「曖昧に頼んだ日のトークン消費が普段の3〜5倍」という感覚があるので、Managed Agentsで同じことをやると$0.08/時間のランタイムも合わせてダブルで効く。「何を達成したら終わりか」を最初に明示しておくこと。

2. ツール権限をunrestrictedで始めて後から絞れなくなる

networking: unrestrictedで動かし始めると楽だけど、本番移行時に「このドメインだけ許可」という要件が必ず出る。最初から必要最小許可で始めて広げる方が後で楽。Claude Codeでも、いきなり全許可で動かしていたBashコマンドを後からホワイトリスト化するのに苦労した経験がある。Managed Agentsのnetworking設定も、最初に絞っておけば後の監査が桁違いに楽になる。

3. Sessionのイベントログを「読む文化」を作っておかないとデバッグが詰む

エンジニアがイベントログを読む習慣がないと、不具合時に「Claudeが悪い」で止まる。Claude Codeの--verboseを見る習慣が、agent.tool_use / agent.errorイベントを読む習慣に直結する。チームに導入する時は「変だと思ったらまずConsoleのセッションログを開く」を最初のオンボーディングに入れたい。

この3つは、僕が実環境で運用してから「やっぱり想定通りだった / 想定外だった」を後で答え合わせする予定の項目だ。

AIエージェント導入を進めるチームのコラボレーション空間の俯瞰

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

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

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

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

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

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

その他の採用事例

公式ブログには、Notion（チームタスクの並列委任・協働）、Sentry（バグ検出からパッチ・PR作成をワンフロー化）、Asana（AI Teammatesでプロジェクト内協働）、Vibecode（プロンプト→デプロイを10倍速化）の採用例が挙げられている。共通しているのは「数カ月かかっていた統合を数週間に圧縮した」という導入リードタイムの短さで、Managed Agentsの売りである「インフラ構築をスキップする」効果が事例ベースで裏付けられている形だ。

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系統ある。OpenAI Agents SDK（ハンドオフ型・Pythonのみ・フルマネージドなし）やGoogle ADK（OSS・多言語・Gemini以外も可）などプロバイダーネイティブ系と、LangChain / CrewAIなどモデル非依存だがインフラ自前の独立FW系だ。

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/時間 + トークンコストの従量課金で、僕の試算ではケース1で月$30前後・ケース2で月$190前後の増分
  • Brain/Hands/Sessionの3層分離アーキテクチャでパフォーマンスと信頼性を両立
  • 楽天は各部門エージェントを週単位でデプロイ。従来の数カ月から劇的に短縮
  • Agent SDKとの使い分けは「インフラ運用人手の有無」「データ滞留要件」で切る。応答チャネルから試すのが筋
  • ベンダーロックイン、コスト予測、データプライバシーのリスクは要考慮
  • 最強機能（マルチエージェント・Outcomes・メモリ）はまだリサーチプレビュー

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

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

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

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

参考リンク