Anthropicのリリースノートを眺めていたら、4月23日付けで気になるアップデートが来ていた。Claude Managed AgentsのMemory機能がパブリックベータに入った。ヘッダーは managed-agents-2026-04-01 で共通化されている。
これ、自分のエージェント実装に刺さる話だ
今の自分のコードを振り返ると、マルチターンのやり取りをどう保持するかで結構泥臭い実装をしていた。会話履歴をそのまま全部コンテキストに詰め込む方式で、トークン数が膨らんでコストがじわじわ増えていくやつ。LLMのAPIコスト最適化を気にし始めてから、これをどうにかしたいとずっと思っていた。
Managed AgentsのMemoryが「マネージドで使える」という意味は、自前でベクトルDBを立てたり、Redis的なものでセッション管理したりしなくていいということ。少なくとも今の自分の設計と比べると、インフラ層の面倒ごとを削れる可能性がある。
ヘッダー一本で動くなら試す価値はある
Managed Agentsは4月8日のローンチから managed-agents-2026-04-01 というベータヘッダーが必要だった。Memoryも同じヘッダーの下に入ってきたから、既にManaged Agentsを触っている人は追加の設定なしに使い始められる。
# リクエストヘッダーにこれを含める
anthropic-beta: managed-agents-2026-04-01公式ドキュメントには「Using agent memory」という統合ガイドが別途用意されている。まずそこを読みに行くのが先だと思う。
ちなみにこの週はほかにも動きがあって、4月16日にはClaude Opus 4.7がリリースされた。$5/$25 per MTokという価格はOpus 4.6から変わっていない。ただし「APIのブレーキングチェンジあり」と明記されていて、Opus 4.6から上げるなら移行ガイドを先に読めという話になっている。自分は今Opus系を本番で使っているわけじゃないけど、将来的に乗り換えるときに慌てないよう把握しておきたい。
もう一個気になったのが4月9日のAdvisor Toolのベータ。「高性能なAdvisorモデルが生成の途中で戦略的な指示を出し、重いトークン生成はExecutorモデルに任せる」という設計思想。要するに賢さとコストのトレードオフを構造で解決しようとしている。これはLLMのAPIコスト最適化という観点でかなり興味深い。
Memoryの話に戻ると、自分が一番気にしているのは「メモリの寿命とスコープ」だ。セッションをまたいで保持されるのか、エージェントインスタンス単位なのか。コンテキスト汚染が起きたときにどうリセットするのか。パブリックベータでドキュメントが出た今、その辺りの挙動を手元で確認するのが次のステップだと思っている。
自分は今週末、Managed Agentsの統合ガイドを実際に動かしながら読んでみるつもりだ。メモリ周りの挙動を確認して、今の会話履歴の持ち方と何が変わるかを比べてみる。