こんな場面を想像してほしい。
ある企業の部門マネージャーが、月曜の朝にSlackでAIエージェントにメッセージを送る。
「先週の営業データをもとに、今月の見込み顧客リストをスプレッドシートにまとめて。完了したらTeamsにも共有して」。
30分後、スプレッドシートが完成し、Teamsに通知が届いている。マネージャーはその間、別の打ち合わせに出ていた。
これは絵空事ではない。
2026年4月8日、AI企業のAnthropicが「Claude Managed Agents」をパブリックベータとして公開した。
楽天では、プロダクト・営業・マーケティング・財務など複数の部門にAIエージェントを展開し、SlackやTeamsを通じてスプレッドシートや提案デッキ・アプリを自動生成する運用が始まっている。各エージェントの展開は1週間以内で完了したという。
この記事は、Managed Agentsを構成する5つの柱——「エージェント」「Environment(実行環境)」「セッション」「メモリ管理」「Vault(ボルト)」——を、技術的な前提知識がなくても理解できるように解説するものだ。
読み終えたとき、AIエージェントが自社業務のどこに使えそうか、そしてセキュリティ上どういう注意が必要かが見えてくるはずだ。
なお、公式ドキュメントではManaged Agentsの中核概念を「Agent」「Environment」「Session」「Events」の4つとしている。本記事では読者の理解しやすさを優先し、「メモリ管理」と「Vault」を独立した柱として取り上げ、5つに再構成した。
まず全体像を一言でまとめると、こうなる。
エージェント(何ができるか)を、Environment(どこで動かすか)にセットし、セッション(実行の単位)として稼働させる。
長時間の作業ではメモリ管理(記憶の仕組み)が支え、外部サービスとの連携ではVault(認証情報の安全管理)が守る。
この5つが協調して、「AIに仕事を任せる」を実現する。
目次

ChatGPTの登場以来、多くのビジネスパーソンがAIと「会話」してきた。
質問すれば答えが返る。文章を要約してくれる。
ただし、それは人間が逐一指示を出し、結果を受け取る「一問一答」のやりとりだった。
Claude Managed Agentsは、この構図を大きく変える。
一度タスクを伝えれば、AIが自律的に判断し、ツールを使い、ファイルを作り、外部サービスと連携し、数分から数時間かけて仕事を完了させる。
人間はその間、別の業務に取り組んでいてよい。
もちろん、Managed Agents以前にも自律的なタスク実行を目指すAIエージェントは存在していた(AutoGPTやDevin、OpenAIのAssistants APIなど)。
Managed Agentsの特徴は、エージェントの「動かし方」——サンドボックス構築、状態管理、エラー復旧、認証情報の安全管理——をすべてプラットフォーム側が引き受け、本番運用レベルの品質で提供した点にある。
開発者は「AIに何をさせるか」だけに集中できる。
Anthropic社によれば、構造化ファイル生成タスクに関する内部テストにおいて、標準的なプロンプティングループ(AIモデルを繰り返し呼び出す基本的な実行方式)と比較して、タスクの成功率が最大10ポイント向上した。特に難易度の高い問題で改善幅が大きかったという。
ただし、この数値はAnthropic社自身の内部テストによるものであり、第三者による独立検証はまだ公表されていない。
では、この仕組みを構成する5つの要素を順に見ていこう。

Managed Agentsにおけるエージェントとは、AIの「能力」を定義したものだ。
たとえるなら、新入社員に渡す「業務マニュアル」と「使ってよいツール一覧」を組み合わせたものに近い。
エージェントには3つの要素が設定される。
まず、どのAIモデルを使うかの選択。高性能なClaude Opus 4.6か、コスト効率重視のClaude Sonnet 4.6かなどを選べる。
次に、「システムプロンプト」と呼ばれる仕事の指示書。AIに対して事前に与えておく基本的な行動指針で、「あなたは経費精算を担当するエージェントです。入力されたデータを検証し、不備があれば差戻してください」のように業務内容を定義する。
そして、使えるツールの設定だ。
Managed Agentsの標準ツールセットには、シェルコマンドの実行(パソコンのコマンドラインを操作する能力)、ファイルの読み書き・編集・検索、Webの検索とページ内容の取得が組み込まれている。
さらに、外部サービスとの接続(Slack、GitHub、Google Driveなど)はMCPという標準規格を通じて、エージェント設定時に追加構成できる。
つまり、エージェントは人間がパソコンで行うような操作——ファイルを作る、データを調べる、外部のサービスにアクセスする——を自律的に組み合わせてタスクを遂行できる。
途中でエラーが起きた場合の自動復旧や、処理効率を上げるためのキャッシュ管理も標準装備されている。
実際にSentryでは、既存のデバッグツール「Seer」とClaude搭載エージェントを連携させ、バグの検知からパッチ作成・プルリクエスト作成までを自動化した。
当初数ヶ月と見込まれていた統合作業が数週間で完了したと報告されている。
では、このエージェントは実際にどこで動くのか。その「場所」を定義するのがEnvironmentだ。

