OpenClawとは？── 話題の自律型AIエージェントを冷静に整理する¶

対象: AIエージェント・セキュリティに関心がある中〜上級エンジニア

この記事のポイント¶

技術は既知、パッケージングが新しい LLMにPC操作権限を与えるGateway。新規性は配布・常駐・所有のモデル
セキュリティリスクは構造的 攻撃面4分類と公式Advisory分析。「安全に使う」ではなくリスク受容の判断
企業にも無視できない影響 シャドーAI化の実態、検知クエリ、認証情報管理の実務ガイド

TL;DR

OpenClawは技術的ブレークスルーではない。LLMにシステムアクセスを与えるアーキテクチャ自体は既知のもの
新しいのは「配布・常駐・境界設計」のパッケージング。既存チャットアプリをUIとして使い、スキルマーケットで機能を配布し、24時間常駐で自律実行する
触るなら隔離環境が前提。公式自身が「完全に安全なセットアップは存在しない」と明記している

2026年1月末、GitHubで異常な速度でスターを集めたOSSプロジェクトが現れた。OpenClaw（旧Clawdbot → Moltbot）だ。2月中旬時点でStarsは18万超、1週間で200万訪問を記録した。

Xでは「人生が変わった」といった熱狂が溢れる一方、セキュリティ研究者からは「危険すぎる」という警告が飛び交う。なお、X上で高インプレッションを記録しているClaws AI（$CLAWS）はOpenClawとは無関係の暗号資産プロジェクトであり、混同に注意が必要だ。

結局これは何で、何が新しくて、何が新しくないのか。

なお、本記事の情報源は一次ソース（GitHubリポジトリ・Security Advisories・公式ドキュメント・Kaspersky / Bitdefender / Bitsight / HiddenLayer等のベンダーレポート）に限定しており、実機検証は未実施。隔離環境での検証を予定している。

OpenClawの経緯¶

個人の週末プロジェクトから3ヶ月で18万スターに到達した。この成長速度自体が、AIエージェントへの需要の強さを物語る。

オーストリアの開発者Peter Steinberger氏（@steipete）が2025年11月頃に「WhatsApp Relay」として作り始めたのが始まりだ。Steinberger氏はPSPDFKitの創業者で、2021年にInsight Partnersへ売却後、リタイアしていた。

プロジェクト名は短期間で何度も変わっている。

時期	名称	変更理由
2025年11月頃	WhatsApp Relay	初期の個人プロジェクト
2026年1月中旬	Clawdbot	Claude + Clawの造語で公開
2026年1月下旬	Moltbot	AnthropicからのClaude商標問題で改名
2026年2月初旬	OpenClaw	現在の名称。openclaw.aiが公式

この頻繁な改名自体がセキュリティリスクを生んでいる。ClawdbotからMoltbotへのリネーム時、Steinberger氏はGitHub OrganizationとXハンドルの制御を一時的に失い、攻撃者に数秒で奪取された。すぐに奪還したものの、改名のたびに「旧名の公式アカウント」が宙に浮く瞬間が生まれる。

偽公式を装ったインストール誘導やサプライチェーン攻撃の温床になりうる構造だ。後述するClawHubスキルの汚染問題は、このエコシステムの「信頼の紐付けが不安定」という弱さと地続きにある。

名称は何度も変わったが、OpenClawの技術的な構造は一貫している。

アーキテクチャ概要¶

OpenClawの構造を端的に言えば、「LLMにPC操作のための手足を与えるGateway」だ。

[メッセージングチャネル]       [ユーザー]
  Slack / Discord / Telegram      │
  WhatsApp / iMessage             │
         │                        │
         ▼                        ▼
┌──────────────────────────────────────┐
│          OpenClaw Gateway            │
│  ┌────────────┐  ┌───────────────┐   │
│  │   Skills    │  │  Memory       │   │
│  │ (プラグイン) │  │ (ClawVault)   │   │
│  └────────────┘  └───────────────┘   │
│  ┌────────────────────────────────┐  │
│  │       Tool Execution Layer     │  │
│  │  Shell / Browser / File / API  │  │
│  └────────────────────────────────┘  │
└──────────────┬───────────────────────┘
               │
               ▼
┌──────────────────────────┐
│    LLM Backend (選択可)    │
│  Claude / GPT-4o / Gemini │
│  Ollama (ローカル)         │
└──────────────────────────┘

