Claude Managed Agents Memory（公開β）｜Rakuten 97%エラー減・$0.08/時間・業務4パターンと設定手順

Q: Claude Managed Agents Memoryとは何か

私の理解を一行で書くと、Claudeエージェント専用の永続ストレージAPI、という位置づけ。公式ドキュメントの言い方を借りるとこうなります。

Q: どんな業務で効いているのか（一次ソースの4つの事例）

ここが今回一番ボリュームある章。Anthropic公式と顧客事例から、実際に成果を出した4パターンを引いてきます。

Q: Memory Storeを1本作る手順（公式ドキュメント準拠）

公式ドキュメントの手順を、個人開発者が追えるようにステップ化してあります。コード実装自体はClaude Codeに書かせれば十分なので、ここでは流れだけ。

この記事で分かること

Claude Managed Agents Memory（2026-04-23公開β）の中身と、ChatGPTのメモリ機能と何が違うか
Rakuten・Wisedocsなどの一次ソースが示した業務成果と、4つの業務適用パターン
ファイルシステム型メモリという設計思想と、read_only/read_write使い分けという落とし穴
公式ドキュメント準拠の「Memory Storeを1本作る手順」

AIエージェントに毎回同じ設定を教え直していて、
しんどくなった人向けの記事です。

Anthropicが2026-04-23に公開βで出したClaude Managed Agents Memoryは、
この「毎回ゼロから」を終わらせる機能。
ファイルシステム型の永続メモリをAPI経由でエージェントに持たせられるという話ですね。

結論だけ先に置くと、
個人開発者や副業でClaude SDKを触ってる層にとって、
ここは一度目を通しておいて損ない領域。
公式ブログと公式ドキュメント、
それにRakutenやWisedocsの顧客事例を軸に、
実運用目線で整理していきます。

Claude Managed Agents Memoryとは何か

私の理解を一行で書くと、
Claudeエージェント専用の永続ストレージAPI、
という位置づけ。
公式ドキュメントの言い方を借りるとこうなります。

Memory stores are collections of text documents that are scoped to a workspace and optimized for Claude. At session start, the store is mounted inside the agent's container as a directory at /mnt/memory/.

出典: platform.claude.com/docs/en/managed-agents/memory

ここが私から見て面白いのは、
専用のメモリAPIを叩くわけではない、
という点。
エージェントは普通のbashやファイル操作ツールでディレクトリを読み書きするだけ、
という設計。

Managed Agents本体が2026-04-08に公開β、
Memoryはその15日後の2026-04-23に追加。
ベータヘッダーはmanaged-agents-2026-04-01で、
SDKを使っていれば自動付与されるので手動指定は不要ですね。

なぜファイルシステム型なのか

ここがChatGPTのメモリ機能との決定的な違い。
Anthropic Engineering Blogはアーキテクチャ思想をこう説明しています。

We applied the abstraction principles of operating systems — processes, files — to agent infrastructure.

出典: anthropic.com/engineering/managed-agents

OSの抽象をエージェントに持ち込んだ、
という話。
プロセス（brain=Claude＋harness）とファイル（hands=sandbox＋tools）を分けた結果、
メモリが「APIで呼ぶ魔法のオブジェクト」ではなく「ディレクトリ内のファイル」になった。

これ、
地味だけど効いてきます。
Hacker Newsの議論では「better suited for solving technical tasks」というコメントが付いていて、
技術タスク向きという評価。

参考: Hacker News: Memory vs ChatGPT議論

ChatGPTメモリ・Gemini・Claudeの違い

ざっくり整理すると、それぞれが狙ってる用途は別物です。

ツール	設計思想	主な用途	共有・権限制御
ChatGPT Memory	会話の要約・抽出を自動記憶	個人ユーザーの好み学習	ユーザー単位、共有不可
Gemini Notebooks	ドキュメント集約型ワークスペース	個人・チームの資料整理	ワークスペース共有あり
Claude.ai Projects	会話履歴＋添付ファイル保持	Claude.ai個人利用	アカウント内限定
Claude Managed Agents Memory	APIで明示的に読み書きするファイル型ストア	業務エージェントの永続化	read_only/read_write権限制御・監査ログ・複数エージェント共有可

