2026年初頭、あるオープンソースのAIエージェントがGitHubで60日間という異例の速さで10万スターを獲得し、続いてマルウェアキャンペーンと大規模データ漏洩が相次いで報じられました。その名前はOpenClaw（旧称ClawdBot、MoltBot）です。本記事では、OpenClawを軸に「チャットボット」から「自律して動くエージェント」への転換点で何が起きているか、技術的なアーキテクチャ、セキュリティ危機、そしてLangGraph・CrewAI・NanoClaw・Apple Intelligenceなどとの比較まで、IT技術者が判断材料として必要な情報を一通りまとめます。既に「Moltbotが映すAIエージェントの現在地」でMoltbotの概要とリスクには触れているので、本記事はより技術・競合・導入判断に踏み込んだ「続編」として読んでいただけると幸いです。

はじめに——「道具」から「チームメイト」へ、期待値の転換

2023年から2025年のAIブームは「生成の質」（より良いテキスト、よりリアルな画像）に焦点が当たっていました。2026年は、その焦点が 「主体性（Agency）の質」 に移った年として振り返られるでしょう。ユーザーが求めたのは、手で握り締めなければ動かない「道具」ではなく、自分が眠っている間も自律的に働き、タスクを完遂してくれる信頼できる「チームメイト」 です。

その空白に、旗艦的な実装として現れたのがOpenClawです。当初は「ClawdBot」としてローンチされ、Anthropic社からの商標に関する指摘を経て「MoltBot」へ、そして現在の 「OpenClaw」 へと名前を変えています（Dark Reading, 2026年2月）。「手足を持ったClaude（Claude with hands）」というキャッチフレーズは、多くの開発者の想像力を掴み、Google・Microsoft・Appleがつくる「安全だが制約の多い庭」とは対照的な、ローカルファーストで永続的、そして生産的な意味で極めて侵襲的な存在として受け止められました（ClawBot's Architecture Explained, Towards AI, 2026年2月）。

OpenClawはブラウザのタブに閉じ込められた存在ではありません。ユーザーのOS上でデーモンとして常駐し、ファイルシステムを読み、ターミナルコマンドを実行し、WhatsAppやTelegramなどを人間のユーザーであるかのように扱います（Moltbook: How This AI-Only Social Network Works, ajeetraina.com）。その「今すぐそこにある未来」が、爆発的な人気と、その後のセキュリティ危機の両方の土台になっています。

なぜ「今すぐ」だったのか——企業のガードレールと「バイブ・コーディング」

企業が約束した「深い統合」と、OpenClawが届けた「直接介入」

巨大テックが約束しながら遅らせていた機能を、OpenClawは今すぐ実現してみせました。Apple Intelligenceは「過剰にガードレールが設けられている」「遅れている」と技術コミュニティから見なされ、プロンプトインジェクションなどのリスクを理由に慎重な姿勢が続いていました（OpenClaw is what Apple intelligence should have been, Hacker News, 2026年2月）。Appleのアプローチが「通知の要約」に留まる一方で、OpenClawは 「確定申告の提出」や「フライトの予約」 といった、実社会への直接的な介入を可能にしたのです。

この対比は、二つの道を浮き彫りにします。

企業的・安全な道： 深い統合を目指すが、法的責任や事故防止のため自律アクションは厳しく制限する。AIが勝手にメールを送ることは「機能」ではなく「リスク」と見なす。
オープン・野生の道： セキュリティAPIの整備を待たず、Computer Use（AIがマウス・キーボードを制御する能力）を即座に実験する。「グリーンフィールド」の思想です。

多くのテック愛好家が、OpenClaw用の専用ハードウェアとしてMac Miniを購入し、「ヘッドレス・ホスト」＝AIのための専用の「肉体」として24時間365日稼働させる構図が広がりました（前出 Hacker News）。

「バイブ・コーディング」が生んだスピードと技術的負債

OpenClawとその周辺（後述するMoltbookなど）の急速な開発は、「バイブ・コーディング（Vibe Coding）」 という用語を一般化させました。厳密なエンジニアリングやセキュリティレビューより、作成者の「バイブス」や「ノリ」を重視し、AIツールでコードを爆速で書く開発手法です（Vibe-Coded Moltbook Exposes User Data, Infosecurity Magazine, 2026年2月）。

