2026年版 OpenClawは安全？権限リスクと隔離運用の結論

OpenClawをコードリポジトリ、メール、ブラウザー、ターミナルへ接続するなら、最初に確認すべきは「モデルが賢いか」ではなく「何を読めて、何を実行できるか」です。OpenClawは安全？という疑問への結論は、限定した権限と隔離した実行環境を組み合わせれば試せますが、主力Macに広い権限を与えたまま運用するのは避けるべきです。

この記事では、AIエージェントのセキュリティリスクを、提示攻撃、秘密情報の漏えい、プラグイン、Gateway公開の4方向から整理します。主力Mac、コンテナ、独立したクラウドMacの比較表、設定手順、3人チームの模擬事故、2026年7月22日時点のレンタル料金まで確認できます。

OpenClawは安全？最初に判断すべき結論

OpenClawは、ローカル環境で動く個人向けアシスタントとして設計されています。ただし公式のセキュリティ文書も、1つのGatewayを互いに信頼していない複数利用者の境界として使う設計ではないと説明しています。複数人が同じツール付きエージェントへ指示できる場合、全員が同じ委任済み権限を利用できるためです。(docs.openclaw.ai)

つまり、危険性はOpenClaw単体だけで決まりません。次の組み合わせでリスクが増えます。

1. 読み取り範囲がホームディレクトリ全体になっている。
2. system.runなどの端末操作を自動承認している。
3. メールやWebページなど、第三者が内容を変更できる情報を読ませている。
4. APIキーやSSH鍵を同じ作業領域に置いている。
5. Gatewayやブラウザー操作用の接続口を外部へ公開している。

ポイント： OpenClawの安全性は「AIが間違えないこと」ではなく、「間違えても被害範囲を限定できること」で判断します。

なぜ問題はモデルの性能だけではないのか

AIエージェントは、回答を生成するだけのチャットボットとは異なります。ファイルを読む、コードを変更する、コマンドを実行する、ブラウザーを操作する、外部サービスへ送信する、といった行動を組み合わせられます。

この自律操作が、AIエージェントのセキュリティリスクを広げます。悪意のある指示が、利用者の入力ではなく、Webページ、メール、Issue、README、PDF、リポジトリ内のテキストに埋め込まれる可能性があるためです。

研究では、外部コンテンツに含まれた提示攻撃によって、エージェントが本来の作業指示から外れ、個人情報や実行時の文脈を外部へ送信する可能性が示されています。悪意のあるページを読ませるだけで外向き通信を誘発する実験も報告されています。(arxiv.org)

特に危険な権限

・~/全体のファイル読み取り
・.env、SSH鍵、クラウド認証情報へのアクセス
・メール送信や外部APIへの書き込み
・ブラウザーのログイン済みセッション操作
・確認なしのシェル実行
・未知のスキルやプラグインの自動導入
・公開アドレスからのGateway操作

OpenClawのmacOSアプリは、macOSの権限確認、通知、ブラウザー連携、system.runなどのMac上の機能を扱えます。便利な機能ほど、許可した後の被害範囲を先に定義する必要があります。(zovcloud.com)

主力Macに置かないほうがよい利用場面

すべての作業を隔離する必要はありません。重要なのは、データの価値と操作の不可逆性を分けて考えることです。

・個人の空のサンプルリポジトリを要約する
・公開情報だけを検索してメモにまとめる
・テスト用のメールボックスを分類する
・破棄可能なWeb操作を自動化する

この程度なら、専用のmacOSユーザーと限定フォルダーを使えば主力Macでも試せます。一方、次の作業は専用環境を推奨します。

・本番コードや非公開リポジトリを扱う
・個人メールと会社メールを同時に読ませる
・GitHub、クラウド、決済、顧客管理の認証情報を使う
・ログイン済みブラウザーで購入、削除、送信を行う
・複数人が同じAgentへ指示する
・未知のプラグインを導入して機能を増やす

※注意： 「ローカルで動く」ことは「安全」を意味しません。ローカルで動くからこそ、端末内のファイル、ブラウザー状態、認証情報へ近い位置にあります。

