ガイド

AI エージェントにはどのデータベースを使うべきか

短い答え：状態は Postgres、検索は pgvector かベクトルストア、キャッシュは Redis、テレメトリは分析用データベース。たいていのエージェント構成に必要なのはこのうち二つで、四つではありません。エンジン選びは、語られている量ほど結果を左右しません。

このページはまずその問いに答えます。そのうえで、エンジン選びが取りこぼす領域を扱います。エージェントが生み出す業務上の事実です。人も後続のエージェントもそれを読み、信頼し、必要なら取り消せなければなりません。

最終確認：2026 年 11 月 13 日

エージェントが実際に保存しているもの

「AI エージェント用のデータベース」は、同時にやってくる五つの負荷をひとまとめにした言葉です。分けて考えれば選択は明らかです。

まず Postgres から。本気で

大半のエージェントプロジェクトでは、Postgres 単体が正しい第一歩で、初日から二つ目のシステムを足すのは早すぎます。状態、リレーション、JSON、全文検索、そして pgvector による埋め込みまで、ほとんどのエージェント製品が到達しない規模まで扱えます。

専用ベクトル DB に早く手を出さない。pgvector は HNSW と IVFFlat のインデックスに対応しています。別のベクトルサービスで得られる検索性能はまだ測れないことが多く、その代わりに整合性の境界と運用対象が一つずつ増えます。

プロンプトと応答のログを状態と同じ Postgres に入れない。全文の記録は追記が多く際限なく増えます。トランザクションテーブルの隣に置けば、数か月後には VACUUM とパーティショニングに追われます。テレメトリは早めに別の場所へ。

専用ベクトルストアや Redis が見合うとき

• ベクトルストア：数千万件規模で、実際に計測しているレイテンシ目標がある場合。メタデータでの絞り込みを近傍探索と組み合わせて多用する場合（pgvector は近似インデックスの走査後にフィルターを適用し、0.8.0 で補うための反復インデックススキャンを追加）。頻繁な全件再埋め込みを主データベースの負荷から切り離したい場合。
• Redis：セッションのコンテキスト、ツール呼び出しのレート制限、重複排除ウィンドウ、キューの状態。Postgres でもできるがレイテンシが足りない、リクエスト単位の処理です。Redis はシステムオブレコードではありません。そう扱うと、退避ポリシーで一日分の作業を失います。

その手前では、二つ目のシステムを運用するコストが差を上回ります。移行の前に計測を。

問いの下にある問い

上の選択肢はどれもバイトをどこに置くかに答えています。何が変わり、誰が変え、元に戻せるかには、どれも答えていません。エージェントの仕事では、プロジェクトを信頼できるかを決めるのは後者です。

エージェントが 200 件の顧客レコードを補完し、Postgres に正しく、完璧な権限で書き込んだとします。そのうち何件かは誤りです。形式は正しく、ただ自信満々に間違っている。制約はすべて通り、古い値は消えています。どの行をエージェントが触ったのか、以前は何だったのか、どのエージェントだったのか、後から読む人に教えてくれるものはスタックのどこにもありません。

これはエンジンの問題ではないので、エンジンを替えても直りません。制約は形を、行レベルセキュリティは権限を検証しますが、どちらも変更前後の値を残しません。

エンジンが取りこぼす層：すべての変更がチェンジリクエスト

Busabase はその層を最初から備えています。内部では Postgres で動きますが、エージェントは行をやみくもに書き込むわけではありません。レコード、ドキュメント、スキルファイル、スキーマ変更など、すべての編集がチェンジリクエストです。不変のコミット、メッセージ、フィールド単位の差分を持つブランチで、マージはレコードを先に進めるだけで何も上書きしません。

素のデータベースで同じことをするには、監査テーブル、トリガー、昇格ステップ付きのステージングテーブル、レビュー画面を自分で作り、保守し続ける必要があります。

• すべての書き込みにメッセージと差分。変更ごとに何をしたかが書かれ、フィールド単位で前後を表示します。
• どのエージェントがやったか分かる。作成者と、経由したキーやツールがコミットに残ります。
• 取り消しが標準。レコード、ドキュメント、スキルは履歴をすべて保持。マージで上書きされることはなく、どの変更もロールバックできます。
• レビューするかは選べる。書き込み権限があれば即座にマージ。エージェントに「提案のみ」のキーを渡すか、autoMerge: false で送れば、変更は受信箱で人の承認か差し戻しを待ちます。チェンジリクエストのドキュメント。

Postgres の上に自作するか、Busabase を使うか

各行は、エージェントが書く業務データについてチームがカバーすべき仕事です。最後の行は Postgres の本領で、そこでの正解は Postgres です。

Busabase がエージェントとチームにもたらすもの

今後の予定

いずれも現在開発中で、まだ利用できません。提供開始まで、このページでもそう表記します。

組み合わせて使う

どちらか一方ではありません。アプリの状態は Postgres、検索は pgvector、キャッシュは Redis、テレメトリは分析用ストアへ。エージェントがチームのために生み出す事実、つまり調査、顧客レコード、コンテンツ、業務ドキュメントは Busabase に置けば、人が読めて、すべての変更を追跡できます。マネージド Postgres と比べているならBusabase と Supabase の比較もどうぞ。

開示：Busabase 自体も Postgres で動いています。ローカルでは PGlite、Cloud では標準の Postgres です。エンジンの問いに中立ではありませんが、選択は退屈なほど堅実です。

よくある質問

次の一歩

エンジンの問いは片付き、「エージェントが何を変えたのか」で行き詰まっているなら、エージェントを Busabase に接続し、最初に残るチェンジリクエストを読んでみてください。

関連ページ： AI エージェントのシステムオブレコード · Busabase の比較 · Busabase と Supabase · チェンジリクエスト · エージェントワークスペースとは

出典： pgvector README