はじめに
生成 AI の業務利用が広がる中で、ChatGPT を全面的に禁止すると業務の効率化を妨げ、無条件に許可すると機密情報が入力されるリスクが残ります。Cisco Secure Access の DLP(Data Loss Prevention)にある AI ガードレールルール(AI Guardrails)を使うと、ChatGPT へのアクセス自体は許可したまま、送信されるプロンプトの内容を検査できます。
本記事では、2026 年 10 月 15 日に Cisco dCloud のラボ環境で実施した検証をもとに、ChatGPT のプロンプトに含まれるテスト用のクレジットカード番号を Monitor で検知し、Block で遮断するまでの設定と、動作を何で確認すべきかを解説します。
- アプリケーション単位のブロックと DLP(AI Guardrails)による制御の違い
- AI ガードレールルールで ChatGPT のプロンプトを検査する設定手順
- Privacy Guardrail の検出対象と、Safety / Security Guardrail との違い
- Monitor と Block の動作の違いと、管理者に表示される入力内容の範囲
- ブラウザーの表示と DLP ログを照合して遮断を確認する方法
結論として、今回の環境では、Block に切り替えた後も「TCP と UDP の違いを教えて」という通常の質問には回答が返り、テスト用カード番号を含む質問だけが遮断されました。遮断の判断は、ブラウザーに表示された Unable to connect ではなく、DLP レポートに記録された LAB-AI-DLP-Test の Block イベントで行っています。
アプリケーション単位のブロックと DLP では、制御の単位が次のように異なります。
| 方式 | 制御の単位 | 通常の質問 | 機密情報を含む質問 |
|---|---|---|---|
| アプリケーション単位の Block | ChatGPT への通信全体 | 遮断 | 遮断 |
| DLP(AI Guardrails) | プロンプトの内容 | 許可 | Monitor では検知、Block では遮断 |
Secure Access の全体像は概要編の『Cisco の SASE|Secure Access の構成と導入のポイント』で、IPsec・BGP の接続確認、PBR による通信誘導、HTTPS 復号、アプリケーション単位のブロックは基本編『Cisco Secure Access の設定|ChatGPT の可視化と遮断』で解説しています。本記事では、これらの構築手順は繰り返さず、DLP の設定と検証結果に絞って説明します。
Cisco Secure Access の DLP 検証環境
今回の DLP 検証は、基本編で構成した環境をそのまま利用しました。DLP の検証に関係する前提は次のとおりです。
| 項目 | 今回の状態 |
|---|---|
| 接続構成 | 拠点 LAN → Cisco C8000V → IPsec / eBGP → Cisco Secure Access |
| 通信誘導 | PBR で検証端末の Web 通信を Secure Access へ誘導 |
| 検証端末 | Windows / Google Chrome(ChatGPT はログインしていない状態で利用) |
| HTTPS 復号 | LAB-Decrypt-Test を割り当てた LAB-Decrypt-Allow を有効のまま使用 |
| ルート CA 証明書 | 検証端末に導入済み |
| ChatGPT のアプリケーションブロック | LAB-Block-ChatGPT を無効化 |
| DLP のアクション | 最初は Monitor、その後 Block に変更 |
HTTPS 復号と CA 証明書の前提
AI ガードレールルールでプロンプトの内容を検査するには、ChatGPT との HTTPS 通信が復号されている必要があります。Cisco の公式資料では、AI ガードレールルールの前提条件として、HTTPS インスペクションの有効化が挙げられています。
参考: Cisco Secure Access Help – Add an AI Guardrails Rule to the Data Loss Prevention Policy
“HTTPS Inspection must be enabled either on the default Access policy, or at least one access policy rule … where the same identity is configured in an AI guardrails rule.”
(HTTPS インスペクションは、デフォルトのアクセスポリシー、または AI ガードレールルールと同じアイデンティティが設定された少なくとも 1 つのアクセスポリシールールで有効にする必要があります。)
https://www.cisco.com/c/en/us/td/docs/security/secure-access/secure-access-help/CiscoSecureAccessHelp/data-loss-prevention-intro/add_an_ai_guardrails_rule_to_the_data_loss_prevention_policy.html
今回のラボでは、DLP ルールのアイデンティティを Network Tunnel Group、復号用 Allow ルールの送信元を検証端末の IP アドレスとしており、この組み合わせで検知と遮断を確認しました。ただし、これは今回の環境での結果であり、公式の前提条件を満たさない構成でも常に動作することを示すものではありません。本番環境では、公式の前提条件に沿って、DLP ルールと同じアイデンティティの通信で復号が有効になっているかを確認することをおすすめします。
アプリケーションブロックルールを無効化した理由
基本編で作成した LAB-Block-ChatGPT は、ChatGPT への通信全体をアクセスルールで遮断します。このルールが有効なままでは ChatGPT にプロンプトを送信できず、入力内容に応じた DLP の動作を確認できません。このため、DLP 検証の前に LAB-Block-ChatGPT を無効化し、HTTPS 復号用の LAB-Decrypt-Allow と LAB-Decrypt-Test は有効のまま残しました。
つまり、ChatGPT への通常のアクセスはアクセスルールで許可し、プロンプトの内容は DLP で検査する、という役割分担の構成です。
AI Guardrails で ChatGPT の入力検査を設定する
AI ガードレールルールは、データ損失防止ポリシーの中で動作し、AI アプリケーションとやり取りするプロンプトや応答を検査するルールです。公式資料では、監視するデータの種類と、内容をブロックするか監視のみとするかをルールで定義すると説明されています。
今回設定した DLP ルール
| 項目 | 設定 |
|---|---|
| ルール名 | LAB-AI-DLP-Test |
| ルールタイプ | AI Guardrails(AI ガードレールルール) |
| 重大度 | 高 |
| データ分類 | Privacy Guardrail |
| 検査対象 | コンテンツ |
| ファイル制御 | 無効 |
| アイデンティティ | Network Tunnel Groups(検証用の NTG を 1 件選択) |
| 接続先 | Generative AI → OpenAI ChatGPT |
| 方向 | プロンプト |
| アクション | 最初は Monitor、2 回目の検証で Block |
| ユーザー通知 | 無効 |
今回の検査対象は、OpenAI ChatGPT のプロンプトのみです。応答の内容、ファイルのアップロード、ほかの生成 AI アプリケーションは検証していません。
AI ガードレールルールの設定手順
「データ損失防止ポリシー」画面の「ルールの追加」から「AIガードレールルール」を選択し、ルール名を LAB-AI-DLP-Test、重大度を「高」としました。
データ分類を検索する場所に「コンテンツ」を選び、データ分類として「Privacy Guardrail」を選択します。「プレビュー」を開くと、分類に含まれるデータ識別子を確認できます。下の画面はプレビューを開いた状態で、Credit Card Number のほか、Bank Account Number(US)、Email Address などが含まれています。
画像は Privacy Guardrail を選択する前の状態です。実際の設定では、Privacy Guardrail のチェックボックスにチェックを入れてから次へ進みます。