主力Mac、コンテナ、独立Macの隔離効果を比較

OpenClawの隔離運用では、必要なmacOS機能があるか、終了後に環境をどこまで消せるか、運用担当者が境界を理解できるかを比較します。

コンテナはファイル処理やAPI検証に向いていますが、macOSアプリ、ログイン済みブラウザー、GUI操作まで必要になると設定が複雑になります。反対に独立Macは、作業用アカウント、ネットワーク、ディスク、ログを一つの検証単位にまとめやすい点が利点です。

ZovCloudのMac mini M4レンタルは、M4 10コア、16GBユニファイドメモリ、256GB NVMe、1Gbps専用帯域、独立パブリックIPv4を標準構成としています。公開料金では東京、ソウル、香港、シンガポール、米国東部の5ノードが同一価格です。(zovcloud.com)

OpenClawの権限設定を最小権限にする手順

ここでは、インストール方法ではなく、接続後に事故を起こしにくくする順番を示します。OpenClawの公式ドキュメントには、設定変更後や外部公開前にopenclaw security auditを実行する手順があります。監査では、受信ポリシー、ツールの影響範囲、ファイル権限、ネットワーク公開、プラグインなどを確認できます。(docs.openclaw.ai)

1. 専用の作業領域を作ります。
   まず、OpenClaw用のディレクトリを1つ作り、公開サンプルやテスト用データだけを置きます。ホームディレクトリ全体、Downloads、Desktop、SSH設定、パスワード保管場所は対象外にします。

2. 初期状態を拒否に寄せます。
   ファイル操作、端末操作、ブラウザー操作、外部送信をすべて有効にするのではなく、必要な機能だけを個別に許可します。公式の強化例でも、作業領域限定、実行拒否、常時確認、特権機能の無効化が基本になっています。(docs.openclaw.ai)

3. 危険な操作は常に承認制にします。
   rm、公開、送信、認証情報の表示、パッケージ導入、Gitの強制操作などは自動実行させません。読み取りと書き込み、可逆操作と不可逆操作を別の許可として扱います。

4. メッセージの受付範囲を絞ります。
   Gatewayを誰でも呼び出せる状態にせず、ペアリングや許可リストを使います。グループチャットでは、メンションがないメッセージを命令として扱わない設定を検討します。

5. 外部公開を避けます。
   Gatewayは可能な限りループバック、または信頼できる閉域接続に限定します。認証トークンを短くしたり、管理画面を公開アドレスへ直接出したりする運用は避けてください。

6. 監査を実行して記録を残します。
   設定変更後にopenclaw security audit、必要に応じて--deepを実行します。指摘されたファイル権限、認証、プラグイン、ブラウザー接続、Gateway公開の項目を修正し、変更日と担当者を記録します。

7. 失敗を前提にテストします。
   「このファイルは読まない」「このコマンドは実行しない」「外部送信は承認なしに行わない」という拒否テストを行います。安全性の確認では、正常に作業できるかだけでなく、悪意のある入力を受けたときに停止できるかが重要です。

詳しい監査項目は、OpenClaw公式のセキュリティガイドで確認できます。macOSの権限を扱う場合は、OS側のプライバシー設定とOpenClaw側の実行ポリシーを別々に確認してください。

ポイント： 「全部許可して、問題が出たら戻す」はAIエージェントでは危険です。最初から読み取り専用、限定フォルダー、常時承認で始めるほうが、原因を追跡しやすくなります。

APIキー、プラグイン、Gatewayで起きる事故

APIキーを設定ファイルへ直書きしない

APIキーをリポジトリ、.env、チャット履歴、Agentの長期メモリへ置くと、読み取り対象になった時点で漏えい経路が生まれます。

・短期間の検証用キーを使う
・権限を読み取り専用にする
・利用上限と送信元制限を設定する
・検証終了時に必ず失効させる
・ログにキーが出ていないか確認する

未知のプラグインをそのまま導入しない