オフィスワーカーにデスクとパソコンと業務ソフトが必要なように、エージェントにも仕事をするための環境が要る。
Managed AgentsにおけるEnvironment(実行環境)とは、エージェントが動作するクラウド上の「仮想パソコン」のテンプレートだ。
Environmentで設定できることは、大きく2つある。
ひとつ目は、事前にインストールするソフトウェアの指定だ。
データ分析に必要なライブラリ、Webアプリ開発で使うパッケージなど、主要なプログラミング言語のツール群に対応している。
エージェントが「仕事道具」を最初から持った状態でスタートできる。
ふたつ目は、ネットワーク接続の制御だ。ここがセキュリティの観点で重要になる。
unrestrictedモードでは、一般的な安全ブロックリストを除き、エージェントはインターネット上のサービスにアクセスできる。開発やテスト段階では便利だが、本番運用には向かない。
limitedモードでは、ホワイトリスト方式で通信先を限定できる。たとえば、「自社のAPIサーバーとSlackだけに通信を許可し、それ以外への接続を遮断する」といった設定が可能だ。
公式ドキュメントでも、本番環境ではlimitedモードの使用が推奨されている。
重要な設計思想は、AgentとEnvironmentが完全に分離されていることだ。
同じ「営業データ分析エージェント」を、テスト用のunrestricted環境と、本番用のlimited環境の両方で動かせる。
「何をやるか」と「どこでやるか」が独立しているからこそ、テスト環境で十分に検証してから本番環境に移すという安心感のある運用が可能になる。
AgentとEnvironmentが揃ったら、次は実際に「仕事を始める」段階だ。ここで登場するのがセッションである。

セッションとは、特定のエージェントを特定の環境で起動して、タスクを実行する「一回の仕事の単位」だ。
「この社員(Agent)に、この部屋と道具一式(Environment)を用意して、このプロジェクトを任せる」という指示を出す行為がセッションの開始に相当する。
セッションのライフサイクルは明快だ。
AgentとEnvironmentを指定してセッションを作成すると、クラウド上に専用の作業空間が立ち上がる。
タスクの指示を送信すると、エージェントは自律的に判断しながらツールを組み合わせてタスクを進める。
タスクが完了すると、セッションは「待機状態」に入り、次の指示を待つ。
このプロセスで特筆すべき機能が3つある。
ひとつ目はリアルタイム監視だ。
セッション中のエージェントの行動は、リアルタイムに観察できる。「今どのツールを使っているか」「どんな結果が返ってきたか」が逐次確認できるため、AIが何をしているかがブラックボックスにならない。
ふたつ目は途中介入だ。
エージェントが間違った方向に進んでいると感じたら、途中で中断をかけ、新しい指示を送って方向転換させることができる。
完全に任せきりにする必要はなく、「様子を見ながら舵を切る」運用が可能だ。
みっつ目はセッションの継続と分岐だ。
一度完了したセッションを後から再開する、最新のセッションをそのまま続ける、あるいは途中から分岐させて別のアプローチを試す。
会議で「その案もいいが、別のパターンも検討しよう」と分科会を立てるようなイメージだ。
料金は、AIモデルの利用量に応じたトークン従量課金(AIが処理するテキスト量に応じた課金)に加え、セッションの稼働時間に対して1時間あたり0.08ドル(約12円)が加算される。
たとえば、公式ドキュメントの計算例では、Claude Opus 4.6で入力5万トークン・出力1.5万トークンの1時間セッションの場合、トークン費用とランタイム費用を合わせて合計約0.7ドル(約105円)になる。
これはあくまで1セッションの直接費用であり、タスクの複雑さによってトークン消費量は大きく変動する。事前のコスト見積もりには幅を持たせるべきだろう。
しかし、数時間にわたるタスクを処理するエージェントには、別の課題が立ちはだかる。AIが一度に覚えていられる情報量には限りがあるのだ。

