PostgreSQL for agents in AlloyDBとは？エージェント専用の隔離DBの仕組み・読み取りプールとの違いと採用判断

PostgreSQL for agents in AlloyDBは、AIエージェントが本番データを読むための専用インスタンスを、本番クラスタと切り離して数秒で用意し、使い終わればゼロまで縮める仕組みです。Google Cloudが2026年9月にプレビューとして発表しました。マネージド版AlloyDBそのものの構成や料金はAlloyDBとは？PostgreSQL互換マネージドDBの構成・カラム型エンジン・料金と採用判断を実装者目線で解説にまとめてあります。この記事では、エージェント向けの隔離インスタンスに絞って、仕組み・既存の読み取りプールとの違い・プレビュー期間に先行できる設定・申し込む条件を、2026年10月時点の公開情報で整理しました。

まとめ｜エージェントの参照を本番から切り離す隔離DBで、現時点はプレビュー

• AIエージェントからの大量の参照を、プライマリ・スタンバイ・読み取りプールのどれとも部品を共有しない使い捨てのノード群で受ける機能です。各ノードはAlloyDBのエンジンをそのまま持ち、データベースの最新状態を読み取り専用で参照します。
• 提供段階はプレビューで、技術ドキュメントも申込み制です。公開ページにはコマンド・対応リージョン・単価の記載がなく、本番の正式運用に組み込める段階ではありません（2026年10月時点）。
• 課金はノードが動いている秒単位で、作業が終わればゼロまで縮退すると説明されています。常設の読み取りプールのように、待機中のノード代を払い続ける形とは逆の発想です。
• 1,000ノードで300万QPS、本番への影響は計測できる差なしという数字はGoogle自身の測定値です。自社の負荷で確かめるまでは見込みとして扱ってください。
• 申込みを急ぐべきなのは、多数のエージェントが瞬間的に本番データを読みに来る業務を既に抱えている場合です。参照負荷が平準なら、GA済みの読み取りプールで足ります。

PostgreSQL for agentsの正体｜本番と隔離した読み取り専用DB

一言でいえば「エージェント専用の、使い捨ての読み取りノード」です。本番クラスタを拡張するのではなく、その外側に独立したノードの集まりを都度立てる点が、従来のレプリカと根本的に違います。

発表と提供段階｜2026年9月発表のプレビューで申込み制という前提

発表はGoogle Cloud公式ブログの発表記事で、日付は2026年9月25日です。国内ではPublickeyが9月30日に報じています。公式ドキュメントの機能ページはPre-GA Offerings Termsの対象と明記しており、製品は現状有姿で提供され、サポートも限られる場合があるという扱いです。プレビュー本体と技術ドキュメントへのアクセスは、どちらもページ内のフォームから申し込む形になっています。

見落としやすいのは、このページ自体には操作手順がないことです。最終更新は2026-10-09 UTCですが、インスタンスの作り方、上限、リージョン、単価はどれも書かれていません。ネット上で「このコマンドで作れる」と書かれた記事を見かけたら、申込み後の資料に基づくものかどうかを確かめてください。

読み取り専用の隔離インスタンス｜フルエンジンで索引もSQLもそのまま

各ノードで動くのは機能を削った簡易版ではなく、AlloyDB for PostgreSQLのエンジン一式です。発表記事は、すべての索引とSQLの全機能に加えて、ベクトル検索・全文検索・空間検索が使えると説明しています。業務テーブルと埋め込みを同じデータベースに置いている構成なら、エージェントは1回の作業の中で集計とベクトル検索と主キー参照を混ぜて実行できます。ベクトル索引の基礎はpgvectorとは？インストール手順（Windows・Ubuntu・Docker）と使い方で扱いました。