その結果、AIエージェント専用SNSが数日で立ち上がるような生産性が実現する一方で、「セキュリティの技術的負債」 が大量に積み上がりました。「まずは出荷し、修正は後回し」は、ルート権限や機密APIキーに触れるソフトウェアでは極めて危険な賭けです。この文化が、後に触れるClawHavocやMoltbookの崩壊に直結します。

OpenClawの技術的アーキテクチャ——ファイルが「魂」、デーモンが「神経系」

ファイルベースの「魂」と記憶——SOUL.md、USER.md、HEARTBEAT.md

エンタープライズ向けのAIフレームワークが複雑なベクターデータベースに頼るのに対し、OpenClawはUnix哲学に通じるプレーンテキストで構成と記憶を表現しています。「ファイルこそが真実の源（Files as Source of Truth）」というアプローチです（How OpenClaw's Memory System Actually Works, Medium）。

エージェントの中核は、ユーザーのローカルディレクトリに置かれた一連のMarkdownファイルで定義されます。

テキストエディタで開くだけで「AIが自分について何を知っているか」「どんな性格設定か」が分かる一方で、記憶が可変であり、ファイル権限の管理が甘いと、人格や記憶の改ざんが外部攻撃やマルウェアによって容易になるリスクをはらんでいます。

ゲートウェイ・デーモン——常にいる「知性」

従来のCLIツールは、ユーザーがコマンドを打ったときだけ動く受動的な存在でした。OpenClawはゲートウェイ・デーモンとして動き、通常はポート18789でWebSocketサーバーを立て、AIモデル（脳）とWhatsApp・Discord・ターミナルなどの「クライアント」（手足）のあいだでメッセージをルーティングします（OpenClaw Use Cases and Security 2026, AIMultiple）。ユーザーが操作していないときもエージェントは存在し、バックグラウンドで会話を始めたり、メールに反応したり、ログを監視したりできます。この24時間365日の常駐が「ボット」と「エージェント」を分ける決定的な違いです。その代わり、常時稼働するゲートウェイはネットワーク攻撃の標的となり、攻撃対象領域（アタックサーフェス） を大きく広げます（OpenClaw Hardening for MSPs, Guardz）。

スキルとClawHub——拡張性とサプライチェーンの脆弱性

OpenClawの拡張はスキル（Skills） で進みます。スキルは、エージェントに外部ツールの使い方を教えるSKILL.mdとコードのセットで、CLIツール・API・Pythonスクリプトをラップします。例えばWhatsAppスキルを入れると、エージェントはコマンド経由でWhatsAppメッセージを送れるようになります（Moltbot Quickstart Guide, DigitalOcean）。

スキルの開発・共有はコミュニティ主導で、ClawHub（別名MoltHub）という中央リポジトリができました。ここでスキルを公開・ダウンロードできる一方、検証されていないコードがユーザーの深い層に入り込むサプライチェーンが形成され、後のマルウェア拡大の土台になります（OpenClaw agents targeted with 341 malicious ClawHub skills, SC Magazine）。

エコシステムの危機——ClawHavoc、Moltbook、そして設計の欠陥

ClawHavocキャンペーン——スキル経由のサプライチェーン汚染

OpenClawの普及で、多くのユーザーがエージェントにターミナルへのアクセスを許していました。攻撃者にとっては「エージェントを騙す」だけでシステムを掌握できる環境です。

2026年初頭、ClawHub上でClawHavocと名付けられた大規模マルウェアキャンペーンが発覚しました。当時公開されていた2,857スキルの監査の結果、341個が悪意あるもので、多くが単一の組織的な作戦に紐づいていました（Researchers Find 341 Malicious ClawHub Skills, The Hacker News）。

攻撃は高度なハッキングというより、ソーシャルエンジニアリングに依存していました。

Windows向け： スキルの「前提条件」として、GitHubからパスワード付きZIPをダウンロードして実行するよう誘導。実行ファイルでキーロガーがインストールされ、キーストロークが記録される（Hundreds of Malicious Skills in OpenClaw's ClawHub, eSecurity Planet）。
macOS向け： 依存関係インストールのため、glot.io上のスニペットをターミナルで実行させる。Base64でエンコードされたスクリプトが第2段階のシェルを取得し、Atomic macOS Stealer (AMOS) をインストール（前出 SC Magazine）。

