AI革命 - 生成AIコンサルティング・受託開発

OpenClawはローカルマシン上で動作する自律型AIエージェントであり、ファイル操作・シェルコマンド実行・ブラウザ制御といった強力な権限を持つため、セキュリティ設定を適切に行わないと深刻なリスクにつながります。本記事では、公式ドキュメントに基づいたセキュリティ設定項目を体系的に整理し、用途別の推奨設定テンプレートからopenclaw security auditによる監査手順まで、実践的に解説します。

この記事でわかること:

OpenClawのセキュリティ設定項目の全体像と各項目の意味
メッセージング用・開発用・企業評価用など用途別の推奨設定
openclaw security auditコマンドの使い方と結果の読み方
インシデント発生時の対応フロー
設定すべきでない危険な構成パターン

こんな方に向けた記事です:

OpenClawを導入済みで、セキュリティ設定を見直したい方
これから導入予定で、安全な初期設定を知りたい方
企業でOpenClawの導入評価をしており、セキュリティ要件を確認したい方

OpenClawの基本的な特徴や危険性の概要については「OpenClawとは？できること・使い方・危険性をわかりやすく解説」、リスクの全体像については「OpenClawの危険性とは？リスクと安全な運用方法を整理」もあわせてご確認ください。

OpenClawのセキュリティ設定が重要な理由

OpenClawは、ChatGPTやClaudeのようなクラウド完結型AIとは根本的に異なり、ユーザーのローカルマシン上でファイルの読み書き・シェルコマンドの実行・ブラウザ操作を直接行います。つまり、設定を誤れば、AIエージェントがマシン上のあらゆるデータにアクセスし、意図しない操作を実行する可能性があります。

公式ドキュメントでは「個人アシスタント展開向け設計：ゲートウェイあたり1信頼境界」と明記されており、マルチテナントには対応していません。セキュリティは「自分で設定して守る」前提の設計です。

特に注意すべき構造的な特徴は以下の3つです。

プライベートデータへのアクセスと外部通信能力が同一システムに同居している — ファイル読み取りとネットワーク通信を同時に行えるため、情報漏洩のリスクが生じる
デフォルト設定ではサンドボックスが無効（オプトイン方式） — 明示的に有効化しない限り、エージェントの操作に制限がかからない
認証情報が平文で保存される — ~/.openclaw/ディレクトリ内のファイルが窃取されると、エージェントの乗っ取りが可能になる

こうした構造を理解した上で、適切なセキュリティ設定を行うことが、OpenClawを安全に活用するための前提条件です。

セキュリティ設定項目の全体像

OpenClawのセキュリティ設定は、大きく6つのカテゴリに分かれます。ここでは各カテゴリの設定項目を、デフォルト値・推奨値とともに整理します。

設定ファイルは ~/.openclaw/openclaw.json に記述します。

Gateway認証・ネットワーク設定

Gatewayは外部からの接続を受け付ける入口であり、最も重要な防御ポイントです。

設定項目	デフォルト値	推奨値	説明
`gateway.bind`	`loopback`	`loopback`	ネットワークバインド先。loopbackはlocalhostのみ接続可
`gateway.port`	`18789`	`18789`	Gatewayのポート番号
`gateway.auth.mode`	—	`token`	認証方式（token / password / trusted-proxy）
`gateway.auth.token`	—	32文字以上のランダム文字列	ベアラートークン
`gateway.mode`	—	`local`	ゲートウェイモード
`gateway.controlUi.dangerouslyDisableDeviceAuth`	—	必ずfalse	デバイス認証の無効化（極めて危険）

絶対に避けるべき設定: gateway.bind を 0.0.0.0 に設定すると、ネットワーク上のすべてのデバイスからGatewayにアクセス可能になります。公式・セキュリティ各社ともに「最も危険な構成」として警告しています。

チャネルアクセス制御（DM・グループ）

OpenClawに誰がメッセージを送れるかを制御する設定です。WhatsApp・Telegram・Discord・Slackなど、接続しているチャットサービスごとに設定します。

