【macOSで始めるOpenClaw】サンドボックス分離とツール権限を段階的に解説

はじめに

こんにちは、NTT西日本の梅木です。

オープンソースのAIエージェント基盤であるOpenClawを、macOSで動かす手順を2部構成で解説します。

OpenClawはSlack・LINE・DiscordなどのメッセージングアプリからAIエージェントに話しかけ、ファイル操作・コマンド実行・ブラウザ操作まで自律的にやらせることができるツールです。

強力な分、権限が広く、初手で全てのセキュリティ設定を盛り込むと「なぜその設定を入れるのか」が分からないまま手を動かすことになり、結果として運用も理解も破綻しがちです。

そこで本記事は、次の2部構成にしました。

第1部：まず動かす ― 最小構成でSlackからMacを操作できる状態をつくります。サンドボックスは使いますが、それ以外は既定値のまま進めます
第2部：段階的に固める ― 実運用に載せる前に、「なぜ必要か」「やらないとどうなるか」をセットで、ステップアップ形式でセキュリティを追加していきます

対象読者

本記事は、以下の方を対象としています。

macOSにOpenClawを導入したい方
OpenClawのサンドボックスに興味がある方
macOSの簡単なコマンドライン操作ができる方

本記事の構成

本記事は2026年4月時点のOpenClawに基づきます。進化が速いため、実構築時はOpenClaw公式ドキュメントの最新版も併せてご確認ください。

1. 背景（なぜこの記事を書こうと思ったか）

OpenClawには、初期セットアップを対話形式で進められるopenclaw onboardコマンドがあります。モデル設定からSlack連携まで一気に片付くのでたしかに便利です。ただ、完了後に生成されたopenclaw.jsonを眺めても、どの項目が何のための設定なのかが掴めずにいました。

セキュリティ面の議論が絶えないツールだけに、自分の環境を説明できない状態はどうにも落ち着かず、きちんと理解しておきたいと思うようになりました。

そこでonboardを使わず、設定の意味をひとつずつ確認しながら一から手で構築し直すことにしました。最初は半日もあれば終わると思っていましたが、公式ドキュメントに書かれていないことも多く、結局丸1日かかりました。本記事はそのときのメモを整理したものです。

セキュリティ設定の意図も含めて理解したい方の参考になれば幸いです。

2. OpenClawとは何か、何が嬉しいのか

OpenClawは、MITライセンスで公開されているオープンソースのAIエージェント基盤です。

Slack・LINE・Discordといったメッセージングアプリをフロントエンドとし、バックエンドではClaude・OpenAI・Ollamaなど複数のLLMプロバイダと連携しながら、ファイル操作・コマンド実行・ブラウザ操作などを自律的にこなします。

一言でいうと「メッセージングアプリで指示するだけで、手元のMacで作業してくれるAIアシスタント」です。あなたの代わりにさまざまなタスクをこなします。

まず知っておくべき3つの要素

初めての方向けに、本記事で頻出する3つの要素をこちらに書いておきます。

名前	役割
Gateway	メッセージ受信の窓口、エージェントへのルーティング、LLMとの通信を担う司令塔
Agent（エージェント）	Gatewayが管理する「AIアシスタント」。エージェントごとに名前・性格・権限・ワークスペース（作業ディレクトリ）が定義できる
Channel（チャネル）	メッセージをやり取りする場所。Slack Bot Token等で接続する

この3者の関係

以下の図は、第1部で構築する最小構成を表しています。

Slackから来たメッセージをGatewayが受け取り、どのエージェントで処理するかを判断し、LLMに推論を依頼しつつツール（ファイル操作やコマンド実行）を呼び出す、という流れです。

3. 第1部で構築する最小構成の全体像

第1部では、2つのエージェントを立てる最小構成で進めます。両者を並べることで、「サンドボックスあり/なし」の違いを体感できるようにするのが狙いです。