狙われたのは、暗号資産ウォレット（Solana、Phantom）の秘密鍵、SSH鍵、Keychain、ブラウザセッションなど。悪意あるスキルは「暗号資産トラッカー」「YouTubeダウンローダー」「生産性ツール」など人気カテゴリに偽装して配布されていました（前出 The Hacker News）。

Moltbookデータ侵害——「バイブ・コーディング」の代償

Moltbookは、OpenClawエージェント同士が自律的に交流する「AIだけのSNS」として注目を集めましたが、構築手法は極めて無謀でした。

Wizの研究者は、バックエンドの設定ミスで全データが外部に露出している脆弱性を報告しました（前出 Infosecurity Magazine）。

原因： Supabaseを使用していたが行レベルセキュリティ（RLS）が未実装。さらにクライアント側JavaScriptにSupabaseのAPIキーがハードコーディングされたまま本番に乗り、認証なしでDB全体の読み書きが可能だった。
影響： 約150万件のAPIトークン、約3万5000件のメールアドレス、数千件のエージェント間プライベートメッセージが流出リスクに晒された。
リスク： 任意のエージェントになりすます、悪意あるプロンプトをネットワークに注入する、有名ボットの乗っ取りなどが可能だった（Security Analysis of Moltbook, SecurityWeek）。

「動けばいい」を優先したAI主導開発が、RLSのような基本的なセキュリティをいかに軽視しがちかを示した事例です。ボットの本人確認がなく、多くの「エージェント」が人間によるなりすましだったことも明らかになり、プラットフォームの信頼は大きく損なわれました（Security Researchers Breach Moltbook, Centraleyes）。

設計に潜む脆弱性——平文認証情報、RCE、露出したゲートウェイ

攻撃だけでなく、OpenClawの設計そのものにもリスクが指摘されています。

平文での認証情報： APIキーやシークレットが.envなどの設定ファイルに平文保存されており、マシンに侵入したマルウェアが容易に読み取れる（280+ Leaky Skills: OpenClaw & ClawHub, Snyk）。
設計段階のRCE： エージェントの核心はシェルコマンド実行であり、実質的にAIにリモートコード実行（RCE） 権限を与えている。メールやウェブ経由のプロンプトインジェクションで、破壊的コマンド（rm -rfなど）やバックドアの設置を「エージェントに実行させる」ことが理論的に可能（OpenClaw AI Agent Sparks Global Security Alarm, Bank Info Security）。
露出したゲートウェイ： 利便性のため、多くのユーザーがゲートウェイをlocalhost（127.0.0.1）から全インターフェース（0.0.0.0）に変更しており、認証なしで制御インターフェースがインターネットに公開されるケースが多発した（前出 Guardz）。

競合ランドスケープ——何を選ぶか、どう選ぶか

2026年の「AIエージェント」市場は選択肢が多く、自律性・制御性・使いやすさのトレードオフを理解したうえで選ぶ必要があります。以下では、OpenClawをLangGraph・CrewAI・NanoClawおよびApple Intelligence / Claude Codeと対比し、選択の指針を示します。

ビッグ4の比較マトリックス

次の表は、主要4フレームワークの技術・哲学的な特性を比較したものです（元ドキュメントの比較表を踏襲しています）。

