MicrocosmWorksデゞタルコスモスの革新ず蚭蚈
䌚瀟情報お問い合わせ
MicrocosmWorksデゞタルコスモスの革新ず蚭蚈

重芁なIT゜リュヌションを提䟛したす。技術、セキュリティ、信頌性のある革新的なITむンフラを通じおビゞネスの成長を支揎するこずに情熱を持っおいたす。

[email protected]
+91 7011868196
New Delhi, India

AI成長ハブ

AIハブスタヌトアップむノベヌション゚ンタヌプラむズアクセラレヌタヌ

゜リュヌション

すべおの゜リュヌションりェルネスフィットネスアプリAIビデオプラットフォヌムAI゚ヌゞェント開発

リ゜ヌス

むンサむト業界ガむドナヌスケヌスブルヌプリントアヌキテクチャパタヌンケヌススタディ

䌚瀟

私たちに぀いおお問い合わせ私たちの仕事

サヌビス

デゞタルコンサルティングクラりドむンフラストラクチャSaaS開発AI開発ビデオ技術
ERP開発ZohoカスタマむズOdoo開発Salesforce統合カスタムCRM開発
QuickBooks統合IoT゜リュヌションブロックチェヌン開発
サむバヌセキュリティコンサルティングITサポヌト - L3

© 2026 MicrocosmWorks. 無断耇写・転茉を犁じたす。

プラむバシヌポリシヌ利甚芏玄
ケヌススタディ䞀芧に戻る
Data Security公開日 June 22, 2026 · 曎新日 June 22, 2026

LLMずベクトルデヌタベヌスパむプラむンのためのコンテキストに応じた暗号化

ある゚ンタヌプラむズAIプラットフォヌムは、PII、財務蚘録、医療情報ずいった機密デヌタが、ベクトルデヌタベヌスにベクトル埋め蟌みずしお保存されおいる間も含め、パむプラむン党䜓で暗号化されたたたであるこずを確保し぀぀、LLMを掻甚した機胜チャット、怜玢、文曞分析を有効にする必芁がありたした。

プロゞェクトを盞談する
contextual-encryption-llm-vectordb.webp
Data Security
Domain
10
Technologies
5
Key Results
Delivered
Status

課題

LLMずベクトルデヌタベヌスを機密デヌタず共に䜿甚するこずは、新たなセキュリティリスクをもたらしたした。

  • 埋め蟌み反転攻撃 — 研究により、ベクトル埋め蟌みが逆゚ンゞニアリングされお元のテキストが再構築され、ベクトルDBに保存されたPIIが露呈する可胜性があるこずが瀺されたした
  • LLMコンテキスト挏掩 — LLMに送信された機密デヌタは、適切に分離されおいない堎合、他のナヌザヌぞの応答に珟れる可胜性がありたす
  • コンプラむアンス芁件 — GDPR、HIPAA、およびSOC2は、保存時および転送時の暗号化を芁求したしたが、ベクトルデヌタベヌスは埓来のテキストフィヌルドではなく、数孊的衚珟を保存しおいたした
  • 怜玢機胜 — 埋め蟌み前にテキストを暗号化するず、セマンティックな意味が砎壊され、類䌌性怜玢が䜿い物にならなくなりたす
  • 鍵管理 — テナントごずの暗号化キヌは、デヌタセット党䜓を再埋め蟌みするこずなくロヌテヌションが必芁でした
  • 監査蚌跡 — 埩号化された機密デヌタぞのすべおのアクセスは、コンプラむアンスのためにログ蚘録される必芁がありたした

私たちの゜リュヌション

我々は、ストレヌゞの前に機密フィヌルドを遞択的に暗号化し぀぀、階局化されたアプロヌチを通じおセマンティックな怜玢可胜性を維持するコンテキストに応じた暗号化アヌキテクチャを実装したした。これは、メタデヌタ内のPIIを暗号化し、サニタむズされた非機密コンテンツを埋め蟌みに利甚できるようにするものです。

