Basic認証下のコンテンツをVertex AI Search(Agent Search)にインデックスさせる方法 ― 検証で分かったこと

はじめに

自社サイトの会員限定エリア(Basic認証で保護されたページ)に、Google CloudのVertex AI Search(現Agent Search)によるサイト内検索を導入しようとすると、思いのほか多くの落とし穴にぶつかります。

「Basic認証の裏側にあるコンテンツを、公開のGoogle検索には一切載せずに、Vertex AI Searchのデータストアにだけインデックスさせたい」——この一見シンプルな要件を満たすために、複数日にわたって実際にテストサイトを構築し、Apacheのアクセスログを解析しながら検証した結果を、このエントリにまとめます。

最初にぶつかった壁: 「独立したクロール」という誤解

Vertex AI Searchのデータストアを作成する際、多くのドキュメントや解説記事では「URLパターンを指定すればGoogle-CloudVertexBotが自動的にクロールしてくれる」と説明されています。ところが、Basic認証で保護されたエリアに対してこれを試すと、いつまで経ってもインデックスが増えません。

検証の結果分かったのは、次の点でした。

Vertex AI Searchの自動クロール経路は、Googlebotが先にそのページをGoogle検索側でインデックスしていることを前提とした挙動になっている。Google-CloudVertexBotは完全に独立してクロールしてくるわけではない。

つまり、「Basic認証で守っているから公開のGoogle検索には出ないはず」という前提のページに対して、Vertex AI Search側だけを動かそうとしても、そもそもの発見(discovery)の起点がGooglebot経由の公開インデックスに依存しているため、うまくいかないケースがあるということです。

解決の方向性: discoveryと本文クロールを分離する

この依存関係を踏まえて設計したのが、「Googlebotにはページの存在だけを知らせるが、本文はクロールさせない」という構成です。具体的には、robots.txtとsitemap.xmlを組み合わせて実現します。

robots.txtの設計

User-agent: *
Allow: /

User-agent: Googlebot
Disallow: /member/
Allow: /member/sitemap.xml

User-agent: Google-CloudVertexBot
Allow: /

Sitemap: https://www.example.jp/sitemap.xml

ポイントは以下の3つです。

  1. Googlebotには/member/配下を丸ごとDisallowすることで、公開Google検索へのインデックスを防ぐ
  2. ただしsitemap.xmlだけは例外的にAllowする。Googleのrobots.txt解釈は「より長く具体的に一致するルールが優先」されるため、Disallow: /member/よりAllow: /member/sitemap.xmlが優先され、このファイルだけは読める
  3. Google-CloudVertexBot専用グループを明示する。GooglebotとGoogle-CloudVertexBotで挙動を分けたい以上、両者に個別のグループを用意しておくのが安全側の設計だと考えたため

この設計により、Googlebotはsitemap.xmlを読んで「このURL群が存在する」ことは認識しますが、Disallowによって本文をクロールできないため、公開検索結果には一切出てきません。一方で、URLの存在自体は認識されるため、Vertex AI Search側のdiscoveryの起点として機能します。

Basic認証を越えさせる: .htaccessでのUser-Agent例外

robots.txtだけでは、実際のBasic認証の壁は越えられません。「クロールしてよい」という許可と、「認証を突破できる」ことは別問題です。ここで使うのが、ApacheのUser-Agentベースの認証除外設定です。

<RequireAny>
    Require valid-user
    Require expr %{HTTP_USER_AGENT} =~ /(?i)(Google-CloudVertexBot|Google-Site-Verification)/
</RequireAny>

# sitemap.xml だけは Googlebot にも認証を通す
<Files "sitemap.xml">
    <RequireAny>
        Require valid-user
        Require expr %{HTTP_USER_AGENT} =~ /(?i)(Googlebot|Google-CloudVertexBot|Google-Site-Verification)/
    </RequireAny>
</Files>

ここでのポイントは以下の通りです。

  • **メインの<RequireAny>**では、通常のBasic認証(valid-user)に加えて、Google-CloudVertexBotのUser-Agentを持つリクエストも通す
  • <Files "sitemap.xml">ブロックだけは、Googlebotも例外的に通す。Apacheのデフォルト仕様(AuthMerging Off)では、より限定的なコンテキストの認証設定が外側の設定を完全に上書きするため、このファイルに対してだけ別のルールを適用できる
  • Google-Site-VerificationというUser-Agentも例外に含めている。これはGoogle Site Verifier User Agentという、Search Console等でのドメイン所有権確認に使われる正規のクローラーで、robots.txtのルールを無視するという特性を持つ。データストアのドメイン確認プロセスを通すために、このUAも例外に加えておく必要がある

