LLMとRAGシステムでは、文書や会話内容を検索するために埋め込みを使用する。

例えば、次のような文章があるとしよう。

"고객사 A와 1억 원 규모의 보안 교육 계약을 체결했다."

埋め込みモデルは、この文章を次のような数値配列に変換する。

[0.132, -0.847, 0.291, ...]

この数値配列がまさに埋め込みベクトルだ。

このため、しばしば次のような質問が出てくる。

埋め込みベクトルを確保すれば、逆解析を通じて原文をそのまま復元できるのか？

結論から言えば、埋め込みベクトルだけで原文が自動的にそのまま復元されるわけではない。

しかし、攻撃者が埋め込みモデルと候補データ、検索API、メタデータなどを一緒に確保した場合には、原文の意味や特定の属性を相当部分推論できる。

埋め込みは暗号化データではない

埋め込みはテキストを暗号化した結果ではない。

暗号化は、正常な復号化キーがあれば原文を正確に復元できるように設計される。

一方、埋め込みは文章の意味的特徴を高次元の数値空間に表現したものだ。

원문 텍스트
    ↓
임베딩 모델
    ↓
벡터

したがって、一般的に次のような逆変換関係は成立しない。

벡터
  ↓
단순 역계산
  ↓
정확한 원문

埋め込み過程では、単語の順序、表現方法、文章構造といった情報の一部が失われる可能性がある。

例えば、次の二つの文章は異なる文章だが、似たようなベクトルを持つことがある。

"고객사 A와 1억 원 규모의 계약을 체결했다."

"A사와 약 1억 원 상당의 계약을 맺었다."

意味が似ているため、埋め込み空間でも近い位置に配置される可能性が高い。

RAGで原文が検索される理由

RAGシステムでベクトル検索結果として原文が出力されるのを見て、ベクトルが原文に逆変換されると誤解するかもしれない。

しかし、実際の構造は通常次のようになる。

원문 문서 ──────────────┐
                       │
                       ├─ 문서 저장소
                       │
                       └─ 임베딩 생성 → 벡터 DB

検索過程は次のとおりだ。

사용자 질문
   ↓
질문 임베딩 생성
   ↓
벡터 DB에서 유사 벡터 검색
   ↓
벡터에 연결된 문서 ID 확인
   ↓
문서 저장소에서 원문 조회

つまり、原文が出てくる理由は、ベクトルを復元したからではなく、ベクトルに連結された原文や文書の断片を再度取得したからだ。

実際のベクトルDBには次のようなデータが保存されうる。

{
  "id": "doc-1042",
  "vector": [0.132, -0.847, 0.291],
  "metadata": {
    "user_id": "user-a",
    "source": "contract-document",
    "text": "고객사 A와 1억 원 규모의 계약을 체결했다."
  }
}

この構造で攻撃者がメタデータや原文フィールドにアクセスできるなら、埋め込みを逆解析する必要すらない。

したがって、実務では埋め込み復元攻撃よりもベクトルDBのアクセス制御失敗がより直接的なリスクとなりうる。

埋め込みベクトルを逆解析する代表的な方法

1. 候補文章比較攻撃

最も単純な方法は、攻撃者が予想可能な候補文章を複数作成し、同じ埋め込みモデルでベクトル化することだ。

탈취한 벡터
    ↕ 코사인 유사도 비교
후보 문장 벡터

例えば、攻撃者は次のような候補を準備できる。

"고객사는 삼성SDS다."
"고객사는 LG CNS다."
"고객사는 SK C&C다."

各文章を埋め込みした後、奪取したベクトルと比較する。

最も類似度が高い候補を通じて、原文に含まれる内容を推論できる。

この攻撃は次の条件で特に有効だ。

埋め込みモデルを知っている場合
候補文章の範囲が狭い場合
文章が短く定型化されている場合
名前、会社名、病名のように選択肢が制限されている場合
攻撃者が同じ埋め込みAPIを呼び出せる場合

例えば、契約状態が次の三つのうちの一つであるという事実を知っていれば、推論は容易になる。