項目	`main`エージェント	`family`エージェント
用途	自分専用の個人アシスタント	権限を限定したユーザー向けの読み取り専用Bot
実行場所	Macホスト上で直接実行	Dockerサンドボックス内で隔離実行
ツール権限	既定（フル権限）	読み取りのみ（`read`）
サンドボックス設定	`off`	`all`（scope: `agent`、workspaceAccess: `ro`）

補足：本記事では便宜上 family と表記しますが、これは公式ドキュメントのサンプル設定に倣った例示の名前です。ここで扱うのはユーザー属性ではなく、アクセス権限（フル権限／読み取り専用）と隔離の有無という設計上の違いです。

サンドボックスとは何か

「サンドボックス」はツール実行を隔離されたDockerコンテナの中でやらせる仕組みです。今回の構成で押さえておきたいポイントが2つあります。

Gatewayはホスト上で実行し、エージェントのみサンドボックス（コンテナ）で動きます。Gatewayもコンテナ化できますが、本記事では扱いません
Dockerコンテナは、エージェントが初めてツールを呼ぶ時にOpenClawが自動で立ち上げます。手動でdocker runする必要はありません

4. セットアップ手順（Step 1〜Step 11）

ここから実機の手順に入ります。以降、ユーザー名はdaisukeを例として使いますが、ご自身の環境ではecho $HOMEで表示されるホームディレクトリに読み替えてください。

Step 1：Docker Desktopの確認

Dockerサンドボックスを使うため、Docker Desktopを準備しておいてください。

docker run --rm hello-world

Hello from Docker!が表示されれば準備OKです。

ファイル共有の設定（必須）

Docker Desktop → 歯車アイコン → [Resources] → [File Sharing] → /Usersが含まれているか確認してください。含まれていなければ+で追加 → [Apply & Restart]してください。

この設定がないと、ワークスペースのバインドマウントが失敗します。

Step 2：Node.jsとOpenClaw CLIのインストール

macOSにOpenClawをインストールするにはHomebrewとNode.jsが必要です。入っていない方はインストールしてください。

# Homebrew未インストールの場合
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Node.js（18以上が必要）
brew install node
node -v && npm -v

OpenClawをインストールします。その後、openclaw --versionで動作確認してください。

# OpenClaw CLI
npm install -g openclaw
openclaw --version

openclaw: command not foundになる場合は、npmのグローバルbinがPATHに入っていない可能性があります。

export PATH="$(npm config get prefix)/bin:$PATH"
# 恒久化
echo 'export PATH="$(npm config get prefix)/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc

Step 3：設定ディレクトリの作成

OpenClawの設定ファイルを置くディレクトリを作ります。

mkdir -p ~/.openclaw

Step 4：設定ファイルの作成

次のコマンドで~/.openclaw/openclaw.jsonを作成します。openclaw.jsonは、OpenClawの設定を司る主要ファイルです。

cat > ~/.openclaw/openclaw.json << 'EOF'
{
  "gateway": {
    "mode": "local"
  },
  "agents": {
    "list": [
      {
        "id": "main",
        "default": true,
        "name": "Personal Assistant",
        "workspace": "/Users/daisuke/.openclaw/workspace",
        "sandbox": {
          "mode": "off"
        }
      },
      {
        "id": "family",
        "name": "Family Bot",
        "workspace": "/Users/daisuke/.openclaw/workspace-family",
        "sandbox": {
          "mode": "all",
          "scope": "agent",
          "workspaceAccess": "ro"
        },
        "tools": {
          "allow": ["read"]
        }
      }
    ]
  }
}
EOF

書き換えポイント：/Users/daisuke/の2箇所を、ご自身のホームディレクトリに置き換えてください。

この設定が何をしているか

