こんにちは、こやしぃです。
Netskopeのアップデートにより、管理コンソールのSkope IT画面に新たなメニューとして【Transaction Events】が追加されました。
「元々、Transaction Eventsというログはあったのでは？」とお気づきの方もいらっしゃるかもしれません。そのご認識は正しく、今回のNetskopeのアップデートによって、このログの活用方法が大きく進化したのです。
本ブログでは、これまでの仕様との違いを整理しつつ、追加のメリットや具体的なユースケース、運用上の注意点を見ていきます。
一方でこれまでは下記のような運用の違いがありました。
つまり外部にSIEMなどの環境を構築していなくても、Netskope単体で最大30日間のログをフィルタリングして閲覧・調査が行えるようになった事が今回の大きな変更点です。
管理画面から直接アクセスできるようになったことで、以下のようなメリットがあります。
別途ログ保管サーバー等を用意しなくても、Netskope単体でパケットレベルに近い詳細な通信ログを追跡できます。
現在のTransaction Eventsは、すべてのトランザクションログで同じフォーマットで統一されており、ログの比較が容易になりました。
※2026年6月現在、Advanced AnalyticsのUIはユニバーサルフォーマット未対応となります。今後対応となりましたらこちらでお知らせします。
参考リンク：https://docs.netskope.com/jp/transaction-events-fields-reference
リモートブラウザ隔離を経由した通信のログもここに集約されるため、隔離された通信も含めて一元的に管理できます。
「特定のWebサイトにアクセスできない」「通信速度が極端に遅い」といった社内ユーザーからの問い合わせに対し、原因の切り分けを迅速に行うことができます。
まずログの詳細画面（ = Transaction Event Details）を開くと、
① Client（端末〜Netskope）…クライアント側で何が起きたか
② Netskope…プロキシとして間に入っているNetskope上で、どう判定されたか
③ Remote Server（Netskope〜宛先サイト）…実際の宛先で何が起きたか
の3つの区間の情報が並んで表示されます。これらを切り分けて見ることで、問題がどこで起きているかを調査しやすくなります。
各項目の意味については、Netskope 公式ドキュメントのName in Management Consoleをご確認ください。
https://docs.netskope.com/jp/transaction-events-fields-reference
下図が、実際のTransaction Event Detailsです。
※個人情報や社内ネットワーク情報が含まれるため一部マスキングしています
・Action / Action Reasonで「何の事象が起きたか」を把握する
Action → Allow / Block / Alert など、Netskopeがその通信をどう処理したか
Action Reason → なぜその判定になったか（policyであればポリシーマッチ、malwareであれば検知理由など）
たとえば 「このサイトにアクセスできない」という問い合わせに対し、ブロックなのか、そもそもポリシー上アクセス不可なのかを最初に確認する出発点になります。
・Classificationで端末の管理プロファイルを確認する
ClassificationはNetskope Clientの分類プロファイルとして、このアクセスをしたPCが、社内でどの管理グループに属しているかを示す項目です。ここでは、 通信元デバイスにNetskope Clientが導入されている (＝Managedされている) か、そしてどのプロファイルが適用されているかを確認し、端末管理状況の切り分けに使うことができます。
また、それぞれの区間のバイトカウント（データ送受信量）を確認することで、以下のような判断が可能です。
| 区間 | フィールド名 / 管理コンソール表示名 | 意味 |
| Client側 |
|
クライアント ⇔ Netskope POP 間のバイト数 |
| Netskope側 | bytes (Total Processed Bytes) |
プロキシが処理した合計バイト数（cs-bytes + rs-bytes） |
| Remote Server側 |
|
Netskope POP ⇔ リモートサーバー間のバイト数 |
これらを比較することで、【社内ネットワーク側（Client側）に問題があるのか】それとも【相手先のサーバー側（Remote Server側）の応答が遅いのか】を探ることができます。
Netskope経由のHTTP/HTTPSリクエスト等が個別のイベントとして記録されるため、ユーザーのアクティビティを時系列で詳細に追跡できます。これによりポリシー違反の調査やシャドーITの監査証跡として、より深い分析が可能になると考えられます。
Transaction events は便利な機能ですが、現状（2026年6月時点）の仕様として、いくつかの点に留意する必要があります。
直近（0〜7日前）のログ検索は15秒程度ですが、7〜30日前のログ検索には60秒程度かかる場合があります。
実際に弊社のテナントで試してみたところ、ログ最大表示(=500件)にしてもNetskope利用者全員(数十人)の当日のログが表示され、過去のログが追跡しづらいように感じられました。Transaction events はフィルタリング機能が非常に豊富な為、もしURLやTransaction IDなどの絞り込みをかけるファクターが大量にある場合は、それらを活用した方がスムーズです。
画面上に「Export」ボタンはありません。ログを外部に書き出して長期保管したい場合は、従来通り別途「Log Streaming」の仕組み及びライセンスが必要です。
これまでは、外部に送信して分析するためのデータだったTransaction Eventsが、管理画面のSkope ITに実装されたことで、日々のトラブルシューティングや一次調査にすぐ使える身近なツールになりました。
すでにNetskopeを利用されている方は、ぜひ一度実際の画面で詳細なログを確認してみてはいかがでしょうか。
Netskope公式ドキュメント - 参考リンク