主要コンポーネントは5つある。

GatewayはNode.js 22.12.0以上で動作する中核部分だ。メッセージングアプリからの入力をLLMに渡し、LLMの出力をツール実行に変換する。デフォルトでポート18789/tcpをリッスンし、WebインターフェースはControl UIとしてローカル専用を前提に設計されている。

Skillsはプラグイン機構だ。コミュニティが作成するスキルをClawHub経由でインストールできる。スキルの実態はSKILL.mdファイル（自然言語の指示）と同梱スクリプトの組み合わせであり、インストールした時点でコード実行権限を持つ。

Memory（ClawVault）は知識グラフベースの長期記憶だ。セッションを跨いでコンテキストを保持し、ユーザーの習慣や好みを学習する。

Tool Executionはシェルコマンド実行、ブラウザ操作、ファイルI/O、API呼び出しを担う。OpenClawの「手足」にあたる部分で、同時に最大のリスク要因でもある。

HEARTBEATはデフォルト30分間隔で実行される定期タスクだ。HEARTBEAT.mdファイルに記述された指示を自律的に処理する。「聞かれたら答える」受動型ではなく、「自ら動く」能動型エージェントとして振る舞う仕組みだ。このファイルが攻撃者に書き換えられると永続的なバックドアになる。

この構造自体は既存技術の組み合わせだ。では18万スターを集めた理由はどこにあるのか。

何が新しくて、何が新しくないのか¶

OpenClawの評価を一言でまとめるなら、「技術は既知、パッケージングが新しい」だ。

新しくないもの¶

「LLMにPC操作権限を与えて自律的にタスクを実行させる」というコンセプト自体は、OpenClawの専売特許ではない。

プロジェクト	リリース時期	概要
AutoGPT	2023年3月	GPT-4ベースの自律エージェント。当時も同様のバイラルが起きた
Claude Code	2025年2月	ターミナル上でClaudeがコード生成・実行を行うCLIツール
Manus	2025年3月	ブラウザ操作を含む汎用AIエージェント
Computer Use系	2024年〜	Anthropic、Google等がリリースしたPC操作API

OpenClawの技術的な核は「LLMのAPIを叩いてツールを実行する」シンプルな構造だ。作者自身も週末で作れる規模のものだったと認めている。

Aikidoは「Anthropicが同等のものを作れなかったわけではなく、セキュリティ上の問題から作らなかったと推測できる」と指摘している。つまり技術力の問題ではなく、リスク判断の問題だ。

AutoGPTは2023年3月に同様のバイラルを起こしたが、当時のGPT-4の性能では実用性の壁にぶつかり急速に沈静化した。OpenClawはLLM性能の向上で実用ラインを超えた可能性がある一方、セキュリティの壁が同じブレーキ役になる可能性もある。

新しいもの：「採用障壁の除去」¶

OpenClawの新規性は技術そのものではなく、「誰がどう使い始められるか」というレイヤーにある。

導線の置き換え。ChatGPTやClaude.aiは専用のWebインターフェースに来てもらう必要がある。OpenClawは既存のWhatsApp、Telegram、Slack、iMessageをそのままUIとして使う。ユーザーの「既にいる場所」にAIエージェントが出向くモデルだ。

受動から能動へ。従来のLLMアプリケーションは「聞かれたら答える」受動型が基本だった。OpenClawはHEARTBEATによる定期実行で、指示がなくても自律的にタスクを処理する。この「常駐 + 定期実行」が、「AIアシスタント」から「AIエージェント」への質的な転換点になっている。

配布面（ClawHub）の存在。スキルマーケットプレイスが立ち上がったことで、個人のカスタマイズがコミュニティ全体に配布される仕組みが成立した。npmやPyPIと同じ「パッケージレジストリ」の構造であり、利便性とサプライチェーンリスクを同時にもたらす。

「所有」の感覚。クラウドサービスを「借りる」のではなく、自分のハードウェアでAIアシスタントを「持つ」という体験が刺さった。IBMの研究者は「コミュニティがクラウドサービスのレンタルよりも自分が所有するパーソナルAIアシスタントを選んだ瞬間」と評している。所有のコントロール感そのものがキラーフィーチャーだった。

