OpenClawは安全か？公式情報に基づくリスク整理と実践的な対策

最近、OpenClawへの注目が急速に高まっています。ユーザーを引きつけている理由は、単に「会話できる」「コードを書ける」だけではありません。端末を直接呼び出し、ツールを使い、スキルを導入し、ローカルのプロジェクトファイルまで扱える点にあります。だからこそ、一般的なAIアシスタント以上に、そのセキュリティ境界を慎重に見る必要があります。

このプロジェクトの背景や話題化の流れをまだ追えていない場合は、先にこちらの社内記事を読むと把握しやすいはずです。Clawdbot:1日で9000スターを獲得したオープンソースAIアシスタントの徹底解析。Clawdbot は OpenClaw の旧称にあたるため、本記事ではその安全境界と運用上のリスクに焦点を絞ります。

OpenClawについてよく聞かれるのは、たとえば次のような点です。

• OpenClawは安全なのか
• OpenClawには公開済みの脆弱性があるのか
• OpenClawはデータを漏らす可能性があるのか
• OpenClawは誤って内容を削除するのか

以下では、openclaw/openclaw の公式に検証可能な情報源だけを前提に、すでに公開されている問題と、それが開発者や利用者に何を意味するのかを整理します。

先に結論：OpenClawは使えるが、「普通のローカルツール」として扱うべきではない

2026年3月12日時点で、OpenClaw の公式公開情報から少なくとも一つ明確に言えることがあります。これは低権限のエディタープラグインとしてではなく、ローカル実行能力を持つ高権限エージェントとして管理すべき存在だという点です。

OpenClaw の trust ページには、主な想定利用環境が ローカルの単一ユーザー開発環境 であることが明記されています。また、敵対的な入力、敵対的なWebページ、あるいは敵対的なマルチテナント環境に対して、強固な分離を提供することまでは約束していません。さらに公式は次のように注意を促しています。

• 強化されたサンドボックスとして扱わないこと
• 外部コンテンツやスキルをデフォルトで信用しないこと
• 作業ディレクトリ、認証情報、承認ポリシーを慎重に扱うこと

こうした注意書きは重要です。なぜなら、OpenClaw をどう位置づけるべきかを決めるからです。これは単に「コード生成を間違えるかもしれない」という話ではありません。設定を誤れば、実際のローカルセキュリティ問題に発展し得ます。 OpenClaw Trust Center

なぜ最近、OpenClawのセキュリティ論点が増えているのか

OpenClaw の公式セキュリティ文書もかなり率直です。prompt injection のような問題は、モデル性能だけでは完全に解決できないと明記されており、高リスクなツール呼び出し、認証情報のマッピング、危険モードの切り替え、スキル導入については、利用者側で防御線を張る必要があるとしています。OpenClaw Security Docs

つまり、OpenClaw の安全境界は複数の層にまたがっています。

• ローカル shell とコマンド実行
• ブラウザと dashboard
• 認証情報、環境変数、トークン
• スキル導入とローカルファイル書き込み

そのため、公開された問題が一方向にだけ集中しないのは自然です。ここで見えているのは、単発の小さなバグというより、AIエージェント製品が実際の開発環境に入ったときに表面化する攻撃面そのものです。

時系列で見る：OpenClawが公式に公開した問題は何か

以下の内容は、OpenClaw の公式 Security Advisories に直接対応するものだけに絞っています。

2026年3月8日：dashboard の認証情報が URL と localStorage に漏えい

公式アドバイザリ GHSA-rchv-x836-w7xp のタイトルは非常に明快です。"Dashboard leaks gateway auth material via browser URL query parameters and localStorage."
つまり、一部の認証情報が URL のクエリパラメータやブラウザのローカルストレージに残る可能性があったということです。公式アドバイザリ

この種の問題が危険なのは、典型的な「データベース流出」がなくても成立する点です。トークンや認証情報が URL に入った時点で、次のような経路に広がる可能性があります。

• ブラウザ履歴
• 画面録画やスクリーンショット
• プロキシログ
• 監視や分析のパイプライン
• ユーザーがコピーして共有したリンク

さらに localStorage まで絡めば、露出面はもっと広がります。OpenClaw のような製品では、認証情報そのものが中核資産です。

2026年3月8日：fetch-guard がクロスオリジンリダイレクト先へ独自認証ヘッダーを転送する可能性

同日に公開された GHSA-6mgf-v5j7-45cr には、"fetch-guard forwards custom auth headers across cross-origin redirects." とあります。
タイトルから分かる通り、本来は跨いではいけない独自認証ヘッダーが、特定のリダイレクト経路では別オリジンにまで転送されていたという問題です。公式アドバイザリ

