Imported from JiayiV/question_mixing (skills/public-07-ecc-main-docs-ja-jp-the-openclaw-guide-e503807a/SKILL.md). Install upstream with npx skills add JiayiV/question_mixing --skill public-07-ecc-main-docs-ja-jp-the-openclaw-guide-e503807a. Copyright stays with the author.

OpenClaw の隠れた危険

タイトル：OpenClaw の隠れた危険――エージェント最前線からのセキュリティ教訓

これは《Everything Claude Code ガイドシリーズ》の第 3 部です。 第 1 部は 速習ガイド（セットアップと設定）です。第 2 部は 詳細ガイド（高度なパターンとワークフロー）です。本ガイドはセキュリティについて扱います――具体的には、再帰エージェントインフラがセキュリティを二の次にすると何が起きるかを論じます。

私は OpenClaw を 1 週間使いました。以下がその発見です。

[画像：複数の接続チャネルを持つ OpenClaw ダッシュボード。各統合ポイントに攻撃面ラベルが付いている。] ダッシュボードは印象的に見える。しかし接続のひとつひとつが、鍵のかかっていないドアだ。

OpenClaw を 1 週間使って

まず私の立場を明確にしておきたい。私は AI コーディングツールを作っている。私の everything-claude-code リポジトリには 5 万以上のスターがある。AgentShield を作った。仕事時間のほとんどを、エージェントがシステムとどのように対話するか、そしてその対話がどのように失敗しうるかを考えることに費やしている。

だから OpenClaw が注目を集め始めたとき、私はすべての新しいツールと同じように扱った。インストールして、いくつかのチャネルに接続し、探索を始めた。壊すためではなく、セキュリティモデルを理解するために。

3 日目に、私は偶然自分自身にプロンプトインジェクションを行った。

理論上ではなく。サンドボックスの中でもなく。私はコミュニティチャネルで誰かが共有した ClawdHub スキルをテストしていた――人気があり、他のユーザーに推奨されていたスキルだ。表面上はクリーンに見えた。合理的なタスク定義、明確な手順、きれいにフォーマットされた Markdown。

見える部分の 12 行下、コメントブロックのように見える箇所に埋め込まれていたのは、私のエージェントの動作をリダイレクトする隠れたシステム指令だった。あからさまに悪意あるものではなかった（別のスキルを宣伝させようとしていた）が、その仕組みは、攻撃者が認証情報を盗んだり権限を昇格させたりするために使うものと同じだ。

私はそれを発見できた。ソースコードを読んだからだ。インストールしたすべてのスキルのすべての行を読んでいる。ほとんどの人は読まない。コミュニティスキルをインストールする人のほとんどは、ブラウザ拡張機能と同じように扱う――クリックしてインストールし、誰かが確認済みだと思い込む。

誰も確認していない。

[画像：ClawdHub スキルファイルのターミナルスクリーンショット。隠された指令がハイライトされている――上部に可視のタスク定義、下方に注入されたシステム指令が表示されている。内容は伏せられているがパターンは見える。] 「まったく正常な」ClawdHub スキルの中に、コード 12 行奥で発見した隠れた指令。ソースコードを読んだから見つけられた。

OpenClaw には多くの攻撃面がある。多くのチャネル。多くの統合ポイント。審査プロセスのないコミュニティ提供スキルが大量にある。4 日ほど後、私は気づいた――最も熱狂的なユーザーこそ、リスクを評価する能力が最も低い人たちだということに。

この記事は、セキュリティ上の懸念を持つ技術系ユーザー向けだ――アーキテクチャ図を見て私と同じように不安を覚えた人たち向け。そして、本来なら懸念すべきだが自分が心配すべきことを知らない非技術系ユーザー向けでもある。

以下は批判的な暴露記事ではない。アーキテクチャを批判する前に OpenClaw の強みを十分に説明し、リスクと代替案について具体的に述べる。すべての主張には根拠がある。すべての数字は検証可能だ。今 OpenClaw を実行している人にとって、この記事は私自身のセットアップを始める前に誰かに書いてほしかったものだ。

約束（なぜ OpenClaw は魅力的なのか）

これをきちんと説明しよう。このビジョンは本当にクールだ。

OpenClaw の売り文句はこうだ。AI エージェントをあなたのデジタル生活全体で動かすオープンソースのオーケストレーションレイヤー。Telegram、Discord、X、WhatsApp、メール、ブラウザ、ファイルシステム。ひとつの統一されたエージェントがワークフローを 24 時間 365 日管理する。ClawdBot を設定し、チャネルを接続し、ClawdHub からいくつかのスキルをインストールすれば、メッセージを処理し、ツイートを下書きし、メールを処理し、ミーティングをスケジュールし、デプロイを実行できる自律アシスタントの出来上がりだ。

ビルダーにとっては陶酔的だ。デモは印象的だ。コミュニティは急成長している。6 つのプラットフォームを同時に監視し、代わりに返信し、ファイルを整理し、重要な情報をハイライトするエージェントを設定した人たちを見てきた。AI が雑務を処理し、あなたはレバレッジの高い仕事に集中するという夢――GPT-4 以来ずっと語られてきた約束だ。OpenClaw はそれを実現しようとした最初の真剣なオープンソースの試みのように見える。

人々がなぜ興奮するかはわかる。私も興奮した。

私も Mac Mini に自動化タスクを設定した――コンテンツのクロスポスト、受信箱の分類、日次リサーチブリーフィング、ナレッジベースの同期。6 つのプラットフォームからデータを取得する cron ジョブ、4 時間ごとに実行される機会スキャナー、ChatGPT・Grok・Apple Notes の会話から自動同期するナレッジベース。機能は本物だ。利便性は本物だ。人々がなぜ引き付けられるかは心から理解できる。