계약 체결
계약 검토
계약 취소

原文全体を復元できなくても、どのような状態であるかを識別できる。

2. 最近接近傍辞書攻撃

攻撃者が大量の文章や文書を事前に埋め込みして辞書を作成することもできる。

문장 사전
   ↓
대량 임베딩 생성
   ↓
벡터 인덱스 구축
   ↓
탈취한 벡터와 최근접 문장 검색

例えば、次のような候補データがあるかもしれない。

candidate_texts = [
    "관리자 비밀번호가 변경되었습니다.",
    "고객의 주민등록번호가 포함되어 있습니다.",
    "계약 금액은 1억 원입니다.",
    "보안 교육 계약이 취소되었습니다."
]

攻撃者はこれらの候補を埋め込みした後、奪取したベクトルと最も近い文章を探す。

この方法は次のようなデータで成功可能性が高い。

標準契約書
Eメールテンプレート
顧客相談文句
人事評価様式
診療記録コード
公開された技術文書
繰り返し使用される社内文書

原文が既存の公開文書や標準文句と類似しているなら、最近接文章検索だけでも相当な情報を得ることができる。

3. 埋め込み逆変換モデル

攻撃者が別途のデコーダーモデルを学習する方法もある。

攻撃者は大量のテキストと埋め込みベクトルのペアを準備する。

텍스트 → 임베딩 모델 → 벡터

その後、次のような逆方向モデルを学習する。

벡터 → 디코더 모델 → 텍스트 추정

学習データが十分であれば、ベクトルを入力として受け取り、原文と類似した文章を生成できる。

例えば、原文が次のようだとしよう。

"고객사 A와 1억 원 규모의 보안 교육 계약을 체결했다."

復元結果は次のようになるかもしれない。

"A사와 약 1억 원 규모의 보안 교육 계약을 맺었다."

完全に同じ文章ではないが、核心的な意味は相当部分復元されうる。

このため、埋め込み逆解析は正確な文字列復旧よりも意味復旧に近い。

4. 属性推論攻撃

攻撃者は原文全体を復元せず、特定の属性だけを突き止めようとすることがある。

例えば、次のような質問だ。

이 벡터에는 금융정보가 포함되어 있는가?
특정 회사명이 들어 있는가?
질병 관련 내용인가?
계약 금액이 포함되어 있는가?
보안 사고 내용인가?

攻撃者はベクトルを入力として受け取る分類器を学習できる。

Embedding
    ↓
속성 분류기
    ↓
"금융정보 포함 확률 92%"

この方法は原文全体の復元よりも現実的である。

実際の攻撃者はすべての文章を知る必要はない。

例えば、次の情報だけを突き止めても問題になることがある。

特定の疾病の存在有無
特定の企業との契約有無
個人情報包含有無
セキュリティ事故発生有無
内部プロジェクト参加有無
特定技術使用有無

このようなタイプを属性推論攻撃と呼ぶ。

5. メンバーシップ推論攻撃

メンバーシップ推論は、特定のデータがベクトルストレージに含まれているかを確認する攻撃だ。

例えば、攻撃者は次を知りたいと思うかもしれない。

"A사 계약서가 이 데이터베이스에 존재하는가?"
"특정 직원의 인사평가 문서가 포함되어 있는가?"
"특정 환자의 진료기록이 학습 또는 검색 데이터에 들어 있는가?"

原文を直接確認できなくても、データの存在有無自体が機密情報となりうる。

例えば、ある会社が特定のセキュリティ事故を調査しているという事実が露呈するだけでも問題になることがある。

6. 検索APIを利用した反復推論

攻撃者がベクトル自体にアクセスできなくても、検索APIを繰り返し呼び出すことで情報を推論できる。

例えば、次のような質問を繰り返す。

"A사와 계약했는가?"
"A사 계약 금액은 1억 원 이상인가?"
"A사 계약은 교육 계약인가?"
"A사 계약 시점은 2026년인가?"

検索結果の順位や類似度スコアが提供されるなら、攻撃者は質問を少しずつ変えながら情報を絞り込むことができる。

