Claude Codeでネットワークが遅い原因を読み取り専用で切り分ける

「ネットワークが遅い」は、原因が名前解決、経路、相手先のポートのどこにあるかで打ち手が変わります。Claude Codeに調べさせるなら、診断だけを許可し、設定を変えるコマンドは最初から止めておく構成が安全です。

この記事は、WindowsのTest-NetConnectionを中心に、pingと経路確認を読み取り専用で回す権限設定を書きます。続けて、出力から原因の候補を絞る頼み方と、許可が思ったとおりに効かないときの見方を扱います。

遅さを切り分ける順番を先に決める

Claude Codeに「遅い原因を調べて」とだけ頼むと、コマンドの選び方も順番もモデル任せになります。調査の順番は人が決めておくと、許可するコマンドも自然に絞れます。

遅さの切り分けは、次の4段で考えると整理しやすくなります。

どの段でも、必要なのは「見る」操作だけです。IPアドレスやDNSサーバーを書き換えるコマンドは、診断のどこにも要りません。この性質が、読み取り専用で回せる根拠になります。

イベントログ側の切り分けはClaude CodeでGet-WinEventを使いイベントログの原因を切り分けるに書いています。ネットワークが遅い原因がOS側のサービス停止にあるなら、そちらと併用できます。

Test-NetConnectionで何が見えるか

Test-NetConnectionはWindowsのNetTCPIPモジュールのコマンドレットです。Microsoft Learnの説明では、ping、TCP接続、経路追跡、経路選択の診断に対応します。

出力には、DNSの参照結果、IPインターフェースの一覧、経路や送信元アドレスの選択結果、接続が確立したかの確認が、指定した引数に応じて含まれます。本記事の4段との対応は次のとおりです。

-InformationLevelにはQuietとDetailedを指定できます。Quietにすると、pingなら成功か失敗かの真偽値だけが返ります。原因の候補を絞りたい調査では、Detailedのほうが材料が多く残ります。

-TraceRouteは経路追跡のスイッチで、-Hopsでたどるホップ数を指定できます。-DiagnoseRoutingは、遠隔ホストに対する経路と送信元アドレスの選択情報を出力します。