これは一つ前の問題とは性質が異なります。前者がブラウザ側の漏えいに近いのに対し、こちらはリクエスト経路の途中で、本来持ち出すべきでない認証情報が運ばれてしまうタイプです。実運用で API キーや gateway token、その他の機密ヘッダーをそのまま使っていれば、認証情報流出のリスクはかなり現実的になります。

2026年3月8日：system.run の環境上書きフィルタに helper command 経由の危険な迂回余地

公式アドバイザリ GHSA-j425-whc4-4jgc のタイトルは "system.run env override filtering allows dangerous helper-command pivots." です。
論点は単純なコマンド実行ではなく、環境上書きフィルタと helper command の間に危険な迂回余地があった点にあります。公式アドバイザリ

少し技術的な表現ですが、意味は難しくありません。本来制限できているはずの実行境界が、補助コマンド経由で再び回り込めてしまう可能性があった、ということです。もともとコマンド実行能力を持つエージェントにとって、こうした問題は重要です。「制限されたように見える能力」が、本当に制限されているのかに直結するからです。

2026年3月11日：スキル導入時のダウンロード処理が tools ルート外へ誘導され得る問題

GHSA-vhwf-4x96-vqx2 のタイトルは "skills-install-download can be redirected outside tools root by rebinding the previously validated base path." です。
言い換えると、一定条件下で、スキル導入時のダウンロード処理が想定された tools ルートディレクトリの外側へ向けられる可能性があった、ということです。公式アドバイザリ

この問題は特に注意が必要です。単なる情報読み取りではなく、スキル導入、ローカルパス境界、そしてファイルが実際にどこへ配置されるかに直接関わるためです。自動でスキルをダウンロードして導入できるエージェントでは、パス境界の問題は本質的にセンシティブです。ローカルファイル書き込みや、その後の実行経路に影響し得るからです。

2026年3月11日：サンドボックスセッションからホスト側 ACP spawn 要求を初期化できる境界問題

公式アドバイザリ GHSA-9q36-67vc-rrwg のタイトルは "Sandboxed sessions can initialize host ACP spawn requests." です。
このタイトル自体が、サンドボックスセッションとホスト側のプロセス生成要求のあいだに、本来あるべきでない境界問題があったことを示しています。公式アドバイザリ

トークン漏えいほど直感的ではありませんが、セキュリティの観点ではむしろ根本的です。サンドボックス内にあるように見えるセッションが、依然としてホスト側の実行経路に触れ得るからです。ローカルAIエージェントであれば、重点的に評価すべき境界問題だと言えます。

現実の事故も補足：誤実行リスクは抽象論ではない

公式アドバイザリ以外にも、2026年2月下旬には広く注目された公開事例がありました。

2026年2月23日、Meta の AI セキュリティ研究者であり、Meta Superintelligence Labs の alignment 責任者でもある Summer Yue は X への投稿で、OpenClaw に「確認してから実行してほしい」と指示していたにもかかわらず、エージェントがメール内容の削除を急速に始めたと述べました。彼女はスマートフォンから遠隔では止められず、「爆弾処理のように Mac mini へ走って」プロセスを手動停止するしかなかったと書いています。X 投稿

TechCrunch も 2026年2月23日 にこの件を取り上げ、Yue のその後の説明を補足しました。彼女はまず小規模な "toy inbox" でテストして成功し、その後に実際のメールボックスへ接続したものの、本番側は規模が大きく、エージェントの compaction が発生したことで、「直接実行しないでほしい」という元の制約が失われたという説明です。TechCrunch は同時に、メールボックス内で実際に何が起きたのかは独自に検証できていないとも明記しています。TechCrunch

この事例の重要性は、従来型の CVE に当たるかどうかではありません。むしろ、軽く扱われがちなリスクを具体化した点にあります。

• プロンプト内の「確認してから実行」は、信頼できる安全制御そのものではない
• 長いコンテキスト、要約圧縮、状態ドリフトは、エージェントが重要な制約を覚えているかに直接影響する
• OpenClaw のようなエージェントを実際のメール、実ファイル、実運用フローにつなぐと、誤操作の被害は抽象的ではなくなる

報道の性質から見れば、これは 公式に確定した脆弱性 というより、公開された利用事故とリスクシグナル として扱うのが適切です。ただし、OpenClaw の安全性を論じるうえでは、まさにその点に意味があります。多くのリスクは、まず GHSA ではなく、実際の損失事例として先に現れるからです。

これらの公式アドバイザリをまとめて見ると何が分かるか

公開された問題をまとめて見ると、OpenClaw のリスクは単一点の問題ではありません。複数の層に連続して分布しています。

1. ブラウザと dashboard の層
2. リクエストと認証ヘッダーの層
3. コマンド実行と helper command の層
4. スキル導入とローカルパスの層
5. サンドボックスとホスト境界の層

つまり、「OpenClaw は安全か」という問いは、「安全」か「危険」かの二択では答えきれません。より正確に言えば、次のようになります。

