【ローカルAIエージェント】OpenClaw系ツールを比較！

お嬢様

最近、“OpenClaw”って名前をよく見かけますわね。便利そうですけれど、種類が多すぎませんこと？

セバスチャン

はい。今は本家だけでなく、考え方を受け継いだ“派生ツール”がいくつも登場しております。本日は代表的な5つ――NanoClaw、nanobot、ZeroClaw、IronClaw、PicoClawを比較しながら、ご案内いたします。

サマリー
個別分析
- NanoClaw
- nanobot
- ZeroClaw
- IronClaw
- PicoClaw
セキュリティ評価
比較軸テーブル
コミュニティやSNSでの評価
運用向きスコア（判断補助）
比較マトリクス（検討しているハードウェア前提）
- 比較マトリクス（要点）
- 組み合わせ検討
評価と実運用を考える
ざっくりと用途別の選び方
主要出典

サマリー

本レポートは、OpenClaw系5ツールを比較資料としてまとめたものです。対象は NanoClaw / nanobot / ZeroClaw / IronClaw / PicoClaw です。手元にある環境のどれに入れて運用するのがいいのか検討します。

検討している環境

デスクトップPC 　メモリ：64GB　グラボ：16GB
ノートPC　メモリ：32GB
MacBook Pro 2016 Intel 8GB
Raspberry Pi 3 MODEL B

結論を先に言うと、安全第一で常用したいなら IronClaw、軽さと移植性を優先するなら ZeroClaw、低スペック実験環境なら PicoClaw、多連携の実験速度を優先するなら nanobot、構造を理解しながら小さく育てたいなら NanoClaw が軸になります。

判断の要点は次のとおりです。

5ツールは名前が似ていても設計思想が異なり、比較軸は「安全境界」「運用コスト」「拡張のしやすさ」を分けて考える必要があります。
セキュリティ設計は IronClaw が最も明示的で、WASMベースの実行分離や秘密情報の扱いが一次資料で読み取りやすいです。
nanobot と PicoClaw は更新速度が高い反面、導入後の追従運用（検証環境での先行検証）が必須です。
ZeroClaw は軽量ランタイムとして有力ですが、配布元の正当性確認（公式リポジトリ固定）が運用上の前提になります。
NanoClaw はコンテナ隔離重視で「見せた領域だけ見える」方向が明確です。小規模構成で理解しやすい点が実務上の強みです。

個別分析

ここでは各プロジェクトについて、指定された項目（URL、メンテナ、ライセンス、最新リリース/日付、目的と差分、対応プラットフォーム、LLM統合、権限/セキュリティモデル、成熟度）を“2列テーブル”で整理し、README/リリースノート/コミット履歴から読み取れる差分と破壊的変更の要点をまとめる。

NanoClaw

セバスチャン

NanoClaw は「小さいコードベース」と「コンテナ隔離」を中心にした設計です。サンドボックス（注: アプリを制限された実行領域に閉じ込める仕組み）志向が強く、ホスト全体に触れさせない運用を作りやすい点が特徴です。

項目	内容
リポジトリ	（公式）GitHub: `https://github.com/qwibitai/nanoclaw`
主メンテナ	主要コミット作者として `gavrielc` が頻出（GitHub上のコミット履歴より）。
ライセンス	MIT。
最新リリース/日付	GitHub Releasesは未運用（“リリース無し”）。ただしコミット履歴上は 2026-02-24 に `1.1.2` へのバージョン更新がある。
目的・上流（OpenClaw）との差分	OpenClawの“巨大さ”と“アプリ層の許可モデル中心”を問題視し、少数ファイルの単一プロセス＋コンテナ隔離で同等コア機能を目指す。
対応プラットフォーム	macOS / Linux。コンテナ実行はApple Container（macOS）またはDocker（macOS/Linux）。
LLM統合	Anthropic Agents SDK/Claude Code前提（“Claude Code handles everything”）。
権限・セキュリティモデル	“Secure by isolation”を明示。エージェントはLinuxコンテナで動作し、明示マウントしたディレクトリしか見えない（bashもホストでなくコンテナ内）。
成熟度（活動/安定）	Stars約13.7k、Issues約32、フォーク約2k。コミットは2026-02に集中し活発。

