OpenClaw サンドボックス入門：AI Agent に隔離されたクラウド Mac を

なぜ AI Agent には専用の隔離環境が必要なのか

Cursor、Claude Code、その他ローカルでツール呼び出しができる AI Agent を使ったことがあるなら、「権限のはみ出し」を一度は経験しているはずです。設定ファイルの修正を頼んだだけなのに rm -rf が走ったり、SSH 鍵が一時サーバーへ送られたり——これは AI のバグというより、境界が定義されていないという設計上の問題です。

ローカル Mac でサンドボックスを組むのは意外と難しい。macOS の App Sandbox は主に GUI アプリ向けで、Docker コンテナには完全な macOS 環境がありません。コード署名、Xcode シミュレータ、Apple Neural Engine——これらはコンテナ内では動きません。さらに、AI Agent に任せたいタスクの多くはそもそも高権限（ソフトウェアのインストール、システム設定の変更、Keychain へのアクセス）を要求するため、「十分な権限を与えつつ、何もできない檻に閉じ込める」という両立はローカルではほぼ不可能です。

OpenClaw はこの矛盾を解くために設計されています。Agent を制限だらけの箱に閉じ込めるのではなく、実機の macOS 物理マシン上で、各タスクに対して監査可能・追跡可能・いつでも停止できる「操作境界」を引きます。どのディレクトリにアクセスできるか、どのシステムコマンドを呼べるか、どのネットワーク宛先へ接続できるかを精密に制御しながら、macOS のネイティブ能力はそのまま使えます。

OpenClaw のコアアーキテクチャ：3層隔離モデル

手を動かす前に、OpenClaw のアーキテクチャを2分ほど理解しておくと、権限設定で遠回りしにくくなります。

OpenClaw は AI Agent の操作境界を管理するために、次の3層隔離モデルを採用しています。

第1層：ファイルシステム名前空間（Namespace）。各 OpenClaw セッション起動時に、指定ディレクトリ配下へ一時的な名前空間マウントポイントが作成されます。セッション内のすべてのファイル読み書きはこの名前空間へリダイレクトされます——Agent が /etc/hosts へ書き込もうとしても、実際に書き込まれるのは名前空間内のコピーであり、ホストシステムには影響しません。セッション終了後、名前空間は自動クリーンアップするか、永続化して残すかを選べます。

第2層：システムコールフィルタ（Syscall Filter）。OpenClaw は macOS の Endpoint Security フレームワークでシステムコールをインターセプトし、フィルタリングします。設定ファイルで許可・禁止する syscall タイプを細かく指定できます（例：fork / exec は許可、ptrace と setuid は禁止）。「コンパイルモード」「Web クロールモード」「読み取り専用レビューモード」などのプリセットテンプレートも用意されています。

第3層：ネットワークアクセス制御（Network ACL）。各 OpenClaw セッションに独立したネットワークポリシーをバインドできます。許可するドメインや IP レンジ、ポートのリッスン可否、外部 DNS 解決の可否などを定義します。ポリシー外の通信はエラーを返さずサイレントに破棄され、監査ログに記録されます。Agent に境界の存在を意識させないための設計で、迂回を試みにくくします。

前提条件：ZilCloud で Mac mini M4 を開通する

OpenClaw は ZilCloud に標準搭載された機能で、コンソールで有効化すれば追加インストールは不要です。まだ ZilCloud アカウントをお持ちでない場合は、登録から初回起動までの流れを先に済ませてください。全体でおよそ5分です。

1. 01
   ノードとプランを選択

   構成・申し込みページへ進み、エンドユーザーに最も近いノード（シンガポール / 東京 / 香港 / ソウル / 米国東部）を選びます。AI Agent タスクであれば大容量ストレージは不要で、基本の 256 GB SSD で十分です。日額 $20.9 から利用できます。

2. 02
   支払い完了後、自動開通を待つ

   支払い後、システムがインスタンスを自動割り当て・交付します。通常 1〜5 分以内に完了し、SSH 認証情報と VNC パスワードが記載された確認メールが届きます。

3. 03
   VNC または SSH でシステムの準備を確認

   コンソールにログインし、「VNC を開く」をクリックすれば、クライアント不要でブラウザから macOS デスクトップを確認できます。SSH の場合：ssh admin@<あなたのグローバルIP> -p <ポート番号>。

OpenClaw サンドボックスを有効化する（コンソール操作）

