AI エージェントにはどのデータベースを使うべきか
短い答え：状態は Postgres、意味検索はベクトルストア、キャッシュは Redis、テレメトリは分析用データベース。多くのエージェント構成はこのうち二つを必要とし、一つではありません。そしてこの選択は、それについて書かれた分量が示唆するほど重大ではありません。
このページはまずその問いにきちんと答えます。その下にもう一つ、ほとんど誰も問わない問いがあり、エンジンの選択よりも重要です。それは最後に置きます。まずは、あなたが探しに来たものから。
エージェントは実際に何を保存しているのか
「AI エージェント用のデータベース」という言い方は、たまたま同時に現れる四つの無関係なワークロードを一つに潰しています。分ければ選択は自明になります。
| 保存するもの | アクセスパターン | 妥当な既定値 |
|---|---|---|
| アプリケーションとセッションの状態 | 小さな読み書き、トランザクション、正確性が必須 | Postgres |
| ドキュメントの意味検索 | 埋め込みに対する近似最近傍 | pgvector、規模が出てから専用ストア |
| ホットな文脈とレート制限 | サブミリ秒、一時的、高頻度 | Redis |
| プロンプト／応答ログとトークン計上 | 大量の追記、集計読み取り | ClickHouse、DuckDB/MotherDuck、あるいは限界まで Postgres |
| エージェントが生んだ業務上の事実 | 人と後続の実行が真実として読む | 最終節を参照 |
Postgres から始める。本気で
大半のエージェント案件では Postgres 単体が正しい最初の答えで、初日に二つめのシステムを足すのは早すぎます。状態、リレーション、JSON、全文検索、そして pgvector による埋め込みまで、多くのエージェント製品が到達する規模を大きく超えて対応できます。
ここでよくある誤りが二つあります。
専用ベクトルデータベースに早く手を出しすぎる。pgvector と HNSW は数百万ベクトルまで問題ありません。別のベクトルサービスを足して買えるのは、まだ測定できていない検索性能であり、代償は整合性ドメインが一つ増え、運用対象が一つ増えることです。成熟したマネージド Postgres は当然のようにベクトル対応を備えており、2026 年の多くの構成では、ベクトルのためだけに別システムを足すのは不要な複雑さに見えます。
プロンプトと応答のログを、状態と同じ Postgres に書く。実際に噛みついてくるのはこちらです。トークン計上と完全なプロンプト／応答の保存は追記が重く、上限なく増えます。トランザクション用テーブルの隣に置けば、半年後に負荷の中で vacuum とパーティショニングをやる羽目になります。テレメトリには早めに自分の家を与えてください。分析用データベースは後付けが高く、最初に足すのは安いのです。
専用ベクトルストアが見合う条件
- 数千万ベクトル以上で、実際にレイテンシ目標を測っている。
- 重いメタデータフィルタと ANN 検索の併用で、pgvector のクエリプランが協力しなくなる。
- 頻繁な全件再埋め込みを、主データベースの負荷から隔離したい。
その閾値より下では、二つめのシステムの運用コストが検索性能の差を上回ります。移行の前に測ってください。
Redis が見合う場面
セッション文脈、ツール呼び出しのレート制限、重複排除ウィンドウ、キューの状態。リクエストごとに行う処理で、Postgres でも処理できるが望むレイテンシには届かない——そのとき Redis が効きます。記録システムではありません。それを記録システムとして扱うのが、エージェントチームが退避ポリシー一つで一日分の作業を失う典型的な経路です。
関係があるので開示します。Busabase 自身も Postgres で動いています。ローカルでは PGlite、Cloud では標準の Postgres です。エンジンの問いについて当社は中立ではありませんが、この点については退屈なことしか言いません。それがこの節の趣旨です。
問いの下にある問い
ここからが通常は欠けている部分です。
上記のどの選択肢もバイトをどこに置くかに答えています。なぜそのバイトを信じられるのかには、どれも答えていません。そしてエージェント業務の増えつつある部分では、後者こそがプロジェクトの成否を決めます。
エンジンが決まった後に何が起きるか考えてみてください。エージェントが顧客レコードを 200 件充実させ、完璧な権限で正しく Postgres に書き込みます。そのいくつかは誤りです。形式不正でも、制約に弾かれたのでもなく、単に偽なのです。自信に満ちた、もっともらしい偽です。
データベースは職務を果たしました。すべての検査を通り、行はそこにあります。そしてあなたのスタックのどこにも、その 200 行のうちどれを人間が見たのかを、後の読み手に伝えられるものがありません。
これはデータベースの問題ではないので、データベースを替えても解決しません。制約が検証するのは形であり、行レベルセキュリティが検証するのは権限です。どちらも値が真であるかは検証しません。そしてエージェントの最も高くつく失敗は、形式が完璧で権限も十分なまま誤っていることです。
自分のスタックにとっての含意
エージェントの書き込みが使い捨てなら——一時状態、キャッシュ、ログ、人がすぐ読む下書き——以上のことは重要ではありません。Postgres を選んで先へ進んでください。
書き込みが他のものに読まれる事実になるなら——次の実行、レポート、公開ページ、API 利用者——アーキテクチャのどこかに、書き込みが有効になる前に検査できる場所が必要です。Postgres の上に自作するレビューキューでも、昇格ステップつきのステージングテーブルでも、それを標準で行うシステムでも構いません。
唯一あってはならないのは、何もないまま、エンジンの制約が「誰も下さなかった判断」の代役を務めている状態です。
よくある質問
AI エージェントに Postgres で十分ですか
多くの案件では十分です。pgvector によるベクトル検索も含みます。二つめのシステムは、必要だと言う測定値が出てから足してください。
ベクトルデータベースは必要ですか
おおむね一千万ベクトル超、あるいは重いメタデータフィルタと ANN 検索の併用時だけです。それ未満なら pgvector が妥当です。
プロンプトと応答はどこに保存すべきですか
トランザクション用データベースには入れないでください。追記が重く上限なく増えるテレメトリには、早期に専用の置き場を。
Busabase はどのデータベースを使っていますか
Postgres です。ローカルは PGlite、Cloud は標準 Postgres。Busabase はアプリのデータベースの代替ではなく、エージェントが生んだレコードが「真かどうかを人が判断するまでの間」置かれる場所です。
一つのデータベースで全部できますか
Postgres が最も近く、出発点として正しい選択です。規模が出るとワークロードは分化し、通常はテレメトリが最初に独立を必要とします。
次のステップ
「どのエンジンか」が決まり、「なぜそれを信じられるのか」で行き詰まっているなら、それが次のページの主題です。