Cloudflare 29：Vectorize と AI Search ― 意味で探して、答える

埋め込み：文章を「意味を表す数字の並び」にする

意味で探すための第一歩が、埋め込み（Embedding） です。

埋め込みモデルは、文章を受け取って、数字の並び（ベクトル）を返す AI のモデルです。たとえば「退会の手順」を入れると、[0.12, -0.53, 0.08, 0.91, …] のような数字が、モデルによって数百〜千個ほど並んだものが返ってきます。この個数を次元数と呼びます。多言語に対応した bge-m3 なら 1024 次元です。

数字の1つ1つに、人間が分かる意味があるわけではありません。大事なのは、モデルが大量の文章から学んだ結果、意味の近い文章は、近い数字の並びになるように作られていることです。「解約したい」と「退会の手順」は、文字は違っても近い並びになり、「カレーの作り方」とは遠い並びになります。

Cloudflare では、この埋め込みを Workers AI（28号）で作れます。

右の図は、この数字の並びを「空間の中の1点」として描いたものです。本当は 1024 次元の空間ですが、図では2次元に縮めて見せています。

意味が近いものは、空間の中で近くに集まる

FAQ の文書を全部、同じモデルで埋め込みにして、空間に置いてみます。すると、図のように意味の近いものどうしが集まります。退会・パスワード・支払いのような手続きの話は手続きどうしで、料理の話は料理どうしで固まり、天気の話は遠くに離れます。

こうなれば、「意味で探す」は「空間の中で近い点を探す」という計算の問題になります。

ただし、文書が何万、何百万と増えると、全部の点との距離を毎回計算するのは遅すぎます。そこで、近い点を速く探せるように、点の集まりを特別な形で整理して保存するデータベースが使われます。これがベクトルデータベースで、Cloudflare のそれが Vectorize です。

Vectorize は Workers からバインディングで使えます。KV や D1 と同じように、env.VECTORIZE として呼び出します。

質問も同じモデルで点にして、近い点を探す

利用者が「解約したい」と入力したら、この質問も同じ埋め込みモデルで数字の並びにします。すると、空間の中に質問の点が置かれます。図の赤い点です。

「解約」という文字は、どの文書にも入っていません。でも、質問の点は「退会の手順」のすぐそばに置かれました。意味が近いからです。これが、キーワード検索では見つからなかった答えを見つけられる理由です。

では、「近い」はどう測るのでしょうか。代表的な測り方は次のとおりです。

どれを使うかは、Vectorize のインデックス（点を入れる箱）を作るときに決めます。埋め込みモデルの説明に推奨の測り方が書かれていることが多いので、それに従いましょう。迷ったら、文章の検索ではコサイン類似度が定番です。

いちばん近い k 件を返す（topK）

Vectorize に質問の数字の並びを渡すと、近い順に上位 k 件を返してくれます。この k を topK と呼びます。図では topK を 3 にしたので、退会の手順・支払い方法の変更・パスワード再設定の3つが選ばれました。料理や天気の文書は出てきません。

返ってくる結果には、それぞれの近さの点数（score）が付きます。コサイン類似度なら、1 に近いほど似ています。「点数が一定より低いものは使わない」と決めておくと、関係の薄い文書を拾いにくくなります。

結果には、保存するときに付けておいたメタデータ（付随する情報）も一緒に返せます。たとえば、文書の ID、題名、カテゴリなどです。本文そのものは D1（23号）や R2（22号）に置き、Vectorize には ID と短いメタデータだけを入れておく、という分担がよく使われます。

メタデータは、絞り込みにも使えます。「カテゴリが account のものだけから探す」「公開中の文書だけから探す」といった条件を付けて検索できます。ただし絞り込みに使う項目は、先にメタデータの索引を作っておく必要があります（後の落とし穴のページで説明します）。

RAG ①：探す ― 質問に関係する資料を集める

ここまでの「意味で探す」を使って、AI に社内の資料に基づいて答えさせる方法が RAG（Retrieval-Augmented Generation、検索で補強した生成）です。流れは5段で、前半の3段が「探す」です。

なぜわざわざ探すのでしょうか。LLM は、学習したときに見た知識しか持っていません。あなたの会社の退会の条件や、昨日変わった料金表は知りません。知らないことを聞かれると、それらしい作り話をしてしまうこともあります。

そこで、答えさせる前に、手元のデータから関係する部分を探して集めておくのです。資料全部を毎回 AI に渡すのは、長すぎて入りきらないうえに費用もかかります。関係する数件だけを選んで渡せば、短く、安く、正確になります。

RAG ②：答える ― 集めた資料を添えて LLM に聞く

後半の2段が「答える」です。

LLM に渡す指示は、たとえば「次の資料だけを根拠に答えてください。資料に書かれていないことは『分かりません』と答えてください」のようにします。その後ろに、③で取り出した文章を並べ、最後に利用者の質問を置きます。

こうすると、LLM は自分の記憶よりも、目の前の資料を元に答えるようになります。作り話がゼロになるわけではありませんが、大きく減ります。さらに、どの文書を根拠にしたかを答えと一緒に表示すれば、利用者が自分で確かめることもできます。

