ClaudeCloudflare2026/04/17 13:00

Agents that remember: introducing Agent Memory

要点だけを先に読めるように短く再構成したセクションです。

元記事

Quick Digest

要約

要点だけを先に読めるように短く再構成したセクションです。

claudejamodel: claude-haiku-4-5

Agent Memory: エージェントに永続的な記憶機能を提供する新サービス

Key Points

  • 永続的なエージェント記憶機能
  • コンテキストウィンドウ圧迫なし
  • データ所有権とエクスポート機能

Summary

Cloudflareが Agent Memory の私的ベータ版を発表しました。これはエージェント会話から情報を抽出し、コンテキストウィンドウを圧迫することなく必要な時に利用可能にする管理型サービスです。AIエージェントに永続的な記憶を提供し、重要な情報を保持しながら不要な情報を忘れることで、時間とともにスマートになります。

Key Points

  • マネージドサービス: 抽出と検索をバックグラウンドで処理し、エージェントのコンテキストウィンドウを圧迫しない設計
  • 複数の操作: ingest(会話から記憶を抽出)、remember(重要な情報を直接保存)、recall(記憶を検索して合成回答を取得)、forget(記憶を削除)をサポート
  • 柔軟な利用方法: 個別エージェントの記憶、カスタムエージェントハーネス、複数エージェント・人・ツール間での共有記憶に対応
  • データ所有権: すべての記憶はエクスポート可能で、ユーザーが蓄積した知識はCloudflareから持ち出せる
  • インジェストパイプライン: 多段階パイプラインで抽出・検証・分類・保存を実行し、Facts、Events、Instructions、Tasksの4種類に分類
  • Cloudflare Workers統合: バインディング経由でアクセス可能で、REST APIでWorkers外のエージェントからもアクセス可能

Full Translation

翻訳

原文の流れを保ったまま読める翻訳セクションです。

claudejamodel: claude-haiku-4-5

記憶を持つエージェント: Agent Memory の紹介

2026-04-17 Tyson Trautmann Rob Sutter 12分読了

概要

Cloudflare上でますます高度なエージェントを構築する開発者が直面する最大の課題の1つは、適切なタイミングで適切な情報をコンテキストに取り込むことです。モデルが生成する結果の品質は、それが操作するコンテキストの品質に直結していますが、コンテキストウィンドウサイズが100万(1M)トークンを超えて増加しても、コンテキストロットは未解決の問題のままです。

2つの悪い選択肢の間に自然な緊張が生じます。すべてをコンテキストに保持して品質の低下を見守るか、積極的に削減してエージェントが後で必要とする情報を失うリスクを冒すかです。

本日、Agent Memoryのプライベートベータを発表します。これはエージェント会話から情報を抽出し、コンテキストウィンドウを満たすことなく必要な時に利用可能にする管理サービスです。AIエージェントに永続的なメモリを提供し、重要なことを思い出し、不要なことを忘れ、時間とともにより賢くなることを可能にします。

エージェントメモリの現状

エージェントメモリはAIインフラストラクチャの中で最も急速に発展している分野の1つであり、新しいオープンソースライブラリ、管理サービス、研究プロトタイプがほぼ毎週立ち上がっています。これらのオファリングは、何を保存するか、どのように取得するか、どのような種類のエージェント向けに設計されているかについて大きく異なります。

LongMemEvalLoCoMoBEAMなどのベンチマークは有用なリンゴとリンゴの比較を提供していますが、特定の評価に過度に適合し、本番環境で機能しなくなるシステムを構築するのも簡単にしてしまいます。

既存のオファリングはアーキテクチャでも異なります。

  • バックグラウンドで抽出と取得を処理する管理サービス
  • メモリパイプラインを自分で実行する自己ホスト型フレームワーク
  • メモリロジックをエージェントのメインコンテキストから除外する制約付きの目的別APIを公開するもの
  • モデルにデータベースまたはファイルシステムへの生のアクセスを与え、独自のクエリを設計させるもの(ストレージと取得戦略にトークンを消費)
  • すべてをコンテキストウィンドウに収めようとするもの(必要に応じて複数のエージェント間で分割)
  • 取得を使用して関連するもののみを表示するもの

Agent Memoryは、意見を持つAPIと取得ベースのアーキテクチャを備えた管理サービスです。代替案を慎重に検討した結果、この組み合わせがほとんどの本番ワークロードの正しいデフォルトであると考えています。

