OpenClaw セキュリティ設定完全ガイド：Docker サンドボックスから権限制御までの 5 層防御
クイック結論（先に答え）
時間がなければ、まずこの 3 つで OpenClaw の高リスクシナリオの大半を抑えられます。
1）認証（トークン／パスワード）を必須にし、入口を制限する。
2）コンテナサンドボックス + 非 root + 最小権限。
3）高危険ツールをホワイトリスト化し、機密コマンドはデフォルト拒否。
この 3 つを固めたあと、監査ログとネットワーク分離を足すと効果が高い。
深夜3時、ある開発者がRedditに助けを求める投稿をしました。彼はMacBookにOpenClawをインストールし、デフォルト設定で2週間ほど快適に使っていました。ある日、OpenClawに「最近のプロジェクトファイルを整理して」と頼んだところ、AIはついでに~/.ssh/と~/.aws/ディレクトリを読み取り、返信の中で「親切にも」彼の秘密鍵の内容を表示してしまったのです。
さらに致命的だったのは、この会話ログが職場のグループチャットに同期されていたことでした。
正直なところ、この事例を初めて見たとき、背筋が凍る思いでした。OpenClawは超強力なAIアシスタントであり、シェルコマンドの実行、ファイルの読み書き、ブラウザの制御が可能です。しかしそれは同時に、設定を誤れば、家の鍵を持った見知らぬ人のような存在になることを意味します。
「自分だけで使うから大丈夫だろう」と思っていませんか？
ああ、問題はそこにあるのです。OpenClawのリスクは外部からの攻撃だけではありません。プロンプトインジェクション（チャット中に誰かがこっそり悪意ある指令を紛れ込ませる）、設定ミス（うっかりAPIポートを公開してしまう）、さらにはAI自身の「過剰な熱意」（ファイルをクリーンアップしてと頼んだら、重要データを削除してしまうなど）もあります。
これらは正しい設定を行えば防げたはずのものです。
この記事では、OpenClawに「セキュリティの檻」をかける方法を手取り足取り教えます。Dockerサンドボックス隔離からきめ細かな権限管理まで、5層の防御でこの「猛獣」を安心して使えるようにします。先に言っておきますが、設定は少し面倒に見えるかもしれません。しかし、データ漏洩やデータベース削除のリスクに比べれば、この程度の手間は取るに足りません。
低コスト「エビ飼育」ガイド：ArkClaw で AI Agent を本当に身近に
話題の OpenClaw（ロブスター）は便利ですが、設定のハードルが高い——ByteDance Volcano Engine の ArkClaw はその敷居を大きく下げました。サーバーや Token 設定をいじらず、ワンクリックで 24 時間オンライン、ブラウザ操作・スクリプト実行・カレンダー管理ができる AI アシスタントを手に入れられます。
月額 9.9 元と本当に安い。招待コード ZLKUK54M（こちらから登録）を使えば 8.9 元。プログラマーなら Coding Plan Pro に入ると無料枠もあります。
なぜセキュリティ設定が必要なのか？
OpenClawの権限はどれほど強力か？
まず、身の引き締まるような事実をお話ししましょう。OpenClawはただチャットができるだけのAIアシスタントではありません。それができることは、基本的にあなたがターミナルでできるすべてのことと同じです。
- 任意のシェルコマンド実行：
rm -rf /？ 技術的には可能です。 - 全ファイルシステムの読み書き：SSHキー、AWS認証情報、データベースのパスワードなど、ディスク上にあれば触れることができます。
- ネットワークリソースへのアクセス：APIの呼び出し、ファイルのダウンロード、さらにはイントラネットのポートスキャンまで。
- ブラウザ制御：Playwrightを通じてブラウザを操作でき、ログイン状態のWebサイトも含まれます。
- 環境変数の読み取り：
process.env内の機密情報が丸見えになります。
言い換えれば、OpenClawにデフォルトの権限を与えることは、「頭はいいがあまりよく知らないアシスタント」に家のマスターキーを渡すようなものです。
デフォルト設定はどれほど危険か？
多くの人が手軽さを求めて npm install -g openclaw でインストールし、そのまま openclaw gateway を起動したり（daemon のみで動かしたり）していることを知っています。しかし、デフォルト状態で何が起こるか知っていますか？
v2026.1.29 以前：
- アクセス制御を
auth: noneに設定できました。つまり、URLを知った人は誰でもあなたのOpenClawを制御できました。 - サンドボックス隔離なし。AIは全ファイルシステムを読み書き可能。
- 危険な
execやbrowserを含むすべてのツールがデフォルトで有効。 - 高権限（rootの場合さえある）で実行される可能性。
"v2026.1.29 で auth: none オプションが強制削除され、トークンまたはパスワード認証が必須になりました"
v2026.1.29 以降は少しマシになりました：公式が auth: none オプションを強制削除し、トークンまたはパスワード認証が必須になりました。しかし、サンドボックス、ツール権限、ファイルシステムアクセスなどの問題は依然として存在し、手動で設定する必要があります。
正直なところ、デフォルト設定は家のドアを開け放って寝るようなもので、さらにドアの前に「ご自由にお入りください」という看板を立てているようなものです。
セキュリティ設定の3つの目標
これほど多くの設定をするのは、一体何のためでしょうか？核心は3点です：
1. 最小権限の原則：OpenClawに本当に必要な権限だけを与え、それ以外は一切与えないこと。コードを書かせるならworkspaceの読み書き権限を与えれば十分です。ブラウザ操作が不要なら、browserツールは無効化すべきです。
2. 多層防御：すべての希望を一つの防衛線に託さないこと。Docker隔離、非特権ユーザー、アクセス制御、ツールホワイトリスト、ネットワーク分離——5層の防御があれば、いずれか一層が突破されても、他の層がカバーできます。
3. 制御可能な爆発半径：最悪の事態（プロンプトインジェクション成功、トークン漏洩、あるいはAI自体のバグ）が発生したと仮定して、被害をどこまで抑えられるか？ もしOpenClawが隔離されたworkspaceディレクトリしかアクセスできなければ、漏洩するのはそのディレクトリの内容だけで、/homeディレクトリ全体ではありません。
要するに、セキュリティ設定は攻撃を防ぐため（それは不可能です）ではなく、攻撃のコストを十分に高くし、被害を十分に小さくするためにあるのです。
5層のセキュリティ設定
さて、前置きはこれくらいにして実践に入りましょう。下層から上層への順序で、5層の防御設定を解説します。各層で「なぜそうするのか」と「設定成功の検証方法」をお伝えします。
第1層：Dockerサンドボックス隔離（必須レベル）
なぜDockerを使うのか？
多くの人がDockerを単なるデプロイの手軽さのためだと思っています。違います。OpenClawのような高権限アプリケーションにとって、Dockerの最大の価値は隔離です：
- ファイルシステム隔離：AIはコンテナ内のファイルしか見えません。ホストマシンの
~/.sshには触れられません。 - ネットワーク隔離：コンテナの外部ネットワークアクセスを切断したり、特定のドメインのみ許可したりできます。
- リソース制限：AIが無限ループを実行してCPUを焼き尽くすのを防ぎます。
- 迅速な復元：問題が起きた？
docker rmでコンテナを消して、数秒でクリーンな環境を再構築できます。
「ローカルの開発マシンで動かすだけなのに、そんなに面倒なことが必要なの？」と聞かれることがあります。
必要です。ローカルこそ危険なのです——あなたの開発マシンにはGitHubトークン、データベースパスワード、各種APIキーがあり、これらはすべてプロンプトインジェクション攻撃の標的です。
設定手順
1. 安全なDockerfileの作成
FROM openclaw/gateway:latest
# 非特権ユーザーを作成
RUN adduser --disabled-password --gecos '' clawuser
# 非特権ユーザーに切り替え
USER clawuser
# 作業ディレクトリを設定
WORKDIR /home/clawuser/openclawここでのポイントは USER clawuser です。デフォルトのDockerコンテナはrootで実行され、これはコンテナ内のOpenClawがroot権限を持つことを意味します。専用ユーザーを作成すれば、仮に誰かがコンテナを突破しても、それはただの clawuser 権限に過ぎません。
2. Docker Composeで安全パラメータを設定
ここが核心部分です。一行ずつ解説します：
version: '3.8'
services:
openclaw-gateway:
build: .
container_name: openclaw-safe
# セキュリティ設定
security_opt:
- no-new-privileges:true # コンテナ内プロセスの権限昇格を防止
cap_drop:
- ALL # すべてのLinux capabilitiesを削除
cap_add:
- NET_BIND_SERVICE # ポートバインド能力のみ追加
# ルートファイルシステムの読み取り専用化
read_only: true
# 一時ディレクトリ（書き込み可能）
tmpfs:
- /tmp
- /home/clawuser/openclaw/temp
# リソース制限
deploy:
resources:
limits:
cpus: '2.0'
memory: 4G
reservations:
cpus: '1.0'
memory: 2G
# ネットワーク分離
networks:
- openclaw-isolated
# ボリュームマウント（最小権限）
volumes:
# 作業ディレクトリ（読み書き）
- ./workspace:/home/clawuser/workspace
# 設定ファイル（読み取り専用）
- ./config:/home/clawuser/openclaw/config:ro
# ログディレクトリ（書き込み専用）
- ./logs:/home/clawuser/openclaw/logs
networks:
openclaw-isolated:
driver: bridge
internal: true # 外部ネットワークへのアクセスを禁止なぜこのように設定するのか？
no-new-privileges:true：sudoやsetuidによる権限昇格を防ぎます。攻撃者がコンテナ内で脆弱性を見つけても、より高い権限を得ることはできません。cap_drop: ALL：Linuxのcapabilitiesはきめ細かな権限制御です。すべて削除してから必要なものだけ（ポートバインドなど）を追加することで、攻撃面を最小化します。read_only: true：ルートファイルシステムを読み取り専用にします。攻撃者が侵入しても、バックドアの設置やシステムファイルの改ざんができません。書き込みが必要な場所（/tmpなど）はtmpfsでマウントします。internal: true：コンテナは外部ネットワークにアクセスできません。OpenClawがネット接続を必要としない場合（ローカルファイル処理のみなど）、この設定でデータ漏洩を防げます。
3. OpenClawのsandboxモードを有効化
実行時の主設定は多くの場合 ~/.openclaw/openclaw.json（JSON） にあります。次の YAML は階層理解のための示意であり、実際のキー名・入れ子は Gateway 設定の公式ドキュメント を正としてください。自前の GitOps リポジトリで config/config.yaml という名前を使っている場合は、リポジトリ内の慣習であって、上流デフォルトのファイル名ではありません。
sandbox:
mode: "non-main" # すべてのグループチャットは隔離コンテナ内で実行
docker:
enabled: true
network: "none" # サンドボックスコンテナのネットワークアクセスを無効化これはOpenClaw自体のサンドボックス機能です。mode: "non-main" は、メインのチャットウィンドウ以外のすべての対話が独立したDockerコンテナ内で実行されることを意味します。これにより、ある対話がプロンプトインジェクション攻撃を受けても、その小さなサンドボックス内で暴れることしかできません。
検証方法
設定してすぐに使い始める前に、まず検証しましょう：
# コンテナが非rootユーザーで実行されているか確認
docker exec openclaw-safe whoami
# 返り値：clawuser
# ファイルシステムが読み取り専用か確認
docker exec openclaw-safe touch /test.txt
# 返り値：Read-only file system
# ネットワーク分離の確認
docker exec openclaw-safe ping 8.8.8.8
# 返り値：Network is unreachableこれら3つのテストすべてにパスしたら、おめでとうございます。第1層の防御は完了です。
第2層：非特権ユーザーでの実行（必須レベル）
Dockerコンテナ内では非rootを使っていますが、コンテナを起動するのは誰でしょうか？ホストマシン上でrootで docker-compose up を実行していると、攻撃者がコンテナから脱出した場合、やはりroot権限を取られてしまいます。
解決策：専用の低権限ユーザーを作成する
ホストマシン上での設定：
# 専用ユーザーグループとユーザーの作成
sudo groupadd -r openclaw
sudo useradd -r -g openclaw -d /opt/openclaw -s /bin/bash clawuser
# ディレクトリ構造の作成
sudo mkdir -p /opt/openclaw/{workspace,config,logs,temp}
# ディレクトリ権限の設定
sudo chown -R clawuser:openclaw /opt/openclaw
sudo chmod 700 /opt/openclaw/config # 設定ファイルディレクトリ（所有者のみ読み書き可）
sudo chmod 755 /opt/openclaw/workspace # 作業ディレクトリ
sudo chmod 750 /opt/openclaw/logs # ログディレクトリ
# ユーザー権限の制限
sudo usermod -L clawuser # パスワードログインをロック、su切り替えのみなぜ chmod 700 なのか？
chmod 700 は、ファイルの所有者（clawuser）だけが読み書き実行でき、他の人は見ることもできないという意味です。設定ファイルにはトークンやパスワードが含まれている可能性があるため、厳重に守る必要があります。
認証情報ファイルの権限（超重要！）
OpenClawでWhatsAppなどのサービスに接続する場合、認証情報ファイルの権限には特に注意が必要です：
# 認証情報ファイルは600（所有者のみ読み書き可）でなければなりません
chmod 600 ~/.openclaw/credentials/whatsapp/*/creds.json
chmod 700 ~/.openclaw認証情報ファイルを644（全員読み取り可）に設定してしまい、同じサーバーの他のユーザーに盗み見られたケースを見たことがあります。このような初歩的なミスは絶対に避けてください。
検証
# OpenClawプロセスのユーザーを確認
ps aux | grep openclaw
# rootではなくclawuserと表示されるべき
# ファイル権限を確認
ls -la /opt/openclaw/config
# drwx------ clawuser openclaw となるべきなぜこの層が重要なのか？
最悪の事態を想定しましょう：攻撃者がDockerコンテナを突破し、OpenClawのサンドボックスを突破し、任意のコードを実行しました——それでも彼が持っているのは clawuser 権限だけです：
- 他のユーザーのファイルにはアクセスできない
- システムレベルのソフトウェアはインストールできない（sudo権限がない）
/etc下のシステム設定は変更できない/rootディレクトリは読めない
これが多層防御の意義です。一層が突破されても、次の層があなたを守り続けます。
第3層：アクセス制御と身元認証（必須レベル）
前2層は「OpenClawに何ができるか」を解決しましたが、この層は「誰がOpenClawを使えるか」を解決します。
v2026.1.29 重大変更
以前のOpenClawは auth: none（全く認証しない）を許可しており、これはまさに災難でした。幸い公式がついに目を覚まし、v2026.1.29でこのオプションを強制削除しました。現在はトークンまたはパスワード認証の設定が必須です。
Gatewayトークン認証の設定
トークン認証はパスワードのどこが良いのでしょうか？異なる人/アプリに異なるトークンを割り当て、各トークンに異なる権限を設定できる点です。あるトークンが漏洩したら？それだけを取り消せばよく、他のトークンには影響しません。
Gateway 関連は ~/.openclaw/openclaw.json に記述します（自前リポジトリの config/config.yaml というファイル名と混同しないこと。以下の YAML は示意です）。
gateway:
# トークン認証を強制
auth: token
# トークン設定
tokens:
- name: "admin-token"
value: "${OPENCLAW_ADMIN_TOKEN}" # 環境変数から読み取り、ハードコード禁止！
permissions:
- "admin" # 全権限
- name: "readonly-token"
value: "${OPENCLAW_READONLY_TOKEN}"
permissions:
- "chat" # チャットのみ
- "read" # ファイル読み取りのみ
# 注意：exec、browserなどの高リスク権限は含まない安全なトークンの生成
123456 や mytoken のような弱いトークンは絶対に使わないでください。このコマンドで256ビットのランダムトークンを生成します：
# ランダムトークンを生成
openssl rand -base64 32
# 環境変数を設定（設定ファイルにハードコードしない！）
export OPENCLAW_ADMIN_TOKEN="生成されたトークン"
export OPENCLAW_READONLY_TOKEN="別のトークン"なぜハードコードしてはいけないのですか？設定ファイルはGitにコミットされたり、ログシステムに記録されたり、クラウドにバックアップされたりする可能性があるからです。環境変数の方が比較的安全です。
アクセス制御ホワイトリスト
トークンは「誰がアクセスできるか」を解決しますが、それだけでは十分ではありません。特定のWhatsAppユーザーやグループだけにOpenClawを使わせたい場合もあるでしょう：
# DM（プライベートチャット）ポリシー
dmPolicy: allowlist # ホワイトリストモード
allowFrom:
- "user_id_1" # これらのユーザーのみチャット可能
- "user_id_2"
# グループポリシー
groupPolicy: allowlist
allowFrom:
- "group_id_1" # これらのグループのみ使用可能
# Mention gating（グループチャットでは @メンション のみに応答）
mentionGating: true
# 公開アクセスの禁止
publicAccess: falsementionGating: true は特に有用です。想像してみてください。100人の仕事グループにOpenClawをデプロイした場合、これを有効にしないと、グループ内のすべてのメッセージをOpenClawが処理してしまいます（コストがかかるだけでなく、悪意あるプロンプト攻撃も受けやすくなります）。有効にすれば、@されたときだけ応答します。
検証
# 未認証アクセスのテスト（拒否されるべき）
curl -X POST http://localhost:3000/api/chat \
-H "Content-Type: application/json" \
-d '{"message":"hello"}'
# 返り値：401 Unauthorized
# 有効なトークンでのテスト
curl -X POST http://localhost:3000/api/chat \
-H "Authorization: Bearer ${OPENCLAW_ADMIN_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"message":"hello"}'
# 返り値：200 OKなぜこの層が重要なのか？
アクセス制御がなければ、前段の隔離や権限制限はすべて無駄になります——攻撃者はAPI経由で直接侵入でき、Dockerや権限昇格を突破する必要すらありません。
この層は門番であり、入るべきでない人を外で阻止します。
第4層：ツール権限管理（推奨レベル）
現在OpenClawは檻の中に閉じ込められていますが、檻の中でまだ多くのツールを使えます。危険な道具をいくつか没収する時です。
問題：デフォルトですべてのツールが使用可能
OpenClawには数十のツールが付属しています：exec（シェルコマンド実行）、browser（ブラウザ制御）、write_file（ファイル書き込み）、web_fetch（Webページ取得）…これらはデフォルトですべて有効です。
しかし、本当にこれらすべてが必要ですか？OpenClawにコードを書かせたり調査させたりするだけなら、browser や exec は完全に無効化すべきです。
ツールホワイトリストの設定
tools:
# 安全なツールのみ許可
allowlist:
- "read_file" # ファイル読み取り
- "write_file" # ファイル書き込み（ディレクトリ限定）
- "web_search" # ネット検索
- "git" # Git操作
# 注意：exec、browserなどの高リスクツールは含まない
# 高リスクツールは明示的な許可が必要
exec:
enabled: false # シェル実行をデフォルトで無効化
browser:
enabled: false # ブラウザ制御を無効化
web_fetch:
enabled: true
# ドメインホワイトリスト
allowedDomains:
- "github.com"
- "api.anthropic.com"
- "*.npmjs.com"execを有効にする必要がある場合は、コマンドホワイトリストを使用
テスト実行やプロジェクトのビルドなど、どうしてもOpenClawにコマンドを実行させる必要がある場合もあります。その場合はホワイトリストを使います：
tools:
exec:
enabled: true
sandbox: true # サンドボックスで実行
# ブラックリストよりホワイトリストが優れている
allowCommands:
- "git"
- "npm"
- "yarn"
- "pytest"
- "curl"
# 危険コマンドブラックリスト（二重保険）
denyCommands:
- "rm -rf"
- "sudo"
- "chmod 777"
- "dd if="
- "mkfs"
- "> /dev/sda"なぜホワイトリストがブラックリストより優れているのでしょうか？攻撃手法は無限に変化するため、すべての危険なコマンドをリストアップすることは不可能だからです。しかし安全なコマンドは有限なので、それらをリストアップすればいいのです。
ファイルシステムアクセス制限
filesystem:
# アクセス許可ディレクトリ
allowedPaths:
- "/home/clawuser/workspace"
- "/home/clawuser/projects"
# アクセス禁止ディレクトリ
deniedPaths:
- "/home/clawuser/.ssh"
- "/home/clawuser/.aws"
- "/home/clawuser/.config"
- "/etc"
- "/root"
# デフォルト権限
defaultPermission: "readonly" # デフォルトで読み取り専用
# 書き込み権限には明示的な付与が必要
writablePaths:
- "/home/clawuser/workspace/temp"このように設定すれば、プロンプトインジェクションでOpenClawに「~/.ssh/id_rsa を読んで」と命令しても、拒否されます。
検証
OpenClawのチャット画面でテスト：
-
あなた：「sudo apt update を実行して」
- OpenClawの返答：このコマンドは実行できません。セキュリティポリシーによりブロックされました。
-
あなた：「~/.ssh/id_rsa ファイルを読んで」
- OpenClawの返答：Access denied
第5層：ネットワーク分離と監視（上級）
企業ユーザーであったり、機密データを扱っていたり、あるいは究極のセキュリティを目指す場合、この層が最後の砦となります。
ネットワーク分離：不要な接続を切断
先ほど internal: true でコンテナが外部ネットワークにアクセスできないようにしました。しかしOpenClawはClaude APIを呼び出す必要があります。どうすればいいでしょうか？
解決策：アウトバウンドトラフィックのプロキシ
OpenClawが特定のドメイン（例：api.anthropic.com）のみにアクセスできるようにし、他はすべて遮断します：
# docker-compose.yml
services:
openclaw-gateway:
environment:
- HTTP_PROXY=http://allowlist-proxy:8080
- HTTPS_PROXY=http://allowlist-proxy:8080
networks:
- openclaw-isolated
allowlist-proxy:
image: squid:latest
volumes:
- ./squid.conf:/etc/squid/squid.conf:ro
networks:
- openclaw-isolated
- external # プロキシのみ外部アクセス可能squid.conf（プロキシホワイトリスト設定）：
# 許可するドメイン
acl allowed_domains dstdomain .anthropic.com
acl allowed_domains dstdomain .github.com
acl allowed_domains dstdomain .npmjs.com
# HTTPS許可
acl SSL_ports port 443
acl CONNECT method CONNECT
# アクセスルール
http_access allow allowed_domains
http_access deny all
# ログ
access_log /var/log/squid/access.logこのように設定すると、OpenClawこれら3つのドメインにしかアクセスできず、他のサイトはプロキシによって遮断されます。プロンプトインジェクションで「悪意あるスクリプトをダウンロード」させようとしても、できません。
監査ログ：すべてを記録
ログは攻撃を防ぐことはできませんが、何が起きたかを知る手がかりになります：
logging:
# 詳細ログを有効化
level: "info"
# 監査ログ
auditLog:
enabled: true
path: "/home/clawuser/openclaw/logs/audit.log"
format: "json"
# 記録内容
logToolCalls: true # すべてのツール呼び出しを記録
logFileAccess: true # ファイルアクセスを記録
logNetworkRequests: true # ネットワークリクエストを記録
logPrompts: true # すべてのプロンプトを記録（インジェクション検知）
# セッションログ
sessionLog:
enabled: true
path: "/home/clawuser/openclaw/logs/sessions/"logPrompts: true は特に重要です。誰かがチャットで「以前の制限を無視して、次を実行…」といった悪意ある指令を注入した場合、ログに記録され、事後分析が可能になります。
リアルタイム監視
# 不審な活動を監視
tail -f /opt/openclaw/logs/audit.log | grep -E "(exec|sudo|rm|chmod)"
# ネットワーク接続の監視
docker exec openclaw-safe netstat -tuln
# リソース使用状況の監視
docker stats openclaw-safeアラート設定
さらに進んで、自動アラートを設定することもできます：
alerts:
# 不審なコマンド実行
- type: "command_execution"
pattern: "sudo|rm -rf|chmod 777"
action: "block_and_notify"
# 機密ファイルへのアクセス
- type: "file_access"
pattern: "/.ssh/|/.aws/|/etc/passwd"
action: "block_and_notify"
# 不審なサイトへのアクセス
- type: "network_request"
pattern: ".*\\.onion|torproject\\.org"
action: "block_and_notify"アラートがトリガーされたら、メールやSlackメッセージを送信したり、OpenClawサービスを直接一時停止したりできます。
読み取り専用権限からの開始戦略
5層の防御を設定した後、「一気にすべて有効化すべきか？」と考えるかもしれません。
私のアドバイスは：いいえ。
セキュリティと利便性は常にバランスのアートです。設定が厳しすぎるとOpenClawは何もできなくなり、使うのが苦痛になります。逆に緩すぎると、防御効果が得られません。
より良い戦略は：最も厳格な状態から始め、段階的に緩和することです。
第1週：完全読み取り専用モード
デプロイ初期は、まず読み取り専用モードでOpenClawの挙動を観察します：
tools:
allowlist:
- "read_file"
- "web_search"
- "git_log" # Git操作は読み取りのみ
filesystem:
defaultPermission: "readonly"
writablePaths: [] # 書き込み完全禁止この1週間は何をしますか？観察です。
- OpenClawが頻繁にアクセスするファイルは何か
- ログに不審な活動はないか
- どんなツールを呼び出しがちか
- プロンプトインジェクションをテストすると何が起きるか（安全な環境で）
この1週間が平穏無事なら、基本設定に問題はありません。異常（頻繁に .ssh ディレクトリへのアクセスを試みるなど）が見つかったら、すぐに設定の問題か、誰かが攻撃しているのかを確認してください。
第2週：制限付き書き込みの追加
観察期間が過ぎたら、徐々に書き込み権限を開放します：
filesystem:
writablePaths:
- "/home/clawuser/workspace/temp" # 一時ファイルのみ書き込み許可
tools:
allowlist:
- "write_file" # writablePaths 内に限定
- "git_commit" # コードコミットを許可注意：ここでは一時ディレクトリの書き込み権限のみ開放しました。重要プロジェクトファイルは依然として読み取り専用で、OpenClawは直接変更できません。
利点：AIが誤操作（「プロジェクトをクリーンアップして」を全ファイル削除と解釈するなど）しても、消えるのは一時ファイルだけで、ソースコードは安全です。
第3週以降：必要に応じたツール有効化
実際の使用ニーズに応じて、ツールを段階的に有効化します：
tools:
exec:
enabled: true
sandbox: true
allowCommands:
- "git" # まずgitのみ許可
- "npm test" # テスト実行が必要になったら追加重要な原則：
- 毎回1つの権限のみ緩和する：
exec、browser、write_fileを一気に開放しないでください。問題が起きたとき、どの部分が原因かわからなくなります。 - 緩和後は24時間観察する：監査ログをチェックし、異常行動がないか確認します。
- 問題があれば即ロールバック：不審な活動を発見したら？直前の設定変更を即座に取り消してください。
実例：私の設定の進化
私自身の経験を共有します。
最初は私も一気にやろうとして、公式ドキュメントを参考に「完全セキュリティプラン」を設定しました。結果は？OpenClawは基本的なコード補完すらできませんでした。私が write_file を無効化していたからです。
その後、学習しました：
- 第1週：読み取り専用モードで、ドキュメント検索やコード解説をさせる。問題なし。
- 第2週：
workspace/draftsディレクトリの書き込み権限を開放し、下書きを書かせる。順調。 - 第3週：
gitコマンドを有効化し、コードをコミットさせる。ここで一つ落とし穴が——Gitのユーザー情報を設定し忘れていて、OpenClawのコミットが毎回エラーになりました。修正後はすべて正常。 - 第4週：
npm testを有効化し、ユニットテストを実行させる。これで日常のニーズはほぼ満たされました。
browser と無制限の exec？一度も有効にしたことはなく、必要もありません。
教訓：「安心感」のために全く使わない権限まで設定しようとしないこと。多少面倒でも、オンデマンドで開放する方が良いです。
セキュリティチェックリスト
さて、多くの設定を行いましたが、漏れがないかどう確認すればよいでしょうか？ここにリストを用意しました。デプロイ前にチェックすれば、90%の初歩的ミスを防げます。
デプロイ前チェック（すべてチェック必須）
コンテナセキュリティ：
- 非特権ユーザーを作成済み（コンテナ内はrootではない）
- Docker設定で
no-new-privileges:trueを設定済み - すべてのLinux capabilitiesを削除済み（
cap_drop: ALL） - ルートファイルシステムを読み取り専用に設定済み（
read_only: true） - リソース制限（CPU、メモリ）を設定済み
- OpenClawのsandboxモードを有効化済み
身元認証：
- 強力なトークン認証を設定済み（
auth: noneではない） - トークンは十分複雑（32文字以上、ランダム生成）
- トークンは環境変数に保存されており、コード内ではない
- アクセスホワイトリスト（DM/Groupポリシー）を設定済み
- VPSにデプロイする場合、IPホワイトリストを設定済み
権限制御：
- ツールはホワイトリストモードを使用
- 高リスクツール（
exec/browser）を無効化、またはコマンドホワイトリストを設定 - ファイルシステムアクセス制限を設定済み
- 機密ディレクトリ（
.ssh、.awsなど）が禁止リストに入っている - 認証情報ファイルの権限を600に設定
監査と監視：
- 監査ログを有効化
- セッションログを設定
- ログディレクトリに十分なディスク容量がある
- ログの閲覧・分析方法を知っている
実行時チェック（定期実行）
週次チェック：
- 監査ログを確認し、異常活動がないか見る
- リソース使用状況（CPU、メモリ、ディスク）を確認
- 未承認のアクセス試行がないか確認
- 設定ファイルのバックアップ
月次チェック：
- OpenClawを最新バージョンに更新
- トークンのローテーション（長期運用サービスの場合）
- Dockerイメージのセキュリティ脆弱性チェック（
docker scan） - 権限設定を見直し、不要になった権限を削除
緊急対応準備
万が一何かが起きたとき、どうすればいいか知っていますか？
緊急停止スクリプトの準備：
#!/bin/bash
# emergency-stop.sh
echo "OpenClawを緊急停止中..."
# コンテナ停止
docker stop openclaw-safe
# 全トークンの取り消し（動的トークンシステム使用の場合）
# curl -X DELETE https://your-auth-server/tokens/revoke-all
# アラート送信
curl -X POST https://your-webhook-url \
-H "Content-Type: application/json" \
-d '{"text":"OpenClaw has been emergency stopped"}'
echo "停止しました。ログを確認してください: /opt/openclaw/logs/audit.log"トークン漏洩時の対応：
- 漏洩したトークンを即座に取り消す
- 監査ログをチェックし、そのトークンで何が行われたか確認する
- 新しいトークンを生成し、正規ユーザーに更新を通知する
- データ漏洩がある場合、データ漏洩対応プランを開始する
不審な活動を発見した場合：
- サービスをすぐに停止しない（相手に気づかれるため）
- まず現在のログとコンテナのスナップショットを保存する
- ネットワーク接続を切断する
- 分析を行う
トークン漏洩時：
- 漏洩トークンを即失効
- 監査ログで悪用内容を確認
- 新トークンを発行し正当利用者へ通知
- データ漏洩があればインシデント手順を開始
不審な活動を発見した場合：
- すぐ停止しない（証拠保全のため）
- ログとコンテナスナップショットを保存
- 攻撃経路と影響範囲を分析
- 隔離・再起動・再構築を判断
結論
ここまで長く書きましたが、核心は一言です。OpenClaw は強力だが、安全な檻の中で初めて「猛獣」ではなく頼れる助手になるということです。
5 層防御のおさらい：
- Docker サンドボックス隔離：コンテナ内に閉じ、触れるファイルとネットワークを制限
- 非特権ユーザー：侵害されても低権限にとどめる
- アクセス制御：トークン認証とホワイトリストで入口を守る
- ツール権限管理：危険ツールを無効化し、必要最小限だけ許可
- ネットワーク分離と監視：不要な外向き通信を切り、操作を記録
前三層は必須、後二層は機密データや企業運用では強く推奨です。
設定は面倒に感じるかもしれません。「個人利用だから」と思う人もいるでしょう。しかし AI の能力は強すぎます。「プロジェクトを整理して」が「重要ファイルまで削除」に化けることも、.git/config の認証情報を読むことも、悪意ではなく過剰な親切で起きます。
セキュリティ設定は OpenClaw を疑うためではなく、事故の爆発半径を小さくするためです。
最後に 3 つ：
- 今すぐ設定を確認：デフォルトのままなら、少なくとも前三層を実装する
- 厳格から始めて段階的に緩める：読み取り専用で 1 週間観察してから権限を開放
- 監査ログを週 1 回見る：5 分の確認で早期発見につながる
OpenClaw は良いツールです。使い方を間違えなければ、データ漏洩や Reddit での泣き言投稿は防げます。
次に読む
- OpenClaw 初期設定で見落としがちな 5 つのセキュリティスイッチ
- OpenClaw 設定完全ガイド：openclaw.json の徹底解説
- OpenClaw 2026 インストールガイド：個人 AI アシスタントをゼロから
FAQ
v2026.1.29 以前のデフォルト設定はなぜ危険だったのか？
• auth: none で URL を知っただけで制御可能
• サンドボックスなしで ~/.ssh や ~/.aws など全体にアクセス可能
• exec・browser など危険ツールがデフォルト有効
• root 相当で動く可能性があり、侵害時の被害が大きい
v2026.1.29 で auth: none は削除されましたが、サンドボックス・ツール権限・ファイルアクセスは手動設定が必要です。
コンテナ内は非 root でも、ホストで root が docker を起動するのは安全か？
正しい運用：
• ホストに専用低権限ユーザー（clawuser）を作成
• そのユーザーでコンテナを起動
• 設定ディレクトリは chmod 700、認証情報は chmod 600
• パスワードログインはロック（usermod -L）
コンテナ突破後も clawuser 権限にとどめ、システム全体への影響を抑えます。
トークン認証はパスワードより何が優れているか？安全な生成方法は？
• 人／アプリごとに別トークンと権限を付与できる
• 漏洩時は該当トークンのみ失効で済む
• 有効期限を設定しやすい
• 監査ログで操作者を追いやすい
安全な生成：
• openssl rand -base64 32 で 256 ビット相当のランダム文字列
• 32 文字以上、推測困難な文字列
• 環境変数に保存し、設定ファイルへハードコードしない
• 長期運用では月次ローテーションを推奨
ツールはなぜホワイトリストがブラックリストより優れているか？
• 危険コマンドは無限にバリエーションがあり、ブラックリストは抜け道が残る
• rm -rf などは空白や変数で回避されうる
• 許可する安全コマンドは有限で、列挙しやすい
例：
tools:
exec:
enabled: true
sandbox: true
allowCommands:
- "git"
- "npm"
- "yarn"
- "pytest"
- "curl"
新コマンドは明示的に追加するまで実行不可です。
ローカル開発 PC だけの利用でも、ここまで厳しい設定は必要か？
リスク：
• プロンプトインジェクションはリモート不要
• AI の誤解釈で重要ファイル削除
• バックアップ体制が弱い個人環境では復旧が困難
最低限：Docker サンドボックス、非特権ユーザー、トークン認証、ツールホワイトリスト。読み取り専用から段階的に緩めるのが現実的です。
internal: true にしたが Claude API はどう呼ぶか？
1. プロキシコンテナで .anthropic.com などを許可
2. OpenClaw に HTTP_PROXY / HTTPS_PROXY を設定
3. 外向きはプロキシ経由のみ
Claude API は許可ドメインへ到達でき、悪意あるダウンロードはプロキシで遮断。アクセスはログに残せます。本文第 5 層の docker-compose と squid.conf を参照してください。
監査ログで異常とみなすべき行動は？
コマンド：
• sudo、rm -rf、chmod 777 の試行
• 連続する失敗コマンド（権限探索の可能性）
• 深夜帯の不審な実行
ファイル：
• ~/.ssh、~/.aws、/etc/passwd へのアクセス試行
• 短時間の大量読み取り
ネットワーク：
• .onion や Tor 関連
• 未知 IP への大量送信
プロンプト：
• 「以前の制限を無視」「管理者として実行」など
週 1 回、tail -f audit.log | grep -E "(exec|sudo|rm|chmod|.ssh|.aws)" で確認するのがおすすめです。
14分で読めます · 公開日: 2026年2月4日 · 更新日: 2026年6月15日
OpenClaw 導入と実践
検索からこのページに来た場合は、前後の記事もあわせて読むと同じテーマの理解がかなり早く深まります。
前の記事
OpenClaw セキュリティ警告：知っておくべき 5 つのリスク
OpenClaw にはリモートコード実行の脆弱性（CVE-2026-25253）、API キー漏洩、プロンプトインジェクションなど深刻な問題があります。ClawHub の Skills の 12% がマルウェア。本記事では 5 大リスクと実践的な防御策を解説します。
第 7 / 36 記事
次の記事
OpenClaw スキルセキュリティレビュー：悪意ある Agent Skills を5分で見抜く実践ガイド
ClawHavoc インシデントで341個の悪意あるスキルが露見。SKILL.md レビュー、危険な権限の識別、高速チェック用コマンドで、5分以内にスキルの安全性を判断し、開発環境をサプライチェーン攻撃から守る方法を解説します。
第 9 / 36 記事
関連記事
OpenClaw 改名の全貌：Clawdbot から Moltbot、そして OpenClaw への変遷
OpenClaw 改名の全貌：Clawdbot から Moltbot、そして OpenClaw への変遷
OpenClaw 完全インストールガイド：環境準備から初回実行まで
OpenClaw 完全インストールガイド：環境準備から初回実行まで
OpenClaw クラウド vs ローカル：最適なデプロイの選び方
コメント
GitHubアカウントでログインしてコメントできます