もう1つの柱がレイクハウス連携です。BigQueryとSpark（Lightning Engine for Apache Spark）から、ETLを挟まずにAlloyDBのトランザクションデータへフェデレーテッドクエリを投げられるとしています。履歴はBigQuery、直近の状態はAlloyDBという分担をそのまま保てるわけです。セキュリティ面では、IAM認証・VPC Service Controls・顧客管理の暗号鍵（CMEK）・監査が挙げられています。

課金と縮退の仕組み｜ノード稼働の秒単位課金とゼロまでの自動停止

アーキテクチャ解説の公式ブログには「課金はエージェントノードの稼働秒単位」とあり、1,000ノードを数十秒だけ使うバーストなら、その分の資源にしか課金されないと書かれています。エージェントが作業を終えるとノードは自動で止まり、ゼロに戻ります。

ただし単価は公表されていません。費用を比べたいなら、現時点で数字として置けるのは読み取りプール側だけです。稟議の資料では「単価未公表・プレビュー」と書き分け、推定値を確定値のように並べないほうが後で揉めません。

隔離を実現する仕組み｜microVMのノードとColossus直読みの構成

アーキテクチャ解説は、エージェント時代のデータベースに求める条件を「分離・遅延・規模」の3つに置いています。分離とは、プライマリとデータベース部品を共有しない経路で、1秒未満の鮮度の本番データを読めること。遅延とは、キャッシュを外してリモートのストレージへ取りに行っても1ミリ秒未満で返ること。規模とは、数秒で立ち上がって数千台まで増え、短時間で終わってゼロに戻ることです。

データ経路の分離｜プライマリと部品を共有しないmicroVMノード群

本番のトランザクション処理は、事前に確保した専用の基盤で動き続けます。エージェント側はそれとは別に、microVMの上で動くAlloyDBノードの使い捨てプールとして立ち上がります。ストレージはGoogleの分散ファイルシステムであるColossusですが、本番とは別のセグメント群を使ってエージェントのI/Oを本番の経路から外す設計です。ノードはDRAMとローカルSSDをキャッシュに使います。

エージェントはMCPで接続すると説明されています。MCP自体の仕組みはMCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説を参照してください。

鮮度の出し方｜ログ転送の複製でなくストレージ共有で最新を読む方式

一般的なレプリカは、プライマリの更新ログを受け取って自分の手元へ再生することで追いつきます。この方式だと新しいレプリカを作るたびにデータの複製が要り、ブログは作成に数時間かかる例を挙げています。遅延が生まれる理由はデータベースレプリケーションとは？同期・非同期の違いとレプリカ遅延の設計で整理したとおりです。

エージェントノードは複製を持ちません。ブログの言葉では「データは共有し、それ以外は何も共有しない」。ColossusのストリームはI/Oごとに仲介役を通らず、データを持つディスクへ直接読みに行くため、暖めるキャッシュ層も外れる層もないと説明しています。鮮度は「1秒未満」「秒単位で最新」と表現されていますが、遅延の測り方は示されていません。参照結果の鮮度に業務上の約束がある場合は、申込み後の資料で数値を確かめる必要があります。

公表ベンチマークの読み方｜1,000ノードで300万QPSという数字の条件

ブログに載っている測定は次のとおりです。いずれもGoogle自身の測定で、ノードのサイズやデータ量の詳細は書かれていません。

比較対象は、オブジェクトストレージと共有ブロックサーバーを組み合わせた方式で、サービス名は伏せられています。リードレプリカを8台まで足しても伸びは2倍未満、4台でピークを迎え、その間にプライマリのスループットが75%以上落ちたという結果です。読み取りを増やすほど本番が遅くなる構造を避けた、というのが設計の主張でしょう。数字の大きさより、この「本番が落ちない」側の結果を自社の負荷で再現できるかが評価の焦点になります。

読み取りプールとの違い｜常設ノード20台の上限と使い捨てノードの比較

AlloyDBには、参照を逃がす手段として以前から読み取りプールがあります。どちらを使うかは、参照負荷の形で決まります。

