Nullstead

Cloudflare

Cloudflare AI Search実践ガイド（2026年4月版）：ai_search_namespacesで「1エージェント1検索基盤」を現実的に回す方法

2026年4月のCloudflare AI Search更新（内蔵ストレージ、namespace binding、横断検索）を踏まえ、個人開発で壊れにくいRAG基盤を設計・実装・運用する具体策を、コード付きで整理します。

約10分

AIエージェントを作っていると、だいたい3日目くらいで「モデルより検索のほうが難しいのでは？」という真実に気づきます。私も何度か、モデル選定より検索設計で夜更かししました。コーヒーの消費量は増えるのに、検索精度はなぜか増えない。これは個人開発あるあるです。

そんな中で、2026年4月のCloudflare AI Searchアップデートは、個人開発者にとってかなり実用的でした。特に ai_search_namespaces バインディングと、インスタンスの内蔵ストレージ／内蔵ベクタインデックス対応は「RAG基盤づくりの初期工事」を大きく減らしてくれます。

本記事では、今回のアップデート内容を前提に、個人開発で壊れにくく・育てやすい検索基盤を作る設計と実装をまとめます。敬体で書きますが、ところどころで正気を保つための冗談が入ります。ご了承ください（仕様です）。

1. 2026年4月アップデートの何が効くのか

まず重要なのは、AI Searchの新規インスタンス（2026-04-16以降）が次の前提で動くようになった点です。

  • インスタンスに内蔵ストレージが付く
  • 内蔵ベクタインデックスが付く
  • Webクローリングも使える
  • ai_search_namespaces でランタイムにインスタンスを作成／管理できる
  • 複数インスタンスをまたいだ検索（namespace-level search）ができる

以前の「まずR2を用意して、次にVectorizeを作って、設定して、同期して…」という段取りが、かなり短縮されます。もちろん高度な要件では個別の設計が必要ですが、最初の立ち上げ速度は体感で大きく変わります。

さらに、Cloudflare公式ブログでも、AI Search（旧AutoRAG）を「エージェントの検索プリミティブ」として明確に位置づけています。つまり、検索は毎回ゼロから作る部品ではなく、エージェント設計の標準レイヤーとして扱う流れです。

※RAG（Retrieval-Augmented Generation）: 生成AIに外部知識検索を組み合わせる手法です。 ※プリミティブ: アプリ全体の基本部品として繰り返し使える最小単位のことです。

2. env.AI.autorag()時代からの設計変更ポイント

今回の実務上の分岐点は、旧 env.AI.autorag() から ai_search_namespaces へ寄ることです。

移行で得られるメリットはシンプルです。

  1. デプロイなしでインスタンスを動的作成できる
  2. テナント単位・顧客単位・言語単位で分離しやすい
  3. 1回の検索で複数インスタンスを横断できる

個人開発でありがちな「最初は1データセットだったのに、途中で顧客ごとに分けたくなる問題」に対して、後追い改修がしやすくなります。

たとえばサポートBotなら、次のような構成が自然です。

  • product-knowledge（共通ドキュメント）
  • customer-xxx（顧客ごとの履歴）

検索時に instance_ids を渡して横断検索し、回答は共通知識＋顧客履歴で作る、という形です。これで「一般論としては正しいけど、この顧客には当てはまらない回答」を減らせます。

3. 最小実装：Wrangler設定とWorkerコード

まずはNamespace bindingを張ります。

// wrangler.jsonc
{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "compatibility_date": "2026-03-27",
  "ai_search_namespaces": [
    {
      "binding": "AI_SEARCH",
      "namespace": "support"
    }
  ]
}

次に、ランタイムでインスタンスを作って検索する最小コードです。

// 動作イメージ（本番投入前に検証してください）
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const customerId = "abc123";

    // 1) 顧客インスタンスを確保（存在済みなら例外を握りつぶす）
    try {
      await env.AI_SEARCH.create({
        id: `customer-${customerId}`,
        index_method: { keyword: true, vector: true }
      });
    } catch {
      // 既存想定
    }

    // 2) 複数インスタンス横断で検索
    const results = await env.AI_SEARCH.search({
      messages: [{ role: "user", content: "請求エラーの再発時の対処は？" }],
      ai_search_options: {
        instance_ids: ["product-knowledge", `customer-${customerId}`],
        retrieval: {
          retrieval_type: "hybrid",
          max_num_results: 8
        },
        boost_by: [{ field: "timestamp", direction: "desc" }]
      }
    });

    return Response.json(results);
  }
};

