Memory Architecture · Google
RAG が終わる日は、
「思い出す」を LLM に返した日だった。
Google Cloud が Gemini 3.1 Flash-Lite 上で発表した「Always-On メモリエージェント」は、検索で外部から呼び出す設計を、モデル内部に統合する設計へ置き換える提案です。ベクトル DB とチャンク分割で組んだ既存構成の何が変わるのか——設計図で解きほぐします。
What Was Announced
「Always-On メモリエージェント」の正体
Google Cloud は 2026 年 7 月 19 日、Gemini 3.1 Flash-Lite 上で常時稼働するメモリエージェントを発表しました。これまで長期記憶＝クエリ時に外部ベクトル DB を叩く RAG が前提だった構成を、モデル内部にメモリを継続的に統合する形へ置き換える提案です。プロダクトの見た目は「毎回聞き返す前提を捨てた Gemini」に近く、実装レベルでは推論と記憶更新が同じパスに乗ります。
ここで押さえておきたいのは、これが「長い context window」の延長ではないという点です。context を伸ばすだけでは、プロンプトのたびに全記憶を再ロードするコストがついて回る。今回の発表はそこを避け、会話・履歴・ユーザーの好みが「重み側」に近い場所に居座り続ける設計に踏み出したものです。
By The Numbers
従来 RAG と何が違うか
Why It Matters Now
RAG の「積み残し」が一気に精算されつつある
RAG は便利でしたが、実運用の 8 割は「チャンク分割・埋め込み再計算・スコア閾値・古情報削除」の運用作業でした。
過去 3 年の LLM アプリ開発は、事実上 ベクトル DB 運用の技術でした。チャンクをどう切るか、埋め込みモデルをどこまで新しくするか、top-k と再ランキングの匙加減、そして古い記憶をどう剥がすか——毎案件で 3 人月級の工数が飛んでいく世界です。今回の発表は、その運用そのものをベンダー側に吸収させる方向の宣言に近いものになります。
もう一つ、業界文脈として大きいのは Anthropic・OpenAI もそれぞれ「会話をまたぐ記憶」機能を強化してきたことです。Google はここに クラウド基盤（Vertex）× 大量ユーザーのプロファイルを掛け合わせられる資源を持っているため、モデル内部に記憶を寄せる戦略の効果は各社と比べても大きく出ます。
Who Should Do What
誰に、どう効くか
「RAG が要らなくなる」と一括りにするのは早い——効き方は役割ごとに違います。
検索基盤を作り込んだチーム: 設計見直し
すでに Pinecone / pgvector / Chroma などで RAG を運用している場合、Always-On メモリとどこで境界を引くかの再設計が必要です。「静的な社内ドキュメントは RAG、ユーザー固有の履歴は Always-On」といった二重構成が現実解になります。
PM: 個人化 UX の粒度が上がる
「昨日話したこと」が翌日の会話にそのまま生きる体験は、これまでプロンプト側で頑張って再現していたものです。プロンプトエンジニアリングで隠していた記憶が UI 側に浮かぶため、記憶を消す UX（forget me）が改めて必須機能になります。
個人・小規模チーム: 今すぐの影響は薄い
外部ベクトル DB を立てていない層には、体感の差分はまだ小さいはず。ただし ChatGPT / Gemini / Claude いずれも「勝手に覚えてくる」方向にそろってくると、設定画面の記憶管理をどれだけ真面目に触るかが使いこなしの分かれ目になります。
What Comes Next
短期に起きること、取れる手
短期の見通しは 3 つ。(a) Anthropic と OpenAI が同種の「常時記憶」で追走する（今の Claude memory は明示的な `/memory-tool` オプトイン相当だが、これが常時化する）、(b) 静的知識ベースは引き続き RAG、ユーザーごとの流れは Always-On、というハイブリッド構成が実装ガイダンスの定石になる、(c) EU AI Act 対応で「記憶を消す権利」の UX 化が急に重い要件になる——の 3 点です。次にやることは、既存 RAG パイプラインの「ユーザー固有履歴」部分を切り出す設計レビューです。
記憶はもう外付けの附属品ではなく、
推論と同じ場所で動く基本部品になる。
Counterpoint
反対視点・限界・見落としがちな点
「RAG は死んだ」と読むのは早すぎます。第一に、企業内の権限つき文書——契約書、人事、機密設計——はモデル内部の重みには載せられません。ここは今後も RAG（＋ ACL 付き検索）が主戦場です。第二に、Always-On の透明性の低さ。モデルが「何を覚えていて、何を忘れたか」を外から観測しにくいのは、RAG の「明示的にヒットしたチャンクを見せる」体験からの後退でもあります。
もう一点、コスト構造の見えなさ。埋め込みと top-k は課金明細の中で数えやすい単位でしたが、Always-On のコストは推論単価に折り込まれ、可視化しづらくなる可能性があります。ベンダー側にも見積もりを求めるべきポイントで、契約前チェックリストに「メモリ更新の課金モデル」を追加しておくのが安全です。