技術 約8分で読めます

AIエージェントのローカル隔離実行、macOS sandbox-execとWindowsサンドボックスで何が違うか

AIエージェント セキュリティ macOS Windows Claude Code OpenAI

AIコーディングエージェントを --dangerously-skip-permissions フラグ付きで動かすとき、「何かおかしなことが起きたら？」という問いへの答えとして、macOSとWindowsで同時期に異なるアプローチが具体化した。macOSではAgent SafehouseがOSネイティブのsandbox-execを使い、WindowsではOpenAIがCodex for Windowsを正式リリースしてWindowsサンドボックスを活用する。どちらもAIエージェントの破壊的操作を防ぐという目的は同じだが、隔離の仕組みと強度が根本的に異なる。

正直なところ、Docker使えばいいのはわかっている。でもDockerは面倒だ。コンテナ内に開発環境を再構築して、ボリュームマウントを設定して、権限周りを調整して…となると、「ちょっと試したいだけなのに」という気持ちが勝って --dangerously-skip-permissions をそのまま付けてしまう。tmuxで一晩放置して自動開発ループを回すときなんかは特にそうで、Ralph Wiggumプラグインの記事ではネットワーク制限をiptablesでかけるという力技でサンドボックス化したが、ファイルシステムの隔離まではできていなかった。

そして実際に事故は起きている。AmazonのKiroが本番環境を「削除して再作成」して13時間のダウンタイムを出した事件、ReplitのAIエージェントが顧客DBを削除した事故。いずれもエージェントに広すぎる権限を渡したことが直接の原因だった。「権限設定が面倒だからフラグを立てる」という判断の先に何が待っているか、既に答えは出ている。

macOS：Agent SafehouseとOS組み込みのsandbox-exec

macOS sandbox-execとは何か

Agent SafehouseはmacOSに組み込まれている sandbox-exec を基盤にしている。sandbox-exec はmacOSのSandbox.framework（別名Seatbelt）を使ってプロセスの行動を制約するカーネルレベルの機能で、App Storeアプリのサンドボックスと同じ仕組みだ。

動作は「許可されたもの以外は全て拒否」するルールをポリシーファイルに記述し、対象プロセスをそのポリシー下で起動するというものだ。ポリシーを破ろうとする操作はカーネルがシステムコールレベルでブロックする。ユーザースペースのフックやLD_PRELOADのようなアプローチと違い、プロセス側から回避する手段がない。

セキュリティモデル

Agent Safehouseのデフォルト設定では、エージェントは以下のみにアクセスできる。

アクセス種別許可内容
読み書き選択したワーキングディレクトリ（デフォルトはgitルート）
読み取りのみインストール済みツールチェーン（npm, pip, cargo等）
ブロックSSH鍵、ホームディレクトリ外のリポジトリ、システム設定

rm -rf ~ のようなコマンドはカーネルが実行前に拒否する。エージェントがどれだけ「正しいシェルコマンド」を生成しても、カーネルの壁を超えることはできない。

インストールと使い方

依存関係はゼロで、Bashスクリプト1本で動く。

curl -fsSL https://raw.githubusercontent.com/eugene1g/agent-safehouse/main/dist/safehouse.sh \
  -o ~/.local/bin/safehouse
chmod +x ~/.local/bin/safehouse

使い方は既存のエージェントコマンドの前に safehouse を置くだけだ。

cd ~/projects/my-app
safehouse claude --dangerously-skip-permissions
safehouse codex

シェル関数を設定すれば、エージェントコマンドを上書きして常にサンドボックス下で動かすこともできる。

safe() { safehouse --add-dirs-ro=~/mywork "$@"; }
claude() { safe claude --dangerously-skip-permissions "$@"; }

これで claude と打つだけで自動的にサンドボックス下での起動になる。

対応エージェント

テスト済みのエージェントとして以下が列挙されている。

Claude Code、Codex、OpenCode、Amp、Gemini CLI、Aider、Goose、Auggie、Pi、Cursor Agent、Cline、Kilo Code、Droid

「テスト済み」とは、サンドボックス下で実際にコーディング作業を完了できたことの確認を意味する。エージェントが内部でどんなサブプロセスを起動しても、親プロセスのポリシーが継承される。

ポリシーのカスタマイズ

profiles/ ディレクトリに複数のポリシープロファイルが格納されており、組み合わせて使える設計になっている。追加ディレクトリへの読み取りアクセスは --add-dirs-ro フラグで指定できる。

マシン固有の設定は共有リポジトリを汚さないよう、環境変数でローカルオーバーライドファイルを指定する。

SAFEHOUSE_APPEND_PROFILE="$HOME/.config/agent-safehouse/local-overrides.sb"

また、ホームディレクトリとツールチェーン構成を読み取り、Claude等のLLMが個別のサンドボックスプロファイルを自動生成する機能も提供されている。「どのディレクトリまで許可するか」という判断をLLMに委ねる、という興味深いアプローチだ。