gateway.mode: "local"：Gatewayを自分のMac上で動かすローカルモードとしています。
agents.list：ここで2つのエージェントを定義しています。
- mainはsandbox.mode: "off"なのでホストで直接実行します。ツール実行の許可/拒否条件を書いていないため、OpenClawの既定ツール一式がフルで使える状態です。
- familyはsandbox.mode: "all" + scope: "agent"で、ツール実行がDockerコンテナに隔離されます。加えてtools.allow: ["read"]と書くことで、明示したread以外のツールは全てブロックされます。
- さらにworkspaceAccess: "ro"を指定すると、コンテナ内には2つの読み取り専用マウントが作られます。エージェントのコマンドが走る作業ディレクトリ（cwd）である/workspaceにはsandboxスコープで切られた別ディレクトリがROでマウントされ、ホスト側の~/.openclaw/workspace-familyは/agentにROでマウントされます。つまり「cwdは/workspace、ホストの共有領域は/agentから参照する」という二層構造です。家族が触れるのは「参照専用の領域」だけ、という役割分担をマウント層のレベルで固定しています。
- workspaceキーには~/.openclaw/workspace-familyを明示していますが、このキーを省略しても、同じパスが自動で使われます。設定ファイルだけを見たときに「どこが作業領域か」が読み取れるよう、本記事では明示しています。

ツール許可の考え方（`allow`と`alsoAllow`）

familyのtools.allow: ["read"]が登場したので、ここでOpenClawのツール許可の指定方法を整理しておきます。２つ目のalsoAllowは第2部で使います。

キー	意味	使いどころ
`tools.allow`	restrictive：列挙したものだけ有効、他は全部ブロック	「このエージェントにできることを最小限に絞る」ときの基本形
`tools.sandbox.tools.alsoAllow`	additive：sandbox既定のツール一式に、これを追加する	sandbox既定にないツール（例：`web_fetch`）を足したいとき

この記事ではすべてのエージェントでallowを使います。許可されていないツールは拒否となるため、わざわざdenyは書いていません。 familyの場合は["read"]しか書いていないので、writeもexecもbrowserも全部使えません。読み取り専用エージェントというわけです。

Step 5：Gatewayの起動

openclaw gateway start

ステータスを確認します。

openclaw gateway status

次の3点が出ていれば起動成功です。

Runtime: running
RPC probe: ok
Listening: 127.0.0.1:18789

Step 6：エージェントの確認

openclaw agents list

mainとfamilyの2エージェントが表示されればOKです。

Step 7：モデルの設定

OpenClawには複数のLLMプロバイダが登録できます。任意のもので結構ですが、ここではOpenAIのCodexサブスクリプションを登録することにします。

# Codex subscriptionでログインする
openclaw models auth login --provider openai-codex

# 利用可能なモデルと認証状態を確認
openclaw models list

# Auth: yesのモデルを既定に設定（バージョンは執筆した2026年4月時点のものです）
openclaw models set openai-codex/gpt-5.4

Auth: yesと表示されているモデルのうち、使いたいものをopenclaw models setで指定します。

Step 8：デバイスペアリング（TUI接続）

OpenClawではTUI（ターミナルUI）が使えます。 TUIからGatewayに接続するには、デバイスペアリングという一回限りの承認が必要です。ターミナルを2つ使うとやりやすいです。

ターミナル1でTUIを起動します。

openclaw tui

Pairing requiredと表示されたら、ターミナル2で次を実行します。

openclaw devices list                    # リクエストIDを確認
openclaw devices approve <REQUEST_ID>    # 承認（時間に制限があるようなのでお早めに）

承認が成功したら、Approvedと出るはずです。

Approved 9c6c23c1... (a52ec4b1-...)

これでTUIが使えるようになります。

Step 9：Slackチャネルの接続

ここからSlack側の準備と、OpenClawへの登録です。

本手順を実施するには、あらかじめ対象のSlackワークスペースに参加済みのSlackアカウントを用意しておく必要があります。

9-1. Slack Appの作成

Slack API Apps → [Create New App] → [From manifest]
使用するワークスペースを選択し、以下のマニフェストを貼り付け

ポイント：以下はOpenClaw公式ドキュメントから引用したmanifest例です。最小権限ではなく、Slack連携機能を広く利用できるサンプルです。気になる方は、files:*、pins:write、assistant:write あたりの要否を見直すことを推奨します。