厳密な取得パイプラインは、エージェントに生のファイルシステムアクセスを与えることより優れています。改善されたコスト性能に加えて、時間的ロジック、優先順位付け、命令追従など、本番環境で必要な複雑な推論タスクのための優れた基盤を提供します。

使用方法

Agent Memoryはプロファイルにメモリを保存します。プロファイルは名前でアドレス指定されます。プロファイルは複数の操作を提供します。

  • ingest: 会話を取り込む
  • remember: 何か重要なことを記憶する
  • recall: 必要なものを思い出す
  • list: メモリを一覧表示する
  • forget: 特定のメモリを忘れる

Ingestはバルクパスで、通常はハーネスがコンテキストを圧縮するときに呼び出されます。Rememberはモデルがその場で何か重要なことを保存するためのものです。Recallは完全な取得パイプラインを実行し、合成された回答を返します。

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // プロファイルを取得 -- セッション、エージェント、ユーザー間で共有される分離されたメモリストア
    const profile = await env.MEMORY.getProfile("my-project");

    // Ingest -- 会話からメモリを抽出(通常は圧縮時に呼び出される)
    await profile.ingest([
      {
        role: "user",
        content: "Set up the project with React and TypeScript."
      },
      {
        role: "assistant",
        content: "Done. Scaffolded a React + TS project targeting Workers."
      },
      {
        role: "user",
        content: "Use pnpm, not npm. And dark mode by default."
      },
      {
        role: "assistant",
        content: "Got it -- pnpm and dark mode as default."
      }
    ], { sessionId: "session-001" });

    // Remember -- 単一のメモリを明示的に保存(モデルによる直接的なツール使用)
    const memory = await profile.remember({
      content: "API rate limit was increased to 10,000 req/s per zone after the April 10 incident.",
      sessionId: "session-001"
    });

    // Recall -- メモリを取得し、合成された回答を取得
    const results = await profile.recall("What package manager does the user prefer?");
    console.log(results.result); // "The user prefers pnpm over npm."

    return Response.json({ ok: true });
  }
};

Agent Memoryは任意のCloudflare Workerからバインディング経由でアクセスされます。Workers外で実行されているエージェント向けに、他のCloudflare開発者プラットフォームAPIと同じパターンに従うREST APIを介してアクセスすることもできます。

Cloudflare Agents SDKで構築している場合、Agent Memoryサービスはメモリ部分のセッションAPIで圧縮、記憶、メモリ検索を処理するための参照実装として適切に統合されます。

構築できるもの

Agent Memoryはさまざまなエージェントアーキテクチャで動作するように設計されています。

個別エージェント向けメモリ

ClaudeコードやOpenCodeなどのコーディングエージェントで構築しているか、OpenClawやHermesなどの自己ホスト型エージェントフレームワークを使用しているか、Anthropicの管理エージェントなどの管理サービスを配線しているかに関わらず、Agent Memoryはエージェントのコアループに変更を加えることなく永続的なメモリレイヤーとして機能できます。

カスタムエージェントハーネス向けメモリ

多くのチームが独自のエージェントインフラストラクチャを構築しており、人間が関与せずに自律的に実行されるバックグラウンドエージェントも含まれています。Ramp Inspectは1つの公開例です。StripeとSpotifyは同様のシステムについて説明しています。これらのハーネスは、セッション間で永続し、再起動を乗り越えるメモリをエージェントに提供することからも利益を得ることができます。

エージェント、人、ツール間での共有メモリ

メモリプロファイルは単一のエージェントに属する必要はありません。エンジニアのチームはメモリプロファイルを共有できるため、1人のコーディングエージェントが学んだ知識は全員が利用できます。コーディング規約、アーキテクチャの決定、現在は人の頭の中に存在するか、コンテキストが削減されると失われる部族知識です。

コードレビューボットとコーディングエージェントはメモリを共有できるため、レビューフィードバックが将来のコード生成を形作ります。エージェントが蓄積する知識は一時的なものではなく、耐久性のあるチーム資産になります。

データはあなたのもの

エージェントがより能力を持つようになり、ビジネスプロセスにより深く組み込まれるにつれて、蓄積するメモリは本当に価値のあるものになります。運用状態としてだけでなく、構築に実際の作業がかかった機関知識としても。

