powered by TechFeed
表示モード
Google

Google CloudがRAG不要のメモリエージェントをOSS公開 — LLMがSQLiteに直接書き込み、デフォルト30分ごとに自律でメモリを整理する

7月18日、Michal Sutterが「Google Cloud's Always-On Memory Agent Replaces RAG and Embeddings With Continuous LLM Consolidation on Gemini 3.1 Flash-Lite」と題した記事を公開した。Google CloudがRAGとベクターDBを使わずにLLMによる継続的なメモリ統合を行うオープンソースの常時稼働メモリエージェントを公開したという内容だ。RAGパイプラインを本番運用した経験があれば、その複雑さは身に染みているはずだ。Embeddingモデルの選定・更新、ベクターDBのインフラ管理、検索精度のチューニング——これらは機能実装とは別に積み重なる運用コストであり、「文脈を持つエージェント」を作ること自体よりも、その基盤維持に開発リソースが割かれがちだ。Google Cloudが今回公開したリファレンス実装は、そうした重みを丸ごと取り除く別アプローチとして注目に値する。

7月18日、Michal Sutterが「Google Cloud's Always-On Memory Agent Replaces RAG and Embeddings With Continuous LLM Consolidation on Gemini 3.1 Flash-Lite」と題した記事を公開した。Google CloudがRAGとベクターDBを使わずにLLMによる継続的なメモリ統合を行うオープンソースの常時稼働メモリエージェントを公開したという内容だ。

RAGパイプラインを本番運用した経験があれば、その複雑さは身に染みているはずだ。Embeddingモデルの選定・更新、ベクターDBのインフラ管理、検索精度のチューニング——これらは機能実装とは別に積み重なる運用コストであり、「文脈を持つエージェント」を作ること自体よりも、その基盤維持に開発リソースが割かれがちだ。Google Cloudが今回公開したリファレンス実装は、そうした重みを丸ごと取り除く別アプローチとして注目に値する。


RAGもベクターDBも不要、SQLiteにLLMが直接書き込む

AIエージェントはリクエストを処理したら文脈を捨てる。これが現状のほとんどのエージェントの動作だ。Google Cloudはこの問題に正面から取り組むリファレンス実装を、generative-aiリポジトリに公開した。名称はAlways-On Memory Agentである。

このエージェントの最も大きな特徴は、ベクターデータベースもEmbeddingも一切使わない点だ。RAGの代名詞とも言えるベクター検索を捨て、LLMが直接メモリを読み・考え・SQLiteに書き込む構成になっている。モデルにはGemini 3.1 Flash-Lite(2026年時点の最新軽量モデル)を採用しており、常時稼働するバックグラウンドプロセスとして低レイテンシ・低コストで動作するよう設計されている。フレームワークはGoogleのADK(Agent Development Kit)を使用する。

アーキテクチャ:3つのサブエージェントが役割分担

オーケストレーターが全リクエストを3つのサブエージェントに振り分ける構成だ。

IngestAgentは入力されたコンテンツを処理する。Geminiのマルチモーダル機能を使ってサマリー・エンティティ・トピック・重要度スコアを抽出し、memoriesテーブルに構造化レコードとして保存する。

ConsolidateAgentがこのエージェントの核心だ。デフォルトで30分ごとにタイマー起動し、未統合のメモリ同士の関連を探り、新たな知見とそのつながりをデータベースに書き出す(この間隔はCLIオプションでカスタマイズ可能。後述)。プロンプトなしで、アイドル中に自律的に理解を深める仕組みだ。人間の睡眠中の記憶整理に例えられている。

QueryAgentは質問に答える際、全メモリと統合済みインサイトを参照し、使用したメモリIDをソースとして引用する。

既存アプローチとの比較

アプローチ 保存方式 能動的処理 主な限界
ベクターDB + RAG ベクターストアにEmbedding なし 受動的:一度埋め込んで後で検索するのみ
会話サマリー 圧縮テキスト なし 詳細が失われる、相互参照なし
ナレッジグラフ ノードとエッジ 手動管理が必要 構築・維持コストが高い
Always-On Memory Agent SQLiteの構造化行 継続的な統合 クエリ時に参照できるのは最新50件まで

RAGが「埋め込んで後で検索する」受動的な仕組みであるのに対し、このエージェントはメモリを能動的に処理し続ける点が異なる。ただし現状の制約として、クエリ時に参照できるメモリは最新50件までという上限がある。

対応入力は27ファイル形式

./inboxフォルダにファイルをドロップするだけで自動取り込みされる。対応形式は以下の通りだ。

カテゴリ 拡張子
テキスト .txt, .md, .json, .csv, .log, .xml, .yaml, .yml
画像 .png, .jpg, .jpeg, .gif, .webp, .bmp, .svg
音声 .mp3, .wav, .ogg, .flac, .m4a, .aac
動画 .mp4, .webm, .mov, .avi, .mkv
ドキュメント .pdf

セットアップと使い方

3コマンドで起動する。

pip install -r requirements.txt
export GOOGLE_API_KEY="your-gemini-api-key"
python agent.py

起動後は./inboxの監視、30分ごとの統合処理、ポート8888でのHTTP APIサービスが始まる。HTTPで直接データを投入することも可能だ。

# テキストの取り込み
curl -X POST http://localhost:8888/ingest \
  -H "Content-Type: application/json" \
  -d '{"text": "AI agents are the future", "source": "article"}'

# 質問
curl "http://localhost:8888/query?q=what+do+you+know"

APIには/status/memories/consolidate/delete/clearのエンドポイントも用意されている。オプションでStreamlitのダッシュボードも利用でき、CLIフラグで監視フォルダ・ポート・統合間隔をカスタマイズできる。

python agent.py --watch ./docs --port 9000 --consolidate-every 15

RAGパイプラインの設計・運用コストを考えると、「LLMがSQLiteに直接書く」というシンプルな代替手段として実験してみる価値はある。一方で、50件というメモリ参照上限がどの程度の実用上の制約になるかは、ユースケースによって異なるだろう。コードはGitHubで全て公開されている

詳細はGoogle Cloud's Always-On Memory Agent Replaces RAG and Embeddings With Continuous LLM Consolidation on Gemini 3.1 Flash-Liteを参照していただきたい。