질문 변경
   ↓
유사도 점수 확인
   ↓
더 높은 점수가 나오는 방향 탐색
   ↓
원문 의미 추정

このような構造を検索オラクルまたは類似度オラクルと見なすことができる。

特にAPIが次の情報を露出する場合、危険が大きくなる。

詳細な類似度スコア
検索順位
文書ID
メタデータ
検索された文書数
フィルタリング前後の結果の差

7. 座標最適化ベース攻撃

攻撃者は任意の文章を作成した後、単語や表現を少しずつ変更しながら目標ベクトルに近づく方向を見つけることができる。

초기 문장 생성
   ↓
단어 또는 문장 구조 변경
   ↓
임베딩 생성
   ↓
목표 벡터와 유사도 측정
   ↓
유사도가 높아지는 변경 유지

例えば、最初は次の文章から始めることができる。

"어떤 회사와 계약했다."

その後、次のように少しずつ変える。

"A사와 계약했다."
"A사와 교육 계약을 체결했다."
"A사와 1억 원 규모의 교육 계약을 체결했다."

類似度スコアが継続的に高くなるなら、原文と近い意味を持つ文章を見つけることができる。

APIが精密な類似度スコアを提供するほど、このような最適化攻撃は容易になる可能性がある。

8. メタデータと原文連結情報の奪取

実務的にはこれが最も直接的な攻撃だ。

ベクトルDBには埋め込みだけでなく、次のようなメタデータが一緒に保存されうる。

{
  "vector": [0.132, -0.847, 0.291],
  "metadata": {
    "tenant_id": "company-a",
    "user_id": "user-1004",
    "document_name": "2026-contract.pdf",
    "chunk_text": "계약 금액은 1억 원이다."
  }
}

この場合、攻撃者は埋め込みを逆解析する必要がない。

ベクトルDBの読み取り権限だけを確保すれば、次の情報が直接露出されうる。

原文チャンク
ユーザーID
テナントID
ファイル名
保存位置
文書タイトル
作成者
会話ID
文書URL

したがって、ベクトルDBは単純な検索インデックスではなく、機密情報貯蔵庫と見なすべきだ。

埋め込み逆解析が容易になる条件

埋め込みベクトルが露出したからといって、常に原文が復元されるわけではない。

しかし、次の条件が多いほど攻撃成功可能性が高くなる。

同じ埋め込みモデルを知っている場合

攻撃者が使用中のモデルを知っているなら、候補文章を同じ方法でベクトル化できる。

例えば、モデル名、次元数、正規化方式が公開されているなら、比較攻撃は容易になる。

埋め込みAPIを自由に利用できる場合

攻撃者が無制限に埋め込みを生成できるなら、多様な候補文章を繰り返し比較できる。

原文候補範囲が狭い場合

次のように選択肢が制限的であれば推論は容易だ。

승인
거절
검토 중

逆に自由形式の長い文書なら、正確な原文復元ははるかに難しい。

文章が短い場合

短い文章は含まれる情報が少ないため、候補空間が減少する。

例えば、次の文章は比較的推論しやすい。

"계약이 취소되었다."

一方、複数の主題が混ざった長い文章は、一つのベクトルだけで正確に復元するのは難しい。

チャンクサイズが小さい場合

RAGでは文書を短い単位に分割して保存する。

문서
  ↓
300~500 토큰 단위 청크
  ↓
각 청크 임베딩

チャンクが小さすぎると、一つのベクトルが特定の文章や機密情報を直接的に表す可能性がある。

メタデータが一緒に露出された場合

次の情報が一緒にあると、攻撃者は候補範囲を大幅に減らすことができる。

파일명
부서명
작성자
문서 유형
날짜
고객사명
사용자 ID

類似度スコアを詳細に提供する場合

類似度スコアが小数点単位で露出されると、攻撃者が文章を少しずつ変えながら目標ベクトルに近づく方向を見つけることができる。

ベクトルだけあれば原文がそのまま出てくるのか？

正確に区別する必要がある。

ベクトル検索

벡터
  ↓
