面白説明おじさんになりたい はん です。
本記事は「生成AIセキュリティ対策シリーズ」の2本目です。前回の
生成AI時代のネットワーク制御」では、Netskopeを使った外向き通信の制御――アクセス先の制御、利用アカウントの制限、送信データの検査――を解説しました。まだお読みでない方はそちらもぜひ。
その記事で取り上げた対策は、生成AIセキュリティの基本であり、最優先で取り組むべきものです。
しかし、実はこれだけでは守りきれない領域があります。
誤解のないように言えば、問題はAIを使うことそのものではありません。問題は、どこで何が起きているか分からないまま利用が広がることです。従来のWebアクセス制御で十分だと思っていると、見えていない経路が残ります。セキュリティ事故は「派手な情報漏洩」より先に、統制不能――何が起きているか把握できない状態――として始まるのです。
本記事では、特定の製品から離れて、AIセキュリティの全体像を一般論として整理します。「そもそもAIの通信ってどこで発生するの？」というところから始めて、外向き通信の制御の守備範囲とその外側にあるリスクを明らかにしていきます。
「AIのセキュリティ」と聞くと、ChatGPTにうっかり機密情報を貼り付ける場面を思い浮かべる方が多いでしょう。もちろんそれも重要ですが、AIの利用形態は想像以上に多岐にわたります。
まずは「AIを使うと、どこからどこへ通信が飛ぶのか」を整理しましょう。
企業内でAIが利用される形態は、大きく以下の5つに分類できます。
| 利用形態 | 説明 | 具体例 |
|---|---|---|
| ① ブラウザ型 | Webブラウザから直接AIサービスを利用する | ChatGPT, Gemini, Claude |
| ② API型 | アプリケーションや開発ツールからAPIで呼び出す | OpenAI API, GitHub Copilot, Cursor |
| ③ エージェント型 | AIが自律的に複数のサービスと通信して作業する | MCP(Model Context Protocol)連携、AIエージェント |
| ④ SaaS組み込み型 | 既存のSaaS内にAIが組み込まれて動作する | Notion AI, Microsoft 365 Copilot, Google Workspace Gemini |
| ⑤ ローカル型 | 端末内でAIを実行する（外部への通信なし） | Ollama, LM Studio |
注目すべきは、①のブラウザ型だけでなく、②〜⑤のような「ブラウザを経由しない」利用形態が急速に拡大していることです。特に③のエージェント型は、AIが自律的に複数のサービスと通信するため、従来のWebアクセス制御の枠組みでは捉えきれません。
以下の図は、企業のPC（管理端末）から見たAI通信の全体像です。
この図の要点は、インライン型セキュリティが制御できるのは「管理端末から外へ出る通信」だけということです。端末の外で起きていること――AIサービス内部の処理、AIサービスからの外向き通信、SaaSに組み込まれたAIの動作――はインラインでは見えません。
前回記事で解説した対策は、まさにこの制御境界上で機能するものです。では、この境界の外にはどのようなリスクがあるのでしょうか。
各論に入る前に、「そもそも何のためにAIの通信を監視するのか」を整理しておきます。目的が明確でないと、対策が場当たり的になります。
| # | 目的 | 概要 |
|---|---|---|
| 1 | データ保護 | 機密情報・個人情報・ソースコード等がAIサービスへ流出することを防ぐ |
| 2 | 利用統制 | 会社が認めたAIサービスだけを、企業アカウントで利用させる。会社が把握していないAIの利用（いわゆるシャドーAI）を防ぐ |
| 3 | 行為規制 | AIのガードレールを意図的に回避する手法（プロンプトインジェクション、ジェイルブレイク等）によるAI悪用を検知・抑止する |
| 4 | 法令遵守 | 個人情報保護法、GDPR、業界規制等に対するコンプライアンスを確保する |
| 5 | 経済合理性 | AIサービスの利用料金が従量課金の場合、意図しない大量リクエスト（例：AIエージェントの暴走）で想定外のコストが発生することを防ぐ |
| 6 | 脅威防御 | AIサービスを経由したマルウェア配布、悪意あるコード生成、攻撃者との不正な通信（C2通信）等を検知する |
これら6つの目的に対して、最も即効性が高く広範囲に効くのが外向き通信の制御（専門用語ではEgress制御と呼びます）です。管理端末からインターネットへの通信を検査・制御することで、目的1〜6のすべてに一定の効果があります。
だからこそ、まず外向き通信の制御から着手するのが現実的です。ただし、それだけで十分かというと――そうではありません。
しかし、外向き通信の制御は万能ではありません。守れる範囲と守れない範囲を正しく認識することが重要です。
管理端末からAIサービスへの通信は、ブラウザ経由であれAPI経由であれ、インターネットを通過します。この通過点にインライン型セキュリティを配置すれば、以下の制御が可能です。
ブラウザ型（①）はもちろん、API型（②）やエージェント型（③）の通信も、端末から外へ出る時点で検査対象になります。
ここまで読むと「じゅうぶん守れるじゃないか」と感じるかもしれません。しかし、最も危ないのは、一部を制御できていることで全体も守れていると誤認することです。端末から出る通信を押さえただけでは、SaaS内で動くAIやサービス内部の処理は依然として死角に残ります。「何を防げるか」よりも、何が防げないかを把握していない状態のほうが危険です。
では、防げないのはどこか。図①の制御境界の外側、つまり「端末を出た後」と「そもそも端末を経由しない」ケースです。
| 記号 | 領域 | なぜ防げないか |
|---|---|---|
| A | AIサービスの内部処理 | データを送った後、AIサービス内部でどう扱われるか（学習利用、保存、第三者共有）は通信制御では見えない |
| B-1 | SaaS型AIの外向き通信 | AIサービスが別のサービスへ通信する場合（プラグイン、ツール連携等）、その通信は企業の制御外 |
| B-2 | プライベートAIの外向き通信 | 自社構築のAI基盤からの外向き通信。こちらは自社設計で制御可能だが、外向き通信の制御とは別のアプローチが必要 |
| C | SaaS組み込みAI | SaaSに組み込まれたAI機能が、SaaS内に保存されたデータを読み取る。ユーザーの端末を経由しないため、インラインでは捕捉不能 |
| D | 管理外デバイス | 私用端末やBYOD（個人所有端末の業務利用）からのアクセスにはセキュリティソフト（クライアントソフト）が入っていないため、インライン制御が効かない |
以降の各論では、A〜Dのそれぞれについて、どのようなリスクがあり、一般的にどう対処すべきかを掘り下げます。
データをAIサービスに送信した時点で、そのデータの扱いはサービス提供者に委ねられます。これは「信頼の委譲」であり、技術的な制御ではなく契約と評価の問題です。
厄介なのは、「送ってよかったのか」を後から検証する手段がないことです。データがどう保存され、学習に使われたかどうかを、企業側から技術的に確認することはできません。
AIサービスがプラグインやツール連携で別の外部サービスと通信するケースです。たとえばChatGPTのプラグインが外部APIを呼び出す場合、その通信は企業の管理端末を経由しません。
現実的に困るのは、プラグインや外部連携でどこまでデータが渡ったのか、企業側で追跡する術がないことです。「何が送られたか」すら分からない状態が生まれます。
技術的に企業側から遮断することは基本的にできません。契約とガバナンスで対処する領域です。
自社がクラウド上（AWS、Azure、GCP等）に構築したプライベートAI基盤の外向き通信です。B-1とは異なり、自社がインフラを管理しているため、技術的な制御が可能です。
ただし「自社管理だから安心」と油断すると落とし穴があります。RAGやAIエージェントが外部APIを呼び出す過程で、想定していなかった社内データの送信や、従量課金の急増が起きるケースがあります。
この領域は自社の設計力がそのままセキュリティレベルになるため、設計段階からセキュリティを組み込むことが重要です。
既存のSaaSにAI機能が組み込まれるケースが急速に増えています。Notion AI, Google Workspace Gemini, Salesforce Einstein, Microsoft 365 Copilot――これらのAIは、SaaS内に保存されたデータを読み取って処理します。
情報漏洩という分かりやすい形でなくても、過去に埋もれていた情報がAIの要約機能で再び表面化する――これがSaaS組み込みAI特有の厄介さです。
なお、SaaS組み込みAIには大きく2つのタイプがあります。
いずれの場合も、権限管理の棚卸しが対策の基本である点は共通です。権限を尊重するタイプであっても、「過剰な権限が付与された状態でAIが読む」なら結果は同じだからです。
この領域は、ネットワーク制御では基本的に対処できません。SaaS内部でAIがデータを読む行為は、ユーザーの端末を経由しないためです。対策の本質はデータガバナンス――「誰が何にアクセスできるか」を適切に管理することです。
私用端末やBYOD（個人所有端末の業務利用）からAIサービスにアクセスされた場合、セキュリティソフト（クライアントソフト）が入っていないため、インライン制御が一切効きません。
管理端末を前提にどれだけ精緻な対策を組んでも、私用端末からアクセスされた瞬間にすべて迂回される。これが管理外デバイスの根本的な問題です。
この領域の制御ポイントは認証基盤（IdP）が主軸です。ネットワーク制御製品は補助的な役割に留まります。
本記事で見てきたように、AIセキュリティは「ネットワークで通信を止める」だけでは完結しません。外向き通信の制御は最優先かつ最も即効性の高い対策ですが、それはあくまで5本柱のうちの1本です。
| 柱 | 役割 | 具体的な手段 | 主な対象領域 |
|---|---|---|---|
| ① 通信の制御 | 端末やAI基盤から外へ出る通信を検査・制御する | 外向き通信の制御（SWG/CASB/DLP）、テナント制御、コーチング、AI Gateway（AI基盤→外部） | 全領域の基盤。AI Gatewayは特にB-2（プライベートAI）に有効 |
| ② 認証基盤 | 認証・認可の一元管理、条件付きアクセス | 認証基盤（IdP/SSO）によるデバイス評価、管理外デバイスのブロック | D（管理外デバイス）への最も有効な対策 |
| ③ エンドポイント | 端末上のソフトウェア管理、端末レベルのデータ検査 | 端末管理ツール（MDM）、セキュリティ監視ツール（EDR）、エンドポイントDLP | ローカルAIの制御、未承認ツールの検知 |
| ④ データガバナンス | アクセス権限の管理、SaaS設定の継続監査 | 共有権限の棚卸し、SaaS側のAI設定管理、設定監視ツール（SSPM）、API経由の監査（CASB API） | C（SaaS組み込みAI）、A（内部処理）の根本対策 |
| ⑤ 契約・評価 | AIサービスの事前評価、利用規約・データ取扱契約の確認 | サービスリスク評価、データ取扱契約（DPA）・SLA条項の確認、利用ガイドライン策定 | A（内部処理）、B-1（SaaS型外向き通信）の唯一の手段 |
AIセキュリティは、1つの製品カテゴリで完結するテーマではありません。通信、認証、端末、データガバナンス、契約・評価――どれか1本の柱だけでは、必ず見えない領域が残ります。
重要なのは「完璧に止めること」ではなく、どこまで見えていて、どこから先が別の対策領域なのかを明確にすることです。自社の現状を5本柱に照らし合わせたとき、「この柱はまだ手をつけていない」と気づけるかどうか。そこがセキュリティの成熟度を分けるポイントです。
次回では、「では具体的にNetskopeはこの5本柱のうちどこに効くのか？」を詳しく解説します。ネットワーク制御の専門家であるNetskopeが、自らの守備範囲とその限界をどう定義しているかを見ていきましょう。
では、よいセキュリティライフを。