📖 13分で読める

【セキュリティ #1】サンドボックスとは？— 隔離の理想と個人開発の現実

⚠️ 注意 この記事は個人の学習記録です。筆者はセキュリティの専門家ではありません。 本番環境や機密性の高いシステムでは、必ず専門家に相談してください。

本記事の内容を参考にした結果について、筆者は一切の責任を負いません。

背景

現在、OpenClawを使って「第2の脳」作りや個人開発をやっています。

VPSでAIエージェントを24時間動かしているのですが、セキュリティについて調べていたら「サンドボックス（Docker）でAIを動かした方が、より安全に制御できる」と聞きました。

「なるほど、やってみよう！」と思って設定したところ…

curl が動かない！ 😱

ということで、サンドボックスについて調べたことをまとめます。

この記事で学べること

  • サンドボックスって何？
  • なぜAIエージェントに必要？
  • Docker隔離のメリット・デメリット
  • 個人VPSでの判断基準

きっかけ：Brave API（ネット検索）が動かない！

OpenClawでAIアシスタントを動かしていたら、Web検索ができませんでした。

スピカ「検索するね」
→ ネットワークアクセスがブロックされている...

なぜ？

調べてみると、AIはDockerコンテナの中で動いていて、 外部APIへのアクセスが制限されていたのです。

AIエージェントのリスク

従来のチャットボットと違い、AIエージェント（スピカ）は実際にコマンドを自律的に実行します。

コマンドの例

# ファイル操作
cat config.yaml        # 設定ファイルを読む
mkdir -p /path/to/dir  # フォルダを作成
rm -rf ./temp/         # フォルダを削除

# Git操作
git add .              # 変更をステージング
git commit -m "..."    # コミット
git push               # リモートにプッシュ

# ネットワーク
curl https://api.example.com  # APIを叩く
graph LR
  A[ユーザー] -->|指示| B[AIエージェント]
  B -->|コマンド実行| C[サーバー]
  C -->|結果| B
  B -->|返答| A

これは便利な反面、リスクもあります。

もしAIが間違ったコマンドを実行したら？

graph TD
  A[ユーザー: ログを削除して] --> B[AI: rm -rf /var/log/]
  B --> C{パスは正しい?}
  C -->|Yes| D[✅ ログ削除成功]
  C -->|No| E[❌ 違うディレクトリを削除...]
  E --> F[💀 重要データ消失]

AIは万能ではありません。

解決策：Dockerサンドボックス

OpenClawはDocker隔離という解決策を採用しています。

設定方法

方法1: 設定ファイルを編集

# 設定ファイルを開く
nano ~/.openclaw/openclaw.json
{
  "sandbox": {
    "mode": "all"   // ← ここを変更
  }
}
mode説明
"all"全コマンドをDocker内で実行（安全）
"off"VPS直接実行（便利だが要ルール）

方法2: CLIで設定

# 現在の設定を確認
openclaw config get sandbox.mode

# Docker隔離を有効化
openclaw config set sandbox.mode all

# Docker隔離を無効化（個人VPS向け）
openclaw config set sandbox.mode off

方法3: 対話形式

openclaw config
# → sandbox セクションを選択
# → mode を選択

設定後

# Gatewayを再起動して反映
openclaw gateway restart

仕組み

graph TB
  subgraph VPS["VPS本体（ホスト）"]
      subgraph Docker["Dockerコンテナ"]
          AI[AIエージェント]
          CMD[コマンド実行]
      end
      Host[システムファイル]
  end
  
  AI --> CMD
  CMD -.->|アクセス制限| Host

ポイント:

  • AIはDockerコンテナ内で動作
  • コンテナからVPS本体のファイルにはアクセスできない
  • 何か問題が起きてもコンテナ内で完結

サンドボックスの比較

隔離あり（mode: all）

ユーザー指示 → AI → Dockerコンテナ → コマンド実行
                         ↓
                   VPSに影響しない ✅

隔離なし（mode: off）

ユーザー指示 → AI → VPS直接 → コマンド実行
                         ↓
                   VPSに影響する ⚠️

機能比較表

機能mode: all（隔離）mode: off（直接）
ファイル読み書きコンテナ内のみVPS全体
コマンド実行コンテナ内のみVPS全体
curl / API連携❌ 制限あり✅ 自由
git push❌ SSH鍵なし✅ 可能
環境変数❌ 引き継がない✅ 使える
VPSファイル保護✅ 安全⚠️ 要ルール
暴走時の影響✅ 限定的⚠️ 広範囲
共有サーバー✅ 推奨❌ 非推奨
個人VPS△ 制限多い✅ 便利

💬 私の選択 結局、個人開発のスピード重視と、VPSを自分で管理しているという点から mode: off を選びました。 ただし、AGENTS.md でルールをしっかり設定しています。

