Agentic AI アプリケーションには、どのデータベースを使うべきか

「Agentic AI アプリケーションには、どのデータベースを使うべきか」と聞くと、多くの答えは製品名を一つ返してきます。その答えの形自体が間違っています。Agentic アプリケーションが抱えるデータは一種類ではないからです。五種類あり、同じ日にやって来て、それぞれ置き場所が違います。「製品」ではなく「種類」で選べば、決断の大半は自動的についてきます。

結論を先に。 アプリケーション自身の状態は Postgres へ。熱いセッション文脈は Redis へ——ただし、あなたが思うより後で。意味的な想起は、同じ Postgres の中の pgvector から始め、理由を測定できるようになって初めて専用ベクトルストアへ卒業します。ログとトークンの記録は分析用ストアへ、初日から分けて。そして、エージェントが生んだ業務上の事実——ほぼすべての選型ガイドが列挙し忘れる種類——は記録層に置くべきです。どの事実を誰が書き、人が受け入れたことがあるのかを示せる場所に。

具体的なアプリケーションで考える

抽象論は安上がりなので、具体例でいきます。サポートチケットを処理するエージェント。新着チケットを読み、分類し、過去の解決事例を検索し、人が承認するための返信を起草し、決まった内容を顧客レコードに反映する。平凡で、構築可能で、それでいて五種類すべてのデータを生むのに十分です。

アプリケーションの状態——ユーザー、チケット、顧客、権限。小さく、トランザクション的で、正確でなければならない。
セッションと熱い文脈——エージェントが処理の途中に持つもの。現在の会話、ツールの結果、レート制限のカウンタ。消えやすく、入れ替わりが激しく、遅延に敏感。
意味的な想起——解決済みチケット数万件とヘルプセンターを埋め込み化し、「これに似たもの」を見つけられるようにする。
テレメトリ——すべてのプロンプト、応答、ツール呼び出し、トークン数を、デバッグとコスト計算のために保持。追記のみ、際限なく増える。
生まれた事実——各チケットの分類、起草された解決策、更新された顧客レコード。他の人と後のエージェントの実行が、これらを真実として読みます。

最初の四種類には枯れた答えがあります。五番目が、Agentic アプリケーションが静かに壊れる場所です——この一文を覚えておいてください。

それぞれの置き場所

種類	置き場所	理由
アプリケーションの状態	Postgres	トランザクション、制約、結合。これは解決済みの問題であり、ここで革新しないこと。
セッションと熱い文脈	まず Postgres、遅延が証明されてから Redis	ほとんどのエージェントアプリは、セッション読み取りがボトルネックになるほど速くありません。Redis はリクエストごとのカウンタと重複排除の窓のためであり、初期装備ではありません。
意味的な想起	同じ Postgres の中の pgvector	運用するシステムは一つ、埋め込みはそれが表す行の隣。専用ベクトルストアの出番は、数千万ベクトルか測定済みの遅延目標の後——それより前ではありません。
テレメトリ	分析用ストア（ClickHouse、DuckDB 系）、または別の Postgres	追記が重く、上限がない。状態テーブルの隣に置けば、数か月でバキュームとパーティションの苦役になります。早期の分離は安く、後の改造は高い。
生まれた事実	記録層	人と後の実行に真実として読まれます。必要なのは出所（どのエージェントが、何をもとに）とレビュー状態（提案済みか、受入済みか）であり、汎用エンジンはこの二つをモデル化しません。

エンジンの閾値やベンチマーク、「Postgres 優先」の議論の全体は、参照ページ「AI エージェントはどのデータベースを使うべきか」にあります。本記事が扱うのはチューニングではなく決断です。

決断の順序

この順に問うてください。答えるたびに次が狭まります。