インスタンスが正常稼働していることを確認したら、ZilCloud コンソールで該当オーダーの「OpenClaw」入口を開きます。初回有効化時は「ゼロトラスト初期化」フローが走り、そのインスタンスに紐づくアクセス鍵ペアが生成され、OpenClaw デーモンがバックグラウンドサービスとしてインストールされます。

初期化が完了したら、macOS ターミナルで OpenClaw サービスの稼働を確認します。

# Check OpenClaw daemon status
launchctl list | grep openclaw
# Expected output:
# -  0  com.zilcloud.openclaw.daemon

終了コードが 0 ならデーモンは稼働中です。次に CLI ツールをインストールします（コンソール初期化時に自動完了していない場合）。

# Install OpenClaw CLI
curl -fsSL https://cdn.zilcloud.com/openclaw/install.sh | bash

# Verify version
claw --version
# openclaw 1.4.2 (darwin/arm64)

AI Agent の権限境界を設定する

OpenClaw は YAML 形式の設定ファイルで、各サンドボックスセッションの権限ポリシーを定義します。AI Agent 向けには公式が3つのプリセットテンプレートを用意しており、CLI から直接読み込めます。

# List available templates
claw template list

# output:
# readonly    — read-only audit mode (no writes, no network)
# dev         — developer mode (full fs write, npm/pip allowed, no external network)
# agent       — AI agent mode (scoped fs, curated syscalls, filtered network)

初めて使う場合は agent テンプレートから始め、必要に応じて微調整するのがおすすめです。

# Generate a config file from the agent template
claw template export agent > ~/openclaw-agent.yaml

生成される openclaw-agent.yaml のおおよその構造は次のとおりです（コメントは簡略化）。

version: "1"
session:
  name: "my-agent-session"
  auto_cleanup: true        # clean namespace on session exit

filesystem:
  workspace: "~/agent-workspace"   # agent's r/w root
  readonly_mounts:
    - /Applications          # read access to installed apps
    - /usr/local/bin         # allow calling homebrew tools
  deny:
    - ~/.ssh                 # block ssh key access
    - ~/Library/Keychains    # block keychain access

syscalls:
  preset: "agent"            # allows fork/exec, blocks ptrace/setuid

network:
  allow_domains:
    - "api.openai.com"
    - "api.anthropic.com"
    - "*.github.com"
  block_all_others: true     # silent-drop, not reject

この設定が行うことの要点は次のとおりです。Agent のファイル書き込みは ~/agent-workspace 内に限定されます。インストール済みアプリや Homebrew ツールは読み取り可能ですが、SSH 鍵や Keychain にはアクセスできません。ネットワークは明示したドメインのみ許可され、それ以外のすべての送信はサイレントに破棄されます。

最初の AI Agent タスクを実行する

設定ファイルの準備ができたら、claw run で隔離セッションを起動し、その中で Agent を動かします。

# Start a sandboxed session with the config
claw run --config ~/openclaw-agent.yaml --attach

# Inside the session, you are now in the sandboxed environment
# Prompt changes to indicate active sandbox:
# (claw:my-agent-session) admin@mac-ZC-xxxxx:~$

# Now run your AI agent tool, e.g. Claude Code
claude --dangerously-skip-permissions

--attach を付けるとサンドボックス shell に直接入り、その中で起動したすべてのプロセスが OpenClaw の監視下に置かれます。claude --dangerously-skip-permissions は Claude Code のパラメータで、ファイルシステムの自律操作を許可します——ただし OpenClaw サンドボックス内では、「自律操作」の実際の範囲は設定ファイルで既に限定されており、このフラグの「危険性」はサンドボックス境界内に封じ込められます。

タスク実行中は、別ターミナルで監査ストリームをリアルタイムに追跡できます。

# Tail the audit stream for the active session
claw audit tail my-agent-session --follow

# Sample output:
# [10:23:41] ALLOW  exec     /usr/local/bin/git clone https://github.com/...
# [10:23:42] ALLOW  write    ~/agent-workspace/repo/README.md
# [10:23:45] BLOCK  network  outbound → 142.250.x.x (google.com) — policy: block_all_others
# [10:23:48] ALLOW  exec     /usr/bin/python3 analyze.py

各レコードにはタイムスタンプ、判定（ALLOW / BLOCK）、操作タイプ（exec / write / network / read）、具体的な対象が含まれます。BLOCK の場合は、どのポリシールールにマッチしたかも記録されます。このログは永続保存され、セッション終了後もいつでも照会できます。

