OpenClaw 完全ガイド：クラウド Mac AI Agent サンドボックスをゼロから本番へ

macOS 上の AI Agent にサンドボックスが必要な理由

ここ 1 年で、Cursor や Windsurf などの AI コーディングツールが「モデルにコードを書かせる」作業を日常化した。 しかし Agent が IDE プラグインから自律的な shell 実行・秘密情報の読み書き・システム API 呼び出しへ拡張されると、 リスクモデルは根本的に変わる。diff を提案するだけではなく、あなたのユーザー権限で実際にディスクへ書き込むからだ。 社内テストでは、制約なしの Agent が複数ファイルのリファクタ中に ~/.ssh/id_ed25519 と同階層への書き込みを試み、security find-identity でキーチェーンを列挙した事例がある—— 開発者のローカル Mac なら許容されても、CI 署名鍵を載せたクラウド Mac では越えてはならない一線だ。

従来の対策は Docker や仮想マシンによる隔離だが、macOS 上のコンテナは完全な Xcode ツールチェーンにアクセスできなかったり、 Apple のコード署名体系と相容れない。別の道は、Agent 専用の物理マシンを用意し、 ポリシーエンジンでファイルシステム・ネットワーク・プロセスの 3 軸をホワイトリストに閉じ込めること——これが OpenClaw の出発点だ。 PixVPS 専用 Mac mini M4 ノード上で動作し、ホストと Apple Silicon 算力を共有しながら、 操作層で独立した監査と権限境界を提供する。Agent は仕事ができ、触ってはいけないリソースには届かない。

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

OpenClaw は macOS と Agent の間に挟まるポリシーと監査のミドルウェア層と捉えるとよい。3 つのコンポーネントが連携する：

• ポリシーエンジン（Policy Engine）：YAML の宣言的ルールを読み込み、Agent の各システムコール前に allow/deny を判定。拒否時は構造化エラーコードを返し、オーケストレーション層がリトライや降格に使える。
• サンドボックスランタイム（Sandbox Runtime）：各 Agent セッションに独立した書き込み可能ワークスペースをマウント。デフォルトは /workspace と明示的ホワイトリストのみ。~/Library/Keychains や /etc など敏感領域は一律ブロック。
• 監査バス（Audit Bus）：ファイル読み書き・子プロセス起動・ネットワーク送信を JSON Lines で記録。セッション ID・ポリシーバージョン・時間窓で検索可能。デフォルト保持 90 日。

「丸ごと再インストール」や「ユーザーアカウント切り替え」と比べ、OpenClaw の強みはポリシーのバージョン管理とロールバックにある。 同一 M4 ノード上で「読み取り専用コード分析 Agent」と「/workspace 書き込み可能なビルド Agent」を並行実行でき、 それぞれ別 YAML にバインドして干渉しない。M4 の 38 TOPS Neural Engine 算力はホスト専有のまま、サンドボックス層の推論遅延はほぼ増えない—— 200 回連続のツールコール負荷試験では、ポリシー判定の平均オーバーヘッドは 1.8 ms で無視できる水準だった。

コンソール開設と環境準備

OpenClaw は PixVPS 標準の Mac mini M4 インスタンスに同梱され、追加オプションの購入は不要だ。 クラウドノードがまだない場合は、まず注文ページでリージョンと契約期間を選択—— 支払い後 1–5 分以内に SSH 認証情報がダッシュボードに表示される。以下は SSH ログイン済みを前提とする。

1. 01
   ダッシュボードで OpenClaw を有効化

   インスタンス詳細 →「セキュリティとサンドボックス」→ OpenClaw をオン。初回有効化でインスタンスレベルの instance-token が生成され、一度だけ表示される。すぐにチームのシークレットストアへ保存すること。

2. 02
   CLI をインストールしてインスタンスを紐付け

   SSH ログイン後、下記コマンドを実行。CLI は PixVPS ソフトウェアソースから配布され、システム Python / Homebrew と競合しない。

3. 03
   デーモンとヘルスチェックを確認

   openclaw status を実行し、Policy Engine・Sandbox Runtime・Audit Bus の 3 つがすべて healthy であることを確認する。

instance-token は 1Password や Bitwarden などに保存し、リポジトリへ平文で書かないこと。 トークンが漏洩した場合は、コンソールの「インスタンストークンのローテーション」で即時無効化できる。実行中のサンドボックスセッションには影響しないが、新規セッションには新トークンが必要だ。

CLI コマンドと最初のサンドボックスタスク

OpenClaw CLI の設計目標は「運用担当が SSH 上で 90% の作業を完結できる」こと。GUI は監査検索と緊急バイパス用。 最小構成の流れ：サンドボックス作成 → ポリシー紐付け → サンドボックス内で Agent スクリプト実行。

sandbox create は /var/openclaw/sandboxes/<id>/ 配下に独立ワークスペースを割り当て、 ポリシーファイルのハッシュを監査ログに書き込む。事後に「当時どのパスが許可されていたか」を追跡できる。 sandbox exec はデバッグに最適：フル Agent オーケストレーションを接続する前に、ポリシーが厳しすぎ／緩すぎないか検証する。

最初のタスクでは Agent にプライベート Git リポジトリのクローンとテスト実行を任せた。ハマりどころ：デフォルトポリシーは ~/.gitconfig へのアクセスを禁止しており、 HTTPS 認証情報の読み取りに失敗した。対策は、ポリシーで ~/.gitconfig を読み取り専用ホワイトリストに追加するか、SSH deploy key を使い ~/.ssh/deploy_key を個別に許可する。

権限 YAML：読み取り専用から書き込みビルドへ