README/設計思想上の差分は“設定ファイルを増やさず、必要ならコードを変える（しかもClaude Codeに変えさせる）”という点に集約される。OpenClawの許可モデル（allowlist、ペアリング等）を「アプリ層の安全」と位置づけ、NanoClawではOS境界（コンテナ）を安全の中心に置く。

破壊的変更として明示されているものは少ないが、コミット履歴にセキュリティ関連の修正が連続している（例：スキルのパス逃げ/シンボリックリンク経由の脱出対策、ルートをread-onlyでマウントして“コンテナ逸脱”を抑える旨のコミットメッセージ）。これは、スキルという“コード生成・コード適用”を伴う仕組みがサプライチェーン的リスクを内包することを示唆する。

nanobot

セバスチャン

nanobot は多チャネル・多プロバイダ連携を高速に取り込む実用路線です。MCP（注: AIが外部ツールと接続するための共通ルール）や OAuth（注: パスワードの代わりに許可トークンで連携する方式）など導入しやすい要素が多い反面、更新追従を止めるとリスクが残りやすい性質があります。

項目	内容
リポジトリ	（公式）GitHub: `https://github.com/HKUDS/nanobot`
主メンテナ	リリース作成者として `Re-bin` が明示され、リリース頻度も高い。
ライセンス	MIT。
最新リリース/日付	v0.1.4.post2（2026-02-24公開）。
目的・上流（OpenClaw）との差分	“Ultra-Lightweight OpenClaw”を掲げ、多チャネル・多プロバイダ・MCPを短い反復で入れていく実用志向。
対応プラットフォーム	Docker/Docker Composeで実行できる構成が明示され、CLIとgatewayを分けて運用する想定。
LLM統合	OpenRouter/Anthropic/OpenAI/DeepSeek等の直結、任意のOpenAI互換エンドポイント、ローカルvLLM、さらにOpenAI CodexやGitHub CopilotのOAuthログインまで列挙されている。
権限・セキュリティモデル	チャネルごとの制御（例：SlackのgroupPolicy、EmailのconsentGranted/allowFromなど）が設定例付きで示される。 MCPはHTTP/stdio両方をサポートし、認証ヘッダ注入も可能（＝外部ツール接続が強力な一方リスクも増える）。
成熟度（活動/安定）	Stars約24.4k、Issues約280台、リリースが短い間隔で継続。

README/リリースノート差分で“実利用の痛点”が透ける。たとえばv0.1.4.post1では「メモリ統合を“壊れやすいJSONパース”から“structured tool calls”へ移行」など、信頼性に直結する設計変更が強調される。

セキュリティ面では、v0.1.4.post2のハイライトで「startswithではなくrelative_to()でパストラバーサルを防止」と明記されており、（修正されたとはいえ）過去に“ファイルパス取り扱い”が脆弱になり得たことが一次情報として確認できる。また、履歴欄でも“security hardeningを含むのでアップグレードせよ”と明示されたリリースがあり、セキュリティを“追随的に強化している最中”というプロファイルに近い。

注意すべき“権限モデル上の例外”として、v0.1.4.post1のハイライトに「Telegramで /help がACLをバイパスする」と書かれている。仕様上の利便性かもしれないが、運用者が“ACL＝境界”と誤認しやすい典型例なので、導入時にコマンド例外を把握しておく必要がある。

ZeroClaw

セバスチャン

ZeroClaw は Rust 単一バイナリの軽量運用が強みです。導入の軽さと起動の速さが魅力ですが、公式性の確認を強く求めるプロジェクトなので、配布経路の管理が重要です。

