 本記事は 夏休みクラウド自由研究2026 8/26付の記事です。 |
こんにちは。廣木です。
以前、Catoの「Advanced AI Assistant」について紹介させていただきました。
当時のAI Assistantは、ネットワーク状況の確認、イベント調査、ユーザ分析、ナレッジベース検索など、主に「調査」や「分析」を支援する機能という印象でしたが、最近のアップデートにより、AI Assistantはさらに進化しています。
最新機能
まずは、最新機能のご紹介です。
今回のアップデートにより、AI Assistantは単なる調査だけではなく、以下のような運用アクションまで支援できるようになりました。
- Internet Firewallルールの作成
- 既存ポリシーの分析
- リモートユーザセッションの取り消し
- ユーザリスクスコアのリセット
利用時の注意事項
それは、AI Assistantにどのような形で質問するのが効果的なのか、という点です。
公式ドキュメントでは、サイト名、ユーザ名、アプリケーション名、ポリシー名、時間範囲など、分かっている情報をできるだけプロンプトに含めることが推奨されています。
実際、ChatGPTと同様に、質問が具体的であるほど期待する回答を得やすい印象でした。
たとえば、
Boxにアクセスできない
ではなく、
user.a@example.co.jp が過去24時間に Box へアクセスできなかった原因を調査して
のように対象ユーザや時間範囲を明確にした方が、より精度の高い調査結果が期待できそうです。
検証シナリオ
そこで今回は、実際の運用で起こりそうな下記3つのシナリオを想定し、できるだけ具体的な条件を与えながら検証してみました。
今回試してみるシナリオ
- SaaSアプリへのアクセスがBlockされた原因を調査し、許可ルールを作成する
- ユーザのリスクレベルがHighとなり、SaaSアプリへアクセスできない原因を調査して復旧する
- 不審なユーザ操作を確認し、リモートユーザセッションを取り消す
シナリオA： SaaSアプリへのアクセスがBlockされた原因を調査し、許可ルールを作成する
まずは、Internet Firewallに関するシナリオです。
単にAI AssistantでFirewallルールを作成するだけではなく、今回は実運用に近い流れとして、
- ユーザから問い合わせが来る
- AI Assistantで原因を調査する
- Blockしているポリシーを特定する
- 許可ルールを提案してもらう
- 未公開リビジョンを確認する
- 管理者がPublishする
という流れを想定します。
検証
それでは、検証を行います。
テストユーザAから以下のような問い合わせがあったとします。
「Gmailにアクセスできません」
従来であれば、管理者はEvents画面を確認し、対象ユーザ、宛先アプリケーション、該当するInternet Firewallルールを順番に調査する必要がありますが、今回はAI Assistantを使ってみましょう。
まず以下のように聞いてみます。
日本時間の8/12(水) 12:45～13:00において、テストユーザA が Gmail にアクセスできない原因を調査して
すると以下のような回答が得られました。
結論
テストユーザA が Gmail にアクセスできない原因は、Internet Firewallポリシーの「Test Rule」によって、12:45～12:52の間に6回連続でGmailへの接続がブロックされたためです。このルールはmail.google.comへのHTTPS接続（ポート443）を遮断しており、ユーザはGmailの同期機能を使用できない状態です。
推奨対応
- Internet Firewallポリシーの「Test Rule」を確認し、Gmail（Emailカテゴリ）をブロックする意図が正しいか検証
- 必要に応じて、テストユーザAまたは特定のユーザグループに対してGmailアクセスの例外を設定
実際にイベントログをみてみると、AI Assistantの回答通り「Test Rule” ルール（index 5）」にヒットしてBlockされているログが確認できました。
ここまでで、想定通りAI Assistantが対象ユーザの通信イベントを確認し、原因となっているInternet Firewallルールを特定できていることがわかります。
次に、許可ルールを提案してもらいます。
テストユーザA が Gmail を利用できるように Internet Firewallルールを作成してください。作成前に既存ルールとの重複や競合を確認し、最も安全なルール追加位置も提案してください。
すると以下のような回答が得られ、さらには「Approve(承諾)」 or 「Reject(拒否)」の選択ができるようになっていました。
テストユーザA が Gmail を利用できるようにする Internet Firewall ルールのドラフトを準備しました。詳細は以下の通りです：
ルール設定:
- ルール名: Allow Gmail for テストユーザA
- 配置位置: “Test Rule” ルール（index 5）の直前
- 送信元: テストユーザ A (user.a@example.co.jp)
- 送信先: Gmail (Email カテゴリ)
- アクション: Allow（許可）
- トラッキング: イベントログ有効
このルールドラフトは、テストユーザA からの Gmail へのアクセスを許可します。現在 Gmail をブロックしている “Test Rule”（index 5）よりも前に配置されるため、テストユーザA は Gmail にアクセスできるようになります。このルールドラフトを作成してよろしいですか？
このように、許可ルールを提案してくれました。
ここで、ルール名、配置位置、送信元、宛先、アクションに問題ないことを確認し、回答が正しいことを確認します。この確認は人の目でしっかり行うことが大事です。
確認できたらApproveをクリックします。
すると、このような回答が返ってきました。
Allow Gmail for テストユーザA ルールドラフト が作成されました。このドラフトは、管理者が CMA からポリシーを公開するまで有効になりません。
「管理者が CMA からポリシーを公開するまで有効になりません。」とのことなので、少なくともAIが管理者の承認なしに自動で設定を反映することはなさそうです。
「Allow Gmail for テストユーザA ルールドラフト」をクリックしてみます。
すると、下の図のようにルールが追加されていることが確認できました。
ここで、ルール名、配置、送信元、宛先、アクション、トラッキングが想定通りになっていることを再度確認します。
今回は、すべて想定通りでしたので、Publishを行います。
少し時間をおいて、実際にユーザAからGmailへのアクセスを試してみると、問題なくアクセスできることが確認できました！
イベントログでも、「Allow Gmail for テストユーザA」というルールで接続許可されていることがわかります。
ちなみに、Audit Trailには記録されるのか？気になったので確認してみました。
すると、管理者である私のアカウントで操作した記録が残されていました。
AI Assistantはあくまでドラフトを作成したのみで、実際に設定をPublishしたのは管理者である私です。
そのため、通常通りAudit Trailに操作ログが記録されているようです。
所感
このシナリオはかなり実用的だと感じました。
単純に「Firewallルールを作れる」だけではなく、Blockされた原因を調査し、そのまま修復案まで進められるという点が重要です。
従来であれば、
- Events画面で通信ログを確認
- Internet Firewallポリシーを確認
- 該当ルールを特定
- 新規ルールを作成
- 既存ルールとの重複を確認
- Publish
という流れになります。
AI Assistantを使うことで、この流れのほとんどをチャットベースで実施できるため、一次調査やルール作成の下書きにかなり使えそうです。
シナリオB： ユーザのリスクレベルがHighとなり、SaaSアプリへアクセスできない原因を調査して復旧する
次は、リスクスコアリセットのシナリオです。
正直、最初は「リスクスコアのリセットっていつ使うのだろう？」と思っていました。
しかし、CatoのUser Risk Levelに関する公式ドキュメントを読むと、かなり納得できました。
Catoでは、ユーザごとに動的なUser Risk Levelを算出し、そのリスクレベルをInternet FirewallやWAN Firewallのポリシー条件として利用できます。
たとえば、Risk LevelがHigh以上のユーザから、機密性の高い社内リソースやSaaSアプリへのアクセスをブロックするルールを作成できます。
つまり、リスクスコアリセットは単体で使うというより、リスクレベルを条件にしたアクセス制御をしている環境で、ユーザ調査から復旧まで行うためのアクションと考えると分かりやすいです。
User Risk Levelとは？
Catoでは、ユーザごとの通信状況やセキュリティイベントをもとに User Risk Level（ユーザリスクレベル） を動的に算出しています。
User Risk Levelは、ユーザが組織に対してどの程度のリスクを持つかを表す指標であり、アクセス制御にも利用できます。
リスクレベルは以下の4段階で評価されます。
- Critical（リスクスコア 96～100）
- High（リスクスコア 81～95）
- Medium（リスクスコア 31～80）
- Low（リスクスコア 0～30）
リスクスコアは、マルウェア通信や不審なアクセス、データ持ち出しの疑い、大量データ転送など、さまざまなセキュリティイベントをもとに算出されます。
また、各ユーザのリスクレベルやリスクスコアは、ダッシュボードから確認できます。
リスクスコアの推移や、どのセキュリティイベントがスコア上昇の要因となったのかも確認できるため、ユーザ調査やインシデント対応時に活用できます。
例えば、以下のユーザはリスクスコアが100のため、リスクレベルは Critical と判定されています。
- AI Assistantで原因を調査する
- 原因としてRisk LevelがHighであることを確認
- 関連イベントを確認
- 問題なしと判断
- リスクスコアリセットを実行
- SaaSアクセス復旧
検証
まずは、テストユーザAの現在のリスクレベルとリスクスコアを確認します。
このダッシュボードから、リスクスコアとリスクレベルがわかりました。
- リスクスコア：20
- リスクレベル：Low
それでは、リスクスコアをリセットしてみたいと思います。
AI Assistantに以下のように依頼します。
テストユーザA のリスクスコアをリセットしてください。
すると以下のような回答が得られ、さらには「Approve(承諾)」 or 「Reject(拒否)」の選択ができるようになっていました。
ユーザ「テストユーザ A」(user.a@example.co.jp)のリスクスコアをリセットする準備ができました。詳細は以下の通りです:
操作内容:
- ユーザ名: テストユーザ A
- メールアドレス: user.a@example.co.jp
- 現在のリスクスコア: LOW
- 操作: リスクスコアをリセット
このユーザのリスクスコアがリセットされます。実行してよろしいですか?
今回は検証なので、リスクスコアをリセットするリスクはないと判断し、Approveをします。
シナリオAの時と同様で、Approveを行う前に、この操作が本当に問題ない操作なのか？を人の目でしっかり行うことが大事です。
Approveを行うと、以下のような回答がありました。
テストユーザ A (user.a@example.co.jp) のリスクスコアがリセットされました。
リセットが正常に行われたようです。
ダッシュボードを確認すると、リスクスコアとリスクレベルがリセットされていることが確認できました。
- リスクスコア：0
- リスクレベル：Low
ここで少し気になるのは、リセット後の動作です。
公式ドキュメントには明記されておりませんが、リセット後はユーザの新しい活動に基づいてリスクスコアが再計算されるようです。
所感
最初は、リスクスコアをリセットする場面ってそんなにあるの？と思いました。
しかし、「SaaSアプリケーションへのアクセスをRisk LevelがHigh未満のユーザのみに許可する」という設計にしている場合、リスクレベルがHighになったユーザは、正規ユーザであってもSaaSへアクセスできなくなります。
こんな時、従来であれば
- Events画面で通信ログを確認
- 原因としてRisk LevelがHighであることを確認
- ダッシュボード画面で関連イベントの詳細を確認
- 問題なしと判断
- ダッシュボード画面でリスクスコアリセットを実行
- SaaSアクセス復旧
という流れになり、Events画面による一次調査やダッシュボード画面でのリセット操作が必要となります。
そこで今回、AI Assistantを使うことで、この流れのほとんどをチャットベースで実施できるということになります。
リスクスコアリセットそのものを利用する場面は限られるかもしれませんが、ユーザー調査から修復アクションまでを一貫して実施できる点は、AI Assistantの価値を示す機能の一つだと感じました。
シナリオC： 不審なユーザ操作を確認し、リモートユーザセッションを取り消す
最後は、リモートユーザセッション取り消しのシナリオです。
これは比較的イメージしやすい機能です。
たとえば、以下のようなケースです。
- ユーザが通常とは異なる大量アップロードを行っている
- PC紛失の連絡があった
- アカウント乗っ取りの疑いがある
- 業務外の不審なアクセスが確認された
Cato公式ドキュメントでは、AI Assistantがユーザアクティビティを調査し、不審な活動が確認された場合に、予防的措置としてユーザのアクティブセッション取り消しを提案するユースケースが紹介されています。
検証
それでは、実際にやってみます。
従来であれば、Eventsや各種ダッシュボードで対象ユーザの活動を調査し、不審な活動が確認された場合は、Users Directoryから対象ユーザを検索して「Revoke Sessions」を実行する必要があります。
今回はAI Assistantを使ってみます。
まずは、セッション状態を確認してみます。
ユーザA の現在のアクティブセッションを表示してください。
すると以下のような回答がありました。現在もセッションは正常に確立されていることがわかります。
ユーザーA の現在のアクティブセッション
スナップショット取得時刻: 2026年8月13日 09:53 JST
項目 詳細 ユーザー名 テストユーザ A メールアドレス user.a@example.co.jp 接続状態 接続中 (Connected) 運用ステータス アクティブ (Active) – トラフィック通過中 接続タイプ リモート接続 (Remote) デバイス名 xxxx OS macOS クライアントバージョン 6.0.1.11646 接続PoP Tokyo_DC4（東京データセンター4） セッションステータス
- 現在のセッション時間: 1時間未満（短時間セッション）
- トラフィック状態: アクティブにデータ通信中
- 認証状態: 正常
- デバイスポスチャー: 準拠
接続詳細
このユーザーは現在、日本の東京（Tokyo_DC4 PoP）経由でCatoクラウドに接続しており、MacBook Air (2)からリモートアクセスしています。セッションは正常に確立されており、トラフィックが通過している状態です。
続いて、ユーザアクティビティを確認してみます。
ユーザA の過去2日間のユーザーアクティビティを分析し、不審な操作や通常と異なる挙動がないか確認してください。
すると以下のような回答がありました。
特にハイライト部分は有益な情報だと感じました。管理操作や接続傾向が要約されているため、第三者による不審な操作が行われていないかを効率的に確認できます。
アクティビティサマリー
- VPN/SDP接続アクティビティ
- 接続イベント数: 48件（認証、接続、切断を含む）
- デバイス: xxxx
- 接続元: 日本 (IP: x.x.x.x)
- 接続パターン:
- 複数のPoP間での頻繁な切り替え（Tokyo、Tokyo_DC2、Tokyo_DC3、Tokyo_DC4）
- 短時間での接続・切断の繰り返し（数秒～数分間隔）
- 最新の接続: 2026-08-13 00:39:41 UTC (Tokyo_DC3)
- セキュリティイベント
- 脅威検知: 150件のマルウェアスキャンイベント
- Anti Malware: 128件
- NG Anti Malware: 22件
- すべて「clean」判定 – 脅威は検出されていません
- アクセスしたアプリケーション:
- Box（ファイル共有）
- Qualified Com（ビジネス情報）
- すべてのアクセスが「Allow」で許可されています
- 管理操作（設定変更）
このユーザーは管理者権限を持ち、過去2日間で28件の設定変更を実施:
- 主な変更内容:
- Internet Firewallポリシー変更 (22件)
- 新規ルール作成: 「Test Rule_Box」（Boxアプリをブロック、User GroupA対象）
- 新規ルール作成: 「Allow Gmail for テストユーザA」（自分用のGmail許可ルール）
- ルールの有効化/無効化の切り替え
- リスクスコア条件の変更（GTE ⇔ LTE）
- ユーザーグループ変更 (4件)
- グループ名変更: 「Outlook Block」→「User GroupA」
- ユーザー情報変更 (2件)
- 自分自身と他のユーザーの名前変更
注意すべき点
- 異常な接続パターン
- 短時間での頻繁な切断・再接続: 8月12日 08:58～09:39の間に10回以上の接続/切断
- 複数PoP間の頻繁な切り替え: Tokyo、Tokyo_DC2、Tokyo_DC3、Tokyo_DC4間での移動
- これはネットワーク不安定性または意図的な接続テストの可能性があります
- 管理者権限の積極的な使用
- 2日間で28件の設定変更は通常より多い活動レベル
- 特に自分自身を対象としたファイアウォールルール作成（Allow Gmail for テストユーザA）
- テスト目的の可能性が高いですが、権限の適切な使用を確認する必要があります
- ポリシー変更の頻度
- 同じルールに対する短時間での複数回の変更（リスクスコア条件の反転など）
- これはテスト・検証作業の可能性が高いですが、本番環境での頻繁な変更は注意が必要です
正常な点
- セキュリティ脅威なし: すべてのマルウェアスキャンで脅威は検出されていません
- 認証成功: すべての認証が成功しています（失敗なし）
- デバイスポスチャー: クライアント接続ポリシーで「Allow」判定
- アンチマルウェア有効: Xprotect、Gatekeeperが有効化されています
推奨事項
- 接続の安定性確認: 頻繁な切断の原因調査（ネットワーク品質、クライアント設定）
- 管理操作のレビュー: テスト作業であることを確認し、本番環境への影響を評価
- ポリシー変更の文書化: 変更の目的と承認プロセスの確認
今回は検証環境のテストユーザによる操作履歴のため、問題ない活動であると判断できます。
一方、実環境で同様の調査を行い、不審な操作や第三者による利用が疑われる場合は、被害拡大防止のためにセッション取り消しを実施する運用が有効だと考えられます。
それでは、AI Assistantにセッション取り消しを依頼してみます。
テストユーザA（user.a@example.co.jp）のすべてのアクティブセッションを切断し、再認証を強制してください。
すると以下のような回答があり、今回も同じように「Approve(承諾)」 or 「Reject(拒否)」の選択ができるようになっていました。
つまり、実行前には提案内容を確認し、管理者が承認する必要があります。
テストユーザA（user.a@example.co.jp）のすべてのアクティブセッションを切断する準備ができました。詳細は以下の通りです:
セッション切断の設定:
- 対象ユーザー: テストユーザ A (ID: 136)
- メールアドレス: user.a@example.co.jp
- 操作: すべてのアクティブセッションを強制切断
- 影響: 現在接続中のすべてのデバイス（VPN/SDP）が切断されます
- 再認証: ユーザーは次回接続時に再認証が必要になります
この操作により、ユーザーAの現在のすべてのVPN/SDPセッションが即座に切断され、再度接続するには認証が必要になります。実行してよろしいですか？
「Approve(承諾)」して約1分後、テストユーザAの端末では再認証が求められました。
今回はユーザの調査を先に行っていますが、PC紛失などの場合は、即座に社内リソースへのアクセスを止めたいですよね。
そのような場合は、まずセッションを取り消して社内リソースへのアクセスを停止し、その後にユーザの活動履歴を調査するという運用も可能です。
所感
この機能は、ヘルプデスクやSOC運用の初動対応と相性が良さそうです。
従来であれば、対象ユーザを検索し、ユーザ詳細やセッション情報を確認し、必要に応じてセッションを取り消す必要があります。
AI Assistantを使うと、
- ユーザの状況を確認
- 不審な操作を確認
- セッション取り消しを提案
- 管理者が承認
- 再認証を強制
という流れをチャット上で進められます。
実際に触って感じたこと
今回の検証を通じて、AI Assistantは単なるAIチャットではなく、運用担当者の調査から修復までを支援するアシスタントに近づいていると感じました。
特に価値を感じたのは、以下の3点です。
調査から修復までを一気通貫で支援
Firewallルール作成機能は便利ですが、それ以上に、Block原因の調査 → 影響ルール特定 → 許可ルール提案 → Publishという一連の流れを支援できる点に価値を感じました。
単にInternet Firewallルールを作成するだけなら、GUIでも簡単に対応できます。
AI Assistantは、Internet Firewallブロックイベントの確認、既存ルール分析、競合確認、推奨挿入位置の確認といった用途に使えるため、原因調査からルール提案までを支援できる点が大きいと感じました。
しかし、Risk LevelがHigh以上のユーザをSaaSアクセスから除外する設計であれば、話は変わります。
Risk Levelを条件にSaaSアクセスを制御している環境では、ユーザ復旧アクションとして有効な場面があると言えます。
今回のような機能は便利な一方で、AIが勝手に設定変更してしまうのでは？という不安もありますよね。
この点について、AI AssistantによるInternet Firewallルール作成は、管理者が提案内容を確認して承認した後に未公開リビジョンとして追加され、Publishするまでトラフィックには影響しません。
また、リモートユーザに対するリスクスコアリセットやセッション取り消しも、提案されたアクションを確認し、管理者が承認した後に実行されます。
そのため、AI Assistantは「勝手に変更するAI」ではなく、管理者の判断を前提に、調査と修復の流れを効率化するAIと捉えるのが良さそうです。
さいごに
今回は、CatoのAI Assistant機能について、実運用に近い3つのシナリオで検証してみました。
特に印象的だったのは、AI Assistantが単なる検索・分析ツールではなく、調査から修復アクションまで支援する運用アシスタントに進化している点です。
Internet Firewallルール作成については、単にルールを作れるだけでなく、Block原因の調査や既存ルール分析と組み合わせることで、より実用的な使い方ができそうです。
今後、Catoの運用では、「まずAI Assistantに聞いてみる」という場面が増えていくかもしれません。
ただし、Firewallルールやユーザセッション、リスクスコアはいずれも運用影響がある項目です。
AI Assistantの提案を活用しつつ、最終的な判断と承認は管理者が行う、という前提で使っていくのが良さそうです。
引き続きこの機能は 無料で利用可能ですが、今後有償になることも予想されます。無料期間中に、ぜひCMA右上の 「Ask AI」 をクリックして実際に試してみてください！