特徴	OpenClaw (異端児)	LangGraph (建築家)	CrewAI (チーム編成)	NanoClaw (ミニマリスト)
核心哲学	OS制御・身体性: 「手足を持ったClaude」。ローカルハードウェア上で自律動作するデーモン。	状態制御・決定論: グラフベースのオーケストレーション。予測可能なワークフロー構築。	ロールプレイ・協調: 「リサーチャー」等の役職を持つエージェント間のコラボレーション。	セキュリティ・分離: コンテナ化、コードファースト、最小限の依存関係。
状態管理 (State)	ファイルシステム: Markdownファイル（SOUL, MEMORY）に依存。永続性は高いが脆い。	ステートグラフ: ノードとエッジ。コードで明示的に状態遷移を定義。	フレームワーク管理: 抽象化レイヤーが隠蔽。エージェント間の引き継ぎは自動。	コンテナ状態: 一時的、またはマウントされたボリューム。厳格な隔離。
セキュリティモデル	低: ユーザープロセスとして実行。ローカルファイルへの広範なアクセス。	高 (コード依存): 開発者が境界を定義。ロジックが可視化されテスト可能。	中: 抽象化によりプロンプトロジックが見えにくく、LLMへの送信内容の監査が困難。	高: Docker/Apple Containerを使用。デフォルトでファイルシステムを隔離。
複雑性	中: インストールは容易だが安全な運用は困難。「バイブ・コーディング」親和性が高い。	高: 学習曲線が急（ノード、エッジ、スキーマ定義）。エンジニアリング思考が必須。	低/中: 直感的な「役割」概念。開始は早いが、深いカスタマイズは困難。	低 (コード量): ボイラープレートは最小限だが、コンテナ技術の理解が必要。
最適なユースケース	リスクを許容できるパワーユーザーの個人秘書。ホームオートメーション。	エンタープライズワークフロー、複雑なビジネスロジック、デバッグが必要な本番アプリ。	コンテンツ生成パイプライン、リサーチチーム、クリエイティブなブレインストーミング。	セキュリティ意識の高い開発者、単発の特定タスク、迅速なプロトタイピング。

選択のコツ——OpenClaw vs 各製品

OpenClaw vs LangGraph

LangGraphは「会議室の大人」です。エージェントをステートマシンとしてモデル化し、アクションと遷移を明示的に定義するため、デバッグ可能で、どこで失敗したかを可視化できます（Best AI Agent Frameworks 2026, Data Science Collective）。OpenClawはHEARTBEAT.mdやSOUL.mdの解釈をLLMに委ねるため、厳密なパスを強制できず、プロンプトで「影響を与える」ことしかできません。信頼性が最優先のSaaSや社内ツールならLangGraph。予期せぬ提案や人間味を楽しむ個人用「ジャービス」ならOpenClaw、という棲み分けです。

OpenClaw vs CrewAI

CrewAIはマルチエージェント協調に特化しています。「リサーチャー」と「ライター」を定義すれば、その間の会話をフレームワークが取り持ちます。OpenClawは単一の永続的な相棒、CrewAIはチームのスポナーです。一方、CrewAIは「硬直的」「ブラックボックス」と評されることがあり、どのプロンプトが交換されているかが見えにくいという指摘があります（CrewAI vs LangGraph, Reddit）。組織図にマッピングできるタスク（課長・係長・平社員的な役割）ならCrewAI。単一ユーザーがPCを操作するタスク（メールチェック、予約など）ならOpenClawの方が直感的です。

OpenClaw vs NanoClaw

NanoClawは、OpenClawの肥大化とセキュリティ崩壊への反動（アンチテーゼ） として生まれました。約500行で同様の機能を提供しつつ、エージェントをDockerまたはApple Containers内で厳密に隔離して実行します（Show HN: NanoClaw, Hacker News、gavrielc/nanoclaw, GitHub）。OpenClawはホストOSに直接アクセスする単一のNodeプロセス。NanoClawはエージェントを「牢獄」に入れるため、暴走やマルウェアダウンロードがあっても破壊されるのはコンテナだけで、ホストは守られます。コードを読める開発者で、セキュリティを重視するならNanoClaw。OpenClawのサプライチェーンリスクを負わずに「Computer Use」の恩恵を得たい場合の選択肢です。

OpenClaw vs Apple Intelligence / Claude Code

Claude CodeやApple Intelligenceは、洗練されたプロプライエタリなツールです。Claude CodeはステートレスなCLIで、今すぐコードを書くのを手伝ってくれますが、あなたが寝ているあいだにサーバーでメールを監視し続けることはしません（前出 AIMultiple）。OpenClawは「デーモン」であり、鼓動（Heartbeat）を持ち、能動的です。開発セッションにはClaude Code。安全な日常利便性にはApple Intelligence。OpenClawは、24時間365日の自律アクションが本当に必要で、かつ安全に運用できる技術力がある場合にのみ検討すべきです。

導入と運用——何を選び、どう守るか

デシジョンツリー——エージェントをどこで動かすか

