Claude Managed Agentsのメモリ機能がパブリックベータ公開——AIエージェントが「学習する」時代へ

「昨日エージェントに教えたことを、今日また最初から説明しないといけない」——AIエージェントを業務で使い始めた人なら、この感覚に覚えがあるはずだ。どれだけ優秀なエージェントでも、セッションが終われば記憶はゼロに戻る。これがAIエージェントの実用化における、地味だが深刻な壁だった。

2026年4月23日、Anthropicはこの問題に真正面から取り組む機能をパブリックベータとして公開した。Claude Managed Agentsのメモリ機能だ。

この記事では、メモリ機能の仕組みから実際のユースケース、他社との比較、そして見落としがちな注意点まで、エンジニアと業務担当者の両方が「で、うちの仕事にどう使えるの？」と判断できるよう整理していく。

Claude Managed Agentsとは何か、まずおさらい
- エージェントインフラを丸ごと提供するサービス
- セッションは「揮発性」が前提だった
メモリ機能の仕組み——「ファイルとして保存する」という設計思想
エンジニア視点のユースケース——実際に何ができるか
ビジネス担当者視点のユースケース——現場での活用イメージ
実際の導入事例から見る効果
他サービスとの比較——何が違うのか
見落としがちな注意点と現実的な制限
開発者向け：基本的な使い方の流れ
まとめ

Claude Managed Agentsとは何か、まずおさらい

エージェントインフラを丸ごと提供するサービス

Claude Managed Agentsは、2026年4月8日にパブリックベータで登場したAnthropicのエージェント基盤サービスだ。一言で言うと、「AIエージェントを本番環境で動かすために必要なインフラをすべてAnthropicが引き受ける」という仕組みである。

通常、エージェントを本番投入しようとすると、開発者はコード実行のサンドボックス、状態管理、認証・権限管理、エラーリカバリー、トレース/ログ基盤を自前で構築しなければならない。それだけで数ヶ月かかるケースも珍しくない。

Managed Agentsはそこを肩代わりする。開発者はエージェントの「何をするか」だけ定義すればいい。楽天が各専門エージェントを1週間以内にデプロイできたのも、この仕組みがあってこそだ。

セッションは「揮発性」が前提だった

Managed Agentsが登場した時点では、各セッションは基本的に使い捨てだった。タスクが終わればコンテナは消え、エージェントが学んだことも一緒に消える。毎回ゼロスタート。それが仕様だった。

この制約が、複雑な長期タスクや「組織の知識を蓄積するエージェント」の実現を難しくしていた。メモリ機能は、まさにその欠点を埋めるために設計されている。

メモリ機能の仕組み——「ファイルとして保存する」という設計思想

メモリストアはファイルシステムとして実装されている

メモリ機能の核心は「メモリストア（Memory Store）」という概念だ。

メモリストアは、ワークスペース単位で管理されるテキストドキュメントの集合体だ。ポイントは、これがファイルシステムとして実装されているところ。エージェントは普段使い慣れたbashやコード実行と同じ感覚でメモリを読み書きできる。

具体的にはこんなイメージだ。エージェントが「このユーザーはGAAPフォーマットのレポートを好む」という知識を得たとき、それを /preferences/user_style.md というファイルとしてストアに書き込む。次のセッションで同じエージェントが起動すると、まずそのストアを確認し、ユーザーの好みを把握した状態でタスクを始める。

Anthropicの最新モデル（Opus 4.7など）はファイルシステムベースのメモリとの相性が特に良く、より包括的で整理されたメモリを保存し、何を記憶すべきかの取捨選択も上手くなっているとされる。

自動で読み書きされる——開発者が指定しなくていい

メモリストアをセッションにアタッチすれば、エージェントはタスク開始前に自動でストアを確認し、タスク完了後に学んだことを自動で書き込む。追加のプロンプト設定も、特別なコードも不要だ。

エージェントが使えるメモリツールは以下の6種類。

ツール	役割
`memory_list`	ストア内のドキュメント一覧取得
`memory_search`	ドキュメント内の全文検索
`memory_read`	ドキュメントの内容を読む
`memory_write`	新規ドキュメントの作成・上書き
`memory_edit`	既存ドキュメントの一部修正
`memory_delete`	ドキュメントの削除

1セッションに最大8つのストアをアタッチできる

複数のストアをアタッチできる設計も面白い。たとえば、こんな使い方が考えられる。

