ZeroClawのアーキテクチャ設計時、最も初期の決定の一つは拡張性の扱い方だった。OpenClawが拡張可能なAIエージェントの市場需要を証明していた——ClawHubマーケットプレイスには数千のスキルと活発なエコシステムがあった。自明な道は似たものを作ること：マーケットプレイス付きのプラグインシステム。
ZeroClawは真逆の道を選んだ。マーケットプレイスなし。ランタイムプラグインローディングなし。拡張はバイナリにコンパイルされるRust trait。
当時批判者はこの決定をエリート主義と呼んだ——「非Rust開発者を締め出している」と。後にClawHubのサプライチェーン攻撃がOpenClawのスキルレジストリの20%を侵害したとき、批判は静かになった。
この決定の背後にある技術的な理由と、実践的な意味を説明する。
OpenClawのプラグインモデルの仕組み
OpenClawスキルはClawHub（カスタムnpmライクレジストリ）に公開されるNode.jsパッケージだ。スキルのインストールは：
- 1.ClawHubからパッケージをダウンロード
- 2.npm依存関係をインストール（再帰的に独自の依存関係を持つ可能性がある）
- 3.`require()` または `import()` でJavaScriptコードをランタイムロード
- 4.スキルはOpenClawと同じNode.jsプロセスで実行
- 5.プロセスの環境、ファイルシステム、ネットワークへの完全アクセスを持つ
便利だ。そしてインストールされたすべてのスキルがすべてへの暗黙的信頼を得るセキュリティモデルでもある。
問題は累積する：
- •依存ツリーが不透明。 5つの直接依存を持つスキルが200の推移的依存を引き込む可能性がある。すべての監査は非現実的。
- •ランタイムローディングが静的解析を無効にする。 実際に実行するまで何のコードが走るか分析できない。
- •パーミッション境界なし。 Dockerヘルスチェックスキルと銀行APIキーを扱うスキルが同じOSレベルのパーミッションを持つ。
- •アップデートが制御されない。 今日安全なスキルが明日悪意あるアップデートを公開できる。セマンティックバージョニングはこれを防げない——npmのデフォルト動作はminorとpatchの自動受け入れ。
ZeroClawのTraitモデルの仕組み
ZeroClawは三つの拡張ポイントを公開し、すべてRust traitとして定義：
Provider ——AIモデルバックエンド。`Provider` traitを実装して新しいモデルAPIを追加。
Channel ——メッセージングプラットフォーム。`Channel` traitを実装して新しい通信チャネルを追加。
Tool ——エージェント能力。`Tool` traitを実装してエージェントに新しい能力を付与。
各traitは明確なインターフェースを定義：拡張が受け取る入力、返さなければならない出力、付与されるケイパビリティ。OpenClawモデルとの決定的な違い：これらはコンパイルされるものであり、ランタイムロードではない。
ZeroClawにカスタム拡張を追加するということは：
- 1.関連traitを実装するRustモジュールを書く
- 2.ZeroClawの設定に追加
- 3.拡張を含むバイナリをコンパイル
- 4.コンパイルされたバイナリは意図したコードだけを含む——それ以上でもそれ以下でもない
コンパイルがもたらすもの
コンパイルステップは歴史的偶然でもUXの手抜きでもない。セキュリティ境界だ。
コンパイル時の静的解析。 Rustの型システムと借用チェッカーがコード実行前にバグの全クラスを捕捉する。インターフェース外のメモリにアクセスしようとするプロバイダはランタイムではなくコンパイル時に失敗する。traitインターフェース契約に違反する拡張はランタイムクラッシュではなくコンパイラエラーを出す。
推移的依存のサプライズなし。 Cargo.lockファイルがすべての依存の正確なバージョンを固定する。`cargo audit` がRustSecアドバイザリデータベースと照合する。`cargo tree` で完全な依存ツリーを検査できる。npmのネストされたnode_modulesと違い、Cargoの依存解決は決定的で監査可能。
ランタイムコードインジェクションなし。 `eval()` なし、動的パスの `require()` なし、コンパイル時に存在しなかったコードを拡張がロードする方法なし。実行されるバイナリはコンパイルされたバイナリ。以上。
ケイパビリティの強制。 Traitが拡張にできることを定義する。`Tool` trait実装は制限された実行コンテキストを受け取り——与えられたパラメータにアクセスして結果を返すだけ。ファイルシステムアクセス、ネットワークアクセス、環境変数アクセスは自動的には得られない。設定で明示的に付与する必要がある。
トレードオフ：アクセシビリティ vs セキュリティ
批判には一理ある：Rust traitを書くのはJavaScript関数を書くより難しい。学習曲線は現実だ。午後でOpenClawスキルを書ける開発者が、同等のZeroClaw拡張に1週間かかるかもしれない。
ZeroClawは二つの方法でこれを緩和する：
WASM拡張。 Rustを書きたくない開発者はWebAssemblyモジュールを使える。WASMにコンパイルできる任意の言語（Go、C、AssemblyScript、Rust、Zig）で拡張を書き、コンパイルし、明示的なケイパビリティ付与でロード。WASMはサンドボックス実行環境を提供——モジュールは明示的に渡されたものだけにアクセスできる。
コミュニティメンテナンスの拡張。 人気の拡張（追加AIプロバイダ、一般的なメッセージチャネル、広く使われるツール）はZeroClawリポジトリ自体でメンテナンスされている。メンテナがレビューし、CIでテストし、公式バイナリと共に配布。マーケットプレイスなし、ユーザーの信頼判断も不要。
アクセシビリティのギャップは現実だが縮小している。Rustのツーリングは2025年に劇的に改善した。Cargo、rust-analyzer、crateドキュメントのエコシステムがtrait実装の記述を2年前より親しみやすくしている。そしてサポートされているプロバイダとチャネルでZeroClawを使うだけの大多数のユーザーには、Rustの知識は一切不要だ。
ClawHavocが証明したこと
ClawHub攻撃がこのアーキテクチャの賭けを正当化した。824件の悪意あるスキル。レジストリの20%。認証情報の窃取、バックドアのインストール、ネットワーク横断の横展開。
これらの攻撃ベクターはすべてプラグインモデルに依存する：信頼されていないコード、ランタイムローディング、サンドボックスなし、暗黙のフルシステムアクセス。どれもZeroClawのtraitモデルには通用しない。
悪意あるRust traitはインターフェース外のリソースにアクセスしようとするとコンパイルに失敗する。悪意あるWASMモジュールは明示的に許可されなければファイルシステムにアクセスできない。毒を盛るマーケットプレイスがない。偽造するスター数がない。乗っ取る `postinstall` スクリプトがない。
セキュリティアーキテクチャはあらゆる攻撃を防ぐことではない。攻撃のコストをターゲットの価値より高くすることだ。OpenClawのプラグインモデルは攻撃を安価でスケーラブルにした——悪意あるスキル一つで数千の被害者。ZeroClawのtraitモデルは攻撃を高価で封じ込め可能にした——ターゲットごとに専門的な労力が必要で、爆発半径がケイパビリティ付与で制限される。
より大きな原則
プラグイン vs traitの決定は、どんなエコシステムを望むかについてのより深い選択を反映している。
プラグインマーケットプレイスは成長を最適化する。低い公開摩擦、低いインストール摩擦、エコシステムが拡大する面積を最大化。エコシステムが信頼できるときこれはうまく機能する。信頼できないとき壊滅的に失敗する。
Traitベースの拡張は整合性を最適化する。より高い公開摩擦、より高いインストール摩擦。しかし存在するすべての拡張が意図的に追加され明示的にケイパビリティを付与されている。エコシステムはゆっくり成長する。しかし爆発もしない。
AIエージェント分野は成長が整合性より重要に感じられる段階にある。ClawHavocは整合性がいずれ追いつくことを思い出させる。そして後から組み込むコストは最初から組み込むコストより常に高い。