設定項目	デフォルト値	推奨値	説明
`dmPolicy`	`pairing`	`pairing` または `allowlist`	DM受信ポリシー
`groupPolicy`	`pairing`	`pairing` または `allowlist`	グループポリシー
`requireMention`	—	`true`	グループ内でメンション必須にする

ポリシーの選択肢:

pairing（推奨）: 未知の送信者にはペアリングコードが発行され、管理者が承認するまでメッセージは無視される
allowlist: 事前に許可リストに登録したユーザーのみ受け付ける
open（非推奨）: 誰でもメッセージを送信可能。プロンプトインジェクション攻撃に対して無防備になる
disabled: DM・グループ機能そのものを無効化

ツールポリシー・プロファイル

OpenClawがどのツール（機能）を使えるかを制御する、セキュリティの核心部分です。

設定項目	デフォルト値	推奨値	説明
`tools.profile`	—	用途に応じて選択	ツールプロファイル
`tools.deny`	—	不要なツールを明示的に拒否	禁止ツールリスト
`tools.exec.security`	—	`deny`（一般）/ `ask`（開発用）	シェル実行の許可レベル
`tools.exec.ask`	—	`always`	実行確認の頻度
`tools.elevated.enabled`	`false`	`false`	特権ツールの有効化
`tools.fs.workspaceOnly`	—	`true`	ファイルアクセスをワークスペースに制限

プロファイル一覧（公式）:

プロファイル	対象ユースケース	権限範囲	セキュリティレベル
`minimal`	最小限の利用	メッセージング基本のみ	最高
`messaging`	一般利用（推奨）	テキスト・ファイル読み取り	高
`coding`	開発作業	exec許可（サンドボックス推奨）	中
`full`	フルアクセス	全ツール有効	低（上級者限定）

tools.exec.security を full に設定すると、エージェントは確認なしにあらゆるシェルコマンドを実行できます。公式の監査チェックでも「警告/危機的」と分類される設定であり、サンドボックスなしでの使用は避けてください。

サンドボックス・Docker設定

エージェントの操作を隔離環境内に閉じ込めるための設定です。特に開発用途（codingプロファイル）では、サンドボックスの有効化が強く推奨されます。

設定項目	デフォルト値	推奨値	説明
`sandbox.mode`	`off`	`all` または `docker`	サンドボックスモード
`sandbox.scope`	`agent`	`agent`	スコープ（agent/session/shared）
`sandbox.workspaceAccess`	`none`	`none` または `ro`	ワークスペースへのアクセス権限
`sandbox.docker.network`	`none`	`none`	Dockerコンテナのネットワーク

Docker社が公式に提供するOpenClaw向けサンドボックスソリューション（2026年2月〜）では、マイクロVM内でエージェントを完全隔離し、ネットワークプロキシ経由でAPIキーを注入するため、エージェントが秘密鍵に直接アクセスできない設計になっています。

セッション分離

セッションの分離範囲を制御します。

設定項目	デフォルト値	推奨値	説明
`session.dmScope`	`main`	`per-channel-peer`	セッションスコープ

デフォルトのmainでは全DMが同一セッションを共有するため、あるユーザーとの会話コンテキストが別のユーザーに漏れる可能性があります。per-channel-peerに変更することで、チャネル×相手ごとにセッションが分離されます。

ファイルパーミッション

OpenClawの設定ファイル・認証情報が格納されるディレクトリのOS側パーミッション設定です。

対象	推奨パーミッション	設定コマンド
`~/.openclaw/`	`700`（ユーザーのみ）	`chmod 700 ~/.openclaw/`
`~/.openclaw/openclaw.json`	`600`（ユーザー読み書きのみ）	`chmod 600 ~/.openclaw/openclaw.json`
`~/.openclaw/credentials/`	`700`	`chmod 700 ~/.openclaw/credentials/`

パーミッションが不適切な場合、openclaw security auditで「危機的」レベルの警告が表示されます。Vidarマルウェアなどによる設定ファイル窃取の事例が実際に報告されており、パーミッション設定は必須です。

