Vertex AIでのGeminiモデル微調整（Tuning）による業界特化型AIの作成方法

Vertex AI Gemini微調整：金融・医療級のデータ保護を実現する「閉域網」特化型アーキテクチャ設計

2026年1月5日更新 2026年3月20日約17分で読めます

文字サイズ:

Vertex AI Gemini微調整：金融・医療級のデータ保護を実現する「閉域網」特化型アーキテクチャ設計

自社データでAIを賢くしたい。でも、そのデータが漏れたら終わりだ。

「業界特有の専門用語や社内ルールをGeminiに教え込みたい。しかし、学習データには顧客の個人情報や極秘の技術仕様が含まれている」

エンタープライズ企業のAIプロジェクトにおいて、このジレンマは最初の壁として立ちはだかります。特に金融機関や医療機関、あるいは高度な知的財産を持つ製造業にとって、精度の高い特化型AIモデルは非常に魅力的です。しかし、セキュリティ部門の承認を得ることは、技術的な実装よりも難しい場合があります。ここで立ち止まっていては、ビジネスのスピードに乗り遅れてしまいます。

Google CloudのVertex AIは、まさにこの「矛盾」を解決するために設計されています。一般的なSaaS型のAIチャットボットとは異なり、インフラレベルでの徹底的なデータ分離と閉域網（プライベートネットワーク）構築が可能です。

本記事では、単にGeminiの精度を上げる方法ではなく、「最高レベルのセキュリティ要件を満たしながら、いかにして安全に微調整（チューニング）を行うか」というアーキテクチャ設計に焦点を当てます。VPC Service ControlsやCMEKといったGoogle Cloud独自の強力なセキュリティ機能を駆使し、会社のデータを保護する方法を、具体的なコードと共に解説していきます。

リスクを恐れてAI導入を躊躇する段階はもう終わりです。技術の本質を見極め、安全かつスピーディーにAI開発のプロトタイプを動かし始めるための第一歩を踏み出しましょう。

なぜ「業界特化AI」の自社開発でセキュリティが最大の壁になるのか

まずは、直面している課題の本質を解き明かすことから始めましょう。なぜ標準的な設定のままAIモデルをチューニングしてはいけないのでしょうか？企業が抱える「漠然とした不安」を、技術的なリスクシナリオとして明確に定義します。

SaaS型AI利用と自社チューニングのリスク境界線の違い

ChatGPTやGeminiのWeb版（コンシューマー向け）を利用する場合と、Vertex AI上で自社専用のアダプターモデルを学習させる場合では、リスクの所在が全く異なります。

Web版を利用する場合、主な懸念は入力データがサービス提供側のモデル改善に使われる可能性（オプトアウト設定の有無）にあります。これは「データの二次利用」リスクです。一方、自社でチューニングを行う場合、リスクは「学習プロセスそのもの」と「生成されたモデルの管理」にシフトします。

チューニングとは、基盤モデルに対して大量のテキストデータを読み込ませ、パラメータを調整する行為です。このプロセスにおいて、以下のようなリスクが発生します。

データの一時的な露出: 学習ジョブを実行する際、データはストレージからGPU/TPUインスタンスへ移動します。この通信経路がインターネットを経由している場合、中間者攻撃のリスクが生じます。
モデルによる機密情報の記憶: モデルが学習データ内のクレジットカード番号や患者名をそのまま「暗記」してしまう現象（Memorization）です。最新の大規模言語モデル（LLM）はコンテキスト理解力が向上しているため、悪意あるプロンプトによって、これらの情報が巧みに引き出される恐れがあります。

学習データに含まれる機密情報（PII/PHI）の漏洩シナリオ

例えば、契約書データのOCR（光学文字認識）結果をそのまま学習データとして使用した場合を想像してみてください。

