Michael JohnsonCloudflare D1にコンテンツを保存しているチームは、別途データを書き出さなくても、選択したレコードをAI Searchに渡せるようになりました。2026年11月12日、Cloudflareはサービスのベータ版でD1をデータソースとして追加しました。開発者が読み取り専用クエリを指定すると、AI Searchは返された各行をドキュメントに変換し、スケジュールに沿ってインデックスを更新します。
何が変わったのか
これまでAI Searchが対応していたデータソースには、R2オブジェクトやウェブコンテンツなどがありました。今回からD1もテーブルのデータを直接インデックスに渡せるようになりました。たとえば、公開済みの記事、商品カタログ、ナレッジベースのレコードなどが対象です。Cloudflareはこの機能を11月12日付の変更履歴で説明しており、管理画面、REST API、Workers bindingからD1をデータソースにしたインスタンスを作成できます。
データベースの所有者はSQLクエリで、どのレコードをインデックスに含めるか、どのフィールドをドキュメントのタイトル、本文、メタデータにするかを指定します。記事データベースの場合、たとえば公開済みのコンテンツだけを選び、列にid、title、content、meta_categoryの役割を割り当てられます。このように、開発者が指定したクエリ結果から検索用のデータが作られます。
接続の仕組み
D1をデータソースに設定すると、AI Searchは指定されたクエリを実行し、行を1件ずつインデックス化して、スケジュールに沿ってインデックスを同期します。REST APIとWorkers bindingを使うには、同じCloudflareアカウント内のD1データベースID、サービスのトークンID、そしてid列を返すクエリが必要です。管理画面ではデータベースを選択してクエリを作成し、インスタンスを作る前に1行分の結果を確認できます。手順はD1データソースのドキュメントに記載されています。
列名によって用途が決まります。titleはドキュメントのタイトル、contentは本文になり、meta_で始まる列はメタデータとして保存されます。その他の列は、ドキュメントテンプレートに応じてラベル付きフィールドとして表示できます。これにより、SQLで検索に必要なカテゴリやフィールドを選択できます。
サービスが受け付けるクエリ
クエリはSELECTまたはWITHで始まる単一の読み取り文でなければなりません。また、空でない結果を返し、idの値は空ではなく一意である必要があります。上限は10万行、クエリの長さは1万文字です。ドキュメントでは、バインドパラメーター、コメント、書き込み操作や管理コマンドを含む複数のSQL構文も禁止されています。ORDER BYやLIMITは使用できません。AI Searchは結果をid順に並べてページ単位で読み取るためです。
行のidが変わると、AI Searchは以前のドキュメントを削除し、新しいドキュメントを作成します。そのため、同期には安定した識別子を選ぶ必要があります。結果に含まれる各列名も一意でなければならず、必要に応じてASで指定できます。同期ではクエリ結果全体を読み取るため、D1の読み取り使用量に計上されます。WHERE条件を使えば、インデックス対象を絞り込めます。
どのようなチームに役立つか
この連携は、構造化コンテンツをすでにD1に保存しているチームに適しています。データベースへのクエリで検索対象のレコードを選び、行の追加、変更、削除に応じてインデックスを同期できます。たとえば、商品カタログでは販売可能な商品だけを、ヘルプセンターでは公開済みの記事とそのカテゴリだけを含められます。各行が個別のドキュメントになります。
この連携はまだベータ版です。運用を始める前に、idの一意性と安定性を確認し、必要な列だけを選び、結果の規模と同期スケジュールがD1の使用量にどう影響するかを見積もるとよいでしょう。インデックスは選択した間隔で更新され、同期のたびに結果全体を読み取るため、D1の読み取り回数が増えます。
今回の変更により、D1をAI Searchのデータソースとして利用できるようになり、SQLクエリでデータベースのどの行を検索ドキュメントにするか指定できます。D1にコンテンツを保存しているチームにとって、データとインデックスを直接つなぐ手段となります。導入を計画する際は、行数の上限と同期時のデータベース読み取り量に注意が必要です。
