【Catoクラウド】Split Tunnelがアプリケーション・FQDN単位で指定可能に！

こんにちは、Cato担当 中川です。今回の記事ではSplit Tunnelの機能強化について取り上げます。

「Catoに接続しているとWeb会議が重い気がする」というご相談は、導入前のお客様からも運用中のお客様からもよくいただきます。こうした場合の対処として、Catoクライアントの Split Tunnel(特定の通信をCatoのトンネルから除外する機能)が候補に挙がります。

従来のSplit Tunnelは、除外する宛先をIPアドレスでしか指定できませんでした。Web会議のようなSaaSは接続先が多数あり、しかも変化するため、IPアドレスでの管理は現実的ではありません。

2026年7月13日のアップデートで、この除外対象を Catoが動的に更新するFQDNベースのアプリで指定できるようになりました。
本記事では、Teamsを除外対象にして、設定内容、実際の経路の変化、そして通信品質を測定した結果をご紹介します。

先に結論をお伝えすると、除外そのものは確実に効いた一方で、今回の環境では通信品質は改善しませんでした。この結果から言えることも、あわせて整理します。

なお、Split Tunnelの基本的な動作は、以前の記事「CatoクライアントのSplit Tunnelを使用して複合機を利用する」で解説されていますので併せてご参照ください。

簡単に補足しておくと、Split Tunnelは下記のようなイメージで通信が流れます。Catoクラウドを迂回する点がポイントです。

機能強化のポイント

宛先をFQDN、アプリで指定可能に

従来のSplit Tunnelでは、除外対象はIPアドレスまたはサブネット単位で登録するものでした。

この機能強化は、Catoの2026年7月13日のProduct Updatesで、次のように案内されています。

Client Split Tunnel Policy Supports FQDN-Based Apps Split Tunnel Policyが、Catoが動的に更新する FQDNベースのアプリ を使えるように強化されました。ポリシーのメンテナンスが簡単になります。クライアントは、一致した通信をインターネットへ直接、またはCato経由でルーティングします。 Windowsクライアント v6.4以上で対応

(上記は公式リリースノートの要約です。原文はProduct Updates – July 13, 2026をご覧ください。)

ポイントは、Cato側が「アプリ」に対応するFQDNを管理し、動的に更新してくれることです。管理者がIPアドレスやドメイン名を調べて登録し続ける必要がなくなり、Web会議のようにアドレスが頻繁に変わるサービスでも、運用の手間を抑えられます。

CMAのSplit Tunnel Policyでは、Excluded Destinations という設定項目で、アプリを選んで除外できます。

アプリケーション指定で選択できるアプリ

検証時点(2026年10月)のCMAで、Excluded Destinationsとして選択できたアプリケーションは以下のようなものがありました。

Web会議だけでなく、帯域を消費しやすいWindows Updateや動画配信、生成AIサービスなども選べるのが特徴です。

任意のFQDNも指定可能

Catoが用意しているアプリから選ぶだけでなく、管理者が任意のFQDNを入力して除外対象にすることもできます。ワイルドカードを使った指定にも対応しています。自社専用のシステムや、一覧にないSaaSの通信を除外したい場合は、FQDNで指定します。

Teamsをアプリ指定でSplit Tunnelの対象にしてみる

Teamsをアプリ指定でCato非経由の設定にし、機能するか試してみました。

CMAの設定

CMAの Access > Split Tunnel Policy で、次のようにルールを作成しました。

除外が効いていることの確認

結論として、除外は意図どおりに効いていました。

Catoクライアントを起動してルールの対象にしたユーザーが使うPCで、ルーティングテーブルを見ると、Cato側のデフォルトルート(メトリック0)に加えて次の2つのルートが追加されていました。

52.112.0.0   255.252.0.0   192.168.1.1   192.168.1.9   35
52.122.0.0   255.254.0.0   192.168.1.1   192.168.1.9   35

Microsoft(Teams)のIPアドレス帯が、Catoの仮想NICではなく、PC自身のNICとゲートウェイから直接出るように登録されています。

図:CatoのApp CatalogでTeamsのIPレンジとして定義されているアドレス（追加されたルートと一致していることがわかる）

通信品質が変わるか測定してみた

Microsoftが提供している Microsoft Teams Network Assessment Tool を使って測定してみました。
Teamsのリレーとの間のパケットロス、遅延、ジッターを測定するツールです。

結果は以下の通りで、残念ながら、Cato非経由にしても品質は改善せず、遅延はむしろ増える結果となりました。

なお、ツールを使うと測定結果のCSVが出力され、通信の送信元(LocalIP)と、Teamsのリレーから見えた送信元の公衆IP(ReflexiveIP)が記録されます。
Cato経由の場合はCatoの仮想NIC・CatoのEgress IP、Cato非経由の場合は物理NIC・回線事業者のIPで記録されたので、Catoのトンネルを通らず、PCの物理NICから直接出ていることが確認できました。

Catoは自社バックボーンで最適な経路を選ぶ特長があります。そのため、Cato経由と非経由のどちらが速くなるかは、回線事業者やPoPの位置によって変わります。今回の環境では、非経由にしても品質は改善しませんでした。

また、今回の検証はWi-Fi環境で測定しています。Split Tunnelによる遅延低減の効果は有線でないと現れずらいのかもしれません。

利用上の注意点

Split Tunnelの対象を追加する際に注意すべき事項を列挙します。

除外した通信は、Catoのセキュリティ検査を受けない

この点が最も重要です。
FW、IPS、アンチマルウェア、TLSインスペクションなどが適用されず、Catoのログにも残りません。

セキュリティとのトレードオフとなることに十分ご注意ください。「速くしたい」という理由だけで選ぶのではなく、除外によって失われる検査やポリシーの適用を確認したうえで、必要最小限にとどめてください。

「重いから除外」は、効果を測ってから

今回の結果のとおり、除外しても改善するとは限りません。改善しないまま、セキュリティだけが弱くなる可能性があります。
除外する前に、原因の切り分けと、効果の測定を行ってから除外いただくことを推奨します。

除外の範囲は最小限に

除外対象は以下の3点に留意して、最小限に限定するようにしましょう。

• 対象ユーザー/グループを絞る
• 対象のアプリを必要最小限にする
• 効果がなければルールを削除する。定期的に棚卸しする

さいごに

今回は、Split Tunnelをアプリ単位(Microsoft Teams)で指定して、除外の動作と通信品質を検証しました。

• アプリ指定により、IPアドレスの変化を意識せず、Teams通信を除外できた
• 経路はroute printや測定結果から、確実に変わっていることを確認できた
• ただし、通信品質は今回の環境では改善しなかった

Web会議が遅いと感じたときに、すぐ除外に走るのではなく、まず「何が原因か」を切り分けること。そして除外する場合は、効果を測って、対象を絞ること。この2点が、Split Tunnelを安全に使うポイントです。