面白説明おじさんになりたい はん です。
生成AIの業務活用が当たり前になりつつあります。ChatGPT、Gemini、Claude、Copilot――名前を挙げればきりがありませんが、これらのツールは業務効率を劇的に高める一方で、企業のセキュリティ担当者に新たな頭痛の種を提供してくれています。
本エントリでは、生成AIがもたらすセキュリティリスクを整理し、「禁止」ではなく「安全に活用」するためのネットワーク制御の考え方と、Netskopeによる具体的な実装を解説します。
「便利だから使いたい」と「危険だから止めたい」の間で揺れている企業は多いでしょう。判断のために、まずはリスクの全体像を把握しましょう。
多くの生成AIサービスは、無料プランやデフォルト設定では、ユーザーが入力したデータをモデルの学習や機能改善に利用します。つまり、社内の機密情報――顧客データ、ソースコード、戦略文書――をプロンプトに入力すれば、それがモデルの糧になり、最悪の場合は他のユーザーへの応答に影響を与える可能性があります。
企業向け有料プランでは「学習に使わない」と明示するサービスも増えていますが、従業員が個人アカウントで利用した場合、その保証は及びません。
個人アカウントで生成AIを利用した場合、以下の問題が生じます。
要するに、個人アカウントで生成AIを使うことは「セキュリティの鎖の最も弱い環」を自ら作り出す行為に等しいのです。
生成AIへの情報漏洩は、単に「どこにアクセスしたか」だけの問題ではありません。何を送信したかが本質的な問題です。
企業が守るべき情報は多岐にわたります。
アクセス先を制御するだけでは不十分で、送信されるデータの中身をリアルタイムで検査し、機密情報の流出を水際で止める仕組みが必要です。
生成AI特有の攻撃手法としてプロンプトインジェクションがあります。これは、巧みに設計されたプロンプトでAIのガードレールを迂回し、本来出力すべきでない情報を引き出したり、意図しない動作をさせる手法です。
企業が自社で構築したRAG（検索拡張生成）システムや、AIエージェントが社内データにアクセスできる環境では、プロンプトインジェクションによる内部データの抜き取りが現実的な脅威となります。
また、従業員が悪意を持って（あるいは無自覚に）機密データを生成AIに食わせ、外部に持ち出すケースも想定しなければなりません。
1章で整理したリスクに対して、企業はどのような対処をすべきでしょうか。セキュリティ戦略としての考え方を整理します。
生成AIサービスは多種多様であり、すべてが同じリスクレベルではありません。データの取り扱いポリシー、学習への利用有無、暗号化水準、コンプライアンス対応――サービスごとに大きな差があります。
「生成AIだから危険」と一括りにするのではなく、各サービスのリスクを評価し、企業利用に耐えるサービスを選別することが出発点です。リスク評価の観点としては以下が挙げられます。
選別した結果、「認可するサービス」と「認可しないサービス」を明確にし、ネットワークレベルでアクセス制御を行います。
認可サービスであっても、個人アカウントで利用されては意味がありません。1-2で述べた通り、個人アカウントは企業のセキュリティ統制が及びません。
同じChatGPTやGeminiでも、企業契約のテナント（インスタンス）と個人アカウントではデータ保護のレベルが天と地ほど違います。企業テナントのみを許可し、個人アカウントでのアクセスを遮断するテナント制御が不可欠です。
1-3で述べた通り、「どこにアクセスするか」の制御だけでは情報漏洩は防げません。企業テナントであっても、ソースコードやクレデンシャル、顧客リストが無制限に入力されるのはリスクです。
送信されるデータの中身をリアルタイムで検査し、機密情報を含む通信をブロックまたは警告する仕組みが必要です。これはDLP（Data Loss Prevention）の領域であり、従来のファイル転送だけでなく、生成AIへのテキスト入力にも適用すべきです。
制御は「ブロックして終わり」ではありません。なぜブロックされたかを従業員に伝え、正しい利用方法を案内するリアルタイムコーチングが、セキュリティ意識の向上に直結します。叱るよりも諭す方が効く、というのは人もシステムも同じです。
プロンプトインジェクションのようなAI特有の脅威は、従来のSaaS向けセキュリティでは対応しきれません。生成AIの利用パターン――「テキスト入力」という行為自体がデータ送信である――を理解した上で、文脈ベースの検知・防御が求められます。
2章で対処を整理しましたが、ここで改めて「全面禁止」という選択肢について触れておきます。
「危ないなら全部止めればいい」――一見合理的ですが、この方針は長続きしません。
必要なのは「使わせない」ではなく「安全に使わせる」ための制御です。ここからはNetskopeを使った具体的な実装を解説します。
2章で述べた対処方針を、Netskopeの機能でどう実装するかを見ていきます。
[対応：2-1. 生成AIの善し悪しを見極めて選ぶ]
NetskopeのApp Catalog（旧Cloud Confidence Index Database）は、85,000以上のSaaSアプリケーションを評価しており、その中で1,800以上が生成AIカテゴリに分類されています。各サービスについて、学習へのデータ利用有無、データ保存場所、第三者共有、暗号化水準、コンプライアンス対応状況などを評価し、リスクスコアとして提供しています。
管理コンソール > Settings > Security Cloud Platform > App Catalog で確認可能です。「このAIは企業利用に耐えるのか」を客観的データに基づいて判断できます。
また、管理コンソール > Skope IT > Application Events で、実際に社内でどの生成AIが使われているかをトラフィックベースで可視化できます。「うちの社員、こんなにAIサービス使ってたのか」と驚く管理者は少なくありません。
例として、Google GeminiとDeepSeekを挙げます。顧客データの学習(Customer data for learning)やテナント間のデータ分離(Tenant isolation or private instances for GenAI)等に差があるのが分かります。
[対応：2-1. 認可サービスのみ利用させる]
App Catalogで評価した結果をもとに、NetskopeのSWG（Secure Web Gateway）とCASB（Cloud Access Security Broker）で実際のアクセス制御を行います。
管理コンソール > Policies > Real-time Protection にて、まずGenerative AIカテゴリ全体をブロックするポリシーを作成し、その上位に認可済みサービスの許可ポリシーを配置します。Netskopeはポリシーを上から順に評価するため、この順序が重要です。
これにより、企業が評価・認可したサービスだけを利用させ、それ以外の野良AIサービスへのアクセスを確実に遮断できます。
[対応：2-2. 企業テナントのみ許可する]
Netskopeのインスタンス認識機能を使えば、同じサービスでも企業テナントと個人アカウントを区別して制御できます。
管理コンソール > Policies > Real-time Protection にて [NEW POLICY] ボタンから [Cloud App Access] を選択
これにより、従業員は企業が契約したChatGPT Enterprise/Teamのみを利用でき、個人アカウントでの利用は遮断されます。1-2で述べた「個人アカウントの落とし穴」を根本から断つ制御です。
[対応：2-3. 経路だけでなくデータ内容を検査する]
NetskopeのDLP（Data Loss Prevention）機能は、生成AIへのアップロード・入力内容をリアルタイムで検査し、機密データの流出を防止します。
管理コンソール > Policies > Real-time Protection にて [NEW POLICY] ボタンから [Cloud App Access] を選択
DLPプロファイルにはNetskopeのビルトイン辞書（PCI、PHI、PII等）を活用できるため、一からルールを作る必要はありません。ソースコード検知やクレデンシャル検知のプリセットも用意されています。
[対応：2-4. 禁止ではなく導く]
Netskopeは違反時にユーザーの端末上にリアルタイムでコーチング通知を表示できます。「このサービスは社内ポリシーにより利用できません。承認済みのサービスはこちらです」といったメッセージで、従業員を正しい利用へ導きます。
単にブロックするよりも、なぜブロックされたかを伝える方が、従業員のセキュリティ意識向上に効果的です。
またブロックするだけでなく警告を発した上で利用を継続させることも可能です。
[対応：2-5. AI特有の脅威に対応する]
Netskopeは従来のCASB/DLPに加え、AI Security Guardrailsという生成AIに特化した防御機能の提供を開始しています。これはコンテンツモデレーション（監視・管理）サービスで、従来のDLPでは検知が難しかった文脈ベースのデータ流出や、プロンプトインジェクションの兆候を検出します。
生成AIの利用パターンは従来のSaaS利用とは異なります。「テキスト入力」という行為自体がデータ送信であり、ファイルアップロードとは別の経路でデータが流出し得ます。AI Security Guardrailsはこの特性を理解した上で設計されています。
ここまでの内容を整理すると、以下の多層防御となります。
| リスク（1章） | 対処方針（2章） | Netskope実装（4章） |
|---|---|---|
| サービスごとのリスク差 | 善し悪しを評価し選んで使う | App Catalog / CCI |
| 野良AIサービスの利用 | 認可サービスのみアクセス許可 | SWG / CASB |
| 個人アカウント利用 | 企業テナントのみ許可 | インスタンス認識 |
| 機密データの流出 | データ内容をリアルタイム検査 | DLP |
| プロンプトインジェクション | AI特有の脅威を文脈ベースで検知 | AI Security Guardrails |
| 従業員のセキュリティ意識 | リアルタイムコーチングで教育 | User Notification |
重要なのは、これらが単一のNetskopeプラットフォーム上で一元管理できることです。ポイントソリューションを複数導入して管理が煩雑になる、という事態を避けられます。
生成AIの利用を「禁止する」時代は終わりました。今求められているのは「安全に使わせる」ための制御です。
生成AIは正しく使えば強力な武器になります。しかし制御なき利用は、鍵をかけずに玄関を開けっ放しにしているのと同じです。Netskopeで「見えない通信」を可視化し、適切に制御して、AIの恩恵を安全に享受しましょう。
では、よいNetskopeライフを。