{
  "display_information": {
    "name": "OpenClaw",
    "description": "Slack connector for OpenClaw"
  },
  "features": {
    "bot_user": {
      "display_name": "OpenClaw",
      "always_online": true
    },
    "app_home": {
      "messages_tab_enabled": true,
      "messages_tab_read_only_enabled": false
    },
    "slash_commands": [
      {
        "command": "/openclaw",
        "description": "Send a message to OpenClaw",
        "should_escape": false
      }
    ]
  },
  "oauth_config": {
    "scopes": {
      "bot": [
        "app_mentions:read",
        "assistant:write",
        "channels:history",
        "channels:read",
        "chat:write",
        "commands",
        "emoji:read",
        "files:read",
        "files:write",
        "groups:history",
        "groups:read",
        "im:history",
        "im:read",
        "im:write",
        "mpim:history",
        "mpim:read",
        "mpim:write",
        "pins:read",
        "pins:write",
        "reactions:read",
        "reactions:write",
        "users:read"
      ]
    }
  },
  "settings": {
    "socket_mode_enabled": true,
    "event_subscriptions": {
      "bot_events": [
        "app_mention",
        "channel_rename",
        "member_joined_channel",
        "member_left_channel",
        "message.channels",
        "message.groups",
        "message.im",
        "message.mpim",
        "pin_added",
        "pin_removed",
        "reaction_added",
        "reaction_removed"
      ]
    }
  }
}

Bot Tokenを取得：OAuth & Permissions → Install to Workspace → xoxb-...をコピー
App Tokenを取得：Basic Information → App-Level Tokens → Generate Token and Scopes → Scope: connections:writeを追加 → xapp-...をコピー

9-2. OpenClawにSlackを追加

openclaw channels add --channel slack --bot-token xoxb-XXXXX --app-token xapp-XXXXX

9-3. Gateway再起動と接続確認

openclaw gateway restart
openclaw channels status --probe

worksが表示されれば接続OKです。

9-4. Slackでペアリング

SlackでOpenClawボットにDMを送信（「hello」などでOK）
ボットからペアリングコードが返ってきます
ターミナルで承認

openclaw pairing approve slack <コード>

Approved slack sender U...が表示されれば完了。これで、承認した自分自身のSlackユーザーからボットに話しかけられる状態になります。

Step 10：Dockerサンドボックスの動作確認

最後に、familyエージェントがちゃんとDockerコンテナの中で動いているかと、workspaceAccess: "ro"が意図どおりに効いているかを確認します。

ここまでのステップでは~/.openclaw/workspace-familyを手動で作っていません。これは意図的で、**familyに対する最初のメッセージ送信をトリガーに、OpenClawが自動生成してくれます。まずはそれを確かめます。

# 初回呼び出し：このタイミングでworkspace-familyが自動生成される想定
openclaw agent --agent family --message "こんにちは"

ホスト側で確認してみます。

ls -la ~/.openclaw/ | grep workspace-family

workspace-familyが出てくれば、エージェント実行をトリガーにホスト側のディレクトリが自動生成されたことが確認できます。分かりやすいように設定ファイルにはworkspaceキーを書いていますが、そのキーがなくてもこのパスが使われます。

コンテナの状態を確認してみましょう。

openclaw sandbox list

📦 Sandbox Runtimes:

  openclaw-sbx-agent-family-99f487df
    Status:  🟢 running
    Image:   openclaw-sandbox:bookworm-slim ✓
    Backend: docker
    Age:     1h
    Idle:    21s
    Session: agent:family

このコンテナも、上のメッセージ送信の瞬間に自動で作られたものです。

対比として、mainにも同じ質問を投げてみてください。

openclaw agent --agent main --message "現在のディレクトリを教えて"

こちらは/Users/daisuke/.openclaw/workspace（ホスト側のパス）が返ってきます。mainはホスト直接実行、familyはサンドボックス越しに/agentでホスト領域を読み取り専用で参照しているわけです。

Step 11：Control UIを使う