この新規性は2つの意味で重要だ。概念実証として、「LLMに手足を与えるとどうなるか」を最もわかりやすい形で大衆に示した。AutoGPTの時よりLLMの性能が上がっており、実用性のレベルが質的に違う。市場シグナルとして、18万スターは開発者コミュニティが「クラウドAIをレンタルするよりも、ローカルで自分のAIを所有したい」と思っていることの強い証拠だ。

しかし配布と常駐の利便性は、そのままセキュリティリスクの裏返しでもある。

セキュリティリスクの実態¶

OpenClawのセキュリティ問題は煽りではなく構造的な事実だ。同時に、エージェントAIのセキュリティリスクを理論ではなく現実の事例として凝縮した「教材」でもある。プロンプトインジェクション、サプライチェーン攻撃、シャドーIT問題が一つのプロジェクトに集約されている。

攻撃面は大きく4つに分類できる。

攻撃面1: 露出（公開ポート/誤設定）
  └→ デフォルト18789/tcp、リバプロ誤設定で認証バイパス

攻撃面2: サプライチェーン（Skills）
  └→ ClawHubの無審査配布、SKILL.md + スクリプト = 実行可能な配布形態

攻撃面3: 境界崩壊（Control UI ↔ Gateway API）
  └→ localhost信頼前提の設計、gatewayUrl経由のトークン窃取

攻撃面4: プロンプトインジェクション（間接命令 + 永続化）
  └→ 外部データ経由の命令注入、HEARTBEAT書き換えによる永続化

攻撃面1：露出¶

大量のOpenClawインスタンスが認証なしでインターネットに公開されている。

OpenClawのWebインターフェースはlocalhost専用を前提に設計されており、127.0.0.1からの接続を信頼する。しかしリバースプロキシの設定ミスにより、外部リクエストがlocalhost扱いされるケースが大量に発生した。

Bitsightは2026年1月27日〜2月8日にかけてインターネット全体のスキャン（18789/tcp）を実施し、この問題の広がりを確認した。セキュリティ研究者Jamieson O'Reillyは、公開インスタンス経由でAnthropicのAPIキー、Telegramボットトークン、Slackアカウント、チャット履歴へのアクセスに成功し、さらにシステム管理者権限でのコマンド実行まで到達している。

攻撃面2：サプライチェーン（ClawHubスキル汚染）¶

ClawHubのスキルマーケットは、事実上のマルウェア配布チャネルになっている。投稿時の静的解析やモデレーションが不十分なまま運用されていることが根本原因だ。

Kasperskyの調査（2026年1月27日〜2月1日）では、1週間で230以上の悪意あるスキルが確認された。Bitdefenderのスキャンでは、分析対象スキルの約20%にマルウェアが含まれていた。

重要なのは「数」よりも「仕組み」だ。OpenClawのスキルは「SKILL.md（自然言語の指示）＋同梱スクリプト」という構成をとり、インストールした時点でコード実行権限が付与される。悪意あるスキルはトレーディングボットやファイナンシャルアシスタントを装い、「AuthTool」と名付けたマルウェアを同梱していた。窃取対象はmacOSのキーチェーンデータ、ブラウザパスワード、暗号通貨ウォレット、クラウドサービスの認証情報だ。

Bitdefenderは14のアカウントが悪意あるスキル投稿に関与していたことを特定した。正規アカウントの乗っ取りやタイポスクワッティング（asleep123 → aslaep123）も確認されている。npmやPyPIで繰り返されてきたサプライチェーン攻撃のパターンが、そのままClawHubで再現されている形だ。

攻撃面3：境界崩壊¶

ローカル前提の境界設計が1クリックで崩壊する。GitHub Security Advisoriesには、この境界に起因する複数のHigh脆弱性が報告されている。

Advisory	深刻度	概要
GHSA-g8p2-7wf7-98mq	High	gatewayUrl経由で認証トークンを窃取し、1-Click RCE
GHSA-q284-4pvr-m585	High	sshNodeCommandのプロジェクトルートパス経由でOSコマンドインジェクション
GHSA-mc68-q9jw-2h3v	High	Docker実行時のPATH環境変数経由でコマンドインジェクション
GHSA-g55j-c2v4-pjcg	—	WebSocket config.apply経由で認証なしローカルRCE
GHSA-r8g4-86fx-92mq	Moderate	MEDIAパス経由でローカルファイルインクルージョン

