導入
「クラウドにデータを上げるな。ましてやAIになんて読ませるな」
上司やセキュリティ部門からのこの一言で、画期的な生成AIプロジェクトがPoC（概念実証）の手前で頓挫するという課題は、実務の現場で頻繁に直面する壁です。AIはあくまでビジネス課題を解決するための手段ですが、その導入において「外部送信への恐怖」が最大のブロッカーとなるケースは少なくありません。
特に金融機関や医療現場、官公庁など、厳格なコンプライアンスが求められる領域では顕著です。RAG（検索拡張生成）は組織内のデータを活用してこそ真の価値を発揮し、ROIの最大化に貢献しますが、そのデータが絶対に外に出してはならない機密情報の塊であるというジレンマに、プロジェクトチームは常に頭を抱えています。
GPT-4oなどのレガシーモデルが廃止され、100万トークン級のコンテキストや高度な自動ルーティングを備えたGPT-5.2へと進化を遂げる現在でも、「OpenAIのAPIは学習に使われない設定ができる」「エンタープライズ版なら契約で守られている」と説明するだけでは、納得を得られない場面は多々あります。求められているのは契約上の保証ではなく、物理的・技術的な「確実な遮断」だからです。
厳しい要件と向き合うインフラエンジニアやセキュリティアーキテクトの皆さんと共に、プロジェクトを確実に前進させるための実践的な解決策として、VPC（仮想プライベートクラウド）内で完結させるセキュアなRAGアーキテクチャを提示します。
これはインターネットへの出口を完全に塞ぎ、すべてのデータフローを管理下に置くアプローチです。近年ではAWS Lambda Managed Instancesによるセキュアな実行環境のデプロイや、AWS Interconnect – multicloud（プレビュー）を活用したプライベートな高速ネットワーク接続など、クラウドインフラの機能も拡充されています。パブリッククラウド上にありながら、オンプレミスの要塞のように振る舞う強固なシステムを構築しやすくなりました。本稿ではAWSを例に挙げますが、AzureやGoogle Cloudでも応用可能です。
リスクを管理可能なレベルまで極小化し、ステークホルダーへの説明責任（Accountability）を果たしつつ、実用的なAI導入を成功に導くための具体的なアーキテクチャ設計を深掘りします。
なぜ「VPC内完結」が唯一の解なのか：AIセキュリティの現状と課題
なぜここまで「閉じる」構成を追求するべきなのか、背景にある本質的な課題を論理的に整理します。
API経由のRAGが抱える「見えないデータ流出」リスク
一般的なRAGや最新の自律型AIエージェントは、対象となるドキュメントをベクトル化して保存し、検索結果をLLMにプロンプトとして渡します。
LLMが外部API（SaaS）の場合、機密情報を含むプロンプトがインターネット経由で送信されます。HTTPSで暗号化されていても、データは一度管理下を離れてしまいます。
2026年現在、RAGは自律型エージェントやマルチモーダル処理へ進化し、外部APIへ送信される情報はより詳細かつ膨大になっています。たとえばChatGPTの環境では、旧モデルであるGPT-4oが2026年2月に廃止され、長い文脈理解やツール実行、高度な画像理解を備えたGPT-5.2が主力となりました。このようなSaaS版AIツールへの移行に伴い、インターネット接続を前提とした機能強化が急速に進んでおり、通信の境界を管理する難易度が飛躍的に上昇しています。
セキュリティ担当者が恐れるのは以下の点です。
- プロバイダー側の侵害リスク: API提供元がサイバー攻撃を受けた場合のデータ漏えい。
- 予期せぬ二次利用: 利用規約改定によるモデル再学習へのデータ利用リスク。
- データレジデンシー: データ処理サーバーの所在地が不明確な場合の法令（GDPR等）違反リスク。
コンプライアンス要件とAI利便性のジレンマ
金融や医療業界ではデータの「主権」が重視され、「データは制御下にあるインフラから一歩も出してはならない」という厳格なポリシーが存在します。
生成AIは外部モデルを利用するため通信が発生し、利便性とセキュリティがトレードオフになりがちです。この課題を解消するアプローチが、「モデルごとVPCの中に引き込む」または「VPCと直結したプライベートな経路でモデルを利用する」という構成の採用です。
「データ主権」を取り戻すためのアーキテクチャ転換
「VPC内完結」とは、クラウド上のVPCからインターネットを経由せずにAIサービスを利用する構成を指します。
AWSの環境では、Amazon Bedrock 公式サイト や Amazon SageMaker 公式サイト（現在はSageMaker AIとして統合・強化）で提供されるサービスを、VPCエンドポイント（AWS PrivateLink）経由で利用します。通信はAWSバックボーンネットワーク内のみを通り、インターネットには出ません。
2026年のAmazon Bedrockは、この「閉域網でのAI活用」を強力に支援する機能を備えています。
- 多様なモデルの選択肢: Claudeに加え、Llamaの最新世代、Mistral、NVIDIAなどの高性能モデルがフルマネージドで利用可能です。
- OpenAI互換APIのサポート: 既存のOpenAI SDKを使用したアプリケーションを、コードを大きく書き換えることなくセキュアなモデルへ移行できます。
- モデルライフサイクル管理: モデルのバージョン固定や、サポート終了に向けた計画的な移行制御については、Amazon Bedrock ユーザーガイド - モデルライフサイクル を参照して確実な運用体制を構築できます。
「データが通る道」をすべて把握し制御できる状態にすることが、エンタープライズAI導入のスタートラインとなります。
セキュリティ最適化のベースライン：脅威モデルの特定と防御
アーキテクチャの構築に着手する前に、RAGシステム特有の脅威モデルを整理し、防御すべき対象を明確にします。漠然としたセキュリティへの不安を、具体的な技術課題へと変換するプロセスは、プロジェクトを円滑に進める上で非常に重要です。
RAGパイプラインにおける3つの攻撃対象領域（Surface）
システムを構成する主要コンポーネントごとに、それぞれ異なるリスクが存在します。
- ナレッジベース（ベクトルDB）: 機密情報がベクトルデータとして集約される保管庫です。ここが侵害されると、大規模なデータ流出に直結します。AWS環境を例に挙げると、Amazon OpenSearch Serverless Collection Groupsのような最新の仕組みを活用し、異なる暗号化キー間でリソースを分離するなど、厳密なアクセス制御を設計する運用が推奨されます。
- 推論エンドポイント（LLM）: プロンプトの入力と生成結果の出力が通過する経路であり、通信傍受やログ漏えいの標的となります。また、パブリックAPIに依存する場合、ベンダー側の仕様変更リスクも考慮しなければなりません。例えば、OpenAIの公式発表（2026年2月時点）によれば、GPT-4oなどのレガシーモデルが廃止され、GPT-5.2への移行が求められるといったライフサイクルの急激な変化が起きています。VPC内で完結するアーキテクチャは、こうした外部要因による予期せぬシステム停止を回避する有効な手段となります。
- オーケストレーター（アプリ層）: LangChainやLlamaIndexなどが稼働する、データ処理の心臓部です。
- フレームワークの脆弱性: シリアライズ処理の不備を突いたAPIキーの奪取や、任意のコード実行といった深刻な事態を招く恐れがあります。
- 依存ライブラリの陳腐化: Google Vertex AI SDKから新しいライブラリへの移行が推奨されるケースなど、古いSDKや廃止予定の機能に依存し続けることは、稼働停止の引き金となります。コンポーネントの継続的な監視と、迅速なアップデート体制を整える運用を取り入れてください。
プロンプトインジェクションとデータ汚染のリスク評価
次に、AIモデルの言語処理能力を悪用した攻撃手法への対策を検討します。
- プロンプトインジェクション: 攻撃者が巧妙に細工した指示を入力し、LLMに設定された安全基準（ガードレール）を突破して不正な操作を実行させる手法です。
- データポイズニング（汚染）: RAGが参照するドキュメントやデータベースに、虚偽の情報や隠しコマンドを意図的に混入させ、最終的な回答出力を操作する高度な手口を指します。
既存の境界防御では防げないAI特有の脆弱性
これらの新たな脅威は、悪意のあるコードが自然言語の文脈に巧妙に隠蔽されているという特徴を持ちます。そのため、ファイアウォールや従来のWAF、単純なIPアドレス制限といった境界型セキュリティだけではシステムを守りきれません。
ネットワーク層での物理的な遮断にとどまらず、入力されるプロンプトの検証や、出力結果のフィルタリングなど、AIの振る舞いを監視する多層的な防御メカニズムの構築が不可欠といえます。
ネットワークの最適化：インターネット遮断とプライベート接続の徹底
データガバナンスの観点から目指すべき究極の姿は、「インターネットゲートウェイ（IGW）を持たないVPC」の構築にあります。物理的なネットワーク経路を最適化し、外部との通信を根底から絶つことで、データ漏洩や誤送信のリスクを物理層に近いレベルで排除できます。
VPCエンドポイント（PrivateLink）による通信経路の完全閉域化
各AWSサービスへのアクセスをパブリックエンドポイントから遮断し、「インターフェース型VPCエンドポイント（AWS PrivateLink）」を作成して通信をAWS内部ネットワークに閉じ込めます。
- Amazon Bedrock: Claude、NVIDIA Nemotron、Mistral、Amazon Novaに加え、新たにサポートされたDeepSeek OCRなどの多様なモデルに対する推論リクエストをPrivateLink経由で実行します。また、AgentCoreによるマルチエージェント機能や、OpenAI SDK互換APIを利用する際も、通信経路の閉域化を徹底します。
- Amazon SageMaker AI: 独自モデルのホスト、サーバーレスMLflow、SageMaker Data Agentの利用時もトラフィックをVPC内に留めます。
- Amazon OpenSearch Serverless (Vector Engine): RAGの要となるベクトルデータの格納先です。最新のアップデートにより高負荷時の自動最適化機能やCollection Groupsを利用したコスト管理が可能になっていますが、これらに対する管理通信もすべてプライベート接続で行います。
- 外部APIのセキュアな統合: 最新のGPT-5.2（標準モデル）やGPT-5.3-Codex（コーディング特化モデル）など、外部プロバイダーの強力な推論能力を活用する要件が生じた場合でも、パブリックなインターネット経由でのアクセスは避けるべきです。プレビュー提供されているAWS Interconnect – multicloudのような高速プライベートネットワーク接続や、セキュアなプロキシ環境を経由させることで、閉域網の原則を維持したまま最新モデルの恩恵を受ける設計を検討します。
- Amazon S3: RAGのナレッジソースとなるドキュメントの安全な保管場所として、ゲートウェイ型またはインターフェース型エンドポイントを経由させます。
- CloudWatch Logs: システムの監査ログや推論ログの出力先として確実に閉域網内でルーティングします。
NAT Gatewayすら排除する究極のアイソレーション設計
機密性の高いデータを扱うRAGアーキテクチャにおいて、NAT Gatewayの排除は極めて有効なアイソレーション設計となります。外部からのパッケージダウンロードを完全に遮断するため、Pythonライブラリなどの依存関係の解決にはAWS CodeArtifactやVPC内に構築したミラーリポジトリを活用します。
さらに、RAGアプリケーションを稼働させるコンテナイメージは、インターネット接続が許可された別のCI/CD専用VPCでビルドと脆弱性スキャンを済ませておきます。その後、本番VPCのAmazon ECRへ安全にプッシュし、PrivateLink経由でプルする運用フローを確立します。物理的に「インターネットに出られない」という制約を持たせることが、データ保護における強固な盾として機能します。
セキュリティグループとNACLによる多層防御のベストプラクティス
エンドポイントによる経路の限定に加えて、ネットワークレベルでの厳格なアクセス制御を組み合わせる多層防御のアプローチを採用します。
- セキュリティグループ: RAGアプリケーションが稼働するコンテナ環境から、特定のVPCエンドポイント（Bedrock、SageMaker、OpenSearchなど）に対する443ポート（HTTPS）の通信のみを明示的に許可します。不要なアウトバウンド通信はすべて遮断し、最小権限の原則をネットワーク層で適用します。
- ネットワークACL (NACL): サブネットの境界において、ステートレスなトラフィック制御を実施します。アプリケーション層やセキュリティグループの設定ミスが発生した場合のフェイルセーフとして機能し、予期せぬ通信の流出をブロックします。
このように「通るべき道」以外をすべて塞ぐホワイトリスト方式を徹底することで、VPC内完結型アーキテクチャの安全性を確固たるものにできます。
データ保護の最適化：保管と転送の暗号化戦略
万が一データストアにアクセスされても中身が読めない「データ中心のセキュリティ」を構築します。
KMSを活用したエンベロープ暗号化
AWS KMSでは「管理者が制御する鍵（CMK）」を使用します。鍵の利用ポリシーを細かく制御でき、万が一の際は鍵を無効化（Crypto-shredding）できます。データキーをマスターキーで暗号化する「エンベロープ暗号化」により、大量のベクトルデータも高速かつ安全に保護します。
ベクトル埋め込みデータの暗号化と鍵管理
ベクトルデータベースもCMKで暗号化します。2026年初頭にはAmazon BedrockにGoogle、Mistral AI、NVIDIA、OpenAIなどから18種類の新モデルが追加され、DeepSeek-R1やClaude、TwelveLabs Pegasusなどが利用可能です。マルチモーダルデータでも以下の暗号化は必須です：
- データソース（S3）: 元ドキュメントの暗号化
- ベクトルストア: 埋め込みベクトルの暗号化
- 一時的なデータフロー: 取り込みプロセス中の保護
Claude Opus 4.1のようにサポート終了が予定されるモデルを切り替えても、暗号化ポリシーが維持されるようIaCで設定を固定化します。
一時データも逃さない：メモリ内データの保護
Amazon Bedrock AgentCoreのA2A（Agent to Agent）連携などにより、プロンプトや思考プロセスが一時ストレージに書き込まれるリスクが高まっています。コンピュートリソースにはEBSボリュームの暗号化を強制し、可能な限りオンメモリで処理します。
- Amazon Bedrock: デフォルトで顧客データを学習に使用しません。ガードレール機能（POLICY SCENARIO）により入出力データの自動推論チェックも強化されています。
- SageMaker AI: 学習データやモデルアーティファクトは、必ずCMKで暗号化されたプライベートバケットに出力します。
API互換性が向上しても、意図しない場所にログが残らないよう厳密に管理します。
アクセス制御の最適化：IAMと最小権限の原則
VPC内でネットワークを物理的に隔離したとしても、システム内部のアクセス制御が甘ければデータガバナンスは機能しません。IAMを駆使し、ゼロトラストの観点からシステム内部のコンポーネント同士が必要最小限の権限で動作する設計を徹底します。これにより、万が一の内部犯行や乗っ取りリスクを最小化できます。
RAGコンポーネント間のIAMロール設計パターン
各コンポーネントに付与する権限は、具体的なアクションとリソースに限定して記述します。
- LLMへのアクセス: Amazon Bedrockなどを利用する場合、
bedrock:InvokeModelのみを許可し、リソース（ARN）で特定のモデルを厳密に指定します。2026年時点では、Bedrockの構造化出力対応モデルや、SageMaker JumpStartに追加されたDeepSeek OCRなど多数の選択肢がありますが、本番環境では検証済みの特定モデル・特定バージョンのみに権限を絞り込みます。 - ベクトルDBへのアクセス: Amazon OpenSearch Serverlessを利用する際、
aoss:APIAccessAllのような広範な権限は避けてください。特定のコレクションに対するReadやWriteに絞ることが基本です。最新のCollection Groups機能を活用し、異なるKMSキー間でOCU（OpenSearch Compute Unit）を共有しながら論理的な分離を保つ構成も、コスト最適化とセキュリティの両立に有効です。 - 実行環境の権限: AWS Lambda Durable Functionsを活用した複数ステップのAIワークフローを構築する場合、各ステップのLambda関数ごとに必要な権限を細分化して付与し、過剰な権限を持たせないように設計します。
人間とAIエージェントのアクセス権限分離
開発者や運用者と、RAGアプリケーション（AIエージェント）のIAMロールは明確に分離しなければなりません。Agentic AIの進化により、自律的にタスクをこなすマルチエージェント構成が増加しているため、以下の対策が推奨されます。
- エージェント権限の厳格化: AIエージェントのロールは原則として「読み取り専用」や「推論のみ」に制限します。AWS Lambda Managed Instancesなどを利用してエージェントを実行する場合でも、ホスト環境へのアクセス権限は最小限にとどめます。
- ガードレールの多層防御: Amazon Bedrockのガードレール機能を用いた自動推論チェックにより、不適切なプロンプトや不正なアクションをシステムレベルでブロックします。
- 人間による承認（Human-in-the-loop）: データの書き込みや重要な設定変更を伴う操作には、必ず人間の承認フローを挟む仕組みを構築します。
本番データベースへの直接クエリは原則として禁止します。デバッグやトラブルシューティングが必要な場合は、マスキングされたログを活用するか、一時的な特権アクセス（JITアクセス）の仕組みを利用して対応します。
ABAC（属性ベースアクセス制御）による動的な権限管理
静的なポリシー管理だけでは、組織の変更やプロジェクトの追加に追従しきれません。そこで、タグ（属性）ベースでアクセス権を制御するABAC（Attribute-Based Access Control）を導入します。
例えば、Project: HR というタグを持つベクトルDBのコレクションやドキュメントストレージには、同じ Project: HR タグを持つIAMロールのみがアクセスできるように設定します。この仕組みにより、部門間でデータ参照事故が起きるリスクを構造的に防ぐことができます。動的な権限管理を取り入れることで、運用負荷を下げつつ強固なガバナンスを維持できます。
トレードオフと運用コスト：セキュリティと引き換えにするもの
堅牢なアーキテクチャ導入に伴う代償についても触れておきます。プロジェクトのROIを最大化するためには、セキュリティ強化に伴うコストや利便性の低下というトレードオフを客観的に評価し、それを上回るビジネス価値を見極めることが不可欠です。
完全閉域化による運用負荷とコスト増の現実
コストの増加: AWS PrivateLinkは時間課金とデータ処理課金が発生し、複数AZ・複数サービス接続で月額数万円から数十万円の追加費用となるケースは珍しくありません。さらに、Amazon OpenSearch Serverlessを利用する場合もコスト管理が課題となりますが、最近追加されたCollection Groups機能により、異なるKMSキー間でのOCU（OpenSearch Compute Unit）共有が可能となり、コスト最適化の手段も提供されています。
運用負荷の増大: インターネット遮断環境では、ライブラリの導入やコンテナイメージの取得にプライベートリポジトリの構築が求められます。また、AIモデルのライフサイクル管理も重要な課題です。たとえば、OpenAIのGPT-4oなどのレガシーモデルは2026年2月13日にChatGPTでの提供を終了し、GPT-5.2への自動移行が進んでいます。API自体の提供は継続されるものの、最新モデルへの追従やプロンプトの再テストなど、継続的な運用体制の構築が不可欠となります。
パフォーマンスへの影響とレイテンシの許容範囲
暗号化処理やVPCエンドポイントを経由するネットワークルーティングにより、わずかにレイテンシが増加する傾向があります。ミリ秒単位の応答性能を求めるユースケースでは、事前の検証を強くお勧めします。
一方で、AWSのサーバーレス環境も進化を続けています。AIワークフローの複数ステップ処理において、AWS Lambda Durable Functionsを活用することで、チェックポイントからの再開が可能になり、長時間の推論タスクも安定して実行できるようになりました。また、Amazon Bedrockでは構造化出力のサポートが強化され、SageMaker JumpStartでもDeepSeek OCRなどの新モデルが継続的に追加されているため、推論速度と精度のバランスを取りながら要件に合わせた最適化が可能です。
それでも「安心」を選ぶべきビジネス上の理由
これらの運用負荷や追加費用は、システムを守るための「保険料」と捉えるべきです。機密情報の漏えい事故が発生した場合、その損害額や社会的信用の失墜はシステム構築費の比ではありません。
Amazon Bedrockの拡張されたガードレール機能と物理的なネットワーク隔離は、経営層やステークホルダーに対する強力な説得材料となります。このアーキテクチャを採用することで、「セキュリティリスクに対する不安によるAI活用の機会損失」を回避し、安全な環境下でイノベーションを推進できます。
継続的な運用最適化に向けて
運用コストとパフォーマンスのバランスを取るためには、最新の技術動向を常に把握し、アーキテクチャを定期的に見直す姿勢が大切です。たとえば、AWS Batchの拡張機能によるリソース最適化や、CloudWatchのアラームミュートルールを活用した運用担当者の負荷軽減など、マネージドサービスの新機能を積極的に取り入れることで、閉域網ならではの運用課題を段階的に解消できます。
まとめ
VPC内でのセキュアなRAG構築には、ネットワーク、暗号化、IAMなどの幅広い専門知識が求められます。しかし、これを実現すれば、外部の脅威に怯えることなくAIの可能性を最大限に引き出し、PoCに留まらない実用的なシステム運用が可能になります。Amazon BedrockやSageMaker AIといったサービスも、この堅牢な基盤の上でこそ真価を発揮します。
ポイントの再確認:
- 閉域網: PrivateLinkを活用してAPI通信をVPC内に閉じ込める。
- 暗号化: CMKを用いたエンベロープ暗号化により、データ主権を確実にする。
- 最小権限: IAMポリシーでコンポーネント間のアクセスを厳格に制限する。
まずは現在のRAG構成図からインターネットゲートウェイを外す設計を検討してみませんか？
次回は、この環境上でRAGアプリケーションをデプロイし、パフォーマンスチューニングを行う手順を解説します。
本記事の執筆にあたり、以下の公式情報や技術記事を参照しています。アーキテクチャ設計や運用計画を立てる際の参考にしてください。
これらのリソースを活用し、最適なセキュアAI環境の構築を進めてください。
コメント