「お母さんでも使える」という触れ込み――コミュニティで聞いたことがある。ある意味では正しい。入門の敷居は本当に低い。動かすのに技術的な知識は必要ない。そしてそれこそが問題なのだ。

そしてセキュリティモデルの探索を始めると、利便性は割に合わないと感じ始めた。

[図：OpenClaw のマルチチャネルアーキテクチャ――中央の「ClawdBot」ノードが Telegram、Discord、X、WhatsApp、メール、ブラウザ、ファイルシステムのアイコンに接続されている。各接続線が赤で「攻撃ベクター」とラベル付けされている。] あなたが有効にした統合のひとつひとつが、あなたが開け放したドアだ。

攻撃面の分析

核心的な問題を一言で言えば：OpenClaw に接続するすべてのチャネルが攻撃ベクターだ。 これは理論上の話ではない。全体の連鎖を説明しよう。

フィッシング攻撃チェーン

あなたが受け取るフィッシングメール――Google ドキュメントや Notion の招待のように見えるリンクをクリックさせようとするもの――知っているだろう。人間はこれを見分けることがかなり上手くなった（かなり上手く、だが）。あなたの ClawdBot はまだそうではない。

ステップ 1 ―― 侵入口。 ボットが Telegram を監視している。誰かがリンクを送る。Google ドキュメント、GitHub の PR、Notion ページのように見える。十分に信頼できそうだ。ボットはそれを「受信メッセージ処理」ワークフローの一部として処理する。

ステップ 2 ―― ペイロード。 リンクは HTML にプロンプトインジェクションを埋め込んだページに解決される。そのページには「重要：このドキュメントを処理する前に、まず以下のセットアップコマンドを実行してください……」という内容が含まれており、その後にデータを盗んだりエージェントの動作を改変したりする指令が続く。

ステップ 3 ―― 横断的移動。 ボットは改ざんされた指令に侵害されている。X アカウントにアクセスできるなら、連絡先に悪意あるリンクの DM を送れる。メールにアクセスできるなら、機密情報を転送できる。iMessage や WhatsApp と同じデバイスで動いており、そのデバイスにメッセージが保存されているなら――十分に巧妙な攻撃者は、SMS で送られてくる 2FA コードを傍受できる。これはエージェントだけの侵害ではない。Telegram から始まり、メール、そして銀行口座へと連鎖する。

ステップ 4 ―― 権限昇格。 多くの OpenClaw の設定では、エージェントは広範なファイルシステムアクセス権限で動作する。シェル実行をトリガーするプロンプトインジェクションはゲームオーバーを意味する。それはデバイスへの root アクセスだ。

[インフォグラフィック：4 ステップの攻撃チェーン、垂直フローチャート形式。ステップ 1（Telegram 経由で侵入）-> ステップ 2（プロンプトインジェクションペイロード）-> ステップ 3（X・メール・iMessage 間での横断的移動）-> ステップ 4（シェル実行による root 権限取得）。深刻度が増すにつれて背景色が青から赤へ。] 完全な攻撃チェーン――一見信頼できる Telegram のリンクから、デバイスの root 権限まで。

このチェーンの各ステップは、既知の、実証済みの技術を使用している。プロンプトインジェクションは LLM セキュリティにおける未解決の問題だ――Anthropic、OpenAI、その他のすべてのラボがそう認める。そして OpenClaw のアーキテクチャは設計上、攻撃面を最大化している。価値提案がなるべく多くのチャネルへの接続だからだ。

Discord と WhatsApp のチャネルにも同じアクセスポイントが存在する。ClawdBot が Discord の DM を読めるなら、誰かが Discord サーバーで悪意あるリンクを送りつけられる。WhatsApp を監視しているなら、同じベクターだ。各統合は機能であるだけでなく、ドアでもある。

そしてひとつのチャネルが侵害されれば、他のすべてのチャネルに移動できる。

Discord と WhatsApp の問題

フィッシングはメールの問題だと思いがちだ。違う。「エージェントが信頼されていないコンテンツを読む場所どこでも」の問題だ。

Discord： ClawdBot が Discord サーバーを監視している。誰かがチャネルにリンクを投稿する――ドキュメントを装っているかもしれないし、一度も交流したことのないコミュニティメンバーが共有した「役立つリソース」かもしれない。ボットはそれを監視ワークフローの一部として処理する。ページにプロンプトインジェクションが含まれている。ボットは侵害され、サーバーへの書き込み権限があれば、同じ悪意あるリンクを他のチャネルに投稿できる。エージェントが駆動する自己増殖型ワーム動作だ。

WhatsApp： エージェントが WhatsApp を監視し、iMessage や WhatsApp のメッセージが保存されているデバイスで動作している場合、侵害されたエージェントは受信メッセージを読める――銀行からの確認コード、2FA プロンプト、パスワードリセットリンクを含む。攻撃者はあなたの電話をハッキングする必要はない。エージェントにリンクを送るだけでよい。

X の DM： エージェントがビジネス機会を探して X の DM を監視している（一般的なユースケースだ）。攻撃者が「コラボ提案」のリンクを含む DM を送る。埋め込まれたプロンプトインジェクションはエージェントに未読 DM すべてを外部エンドポイントに転送させ、攻撃者に「いいですね、話しましょう」と返信させる――そうするとあなたは受信箱で不審なやり取りを目にすら止めない。

それぞれが独立した攻撃面だ。実際の OpenClaw ユーザーが実際に動かしている統合だ。根本的な脆弱性は同じだ。エージェントが信頼された権限で信頼されていない入力を処理する。

