はじめに
「生成AIは便利だが、社内データが学習に使われて外部に流出するのが怖い」
実務の現場では、多くのCIOやITアーキテクトからこの懸念が提示されます。特に金融業界やヘルスケア業界、製造業など機密情報を扱う環境において、これは乗り越えるべき「壁」です。
企業向けに正しく設計された環境であれば、データ学習や漏洩のリスクは低減できます。多くの誤解は、個人向け無料ツール（コンシューマー版）のリスクを企業向けプラットフォーム（エンタープライズ版）に当てはめることから生じています。Google CloudのVertex AI経由で提供されるGemini Pro 1.5は、コンシューマー版とは異なる法的な契約と技術的な基盤の上に成り立っています。
本記事では、「いかにしてデータを守り抜くか」というアーキテクチャ設計に焦点を当てます。Google Cloud特有のセキュリティ機能であるVPC Service ControlsやIAMを組み合わせた「3つの防衛線」を構築し、コンプライアンス部門も納得できるAI基盤を作る方法を解説します。
セキュリティはAI導入のブレーキではなく、ビジネスのアクセルを全開にするために不可欠な要素です。技術の本質を見抜き、最短距離で安全なAI活用を実現していきましょう。
なぜ企業利用では「ブラウザ版」ではなく「Vertex AI経由」一択なのか
まず、システム設計の根幹となる「どの入り口からGeminiを使うか」という点について整理しましょう。ここを間違えると、どんなに高度なセキュリティ対策も意味を成しません。
データプライバシー規約の決定的な違い
Webブラウザでアクセスするコンシューマー向けのGeminiと、API経由で利用する「Vertex AI上のGemini」は、データを取り扱うルールが根本的に異なります。
コンシューマー版では、サービス向上のために入力データがレビュアーに確認されたり、モデルの再学習に使われたりするケースがあり、企業にとって看過できないリスクです。
一方、Vertex AI経由での利用は、Google Cloudのエンタープライズ契約が適用されます。ここには以下の原則が明記されています。
- 学習への不使用: 顧客のデータ（プロンプト、回答、チューニング用データ）は、基盤モデルの再学習に一切使用されません。
- データ所有権: データは顧客に帰属し、Googleが権利を主張することはありません。
- データの分離: 他の顧客のデータと混ざることはなく、論理的かつ厳格に分離されています。
Vertex AIを選択した時点で、「勝手に学習される」リスクは契約レベルで排除されます。
SLA（サービス品質保証）と責任共有モデル
ビジネス利用では可用性やサポート体制も重要です。Vertex AIはエンタープライズグレードのSLAを提供し、システムダウン時の補償や24時間365日のサポート体制が整っています。
また、クラウドセキュリティの「責任共有モデル」の理解も不可欠です。インフラの物理的セキュリティや基盤モデルの安全性はGoogleが責任を持ちますが、「誰にアクセスさせるか」「どのデータを参照させるか」の設定はユーザー企業側の責任です。この責任範囲を技術的に守る方法が、次章から解説する「3つの防衛線」です。
企業資産としてのAIモデル管理と高度なガバナンス
Vertex AIを利用するもう一つの理由は、AIモデルを「バージョン管理されたソフトウェア資産」として扱える点です。
ブラウザ版はモデル更新が自動で行われるため、アップデートでプロンプトの挙動が変わる事態が起こり得ます。一方、Vertex AIでは特定のバージョン（例: gemini-2.5-pro-001）に固定して利用でき、業務プロセスの安定性を担保できます。経営者視点で見れば、この「予測可能性」は極めて重要です。
さらに、Vertex AIでは高度な管理機能が提供されています。
- ライフサイクル管理: 古いモデルバージョン（例: Geminiなど）の廃止スケジュールが明確にアナウンスされ、計画的な移行が可能です。
- 組織的なガバナンス: 最新のAgent Builderでは、開発者が利用できるツールやエージェントを管理者が一元的に制御でき、「誰がどの外部ツールを使えるか」といったガバナンスを効かせられます。
- リアルタイム処理への対応: 軽量なAIモデル Live API**の一般提供により、音声・映像・テキストを統合した低遅延なリアルタイム対話システムもセキュアに構築可能です。
予測可能性と統制を確保できる点が、企業がVertex AIを選択すべき技術的な根拠となります。
防衛線①：ネットワークレベルでの完全遮断設計
ここから具体的なアーキテクチャの話に入ります。最初の防衛線は「ネットワーク」です。どれだけ認証を強化しても、データがインターネット経由でやり取りされる限り、経路上のリスクや設定ミスによる公開リスクはゼロになりません。プロトタイプ開発の段階から、この外堀を意識することが重要です。
VPC Service Controlsによる境界防御
Google Cloudには、指定したリソース（Vertex AI、Cloud Storageなど）の周囲に論理的な「境界」を張り巡らせるVPC Service Controls (VPC-SC) という強力な機能があります。
これはデータセンターがインターネットから完全に隔離されたドームに覆われている状態です。正規の権限を持つユーザーであっても、許可されていないネットワークからデータを持ち出すことは不可能です。
VPC-SCを適用することで、以下の事故を論理ネットワーク的に防げます。
- 開発者によるCloud Storageバケットの誤った「公開」設定。
- 社員による社内データの個人Gmailアカウントへのコピー。
- マルウェア感染サーバーからの外部C&Cサーバーへのデータ送信。
Gemini 1.5 Proや、新たに一般提供が開始されたGemini Live APIを利用する際も、VPC-SCの境界内にAPIエンドポイントを配置することが重要です。これにより、テキストや音声、動画などのマルチモーダルデータを含め、プロンプトや回答が境界外へ流出するのを防ぎます。
Private Service Connectを用いた閉域接続
社内のオンプレミス環境やVPC内のサーバーから「ドーム内」のGeminiにアクセスするには、Private Service Connect (PSC) を使用します。PSCを使うことで、プライベートIPアドレスを通じてVertex AIにアクセスできるようになります。
これにより、通信はすべてGoogleのバックボーンネットワーク内、および自社の専用線やVPNの中だけで完結します。データがパブリックなインターネットに出ないため、盗聴や中間者攻撃のリスクを低減できます。
インターネットへのデータ流出を防ぐ出口対策
生成AIアプリ開発において、外部Webサイトを検索させる場合を除き、AIサーバー自体がインターネットへの外向き通信（Egress）を持つ必要はありません。
ファイアウォールルールで外向き通信を遮断し、Vertex AIへの通信のみを許可する「ホワイトリスト方式」を採用すべきです。これにより、サーバー内部に侵入されても、攻撃者がデータを外部に持ち出す経路を塞げます。Agent Engine等で自律的なエージェントを構築する場合、予期せぬ外部アクセスを防ぐためにも出口対策は不可欠です。
防衛線②：IAMとRAGによるデータアクセス制御の適正化
ネットワークで外堀をしっかりと固めたら、次は内側の守りです。つまり「誰が、どのデータを使ってAIに回答させてよいか」という認証・認可の制御を整備する必要があります。AIを全社展開する時代において、このデータアクセス制御は最も重要な防衛線の一つと言えます。
最小権限の原則に基づくIAM設計
Google CloudのIAM（Identity and Access Management）を設計する際、基本かつ最重要なアプローチは「サービスアカウント」と「ユーザーアカウント」を明確に分離することです。
アプリケーションが裏側でAIモデルを呼び出す際は、必ず専用のサービスアカウントを使用します。この際、Vertex AI Userといった、そのタスクを実行するために必要な最小限の権限のみを付与する運用が推奨されます。OwnerやEditorのような強力すぎる権限を付与することは、万が一のインシデント発生時に被害を拡大させる要因となるため避けるべきです。
一方で、開発者や運用担当者がコンソールにアクセスする際は、個人のユーザーアカウントを使用します。本番環境への定常的なアクセスは厳格に制限し、特権ID管理（PAM）などを導入して、必要な作業が発生した時だけ一時的に権限を付与する「Just-in-Timeアクセス」の運用を構築することが理想的なセキュリティ対策となります。
Vertex AI Searchにおけるドキュメント単位の権限継承
RAG（検索拡張生成）システムを構築し、社内の多様なドキュメントをAIに参照させる際、多くの企業が直面する最大の課題があります。それは、「本来閲覧する権限のない従業員が、AIへの質問を通じて機密情報を引き出してしまう」というリスクです。
例えば、経営会議の議事録や人事評価データを含むドキュメントをRAGのデータソースに格納したと仮定します。もし一般社員の質問に対してAIがそれらの機密データを参照して回答を生成してしまえば、重大なコンプライアンス違反に直面します。
Vertex AI Searchは、この複雑な問題に対応するACL（アクセスコントロールリスト）連携機能を備えています。Google DriveやSharePointなどのデータソースが元々持っている権限情報をインデックス化の段階で取り込み、ユーザーが検索を実行する際の権限とリアルタイムで照らし合わせます。
これにより、「AIへの質問者が、そのドキュメントを直接閲覧する権限を持っている場合のみ、検索結果のコンテキストに含める」という高度な制御が自動で行われます。既存の社内セキュリティポリシーやアクセス権限の階層を崩すことなく、安全にRAGを導入するための強力な仕組みです。
グラウンディング（根拠付け）によるハルシネーション抑制とセキュリティ
Gemini 1.5 Proや、推論性能が前世代から2倍以上に向上した最新の後継モデルであるGemini 3.1 Pro（2026年2月リリース）は、非常に長大なコンテキストウィンドウを持っています。そのため、大量の業務文書やマニュアルをプロンプトに直接含め、複雑な問題解決やデータ統合を行わせることが可能です。
しかし、セキュリティと回答品質の両面を考慮すると、何でもかんでもコンテキストに詰め込むのではなく、必要な情報だけを厳選してモデルに渡す「グラウンディング（根拠付け）」のプロセスが極めて重要になります。
Vertex AIのグラウンディング機能を活用すれば、AIの生成した回答が社内ドキュメントのどの部分を根拠にしているのかを明確に示すことができます。これは単に情報の正確性を担保しハルシネーション（もっともらしい嘘）を抑制するだけでなく、「AIがどの機密情報にアクセスし、どのデータを参照して回答したか」を後から監査可能にするため、セキュリティ対策の観点でも大きな意味を持ちます。
RAGシステムの運用においては、不正確な回答が時として誤った業務判断やセキュリティリスクの引き金になる可能性があります。適切な評価指標を用いてシステムの健全性を継続的にモニタリングし、グラウンディングによる透明性を確保し続けることが、企業データを守る強固な防衛策となります。
防衛線③：監査ログとモニタリングによる透明性の確保
最後の防衛線は「監視」です。事故を未然に防ぐ努力と共に、万が一何かが起きた時に「何が起きたか」を追跡できる体制が必要です。
Cloud Audit Logsで記録すべき4つのログタイプ
Google Cloudの統合ログ基盤 Cloud Audit Logs を用い、AIシステムでは以下のログを取得・保存します。
- 管理アクティビティログ: モデルのデプロイやVertex AI Agent Builderの設定変更など、管理操作の記録。
- データアクセスログ: Gemini APIの呼び出しや参照されたドキュメントの記録。デフォルトではオフの場合があるため、明示的にオンにします。
- システムイベントログ: Google Cloud側のメンテナンスや障害情報の記録。
- ポリシー拒否ログ: VPC-SCなどのセキュリティポリシーによってブロックされたアクセスの記録。
これらのログをCloud Storageに長期保存し、BigQueryにエクスポートして分析可能な状態にしておくことが監査対応の第一歩です。
プロンプトと回答のトレーサビリティ確保
金融機関をはじめとする厳格なコンプライアンスが求められる環境では、AIが不適切な回答をしなかったかを事後検証できることが求められます。
アプリケーション側で、ユーザーのプロンプトとAIの回答のペアをすべてログとして記録する設計にします。ここで注意すべきは、Geminiが提供するマルチモーダル機能です。テキストだけでなく、画像、動画、リアルタイム音声（Live API）などの非テキストデータについても、メタデータや要約テキストと紐付けてトレーサビリティを確保する設計が求められます。
ただし、個人情報（PII）が含まれる可能性があるため、ログへのアクセス制限を厳重にするか、Cloud DLP (Data Loss Prevention) APIを使ってマイナンバーなどをマスキングしてから保存する処理を組み込むべきです。
異常検知アラートの設定基準
ログ取得に加え、異常検知時の即座な通知も必要です。Cloud Monitoringのアラート機能を使い、以下の兆候を監視します。
- API利用量の急増: 認証情報漏洩による不正利用や、無限ループによる暴走の可能性。
- VPC-SC拒否の多発: 内部からのデータ持ち出しの試みや、設定ミスの可能性。
- 高額なコスト発生: クオータ上限に近づいている警告。
ダッシュボードでの可視化も重要です。
やってはいけない「アンチパターン」とセキュリティリスク
成功事例だけでなく、アンチパターンを知ることも重要です。以下は、一般的な開発現場で散見される「危険な構成」と、それが引き起こすセキュリティリスクです。
APIキーのハードコーディングと漏洩リスク
最も初歩的かつ重大なミスが、ソースコード内にAPIキーやサービスアカウントキーを直接書き込むハードコーディングです。
認証情報が誤ってリポジトリにプッシュされれば、攻撃者に即座に検知され、クラウド資源を不正利用される可能性があります。Secret Scanningなどの検出機能もありますが、防御の基本は「そもそもコードに含めない」ことです。
対策: APIキーではなく、Application Default Credentials (ADC) を使用します。認証情報はコードに含めず、実行環境（Vertex AI WorkbenchやCloud Runなど）に紐付いたサービスアカウントの権限を自動的に利用する設計にし、漏洩リスクを根本から断ち切ります。
過剰な権限を持つサービスアカウントの使い回し
Owner権限を持つ強力なサービスアカウントを作成し、すべての用途で同じアカウントキーを使い回すケースも危険です。
1つのキーが漏洩しただけで全システムが掌握される危険性があり、監査ログを見ても操作元の特定が不可能になります。
対策: 最小権限の原則（PoLP） を徹底します。システムや環境ごとにサービスアカウントを分割し、必要最小限のIAMロールのみを付与します。サービスアカウントキーのダウンロードは避け、Workload Identity 連携を活用したキーレス認証の実装を強く推奨します。
検証環境と本番環境の境界曖昧化
PoC環境をそのまま本番運用にスライドさせるパターンです。PoC環境はスピード優先でセキュリティ設定が緩められていることが多く、データ保護の観点で脆弱です。
対策: 本番環境は、PoC環境とは完全に切り離された別のGoogle Cloudプロジェクトとして新規構築します。Infrastructure as Code (Terraform等) を用い、セキュリティポリシーが組み込まれた環境をコードから自動構築できるようにするのが理想的なアプローチです。
成熟度別：セキュアAI基盤の導入ロードマップ
セキュリティとガバナンスは、一足飛びに完成させるものではなく、段階的にレベルを引き上げていくアプローチが一般的です。組織の成熟度に合わせて、以下のロードマップを参考に導入を進めることをお勧めします。
フェーズ1：サンドボックス環境での技術検証
- 目的: 最新モデル（Gemini 3.1 Proなど）の基本性能確認、マルチモーダル入力の挙動検証。公式情報によると、Gemini 3.1 Proは複雑な問題解決において推論性能が前バージョンと比較して大幅に向上しています。
- データ: 公開情報またはダミーデータのみ。機密データは利用しません。
- セキュリティ: デフォルトのVPC設定。開発環境でのアクセス制御。
- ゴール: AIモデルの推論能力で何が実現できるかの感触を掴み、具体的な利用シナリオを想定します。まずはReplitやGitHub Copilotなどのツールも活用しつつ、スピーディーに仮説検証を回していくのがよいでしょう。
フェーズ2：社内限定データでのPoC
- 目的: 実際の業務データを使ったRAGの精度検証およびエージェント機能の挙動確認。一般提供が開始されたCloud SQL for MySQLとの統合機能を活用し、データベースから直接モデルを呼び出すセキュアなアーキテクチャの検証も有効です。
- 検証項目:
- Agent Engine: トピックベースのメモリ機能による文脈維持の精度。
- Gemini Live API: マルチモーダル対応の高スループット環境でのレイテンシ確認。
- データ: 特定部門の社内データ（個人を特定できる情報を含まないもの）。
- セキュリティ: 専用プロジェクトの作成。VPC-SCの適用（学習モード）。監査ログの有効化。
- ゴール: 業務効率化の仮説検証と、セキュリティ設定のひな形（ブループリント）作成。プロビジョンド スループット（PT）の予約など、本番を見据えたリソース計画も検討します。
フェーズ3：全社展開と継続的なセキュリティ評価
- 目的: 全社員向けチャットボット、業務システムへの組み込み、高度な検索基盤の構築。Vertex AI Searchなどのアップグレード機能を活用し、大規模なデータに対する高精度な検索を実現します。
- データ: 全社のナレッジベース、機密データ（DLP適用による保護を前提）。
- セキュリティ:
- VPC-SCの完全適用（強制モード）。
- Agent Builderのガバナンス機能: 組織全体で利用可能なツールやエージェントを一元管理。
- IAMの厳格化とCI/CDパイプラインによる自動デプロイ。
- SOC運用の開始。
- ゴール: 高度なガバナンスが効いた状態での全社的なAI活用とエコシステムの確立。
まとめ：技術的な「防御」は揃っている。あとは踏み出すだけ。
Google CloudとVertex AIは、企業が懸念するデータ漏洩や学習利用のリスクに対し、多層的な防御策を提供しています。特にGeminiやAgent機能においては、エンタープライズレベルのセキュリティが前提として設計されています。
- 契約による保証: 顧客データをモデルの学習に利用しないという明確な方針。
- ネットワーク: 閉域網（VPC-SC）でデータ境界を強固に保護。
- IAM: 最小権限の原則に基づいた緻密なアクセス制御。
- ガバナンス: Agent Builder等で組織全体の利用ポリシーを徹底。
- ログ: 監査ログですべての操作を記録・追跡。
これらを組み合わせることで、厳格なセキュリティ要件を満たすシステム構築が可能です。セキュリティへの懸念からAI活用を見送ることは、技術的な制約というよりも心理的なハードルによるものが大きいと考えられます。
重要なポイントは、これらの機能を正しく理解し、自社のセキュリティポリシーに合わせて適切に設計することです。
まずは安全なサンドボックス環境で、最新のGeminiのパフォーマンスを体感してみてください。「まず動くものを作る」というアプローチで実際にシステムを検証することで、セキュリティへの漠然とした不安は具体的な実装課題へと変わり、解決への明確な道筋が見えてくるはずです。皆さんの現場では、どのような課題から着手できそうでしょうか？
次の一歩を踏み出し、セキュアな環境でAIの可能性を最大限に引き出すことを検討してみてはいかがでしょうか。
コメント