用途が根本的に違う。
ChatGPTは個人向け、
Claude Managed Agents Memoryは業務エージェント向け。
比較する土俵が別、
と見るのが正確ですね。

どんな業務で効いているのか（一次ソースの4つの事例）

ここが今回一番ボリュームある章。
Anthropic公式と顧客事例から、
実際に成果を出した4パターンを引いてきます。

事例1. Rakuten：エラー97%減、コスト27%減、レイテンシ34%減

Rakutenの顧客事例ページに載っている数字はなかなか強烈。

97% reduction in first-pass errors, 27% lower cost, and 34% lower latency.

Memory in Claude Managed Agents lets us put continuous learning into production at scale. Individual learning becomes organizational learning instantly.

— Yusuke Kaji, GM of AI for Business, Rakuten
出典: claude.com/customers/rakuten-qa

97%減は「初回エラー」の数字。
リリース頻度は四半期1回から2週間に1回へ、
機能デリバリーは24日から5日（99.9%精度）へと短縮されたとも書いてあります。

これ、
正直やばい。
個人の学習を組織の学習に即時変換するという発想自体が、
メモリ機能の本質を言い当ててる気がします。

事例2. Wisedocs：ドキュメント検証が30%高速化

公式ブログのWisedocs事例はこちら。

Using cross-session memory to recognize recurring document issues, speeding up verification by 30%.

A good memory API gets rid of many infrastructure headaches, especially when building across agents.
— Denys Linkov, Head of ML, Wisedocs
出典: claude.com/blog/claude-managed-agents-memory

「繰り返し発生するドキュメント問題を記憶する」という使い方。
一度人間が直したパターンを覚えておけば、
次回以降は自動で同じ修正を提案できる、
という話ですね。

事例3. Ando：メモリインフラから解放された

Andoの創業者コメントが、個人開発者にとって一番刺さる部分。

Memory lets us stop building memory infra and focus on the product itself.
— Sara Du, Founder, Ando
出典: claude.com/blog/claude-managed-agents-memory

メモリインフラを自前で組むのをやめて、
プロダクトに集中できる、
と。
副業や個人開発でAIエージェントを組んでいる層には、
ここが一番効く一文。

事例4. NTT DATA：8セント／セッション時間で本番投入

InfoQの記事ではNTT DATAのAI担当ディレクターのコメントも拾われています。

All the infrastructure complexity that used to take months is now native to the platform. At 8 cents per session hour, you go from idea to production in days instead of months.
— Radhika Menon, Sr. Director AI, NTT DATA
出典: infoq.com/news/2026/04/anthropic-managed-agents/

セッションランタイム$0.08/時間という料金設定。
このラインがManaged Agents全体のコスト感を決めています。
個人開発者がPoCを回すラインとしては、
現実的な水準。

4事例から読める業務適用パターン

事例を束ねると、Memory機能が効く業務は以下4つに分類できます。

業務パターン	メモリの使い方	該当事例
顧客対応の継続学習	過去の問い合わせパターンと解決策を蓄積、次回エージェントへ引き継ぎ	Rakuten
社内コーディング支援	自社コーディング規約・過去の修正履歴を永続化し再利用	Rakuten（四半期1回→2週間1回のリリース加速）
自走エージェントの失敗学習	繰り返し発生する問題パターンを記録、同じ失敗を避ける	Wisedocs
組織ナレッジ共有	複数エージェント間で共通の知識ベースをread_onlyで共有	Rakuten（individual→organizational learning）

どの業務にも共通するのは「一度学んだことを、
次回のセッション・別のエージェントにも引き渡せる」という1点。
これまで自前で書いてきたメモリインフラが、
そのままAPIに載った、
と整理できます。

Memory Storeを1本作る手順（公式ドキュメント準拠）

公式ドキュメントの手順を、
個人開発者が追えるようにステップ化してあります。
コード実装自体はClaude Codeに書かせれば十分なので、
ここでは流れだけ。