AIモデルには「コンテキストウィンドウ」と呼ばれる、一度に扱える情報量の上限がある。
本でいえば「一度に開いておけるページ数」に当たる。
Claude Opus 4.6の場合は100万トークン(日本語で約50万文字相当、書籍5〜10冊分程度)。
日常的な会話には十分すぎるほどだが、数時間にわたって大量のファイルを処理し続けるエージェントにとっては、それでも制約となりうる。
Managed Agentsは、この制約を3つの仕掛けで乗り越えている。
第一の仕掛けは「コンパクション(自動要約圧縮)」だ。
会話やツールの実行結果が蓄積され、容量が一定の閾値に達すると、AIが自動的にそれまでの内容を要約する。
重要なポイントだけを残して圧縮し、処理を続行する。
会議で長時間議論した後に「ここまでの要点をまとめると」と整理するのに似ている。
第二の仕掛けは「ツール結果の整理」だ。
エージェントがツールを使うたびに結果がコンテキストに蓄積されるが、再取得可能な古い結果は選択的に削除される。
ツールを「使ったという記録」は残しつつ、具体的なデータを整理することで、限られた記憶領域を効率的に使う。
第三の仕掛けが「メモリツール」だ。
これはコンテキストウィンドウの外部にある、永続的なファイルストレージへの読み書き機能である。
エージェントは専用のディレクトリに「学んだこと」「進捗状況」「重要な判断」などを自発的にファイルとして書き出す。
次にセッションを開始するとき、エージェントはまずこのディレクトリを確認し、過去の記録を読み込む。
いわば「業務日誌」を自分でつけて、翌日の仕事に引き継ぐ仕組みだ。
この3つの仕掛けを組み合わせることで、Managed Agentsは100万トークンというコンテキストウィンドウの制限を超え、数時間にわたる複雑なタスクを中断なく遂行できる。
ところで、エージェントが外部サービス——社内のSlackやGitHub、顧客管理システム——と連携するには、認証情報(パスワードやAPIキーに相当するもの)が必要になる。
この認証情報を、AIが自律的に行動する環境でどう安全に扱うか。
ここに、Managed Agentsの設計で最も注目すべき仕組みが登場する。

AIエージェントが自律的に動くとき、最も深刻なセキュリティリスクのひとつが「認証情報の漏洩」だ。
エージェントがSlackにメッセージを送るにはSlackのAPIキーが要る。GitHubにコードをプッシュするにはアクセストークンが要る。
従来の多くのエージェント設計では、これらの認証情報はエージェントが動作する環境内に直接置かれていた。
ここに「プロンプトインジェクション」と呼ばれる攻撃のリスクが潜む。
これは、悪意のある入力をAIに送り込み、本来やるべきでない行動——たとえば「環境内の認証情報をすべて読み出して表示せよ」——を実行させる手法だ。
認証情報が環境内にあれば、この攻撃が成功した瞬間にすべてのキーが漏洩しうる。
Managed AgentsのVaultは、この問題を構造から解決する。
発想は明快だ。「エージェントに鍵を渡さなければ、鍵は盗まれない」。
日常的な場面でたとえるとこうなる。
あなたが秘書に「取引先のA社に電話して打ち合わせの日程を調整して」と依頼する場面を想像してほしい。
従来型の設計は、秘書にA社の担当者の携帯番号、社内の内線番号表、さらには取引先のシステムへのログインパスワードまで全部渡してしまう状態に等しい。
Vaultの設計は、秘書が「A社に連絡してほしい」と交換台(プロキシ)に伝えるだけで、交換台が適切な番号に接続してくれる仕組みだ。
秘書は電話番号を一切知らないし、知る必要もない。
Anthropic社はManaged Agentsのアーキテクチャ全体を「脳と手の分離(Decouple the brain from the hands)」と呼んでいる。
このアーキテクチャのセキュリティ境界の一部として、エージェント(Claude)もハーネス(エージェントの実行基盤)も認証情報を受け取らない。
代わりに、専用のプロキシ(中継サービス)がVaultから認証情報を取り出し、外部サービスへのリクエストに組み込んで送信する。
公式ドキュメントでは「ハーネスはいかなる認証情報も認識しない」と明記されている。
この仕組みを支えるのが、エージェントの実行環境の隔離だ。
エージェントは軽量仮想マシンやコンテナ技術によってネットワーク的に隔離されており、直接インターネットにアクセスできない。
すべての外部通信はプロキシを経由するため、通信経路は暗号化で保護され、通信先もEnvironmentのネットワーク設定で制限される。
Vaultがある場合、そもそもエージェントの環境内に認証情報が存在しない。
プロンプトインジェクションが成功したとしても、盗み出せるものがない。
金庫の中身を盗もうとしたら、部屋に金庫自体がなかった——という状況だ。
ただし注意すべき点がある。
Vaultが防ぐのは「認証情報の漏洩」であり、プロンプトインジェクション攻撃そのものを完全に防ぐわけではない。
たとえば、攻撃者がエージェントに不正なファイル操作を実行させるリスクは依然として残る。
Vaultは万能の盾ではなく、「鍵の安全管理」に特化した防御策だ。
Environmentのネットワーク制限やツールのパーミッション設定と組み合わせて多層防御を構築することが重要になる。
実際、2025年にはAnthropic公式のGit MCPサーバー(mcp-server-git)に、プロンプトインジェクションで悪用可能な3件の脆弱性が発見された。
うち1件は2025年9月、残る2件は2025年12月にそれぞれ修正されている。
このような脆弱性が見つかったとき、Vault設計であれば少なくとも認証情報は安全に保たれる。
「事故は起こりうる」という前提に立った、構造的な防御策なのだ。
ここまでの5つの要素を実際に使っている企業では、何が起きているのか。

