Cloudflare AI Search のテナント分離：境界をテストする

Cloudflare AI Search のテナント分離は、一つのアプリが非公開文書を持つ複数組織にサービスを提供した時点で重要になります。検索結果は回答生成前でも情報を漏らし、回答が無害に見えても引用が文書を公開する場合があります。権限境界は検索の全過程を覆う必要があります。

認証済みのアプリ上の本人情報からテナント範囲を決め、許可された検索インスタンスを選ぶか、サーバーが管理する必須フィルターを適用します。取り込み、検索、引用、キャッシュに同じアクセス設計を適用してください。組織切り替え、古いセッション、他組織の原本を直接開く試行を含む否定テストで分離を証明します。

販売会社が仕入先契約を登録できる SaaS を想像してください。各社は自社の納品や割引条件を説明するアシスタントを求め、全社共通の公開マニュアルもあるかもしれません。これらを組み合わせて有用になるのは、非公開資料が決めた境界を越えない場合だけです。

これはアプリ設計と受入方法の案です。名前空間やフィルターだけですべてのセキュリティ要件を満たすという主張ではありません。

Cloudflare AI Search のテナント分離は検索前に始まる

Cloudflare のマルチテナントガイド は、個別インスタンスと共有インスタンスの方式を説明しています。構成判断の前にアプリの識別モデルが必要です。テナントが何を表し、誰がその中で操作できるかを決めます。

検証したセッションなど、同等に信頼できる情報からテナントを取得します。要求引数は希望する選択を示せますが、選んでよいかはサーバーが確定します。正本となるテナント範囲をモデルに指定させてはいけません。

複数の販売会社に属する同僚には、現在の組織を明示します。組織切り替えでは許可資料と会話の文脈も変えます。切り替え前に得た非公開の段落が、次の回答に黙って残らないようにします。

インスタンスと強制フィルターを比較する

個別インスタンスならデータ境界を確認しやすい一方、作成やライフサイクルの仕事が増えます。共有ならその負担を減らせますが、すべての関連検索経路で正しい範囲を適用し、任意の迂回を許してはいけません。

Cloudflare の名前空間の文書 は、インスタンスの分類とバインディングによるアクセスを説明します。バインディングの範囲を慎重に確認します。論理的な分類だけで、呼び出し元が常に正しい先に届く証明にはなりません。

テナント数だけでなく、権限モデルと運用要件から選びます。組織内に制限付きチームがあるなら、配置がどうであっても組織全体の境界だけでは足りない場合があります。

問い合わせだけでなく取り込みにも範囲を適用する

内容が入る時点で文書の所有を確定します。信頼できるアプリのメタデータで、資料をテナントと公開範囲へ関連付けます。呼び出し元の権限を調べず、登録ファイルの自己申告を受け入れません。

更新を通じて資料識別子を安定させます。契約の置換は正しい組織の資料を更新し、削除は正しい原本と派生内容を対象にします。識別子の組織間衝突は、検索前から分離を壊すことがあります。

公開と非公開の取り込み判断を分けます。共有マニュアルは意図して公開できますが、仕入先契約を拡張子やフォルダー名が似ているという理由で同じ集合へ入れてはいけません。

どの取り込み用の主体が各資料の場所を読めるか記録します。結果を正しく絞っていても、広すぎる接続権限で、本来処理してはいけない資料を取り込むかもしれません。確認はパイプラインの両側を含めます。

フィルターを外せないアプリ方針にする

Cloudflare は検索フィルター を文書化しています。現在のアプリ権限を選ぶフィルター契約へ変換し、サーバーが実際に生成する要求をテストします。

一般クライアントが置き換えられる汎用フィルターを公開しないでください。範囲付き検索が空ならフィルターなしで試す、という便利な代替経路も加えません。権限外や不存在の情報では、結果なしが有効で必要な応答です。

文書型や言語などのユーザーの好みと、アプリの権限範囲を分けます。ユーザーは検索を狭められても、選択肢を変えて必須のアクセス条件を除去できてはいけません。