項目	内容
リポジトリ	（公式）GitHub: `https://github.com/zeroclaw-labs/zeroclaw`
主メンテナ	リリースv0.1.7には`chumyin`名義が表示され、署名付きタグとして扱われている。
ライセンス	Apache-2.0 / MIT デュアル。
最新リリース/日付	v0.1.7（2026-02-24）。
目的・上流（OpenClaw）との差分	Rust単一バイナリで「エージェント実行基盤（runtime OS）」を目指し、モデル/ツール/メモリ/実行を差し替え可能に抽象化する。
対応プラットフォーム	ARM/x86/RISC-Vを同一運用モデルで扱うと明記。macOS/LinuxbrewではHomebrew導入が例示される。
LLM統合	OpenRouterやOpenAI Codex OAuth等の“サブスク認証プロファイル”をサポートすると説明（ただしAnthropic OAuth運用には注意喚起あり）。
権限・セキュリティモデル	“secure default（ペアリング、明示allowlist、サンドボックス、スコープ制御）”を掲げる。 v0.1.7では「prompt injection defenseとleak detection」追加がリリースノートに入っている。
成熟度（活動/安定）	Stars約18.4k、フォーク約2.2k。なりすまし/偽ドメイン対策をREADME先頭で扱うなど、配布・公式性のガバナンスも成熟課題として顕在化。

ZeroClawのREADME（日本語）は、単なる翻訳ではなく“公式性と安全性”を最優先する編集方針が明記されている点が特徴的で、2026-02-19時点で「非公式fork・非公式ドメイン（zeroclaw.org等）への緊急注意」を出している。これは、Claw系の急拡大期に典型的な“なりすまし配布・改ざんバイナリ”リスクを最初から想定していることを示す。

破壊的変更としては、クラウド/サブスク認証の扱いが大きい。Anthropicの条項更新（2026-02-19）に触れ、Claude Free/Pro/MaxのOAuthトークンを他製品（Agent SDK含む）へ流用するのは規約違反になり得ると読み取れるため「当面試さないで」と明確に書いている。導入者側は“技術的に可能”と“契約上許される”を分離して判断する必要がある。

IronClaw

セバスチャン

IronClaw は安全性を仕様として前面に出しており、WASM（注: 異なる環境でも同じ処理を安全寄りに動かしやすい実行形式）を使った分離、監査ログ、テレメトリー（注: 利用情報の外部送信）なし方針などが確認できます。セキュア運用の説明責任を取りやすい設計です。

項目	内容
リポジトリ	（公式）GitHub: `https://github.com/nearai/ironclaw`
主メンテナ	`nearai`名義（組織）で運用。READMEで“NEAR AIアカウント”を前提にしたオンボーディング導線がある。
ライセンス	Apache-2.0 / MIT デュアル。
最新リリース/日付	0.11.1（2026-02-23）。プリビルドにIntel macOS（x86_64-apple-darwin）が含まれる。
目的・上流（OpenClaw）との差分	“privacy and security”を前面に、Rust・WASMサンドボックス・PostgreSQLを核に据える。
対応プラットフォーム	リリース配布物としてApple Silicon/Intel macOS、Windows、ARM64/x64 Linuxのアセットが列挙される。
LLM統合	既定はNEAR AIだが、“OpenAI互換エンドポイントなら何でも”と明記。OpenRouter/Ollama/vLLM/LiteLLM等が例示される。
権限・セキュリティモデル	WASMサンドボックス（能力ベース許可、HTTP allowlist、秘密情報の境界注入、リーク検知、レート/リソース制限）を明示。外部コンテンツに対するprompt injection対策、ローカルDB保存、AES-256-GCMでの秘密暗号化、telemetry無し、監査ログも掲げる。
成熟度（活動/安定）	Stars約3.3k、Issues約85、リリースが継続。依存としてPostgreSQL+pgvectorを要求し、運用は“軽量フォーク”より重いが、設計は一貫してセキュリティ主導。

