Googleのプロダクトマネージャーが公開した、ベクトルデータベースを使用しない実験的なAIエージェントの実装が議論を呼んでいます。従来のRAG(検索拡張生成)の常識を覆す「LLMにすべてを読ませる」アプローチは、ロングコンテキスト時代の新たな選択肢となるのでしょうか。日本企業のAI開発現場におけるメリットとリスクを解説します。
「No Vector Database」という挑発的なアプローチ
生成AIを活用したシステム構築、特に社内ドキュメントや過去の履歴を参照して回答するRAG(Retrieval-Augmented Generation)において、ベクトルデータベース(Vector DB)の導入は「定石」とされてきました。テキストを細切れ(チャンク)にし、数値化(エンベディング)して保存し、類似性の高い情報を検索してLLMに渡すという手法です。
しかし、Googleのプロダクトマネージャーが個人プロジェクトとしてオープンソース化した「Always On Memory Agent」は、この定石に対し「No vector database. No embeddings.」という挑発的なコンセプトを掲げました。仕組みは極めてシンプルで、構造化されたテキストファイルに会話履歴や情報を蓄積し、必要に応じてLLM自身にその情報を「読ませ、考えさせ、更新させる」というものです。
これは、近年のLLM(Gemini 1.5 ProやGPT-4oなど)が扱える情報量(コンテキストウィンドウ)が飛躍的に増大したことによる、アーキテクチャの揺り戻し現象と言えます。数十万〜数百万トークンを一度に処理できるなら、複雑な検索システムを組むより、すべてをプロンプトに含めてLLMの推論能力に任せた方が文脈を正確に捉えられるのではないか、という問いかけです。
日本企業の開発現場におけるメリット:複雑性の排除
この「ベクトルDBレス」のアプローチは、日本のAI開発現場、特にエンジニアリソースが不足している組織にとって魅力的な側面があります。
第一に、日本語処理の複雑さからの解放です。従来のRAGでは、日本語の文章をどこで区切るか(チャンキング)、どの埋め込みモデルを使うかが精度を左右し、そのチューニングには高度なノウハウが必要でした。すべてのテキストをそのままLLMに渡す手法であれば、この前処理の手間が大幅に削減されます。
第二に、MLOps(機械学習基盤の運用)の簡素化です。ベクトルDBという新たなインフラを管理・保守する必要がなくなるため、システム構成がシンプルになり、障害時の切り分けも容易になります。これは、保守運用コストを重視する日本企業のIT部門にとって大きな利点です。
実務上の課題:コスト、レイテンシ、そしてガバナンス
一方で、このアプローチをそのまま企業システムに採用するには、いくつかの超えるべき壁があります。
最大の問題はコストとレイテンシ(応答速度)です。過去の履歴すべてを毎回LLMに入力すれば、入力トークン数は雪だるま式に増え、それに比例してAPI利用料が増大し、回答生成までの待ち時間も長くなります。従量課金モデルが一般的な現状では、コスト対効果のシビアな検証が必要です。
また、「幻覚(ハルシネーション)」と「情報の取捨選択」の問題も残ります。LLMに大量の情報を一度に与えると、重要な指示を見落とす(Lost in the Middle現象)リスクがあります。また、本来参照すべきでない古い情報や、アクセス権限のない情報までプロンプトに含まれてしまうリスクもあり、厳格なデータガバナンスが求められる金融や医療などの領域では慎重な設計が必要です。
日本企業のAI活用への示唆
今回のニュースは、AIアーキテクチャが過渡期にあることを示しています。日本企業の実務担当者は以下の点を意識して意思決定を行うべきです。
- PoC(概念実証)の加速手段として活用する:
初期段階のプロトタイプ開発において、ベクトルDBの構築はオーバーエンジニアリングになりがちです。まずはロングコンテキストLLMを活用して「データさえ渡せば価値が出るか」を素早く検証し、運用フェーズで必要に応じて検索システムを導入するという段階的なアプローチが有効です。 - ハイブリッド構成を見据える:
「すべてベクトル検索」か「すべてロングコンテキスト」かの二者択一ではありません。直近の重要な文脈はLLMのメモリ(コンテキスト)に保持し、古い記録はベクトルDBやキーワード検索で呼び出すといったハイブリッドな構成が、コストと精度のバランスにおける現実解となります。 - ベンダーロックインへの警戒:
ロングコンテキストに依存しすぎると、その膨大なトークン数を処理できる特定のLLM(例:Google GeminiやOpenAI GPT-4など)以外への乗り換えが困難になります。AIモデルの進化は早いため、特定のモデル仕様に過度に依存しないシステム設計を心がけることが、中長期的なリスクヘッジにつながります。