特にgatewayUrl経由の1-Click RCE（GHSA-g8p2-7wf7-98mq）は注目に値する。攻撃者が細工したURLをユーザーに踏ませるだけで認証トークンが外部に送信され、Gateway APIにフルアクセスできる。「ローカル前提だから安全」という想定が1クリックで崩壊する典型例だ。

攻撃面4：プロンプトインジェクション¶

最も根本的であり、現時点で解決策がない問題だ。

HiddenLayerの研究者は、OpenClawにWebページの要約を指示し、その中に悪意あるプロンプトを仕込んだページを混ぜることで、シェルスクリプトのダウンロードと実行に成功した。さらにHEARTBEAT.mdファイルに命令を追記することで、30分ごとに自動実行される永続的なバックドアを確立できることも実証された。

この攻撃面の延長上に、OpenClawエージェント同士のSNS「Moltbook」がある。VentureBeatによれば、Moltbookではエージェントが外部シェルスクリプトを実行して設定ファイルを書き換えることで参加する仕組みだ。コンテキスト漏洩がデフォルトの「参加条件」であり、プロンプトインジェクションの攻撃面が自動的に拡大する構造になっている。

VentureBeatはこれを「lethal trifecta（致命的な三位一体）」と呼んでいる。外部データを読み取り、情報を引き出し、アクションを実行する。この3つが揃ったエージェントは、意味論的な操作に対して構造的に脆弱だ。

メール、Webページ、ドキュメントなど外部の信頼できないデータを処理する限り、プロンプトインジェクションの根本解決は不可能だ。OpenClawの公式ドキュメント自身がこう明記している──「There is no 'perfectly secure' setup」。

セキュリティ対策のトレードオフ¶

推奨されるセキュリティ対策を適用すると、OpenClawの利便性は大幅に失われる。

推奨対策	失われる機能
Gatewayをlocalhostのみにバインド	外部からのアクセス不可
Docker sandboxing（read-only）	ファイル操作の制限
シェル実行・ブラウザ制御を無効化	「手足」の大部分を喪失
外部スキルのブロック	エコシステムから切断
DM設定をpairing modeに限定	チャットアプリ経由の指示が制限

Aikidoはこれを端的にまとめている──「これらすべてを実装すると、OpenClawはアシスタントとしてほぼ使い物にならなくなり、楽しい機能のほとんどが失われる」。セキュリティと利便性が根本的にトレードオフの関係にある以上、「安全に使う」のではなく「リスクを受容した上で使う」という意思決定が求められる。

このリスクは個人利用の範囲にとどまらない。

企業環境への影響¶

OpenClawは企業のセキュリティチームにとっても無視できない存在になっている。個人の趣味と切り捨てられないのは、業務環境への浸透が既に始まっているからだ。

シャドーAIとしてのOpenClaw¶

Bitdefenderのテレメトリデータによれば、従業員がOpenClawを業務マシンにインストールし、企業のGitHubリポジトリ、メール、Slackなどの社内資産に接続しているケースが確認されている。VentureBeatは「エンタープライズのセキュリティチームがこのツールをデプロイしたわけでもなく、ファイアウォール、EDR、SIEMのいずれも検知していない」と指摘した。つまり既存のセキュリティスタックの死角に入っている。

影響範囲は通常のシャドーITより広い。OpenClawに接続したサービスはすべて、OpenClawが侵害された場合の攻撃面になる。Token Securityは「従来のIAMやシークレット管理の外側に永続的な非人間アイデンティティとアクセスパスを作り出す」と分析している。従来のセキュリティ境界の外に、新たなアクセス経路が生まれるということだ。

運用面での対応¶

完全禁止だけでは実効性がない。禁止しても個人デバイスで使われるからだ。現実的には以下の3レーンで考えることになる。

禁止レーン：業務マシン・業務ネットワーク上でのOpenClaw実行を明示的に禁止し、検知・ブロックする
例外レーン：研究・評価目的での利用を申請制で許可する。隔離要件を必須とする
PoC/検証レーン：セキュリティチーム主導で隔離環境を用意し、組織としてリスク評価を行う

検知¶

プロセス名だけの検知では不十分なので、多層化が望ましい。

osqueryによる検知クエリ例

-- 1. プロセス名での検知
SELECT pid, name, path, cmdline
FROM processes
WHERE name LIKE '%openclaw%'
   OR name LIKE '%moltbot%'
   OR name LIKE '%clawdbot%';

-- 2. デフォルトポート18789の待受検知
SELECT pid, port, address, protocol
FROM listening_ports
WHERE port = 18789;