IronClawは、他の派生よりも“権限モデルの仕様化”がはっきりしている。特にWASMサンドボックスの説明が詳細で、「HTTPは許可したホスト/パスにしか出られない」「シークレットはWASMコードに露出せずホスト境界で注入」「リクエスト/レスポンスのリーク検知」など、実装方針がREADMEで定義されている。

一方で、要件としてPostgreSQL 15+ と pgvector を要求するため、Raspberry Pi 3Bクラスでは現実的に厳しく、あなたの構成では“デスクトップ/ノート”向けの“安全第一・常用”枠が適合する。

PicoClaw

セバスチャン

PicoClaw は低リソース環境向けの実験適性が高い一方、早期開発段階である注意が公式に明示されています。公開本番より、閉じた検証環境で使う前提が安全です。

項目	内容
リポジトリ	（公式）GitHub: `https://github.com/sipeed/picoclaw`
主メンテナ	`sipeed`名義（組織）で運用。README内で公式ドメインを一本化し、なりすまし注意を強調。
ライセンス	MIT（LICENSEに明記）。nanobot由来である旨の注記も付いている。
最新リリース/日付	v0.1.2（2026-02-17）。
目的・上流（OpenClaw）との差分	Goでゼロから再設計し、<10MB RAM・1秒起動・RISC-V/ARM/x86単一バイナリをうたう。nanobotに強くインスパイアされたと日本語READMEでも明言。
対応プラットフォーム	日本語READMEではRISC-V/ARM/x86対応を強調し、Linuxデバイスへの広いデプロイ例を挙げる。Docker Compose運用も例示。
LLM統合	モデル中心（vendor/model）設定を採用し、Anthropic/Ollama（ローカル）/カスタムプロキシ等の例を提示。
権限・セキュリティモデル	公式に「NO CRYPTO」「公式ドメインはpicoclaw.ioのみ」「初期開発で未解決のネットワークセキュリティ問題があり得るのでv1.0前の本番投入禁止」と明示。また、`restrict_to_workspace`がメイン/サブエージェント/ハートビート全経路で一貫して適用され、迂回できないと説明。
成熟度（活動/安定）	Stars約19.2k、Issues約150台。人気は大きいが、リポジトリ自身が“early development”警告を出しており、安定度は“実験〜準実用”評価が妥当。

PicoClawのREADME差分で最大の“破壊的変更候補”は設定方式で、旧来のproviders設定が「deprecatedだが後方互換で残す」とされ、“モデル中心（model_list / vendor/model）”に寄せる移行が明示されている。運用者は、既存設定テンプレを持っている場合にマイグレーション手順を固定化しておく必要がある。

また、公式が“未解決のネットワークセキュリティ問題があり得る”と明記するのは珍しく、攻撃面の存在を自覚したうえでの早期リリースであることが分かる。ここは「小ささ」より「境界設計（workspace制限、allow_from、外部公開しない）」が優先されるべきプロジェクトプロファイルである。

セキュリティ評価

改善が明確な方向性

最も“仕様として強い”のはIronClawで、能力ベース許可・HTTP allowlist・秘密注入境界・リーク検知・監査ログ・telemetry無しがREADMEで明示される。少なくとも一次ソース上は「何を守り、どこを境界にし、どう検知するか」が書かれている。

NanoClawは、OpenClawの許可モデルを「アプリ層の安全」と整理したうえで、コンテナ隔離（マウント明示、bashはコンテナ内）へ寄せる。OS境界を使うため、エージェントが“勝手にホスト全体を見る”リスクを減らしやすい。

ZeroClawは、プロダクト設計（secure default、prompt injection defense、leak detection）に加え、配布の公式性（なりすまし）を脅威モデルの中心に置いている点が特徴。Claw系の急拡大局面では、脆弱性そのものより「偽物を踏んでしまう」供給網問題が先に致命傷になるため、この注意喚起は実務上の価値が高い。

“退化（regression）”が起こりやすいポイントと実例

