大規模にエージェントを構築する Claude Managed Agents を試してみた

クラウドホスト型エージェントを大規模に構築・展開するためのサービスである Claude Managed Agents がパブリックベータとしてリリースされました。Claude Managed Agents は Claude を自律的なエージェントとして動作させるためのハーネスとインフラストラクチャーを提供します。長時間かかるタスクや非同期のタスクを実行するために使用するのが想定されています。

自律的に動作するエージェントを動かす環境を作ろうとすると、安全なサンドボックス環境・エージェントの状態を保存するためのストレージ・エージェントの状態を監視するためのモニタリングツール・アクセス権限など、様々な開発工数がかかります。Managed Agents を使用することで、これらのインフラストラクチャーを構築する必要がなくなり、ユーザーに価値を提供するという本質的な開発に集中できます。Managed Agents は AI モデルとして Claude 専用に開発されており、Claude の能力を最大限に引き出すための最適化が施されています。

この記事では実際に Claude Managed Agents を試してみた内容を紹介します。この記事を読むと、Claude Managed Agents の基本概念を把握し、Claude Console でセッションを開始して、GitHub リポジトリに接続したエージェントに実務的なタスクを依頼する流れをひととおり追えるようになります。

:::info Claude Managed Agents は従量課金制のサービスです。通常の Claude API のトークン使用量に加えて、セッションが running 状態だった時間に対して 1 セッション時間あたり 0.08 ドルが加算されます。idle や terminated の時間は課金対象に含まれません。料金の詳細はドキュメントを参照してください。 :::

Claude Managed Agents を始める

まずは Claude Managed Agents の基本的な操作感をつかむために、Claude Console 上でエージェントの作成からセッションの開始までを順番に試してみます。

Claude Managed Agents は Claude Console もしくは SDK を使用して API 経由で利用できます。/v1/agents エンドポイントでエージェントを作成し、/v1/sessions エンドポイントでセッションを開始するといった形です。Claude Console を使用する場合、エージェントの作成からセッションの開始までの一連の流れを UI 上で対話形式で進めることができます。

ここでは Claude Console を使用して利用する方法を紹介します。Claude Managed Agents のクイックスタートガイドにアクセスすると、Claude Managed Agents を始めるためのガイドが表示されます。

Managed Agents は以下の 4 つの概念を中心に構成されています。

エージェント: モデル, システムプロンプト, ツール, MCP サーバー, スキルを設定してエージェントを作成する
環境: エージェントがタスクを実行するための環境を作成する。クラウドコンテナにプレインストールされたパッケージ（Python, Node.js, Go など）やネットワークアクセスを設定する
セッション: エージェントと環境を組み合わせてタスクを実行するインスタンス。会話履歴を保持する
イベント: ユーザーの指示やエージェントの応答など、セッション内のやり取りを表す単位

クイックスタートガイドではまずはじめにエージェントを選択する画面が表示されています。エージェントは、あらかじめ用意されたテンプレートから選択もできますし、ゼロから自分で作成もできます。テンプレートには、タスク管理エージェントやコード生成エージェントなど、様々なユースケースに対応したものが用意されています。例えば Incident Commander テンプレートを選択してみると、以下のような YAML 形式の設定が表示されます。

name: Incident commander
description: Triages a Sentry alert, opens a Linear incident ticket, and runs the Slack war room.
model: claude-opus-4-6
system: |-
  You are an on-call incident commander. When handed a Sentry issue ID or an error fingerprint:
 
  1. Pull the full event payload, stack trace, release tag, and affected-user count from Sentry.
  2. Grep the repo for the top frame's file path and surrounding commits (last 72h).
  3. Open a Linear incident ticket with severity, suspected blast radius, and your rollback recommendation.
  4. Post a threaded status to the incident Slack channel: what broke, who's looking, ETA for next update.
  5. Every 15 minutes, re-check Sentry event volume and update the thread until the user closes the incident.
 
  Be decisive. If you're >70% confident it's a specific deploy, say so and recommend the revert.
mcp_servers:
  - name: sentry
    type: url
    url: https://mcp.sentry.dev/mcp
  - name: linear
    type: url
    url: https://mcp.linear.app/mcp
  - name: slack
    type: url
    url: https://mcp.slack.com/mcp
  - name: github
    type: url
    url: https://api.githubcopilot.com/mcp/
