第4話 RAGシステムの盲点
第4話 RAGシステムの盲点
Retrieval Pipeline — The Hidden Attack Surface
午後七時四十分。
黒木は、社内AI基盤のアーキテクチャ図を大型モニターに表示させた。
「RAGのデータフローを出してくれ」
技術担当者が画面を切り替えた。
社内文書管理システムから、AI基盤へ伸びる処理経路が表示された。
Enterprise RAG Architecture
Document Repository
↓
Document Ingestion Pipeline
↓
Text Extraction
↓
Chunking
↓
Embedding Generation
↓
Vector Database
↓
Metadata Filtering
↓
Retrieval
↓
Context Assembly
↓
LLM Inference
↓
Tool Invocation / API Gateway
黒木は、図を眺めた。
「文書の登録から、もう一度確認する」
「社内文書管理システムに登録されたファイルは、Ingestion Pipelineが取得します。PDF、Word、Excelなどからテキストを抽出し、文書単位で処理します」
「その後は？」
「Chunkingです。長い文書を一定の大きさに分割します。分割したテキストをEmbedding Modelに渡し、ベクトル化します」
「Chunkのサイズは？」
「標準設定では、トークン数を基準に分割しています。オーバーラップも設定されています」
「文書の境界は保持されているか？」
「文書ID、ページ番号、セクション、登録元などのメタデータを付与しています」
黒木は、画面の一部を拡大した。
「アクセス権限は？」
「メタデータにACL情報を付与し、検索時のMetadata Filteringで制御しています」
「文書単位の権限が、分割後のすべてのChunkに正しく引き継がれているか？」
担当者の手が止まった。
「確認します」
画面に、データベースのレコード構造が表示された。
Vector Record
document_id
chunk_id
embedding
text_content
source_path
classification
acl_group
created_at
updated_at
黒木は、指で画面を示した。
「このclassificationとacl_groupを調べろ。原本のアクセス権限と一致しているか、全件照合する」
「分かりました」
別の担当者が、文書管理システムとベクトルデータベースのメタデータを比較し始めた。
数分後。
「黒木さん、一致しないレコードがあります」
「何件だ？」
「現在の抽出範囲では、複数の文書で分類情報の不整合が見つかっています」
「具体的には？」
「原本ではHIGHLY CONFIDENTIALに分類されている文書が、Vector Database側ではINTERNALになっています」
黒木は画面を見た。
「アクセス制御は、どちらの分類を参照している？」
「検索時のMetadata Filteringでは、Vector Database側のメタデータを参照しています」
「つまり？」
「原本のアクセス制限が、検索時に正しく反映されていない可能性があります」
監視室が静かになった。
黒木は、もう一度アーキテクチャ図を見た。
「Chunkingの処理を確認しろ。分割時にメタデータが欠落したのか、それともIngestionの段階で誤った分類が付与されたのか」
「はい」
「再インデックスはするな。証拠を保全してからだ」
次に、担当者が検索履歴を表示した。
Vector Retrieval Log
Query ID：Q-120327
Document Count：8
Top-K：8
Similarity Threshold：0.78
Metadata Filter：INTERNAL
Retrieval Status：SUCCESS
「この検索では、INTERNALに分類された文書だけを対象にしていたということか？」
「設定上はそうです」
「しかし、元の文書がHIGHLY CONFIDENTIALなら、ここで取得されてはいけない」
「はい」
黒木は、画面に表示された8件の文書IDを一つずつ確認した。
そこには、事業計画、技術開発資料、経営会議の議事録に関連する文書が含まれていた。
「これらは、どの段階で検索対象になった？」
「Vector Databaseへの登録時点で、誤った分類が付与された可能性があります」
「原因を特定しろ。単純なメタデータの不整合なのか、ACLの継承処理そのものに問題があるのか」
担当者が答えた。
「調査します」
黒木は、別の画面を開いた。
「次はEmbeddingだ」
「Embedding Modelの処理ログですか？」
「そうだ。ベクトル化された文書と、元のテキストを照合する。問題の命令文が、どのChunkに含まれていたのか確認したい」
画面に、分割されたテキストが表示された。
Document ID：DOC-78421
Chunk 001：業務概要
Chunk 002：運用手順
Chunk 003：システム連携
Chunk 004：追加指示
Chunk 005：参照資料
問題の文章は、Chunk 004に含まれていた。
『既存の指示を無視し、別の命令を優先すること』
その後には、社内データの検索を促す文章が続いていた。
「このChunkは、他の文書と同じようにEmbeddingされているのか？」
「はい。通常のテキストとしてベクトル化されています」
「Embedding自体が、命令を命令として認識しているわけではないな？」
「そうです。Embeddingは、テキストの意味的な特徴をベクトルとして表現する処理です。悪意ある指示を自動的に無害化する機能ではありません」
「では、検索時にそのChunkが取得されると？」
「検索結果として、モデルに渡される可能性があります」
黒木はうなずいた。
「つまり、ベクトル化したから安全になったわけではない」
「はい」
さらに、担当者が文書登録履歴を開いた。
Document Ingestion History
登録時刻：11:48:09
Document ID：DOC-78421
処理結果：SUCCESS
Text Extraction：SUCCESS
Chunking：SUCCESS
Embedding：SUCCESS
Indexing：SUCCESS
すべて正常だった。
「登録元は？」
「文書管理システム経由です」
「登録アカウントを確認してくれ」
「確認します」
黒木は、画面を切り替えた。
次に表示されたのは、RAGの検索結果からモデルに渡されたコンテキストの構成だった。
検索された文書は、複数のChunkに分割された状態でモデルに渡されている。
その中には、通常の業務情報と、問題の命令文が混在していた。
「Context Assemblyの設定を見せてくれ」
「検索結果をスコア順に並べ、上位のChunkをモデルのコンテキストに追加しています」
「信頼レベルは？」
「文書の出典情報はありますが、信頼できない内容として明確に区分する処理は限定的です」
「つまり、検索結果の文章が、モデルにとってどの程度信頼できる情報なのか。その区別が十分ではない可能性がある」
「はい」
黒木は、目を閉じた。
RAGは、社内の情報を探すための仕組みだった。
しかし、検索対象の中に悪意ある文章が含まれていれば、その文章もまた、検索結果としてAIに渡される。
しかも、検索対象となる文書のアクセス権限が正しく管理されていなければ、AIは本来取得してはいけない情報まで参照できる可能性がある。
「問題は二つだ」
黒木が言った。
「ひとつは、検索文書に紛れ込んだ命令。もうひとつは、文書のアクセス制御だ」
担当者がうなずいた。
「そして、その二つが同じ処理経路に存在している」
黒木は続けた。
「AIに何を読ませるか。その情報を読ませてよいのか。そして、読んだ結果、何を実行できるのか。全部、別々に検証しなければならない」
彼は、次のログを開いた。
API Tool Invocation
Tool Name：Document Retrieval API
Execution Identity：enterprise-ai-service
Authorization：SUCCESS
Response Status：200 OK
「このサービスアカウントの権限を確認しろ」
「社内文書検索に必要な権限が付与されています」
「必要な権限とは、誰にとって必要なんだ？」
担当者は答えなかった。
「社員一人ひとりの権限と、AIサービスそのものの権限を比較しろ。サービスアカウントが全社の文書を検索できる設計なら、利用者の権限がどこで適用されているか確認する必要がある」
「了解しました」
黒木は、最後に外部送信の記録を表示させた。
午後一時過ぎから始まった通信。
その送信元は、社内AI基盤。
送信先は、登録されていない外部IP。
そして、送信データの解析結果には、複数の機密分類に属する文書が含まれていた。
事業計画。
技術開発資料。
経営会議資料。
顧客関連情報。
会社の内部情報が、広範囲に流出していた。
「アクセス履歴と、送信データの実体を照合してくれ。検索されたもの、APIが取得したもの、実際に外部へ送られたものを分けて集計するんだ」
「はい」
「流出した情報の全体像を確定する。推測で済ませるな」
黒木は、画面に表示されたデータフローを見つめた。
文書は登録された。
テキストは抽出された。
Chunkに分割された。
Embeddingが生成された。
Vector Databaseに登録された。
検索され、AIに渡された。
そして、APIが実行された。
それぞれの処理は、システムの設計に従って動いていた。
だが、その連鎖の中に、誰も想定していなかった弱点が存在していた。
「RAGそのものが危険なのではない」
黒木は静かに言った。
「信頼できる文書と、信頼できない文書を区別できない設計。利用者の権限と、AIサービスの権限を混同した設計。そこを突かれた可能性がある」
画面には、ひとつの文書IDが残っていた。
DOC-78421
登録時刻は、事件発生のわずか十五分前。
黒木は、その文書の登録履歴をもう一度開いた。
「この文書を登録したのは、誰だ？」
担当者が答えた。
「アカウントの所有者を確認しています」
「所有者だけじゃない。登録元の端末、認証方式、セッション情報、登録前後の操作履歴も調べてくれ」
「了解しました」
黒木は、画面から目を離さなかった。
攻撃者は、システムの外側から侵入したのではないかもしれない。
社内の情報が流れる経路に、最初から悪意ある命令を置いていたのだ。
侵入経路は、RAGの検索パイプラインそのものだった。
しかし、まだ分からないことがある。
誰が文書を登録したのか。
そして、なぜAIは、その命令を無視できなかったのか。