すでにManaged Agentsを採用している企業の事例は、この技術の適用範囲の広さを示している。
Notionは自社のワークスペース内にClaude Managed Agentsを統合し、ユーザーがNotionのタスクボードから直接Claudeエージェントに作業を委任できるようにした。
エンジニアがコードを書く傍ら、ナレッジワーカーはプレゼンテーションやWebサイトを生成する。数十のタスクが並列で処理されている。
楽天では、プロダクト・営業・マーケティング・財務など複数部門にエージェントを展開した。
SlackやTeamsに接続し、スプレッドシートや提案デッキなどの成果物を返却する運用が始まっている。
Asanaでは、プロジェクト内で人間と並行して作業する「AIチームメイト」として統合された。
プロジェクトのタスクボードにAIチームメイトが並び、人間のメンバーと同じようにタスクを割り当てられる。
これらの事例に共通するのは、「エージェントの構築」よりも「業務への組み込み」に注力できている点だ。
インフラ構築の手間がなくなったことで、「何を自動化するか」というビジネス判断にリソースを集中できている。

ここまで読んで、「自分の部門でも使えるのか」と考えた方も多いだろう。
AIエージェントによる自動化が向いている業務には、いくつかの共通パターンがある。
向いている業務の特徴として、まず「手順がある程度明確で、繰り返し発生する」ものが挙げられる。
月次のレポート作成、定型的なデータ集計、テンプレートに沿った文書作成などだ。
次に、「複数のツールやサービスをまたぐ作業」。
Slackでの通知、スプレッドシートへの記入、メールの送信といった横断的なタスクは、エージェントの強みが発揮される。
そして、「万が一ミスがあっても即座に致命的な影響を及ぼさない業務」。
人間がレビューできる段階を挟める作業が適している。
逆に、慎重に考えるべきケースもある。
判断基準が曖昧で、高度な文脈理解が必要な業務。エラー時のリスクが極めて大きい業務(法的文書の最終承認、資金移動の最終決裁など)。
あるいは、機密性の高いデータを大量に扱う業務では、データがAnthropicのクラウド上で処理されることのプライバシーリスクを慎重に評価する必要がある。
導入を検討する際は、まず小さなタスク(週次レポートの下書きなど)でテストし、品質と速度を確認する。
次に、監視体制を整えた上で適用範囲を広げる。
いきなり基幹業務に適用するのではなく、段階的に信頼を積み重ねるアプローチが現実的だ。

