AI研修では「自由に試せる環境」と「安全性」の両立が必要
企業で生成AI研修を実施する際、意外に見落とされやすいのが「受講者がAIを実際に操作する環境」の設計です。
生成AI研修は、講義を聞くだけでは十分とはいえません。
プロンプトを入力する、ファイルを読み込ませる、Pythonコードを実行する、APIを利用する、AIエージェントを動かすなど、実際に手を動かすことで理解が深まります。
しかし、自由度を高めるほどセキュリティ上のリスクも増えていきます。
例えば、研修環境から社内ネットワークへアクセスできてしまったり、誤って機密情報を外部AIサービスへ送信したり、受講者が実行したコードから外部サイトへ通信できたりすれば、研修そのものが新たなセキュリティリスクになりかねません。
そこで重要になるのが「サンドボックス環境」です。
サンドボックスとは、利用者が自由に操作できる一方で、その影響範囲を限定した隔離環境です。
AI研修向けのサンドボックスでは、単に仮想マシンを用意するだけではなく、
- コンピューティング環境
- GPU
- ネットワーク
- ストレージ
- ユーザー権限
- 外部AI API
- AIエージェント
といった複数のレイヤーを分離して設計する必要があります。
AI研修用サンドボックスを構成する4つの基本レイヤー
安全なAI研修環境を考える際には、大きく4つのレイヤーに分けると整理しやすくなります。
コンピューティング環境の分離
最初に必要なのが、受講者ごとの実行環境を分離することです。
例えばJupyterLabを利用する場合でも、複数の受講者が同じOS環境を共有する設計では、一人の操作が他の受講者へ影響する可能性があります。
そのため、
- 仮想マシン
- コンテナ
- Kubernetes Pod
などを利用し、受講者単位で実行環境を分離します。
特に受講者数が多い研修では、Kubernetesを利用して受講者ごとにPodを起動する方式が有効です。
必要になったときだけ環境を作成し、研修終了後に削除することで、セキュリティだけでなく運用効率も高められます。
GPUの分離
生成AI研修ではGPUを利用するケースも増えています。
例えば、
- LLMの推論
- ファインチューニング
- 画像生成
- 機械学習モデルの学習
などです。
しかしGPUを複数ユーザーで共有する場合、CPUやメモリとは異なる分離設計が必要になります。
資料では、NVIDIA MIGなどのGPU分割技術や、GPU Operatorなどを利用したKubernetes上でのGPU管理について説明されています。
研修環境では、単に「GPUが使える」だけではなく、
「誰が、どのGPUリソースを、どの範囲まで利用できるか」
を管理することが重要です。
ネットワークの分離
AI研修環境で特に重要なのがネットワークです。
受講者が自由にコードを実行できる環境から、
- 社内サーバー
- データベース
- 管理システム
- クラウド内部サービス
などへアクセスできてしまう構成は避けなければなりません。
基本的には、
「必要な通信だけを許可し、それ以外は拒否する」
というDefault Denyの考え方を採用します。
これはゼロトラストの考え方とも共通しています。
データとストレージの分離
受講者が作成したNotebook、アップロードしたファイル、生成したデータなどについても分離が必要です。
受講者Aのファイルを受講者Bが閲覧できる状態では、十分なサンドボックスとはいえません。
そのため、
- ユーザー単位のストレージ
- Namespace単位のアクセス制御
- IAMによる権限管理
などを組み合わせます。
AWS・Google Cloud・Azureで構築する場合のポイント
サンドボックス環境は主要クラウドサービス上でも構築できます。
資料では、AWS、Google Cloud、Microsoft Azureについて、それぞれプライベートネットワークを前提とした構成が示されています。
AWSの場合
AWSではAmazon SageMaker Studioなどを利用できます。
企業研修で利用する場合は、インターネットへ直接接続する構成ではなく、VPC-onlyモードを利用してネットワークを制御する方法が考えられます。
さらに、
- VPC Endpoint
- PrivateLink
- IAM
- Security Group
- S3アクセス制御
などを組み合わせます。
重要なのは、研修環境から必要なサービスにだけ接続できる構成にすることです。
Google Cloudの場合
Google CloudではVertex AI Workbenchを利用した構成が考えられます。
Private Google AccessやVPC Service Controlsなどを利用することで、外部インターネットへの依存を抑えながらGoogle Cloud上のAIサービスを利用できます。
資料では、Cloud NATなどを利用してインターネット通信の出口を管理する方法についても触れられています。
Microsoft Azureの場合
Azure Machine LearningではManaged Virtual Networkを利用できます。
研修環境全体を管理された仮想ネットワーク内に配置し、
- Storage Account
- Container Registry
- Key Vault
などへの通信をPrivate Endpoint経由にすることで、インターネットへ露出する範囲を抑えることができます。
多人数研修ではKubernetesが有力な選択肢になる
数人程度の研修であれば、受講者ごとに仮想マシンを用意する方法でも対応できます。
しかし、
数十人、数百人規模の研修になると、環境の作成・削除・管理が大きな負担になります。
そこで有力になるのがKubernetesです。
例えば、
受講者がログイン
↓
専用Podを自動作成
↓
JupyterLabを起動
↓
CPU・メモリ・GPUを割り当て
↓
研修終了後にPodを削除
という仕組みを構築できます。
資料ではJupyterHubとKubeSpawnerを利用したマルチユーザー環境が取り上げられています。
KubernetesのResourceQuotaなどを利用すれば、ユーザーごとに利用できるリソース量も制御できます。
その結果、一人の受講者が大量のGPUやメモリを使用し、他の受講者の研修環境が利用できなくなるといった問題も防ぎやすくなります。
NetworkPolicyで受講者間の通信を遮断する
Kubernetesを利用しただけでは、ネットワークが自動的に安全になるわけではありません。
そこで重要になるのがNetworkPolicyです。
まず基本方針として、すべての通信を拒否します。
そのうえで、
- DNS
- 認証サービス
- プロキシ
- 必要なAIサービス
など必要な通信のみを個別に許可します。
特に注意したいのが、クラウドのメタデータAPIです。
クラウド環境ではインスタンスメタデータ経由で認証情報などにアクセスできる場合があります。
そのため、受講者環境からメタデータAPIへのアクセスを遮断する設計も重要です。
AIエージェント研修では従来以上のセキュリティ対策が必要
近年はChatGPTなどの生成AIだけでなく、AIエージェントを利用した研修も増えています。
AIエージェントは、
- Web検索
- API利用
- ファイル操作
- コード実行
- 外部サービスとの連携
などを自律的に行う場合があります。
ここが通常の生成AI研修との大きな違いです。
資料では、AIエージェント特有のリスクとして、プロンプトインジェクションなどによって意図しないツール実行が発生する可能性が取り上げられています。
そのため、AIエージェント研修ではさらに、
外部通信先を限定する
利用できるAPIやWebサイトをAllowlist方式で限定します。
ファイル書き込み範囲を限定する
AIエージェントがアクセスできるフォルダを研修用領域だけに限定します。
コマンド実行権限を制限する
OS全体を操作できる権限を与えず、必要なツールのみ利用できる設計にします。
Human-in-the-loopを導入する
重要な操作については、AIが自動実行するのではなく、人間による承認を必要とする仕組みを設けます。
AIエージェント時代のサンドボックスでは、
「利用者を制限する」
だけでなく、
「AIそのものが実行できる操作を制限する」
という考え方が必要になります。
ローカルLLMを利用して外部AIへのデータ送信を防ぐ
機密情報を扱う研修では、OpenAIやAnthropicなど外部AI APIへデータを送信できない場合があります。
その場合はローカルLLMをサンドボックス内部で稼働させる方法があります。
資料では、
- vLLM
- Ollama
- llama.cpp
- TensorRT-LLM
- LocalAI
など複数の推論基盤が紹介されています。
ローカルLLMを利用すれば、入力したデータを研修環境内部にとどめながら生成AI研修を行うことができます。
ただし、モデルの運用やGPU管理が必要になるため、
「機密性」と「運用コスト」
のバランスを考えることが重要です。
AI研修サンドボックスの実践的な構築手順
実際に環境を設計する場合は、次のような順序で進めると整理しやすくなります。
1．研修で利用する機能を整理する
まず、
- Chat型生成AI
- Python
- JupyterLab
- AI API
- ファイルアップロード
- GPU
- AIエージェント
など、研修で必要な機能を整理します。
2．扱うデータの機密度を決める
公開情報だけを扱う研修なのか、社内データを使用する研修なのかによって必要なセキュリティレベルは変わります。
3．外部通信先を決める
必要なWebサイトやAPIだけを許可し、それ以外の通信を原則遮断します。
4．受講者環境を分離する
VM、コンテナ、Kubernetesなどを利用して、受講者同士の環境を分けます。
5．CPU・メモリ・GPUを制限する
ユーザーごとに利用可能なリソース上限を設定します。
6．認証とアクセス権限を設定する
社内ID、SSO、IAMなどと連携し、誰が研修環境を利用しているかを管理できる状態にします。
7．ログを取得する
問題が発生した際に、
「誰が、いつ、どの環境を利用したか」
を確認できるログを残します。
8．研修終了後に環境を自動停止する
GPUインスタンスは稼働時間に応じてコストが増えるため、研修終了後に自動停止する仕組みを用意することが重要です。
資料でもAWS、Google Cloud、Kubernetes環境におけるアイドルリソースの自動停止が重要な設計要素として扱われています。
「強固な環境」を作ることだけが目的ではない
AI研修用サンドボックスでは、セキュリティを高めれば高めるほどよいわけではありません。
制限が強すぎると、
- AI APIが利用できない
- 必要なライブラリをインストールできない
- 外部ドキュメントを参照できない
- AIエージェントを十分に試せない
といった問題が発生します。
研修環境で重要なのは、
「安全性を確保しながら、学習に必要な自由度をどこまで残すか」
という設計です。
企業ごとに、
- 研修内容
- 参加人数
- 利用する生成AI
- データの機密度
- 既存クラウド環境
は異なります。
そのため、すべての企業に共通する一つの正解があるわけではありません。
まとめ
生成AI研修の高度化に伴い、研修環境そのもののセキュリティ設計が重要になっています。
特にAIエージェントやコード実行型AIを利用する場合、従来の「アカウントを作成してAIサービスを使わせる」という研修方式だけでは十分ではありません。
今後の企業AI研修では、
- 受講者環境の分離
- GPUリソースの管理
- プライベートネットワーク
- Default Denyによる通信制御
- Kubernetesによるマルチテナント管理
- AIエージェントの権限制御
- ローカルLLM
- 自動停止によるコスト管理
といった仕組みを組み合わせたサンドボックス環境が重要になります。
AIを安全に活用できる人材を育成するためには、操作方法を教えるだけではなく、安全に試行錯誤できる環境そのものを企業側が整備することが、AI研修の基盤となるのです。
コメント