RAG の良いところは、AI を学習し直さなくても、資料を入れ替えるだけで答えが新しくなることです。料金表が変わったら、その文書を埋め込みにして Vectorize に入れ直すだけです。

導入：インデックスを作り、バインディングを書く

Vectorize を使うには、まずインデックス（ベクトルを入れる箱）を作ります。wrangler のコマンドで作れます。

npx wrangler vectorize create faq-index --dimensions=1024 --metric=cosine
npx wrangler vectorize create-metadata-index faq-index --property-name=category --type=string

--dimensions には、使う埋め込みモデルの次元数を指定します。bge-m3 なら 1024 です。--metric は近さの測り方です。この2つは作った後に変えられません。 モデルを変えたら、インデックスを作り直すことになります。

2行目は、メタデータの category で絞り込めるようにするための索引です。絞り込みに使う項目があるなら、ベクトルを入れる前に作っておきます。

次に、wrangler の設定ファイルにバインディングを書きます。埋め込みを作るために、Workers AI のバインディングも一緒に付けます。

[[vectorize]]
binding = "VECTORIZE"
index_name = "faq-index"

[ai]
binding = "AI"

これで、コードから env.VECTORIZE と env.AI が使えるようになります。

使い方：入れる（upsert）と探す（query）

文書を入れる処理と、質問から探す処理の例です。

// 入れる：文書を埋め込みにして保存する
const e = await env.AI.run("@cf/baai/bge-m3", { text: [doc.body] });
await env.VECTORIZE.upsert([
  { id: doc.id, values: e.data[0], metadata: { category: "account" } },
]);

// 探す：質問も同じモデルで埋め込みにする
const q = await env.AI.run("@cf/baai/bge-m3", { text: [question] });
const res = await env.VECTORIZE.query(q.data[0], {
  topK: 3,
  returnMetadata: "all",
  filter: { category: "account" },
});
// res.matches は [{ id, score, metadata }, …]

upsert は「無ければ入れる、同じ ID があれば置き換える」です。文書を書き換えたときも、同じ ID で upsert すれば新しい内容になります。

探した後は、res.matches の ID で元の文章を D1 などから取り出し、RAG の④として LLM に渡します。

const context = docs.map((d) => d.body).join("\n---\n");
const answer = await env.AI.run("@cf/meta/llama-3.1-8b-instruct", {
  messages: [
    { role: "system", content: `次の資料だけを根拠に答えてください。\n${context}` },
    { role: "user", content: question },
  ],
});

AI Search：ここまでの RAG を、丸ごと任せる

ここまで見てきたように、RAG を自分で組むには、やることがたくさんあります。文書を適当な長さに分け、埋め込みにし、Vectorize に入れ、文書が更新されたら入れ直し、質問が来たら探して LLM に渡す。

これを丸ごと引き受けてくれるのが AI Search です。以前は AutoRAG という名前でした。

使い方は、管理画面で AI Search のインスタンスを作り、データの置き場所（たとえば R2 のバケット）を指定するだけです。PDF やテキストをそのバケットに置けば、あとは自動で検索できる状態になります。意味の検索に加えて、キーワードでの検索を組み合わせる仕組みも用意されています。

呼び出し方は、Workers のバインディング、REST API、そしてインスタンスごとに用意される MCP サーバーなどがあります。バインディングの書き方は 2026年に新しい形（ai_search_namespaces）に移っているので、公式の Workers binding のページで最新の書き方を確かめてください。

Vectorize で組むか、AI Search に任せるか

両方あると、どちらを使えばよいか迷います。目安は次のとおりです。

まず AI Search で試してみるのがおすすめです。社内文書に答えるボットのような用途なら、数分で動くものができます。

そのうえで、「文書の分け方を細かく決めたい」「D1 の商品データと組み合わせて絞り込みたい」「文章ではなく、画像や商品の特徴で似たものを探したい」といった要望が出てきたら、Vectorize で自分で組みます。Vectorize は RAG 専用ではなく、似ているものを探すための汎用の部品です。

料金と制限：「次元の数」で数える

2026年9月時点の料金と主な上限の骨格です。

「次元の数」は、ベクトルの数 × 次元数です。たとえば 1024 次元のベクトルを 4,800 件入れると、約 490万次元になり、保存の無料枠にほぼ届きます。小さなモデル（次元数の少ないモデル）を選ぶと、同じ件数でも数える量が減ります。

検索のほうは、1回の検索で「インデックスにある件数 × 次元数」に近い量を数える形です。件数が多いインデックスを頻繁に検索するなら、見積もりを公式の料金ページの例で確かめておきましょう。

AI Search は、課金が始まる前に通知すると案内されています。本番で使う前に、公式の Limits & pricing を必ず確認してください。

よくある落とし穴

Vectorize と RAG でつまずきやすい点をまとめます。

とくに「分け方」は、RAG の答えの質を大きく左右します。短すぎると文脈が消え、長すぎると関係ない話が混ざります。AI Search に任せると、この部分も既定の方法でやってくれます。

他の機能とのつながり

RAG は、いくつもの機能の組み合わせです。

図の左に並んだ5段の手順のうち、①と④⑤は Workers AI、②は Vectorize、③は D1 や R2 が受け持ちます。AI Search は、この5段をまとめて1つにしたものだと考えると分かりやすいでしょう。