プラグインやスキルは、機能追加であると同時に実行コードの追加です。OpenClawの公式セキュリティ監査でも、プラグインの明示的な許可リストやスキルの導入ポリシーが確認対象になっています。(docs.openclaw.ai)

導入前に、次を確認します。

・提供元と更新履歴
・要求するファイル、端末、ネットワーク権限
・インストール時に実行されるスクリプト
・外部へ送信するデータ
・削除方法と設定ファイルの場所

Gatewayとブラウザー接続を公開しない

Gatewayの認証情報が漏れると、単なるチャット履歴の流出ではなく、委任済みツールの操作へ到達する可能性があります。ブラウザー制御やペアリング済みノードは、実質的にオペレーター権限に近いものとして扱い、外部公開ではなく閉じた接続を優先します。(docs.openclaw.ai)

3人チームの模擬事例：Agentが.envを読んだ場合

ここでは、現場で起こり得る流れを整理した模擬事例です。3人の開発チームが2つのGitHubリポジトリ、共有メールボックス、経費表を1つのAgentへ接続し、作業効率を優先してプロジェクトの親ディレクトリ全体を読み取り対象にしたとします。

1. AgentがIssueとメールを読み込みます。
2. その中に、作業指示に見える隠しテキストが含まれています。
3. Agentが親ディレクトリを検索し、テスト用ではない.envを文脈へ取り込みます。
4. 内容の一部が要約、外部API呼び出し、メール作成の途中で扱われます。
5. チームは後から、どのセッションがどのファイルを読んだか確認します。

この場合、最初に行うべきは原因究明より封じ込めです。

・クラウド、GitHub、メール、決済関連のキーを失効させる
・AgentのGatewayと外部連携を停止する
・アクセスログと実行履歴を保存する
・.env、SSH鍵、個人情報を作業領域から移動する
・3人それぞれの権限と承認経路を分ける
・同じ設定を再利用せず、専用環境を初期化する

復旧に必要な時間は、秘密情報の数、連携サービス、監査ログの有無によって大きく変わります。したがって、事前に正確な工数を断定するのではなく、「キーの一括失効」「環境の破棄」「ログ確認」を短い手順として準備しておくことが現実的です。

隔離試用の料金と、短期レンタルが向くケース

主力Macで試す場合、金銭的な支出は少なく見えます。しかし、設定を戻す時間、開発環境の再構築、認証情報のローテーション、作業停止の影響は見落とされがちです。

2026年7月22日時点で、ZovCloudの公開料金はMac mini M4の独立マシンが日額$19.8、週額$53.5、月額$99.1です。支払い後の開通目安は1〜5分で、専用帯域、独立IPv4、VNCとSSH接続が含まれます。料金や提供条件は変更される可能性があるため、利用前にMacレンタル料金の最新ページを確認してください。(zovcloud.com)

日単位は、未知のプラグインや提示攻撃を短時間で確認したい場合に向いています。1週間なら、設定変更、失敗テスト、キーの交換、チーム内レビューまで行いやすくなります。1か月は、実際の業務フローを限定的に移し、主力Macへ戻すべきか判断する期間です。

※注意： レンタルMacを借りたから自動的に安全になるわけではありません。専用のAppleアカウント、検証用APIキー、限定リポジトリ、閉じたGatewayを組み合わせて、環境全体を試験用に設計してください。

最終判断：主力Macより、まず独立したMacで試す

主力MacでのOpenClaw運用は、すぐに始められる反面、個人の認証情報、仕事のコード、ログイン済みブラウザーが同じ境界に入りやすく、事故後の切り分けと復旧に手間がかかります。コンテナは再作成しやすい一方、macOSのGUIやブラウザー操作を含む検証では設定が複雑になり、実際の利用環境との差も出やすくなります。

そのため、コード、メール、ブラウザー、ターミナルをまとめて試す段階では、主力Macをいきなり開放するより、独立したMacを短期間レンタルするほうが判断しやすいです。日額でプラグイン審査と提示攻撃テストを行い、権限を絞った後に週額、月額へ切り替える流れなら、OpenClawの安全性を確認しながら長期運用の必要性を評価できます。