Managed Agentsのレート制限とMCP対応・ブランディング規定

Managed Agentsを本番で使う前に確認しておきたい仕様が、公式リファレンスの中に分散しています。APIのレート制限、接続できるMCPサーバーの種類とその宣言方法、セッション単位の予算上限、パートナー製品でClaudeブランドを使うときの規定を、この記事1本で確認できるようにまとめます。

Managed Agentsのレート制限は組織単位でいくつか

Managed Agentsのエンドポイントは、組織(organization)単位でレート制限がかかります。個別のAPIキー単位ではありません。

読み取り系が作成系の4倍という設計は、ポーリングでセッションのステータスを監視する運用を前提にしていると読めます。イベントのストリーム購読ではなくGETのポーリングでステータスを追う実装をしている場合、この上限は意外と早く近づきます。

この上限に加えて、組織レベルの使用量上限とスペンドリミットも別枠で適用されます。Managed Agents固有の300/1,200という数字をクリアしていても、ワークスペース全体の支出上限や使用量ティアの制限に引っかかることがあるため、両方を見ておく必要があります。

レート制限とは別枠のセッション予算(budget)

組織単位のレート制限とは別に、セッション1本ごとに使える金額を直接絞る仕組みもあります。セッション作成時にbudgetフィールドでmax_list_cost(米セント単位の文字列、例:"125"は1.25ドル)を渡すと、公開の一覧料金で継続的に積算された消費額(list cost)がその金額に達した時点で新しい推論リクエストが止まります。上限を跨いだ瞬間に実行中だったリクエストは最後まで完了するため、最終的な消費額は上限をわずかに超えることがあります。

予算に達したセッションは終了するのではなくアイドル状態で止まります。上限を変更するか予算を外せば、作業は自動的に再開します。ただし予算を設定できるのはセッション作成時のみです。既存セッションへの後付けは400エラーで拒否されるので、必要になりそうなセッションは作成時点で予算を設定しておく必要があります。デプロイメントに予算を設定した場合は、そこから起動する各セッションに同じ上限がそのまま適用されます。

接続できるMCPサーバーの種類は何か

Managed Agentsが接続できるのは、HTTPエンドポイントを公開するリモートMCPサーバーと、MCPトンネル経由のプライベートMCPサーバーの2系統です。

サーバー側が実装すべきトランスポートは、MCPプロトコルのstreamable HTTPが基本です。ただし、非推奨になった旧SSEトランスポートしか対応していないサーバーでも自動フォールバックによって動作します。新規にMCPサーバーを実装するならstreamable HTTPを選ぶべきですが、既存のSSE専用サーバーを今すぐ書き換える必要はありません。

エージェント側でMCPサーバーを宣言する仕組み

エージェント作成時、mcp_servers配列にtype("url"固定)・name・urlを指定してサーバーを宣言します。1エージェントにつき最大20台まで、名前は配列内で重複できません。宣言した各サーバーはtools配列側のmcp_toolsetエントリとmcp_server_nameで対応させる必要があり、対応先のない宣言や宙に浮いたtoolsetがあるとAPIがエージェント定義自体を拒否します。

サーバーが公開するツールのうちどれを使わせるかは、mcp_toolsetのdefault_configとconfigsで絞り込めます。default_config.enabledをfalseにして必要なツール名だけconfigsで個別に有効化すれば、多機能なMCPサーバーから一部のツールだけを許可する構成になります。逆に大半を使わせたいときは、無効化したいツールだけをconfigsに列挙すれば足ります。ツールの出力が10万字を超えると、サンドボックス内のファイルへ自動的に書き出され、モデルには要約プレビューとファイルパスが渡されます。

認証情報はエージェント定義には含めず、セッション作成時にvault_idsとして渡します。vaultに登録された認証情報はmcp_server_urlとURLを照合してマッチングされ、スキームとホストの大文字小文字・既定ポート・末尾スラッシュの違いは正規化後に無視されますが、パスやサブドメイン、非標準ポートが違えば別サーバー扱いになります。一致する認証情報が無ければ、そのサーバーへは未認証のまま接続が試みられます。接続やAuth自体はセッション作成時に検証されないため、サーバーに到達できない場合はmcp_connection_failed_error、認証情報が拒否された場合はmcp_authentication_failed_errorというsession.errorイベントがそれぞれ発生し、セッションは止まらず対象サーバーのmcp_server_name付きで通知されます。接続は次にセッションがidleからrunningへ遷移するタイミングで自動的に再試行されます。