読み取り専用の共有ストア：社内の設計規約やドメイン知識を格納。すべてのエージェントが参照するが書き込みはしない
ユーザー固有のストア：個々のユーザーの好みや過去の会話履歴を保存。読み書き可能
プロジェクト単位のストア：プロジェクトごとの文脈情報。メンバー全員のエージェントが参照できる

1つのストアを複数エージェントが同時に読み書きする場合も、互いに上書きしないよう設計されている。

エンジニア視点のユースケース——実際に何ができるか

コードレビューエージェントに「チームの好み」を覚えさせる

たとえばコードレビューエージェントを開発チームで運用するとしよう。最初の数週間は、レビュー担当者が「うちのチームはコメントにissueリンクを必ず含める」「テストはAAA（Arrange-Act-Assert）パターンで書く」といった指摘を繰り返す。

メモリ機能があれば、エージェントはこれらを学習し、次のセッションから自動でそのスタイルに合ったレビューを行う。同じ指摘を何度もしなくていい。チームの暗黙知がエージェントに蓄積される、ということだ。

長期間にわたるデバッグ作業で文脈を引き継ぐ

複数日にわたるデバッグセッションも変わる。1日目に「このエラーはDBのコネクションプールに起因していた」と判明したとする。2日目のセッションでも、エージェントはその調査結果を覚えており、同じ調査を繰り返さずに続きから始められる。

Sentryが構築した「バグを検出→Claudeがパッチを書いてPRを作成する」パイプラインも、こうしたセッション間の文脈継続があって初めて実用的なものになる。

マルチエージェントで知識を共有する

研究エージェントAが発見した市場情報を共有ストアに書き込み、報告書作成エージェントBがその情報を読んで文書化する。エージェント間でのナレッジ共有が、ストアを介して自然に実現できる。

ビジネス担当者視点のユースケース——現場での活用イメージ

カスタマーサポートエージェントが過去の対応を学ぶ

カスタマーサポートのエージェントがあるとしよう。よくあるクレームのパターン、特定製品に多いトラブルの傾向、効果的な対応フレーズ——こういった知識を、対応を重ねるごとにメモリストアに蓄積していける。

Wisedocsは文書検証パイプラインにManaged Agentsのメモリを組み込み、繰り返し登場する書類の問題パターンをエージェントに記憶させた。その結果、検証スピードが30%向上したという。

営業支援エージェントが顧客情報を記憶する

顧客Aとの商談で「予算は上期に集中している」「意思決定者は技術部門長」といった情報が出た場合、それをメモリに書き込んでおく。次の商談セッションでエージェントはその情報を踏まえた提案を最初から行える。CRMに入力するほどではない細かいニュアンスを拾えるのが利点だ。

社内ナレッジを継続的に更新するエージェント

新入社員向けのQ&Aエージェントが、よくある質問とその回答を学習し続ける。最初は薄かったナレッジベースが、運用を重ねるごとに充実していく。エンジニアがナレッジベースを手動でメンテナンスしなくていい。

実際の導入事例から見る効果

公式ブログで紹介された事例をもとに、具体的な数字を確認しておこう。

楽天：初回エラー率97%削減

楽天はManaged Agentsのメモリを活用して、エージェントが毎セッションから学習する仕組みを構築した。その結果、初回パスのエラーが97%減少し、コストは27%削減、レイテンシも34%改善したという。ユーザーがエージェントのミスを修正するために費やす時間が大幅に減ったことが大きい。

Wisedocs：検証スピード30%向上

文書検証パイプラインで、頻出する書類の問題パターンをクロスセッションメモリで記憶させた。「考えていなかった問題まで自動で見つけて記憶してくれた」というフィードバックも印象的だ。

Netflix、Ando

Netflixのエージェントは、複数のターンを経て得られた知見や会話中の人間からの修正を、プロンプトやスキルを手動更新することなくセッション間で引き継いでいる。Andoはメモリインフラ構築から解放され、プロダクト開発に集中できるようになったと語っている。

他サービスとの比較——何が違うのか

メモリを持つAIエージェント基盤は他にも存在する。主要な選択肢と比較してみよう。

