こんにちは！zhackです。
Claude CodeをWSL上で動かせば、WindowsのファイルやプログラムからAIが切り離される——そう思っていましたが、実際に確かめたら隔離できていたのは依存関係だけでした。ファイルシステムのアクセスもWindowsのプログラム起動も、既定の設定では素通しです。この記事では、その確認手順と、「締めるか・利便性を取るか」という判断を自分の運用でどう決めたかを書きます。
なぜWindowsで直接使わず、WSLに入れたのか
AIエージェントは自律的にコマンドを実行してファイルを書き換えます。何かミスがあったとき、被害がWindows環境全体に及ぶのが怖かったのが正直なところです。
WSL2はWindows上でLinuxカーネルを動かす仕組みで、Linux側にインストールしたパッケージ（apt / pip / npm など）はWindows側の環境には影響しません。PythonのvenvもNode.jsのnode_modulesもWSL内に閉じます。この点は調べる前から知っていて、「依存関係が汚れてもLinux側だけ」という安心感で使い始めました。
ただ、「ファイルを消されたら」「レジストリを触られたら」という不安は、依存関係の話とは別です。ここを確認しないまま使っていたのが今回の問題でした。
私の環境は以下のとおりです。
- OS: Windows（WSL2）
- Linuxカーネル: 6.6.87.2-microsoft-standard-WSL2
- ホストの物理メモリ: 31.7 GB（WSLへの割り当ては既定50%の15.5 GB）
確認してみたら、隔離できていたのは半分だけだった
結論を先に言うと、WSL内のAIエージェントはWindowsのファイルを読み書きできるし、Windowsのプログラムも起動できます。これは設定ミスではなく、WSLの既定動作です。
2026年7月時点・WSL2（Linux 6.6.87.2-microsoft-standard-WSL2）で確認しています。
/etc/wsl.conf の状態
まず設定ファイルを確認しました。/etc/wsl.conf は、WSLの起動時の動作を決める設定ファイルです。cat はファイルの中身をそのまま表示するコマンドです。
cat /etc/wsl.conf
私のファイルには、次の2行しか入っていませんでした。
[boot]
systemd=true
systemd=true はLinuxのサービス管理の仕組みを有効にする設定で、隔離とは関係ありません。つまり隔離に関する設定は何も入っていない状態です。「何も設定しないと既定がどうなるか」を確かめる必要がありました。
Cドライブがマウントされているか
WindowsのCドライブがLinux側から見えているかを調べます。mount は「いま何がどこにつながっているか」の一覧を出すコマンドです。ただ、そのまま実行すると何十行も出てくるので、| grep mnt で mnt を含む行だけに絞り込みます。
mount | grep mnt
出力の中にこれが含まれていました。
C:\ on /mnt/c type 9p (rw,noatime,aname=drvfs;path=C:\;...)
読み方はこうです。C:\ on /mnt/c は「WindowsのCドライブが /mnt/c として見えている」という意味です。type 9p はWindowsとLinuxの間でファイルをやり取りするための仕組みの名前で、ここは気にしなくて構いません。
大事なのはカッコの中の先頭、rw です。 これは read-write の略で、読み書きの両方ができる状態を表します。ここが ro（read-only）なら読み取り専用です。
一覧に出ているだけで本当に書けるのか確かめたかったので、実際に空のファイルを作ってみました。touch は、指定した名前の空ファイルを作るコマンドです。
touch /mnt/c/Users/<ユーザー名>/wsl_test.txt
エラーは出ず、ファイルが作れてしまいました。AIエージェントがここに何かを書いても、何かを消しても、WSLは止めません。
確認用に作ったファイルは、そのままにせず消しておきます。
rm /mnt/c/Users/<ユーザー名>/wsl_test.txt
WindowsのプログラムをWSLから起動できるか
ファイルが読み書きできるだけでなく、Windows側のプログラムそのものを動かせてしまうのかを確かめます。cmd.exe はWindowsのコマンドプロンプトで、/c は「このコマンドを1回実行して終了する」という指定です。つまり以下は、Linuxの中からWindowsのコマンドプロンプトを呼び出して文字列を表示させています。
cmd.exe /c "echo hello from windows"
hello from windows
普通に動きました。Linuxのシェルから打ったコマンドが、Windows側で実行されて返ってきたということです。cmd.exe に限らず、Windowsにインストールされた実行ファイルはWSLから呼び出せる状態でした。
これは設定ミスか、既定の動作か
Microsoftの公式ドキュメント（WSLのファイルシステム・WSLの相互運用）に、相互運用（interop）と自動マウント（automount）は既定で有効と明記されています。設定ミスではありません。「WSLとWindowsを行き来しやすくする」という設計思想どおりの動作です。
なるほど。「Linuxの中に入れたから安全」という私の思い込みが間違っていました。
隔離できていたのは依存関係だけ。ファイルシステムとプロセス実行については、何も守られていませんでした。
締めるか、利便性を取るか
対処方法は3つあります。どれが正解かは用途次第で、私は最終的に③を選びました。
選択肢は3つ
① 何もしない（現状維持）
利便性は最大です。WSLからWindows側のファイルを自由に読み書きできます。そのぶん、AIエージェントに渡している権限も最大になります。
② interopとautomountを両方無効にする（完全に締める）
/etc/wsl.conf に以下を追加し、wsl --shutdown で再起動します。
[interop]
enabled = false
[automount]
enabled = false
これでWindowsの実行ファイルは起動できなくなり、/mnt/c もマウントされなくなります。依存関係だけでなく、ファイルアクセスとプロセス実行もWSL内に閉じます。
③ automountを読み取り専用にする（中間）
/etc/wsl.conf に以下を追加し、wsl --shutdown で再起動します。
[automount]
enabled = true
options = "ro"
/mnt/c はマウントされますが、書き込みができなくなります。WindowsのファイルをWSLから読むことは引き続きできます。
なぜ③にしたか
正直に書くと、この記事を書き始めた時点では、まだ何も変えていませんでした。3つを並べて、自分がWSLに何をさせているかを見直してから決めました。
決め手になったのは、「今は使っていない権限」と「これから使うかもしれない権限」を分けて考えたことです。
まず書き込みのほう。私の作業ファイルはすべてWSL側にあります。開発中のコードもPythonの仮想環境もLinux側の /home の下にあって、Windows側に書き戻す用途は今のところ一つもありません。使い道がないまま、事故のときだけ効いてくる権限だったわけです。これは返してしまってよさそうでした。
一方の読み取りは、今すぐ必要というわけではありません。ただ、この先Windows側にあるファイルをWSLから参照したくなる場面は出てきそうです。②で完全に閉じてしまうと、そのときまた設定を戻すところからやり直しになります。
そこで③にしました。使う予定のない権限は返す。使うかもしれない権限は残す。 今の私には、これが過不足のない線でした。
設定を書き換えて wsl --shutdown で再起動すると、さきほどの mount | grep mnt の出力が変わります。rw だった部分が ro になっていれば、読み取り専用でマウントされている状態です。
なお、Anthropicの公式ドキュメント（Claude Code IAM）によると、Claude Codeはデフォルトでファイル編集やコマンド実行の前に確認を求める設計になっています。WSLの設定に頼るだけでなく、Claude Code側の権限設定も合わせて見ておくと良いでしょう。
まとめ
| 確認したこと | 結果 |
|---|---|
| apt/pipの依存関係がWindowsに影響するか | しない（隔離できている） |
| Cドライブへの書き込みができるか | できる（既定でrwマウント） |
| WindowsのEXEをWSLから実行できるか | できる（interopが既定で有効） |
WSLは「Linuxの依存関係をWindowsから切り離すツール」であり、「AIエージェントからWindowsを守るサンドボックス」ではありません。この違いを最初に整理しておけば、「隔離したつもり」にはならずに済みます。
MCPを使ってAIエージェントにさらに多くのツールを渡すことを検討している方は、MCPとは？AIとツールの共通規格を5分で解説も読んでみてください。権限の範囲がWSL以上に広がるので、設定の確認がより大切になります。
ではでは！
参考文献
関連記事
コメント