OpenClawはCLI/TUIに加えてブラウザベースのControl UIを提供しており、チャットのやり取りや各種設定がやりやすくなります。初回セットアップさえ済ませれば、以降はhttp://127.0.0.1:18789/にアクセスすれば使えます。

起動と初回ログイン

http://127.0.0.1:18789/ にアクセスします。

アクセスできない場合は、Gatewayを再起動してください。

openclaw gateway restart
openclaw gateway status

最初にアクセスすると、以下のような画面が出ます。

OpenClaw Control UI

このブラウザはまだ承認されていません。 CLIで次のコマンドを実行して承認してください。

openclaw devices list                   # 保留中のリクエストを確認
openclaw devices approve 4d2a1f8c-...

🎉 第1部はここで完了です。

この時点で、SlackからMac上のOpenClawに話しかけ、2種類のエージェントを使い分けられる状態になっています。一度ここで止まって、しばらく触ってみるのもおすすめです。

第1部で動かした最小構成は、「2エージェント構成でサンドボックス有無の差を確認する」ことに最適化されていました。ここからの第2部では、この最小構成を実運用に育てていくために、もう少し権限を与えてみます。

具体的には、用途別に権限を段階的に解放した3種類のエージェント（work / dev / research）を設計し、「何を許すと何ができるようになり、何を引き受けることになるか」をステップバイステップで学びます。

5. これから追加するエージェントについて

5.1 用途別に3エージェントを追加する

本記事では以下のエージェントを追加します。main・familyに加え、work・dev・researchを追加していきます。

6. Step-up 1：`work`エージェント ― write/editを解放する

6.1 何を許可するのか

write・edit・apply_patchの3つです。

ツール	できること	典型的な使用例
`write`	ファイル新規作成	議事録の清書、新しいマークダウン作成
`edit`	既存ファイルの部分編集	文章の推敲、タイポ修正
`apply_patch`	diff形式のパッチ適用	複数ファイルの一括変更

6.2 設定例

openclaw.jsonのagents.listに以下を追加します。カンマやカッコに注意しながら追加してください。

{
  "id": "work",
  "name": "Work Assistant",
  "workspace": "/Users/daisuke/.openclaw/workspace-work",
  "sandbox": {
    "mode": "all",
    "scope": "agent",
    "workspaceAccess": "rw",
    "docker": {
      "image": "openclaw-sandbox:bookworm-slim",
      "network": "none",
      "memory": "1g",
      "cpus": 2
    }
  },
  "tools": {
    "allow": ["read", "write", "edit", "apply_patch"]
  }
},

familyとの違いは以下です。

workspaceAccess: "rw"：familyは"ro"（/agentにRead-Onlyマウント）でしたが、"rw"（/workspaceにRead/Writeマウント）と書き込みできるようになります。
allowに書き込みに使うツールを3つ追加（"write", "edit", "apply_patch"）しています。

設定変更後はGatewayを再起動します。

openclaw gateway restart

~/.openclaw/workspace-workディレクトリは事前に作らなくて構いません。初回にworkエージェントを呼び出したタイミングでOpenClawが自動生成します。

6.3 新しくできるようになること

チャットでworkに次の内容を話しかけてください。

openclaw agent --agent work --message "poem.mdに適当なポエムを書いて"

write/editレベルのファイル作業がチャット経由で完結するようになります。議事録の清書、ブログ原稿の推敲、マニュアルの修正などが頼めるようになります。

7. Step-up 2：`dev`エージェント ― execを解放する

7.1 何を許可するのか

execは任意のコマンドを実行するツールです。

execはOpenClawの権限のなかでも特に影響範囲が大きいツールです。LLMの判断で任意のシェルコマンドが走ることになるため、ここではsandboxに閉じたままexecを許可する構成としています（ホスト側でコマンドを実行する方法については、章末のコラムで触れます）。