ゼロトラストアクセスと監査ログの実務的な価値

上記の google.com への BLOCK は実際に発生した事象です。Agent がコード分析中に内部ライブラリを呼び出したところ、そのライブラリの起動時に Google Analytics へ初期化 ping を送ろうとしました。通常環境ではこの挙動に気づくことはほぼありません。OpenClaw サンドボックスでは、きちんと記録されました。

これが「ゼロトラスト」の実務的な意味です。Agent を信用しないのではなく、すべての操作が想定どおりであると仮定しないこと。操作を可視化し、監査可能にすることが、Agent が実際に何をしているかを理解する唯一の確実な方法です。

監査ログのもう一つの用途はコンプライアンスです。AI Agent で顧客データやコードレビューを扱う場合、セキュリティチームから「AI が外部へデータを送っていないことの証明」を求められることがあります。OpenClaw の監査ログは検証可能な記録として、JSON 形式でエクスポートし、コンプライアンス審査に提出できます。

# Export full audit log as JSON for compliance review
claw audit export my-agent-session \
    --format json \
    --output audit-report-$(date +%Y%m%d).json

よくあるシナリオ別の設定クイックリファレンス

AI Agent の利用シーンに応じて、agent テンプレートをベースに次のような権限境界の調整がよく使われます。

OpenClaw はセッションテンプレート化にも対応しています。調整済みの設定を名前付きテンプレートとして保存し、起動時に claw run --template xcode-build のように呼び出せます。CI/CD パイプラインでは、テンプレート設定をリポジトリにコミットし、毎回同一かつ監査可能なサンドボックス環境でビルドを回す運用が可能です。

Docker コンテナや仮想マシンではなく、なぜ OpenClaw なのか

OpenClaw のデモのたびに聞かれる質問です。きちんと答えておきます。

Docker コンテナは Linux 向けの隔離機構であり、macOS 上で Docker を動かすと、実質的には Linux 仮想マシン内でコンテナが走ります——Docker Desktop の HyperKit でも OrbStack の Lima でも、底層は Linux カーネルです。つまり AI Agent は macOS ではなく Linux 環境で動きます。Xcode ツールチェーン、Apple Neural Engine、codesign、simctl（シミュレータ制御）が必要なタスクでは、Docker は根本的に使えません。これらは macOS プライベートフレームワークに依存しており、Linux コンテナには存在しません。

macOS ネイティブ仮想化（Virtualization.framework と UTM や VMware Fusion の組み合わせ）なら完全な macOS 仮想マシンを動かせますが、3つの実務上の問題があります。第一に、クラウド Mac 上でさらに macOS VM をネストすると性能損失が無視できず、M4 の Neural Engine はネスト仮想化ではゲスト OS から直接使えません。第二に、VM の管理コストは OpenClaw のセッションモデルよりはるかに高く、イメージ・スナップショット・ネットワークブリッジの運用が必要です。第三に、VM 内部にも監査ログ機構は標準搭載されておらず、OpenClaw と同等の監査カバレッジを得るには別途ログ収集基盤を構築する必要があります。

OpenClaw は別のアプローチを取ります。実機の macOS 物理マシン上で、OS ネイティブの Endpoint Security フレームワークによる操作インターセプトを使い、性能オーバーヘッドは極めて小さい（実測で CPU 約3%）。Agent からはほぼ透過的——Agent は自分がサンドボックス内にいることを知りません。Apple Silicon の Neural Engine、Xcode フルツールチェーン、コード署名サービスなど、macOS の能力はすべて本物で、操作境界だけが事前に定義されています。

GitHub Actions の macOS ホステッド Runner を使っている場合は、こう考えてみてください。GitHub が提供するのは macOS 仮想マシンであり、物理マシン専有の計算資源は得られません。Runner 環境で細かい監査を行う手段もありません。さらに macOS Runner の料金は Linux Runner の10倍です。ZilCloud の Mac mini M4 は日額 $20.9 から、物理マシン専有。OpenClaw を有効化すれば、監査可能で隔離された macOS AI Agent 実行環境が手に入ります。「なんとか使える」代替案ではなく、本番で使える環境です。

より深い運用知識（マルチユーザー権限、CI/CD 統合、障害切り分け）は、OpenClaw 完全ガイドをご参照ください。本記事は「最初の1セッションを動かす」ことに焦点を当てています。