項目	Claude Managed Agents (Memory)	OpenAI Assistants / Responses API	LangGraph / 自前構築
メモリの永続化	ファイルシステムベース（組み込み）	Thread/Vectorstore（別途設定）	自前実装が必要
マルチエージェント共有	ストアをシェアして同時アクセス可能	プロジェクトレベルで可能	設計次第
監査ログ	全変更にバージョン管理・アクターを記録	限定的	自前実装
ロールバック	バージョン単位でリストア可能	なし	自前実装
機密情報の削除	Redact機能で履歴から抹消	なし	自前実装
料金	トークン+$0.08/セッション時間	トークン料金のみ（インフラは無料）	インフラ費用が別途発生
モデルの自由度	Claudeのみ	OpenAIのみ	マルチモデル対応可
ベンダーロックイン	高い	高い	低い
導入の手軽さ	高い（数行のコード）	高い	低い（設計コスト大）

料金について少し補足する。Managed Agentsはトークン料金に加えて$0.08/セッション時間がかかる。24のエージェントが1日8時間稼働する場合、セッション料金だけで1日あたり$15.36（約2,300円）になる計算だ。長時間稼働するエージェントが多いケースでは、事前に試算しておく必要がある。

一方、OpenAI Agents SDKはオープンソースで基盤自体は無料だが、APIトークンは別途課金される。インフラを自前で持てるチームには選択肢になりうる。

見落としがちな注意点と現実的な制限

パブリックベータであることの意味

現時点でメモリ機能は「パブリックベータ」、さらに技術的には「リサーチプレビュー」という段階だ。APIドキュメントには managed-agents-2026-04-01 ベータヘッダーが必須と明記されている。動作が改善される代わりに、リリース間で挙動が変わる可能性もある。本番の基幹業務に投入する前に、十分な検証期間を設けるべきだ。

ベータヘッダーの競合問題

Managed Agentsの managed-agents-2026-04-01 と他のベータ機能ヘッダーを同時指定できない問題が報告されている。複数のベータ機能を組み合わせた実装を検討する場合は、事前に制約を確認しておく必要がある。

シークレット管理機能がまだない

OAuth、サービスアカウントJSON、APIキーを安全に渡す仕組みがまだ実装されていない。外部サービス連携を伴うエージェントを構築する場合、認証情報の扱いに別途工夫が必要になる。

データがAnthropicのインフラを通る

エージェントが処理するすべてのデータ（ツールの入出力を含む）はAnthropicのインフラを通る。エンタープライズアカウントには契約上のデータプライバシー保護があるが、エアギャップ（完全な外部遮断）環境ではない。機密性の高い情報を扱うユースケースでは、法務・コンプライアンス部門との確認が必要だ。

ベンダーロックインのリスク

Managed Agentsで構築したエージェントのオーケストレーション層はClaudeとAnthropicのインフラに紐づく。他のモデルへの移行や、オンプレミス環境への移植は容易ではない。将来的な可搬性を重視するチームは、LangGraphなどのフレームワーク採用も検討したほうがいい。

メモリの肥大化と精度低下

ストアに蓄積された情報が増えすぎると、エージェントが必要な情報を見つけにくくなったり、古い情報と新しい情報が混在する問題が起きる。Anthropicは「1ファイルあたりの上限は100KB（約25,000トークン）」としており、「大きなファイルを少数作るより、小さな焦点を絞ったファイルを多数作る」設計を推奨している。定期的なメモリのレビューと整理も、運用上の課題になってくる。

開発者向け：基本的な使い方の流れ

実際の実装イメージを掴んでおこう。詳細は公式ドキュメントに委ねるが、大まかな流れはこうだ。

ステップ1：メモリストアを作成する

名前と説明を指定してストアを作成する。説明文はエージェントに渡されるので、「何が入っているか」を明確に書く。

curl -fsS https://api.anthropic.com/v1/memory_stores \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  -d '{
    "name": "User Preferences",
    "description": "ユーザーごとの設定と過去プロジェクトの文脈"
  }'

ステップ2：セッションにストアをアタッチする

エージェントセッション作成時に resources 配列でストアを指定する。アクセス権は read_write（読み書き可能）か read_only（読み取り専用）を選べる。

ステップ3：あとはエージェントに任せる

セッションが始まると、エージェントは自動でストアを確認してからタスクに入る。タスク完了後には学んだことを自動で書き込む。

メモリの確認と修正

APIからメモリ一覧の取得、個別ドキュメントの読み書き、楽観的ロック（content_sha256による競合防止）、バージョン履歴の閲覧と特定バージョンへのロールバックが可能だ。機密情報が誤ってメモリに書き込まれた場合は、Redact機能で履歴から内容を消去できる。これはコンプライアンス対応として重要な機能だ。