workに続いてworkspaceAccessは"rw"のまま（開発・直接編集用）を踏襲します。sandbox境界により影響はコンテナ内に閉じますが、"rw"でマウントしている~/.openclaw/workspace-devはsandbox内から書き換え・削除が可能です。ホスト全体には届かないが、作業中のワークスペースは壊し得る、という前提で読み進めてください。

7.2 設定例

openclaw.jsonのagents.listに以下を追加してください。

{
  "id": "dev",
  "name": "Dev Assistant",
  "workspace": "/Users/daisuke/.openclaw/workspace-dev",
  "sandbox": {
    "mode": "all",
    "scope": "agent",
    "workspaceAccess": "rw",
    "docker": {
      "image": "openclaw-sandbox:bookworm-slim",
      "network": "none",
      "memory": "2g",
      "cpus": 2
    }
  },
  "tools": {
    "allow": ["read", "write", "edit", "apply_patch", "exec"]
  }
},

Gateway再起動：

openclaw gateway restart

~/.openclaw/workspace-devは初回のdevエージェント呼び出しで自動生成されます。

7.3 新しくできるようになること

次のようなコマンド実行です。

git status / git log → 現在のブランチ状況を要約
make test → テスト結果を要約
rg TODO ./src → ソースコード内のTODOを横断検索して整理

なお、network: "none"なので、コンテナ内のgitはリモートリポジトリと通信できません。ローカルリポジトリの操作（status, log, diff, commit）のみ可能です。git push / git pullをAIにやらせたい場合は、まずnetwork: "bridge"でネットワーク疎通を開ける必要がありますが、それだけでは足りません。sandboxにはSSH鍵・~/.gitconfig・GitHub PATなどの認証情報をマウントしていないため、リモートへの認証経路を別途用意しない限りpush/pullは通りません。

7.4 新しく引き受けるリスク

