社内文書をAIで検索できるようにしたものの、回答が遅い。モデルを替える前に確認したいのが、必要な文書を探すデータベース側の時間です。

Google Cloudは2026年9月17日、Lucius AIによるAlloyDBとMCPの運用事例を公開しました。これは顧客の実践報告であり、ScaNNの新規提供開始の発表ではありません。本稿では提供元の実測報告を入口に、自社の検索を評価する手順を考えます。Google Cloudの顧客事例

<style> .sv-summary,.sv-note,.sv-flow{padding:1.2rem;margin:1.5rem 0;border:1px solid #c8d8e8;border-radius:16px;background:#edf5ff;color:#142b43}.sv-summary p:last-child,.sv-note p:last-child{margin-bottom:0}.sv-cards{display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,210px),1fr));gap:12px;margin:1.5rem 0}.sv-card{padding:1.1rem;border:1px solid #c8d8e8;border-radius:14px;background:#fff;color:#142b43}.sv-card h3{margin-top:0;color:#174b84}.sv-chart{padding:1.2rem;margin:1.5rem 0;background:#fff;border:1px solid #c8d8e8;border-radius:16px;color:#142b43}.sv-row{margin:1.1rem 0}.sv-row p{margin:.4rem 0}.sv-track{height:24px;background:#e4ebf2;border-radius:3px;overflow:hidden}.sv-bar{height:100%;background:#315c9b}.sv-bar.after{background:#087965}.sv-axis{display:flex;justify-content:space-between;font-size:.85rem;color:#39546c}.sv-table{overflow-x:auto;margin:1.5rem 0}.sv-table table{border-collapse:collapse;width:100%;min-width:640px}.sv-table th,.sv-table td{padding:.85rem;border:1px solid #c8d8e8;text-align:left}.sv-table th{background:#e5effb;color:#142b43}.sv-note{background:#fff7e7;border-left:5px solid #9a5900}.sv-flow ol{padding-left:1.3rem}.sv-flow li{margin:.7rem 0}.sv-small{font-size:.9rem} </style>

何が報告された？ 数字を同じ物差しで見る

Lucius AIの報告では、インデックスなしのベクトル比較からScaNNへ移行し、代表的な本番クエリの時間を1.14秒から24msへ短縮しました。著者は同社創業者で、掲載媒体はGoogle Cloudです。独立機関による横断ベンチマークとは区別します。測定対象と報告値

移行前：インデックスなし 1,140ms

移行後：ScaNN 24ms

0ms1,140ms

出典：上記顧客事例。両方の棒は同じ線形スケールです。掲載値の比は1,140÷24＝47.5（本稿計算）。提供元は約47倍と表現しています。

ここから「当社の全検索も同じ倍率になる」「モデル応答も同じだけ速くなる」とは言えません。公開値だけでは、負荷別の分布や自社の条件まで分からないためです。

技術の要点：近い文書を、どこまで探すか

ベクトル検索は、文書の意味を数値の列で表し、質問に近い列を探す仕組みです。ScaNNは近似最近傍検索（ANN）を行います。厳密な最近傍検索との一致度を示すrecallも測ることで、速さと候補の取りこぼしを一緒に評価できます。これはAIが生成する文章の正答率とは別の指標です。recallの定義と測定

検索対象のパーティション数や再順位付けの候補数を増やすと、recallは改善しやすい一方、単位時間に処理できるクエリ数（QPS）は低下します。CPUが既に飽和している場合、検索スレッドを増やしても単一クエリの時間は改善しません。ScaNNのパラメーター仕様

この3つは、本稿が提案する評価軸です。最高速の設定を採用するのではなく、品質と負荷の要件を満たす設定の中から選びます。

実践：自社で検証する5ステップ

以下は導入判断用の検証案です。本記事制作時にAlloyDBを実行した結果ではありません。最初は本番ではなく、権限を分離した検証環境で試してください。

最小のインデックス作成例

公式ドキュメントでは、次のような構文で自動調整型のScaNNインデックスを作成できます。例のdocumentsは既存テーブル、embeddingはvector型の既存列を想定しています。必要な権限、拡張機能、データ量を事前に確認してください。作成手順

-- 検証環境用。テーブル名・列名・距離関数は実データに合わせる
CREATE EXTENSION IF NOT EXISTS alloydb_scann CASCADE;

CREATE INDEX documents_embedding_scann
ON documents USING scann (embedding cosine);

検索に使う距離関数もインデックスと合わせます。自動調整型について、公式資料は1万行未満のテーブルでは遅延作成を案内しています。この遅延作成はPreviewです。小規模なデモで通常の作成が失敗しても、すぐ製品全体の性能問題と判断せず、要件と機能段階を確認しましょう。行数と遅延作成の条件

recall＝1だけで合格にしない

公式のevaluate_query_recallでは、指定したインデックスが存在しない場合やインデックス検索が選ばれない場合にも、recallが1になることがあります。満点の表示と、近似検索が実際に動いたことは同義ではありません。 実行計画と実行時間を合わせて確認します。評価関数の注意事項

テナントや権限のフィルターも必ず維持します。公式資料は、フィルター付き検索で返却件数がLIMITに届かない状況を説明しています。件数、候補の一致度、フィルターの選択性を一緒に観察してください。フィルター付き検索の調整

開発・保守・運用・コンサルでは何を見る？

費用比較ではDB料金だけでなく、検証・移行の工数や、検索結果を生成モデルへ送る量も記録すると判断しやすくなります。「高速化率」をそのまま「費用削減率」へ置き換えないことが大切です。

MCP運用：分析を頼むことと、変更を許すことを分ける

MCPはAIと外部ツールをつなぐためのプロトコルです。今回の事例では、専用DBロールに読み取りと特定の運用テーブルへの更新を許し、破壊的操作を制限しています。事例の権限設計

自社での開始点としては、読み取り専用の診断を提案します。AIがインデックスを推薦しても、作成は変更申請・承認・検証の経路に載せます。ツール画面から危険なボタンを隠すだけでなく、DBの権限で拒否できるかも確認します。

読み取り専用でも、大量検索が負荷を与えたり、機密データを外へ送ったりするリスクは残ります。利用できるビュー、時間制限、同時実行数、結果の出力先、監査記録を運用要件として決めてください。本文やログからAIが予期しない指示を受けた場合も、権限の境界を越えられない構成を目指します。

限界と、今後見るべきデータ

今回の報告値を別ソースの独立実測で裏付けることはできていません。公式仕様で照合できるのは、機能の使い方や評価時の注意点であり、当該顧客の速度を再測定したものではありません。

今後の比較では、インデックスを使う現状構成との対照、同じrecall条件での速度、更新中の遅延、フィルター付き検索、負荷時のp95、総費用を注視します。これらがそろえば、自社にとっての価値をより具体的に判断できます。

今日の一歩は、モデル交換ではなく、検索と生成の時間を分けて測ること。 遅い場所が分かって初めて、インデックス追加・検索設定・モデル変更のどれを優先するか決められます。

最終確認日：2026年9月18日（日本時間）。報告値は提供元の顧客事例、計算と導入手順の提案は本稿によるものです。

参照元

• Google Cloud：Lucius AIのAlloyDB・MCP運用事例（9月17日公開）
• AlloyDB：ベクトル検索recallの測定
• AlloyDB：ScaNNインデックスの作成
• AlloyDB：ScaNNパラメーター仕様
• AlloyDB：ScaNNの調整ベストプラクティス