最新のAI-OCR技術は、従来読み取りが困難だった手書き文字や複雑な帳票レイアウト、さらには印影に含まれる文字情報までも高精度にデジタル化できるようになっています。業務効率化の観点では大きな進歩ですが、セキュリティの観点では「意図しない機密情報の混入」リスクが高まっていることを意味します。取引先担当者の氏名や個人の識別情報が、ノイズとして処理されず、正確なテキストデータとして学習パイプラインに乗ってしまうのです。

もし、このデータを使って作成したモデルが攻撃を受けた場合、あるいは権限のない社員がモデルを利用した場合、何が起きるでしょうか？

「取引先の担当者の連絡先を教えて」とモデルに尋ねるだけで、学習データに含まれていた非公開の携帯番号が出力されてしまう可能性があります。これは、従来のデータベースからの漏洩とは異なり、「モデルの振る舞い」として情報が漏れるため、従来のセキュリティ対策での検知が極めて困難です。

Google Cloudの「責任共有モデル」におけるユーザーの責務

クラウドセキュリティには「責任共有モデル」という大原則があります。Googleはインフラの物理的なセキュリティやハイパーバイザーの脆弱性対策に責任を持ちます。しかし、「その上で何を動かすか」「誰にアクセス権を与えるか」「データをどう暗号化するか」は、完全にユーザーの責任です。

Vertex AIを使うからといって、自動的に安全になるわけではありません。これから紹介するVPC Service ControlsやIAM設定を行わなければ、AIパイプラインは「鍵のかかっていない金庫」と同じ状態になる可能性があります。

Vertex AIが提供する「データ分離」と「暗号化」の多層防御アーキテクチャ

Vertex AIが提供する「データ分離」と「暗号化」の多層防御アーキテクチャ - Section Image

リスクばかりを強調するだけでは意味がありません。ここからは、Google Cloudが用意している解決策を見ていきましょう。Vertex AIは、エンタープライズ利用を前提とした多層防御の仕組みを持っています。

アダプターチューニング方式によるベースモデルの凍結と安全性

Geminiの微調整において、Googleが採用しているのは「アダプターチューニング（Adapter Tuning）」という手法です。これはセキュリティの観点から非常に重要です。

従来のファインチューニングでは、巨大なモデルの全パラメータを更新していました。しかし、アダプター方式では、基盤となるGeminiモデル（プレトレーニング済みモデル）は凍結され、一切変更されません。 代わりに、比較的小さな「アダプター層」と呼ばれる追加のパラメータ群のみを学習させます。

これによるセキュリティ上のメリットは大きいです。

データ混入の防止: データはアダプター層の学習にのみ使用され、Googleが管理する基盤モデルには混入しません。他のユーザーのモデルに影響を与えることも、逆に影響を受けることもありません。
テナント分離: 学習済みのアダプターは、Google Cloudプロジェクト内の専用ストレージに保存され、テナントごとの厳格な分離が保証されます。

顧客管理暗号鍵（CMEK）による学習データとモデルの完全制御

Google Cloudでは、デフォルトで全てのデータが保存時に暗号化されています（Google管理鍵）。しかし、機密性の高いプロジェクトではこれでは不十分です。「Googleの管理者であってもデータを見られない状態」を作る必要があります。

そこで登場するのがCMEK（Customer-Managed Encryption Keys）です。これは、暗号化の鍵をユーザー自身がCloud KMS（Key Management Service）で作成・管理する仕組みです。

学習データの暗号化: Cloud Storage上のデータセットをCMEKで暗号化。
モデルの暗号化: 生成されたアダプターモデルもCMEKで暗号化。
一時データの暗号化: 学習ジョブ中に生成される一時ファイルも含めて暗号化。

万が一、セキュリティインシデントが発生した場合や、契約終了時にデータを完全に破棄したい場合、この「鍵」を無効化（破棄）するだけで、データは即座に復号不可能（Crypto-shredding）となり、実質的な削除が完了します。これは物理的な削除を待つよりも遥かに迅速で確実な方法です。

データレジデンシー：学習データの保存場所を国内に限定する設定