연결된 문서 ID 확인
  ↓
저장된 원문 조회

この場合は原文を逆解析したものではない。

ベクトルに連結された原文をそのまま取得したものだ。

埋め込み逆解析

벡터
  ↓
후보 비교 또는 디코더 분석
  ↓
원문의 의미나 속성 추정

この場合は原文を確率的に推論する。

完全に同じ文字列が出てこなくても、核心内容や機密な属性が露出されうる。

したがって、次のように表現するのが正確だ。

埋め込みベクトルを確保したからといって、原文が自動的にそのまま復元されるわけではない。しかし、候補文章比較、属性推論、デコーダー学習、検索API分析などを通じて、原文の意味や機密な情報を推定できる。

ChatGPT対話記録もベクトルだけで保存されるのか？

特定のサービスが対話記録をどのような内部構造で保存するかは、公開された情報だけでは断定できない。

対話履歴、メモリ、検索インデックスがそれぞれどのようなデータベース構造で管理されるかは、サービス提供者の内部設計に該当する。

したがって、次のように断定してはならない。

모든 대화 원문이 임베딩 벡터로만 저장된다.
벡터를 역변환하면 모든 대화가 그대로 나온다.

一般的なサービスでは、次の要素が別途存在する可能性がある。

대화 원문 저장소
검색용 임베딩 인덱스
사용자 메모리
메타데이터
로그 및 감사 기록

埋め込みは主に検索と類似度比較に使用され、実際の原文は別途のストレージで管理されることが多い。

セキュリティ診断では何を確認すべきか？

埋め込み逆解析の可能性だけを確認するだけでは不十分だ。

実際のLLMおよびRAGセキュリティ診断では、次の項目がより重要である可能性がある。

ユーザー間のデータ隔離

ユーザーAがユーザーBの文書を検索できるかを確認する必要がある。

user_id = A
tenant_id = company-a

検索時にこのようなフィルターが欠落すると、他のユーザーのデータが露出される可能性がある。

テナント単位アクセス制御

マルチテナント環境では、組織別データ分離が必須だ。

tenant-a의 문서
tenant-b의 문서

ベクトル検索後に権限を検査するのではなく、検索以前からアクセス範囲を制限する必要がある。

メタデータ最小化

ベクトルDBに原文、Eメールアドレス、住民登録番号、APIキーなどを不必要に保存してはならない。

検索スコア非公開

詳細な類似度スコアは攻撃者の反復推論に活用されうる。

必要でなければ、外部ユーザーにスコアを公開しない方が良い。

クエリ回数制限

攻撃者が数千回の候補文章を比較できないように、次の制御が必要だ。

Rate limiting
사용자별 요청 제한
이상 질의 탐지
반복 패턴 탐지

埋め込みと原文の両方を暗号化

ベクトルは原文ではないが、機密情報を含む可能性がある。

したがって、埋め込みデータも原文と同じレベルで保護する必要がある。

저장 데이터 암호화
전송 구간 암호화
키 관리
접근 로그
권한 분리

まとめ

埋め込みベクトルは単純な無作為な数字ではない。

原文の意味的特徴を含んでいるため、適切な補助情報があれば次のような攻撃が可能だ。

후보 문장 비교
최근접 이웃 검색
임베딩 역변환 모델
속성 추론
멤버십 추론
검색 API 반복 분석
메타데이터 탈취

だからといって、ベクトルをひっくり返すだけで原文がそのまま出てくるわけではない。

より正確には次のとおりだ。

埋め込みは原文を直接復号化できる暗号文ではないが、攻撃者がモデルと候補データ、検索インターフェース、メタデータを確保すれば、原文の意味や機密な属性を推論できる。

実務的には、埋め込み逆解析自体よりもベクトルDBのアクセス制御失敗、テナント分離エラー、メタデータ露出、原文連結情報流出がより直接的なリスクとなりうる。

したがって、埋め込みベクトルも単純な検索データではなく、原文と類似したレベルの機密情報として扱うべきだ。

埋め込みベクトルを逆解析すると、原文はそのまま復元されるのか？