ここでの要点は、検索対象を設計で絞ることです。モデル性能で殴るより、対象集合を小さくしたほうが効く場面は多いです。筋トレで言うと「重量を増やす前にフォームを直す」やつです。地味ですが効きます。

4. 検索品質を上げる実務チューニング

AI Searchの検索は、vector / keyword / hybrid を切り替えできます。実務での第一選択は、ほぼ hybrid でよいと私は考えています。

理由は、問い合わせが次の2系統に割れるからです。

  • 意味ベースで探したい（例: 「接続不良っぽい障害」）
  • 文字列を正確に当てたい（例: ERR_CONNECTION_REFUSED）

ベクター検索だけだと後者が取りこぼれ、BM25※だけだと前者が弱くなります。ハイブリッドで両方拾い、必要なら再ランキングを使うのが安定です。

※BM25: キーワード検索の代表的なスコアリング手法。単語の出現頻度や文書全体での希少性を使って関連度を評価します。

実運用で触ることが多いパラメータは次です。

  • retrieval_type: hybrid を基本に
  • match_threshold: 低すぎるとノイズ増、高すぎると取りこぼし増
  • max_num_results: モデル入力コストと相談
  • keyword_match_mode: and / or の選択
  • fusion_method: rrf or max
  • boost_by: 新しい情報を優先する時に有効
  • filters: メタデータでテナントや期間を限定

このあたりは「最適値」を1発で決めるのではなく、失敗例をログに残して調整するのが結局速いです。AI開発は感覚派に見えて、最後は記録が勝ちます。家計簿と同じです。見たくない月もありますが。

5. コストと制限：無料枠の罠を先に潰す

AI Searchは、2026-04-16以降の新規インスタンスなら、オープンベータ期間中は範囲内で無料です。ただし、ここで誤解しやすい点があります。

  • AI Search本体は無料枠あり
  • ただし Workers AI / AI Gateway は別課金

「無料だと思っていたら推論側で課金」というのは、個人開発の請求書あるあるです。ここは最初からダッシュボードで分けて観測したほうが平和です。

無料プラン主要制限の例（記事執筆時点）:

  • インスタンス数: 100
  • インスタンスあたりファイル: 100,000
  • クエリ/月: 20,000
  • クロール/日: 500ページ
  • ファイルサイズ上限: 4MB

小さな検証には十分ですが、Botを公開して想定よりバズるとクエリ数が先に刺さる可能性があります。公開前に「1リクエストで何回検索を叩くか」を数えておくと、未来の自分が助かります。

6. マルチテナント設計の現実解

個人開発でも、次のどれかはだいたい来ます。

  • 顧客ごとにデータを分けたい
  • 言語ごとに検索精度を調整したい
  • 法務や契約でデータ分離要件が出る

このとき、namespace + instance_ids のモデルは扱いやすいです。

  • Namespace: プロダクト単位の大分類
  • Instance: 顧客／言語／用途単位の実体

さらに、Vectorizeのメタデータフィルタ設計の考え方（事前にmetadata indexを作る、文字列先頭64Bの制約など）を理解しておくと、AI Search側のフィルタ運用でも「なぜ効かないのか」を切り分けやすくなります。

ここを知らずに進むと「昨日まで動いていたフィルタが、なぜか精度に効いていない」というホラー回が始まります。深夜2時の障害調査でホラー演出は不要です。

7. 私ならこう運用する：小さく始めて壊れにくく育てる

最後に、私が個人開発で採るならこの順番です。

  1. まずは1 namespace + 1 共通インスタンスで開始
  2. 顧客数が増えたら customer-<id> を動的作成
  3. 失敗問い合わせを収集し、match_threshold と max_num_results を調整
  4. 精度課題が残る時だけ reranking / query rewrite を有効化
  5. 月次でクエリ数と推論コストを確認

つまり、「最初から全部盛りにしない」です。最初から全部盛ると、だいたい設定の意味を忘れます。私は忘れました。だから今こうして記事にしています（再発防止策）。

AI Search周辺は更新ペースが速いので、実装を固定化しすぎず、バインディングと設定を差し替えやすいコード構造にしておくのが安全です。2026年のエージェント開発は、モデルそのものより周辺アーキテクチャの更新追従力で差がつくと感じています。

参考リンク

Tags #Cloudflare #AI Search #RAG #Workers #個人開発 #自動化
← 記事一覧に戻る ページの先頭へ ↑