一行定義

プロンプト知能ではなく、セッション時間単位で課金されるホスト型ランタイムとしてのエージェント。Anthropic Managed Agents が代表例。

全体システムの中での役割

マネージドエージェントは、エージェントを「プロンプトの産物」から「時間貸しのランタイム」に置き換える カテゴリだ。単一製品の名前ではなく、運用形態のラベルとして扱うのが正確だ。

これまでのエージェント開発は、自分の環境に Claude Code や harness を組んで、モデル API を叩きながら動かすのが基本だった。これは「ローカル work surface」に近い。マネージドエージェントはその逆で、提供者側（Anthropic など）が session · harness · sandbox を含んだランタイムを丸ごとホストする。利用者は API で「このタスクを、これだけの道具と権限で、session として走らせてほしい」と渡すだけになる。

代表例である Anthropic Managed Agents（2026-04 時点）を起点に特徴を並べると：

• session が第一級オブジェクト：1 回の質問応答ではなく、長時間稼働する作業単位。中断しても再開できる前提で設計されている
• brain と hands の分離：モデル（考える側）とツール実行環境（動かす側）を別レイヤーに切る。sandbox はこの hands 側に属する
• credential boundary：API キーや資格情報をモデルに直接見せず、実行環境側に閉じ込める
• session-hour 課金：Anthropic の公式 pricing docs では $0.08 per session-hour（session が running のときだけ加算、2026-04 時点）。token とは別の課金軸が出てきた点が新しい
• hosted service：利用者は裏のインフラを見ない。Claude API direct surface から呼ぶ

この設計から読める本質は、エージェントの競争軸が プロンプトの賢さから、長く安全に走り続ける土台の強さへ 移ったことだ。autonomous loop を数時間〜数日の単位で回す前提が成立してはじめて、A2A のような上位プロトコルや meta-harness の議論が意味を持ち始める。マネージドエージェントはその土台側の選択肢だ。

位置づけを一行で言うなら：Claude Code はローカル work surface、Managed Agents はホスト型 runtime surface。同じ Anthropic 系列でも、運用哲学が分かれている。

よくある誤解

• 誤解 1：マネージドエージェント = さらに賢くなった AI 秘書、と受け取られがち。

– 実際には、答えの質そのものを劇的に上げる製品ではない。変わっているのは「長く止まらず、credential を漏らさず、途中で死んでも再開できる」構造のほうだ。モデルは同じ Claude でも、置かれている runtime が別物、という見方が近い。

• 誤解 2：Managed Agents という Anthropic 固有プロダクトの名前だ、と狭く捉えられがち。

– 実際には、Anthropic Managed Agents は代表例ではあるが、カテゴリとしての「マネージドエージェント」は他社も追随する領域だ。文脈によって「Anthropic の特定プロダクトを指しているのか」「ホスト型ランタイム一般を指しているのか」を読み分ける必要がある。この用語ページは後者の意味で使う。

• 誤解 3：session-hour 課金は token 課金より必ず得（または損）だ、と単純化されがち。

– 実際には、作業の性質で逆転する。待機時間が長く token 生成が少ない長時間タスク（監視・ポーリング・人の承認待ちを挟む処理）では session 課金が効きやすいが、token を大量に吐く単発処理では割高になる。Anthropic の公式 pricing docs は session が running のときだけ加算と明記している ── この条件の読み違いが見積りミスを生みやすい。

この用語が重要な理由

マネージドエージェントを「プロダクト名」ではなく「運用カテゴリ」として理解しておくと、実務の判断軸が増える。これが価値だ。

自社でエージェントを動かそうとする時、選択肢は大まかに 3 つある：

1. ローカル harness（Claude Code など）を自分たちのマシンや CI で回す

2. マネージドエージェントに session を立てて、提供者側のランタイムに任せる

3. 両方を組み合わせる（開発・検証はローカル、本番は hosted）

この切り分けを持っていない人は、「エージェント＝賢いチャット」の延長線でしか設計できない。一方、この 3 択を持っている人は、たとえば次のような問いに答えを出せる：

• 24 時間走る監視型エージェントはどこに置くか（ローカル PC だと止まる）
• 顧客データに触るエージェントの credential boundary はどこで引くか
• 失敗した session を誰が再起動するか（自分たちか、runtime 側か）
• session-hour と token の合算コストをどう見積るか

つまり、マネージドエージェントを知ることは、エージェント運用の「置き場所」設計を獲得する ことに等しい。プロンプトチューニングだけでは到達できないレイヤーの判断軸が手に入る。

この用語が登場する記事

• Anthropic Managed Agents、長時間エージェント運用、Claude Code との比較関連の記事（※ auto-link で自動挿入）

次に読むべき用語 3 つ

• agent — マネージドエージェントが属する上位概念。「運用形態の 1 つ」として位置づけると理解しやすい。
• A2A — 複数のマネージドエージェントを連携させる上位プロトコル。単独運用の次のステップ。
• autonomous loop — session 内でエージェントが回り続けるパターン。マネージドランタイムが支える実行モデル。