sandboxはホスト全体を守ってくれますが、workspaceAccess: "rw"でマウントしている~/.openclaw/workspace-devの中身は別です。プロンプトインジェクションで「rm -rf /workspace/*を実行して」と指示されたり、LLMの判断ミスで意図しないファイルが削除・上書きされる恐れがあります。ワークスペースは"消失する可能性がある前提"で運用し、重要なものはGit管理や定期バックアップで守ってください。

📝 コラム：ホスト側でコマンドを実行したいとき（ElevatedとExec Approvals）

本節で作ったdevエージェントは、execをsandboxのコンテナ内に閉じて実行する構成です。コンテナ内のgitはホストの実リポジトリを直接操作できないので、「ホスト側のリポジトリでそのままgitやmakeを走らせたい」というケースでは物足りなく感じるはずです。

OpenClawには、このようなときのためにツール実行をホスト側に逃がす仕組み（Elevated）と、その際のガードレール（Exec Approvals：バイナリのallowlistと毎回承認ダイアログ）が別途用意されています。Elevatedを有効にするとコマンドはsandboxの境界を越えてホストで走るので、強力な反面、誤爆時の影響範囲も一気に広がります。そのためExec Approvalsとの併用が実質前提になります。

本記事では扱いません。設計トレードオフが一段重くなるためで、必要になったタイミングで公式ドキュメントを参照するのが安全です。

Sandbox vs Tool Policy vs Elevated

Exec Approvals

8. Step-up 3：`research`エージェント ― web_fetch/networkを解放する

8.1 何を許可するのか

web_fetch（任意URLのHTTP GET + 本文抽出）を許可します。Web検索（web_search）を後で足すことも可能ですが、まずはweb_fetch単独で動かすのが最小構成です（web_searchの足し方は補足3で触れます）。

ここまで作ったエージェントは全部network: "none"でした。外部通信は特にリスクを伴うので、このエージェントだけは特に慎重な設計が必要です。

なお、web_fetchには「JS実行が必要なSPAや、ログイン/アンチボットのかかったサイトは読めない」という制約があります。静的ページには十分機能しますが、動的UIを相手にする場合は別途ブラウザ経由の構成を検討することになります。

8.2 設定例

openclaw.jsonのagents.listに以下を追加してください。

{
  "id": "research",
  "name": "Research Assistant",
  "workspace": "/Users/daisuke/.openclaw/workspace-research",
  "sandbox": {
    "mode": "all",
    "scope": "agent",
    "workspaceAccess": "ro",
    "docker": {
      "image": "openclaw-sandbox:bookworm-slim",
      "network": "bridge",
      "memory": "1g",
      "cpus": 1
    }
  },
  "tools": {
    "allow": ["read", "web_fetch"],
    "sandbox": {
      "tools": {
        "alsoAllow": ["web_fetch"]
      }
    }
  }
},

ここのポイント - network: "bridge"：外向き通信を許可するため、規定値のnoneから明示的に変更しています。web_fetchが外に出るために必要です。 - tools.sandbox.tools.alsoAllowにweb_fetchを明示しています。web_fetchはsandboxの既定許可セットに含まれていないため、alsoAllowで追加する必要があるためです（詳細は後述の補足1）。

Gatewayを再起動します。

openclaw gateway restart

~/.openclaw/workspace-researchは初回のresearchエージェント呼び出しで自動生成されます。

補足 1（なぜalsoAllowか）：4章で触れた通り、allowはrestrictive（列挙したものだけ有効）、alsoAllowはadditive（既定に追加）です。sandboxの既定許可セットにはexec・process・read・write・edit・apply_patch・image・sessions_*（list/history/send/spawn/yield）・subagents・session_statusが入っている一方、web_fetchは含まれていません。そのためalsoAllowでの追加許可が必要になります。

補足 2（SSRF対策）：web_fetchは組み込みでSSRF対策が効いており、127.0.0.1、169.254.169.254（クラウドメタデータ）、プライベートIPレンジへのアクセスは既定で拒否されます。リダイレクト先も再チェックされるため、追加設定なしで安全側に倒れます。

補足 3（web_searchを使いたい場合）：検索プロバイダ（Brave / Perplexity / Geminiなど）のAPIキー設定と合わせて、tools.allowとtools.sandbox.tools.alsoAllowの両方にweb_searchを足せば有効化できます。未設定で列挙だけしても機能しないので、まずweb_fetch単独で運用を確立してから追加するのが無難です。

8.3 新しくできるようになること

公開ページの要約、RSS代替、公開APIのGET、技術ドキュメント調査などがユースケースです。結果はOpenClaw側で15分キャッシュされるので、同じURLを繰り返し読んでも外部には毎回アクセスしません。

9. まとめ

第2部でやったこと

Step-up	やったこと
1	`work`エージェント：文書作業用にwrite/editを安全に解放
2	`dev`エージェント：開発作業用にexecをsandbox内で解放
3	`research`エージェント：Web調査のためにnetworkを解放（機密データ軸を切る設計）

用途別エージェント構成の最終形

本記事の第1部・第2部を通じて構築できる5エージェント構成のまとめです。

Agent	サンドボックス	workspaceAccess	ネットワーク	主な権限	用途
`main`	off	―（ホスト直接実行）	―	フル（ただし実運用非推奨）	学習用、ホスト実行の挙動確認
`family`	all	`ro`（`/agent`にRO）	none	readのみ	家族・来客のリードオンリー窓口
`work`	all	`rw`（`/workspace`にRW）	none	+write/edit/apply_patch	自分の文書作業
`dev`	all	`rw`（`/workspace`にRW）	none	+exec	自分の開発作業
`research`	all	`ro`（`/agent`にRO）	bridge	+web_fetch	Web調査

roは「信頼できない相手にホスト領域を見せるが書き換えさせたくない（family）」と「信頼できない入力源を扱うが書き込み経路を閉じたい（research）」の両方で使える、防御的な中間段として機能します。rwは自分自身が使う作業系エージェント（work・dev）に限定することで、「書き込み先がホストと直結する」リスクを引き受ける場面を最小化しています。

段階的に育てるメンタルモデル

最初から全部盛りにせず、用途が明確になった時点で対応するエージェントを追加するのが実践的です。

文書作業から始めるなら：main（学習）+ family（参考）+ workの3つで十分
開発作業が加わったら：devを追加
Web調査が必要になったら：researchを追加、ただしdevと混ぜない

そして、エージェントを追加するたびに次の3点を自分に問う習慣をつけてください。

何を許すのかを設定ファイルと対応づけて説明できる
何ができるようになるのかを具体例で言える
何を引き受けるのか（リスク）を理解している

この3点を満たしている状態を保つのが、エージェント運用の要です。

次のステップ

本記事ではここまでとしますが、実運用ではさらに考えることがあります。機会があれば、次のテーマも記事化したいと思います。

ローカルLLMへの移行：機密情報を外部APIに送らないため、Ollama統合でqwen3:14bやgpt-oss:20b等をローカルで動かす
Tailscale Serveでの閉域化：外出先から使いたい場合、Tailnet経由のHTTPSでの接続が安全です。gateway.bind: "0.0.0.0"は原則として推奨されません
監査ログのSIEM連携：~/.openclaw/agents/<agentId>/sessions/*.jsonlを集約して継続監視

AIエージェントが「応答するもの」から「行動するもの」に変わった今、用途ごとに分離された複数エージェントを育てていくスキルは、これからのエンジニアに求められる能力です。

本記事がその実践の一助となれば幸いです。

参考文献

OpenClaw公式ドキュメント

トップ（英語）：https://docs.openclaw.ai/
トップ（日本語）：https://docs.openclaw.ai/ja-JP
GitHubリポジトリ：https://github.com/openclaw/openclaw
サンドボックス化（日本語）：https://docs.openclaw.ai/ja-JP/gateway/sandboxing
セキュリティ：https://docs.openclaw.ai/gateway/security
Dockerインストール：https://docs.openclaw.ai/install/docker
Exec Approvals：https://github.com/openclaw/openclaw/blob/main/docs/tools/exec-approvals.md
Gateway Runbook：https://docs.openclaw.ai/gateway
Ollama：https://docs.openclaw.ai/providers/ollama
Tailscale：https://docs.openclaw.ai/gateway/tailscale
Sandbox CLI：https://open-claw.blog/docs/sandbox.html

執筆者

梅木大助
NTT西日本で、主にクラウドビジネスのサービス開発を担当しています。
最近、同じ時代を舞台にした大河ドラマを2作並行で見始めてしまいました。登場人物の顔と名前がごちゃ混ぜになり多少混乱しますが、同じ役どころが脚本家や演じ手によってこうも違って見えるのかと、ただただ感心するばかりです。
保有資格：AWS Certified Solutions Architect - Professional、AWS Certified Advanced Networking - Specialty、AWS Certified Security - Specialtyなど。

商標

OpenClawは、OpenClaw Foundationの商標です。
macOS、Apple、Apple Silicon、iCloud、Keychain、LaunchAgentは、Apple Inc.の商標です。
Dockerは、Docker, Inc.の商標です。
Homebrewは、Homebrewプロジェクトの商標です。
Anthropic、Claudeは、Anthropic, PBC.の商標です。
OpenAIは、OpenAI OpCo, LLCの商標です。
Ollamaは、Ollama Inc.の商標です。
Slackは、Slack Technologies, LLCの商標です。
LINEは、LY Corporation（LINEヤフー株式会社）の商標です。
Discordは、Discord Inc.の商標です。
Node.jsは、OpenJS Foundationの商標です。
GitHubは、GitHub, Inc.の商標です。

※その他、本文中に記載されている会社名、製品名、サービス名は、各社の商標もしくは登録商標です。

免責事項

本記事で紹介している設定例やコマンドは、2026年4月時点の情報に基づきます。OpenClawは急速に進化しており、設定項目や挙動が変更される可能性があります。実際の運用にあたっては、公式ドキュメントの最新版を必ずご確認のうえ、ご自身の責任において実施してください。本記事の内容に起因する損害について、筆者および当社は一切の責任を負いかねます。