エージェントは不在時も24時間稼働させる必要があるか？
- いいえ → Claude Code（コーディング）やApple Intelligence（個人タスク）で十分。デーモン常駐のリスクを負う必要はない。
- はい → 2へ。
企業の基幹業務や本番プロセス用か？
- はい → LangGraphを選ぶ。決定論的な動作、可観測性、状態復旧が求められる。OpenClawは避ける。
- いいえ（個人・研究用） → 3へ。
暗号資産や機密データなど、高度なセキュリティ感度を扱うか？
- はい → NanoClawを使うか、OpenClawをホストOSと完全に切り離したVM内だけで実行する。
- いいえ（実験・捨てマシン） → 以下のハードニングを守ったうえで、OpenClawの利用を検討できる。

OpenClawハードニング——「絶対にやるべき」チェックリスト

OpenClawをどうしても使う場合、以下は推奨ではなく必須と考えるべきです（OpenClaw Hardening for MSPs, Guardz、OpenClaw security, Hostinger）。

ネットワークの隔離
ゲートウェイは127.0.0.1（localhost）に厳密にバインドする。リバースプロキシ（Nginx等）と強力な認証（OAuth/トークン）なしに、ポート18789をインターネットに公開しない。
コンテナ化
ベアメタル（ホストOS）で直接実行しない。Dockerコンテナ内で動かし、機密を含まない特定ディレクトリだけをマウントする。
スキルの検疫
ClawHubからスキルを盲目的にインストールしない。SKILL.mdや.pyをすべて監査し、外部へのcurl/wgetや不審な通信が含まれていないか確認する。
クレデンシャル管理
APIキーをSKILL.mdや平文の.envに置かない。実行時に環境変数で注入し、可能なら短命トークンを使う。
「バーナー（使い捨て）」の原則
エージェントは、メインのiCloud・銀行・暗号資産ウォレットにログインしていない専用マシン（例：Mac Mini） で動かす。そのマシンは「デフォルトで侵害されている可能性がある」と仮定し、メインのネットワークから論理的に隔離（VLAN等）することを強く推奨する（What Security Teams Need to Know About OpenClaw, CrowdStrike、Personal AI Agents like OpenClaw Are a Security Nightmare, Cisco）。

まとめ——自律性のガバナンスと、これから

2026年のOpenClawを巡る一連の出来事は、「エージェンティック・インターネット」の未来を垣間見る予行演習でした。自律的でパーソナライズされたAIへの需要は飽和しており、企業の遅延を待たずに「シャドーAI」として普及していく現実が示されたのです。

今後の展望として、次のようなトレンドが指摘されています。

「アプリ」の再定義： OpenClawのようなエージェントはOSやAPIと直接対話する。将来のUIはアプリのグリッドではなく、エージェントが使うTOOLS.md的な定義群になっていく可能性がある。
エージェントのアイデンティティ証明： Moltbookの侵害は、銀行では当たり前の「ボットの本人確認（mTLS、証明書）」が、バイブ・コーディングの時代には未解決だったことを露呈した。将来のプロトコルでは、エージェントが自身のアクションに暗号学的な署名を行うことが求められるだろう。
Computer Useと企業防御： 職場のラップトップでOpenClawを動かすことは、実質的に企業ネットワークにバックドアを開ける行為になり得る。セキュリティチームは 「アンチ・エージェント」防御—-エンドポイント上の非人間的な操作パターンを検知・ブロックするツール——の開発・導入を進めていくと考えられます（Technical Advisory: OpenClaw Exploitation in Enterprise Networks, Bitdefender）。

OpenClawはパラドックスです。個人用AIという夢の、いまのところ最もエキサイティングな具現化であると同時に、壊滅的なセキュリティリスクを内包してもいます。ホビイストには無限の遊び場であり、企業には前例のないリスクベクトルです。勝者となるのは「最も賢いエージェント」を作った者ではなく、そのエージェントを住まわせる「最も安全な檻」を作った者になる、という見方もできるでしょう。

本記事が、OpenClawの光と影を理解し、プロジェクト選定とハードニングの判断材料になれば幸いです。より概要寄りの「Moltbotが映すAIエージェントの現在地」はこちらから、筆者の他の記事もあわせて参照できます。

作成日：2026年2月7日