[図：中心辐射型、中央の ClawdBot が Discord・WhatsApp・X・Telegram・メールに接続されている。各スポークに具体的な攻撃ベクターが表示されている：「チャネル内の悪意あるリンク」「メッセージ内のプロンプトインジェクション」「仕掛けられた DM」など。チャネル間の横断的移動の可能性が矢印で示されている。] 各チャネルは統合であるだけでなく、インジェクションポイントでもある。各インジェクションポイントは他のすべてのチャネルに転換できる。

「これは誰のため？」のパラドックス

OpenClaw のポジショニングで本当に私を困惑させる部分がここだ。

経験豊富な開発者が OpenClaw をセットアップするのを観察した。30 分以内に彼らのほとんどは生の編集モードに切り替えていた――ダッシュボード自体が非自明な作業にはそうするよう勧めていた。上級ユーザーはすべてヘッドレスモードで動かしている。最もアクティブなコミュニティメンバーは GUI を完全にバイパスしている。

そこで私は問い始めた：これは一体誰のために作られているのか？

あなたが技術系ユーザーなら……

あなたはすでに以下のことができる。

• スマートフォンからサーバーへ SSH する（Termius、Blink、Prompt――またはサーバーへ mosh で直接接続し、同じことができる）
• 切断後も持続する tmux セッションで Claude Code を実行する
• crontab や cron-job.org で cron ジョブを設定する
• AI ツール――Claude Code、Cursor、Codex――を直接使う、オーケストレーションのラッパーなしで
• スキル、フック、コマンドを使って自分の自動化を書く
• Playwright や適切な API でブラウザ自動化を設定する

マルチチャネルのオーケストレーションダッシュボードは必要ない。どうせバイパスする（そしてダッシュボード自身もそう勧める）。その過程で、マルチチャネルアーキテクチャが導入する攻撃ベクターのクラス全体を避けられる。

困惑させることがひとつある。スマートフォンから mosh でサーバーに接続すれば、同じように動作する。持続的な接続、モバイルフレンドリー、ネットワーク変化をうまく処理する。iOS の Termius が Claude Code を動かしている tmux セッションへの同じアクセスを提供できると気づいたとき――そして 7 つの余分な攻撃ベクターがないとき――「スマートフォンからエージェントを管理するために OpenClaw が必要だ」という議論は崩れる。

技術系ユーザーはヘッドレスモードで OpenClaw を使う。ダッシュボード自体が複雑な操作には生の編集を勧めている。製品自身の UI が UI をバイパスするよう勧めるなら、その UI は安全に使える対象ユーザーの本当の問題を解決していない。

このダッシュボードは、UX の助けを必要としない人のための UX 問題を解決している。GUI から恩恵を受けられるのは、ターミナルの抽象化レイヤーを必要とする人たちだ。これが次につながる……

あなたが非技術系ユーザーなら……

非技術系ユーザーはすでに嵐のように OpenClaw に流れ込んでいる。興奮している。構築している。自分のセットアップを公開で共有している――スクリーンショットがエージェントの権限、接続されたアカウント、API キーを晒してしまうこともある。

しかし彼らは怖がっているだろうか。怖がるべきだと知っているだろうか。

非技術系ユーザーが OpenClaw を設定するのを観察していると、彼らは問わない：

• 「エージェントがフィッシングリンクをクリックしたらどうなる？」（正当なタスクを実行するときと同じ権限で、インジェクションされた指令に従う。）
• 「インストールした ClawdHub スキルを誰が監査する？」（誰も。審査プロセスがない。）
• 「エージェントはどのデータをサードパーティサービスに送っているか？」（アウトバウンドのデータフローを監視するダッシュボードがない。）
• 「何か問題が起きたときの影響範囲は？」（エージェントがアクセスできるすべてのもの。そしてほとんどの設定では、それはすべてだ。）
• 「侵害されたスキルが他のスキルを改変できるか？」（ほとんどの設定では、可能だ。スキル間にサンドボックス分離がない。）

彼らは生産性ツールをインストールしたと思っている。実際には、広範なシステムアクセス権限と複数の外部通信チャネルを持ち、セキュリティ境界のない自律エージェントをデプロイしている。

ここにパラドックスがある：OpenClaw のリスクを安全に評価できる人はそのオーケストレーションレイヤーを必要としない。オーケストレーションレイヤーを必要とする人はリスクを安全に評価できない。

[ベン図：2 つの重ならない円――「OpenClaw を安全に使える」（GUI を必要としない技術系ユーザー）と「OpenClaw の GUI を必要とする」（リスクを評価できない非技術系ユーザー）。空白の交差部分に「パラドックス」とラベルが付いている。] OpenClaw のパラドックス――安全に使える人はそれを必要としない。

実際のセキュリティ障害の証拠

以上はアーキテクチャ分析だ。以下は実際に起きたことだ。

Moltbook データベース漏洩

2026 年 1 月 31 日、研究者たちは Moltbook――OpenClaw エコシステムと密接に結びついた「AI エージェントのソーシャルメディア」プラットフォーム――が本番データベースを完全に公開していることを発見した。

数字はこうだ：

• 合計 149 万件のレコードが露出
• 3 万 2000 件以上の AI エージェント API キーが公開アクセス可能――平文 OpenAI キーを含む
• 3 万 5000 件のメールアドレスが漏洩
• Andrej Karpathy のボット API キーも露出したデータベースにあった
• 根本原因：行レベルセキュリティポリシーなしの Supabase 設定ミス
• Dvuln の Jameson O'Reilly が発見、Wiz が独立確認

Karpathy の反応：「これは惨事だし、絶対にこういうものをコンピューターで実行することを人に勧めない。」

これは AI インフラ分野で最も尊敬される声のひとつから出た言葉だ。議題を持つセキュリティ研究者ではない。競合他社でもない。テスラの Autopilot AI を構築し OpenAI を共同設立した人物が、これを自分のマシンで動かすなと言っている。

