AlloyDBがAIエージェント専用DBを本番と分離したまま数秒起動

複数のAIエージェントに、注文データや在庫データを同時に見に行かせる仕組みを作ろうとしたら、本番の処理が重くなったり、最悪止まったりしないかと不安になる。読み取り専用の複製(レプリカ)を増やす方法はあるが、増やすほど複製の用意や通信路が混み合い、本番の速度まで落ちることがある。

Google Cloudは2026年9月24日、この板挟みへの答えを発表した。AIエージェント専用のデータベース実行環境を数秒で用意する新機能をAlloyDBに追加したのだ。本番システムと計算資源やネットワークを共有しない設計にすることで、大量のエージェントが同時に動いても本番の速度が落ちないようにしている。気になるのは、なぜ今までの方法では足りなかったのか、AlloyDBは本番と何を分けているのか、そしてどこまで拡張しても大丈夫なのか、という点だ。

何が新しく使えるようになったか

AlloyDBの新機能「PostgreSQL for agents」は、AIエージェント専用の読み取り専用インスタンスを、本番の複製ではなく数秒で用意できる仕組みだ。Google Cloud公式ブログによると、このインスタンスは本番の一次系・待機系・読み取りレプリカのいずれとも切り離されている。Googleの分散ストレージ基盤「Colossus」から直接、秒単位の鮮度でデータを読みに行く仕組みだ。エージェントの処理が終われば台数は自動的にゼロまで戻り、動いていた分だけ課金される。現時点ではプレビュー提供で、利用には申込みが必要だ。

ここまでは何が起きたかの説明だが、そもそもなぜ今まで、エージェント用にこれだけの仕組みを新しく作る必要があったのだろうか。

なぜ今まで難しかったのか

複数のAIエージェントが一斉に問い合わせを送る負荷は、これまでのデータベースの拡張方法と相性が悪い。Googleは、オブジェクトストレージと共有のキャッシュ層(ブロックサーバー)を使う、ある商用サービスで実際に検証している。

技術解説ブログによれば、読み取り用のレプリカを1台から8台まで増やしても、処理量は2倍にも届かないままピークに達した。その一方で、本番クラスタの処理速度は75%を超えて落ち込んだという。エージェントを増やして負荷を分散させたはずが、逆に本番を巻き添えにした形だ。比較対象の商用サービス名は公式ブログに明記されておらず、この検証はGoogle自身が実施したものである点は割り引いて読む必要がある。

なぜこうなるのか。データベースを増やす方法には、大きく3つの型がある。

表は、本番からの隔離・読み取りの速さ・拡張のしやすさという3条件を、既存の3方式で比べたものだ。差から分かるのは、どの方式も3条件を同時には満たせていないということになる。独立レプリカは安全だが用意が遅く、共有ストレージ型は速いが本番と資源を分け合ってしまう。この3条件は互いにトレードオフの関係にある。複製を独立させれば安全だが、用意に時間がかかる。ストレージを共有すれば複製はすぐ増やせるが、本番と読み書きの経路を分け合うことになる。どちらを選んでも、どこか1つを犠牲にせざるを得なかった。

つまりAlloyDBが取り組んだのは、複製を「独立させる安全さ」と「すぐ増やせる速さ」を両立させるという、長年の綱引きそのものになる。

本番と何を分けているのか

AlloyDBのエージェント向け方式は、本番と共有する部品を意図的に1つだけに絞っている。Googleには、検索やYouTube、Gmailなどを長年支えてきた分散ストレージ基盤「Colossus」がある。単一のクラスタでエクサバイト規模のデータを収め、最大15テラバイト/秒の集約転送量と2,000万クエリ/秒を1つのデータベースにさばけるという(公式ブログ)。AlloyDBのエージェント向けインスタンスは、このColossusの中でも本番用とは別の区画から、実データを直接読みに行く。

読みに行くための計算資源(マイクロVMという軽量な仮想マシン)とネットワーク経路は、本番用とは別に用意される。本番と共有しているのはデータの実体だけで、そこへ辿り着く経路は最初から別物になっている。この分離の効果は、実際にどこまでの規模で確かめられているのだろうか。

どこまで速く拡張できるのか

Google自身の検証によれば、この方式は1台から1,000台まで台数を増やしても、本番クラスタの性能低下が測定できないレベルにとどまった。公式ブログの検証では、エージェント向けインスタンスを1台動かした時点で秒間3,900件のクエリを処理できた。10台に増やすとほぼ比例して、秒間41,000件まで伸びている。そこから台数をさらに1,000台まで増やしても伸び方はほぼ線形のままで、合計の処理能力は最終的に773倍の秒間300万件に達したという。

自分はこの773倍という数字に、思わず二度見した。普通、複製を増やせば増やすほど元のストレージや通信路が窮屈になり、増やした分だけ性能が素直に伸びることはまずない。この図が示すのは、1台の処理能力を積み上げただけでは追いつかないほどの伸び方が、実際に観測されたということだ(出典: 前掲のGoogle Cloud公式ブログ)。この間、Colossus側のI/O処理は800万IOPSを超えた。2,100台規模の全表スキャンでは、集約1テラビット/秒を超すスキャン帯域も確認できている。それでも本番側の処理速度は、一貫して保たれていたという。

ここで紹介した数字は、AlloyDB自身の検証も、前節で触れた比較対象サービスの検証も、いずれもGoogleが自ら実施したものだ。独立した第三者による再現は確認できておらず、比較相手の商用サービス名も公式ブログには明記されていない。

サプライチェーン管理を手がけるManhattan AssociatesのCTO、Sanjeev Siotia氏も、この新しい仕組みにコメントを寄せている。

複数のエージェントが在庫や注文のデータをサブ秒の鮮度で分析できるようになり、基幹の取引処理にはまったく手を触れずに済んでいるという。冒頭で挙げた「注文データや在庫データ」という例は、机上の想定ではなく、実在の顧客が実際に扱っている対象と重なる。ただしこれは同社自身の評価であり、Googleの検証と同じく、独立した第三者による確認ではない。

拡張できることは分かったが、では実際に今どこまで使えて、費用はどうなるのだろうか。

今すぐ使えるのか

2026年9月24日時点で、この機能はプレビュー提供にとどまり、利用には公式サイトからの申込みが必要だ。料金は稼働した時間だけを払う従量課金制で、エージェントが処理を終えればインスタンスは自動的に台数ゼロまで戻り、そこから先の課金は発生しない。1クエリあたりや1秒あたりの正式な単価、一般提供の時期、対応リージョンは、2026年9月26日時点の公式ブログには記載がなく、確認できていない。

まとめ

AlloyDBの新機能は、AIエージェント専用の実行環境を数秒で用意する。本番と共有する部品を、実データを収めたストレージだけに絞ることで、隔離・速度・拡張性を同時に満たした。Googleの検証では、1台から1,000台に増やしても本番への影響は測定できないレベルで、合計の処理能力は773倍の秒間300万件に達している。エージェントに本番データを安心して触らせたいと考えているなら、まず公式ドキュメントでプレビューの申込み条件を確認するところから始められる。