GDPRや日本の個人情報保護法、あるいは業界規制により、データの保存場所（リージョン）が制限される場合があります。Vertex AIでは、学習ジョブの実行リージョンとデータの保存リージョンを明示的に指定できます。

例えば、asia-northeast1（東京）リージョンを指定すれば、データ処理と保存は日本国内で完結し、国境を越えることはありません。これにより、データ主権（Data Sovereignty）に関する法的リスクを回避できます。

【実装編1】学習データを「持ち出さない」ための閉域網設計（VPC Service Controls）

【実装編1】学習データを「持ち出さない」ための閉域網設計（VPC Service Controls） - Section Image

ここからが本記事の核心です。インフラエンジニアやセキュリティアーキテクトの皆様が最も関心を持つであろう、インターネットからのアクセスを完全に遮断し、データの持ち出し（Exfiltration）を防ぐための「VPC Service Controls (VPC SC)」の実装について、実践的な視点から解説します。

VPC Service Controls（VPC SC）によるサービス境界の構築

通常のIAM（権限管理）だけでは、権限を持つユーザーがデータを個人のGoogleドライブにコピーしたり、自宅のPCからダウンロードしたりすることを完全に防ぐことは難しいです。VPC SCは、プロジェクト全体を「サービス境界（Service Perimeter）」という見えない壁で囲い込む機能です。

境界の中にあるリソース（Vertex AI, Cloud Storage, BigQueryなど）は、境界の外側からのアクセスを一切受け付けなくなります。また、境界の中から外側へのデータ送信もブロックされます。

以下は、Terraformを用いてVPC SCの境界を定義するサンプルコードです。これにより、Vertex AIとCloud Storageを保護対象として囲い込みます。

resource "google_access_context_manager_service_perimeter" "secure_ai_perimeter" {
  parent = "accessPolicies/${var.policy_id}"
  name   = "accessPolicies/${var.policy_id}/servicePerimeters/secure_ai_perimeter"
  title  = "Secure AI Perimeter"
  
  status {
    restricted_services = [
      "aiplatform.googleapis.com",      # Vertex AI
      "storage.googleapis.com",         # Cloud Storage
      "containerregistry.googleapis.com" # Container Registry
    ]

    # 境界内からのアクセスを許可するVPCネットワークを指定
    access_levels = [google_access_context_manager_access_level.corporate_network.name]
    
    vpc_accessible_services {
      enable_restriction = true
      allowed_services   = ["RESTRICTED-SERVICES"]
    }
  }
}

このコードを適用することで、指定されたAPIへのアクセスは、許可されたネットワーク（例えば社内VPN経由のIPアドレス）からのみ可能となり、それ以外のインターネットアクセスは遮断されます。

インターネットを経由しないPrivate Service Connect接続

学習ジョブを実行する際、Vertex AIのマネージドサービスとVPCネットワークとの間で通信が発生します。これをインターネット経由にしないために、Private Service Connect (PSC) または Private Google Access を利用します。

特にPSCを利用すると、Vertex AIのAPIエンドポイントに対して、VPC内部のプライベートIPアドレスを割り当てることができます。これにより、トラフィックはGoogleのバックボーンネットワーク内のみを通り、パブリックインターネットには一切出ません。

Cloud Storageバケットへのアクセス制限とデータ持ち出し防止

VPC SCを設定しても、Cloud Storageの設定が適切でなければ意味がありません。バケットレベルでのアクセス制御リスト（ACL）の使用は避け、「均一なバケットレベルのアクセス（Uniform Bucket-Level Access）」を有効にしましょう。これにより、IAMによる集中管理が強制されます。

さらに、VPC SCの「下りルール（Egress Rules）」を厳格に設定することで、権限を持つ管理者であっても、境界内のバケットから境界外（例えば個人のGmailアカウントに関連付けられたプロジェクト）へデータをコピーする操作をブロックできます。

【実装編2】学習データの「無毒化」と最小権限のIAM設計

