Cloudflare AI Searchで社内文書検索を作る｜取り込みから回答の確認まで

Cloudflare AI Searchを使うと、文書を取り込んで検索し、その検索結果をもとに回答する仕組みを作れます。 ただし、文書を入れただけで回答の正確さや既存システムの閲覧権限が自動的に保証されるわけではありません。公式：AI Search

この記事では、機密情報を含まないサンプル文書から始め、社内利用へ進めるための確認手順を説明します。全社員が同じ文書を読める小規模な検証を想定し、部署ごとの機密文書や顧客別データを混在させる構成は、権限設計を追加してから扱います。

最初に「検索」と「回答」を分けて確かめる

RAGは、関連する文書を検索し、その内容を参照して回答を生成する構成です。検索対象に答えがない、古い資料が優先される、根拠と違う文章を生成するなど、失敗する箇所は複数あります。

段階	確認すること
取り込み	必要な文書が読み込まれ、検索対象になったか
検索	質問に対応する文書の該当部分が返るか
回答生成	根拠の範囲内で答え、不明なことを断定しないか
表示	出典や更新日を利用者が確認できるか
権限	質問者が読める文書だけを検索しているか

先に検索結果だけを見て、正しい根拠が取得されてから回答を評価します。根拠の取り違えを、回答の口調を直すだけで解決しようとすると原因が見えにくくなります。

同じ閲覧範囲のサンプル文書を3つ用意する

最初から共有ドライブ全体を投入せず、役割の異なる資料を少数用意します。たとえば、架空の会社向けに次の3文書を作ります。

サンプル	入れる情報	確認用の質問
備品の貸出手順	申請先、必要な項目、返却方法	モニターを借りるには何を申請する？
会議室の利用ルール	予約方法、取消、設備の扱い	予約を取り消す場合の手順は？
新しい社員向けの案内	初日の連絡先、端末の受け取り	初日に端末を受け取る場所は？

各文書には、タイトル、更新日、管理担当、原本を識別するIDを付けます。同じ規則の旧版と新版を両方入れる場合は、どちらが有効なのかを明確にしてください。

ここで挙げた文書や質問は検証用の例です。実在する社員情報や顧客資料を、そのまま公開のデモへ投入することを想定していません。

インスタンスを作り、取り込み完了後にPlaygroundで確認する

2026年10月22日に確認した公式手順では、ダッシュボードからAI Searchのインスタンスを作成し、内蔵ストレージへ文書をアップロードして試せます。R2やWebサイトなどのデータソースを使う構成もあります。公式：ダッシュボードで始める

1. AI Searchでインスタンスを作り、用途が分かる名前を付ける。
2. 検証の対象となるデータソースと設定を確認する。
3. Itemsからサンプル文書をアップロードする。
4. 文書の取り込みと索引作成の状態を確認する。
5. PlaygroundのSearchで、質問と検索結果を比べる。
6. 根拠が正しく取得できたら、Chatで回答を確認する。

アップロード完了と、検索可能になったことは分けて確認します。失敗した文書がある場合は、ファイル形式やサイズなどの制限、処理結果を確認してください。公式：制限と料金

Webサイトを取り込む場合は、対象URLの範囲、取得できるページ、更新・削除時の反映も調べます。ログインが必要な社内サイトの閲覧権限が、取得後の検索結果へそのまま引き継がれるとは考えません。

Workersから呼ぶ場合は、現在のバインディングを確認する

現行ドキュメントでは、AI Searchの名前空間をWorkersへバインドし、対象インスタンスを指定する経路が案内されています。以前のAutoRAG向け記事と設定を混在させず、今のAPIを基準にします。公式：Workers binding

次はWrangler設定に追加する部分の例です。設定ファイル全体ではありません。remote: true は、ローカル開発時にも実際のリモートリソースを使う設定なので、検証データと利用量を管理します。

{
  "ai_search_namespaces": [
    {
      "binding": "AI_SEARCH",
      "namespace": "default",
      "remote": true
    }
  ]
}

次の関数は、呼び出し前に利用者の認証と閲覧権限を確認することを前提にしたサーバー側の検索部分です。HTTPエンドポイント全体の実装ではなく、認証のない公開URLへ直接つなぐための例でもありません。

async function searchHandbook(env, query) {
  if (typeof query !== "string" ||
      query.trim().length === 0 || query.length > 1000) {
    throw new Error("検索語を1〜1000文字で入力してください");
  }
  const instance = env.AI_SEARCH.get("staff-handbook-pilot");
  const results = await instance.search({
    messages: [{ role: "user", content: query.trim() }],
    ai_search_options: {
      retrieval: { max_num_results: 3 }
    }
  });
  return results.chunks;
}