今回はプロンプトの文字列だけを検査するため、ファイル制御は無効のままとしました。アイデンティティには「Network Tunnel Groups」を選び、検証用の NTG を指定しています。
接続先で「アプリケーションカテゴリ」→「Generative AI」を開き、「OpenAI ChatGPT」にチェックを入れ、方向を「プロンプト」とします。Generative AI のカテゴリ全体ではなく、OpenAI ChatGPT のみを対象にしています。

アクションは「モニター」、ユーザー通知は無効として保存しました。保存後のルール一覧には、ルールタイプ「AIガードレール」、重大度「高」、アクション「モニター」、データ分類「Privacy Guardrail」と表示されます。
Privacy / Safety / Security Guardrail の違い
AI ガードレールには、組み込みのデータ分類として Privacy、Safety、Security の 3 種類が用意されています。今回選択したのは Privacy Guardrail のみです。
| データ分類 | 主な目的(公式資料の説明) | 今回の設定 |
|---|---|---|
| Privacy Guardrail | 個人を特定できる情報(PII)を AI アプリケーションとやり取りしないようにする | 選択 |
| Safety Guardrail | 不正確な情報や、危害につながる情報の拡散を防ぐ | 未選択 |
| Security Guardrail | プロンプトインジェクション攻撃などから保護する | 未選択 |
参考: Cisco Secure Access Help – Manage AI Guardrails Data Classifications
“prevent the AI application from disseminating personal information identifiers (PII)”
(AI アプリケーションが個人を特定できる情報(PII)を拡散することを防ぐ)
https://www.cisco.com/c/en/us/td/docs/security/secure-access/secure-access-help/CiscoSecureAccessHelp/ai-guardrails-data-classification-intro/manage-ai-guardrail-classifications.html
Privacy Guardrail はクレジットカード番号専用の分類ではありません。今回の環境では、Credit Card Number、Bank Account Number、Email Address、Phone Number、IP Address、Passport Number(US)、Social Security Number(SSN)(US)など、個人情報に関連する複数のデータ識別子が含まれていました。今回のテストで実際に検出されたのは Credit Card Number です。
Monitor で機密情報の入力を可視化する
最初に、アクションを Monitor にした状態で、機密情報を含まない質問と、テスト用カード番号を含む質問を ChatGPT に送信しました。
検証に使った 2 種類のプロンプト
- 通常の質問
-
「TCP と UDP の違いを教えて」
- テスト用カード番号を含む質問
-
「以下は架空のテスト用クレジットカード番号です。4111 1111 1111 1111 この番号の桁数と、Luhn アルゴリズムによるチェック結果を教えてください。」
4111 1111 1111 1111 は、決済システムのテストで一般的に使われる番号で、実在する顧客の決済情報ではありません。検証では、実在するカード番号や顧客情報を入力しないでください。
Monitor の状態では、通常の質問を送信すると、ChatGPT から通常どおり回答が返りました。
DLP イベントで確認した内容
テスト用カード番号を含む質問を送信すると、DLP レポートに検出イベントが記録されました。イベントの一覧と詳細で、次の内容を確認しています。
| 項目 | 表示内容 |
|---|---|
| イベントタイプ | AIガードレール |
| 重大度 | 高 |
| 方向 | プロンプト |
| 接続先 | OpenAI ChatGPT |
| ルール | LAB-AI-DLP-Test |
| 検出したデータ識別子 | Credit Card Number(1 件が一致) |
| アクション | モニタ対象 |
| 詳細パネル | 一致したプロンプトの抜粋 |