ネットワークの堅牢性を確保した後は、データそのものと、それを扱う「人」の制御へとステップを進めましょう。

Cloud DLPを用いた個人情報（PII）の自動検出とマスキング

最も安全なデータとは、「漏れても被害がないデータ」です。学習を開始する前に、Cloud Data Loss Prevention (DLP) を使用して、データセット内の機密情報を無毒化しましょう。

Cloud DLPは、氏名、住所、電話番号、クレジットカード番号などを自動的に検出し、マスキング（隠蔽）やトークン化（置換）を行うサービスです。

実践的なパイプライン例:

生データを「Rawデータ用バケット（高セキュリティ）」にアップロード。
Cloud Functions等がトリガーされ、DLP APIを呼び出す。
DLPがPIIを検出し、[PERSON_NAME] [PHONE_NUMBER] といったタグに置換。
無毒化されたデータを「学習用バケット」に保存。
Vertex AIはこの「学習用バケット」のみを参照してチューニングを行う。

これにより、モデルは個人情報を学習することなく、文脈や業界知識だけを習得できます。

チューニングジョブ専用サービスアカウントの作成と権限分離

「誰がジョブを実行するか」も重要です。個人のユーザーアカウントでジョブを実行するのは避け、専用のサービスアカウント（Service Account: SA）を作成してください。

そして、このSAには必要最小限の権限（Least Privilege）のみを与えます。

Vertex AI User: ジョブの作成と実行のみ許可。
Storage Object Viewer: 学習データの読み取りのみ許可（書き込み不可）。
KMS CryptoKey Encrypter/Decrypter: 指定されたCMEK鍵の使用のみ許可。

以下は、サービスアカウントに最小権限を付与するTerraformの例です。

resource "google_project_iam_binding" "ai_job_sa_permissions" {
  project = var.project_id
  role    = "roles/aiplatform.user"

  members = [
    "serviceAccount:${google_service_account.tuning_job_sa.email}",
  ]
}

# バケットへの読み取り権限のみ付与（書き込みは許可しない）
resource "google_storage_bucket_iam_binding" "dataset_read_only" {
  bucket = google_storage_bucket.training_data.name
  role   = "roles/storage.objectViewer"

  members = [
    "serviceAccount:${google_service_account.tuning_job_sa.email}",
  ]
}

学習データセットへのアクセスログ監査設定

「誰がいつデータにアクセスしたか」を追跡するために、Cloud Audit Logsを有効化します。特に「データアクセスログ（Data Access Logs）」はデフォルトでは無効になっている場合があるため、明示的にONにする必要があります。

これにより、storage.objects.get（ファイルのダウンロード）などの操作が全て記録され、不正なアクセスの予兆を検知できるようになります。

運用フェーズ：特化型モデルへのアクセス制御とライフサイクル管理

バケットへの読み取り権限のみ付与（書き込みは許可しない） - Section Image 3

モデルが完成してプロトタイプが動いたからといって、そこで終わりではありません。むしろ、そこからがビジネス環境におけるセキュリティ運用の本番です。

エンドポイントへのアクセス制御と推論リクエストの監視

チューニング済みのGeminiモデルは、Vertex AIのエンドポイントとしてデプロイされます。このエンドポイントへのアクセスも、IAMによって厳格に管理する必要があります。

アプリケーションサーバー（またはBFF）からのみアクセスを許可し、開発者のローカルPCなどからの直接アクセスは避けるべきです。ここでもVPC SCが効力を発揮します。

また、推論リクエストの内容（プロンプト）とレスポンスをログとして保存し、定期的に監査することも推奨されます。ただし、ログ自体に機密情報が含まれる可能性があるため、ログバケット自体もCMEKで暗号化し、アクセス制限をかけることを忘れないでください。

モデルバージョニングと古いモデルの安全な廃棄手順

