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

この記事はClaudeで自動化やエージェントを組んでいる個人開発者・副業エンジニア向け（APIを触ったことがあれば読めます）。

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/.

（メモリストアはワークスペース単位のテキスト文書の集まりで、セッション開始時にエージェントの中で /mnt/memory/ というフォルダとして開かれる、の意）

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

私から見て面白いのは、専用のメモリAPIを叩くわけではない、という点。

エージェントは普通のコマンドでフォルダの中のファイルを読み書きするだけ、という作り。

Managed Agents本体が2026-04-08に公開β、Memoryはその15日後の2026-04-23に追加されました。

動かすのに必要なベータヘッダー（APIに付ける合図のようなもの）はSDKを使えば自動でつくので、手で指定する必要はないですね。

なぜわざわざファイル型にしたのか？

ここがChatGPTのメモリ機能との決定的な違いです。

Anthropicの技術ブログは、設計思想をこう説明しています。

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

（OSの考え方＝プロセスとファイルという分け方を、エージェントの土台にそのまま持ち込んだ、の意）

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

パソコンの仕組み（動いてるプログラム＝Claude本体と、保存されたファイル）をそのままエージェントに当てはめた、という話。

結果、メモリが「APIで呼ぶ謎のオブジェクト」ではなく「フォルダの中のファイル」になりました。

これ、地味だけど効いてきます。

中身がただのファイルなので、人間が後から開いて確認できるし、バージョン管理もしやすい。

技術タスク向きという評価が開発者コミュニティでも出ています。

ChatGPTメモリ・Gemini・Claudeの違いは？

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

用途が根本的に違います。

ChatGPTは個人向け、Claude Managed Agents Memoryは業務エージェント向け。

比較する土俵が別、と見るのが正確ですね。

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

ここが今回一番ボリュームのある章。

Anthropic公式と顧客事例から、実際に成果を出した4パターンを引いてきます。

事例1. Rakuten：初回の致命的エラー97%減、コストと応答時間は合計30%超の改善

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

97% reduction in initial critical errors, with cost and latency down more than 30%.

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

（初回の致命的エラーが97%減り、コストと応答時間は合わせて30%超改善した、の意。

1人の学びがすぐ組織全体の学びになる）

出典: Rakuten AI for Business責任者コメント claude.com/customers/rakuten-qa

97%減は「初回の致命的エラー」の数字です。

リリース頻度は四半期1回から2週間に1回へ、機能の提供は24日から5日（99.9%精度）へと短縮されたとも書いてあります。

これ、正直やばい。

1人の学習を組織の学習に即時変換するという発想が、この機能の本質を言い当ててる気がします。

事例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.

（繰り返し起きる書類の不備を記憶させてチェックを30%速くした。

良いメモリAPIは土台まわりの面倒を消してくれる、の意）

出典: Wisedocs ML責任者コメント claude.com/blog/claude-managed-agents-memory

「繰り返し起きる書類の不備を記憶する」という使い方ですね。

一度人間が直したパターンを覚えておけば、次回からは自動で同じ修正を提案できる、という流れ。

事例3. Ando：メモリの自作から解放された

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

Memory lets us stop building memory infra and focus on the product itself.

（メモリの土台を自作するのをやめて、プロダクト本体に集中できるようになった、の意）

出典: Ando 創業者コメント claude.com/blog/claude-managed-agents-memory

メモリの土台を自前で組むのをやめて、作りたいものに集中できる、と。

副業や個人開発でエージェントを組んでいる層には、ここが一番効く一文です。

事例4. NTT DATA：$0.08/時間で本番投入

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.

（これまで何ヶ月もかかっていた土台作りが、最初から備わっている。

1セッション1時間8セントで、思いつきから本番まで何ヶ月でなく数日で行ける、の意）

出典: NTT DATA AI担当ディレクターのコメント infoq.com/news/2026/04/anthropic-managed-agents/