STEP1. Memory Storeを作成する
Anthropic APIにPOST /v1/memory_storesでnameとdescriptionを投げる。descriptionはエージェントのシステムプロンプトに直接渡されるので、「このストアに何が入っているか」を具体的に書くのがコツ。

STEP2. 事前資料をシード（任意）
セッション開始前に参照したい資料がある場合、POST /v1/memory_stores/{id}/memoriesでファイルを先に入れておく。1記憶あたり最大100KB（約25Kトークン）まで。

STEP3. セッション作成時にアタッチする
セッション作成APIのresources[]配列にMemory Store IDを指定。このときaccessをread_writeかread_onlyで選ぶ。外部入力を扱うなら後述の通りread_only一択。

STEP4. エージェント側はファイルシステム操作だけ
セッションが始まると/mnt/memory/にディレクトリとしてマウントされる。エージェントは普通のbashやファイル操作ツールで読み書きするだけ。専用のメモリAPIは叩かない。

STEP5. バージョン管理・監査ログを確認する
全変更にmemver_...形式の不変バージョンIDが振られる。履歴は30日間保持され、必要ならredactで過去バージョンの中身を消せる（監査ログ自体は残る）。

ここで引っかかりやすいのが「アタッチはセッション作成時のみ、
後から追加・削除不可」という点。
動的にメモリを切り替えたいなら、
セッションを分けて設計する必要があります。

手順の一次ソース: 公式Memory ドキュメント

料金はどれくらいかかるのか

公式pricingページの情報を整理します。

項目	料金	備考
セッションランタイム	$0.08/session-hour	`running`状態のみ課金。idle/rescheduling/terminatedは課金なし
トークン料金（Opus 4.7）	$5/MTok input、$25/MTok output	通常のモデル料金と同一
Memory機能追加料金	公式に記載なし	ストレージ単体課金は現時点で見当たらず
Batch API割引・Fast mode	非適用	Managed Agentsには使えない

公式の計算例だと、
Opus 4.7で1時間稼働、
50Kトークン入力＋15Kトークン出力で合計$0.705。
個人開発者の動作検証ならランチ1食分にも届かない水準です。

ただHacker Newsでは次のような釘を刺す声も出ています。

could become very expensive...like AWS where if you're not careful it will spin up 1000s of agents and rack up huge bills!
出典: Hacker News

セッション料金×同時実行数で一気に跳ねるリスクはある。
上限設定は先に入れておくのが安全ですね。

公式料金ページ: platform.claude.com/docs/en/about-claude/pricing

公開βの上限値まとめ（2026-04-24時点）

公式ドキュメントのLimitsテーブルから拾った数字です。
個人開発規模なら引っかからない上限ばかりですが、
本番前に一度目を通しておく価値あり。

項目	上限
1組織あたり最大メモリストア数	1,000
1ストアあたり最大メモリ数	2,000
1ストアあたり最大ストレージ	100MB（104,857,600 bytes）
1ストアあたり最大バージョン数	250,000
1メモリあたり最大サイズ	100KB（約25Kトークン）
バージョン履歴保持期間	30日間（更新頻度低いメモリは超える場合あり）
1セッションあたり最大アタッチストア数	8
instructions最大文字数	4,096

私が気になったのは1メモリ100KBという粒度。
25Kトークン相当なので、
中規模の設計書やFAQ丸ごと1本分はここに収まる計算。
細かすぎず大きすぎず、
現実的なサイズ感。

落とし穴：read_writeデフォルトとプロンプトインジェクション

ここ、絶対に踏んでおきたい話。公式ドキュメントが警告ブロックで明示しています。

Memory stores attach with read_write access by default. If the agent processes untrusted input (user-supplied prompts, fetched web content, or third-party tool output), a successful prompt injection could write malicious content into the store. Later sessions then read that content as trusted memory. Use read_only for reference material, shared lookups, and any store the agent does not need to modify.
出典: 公式Memory ドキュメント

デフォルトがread_write。
つまり何も指定しないと、
エージェントはメモリに書き放題。
ここに外部入力（ユーザー入力、
Web取得コンテンツ、
外部ツール出力）を食わせると、
プロンプトインジェクションで汚染されたメモリが次回セッションに持ち越される、
という構図です。

