AIセキュリティの全体像：外向き通信の制御だけでは守れない【生成AIセキュリティ対策シリーズ】

面白説明おじさんになりたい はん です。

本記事は「生成AIセキュリティ対策シリーズ」の2本目です。前回の

生成AI時代のネットワーク制御」では、Netskopeを使った外向き通信の制御――アクセス先の制御、利用アカウントの制限、送信データの検査――を解説しました。まだお読みでない方はそちらもぜひ。

その記事で取り上げた対策は、生成AIセキュリティの基本であり、最優先で取り組むべきものです。

しかし、実はこれだけでは守りきれない領域があります。

誤解のないように言えば、問題はAIを使うことそのものではありません。問題は、どこで何が起きているか分からないまま利用が広がることです。従来のWebアクセス制御で十分だと思っていると、見えていない経路が残ります。セキュリティ事故は「派手な情報漏洩」より先に、統制不能――何が起きているか把握できない状態――として始まるのです。

本記事では、特定の製品から離れて、AIセキュリティの全体像を一般論として整理します。「そもそもAIの通信ってどこで発生するの？」というところから始めて、外向き通信の制御の守備範囲とその外側にあるリスクを明らかにしていきます。

1. 前提知識：AIの通信はどこで発生するのか

「AIのセキュリティ」と聞くと、ChatGPTにうっかり機密情報を貼り付ける場面を思い浮かべる方が多いでしょう。もちろんそれも重要ですが、AIの利用形態は想像以上に多岐にわたります。

まずは「AIを使うと、どこからどこへ通信が飛ぶのか」を整理しましょう。

1-1. AIの利用形態

企業内でAIが利用される形態は、大きく以下の5つに分類できます。

注目すべきは、①のブラウザ型だけでなく、②〜⑤のような「ブラウザを経由しない」利用形態が急速に拡大していることです。特に③のエージェント型は、AIが自律的に複数のサービスと通信するため、従来のWebアクセス制御の枠組みでは捉えきれません。

1-2. 制御境界の全体像

以下の図は、企業のPC（管理端末）から見たAI通信の全体像です。

この図の要点は、インライン型セキュリティが制御できるのは「管理端末から外へ出る通信」だけということです。端末の外で起きていること――AIサービス内部の処理、AIサービスからの外向き通信、SaaSに組み込まれたAIの動作――はインラインでは見えません。

前回記事で解説した対策は、まさにこの制御境界上で機能するものです。では、この境界の外にはどのようなリスクがあるのでしょうか。

2. AIの通信を監視する6つの目的

各論に入る前に、「そもそも何のためにAIの通信を監視するのか」を整理しておきます。目的が明確でないと、対策が場当たり的になります。

これら6つの目的に対して、最も即効性が高く広範囲に効くのが外向き通信の制御（専門用語ではEgress制御と呼びます）です。管理端末からインターネットへの通信を検査・制御することで、目的1〜6のすべてに一定の効果があります。

だからこそ、まず外向き通信の制御から着手するのが現実的です。ただし、それだけで十分かというと――そうではありません。

3. 外向き通信の制御で防げる範囲と防げない範囲

しかし、外向き通信の制御は万能ではありません。守れる範囲と守れない範囲を正しく認識することが重要です。

3-1. 外向き通信の制御で防げること

管理端末からAIサービスへの通信は、ブラウザ経由であれAPI経由であれ、インターネットを通過します。この通過点にインライン型セキュリティを配置すれば、以下の制御が可能です。

• 会社が認めていないAIサービスへのアクセスブロック
• 個人アカウントでの利用制限（企業が契約したアカウントだけで利用させ、個人アカウントでの利用を遮断する「テナント制御」）
• 送信データのリアルタイム検査（データ漏洩防止：DLP）
• 利用状況の可視化・ログ記録
• リアルタイムのユーザーコーチング（なぜブロックされたかを通知し、正しい利用へ導く）

ブラウザ型（①）はもちろん、API型（②）やエージェント型（③）の通信も、端末から外へ出る時点で検査対象になります。

ここまで読むと「じゅうぶん守れるじゃないか」と感じるかもしれません。しかし、最も危ないのは、一部を制御できていることで全体も守れていると誤認することです。端末から出る通信を押さえただけでは、SaaS内で動くAIやサービス内部の処理は依然として死角に残ります。「何を防げるか」よりも、何が防げないかを把握していない状態のほうが危険です。

3-2. 外向き通信の制御で防げないこと