インスタンス名は、作成した検証用の名前へ置き換えます。この例は、許可された利用者全員が同じ文書を読める場合を想定しています。ブラウザーが送ったインスタンス名や部署名をそのまま信用して切り替える設計にはしません。

結果に含まれる文書の識別情報やテキストを、管理している原本情報と結び付けて表示します。文書の本文をHTMLとして無条件に描画せず、画面側でも安全に扱います。コードは公式APIをもとにした構成例で、利用者の環境での動作や回答精度を保証するものではありません。

社内文書は、公開エンドポイントと権限を先に確認する

AI Searchには公開エンドポイントの機能があります。公式資料では、公開エンドポイント自体は認証を要求しないため、非公開データを扱う場合の保護が必要とされています。CORSの許可元を限定するだけでは、アクセス制御になりません。 公式：公開エンドポイント

最初の社内検証では公開エンドポイントを有効にせず、認証済みアプリのサーバーから呼び出す構成にすると、入口の確認範囲を絞れます。公開エンドポイントを使用する必要がある場合は、Cloudflare Accessなどで保護し、許可されない利用者が直接呼べないことまで確認します。

部署や顧客ごとに資料を分ける場合は、インスタンスの分離やメタデータによる検索範囲の制限を設計します。フィルターは検索前に対象を絞る仕組みですが、その条件を誰が決めるかが重要です。公式：メタデータフィルター

設計項目	確認する内容
利用者の識別	サーバーで検証したログイン情報を使う
検索対象	権限に対応するインスタンスや条件をサーバーで選ぶ
原本文書	元の共有範囲と検索対象の共有範囲を照合する
ログと履歴	質問・回答・引用に機密情報が残る範囲を確認する
退職・異動	権限を失った利用者のアクセスを止める

回答を作ってから機密部分を隠すのではなく、検索へ渡す段階で閲覧可能な文書に限定します。テナント別の分離を行う場合は、公式の構成例と自社の要件を照合してください。公式：テナント別検索

料金は2026年11月からの課金条件も確認する

2026年10月22日に確認した公式資料には、AI Searchの課金開始日が2026年11月1日と記載されています。以前の無料ベータの説明を、そのまま長期運用の予算に使わないようにします。公式：制限と料金

見積もりでは、文書の取り込み量、保存量、検索方式ごとの回数、回答生成などに使うモデルを分けます。文書の更新や再取り込み、想定外に増えた検索も計算対象です。

回答生成や質問の書き換えなどで利用するモデルの料金は、AI Search本体と別に発生する場合があります。一方、内蔵の埋め込み・再ランキングの処理を、別のWorkers AIやVectorizeの料金として重ねて計上しないよう、利用経路を確認します。R2やアプリ用Workersを使う場合は、それらも含めて集計します。

最初の検証では、文書数・更新頻度・検索回数・回答生成回数を記録します。品質を確認する前に大量の文書を繰り返し取り込む運用は避け、小さく試してから対象を広げます。

回答の確認表を作り、更新と権限まで試す

20問程度の確認用の質問を用意し、期待する根拠と実際の検索・回答を別々に記録すると、改善箇所が分かります。以下は評価項目の例で、実測結果ではありません。

質問の種類	合格とする状態
文書に答えがある	正しい文書の該当部分を参照して答える
言い換えた質問	用語が違っても必要な根拠を取得できる
文書に答えがない	根拠のない規則や担当者を作り出さない
旧版と新版がある	有効な版を優先し、更新日を確認できる
文書を削除・更新した	索引の反映後に古い内容を返さない
権限のない文書を尋ねる	本文や存在を含め、許可外の情報を漏らさない

回答の言い回しだけで採点せず、原本との一致、出典、更新日も見ます。文書中に「以前の指示を無視して」といった命令が含まれるケースも用意し、資料の文章をアプリへの操作指示として扱わないことを確認します。

よくある質問

PDFを入れれば、どんな内容でも正確に回答できますか？

保証はされません。対応形式であっても、図表、画像中心のページ、複雑な段組みなどは取り込み結果を確認する必要があります。原文と検索結果を照合してから、回答を評価します。

社内の全資料を1つのインスタンスへ入れてよいですか？

全員の閲覧範囲が同じかを先に確認します。権限が異なる資料を混在させるなら、検索前の制御と権限の更新方法が必要です。最初は同じ共有範囲の文書から始めると確認しやすくなります。

正しい回答が1回出たら、社内公開してよいですか？

複数の質問、更新・削除、回答不能な質問、権限外の質問を確認してから判断します。公開後も、誤回答の報告先と文書の管理担当を決めておきます。

次に読む記事

• R2の保存量・操作回数から費用を試算する
• Workersの料金と無料枠を確認する
• Cloudflare TunnelとAccessで社内アプリへの接続を整える

※仕様・料金と公式資料の確認日：2026年10月22日。導入時には最新の対応形式、料金、API仕様を確認してください。