Windows内の特定ディレクトリのみをAIエージェントに参照させ、それ以外から隔離した開発環境をゼロから構築する。
特定のツールに依存しない汎用的な隔離アーキテクチャをベースとしつつ、具体的な実装例として
- 適用例1: WSLネイティブGUI型 (Antigravity IDE)
- 適用例2: ホスト接続型 (VS Code + Codex)
の2通りの接続パターンを解説する。
全体構成
Windowsホストの個人領域（Cドライブ全体）をWSL2から不可視にし、特定ディレクトリのみをホワイトリスト形式でマウントする。その上でDockerコンテナを立ち上げ、AIエージェントの作業領域および参照領域（読取専用）を完全隔離する。
適用例1
[ Windows 11 (ホスト) ]
├── C:\Users\... (完全遮断・アクセス不可)
└── C:\Users\<Windowsユーザー>\AI-shared (マウントする共有フォルダ)
[ WSL2 (Ubuntu) ] ── (automount=false / Dockerホスト)
└── Antigravity IDE (GUI)
└── [ Docker コンテナ ]
├── AIエージェントの作業領域 (/workspace)
└── 参照フォルダ (/shared:ro)
適用例2
[ Windows 11 (ホスト) ]
├── C:\Users\... (完全遮断・アクセス不可)
├── C:\Users\<Windowsユーザー>\AI-shared (マウントする共有フォルダ)
└── VS Code (本体 + Dev Containers拡張機能 + Codex拡張機能)
↓
[ WSL2 (Ubuntu) ] ── (automount=false / Dockerホスト)
└── [ Docker コンテナ ]
├── AIエージェントの作業領域 (/workspace)
└── 参照フォルダ (/shared:ro)
共通基盤編：ホスト完全隔離環境の構築
まずは特定の開発ツールに依存しない、安全なWSL2・Dockerサンドボックス基底環境を構築する。
Step 1. [Windows] WSL2 (Ubuntu) のセットアップ
1. WSL2のインストール
PowerShellを管理者として起動し、WSLおよびUbuntuをインストールする。
wsl --install
※環境によっては、一度の実行でUbuntuまでインストールされず、再起動後に再度 wsl --install を実行する必要がある場合がある。
2. Windows側でのWSLネットワーク設定
Windowsホスト側の C:\Users\<ユーザー名>\.wslconfig を新規作成（または編集）し、以下を記述して保存する。
[wsl2]
networkingMode=NAT
dnsTunneling=true
autoProxy=true
Step 2. [WSL(Ubuntu)] WSL自動マウント制限と共有フォルダ設定
WindowsのCドライブ全体がWSL2へ自動マウントされる動作を無効化する。((本環境では、WSL2からWindowsホストへの実行パス自体は有効であるものの(Interop)、Cドライブ全体のマウントを無効化している。これにより、WSL2側から実質的にマウントした対象以外のホストコマンドやファイルは実行・参照できない「ホワイトリスト状態」が作られる。すなわち、ホスト側の個人フォルダやpowershell.exeなどのパスはWSL2から不可視である。※ただし、万が一コンテナからWSL2（Ubuntu）へエスケープされ、さらにUbuntu側で管理者権限（sudo）を奪取された場合、攻撃者が手動でCドライブを強制マウントする可能性がある。そのため、WSL2側では sudo 実行時に必ずパスワードを要求する設定（デフォルト状態）を維持するべきである。))
1. パッケージの更新
sudo apt update
sudo apt upgrade -y
2. 自動マウントの制限設定
設定ファイル /etc/wsl.conf を編集する。
sudo nano /etc/wsl.conf
以下を追記する。
[automount]
enabled = false # Cドライブ全体の自動マウントを無効化
mountFsTab = true
options = "metadata,uid=1000,gid=1000,umask=022,fmode=11,dmode=755"
[interop]
appendWindowsPath = false # Windows側の環境変数を展開しない
[network]
generateResolvConf = false
3. DNSサーバーの固定
DNS名前解決を固定するためのDNSサーバー情報を書き込む。
# パブリックDNSを上書き
sudo rm -f /etc/resolv.conf
sudo bash -c 'cat << EOF > /etc/resolv.conf
nameserver 8.8.8.8
nameserver 1.1.1.1
EOF'
4. 共有フォルダのマウント
ホワイトリスト方式で、AIに共有するフォルダとアプリをマウントする。
ここでは例としてAIに参照を許可する AI-shared ディレクトリのみをマウントする。
マウント先ディレクトリを作成し、/etc/fstab に定義を追加する。
# Windowsユーザー名を確認し、マウント先を作成
sudo mkdir -p /mnt/c/Users/<Windowsユーザー名>/AI-shared
sudo nano /etc/fstab
/etc/fstab の末尾に追記：
C:/Users/<Windowsユーザー名>/AI-shared /mnt/c/Users/<Windowsユーザー名>/AI-shared drvfs metadata,noatime,gid=1000,uid=1000,defaults 0 0
※マウントオプションで使用するユーザーID uid とグループID gid は、以下で確認できる。初期登録ユーザーは通常どちらも 1000 。
$ id <WSLのユーザー名>
5. 反映と隔離の確認
WindowsのPowerShellでWSLを再起動する。
wsl --shutdown
再度WSLターミナルを開き、指定フォルダのみが見えているか確認する。
ls -ld /mnt/c/Users/<Windowsユーザー名>/*
# 出力に AI-shared のみが表示され、他の個人フォルダが見えなければ遮断成功
Step 3. [WSL(Ubuntu)] Docker Engineの導入
WSL2内部に直接 Docker Engine を導入する。
# Docker 本体の導入
sudo apt install -y docker.io docker-compose-v2
sudo usermod -aG docker $USER
sudo apt update
sudo apt install -y docker-buildx
# デーモン設定
sudo mkdir -p /etc/docker
sudo bash -c 'cat << "EOF" > /etc/docker/daemon.json
{
"dns": ["8.8.8.8", "1.1.1.1"],
"max-concurrent-downloads": 1,
"iptables": true
}
EOF'
sudo service docker restart
※ターミナルを開き直し、docker run hello-world が sudo なしで動作することを確認する。
適用例 1：Antigravity IDE（WSLネイティブGUI型）
WSL2内にGUI IDE本体を配置し、LinuxネイティブのGUIアプリとして動かす構成。
追加設定：OAuth用Chromeのマウントとブラウザ連携
WSL2上のIDEからホスト側のGoogle Chromeを呼び出せるよう、Chromeのパスのみをホワイトリストマウントする。
# マウントポイント作成と fstab への追記
sudo mkdir -p /mnt/win-chrome
sudo nano /etc/fstab
/etc/fstab に追記：
C:/Program\040Files/Google/Chrome/Application /mnt/win-chrome drvfs defaults,uid=1000,gid=1000,umask=022 0 0
設定を再読み込み後、ブラウザ呼び出し用ラッパーを作成する。
# 呼び出しスクリプトを作成
mkdir -p ~/.local/bin
cat << 'EOF' > ~/.local/bin/win-chrome-wrapper
#!/bin/bash
if [ -n "$1" ]; then
/mnt/win-chrome/chrome.exe "$1" &
fi
EOF
chmod +x ~/.local/bin/win-chrome-wrapper
# ラッパースクリプト作成
mkdir -p ~/.local/bin ~/.local/share/applications
cat << 'EOF' > ~/.local/bin/win-chrome
#!/bin/bash
if [ -n "$1" ]; then
/mnt/win-chrome/chrome.exe "$1" &
fi
EOF
chmod +x ~/.local/bin/win-chrome
# デスクトップエントリ作成
cat << 'EOF' > ~/.local/share/applications/win-chrome.desktop
[Desktop Entry]
Version=1.0
Name=Windows Chrome
Exec=/home/<Ubuntuユーザ>/.local/bin/win-chrome %u
Terminal=false
Type=Application
MimeType=text/html;text/xml;application/xhtml_xml;x-scheme-handler/http;x-scheme-handler/https;
EOF
# XDG既定ハンドラに設定
xdg-mime default win-chrome.desktop x-scheme-handler/http
xdg-mime default win-chrome.desktop x-scheme-handler/https
xdg-settings set default-web-browser win-chrome.desktop
IDEのインストールと起動
sudo apt install -y libgtk-3-0 libnss3 libasound2t64 xdg-utils
cd /tmp
# 公式サイトから Linux版 (x64) アーカイブ (tar.gz)をダウンロード。URLは最新のものに書き換える
curl -fSL -o antigravity-ide.tar.gz "<公式サイトのLinux版(x64)ダウンロードURL>"
sudo mkdir -p /opt/antigravity-ide
sudo tar -xzf antigravity-ide.tar.gz -C /opt/antigravity-ide --strip-components=1
sudo ln -sf /opt/antigravity-ide/antigravity-ide /usr/local/bin/antigravity-ide
# 起動
antigravity-ide
起動後、指示に従いブラウザ経由でライセンスなどの認証を行う。
サンドボックスコンテナの作成とアタッチ
mkdir -p ~/workspace/antigravity-app
cd ~/workspace/antigravity-app
docker-compose.yml を作成：
services:
agent-sandbox:
container_name: agent-sandbox
image: mcr.microsoft.com/devcontainers/base:ubuntu
working_dir: /workspace
environment:
- HOME=/workspace
volumes:
- .:/workspace
- /mnt/c/Users/<Windowsユーザー名>/AI-shared:/shared:ro
command: sleep infinity
サンドボックスコンテナを起動する。
docker compose up -d
起動した Antigravity IDE 上で Ctrl + Shift + P を押し、
Dev Containers: Attach to Running Container... を選択し、agent-sandbox にアタッチする。
適用例 2：VS Code + Codex（ホスト接続型）
Windowsホスト側で起動しているVS Codeから、WSL2上の隔離サンドボックスコンテナへ直接接続し、Codex等のCLIエージェントを動かす構成。
追加設定：VS Code実行パスのホワイトリストマウント
Windowsホスト側のDev Containers拡張機能がWSL2内部と通信する際、VS Code自身のインストールパスを参照する。
automount = false の環境下では参照が遮断されるため、VS CodeのプログラムディレクトリのみをWSL2側へホワイトリストマウントする。
sudo mkdir -p /mnt/c/Users/<Windowsユーザー名>/AppData/Local/Programs/Microsoft\ VS\ Code
sudo nano /etc/fstab
/etc/fstab に追記：
C:/Users/<Windowsユーザー名>/AppData/Local/Programs/Microsoft\040VS\040Code /mnt/c/Users/<Windowsユーザー名>/AppData/Local/Programs/Microsoft\040VS\040Code drvfs defaults,uid=1000,gid=1000,ro 0 0
WindowsのPowerShellで wsl --shutdown を実行して反映させる。
VS Code（Windows側）の設定
- Windows側VS Codeの拡張機能で'Dev Containers'および'WSL'をインストールする。
Ctrl + Shift + P → Preferences: Open User Settings (JSON) を開き、以下を追加する。
"dev.containers.executeInWSL": true,
"dev.containers.dockerSocketPath": "/var/run/docker.sock"
サンドボックスコンテナの作成とCodexの導入
WSL2側でプロジェクトを作成する。
mkdir -p ~/workspace/codex-app
cd ~/workspace/codex-app
docker-compose.yml を作成：
services:
codex-sandbox:
container_name: codex-sandbox
image: mcr.microsoft.com/devcontainers/javascript-node:20
working_dir: /workspace
environment:
- HOME=/workspace
volumes:
- .:/workspace
- /mnt/c/Users/<Windowsユーザー名>/AI-shared:/shared:ro
command: sleep infinity
コンテナを起動し、Codex CLIを導入する。
docker compose up -d
docker compose exec -it codex-sandbox npm install -g @openai/codex
VS Codeからのアタッチ
- Windows側でVS Codeを起動する。
Ctrl + Shift + P → Dev Containers: Attach to Running Container... を選択する。
- 一覧から
codex-sandbox を選択する。
隔離状態の検証（共通確認手順）
どちらの構成でも、アタッチしたコンテナ内の統合ターミナルで以下を実行し、ファイルシステムが適切に制限されていることを検証する。
# 1. カレントディレクトリの確認
pwd
# -> /workspace
# 2. 共有フォルダの参照確認（正常に読めること）
ls /shared
# 3. 共有フォルダへの書き込み遮断確認
touch /shared/test.txt
# -> Read-only file system エラーとなり書き込みが拒否されること
# 4. ホスト領域の完全遮断確認
ls /mnt/c
ls /home
# -> ホストのCドライブ全体やWSLホスト領域へアクセス不能であることを確認
編集履歴
2026-10-06: VS Code + Codexの構成を追加し、全体をリライト
2026-08-23: 公開(Antigravity構成)