4観点の比較表｜起動時間・上限・課金・本番への影響を並べた違い

読み取りプールの作成手順によると、ノード数は1インスタンスあたり1〜20で、クラスタ内の全読み取りプールを合計しても20ノードが上限です（ドキュメント最終更新 2026-10-09 UTC）。

読み取りプールの構成と見積りの手順はAlloyDBとはで、AWSのリードレプリカとの対比はリードレプリカとは？RDS・Auroraでの作成手順と読み書き分離の実装を実装者目線で解説で扱っています。

読み取りプールで足りる場面｜参照負荷が平準で予測できる業務の条件

社内の問い合わせ用エージェントが数体あり、参照の量が日中の業務量に沿って緩やかに動く。この程度なら読み取りプールで足ります。ノードを数台常設しておけば待ち時間はなく、手順も料金も公開済みです。20ノードの上限に当たる規模でもありません。

読み取りプールで苦しくなるのは、数百から数千のエージェントが同時に走り、数十秒だけ全件走査に近い参照をして消える、という形の負荷です。ピークに合わせて常設すれば大半の時間は空回りし、平均に合わせれば本番側まで巻き込みます。PostgreSQL for agentsが狙っているのは、この谷と山の差が極端な領域です。

プレビュー期間に先行できる準備｜権限・接続経路・MCP設定の具体手順

機能固有の操作は申込み後の資料待ちですが、エージェントにDBを読ませるための土台は、GA済みの機能で今から作れます。ここで作ったロール・サービスアカウント・MCP設定は、接続先を読み取りプールから隔離インスタンスへ差し替えても使い回せる部分です。

エージェント用DBロールの作成｜SELECTだけを許す設定と時間上限

エージェントには、公開してよいスキーマだけを読めるロールを渡します。PostgreSQLのGRANTでSELECTだけを与え、クライアント接続の既定値にある default_transaction_read_only と statement_timeout をロールに固定します。

-- エージェント専用の読み取りロール（スキーマ名・ロール名は環境に合わせて置き換える）
CREATE ROLE agent_reader LOGIN;
GRANT CONNECT ON DATABASE appdb TO agent_reader;
GRANT USAGE ON SCHEMA agent_view TO agent_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA agent_view TO agent_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA agent_view GRANT SELECT ON TABLES TO agent_reader;
ALTER ROLE agent_reader SET default_transaction_read_only = on;
ALTER ROLE agent_reader SET statement_timeout = '30s';

公開用のスキーマを別に切り、機微な列を外したビューだけを置くのが前提です。default_transaction_read_only はセッション側で上書きできるため、書き込み禁止の担保はあくまでGRANTの側で取ります。列単位のGRANTやsearch_pathの固定まで含めた設計はPostgreSQL MCPサーバーの構成と権限設計｜読み取り専用ロールとスキーマ公開範囲の決め方で詳しく扱いました。

サービスアカウントへの権限付与｜接続用ロールだけを絞って渡す手順

MCP接続のセキュリティのベストプラクティスは、エージェントごとに専用のサービスアカウントを作り、alloydb.admin のような広いロールは避けるよう求めています。接続とクエリに要るのは Cloud AlloyDB Client と Service Usage Consumer の2つです。

# SA_EMAIL にはエージェント専用サービスアカウントのメールアドレスを入れる
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:SA_EMAIL" \
  --role="roles/alloydb.client"

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:SA_EMAIL" \
  --role="roles/serviceusage.serviceUsageConsumer"

高リスクのデータを読むエージェントと、運用作業をするエージェントでサービスアカウントを分けることも同じページで推奨されています。1つのアカウントに権限を寄せると、事故の範囲を後から絞れません。

MCP Toolboxでの接続設定｜既存の読み取りプールへ向ける設定例

MCP Toolboxの接続手順では、v0.15.0以降のToolboxを –prebuilt alloydb-postgres で起動し、接続先を環境変数で渡します。今の段階では INSTANCE に読み取りプールを指定しておき、隔離インスタンスが使えるようになったら差し替える、という運び方が現実的です。