顧客から、そのアセットを単一のベンダーに結びつけることが何を意味するのかについて、懸念が増えています。これは合理的です。エージェントが学ぶほど、そのメモリが一緒に移動できない場合の切り替えコストが高くなります。

Agent Memoryは管理サービスですが、データはあなたのものです。すべてのメモリはエクスポート可能であり、エージェントがCloudflareで蓄積する知識がニーズが変わった場合に一緒に移動できることを確認することにコミットしています。

長期的な信頼を得る正しい方法は、離脱を簡単にし、離脱したくないほど十分に良いものを構築し続けることだと考えています。

Agent Memoryの仕組み

上記で示したAPIの背後で何が起こるかを理解するには、エージェントがコンテキストを管理する方法を分解するのに役立ちます。

エージェントには3つのコンポーネントがあります。

  1. ハーネス: モデルへの繰り返し呼び出しを駆動し、ツール呼び出しを促進し、状態を管理します
  2. モデル: コンテキストを取得して補完を返します
  3. 状態: 現在のコンテキストウィンドウと、コンテキスト外の追加情報(会話履歴、ファイル、データベース、メモリ)の両方を含みます

エージェントのコンテキストライフサイクルの重要な瞬間は圧縮です。ハーネスがコンテキストを短縮してモデルの制限内に留まるか、コンテキストロットを回避することを決定します。

現在、ほとんどのエージェントは情報を永続的に破棄します。Agent Memoryは圧縮時に知識を保存し、失うことはありません。

Agent Memoryは2つの方法でこのライフサイクルに統合されます。

圧縮時のバルク取得

ハーネスがコンテキストを圧縮するとき、会話をAgent Memoryに送信して取得します。取得は、メッセージ履歴から事実、イベント、命令、タスクを抽出し、既存のメモリに対して重複排除し、将来の取得のためにメモリとして保存します。

モデルによる直接的なツール使用

モデルは、メモリと直接対話するツール(特定の情報についてメモリを検索する機能を含む)を取得します。モデルは、重要なことに基づいてメモリを明示的に保存する(remember)、メモリを重要でなくなったか真実でなくなったとしてマークする(forget)、保存されているメモリを確認する(list)こともできます。これらは軽量な操作で、モデルがクエリを設計したりストレージを管理したりする必要はありません。

プライマリエージェントはストレージ戦略にコンテキストを消費してはいけません。表示されるツール表面は意図的に制約されているため、メモリは実際のタスクの邪魔にならないようにします。

取得パイプライン

会話が取得のために到着すると、メモリを抽出、検証、分類、保存する多段階パイプラインを通過します。

最初のステップは決定論的IDの生成です。各メッセージは、セッションID、ロール、コンテンツのSHA-256ハッシュを128ビットに切り詰めたコンテンツアドレス指定IDを取得します。同じ会話が2回取得された場合、すべてのメッセージは同じIDに解決され、再取得がべき等になります。

次に、エクストラクタは2つのパスを並行して実行します。

  • フルパス: メッセージを約10K文字でチャンク化し、2メッセージのオーバーラップを持ち、最大4つのチャンクを同時に処理します。各チャンクはロールラベル、相対日付を絶対値に解決("yesterday"は"2026-04-14"になる)、ソース出所のための行インデックスを含む構造化トランスクリプトを取得します。

  • 詳細パス: より長い会話(9以上のメッセージ)の場合、フルパスと並行して実行され、名前、価格、バージョン番号、エンティティ属性など、広範な抽出が見落とす傾向がある具体的な値の抽出に特に焦点を当てたオーバーラップウィンドウを使用します。

2つの結果セットはマージされます。

次のステップは、抽出されたメモリを各ソーストトランスクリプトに対して検証することです。検証者は、エンティティアイデンティティ、オブジェクトアイデンティティ、位置コンテキスト、時間的精度、組織コンテキスト、完全性、関係コンテキスト、推論された事実が実際に会話によってサポートされているかどうかをカバーする8つのチェックを実行します。各項目は合格、修正、または削除されます。

パイプラインは、検証されたメモリを4つのタイプのいずれかに分類します。

  • 事実: 「プロジェクトはGraphQLを使用している」や「ユーザーはダークモードを好む」など、今現在真実である、原子的で安定した知識を表します
  • イベント: デプロイメントや決定など、特定の時間に何が起こったかをキャプチャします
  • 命令: 手順、ワークフロー、ランブックなど、何かをする方法を説明します
  • タスク: 現在取り組まれている内容を追跡します