エージェントを動かす時間に対して$0.08/時間という料金設定です。

個人開発者が試しに動かすラインとしては、十分に現実的な水準。

正直、$0.08/時間なら半日回しても1ドル以下。これは試さない理由がない。

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

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

どの業務にも共通するのは「一度学んだことを、次回のセッション・別のエージェントにも引き渡せる」という1点。

これまで自前で書いてきたメモリの仕組みが、そのままAPIに載った形ですね。

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

公式ドキュメントの手順を、個人開発者が追えるようにステップ化しました。

コードの実装自体はClaude Codeに書かせれば十分なので、ここでは流れだけ示します。

STEP1. Memory Storeを作る
Anthropic APIに POST /v1/memory_stores で name と description を投げます。descriptionはエージェントの指示文に直接渡るので、「このストアに何が入っているか」を具体的に書くのがコツ。
期待される結果: ストアIDが返ってきます。
詰まりどころ: descriptionを空や曖昧にすると、エージェントがそのメモリを参照しに行かないので、用途を1〜2文で書いておきます。

STEP2. 事前資料を入れておく（任意）
セッション開始前に参照させたい資料があるなら、POST /v1/memory_stores/{id}/memories でファイルを先に入れます。
期待される結果: ストアの中に資料ファイルが並びます。
詰まりどころ: 1ファイルあたり最大100KB（約25Kトークン）まで。大きい設計書は分割して入れます。

STEP3. セッション作成時にアタッチする
セッションを作るAPIの resources[] にMemory Store IDを指定。このとき access を read_write（読み書き可）か read_only（読み取り専用）で選びます。
期待される結果: そのセッションのエージェントが /mnt/memory/ からストアを読めるようになります。
詰まりどころ: 外部からの入力を扱うなら、ここで必ず read_only を選びます（理由は後半の落とし穴の章で）。

STEP4. エージェント側はファイル操作だけ
セッションが始まると /mnt/memory/ にフォルダとして開かれます。エージェントは普通のコマンドでファイルを読み書きするだけ。専用のメモリAPIは叩きません。
期待される結果: エージェントが前回のメモを読んで、続きから作業を始めます。
詰まりどころ: アタッチはセッション作成時のみ。後から追加・削除できません。

STEP5. バージョン管理・監査ログを確認する
全変更に memver_... 形式の変わらないバージョンIDが振られます。履歴は30日間残り、必要なら redact で過去バージョンの中身を消せます（消した記録自体は残る）。
期待される結果: いつ誰が何を書き換えたか追えます。
詰まりどころ: 個人情報を入れてしまった時の消し方を、本番前に一度試しておくと安心です。

ここで一番引っかかりやすいのが「アタッチはセッション作成時のみ、後から追加・削除できない」という点。

途中でメモリを切り替えたいなら、セッションを分けて設計する必要があります。

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

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

公式の計算例だと、Opus 4.7で1時間稼働、入力50Kトークン＋出力15Kトークンで合計$0.705。

個人開発者の動作確認なら、ランチ1食分にも届かない水準です。

私なら、月1〜2回の検証用途でも$1以内に収まります。

本格運用するまでは財布の心配はほぼ要らないですね。

ただ、コミュニティでは料金面で釘を刺す声も出ています。

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

（うっかりするとAWSみたいに数千のエージェントが立ち上がって請求が跳ねる、という指摘）

出典: 開発者コミュニティの議論 Hacker News

セッション料金 × 同時実行数で一気に膨らむリスクはあります。

上限設定は先に入れておくのが安全ですね。

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

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

公式ドキュメントの上限テーブルから拾った数字です。

個人開発の規模なら引っかからない上限ばかりですが、本番の前に一度目を通しておく価値あり。

私が気になったのは1メモリ100KBという粒度。

25Kトークン相当なので、中規模の設計書やFAQ丸ごと1本分はここに収まる計算です。

細かすぎず大きすぎず、現実的なサイズ感ですね。