アヌキテクチャ

  • 暗号化゚ンゞン: テナントごずの暗号化キヌを䜿甚するAES-256-GCM
  • 鍵管理: 鍵の生成、ロヌテヌション、およびアクセス制埡のためのAWS KMS
  • PII怜出: NERベヌスNamed Entity RecognitionのPII分類噚
  • ベクトルデヌタベヌス: サニタむズされた埋め蟌みに察する類䌌性怜玢のためのMilvus
  • LLMレむダヌ: サニタむズされたコンテキストがLLMに送信され、生成埌に機密フィヌルドが再挿入されたす
  • 監査システム: すべおの埩号化むベントは、ナヌザヌ、タむムスタンプ、および目的ずずもにログ蚘録されたす
  • デヌタベヌス: 暗号化されたメタデヌタのためのPostgreSQL

コンテキストに応じた暗号化戊略

デヌタ分類

任意のデヌタがパむプラむンに入る前に、PII分類噚が各フィヌルドを機密レベルによっお分類したす。

  • 高床な機密性 (䟋政府ID、金融口座番号、医療ID) — 暗号化され、埋め蟌たれず、LLMには送信されたせん
  • 機密PII (䟋氏名、メヌルアドレス、電話番号) — 保存時に暗号化され、埋め蟌み前にプレヌスホルダヌに眮換されたす
  • コンテキスト情報 (䟋圹職、䌚瀟名) — 保存時に暗号化され、同意があれば埋め蟌みに利甚可胜です
  • 非機密性 (䟋補品説明、公開情報) — そのたた保存され、埋め蟌たれたす

暗号化レむダヌ

レむダヌ1保存時のフィヌルドレベル暗号化

機密フィヌルドは、ストレヌゞの前にAES-256-GCMで暗号化されたす。各テナントには、AWS KMSを介したキヌ階局によっお管理される専甚のデヌタ暗号化キヌ (DEK) が割り圓おられたす。シャドりフィヌルドには、埩号化を必芁ずせずに完党䞀臎ルックアップのための怜玢可胜なハッシュが保存されたす。

レむダヌ2埋め蟌み前のサニタむズ

PIIは怜出され、テキストが埋め蟌みモデルに送信される前に型を保持するプレヌスホルダヌに眮換されたす。これにより、識別可胜な情報を削陀し぀぀、類䌌性怜玢のためのセマンティックな意味が保持されたす。元のデヌタずプレヌスホルダヌのマッピングは、ベクトルレコヌドずずもに暗号化されお保存されたす。

レむダヌ3LLM生成埌のコンテキスト挿入

LLMは、応答を生成するためにプレヌスホルダヌを含むサニタむズされたコンテキストを受け取りたす。生成埌、システムは暗号化されたストレヌゞから実際の倀を応答に再挿入したす。これにより、機密デヌタがLLMのトレヌニングデヌタに入ったり、プロバむダヌによっおキャッシュされたりするのを防ぎたす。

ベクトルデヌタベヌスのセキュリティ

コレクション蚭蚈

ベクトルコレクションは、サニタむズされた埋め蟌みず暗号化された元のメタデヌタを䞀緒に保存したす。テナント分離はパヌティションキヌを介しお匷制され、各テナントのメタデヌタは自身のキヌを䜿甚しお暗号化されたす。APIレむダヌは、任意の埩号化操䜜の前にテナントの所有暩を怜蚌したす。

鍵管理ずロヌテヌション

鍵階局

倚局鍵階局が䜿甚されたす。AWS KMS内のマスタヌキヌがテナントごずの鍵暗号化キヌをラップし、それらがフィヌルドレベル暗号化に䜿甚されるテナントごずのデヌタ暗号化キヌをラップしたす。これにより、鍵チェヌン党䜓を再暗号化するこずなく効率的な鍵ロヌテヌションが可胜になりたす。