Agent SafehouseはApache 2.0ライセンスで公開されており、GitHub上ではすでに500スターを超えている。

Windows：Codex for WindowsとWindowsサンドボックス

Windowsサンドボックスによる隔離実行

OpenAIは2026年3月9日、AIコーディングエージェント「Codex」のWindows対応版を正式リリースした。最大の特徴は、エージェントがデフォルトでWindowsサンドボックス内で動作する点だ。

Windowsサンドボックスは、Windows 10 Pro/Enterprise以降に組み込まれた軽量仮想化機能で、ホスト環境と完全に隔離されたデスクトップセッションを起動する。セッションを閉じると内部の変更は全て破棄される。AIエージェントが意図しないシステムファイルの書き換えや設定の破損を起こしても、ホスト環境には影響しないという保証をカーネルレベルで提供する。

OpenAIはこのサンドボックス実装のコードをGitHubで公開しており、開発者が内部の動作を確認・改変できる。

WSL対応とPowerShell統合

Codex for WindowsはWSLにも対応する。LinuxベースのツールチェーンやShellスクリプトをそのまま使いたい開発者向けの選択肢で、WindowsネイティブのPowerShellと並行して利用できる。

Windowsネイティブアプリケーション向けのスキルセットも用意されており、Win32 API、.NET、UWP（Universal Windows Platform）など、Windowsエコシステム固有の開発タスクに対応したエージェント動作が可能になっている。

GUIによるプロジェクト管理

従来のCodexはコマンドラインベースの操作が主流だったが、Codex for WindowsはWindowsアプリケーションとしてのGUIを持つ。複数プロジェクトを一覧管理し、エージェントのタスク状況を画面上で確認できる。エージェントへの指示は「このファイルにある認証ロジックを修正して」「このコンポーネントにユニットテストを追加して」といった自然言語で行え、エージェントがコーディング・デバッグ・レビューを自律的に実行する。

2つのアプローチの比較

項目Agent Safehouse（macOS）Codex for Windows
隔離の仕組みカーネルレベルのsandbox-exec（Seatbelt）軽量VM（Windowsサンドボックス）
セッション後の状態許可ディレクトリへの変更は残る破棄される（VMを閉じると消える）
オーバーヘッド小（ネイティブAPI）VMの起動コストあり
隔離の強度プロセスレベルVM境界（より強い分離）
対応エージェント12以上（Claude Code、Codex他）Codex（自社製品のみ）
ポリシー設定ユーザーがプロファイルをカスタマイズ可OpenAIが固定
ライセンスApache 2.0（OSS）クローズド

sandbox-execはVMを使わずmacOSのネイティブAPIを使う点が特徴で、オーバーヘッドが小さい代わりに、隔離の強度はVMより低い。Windowsサンドボックスはセッション終了時に状態が全て破棄されるため、「実験的なタスクを試して全てリセットする」用途では明確な優位性がある。

「破壊的操作を防ぐ」という目的では両者とも有効だが、強度と利便性のトレードオフが異なる。macOSのdevelopmentワークフローで常時使うならAgent Safehouseの軽量性が活きる。Windowsで新しいことを試す・壊れても構わない実験をするならWindowsサンドボックスの完全分離が向く。

ファイルシステムの隔離だけでは防げない攻撃もある

ここまでの話はエージェント自身の破壊的操作（rm -rf や本番環境の削除）を防ぐための隔離だ。しかし2026年に入って、エージェントが外部から操られるケースが急増している。

Clinejectionでは、GitHubイシュータイトルに埋め込まれたプロンプトインジェクションがClineのAIトリアージbotを経由してnpmトークンを窃取し、4000台の開発マシンに悪意あるパッケージを自動インストールさせた。SANDWORM_MODEキャンペーン（一連の攻撃活動）ではClaude CodeやCursorを装った偽npmパッケージがSSH鍵やAPIトークンを盗み出している。OpenClawのSKILL.mdを経由したAMOS配布に至っては、AIエージェントがスキルファイルの指示に従って自らマルウェアインストーラーを実行するという経路だった。

さらに、エージェントのメモリファイル自体が攻撃対象になる事例も報告されている。CLAUDE.mdやcursorrulesのような設定ファイルを通じて、エージェントの振る舞いそのものを書き換える手法だ。

こうした攻撃に対しては、Agent Safehouseのネットワーク制限やファイルアクセス制限が一定の防御になる。SSH鍵へのアクセスがブロックされていれば窃取されないし、許可ディレクトリ外への書き込みが禁止されていれば、エージェントが勝手にグローバルインストールを実行することもできない。ただし、ワーキングディレクトリ内のコードに悪意ある依存関係を追加されるケースまでは防げない。最終的にはコードレビューと依存関係の監視が必要になる。

Claude Codeの権限設定で細かくアクセス制御を組むアプローチもあるが、公式が「バイパスされうる」と言っている段階では、OS側の強制力に頼る方が現実的だ。