清水理史の「AI道場」
「OpenClaw」何が危険か？ 利用者の責任はどこにあるのか？
手軽な導入環境が増えてきたOpenClawのセキュリティを考える
2026年6月11日 12:15
6月に開催されたMicrosoftのBuild 2026で、MXC（Microsoft Execution Containers）によるWindows＋OpenClawのデモも実施されたこともあり、OpenClawへの注目が一層高まっている。実際、NASなどの組み込みデバイスでは、いくつかのメーカーがOpenClawをアプリとして簡単に追加できるようにしており、OpenClawが身近な存在になりつつある。本稿では、OpenClawのセキュリティや運用で協調される「パーソナルアシスタント信頼モデル」を基に、はじめてOpenClawに触れるユーザーが知っておくべき、利用者の責任について解説する。
利用者の判断と設定が重要
最初に断っておくと、OpenClawに関する危険は「利用者の判断と設定」が原因となるケースが多い。
もちろん、CVE-2026-25253で知られるControl UIの認証トークンが漏洩する脆弱性、追加機能を提供するマーケットプレイス「ClawHub」上で実際に提供されていた多数の悪意のあるスキルなど、脆弱性やマルウェアなどを原因とする危険も存在する。
□CVE-2026-25253 Detail
□OpenClaw Partners with VirusTotal for Skill Security
□From Automation to Infection: How OpenClaw AI Agent Skills Are Being Weaponized
しかしながら、脆弱性に関しては、すでにアップデートによって改善されているうえ、ClawHubもセキュリティベンダーとの協力によって対策が進められている。現状、課題になっているのは、むしろ知名度が向上し、簡単にインストールするための環境が整ったことで、最低限の設定のみで、すぐに使える環境が増えている点にある。
手元で検証可能な数台のNASを確認してみたが、アプリとして簡単にインストールできる点は共通だが、単にDockerのコンテナを実行するだけのもの、NASのボリューム全体をDockerに接続しOpenClawの操作対象に含めるもの、NASのホストOS上で直接OpenClawが動作するものなど、さまざまな形態で動作していることが確認できた。
メーカーによって、OpenClaw+NASという設計における自由度とセキュリティのバランスについての考え方が違うため、ここでは、その方法の良し悪しについては語らないが、いずれにせよ、OpenClawを利用する上では、設定を自ら確認し、どのような範囲で、何が許可されているのかを判断しないと、意図しない動作や結果が生じることになりかねない。
ここでは、OpenClawとは何かをおさらいしつつ、OpenClawが強調する「パーソナルアシスタント信頼モデル」という考え方を紹介する。OpenClawを使うかどうかを判断する際、つまりOpenClawをインストールするためのボタンをクリックしたり、スクリプトを実行したりする前に、この基本的な思想というか、セキュリティ方針を理解しておきたい。
OpenClawとは何か？
まずは、簡単にOpenClawについておさらいしておく。OpenClawは、Peter Steinberger氏が生み出した自立型AIエージェントだ。当初は「Clawbot」という名称だったが、「Moltbot」を経て、現在の「OpenClaw」となった。
自分が使っているPCを自律的に制御するAIエージェントで、メールに返信する、ファイルを整理する、コードをレビューするといった幅広いタスクを、TelegramやDiscordなどのメッセージングアプリからの指示で実行できることが話題となり、急速に普及が進んだ。
同様のエージェント型AIは、Claude CodeやClaude Coworkなどが存在するが、OpenClawは、「個人の作業環境そのものを操作できる万能アシスタント」として、幅広い操作対象（ファイルやツール）や権限を与えられた、より自由度の高いAIエージェントである点が特長となる。
実際、開発者のPeter Steinberger氏は、Microsoft Build 2026のステージで、「私はOpenClawをあらゆるものにアクセスできるように作りました」と述べ、その前に実施されたOpenClawがWindowsのデスクトップ上のファイルをすべて削除しようとして失敗したデモについて、「数か月前なら完全にうまくいったでしょう」と冗談交じりに語っている。
□OpenClaw + Windows: Microsoft Build 2026
Windowsネイティブ版のOpenClawがMXC（Microsoft Execution Containers）によって「安全」に使えるようになることは、言わば、ゼロトラストの原則をAIエージェント実行環境に適用したものと言える。MXCは、Windows / WSL上のエージェント向けの「policy-driven execution layer」であり、AIエージェントがアクセスできるファイル、ネットワーク、UI、クリップボードなどをポリシーで定義し、実行時にOS側で強制する。
□Microsoft eXecution Container (MXC)
これは、今後登場予定の組織向けのOpenClawの進化系と言えるが、OpenClawの本質やもともとの根っこの発想は、むしろ、その逆、「あらゆるものにアクセスできる」自由度の高さに他ならない。
このため、OpenClawを利用する際は、この自由度を、誰に対して、どの程度許容するのかをユーザーが判断し、設定する必要がある。前述したNASベンダーによって公開されるフォルダーや実行環境に違いがあるのは、開発者がどのようにOpenClawの自由度をとらえているのかの違いに起因している。
境界を越えたオペレーター＝信頼できるボットオーナー
前述したように、今後、AIエージェントはゼロトラスト的な発想での監視と管理が主流になりそうだが、現状、少なくともユーザーが自ら導入するOpenClawやNASなどに組み込まれたOpenClawアプリは、そうではない。ネットワークで言うところの境界型セキュリティモデルの発想で設計されている。
詳細はOpenClawの公式ドキュメントを読むことをお勧めするが、OpenClawの「パーソナルアシスタント信頼モデル」は、以下のようなセキュリティ境界（ゲートウェイアクセス）によって、信頼できるゾーンと信頼できないゾーンに分かれる境界モデルの発想となっている。
□OpenClawドキュメント：Gateway & Ops Gateway Security
いわば、VPNで組織内ネットワークに接続した端末が社内システムに到達可能になるのと同じように、OpenClawではGatewayに到達し、認証やデバイス確認を通過した呼び出し元が、そのGatewayの「信頼済みオペレーター」として扱われる。
OpenClawのGatewayには、組み込みのControl UI（Web）、Telegramなどのメッセージングアプリ、ローカルでのコマンド操作など、複数の経路からアクセスできるが、ここではわかりやすくWeb版のControl UIを例にしよう。
上図のようにControl UIを、
(1)インターネットを含む広いネットワークやLANに公開すると、Gatewayに到達できる利用者や攻撃者の範囲が広がり、より多くの対象が「信頼済み」となる可能性がある。
(2)Control UIの接続トークンやパスワードを知っている利用者は、そのGatewayのオペレーターとして扱われる可能性があり、これも「信頼済み」として扱われる人が増える。
(3)デバイス認証やブラウザのOrigin制限を緩めたり無効化したりすると、本来は接続を制限すべき端末やブラウザからもControl UIを利用できる可能性が高まり、これまた「信頼済み」が増える結果になる。
つまり、どの範囲に？ 誰に？ どのデバイスに？ という条件を緩めるほど、利便性が上がり、「信頼済みオペレーター」が増える一方で、セキュリティレベルは確実に下がることになる。認証を通過したオペレーターは、誰であろうと、Gatewayに接続されたエージェント、ツール、認証情報、実行環境を、同じ信頼境界の内側から操作する「信頼済み」の立場になる。まずは、この原則を理解することが大切だ。
例えば、OpenClawに関する設定情報は、「~/.openclaw/openclaw.json」に記載されており、このファイルには接続用のトークンや言語モデルを利用するためのAPIキーが平文で記述されている。SecretRefという機能によって、設定ファイル上は資格情報を隠すこともできるが、OpenClawがアクセスできるメモリやファイルのどこかに平文のトークンやAPIキーが格納されていたり、OpenClawが、Gatewayがopenclaw.jsonからSecretRefのトークンやAPIキーを読み取るのと同じツールを使うことができたりすれば、秘匿性が回避される可能性がある。
このように、OpenClawは基本的に信頼境界の内側で強い権限を持って動作することを知る必要がある。そのOpenClawと人間との窓口がGatewayとなるため、ここを保護することがいかに重要かがわかるだろう。
少し話題が外れるが、OpenClawのGatewayは、そもそも相互に信頼していない複数ユーザーを安全に分離するための境界として設計されていない。要するにLAN上の複数のユーザーがGatewayにアクセスするという用途を想定していない。これは上記のドキュメントでも「Warning」に加え、あらゆる部分で何度も登場する文言だ。
これは情報を複数ユーザーで共有することを前提としたNASなどのデバイス上で、アプリとして動作するOpenClawで矛盾を引き起こしかねない。例えば、アクセス権が設定されたユーザーごとの個人フォルダーのデータであっても、OpenClawは管理権限を使って自由にアクセスできてしまう可能性がある。境界を越えたユーザーは誰であろうと信頼済みオペレーターとして扱われるのが原則なので、ユーザーごとのアクセス制御というのは、そもそも設計思想と合っていないことになる。
もちろん、NASベンダーによってなんらかの対策がなされる可能性もあるが、残念ながら筆者がこれまでに見た製品ではそういった工夫はないので、こうしたリスクが発生する可能性があることも理解すべきだ。
OpenClawの影響範囲を把握する
OpenClawを安全に使ううえでは、Gatewayへの入口を絞るだけでなく、OpenClawにどこまでの操作を許可するかを把握しておく必要もある。OpenClawは、ユーザーの代わりに実環境を操作することを前提としたソフトウェアであり、その自由度の高さが大きな特徴でもある。一方で、許可する範囲を広げれば広げるほど、誤操作や設定ミス、脆弱性があった場合の影響範囲も広がる。
この影響範囲は、大きく「権限」、「ファイルシステム」、「ネットワーク」の3つの観点で整理するとわかりやすい。
権限
まず重要なのは、OpenClawがどの権限で動作しているかだ。専用の一般ユーザーで実行している場合、OpenClawが操作できる範囲は基本的にそのユーザーに許された範囲に限られる。
一方、UID=0、つまりrootで実行している場合や、sudo、Dockerソケット、管理者用のAPIキーなどにアクセスできる場合は、実質的にシステム全体へ影響が及ぶ可能性がある。最近のバージョンは危険な指示、例えば「rm -rf 〇〇を実行して」、「〇〇のAPIキーを表示して」などの命令はセーフガードによって拒否されるが、それでも「あらゆるものにアクセスできる」可能性がある点は注意したい。
ファイルシステム
次に、ファイルシステムの範囲である。OpenClawに作業用フォルダーだけを見せる構成であれば、誤ったファイル操作が起きても影響はそのフォルダー内に限定しやすい。これに対して、ユーザーフォルダー全体やNASの共有ボリューム全体を見せる構成では、より多くの情報が影響範囲に入る。
さらに、ネイティブインストールでシステム領域まで操作できる構成では、データだけでなく、OSやサービスの設定そのものにも影響が及ぶ可能性がある。特に、市販NASでは、メーカーや実装方式によって、OpenClawに見せる領域が「作業用フォルダーのみ」、「共有ボリューム全体」、「システムを含むホスト全体」と大きく異なる場合があるため、どの範囲が公開されているのかを確認しておくことが重要だ。
ネットワーク
最後に、ネットワークの影響範囲も無視できない。OpenClawがLAN内の他のPC、NAS、ルーター、仮想マシン、クラウドサービスへ到達できる環境にある場合、万一OpenClawが不適切に操作されたとき、その影響はOpenClawを実行している端末だけにとどまらない可能性がある。たとえば、同一ネットワーク上の管理画面にアクセスできる、SSHで別サーバーへ接続できる、NASやクラウドストレージに認証済みでアクセスできる、といった構成では、横展開のリスクも考慮する必要がある。
こうした影響範囲を狭めるには、OpenClawを専用ユーザーで実行する、見せるフォルダーを限定する、不要な認証情報を置かない、Dockerや仮想マシンで実行環境を分離する、といった対策が有効だ。Gatewayを含めたOpenClaw全体をコンテナやVMに閉じ込める方法もあれば、Gatewayはホスト上で動かしつつ、シェル実行環境やブラウザ操作だけをサンドボックス化する方法もある。さらに、仮想環境やLAN内の他システムへ不要に到達できないよう、ネットワーク分離やファイアウォールで通信先を制限することも検討すべきだ。
ただし、OpenClawをDockerベースのサンドボックスで運用する場合、影響範囲を小さくできる一方で、その安全性はDocker EngineやDocker daemonの設定にも依存する。過去には、Docker Engine 29.3.1未満を対象とするCVE-2026-34040でOpenClawのようなAIエージェント型サンドボックスと組み合わせた攻撃シナリオが示されている。サンドボックス内からDocker APIやDockerソケットへ到達できる構成では、特権コンテナの作成やホストファイルシステムのマウントを通じて、サンドボックス外へ影響が広がる可能性がある点に注意が必要だ。
OpenClawの安全性を考える際には、「使えるかどうか」だけでなく、「問題が起きたときに、どこまで影響が及ぶか」、「他のシステムとの組み合わせに問題がないか」を確認することが欠かせない。OpenClawに与える権限、見せるファイルシステム、到達可能なネットワークを把握し、必要最小限に抑えることが、影響範囲を管理するための基本となる。
安全な設定は無い。危険な設定を避ける
それでは、具体的な設定について見てみよう。ただし、本稿ではリスクを理解してユーザーが自ら利用の可否を判断すべき設定の例を紹介する。OpenClawに関しては「安全」と言い切れる設定が存在しない、というか前述した思想の違いもあるため、自由度と危険の線引きができないため、注意することしかできないためだ。
上記が、よく見かけるOpenClawの設定のうち、注意が必要なものをリストアップしたものだ。OpenClawを利用する際は、必ず~/.openclaw/openclaw.jsonを確認し、こうした設定があるかどうかを確認した方がいい。
これらの設定が危険ということではない。あくまでも、高い自由度を許容しているという点に注意してほしい。セキュリティ境界を越えた信頼できるオペレーターの操作なのだから、むしろ高い自由度を与えたいという場合は合理的な設定だ。
なお、OpenClawには設定をチェックする機能が搭載されている。コンソールで「openclaw security audit --deep」を実行することで、criticalやwarnとして注意すべき設定が表示される。ユーザー自身が理解して設定しているのであれば問題ないが、意図せず設定されている場合は、何の意味がある設定なのか？ どうすべきかを検討すべきだ。
また、以下のようなプロンプトでOpenClaw自身にチェックを依頼することもできる。こうしたシステム調査ができること自体がOpenClawの自由度の高さと信頼済みオペレーターの重要度を示しているとも言えそうだ。
あなた（OpenClaw）が稼働しているこのホストの「読み取り専用セキュリティ自己点検」を実施し、日本語で構造化レポートを返してください。本プロンプトは機種非依存です。パスやポートは決め打ちせず、稼働中のプロセスと設定から自動検出してください。
## 厳守事項（最重要）
- 完全リードオンリー。設定変更・`config set`・`security audit --fix`・ファイル編集・サービス再起動・パッケージ導入を一切しない。
- 秘密の値（APIキー・トークン・パスワード）は絶対に出力しない。存在・保存先パス・件数のみ報告し、値は `<REDACTED>`。
- 結果を外部に送信しない。このチャットに返すだけ（任意で `~/openclaw-selfcheck-<YYYYMMDD>.md` への保存“だけ”は許可。それ以外の書き込み禁止）。
- 確認できない項目は推測せず「不明」と明記。失敗したコマンドはその旨を記録して継続。自分に都合よく「OK」と丸めない。
- コマンドは exec/シェルツールで実行する。
## STEP 0: 環境の自動検出（決め打ち禁止）
稼働中の Gateway プロセスから、実環境・パス・ポートを動的に取得する。
- Gateway プロセス特定: `pgrep -af 'openclaw.*gateway' || ps -eo pid,user,args | grep -i '[o]penclaw'` → その PID を GWPID とする。
- GWPID の実環境を読む: `tr '0' 'n' < /proc/<GWPID>/environ | grep -E '^(OPENCLAW_HOME|HOME|TMPDIR|PATH)='`
- openclaw 実行体: `readlink -f /proc/<GWPID>/exe`（node 実体）、`tr '0' ' ' < /proc/<GWPID>/cmdline`（起動引数）、`command -v openclaw`。
- 以後 CLI を呼ぶ際は検出値を env で補うラッパーを作る（temp dir/PATH 不一致で CLI が起動しない事故を防ぐ）。例:
`OC="env PATH=<検出PATH> HOME=<検出HOME> OPENCLAW_HOME=<検出HOME> TMPDIR=<検出TMPDIR> <openclawの絶対パス>"`
- 設定ファイル: `<OPENCLAW_HOME>/.openclaw/openclaw.json`。無ければ `find / -maxdepth 6 -name openclaw.json 2>/dev/null`。
- Gateway ポート: `$OC config get gateway.port`、または `ss -tlnp | grep <GWPID>`。これを GWPORT とする。
## 点検項目
### 1. 実行環境・コンテナ判定
- `uname -a`; `cat /etc/os-release`; `systemd-detect-virt`; `[ -f /.dockerenv ] && echo container:docker`; `[ -f /run/.containerenv ] && echo container:podman`; `tr '0' 'n' < /proc/1/environ | grep -i '^container='`; `head -3 /proc/1/cgroup`
- → ホスト直インストール / コンテナ内 / VM 内 のいずれかを断定（ブラスト半径の前提）。
### 1b. コンテナ・マウント・権限の精査（コンテナで稼働している場合は必須）
重要: OpenClaw をコンテナ化しても、ホスト/NAS のボリュームを丸ごとマウントしていたり、特権/`docker.sock`/host ネットワークだと、隔離の利点はほぼ失われる。コンテナと判定したら必ずここまで踏み込む。
- ランタイムと識別子:
- `grep -aE 'docker|containerd|kubepods|libpod' /proc/1/cgroup /proc/self/cgroup 2>/dev/null`
- `hostname; cat /etc/hostname; printenv HOSTNAME` … 注: コンテナの“名前”(docker ps の NAME)はコンテナ内部からは原則取得できない。hostname が `--name`/`--hostname` と一致していれば手掛かり。`docker.sock` が見える場合のみ自コンテナ設定を API で引ける。
- マウント精査（最重要）: `findmnt -A 2>/dev/null || cat /proc/self/mountinfo`; `df -h`
- ホスト/NAS のボリューム全体（`/`, `/Volume*`, `/mnt`, `/shares`, 共有ルート等）が rw でバインドされていないか。
- `/var/run/docker.sock` がマウントされていないか（＝ホスト Docker 全権＝コンテナ脱出に直結）。
- ホストの機微パス（`/etc`, `/root`, ホーム, host 側の `/proc`・`/sys`）が見えていないか。
- → 判定を明記: 「コンテナだが NAS ボリューム全体を rw マウント → ファイルシステム上のブラスト半径は NAS 全体。隔離の利点は事実上無効化」。
- 権限・脱出面: `cat /proc/self/status | grep -iE 'CapEff|CapBnd|Seccomp|NoNewPrivs'`（あれば `capsh --print` も）/ `cat /proc/self/uid_map`（user namespace の有無＝コンテナ root がホスト root と同一か）/ `cat /proc/self/attr/current 2>/dev/null`（AppArmor/SELinux 拘束）/ privileged 推定（`/dev` が豊富・`cap_sys_admin` 保持・`/sys` が rw）。
- `/var/run/docker.sock` が見えるなら（読み取りのみ）`docker inspect <自hostname>` 等で Privileged / Binds / NetworkMode を確認。
- ネットワークモード: `--network host` 相当か（`ss -tlnp`/`ip addr` がホストと同一に見えるか）。host ネットなら直公開ポートの評価はホスト同様に厳格化する。
- → 結論: コンテナの「隔離強度」を (1)マウント範囲 (2)実効 capability/privileged (3)docker.sock の有無 (4)network mode (5)userns(コンテナ root ≠ ホスト root か) (6)読取専用 rootfs の6点で評価する。
### 2. バージョン
- `$OC --version`; `node --version`（または STEP0 で得た node 実体）
- → OpenClaw が 2026.1.29 以降（CVE-2026-25253 修正側）か、Node が 22.14.0 以降かを評価。
### 3. 実行権限
- `id`; `id -Gn`（補助グループを全件）; `grep -E '^(Uid|Gid):' /proc/<GWPID>/status`（=Gateway/エージェント実行体の実効 uid/gid）; `sudo -n -l 2>/dev/null`; `echo "$SSH_AUTH_SOCK"`; `ls -la ~/.ssh 2>/dev/null`
- → 実効 uid が 0(root) か、(ALL)ALL や NOPASSWD の sudo が可能か、ssh-agent 転送/鍵の有無。root 相当なら危険度を引き上げる。
### 4. ネットワーク露出（結論まで出す）
- 全待受の列挙と分類: `ss -tlnp` → 各待受を loopback(127.0.0.1/::1) / 0.0.0.0 / `*` / 具体IP に分類。
- OpenClaw 関連の特定: Gateway 本体ポート(GWPORT)と、`*`/0.0.0.0 で開く openclaw 関連の“ブリッジ/コンパニオン”プロセス（プロセス名に openclaw/claw/ベンダー名を含むもの）を洗い出す。これら直公開ポートは、後段の reverse proxy 認証とは別枠で評価する。
- リバースプロキシ探索（機種非依存）:
`grep -rnE 'proxy_pass|auth_request|auth_basic|allow |deny |satisfy' /etc/nginx /etc/nginx/conf.d /etc/nginx/sites-enabled /usr/local/etc/nginx /Volume*/@apps/*/nginx /var/packages/*/etc /etc/apache2 2>/dev/null | grep -iE 'openclaw|:<GWPORT>|1879'`
- **結論づける（重要）**: Gateway/ブリッジへ `proxy_pass` している各 location について、その location（または親 server/include 元）に `auth_request`/`auth_basic`/`allow`-`deny`/`satisfy` の認証ゲートが“実際に掛かっているか”を判定する。ゲートが別ファイル（例: AppAccessControl 等）にある場合は include 関係と location パターンの一致を辿って確認し、「掛かっている / 掛かっていない / 要手動確認」を明記する。直公開ポート（0.0.0.0/`*`）は nginx ゲートの保護外であることも明記。
- ファイアウォール（機種非依存）:
`iptables -S 2>/dev/null`; `nft list ruleset 2>/dev/null`; `command -v ufw && ufw status`; `command -v firewall-cmd && firewall-cmd --list-all`
→ 既定ポリシー(ACCEPT/DROP)と、Gateway/ブリッジ/管理ポートが制限されているかを判定。
- 横展開素地: 22/445/111/2049/3389 等の公開状況、鍵、agent 転送。
- → 最終結論: 「Control UI/Web が LAN もしくは外部から到達可能か」「ホストFWで守られているか」を断定する。
### 5. 設定内容
- 監査: `$OC security audit --deep`（読み取り専用）。**もし missing scope (operator.read) 等で live probe が失敗したら、その旨を明記し、`$OC security audit --json`（静的監査）と下の設定直読で補完する**。in-agent では deep probe が権限不足になりうるため、完全な結果は運用者がサービス環境のシェルから取得するのが確実、と注記すること。
- 主要キーを `config get` で明示取得（dump 任せにしない・値は伏字）:
`bind` / `mode` / `auth.mode` / `controlUi.dangerouslyDisableDeviceAuth` / `controlUi.allowInsecureAuth` / `controlUi.allowedOrigins` / `tailscale.mode` / `sandbox.mode` / `tools.profile` / **`tools.exec.security`** / **`tools.exec.host`** / `tools.elevated` / `plugins.allow` / `dmPolicy` / `groupPolicy` / `channels` / `dangerous*` 系。
例: `$OC config get tools.exec.security; $OC config get tools.exec.host; $OC config get tools.elevated; $OC config get sandbox.mode; $OC config get tools.profile`
### 6. APIキー・秘密の平文
- `$OC secrets audit --check` → 件数と保存先(file:key)のみ。値は絶対に出さない。
- 設定ディレクトリ権限: `ls -la <OPENCLAW_HOME>/.openclaw`（group/world 読み取り可なら指摘）。バックアップ・zip・エクスポート等に平文の複製が無いかも言及。
### 7. プラグイン/拡張
- 有効な拡張の一覧と `plugins.allow` 設定の有無。permissive な tool policy 下で拡張ツールが到達可能かにも触れる。
## レポート形式
- 冒頭に「リスク要約」: P0(即時)/P1(高)/P2(構造) を箇条書き。
- 各項目: 「結果 / 評価(OK・注意・危険) / 根拠(実行コマンド)」。
- ネットワークは必ず「到達可能性の結論」と「認証ゲートの掛かり方」を明示。直公開ポートは別項目で評価。
- 不明・未完了の項目を隠さず列挙する。
- 末尾に「本点検は読み取り専用で、いかなる設定も変更していない」旨を明記。是正案を出す場合は“提案のみ”とし適用しない。
- 評価軸: OpenClaw は『1ホスト=1信頼操作者』の信頼モデルで、本物の境界はホスト/設定/認証/サンドボックス/exec承認にある。露出(Control UI・ネットワーク・直公開ポート)・権限(root か)・秘密の平文・LAN 横展開の可能性を重点的に判定する。コンテナで動いている場合は、マウント範囲（NAS/ホストのボリュームを丸ごと抱えていないか）・特権/capability・docker.sock・network host・userns を“隔離が実効しているかの判定軸”として必ず含める（コンテナでも全ボリュームマウントなら隔離は事実上無効）。
## 自己点検の限界（必読）
AI モデルは「信頼された主体」ではない。自己点検は便利だが、プロンプトインジェクションや整合性のずれにより過少報告・誤判定が起こりうる。最重要の3点 ―― (1)Control UI/ネットワークの外部到達性、(2)実効 uid が 0(root) か、(3)APIキー等の平文残留 ―― は、エージェントの報告を鵜呑みにせず、運用者自身が `ss -tlnp` / `id` / `openclaw secrets audit --check` で独立に裏取りすること。機種が変われば reverse proxy・FW・初期化の流儀も変わるため、検出結果（特に proxy 認証の掛かり方）は必ず手動で再確認する。
使ってみないと理解もできない
以上、OpenClawのセキュリティの基本的な考え方と、注意すべき設定について解説した。もちろん、今回は基本的な設定のみで、スキルなどについて触れていないが、最初の一歩として活用してもらえれば幸いだ。
OpenClawの使い方は人それぞれとなるうえ、求める自由度にも違いがあるので、正直、正解はない。個人的には、Claude Coworkなどではなく、わざわざOpenClawを選ぶのであれば、リスクを取ってでも自由度を上げるべきだと思うが、これは「あらゆるものにアクセスできる」という思想や「パーソナルアシスタント信頼モデル」に同意できるかがカギで、そのための設定も一通り理解しておくのが前提になる。
というわけで、世の中にはワンクリックでOpenClawを導入できる環境も登場しつつあるが、そのワンクリックには結構重いユーザーの責任が含まれることは理解しておきたい。
ただ、使ってみないと何も理解できないし、自分の考えと合っているかも判断できないので、ちょっと使ってみようではなく、本腰を入れて調べてみようという目的で導入してみることをはおすすめする。