Test-NetConnection -ComputerName example.com -InformationLevel Detailed
Test-NetConnection -ComputerName example.com -Port 443
Test-NetConnection -ComputerName example.com -TraceRoute -Hops 15
Test-NetConnection -ComputerName example.com -DiagnoseRouting `
  -InformationLevel Detailed

example.comは置き換え用のホスト名です。調査対象の社内ホストや、遅いと報告のあったサービスのFQDNに換えて使います。

診断だけを許可するpermissions設定

次に、上の診断コマンドだけを確認なしで通す設定を書きます。PowerShellの権限ルールはPowerShell(コマンド *)の形で、Bashと同じ形式です。*は任意の位置に置け、:*は末尾の *と同じ意味になります。

{
  "permissions": {
    "allow": [
      "PowerShell(Test-NetConnection *)",
      "PowerShell(ping *)",
      "PowerShell(tracert *)",
      "PowerShell(Resolve-DnsName *)"
    ]
  }
}

コマンドレットの別名は、照合の前に正規化されます。Get-ChildItemのルールがgciやlsにも一致するのと同じ扱いです。大文字小文字は区別されません。

ルールの置き場所は/permissionsで確認できます。ダイアログには全ルールと、それぞれが書かれたsettings.jsonが並びます。ルールを足したり消したりすると、Claudeの次のツール呼び出しから反映されます。

macOSやLinux、WSLで調べるなら、同じ考え方をBashのルールで書きます。

{
  "permissions": {
    "allow": [
      "Bash(ping -c 4 *)",
      "Bash(traceroute *)"
    ]
  }
}

ping -c 4 *のように回数の指定までルールに含めると、回数なしで走り続ける呼び出しは許可の対象から外れます。引数まで縛るBashのルールには、別の書き方の呼び出しを取りこぼす弱さもあります。その点は後の「許可が効かないとき」で触れます。

設定変更系をdenyで止める

許可の側を絞っても、Claude Codeが原因を探すうちに「DNSを切り替えれば直るかもしれない」と設定変更を試みる可能性は残ります。そこで、変更系のコマンドをdenyに置きます。

{
  "permissions": {
    "allow": [
      "PowerShell(Test-NetConnection *)",
      "PowerShell(ping *)",
      "PowerShell(tracert *)",
      "PowerShell(Resolve-DnsName *)"
    ],
    "deny": [
      "PowerShell(Set-DnsClientServerAddress *)",
      "PowerShell(Set-NetIPAddress *)",
      "PowerShell(New-NetRoute *)",
      "PowerShell(Remove-NetRoute *)",
      "PowerShell(Restart-NetAdapter *)",
      "PowerShell(Disable-NetAdapter *)",
      "PowerShell(netsh *)",
      "PowerShell(ipconfig /release*)",
      "PowerShell(ipconfig /renew*)"
    ]
  }
}

ルールは「deny、ask、allow」の順に評価され、最初に一致したものが結果を決めます。denyに一致した呼び出しは、より具体的なallowがあっても止まります。つまり、allowを広めに書いておいて、危ないものだけをdenyで抜く構成が成立します。

この例のdenyは、DNSサーバーの変更、IPアドレスの変更、経路の追加と削除、アダプターの再起動と無効化、netsh、DHCPリースの解放と更新を並べたものです。環境によって必要な項目は変わるので、自分の環境で「調査中に絶対に走ってほしくない操作」を洗い出して足します。

削除系コマンドがどう扱われるかは、PowerShell Remove-ItemがClaude Codeでブロックされる条件に詳しく書いています。

調査の頼み方とCLAUDE.mdの断片

権限ルールが「できること」を決めるのに対し、頼み方は「何をするか」を決めます。権限ルールはClaude Codeが強制するもので、プロンプトやCLAUDE.mdの記述は強制力を持たない、という違いを押さえておきます。CLAUDE.mdに書くのは、あくまで試行の方向づけです。

CLAUDE.mdには、調査の手順と禁止事項を短く置いておきます。

## ネットワーク調査のルール
- 調査は名前解決 → 往復時間 → ポート → 経路の順に進める
- 使うのは Test-NetConnection / ping / tracert / Resolve-DnsName のみ
- 設定を変えるコマンドは提案にとどめ、実行しない
- 結果は「確認できた事実」と「推測」を分けて報告する

依頼文は、症状と範囲を具体的に書きます。

社内システムのhttps://app.example.internal が午前中だけ遅いと報告があります。
名前解決、往復時間、443番ポート、経路の順に確かめ、
遅れの原因として考えられる箇所を候補の形で絞ってください。
設定変更は実行せず、必要なら手順だけ提案してください。

「候補の形で」と頼むのは、診断コマンドの出力だけでは原因を断定できないからです。pingの往復時間が長くても、それが相手側の負荷なのか、途中の回線なのかは、1回の測定では分かれません。測定を数回繰り返して、時間帯による差まで見て初めて、候補に重みがつきます。

出力から原因の候補を絞る読み方

出力を読むときの目安を、症状別に置きます。いずれも「候補を絞る」ための見方で、断定の根拠にはなりません。

3行目の組み合わせは、ICMPだけを遮断している環境で起きます。pingが通らないことと、サービスに接続できないことは別の話です。Claude Codeには、pingの失敗だけで「ネットワークが落ちている」と結論させず、TCPの結果と並べて報告させると、取り違えが減ります。

RTTは1回の値だけでは良し悪しが決まりません。同じ相手に対して時間帯を変えて何度か測り、比較する使い方が現実的です。

許可が思ったとおりに効かないとき

設定を書いたのに、確認ダイアログが出る、あるいは意図しないコマンドが通る。そうしたときの見どころを3つにまとめます。

次に、UNCパスです。\\server\shareのようなネットワークパスを引数に含むコマンドは、Windowsの資格情報が相手に送られる可能性があるため、読み取り専用のコマンドでも確認が出ます。共有フォルダーの応答が遅い調査では、この確認が出るのが正常な動作です。

もう1つは、Bashをdenyしたときの副作用です。Git Bashが入ったWindowsでは、Bashに対するdenyルールが1つでもあると、PowerShellツールがそのセッションでは無効になります。スコープ付きのBash(git push *)でも同じです。この警告は出ないことがあり、症状は「PowerShellが急に使えない」として現れます。回避の方法はDenying BashでPowerShellも止まる警告の意味と対処にまとめています。

denyは境界ではなく、保険として置く

denyルールは、コマンド文字列に対する照合です。Bashのドキュメントには、Bash(curl *)のdenyが絶対パスで呼んだcurlやsh -cの中のcurlを止めない、という記述があります。denyは、Claudeが普通に書く形の呼び出しを止める仕組みで、プログラムの周りの境界にはならない、という位置づけです。

PowerShell側のルールには、ASTを解析して各コマンドを個別に確認する仕組みがあります。それでも、書き方の違いをすべて塞げると考えないほうが安全です。設定変更を確実に止めたい環境では、次の2つを検討します。

• PreToolUseフックで、コマンド文字列を自前のロジックで検査して止める。PowerShellツールのフックには、Bashと同じ項目でコマンド文字列が渡されます
• 調査用のアカウントやマシンそのものの権限を絞る。OS側で変更権限を持たないアカウントなら、コマンドが通っても変更は失敗します

なお、PowerShellツールのドキュメントには、Windowsではサンドボックスが使えないと書かれています。ネットワークの変更をOSの仕組みで止める選択肢は、Windowsでは権限を絞った実行アカウントに頼ることになります。

許可ルールを増やしすぎないことも大切です。読み取り専用に見えるコマンドでも、引数しだいで通信を発生させるものがあります。pingを許可すれば外部へのICMPが出ますし、Test-NetConnectionは指定した相手に接続を試みます。調査の対象ホストを依頼文で明示し、調査先を人が決める運用にしておくと、意図しない相手への接続を避けられます。Bash側の組み込みの読み取り専用コマンドの範囲はClaude Codeの読み取り専用コマンドが確認なしで通る範囲と例外で整理しています。

まとめ

ネットワークの遅さの調査は、見るだけのコマンドで進みます。許可はTest-NetConnection、ping、tracert、Resolve-DnsNameに絞り、DNS・IP・経路・アダプターを変えるコマンドをdenyに置く。この2つの設定で、Claude Codeが調べられる範囲と触れない範囲が分かれます。

出力は原因の断定ではなく、候補を絞る材料です。名前解決、往復時間、ポート、経路の順に並べ、「確認できた事実」と「推測」を分けて報告させる。そのうえで、変更が必要だと分かったら、実行は人が確認してから行います。