RAGの権限漏れを防ぐ｜namespace・metadata filterを認可情報から作る【2026】

RAGで社内文書を検索できるようにすると、質問に近い情報をすばやく回答へ渡せます。しかし、類似度が高いことは、その利用者に閲覧を許可してよいことを意味しません。別会社の契約書、異動前の部署資料、公開停止した手順書が一度でもpromptへ入れば、後から出力を隠しても漏えいの経路が残ります。

結論は、ベクトル検索の前に、認証済みの利用者・テナント・役割から検索範囲を決めることです。Cloudflare Vectorizeではnamespaceとmetadata filterで候補集合を狭められます。ただし、利用者が送ったtenantIdや部署名をそのままfilterに渡してはいけません。認可serverまたはアプリケーションの正本から取得した属性でfilterを組み立て、検索結果を本文へ渡す直前にも原本の閲覧権限を確認します。

類似検索は認可の代わりにならない

OWASPは、RAGで用いるvectorとembeddingの生成、保管、検索の弱点が、有害な内容の注入、出力の操作、機微情報へのアクセスにつながると整理しています。とくにtenantや顧客の境界をmetadataではなく「質問文に顧客名が入っているはず」といった暗黙の前提へ任せると、曖昧な質問、綴り揺れ、prompt injection、実装変更で境界が崩れます。

認可は、モデルが回答を作った後ではなく、候補を検索する前に実施します。アプリケーションは認証済みsessionから利用者IDとtenant IDを取得し、その利用者に許可されたdocument class、部署、案件などを認可サービスで解決します。そこで得た属性だけをnamespaceまたはmetadata filterへ入れます。クライアントが送るfilter条件は検索語として使えても、権限の根拠には使いません。

namespaceとmetadata filterの役割を分ける

Vectorizeのnamespaceは、一つのindexを大きな区画に分ける方法です。namespaceを指定したqueryでは、そのnamespace内だけがベクトル検索の対象になります。会社ごと、顧客ごと、あるいは明確に分離されたデータ領域ごとに使うと、検索の最初の候補集合を狭められます。

一方、metadata filterはtenant、documentClass、visibility、aclRevisionのような複数属性で絞る方法です。Cloudflare Vectorizeではfilterが先に適用され、そのfiltered setからtopKが取られます。部署横断の共有文書、特定案件だけに見せる文書、公開停止直後の文書など、namespace一つでは表しきれない条件に向きます。

両者は代替ではありません。一つのvectorは一つのnamespaceにしか属せないため、複数tenantへ共有する文書をnamespaceだけで表すと、複製と削除の運用が複雑になります。逆に全件を一つのnamespaceに置き、filterを付け忘れる経路を許すと、横断検索になります。まず大きな隔離単位をnamespaceで切り、必要な業務条件をmetadata filterで追加するか、共有文書を明示的な共有領域へ置くかを決めます。

metadataは「検索用の写し」であり、認可の正本ではない

metadataにはdocument ID、source revision、公開状態、分類、権限versionなど、検索時に必要な最小の値を入れます。ACLの全一覧や個人情報、本文を詰め込む場所ではありません。Vectorizeのmetadataにはサイズ制約があり、文字列のmetadata indexは先頭64 bytesだけがfilter対象です。長い権限リストを文字列に連結して比較する設計は、切り捨てや更新漏れの原因になります。

metadata filterを使う属性は、vectorを入れる前にmetadata indexとして作成する必要があります。作成前にupsertされたvectorは、そのmetadata indexへ自動では入らず、再upsertが必要です。認可属性を後付けしたのに、一部の旧vectorだけfilterを通らない・通ってしまう状態を避けるため、index作成時にtenant、visibility、aclRevisionなどの候補を棚卸しします。

検索後にも原本で再認可する

検索前filterが正しくても、権限変更と索引反映には時間差があります。異動、退職、案件終了、文書の公開停止の直後は、vector metadataだけを信用せず、検索結果のdocument IDを原本または認可サービスで再確認します。許可されない候補はpromptへ渡さず、回答の根拠からも除外します。

この二段階は過剰な二重実装ではありません。検索前は候補を出さないための広い境界、検索後は権限変更の競合を閉じる最終境界です。原本照合に失敗した場合は「資料を確認できない」としてfail-closeし、類似度だけで代替文書を選びません。文書更新と索引の反映手順は、RAG索引の鮮度設計も参照してください。

テストは「答えられたか」より「出してはいけない候補がないか」

RAGの評価では正答率だけでなく、tenant Aの利用者がtenant Bのdocument ID、title、snippet、metadataを一切取得しないことをテストします。部署異動、共有解除、文書非公開、filter未指定、古いACL revision、管理者権限の誤付与を含めます。query resultをログへ残す場合も、本文ではなくdocument ID、filter policy version、許可・拒否、時刻を中心にし、閲覧可能者を絞ります。

また、RAGに渡す文書が正当でも、そこへ書かれた命令をモデルが実行してよいとは限りません。検索結果は信頼できる業務情報と、モデルにとっては外部入力の両方です。外部送信や更新を行うagentには、MCPのOAuth認可設計と承認ゲート設計を重ねます。

実装前チェックリスト

• tenant・利用者・役割を、クライアント入力でなく認証済みserver側の属性から決めているか
• 検索前に必ずnamespaceまたはmetadata filterが作られ、filter未指定のquery経路がないか
• namespaceで分ける範囲と、metadata filterで分ける業務条件を文書化したか
• metadataにACL全件や機微な本文を入れず、正本のdocument IDとrevisionを残しているか
• filter対象のmetadata indexをvector投入前に作り、既存vectorを再upsertしたか
• 検索後に原本または認可サービスで閲覧可否を再確認し、失敗時はfail-closeするか
• tenant横断、異動、共有解除、非公開、古いACL revisionを含む漏えいテストをしたか

限界：filterは業務分類の誤りを直せない

namespaceやmetadata filterは、正しく分類・登録されたデータに対してしか働きません。誤ってpublicへ分類された文書、共有範囲を間違えた原本、侵害された認証sessionは防げません。また、検索候補を隔離しても、引用・画面キャプチャ・外部toolへの送信など回答後の経路には別の対策が必要です。

Vectorizeの制限、metadata index、namespaceの仕様は変更され得ます。本記事は2026年9月9日時点の公開資料を前提にしており、実装前には最新の製品仕様と自社の権限モデルを照合してください。

MCP・AIエージェントのセキュリティレビュー

社内AI検索・RAGの文書分類、認可、検索ログを導入前にレビューしたい方は、MCP・AIエージェントのセキュリティレビューをご利用ください。

一次情報と確認範囲

一次情報と確認範囲

確認日：2026年9月9日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。

1. RAGのvector・embeddingの弱点は、機微情報への不正アクセスや漏えいにつながり得る
2. namespaceを指定したqueryはそのnamespace内だけを検索し、vectorは一つのnamespaceに属する
3. metadata filterはvector検索前に適用され、filtered setからtopKを取る
4. metadata indexは最大十件で、文字列のindexed metadataは先頭64 bytesがfilter対象となる
5. queryはmetadataの返却方法を選べ、全metadataを返す場合のtopK上限は50である
6. NIST NCCoEのRAG-LLM構成例にはmetadata layerとvector databaseが含まれる