ベクトルDB不要？Google発「記憶するAI」の実装論と2026年の現場

皆さん、こんにちは！エンジニア向けに日々の技術ニュースを記事にするTetraです。

2026年3月7日の朝、皆さんいかがお過ごしでしょうか。春の足音が聞こえつつも、まだ少し肌寒いこの季節、技術界隈では非常にホットな話題が飛び込んできました。今日は、Google周辺から出てきた「AIエージェントの記憶」に関する非常に興味深いオープンソースプロジェクトについてお話しします。

これまで私たちが構築してきたRAG（検索拡張生成）システムやAIエージェントのアーキテクチャと言えば、「ベクトルデータベース」が必須の構成要素だと思われてきましたよね？「Embeddingして、Vector DBに入れて、Cosine類似度で検索して…」というあの一連の流れです。しかし、今日ご紹介するニュースは、そんな常識に「待った」をかけるかもしれません。

GoogleのシニアAIプロダクトマネージャーが公開した、ベクトルデータベースを使わない「Always On Memory Agent」。この設計思想が、これからの開発現場にどのような影響を与えるのか、現役エンジニアの視点で深掘りしていきたいと思います。

【速報】Google PMが公開した「Always On Memory Agent」とは？
【考察】なぜ「脱・ベクトルDB」が重要なのか？
1. 1. 複雑性という「技術的負債」の削減
2. 2. コスト構造の変化と「Flash-Lite」の役割
【技術的課題】企業の現場で直面する「ガバナンス」の壁
1. 「勝手に覚える」ことのリスク
【未来】2026年以降、エンジニアに求められるスキル
1. 1. 「検索エンジニア」から「記憶アーキテクト」へ
2. 2. エージェントの「飼育」と「監査」
【提言】日本のエンジニアはどう動くべきか
まとめ

【速報】Google PMが公開した「Always On Memory Agent」とは？

まずは、今回話題になっているニュースの事実関係を整理しましょう。

GoogleのシニアAIプロダクトマネージャーであるShubham Saboo氏が、AIエージェント開発における最大の難所の一つである「永続的メモリ（Persistent Memory）」の問題に取り組むためのオープンソースプロジェクトを公開しました。

「Always On Memory Agent」と名付けられたこのプロジェクトは、Google Cloud Platformの公式GitHubページでMITライセンスのもと公開されており、商用利用も可能です。

このエージェントの最大の特徴は、アーキテクチャの選択にあります。リポジトリの主張によれば、「ベクトルデータベースなし。Embeddingなし。あるのは、構造化されたメモリを読み、考え、書き込むLLMだけ」という非常にシンプルな構成を採用しています。具体的には、SQLiteを使用して構造化された記憶を保存し、エージェントが継続的にファイルを読み込み、バックグラウンドで情報の統合（Consolidation）を行います。デフォルトでは30分ごとに記憶の整理が行われる設定になっているようです。

このシステムを支えているのが、以下の2つの技術要素です。

Google Agent Development Kit (ADK): 2025年の春に導入されたフレームワーク。
Gemini 3.1 Flash-Lite: つい先日、2026年3月3日にGoogleが発表したばかりのGemini 3シリーズの中で最も低コストかつ高速なモデル。

Gemini 3.1 Flash-Liteは、Googleのベンチマークによると、従来のGemini 2.5 Flashと比較して「最初のトークンまでの時間（TTFT）」が2.5倍速く、出力速度も45%向上しているとのこと。価格も入力トークン100万あたり0.25ドルと非常に安価に設定されており、これが「常に起動し続ける（Always On）」エージェントの経済的な実現可能性を支えています。

【考察】なぜ「脱・ベクトルDB」が重要なのか？

ここからは、私Tetraのエンジニア視点での考察です。

正直なところ、このニュースを見た瞬間に「やっと来たか」と膝を打ちました。皆さんも開発現場で感じていませんか？「ちょっとしたチャットボットにベクトルDBを立てるのはオーバーエンジニアリングではないか？」というあのモヤモヤ感です。

1. 複雑性という「技術的負債」の削減

従来のRAG構成におけるベクトル検索スタックは、確かに強力ですが、運用コストと複雑さがネックでした。Embeddingのパイプラインを作り、インデックスを管理し、データの同期を取る…。これらは、小～中規模のエージェントシステムにとっては重すぎる装備です。

