セルフホスト版 Claude Managed Agents: サーバーは自分のものになり、何も報告しない失敗も自分のものになる

11 月 12 日、Anthropic はセルフホスト版 Claude Managed Agents を公開しました。これまではサンドボックスを自分のマシンに移し、それ以外は Anthropic に任せる形でした。今回からはサービス全体を移せます。API、エージェントループ、そしてエージェント、セッション、セッション履歴のストレージです。サーバーはモデル呼び出しをデフォルトで Claude API に送り、代わりに Amazon Bedrock、Google Cloud、Microsoft Foundry、または自分で運用するゲートウェイにも送れます。

私自身はまだ動かしていません。ダウンロードはアカウントチーム経由の申請制なので、この記事は 11 月 13 日時点のドキュメントだけに基づいています。最初に読むべきページは「Differences from the hosted service」で、中でも価値があるのは「no error」で終わる行です。

セルフホスト版 Claude Managed Agents とは何か

同じ Managed Agents API を、自分で動かすプログラム cma-server が提供する形です。そのため SDK も ant CLI もそのまま使えます。デプロイは 1 台以上のサーバー、PostgreSQL 16 以降、そしてサーバーをポーリングしてエージェントのシェルツールとファイルツールを自分のサンドボックスで実行するワーカーで構成されます。

概要ページの中で、何よりも先に知っておきたい点が 2 つあります。サーバーはデータベースなしでも起動します。その場合はすべてをメモリに保持し、再起動すると消えます。もう 1 つは、bash ツールがワーカーの権限を持つ本物のシェルだということです。ワーカーはこれを隔離しません。隔離の強さは、ワーカーを入れたコンテナや VM で決まります。

セルフホスト版 Claude Managed Agents で何も報告しない失敗はどれか

Differences ページに列挙されています。どのケースでも、呼び出しは成功するか沈黙したままで、作業は頼んだとおりには行われていません。

• 環境をポーリングしているワーカーがいない。モデルのターンは進み、最初のツール呼び出しは、ワーカーが実行するまでエラーを出さずに待ち続けます (原文: 「waits, with no error, until a worker runs it」)。ワーカーを webhook で起動するつもりだった場合も同じ待ちが起きます。サーバーは webhook を送らないからです。
• Web ツールを有効にしたが、プロバイダーがそのツールを提供していない。web_search は anthropic、vertex、foundry で、web_fetch は anthropic と foundry でのみ動きます。それ以外では、エージェントは保存も実行もでき、ツール一覧にも残りますが、モデルにそのツールが提示されることはありません。
• 画像やドキュメントを URL で送る。サーバーはブロックを受け付けますが、モデルはそれを一度も見ません。
• Git ホストが push を拒否する。それでもサーバーのログには ok と出ます。
• Claude API 利用時に安全性分類器がリクエストを拒否する。サーバー側のフォールバックはデフォルトで有効なので、別の Claude モデル、ドキュメントの言葉では「possibly a less capable one」(性能が劣る可能性のあるモデル) が答えます。モデルは Anthropic が選び、切り替えを知らせるイベントはなく、セッション内のモデル ID だけがそれを示します。inference.model_fallback: false で無効にできます。

これに近いケースがもう 1 つあります。コンテキストウィンドウに収まらないほど大きいカスタムツールの結果を送ると 200 が返り、エラーはその後に、セッションを終了させる session.error として届きます。どれもドキュメントに書かれています。そして、探しに行かない限りどれも表に出てきません。同じ構図については Claude Code の記事でも書きました。そこでは拒否された作業が success サブタイプで終わります。きれいに終了したことと、作業が終わったことは別物です。

セルフホスト版 Claude Managed Agents に欠けているホスト版の機能は何か

Dreams、webhook、scheduled deployments、Files API、mcp_oauth の vault 認証情報、そして docx、pdf、pptx、xlsx 用の組み込みスキルはすべてありません。定期実行は自前の cron に、ファイルはワーカーのディレクトリに、画像は base64 で送ることになり、OAuth トークンは手動でローテーションする静的なトークンに置き換わります。Dreams には代替手段がありません。

最も縮小するのはオーケストレーションです。Dynamic workflows、advisor、モデル自身が定義するエージェントは 400 を返し、サーバーが受け付けるのは 1〜20 個のエージェントを列挙した coordinator タイプだけです。つまり以前書いた dynamic workflows のガイドで扱った multiagent_20261001 を指定したエージェントはここでは拒否され、ワークフローは移行できません。ほかのものも引き継がれません。エージェント、スキル、vault 認証情報、メモリストアは作り直しになり、MCP と Git ホストの許可リストは空の状態から始まります。

セルフホスト版 Claude Managed Agents でネットワークの外に出るものは何か

モデル呼び出しのたびに、ツールの入力と結果を含むそれまでの会話がプロバイダーに送られます。Claude API を使う場合は、セッション、エージェント、環境の ID という 3 つのヘッダーも一緒に送られます。ID には名前や内容は含まれませんが、どれもサーバーがそれを作成した時刻をエンコードしており、「No setting turns them off」とされています。

保持の扱いは確かに変わります。ホスト版の Managed Agents は、ユーザーが削除するまで Anthropic がトランスクリプトを保存するため、ゼロデータ保持 (ZDR) の対象外です。セルフホストなら保存するのは自分です。モデル呼び出しは、それを処理するプロバイダーとの契約の対象になります。それが Claude API なら、既存の ZDR 契約がほかの Messages API 呼び出しと同様に適用されます。

セルフホスト版 Claude Managed Agents とセルフホストのサンドボックス、どちらが合うか

ドキュメントは 2 つの要件で線を引いています。エージェント、セッション、履歴を自分のインフラに保存したいか、モデル呼び出しを Bedrock、Google Cloud、Foundry、または自前のゲートウェイに送りたいかです。どちらも不要なら、セルフホストのサンドボックスでツールを自分のネットワーク内に置いたまま、サービスの運用は Anthropic に任せられます。ただしこちらにも独自の制限があります (たとえば file や github_repository のセッションリソースは使えません)。

私の読みでは、完全なセルフホストで手に入るのは管理権、つまりトランスクリプトとプロバイダー選択の主導権です。その代償は、サービスを自分で運用することです。バックアップが必要なデータベース、パッチを当て続けるサーバー、そして上に挙げた、何も報告しないケースがついてきます。

セルフホスト版 Claude Managed Agents で最初のセッションを始める前に何を確認すべきか

サイレントなケースを、あえて起こしてみることです。ワーカーを止めて、セッションがツール呼び出しで止まるのを確認します。Web ツールを有効にしてプロバイダーを Bedrock にし、エージェントに検索を頼みます。画像を URL で送ります。サーバー側でブランチを許可し、ホスト側で保護したうえで push し、2 つのログを比べます。これは未検証の提案ですが、どの手順もドキュメントの 1 行から来ています。

私の読みでは、変えたいデフォルトが 1 つ、追加したいアラートが 1 つあります。inference.model_fallback: false を設定するか、全セッションのモデル ID を記録すること。誰も記録しないモデルの切り替えがあると、後から実行結果を比べるたびにその比較が疑わしくなるからです。そして、動いているはずのセッションが数分間イベントを出していなければアラートを出すこと。push についてドキュメント自身が勧めていることが一般原則になります。結果は、それを送ったシステムのログではなく、それを保持しているシステムで確認することです。