nanobotは機能増が速い分、境界の抜け穴が出やすい。リリースノートにパストラバーサル対策が明記されていることは、改善の証拠である一方で「少なくとも過去にリスク領域が存在した」ことも示す。

同様に、/helpがACLをバイパスする仕様は、UX上の利点があっても“権限境界の理解”を崩す典型になり得る。こうした例外仕様が運用ドキュメントに反映されないと、「ACL設定したから大丈夫」という誤認を生む。

PicoClawは自ら“ネットワークセキュリティ未解決の可能性”を明示し、v1.0前の本番投入を止めている。これは正直な表現だが、裏返すと「インターネット公開（Webhook/ゲートウェイ公開）するだけで危険域に入る」可能性があるため、導入者側が隔離を上乗せしない限り安全は担保できない。

サプライチェーン・拡張機構のリスク

Claw系は「スキル」「MCP」「自動ツール生成」といった拡張機構が中核で、ここが供給網の主要リスクになる。

NanoClawは“スキルで自分のフォークを変形させる”思想が明示され、コミット履歴にも“スキル経由のパス脱出”対策が出てくる。拡張の自由度と引き換えに、ファイル操作やパス正規化の実装品質がそのまま安全性になる。

nanobotはMCPのHTTP接続（認証ヘッダ含む）をサポートし、強力だが“外部ツールサーバが侵害された/偽物だった”場合の爆発半径が大きい。MCPサーバ設定は「信用できるREADMEからコピペ可能」と書かれているため、運用では“コピペ元の一次性”を厳格に管理する必要がある。

また、コミュニティ側でも“悪性スキル”を検知するスキャナ（skill-auditor）が存在することから、攻撃が現実的に想定されている領域だと読み取れる。

比較軸テーブル

比較軸	NanoClaw	nanobot	ZeroClaw	IronClaw	PicoClaw
設計の中心	小規模コード + コンテナ隔離	多連携 + 高速改善	軽量ランタイムOS志向	安全設計の仕様化	低リソース最適化
セキュリティ明示度	中〜高	中（改善継続型）	中〜高（配布警戒を明記）	高	中（early development注意あり）
運用の軽さ	中	中	高	中（DB要件あり）	高
更新追従の必要性	中	高	中	中	高
向いている用途	理解しながら育てる個人運用	連携重視の実験/自動化	軽量常用・移植運用	安全重視の常用	Pi系の検証環境

コミュニティやSNSでの評価

公的ベンチマークではなく、コミュニティ投稿・スレッド・リリースノートでの反応を整理する。

NanoClawは「Apple containersをネイティブに使える」「Claude CodeのOAuthサブスクと相性が良い」「デフォルトがWhatsAppだがforkして変えやすい」「自分で自分を改造させるのが最高」といった評価がHacker Newsコメントに現れている。称賛点は“自己改造可能性”と“隔離の安心感”で、痛点は“初期導線（WhatsApp前提）”という傾向。

Claw系全体の混乱としては、「OpenClaw/ZeroClaw/PicoClaw…名前が似すぎて何が何だか分からない」「runtimeとgovernance（権限/監査/マルチユーザ）を分けて見ると理解できる」といった議論がSelfHosting系のスレッドに出ている。これは、導入前に“自分が欲しいのはランタイムか、ガバナンスか、チャネル連携か”を切り分ける必要があることを示す。

日本語コミュニティでは、OpenClaw代替としてZeroClaw等を列挙し、特徴を短くまとめる動きがある（Zennスクラップ）。ただし、ここも一次情報（公式README/リリース）に戻って確認しないと、なりすましや仕様変更に追随できない。

nanobotはリリースノートでメモリ統合の堅牢化、Discord長文分割、MCP再接続、cronの実行不具合など、運用で刺さる不具合が高速で潰されていることが分かる。裏返すと「変化が速い＝追随コストがある」ので、常用するなら更新手順（検証→段階的更新）のコストを検討するべきだろう。