{
  "mcpServers": {
    "alloydb": {
      "command": "./toolbox",
      "args": ["--prebuilt", "alloydb-postgres", "--stdio"],
      "env": {
        "ALLOYDB_POSTGRES_PROJECT": "PROJECT_ID",
        "ALLOYDB_POSTGRES_REGION": "REGION",
        "ALLOYDB_POSTGRES_CLUSTER": "CLUSTER_ID",
        "ALLOYDB_POSTGRES_INSTANCE": "READ_POOL_INSTANCE_ID",
        "ALLOYDB_POSTGRES_DATABASE": "appdb",
        "ALLOYDB_POSTGRES_USER": "agent_reader",
        "ALLOYDB_POSTGRES_IP_TYPE": "private"
      }
    }
  }
}

IP_TYPE を指定しないとパブリックIPでの接続が既定になります。本番データを読ませるなら private を明示してください。なおAlloyDBのリモートMCPサーバーも用意されており、グローバルエンドポイントはGA、リージョンエンドポイントはプレビューです。読み取り専用ツールの execute_sql_read_only はPostgreSQL 17以降でしか使えません。

独自章｜エージェントへ本番データを開く前に決める4つの境界と監査

隔離インスタンスが解決するのは「本番が遅くなる」問題だけです。誰が何を読めるか、何が起きたかを追えるかは、機能の外側で決めておく必要があります。決める順に並べると次の4つになります。

1. 読ませるスキーマと列の範囲（ビューで切る）
2. エージェントに渡すツールの粒度（任意SQLか、用途別の固定クエリか）
3. 利用者の識別子を誰が設定するか（エージェントに任せない）
4. 監査ログの取得範囲と、アプリ側に残す記録の項目

1つ目は前章のロール設計で済んでいます。残りの3つを以下で詰めます。

汎用SQLツールを渡さない設計｜execute_sqlより用途別ツールを選ぶ理由

公式のベストプラクティスは、execute_sql のような汎用ツールをマルチテナント環境で渡すと、利用者をまたいだデータ漏えいを招きうると警告しています。代わりに勧めているのが、利用者IDをエージェントの外側で埋め込んだ用途別のツールで、例として lookup_active_order が挙げられています。エージェントが新しいツールを登録したり、既存ツールの権限を書き換えたりできないようにし、触れてよい関数とテーブルの許可リストを、システムプロンプトとバックエンドのコードの両方に書く、という指示です。

実務での判断は単純です。社外の顧客が使うエージェントには、任意のSQLを渡さない。社内の分析担当が使う探索用途に限って、読み取り専用ロールと組み合わせて任意SQLを許す。この線を最初に引いておけば、隔離インスタンスへ移った後も設計を変えずに済みます。

監査ログの初期値｜Data Accessログが既定で無効という落とし穴

同じページは、既定で有効なのはAdmin Activityの監査ログだけで、Data Accessの監査ログは自分で有効化する必要があると書いています。エージェントが何を読んだかを後から追うには、こちらを先に有効にしておかなければなりません。

加えて、アプリ側でも判断ごとに記録を残すよう求めています。呼ばれたMCPツール、LLMが生成した生のSQL、最終的な実行か承認かの結果、利用者とセッションのID、の4項目です。数千ノードに広がるエージェントの参照は、DB側のログだけでは誰の依頼だったかが分かりません。

独自章｜今すぐ申し込む条件と、GAまで読み取りプールで待つ場面

ここまでの事実を踏まえて、プレビューに申し込むかどうかを条件付きで言い切ります。

申込みを急いでよい条件｜参照が瞬間的に跳ねる多数エージェントの業務