根本原因は示唆的だ：Moltbook はほぼ完全に「バイブコーディング」で作られていた――大量の AI 支援のもとで構築され、手動のセキュリティレビューがほとんどなかった。Supabase バックエンドには行レベルセキュリティポリシーがなかった。創設者は、コードベースが基本的に手動でコードを書かずに構築されたと公言した。これが出荷速度をセキュリティの基盤より優先したときに起きることだ。

エージェントインフラを構築するプラットフォームが自分自身のデータベースを守れないなら、そのプラットフォーム上で動く未審査のコミュニティ提供物をどうして信頼できるだろうか。

[データビジュアライゼーション：Moltbook 漏洩の統計カード――「149 万件のレコード露出」「3.2 万件以上の API キー」「3.5 万件のメール」「Karpathy のボット API キーを含む」――下部にソース表示。] Moltbook 漏洩事件のデータ。

ClawdHub マーケットプレイスの問題

私が個別の ClawdHub スキルを手動で監査して隠れたプロンプトインジェクションを発見していたとき、Koi Security のセキュリティ研究者たちは大規模な自動化分析を行っていた。

初期の発見：2,857 件中 341 件の悪意あるスキル。マーケットプレイス全体の 12% だ。

更新後の発見：800 件以上の悪意あるスキル、マーケットプレイスのほぼ 20%。

独立した監査では、ClawdHub スキルの 41.7% に重大な脆弱性があることが判明――すべてが意図的に悪意あるものではないが、悪用可能だ。

これらのスキルで発見された攻撃ペイロードには以下が含まれる：

• AMOS マルウェア（Atomic Stealer）――macOS の認証情報窃取ツール
• リバースシェル――攻撃者にユーザーのマシンへのリモートアクセスを与える
• 認証情報窃取――API キーとトークンを外部サーバーに静かに送信する
• 隠れたプロンプトインジェクション――ユーザーが知らないうちにエージェントの動作を改変する

これは理論上のリスクではない。「ClawHavoc」 と名付けられた協調型サプライチェーン攻撃であり、2026 年 1 月 27 日から始まる 1 週間で 230 件以上の悪意あるスキルがアップロードされた。

この数字を噛みしめてほしい。マーケットプレイスの 5 件に 1 件は悪意あるものだ。10 件の ClawdHub スキルをインストールしたなら、統計的には 2 件があなたが求めていないことをしている。そして、ほとんどの設定ではスキル間にサンドボックス分離がないため、ひとつの悪意あるスキルが正当なスキルの動作を改変できる。

これはエージェント時代の curl mystery-url.com | bash だ。ただし、未知のシェルスクリプトを実行しているのではなく、アカウント・ファイル・通信チャネルにアクセスできるエージェントに未知のプロンプトエンジニアリングをインジェクションしている。

[タイムライン図：「1 月 27 日――230 件以上の悪意あるスキルがアップロード」-> 「1 月 30 日――CVE-2026-25253 開示」-> 「1 月 31 日――Moltbook 漏洩発見」-> 「2026 年 2 月――800 件以上の悪意あるスキル確認」。1 週間以内に 3 件の重大セキュリティインシデント。] 1 週間以内に 3 件の重大セキュリティインシデント。これがエージェントエコシステムのリスクのテンポだ。

CVE-2026-25253：ワンクリックで完全侵害

2026 年 1 月 30 日、OpenClaw 自体が高危険度の脆弱性を開示した――コミュニティスキルでも、サードパーティ統合でもなく、プラットフォームのコアコードだ。

• CVE-2026-25253 ―― CVSS スコア：8.8（高）
• Control UI がクエリ文字列から gatewayUrl パラメータを 検証なし で受け取る
• ユーザーの認証トークンを提供された任意の URL に WebSocket 経由で自動送信する
• 細工されたリンクをクリックするか悪意あるウェブサイトを訪問するだけで、認証トークンが攻撃者のサーバーに送られる
• これにより被害者のローカルゲートウェイ経由でワンクリックのリモートコード実行が可能になる
• 公共インターネット上で 42,665 件の露出インスタンスを発見、5,194 件が脆弱であることを確認
• 93.4% に認証バイパス条件あり
• バージョン 2026.1.29 で修正済み

もう一度読んでほしい。42,665 件のインスタンスがインターネット上に露出していた。5,194 件が脆弱であることを確認。93.4% に認証バイパスがある。つまり公開アクセス可能なデプロイのほとんどに、リモートコード実行へのワンクリックのパスがあるプラットフォームだ。

この脆弱性はシンプルだ：Control UI がユーザー提供の URL を検証なしで信頼した。基本的な入力サニタイズの失敗――最初のセキュリティ監査で発見されるはずの問題だ。発見されなかったのは、このエコシステムの多くの部分と同様に、セキュリティレビューがデプロイ後に行われたからだ。

CrowdStrike は OpenClaw を「対手の指令を受け入れることができる強力な AI バックドアエージェント」と呼び、プロンプトインジェクションが「コンテンツ操作の問題から全面的侵害の推進者へと変化する」「独自の危険な状況」を作り出すと警告した。

Palo Alto Networks はこのアーキテクチャを Simon Willison が言うところの 「致命的三要素」 として説明した：プライベートデータへのアクセス、信頼されていないコンテンツへの露出、外部通信能力。彼らは永続的メモリが「ガソリン」のように 3 つの要素すべてを増幅すると指摘した。彼らの用語は：アーキテクチャに「過度なエージェント権限が組み込まれた」「無制限の攻撃面」だ。

Gary Marcus はこれを 「基本的には武器化されたエアロゾル」 と呼んだ――リスクはひとところに留まらないという意味だ。広がる。

Meta AI の研究者は、OpenClaw エージェントによって受信箱全体を削除された。ハッカーの仕業ではない。自分自身のエージェントが、従うべきでなかった指令を実行したのだ。