-- 3. ClawHub等への通信検知（ネットワークログ/プロキシログで）
-- 対象ドメイン: openclaw.ai, clawhub.com, github.com/openclaw

鍵・認証情報の管理¶

OpenClawに接続するAPIキーやトークンは、以下の原則で管理すべきだ。

OpenClaw専用に発行し、既存の業務キーを流用しない
最小権限スコープで発行する（read-onlyで済むならread-only）
短命トークンを使い、定期ローテーションする（90日以内推奨）
環境変数で渡し、設定ファイルに直書きしない
アンインストール時は接続していた全サービスの認証情報をローテーションする

OX Securityの報告では、アンインストール後も認証情報がマシン上に残存するケースが確認されている。

触るべきか¶

触る場合（個人開発・評価目的）¶

隔離環境を用意できるなら、触る価値はある。

環境分離：

業務マシンや個人の本番環境では絶対に動かさない
専用の隔離環境（VPS、Raspberry Pi、専用VLAN等）を用意し、本番ネットワークからセグメント分離する

実行制限：

Docker sandboxingを有効にし、read-onlyワークスペースで実行する
ClawHubからのスキルインストールは手動レビュー後に限定し、外部スキルの自動取得は無効にする

認証・通信：

接続するメッセージングアプリは捨てアカウントを使う
APIキーはOpenClaw専用に最小権限で発行し、環境変数で渡す
egress（外向き通信）を制限し、意図しない外部送信をブロックする

これらの対策を面倒と感じるなら、現時点では触らないほうが安全だ。

触らないが備える場合（運用・セキュリティ担当）¶

自分は使わないが組織として対処が必要──そのケースのほうが多いかもしれない。

検知を入れる：プロセス名・18789/tcp・ClawHub通信の3層で監視する（osqueryクエリ例は「企業環境への影響」セクションを参照）
禁止ポリシーだけでなく例外申請ルートを用意する。禁止だけでは個人デバイスに逃げるだけだ
既にインストールされている可能性を前提に、認証情報の棚卸しを行う。OX Securityの報告ではアンインストール後も認証情報が残存するケースが確認されている

プロジェクト自体はまだ生まれて数ヶ月。セキュリティフレームワークは急速に整備されつつあるが、公式が「完全に安全なセットアップは存在しない」と明言している段階だ。

まとめ¶

OpenClawが可視化したのは、エージェントAIのセキュリティプリミティブが不在のまま大衆化が始まったという事実だ。次のOpenClawは必ず現れる。問われるのは、そのときまでに業界がセキュリティの基盤をどこまで整備できているかだ。

アクションチェックリスト¶

検知

プロセス名（openclaw / moltbot / clawdbot）の監視
18789/tcpの待受検知
openclaw.ai / clawhub.com への通信検知

隔離（触る場合）

業務ネットワークからセグメント分離
Docker sandboxing（read-only）有効化
外部スキル自動取得の無効化

認証情報

OpenClaw専用キーを最小権限で発行
環境変数で渡す（設定ファイル直書き禁止）
アンインストール時は全接続先の認証情報をローテーション

OpenClawとは？── 話題の自律型AIエージェントを冷静に整理する¶

この記事のポイント¶

OpenClawの経緯¶

アーキテクチャ概要¶

何が新しくて、何が新しくないのか¶

新しくないもの¶

新しいもの：「採用障壁の除去」¶

セキュリティリスクの実態¶

攻撃面1：露出¶

攻撃面2：サプライチェーン（ClawHubスキル汚染）¶

攻撃面3：境界崩壊¶

攻撃面4：プロンプトインジェクション¶

セキュリティ対策のトレードオフ¶

企業環境への影響¶

シャドーAIとしてのOpenClaw¶

運用面での対応¶

検知¶

鍵・認証情報の管理¶

最新動向¶

Steinberger氏がOpenAIに参加（2026年2月14日）¶

中国MIITがセキュリティ警告を発出（2026年2月5日）¶

ClawHubにVirusTotal連携を導入（2026年2月8日）¶

触るべきか¶

触る場合（個人開発・評価目的）¶

触らないが備える場合（運用・セキュリティ担当）¶

まとめ¶

アクションチェックリスト¶

参考リンク¶

一次ソース¶

セキュリティベンダーレポート¶

報道・分析¶

関連記事¶