こんにちは！セキュリティチームのHitomiです。
Netskope の Real-time Protection ポリシーをアラートモード（ユーザー通知なし・ログのみ）で展開し、誤検知を潰し、チューニングもひと段落した。
「さあ、いよいよユーザーへの通知ありで順次展開だ！」
・・・このタイミングで初めて向き合うことになるのが「ユーザー通知テンプレート」です。
ポリシーのアクションを User Alert に切り替えて、テンプレートをデフォルトのまま展開するとどうなるか。ユーザーの画面に出るのは、英語の定型文です。「You don't have permission to perform this operation」のメッセージが、何の文脈もなく表示されます。
もちろん、これでも運用は始められます。ただ、デフォルトのまま展開すると、展開初日からほぼ確実に起きることがあります。誤検知に引っかかったユーザーからの「英語の画面が出て仕事にならないんですけど」という問い合わせです。
管理者は一件ずつヒアリングして、URL を聞き出し、業務上の必要性を確認して、ポリシーを直す。この往復が、展開対象ユーザーの増加に比例して増えていきます。
通知テンプレートをカスタマイズすると、この往復を減らせます。ユーザーが通知画面の上で「使う理由」をその場で書き残し、管理者はそれをログから拾ってチューニングに回す。通知を単なる「お知らせ」ではなくチューニングの入力チャネルにする、というのが本記事の主題です。
3行まとめ
- User Alert は、警告を見せたうえでユーザーに続行／中止を選ばせる「コーチング」アクション。グレーゾーンの通信に向く
- カスタム通知テンプレートで、文言の日本語化・理由入力・誤検知報告を通知画面に組み込める
- 入力された理由は Skope IT から抽出でき、そのままポリシーチューニングのインプットになる
想定読者
- Netskope を導入したばかりで、これからポリシーをユーザー通知ありで展開していく方
- 導入済みだが、通知はデフォルトのままで「使いこなせていない」と感じている方
まず、User Alert とは何か — Block と何が違うのか
そもそも Block と User Alert は何が違うのでしょうか。
Block は文字どおり遮断して終わりです。一方の User Alert は、警告画面を表示したうえで、続行するか中止するかをユーザー自身に選ばせます。
通知画面には Proceed（続行） と Stop Action（中止） のボタンが表示され、Proceed を選ぶとその操作は許可されると同時に、ユーザーが入力した理由（Justification）付きのアクティビティイベントが生成されます。
入力された理由は 30 分間キャッシュされるため、同じ操作のたびに毎回入力を求められるわけではありません（出典：Netskope 公式ドキュメント「Configuring Real-time Protection Policies」）。
| 観点 | Block | User Alert |
|---|---|---|
| ユーザーの体験 | 遮断されて終わり | 警告を確認したうえで Proceed / Stop を選択 |
| 理由の入力 | 入力欄の表示は可能だが遮断は解除されない | 続行時の理由入力を必須／任意に設定できる |
| 誤検知時の業務影響 | 業務が止まる（管理者対応待ち） | ユーザー判断で業務を継続できる |
| 管理者が得られる情報 | ブロックイベント | 続行／中止の選択と、入力された理由がイベントとして残る |
「本当に止めたいもの」には引き続き Block を使うべきです。マルウェア配布サイトや、明確に禁止しているカテゴリに Proceed ボタンを付ける理由はありません。
User Alert が効くのは、チューニングで一番厄介なグレーゾーンです。業務利用かもしれないし、そうでないかもしれないカテゴリやクラウドアプリです。誤検知だった場合でもユーザーの業務は止まらず、しかも「なぜ使うのか」が理由付きで自動的に記録される。ヒアリングの往復が要らなくなるのは、この記録のおかげです。
カスタム通知テンプレートを作る
テンプレートは管理コンソールの Policies 配下にある Templates（User Notification） から作成します（メニュー配置はリリースにより変わることがあるため、最新は公式ドキュメントを参照してください）。
主な設定項目は次のとおりです。
| 設定項目 | 内容 |
|---|---|
| Template Name | テンプレート名。ポリシー側から選択する際の識別子 |
| Logo / Custom Image | 会社ロゴなどをアップロードして通知に表示できる |
| Title / Message | 通知のタイトルと本文。日本語で自由に記述できる |
| Subtitle / Footer Message | 補足文言（任意） |
| Action Button | Stop / Proceed ボタンのラベル文言を変更できる |
| Show Justification Option | 「Justify Usage（業務利用として申告）」「Report False Positive（誤検知として報告）」の選択肢を表示 |
| Show Justification Box | 選択肢のあとに自由記述欄を表示。入力を必須／任意にできる |
（出典：Netskope 公式ドキュメント「Policy Notification Templates」「Chrome Extension Support For User Notifications」）
文言の具体例
デフォルトの定型文と何を変えるべきか。一例を挙げます。
タイトル：【注意】業務利用端末での＜アプリ名＞の利用は制限されています。
本文：アクセス先が、情報システム部の定めるポリシー条件＜ポリシー名＞に一致しました。業務上必要な場合は、理由を入力のうえ「続行」を選択してください。入力いただいた内容は情報システム部が確認し、必要に応じてポリシーを見直します。誤検知と思われる場合は「誤検知を報告」を選択してください。
ボタン：終了 ／ 続行
これがアラート画面になると以下です。
ポイントは「ブロックされました」ではなく「理由を書けば使えます。その理由はポリシー改善に使います」と伝えることです。ユーザーから見た通知が、敵対的な検問から、改善プロセスへの参加に変わります。この一文があるかどうかで、入力される理由の質も量も変わってきます。
上の画像のように設定したときの設定画面は以下です。
ポリシーに適用する
Real-time Protection ポリシー側の設定はシンプルです。
- 対象ポリシーのアクションを User Alert に設定する
- テンプレート選択欄で、作成したカスタムテンプレートを指定する
- Apply Changes で反映する
順次展開の文脈では、いきなり全社に開くのではなく、パイロットグループ（部門単位・拠点単位など）から User Alert ＋カスタムテンプレートで展開し、後述の理由ログを見ながら対象を広げていく進め方が安全です。
アラートモードでのチューニングが「管理者だけで回す静的なチューニング」だったのに対し、ここからは「ユーザーの申告を取り込みながら回す動的なチューニング」に切り替わります。
入力された理由をチューニングに回す
ユーザーが Proceed したとき、選択した理由の種別と記述内容はアクティビティイベントとして記録されます。Skope IT では justification_reason と justification_type のフィールドが用意されており、公式ドキュメントでは neq 演算子と組み合わせて、理由が入力されたイベントを一覧する方法が案内されています（出典：Netskope 公式ドキュメント「Policy Notification Templates」）。
いきなりクエリ書けと言われてもわかんないよ！という方向けに書き方例をご紹介します。
例えば特定のカテゴリ(Gambling)に対して、reasonフィールドに文字列が記載されているものは
justification_reason neq '' and category eq 'Gambling'とクエリを書きます。
ユーザー側で正当化フロー（Proceed/Stop/誤検知報告など）を選択したものかつ特定のアプリ（Box）に絞り込みたい場合は
justification_type neq '' and app eq Boxとクエリを書きます。
これを使った運用ループは、たとえば次のようになります。
- 週次で justification 付きイベントを抽出する（Skope IT でクエリ、またはレポート化）
- 「誤検知を報告」が付いたもの → URL カテゴリの見直し、カスタムカテゴリ／除外設定の修正
- 「業務利用」の理由が妥当で、同一宛先に件数が集中しているもの → そもそもポリシー側（対象カテゴリ・アクティビティ・適用グループ）を見直す
- 理由が空・不明瞭なまま Proceed が多発しているもの → テンプレートの文言や、理由入力を必須にするかどうかの設計を見直す
従来なら「問い合わせを受ける → ヒアリング → 事象の再現確認 → 修正」という往復が必要だった情報が、ユーザー本人の言葉で、事象発生時刻付きで、最初からログに揃っている状態になります。チューニングの材料集めそのものをユーザーに分担してもらう、と言い換えてもよいでしょう。
具体的なチューニング手順
では、「直す」と決めたあとの実作業はどうなるかですが、申告の種別に応じて、大きく 2 パターンに分かれます。
「誤検知を報告」だった場合 — カテゴリ判定そのものを直す
- URL Lookup で現在の判定を確認する。
Skope IT > Tools > URL Lookup に対象の URL やドメインを入力すると、事前定義カテゴリ／カスタムカテゴリ／URL リストのどれに一致してポリシーに掛かったのかを確認できます - Report Miscategorization で再分類を申請する。
URL Lookup の結果画面から、そのまま Netskope に誤分類を報告できます - 反映を待てない場合は、次のパターンの手順でカスタムカテゴリ側から先に除外します
「業務利用」の申告が妥当だった場合 — 自組織側で例外を作る
- Destination Profile を作る。
Policies > Destination から New Destination Profile を作成し、許可したい URL／ドメインをまとめます（IP アドレスや CIDR も指定可能です）。 - カスタムカテゴリで上書きする。
Policies > Profiles > Custom Categories で、対象の事前定義カテゴリに対して作成した Destination Profile を Exclude（除外） に指定します。カスタムカテゴリは事前定義カテゴリのマッピングを上書きできるため、「このカテゴリは引き続き検査対象、ただしこのサイトだけ除外」という粒度で直せます - ポリシーを見直して Apply Changes で反映する。
なお、同一宛先への申告が特定の部門に集中しているなら、URL 単位の除外ではなく、ポリシーの適用グループや対象アクティビティ自体を見直すほうが筋が良いこともあります
（出典：Netskope 公式ドキュメント「URL Lookup」「Report Miscategorization」「Destination Profile」「Custom Category」）
どちらのパターンでも、修正後に同じ宛先の justification 付きイベントが減っているかを翌週の抽出で確認すれば、チューニングが効いたかどうかまでログで追えます。
運用上の注意点
- 理由は 30 分キャッシュされる。
同一の操作について 30 分間は再入力を求められないため、頻繁に使われているものをチューニングしたいという目的でイベント件数を集計する際はこの挙動を前提に読む必要があります。 - Proceed は「許可」である。
User Alert はあくまでグレーゾーン向けです。確実に止めたい通信は Block のまま運用してください。 - 脅威対策ポリシーには使わない。
マルウェアサイトのフィルタリングなど脅威対策系のポリシーに User Alert を使うことは、Netskope が明確に非推奨としています（参考：Best Practice: Do Not Use User Alert Policies for Threat Protection）。 - 相性のよいアクティビティで使う。
送信・アップロード・投稿・共有・作成・削除・ダウンロード・編集など、ユーザーの明示的な操作への適用が推奨されています。逆に「閲覧（Browse）」に適用するとアラートが頻発するため避けるべきです。 - そもそも選べないケースがある。
ログイン失敗／ログイン成功／ログアウト／プレビュー／API POST／コピー／招待のいずれかのアクティビティが選択されている場合や、アクティビティフィールドが空欄の場合、User Alert はポリシーアクションとして選択できません。（出典：Netskope 公式ドキュメント「Best Practices for User Alert Policies」）
まとめ
順次展開の初日、ユーザーが最初に目にする画面が「英語の定型文」なのか、「日本語で、理由を書けば続行できて、その理由が改善に使われると書かれた画面」なのか・・・。この差は、ユーザー体験だけでなく、その後のチューニング工数に直接跳ね返ってきます。
- User Alert は、警告を見せたうえでユーザーに Proceed / Stop を選ばせる「コーチング」アクション
- カスタムテンプレートで、文言の日本語化・理由入力・誤検知報告を通知画面に組み込める
- 入力された理由は
justification_reason/justification_typeとして Skope IT から抽出でき、そのままチューニングのインプットになる
Netskope を導入して、まだ通知がデフォルトのままの方は、次のポリシー展開のタイミングでぜひテンプレートから手を入れてみてください。
参考文献
本記事の技術的内容は、2026 年 7 月時点の Netskope 公式ドキュメント（Netskope Knowledge Portal）に基づいています。UI 名称・メニュー配置はリリースにより変更される可能性があります。
- Policy Notification Templates - Netskope Knowledge Portal
- Configuring Real-time Protection Policies - Netskope Knowledge Portal
- Create and Validate a Security Policy - Netskope Knowledge Portal
- Chrome Extension Support For User Notifications - Netskope Knowledge Portal
- URL Lookup - Netskope Knowledge Portal
- Report Miscategorization - Netskope Knowledge Portal
- Destination Profile - Netskope Knowledge Portal
- Migrating URL Lists to Destination Profiles - Netskope Knowledge Portal
- Custom Category - Netskope Knowledge Portal
- Best Practices for User Alert Policies - Netskope Knowledge Portal
- Best Practice: Do Not Use User Alert Policies for Threat Protection - Netskope Support