管理者は、検出されたデータ識別子の種類だけでなく、一致したプロンプトの内容の一部を DLP レポートで確認できました。イベントの詳細パネルには、送信したプロンプトの文字列がカード番号を含む形で表示されています。
Monitor は検知と記録を行うモードで、今回の検証でも ChatGPT へのアクセスは遮断されていません。入力内容を止めるには、次の Block へ切り替えます。
管理者に見える入力内容の範囲
今回確認できたのは、Privacy Guardrail に一致したプロンプトの抜粋です。今回の DLP レポートの一覧には、通常の質問に対応するイベントは表示されていませんでした。この結果から、ChatGPT に送信されたすべてのプロンプトの全文を管理者が常に閲覧できる、とは言えません。
一方で、ルールに一致した場合は、テスト用カード番号のような機密情報が管理画面に表示されます。情報漏えい対策として有効な反面、管理者側に機密情報が表示され得る点は、運用上の注意点として後述します。
Block に変更して機密情報の送信を遮断する
続いて、同じ LAB-AI-DLP-Test のアクションを Monitor から Block に変更しました。データ分類、アイデンティティ、接続先、方向などの条件は変更していません。
通常の質問と機密情報を含む質問の結果
Monitor と Block の検証結果は次のとおりです。
| プロンプト | Monitor | Block |
|---|---|---|
| 通常の質問 | 回答が返った | 回答が返った |
| テスト用カード番号を含む質問 | DLP レポートにモニタ対象のイベントを記録 | ChatGPT の画面に Unable to connect と表示。DLP レポートにブロック済みのイベントを記録 |
Block に切り替えた後も、通常の質問は送信でき、回答が返りました。DLP が ChatGPT の利用そのものを止めるのではなく、条件に一致したプロンプトだけを対象にしていることが分かります。

ブラウザーの表示と DLP の Block イベントを照合する
テスト用カード番号を含む質問を送信すると、ChatGPT の画面には「Unable to connect」と表示されました。

Unable to connect は一般的な通信エラーでも表示される可能性があるため、この画面だけで DLP による遮断が成功したとは判断できません。今回の検証では、DLP レポートに LAB-AI-DLP-Test によるブロック済みのイベントが、方向「プロンプト」、接続先「OpenAI ChatGPT」として記録されていたことから、DLP ルールによる遮断と判断しました。