運用向きスコア（判断補助）

下図は本レポートの比較結果を「安全運用との相性（主観評価）」として可視化したものです。公式ベンチマークではなく、導入判断を揃えるための社内用スコアです。

比較マトリクス（検討しているハードウェア前提）

比較マトリクス（要点）

評価は一次ソース上の仕様（隔離モデル、設定/移植性、公式注意喚起、リリース頻度）と、検討ハードに対する現実性で行う。

観点	NanoClaw	nanobot	ZeroClaw	IronClaw	PicoClaw
省リソース	中（Docker前提）	中（Python/Docker）	高（<5MB級を主張）	中（DB要件あり）	高（<10MB級を主張）
隔離の強さ（一次記述）	コンテナ隔離が中心	ACL+チャネル制御＋修正継続	secure default＋注記が強い	WASM能力ベースが最も明確	workspace制限＋早期警告
LLM/プロバイダ柔軟性	Claude中心	非常に広い（OAuth含む）	サブスク認証含む	OpenAI互換なら概ね可	Ollama/カスタム等例示
“公式性”リスクへの注意	特段のなりすまし警告は一次上薄い	同左	README先頭で強烈に警告	仕様中心で警告は相対的に少ない	“公式ドメインのみ/詐欺注意”
更新追随の必要性	中（Releases無）	高（頻繁なpostリリース）	中（v0.xで機能追加）	中（リリース継続）	高（early dev明記）
Raspberry Pi 3B適合	低（Dockerが重い）	低〜中（構成次第）	中（ARM/RISC-V志向）	低（PostgreSQL要件）	高（低リソース志向）

組み合わせ検討

安全なローカル常用（デスクトップ 64GB + 16GB GPU）

最優先が“安全”ならIronClawが最も筋が良い。理由は、WASMサンドボックスの権限仕様が具体的で、秘密情報の扱い（境界注入・暗号化・監査ログ・telemetry無し）まで一次ソースで明言されているため。

デスクトップ側にはGPUがあるため、LLMはローカルに立てたOpenAI互換API（vLLM等）へ寄せ、IronClawは“OpenAI互換エンドポイントに繋げられる”前提で動かす設計が取りやすい。

一方、運用軽量さ（DBを立てたくない、単一バイナリがいい）を優先するならZeroClawが候補になる。特に低メモリ・高速起動、Homebrew導入など“日常運用の軽さ”が強い。

Raspberry Pi 3B / 低リソース実験枠

Raspberry Pi 3B（メモリ1GB級）では、PicoClawが最も方向性が一致する。日本語READMEが低メモリ・多アーキ・低価格ボード運用例を前面に出し、リリースも継続している。

ただしPicoClawは“v1.0まで本番投入しない”と明言しているため、Pi 3Bでは「外に公開しない」「ネットワーク許可先を絞る」「workspace境界を極小にする」などの硬化を前提に“実験用途”として割り切るのが安全。

MacBook Pro 2016 Intel（8GB）での“隔離ランタイム”

古いIntel Macでは、まず「動くこと」「軽いこと」「境界が作りやすいこと」が重要になる。

IronClawはIntel macOS向けプリビルドが明示されており、“動かす”ハードルが下がる。そのうえでWASMサンドボックス中心のため、MacBook側を“危険作業の実行環境”として隔離し、LLMはLAN上のデスクトップGPUサーバへ投げる（＝MacBook側は軽量に保つ）トポロジが作りやすい。

ZeroClawもHomebrew導入例があり、低メモリ志向でMacBook 8GBの制約と相性が良い。ただし、公式性のなりすましが現実に起きているため、入手元（公式リポジトリ）を厳格に固定する必要がある。

NanoClawはmacOS対応だが、Intel MacでDockerを回すと8GBでは重くなりがちで、隔離専用マシンとして最小負荷という意図にはやや合いにくい（Apple ContainerがIntelで軽量に動くかは断言できない）。