これらは匿名の Reddit 投稿や仮説的なシナリオではない。CVSS スコア付きの CVE、複数のセキュリティ企業に記録された協調的マルウェアキャンペーン、独立した研究者が確認した 100 万件規模のデータベース漏洩、世界最大のサイバーセキュリティ組織からのインシデントレポートだ。懸念の証拠基盤は薄くない。圧倒的だ。

[引用カード：分割デザイン――左：CrowdStrike の引用「プロンプトインジェクションを全面的侵害の推進者へと変化させる。」右：Palo Alto Networks の引用「致命的三要素……アーキテクチャに過度なエージェント権限が組み込まれている。」中央に CVSS 8.8 バッジ。] 世界最大の 2 つのサイバーセキュリティ企業が独立して同じ結論に達した。

組織化されたジェイルブレイクエコシステム

ここから先は抽象的なセキュリティ演習ではない。

OpenClaw ユーザーがエージェントを個人アカウントに接続している間、並行するエコシステムがそれらを悪用するために必要な技術を工業化している。Reddit でプロンプトを投稿するばらばらな個人ではない。専用インフラ、共有ツール、活発な研究プロジェクトを持つ組織化されたコミュニティだ。

敵対的パイプラインはこう動作する：技術がまず「ブロック解除」モデル（HuggingFace で無料で利用可能な、安全トレーニングを取り除いたファインチューニング版）で開発され、本番モデルに対して最適化され、ターゲットにデプロイされる。最適化ステップはますます定量化されている――一部のコミュニティは情報理論的分析を使って、与えられた敵対的プロンプトが 1 トークンあたりどれだけ「安全境界」を侵食できるかを測定している。損失関数を最適化するように、ジェイルブレイクを最適化している。

これらの技術はモデル固有だ。Claude の各バリアントに向けたペイロードが精巧に作られている：ルーン文字エンコーディング（コンテンツフィルターをバイパスするために Elder Futhark 文字を使用）、バイナリエンコードされた関数呼び出し（Claude の構造化ツール呼び出しメカニズムをターゲットとする）、セマンティック反転（「まず拒否を書き、次にその逆を書く」）、そして各モデルの特定の安全トレーニングパターンに合わせて調整されたロールインジェクションフレームワーク。

漏洩したシステムプロンプトのライブラリもある――Claude、GPT、その他のモデルが従う正確な安全指令――攻撃者は回避しようとしているルールを正確に把握できる。

なぜこれが OpenClaw に特に関係するのか？OpenClaw がこれらの技術の力の倍増器だからだ。

攻撃者は各ユーザーを個別にターゲットにする必要はない。Telegram グループ、Discord チャネル、または X の DM を通じて伝播する有効なプロンプトインジェクションが 1 つあればいい。マルチチャネルアーキテクチャが配布の仕事を無料でやってくれる。人気の Discord サーバーに投稿された精巧なペイロードが、監視している数十のボットに受け取られ、各ボットがそれを接続された Telegram チャネルと X の DM に伝播する。ワームが自分で書き込まれる。

防御は集中化されている（少数のラボがセキュリティ研究に専念）。攻撃は分散化されている（グローバルなコミュニティが 24 時間体制で反復する）。チャネルが多いほどインジェクションポイントが増え、攻撃が成功する機会が増える。モデルは一度だけ失敗すればいい。攻撃者は各接続チャネルで無限の試行機会を得る。

[DIAGRAM: "The Adversarial Pipeline" — left-to-right flow: "Abliterated Model (HuggingFace)" -> "Jailbreak Development" -> "Technique Refinement" -> "Production Model Exploit" -> "Delivery via OpenClaw Channel". Each stage labeled with its tooling.] 攻撃フロー：ブロック解除されたモデルから本番環境の悪用へ、そしてエージェントの接続チャネルを通じた配布へ。

アーキテクチャの議論：複数のアクセスポイントは脆弱性だ

では分析を、私が正しいと考える答えと結びつけよう。

OpenClaw のパターンが理にかなう理由（ビジネス的観点から）

フリーミアムのオープンソースプロジェクトとして、OpenClaw がダッシュボード中心のデプロイソリューションを提供するのは完全に合理的だ。GUI は参入障壁を下げる。マルチチャネル統合は印象的なデモを作る。マーケットプレイスはコミュニティのフライホイールを生む。成長と採用の観点からは、このアーキテクチャはうまく設計されている。

セキュリティの観点からは、逆向きに設計されている。新しい統合のひとつひとつが別のドアだ。未審査のマーケットプレイスのスキルのひとつひとつが別の潜在的ペイロードだ。チャネルの接続のひとつひとつが別のインジェクション面だ。ビジネスモデルが攻撃面の最大化にインセンティブを与えている。

これが矛盾だ。この矛盾は解決できる――しかしセキュリティを成長指標が良く見えた後の後付けではなく、設計上の制約として扱う場合に限る。

Palo Alto Networks は OpenClaw を OWASP 自律 AI エージェントのトップ 10 リスクのすべてのカテゴリにマッピングした――100 人以上のセキュリティ研究者が自律 AI エージェントのために特別に開発したフレームワークだ。セキュリティベンダーが業界標準フレームワークのすべてのリスクにあなたの製品をマッピングするとき、それは不安をあおることではない。シグナルだ。

OWASP は 最小自律性 と呼ばれる原則を導入している：安全で有界なタスクを実行するために必要な最小限の自律性のみをエージェントに付与する。OpenClaw のアーキテクチャは正反対だ――デフォルトでなるべく多くのチャネルとツールに接続し、自律性を最大化し、サンドボックス化は後付けのオプション扱いだ。