研究事例もあります。
embracethered.comの実験では、
Opus 4.7に対してChatGPTが生成した画像経由でメモリ汚染攻撃が10試行中5回成功したとのこと。

the attack is more likely to succeed when no memories are present initially.
出典: embracethered.com

空のメモリストアほど汚染されやすい、という話。初期化直後こそ要注意。

私の整理では、
外部入力を扱うエージェントにはread_onlyを渡す、
が鉄則。
書き込みが必要なメモリと読み取り専用のメモリを分けて、
1セッションに複数アタッチする設計が現実解です（上限8ストアまでアタッチ可能なので枠はある）。

他にも出ている懸念の声

InfoQとHacker Newsを中心に、
批判的な意見も拾っておきます。
フェアに見るなら両面必要。

If the intention is to become a platform, the trajectory definition needs to be open source, and proposing a public open standard. But from what I read, this is a lock in into their SDK and their format.
— Weilun Chen, Stealth創業者
出典: InfoQ

being locked into a single model provider is a deal breaker...you want to be able to compare different models.
— Hacker News ユーザー0o_MrPatrick_o0
出典: Hacker News

ロックインへの警戒。
マルチモデルで比較したい層にとっては、
Managed Agents SDKに張り付くのがリスクに映るという話ですね。

Dev.toの深掘り記事は、技術側の懸念を指摘しています。

data traverses Anthropic's infrastructure even for on-prem-adjacent workloads. p99 latency of one agent becomes p50 of the next in coordinated multi-agent workflows.
出典: Dev.to

VPCピアリング非対応、
データ残留の問題、
マルチエージェントでレイテンシが連鎖する話。
エンタープライズ本番投入にはまだ要検討、
という論調。

結局どんな人が触るべきか

整理するとこうなります。

触る価値が高い層: Claude SDKやClaude Codeで既にエージェント組んでる個人開発者・副業層。自前メモリインフラから解放されたい人。PoCを$0.08/時間で回して感触掴める
様子見でいい層: マルチモデル比較前提の開発チーム。VPCピアリング必須のエンタープライズ。研究preview扱いのoutcomes/multiagentが本命の用途
メリット小さい層: 個人ユーザー向けチャット用途（これはChatGPT Memoryで十分）

Aisola Labの立場から見ると、
Claude特化で追っかけてる個人開発者・副業エンジニアには、
公開βのうちに触っておく理由がある機能。
Managed Agents本体のオンボードが30分、
Memoryはそこに載せるだけ、
というのが公式の言い分です。

FAQ

Q. Claude Managed Agents Memoryは2026-04-24時点でどのステータスですか。

A. Public Beta（公開β）です。
2026-04-23にresearch previewからpublic betaへ昇格しました。
利用にはmanaged-agents-2026-04-01のベータヘッダーが必要ですが、
SDK経由なら自動付与されます。
出典: 公式リリースノート

Q. ChatGPTのメモリ機能とは何が違いますか。

A. 用途が別物です。
ChatGPTは個人ユーザーの好みを自動記憶するチャット向け機能、
Claude Managed Agents Memoryは開発者が業務エージェント用にAPIで明示的に作るファイル型ストアです。
権限制御・監査ログ・複数エージェント共有はClaude側が持っています。

Q. 料金はいくらかかりますか。

A. セッションランタイム$0.08/時間と、
通常のトークン料金（Opus 4.7なら$5/MTok input、
$25/MTok output）です。
Memory機能そのものの追加料金は公式に記載されていません。
出典: 公式pricing

Q. プロンプトインジェクションが怖いのですが対策はありますか。

A. Anthropic公式が明示的に推奨しているのは「外部入力を扱うエージェントにはread_onlyアクセスを使う」ことです。
デフォルトのread_writeのままにしておくと、
汚染されたメモリが次回セッションに引き継がれるリスクがあります。

Q. 個人開発者でも触れますか。

A. 触れます。
Managed Agentsは公開β時点で、
全APIアカウントにデフォルトで有効。
SDKはPython/TypeScript/C#/Go/Java/PHP/Rubyの7言語、
CLI（antコマンド）からも全Memory操作を同じように叩ける形。