AIモデルは、時間とともに精度が低下する可能性があります。データが古くなれば精度が落ちるだけでなく、古いコンプライアンス基準で作られたモデルがリスクになることもあります。

Vertex AI Model Registryを活用してバージョン管理を行い、一定期間が経過したモデルや、精度基準を満たさなくなったモデルは計画的に廃棄（削除）するフローを確立しましょう。前述の通り、CMEKを使用していれば、鍵の破棄によって論理的に完全削除が可能です。

セキュリティインシデント発生時の緊急遮断フロー

万が一、モデルが悪用されたり、予期せぬ挙動（ハルシネーションによる不適切な発言など）が見られたりした場合に備え、「キルスイッチ」を用意しておく必要があります。

具体的には、エンドポイントへのトラフィックを即座に遮断するファイアウォールルールや、モデルのデプロイを強制的に解除するスクリプトを準備し、運用マニュアルに記載しておきます。自動検知システムと連動させ、異常なリクエスト数を検知したら自動的に遮断する仕組みも検討する価値があります。

社内セキュリティ審査を突破するためのチェックリスト

ここまで解説してきた技術的な対策は、社内のセキュリティ審査や稟議を通すための根拠となります。最後に、情報システム部門を説得するためのチェックリストをまとめました。

CIS Google Cloud Foundation Benchmarkとの照合

セキュリティ審査では、「客観的な基準に準拠しているか」が問われます。CIS (Center for Internet Security) ベンチマークは、業界標準のセキュリティ基準です。

「本プロジェクトのアーキテクチャは、CIS Google Cloud Foundation Benchmark v2.0の推奨事項（IAMの最小権限、VPC SCの使用、ロギングの有効化など）に準拠して設計されています」と説明することで、説得力が増します。

ISO/IEC 27001, 27017対応項目の整理

もし貴社がISMS認証（ISO 27001）を取得している場合、クラウドセキュリティ管理策（ISO 27017）への対応も求められます。

アクセス制御: IAMとVPC SCによる多層防御
暗号化: CMEKによる保存データの暗号化とTLSによる通信の暗号化
ログ監視: Cloud Audit Logsによるトレーサビリティの確保

これらが網羅されていることを示し、コンプライアンス上の懸念がないことを証明しましょう。

経営層・セキュリティ部門への説明用テンプレート

経営層やセキュリティ部門を説得する稟議書には、以下のロジックを盛り込むと効果的です。

ビジネス価値: 特化型AIにより業務効率が向上する見込み。
リスク認識: 情報漏洩リスクがあることを認識している。
対策の具体性: VPC SCによる閉域網構築とCMEKによる暗号化により、物理的な持ち出しと論理的な不正アクセスを技術的に遮断する。
残存リスク: 残るリスクは管理者権限の乗っ取りだが、これも多要素認証（MFA）とハードウェアキーにより対策済みである。

まとめ：技術に裏打ちされた「安心」が、AI活用のスピードを加速させる

「セキュリティか、イノベーションか」という二者択一は、過去のものになりつつあります。Google CloudとVertex AIの機能を正しく理解し、適切なアーキテクチャを組むことで、「堅牢性」と「最新AIの利便性」は両立できます。

今回解説したVPC Service Controls、CMEK、Adapter Tuningといった技術は、初期の実装に少し手間がかかるかもしれません。しかし、これらを組み込むことで得られる「データは確実に守られている」という技術的な裏付けこそが、アジャイルで大胆なAI活用を推進する強力なエンジンとなります。

もし、インフラ環境に合わせた具体的なネットワーク設計や、VPC SCの詳細な設定ポリシー策定にお悩みであれば、専門家への相談を検討することをおすすめします。セキュリティポリシーに合致した、AI導入ロードマップを描き、安全な商用利用への第一歩を踏み出しましょう。

Vertex AI Gemini微調整：金融・医療級のデータ保護を実現する「閉域網」特化型アーキテクチャ設計 - Conclusion Image

コメントは1週間で消えます

コメントを読み込み中...