では、防げないのはどこか。図①の制御境界の外側、つまり「端末を出た後」と「そもそも端末を経由しない」ケースです。

以降の各論では、A〜Dのそれぞれについて、どのようなリスクがあり、一般的にどう対処すべきかを掘り下げます。

4. リスク各論

4-1. A：AIサービスの内部処理 ― 信頼の委譲

データをAIサービスに送信した時点で、そのデータの扱いはサービス提供者に委ねられます。これは「信頼の委譲」であり、技術的な制御ではなく契約と評価の問題です。

厄介なのは、「送ってよかったのか」を後から検証する手段がないことです。データがどう保存され、学習に使われたかどうかを、企業側から技術的に確認することはできません。

リスク

• 学習利用：投入データがモデルの学習に使用され、他ユーザーへの応答に影響する可能性
• データ保存：プロンプトと応答がサービス側に保存され、サービス提供者の従業員やシステムからアクセス可能な状態になる
• 第三者共有：サービスの裏側で使われている外部の委託先（クラウドインフラ事業者など）にデータが渡る可能性
• 法域の問題：データが国外のデータセンターに保存・処理される場合、現地政府による法的なデータ開示要求のリスク

対策の方向性

• サービス評価：学習利用の有無、データ保存ポリシー、暗号化水準、コンプライアンス認証（SOC2、ISO27001等）を事前に評価
• 契約による担保：データの取り扱いに関する契約（DPA）の締結、SLA条項の確認
• プランの選定：多くのサービスでEnterprise/Businessプランは「学習に利用しない」を明示。無料・個人プランとの差を理解する
• 認可サービスの限定：評価を通過したサービスのみ利用を許可し、それ以外をブロック（→ 外向き通信の制御と連携）

4-2. B-1：SaaS型AIの外向き通信 ― 制御不能、契約で対処

AIサービスがプラグインやツール連携で別の外部サービスと通信するケースです。たとえばChatGPTのプラグインが外部APIを呼び出す場合、その通信は企業の管理端末を経由しません。

現実的に困るのは、プラグインや外部連携でどこまでデータが渡ったのか、企業側で追跡する術がないことです。「何が送られたか」すら分からない状態が生まれます。

リスク

• AIに投入したデータが、プラグイン経由で意図しない第三者サービスに送信される
• プラグインの脆弱性を通じたデータ漏洩
• AIサービスがどの外部サービスとツール連携しているのか、自社のセキュリティ管理者からは把握・制御する手段がない

対策の方向性

• プラグイン/連携機能の利用制限：管理コンソールでプラグインを無効化、または許可リスト方式で管理
• 契約による担保：サービス提供者の外部委託先リスト確認、データの流れの開示要求
• 利用ガイドラインの策定：「プラグインを有効にする場合は情シスの承認を得ること」等のルール整備

技術的に企業側から遮断することは基本的にできません。契約とガバナンスで対処する領域です。

4-3. B-2：プライベートAIの外向き通信 ― 自社設計で制御可能

自社がクラウド上（AWS、Azure、GCP等）に構築したプライベートAI基盤の外向き通信です。B-1とは異なり、自社がインフラを管理しているため、技術的な制御が可能です。

ただし「自社管理だから安心」と油断すると落とし穴があります。RAGやAIエージェントが外部APIを呼び出す過程で、想定していなかった社内データの送信や、従量課金の急増が起きるケースがあります。

リスク

• 社内データを検索・参照して回答を生成する仕組み（RAG：検索拡張生成）を使っている場合、参照した社内データが外部API呼び出し時に送信されてしまう
• AIエージェントが自律的に外部サービスと通信し、意図しないデータ流出が発生する
• 開発・検証段階でのセキュリティ設定の不備

対策の方向性

• AI Gateway（APIゲートウェイ）の配置：プライベートAIの外向き通信をゲートウェイ経由に集約し、データ検査・ログ記録・利用量制限を実施
• ネットワーク設計：クラウド環境のネットワーク設定で、AIシステムの通信先を必要最小限に制限する
• プロンプト/レスポンスの検査：ゲートウェイ層で不正なプロンプトの検知やデータ分類を実施
• コスト制御：AI利用量の監視とアラート設定（エージェントの暴走対策）

この領域は自社の設計力がそのままセキュリティレベルになるため、設計段階からセキュリティを組み込むことが重要です。

4-4. C：SaaS組み込みAI ― データガバナンスの問題