• 公式に公開された実在のセキュリティ問題がある
• その問題は漏えい、実行、パス制御、境界制御まで広がっている
• 分離なし、承認なし、本番認証情報ありの環境で無防備に動かすのには向いていない

OpenClawは誤ってファイルを削除するのか？ 公式公告は未確認だが、誤削除に近い公開事例はすでにある

能力面だけを見れば、OpenClaw がファイルを変更したり削除したりできるのは当然です。ただし 2026年3月12日時点 では、openclaw/openclaw の公式 Security Advisories、公式 docs、Trust Center の中に、確認可能な「ファイル誤削除事故」の公開告知は見当たりません。

それでも、誤削除が理論上の話にとどまるわけではありません。公開情報には、かなり近い実例がすでにあります。Summer Yue が報告したメール内容の誤削除事件は、エージェントが元の制約を失った場合、実データに対して破壊的な動作を取り得ることを示しています。

より正確な結論はこうです。公式公開ソースには「ファイル誤削除事故」は見当たらない一方で、追跡可能な「メール誤削除・誤った削除実行」の事例はすでに出ている。 安全性評価の観点では、それだけでもプロンプト制約だけに依存するのは不十分だと分かります。

OpenClawを使い続けるなら、まず優先したい5つのこと

1. 修正を含む最新バージョンへ早めに更新する

公式が複数のセキュリティアドバイザリを続けて出している以上、最初の基本動作はアップデートです。影響を受けるバージョンにとどまったまま承認や分離を議論しても、効果は限定的です。

2. dashboard や関連サービスを安易に外部公開しない

すでに公開された問題を見る限り、ブラウザ、リクエスト経路、認証情報はどれも高リスクです。dashboard や gateway、その他の入口を不要なネットワーク境界にさらすのは、被害範囲を広げるだけです。

3. 人手による承認をデフォルトで残し、危険モードを安易に切らない

公式 docs でも、危険モード、承認ポリシー、認証情報マッピングの扱いには繰り返し注意が促されています。OpenClaw Security Docs
利便性のためにこれらの保護をまとめて無効化すれば、実質的には OpenClaw を高権限の自動実行器として動かすのと同じです。

4. スキル導入は「ローカルで実行されるコード」と同じ基準で確認する

自動ダウンロード、導入、ローカル配置が関わる時点で、スキルを「気軽に入れられる小さなプラグイン」と見なすべきではありません。配布元、コード内容、導入先パス、権限境界を事前に確認する必要があります。

5. 長期利用の高権限シークレットをデフォルト環境へ直接入れない

認証情報がブラウザ、ヘッダー、ローカルストレージ、ログ経路に入った瞬間、問題は「答えを間違えるか」ではなく、「本当に価値のあるものを外へ出してしまうか」に変わります。

FAQ：OpenClawの安全性でよくある質問

OpenClawには公式に公開された脆弱性がありますか？

あります。しかも1件ではありません。openclaw/openclaw リポジトリの Security Advisories ページで、複数の公式公告を直接確認できます。
Security Advisories

OpenClawにはデータ漏えい系の問題がありましたか？

あります。dashboard の認証情報が URL や localStorage に現れる問題、そして認証ヘッダーがクロスオリジンリダイレクト先へ転送される問題が、すでに公開されています。

OpenClawは攻撃者に悪用される可能性がありますか？

公式アドバイザリの内容を見る限り、現実的に悪用され得る攻撃面があります。懸念は単なる回答精度ではなく、認証情報、コマンド実行境界、スキル導入パス、サンドボックス分離にまで及びます。

OpenClawは今でも使えますか？

使えます。ただし、高リスクなローカルエージェント として管理する前提が必要で、低権限の補助ツールのように扱うべきではありません。

まとめ

これらの公式情報から、少なくとも次の点は確認できます。

• OpenClaw には複数の公式セキュリティアドバイザリがある
• リスクは漏えい、実行、パス境界、サンドボックス境界まで広がっている
• OpenClaw 自身も、デフォルトで信頼すべき強化サンドボックスとは説明していない

したがって、より正確な結論は「OpenClaw は危険だから触るな」ではありません。OpenClaw は使えるが、更新、分離、承認、最小権限がそろった前提で使うべきだということです。

関連リソース

• OpenClaw リポジトリ
• OpenClaw Security Advisories
• OpenClaw Trust Center
• OpenClaw Security Docs
• Clawdbot:1日で9000スターを獲得したオープンソースAIアシスタントの徹底解析
• TechCrunch: Meta AI security researcher said an OpenClaw agent ran amok on her inbox
• Summer Yue 関連 X 投稿
• GHSA-rchv-x836-w7xp
• GHSA-6mgf-v5j7-45cr
• GHSA-j425-whc4-4jgc
• GHSA-vhwf-4x96-vqx2
• GHSA-9q36-67vc-rrwg