アプリケーション自身は何を保存するのか。 ユーザー、注文、チケット、コンテンツ。それは Postgres です。議論の余地はありません——マネージドかセルフホストかは予算の問題であって、アーキテクチャの問題ではありません。
エージェントは何を想起する必要があるのか。 文書と過去の事例を、類似性で。まず pgvector。ベクトルの数と実測した遅延を書き留めてください。そのメモが、将来専用ストアへ進む発火条件になります。それまでは不要です。
熱くて、捨てられるものは何か。 進行中のセッション、カウンタ、ロック。失っても痛くないものは Redis に置けます——あるいは、遅いと証明できるまで Postgres で構いません。
ログはどこへ行くのか。 別の場所へ。初日に決めてください。その時点では設定一行で済みます。
エージェントが書き、他人が真実として扱うものは何か。 この問いが、あなたのスタックに記録層が要るかどうかを決めます。そして多くのチームは、最初の事故の後に初めてこれを問います。

チームがよくやる三つの間違い

ベクトルデータベースから始める。 デモは見事です——何でも埋め込み、何でも聞ける。しかし半年後、チームには想起システムがあるのに、想起するに足る信頼できるものがありません。事実はチケットと文書とチャットに散らばったまま。想起は三番目の種類であり、最初の問題であることは稀です。

チャットの記録を記憶として扱う。 エージェントの履歴は会話ログに溜まり、次の実行は生の記録を読み返して、あのとき何が決まったのかを組み立てようとします。記録の写しはテレメトリ（四番目の種類）です。意思決定はレコードの中に、次の実行と次の人が実際に使える形で置くべきです。

エージェントに本番データベースへ直接書かせる。 書き込みは整っていて、権限もあり、そのうちの一部が間違っています——もっともらしく、自信たっぷりに。データベースは、どの行を人が見たことがあるか教えてくれません。顧客がその一行をもとに行動したとき、「エージェントが書いた」と「私たちが責任を持つ」が、自分のシステムの中で一度も同じ文ではなかったことに気づきます。これこそ、五番目の種類が防ぐために存在する失敗です。

記録層の位置づけ

五番目の種類に必要なのは、より大きなデータベースでも、より賢いデータベースでもありません。別の仕事です。業務上の事実を型付きレコードに保ち、それを説明するドキュメントと、エージェントが従うルールを同じワークスペースに置き、重みのある書き込みは提案として——人が受け入れも却下もできる、diff を伴う変更リクエストとして——届け、軽いものは直接着地させる。Busabase が占めるのはその層です。自らも Postgres の上で動き（ローカルでは PGlite、クラウドでは標準 Postgres）、エージェントは MCP、Agent Skill、API、CLI のいずれでも接続できます。最初の四種類の代わりではありません。その四つが担うようには設計されなかった、ただ一種類のデータの家です。

まとめると——状態は Postgres。ベクトルは測定が語るまで pgvector。Redis は遅延が恐れではなく証明になったとき。テレメトリは最初から独立したストアへ。そして、エージェントが生んだ事実は記録層へ。あなたのビジネスが最終的に評価されるのは、その種類によってだからです。

よくある質問

Agentic アプリケーションを作るのに、ベクトルデータベースは必須ですか。 必要なのは想起のためのベクトル検索であり、独立したベクトルデータベースは最初はまず不要です。既存の Postgres の中の pgvector で、ローンチをはるかに超える段階まで大半のアプリケーションをまかなえます。卒業は、ローンチ記事ではなく、測定した規模や遅延が語ったときに。

Postgres 一つですべてを賄えますか。 一、二、三番目の種類は、長い間快適に。四番目はいずれ痛みになります。五番目は容量の問題ですらありません——欠けているのは概念（出所とレビュー状態）であり、チューニングで概念は増えません。

二人目のエージェントが加わると何が変わりますか。 共有される種類すべてに、書き手がもう一人増えます。状態と想起はそれに耐えます。咬んでくるのは生まれた事実です。二人のエージェントが同じ顧客レコードを書き、相手が何を提案したか、人が何をすでに受け入れたかを互いに見られない。マルチエージェントシステムはエンジンで倒れるのではありません。レビューされず、出所のない事実で倒れるのです——だからこそ、決断の順序の五番目の問いは、エージェントを一人増やすごとに重要になります。