tools:
  - type: agent_toolset_20260401
  - type: mcp_toolset
    mcp_server_name: sentry
    default_config:
      permission_policy:
        type: always_allow
  - type: mcp_toolset
    mcp_server_name: linear
    default_config:
      permission_policy:
        type: always_allow
  - type: mcp_toolset
    mcp_server_name: slack
    default_config:
      permission_policy:
        type: always_allow
  - type: mcp_toolset
    mcp_server_name: github
    default_config:
      permission_policy:
        type: always_allow
metadata:
  template: incident-commander

この設定では、Sentry のアラートをトリアージして Linear にインシデントチケットを開き、Slack でウォールームを実行するエージェントが定義されています。エージェントは claude-opus-4-6 モデルを使用し、システムプロンプトにはエージェントの役割とタスクの手順が記載されています。mcp_servers や tools でエージェントが利用可能なツールが定義されていることが確認できます。

ここでは Blank agent テンプレートを選択して、汎用的なエージェントを作成してみましょう。YAML もしくは JSON の設定画面が表示されるので、内容を確認して「Use this template」をクリックします。これでエージェントが作成されます。

エージェントは /v1/agents エンドポイントに POST リクエストを送ることで作成されます。コンソールには実行ログが表示されています。エージェントが作成されたら「Next: Configure environment」をクリックして環境の設定に進みましょう。

エージェントと対話形式で環境の設定が進められていきます。質問では環境がオープンなインターネットにアクセスできるか、それとも特定のホストのみにアクセスできるようにするかが聞かれました。

ネットワークのモードとしては unrestricted と limited の 2 種類が用意されています。unrestricted モードでは環境は一部のブロックリストを除き、すべてのネットワークアクセスが許可されます。limited モードではデフォルトでネットワークアクセスがブロックされ、allowed_hosts に指定されたホストへのアクセスのみが許可されます。その他 allow_mcp_servers, allow_package_managers オプションも用意されており、true に設定するとそれぞれ MCP サーバーや公開パッケージマネージャー（PyPI, npm など）へのアクセスが許可されます。

ネットワークアクセスを許可する形でエージェントの質問に返答すると、/v1/environments エンドポイントに POST リクエストが送られて環境が作成されます。環境が作成されたら「Next: Start session」をクリックしてセッションを開始しましょう。

/v1/sessions エンドポイントに POST リクエストを送ることでセッションが開始されます。セッションとは環境内で実行されているエージェントのインスタンスのことです。セッションはエージェントと環境を参照し、会話履歴を保持します。セッションを開始したタイミングではまだタスクは実行されていません。セッションを開始した後に、ユーザーがメッセージを送信することでエージェントがタスクを実行し始めます。

セッションが開始されると、右側にメッセージを送信するための入力フォームが表示されるので、何かメッセージを送信してエージェントに指示を出してみましょう。プレイスホルダーとして「Search the web for the latest news about Claude AI and summarize the top 3 stories.」と表示されているので、これをそのまま入力して送信してみます。

メッセージの送信自体は /v1/sessions/:session_id/events エンドポイントへの POST リクエストで行われます。一方で、イベントのストリームは /v1/sessions/:session_id/stream から受信します。Console 上ではこれらが一連の操作として表示されるためひと続きに見えますが、API レベルでは送信と受信でエンドポイントが分かれています。ストリームには Web Search ツールの呼び出しやエージェントのレスポンスが順次流れてきます。

最初にメッセージを送信した後、エージェントがタスクを実行してレスポンスを返すまでの一連の流れは、イベントのやりとりとして記録されていきます。イベントには、ユーザーがセッションを開始したりセッションを制御するために送信する「ユーザーイベント」と、セッションの状態の変化やエージェントの進行状況を監視するための「エージェントイベント」「セッションイベント」「スパンイベント」に分類されます。

イベントタイプを示す文字列は {domain}.{action} という形式になっており、以下のようなイベントが存在します。

user.message: ユーザーがセッションにメッセージを送信したときに発生するイベント
agent.message: エージェントからの応答
agent.tool_use: エージェントがツールを使用したときのイベント
session.status_idle: エージェントが現在のタスクを完了し、アイドル状態になったときのイベント
span.model_request_start: モデルへのリクエストが開始されたときのイベント

エージェントのレスポンスの詳細を確認すると、確かにニュースの要約が返ってきていることがわかりますね。これでクイックスタートガイドは完了です。

GitHub リポジトリに接続してプルリクエストを作成してもらう

基本操作を確認したので、次は GitHub MCP サーバーと GitHub repository リソースを組み合わせて、コード変更からプルリクエスト作成までを任せる例を試します。