用途別の推奨設定テンプレート

ここでは、利用シーンに応じた設定テンプレートを4パターン紹介します。自分の用途に近いテンプレートをベースに、必要に応じてカスタマイズしてください。

パターン1: メッセージング専用（初心者向け）

チャットアプリ経由でのテキストやり取りが中心で、ファイル操作やコマンド実行は不要な場合の設定です。

{
  "gateway": {
    "mode": "local",
    "bind": "loopback",
    "auth": {
      "mode": "token",
      "token": "（32文字以上のランダム文字列）"
    }
  },
  "session": {
    "dmScope": "per-channel-peer"
  },
  "tools": {
    "profile": "messaging",
    "exec": {
      "security": "deny"
    },
    "elevated": {
      "enabled": false
    },
    "fs": {
      "workspaceOnly": true
    }
  },
  "channels": {
    "whatsapp": {
      "dmPolicy": "pairing",
      "groups": {
        "*": {
          "requireMention": true
        }
      }
    }
  }
}

この設定のポイントは、シェル実行を完全に拒否（exec.security: deny）し、ファイルアクセスをワークスペースに限定している点です。公式が「60秒ハードニングベースライン」として推奨している構成とほぼ同等です。

パターン2: 開発者向け（Dockerサンドボックス付き）

コーディング支援としてOpenClawを使う場合の設定です。シェルコマンドの実行を許可しつつ、Dockerサンドボックスで隔離します。

{
  "gateway": {
    "mode": "local",
    "bind": "loopback",
    "auth": {
      "mode": "token",
      "token": "（32文字以上のランダム文字列）"
    }
  },
  "session": {
    "dmScope": "per-channel-peer"
  },
  "tools": {
    "profile": "coding",
    "exec": {
      "security": "ask",
      "ask": "always"
    },
    "elevated": {
      "enabled": false
    },
    "fs": {
      "workspaceOnly": true
    }
  },
  "sandbox": {
    "mode": "docker",
    "scope": "agent",
    "workspaceAccess": "rw",
    "docker": {
      "network": "none"
    }
  }
}

exec.security: ask + exec.ask: always の組み合わせにより、シェルコマンドは毎回ユーザーの承認を求めてから実行されます。さらにDockerサンドボックスで隔離されるため、万が一不正なコマンドを承認してしまっても、ホストマシンへの影響を最小限に抑えられます。

パターン3: 企業セキュリティ評価向け（最小権限）

企業でOpenClawの導入を検討する際、評価目的で最小限の権限で試用する場合の設定です。

{
  "gateway": {
    "mode": "local",
    "bind": "loopback",
    "auth": {
      "mode": "token",
      "token": "（32文字以上のランダム文字列）"
    }
  },
  "session": {
    "dmScope": "per-channel-peer"
  },
  "tools": {
    "profile": "minimal",
    "exec": {
      "security": "deny"
    },
    "elevated": {
      "enabled": false
    }
  },
  "sandbox": {
    "mode": "all",
    "scope": "agent",
    "workspaceAccess": "none",
    "docker": {
      "network": "none"
    }
  }
}

minimalプロファイル + サンドボックス all + ワークスペースアクセス none という最も制限の厳しい構成です。評価の際は専用のVM上で動かし、機密データを一切含まない環境で試すことを推奨します。

パターン4: リードオンリーモード（情報閲覧専用）

エージェントにファイルの読み取りのみを許可し、書き込み・編集・コマンド実行を一切禁止する設定です。

{
  "sandbox": {
    "workspaceAccess": "ro"
  },
  "tools": {
    "allow": ["read"],
    "deny": ["write", "edit", "apply_patch", "exec"]
  }
}

ログ分析やドキュメント要約など、読み取りだけで完結する用途に適しています。

用途別の設定比較