落とし穴：初期設定は「書き込みOK」になっている

ここ、絶対に踏んでおきたい話です。

公式ドキュメントが警告ブロックではっきり書いています。

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.

（メモリは初期状態で「読み書き可」でつながる。

エージェントが信用できない入力＝ユーザー入力・取得したWebの中身・外部ツールの出力を扱うと、プロンプトインジェクションで悪意ある内容がストアに書き込まれ得る。

後のセッションはそれを「正しい記憶」として読んでしまう。

参照用や共有用、書き換える必要のないストアは「読み取り専用」にせよ、の意）

出典: 公式Memory ドキュメント

初期設定が「読み書き可」です。

つまり何も指定しないと、エージェントはメモリに書き放題。

ここに外部の入力（ユーザー入力、Webから取ってきた文章、外部ツールの出力）を食わせると、汚染されたメモリが次回セッションに持ち越される、という構図です。

実際に攻撃が通った研究もあります。

あるセキュリティ研究では、Opus 4.7に対して画像経由でメモリ汚染を狙った実験で、10回中5回成功したと報告されています。

the attack is more likely to succeed when no memories are present initially.

（メモリが空っぽの初期状態ほど、攻撃が成功しやすい、の意）

出典: セキュリティ研究ブログ embracethered.com

空のメモリストアほど汚染されやすい、という話。作りたての直後こそ要注意です。

私なら、外部の入力を扱うエージェントには迷わず「読み取り専用」を渡します。

書き込みが必要なメモリと読み取り専用のメモリを分けて、1セッションに複数つなぐ設計が現実解。

最大8ストアまでつなげるので、枠は十分あります。

他にも出ている懸念の声は？

批判的な意見もフェアに拾っておきます。両面を見ておかないと判断を誤るので。

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.

（プラットフォームを狙うなら仕様をオープンにして公開標準を提案すべきだが、読む限りこれは自社SDKと自社フォーマットへの囲い込みだ、という指摘）

出典: スタートアップ創業者のコメント InfoQ

being locked into a single model provider is a deal breaker...you want to be able to compare different models.

（1社のモデルに縛られるのは致命的、複数モデルを比較できる状態でいたい、という意見）

出典: 開発者コミュニティの議論 Hacker News

共通するのは囲い込みへの警戒ですね。

複数のモデルを比べながら使いたい層にとっては、Managed Agents SDKに張り付くのがリスクに映る、という話。

技術側の懸念を指摘する深掘り記事もあります。

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.

（社内設置に近い処理でもデータがAnthropic側を経由する。

複数エージェントを連携させると、1つのエージェントの遅さが次のエージェントの標準的な遅さに化ける、という指摘）

出典: 技術解説ブログ Dev.to

自社ネットワーク内に閉じる構成に未対応、データが外を通る問題、複数エージェントで遅延が連鎖する話。

大企業の本番投入にはまだ要検討、という論調ですね。

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

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

私の見方では、Claude特化で追っかけてる個人開発者・副業エンジニアには、公開βのうちに触っておく理由がある機能です。

Managed Agents本体の初期設定が30分、Memoryはそこに載せるだけ、というのが公式の言い分。

週末の半日もあれば、$1かからずにひと通り試せる計算です。

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言語、コマンドライン（antコマンド）からも全Memory操作を同じように叩けます。

関連リンク

• 公式ブログ: Claude Managed Agents Memory発表
• 公式Memory ドキュメント
• 公式Managed Agents オーバービュー
• 公式pricing ページ
• Anthropic Engineering Blog: アーキテクチャ解説
• Rakuten顧客事例（エラー97%減・コスト/応答時間30%超改善の一次ソース）
• InfoQ: Managed Agents報道
• Hacker News: Memory設計議論
• Hacker News: ロックイン議論
• Dev.to: 技術深掘り分析
• embracethered: プロンプトインジェクション研究

※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。