既存のSaaSにAI機能が組み込まれるケースが急速に増えています。Notion AI, Google Workspace Gemini, Salesforce Einstein, Microsoft 365 Copilot――これらのAIは、SaaS内に保存されたデータを読み取って処理します。

情報漏洩という分かりやすい形でなくても、過去に埋もれていた情報がAIの要約機能で再び表面化する――これがSaaS組み込みAI特有の厄介さです。

なお、SaaS組み込みAIには大きく2つのタイプがあります。

• ユーザーの権限を尊重するもの（例：Microsoft 365 Copilot）：そのユーザーがアクセスできるデータのみをAIが参照する。適切な権限管理がなされていればリスクは限定的
• 広範なデータにアクセスするもの：管理者権限やシステム権限でSaaS内のデータを横断的に参照する。共有設定の見直しが急務

いずれの場合も、権限管理の棚卸しが対策の基本である点は共通です。権限を尊重するタイプであっても、「過剰な権限が付与された状態でAIが読む」なら結果は同じだからです。

リスク

• 過剰な権限での情報アクセス：共有設定が緩いと、本来見るべきでないデータもAIが参照し、応答に含めてしまう
• 意図しないデータの要約・表面化：AIが過去の議事録や古いドキュメントを要約して提示することで、忘れられるべきだった情報が再浮上する
• AI機能のオプトアウト困難：SaaSベンダーがAI機能をデフォルトで有効化し、無効化のオプションが限定的なケース

対策の方向性

• データガバナンスの徹底：SaaS内のアクセス権限・共有設定を定期的に棚卸し。過剰な共有を是正する
• SaaS側のAI設定管理：管理コンソールでAI機能の有効/無効を制御。データ処理範囲の設定を確認
• SaaSの設定を継続的に監視するツール（SSPM）の活用：設定ミスや過剰な権限を自動的に検出
• SaaSのAPIを通じた監査（CASB API）：データアクセスログを取得・監査（ただし対応サービスは限定的）

この領域は、ネットワーク制御では基本的に対処できません。SaaS内部でAIがデータを読む行為は、ユーザーの端末を経由しないためです。対策の本質はデータガバナンス――「誰が何にアクセスできるか」を適切に管理することです。

4-5. D：管理外デバイス ― 制御ポイントの不在

私用端末やBYOD（個人所有端末の業務利用）からAIサービスにアクセスされた場合、セキュリティソフト（クライアントソフト）が入っていないため、インライン制御が一切効きません。

管理端末を前提にどれだけ精緻な対策を組んでも、私用端末からアクセスされた瞬間にすべて迂回される。これが管理外デバイスの根本的な問題です。

リスク

• 管理端末で実施しているすべての外向き通信の制御が無効化される
• 個人アカウントでのAI利用を制限できない
• データの持ち出し経路が生まれる

対策の方向性

• 認証基盤（IdP）による条件付きアクセス：認証基盤側でデバイスの状態を評価し、管理外デバイスからのアクセスをブロックまたは制限する。これが最も確実かつ汎用的な対策
• SaaS側のIP制限/デバイス認証：SaaSの管理設定で、接続元IPやデバイス証明書によるアクセス制限を設定
• リバースプロキシ型アクセス：管理外デバイスからのアクセスをプロキシ経由に強制し、制限付きで利用させる
• リモートブラウザ分離（RBI）：管理外デバイスのブラウザにデータを残さず、画面描画のみを転送する

この領域の制御ポイントは認証基盤（IdP）が主軸です。ネットワーク制御製品は補助的な役割に留まります。

5. まとめ：5本柱で守る

本記事で見てきたように、AIセキュリティは「ネットワークで通信を止める」だけでは完結しません。外向き通信の制御は最優先かつ最も即効性の高い対策ですが、それはあくまで5本柱のうちの1本です。

AIセキュリティは、1つの製品カテゴリで完結するテーマではありません。通信、認証、端末、データガバナンス、契約・評価――どれか1本の柱だけでは、必ず見えない領域が残ります。

重要なのは「完璧に止めること」ではなく、どこまで見えていて、どこから先が別の対策領域なのかを明確にすることです。自社の現状を5本柱に照らし合わせたとき、「この柱はまだ手をつけていない」と気づけるかどうか。そこがセキュリティの成熟度を分けるポイントです。

次回では、「では具体的にNetskopeはこの5本柱のうちどこに効くのか？」を詳しく解説します。ネットワーク制御の専門家であるNetskopeが、自らの守備範囲とその限界をどう定義しているかを見ていきましょう。

では、よいセキュリティライフを。