見落としがちな失敗パターン

検証中、<Files>ブロックがコメントアウトされてしまい、sitemap.xmlの取得が401エラーになるという事故が実際に起きました。設定ファイルを触るたびに、対象ファイルへの意図しないアクセス制限がかかっていないか、curlで都度確認する習慣が重要です。

curl -A "Googlebot" -I https://www.example.jp/member/sitemap.xml

手動クロールという武器: recrawlUris API

discoveryの起点を用意しても、実際にいつクロールされるかはGoogle側の裁量に委ねられます。検証・デバッグの場面で「今すぐ結果を確認したい」という場面では、recrawlUrisというAPIが有効です。

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://discoveryengine.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/collections/default_collection/dataStores/DATA_STORE_ID/siteSearchEngine:recrawlUris" \
  -d '{"uris": ["対象URL"]}'

このAPIには以下のような特性があります。

  • 1回のリクエストで最大10,000件のURLを指定可能
  • long-running operationとして実行され、指定したページがクロールされるか、最大24時間でタイムアウトするまで動作する
  • sitemap.xmlの中身は一切参照しない。URLを直接指定する方式なので、sitemapに載せる/載せない、lastmodの有無とは無関係に動作する
  • コンソールのUIには相当する操作がなく、curlベースでの操作が前提

継続的な更新はどう扱うか: sitemapベースの自動リフレッシュ

毎回手動でAPIを叩く運用を避けたい場合は、sitemap.xmlの差分検知に任せる方法があります。公式ドキュメントによると、Agent Searchは初回登録後、sitemapの変更を毎日検知し、次のように処理します。

変更の種類挙動
URLの追加該当URLがインデックスに追加され、以降毎日リフレッシュ対象になる
URLの削除インデックスから削除され、リフレッシュ対象から外れる
既存URLの更新(lastmodの変更)更新から最大24時間以内に、そのURLだけが再クロールされる
変更のないURL14日ごとの定期リフレッシュのみ

ここで重要なのは、「更新された」と判定される唯一の合図がlastmodフィールドの変化であるという点です。逆に言えば、内容を修正してもlastmodを更新しなければ、Agent Search側はその変更に気づきません。

一方で、「定期的にsitemap.xmlを丸ごと再生成し、全URLのlastmodを一律で最新日付に書き換える」という運用は避けるべきです。実際には変更されていないページまで「更新された」と誤認識され、無駄な再クロールが大量発生するほか、sitemap全体の信頼性が下がるリスクもあります。lastmodは、実際にコンテンツを変更したURLだけを、その都度正確に更新する運用が前提です。

まとめ

一連の検証を通じて分かった要点を整理すると、次の通りです。

  • Vertex AI Search(Agent Search)の自動クロールは、Googlebotによる公開インデックスへの依存が大きい。Basic認証コンテンツを公開検索に晒さずにインデックスさせるには、discovery(sitemap閲覧の許可)と本文クロール(Disallow)を意図的に分離する設計が必要
  • Google-CloudVertexBot専用のUser-agentグループを明示しておくと、少なくともそれが最も具体的なルールとして適用される。専用グループを省略した場合の挙動については公式な裏付けが取れなかったため、省略せず明示しておくのが無難
  • Basic認証を越えさせるには、robots.txtだけでなく.htaccess側でのUser-Agentベースの認証除外が必要。ただしUser-Agentは容易に偽装可能なため、本番運用ではIPレンジによる検証も検討すべき
  • 即時性を求めるならrecrawlUris API、継続的な自動反映を求めるならlastmodを正確に運用したsitemapベースのリフレッシュ、と使い分けるのが実務的

なお、これらの挙動については、Google公式ドキュメントに明記されていない部分や、質問の仕方によってAIツールの回答が一貫しないケースも見られました。本記事の内容のうち、実際にApacheのアクセスログで挙動を確認できた部分は事実として扱っていますが、Google公式ドキュメントの記載を引用する形の説明については、可能な限りURLを直接開いてご自身でも確認いただくことをおすすめします。Google側の仕様変更によって挙動が変わる可能性がある点にも、あわせてご留意ください。

コメント