こんにちは、SCSKセキュリティのふくしまです。
前回の記事では、Cisco Secure AccessのAI Access機能の一つである「シャドーAIの可視化・制御」を取り上げました。
組織内で利用されている生成AIアプリケーションを発見し、リスクを評価・分類したうえで、評価結果に応じてアクセスを制御するまでの流れをご紹介しました。
一方で、生成AIアプリケーションの利用を一律に禁止するのではなく、業務での活用を認めながら、入出力情報を適切に保護したいというニーズもあります。
Cisco Secure Accessでは、このようなニーズに対応する機能として「AI Guardrails」が提供されています。
本記事では、AI Guardrails を用いて、生成AIへの入力内容（プロンプト）、出力内容（レスポンス）、およびプロンプトの添付ファイルに対する保護機能の概要を紹介します。また、プロンプトおよびレスポンスの制御動作を実際に検証してみます。
AI Access機能とは
前回記事のおさらいとなりますが、Cisco Secure AccessのAI Accessは、大きく次の2つの機能で構成されています。
| 機能 | 機能概要 | 必要ライセンス |
| シャドーAIの可視化・制御 | 組織内で利用されている生成AIアプリケーションを検出・可視化し、評価結果に応じてアクセス制御を行う機能
※詳細は前回記事参照 |
SIA Essential |
| AI Guardrails（DLP） | 生成AIへの入力内容（プロンプト）や出力内容（レスポンス）およびプロンプトに添付するファイルを分析し、機密情報の漏えいや不適切な利用を防止する機能
※本記事にて紹介する内容 |
SIA Advantage または SIA Essential向け Add-On |
前回は「どの生成AIアプリケーションの利用を認めるか（認めないか）」という観点で、シャドーAIの可視化・制御を検証しました。
今回は「生成AIにどのような情報を入力・出力させないか」という観点から、AI Guardrails（DLP）を検証します。
AI Guardrailsとは
AI Guardrailsは、生成AIへの入力内容や出力内容を検査し、機密情報の漏えいや不適切な利用を抑止するための機能です。
Ciscoでは次のようなAI向けデータ分類を提供しています。
これらを利用することで、一からデータ分類を作成することなくAI利用の保護を開始できます。
| データ分類 | 主な用途 |
|---|---|
| Privacy Guardrail | クレジットカード番号、電話番号、メールアドレスなど、個人情報やプライバシーに関わる情報の検知・制御 |
| Safety Guardrail | 有害または不適切なコンテンツの検知・制御 |
| Security Guardrail | プロンプトインジェクションなど、生成AI利用時のセキュリティ脅威の検知・制御 |
また、AI Guardrailsに対応している生成AIアプリケーションは現時点（2026年9月時点）で以下の18種類です。
| Anthropic Claude | Anyword | Botpress | Chatbase | ChatBot | Craiyon |
| DeepSeek | Frase.io | GitHub Copilot | Google Gemini | Microsoft Copilot | Notion AI |
| OpenAI API | OpenAI ChatGPT | QuillBot | Rytr | XAI Grok | Microsoft Office Online |
AI Guardrailsの対応アプリケーションや、アプリケーションごとに対応している制御内容（プロンプト／レスポンス）は、変更される可能性があります。
導入・設計時には、管理画面および最新のCisco公式ドキュメントで対象範囲を確認してください。
本記事ではGoogle Geminiを対象に、実際にプロンプトやレスポンスの制御が行えることを検証していきたいと思います。
検証してみた
検証シナリオは次のとおりです。
- IPアドレス（プライバシー情報）を含むプロンプトの送信をブロックする
- IPアドレス（プライバシー情報）を含むレスポンスをブロックする
- 検知・制御されたイベントをログで確認する
今回は検証用のデータとしてIPアドレスを使用します。
IPアドレスはPrivacy Guardrailの検知対象に含まれており、個人情報やプライバシー情報として扱われる場合があるだけでなく、社内ネットワークの構成や利用環境に関する情報を含むため、組織によっては外部への不用意な共有を避けたい情報の一つです。
AI Guardrails用のデータ分類を準備する
はじめに、DLPルールで使用するAI Guardrails用データ分類を確認します。
管理コンソールで、[Secure] > [Settings] > [Data Classification] の順に移動し、[AI Guardrails Classifications]タブを開きます。
冒頭で紹介した、組み込みのAI向けデータ分類である「Privacy Guardrail」、「Safety Guardrail」、「Security Guardrail」が存在することを確認できます。
今回は、Privacy Guardrail を使用します。
Privacy Guardrail の詳細画面を展開すると、「IP Address」がデータ識別子として含まれていることを確認できます。
IPアドレス以外にも、メールアドレス、電話番号、国・地域に固有の口座番号や免許証番号など、複数のデータ識別子が含まれます。
各データ識別子の説明は、詳細画面を展開すると確認できます。
また、Privacy Guardrail のような組み込みのデータ分類をそのまま使用するだけでなく、あらかじめ用意されているデータ識別子を組み合わせて、AI Guardrails用のカスタムデータ分類を作成することもできます。
カスタムデータ分類では、複数のデータ識別子を[AND] または [OR]で組み合わせ、検知条件を定義することが可能です。
AI Guardrails用のDLPポリシーを作成する
続いて、AI GuardrailsルールをDLPポリシーに追加します。
管理コンソールで、[Secure] > [Policy] > [Data Loss Prevention Policy] へ移動し、[Add Rule]から[AI Guardrails Rule]を選択します。
設定項目ごとにポイントを確認します。
ルール名と重要度
Rule Name(ルール名)、任意のDescription(ルールの説明)、およびSeverity(重要度)を設定します。
Severityは、検知イベントの重要度を表し、ログを絞り込む際にも利用できます。
運用時に識別しやすいルール名称と、組織の基準に沿った重要度を設定します。
今回は検証なので、Rule Name(ルール名)とSeverity(重要度)のみ添付画像のように設定しました。
Data Classifications
Data Classificationsでは、本ルールで使用するデータ分類を指定します。
データ分類選択セクションにはAI Guardrails用データ分類が表示されています。[Preview] から、分類に含まれるデータ識別子を確認できます。
今回は Privacy Guardrail を指定します。
File Control
File Controlでは、ファイルラベル、ファイルサイズ、ファイル形式、未分類ファイルなどをDLPルールの追加条件として指定できます。
本記事では詳細な設定は行いませんが、実運用ではファイルサイズやファイル種別などを条件に追加することも可能です。
| 項目 | 用途 |
|---|---|
| File Labels | ファイルに付与されたラベル名を条件として使用します。 Microsoft Officeの機密ラベル（Sensitivity Label）やAdobe PDFのドキュメントプロパティに設定されたラベルを参照し、指定したラベルを持つファイルを対象にルールを適用できます。 |
| File Size | 指定したファイルサイズ条件に一致するファイルを対象にルールを適用します。 なお、50MBを超えるファイルであってもルールは適用可能ですが、ファイル内容の検査は先頭50MBまでが対象となります。 |
| File Type | ファイルの種類を条件として使用します。 特定のファイル形式を「含める」または「除外する」条件を設定できます。 |
| Unclassified Files | 機密ラベルやドキュメントラベルが付与されていないファイルをルール条件として使用します。 |
今回はAI Guardrailsの基本動作に焦点を当てるため、各項目は既定値のままとします。
Identities
Identities では、本ルールを適用するIDを指定します。
カテゴリ全体を選択するほか、特定のユーザやグループに限定することもできます。今回は、検証対象のユーザのみを対象にします。
また、[Select identities for exclusion] を使用すると、適用対象ではなく除外対象のIDを指定できます。
このとき、同じIDが適用対象と除外対象の両方に含まれる場合は、除外が優先されます。
Destinations
Destinations では、制御対象の生成AIアプリケーションと、検査する方向を指定します。
今回は Google Gemini を選択し、プロンプトとレスポンスの両方を対象にします。
選択できる方向はアプリケーションによって異なる場合があります。
対象アプリケーションでPrompt、Response、またはその両方（Prompt & Response）を選択できるか、設定画面で確認してください。
Action
Actionでは、ルール一致時の動作として、[Monitor] または [Block]を選択します。
- Monitor：通信はブロックせず、ルールに一致したイベントをログに記録します。
- Block：ルールに一致したプロンプト、レスポンス、またはファイルの処理をブロックします。
今回は動作確認のため Block を選択しますが、
本番導入では、まずMonitorで検知状況や業務影響を確認し、必要に応じて条件を調整したうえでBlockへ移行する方法が推奨されます。
User Notifications
User Notificationsでは、ルールに一致した場合、エンドユーザ向けのポップアップ通知や、指定した宛先へのメール通知を設定できます。
通知文は運用方針に合わせてカスタマイズできます。
今回は、AI Guardrailsの制御動作とログの確認に焦点を当てるため、通知は使用しません。
ルールの保存
すべての設定が完了したら[Save]を選択してルールを保存します。
DLPポリシーの一覧に戻り、作成したAI Guardrailsルールが追加されていることを確認します。
動作確認・ログの確認
作成したルールを使用して、プロンプト、レスポンスの順に動作を確認します。
プロンプトの制御
まずはプロンプト制御の動作確認を行います。
Cisco Secure Access を経由して通信する検証ユーザから Google Gemini にアクセスし、グローバル IP アドレスを含むプロンプトを送信します。
今回は例として、「8.8.8.8 は何の IP アドレスですか？」というプロンプトを Gemini に入力しました。
プロンプトを送信すると、Cisco Secure Access によって入力内容が検査され、プロンプトの送信がブロックされます。
その結果、Gemini にはプロンプトが送信されず、「インターネット接続を確認してもう一度お試しください」といったエラーメッセージが表示されました。
なお、ブロック時に表示されるメッセージや挙動は、利用する AI アプリケーションによって異なります。
レスポンスの制御
続いて、レスポンス制御の動作確認を行います。
同様に検証ユーザから Google Gemini にアクセスし、レスポンスにグローバル IP アドレスが含まれそうなプロンプトを送信します。
今回は例として、「適当なグローバル IP アドレスを提示してください。」というプロンプトを Gemini に入力し、送信しました。
Gemini はプロンプトに対する回答を生成しますが、Cisco Secure Access がレスポンス内容を検査し、グローバル IP アドレスを検知した場合はレスポンスの表示をブロックします。
画面上ではプロンプト制御時と似た挙動に見えますが、実際には入力内容ではなく、Gemini が生成したレスポンスが検査されています。
その結果、Gemini が回答を生成していても、ユーザは回答内容を閲覧できません。
なお、ブロック時に表示されるメッセージや挙動は、利用する AI アプリケーションによって異なります。
最後に念のため、プライバシー情報を含まないメッセージを送ると、プロンプト・レスポンス共に制御されず正常に利用できることを確認します。
ログの確認
ここまでの検証結果が Cisco Secure Access にどのように記録されるのかを確認してみましょう。
管理コンソールで、[Monitor] > [Reports] > [Data Loss Prevention] へ移動します。
続いて、[Event Type]を[AI Guardrails]でフィルタします。
すると、AI アプリケーションに対して実行されたプロンプト制御やレスポンス制御のイベントを確認できます。
ログには、検知対象となった AI アプリケーションや通信方向（Prompt / Response）、適用されたルールなどが記録されており、どのような制御が行われたかを把握できます。
また、各ログの右側にある三点リーダー（…）をクリックすることで、イベントの詳細情報を確認できます。
まずはプロンプトブロックのイベント詳細情報（Event Details）を確認してみます。
詳細ログからは、以下のような情報を確認できます。
- アクション
- ファイル名（ファイルアップロードがブロックされた場合）
- 対象ユーザ（Identity）
- 生成AIアプリケーション名（Application）
- 適用されたルール（Rule）
- 制御方向（Direction）
- 一致したデータ分類や文字列
例えば今回の検証では、Direction が Prompt となっていることから、ユーザが入力したプロンプトに対して制御が実施されたことが分かります。
また、一致したデータ分類や文字列からは、どの情報がポリシーに抵触したのかを確認できます。
続いてレスポンスブロック時のログも確認してみます。
基本的に確認できる項目はプロンプトブロック時と同様ですが、Direction が「Response」 となっていることから、ユーザが入力したプロンプトではなく、生成AI が生成したレスポンスに対して制御が実施されたことが分かります。
また、ユーザには表示されなかったレスポンス内容についてもログから確認できます。
そのため、どの情報がルールに抵触し、ブロック対象となったのかを把握できます。
利用にあたっての注意事項
AI Guardrails を利用する際は、事前にいくつか確認しておきたいポイントがあります。
ここでは、検証時に確認した内容をもとに、設計・導入時に注意すべき事項を紹介します。
① 保護対象について
本検証では生成AIアプリケーションに対するプロンプトとレスポンスの制御を確認しましたが、AI Guardrails では以下のデータを保護対象として設定できます。
- 入力内容（プロンプト）
- 出力内容（レスポンス）
- プロンプトに添付するファイル
利用シーンに応じて、どの通信を保護対象とするかを検討してください。
② HTTPS Inspectionの有効化が必要
AI Guardrails でプロンプトやレスポンスの内容を検査するためには、対象通信に対して HTTPS Inspection が有効になっている必要があります。
また、AI Guardrails ルールを適用するユーザやグループ、宛先アプリケーションなどの対象範囲が、HTTPS Inspection を有効とするポリシーの対象範囲と一致していることを確認してください。
対象通信のHTTPS Inspection が有効になっていない場合、プロンプトやレスポンスを検査できません。
③ 対応アプリケーションとサポート状況を確認する
AI Guardrails を利用できる生成AI アプリケーションや、アプリケーションごとに選択可能な Prompt / Response の対応状況は、製品のアップデートによって変化します。
設計および導入時には、最新の Cisco 公式ドキュメントや管理画面を参照し、対応アプリケーションおよびサポート状況を確認することを推奨します。
④ AI Guardrails用データ識別子には制約がある
AI Guardrails 用のカスタムデータ分類は、Cisco が提供する組み込みデータ識別子を利用して構成します。
DLPのリアルタイムルール のように、任意の文字列やキーワード、近接性条件などを自由に定義できるわけではありません。
そのため、自組織で保護したい情報を適切に識別できるか、事前の検証を推奨します。
⑤ 添付ファイルの検査上限
アップロードファイルの検査にはサイズ上限があります。
執筆時点では、最大50MBまでのファイルに対応しており、50MBを超えるファイルについては最初の 50 MB までが検査対象となります。
実運用を想定する場合は、利用者が扱うファイルサイズと製品仕様を照らし合わせ、運用上問題がないか事前に確認しておくことが重要です。
⑥ データ分類は用意されているが、ポリシー設計は必要
AI Guardrailsでは、個人情報などを検知するためのデータ分類（Data Classification）はあらかじめ用意されています。
しかし、実際にどのデータを保護対象とし、どのAIサービスに対して、どのユーザーに、どのようなアクション（Monitor／Block）を適用するかは、お客様のセキュリティ要件や業務内容に応じてDLPポリシーを設計する必要があります。
そのため、AI Guardrailsを導入する際は、あらかじめ用意されているデータ分類をベースに、保護対象のデータや利用するAIサービス、適用対象ユーザー、制御内容を検討し、組織の要件に応じたDLPポリシーを作成する必要があります。
⑦ Monitorによる事前評価
データ識別子の特性や業務内容によっては、想定外の検知が発生する可能性があります。
そのため、本番環境でいきなり Block を適用するのではなく、まずは Monitor モードで運用を開始し、検知傾向や業務影響を確認することを推奨します。
検知結果をもとに、「適用対象」、「データ分類」、「通知方法」、「ブロック対象」を段階的に調整していくことで、業務影響を抑えながら導入を進めることができます。
まとめ
本記事では、Cisco Secure AccessのAI Guardrailsを使用し、生成AIに対するプロンプトおよびレスポンスをDLPルールで検査・制御する流れをご紹介しました。
AI Guardrailsは、「生成AIの利用そのものを禁止する」のではなく、業務での生成AI活用を認めながらも、機密情報や個人情報の漏えいリスクを低減するための仕組みとして活用できます。
例えば、以下のような要件がある場合に有効です。
- クレジットカード番号やメールアドレスなどの個人情報を生成AIへ入力させたくない
- 機密情報を含むファイルが生成AIへアップロードされることを防ぎたい
- 生成AIのレスポンスに機密情報が含まれる場合、その表示を制御したい
- プロンプトインジェクションなど、生成AI特有のセキュリティリスクを検知したい
一方で、生成AIの利用目的や業務内容は組織によって大きく異なります。
そのため、「どの情報を保護したいのか」を明確にしたうえで、段階的にポリシーを調整していくことが重要です。
また、データ識別子の特性や業務内容によっては想定外の検知が発生する可能性もあります。
そのため、本記事で紹介したように、まずはMonitorモードによる事前評価を行い、検知傾向や業務影響を確認しながら段階的にルールを調整していくことを推奨します。
AI Guardrailsは、生成AIの利活用と情報保護を両立するための仕組みであり、自組織の利用方針やリスク許容度に合わせて継続的にチューニングしながら活用することが望ましいと考えます。
次回予告
次回は、Cisco Secure Accessの特長的な機能の一つであるDEM（Digital Experience Monitoring）を取り上げます。
ユーザのデジタル体験をどのように可視化し、通信品質やアプリケーション到達性の確認に活用できるのか、実際の画面と検証結果を交えてご紹介する予定です。