申し込んで検証を始めてよいのは、次の3点がそろっている場合です。本番のAlloyDBが既に稼働していること。エージェントからの参照が、短時間に大量のノードを要する跳ね方をしていること、あるいは近く確実にそうなること。そして読み取りプールの20ノード上限か、ピークに合わせた常設費用のどちらかが既に問題になっていること。発表記事で顧客として名前が出ているManhattan Associatesは、数千拠点の在庫と受注のデータを1秒未満の鮮度で分析するエージェント群を動かしている例として紹介されています。このくらいの規模感が想定の中心です。

見送るべき場面｜本番の正式運用やAlloyDB外のDBが中心の構成

今すぐ本番の業務フローに組み込む前提なら見送ります。Pre-GAの条件では提供内容もサポートも限られ、リージョンと単価も未公表だからです。エージェントの数が少なく参照が平準な場合も、読み取りプールで足りるので待って構いません。DBの中心がCloud SQLやAurora、オンプレミスのPostgreSQLにある場合、この機能のためだけにAlloyDBへ移すのは順序が逆です。移行の費用と、エージェント負荷の伸びを見積もってから判断してください。

既存のデータベースのどこまでをエージェントに開くか、読み取りの経路と権限をどう切るかは、機能の選定より先に決まる設計の問題です。現行DBの構成や移行の要否から整理したい場合は、データベース設計・移行支援で構成案の作成からご相談いただけます。

よくある質問

2026年10月時点の公開情報で答えられる範囲に限って回答します。

エージェントから書き込みもできますか？

できません。公式の説明では、エージェントノードはデータベースの最新状態に読み取り専用でアクセスします。書き込みが必要な業務は、本番側のAPIとして手続きを固定し、エージェントにはそのAPIを呼ばせる形にしてください。任意のSQLで更新させる設計は、隔離の有無にかかわらず避けるべきです。

料金はいくらかかりますか？

単価は公表されていません。公表されているのは、エージェントノードが動いている秒単位で課金され、アイドル時はゼロまで縮退するという課金の形だけです。費用の比較が必要な場合は、読み取りプールの構成で見積もった額を基準に置き、プレビューの申込み後に提示される条件で差し引きを確かめてください。

東京リージョンで使えますか？

公開ドキュメントには対応リージョンの記載がありません（2026-10-09 UTC更新時点）。技術ドキュメントが申込み制のため、リージョンの範囲は申込み後の資料で確認することになります。データの所在に要件がある場合は、申込みの段階でその条件を伝えておくと話が早く進みます。

AlloyDB Omniでも使えますか？

公表資料はColossus上のマネージド版AlloyDBを前提に仕組みを説明しており、Omniでの提供は案内されていません（2026年10月時点）。Omniは自前のファイルシステムにデータを置く提供形態なので、構造が異なります。Omniの要件や費用はAlloyDB Omniとは？自前環境で動かす導入手順・要件・ライセンスと採用判断を実装者目線で解説を参照してください。

既存のエージェントからそのまま接続できますか？

アーキテクチャ解説では、エージェントはMCPで接続すると説明されています。接続先の指定方法そのものは申込み後の資料にあるため、現時点で確実にできるのは、MCP Toolboxやリモート MCPサーバーで読み取りプールへつなぐ構成を先に組むところまでです。ロールとサービスアカウントをこの段階で分けておけば、切り替え時の変更は接続先の設定にほぼ限られます。

関連記事

• AlloyDBとは？PostgreSQL互換マネージドDBの構成・カラム型エンジン・料金と採用判断を実装者目線で解説
• AlloyDB Omniとは？自前環境で動かす導入手順・要件・ライセンスと採用判断を実装者目線で解説
• PostgreSQL MCPサーバーの構成と権限設計｜読み取り専用ロールとスキーマ公開範囲の決め方
• リードレプリカとは？RDS・Auroraでの作成手順と読み書き分離の実装を実装者目線で解説
• AIエージェントとは？生成AIとの違い・仕組みと業務に組み込む判断基準を解説