Cloudflare VectorizeとRAG入門：検索とAI回答の違いを理解する

先に結論：Vectorizeは「探せない」を減らすための検索層

サイトには、すでに丁寧なガイドやFAQがあるのに、訪問者がそのページにたどり着けないことがあります。理由は、見出しの言葉と利用者の質問の言葉が一致しないからです。

たとえば、サイトに「アカウント設定」という説明があっても、利用者は「ログイン後に何をすればいい？」「初期設定が分からない」と質問するかもしれません。単語が完全に同じではないこの差を埋めるのが、意味の近さで候補を探すVectorizeです。

Cloudflareの公式説明でも、Vectorizeはsemantic search、推薦、分類などに使えるベクトルデータベースとして案内されています。この入門では、もっとも身近な「公開サイト内の情報を、利用者の言葉で探しやすくする」使い方に絞ります。Cloudflare Vectorize公式ドキュメント

導入すると、何が変わるのか

Vectorizeは、新しい事実を作ったり、古い情報を自動で正しくしたりするものではありません。価値は、すでに公開している信頼できる情報に、より自然な入口を作ることです。

利用者は、言い換えた質問から近いページを見つけやすくなる

検索語を正確に思い出せない利用者でも、相談文に近い意味を持つガイド、FAQ、事例を候補として受け取れます。これは、見出しを知っている人のための検索だけでなく、「何を探すべきか自体が分からない人」の入口になります。

運用側は、既存のドキュメントを案内に再利用できる

新しいチャットの回答をゼロから書くのではなく、公開済みの情報を検索結果や回答の根拠にします。どのページを案内したかが分かるため、情報を増やすべき場所や、説明が重複している場所を見直す起点にもなります。

AI回答を付ける場合も、出典を確認できる形にできる

RAGでは、選んだ公開ページを追加コンテキストとしてAIへ渡し、回答と一緒に元ページへリンクします。利用者は答えを鵜呑みにせず、一次情報を確認できます。根拠が弱いときは、回答を作らないことも品質の一部です。

RAGとは何か

RAGは Retrieval Augmented Generation の略です。日本語では「検索で取り出した情報を補って、AIが回答を生成する仕組み」と考えると分かりやすくなります。

たとえると、Vectorizeは意味が近い資料を見つける司書の検索棚です。RAGは、その棚から見つけた資料を読んで出典を添えながら答える司書の仕事全体です。

つまり、AIへ質問をそのまま送るのではなく、先に自分の公開情報から関連資料を探し、その資料を追加コンテキストとして渡します。Cloudflareも、ベクトル検索で得たコンテキストをLLMへのpromptに加える使い方をRAGとして説明しています。Cloudflare公式解説

VectorizeとRAGの役割は違う

部品	担当すること	それだけでできること
Pagefind	ページ内の単語を探す	製品名、固有名詞、エラーコードを素早く探す
Vectorize	意味が近い情報を探す	言い換えや関連ページを候補として返す
RAG	検索結果を根拠にAIが回答を作る	回答と、参照したページのURLを返す

Vectorizeは回答を生成しません。RAGは検索だけでもありません。検索、根拠の選別、回答生成、出典表示までを一つの契約として設計して初めて、利用者が答えを確かめられます。

図：通常検索は正確な単語探しに、意味検索は言い換えや関連情報の発見に向きます。どちらか一方へ置き換えるのではなく、役割を分けます。

効果が出る場面と、先に整備したい場面

Vectorizeが役立ちやすい場面	先に情報設計を整えたい場面
同じ相談が、利用者ごとに違う言葉で届く	公開してよい情報と下書き・社内情報が混ざっている
FAQ、ガイド、仕様、事例が複数ページに分かれている	記事が古く、どれが正しいかを判断できない
関連する次の一歩を案内したい	固有名詞や型番だけを素早く探せれば十分
回答に元ページのリンクを添えたい	出典を示せないままAIに自由回答させたい

意味検索は、情報の品質を置き換えません。まず公開内容の責任範囲を整え、その上で「どの質問に、どのページを出すか」を小さなテスト質問で評価します。

小さく始める3段階

最初からチャットボットを作る必要はありません。次の順番なら、価値を測りながら安全に広げられます。

1. 通常検索を残す：Pagefindで、製品名やエラーコードを今までどおり探せる状態を保ちます。
2. 関連ページ検索を加える：Vectorizeで、質問に近い公開ページを候補表示し、テスト質問で妥当性を確認します。
3. 根拠付きの回答へ進む：使うページ、出典リンク、回答しない条件を決められた場合だけ、RAGの回答機能を追加します。

図：通常検索を土台として残すことで、意味検索やAI回答を小さく検証し、問題があれば安全な経路へ戻れます。

この順番なら、AI回答の見栄えより先に、検索対象そのものが正しいかを確かめられます。

RAGの回答は、根拠を選ぶところから始まる

決めること	はじめやすい選択	理由
質問の対象	公開サイトの説明だけ	社内情報や下書きを誤って答えに使わない
根拠の表示	回答ごとに元ページへリンク	利用者が回答を確認できる
情報不足時	「確認できません」と伝える	もっともらしい推測を避ける
検索との分離	入力中はPagefind、明示操作でVectorize／RAG	送信範囲、費用、待ち時間を分かりやすくする
更新の基準	公開済みHTMLと公開日時を基準にする	下書きや未公開の修正を根拠に混ぜない
評価方法	代表的な質問と元ページのリンクで確認する	「それらしい答え」だけで品質を判断しない

RAGは誤答をゼロにする技術ではありません。検索対象の選び方、根拠の確認、回答できない条件を明示することが品質を決めます。

図：RAGは、検索結果をそのまま答えにしません。元の公開情報を確認し、使える根拠だけを回答と出典へつなげます。

次に読むと、導入の判断から実装までつながる

このページは「何のために使うか」を判断する入門です。次の順番で読むと、構想だけで終わらせず、実装と運用の境界まで確認できます。

1. Vectorizeを安全に実装する詳細ガイドで、公開HTMLのcorpus化、content hash、差分同期、Preview／Production分離、rate limitを確認する。
2. 問い合わせAIチャットを組み込む技術設計で、AIに渡す入力、API境界、URL許可リストを確認する。
3. Astro + Cloudflareで公式サイトを機能拡張する全体設計で、静的サイトを土台に検索・AI機能を増やす役割分担を確認する。

「検索を良くしたい」のか、「根拠を示せるAI案内まで必要か」を分けて決めると、必要な実装と検証が見えやすくなります。