今回Saboo氏が示したアプローチは、LLM自体の能力向上（特に長いコンテキストの理解と構造化データの出力）を前提に、「LLMに記憶の整理係をやらせて、SQLiteという枯れた技術で保存する」というものです。これは、インフラ構成を劇的にシンプルにします。日本の開発現場、特にSIerや受託開発の現場では、運用保守の容易さが何より重視されます。「SQLでクエリが叩ける」という安心感は、多くのエンジニアにとって救いになるはずです。

2. コスト構造の変化と「Flash-Lite」の役割

ここで重要なのが、2026年3月3日に発表されたばかりのGemini 3.1 Flash-Liteの存在です。

「Always On（常時稼働）」で、しかも30分おきに記憶を整理（再読込・要約・統合）するエージェントなんて、一昔前のモデル単価なら破産案件でした。しかし、Flash-Liteのような「極めて安価で高速なモデル」が登場したことで、計算資源を贅沢に使って複雑なインデックス管理を省略するというトレードオフが成立するようになりました。

これは、「検索精度を上げるためにエンジニアがチューニングする」時代から、「AIに何度も整理させて精度を維持する」時代へのシフトを意味しているのかもしれません。

【技術的課題】企業の現場で直面する「ガバナンス」の壁

しかし、手放しで喜べるわけではありません。ニュース記事でも触れられていた「企業のコンプライアンス担当者が青ざめるポイント」について、もう少し深掘りしてみましょう。

「勝手に覚える」ことのリスク

エージェントがバックグラウンドで勝手に情報を統合し、記憶を形成するということは、「何が記憶され、何が統合されたか」がブラックボックス化しやすいということを意味します。

例えば、機密情報Aと機密情報Bを別々のタイミングで入力したとします。エージェントが勝手にそれらを結びつけ、本来アクセス権限のないユーザーに対して「AとBから導き出される推論C」を回答してしまったら？

Franck Abe氏が指摘しているように、決定論的な境界線を持たずに記憶を交配させることは「コンプライアンスの悪夢」になり得ます。また、ELED氏が指摘する「記憶のドリフト（意図しない変容）」やループの問題も、運用フェーズでは深刻なバグとして現れるでしょう。

日本の企業、特に金融や製造業の現場では、「AIが何を学習（記憶）しているか監査ログを出せ」と言われるのが常です。ベクトルDBなら「このベクトルを削除すればいい」と比較的明確でしたが、LLMによって要約・統合された「構造化メモリ」の中に紛れ込んだ機密情報を特定・削除するのは、より高度な設計が求められます。

【未来】2026年以降、エンジニアに求められるスキル

この「Always On Memory Agent」の登場は、AI開発のトレンドが「単発のタスク実行」から「継続的な自律動作」へ移行していることを象徴しています。これからのエンジニアには、以下のような視点が必要になるでしょう。

1. 「検索エンジニア」から「記憶アーキテクト」へ

これまでは検索アルゴリズムやベクトルインデックスの知識が重宝されましたが、これからは「AIにどう記憶を整理させるか」というプロンプトエンジニアリングとデータモデリングの融合領域が重要になります。人間の脳のように、短期記憶を長期記憶にどう定着させるか、不要な記憶をどう忘却させるか（Garbage CollectionならぬMemory Collection）を設計するスキルです。

2. エージェントの「飼育」と「監査」

コードを書くだけでなく、稼働し続けるエージェントが「変な癖」をつけていないか監視する役割が必要です。これはDevOpsならぬAgentOpsの領域ですが、特に「記憶の健全性」を保つためのツールやワークフローの整備が急務になるでしょう。

【提言】日本のエンジニアはどう動くべきか

今回のGoogleの動きを受けて、私たち日本のエンジニアはどう動くべきでしょうか。

まず、「ベクトルDB至上主義からの脱却」を検討してみてください。現在開発中のプロトタイプや社内ツールにおいて、本当にベクトル検索が必要ですか？今回のGemini 3.1 Flash-Liteのような高速モデルとSQLiteの組み合わせで、よりシンプルに、より安価に実装できる可能性はないでしょうか。技術選定の引き出しを一つ増やすチャンスです。

次に、「ガバナンスの実装」に目を向けてください。Saboo氏のデモは素晴らしいですが、エンタープライズ機能（権限管理、監査ログ、決定論的なポリシー）はまだ不足しています。逆に言えば、ここが我々エンジニアの腕の見せ所です。「便利だけど危ない」技術を、「安全で使える」システムに昇華させるのが、プロフェッショナルの仕事です。

例えば、記憶の統合プロセスに人間が介在する承認フローを組み込んだり、記憶テーブルに対して従来のSQLベースの厳格なアクセス制御を適用したりといった「ハイブリッドなアプローチ」が、日本の現場では現実的な解になるでしょう。