Agents that remember: introducing Agent Memory

openaijamodel: gpt-5-mini-2025-08-07

記憶するエージェント：Agent Memory の紹介

2026-04-17 — Tyson Trautmann, Rob Sutter — 読了時間: 12分

開発者が Cloudflare 上でますます高度なエージェントを構築するにつれて、最大の課題の一つは「適切な情報を、適切なタイミングでコンテキストに取り込むこと」です。モデルが出す結果の品質は、モデルが動作するコンテキストの品質に直接依存します。しかし、コンテキストウィンドウサイズが 1M トークンを超えても、コンテキストの劣化（context rot）は未解決の問題のままです。ここには二つの望ましくない選択肢の緊張があります：すべてをコンテキストに入れて品質低下を見守るか、あるいは攻撃的に削除して後でエージェントが必要とする情報を失うリスクを取るか。

本日、Agent Memory のプライベートベータを発表します。Agent Memory は会話から情報を抽出し、コンテキストウィンドウを埋めることなく必要なときに利用できるようにするマネージドサービスです。AIエージェントに永続的なメモリを与え、重要なものを想起し、不必要なものを忘れ、時間とともに賢くなることを可能にします。このポストでは、その仕組みと何が構築できるかを説明します。

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

エージェント的メモリは AI インフラストラクチャの中で最も急速に動いている分野の一つであり、オープンソースライブラリ、マネージドサービス、研究プロトタイプがほぼ週次で登場しています。これらの提供物は、何を保存するか、どのように検索するか、どの種類のエージェント向けかで大きく異なります。LongMemEval、LoCoMo、BEAM のようなベンチマークは有用な比較を提供しますが、特定の評価に過学習したシステムを作りやすく、本番環境で破綻する危険性もあります。

既存の提供物はアーキテクチャにも差があります。抽出と検索をバックグラウンドで処理するマネージドサービス、メモリパイプラインを自分で実行するセルフホストのフレームワーク、メモリロジックをエージェントのメインコンテキストから切り離す制約付きの目的別 API、生のデータベースやファイルシステムへのアクセスをモデルに与え、モデル自身にクエリ設計を任せてトークンをストレージや検索戦略に消費させるもの、必要なら複数のエージェントに分割してコンテキストウィンドウに収めようとするもの、検索を使って関連するものだけを取り出すもの、などさまざまです。

Agent Memory は意見を持った API と検索ベースのアーキテクチャを備えたマネージドサービスです。我々は代替案を慎重に検討し、この組み合わせがほとんどの本番ワークロードにとって適切なデフォルトだと考えています。エージェントに生のファイルシステムアクセスを与えるよりも、より厳密な取り込み（ingestion）と検索パイプラインの方が優れています。コストとパフォーマンスの向上に加え、時間論理、上書き（supersession）、指示の遵守など、本番で必要な複雑な推論タスクに対するより良い基盤を提供します。将来的にプログラム的な問い合わせ用にデータを公開する可能性はありますが、それは例外的なケースで役立つものであり、一般的なケースにはならないと想定しています。

我々が Agent Memory を構築したのは、プラットフォーム上で見えるワークロードが既存のアプローチでは十分に対処できないギャップを露呈したからです。何週間・何ヶ月も実際のコードベースや本番システムに対して稼働するエージェントは、成長しても有用性を保つメモリを必要とします—単に新しいモデルのコンテキストウィンドウに収まるクリーンなベンチマーク上で良好に動くメモリではなく。高速な取り込みが必要です。会話をブロックしない検索が必要です。そして、クエリあたりのコストを合理的に保てるモデルで動く必要があります。

使い方

Agent Memory は名前でアドレスされるプロファイルにメモリを保存します。プロファイルは次の操作を提供します：会話を取り込む（ingest）、ある特定のことを記憶する（remember）、必要なものを想起する（recall）、メモリを一覧する、特定のメモリを忘れる（forget）。

ingest は通常、ハーネス（harness）がコンパクションを行うときに呼ばれるバルク経路です。
remember はモデルがその場で重要なことを保存するために使います。
recall はフル検索パイプラインを実行して統合された応答を返します。

以下は例です（Cloudflare Worker からのアクセス例）：

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // Get a profile -- an isolated memory store shared across sessions, agents, and users
    const profile = await env.MEMORY.getProfile("my-project");

    // Ingest -- extract memories from a conversation (typically called at compaction)
    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 -- store a single memory explicitly (direct tool use by the model)
    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 -- retrieve memories and get a synthesized answer
    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 サービスは Sessions API の memory 部分におけるコンパクション、記憶、検索処理の参照実装としてきれいに統合されます。

何が作れるか

Agent Memory は幅広いエージェントアーキテクチャで動くよう設計されています：

個々のエージェント向けのメモリ
- Claude Code や OpenCode のようなコーディングエージェント（人が関与する場合でも）や、OpenClaw や Hermes のようなセルフホストのエージェントフレームワーク、Anthropic’s Managed Agents のようなマネージドサービスに接続する場合でも、Agent Memory はエージェントのコアループを変更せずに永続メモリ層を提供できます。
カスタムエージェントハーネス向けのメモリ
- バックグラウンドで人が介在せずに自律的に動くエージェントを含む、多くのチームが独自のエージェントインフラを構築しています。Ramp Inspect は公開された例であり、Stripe や Spotify も類似のシステムを述べています。これらのハーネスは、セッションを超えて持続し、再起動を越えて生き残るメモリを持つことで恩恵を受けます。
エージェント、人物、ツール間で共有されるメモリ
- メモリプロファイルは単一のエージェントに属する必要はありません。エンジニアチームがメモリプロファイルを共有すれば、ある人のコーディングエージェントが学んだ知識が全員に利用可能になります：コーディング規約、アーキテクチャ上の決定、個人の頭の中に留まっている属人的知識や、コンテキストが剪定されると失われる知識など。コードレビュー用ボットとコーディングエージェントがメモリを共有すれば、レビューのフィードバックが将来のコード生成に反映されます。エージェントが蓄積する知識は、儚いものではなく、耐久性のあるチーム資産になります。