Managed Agentsは有望な技術だが、導入を検討するなら以下のリスクと制約を正しく理解しておく必要がある。
ベータ版であること。
2026年4月時点でパブリックベータの段階にある。SLA(サービス品質保証)が正式に提供されない可能性があること、仕様が今後変更されうることを意味する。
ミッションクリティカルな業務への適用は、GA(正式版)リリース後に検討するのが安全だ。
ベンダー依存のリスク。
Managed Agentsを採用することは、Anthropic社のインフラに業務プロセスを依存させることでもある。
サービスの停止、料金改定、仕様変更が業務に直接影響しうる。代替手段の確保や、エージェントの設計を特定プラットフォームに過度に依存させない工夫が求められる。
AIの判断ミス。
エージェントが自律的にタスクを実行する以上、誤った判断をするリスクは常に存在する。
AIが生成したパッチにバグが含まれる、データの解釈を誤る、といった事態は起こりうる。
セッションのリアルタイム監視機能や途中介入の仕組みを活用し、人間によるレビュー工程を組み込むことが重要だ。
コスト予測の難しさ。
トークン従量課金はタスクの複雑さによって大きく変動する。
簡単なタスクで100円程度でも、複雑なタスクでは数千円に達することもありうる。
本格導入前にパイロット運用でコスト実績を蓄積し、予算化の根拠を得ることが望ましい。
データプライバシー。
エージェントが処理するデータはAnthropicのクラウド上に置かれる。
個人情報や営業秘密を扱う場合は、自社の情報セキュリティポリシーとの整合性を確認し、必要に応じてEnvironmentのネットワーク制限やデータの匿名化を検討すべきだ。

冒頭で想像した場面に戻ろう。
部門マネージャーがSlackにメッセージを送っただけで、スプレッドシートが完成しTeamsに共有された。
その裏では、Environment(セキュアなクラウド環境)上でAgent(営業データ分析の能力を持つAI)がSession(一連のタスク実行)を開始し、Memory(過去の作業記録)を参照しながら、Vault(認証情報を安全に管理する仕組み)を通じてSlackやTeamsと連携していた。
5つの構成要素がそれぞれの役割を果たしながら、ひとつの仕事を完遂する。
この仕組みが意味するのは、「AIに仕事を任せる」という行為が、技術的な実験段階から、設計可能なビジネスプロセスへと移行し始めたということだ。
ただし、「移行し始めた」であって、完了したわけではない。
ベータ版という段階、AIの判断精度の限界、セキュリティリスクの残存——これらの課題は依然として存在する。
Managed Agentsが提供するのは、あくまでも「AIに安全に仕事を任せるための土台」であり、その上にどのような業務プロセスを組み立てるかは、各企業の判断に委ねられている。
大切なのは、この土台の仕組みを正しく理解した上で、自社にとっての「最初の一歩」を見極めることだ。
小さく始め、効果を確認し、段階的に広げる。
AIエージェントの活用は、そうした地に足の着いたアプローチでこそ成果につながる。
・ Anthropic「Claude Managed Agents overview」
・ Anthropic「Claude Managed Agents: get to production 10x faster」
・ Anthropic Engineering Blog「Scaling Managed Agents: Decoupling the brain from the hands」
・ Anthropic「Cloud environment setup」
・ Anthropic「Events and streaming」
・ Anthropic「Securely deploying AI agents」
コンテキストウィンドウ:AIが一度の会話で扱える情報量の上限。本でいえば「一度に開いておけるページ数」のようなもの
トークン:AIがテキストを処理する際の最小単位。日本語1文字は約0.5〜2トークンに相当する
プロンプトインジェクション:AIに悪意のある指示を紛れ込ませ、本来想定されていない行動を取らせる攻撃手法
サンドボックス:外部と隔離された安全な実行環境。砂場(sandbox)のように、中で何が起きても外に影響しない設計
MCP(Model Context Protocol):AIエージェントが外部ツールやサービスと安全に連携するための標準規格。Anthropicが策定した
コンパクション:会話の蓄積がコンテキストウィンドウの上限に近づいたとき、AIが自動的に内容を要約・圧縮する仕組み
プロキシ:二者間の通信を仲介するサービス。Vaultの文脈では、エージェントと外部サービスの間に入り、認証情報を代わりに付与して通信する
SLA(Service Level Agreement):サービス提供者が利用者に保証するサービス品質の基準。稼働率や応答時間などを定める
GA(General Availability):ソフトウェアやサービスの正式リリース。ベータ版よりも安定性と品質保証のレベルが高い