検索結果、生成回答、書き出し、エージェントツール、管理用プレビューなど、検索へ届く全経路を試します。同じ集合を無制限に検索するツールがあれば、安全な検索画面だけでは補えません。

引用、キャッシュ、会話履歴を守る

回答文に非公開の段落がなくても、別組織の情報を示す引用の題名や URL が返ることがあります。回答文だけでなく、すべての返却項目を確認します。

引用は現在の文書認可で開きます。アプリが配信するなら、返す前に呼び出し元を検証します。外部文書システムなら、そのリンクでも元のアクセス規則が保たれるかを確定します。

アプリのキャッシュには、テナントと関係する権限情報を含めます。質問の文字列が一致するだけで、一社に適切な回答を共有回答にしてはいけません。

組織の切り替えや失効後も、履歴に検索済みの段落が残る場合があります。再び開ける履歴とモデルへ渡せる情報を決めます。失効は生の検索だけでなく、派生コピーにも明示的な影響を持たせます。

実際の漏えいが分かる否定テストを作る

組織ごとに識別しやすい固有の印を持つ合成文書を使います。異なる組織のユーザーで同じ質問を行い、他組織の印が段落、回答、メタデータ、引用のどこにも出ないことを検査します。

複数組織の管理権限を持つ担当者は、通常ユーザーと別に試します。管理上の調査には独自の権限と証拠が必要です。広い管理者結果を、一般利用者の受入条件に混ぜないでください。

経路、取り込み、フィルター、キャッシュの変更後に分離集合を再実施します。関連性のテストだけでは権限の回帰は分かりません。非常に関連する結果こそ、その人が見てはいけない文書かもしれません。

権限のライフサイクルに予算を付ける

開発量は、所属、文書権限、資料連携、検索経路の数に依存します。単純なテナントフィルターの実演には、実際の SaaS が必要とする多くのライフサイクル作業が含まれません。

作成、テナント変更、削除、失効、受入を含む GBP の提案を求めます。組織の境界までなのか、内部のチームや個別文書も含むかを明記します。

範囲を限定した AI 連携パイロット で、非公開データを入れる前に合成組織と代表文書を試せます。所属モデルと資料権限を添えてテナント検索案をご依頼 ください。分離を図の安心感あるラベルで終わらせず、検証可能な契約にできます。

よくある質問

各テナントに独立インスタンスが必要ですか？ 必ずしも必要ではありません。Cloudflare は個別と共有の方式を説明しています。権限モデル、作成負担、必須フィルターの信頼性を比較します。どちらもアプリの認可を不要にはしません。

ブラウザーがテナント番号を送ってよいですか？ 選択を要求できますが、サーバーが認証済みの所属に照合する必要があります。任意の引数やモデル生成値を、権限の根拠として扱いません。

名前空間は認可システムですか？ 文書化されたバインディングでインスタンスへのアクセスを整理します。本人確認と正しい振り分けは依然として必要です。範囲を確認し、一般ユーザーの否定テストで証明します。

空の検索はフィルターなしで再試行すべきですか？ いいえ。回答のために必須範囲を外すと、他組織の資料を公開しかねません。役立つ結果なしを返すか、アクセスを広げず索引と権限を調べます。

引用から情報が漏れることはありますか？ あります。回答で省略しても、題名、URL、抜粋、取得文書が非公開情報を示す場合があります。応答全体を試し、原本を開く時点で現在の認可を要求します。

所属を失ったユーザーはどう扱いますか？ 以後のアクセスは現在権限に従います。検索だけでなく、既存セッション、キャッシュ、会話履歴、派生コピーへの影響も決めます。接続中の失効を試します。

分離パイロットは何を証明しますか？ 一般ユーザーが他組織の非公開資料を検索できず、返却メタデータから推測できず、原本を開けないことです。範囲改変、切り替え、キャッシュ再利用、資料更新、失効を含めます。