⚠️ mode: off のデメリット

便利だけど、リスクもあります：

  • VPS全体にアクセス可能 — 重要ファイルを誤って削除する可能性
  • 暴走時の影響が大きい — ミスがVPS全体に波及
  • rm -rf の危険性 — 復元不可能な削除ができてしまう
  • 秘密情報へのアクセス — .env や秘密鍵が見える
  • ネットワーク制限なし — 未知のURLにもアクセス可能
  • ルール設定が必須 — AGENTS.md を書かないと危険

対策

✅ AGENTS.md でルールを明文化
✅ trash > rm で削除を復元可能に
✅ 許可リストで外部アクセスを制限
✅ 確認必須の操作を定義

📖 ルール設定の詳細は下記セクションで解説！

mode: off のルール設定

サンドボックスを外したので、AGENTS.md でルールを設定して安全を確保しました。

設定例（AGENTS.md）

# AGENTS.md - AIエージェントのルール

## ファイル操作
- trash > rm（復元可能にする）
- ワークスペース外は触らない
- .env, 秘密鍵は絶対に外部送信しない

## 許可されたAPI
- discord.com/api/
- *.googleapis.com
- api.open-meteo.com（天気）
- hacker-news.firebaseio.com
- api.github.com

## 禁止
- localhost / 127.0.0.1
- プライベートIP（192.168.x.x, 10.x.x.x）
- 未知のドメインへのアクセス
- 短縮URL（bit.ly等）への -L リダイレクト

## レート制限
- 複数URLを連続で叩く時は sleep 1 を入れる
- 10件以上のループは必ず間隔を空ける

## 確認が必要なこと
- メール送信
- SNS投稿
- 課金が発生する操作
- 不明なURLへのアクセス

ポイント

ルール理由
trash > rm間違って削除しても復元可能
許可リスト知らないURLにアクセスしない
レート制限API制限やIP BANを防ぐ
確認必須外部への影響は人間が判断

設定場所

OpenClawのワークスペース構造：

workspace/
├── AGENTS.md      ← AIへのルール・指示書
├── MEMORY.md      ← 長期記憶（重要な情報）
├── SOUL.md        ← AIの性格・トーン
├── USER.md        ← ユーザー情報
├── TOOLS.md       ← ツールの使い方メモ
├── HEARTBEAT.md   ← 定期チェック項目
├── TASKS.md       ← タスク管理
├── memory/        ← デイリーログ
│   └── 2026-02-05.md
└── skills/        ← カスタムスキル
    └── blog-manager/
        └── SKILL.md
ファイル役割
AGENTS.mdルール・禁止事項・許可リスト
MEMORY.md長期記憶（誕生日、プロジェクト等）
SOUL.mdAIの性格・話し方
USER.mdユーザーのプロフィール

OpenClawは起動時にこれらのファイルを読み込んで、ルールに従って動作します。

📖 詳細は #4 AGENTS.md で解説！

メリット・デメリット

💬 余談 最初、2GBのVPSでDocker使おうとしたら「メモリ足りないかも」と言われました。 でもやってみたら…動いた！ 案外いけるもんですね。

✅ Docker隔離のメリット

項目説明
環境隔離コンテナ内の問題がVPSに波及しない
リソース制限CPU・メモリの使いすぎを防げる
ファイル保護VPSの重要ファイルに触れない
再現性環境を壊しても作り直せる

❌ Docker隔離のデメリット

項目説明
ツール不足コンテナにないツールは使えない
設定ファイルVPS側の設定が見えない
環境変数VPS側の変数が引き継がれない

💭 今後の課題 VPS × Docker でうまく運用している事例があれば、ぜひ参考にしていきたいです。 良い方法をご存知の方、ぜひ教えてください！

判断フローチャート

graph TD
  A[自分専用のVPS?] -->|No| B[mode: all を維持]
  A -->|Yes| C[外部API連携が必要?]
  C -->|No| D[mode: all でOK]
  C -->|Yes| E[mode: off + ルール設定]

まとめ

環境私の選択
共有サーバー / 本番環境mode: all（隔離あり）
個人VPS / 開発環境mode: off + ルール設定 ← これにしました

私は個人VPSなので、隔離を外してルールで守る方法を選びました。

次回は「SSH鍵認証入門」を解説します。

💡 この記事は個人VPS向けです。 業務環境では追加の対策が必要な場合があります。

シリーズ目次

  1. サンドボックスとは？ ← 今ここ
  2. SSH鍵認証入門
  3. Deploy Key を使う
  4. AIエージェントのリスク管理
  5. tmux でプロセス永続化
  6. CI/CD セキュリティチェック