検索はメモリの一要素ですが、Agent Search（AI Search）と Agent Memory は異なる問題を解きます。AI Search は非構造化・構造化ファイル全体から結果を見つけるためのプリミティブであり、Agent Memory はコンテキストの想起のためのものです。Agent Memory のデータはファイルとして存在するわけではなく、セッションから導出されたものです。エージェントは両方を使うことができ、両者は一緒に動くよう設計されています。

あなたのメモリはあなたのもの

エージェントがより有能になり業務プロセスに深く組み込まれるにつれて、彼らが蓄積するメモリは単なる運用状態に留まらず、構築に実際の努力を要した組織的知識として真に価値あるものになります。お客様からは、その資産を単一ベンダーに紐付けることの意味について懸念が高まっているという声を聞いており、それは妥当です。エージェントが多くを学ぶほど、もしそのメモリが移行できないとスイッチングコストは高くなります。

Agent Memory はマネージドサービスですが、データはあなたのものです。すべてのメモリはエクスポート可能であり、Cloudflare 上でエージェントが蓄積した知識がニーズの変化に応じてあなたとともに移動できるようにすることにコミットしています。長期的な信頼を得る正しい方法は、離れること（乗り換えること）を簡単にし、かつあなたが離れたくなくなるだけ良いものを作り続けることだと考えています。

Agent Memory の仕組み

上で示した API の背後で何が起きているかを理解するには、エージェントがコンテキストをどのように管理するかを分解するのが助けになります。エージェントは三つの要素を持ちます：

ハーネス（harness） — モデルへの繰り返し呼び出しを駆動し、ツール呼び出しを仲介し、状態を管理するもの。
モデル — コンテキストを取り、補完（completions）を返すもの。
状態 — 現在のコンテキストウィンドウと、コンテキスト外の追加情報（会話履歴、ファイル、データベース、メモリ）を含むもの。

エージェントのコンテキストライフサイクルにおける重要な瞬間はコンパクションです。ハーネスがモデルの制限内に留めるため、あるいはコンテキストの劣化を避けるためにコンテキストを短縮することを決める瞬間です。今日、多くのエージェントは情報を恒久的に破棄します。Agent Memory はコンパクション時に知識を保存し、失わないようにします。

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

コンパクション時のバルク取り込み（Bulk ingestion）
- ハーネスがコンテキストを圧縮すると、会話を取り込みのために Agent Memory に送ります。取り込みはメッセージ履歴から事実、イベント、指示、タスクを抽出し、既存のメモリと重複を排除して将来の検索のためにメモリとして保存します。
モデルによる直接ツール利用（Direct tool use）
- モデルはメモリと直接やり取りするツールを与えられます。これには想起（recall：メモリから特定情報を検索する能力）も含まれます。モデルはまた remember（何か重要なものを明示的に保存する）、forget（もはや重要でない、または真ではないメモリをマークする）、list（保存されているメモリを一覧する）を行えます。これらは軽量な操作であり、モデルがクエリ設計やストレージ管理を行う必要はありません。主要なエージェントはストレージ戦略にコンテキストを浪費してはなりません。モデルに見せるツール面は意図的に限定されており、メモリは実際のタスクの邪魔にならないようにしています。

取り込み（ingestion）パイプライン

会話が取り込みのために到着すると、それは抽出、検証、分類、保存を行う多段階パイプラインを通過します。最初のステップは決定論的な ID 生成です。各メッセージにはコンテンツ指向の ID（SHA-256 ハッシュ：session ID、role、content のハッシュを取り 128 ビットに切り詰めたもの）が付与されます。同じ会話が二度取り込まれても、各メッセージは同じ ID に解決され、再取り込みが冪等になります。

次に、抽出器（extractor）が並列で二つのパスを実行します。フルパスはメッセージを概ね 10K 文字ごとにチャンクし、2 メッセージのオーバーラップを入れ、最大 4 チャンクを同時に処理します。各チャンクはロールラベル、相対日付を絶対日付に解決（"yesterday" は "2026-04-14" になる等）、ソースの出典性を示す行インデックスを含む構造化された書き起こしを得ます。長い会話（9 メッセージ以上）については、フルパスと並行して詳細パスが実行され、重複するウィンドウで名前、価格、バージョン番号、エンティティ属性など、広範な抽出では取りこぼしがちな具体的な値の抽出に特化します。二つの結果セットはその後マージされます。

次のステップは、抽出された各メモリをソースの書き起こしに対して検証することです。検証器はエンティティ識別、オブジェクト識別、場所の文脈、時間的正確さ、組織的文脈、完全性、関係性文脈、推論された事実が会話で実際に支持されているかどうか、の八つのチェックを実行します。各項目は合格、修正、または破棄されます。

パイプラインは次に各検証済みメモリを四つのタイプのいずれかに分類します。

Facts（事実）: 現在真である原子的で安定した知識（例："プロジェクトは GraphQL を使っている"、"ユーザーはダークモードを好む"）。
Events（イベント）: 特定の時点で起きたこと（デプロイや意思決定など）。
Instructions（指示）: 何かを行う方法を記述するもの（手順、ワークフロー、ランブックなど）。
Tasks（タスク）: 現在取り組まれている事項を追跡するもの。

（以下に続く）

Summary