2系統のどちらを選ぶかは、MCPサーバーをどこに置いているかで決まります。

自社で新規にMCPサーバーを立てる場合、公開エンドポイントを用意できるならリモート接続がシンプルですが、認証情報や社内システムへのアクセスを外部に晒したくない構成なら、トンネル経由の一択になります。

運用でよくあるつまずき

• ポーリング過多: 複数セッションを同時監視する実装では読み取り系の1,200リクエスト/分に触れやすく、ポーリング間隔をセッション数に比例して延ばすか、イベントストリームの購読に切り替える対処が要る
• 旧SSE専用のMCPサーバーを書き換えなければ動かないという思い込み: 自動フォールバックが効くため、streamable HTTP未対応のサーバーでもそのまま接続できる
• 社内向けのエージェントUIに「Claude Code」と表記してしまう誤り: 許可されているのは「Claude Agent」「Claude」(Agentsラベル配下限定)「 Powered by Claude」の3パターンのみで、Claude Code・Claude Cowork本体を名乗る表記は不許可
• 予算超過を「セッションが落ちた」と誤解する: budget到達時のセッションはアイドルで停止するだけで、消費データも設定も保持されたまま。上限の変更か削除で作業は自動的に再開する

パートナー製品でClaudeブランドをどう表記してよいか

自社プロダクトにManaged Agentsを組み込むパートナーにとって、Claudeブランドの表示は任意です。使う場合の許可表現と禁止表現は、公式に明確な線引きがあります。

この規定の要点は、自社製品がClaude Code・Claude Cowork・その他Anthropicプロダクトそのものであるかのように見せてはいけないという一点に尽きます。自社ブランドを主にし、Claudeへの言及は補助的な位置づけに留める設計が求められます。ブランディング準拠についての個別の疑義は、Anthropicの営業チームへの問い合わせが公式な窓口です。

参照情報をどう運用に落とし込むか

性質の異なる参照情報を実装判断に落とすと、次のように整理できます。

• レート制限: ポーリング頻度を設計する段階で確認する。読み取り系1,200リクエスト/分を前提に、複数セッションを並行監視するならポーリング間隔をセッション数に応じて調整する
• MCPサーバー種別: 新規サーバーを立てるならstreamable HTTP、既存のSSEサーバーを持ち込むだけならそのままで良い。判断が要るのはリモートかトンネル経由かの選択で、社内ネットワークに置くならMCPトンネルが選択肢になる
• セッション予算: 想定外の高額消費を止めたいセッションだけにbudgetを設定する。後付けができない仕様なので、対象になりそうなセッションは作成コードの時点で判断する
• ブランディング: 自社プロダクトにエージェント機能を組み込んで外部提供する場合にだけ関係する。社内利用のみなら意識する必要はない

まとめ

• Managed AgentsのAPIレート制限は組織単位で、作成系300リクエスト/分・読み取り系1,200リクエスト/分。ワークスペース全体の使用量上限とは別枠で適用される
• 接続できるMCPサーバーはリモートMCPサーバーとMCPトンネル経由のプライベートサーバーの2系統。streamable HTTPが基本だが旧SSEトランスポートも自動フォールバックで動き、宣言は最大20台まででmcp_toolsetとの対応が必須
• セッション単位の予算(budget)は作成時にしか設定できず、上限に達したセッションは終了ではなくアイドルで停止する
• パートナー製品でのClaudeブランド表記は任意で、「Claude Agent」等の許可表現と、「Claude Code」「Claude Cowork」を名乗ることの禁止が明確に分かれている

セッションの具体的な操作方法はManaged Agentsのセッション操作リファレンス、初期イベントでの起動パターンはManaged Agentsのセッションを初期イベントでシードするにまとめています。Managed Agents全体の設計思想はAgent SDKのManaged Agentsの設計思想を参照してください。