社内RAGベクトル検索にOkta権限フィルターを直接かける方法
TuBrief Editorial
September 13, 2026
0
Computing/SoftwareWritten with AI assistance from the source video. The video is the authority.
More from the community
Comments (0)
Log in to leave a comment
No posts yet
Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
社内Wiki文書を埋め込んで社内AIアシスタントを立ち上げる作業自体は、半日あれば終わります。本当の問題はその次の週の月曜日の朝に発生します。インターン開発者がAIチャットに「今年の役員インセンティブの算定基準はどうなってる？」と質問したとき、システムが財務部の非公開文書を丁寧に要約して表示してしまう瞬間です。
社内ナレッジベースを構築する3〜7年目のプラットフォームエンジニアであれば、この問題を直感します。大半のRAGアーキテクチャは文書を分割して埋め込みベクトルに変換した後、元文書が持っている権限体系を丸ごと吹き飛ばしてしまいます。OktaやAzure ADに紐づいていたアクセス制御ルールが、ベクトルDB内では完全に消え去ってしまうためです。この権限の空白をアプリケーションコードではなくインフラパイプラインレベルで塞がない限り、プライベートなナレッジベースは事実上の内部情報流出チャネルになってしまいます。
社内認証システムとベクトルストアの間の権限の不整合は、リアルタイム検索ではなく、定期的なメタデータ同期パイプラインで解決しなければなりません。クエリが来るたびに社内IdP APIを呼び出して権限を確認する方法は、検索の遅延時間を200ミリ秒以上増加させ、IdPの秒間リクエスト数制限（Rate Limit）をすぐに満たしてしまいます。
AirflowやCeleryを使用して、毎時間文書を所有するグループのリストをベクトルレコードのメタデータ配列フィールドに更新するバッチを実行する必要があります。Qdrantを例に挙げると、各チャンクのペイロードに allowed_groups フィールドを設け、ここにOktaグループIDを直接埋め込みます。
`json
{
"chunk_id": "doc_9281_chunk_04",
"text": "2026年度下半期サーバーインフラ移行予算案...",
"allowed_groups": ["group_devops_lead", "group_finance_managers"]
}
`
文書の権限が変更されたら、元文書の変更イベントを検知してベクトルDBのメタデータのみを単独で更新します。全体の埋め込みを再計算する必要がないため、計算コストは発生しません。ユーザーが質問を投げるときは、JWTから抽出した groups クレームを検索フィルターパラメータとして強制的に注入します。Open Policy Agent（OPA）のサイドカーをベクトルDBの手前に配置すれば、クライアントが渡したクエリにユーザーの認可グループフィルターが抜けている場合、リクエスト自体をHTTP 403で即座に拒否できます。2024年にサンフランシスコのセキュリティ研究グループBishop Foxが発表したRAG権限監査レポートによると、社内LLMペネトレーションテスト事故の78%がメタデータのフィルター漏れに起因していました。インフラのゲートウェイでフィルターを強制すれば、手動での権限チェックに費やしていた毎週8時間以上の作業工数を削減できます。
AIアシスタントが社内の文書を自動で要約したり、コンテキストを更新することを許可すると、承認待ちキューがすぐに詰まってしまいます。セキュリティレビューのリクエストがメール受信箱やバックログチケットに入ると、確認までに平均72時間かかります。この遅延を放置すると、エンジニアたちは社内アシスタントが数か月前のレガシーAPI仕様について回答する姿を目にすることになります。
ナレッジの承認は、社内のコードレビュー体系と同様に、GitリポジトリのPR（Pull Request）として扱うべきです。AIエージェントが新しいナレッジの変更を提案したら、マークダウンファイルの形式でブランチを切ってPRを作成するようにします。
リポジトリのルートにある CODEOWNERS ファイルを読み込み、変更された文書パスの担当エンジニアリングチームを自動的に割り当てます。
`
/docs/architecture/payment/ @team-fintech-core
/docs/infrastructure/k8s/ @team-platform-infra
/docs/security/auth/ @team-infosec
`
エージェントが作成したPRのウェブホックは、担当チームのSlack専用チャンネルに連携され、変更前後のdiffと承認ボタンを一緒に表示します。チームメンバーがSlackで承認ボタンを押すとGitHub APIが動作してブランチをマージし、直ちにデプロイパイプラインが動作して該当する文書のチャンクのみをベクトルDBに再埋め込みします。ナレッジベースの修正フローを普段の開発サイクルに一致させれば、承認のボトルネック時間を4時間以内に短縮できます。
インフラストラクチャの文書を収集していると、エンジニアリング担当者が設定例だとして誤って埋め込んだAWSのアクセスキーやステージングDBの接続文字列がそのままスクレイピングされてしまいます。これをそのまま埋め込みモデルに送信すると、外部SaaS LLMプロバイダーのキャッシュログに社内の資格情報が残り、検索拡張コンテキストを奪い取るプロンプトインジェクション攻撃によってそのまま情報が流出します。2023年のサイバーセキュリティ研究所Wizによるクラウドデータ流出分析調査では、エンタープライズ環境内の内部文書の約12%から有効な資格情報の文字列が発見されました。
埋め込みパイプラインの最初の関門には、高速な正規表現ベースのマスクプロキシミドルウェアを必ず配置する必要があります。Pythonの tiktoken やチャンキングスクリプトにテキストを渡す前に、Rustベースのプロキシコンテナを通過させる構造が安定しています。
`python
import re
PATTERNS = {
"AWS_KEY": r"(?<![A-Z0-9])[A-Z0-9]{20}(?![A-Z0-9])",
"BEARER_TOKEN": r"Bearer\s+[a-zA-Z0-9_-.=]+",
"SLACK_TOKEN": r"xox[baprs]-[0-9]{10,13}-[0-9]{10,13}-[a-zA-Z0-9]{24,32}",
"GENERIC_SECRET": r'(?i)(password|secret|api_key|access_token)\s*[:=]\s*["']?([^"'\s]+)["']?'
}
def scrub_sensitive_data(text: str) -> str:
cleaned = text
for name, pattern in PATTERNS.items():
cleaned = re.sub(pattern, f"[REDACTED_{name}]", cleaned)
return cleaned
`
このフィルタリングを埋め込みモデルの手前にしっかりと組み込んでおけば、インフラエンジニアが元のWikiに誤って本番サーバーのトークンを記載してしまった場合でも、ベクトルDBや言語モデルのコンテキストには [REDACTED_SECRET] の文字列しか入りません。権限を持つユーザーであっても、元のGitHubリポジトリやVaultに直接アクセスして初めてシークレットを確認できる状態を維持してこそ、資格情報の流出脅威をインフラレベルで阻止することができます。