Google は AlloyDB の ScaNN インデックスを3層から4層に増やし、100億ベクトルでも p95 51ms・再現率95% を達成したと発表した。ただし、この数字は Google 内部テストの結果であり、第三者による再現検証はまだない。鵜呑みにせず、独立したベンチマークを待つべきだ。
10億ベクトル逼近、従来の木構造が限界に
Google AlloyDB は2026年8月20日に ScaNN インデックスを100億ベクトル規模に拡張し、p95（95%のリクエストが超えない遅延）≤51ms、再現率95%を公式に発表した。数字はひとまず置いておく——この節では、なぜ木の構造を書き換える必要があったのかを見ていく。
エンタープライズ向けの agentic AI（AIが自律的にツールを呼び出して多段階タスクを完了させるパラダイム）が、ベクトルデータベースを数十億〜数百億レコード規模へと押し上げている。AlloyDB の従来の ScaNN インデックスは2層または3層の木にしか対応しておらず、そこからさらにスケールしようとすると2つの具体的な障壁にぶつかる。木の規模が大きくなるにつれ、インデックスの構築とクエリ走査に必要な演算量が急増する。100億ベクトルに対してインデックスを構築するためにサンプリング（木の構造を学習させるためにベクトルの一部をランダムに抽出すること）を行うと、100億件のフルサンプリングはメモリに載らない。2層木の検索計算量は O(N1/2)（ベクトル数 N が増えると、走査量が N の平方根に比例して増える）、3層は O(N1/3)、4層なら O(N1/4) まで圧縮できる——データ量が10倍になっても走査量は2倍未満にしかならない。これが Google が3層から4層に積み増した理由だ。
4層の木は単純に1層多くしただけではない。Google は新構造に Top-K branch、SOAR、centroid adjustment（クラスタ中心の微調整）、balanced tree shape（木形状の均衡化）の4つを同時に組み込み、階層的なサンプリング集合の圧縮と組み合わせた。狙いは、より小さな学習サンプルで高忠実度の木パーティションを再構築することだ。公式ブログではこの数字が内部テスト（internal tests）由来であることが強調されており、第三者による再現データは示されていない——95%再現率と51ms p95 は当面、公式発表値として扱うしかない。
4層木——各層で候補集合をルート倍に絞り込む
数十億規模のベクトルを100ミリ秒未満のレイテンシでさばくために使われているのは、全件スキャンではない。クエリを木の構造に沿って1層ずつ下らせ、層ごとに候補集合を切り詰める手法だ。
query（ユーザーが入力したクエリベクトル。これを使ってデータベース内から最も類似したエントリを探す）に最も近い上位K件を探すには、従来は全ベクトルと比較する必要がある。それが遅延の壁になる。AlloyDB ScaNNは木インデックスを使う。まずベクトル空間全体を粗い粒度のクラスタに分割し、2層目でさらに細かく、3層目、4層目と分割を続け、葉ノードに少数のベクトルだけが残るまで繰り返す。クエリは最上層の入り口から入り、層ごとに query に近い子ノードだけを辿るため、走査ベクトル数は層数に応じて指数的に縮小する。
Google が示す計算量の対比は明快だ。2層木は O(N1/2)、3層木は O(N1/3)、4層木は O(N1/4)。N=100億のとき、N1/2 は10万のオーダー、N1/4 は約562。層が1つ増えるごとに、ルート号の中にさらにルート号が入り、候補集合の圧縮幅は2桁も違ってくる。
木の階層は事前に固定されているわけではない。ScaNN には再現率（真の最近傍のうち実際に検索で見つかった割合。95%なら真の該当100件のうち95件を正しく取り出している） を守るための4つの補助機構が備わっている。Top-K branch（各層で上位 K 個の分岐を保持して下層へ進み、枝刈りで経路を完全に失うのを防ぐ）、SOAR（木の分割で失われる精度を補うリランキング機構）、centroid adjustment（学習時にクラスタ中心を微調整し、境界をより正確にする）、balanced tree shape（木形状の均衡を強制し、特定の枝が肥大化して走査しきれない事態を防ぐ）だ。数十億規模のベクトルを1度学習するには膨大なサンプルが必要でメモリが持たないため、より小さなサンプリング集合とバランス構造を組み合わせて高品質なパーティションを再構築しなければならない。
計算量の式は Google Cloud ブログの原文（2026年8月20日公開）に基づく。N=100億で p95 ≤51ms 遅延・再現率95%という結果は Google 内部テストの数値であり、第三者による再現検証はまだ確認できていない。この不確実性はひとまず保留しておく。
層を1つ増やすと、正解まで刈り取るリスクが高まる
木を3層から4層に増やした狙いは、走査量を N の3乗根から4乗根へ圧縮することにある。しかし結果は逆の方向に働いた。細かく分けるほど各層で選べる分岐が減り、正解を早い段階で剪定してしまうリスクが高まる。ScaNN は4つのパッチで再現率を95%まで押し戻している。
多層木のアプローチは粗い筛いから細かい筛いへと進める。各層では候補となる数本の分岐だけを見て、残りすべてを切り捨てて計算を節約する。層数が増えるほど検索空間 O(N の 1/4 乗) は狭くなり、速度は上がる。同時に枝刈りもより厳しくなり、正解を巻き込んで切り落とす確率も増えていく。
Google のエンジニアはブログで「層を1つ増やすたびに精度損失が増える」とは明言していないが、「Top-K branch、SOAR、centroid adjustment、balanced tree shape」という4点セットの存在自体が、その仮説を裏づけている。
最初のパッチは Top-K branch。通常は各層で最も近い1本の分岐だけを選んで下層へ進むが、Top-K では各層で上位 K 本の候補分岐を並行して辿る。走査量は少し増えるが、漏れが減る。
2つ目は SOAR。原文では「複数のクラスタ中心に再配分するセーフティネット機構」と説明されている。ベクトルが2つのクラスタ中心の境界上にいるとき、どちらかに決めるとどちらかが失われるため、両方の分岐で考慮されるようにする。いわば保険をかける仕組みだ。
3つ目は centroid adjustment。クラスタ中心を構築した後、繰り返し反復して位置を修正し、誤った境界を正しい方向へずらす。最後の balanced tree shape は、各層の分岐が太すぎたり細すぎたりするのを防ぐ。太い層は走査が遅く、細い層は枝刈りが厳しくなるため、バランスを取って初めて全体レイテンシが安定する。
これは Google が4点セットと4層木を同時に発表した理由も説明する。4層木だけ見れば単なるエンジニアリング最適化だが、4つのパッチと組み合わせることで初めて完全な精度修復ソリューションになる。95%再現率、p95 51ms は Google 内部テストの結果であり、第三者による再現テストはまだ出ていない。この精度が他社のデータでも維持できるかどうかは、別の問題だ。
4層木の先に、新たな課題が並ぶ
Google は4層木によって、学習段階のメモリ使用量と検索時の計算量を同時に圧縮した。インデックス構築後の運用、第三者検証、比較基準の整備が新しい論点となる。
検証可能な結論は2つあり、いずれも公式の数字に依拠している。前提は「4層木 + バランス構造 + 圧縮サンプリング集合」の3点セットが一体で機能することだ。どれか1つでも欠ければ結論は崩れる。
このアプローチが本当に機能したと言えるのはいつか。独立したベンチマークによる再現テストが出て、その結果も公式と同等の桁を示す場合。逆に、再現テストで再現率が公式より明確に落ちたり、レイテンシが顕著に悪化したりするなら、4層木のコストが過小評価されていたことになる。
もう1つの観察ポイントは「圧縮サンプリング集合」の発動頻度だ。情報源はメモリ逼迫時にシステムがこの圧縮版を生成すると述べるだけで、閾値、圧縮比、圧縮後の精度損失は明らかにされていない。今後 Google が更新で具体的な発動条件と誤差範囲を提示すれば、その機構は工学的に安定していると判断できる。長期にわたって何も開示されないなら、それはあくまで保険的な仕組みに過ぎず、デフォルトの保証とは見なせない。
エコシステムについては2つ観察できる。ScaNN が今回 AlloyDB に組み込まれたことで、Google 自社のベクトル検索アルゴリズムがマネージド PostgreSQL と結びついた。第1に、ScaNN インデックスが BigQuery や AlloyDB 以外の顧客にも独立した形で開放されるか。第2に、AWS Aurora や Azure Database が対抗となる多層木ソリューションを投入するか。どちらかが実現すれば「4層木」が業界標準の設計になりつつある証拠だし、どちらも実現しなければ、当面は Google 単一製品ラインの内部選択に留まる。
コストはまだ明らかにされていない。この規模のインデックスをクラウドで動かすと、メモリ・CPU・ストレージの3つの費用がいずれも膨らむ。公式は末尾で30日間無料トライアルとクイックスタートドキュメントに読者を誘導するのみだ。今後 Google が対応規模の AlloyDB インスタンス価格や、1000クエリあたりの課金内訳を公表して初めて、このアーキテクチャが企業予算にとって贅沢品か日用品かが判断できる。
まず採算を見極めてから試すか決める
公式の数字は自社テストだ。以下のアクションで、再現テストを待ちつつ数字の信頼性を確認できる。
まず押さえておきたい重要な区別がある。公式の3つの数字は互いに関連する。100億ベクトル、再現率95%、p95 51ms は同じ文脈で語られており、Google は95%再現率を閾値として遅延を報告しているのであって、100%再現率で報告しているわけではない。これはベクトル検索では一般的な手法だが、読者が両者を混同しやすい点に注意が必要だ。ベンダーによる自社テストであり、第三者による同一ハードウェア・同一データセットでの同一指標測定はまだ存在しない。現時点でこの数字をそのまま信じるのはリスクがある。
すでに AlloyDB を使っているなら、最短の検証ルートは公式の quickstart ドキュメントで4層木インデックスの有効化方法を確認すること。独立した第三者ベンチマークが出たら、桁が一致するかを比較しよう。数十ミリ秒級なら合格、数百ミリ秒級なら自環境では調整が必要かもしれない。
新規ユーザーなら30日間無料トライアルから始めて、本番環境への投入は約束しないでおこう。原文には quickstart の具体的なURL、トライアル条件の詳細、料金体系は示されておらず、それらは読者が公式ページで確認する必要がある。
いまは観察しかできないアクションもある。原文では4層木が preview とされており、まだ初期段階のため仕様や価格が変わる可能性がある。AlloyDB のリリースノートと changelog を盯視し、preview ラベルが外れて GA になって から本番投入を決めるのがより安全なルートだ。
ScaNN は近似最近傍インデックス（速度と引き換えに少量の誤差を許容するインデックス構造）であり、preview 段階で API 変更、パラメータ調整、性能のばらつきが起きても不思議ではない。
最後に自分に問うべき判断材料を1つ残しておく。実際のビジネスでベクトル数が数百万〜数千万程度なら、3層木で十分であり、4層木による遅延改善はおそらく体感できない——その場合、移行コストの方が便益を上回るだろう。100億という規模は、文字通り天井に突き当たった人のためのものだ。
リリースノートと quickstart ドキュメントを確認し、4層木インデックスの有効化方法を把握する。
独立した第三者ベンチマークを待ち、桁が一致するかを比較する。
AlloyDB changelog を確認し、four-level tree がまだ preview 状態であることを確かめてから GA シグナルを待つ。
自身のベクトル規模を見積もる。1億未満なら手を付けず、100億級になって初めて移行のコストと便益を検討する。
公式の3つの数字が互いに関連する関係——100億ベクトル、再現率95%、p95 51ms——を独立した値ではないと認識しておく。
情報源：Google Cloud Blog（AlloyDB チームの Software Engineer Bin Song と Engineering Manager Itai Rosenblatt による署名記事）。条件説明：本文中の100億ベクトル、再現率95%、p95 ≤51ms はいずれも Google 内部テストの結果であり、2026年8月20日に公開。4層木アーキテクチャは preview 段階にあり、第三者による独立した再現テストはまだ確認されていない。