項目	メッセージング	開発者向け	企業評価	リードオンリー
profile	`messaging`	`coding`	`minimal`	カスタム
exec.security	`deny`	`ask`	`deny`	`deny`
sandbox.mode	`off`	`docker`	`all`	—
workspaceAccess	—	`rw`	`none`	`ro`
セキュリティレベル	高	中〜高	最高	最高
想定ユーザー	一般ユーザー	エンジニア	セキュリティ担当者	分析担当者

`openclaw security audit`によるセキュリティ監査

OpenClawには公式のセキュリティ監査コマンドが組み込まれています。初回セットアップ後、設定変更後、定期的な確認時に実行することを推奨します。

監査コマンドの種類

# 基本監査（初回セットアップ後に必ず実行）
openclaw security audit

# 詳細監査（ライブGatewayプローブを含む）
openclaw security audit --deep

# 自動修正（実行前に変更内容を確認すること）
openclaw security audit --fix

# JSON出力（CI/CD統合向け）
openclaw security audit --json

基本監査はオフラインで設定ファイルを検査するもので、--deep オプションを付けると実際にGatewayへ接続して認証やバインド状態を確認します。まずは基本監査を実行し、問題がなければ --deep で追加検証する流れが効率的です。

主要な監査チェック項目と深刻度

監査結果に表示される主要なcheckIDと、その意味・対処法を以下にまとめます。

checkID	深刻度	内容	対処法
`fs.state_dir.perms_world_writable`	危機的	`~/.openclaw`のパーミッション不備	`chmod 700 ~/.openclaw/` を実行
`gateway.bind_no_auth`	危機的	認証なしで外部バインド	`gateway.auth.mode: "token"` を設定
`security.exposure.open_groups_with_elevated`	危機的	オープングループ+特権ツール有効	グループポリシーをpairingに変更し、`elevated.enabled: false`に
`tools.exec.security_full_configured`	警告〜危機的	exec.securityがfull	`ask` または `deny` に変更
`sandbox.docker_config_mode_off`	警告	サンドボックス無効	`sandbox.mode` を `docker` または `all` に変更
`gateway.tailscale_funnel`	危機的	Tailscale Funnelが有効	Funnelを無効化するか、認証を必ず設定

「危機的」レベルの項目が1つでも表示された場合は、OpenClawの運用を一時停止し、即座に対処してください。

監査→修正→再監査のフロー

openclaw security audit を実行し、結果を確認
「危機的」→「警告」の順に対処（設定ファイルを編集）
OpenClawを再起動（設定の反映）
openclaw security audit --deep で再度検証
すべてのチェックがパスするまで繰り返す

--fix オプションで自動修正も可能ですが、事前に --json で変更内容を確認してから実行するのが安全です。

既知の脆弱性と必要な対策

OpenClawには過去に複数の深刻な脆弱性が報告されています。セキュリティ設定と合わせて、バージョンを常に最新に保つことが重要です。

脆弱性	深刻度	対策
CVE-2026-25253（ワンクリックRCE）	CVSSスコア 8.8	v2026.1.29以降へのアップデート
ClawHavocキャンペーン（悪意あるスキル）	高	スキル導入前のソースコード手動レビュー
Vidarマルウェアによる設定ファイル窃取	高	ファイルパーミッション700/600の設定
ClawJacked（WebSocket認証バイパス）	高	`gateway.bind: loopback` + 認証トークン設定

セキュリティアドバイザリの最新情報は trust.openclaw.ai で確認できます。公式によると、現時点で9件のCVEが公開されています。

スキル導入時のセキュリティチェックポイント

ClawHubに公開されているスキル（拡張機能）の中には悪意あるコードが含まれている事例が報告されています。スキルを導入する前に、以下のレッドフラグがないか確認してください。

curl | bash や wget | sh などのパイプ実行パターン
base64エンコードされた不透明なコード
不必要な外部サーバーへの通信
tools.elevated.enabled: true を要求するスキル
GitHubスター数が極端に少ない、作成日が新しすぎるリポジトリ

プロンプトインジェクション対策