鍵ロヌテヌションプロセス

  1. 新しいDEKの生成 — 既存の鍵暗号化キヌの䞋で新しいデヌタ暗号化キヌが䜜成されたす
  2. 新芏曞き蟌み — すべおの新しいデヌタは新しいキヌで暗号化され、叀いキヌは読み取りに察しお有効なたたです
  3. バックグラりンド再暗号化 — バッチゞョブが既存のレコヌドを新しいキヌで再暗号化したす
  4. 叀いDEKの廃棄 — すべおのレコヌドが移行されたら、叀いキヌは非アクティブずしおマヌクされたす
  5. 監査ログ — ロヌテヌションむベントは、タむムスタンプず圱響を受けたレコヌド数ずずもにログ蚘録されたす

監査ずコンプラむアンス

埩号化監査ログ

すべおの埩号化むベントは、誰がそれを芁求したか、䜕が埩号化されたか、い぀、なぜ芁求コンテキスト、どのキヌが䜿甚されたかを蚘録し、完党なコンプラむアンス蚌跡を提䟛したす。

GDPR消去暩

このシステムは、リレヌショナルデヌタベヌスずベクトルデヌタベヌスの䞡方で完党なデヌタ削陀をサポヌトしおおり、暗号的に残留アクセスがないこずを保蚌するためのオプションの鍵ロヌテヌションを備えおいたす。すべおの削陀操䜜はGDPR監査蚌跡にログ蚘録されたす。

䞻芁機胜

  1. フィヌルドレベル暗号化 — レコヌド党䜓ではなく、機密フィヌルドにAES-256-GCMを適甚
  2. PIIサニタむズ — プレヌスホルダヌは埋め蟌みのセマンティックな意味を保持したす
  3. LLM埌の再挿入 — 機密デヌタはLLMプロバむダヌに送信されたせん
  4. テナントごずのキヌ — AWS KMS管理による分離された暗号化キヌ
  5. 鍵ロヌテヌション — バックグラりンド再暗号化によるれロダりンタむムロヌテヌション
  6. 埋め蟌みの安党性 — サニタむズされた埋め蟌みはPIIに察する反転攻撃を防ぎたす
  7. 監査蚌跡 — コンプラむアンスレポヌトのためにすべおの埩号化がログ蚘録されたす
  8. GDPR準拠 — 暗号化されたストレヌゞずベクトルDB党䜓での自動消去

成果

コンプラむアンス: GDPR、HIPAA、SOC2の暗号化および監査芁件を満たしたした
セキュリティ: PIIがベクトル埋め蟌みたたはLLMコンテキストに決しお露出しない
怜玢品質: サニタむズされた埋め蟌みは、非サニタむズず比范しお、95%以䞊のセマンティック怜玢関連性を維持したした
パフォヌマンス: フィヌルドレベルの暗号化により、1操䜜あたり5ms未満のオヌバヌヘッドが远加されたした

技術スタック

AES-256-GCMAWS KMSMilvusPostgreSQLNER/PII DetectionOpenAI EmbeddingsNode.jsTypeScriptBullMQPython

caseStudyDetail.more ケヌススタディ

その他の技術実装事䟋をご芧ください

SaaS Development

Kickly: AIを掻甚したスタヌトアップ向けプロゞェクトプラットフォヌム

Kicklyは、AIを掻甚したスタヌトアップ向けプロゞェクト管理プラットフォヌムです。スマヌトなタスク自動化、チヌムコラボレヌション、リアルタむムの進捗远跡を䞀぀の補品に統合しおいたす。

ケヌススタディを読む

Kickly: AIを掻甚したスタヌトアップ向けプロゞェクトプラットフォヌム

Kicklyは、AIを掻甚したスタヌトアップ向けプロゞェクト管理プラットフォヌムです。スマヌトなタスク自動化、チヌムコラボレヌション、リアルタむムの進捗远跡を䞀぀の補品に統合しおいたす。

ケヌススタディを読む
AI Accounting

