発表内容と、その限界
2026年8月21日、Google CloudはAlloyDBのScaNNインデックスについて、四階層ツリーという構造の導入によって大規模なベクトル検索に対応したと発表しました。公式ブログの記載によれば、内部テストにおいて、ScaNNインデックスで100億を超えるベクトルまで拡張でき、100億ベクトル時点でp95のレイテンシが51ミリ秒以下、再現率95%を達成したとしています。
ここで確認しておくべき条件が2つあります。ひとつは、この数値がGoogleの内部テストによるものであり、第三者による検証結果ではないこと。もうひとつは、四階層ツリーがプレビューとして提供されている機能であることです。公式ブログにも明確にプレビューと記載されています。したがって、この数値をそのまま自社の要件定義や提案書に転記することはできません。
一方で、このニュースには経営判断に使える面があります。ベクトル検索の規模が、事業者が正面から取り上げる論点になっているということです。規模が増えたときに設計上の課題が生じることを前提に、製品側が対応を進めている状況が読み取れます。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
中堅企業に100億件は不要。しかし件数は見積もる必要がある
社内文書の検索にRAGを使う場合、100億という数字は現実的ではありません。しかし「うちは小規模だから関係ない」で済ませると、後で困ります。件数を見積もらないまま作り始め、想定の何倍にもなってから設計を変えることになるからです。
件数は次の式でおおまかに出せます。
ベクトル件数 ≒ 対象文書数 × 1文書あたりの分割数
問題は、右辺の両方が動くことです。
対象文書数が動く理由：最初は「社内規程だけ」で始めても、運用が回ると議事録、提案書、過去の見積り、メール、問い合わせ履歴を入れたくなります。範囲が広がるのは成功の証拠でもありますが、件数は桁が変わります。
1文書あたりの分割数が動く理由：長い文書を何文字ごとに区切るか、重なりをどれだけ持たせるかで、同じ文書でも件数が数倍変わります。精度を上げようとして細かく分割すると件数が増え、費用と検索時間に跳ね返ります。
したがって、着手前に確認すべきは次の3点です。
- 第一段階で入れる文書の種類と、おおよその件数
- 半年後、1年後に入れたい文書の種類と、その件数
- 分割の方針（何を1件とするか）
3番目は技術的な決定に見えますが、実際は業務側の決定です。「1件の検索結果として、何が返ってきてほしいか」を決めるのは業務です。
規模が変わると何が変わるのか
件数が増えたときに影響が出る箇所を、経営判断の観点で整理します。技術的な詳細ではなく、費用と業務への影響で見ます。
横にスクロールして確認できます
| 影響箇所 | 件数が少ないとき | 件数が増えたとき |
|---|---|---|
| 検索の応答時間 | ほぼ気にならない | 設計次第で体感差が出る |
| 保存の費用 | 小さい | 件数に応じて増える |
| 作成時の費用 | 一度作れば終わり | 追加・改定の分だけ作成が発生し、積み上がる。分割方針を変えると全件の作り直しになる |
| 精度 | 対象が少ないため関連文書を拾いやすい | 似た文書が増え、関係ないものが混ざりやすくなる |
| 権限管理 | 対象が限られるため後回しにされやすい | 対象文書が広がると、機密性と利用者の範囲に応じて出し分けが必要になる |
| 更新の運用 | 手動で足せる | 自動化しないと追いつかない |
このうち、後からの手戻りが大きくなりやすいのは権限管理です。最初に「全社員が見てよい文書だけ」で作ると、権限の概念が実装に入りません。後から人事情報や役員向け資料を追加する場合、どこまで作り直しになるかは、採用した構成、データの持ち方、絞り込みの方式によって変わります。検索の仕組みを含めて見直しになることもあります。
将来的に権限の出し分けが必要になる可能性があるなら、最初から文書に属性を持たせておくことを検討してください。属性を保持する費用は、項目数とデータ量によって変わるため、設計時に見積もっておくと判断しやすくなります。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
更新をどう回すか
RAGの運用で最も見落とされるのが、文書が更新されたときの扱いです。次の3パターンを決めておいてください。
追加：新しい文書が増えたとき、いつ反映するか。即時か、日次か、週次か。業務上「昨日の改定が反映されていない」ことが問題になる文書はどれかを先に決めます。
改定：既存の文書が差し替わったとき、古い内容が検索結果に残らないようにする方法。ここを設計していないと、古い規程が回答に混ざります。実務上、これが最も危険です。
削除：文書が廃止されたとき、確実に検索対象から外れるか。特に、権限の変更（ある部門だけ見られる、に変わった場合）への追随が必要です。
改定と削除が回っていないRAGは、時間とともに信頼を失います。「AIが古い規程を答えた」という事故が一度起きると、現場は使わなくなります。
評価をどう作るか
導入後に「精度が悪い」という声が上がったとき、何をもって悪いと判断するかが決まっていないと改善が進みません。着手時に、次を用意してください。
- 想定質問を30〜50件用意する（現場の担当者に実際の質問を出してもらう）
- 各質問に対して、正しい参照元となる文書を人が指定する
- 変更を加えたら、同じ質問で結果を確認する
この一覧があれば、分割方法を変えたとき、文書を追加したとき、モデルを変えたときに、良くなったのか悪くなったのかを言えるようになります。逆に、これがないまま調整を重ねると、担当者の主観だけで判断することになります。
質問を集める作業は、業務側の協力が要るため後回しにされがちです。しかし、この作業自体が「AIに何を期待しているか」を明確にするため、導入の成否を左右します。
製品選定より先に決めること
ベクトル検索を扱う製品は複数あり、既存のデータベースの拡張機能を使う方法と、専用の製品を使う方法があります。どちらが適しているかは、次で分かれます。
- 既存のデータベースに業務データがあり、それと組み合わせて検索したいか
- 権限の情報を、既存システムから持ってくる必要があるか
- 運用できる人が社内にいるか、委託するか
- 想定件数が、どの程度の期間でどこまで増えるか
製品比較から始めると、この4点が曖昧なまま機能表の比較になります。件数と更新頻度と権限要件を先に出せば、選択肢は自然に絞られます。
文書量と用途から構成を決めたいという相談はデータ活用基盤構築で受けています。AIの用途そのものが定まっていない段階ならAI導入可否アセスメント、受け取った提案の妥当性だけを見てほしいという依頼はシステム開発の発注前相談で扱います。
見積りを比較するための前提条件
RAGの構築を複数社に見積もってもらう場合、前提を揃えないと金額が比較できません。依頼時に、次を自社から提示してください。
横にスクロールして確認できます
| 提示する項目 | 具体例 |
|---|---|
| 対象文書の種類と件数 | 社内規程200件、議事録3年分、製品資料500件 |
| 文書の形式 | PDF、Word、スキャンした画像、社内システム内のデータ |
| 更新の頻度 | 月に10件程度、規程改定は年2回 |
| 想定する利用者数と頻度 | 50人、1人あたり1日5回程度 |
| 求める応答時間 | 数秒以内 |
| 権限の要否 | 部門ごとに参照範囲を分ける必要あり／なし |
| 既存システムとの連携 | 既存の文書管理システムから取得したい |
このうち、形式の欄で結果が大きく変わります。スキャンした画像や、表が多いPDFは、どこまで正しく読み取れるかが製品や処理方式によって異なり、前処理の工数が発生する場合があります。「PDFです」とだけ伝えると、この工数が見積りに含まれず、後から追加になります。実際の文書を数点渡して、読み取り結果を確認してもらうのが確実です。
費用の内訳を分けて把握する
RAGの費用は、一度払えば終わるものと、継続的に発生するものが混在します。分けて把握してください。
初期に発生するもの：文書の収集と整理、形式の変換、初回のデータ作成、検索の仕組みの構築、権限設定、評価用の質問の作成。
毎月発生するもの：データの保存、検索の実行、生成にかかる利用料、更新分のデータ作成、運用の人件費。
不定期に発生するもの：文書の追加に伴うデータ作成、分割方法の見直しに伴う全件の作り直し、モデルの変更に伴う検証。
3番目の「全件の作り直し」が想定外の支出になりがちです。分割方法を変えると、原則としてすべてのデータを作り直すことになります。件数が多いほど費用が大きくなるため、初期の設計で分割方法を検証しておく価値があります。
失敗する使われ方の型
導入したものの使われなくなるRAGには、共通した型があります。
型1：何でも聞ける、と説明してしまった 期待値が高すぎると、少しの誤りで信頼を失います。「この範囲の文書について答えます」と対象を明示したほうが、定着します。
型2：出典が示されない 回答だけが返ってくる設計では、利用者が内容を検証できません。どの文書のどこを根拠にしたかを示す設計にしてください。
型3：古い情報が混ざる 更新の運用が回っていないと発生します。前述のとおり、改定と削除の設計が要です。
型4：権限の考慮がない 見えてはいけない文書の内容が回答に含まれると、一度で運用が止まります。復旧には時間がかかります。
型5：質問の仕方が難しい 利用者が期待する結果を得るために特殊な聞き方が必要な状態は、定着しません。よく使う質問については、あらかじめ用意しておくほうが実用的です。
段階的に広げる進め方
最初から全社・全文書を対象にすると、費用も期間も膨らみ、失敗したときの損失が大きくなります。次の段階で進めるのが実務的です。
第1段階：1部門、1種類の文書、利用者10名程度。ここで想定質問による評価を行い、分割方法と出典表示を確定させます。
第2段階：同じ部門で文書の種類を増やします。更新の運用をここで回し始めます。
第3段階：他部門へ広げます。この段階で権限の出し分けが必要になります。
第4段階：既存システムからの自動取得を組み込みます。運用の人手を減らす段階です。
各段階の終わりに、続けるかどうかを判断する場を設けてください。第1段階で想定質問に答えられない場合、原因は文書そのものだけでなく、分割方法、検索の設定、絞り込み、生成の指示、そして評価用の質問の作り方にもあり得ます。どこに原因があるかを切り分けないまま範囲を広げても、改善しません。
FAQ
Q1. 100億ベクトルという数字は自社に関係ありますか
直接は関係しない企業がほとんどです。ただし、規模が増えたときに検索の設計が変わるという事実は、規模を問わず当てはまります。自社の件数を見積もることに意味があります。
Q2. プレビュー機能を前提に設計してよいですか
推奨できません。プレビューは提供条件や仕様が変わる可能性があります。将来の選択肢として認識しておき、現時点の設計は一般提供されている機能で組み立ててください。
Q3. 文書の分割は細かいほど精度が上がりますか
一概には言えません。細かくすると前後の文脈が失われ、かえって関連性の判断が難しくなる場合があります。想定質問を使って比較するのが確実です。
Q4. 既存のデータベースで対応できますか
扱う件数と要件によります。既存のデータベースにベクトル検索の機能が備わっている場合、運用の担当者や監視の仕組みを共有できる利点があります。件数の見込みを出したうえで比較してください。
Q5. 最初から大規模を想定して作るべきですか
作り込みすぎると、初期の費用と期間が膨らみます。現実的なのは、権限の情報と文書の属性だけは最初から持たせ、それ以外は段階的に拡張できる形にしておくことです。
参考情報
- Google Cloud Blog: AlloyDB ScaNN index four-level tree improves vector search（2026年8月21日）
- GXO データ活用基盤構築
- GXO AI導入可否アセスメント
引用した性能値は、Google Cloudが自社の内部テストの結果として示したものです。外部機関が検証した数値ではありません。四階層ツリーはプレビューとして記載されている機能です。自社環境での性能は、データの性質、件数、構成によって異なります。
