AI検索：あなたのエージェントのための検索プリミティブ

すべてのエージェントに検索機能が必要です：コーディングエージェントはリポジトリ全体にある数百万のファイルを検索します。サポートエージェントは顧客チケットや社内ドキュメントを検索します。さらに、エージェントのメモリ、つまり過去のやり取りを想起する能力でさえ、根本的には検索問題です。ユースケースは異なりますが、根本的な問題は同じです：適切なタイミングでモデルに正しい情報を提供すること。 検索機能を自分で構築する場合、ベクトルインデックス（vector index）、ドキュメントを解析してチャンク化するインデックス作成パイプライン（indexing pipeline）、データ変更時にインデックスを更新する仕組みが必要です。キーワード検索（keyword search）も必要な場合、それには別のインデックスと上位の融合ロジック（fusion logic）が必要です。さらに、各エージェントが独自の検索可能なコンテキストを必要とする場合、それらすべてをエージェントごとに設定することになります。 AI Search（旧名：AutoRAG）は、必要なプラグアンドプレイの検索プリミティブ（plug-and-play search primitive）です。動的にインスタンスを作成し、データを与えて検索できます——Worker、Agents SDK、またはWrangler CLIから。以下が今回提供する機能です： ハイブリッド検索（Hybrid search）。1つのクエリでセマンティックマッチング（semantic matching）とキーワードマッチングの両方を有効にします。ベクトル検索（Vector search）とBM25が並列で実行され、結果が融合されます。（当ブログの検索機能は現在AI Searchによって駆動されています。右上の虫眼鏡アイコンをクリックしてお試しください。） 内蔵ストレージとインデックス（Built-in storage and index）。新しいインスタンスには、独自のストレージとベクトルインデックス（vector index）が付属します。APIを介してファイルを直接インスタンスにアップロードすると、自動的にインデックスが作成されます。設定するR2バケット（R2 bucket）も、最初に接続する外部データソースも不要です。新しいai_search_namespacesバインディング（ai_search_namespaces binding）により、Workerから実行時にインスタンスの作成と削除が可能になり、再デプロイすることなく、エージェントごと、顧客ごと、または言語ごとにインスタンスを立ち上げることができます。 また、ドキュメントにメタデータ（metadata）を付与してクエリ時にランキングをブーストしたり、1回の呼び出しで複数のインスタンスにまたがってクエリを実行することもできるようになりました。 それでは、これが実際にどのような意味を持つのか見ていきましょう。 実例：カスタマーサポートエージェント 共有製品ドキュメントと、過去の解決策のような顧客ごとの履歴という2種類の知識を検索するサポートエージェントの動作を追ってみましょう。製品ドキュメントはコンテキストウィンドウ（context window）に収まりきらず、各顧客の履歴は解決された問題ごとに成長するため、エージェントは関連する情報を取得するために検索機能が必要です。 AI SearchとAgents SDKを使用した場合、以下のような構成になります。まずプロジェクトのスケルトンを作成しましょう： npm create cloudflare@latest -- --template cloudflare/agents-starter まず、AI SearchのネームスペースをWorkerにバインドします： // wrangler.jsonc { "ai_search_namespaces": [ { "binding": "SUPPORT_KB", "namespace": "support" } ], "ai": { "binding": "AI" }, "durable_objects": { "bindings": [ { "name": "SupportAgent", "class_name": "SupportAgent" } ] } } 共有製品ドキュメントがproduct-docという名前のR2バケット（R2 bucket）に格納されていると仮定します。Cloudflareダッシュボード（Cloudflare Dashboard）のサポートネームスペース内で、そのバケットをバックエンドとする一時的なAI Searchインスタンス（product-knowledgeという名前）を作成できます： ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1b8NdFL2HDBy8FqBHEI679/f17ed98d45fb9b42a616e0b464460489/BLOG-3240_2.png) これが共有ナレッジベース（shared knowledge base）です。すべてのエージェントが参照できるドキュメントとなります。 顧客が新しい問題を報告してきた際、すでに試された対策を知っているだけで、関係者の時間を大幅に節約できます。これを追跡するには、顧客ごとにAI Searchインスタンスを作成します。問題が解決するたびに、エージェントはエラーの原因と修正方法を要約して保存します。時間が経つにつれて、過去の解決策を検索可能なログとして蓄積していくことができます。名前空間バインディング（namespace binding）を使用してインスタンスを動的に作成できます： // 顧客が最初にアクセスした際に、顧客ごとのインスタンスを作成する await env.SUPPORT_KB.create({ id: `customer-${customerId}`, index_method:{ keyword: true, vector: true } }); 各インスタンスには、R2とVectorizeによって駆動する組み込みストレージ（storage）とベクトルインデックス（vector index）が自動的に割り当てられます。インスタンスは空の状態から始まり、時間とともにコンテキスト（context）を蓄積していきます。次回顧客がアクセスした際には、すべてのデータが検索可能になります。 数名の顧客が追加された後の名前空間（namespace）は以下のようになります： namespace: "support" ├── product-knowledge (R2をソースとして使用し、すべてのエージェントで共有) ├── customer-abc123 (管理対象ストレージ、顧客ごと) ├── customer-def456 (管理対象ストレージ、顧客ごと) └── customer-ghi789 (管理対象ストレージ、顧客ごと) 次にエージェント本体です。これはAgents SDKのAIChatAgentを拡張し、2つのツールを定義しています。Workers AI経由でKimi K2.5を大規模言語モデル（LLM）として使用しています。モデルは会話内容に基づき、ツールを呼び出すタイミングを判断します： import { AIChatAgent, type OnChatMessageOptions } from "@cloudflare/ai-chat"; import { createWorkersAI } from "workers-ai-provider"; import { streamText, convertToModelMessages, tool, stepCountIs } from "ai"; import { routeAgentRequest } from "agents"; import { z } from "zod"; export class SupportAgent extends AIChatAgent { async onChatMessage(_onFinish: unknown, options?: OnChatMessageOptions) { // クライアントはリクエストボディ経由でcustomerIdを渡します // （Agent SDKのsendMessage({ body: { customerId } })を使用） const customerId = options?.body?.customerId; // 顧客が最初にアクセスした際に、顧客ごとのインスタンスを作成する。 // 各インスタンスには独自のストレージとベクトルインデックスが割り当てられる。 if (customerId) { try { await this.env.SUPPORT_KB.create({ id: `customer-${customerId}`, index_method: { keyword: true, vector: true } }); } catch { // インスタンスは既に存在する } } const workersai = createWorkersAI({ binding: this.env.AI }); ```javascript const result = streamText({ model: workersai("@cf/moonshotai/kimi-k2.5"), system: `サポートエージェントとして振る舞ってください。回答する前にsearch_knowledge_baseを使用して 関連するドキュメントを検索してください。検索結果には、 製品ドキュメントとこの顧客の過去の 解決策が含まれます。失敗した修正の繰り返しを避け、 問題の再発を認識するためにこれらを使用してください。問題が 解決された場合、回答する前にsave_resolutionを呼び出してください。`, // this.messagesは会話履歴全体であり、自動的に // AIChatAgentによって再接続時にも永続化されます messages: await convertToModelMessages(this.messages), tools: { // ツール1：共有製品ドキュメントとこの // 顧客の過去の解決策を単一の呼び出しで横断的に検索 search_knowledge_base: tool({ description: "製品ドキュメントと顧客履歴を検索", inputSchema: z.object({ query: z.string().describe("検索クエリ"), }), execute: async ({ query }) => { // 常に製品ドキュメントを検索し、 // 利用可能な場合は顧客履歴も含めます const instances = ["product-knowledge"]; if (customerId) { instances.push(`customer-${customerId}`); } return await this.env.SUPPORT_KB.search({ query: query, ai_search_options: { // 古いドキュメントより新しいドキュメントを優先 boost_by: [ { field: "timestamp", direction: "desc" } ], // 両方のインスタンスを同時に検索 instance_ids: instances } }); } }), // ツール2：問題を解決した後、エージェントは保存を行います // 将来のエージェントが完全なコンテキストを持てるように save_resolution: tool({ description: "顧客の問題を解決した後に解決策の概要を保存", inputSchema: z.object({ filename: z.string().describe( "短い説明的なファイル名、例：'billing-fix.md'" ), content: z.string().describe( "問題の内容、原因、および解決方法" ), }), execute: async ({ filename, content }) => { if (!customerId) return { error: "No customer ID" }; const instance = this.env.SUPPORT_KB.get( `customer-${customerId}`); // uploadAndPollはインデックス作成が完了するまで待機し、 // 次のクエリ前に解決策が検索可能になります const item = await instance.items.uploadAndPoll( filename, content); return { saved: true, filename, status: item.status }; } }), }, // エージェントのツール使用ループ（agentic tool-use loops）を10ステップで制限 stopWhen: stepCountIs(10), abortSignal: options?.abortSignal, }); ``` return result.toUIMessageStreamResponse(); } } // route requests to the SupportAgent durable object export default { async fetch(request: Request, env: Env) { return ( (await routeAgentRequest(request, env)) || new Response("Not found", { status: 404 }) ); } } satisfies ExportedHandler; これにより、モデルは検索すべき時と保存すべき時の判断を行います。検索時には、製品ナレッジとこの顧客の過去の解決策を合わせてクエリします。問題が解決されると、将来の会話ですぐに検索可能なサマリーを保存します。 How AI Search finds what you're looking for 内部では、AI Search がマルチステップの検索パイプラインを実行しており、各ステップはすべて設定可能です。 Hybrid Search: search that understands intent and matches terms これまで AI Search はベクトル検索（vector search）のみを提供していました。ベクトル検索は意図の理解に優れていますが、詳細な情報が抜け落ちる場合があります。「ERR_CONNECTION_REFUSED timeout」というクエリの場合、エンベッディング（embedding）は接続障害という広い概念を捉えます。しかしユーザーは一般的なネットワークドキュメントを探しているのではなく、「ERR_CONNECTION_REFUSED」に言及している特定の文書を探しています。ベクトル検索はトラブルシューティングに関する結果を返すかもしれませんが、その正確なエラー文字列を含むページが上位に表示されないこともあります。 このギャップを埋めるのがキーワード検索（keyword search）です。AI Search は現在、最も広く使用されている検索スコアリング関数の一つである BM25 をサポートしています。BM25 は、クエリ用語が文書内でどの程度出現するか、その用語がコーパス全体でどれだけレアか、そして文書の長さを基にスコアを計算します。特定の用語への一致にはボーナスを付与し、一般的なフィラーワードにはペナルティを科し、文書の長さで正規化します。「ERR_CONNECTION_REFUSED timeout」を検索すると、BM25 は実際に「ERR_CONNECTION_REFUSED」という用語を含む文書を見つけます。ただし、BM25 は同じ問題を説明している可能性が高い「troubleshooting network connections」に関するページを見逃すことがあります。ここでベクトル検索が真価を発揮し、両方が必要な理由となります。 ハイブリッド検索（hybrid search）を有効にすると、ベクトル検索と BM25 が並列で実行され、結果が融合され、オプションとして再ランク付けされます： ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/27CV8IBS2dYTV5puCtIPmD/3c66c190127fa38c4a4275425de8f9c4/BLOG-3240_3.png) BM25 の新しい設定と、それらがどのように連携するかを見ていきましょう。 トークナイザー（Tokenizer）は、インデックス作成時に文書がどのようマッチング可能な用語に分割されるかを制御します。ポーターステム法（Porter stemmer）（オプション: porter）は単語を語幹に分解するため、「running」が「run」と一致します。トリグラム（Trigram）（オプション: trigram）は文字列のサブストリングに一致するため、「conf」が「configuration」と一致します。ドキュメントのような自然言語コンテンツには porter を、部分一致が重要となるコードには trigram を使用できます。 キーワードマッチモード（Keyword match mode）は、クエリ実行時に BM25 のスコアリング対象となる文書を制御します。AND は文書内にすべてのクエリ用語の出現を要求し、OR は少なくとも 1 つの一致を含むものをすべて含みます。 検索クエリ実行時、ベクトル結果とキーワード結果が最終的な結果リストにどのように結合されるかを制御します。逆順順位融合（Reciprocal Rank Fusion、オプション: rrf）はスコアではなく順位位置で結合するため、互換性のない2つのスコアリング尺度を比較するのを防ぎます。一方、最大融合（Max Fusion、オプション: max）はより高いスコアを採用します。 （オプション）再ランク付け（Reranking）は、クエリとドキュメントをペアとして評価して結果に再スコアリングを行うクロスエンコーダー処理（cross-encoder pass）を追加します。これにより、適切な用語は持っているものの質問に答えていない結果を捕捉するのに役立ちます。 各オプションには省略時の合理的なデフォルト値が設定されています。新しいインスタンスを作成する際、必要な項目を柔軟に構成できます： ```javascript const instance = await env.AI_SEARCH.create({ id: "my-instance", index_method: { keyword: true, vector: true }, indexing_options: { keyword_tokenizer: "porter" }, retrieval_options: { keyword_match_mode: "or" }, fusion_method: "rrf", reranking: true, reranking_model: "@cf/baai/bge-reranker-base" }); ``` Boost relevance: surface what matters 検索結果の関連性を高め、重要な情報を前面に出します 検索（Retrieval）は関連する結果を返しますが、関連性だけでは常に十分ではありません。例えばニュース検索において、先週の記事と3年前の記事がともに「選挙結果」というキーワードに対して意味的に関連していても、多くのユーザーはおそらく最新の記事を求めています。ブースティング（Boosting）により、ドキュメントのメタデータに基づいてランキングを調整することで、検索の上にビジネスロジックを層状に重ねることができます。 あなたはタイムスタンプ（すべての項目に組み込み済み）または定義した任意のカスタムメタデータフィールドに基づいてブーストを適用できます。 ```javascript // boost high priority docs const results = await instance.search({ query: "deployment guide", ai_search_options: { boost_by: [ { field: "timestamp", direction: "desc" } ] } }); ``` Cross-instance search: query across boundaries 境界を越えた検索：インスタンス間でのクエリ サポートエージェントの例では、製品ドキュメントと顧客解決履歴は設計上、別々のインスタンスに格納されています。しかし、エージェントが質問に回答する際には、両方の場所からのコンテキストを同時に必要とします。クロスインスタンス検索（Cross-instance search）がない場合、2つの別々の呼び出しを行い、結果を自分でマージする必要があります。 namespaceバインディング（namespace binding）は、この処理を行う `search()` メソッドを公開しています。インスタンス名の配列を渡すと、1つのランク付けされたリストが返されます： ```javascript const results = await env.SUPPORT_KB.search({ query: "billing error", ai_search_options: { instance_ids: ["product-knowledge", "customer-abc123"] } }); ``` 結果はインスタンス間でマージされ、ランク付けされます。エージェントは、共有ドキュメントと顧客解決履歴が別々の場所に格納されていることを知る必要も気にする必要もありません。 How AI Search instances work これまでAI Searchが適切な結果をどのように見つけるかについて解説しました。次に、検索インスタンスの作成と管理方法を紹介します。 このリリース以前にAI Searchを利用したことがある方なら、セットアップの流れをご存知でしょう：R2バケット（R2 bucket）を作成し、AI Searchインスタンスにリンクします。AI SearchがサービスAPIトークン（service API token）を生成してくれるので、アカウント上にプロビジョニングされたVectorizeインデックス（Vectorize index）をあなたが管理します。オブジェクトのアップロードには、R2への書き込みと、同期ジョブ（sync job）が実行されてそのオブジェクトがインデックスされるまでの待機が必要です。 現在作成される新しいインスタンスは動作が異なります。`create()`を呼び出すと、インスタンスにはストレージとベクトルインデックス（vector index）が組み込まれた状態で提供されます。ファイルをアップロードすると、そのファイルは即座にインデックス処理へ送信され、`uploadAndPoll()` API 1つでアップロードとインデックス状態のポーリング（polling）が可能です。完了後、インスタンスに対して即座に検索を実行でき、外部依存関係を別途接続する必要はありません。 ```js const instance = env.AI_SEARCH.get("my-instance"); // インデックス処理の完了を待ってアップロード const item = await instance.items.uploadAndPoll("faq.md", content, { metadata: { category: "onboarding" } }); console.log(item.status); // "完了" // インデックス処理完了後、即座に検索 const results = await instance.search({ // パラメータ query を使用する以外の、ユーザーのクエリを渡す代替方法 messages: [{ role: "user", content: "onboarding guide" }], }); ``` 各インスタンスは、1つの外部データソース（external data source）（R2バケットまたはウェブサイト）に接続し、同期スケジュール（sync schedule）で実行することもできます。これは提供された組み込みストレージ（built-in storage）と併存させることができます。サポートエージェントの例では、製品知識は共有ドキュメント用のR2バケットによってバックアップされていますが、各顧客のインスタンスはオンザフライ（on the fly）でアップロードされたコンテキストのために組み込みストレージを使用します。 `## Namespaces: 実行時（runtime）に検索インスタンスを作成する` `ai_search_namespaces`は、実行時（runtime）に検索インスタンスを動的に作成するために活用できる新しいバインディング（binding）です。これは、AIバインディングを通じてAI Searchにアクセスしていた以前の`env.AI.autorag()` APIを置き換えるものです。従来のバインディングは、Workers互換性日付（Workers compatibility dates）を使用して引き続き動作します。 ```jsonc // wrangler.jsonc { "ai_search_namespaces": [ { "binding": "AI_SEARCH", "namespace": "example" }, ] } ``` このnamespaceバインディング（binding）は、ネームスペースレベル（namespace level）で`create()`、`delete()`、`list()`、`search()`などのAPIを提供します。インスタンスを動的に作成する場合（例：エージェントごと、顧客ごと、テナントごと）、これを使用するバインディングとなります。 ```js // インスタンスの作成 const instance = await env.AI_SEARCH.create({ id: "my-instance" }); // インスタンスおよびすべてのインデックスデータを削除 await env.AI_SEARCH.delete("old-instance"); ``` `## Pricing: 新しいインスタンスの料金` 今日以降に作成される新しいインスタンスには、組み込みストレージ（built-in storage）とベクトルインデックス（vector index）が自動的に付与されます。 これらのインスタンスは、AI検索（AI Search）が以下の制限を設けて公開ベータ版を提供している間、無料でご利用いただけます。ウェブサイトを経済データソースとして使用する際、ブラウザ実行（Browser Run、旧：Browser Rendering）を使用したWebサイトクロールも組み込みサービスとなったため、別途請求されることはありません。ベータ終了後は、各基盤コンポーネントごとに個別に課金するのではなく、AI検索（AI Search）を単一サービスとして統一された価格で提供することを目指しています。ワーカーAI（Workers AI）およびAIゲートウェイ（AI Gateway）の使用料は引き続き個別に課金されます。 課金開始前に少なくとも30日前にお知らせし、価格の詳細をお伝えします。 制限\nWorkers Free\nWorkers Paid\nアカウントあたりのAI検索（AI Search）インスタンス数\n100\n5,000\nインスタンスあたりのファイル数\n100,000\n1Mまたはハイブリッド検索の場合500K\n最大ファイルサイズ\n4MB\n4MB\n月間クエリ数\n20,000\n無制限\n1日あたりのクロール最大ページ数\n500\n無制限 既存のインスタンスはどうなりますか？ このリリース以前にインスタンスを作成された場合、それらは今日と同じように引き続き動作します。R2バケット（R2 buckets）、ベクトルインデックス（Vectorize indexes）、ブラウザ実行（Browser Run）の使用量はアカウントに残り、従来通り課金されます。既存のインスタンスのマイグレーション詳細については近日中にお知らせします。 \n 今すぐ始める\n \n \n \n 検索はエージェントが行う最も基本的な機能の一つです。AI検索（AI Search）を利用すれば、そのためのインフラを構築する必要はありません。インスタンスを作成し、データを渡すだけで、エージェントが検索を実行してくれます。 以下のコマンドを実行して最初のインスタンスを作成し、今すぐ始めましょう： \nnpx wrangler ai-search create my-search\n \nn ドキュメントをチェックし、Cloudflare Developer Discordであなたが構築しているものを教えてください。\n \n ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5Y5WLWBuK7NBMLmY6ZWL96/ce7ca954f4f51ac21f8e9d3f15d0343c/BLOG-3240_4.png)

AI検索：あなたのエージェントのための検索プリミティブ

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

調べる

選ぶ

サイト