こんにちは、セキュリティチームのHitomiです。
R139（2026年7月6日公開）とR140（2026年8月3日公開）を読みました。
今回は「それ待ってた」と言いたくなる変更が入っています。特にAuto Re-enableのGA。運用者目線で刺さったものから順に紹介していきます。
0. はじめにまとめ
- Auto Re-enable がGAになりました！ユーザーが Netskope Client を無効化しても、設定した時間が経てば自動で元に戻る。それだけの機能ではあるのですが、「無効化しっぱなし」問題で一本記事が書けるぐらいには課題があったので、今回いちばんの嬉しい機能です。
- 対応が必要な変更：R140で
claude.comとanthropic.comが Generative AI カテゴリの「Anthropic Claude」に再マッピングされます。リリースノートに「Action Required」と明記されており、Claude を業務で使っている組織は点検しておきましょう。
デプロイは約1週間のウィンドウで段階展開されるので、手元のテナントの版は Settings > General で確認してください。
1. Auto Re-enable：「無効化しっぱなし」が、ようやく自動で戻る
ユーザーが Netskope Client を無効化する。Web会議が重いから、トラブルの切り分け中だから、理由はいろいろです。問題はその後で、ユーザーは高確率で戻し忘れます。
そして従来の仕様では、全 Client サービスの無効化は管理者が手動で再有効化するまでそのまま。つまり誰かが気づくまで、その端末は保護なしで動き続けていました。
弊社ブログでも、この「無効化しっぱなし」を検知してユーザーに気付かせる仕組みをご紹介しました。検知まではできた。ただ、復旧は結局ユーザー任せか管理者の手作業のままで、そこが残っていたわけです。
R139でBetaとして入り、R140でGAになった Auto Re-enable Duration が、その残っていた側を製品機能で埋めてくれます［出典: Netskope Release Notes 139.0.0 / 140.0.0］。
- Client Configuration の「Allow disabling of all Client services together」オプションにタイマーを設定できる
- ユーザーが全サービスを無効化しても、設定時間の経過後に全サービスが自動で再有効化される。ユーザーにも管理者にも操作は不要
- 対応OS：Windows / macOS / Linux、最小 Client バージョン 139.0.0
設計で悩むのは時限値です。短すぎると、ユーザーが無効化した理由・・・たとえば切り分け作業を途中で潰してしまう。長すぎると無防備な時間が延びる。つまり落としどころを決めるには、「うちのユーザーは何のために無効化しているのか」を知っている必要があるんですよね。
とはいえ、ブログの無効化検知の仕組みまで組んでいる組織において、この仕組みはこのアップデートで不要にはなりません。
復旧は Auto Re-enable に任せて、検知・通知は「なぜ無効化したのか」を拾うために残すのがおすすめです。無効化の理由はステアリング例外やポリシー改善のネタ元であると同時に、時限値そのもののチューニング材料にもなるので、チャネルとして生かしておく価値があります。
ちなみに製品サポートの担当者に確認したところ、Disable時に理由入力を強制する（プロンプトを表示するような）機能は今後の実装計画に組み込まれているとのことでした。ただし実装時期につきましては「未定」のようです。実装を期待。
あわせて：デバイス削除もセルフサービスに（R139、Beta）
Client 運用の手作業つながりでもう1つ。Devices ページからデバイスを直接削除できるようになりました。削除すると該当端末の Client は自動でアンエンロールされ、ユーザーには再エンロールを求める通知が出ます。
退職者端末や重複エントリの掃除、不正な招待メール経由でエンロールされた端末の排除。これまでサポートチケットを切っていた作業が管理画面で完結します。
Devices ページを監査用にエクスポートしている組織なら、stale エントリのせいでカバレッジが不正確になる問題も一緒に片付きますよ〜。
2. 要対応：claude.com / anthropic.com のカテゴリ再編（R140）
要確認の変更点です。R140のCCI（Cloud Confidence Index）更新で、Anthropic 関連ドメインのマッピングが変わります［出典: 140.0.0］。
Home \ Anthropic：「Anthropic PBC」（Technology カテゴリ）から「Anthropic Claude」（Generative AI カテゴリ）へ移動Claude：これまで未マッピング → 「Anthropic Claude」（Generative AI カテゴリ）に追加
リリースノートは目的を Anthropic のネットワークレベルアクセス制御（Tenant Restrictions）要件との整合と説明し、「Action Required：既存のカテゴリベースポリシーを見直せ」と明記しています。
Action Required: Please review your existing category-based policies. Ensure that your “Generative AI” configurations account for these changes to prevent any unintended disruptions to end-user workflows.
引用元：Domain Addition Request for Anthropic Claude
影響の構図はシンプルです。Generative AI カテゴリを対象にした許可・ブロック・コーチング・DLPポリシーに、これまで対象外だった Claude のトラフィックが新たに入ります。
逆に「Anthropic PBC」（Technology）を前提にした例外や個別指定は対象を失う可能性がある。Claude をがっつり業務利用してポリシー制御している組織ほど、ある日突然の意図しないブロックか、その逆のDLP素通しが起きやすくなりそうです。
3. SOC/IR：「どのプロセスが通信したか」が SSE 側でわかるようになる
3.1 Process Name / Parent Process Name ポリシー（R140、Beta）
Netskope Client 経由のトラフィックについて、リクエストを出したプロセス名と親プロセス名を RTP・SSL Do-Not-Decrypt ポリシーの条件に使えるようになりました。ログにも載ります。
curl.exe が単体で通信するのと、powershell.exe を親として通信するのでは、意味がまるで違う。EDR を触っている人には当たり前のこの文脈が、ようやく SSE 側のポリシーと SkopeIT Transaction Events に入ってきました。EDR と Netskope の両方を運用している立場からすると、これは素直に嬉しい変化です。
- 特定プロセス（またはその親）が検出されたときだけ発火するブロック／検知ポリシーを組める
- EDR アラートと Netskope のログをプロセス名で突合できるので、初動の「この通信、どの端末の何が出した？」が速くなる
適用は Netskope Client 経由のトラフィックと RTP / SSL Bypass ルックアップに限られ、テナント単位のフィーチャーフラグが必要な Beta です。いきなりブロックせず、まず Alert モードで powershell.exe 親の LOLBin 通信を観測するところから始めるのが安全だと思います。
3.2 C2疑いドメインが宛先プロファイルに自動で溜まる（R140）
Advanced UEBA の SOC Detections パックが C2 疑いドメインを検知すると、テナント固有の宛先プロファイル SOC Detections - Suspected C2 domains に自動追加されるようになりました。そのままインラインポリシーのブロックに使うこともできます。
が、リリースノート自身がクローンして人手でキュレーションしてから使うことを推奨しています。検知から封じ込めの間に確認を挟むかどうかは、誤検知時の業務影響と相談で。（なお、こちらはAdvanced UEBA 前提のアドオン機能です）。
3.3 APIキー・シークレット検知が64種増える（R139）
ソースコードや設定ファイルに混入しがちなシークレット・APIキー・トークンの DLP 検知エンティティが64種追加され、対象が120超のサービスに広がりました。
Anthropic・OpenAI の API キー、Stripe、GitHub、Slack、JWT などが対象で、新しい Rule と Profile にマッピング済み。開発部門のコード共有経路（チャット、コラボツール）に当てるのが定石です。1点だけ、139.0.0 のデプロイ完了を待ってから新しい Rule / Profile を使うよう注記があるので焦らずに。
このほか R139 では、Threat Hunting の専用設定ページ新設と、R137でBetaだった HTML Smuggling 挙動検知のGA も入っています。
4. AI統制：可視化がGAになり、MCPに"効くポリシー"が入った
R136〜R138 のAI統制はBetaの積み上げ期間でした。R139〜R140で、使う段に入ります。この領域はアップデートの量が多いのですが、運用者として押さえるのは3つだけだと思っています［出典: 139.0.0 / 140.0.0］。
① AI Command Center（AICC）がGA（R139）。
組織で使われているAIアプリとMCPサーバーを発見して、ユーザーのやり取りを監視するダッシュボードです。AI統制の議論が「そもそも何が使われているのか分からない」で止まっているなら、棚卸しの起点がGAになったここから始められます。
② Agentic Broker の MCP 制御が RTP ポリシーになった（R140）。
専用の RTP ページで、特定 MCP サーバー単位・カタログのカテゴリ単位・Any MCP Traffic の3段階でポリシーを組めます。SkopeIT にも MCP アクティビティのイベントが載るようになりました。社員が勝手に MCP サーバーを繋ぎ始める問題は、もう「見えているけど止められない」段階ではなくなったわけです。
ただし1つ、リリースノートの端に大事なことが書いてあります。カタログに新規追加された MCP サーバー群は、RTP のサーバー一覧にまだ出てこず、カテゴリベースのポリシーからも除外されます。制御するには先に Destination Profile を作って紐付ける手順が必要。「カテゴリで包括ブロックしてあるから新しいサーバーも守られている」という前提は、この除外仕様で崩れます。ここ、見落とすと痛いポイントです。
③ ローカルLLMに観測点が置かれた（R140、Beta）。
Endpoint AI Security として、Netskope Client（Windows/macOS）がシャドーAIエージェントやローカル実行LLMのネットワーク接続を監視し、テレメトリを AICC に送ります。ペイロードは検査しません。プロキシを通らないローカルLLMは今まで可視化の完全な死角だったので、そこに観測点が置かれた意味は大きいと思います。
細かいところでは、AI Guardrails の誤検知をサポートチケットなしで UI / API から報告できるようになりました（R140）。チューニングの往復が減る、地味に好きな変更です。なお Deepfake 検知 API や AI Red Teaming の強化も入っていますが、多くの運用現場ではまだ出番が薄いので今回は割愛します。
5. 既定挙動の変更と予告：静かに変わるものリスト
ここからは機能追加ではない変更です。お客様の問い合わせ対応をしていると、この手の既定値変更は数ヶ月後に「急に挙動が変わったんですが」という形で返ってくるので、先に書いておきます。
- 通知メールの reply-to 変更（R139）：RTP ポリシーのメール通知で「From Email」未指定時の reply-to が、テナント管理者アドレスから
do-not-reply@netskope.comに変わりました。ユーザーからの返信が管理者に届く前提の運用は見直しを。 - Early File Size Checks（R139、新規テナントのみ既定有効）：検査上限を超えるサイズのファイルはバッファせずストリーミング転送されるようになり、大容量ダウンロードの遅延が減ります。既存テナントは既定変更なし。「ダウンロードが遅い」という問い合わせが多い環境は、有効化を検討する価値があります。
- URLフィールドの6KiBキャップ（R140）：イベントログの URL 型フィールドが 6KiB で切り詰められます。長大 URL の完全一致で SIEM 側の検索・相関を組んでいる場合は前方一致へ。
- R141 で DLP 検出エンジンのコンポーネント更新（R140で予告）：
メタデータ検査から抽出される「Author」「format」等のフィールドが変わります。影響は想定されないとしつつ、141展開後の検証テストを強く推奨と明記されています。メタデータ依存の DLP ルールを今のうちに洗い出しておけば、141対応はサクッと終わるはずです。 - Google Apps が BYOP へ（R140）：Google Workspace API の従量課金化を受け、API Data Protection の Google 連携が自社所有の GCP プロジェクトを使うモデルに移行します。共有クォータの影響を受けなくなる代わりに、GCP プロジェクトの管理が自社側の仕事になります。
- 管理コンソールの WebUI 刷新が進行中（完了目標 2026年12月31日）：ゼロインパクト変更とされていますが、手順書のスクリーンショットは順次古くなります。地味に困るのはここですよね。
- 【既知の不具合/R140で解消】Windows 再起動後に全通信が遮断される可能性（R139、Issue 1022611）：
セルフサービスパスワードリセット（SSPR）などの再起動時、Client が Windows のビルトインシステムアカウント（WsiAccount）をアクティブなユーザーセッションと誤認し、ログイン前に Fail Close が発動して全トラフィックを遮断する場合がありました［出典: 139.0.0］。- この事象は R140 で修正済みで、再起動時にビルトインシステムアカウントを正しく無視し、SSPR も期待どおり動作するようになっています［出典: 140.0.0 Fixed Issues］。
- ただしこのブログを記載している2026年8月は R140 への移行期間中。R139 のままの端末で Fail Close 運用をしている場合は、展開が完了するまで回避策（Dynamic Steering の有効化）で凌いでください。
このほか、刺さる人には刺さる変更を一行ずつ：NPA のアプリ定義が FQDN のパターンマッチに対応（R139、Beta。ECS のような動的ホスト名の定義追従がやっと楽に）、SSL 復号ポリシーのグループ/OU/国の除外指定が GA（R140、フィーチャーフラグ配下）、Client の対応 OS に RHEL 10・Ubuntu 26.04・Android 17・ChromeOS 149/150 が追加。Enterprise Browser と RBI も今回かなり更新されていますが、展開中のテナント以外にはまだ縁遠いので割愛しました。気になる方は一次情報へ。
6. まとめ
今回は R139とR140 のアップデートから、Auto Re-enable のGAを中心に、Claude 関連ドメインのカテゴリ再編、Process Name ポリシーや MCP 制御など、運用者目線で刺さった変更をご紹介しました。
「有効化忘れで無効化しっぱなし」は、運用担当者としてもアプローチしたい課題の一つでした。製品側が復旧まで面倒を見てくれるようになったのは素直に嬉しいです。運用の工夫でカバーしていた部分が製品機能に吸収されていくのは、こうあってほしい進化ですね。
一方で Claude のカテゴリ再編のように、放っておくと勝手に挙動が変わる変更も入っています。こちらは使うかどうかを選べないので、Claude を業務利用している組織は展開前の点検をお忘れなく。どなたかの運用の参考になれば幸いです。
7. FAQ
Q1. Auto Re-enable を入れたら、無効化検知の仕組みはもう不要ですか？
A. 役割が変わるだけで、価値は残ります。復旧は Auto Re-enable が自動でやってくれますが、「なぜ無効化したのか」は分からないままです。無効化の理由はステアリング例外やポリシーの改善点を教えてくれる情報源なので、検知・通知の仕組みは原因把握のチャネルとして残すことをおすすめします。
Q2. Claude のカテゴリ再編で、最低限どこを見ればよいですか？
A. 2点です。①Generative AI カテゴリを条件に使っている RTP／コーチング／DLP ポリシー（Claude トラフィックが新たに入る側）、②「Anthropic PBC」や Technology カテゴリを前提にした例外・個別指定（対象を失う側）。展開後に SkopeIT で実トラフィックのポリシーマッチを確認するところまでがワンセットです。
Q3. Agentic Broker の MCP 制御はすぐ使えますか？
A. まず前提として、Agentic Broker は別ライセンスのアドオン機能なので、契約がなければそもそも使えません。そのうえで、RTP ページ自体は R140 で提供されますが、カタログに新規追加された MCP サーバーは RTP のサーバー一覧に未収載で、カテゴリポリシーからも除外されます。これらは Destination Profile を作成して紐付ける手順が必要です。「カテゴリで包括ブロックしているから新しいサーバーも守られている」とは限りません。
8. 参考リンク（一次情報）
- Netskope Release Notes Version 139.0.0（Netskope公式）
- Netskope Release Notes Version 140.0.0（Netskope公式）
- Netskope Release Notes（インデックス）
- 関連記事: Netskope Client の「無効化しっぱなし」を検知してユーザーに気付かせる
免責: 機能の挙動・可用性はテナント・地域・ライセンス・デプロイモード（FedRAMP/PBMM等）により異なる場合があります。導入判断時は必ず最新の公式ドキュメントとテナント上の表示を確認してください。