ポリシーファイルは宣言的 YAML。apiVersion: openclaw.pixvps.com/v2。 コア構造は filesystem・process・network の 3 ブロック。 各ブロックに allow と deny リストがあり、deny が allow より優先される。

ビルド系 Agent は /workspace への書き込み、xcodebuild の呼び出し、npm registry へのアクセスが必要になる。 filesystem.allow の /workspace を [read, write] に変更し、 process.allow に xcodebuild・swift・npm を追加、 network.egress を allow-list に切り替えて registry.npmjs.org:443 や github.com:443 などを列挙する。

ポリシー変更は openclaw policy apply -f ./policies/build.yaml --sandbox dev-agent でホットリロード。 エンジンは YAML 構文とパス競合を検証し、同一パスを allow と deny の両方に書いた設定は拒否する。 ポリシーファイルは Git 管理し、PR でレビューすること——権限拡大はアプリケーションコード変更と同じ重みで扱う。

マルチユーザー零信頼アクセス

本番環境では複数エンジニアが Agent を観察・デバッグするが、SSH 秘密鍵を共有すべきではない。 OpenClaw は PixVPS 零信頼ゲートウェイと統合される。各ユーザーはコンソールの「チームメンバー」ページで個人デバイス証明書を取得し、 MFA 通過後に時限付き SSH 証明書（デフォルト 8 時間）を受け取る。長期パスワードではない。

ロールは 3 段階：viewer は監査ログの閲覧のみ；operator はサンドボックスの作成/停止、sandbox exec の実行； admin はポリシー変更とトークンローテーション。ロールはコンソールで割り当て、CLI では openclaw auth whoami で現在の身份を確認できる。

CI/CD と自動化パイプライン統合

Agent タスクが「手動トリガー」から「push のたびに自動実行」へ移行すると、OpenClaw セッションをパイプラインオーケストレーションに組み込む必要がある。 典型的な構成：同一 PixVPS M4 ノード上で GitHub Actions セルフホスト Runner を動かし、 workflow 内で openclaw sandbox create → Agent エントリスクリプト実行 → sandbox stop と監査サマリのアップロード。

Jenkins 側は共有 Pipeline ライブラリ関数にラップし、post { always { ... } } で監査エクスポートを強制する。 Agent 失敗後にゾンビサンドボックスがディスクを占有するのを防ぐ。単一サンドボックスのワークスペースピークは約 2.4 GB（DerivedData 含む）だった。 16 GB ユニファイドメモリの M4 ノードではビルドサンドボックスを 2 つ並行しても swap は発生しなかった。それ以上は TB5 マルチマシンクラスタや Runner 分割を検討する。

監査ログ検索とよくあるトラブルシューティング

監査は OpenClaw の本番価値の中核だ。ブロックと許可のたびに Audit Bus へ書き込まれ、 timestamp・sandbox_id・policy_hash・action・target・decision・actor などのフィールドを持つ。 CLI 検索例：

openclaw audit tail --sandbox dev-agent --follow でリアルタイム追跡； openclaw audit query --since 24h --decision deny で直近 24 時間の拒否操作； openclaw audit export --format jsonl -o audit.jsonl で法務や SOC2 エビデンスチェーン用にエクスポート。

ポリシーエンジン自体が異常な場合、コンソールに「セキュリティバイパス」スイッチがある——admin のみ、1 回あたり最長 15 分。 バイパス操作はすべて最高重要度で監査に記録される。P0 インシデント以外、本番では有効化しないこと。

本番投入：クラウド Mac で Agent サンドボックスを段階的に展開

最初の問いに戻る：Agent は macOS を必要とするが、ベアメタル上を無制限に走らせるべきではない—— オフィス Mac の自前運用は電気代と運用負荷がかかり、パブリッククラウドの macOS インスタンスは仮想化されがちで OpenClaw のような操作レベル監査を持たない。 PixVPS の答えは専用物理 Mac mini M4 + ネイティブ OpenClaw 統合： 支払い後 1–5 分でデリバリー、SSH / VNC 接続、5 リージョン（シンガポール、日本東京、韓国ソウル、中国香港、米国東部）を遅延で選択、 日額 $21.1 から。実験期間は使い終わったら解放し、安定後は月額 $105.7 の常駐へ移行できる。

推奨ロールアウト：単一ノードで読み取り専用ポリシーにより Agent ロジックを検証 → 段階的に /workspace 書き込みとネットワークホワイトリストを開放 → ポリシー YAML を Git に入れ CI 接続 → チームメンバーに零信頼証明書とロールベース権限を設定。 オンデバイス推論には M4 の 38 TOPS Neural Engine をサンドボックス外で使え、サンドボックスポリシーとは直交する。 5 分で始める短編は同シリーズのOpenClaw サンドボックス クイックスタートを参照。

1. 01
   ノードを選びインスタンスを開設

   注文ページでリージョンと契約期間を選択。支払い後、ダッシュボードで OpenClaw を有効化し instance-token を保存する。

2. 02
   CLI をインストールし、最初の読み取り専用ポリシーを投入

   sandbox exec で Agent エントリスクリプトが制約下で動くことを確認してから、書き込み権限を段階的に開放する。

3. 03
   CI とチーム零信頼を接続

   workflow で監査エクスポートを強制。メンバーに viewer / operator / admin を割り当て、トークンを定期ローテーションする。

AI Agent を本番に載せるハードルは、モデルの性能ではなくすべてのシステムコールが予測可能・追跡可能・ロールバック可能かだ。 OpenClaw はそれをバージョン管理可能な YAML と検索可能な監査ログに分解する。 PixVPS は仮想化で薄められない Apple Silicon 算力と分単位のプロビジョニングを提供する。 両者の組み合わせは、macOS 上で自動化 Agent を回す際に、スピードとコンプライアンスを両立する現実的な道だ。