公式セキュリティポリシーでは「プロンプトインジェクションへの完全な防御は現時点で保証されていない」「セキュリティ報告の対象外」と明記されています。完全な防御は技術的に困難ですが、設定によってリスクを大幅に低減できます。

設定で講じるべき対策:

DMポリシーをpairingまたはallowlistにする — 未知の送信者からのメッセージを遮断し、攻撃の入口を塞ぐ
グループでrequireMention: trueにする — グループ内の全メッセージに反応するのを防ぐ
tools.exec.securityをdenyまたはaskにする — インジェクションに成功しても、コマンド実行を阻止する
高性能な最新モデルを使う — 小型・旧式のモデルはインジェクション耐性が低いと公式が注意喚起している
ブラウザに専用プロファイルを使う — デフォルトの「openclaw」プロファイルを使い、ログイン済みの個人プロファイルでブラウザ制御を行わない

インシデント発生時の対応フロー

万が一セキュリティインシデントが発生した場合の対応手順です（公式ドキュメント準拠）。

ステップ1: 封じ込め

# 1. Gatewayを即座に停止
openclaw stop

# 2. 設定ファイルを安全な状態に変更
# gateway.bind: "loopback" に変更
# 危険なDM/グループを dmPolicy: "disabled" に変更

ステップ2: 資格情報のローテーション

Gateway認証トークン/パスワードを更新し、再起動
リモートクライアントの資格情報を更新
プロバイダー/APIの資格情報をすべてローテーション

ステップ3: 監査・調査

# ログの確認
cat /tmp/openclaw/openclaw-$(date +%Y-%m-%d).log