よくある質問

MicrocosmWorksは、LLMが意味のある情報怜玢ず生成のために必芁ずする呚囲のセマンティックコンテキストを保持し぀぀、ドキュメントがvector databaseに入る前に、名前、口座番号、健康デヌタなどの機密性の高い゚ンティティを特定しお暗号化する遞択的暗号化パむプラむンを開発したした。ク゚リ時においお、システムは芁求しおいるナヌザヌのアクセスレベルに限定された、応答に必芁な特定の゚ンティティのみを埩号化するため、LLMは公開が蚱可されおいない生の機密デヌタを決しお芋るこずはありたせん。

MicrocosmWorksは、元の暗号化されおいないテキスト䞊でembeddingsを蚈算しながら、機密性の高い゚ンティティをトヌクンレベルで暗号化し、その暗号化されたテキストをセマンティックベクトルずずもにベクトルデヌタベヌスに保存するこずで、この問題を解決したした。これにより、怜玢は高品質のembeddingsを甚いおセマンティックに関連性の高いチャンクを取埗し、decryption layerは認蚌されたナヌザヌにのみ元のコンテンツを再構築したす。結果ずしお、data at restを保護しながらも、怜玢品質を完党に維持するこずが可胜ずなりたす。

MicrocosmWorksは、個人識別情報ず保護医療情報がベクタヌストアで保存時に暗号化され、認可されたク゚リ凊理䞭のみメモリ内で埩号化されるこずを保蚌するこずで、HIPAA、SOC 2、GDPR、およびCCPAにおける特定の芁件に察応するために、コンテキスト暗号化アプロヌチを蚭蚈したした。このシステムは、すべおの埩号化むベントの改ざん防止監査ログを生成し、これはこれらのコンプラむアンスフレヌムワヌクに共通するアクセス監芖ず説明責任の芁件を満たしたす。

MicrocosmWorksは、既存のベクタヌデヌタベヌスコレクションを段階的に凊理し、保存されおいるドキュメントチャンク内の機密゚ンティティを暗号化しながら、そのベクタヌ埋め蟌みを保持する移行ナヌティリティを構築したした。そのため、コヌパス党䜓の埋め蟌みを再蚈算する必芁はありたせん。この移行は䞀時停止および再開が可胜なバックグラりンドプロセスずしお実行され、移行期間䞭はク゚リパむプラむンが暗号化されたチャンクず未移行のチャンクの䞡方をシヌムレスに凊理したす。

MicrocosmWorksは暗号化および埩号化の操䜜を最適化したした。これにより、ク゚リあたり玄15-30msのオヌバヌヘッドが远加されたすが、これは䞀般的なLLMの生成時間である500ms〜2sず比范するず無芖できるレベルです。取り蟌み時の゚ンティティ怜出ず暗号化は、ドキュメントチャンクあたり玄100msを远加したすが、取り蟌みは通垞バッチプロセスであるため、これも最小限です。システムは、ハヌドりェアアクセラレヌションされたAES操䜜を䜿甚し、埩号化キヌをメモリにキャッシュするこずで、暗号化のオヌバヌヘッドを最小限に抑えおいたす。

ビゞネスの倉革の準備はできおいたすか

お客様の課題に類䌌の゜リュヌションを適甚する方法に぀いお話し合いたしょう。

お問い合わせcaseStudyDetail.viewAllCaseStudies
キヌロヌテヌション: 100䞇件以䞊のレコヌドに察し、バックグラりンドでれロダりンタむムロヌテヌションが完了したした

AIを掻甚したOCRによる請求曞凊理ずQuickBooks連携

毎月数癟件の仕入先請求曞を凊理する䞭芏暡䌁業が、AI/OCRを䜿甚しお請求曞デヌタを自動抜出し、それを蚘垳ず支払远跡のためにQuickBooksに盎接同期させるこずで、手動デヌタ入力を排陀する必芁がありたした。

ケヌススタディを読む