同じルールについて、Monitor のときのモニタ対象のイベントと、Block に変更した後のブロック済みのイベントを、同じ一覧で確認できました。ブロック済みのイベントは複数件記録されていますが、送信操作の回数との対応までは確認していません。
ユーザーから「ChatGPT に接続できない」という問い合わせを受けた場合は、次の順序で確認することをおすすめします。
- エラーが表示された時刻と、送信した操作を確認する
- DLP レポートで、同じ時刻帯のイベントのルール名、方向、接続先、アクションを確認する
- ブロック済みのイベントがあれば、DLP による遮断と判断する
- イベントが見つからない場合も直ちに DLP を原因から除外せず、検索期間、フィルター、ログの反映状況を確認したうえで、アクセスルールや通信経路を切り分ける
DLP を運用する際の注意点
今回の結果は、標準の Privacy Guardrail と特定のテスト番号に対するものです。すべての機密情報を漏れなく検出できる、あらゆる生成 AI で同様に制御できる、と判断できるものではありません。本番環境へ展開する前に、次の点を確認しておくことをおすすめします。
Privacy Guardrail の検出対象と誤検知・検知漏れ
Privacy Guardrail には、カード番号以外にもメールアドレス、電話番号、IP アドレスなどのデータ識別子が含まれます。そのため、業務上の問い合わせでこれらの情報を含めた場合にも、ルールに一致する可能性があります。いきなり Block で展開せず、Monitor で検出状況を確認してから Block へ切り替える進め方が、誤検知による業務影響の抑制につながります。
公式資料では、組み込みのデータ識別子は独自に作成できない一方、データ分類はカスタマイズしたものを作成して使用できると説明されています(Manage AI Guardrails Data Classifications)。検出対象を絞り込む場合は、カスタムのデータ分類を検討します。逆に、今回テストしたのは 1 種類のテスト番号のみであり、表記の揺れなどによる検知漏れの有無は確認していません。
DLP の検査対象と対象外
公式資料では、AI ガードレールルールはアップロードされるファイルを含め、プロンプトや応答の内容を検査できると説明されています。ただし、今回検証したのは OpenAI ChatGPT のプロンプトのみで、応答、ファイルのアップロード、ほかの生成 AI アプリケーションでの動作は確認していません。
また、今回の AI ガードレールルールで検査できるのは、Secure Access を経由し、HTTPS インスペクションの対象となった通信です。PBR の対象外の端末や、Secure Access を経由しないネットワークからの利用は、今回のルールでは検査されません。
HTTPS 復号、ログの閲覧権限とプライバシー
AI ガードレールルールによるプロンプト検査は HTTPS 復号を前提とし、ルールに一致したプロンプトの抜粋は管理画面に表示されます。DLP レポートを閲覧できる管理者の範囲、ログの保存期間と取り扱い、社内規程や従業員への周知との整合を、導入前に決めておくことをおすすめします。情報漏えい対策の全体像は『情報漏えいはなぜ起きる?|国内事例から考える情シス・インフラの対策』も参照してください。
ルールの適用範囲と例外設計
今回はアイデンティティに Network Tunnel Group を指定したため、そのトンネルを経由する拠点の通信全体がルールの対象になります。業務でカード番号を扱う部署など、例外が必要な利用者がいる場合は、適用範囲と例外の扱いを事前に設計します。
利用者への通知と問い合わせ対応
今回はユーザー通知を無効にした状態で検証し、ChatGPT の画面には Unable to connect と表示されました。通知を有効にした場合の表示は検証していません。公式資料の手順には、違反時のポップアップ通知やメール通知を任意で設定する項目があります(Add an AI Guardrails Rule to the Data Loss Prevention Policy)。通知を有効にするかどうかと、問い合わせを受けたときに DLP レポートを確認する手順を、ヘルプデスクと共有しておくことをおすすめします。
まとめ
Cisco Secure Access の AI Guardrails を使うと、ChatGPT の利用を全面的に禁止せず、プロンプトに含まれる機密情報だけを制御できます。今回の検証では、通常の質問には回答が返り、テスト用カード番号を含む質問は Monitor で検知、Block で遮断されました。
- アプリケーション単位のブロックを無効にし、DLP でプロンプトを検査しました。
- AI Guardrails でプロンプトを検査するには、HTTPS 復号が前提になります。
- Privacy Guardrail はカード番号以外の個人情報も検出対象に含みます。
- Monitor は検知と記録を行い、ChatGPT へのアクセスは遮断しません。
- Block に変更しても、通常の質問は送信でき、回答が返りました。
- 遮断の判断は、画面のエラーではなく DLP の Block イベントで行います。
- 管理者に入力内容の抜粋が表示されるため、閲覧権限の管理が必要です。
以上、最後までお読みいただきありがとうございました。