# セッション履歴の確認
ls ~/.openclaw/agents/*/sessions/*.jsonl

# 設定変更履歴の確認（bind, auth, dmPolicy, tools.elevated等）

# セキュリティ監査の再実行
openclaw security audit --deep

調査で確認すべきポイントは、「いつ」「どのチャネルから」「どのような操作が行われたか」です。セッション履歴（.jsonlファイル）にはエージェントの全操作ログが記録されています。

設定変更の手順（ステップバイステップ）

セキュリティ設定を実際に変更する手順を、順を追って説明します。

1. 設定ファイルの場所を確認

# メインの設定ファイル
ls -la ~/.openclaw/openclaw.json

# 現在の設定を確認
cat ~/.openclaw/openclaw.json

2. バックアップを取得

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.backup

3. 設定ファイルを編集

任意のテキストエディタで ~/.openclaw/openclaw.json を編集します。前述の用途別テンプレートを参考に、必要な項目を追加・変更してください。

4. ファイルパーミッションを設定

chmod 700 ~/.openclaw/
chmod 600 ~/.openclaw/openclaw.json
chmod 700 ~/.openclaw/credentials/

5. OpenClawを再起動

openclaw stop
openclaw start

6. 監査を実行して確認

openclaw security audit --deep

すべてのチェックが通れば、設定変更は完了です。

mDNSの無効化（ネットワーク検出の抑制）

OpenClawはデフォルトでmDNS（Bonjour）によるネットワーク検出が有効です。ローカルネットワーク上の他のデバイスからOpenClawの存在が検知される可能性があるため、不要な場合は無効化を推奨します。

export OPENCLAW_DISABLE_BONJOUR=1

環境変数として設定するか、シェルのプロファイルファイル（.bashrc、.zshrcなど）に追加してください。

こんな方にはOpenClawの利用をおすすめしません

セキュリティ設定に時間をかけたくない方 — デフォルト設定のままでは危険であり、最低限の設定変更が必須
機密データを扱うマシンで使いたい方 — Semgrepのセキュリティチートシートでは「OpenClawをクラウンジュエル（最重要資産）のシステム・データに接続してはならない」と明記されている
CLIやJSON設定ファイルの操作に不慣れな方 — 設定はすべてJSON形式のファイル編集で行うため、基本的なCLI操作スキルが前提
マルチテナント環境で共有利用したい方 — 公式がマルチテナント非対応と明記しており、複数ユーザーでの共有は推奨されない

こんな方におすすめ

OpenClawの自律的な操作能力を理解した上で、適切に制御できるエンジニア
Dockerやサンドボックス環境を構築・運用できる方
個人の開発マシンで、非機密のプロジェクトに対してAIエージェントを活用したい方
セキュリティ監査の結果を読み解き、継続的に設定を見直せる方

AIエージェント全般の比較検討には「生成AIツールおすすめ比較｜主要ツールの特徴と選び方」も参考にしてください。

よくある質問（FAQ）

Q1. OpenClawのセキュリティ設定は最低限どこまでやれば安全ですか？

公式が推奨する「60秒ハードニングベースライン」として、以下の4点は最低限設定してください。(1) gateway.bind: loopback + auth.mode: token（Gateway保護）、(2) tools.exec.security: deny（シェル実行禁止）、(3) dmPolicy: pairing（未知のDM遮断）、(4) ファイルパーミッション700/600の設定。ただしこれは最低限であり、用途に応じた追加設定が望ましいです。

Q2. Dockerサンドボックスは必須ですか？

メッセージング用途でexec.security: denyにしている場合は必須ではありません。しかし、開発用途でcodingプロファイルを使いシェル実行を許可する場合は、Dockerサンドボックスの有効化を強く推奨します。Docker社が公式に提供するOpenClaw向けサンドボックスを利用すれば、比較的容易に導入できます。

Q3. `openclaw security audit`はどのくらいの頻度で実行すべきですか？

初回セットアップ後は必ず実行してください。その後は、設定変更のたびに実行するほか、OpenClawのバージョンアップ後、新しいスキルやチャネルを追加した後にも実行することを推奨します。定期的には月1回程度の実行が目安です。

Q4. OpenClawの認証情報はどこに保存されますか？

~/.openclaw/credentials/ ディレクトリ以下に、チャネルごとの認証情報が保存されます。WhatsApp認証は credentials/whatsapp/<accountId>/creds.json、モデル認証は agents/<agentId>/agent/auth-profiles.json に格納されます。これらは平文保存のため、ファイルパーミッション設定が極めて重要です。

Q5. ChatGPTやClaudeと比べて、なぜOpenClawだけセキュリティ設定が必要なのですか？

ChatGPTやClaudeはクラウド上で動作し、ユーザーのローカル環境にアクセスする権限を持ちません。一方、OpenClawはユーザーのマシン上で直接動作し、ファイル操作・コマンド実行・ブラウザ制御を行うため、権限管理をユーザー自身が設定する必要があります。利便性と引き換えに、セキュリティ責任がユーザー側にあるという構造の違いです。

Q6. 企業でOpenClawを導入する場合、追加で検討すべき点はありますか？

企業導入では、(1) 専用のVM/コンテナ上で動作させ本番環境から完全に分離する、(2) 機密データを含まない環境でのみ使用する、(3) マルチテナント非対応のため1インスタンス1ユーザーで運用する、(4) セキュリティ監査コマンドをCI/CDパイプラインに組み込み定期的に自動検査する、といった追加対策を検討してください。

まとめ

OpenClawのセキュリティ設定は、Gateway認証・チャネルアクセス制御・ツールポリシー・サンドボックス・セッション分離・ファイルパーミッションの6カテゴリを理解し、自分の利用シーンに合った設定を選ぶことが重要です。

最低限やるべきことは以下の4つです。

gateway.bind: loopback + auth.mode: token でGatewayを保護する
tools.exec.security を deny または ask に設定する
dmPolicy を pairing または allowlist にする
chmod 700 ~/.openclaw/ でファイルパーミッションを設定する

設定後は openclaw security audit --deep で必ず検証し、定期的に監査を実施してください。

OpenClawの導入・インストール手順については「OpenClawの使い方・インストール方法を解説」、リスクの全体像については「OpenClawの危険性とは？リスクと安全な運用方法を整理」、AIエージェント全般については「AIエージェントとは？仕組み・種類・活用事例をわかりやすく解説」もあわせてご確認ください。