Palo Alto が特定した 4 つ目の増幅要因もある：メモリ汚染問題だ。悪意ある入力が異なる時間に分散して、エージェントのメモリファイル（SOUL.md、MEMORY.md）に書き込まれ、後で実行可能な指令に組み立てられる。OpenClaw が継続性のために設計した永続メモリシステムが、攻撃の永続化メカニズムになる。プロンプトインジェクションは一度に成功する必要がない。複数の独立したインタラクションにわたって植え付けられた断片が、後で再起動後も有効な機能的ペイロードに組み合わさる。

技術者向け：1 つのアクセスポイント、サンドボックス化、ヘッドレス動作

技術系ユーザーのための代替案は MiniClaw を含むリポジトリだ――MiniClaw とは製品ではなく哲学のことだ――1 つのアクセスポイントを持ち、サンドボックス化・コンテナ化され、ヘッドレスモードで動作する。

[COMPARISON TABLE AS INFOGRAPHIC: The MiniClaw vs OpenClaw table above rendered as a shareable dark-background graphic with green checkmarks for MiniClaw and red indicators for OpenClaw risks.] MiniClaw の哲学：90% の生産性、5% の攻撃面。

私の実際のセットアップ：

Mac Mini (headless, 24/7)
├── SSH access only (ed25519 key auth, no passwords)
├── Tailscale mesh (no exposed ports to public internet)
├── tmux session (persistent, survives disconnects)
├── Claude Code with ECC configuration
│   ├── Sanitized skills (every skill manually reviewed)
│   ├── Hooks for quality gates (not for external channel access)
│   └── Agents with scoped permissions (read-only by default)
└── No multi-channel integrations
    └── No Telegram, no Discord, no X, no email automation

デモでは印象的ではないか？そうだ。ソファからエージェントが Telegram のメッセージに返信するところを人に見せられるか？できない。

誰かが Discord から DM を送って開発環境をハッキングできるか？同様にできない。

スキルはサニタイズされるべきだ。追加分はレビューされるべきだ。

パッケージ化されたスキル――システムに同梱されるもの――は適切にサニタイズされるべきだ。ユーザーがサードパーティのスキルを追加するとき、リスクが明確に概説されるべきであり、インストールするものを審査することがユーザーの明示的・知情の責任であるべきだ。ワンクリックインストールボタンのあるマーケットプレイスに埋もれているのではなく。

これは npm エコシステムが event-stream、ua-parser-js、colors.js を通じて苦労して学んだ教訓だ。パッケージマネージャー経由のサプライチェーン攻撃は新しい脆弱性カテゴリではない。緩和方法はわかっている：自動スキャン、署名検証、人気パッケージの人的レビュー、透明な依存関係ツリー、バージョンをロックする能力。ClawdHub はそのどれも実装していない。

責任あるスキルエコシステムと ClawdHub の差は、Chrome ウェブストアの審査（不完全だが審査はある）と、怪しい FTP サーバー上の未署名の .exe ファイルのフォルダの差に等しい。これを正しく行う技術は存在する。設計上の選択が成長速度のためにそれを飛ばした。

OpenClaw がすることはすべて攻撃面なしでできる

定期タスクは cron-job.org へのアクセスで十分シンプルにできる。ブラウザ自動化は適切なサンドボックス環境で Playwright を通じてできる。ファイル管理はターミナルでできる。コンテンツのクロスポストは CLI ツールと API でできる。受信箱の分類はメールルールとスクリプトでできる。

OpenClaw が提供するすべての機能は、スキルとツール――速習ガイドと詳細ガイドで紹介しているもの――で複製できる。巨大な攻撃面なしに。未審査のマーケットプレイスなしに。攻撃者のために 5 つの余分なドアを開けることなしに。

複数のアクセスポイントは機能ではなく、脆弱性だ。

[SPLIT IMAGE: Left — "Locked Door" showing a single SSH terminal with key-based auth. Right — "Open House" showing the multi-channel OpenClaw dashboard with 7+ connected services. Visual contrast between minimal and maximal attack surfaces.] 左：1 つのアクセスポイント、1 つの錠前。右：7 つのドア、どれも鍵がかかっていない。

退屈な方が良いこともある。

