HigLabo
Latest posts
Zscaler AI-Guardian拡張でも守り切れない？ 部門SaaS内蔵AIが監査漏れする理由
Zscaler AI-Guardian拡張でも見えにくい領域は残る
生成AIの統制が進んだ企業でも、実は「見えているAI」だけを管理して安心してしまうことがあります。結論から言うと、ZscalerのAI Securityで提供される可視化・制御の仕組みが有効でも、サポート対象外のSaaSやSaaSベンダー内部で完結するAI処理では、部門SaaSに埋め込まれたAI機能まで十分に監査できない場合があります。
特に、CISO・SecOps責任者・IT資産管理責任者・SaaS統制担当者にとっての論点は、AI製品そのものの有無ではありません。どの業務で、どの権限を使い、どのデータがどこへ流れてAI処理に入るのかまで見ないと、監査の抜け漏れが起きやすくなります。
参考として、ZscalerのAI Security関連情報は公式ページで確認できます。製品の守備範囲を把握する出発点として有用です。
“AIを見えているつもり”が危ないのは部門SaaS内蔵AI
多くの企業は、まずChatGPTやGeminiのような明示的なAIサービスの利用制御から始めます。アクセス先がわかりやすく、ポリシーも作りやすいため、これは自然な流れです。
しかし現場では、営業支援SaaSの文章作成、人事SaaSの求人要約、カスタマーサポートSaaSの返信支援など、AIが通常機能として埋め込まれている例が増えています。利用者自身が「AIを使っている」と強く意識しないまま使っていることも珍しくありません。
その結果、情報システム部門は外部の生成AI利用は管理していても、部門SaaSの内部でどのデータがAI処理に回っているかを追えないままになります。Zscalerも、AI利用の可視化や制御の重要性を打ち出していますが、可視化対象の定義を誤ると盲点は残ります。
Zscaler AI Securityが得意な領域と見落としやすい前提
まず押さえたいのは、Zscaler系のAIセキュリティ機能が無力だという話ではないことです。公開AIサービスへのアクセス把握、プロンプトやアップロードの制御、データ保護ポリシーの適用では大きな価値があります。
強いのは、通信先やアプリ識別が比較的明確なケースです。たとえば、ユーザーが特定の生成AIサービスにアクセスし、そこで入力やファイル送信を行う場面では、監視や制御の設計がしやすくなります。
一方で前提条件もあります。つまり、何をAI利用として識別できるかです。AI機能が既存SaaSの一機能として溶け込んでいる場合、通信上は単なるSaaS利用に見えやすくなります。
SaaSのAI実装がどう行われるかは各社のアーキテクチャ次第で、利用実態の把握には製品単体以外の視点が必要です。だからこそ、AIそのものではなく、業務経路と権限、データ流れの組み合わせで見る発想が重要になります。
なぜ部門SaaS内蔵AIは監査対象から漏れやすいのか
最大の理由は、AI利用が独立した行為として見えにくいことです。ユーザーから見れば、メールを書いた、議事録を整えた、CRMに要約を追加しただけであり、裏側でAI推論が走っていても通常業務と区別しにくい場合があります。
次に、SaaS内で完結する処理はネットワーク観測だけでは詳細が取りにくいことがあります。特に、ベンダー側の内部API呼び出しでAI処理が行われる場合、ネットワーク観測だけでは企業側の監査基盤から「そのSaaSを使った」ことまでしか分かりにくく、詳細な把握はSaaSごとの監査ログ公開範囲やAPI連携の有無に左右されます。
さらに厄介なのは、AI機能の追加スピードです。以前は単なる文書管理だったSaaSが、短期間で要約、分類、生成、検索支援まで備えることがあります。Microsoft 365 Copilotのように、日常業務で使うアプリにAIが深く組み込まれる流れは急速に広がっています。
見落としが起きる3つの監査盲点
1つ目は、そもそも「どこからをAI利用とみなすか」という定義不足です。ChatGPTの利用だけをAI管理対象にすると、SaaSの要約機能や自動返信機能は台帳から外れやすくなります。
2つ目は、SaaS台帳の更新遅れです。導入時にはAI機能がなくても、後から標準搭載されることがあります。契約更新や機能追加のたびに見直さないと、監査対象はすぐに現実とずれます。
3つ目は、部門主導で導入されたツールの権限棚卸し不足です。現場が便利機能として有効化したAIが、どのデータにアクセスし、どのユーザー権限を使っているのか不明なまま運用されることがあります。この状態では、「使っているかどうか」よりも「何に触れられるか」が見えません。
営業・人事・サポートで起きる統制リスク
たとえば営業部門では、CRM内の商談メモをAIが自動要約する機能は便利です。ただし、そのメモに未公開の価格情報や顧客の機密要件が含まれていれば、どこまで処理対象になり、保存され、再利用されるのかを確認しないまま使うのは危険です。
人事部門では、応募書類の要約や面接メモの整理をAIに任せる例が増えています。ここでは個人情報や評価情報が混ざりやすく、通常のDLPだけでは判断しきれない場面があります。
入力データの扱いと権限制御は、LLM活用全般で継続的な論点です。OWASPの資料も、こうしたリスク整理の参考になります。
カスタマーサポートでも同様です。問い合わせ文面から返信案を作るAIは便利ですが、顧客データ、契約情報、障害情報が文脈に含まれることがあります。生成AIガバナンス全体像を整理する材料として、公開カンファレンスの動画も役立ちます。
承認済みAI、SaaS内蔵AI、把握不能AIの3区分で棚卸しする
実務では、AIツール一覧を作るだけでは不十分です。重要なのは、どの業務で、誰が、どのデータを、どのSaaSに入れ、その先でAI処理がどう走るかを追うことです。
そのため、初級レベルの着手としても、AI利用を承認済みAI、SaaS内蔵AI、把握不能AIの3区分で整理すると、検討の優先順位を付けやすくなります。
具体的には、承認済みAIでは通信先、保存データ、監査可否を確認し、SaaS内蔵AIではSaaS内での処理範囲、管理者設定、ログ取得可否を見ます。さらに把握不能AIについては、部門利用SaaSや新規機能追加を起点に洗い出し、監査できていない領域を明確にします。
つまり監査の単位を、AIサービスから業務フローへ切り替える必要があります。AIが見えるかどうかではなく、業務経路としてどこに組み込まれているかを洗い出す発想です。
NISTのAI RMFも、技術対策だけでなく、ガバナンスと運用の継続的管理を重視しています。
次に取るべき対応は業務経路・権限・データ流れの見直し
最後に重要なのは、CASB、SSPM、ID管理、契約管理、利用部門ヒアリングを分断せずに見ることです。単一のAI可視化製品だけで全体を監査できると考えると、部門SaaS内蔵AIのような見えにくい領域が抜け落ちます。
AIニュースでは新機能に目が向きがちですが、統制の現場でより重要なのは、見えるAIを止めることより、見えにくい業務経路を洗い出すことです。
今後のAIガバナンスは、製品比較だけでは差がつきません。SaaS運用台帳をどう更新し続けるか、権限とデータ流れをどう定常的に点検するかが、実務の差になります。
まずは、承認済みAI、SaaS内蔵AI、把握不能AIの3区分で、自社の通信先、保存データ、監査可否を棚卸しすることが現実的な第一歩です。