Managed Agents の基本的な概念を一通り理解したところで、次は GitHub リポジトリに接続してプルリクエストを作成してもらうという実践的なタスクをやってもらいましょう。まずは GitHub MCP サーバーにアクセスできるエージェントを作成します。左サイドバーの「Agents」からエージェントの一覧ページにアクセスし、「New agent」をクリックしてエージェントの作成を開始します。

モーダルで YAML 形式のエージェントの設定を入力していきます。以下のような内容にしてみましょう。

name: Coding assistant
description: An agent that can create a pull request in GitHub.
model: claude-sonnet-4-6
system: |-
  You are a coding assistant. You can use the GitHub MCP server to interact with GitHub repositories.
# MCP サーバーの定義。GitHub MCP サーバーの URL を指定する
mcp_servers:
  - name: github
    type: url
    url: https://api.githubcopilot.com/mcp/
tools:
  # bash, read, write, web_search などの基本的なツールセット
  - type: agent_toolset_20260401
  # mcp_servers を定義した場合、type: mcp_toolset を指定して MCP サーバーをツールとして使用できるようにする
  - type: mcp_toolset
    mcp_server_name: github
    default_config:
      permission_policy:
        type: always_allow

作成後のエージェントを確認すると、GitHub MCP サーバーがツールとして定義されていて create_pull_request などの操作が使用可能になっていることを確認できます。

ただしこのままでは GitHub MCP サーバーに認証されていないため、エージェントは GitHub MCP サーバーにアクセスできません。私が試したときは OAuth を使うフローに案内され、その認証情報を Vault に保管する形でした。認証情報は mcp_server_url にバインドされ、エージェントが MCP サーバーにアクセスする際に使用されます。Vault に認証情報を保管するためには、左サイドバーの「Credential vault」から「New value」をクリックします。

私が試したときは、エージェントの設定から「Guided Edit」をクリックしてエージェントと対話形式で認証の問題を解決しました。「github mcp サーバーの認証を完了するには？」という質問に対して「GitHub の MCP サーバーへの認証は Vault（ボールト）を通じて行います。」という回答が返され、そのまま Vault に認証情報を保管するためのフローを実行してくれました。

次にセッションを作成します。セッションを開始する際にオプションでリソースを指定できます。リソースには「GitHub repository」や「File」などがあり、セッション開始時にエージェントがアクセスできるリソースを指定できます。ここで指定する GitHub repository リソースは、先ほど Vault に保存した GitHub MCP サーバーの認証とは別に、リポジトリをクローンするための認証情報を受け取ります。エージェントには先程作成した「Coding assistant」エージェントを指定し、リソースには「GitHub repository」を選択します。

リソースのオプションを入力するフォームが表示されるので、GitHub のリポジトリの URL と Authentication Token を入力します。Authentication Token は GitHub で Developer Settings → Fine-grained tokens から作成できます。Token を作成する際には以下の権限を付与する必要があります。

Contents: Read and write
Pull requests: Read and write
Repository metadata: Read

セッションを作成したらエージェントに指示を出してみましょう。ここでは試しに「記事の詳細画面の関連記事の見出しのフォントサイズを 1rem に変更し、その変更をプルリクエストとして作成して」という指示を出してみます。

エージェントがコードベースを分析して、変更すべきファイルを特定し、Edit ツールを使用してコードを変更している様子が確認できます。タスクが完了したらエージェントは Idle 状態に遷移します。今回は実際に対象ファイルの修正案を作成し、プルリクエスト作成に必要な操作まで進められることを確認できました。

まとめ

Claude Managed Agents はクラウドホスト型エージェントを大規模に構築・展開するためのサービス
Managed Agents を使用することで、安全なサンドボックス環境・エージェントの状態を保存するためのストレージ・エージェントの状態を監視するためのモニタリングツール・アクセス権限など、エージェントを動かすためのインフラストラクチャーを構築する必要がなくなり、ユーザーに価値を提供するという本質的な開発に集中できる
Managed Agents はエージェント, 環境, セッション, イベントの 4 つの概念を中心に構成されている
エージェントの作成からセッションの開始までの一連の流れを UI 上で対話形式で進めることができる
Vault を使用して認証情報をあらかじめ保管しておくことで、GitHub MCP サーバーなどの外部サービスにアクセスするための認証情報をエージェントが利用できるようになる
セッションの開始時にリソースを指定でき、ファイルや GitHub リポジトリなどのリソースにアクセスできる
向いている用途として、長時間かかる作業や非同期に進めたい作業、複数の外部ツールをまたぐタスクが挙げられる
一方で、細かい制御が必要な軽量な処理や、単発のモデル呼び出しで十分な用途では Messages API を直接使うほうがシンプルな場合もある