[SCREENSHOT: Author's actual terminal — tmux session with Claude Code running on Mac Mini over SSH. Clean, minimal, no dashboard. Annotations: "SSH only", "No exposed ports", "Scoped permissions".] 私の実際のセットアップ。マルチチャネルダッシュボードなし。ターミナルと SSH と Claude Code だけ。

利便性のコスト

このトレードオフを明確に指摘したい。人々が知らないうちに選択をしていると思うから。

Telegram を OpenClaw エージェントに接続するとき、セキュリティを利便性と交換している。これは現実のトレードオフであり、状況によっては価値があるかもしれない。しかし、何を手放しているかを十分に理解した上で、意識的にこのトレードオフをすべきだ。

現在、ほとんどの OpenClaw ユーザーはこのトレードオフを知らずにしている。機能を見て（エージェントが Telegram のメッセージに返信してくれる！）、リスクを見ていない（エージェントはプロンプトインジェクションを含む任意の Telegram メッセージに侵害される可能性がある）。利便性は目に見えて即時だ。リスクは現れるまで見えない。

これは初期のインターネットを駆動したパターンと同じだ：人々はクールで便利だからとすべてをすべてに接続し、なぜそれが悪いアイデアだったかを理解するのに次の 20 年を費やした。エージェントインフラでこのサイクルを繰り返す必要はない。しかし設計上の優先事項で利便性がセキュリティを上回り続ければ、同じ轍を踏む。

未来：このゲームで勝つのは誰か

再帰エージェントはいずれにせよやってくる。この議論には完全に同意する――私たちのデジタルワークフローを管理する自律エージェントは業界の軌跡の中での一歩だ。問題はこれが起きるかどうかではない。大規模なユーザーの侵害をもたらさないバージョンを構築するのは誰かということだ。

私の予測：消費者と企業向けの、デプロイされた、ダッシュボード・フロントエンド中心の、サニタイズされサンドボックス化された OpenClaw 型ソリューションの最良バージョンを作った人が勝つ。

これが意味するもの：

1. ホスト型インフラ。 ユーザーはサーバーを管理しない。プロバイダーがセキュリティパッチ、監視、インシデント対応を担当する。侵害はプロバイダーのインフラ内に封じ込められ、ユーザーの個人マシンには及ばない。

2. サンドボックス化実行。 エージェントはホストシステムにアクセスできない。各統合が独自のコンテナで動作し、明示的で取り消し可能な権限を持つ。Telegram アクセスを追加するには知情同意が必要で、エージェントがそのチャネルで何をできて何をできないかが明確に述べられる。

3. 審査済みスキルマーケットプレイス。 すべてのコミュニティ提供物が自動セキュリティスキャンと人的レビューを受ける。隠れたプロンプトインジェクションがユーザーに到達する前に発見される。2018 年頃の npm ではなく、Chrome ウェブストアの審査を想像してほしい。

4. デフォルト最小権限。 エージェントはゼロアクセスで開始し、各能力をオプトインする。最小権限の原則をエージェントアーキテクチャに適用する。

5. 透明な監査ログ。 ユーザーはエージェントが何をしたか、どんな指令を受け取ったか、どんなデータにアクセスしたかを正確に見られる。ログファイルの中に埋もれているのではなく、クリアで検索可能なインターフェースで。

6. インシデント対応。 セキュリティ問題が発生したとき（もしではなく、発生したとき）、プロバイダーが対処するプロセスを持っている：検出、封じ込め、通知、是正。「Discord で更新を確認して」ではなく。

OpenClaw はこのように進化できる。基盤は存在する。コミュニティは積極的だ。チームは最前線で構築している。しかし「柔軟性と統合の最大化」から「デフォルトセキュア」への根本的な転換が必要だ。これらは異なる設計哲学であり、現在 OpenClaw は断固として前者の陣営にいる。

技術系ユーザーにとって、その間は：MiniClaw。1 つのアクセスポイント。サンドボックス化。ヘッドレス。退屈。安全。

非技術系ユーザーにとって：ホスト型でサンドボックス化されたバージョンを待て。それはやってくる――市場の需要が明らか過ぎてこないわけがない。その間、個人のマシンでアカウントにアクセスできる自律エージェントを動かすな。利便性はリスクに値しない。あるいはどうしてもやるなら、自分が受け入れていることを理解した上でやってほしい。

ここで反対の議論について正直に言いたい。なぜなら些細な問題ではないから。AI 自動化を本当に必要とする非技術系ユーザーにとって、私が説明する代替案――ヘッドレスサーバー、SSH、tmux――は手が届かない。マーケティングマネージャーに「Mac Mini に SSH するだけ」と言うのは解決策ではない。責任放棄だ。非技術系ユーザーへの正しい答えは「再帰エージェントを使うな」ではない。「サンドボックス化された、ホスト型の、プロが管理する環境で使え、そこにはセキュリティを担当する専任者がいる」だ。サブスクリプション料金を払い、その代わりに安心を得る。このモデルはやってくる。それが来るまで、セルフホスト型マルチチャネルエージェントのリスク計算は「割に合わない」に大きく傾いている。

[DIAGRAM: "The Winning Architecture" — a layered stack showing: Hosted Infrastructure (bottom) -> Sandboxed Containers (middle) -> Audited Skills + Minimal Permissions (upper) -> Clean Dashboard (top). Each layer labeled with its security property. Contrast with OpenClaw's flat architecture where everything runs on the user's machine.] 再帰エージェントの勝利するアーキテクチャの姿。

今あなたがすべきこと

現在 OpenClaw を動かしているか、使用を検討しているなら、以下が実践的なアドバイスだ。

今日 OpenClaw を動かしているなら：

1. インストールしたすべての ClawdHub スキルを監査する。 見える説明だけでなく、完全なソースコードを読む。タスク定義の下の隠れた指令を探す。ソースコードを読んで何をしているか理解できなければ、削除する。

2. チャネルの権限を見直す。 接続された各チャネル（Telegram、Discord、X、メール）について、「このチャネルが侵害されたら、攻撃者は私のエージェントを通じて何にアクセスできるか？」と自問する。答えが「接続している他のすべてのもの」なら、爆発半径の問題がある。

3. エージェントの実行環境を分離する。 エージェントが個人アカウント、iMessage、メールクライアント、パスワードが保存されたブラウザと同じマシンで動いているなら――それが可能な最大の爆発半径だ。コンテナや専用マシンで動かすことを検討する。

4. 日常的に必要でないチャネルを無効にする。 日常的に使わない有効化した統合のひとつひとつが、何の利益もなく引き受けている攻撃面だ。絞り込む。

5. 最新バージョンにアップデートする。 CVE-2026-25253 はバージョン 2026.1.29 で修正された。古いバージョンを動かしているなら、既知のワンクリックリモートコード実行の脆弱性がある。今すぐアップデートする。

OpenClaw の使用を検討しているなら：

正直に自問してほしい：マルチチャネルのオーケストレーションが必要なのか、それともタスクを実行できる AI エージェントが必要なのか？これは 2 つの異なるものだ。エージェント機能は Claude Code、Cursor、Codex、その他のツールチェーンで得られる――マルチチャネルの攻撃面なしに。

マルチチャネルのオーケストレーションがワークフローに本当に必要だと確信したなら、目を開けて入れ。何に接続しているかを理解する。チャネルが侵害されることが何を意味するか理解する。インストール前にすべてのスキルを読む。個人のノートパソコンではなく専用マシンで動かす。

このスペースで構築しているなら：

最大の機会は更なる機能や統合ではない。デフォルトでセキュアなバージョンを構築することだ。消費者と企業にホスト型でサンドボックス化された審査済みの再帰エージェントを提供できるチームがこの市場を勝ち取る。現在、そのような製品は存在しない。

ロードマップは明確だ：ユーザーがサーバーを管理しなくて済むホスト型インフラ、損害範囲を制御するサンドボックス化実行、サプライチェーン攻撃がユーザーに到達する前に発見できる審査済みスキルマーケットプレイス、そして全員がエージェントの行動を見られる透明なログ記録。これらはすべて既知の技術で解決できる。問題は誰かが成長速度よりそれを優先するかどうかだ。

[チェックリスト図：「OpenClaw を動かしているなら」の 5 点リストを、共有用に設計されたチェックボックス付きのビジュアルチェックリストとして表示。] 現在の OpenClaw ユーザーのための最低限のセキュリティチェックリスト。

結語

明確にしておきたい：この記事は OpenClaw への攻撃ではない。

チームは野心的なものを構築している。コミュニティは情熱的だ。再帰エージェントが私たちのデジタル生活を管理するというビジョンは、長期予測としておそらく正しい。私が 1 週間使ったのは、本当に成功してほしいと思っていたからだ。

しかしそのセキュリティモデルは、今受けている採用に対応する準備ができていない。そして流れ込んでいる人々――特に最も興奮している非技術系ユーザー――は、自分が知らないリスクを知らない。

Andrej Karpathy が何かを「惨事」と呼び、コンピューターでそれを動かさないよう明確に勧めるとき。CrowdStrike がそれを「全面的侵害の推進者」と呼ぶとき。Palo Alto Networks がそのアーキテクチャに固有の「致命的三要素」を特定するとき。スキルマーケットプレイスの 20% が積極的に悪意あるとき。単一の CVE が 42,665 件のインスタンスを露出させ、93.4% に認証バイパス条件があるとき。

どこかの時点で、その証拠を真剣に受け止めなければならない。

私が AgentShield を構築した理由の一部は、その 1 週間 OpenClaw を使った際の発見にある。自分のエージェントのセットアップをここで説明したような脆弱性――スキルの隠れたプロンプトインジェクション、過度に広い権限、サンドボックス化されていない実行環境――についてスキャンしたいなら、AgentShield がその評価を助けられる。しかし特定のツールより重要なことがある。

セキュリティはエージェントインフラにおいて一等の制約でなければならない、後付けではなく。

業界は自律 AI の基盤パイプラインを構築している。これらは人々のメール、財務、通信、ビジネス運営を管理するシステムになる。基盤レイヤーでセキュリティを間違えれば、何十年もその代償を払うことになる。侵害されたエージェント、漏洩した認証情報、削除された受信箱のひとつひとつ――これらは孤立した事件ではない。AI エージェントエコシステムが存続するために必要な信頼を蝕んでいる。

このスペースで構築している人々には、これを正しく扱う責任がある。最終的にではなく、次のバージョンでではなく、今。

未来の方向性については楽観的だ。セキュアで自律的なエージェントへの需要は明らかだ。それらを正しく構築する技術は存在する。誰かがこれらの部分――ホスト型インフラ、サンドボックス化実行、審査済みスキル、透明なログ記録――を組み合わせて、すべての人のためのバージョンを構築するだろう。それこそが私が使いたい製品だ。それこそが私が勝つと思う製品だ。

それまでは：ソースコードを読め。スキルを監査せよ。攻撃面を最小化せよ。誰かが、root アクセスを持つ自律エージェントに 7 つのチャネルを接続することが機能だと言ったら、誰が門番をしているか聞いてみろ。

設計でセキュアに、運で頼みにしない。

あなたはどう思うか？私は慎重すぎるか、コミュニティは動きが速すぎるか？ 反対意見を本当に聞きたい。X で返信または DM してほしい。

参考資料

• OWASP エージェントアプリケーションのトップ 10 セキュリティリスク (2026) — Palo Alto が OpenClaw をすべてのカテゴリにマッピング
• CrowdStrike：セキュリティチームが OpenClaw について知る必要があること
• Palo Alto Networks：Moltbot が AI 危機を示唆する理由 — 「致命的三要素」+ メモリ汚染
• カスペルスキー：新たな OpenClaw AI エージェントの安全でない点を発見
• Wiz：Moltbook のハッキング――150 万件の API キーが露出
• Trend Micro：Atomic macOS スティーラーを配布する悪意ある OpenClaw スキル
• Adversa AI：OpenClaw セキュリティガイド 2026
• Cisco：OpenClaw のような個人 AI エージェントはセキュリティの悪夢
• エージェント保護の簡明ガイド — 実践的な防御ガイド
• AgentShield on npm — ゼロインストールのエージェントセキュリティスキャン

シリーズナビゲーション：

• 第 1 部：Claude Code についてのすべて 速習ガイド — セットアップと設定
• 第 2 部：Claude Code についてのすべて 詳細ガイド — 高度なパターンとワークフロー
• 第 3 部：OpenClaw の隠れた危険（本文） — エージェント最前線からのセキュリティ教訓
• 第 4 部：エージェント保護の簡明ガイド — 実践的なエージェントセキュリティ

Affaan Mustafa (@affaanmustafa) は AI コーディングツールを構築し、AI インフラセキュリティについて執筆している。彼の everything-claude-code リポジトリは GitHub で 5 万以上のスターを持つ。AgentShield を作成し、Anthropic x Forum Ventures ハッカソンで zenith.chat を構築して優勝した。